CUADRO COMPARATIVO – MODELOS DE DESARROLLOTIPO DE MODELO

MODELO DE

DESARROLLO DE SOFTWA

RE

CARACTERISTICAS

FASES VENTAJAS DESVENTAJAS ESTRUCTURA

SECUENCIALES

CASCADA

Ordena rigurosamente las etapas del ciclo de vida del software, de forma tal que el inicio de cada etapa debe esperar a la finalización de la inmediatamente anterior.

Una de las contribuciones más importantes del modelo cascada es para los administradores, posibilitándoles avanzar en el desarrollo, aunque en una escala muy bruta.

• Los cambios introducidos durante el desarrollo pueden confundir al equipo profesional en las etapas tempranas del proyecto. Si los cambios se producen en etapa madura (codificación o prueba) pueden ser catastróficos para un proyecto grande. • No es frecuente que el cliente o usuario final explicite clara y completamente los requisitos (etapa de inicio); y el modelo lineal lo requiere. La incertidumbre natural en los comienzos es luego difícil de acomodar. • El cliente debe

tener paciencia ya que el software no estará disponible hasta muy avanzado el proyecto. Un error detectado por el cliente (en fase de operación) puede ser desastroso, implicando reinicio del proyecto con altos costos.

MODELO V

Representación gráfica del ciclo de vida del desarrollo de un sistema.

En él se resumen las principales medidas que deben adoptarse en relación con las prestaciones correspondientes en el marco del sistema informático de validación.

Aquí se

Fase # 1: está orientado al “cliente”. El inicio del proyecto y el fin del proyecto constituyen los dos extremos del ciclo. Se componen del análisis de requisitos y especificaciones, se traduce en un documento de requisitos y especificaciones.

Fase # 2: se dedica a las características funcionales del sistema propuesto. Puede considerarse el sistema como una caja negra, y caracterizarla únicamente con aquellas funciones que son directa o indirectamente visibles por el usuario final, se traduce en un documento de análisis funcional.

Fase # 3: Define los componentes hardware y software del sistema

Es un modelo sencillo y de fácil aprendizaje.

La relación entre las etapas de desarrollo y los distintos tipos de pruebas facilitan la localización de fallos.

Especifica bien los roles de los distintos tipos de pruebas a realizar

Involucra al usuario en las

El cliente debe tener paciencia pues obtendrá el producto al final del ciclo de vida

Las pruebas pueden ser caras y, a veces, no lo suficientemente efectivas•

El producto final obtenido puede que no refleje todos los requisitos del usuario

No se puede repetir la secuencia de pasos si este no sale bien; Se debe realizar nuevamente todo el proceso de validación

describen las actividades y resultados que deben producirse durante el desarrollo del proyecto.Es una variación del modelo en cascada que muestra cómo se relacionan las actividades de prueba con el análisis y el diseño.

final, a cuyo conjunto se denomina arquitectura del sistema.

Fase # 4: Es la fase de implementación, en la que se desarrollan los elementos unitarios o módulos del programa.

pruebas y verificación.

MODELO W

Lo que hace el modelo en W es diferenciar claramente cuáles son los hitos de un proyecto software (algo que podía resultar confuso en el modelo en V) de manera que en la primera

Fases de desarrollo de software Especificación de requisitos. Análisis. Diseño Construcción.

Fases testing temprano Revisión, requisitos y plan de

pruebas de aceptación. Revisión, análisis y plan de

pruebas funcionales. Revisión, diseño y plan de

pruebas. Construcción de pruebas.

*Más claro y completo *Hace explícito parte de la iteración y trabajo que hay que revisar *Especifica bien los roles de los distintos tipos de pruebas a realizar

Mantenimiento costoso para el usuario.

Si ocurre una falla en una fase , no se puede continuar en la siguiente.

Los errores en cualquier fase no permiten avanzar a la siguiente hasta no

recta están los hitos previos a la construcción del software (con las pruebas y verificaciones correspondientes a los hitos documentales) y en la segunda los posteriores a la construcción del software

Fases testing software Pruebas de aplicación. Pruebas funcionales y de

sistema. Pruebas unitarias y de

integración. Pruebas de código.

repararsen.

ITERATIVOS DRA(RAD)

El Desarrollo Rápido de Aplicaciones (DRA) es un modelo de proceso del desarrollo del software lineal secuencial que enfatiza un ciclo de desarrollo extremadamente corto. El modelo DRA es una adaptación a “alta velocidad” del modelo lineal secuencial en el que se logra el desarrollo rápido utilizando un enfoque de construcción basado en componentes.

Si se comprenden bien los requisitos y se

•El modelado de Gestión se modela respondiendo a: ¿Qué información conduce el modelo de gestión?, ¿Qué información se genera?, ¿Quién la genera?, ¿A dónde va la información?, ¿Quién la procesa?.

•El modelado de Datos refina la información determinada en el paso anterior con la definición de un conjunto de objetos de datos con metodologías propias para tal fin.

•El modelado del proceso define funciones de gestión (insertar, borrar, modificar, recuperar) que utilizan el modelo de datos definido para procesar la información.

•La generación de la aplicación debe realizarse con herramientas de cuarta generación con herramientas que automatizan la creación de componentes y su reutilización.

•Finalmente la etapa de pruebas y entrega se supone es corta por la reutilización de software ya existente y correcto.

Desarrollo completo de una Aplicación en poco tiempo.

+Progreso más difícil de medir.

