ANÁLISIS Y DISEÑO ORIENTADO A OBJETOS

2. Es una estructura aplicada al desarrollo de un producto
de software. Hay varios modelos a seguir para el
establecimiento de un proceso para el desarrollo de
software, cada uno de los cuales describe un enfoque
diferente para diferentes actividades que tienen lugar
durante el proceso.

3. Los modelos de desarrollo de software son una representación
abstracta de una manera en particular. Realmente no representa
cómo se debe desarrollar el software, sino de un enfoque común.
Puede ser modificado y adaptado de acuerdo a las necesidades del
software en proceso de desarrollo. Hay varios modelos para perfilar
el proceso de desarrollo, cada uno de las cuales cuenta con pros y
contras. El proyecto debería escoger el más apropiado para sus
necesidades. En ocasiones puede que una combinación de varios
modelos sea apropiado.

4. Si se aplica este paradigma, unos de los principales
problemas , es que las etapas realizadas no son
autónomas de las siguientes, creando una
dependencia estructural y en el acaso de un error
atrasaría todo el proyecto.

5. El modelo o paradigma orientado a objetos
posee DOS CARACTERÍSTICAS principales, las
cuales son:
•Permite la re-utilización de software.
•Facilita el desarrollo de herramientas
informáticas de apoyo al desarrollo, el cual es
simple al implementarla en una notación
orientado a objetos llamado UML.

6. Es un paradigma de las Metodologías De
Desarrollo basado en procesos ágiles. Estos intentan
evitar los tediosos caminos de las metodologías
tradicionales enfocándose en las personas y los
resultados. Usa un enfoque basado en el Valor para
construir software, colaborando con el cliente e
incorporando los cambios continuamente.

7. 1.Especificación de requisitos
2.Diseño del software
3.Construcción o Implementación del
software
4.Integración
5.Pruebas (o validación)
6.Despliegue (o instalación)
7.Mantenimiento
Siguiendo el modelo de cascada de forma estricta, sólo cuando se finaliza
una fase, comienza la otra. En ocasiones se realiza una revisión antes de
iniciar la siguiente fase, lo que permite la posibilidad de cambios (lo que
puede incluir un proceso de control formal de cambio). Las revisiones
también se utilizan para asegurar que la fase anterior ha sido totalmente
finalizada.

8. El modelo espiral de los procesos software es un modelo
del ciclo de meta-vida. En este modelo, el esfuerzo de
desarrollo es iterativo. Tan pronto como uno completa un
esfuerzo de desarrollo, otro comienza.
-Determinar qué queremos lograr.
-Determinar las rutas alternativas que podemos tomar para
lograr estas metas. Por cada una, analizar los riesgos y
resultados finales, y seleccionar la mejor.
-Seguir la alternativa seleccionada en el paso 2.
-Establecer qué se tiene terminado.

9. Como el modelo espiral, el modelo concurrente provee una meta-descripción
del proceso software. Mientras que la contribución primaria del modelo espiral
es en realidad que esas actividades del software ocurran repetidamente, la
contribución del modelo concurrente es su capacidad de describir las múltiples
actividades del software ocurriendo simultáneamente.

10. El desarrollo incremental es el proceso de construcción
siempre incrementando subconjuntos de
requerimientos del sistema. Típicamente, un
documento de requerimientos es escrito al capturar
todos los requerimientos para el sistema completo.
El modelo de desarrollo incremental provee algunos
beneficios significativos para los proyectos:
•Construir un sistema pequeño es siempre menos
riesgoso que construir un sistema grande.
•Al ir desarrollando parte de las funcionalidades, es
más fácil determinar si los requerimientos planeados
para los niveles subsiguientes son correctos.
•Si un error importante es realizado, sólo la última
iteración necesita ser descartada.

11. El modelo de desarrollo evolutivo (algunas veces denominado como
prototipado evolutivo) construye una serie de grandes versiones
sucesivas de un producto. Sin embargo, mientras que la
aproximación incremental presupone que el conjunto completo de
requerimientos es conocido al comenzar, el modelo evolutivo asume
que los requerimientos no son completamente conocidos al inicio del
proyecto.