Modelo en Espiral:
Es un modelo que se caracteriza por ser evolutivo, es decir,
cambia constantemente y se puede adaptar y aplicar a lo largo de la vida del
software de la computadora. Como se encuentra en constante evolución el
desarrollador y el cliente comprenden y reaccionan sin ningún tipo de problema ante
riesgos en cada uno de los nivele evolutivos.
Permite al desarrollador aplicar el enfoque de construcción
de prototipos en cualquier etapa de evolución del producto y demanda una
consideración directa de los riesgos técnicos en todas las etapas del proyecto,
si se aplica adecuadamente debe reducir los riesgos antes de que se conviertan
en problemas, permitiendo así un mejor desarrollo del mismo.
Dado que la construcción de prototipos se realiza en
pequeños fragmentos, la estimación de costos se realiza de una manera más fácil
y el cliente puede obtener el control sobre la administración del nuevo
sistema. Controla muy bien los riesgos y mientras más iteraciones se realicen,
menos riesgos habrá, a su vez monitoriza y controla los riesgos continuamente
incorporando objetivos de calidad.
Modelo en Cascada:
Su principal
beneficio es que ninguna de sus etapas se cruza con la otra, lo que proporciona
un mejor desarrollo de ellas, a su vez posee un tipo de planificación sencilla,
lo cual puede ser muy apropiado si se aplica en proyectos estables y no en
proyectos que se encuentren en constante cambio.
Este modelo promueve una metodología de trabajo efectiva:
Definir antes que diseñar, diseñar antes que codificar y es muy útil porque
ayuda a los desarrolladores a comprender qué es lo que tienen que hacer en cada
momento y en cada una de las etapas. La calidad del producto resultante es alta
y por ser un modelo muy fácil de usar, permite trabajar con personal poco
calificado.
Modelo Incremental:
Con un paradigma incremental se puede reducir el tiempo de
desarrollo inicial, ya que se implementa la funcionalidad parcial, a su vez
provee un gran impacto frente al cliente, como lo es la entrega temprana de
partes operativas del software.
Este modelo puede proporcionar los mismos beneficios que el
modelo en cascada con la diferencia que le permite entregar al cliente un
producto más rápido y en menos tiempo.
Resulta más sencillo acomodar cambios al establecer un
límite del tamaño de los incrementos, es un modelo flexible, por lo que se
reduce el coste en el cambio de alcancey requisitos.
Es más fácil probar y depurar en una iteración más pequeña,
también facilita la gestión de los riesgos y por su versatilidad requiere de
una planeación cuidadosa tanto a nivel administrativo como técnico.
Modelo en V:
Este modelo, especifica muy bien los roles de los distintos
tipos de pruebas a realizar, hace más explícita la tarea parte de la iteración
de las actividades del proceso. La relación que existe entre las etapas de
desarrollo y los distintos tipos de pruebas facilitan una mejor localización de
fallos que puedan existir sin tener que esperar a que sean rectificados en la
etapa final del proceso.
Es un modelo muy sencillo y tiene una manera fácil de aprendizaje
ya que Involucra al usuario en las distintas pruebas que realiza, a su vez involucra
chequeos de cada una de las etapas del método Cascada. La diferencia es que es
un método más robusto y completo que el método cascada y produce software de
mayor calidad que con el modelo cascada.
Con las pruebas unitarias que se realizan y las de
integración se consigue obtener exactitud en los programas.
Modelo lineal:
Su principal beneficio es la sencillez de su gestión y
administración tanto a nivel económico como el tiempo establecido. Se ajusta
perfectamente a los proyectos internos que puedan poseer las empresas
referentes a programas muy pequeños.
Las posibilidades de error durante el proceso de codificación
se minimizan a igual necesidad del requerimiento de la información por parte
del usuario o cliente.
Modelo basado en
transformaciones:
Tiene una mejor
posibilidad de la comprobación de los errores en las etapas iniciales de su desarrollo,
así como también la posibilidad de un mantenimiento a nivel de especificación,
evitando tener que modificar un código que esté mal estructurado después de
repetidos procesos de optimización.
Tiene un soporte tanto para la
validación de los requisitos como uno de reusabilidad, tiene una gran potencia
en la especificación que se orienta al problema.