Para proyectos grandes el DRA requiere recursos humanos suficientes.

•Requiere clientes y desarrolladores comprometidos con las actividades rápidas. •No Todas las aplicaciones son candidatas a utilizar DRA.

•No es Adecuado en altos riesgos.

limita el ámbito del proyecto, el DRA permite al equipo de desarrollo implementar un “Sistema completamente funcional”, dentro de períodos cortos tiempo

ESPIRAL Modelo centrado en las actividades, las cuales son organizadas en ciclos. Consiste en una serie de ciclos que se repiten en forma de espiral, comenzando desde el centro.

1. Determinar o fijar los objetivos. En este paso se definen los objetivos específicos para posteriormente identifica las limitaciones del proceso y del sistema de software, además se diseña una planificación detallada de gestión y se identifican los riesgos.

2. Análisis del riesgo. En este paso se efectúa un análisis detallado para cada uno de los riesgos identificados del proyecto, se definen los pasos a seguir para reducir los riesgos y luego del análisis de estos riesgos se planean estrategias alternativas.

3. Desarrollar, verificar y validar. En este tercer paso, después del análisis de riesgo, se eligen un paradigma para el desarrollo del sistema de software y se

No requiere una definición completa de los requerimientos del software a desarrollar para comenzar su funcionalidad.

En la terminación de un producto desde el final de la primera iteración es muy factible aprobar los requisitos.

Sufrir retrasos corre un riesgo menor, porque

• Requiere mucha experiencia y habilidad para la evaluación de los riesgos, lo cual es requisito para el éxito del proyecto. • Es difícil convencer a los grandes clientes que se podrá controlar este enfoque evolutivo.

lo desarrolla.

4. Planificar. En este último paso es donde el proyecto se revisa y se toma la decisión si se debe continuar con un ciclo posterior al de la espiral. Si se decide continuar, se desarrollan los planes para la siguiente fase del proyecto.

se comprueban los conflictos presentado tempranamente y existe la forma de poder corregirlos a tiempo.

SCRUM Scrum es una metodología para la gestión y desarrollo de software basada en un proceso iterativo e incremental utilizado comúnmente en entornos basados en el desarrollo ágil de software; Scrum es un proceso en el que se aplican de manera regular un conjunto de mejores prácticas para trabajar en equipo y

1. Planificación de la iteración ( selección de requisitos) 2. Ejecución de la planificación. 3. Inspección y adaptación.

Se obtiene software lo más rápido posible y este cumple con los requerimientos más importantes.• Se trabaja en iteraciones cortas, de alto enfoque y total transparencia.• Se acepta que el cambio es una constante universal y se adapta el desarrollo para integrar los cambios que son importantes.• Se incentiva la creatividad de

Falta de

documentación del

diseño. Al no haber

documentación es el

código (junto con sus

comentarios) lo que

se toma como

documentación.

Problemas derivados

de la comunicación

oral. No hace falta

decir que algo que

está escrito “no se

puede borrar”, en

cambio, algo dicho es

muy fácil crear

obtener el mejor resultado posible de un proyecto.Aunque Scrum estaba enfocado a la gestión de procesos de desarrollo de software, puede ser utilizado en equipos de mantenimiento de software, o en una aproximación de gestión de programas: Scrum de Scrum.Scrum es una metodología ágil, y como tal:

• Es un modo de desarrollo de carácter adaptable más que predictivo.

los desarrolladores haciendo que el equipo sea auto administrado.• Se mantiene la efectividad del equipo habilitando y protegiendo un entorno libre de interrupciones e interferencias.• Permite producir software de una forma consistente, sostenida y competitiva.• Las reuniones se dedican a inconvenientes recientes, evitando el estancamiento

ambigüedad.

Fuerte dependencia

de las personas.

Falta de reusabilidad

derivada de la falta de

documentación

Restricciones en

cuanto a tamaño de

los proyectos

Problemas derivados

del fracaso de los

proyectos ágiles. Si

un proyecto ágil

fracasa no hay

documentación o hay

muy poca; lo mismo

ocurre con el diseño.

La comprensión del

sistema se queda en

las mentes de los

• Orientado a las personas más que a los procesos.

• Emplea la estructura de desarrollo ágil:Incremental basada en iteraciones y revisiones.

desarrolladores.

INCREMANTALES O EVOLUTIVOS

Incremental

Modelos que consisten en un desarrollo inicial de la arquitectura completa del sistema, seguido de sucesivos incrementos funcionales.

AnálisisDiseñoProgramación Pruebas.

Con un paradigma incremental se reduce el tiempo de desarrollo inicial, ya que se implementa la funcionalidad parcial.- También provee un impacto ventajoso frente al cliente, que es la entrega temprana de partes operativas del Software.- El modelo

El modelo Incremental no es recomendable para casos de sistemas de tiempo real, de alto nivel de seguridad, de procesamiento distribuido, y/o de alto índice de riesgos.

- Requiere de mucha planeación, tanto administrativa como técnica.

- Requiere de metas claras para conocer el estado del proyecto.

proporciona todas las ventajas del modelo en cascada realimentado, reduciendo sus desventajas sólo al ámbito de cada incremento.- Permite entregar al cliente un producto más rápido en comparación del modelo de cascada.- Resulta más sencillo acomodar cambios al acotar el tamaño de los incrementos.- Por su versatilidad requiere de una planeación cuidadosa tanto a nivel administrativo como técnico.