1. Modelo espiral
1.1. Caracteristicas:
1.1.1. -En cada giro se construye un nuevo modelo del sistema completo. -Este modelo puede combinarse con otros modelos de proceso de desarrollo (cascada,evolutivo) -Mejor modelo para el desarrollo de grandes sistemas. -El análisis de riesgo requiere la participaciónde personal con alta cualificación
1.2. Etapas (Ciclos):
1.2.1. -Planificación -Análisis de riesgo -Evaluación del cliente -Ingenieria
1.2.1.1. Desarrollo cíclico (iterativo) donde en cada ciclo se llevan a cabo 4 tareas: –Determinación de objetivos, alternativas y restricciones –Evaluación de alternativas, análisis y control de riesgos. –Desarrollo y verificación del producto. –Planificación del siguiente ciclo (fase).
1.3. Ventajas:
1.3.1. -No necesita una definición completa de los requisitos para empezara funcionar. -Al entregar productos desdeel final de la primera iteración es más fácil validar los requisitos. -El riesgo en general es menor, porque si todo se hace mal, solo se ha perdido el tiempo y recursosinvertidos en una iteración (las anteriores iteraciones estánbien). -El riesgo de sufrir retrasos es menor, ya que al identificar los problemas en etapas tempranas hay tiempode subsanarlos.
1.4. Desventajas:
1.4.1. -Es difícil evaluar los riesgos. -Necesita de la participación continua por parte del cliente. -Cuando se subcontrata hay que producir previamente una especificación completa de lo que se necesita, y esto lleva tiempo.
2. Modelo de prototipos
2.1. Caracteristicas:
2.1.1. El modelo de prototipos permite que todo el sistema, o algunos de sus partes, se construyan rápidamente para comprender con facilidad y aclarar ciertos aspectos en los que se aseguren que el desarrollador, el usuario, el cliente estén de acuerdo en lo que se necesita así como también la solución que se propone para dicha necesidad y de esta forma minimizar el riesgo y la incertidumbre en el desarrollo, este modelo se encarga del desarrollo de diseños para que estos sean analizados y prescindir de ellos a medida que se adhieran nuevas especificaciones, es ideal para medir el alcance del producto, pero no se asegura su uso real.
2.2. Etapas de elaboracion:
2.2.1. -Identificar requerimientos básicos del usuario -Desarrollar prototipo inicial -Usar el prototipo -Revisión y mejora del prototipo
2.3. Ciclo de vida:
2.3.1. -Definición de proyecto -Análisis del sistema -Diseño -Programación -Instalción -Post-Implantación
2.4. Clasificación de modelos:
2.4.1. -Modelo de rendimiento -Modelo a escala no funcional -Modelo a escala completa -Modelo con características esenciales
2.5. Ventajas:
2.5.1. Este modelo es útil cuando el cliente conoce los objetivos generales para el software, pero no identifica los requisitos detallados de entrada, procesamiento o salida. También ofrece un mejor enfoque cuando el responsable del desarrollo del software está inseguro de la eficacia de un algoritmo, de la adaptabilidad de un sistema operativo o de la forma que debería tomar la interacción humano-máquina.
2.6. Desventajas:
2.6.1. El cliente ve funcionando lo que para él es la primera versión del prototipo que ha sido construido con “plastilina y alambres”, y puede desilusionarse al decirle que el sistema aún no ha sido construido. El desarrollador puede ampliar el prototipo para construir el sistema final sin tener en cuenta los compromisos de calidad y de mantenimiento que tiene con el cliente.
3. Modelo concurrente
3.1. Definición:
3.1.1. Define una serie de acontecimientos que dispararán transiciones de estado a estado para cada una de las actividades. Durante las primeras etapas del diseño, no se contempla una inconsistencia del modelo de análisis. Esto genera la corrección del modelo de análisis de sucesos, que disparará la actividad de análisis del estado hecho al estado cambios en espera.
3.2. Características:
3.2.1. -se puede expresar de manera esquematizada -las actividades llevan procesos concurrentes -es aplicable a todo tipo de desarrollo de software -es un modulo aplicable para cliente soñador -esta dirigido por las necesidades del usuario -es aplicable al cliente servidor
3.3. Etapas:
3.3.1. Actividad de análisis con estados de actividad y son los siguientes: -Ninguna -Bajo desarrollo -Cambios en espera -Bajo revisión -Bajo modificación -En linea base -Realizado
3.4. Ventajas:
3.4.1. -Excelente para proyectos en los que se conforman grupos de trabajo independientes. -Proporciona una imagen exacta del estado actual de un proyecto.
3.5. Desventajas:
3.5.1. -Si no se dan las condiciones señaladas no es aplicable. -Si no existen grupos de trabajo no se puede trabajar en este método
4. Modelo en cascada
4.1. Caracteristicas:
4.1.1. -Es el más utilizado. -Es una visión del proceso de desarrollo de software como una sucesión de etapas que producen productos intermedios. -Para que el proyecto tenga éxito deben desarrollarse todas las fases. -Las fases continúan hasta que los objetivos se han cumplido. -Si se cambia el orden de las fases, el producto final será de inferior calidad
4.2. Etapas:
4.2.1. -Análisis y definición de requerimientos. -Diseño del sistema y software. -Implementación y prueba de unidades. -Integrasción y prueba del sistema. -Funcionamiento y mantenimiento.
4.3. Ventajas:
4.3.1. -La Documentación se va produciendo en cada fase. -El Modelo cuadra con otros modelos del proceso de ingeniería.
4.4. Desventajas:
4.4.1. -Inflexibilidad : al dividir el proyecto en distintas etapas. -Es difícil responder a cambios en los requerimientos del cliente.
5. Incremental
5.1. Caracteristicas:
5.1.1. Combina elementos del modelo lineal con la filosofía de creación de prototipos. -El primer incremento a menudo es un producto esencial(núcleo). -A partir de la evaluación se planea el siguiente incremento y así sucesivamente. -Es interactivo por naturaleza -Es útil cuando el personal no es suficiente para la implementación completa. -Se evitan proyectos largos y se entrega "algo de valor" a los usuarios con cierta frecuencia. -El usuario se involucra mas. -Difícil de evaluar el costo total. -Difícil de aplicar a los sistemas transaccionales que tienden a ser integrados y a operar como un todo. -Requiere gestores experimentados. -Los errores en los requisitos se detectan tarde. -El resultado puede ser positivo.
5.2. Etapas:
5.2.1. -Análisis. -Diseño. -Código. -Prueba.
5.3. Ventajas:
5.3.1. -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 proporciona todas las ventajas del modelo en Cascada re-alimentado, reduciendo sus desventajas sólo al ámbito de cada incremento. -Resulta más sencillo acomodar cambios al acotar el tamaño de los incrementos.
5.4. Desventajas:
5.4.1. -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
6. DRA
6.1. Caracteristicas:
6.1.1. Modelo de proceso del desarrollo del software lineal secuencial que enfatiza un ciclo de desarrollo extremadamente corto. Es una adaptación a “Alta velocidad” 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 limita el ámbito del proyecto, el proceso DRA permite al equipo de desarrollo crear un “sistema completamente funcional” dentro de periodos cortos de tiempo.
6.2. Etapas:
6.2.1. -Modelado de gestión -Modelado de datos -Modelado de proceso -Generación de aplicaciones -Pruebas y entrega
6.3. Ventajas:
6.3.1. -Es muy rápido. -Permite trabajar en él a varias personas a la vez
6.4. Desventajas:
6.4.1. -Para proyectos grandes aunque por escalas, el DRA requiere recursos humanos suficientes como para crear el número correcto de equipos DRA. -Requiere clientes y desarrolladores comprometidos en las rápidas actividades necesarias para completar un sistema en un marco de tiempo abreviado. Si no hay compromiso, por ninguna de las partes constituyentes, los proyectos DRA fracasaran. -No todos los tipos de aplicaciones son apropiados para DRA. Si un sistema no se puede modulizar adecuadamente. -La construcción de los componentes necesarios para DRA será problemático. Si está en juego el alto rendimiento, y se va a conseguir el rendimiento convirtiendo interfaces en componentes de sistema, el enfoque DRA puede que no funcione. -No es adecuado cuando los riesgos técnicos son altos. Esto ocurre cuando una nueva aplicación hace uso de tecnologías nuevas, o cuando el nuevo software requiere un alto grado de interoperabilidad con programas de computadora ya existentes. -Enfatiza el desarrollo de componentes de programas reutilizables. La reutilización es la piedra angular de las tecnologías de objetos, y se encuentra en el modelo de proceso de ensamblaje