Cascada:

Generalidades:
El modelo de desarrollo en cascada se originó en la industria y la construcción,
donde los cambios a posteriori son caros y difíciles de implementar. Cuando estás
creando un producto material, realizar cambios en lo ya construido es mucho más
difícil que en un programa informático. En el mundo del software, todavía no se
habían implantado otras metodologías de desarrollo por lo que se adaptó el
modelo en cascada que se utilizaba en otros sectores
Características:
Es un proceso de desarrollo secuencial, en el que el desarrollo de software se
concibe como un conjunto de etapas que se ejecutan una tras otra. Se le
denomina así por las posiciones que ocupan las diferentes fases que componen el
proyecto, colocadas una encima de otra, y siguiendo un flujo de ejecución de
arriba hacia abajo, como una cascada.
El modelo de desarrollo en cascada sigue una serie de etapas de forma sucesiva,
la etapa siguiente empieza cuando termina la etapa anterior
Etapas del modelo:
1. Requisitos del software
2. Diseño
3. Implementación
4. Verificación
5. Instalación y mantenimiento

Donde se puede usar:

En el desarrollo de software
Ventajas y desventajas:
Ventajas
El tiempo que se pasa en diseñar el producto en las primeras fases del proceso
puede evitar problemas que serían más costosos cuando el proyecto ya estuviese
en fase de desarrollo.
La documentación es muy exhaustiva y si se une al equipo un nuevo
desarrollador, podrá comprender el proyecto leyendo la documentación.
Al ser un proyecto muy estructurado, con fases bien definidas, es fácil entender el
proyecto.
Ideal para proyectos estables, donde los requisitos son claros y no van a cambiar
a lo largo del proceso de desarrollo.

Inconvenientes
En muchas ocasiones, los clientes no saben bien los requisitos que necesitarán
antes de ver una primera versión del software en funcionamiento. Entonces,
cambiarán muchos requisitos y añadirán otros nuevos, lo que supondrá volver a
realizar fases ya superadas y provocará un incremento del coste.
No se va mostrando al cliente el producto a medida que se va desarrollando, si no
que se ve el resultado una vez ha terminado todo el proceso. Esto cual provoca
inseguridad por parte del cliente que quiere ir viendo los avances en el producto
Los diseñadores pueden no tener en cuenta todas las dificultades que se
encontrarán cuando estén diseñando un software, lo que conllevará rediseñar el
proyecto para solventar el problema.
Para proyectos a largo plazo, este modelo puede suponer un problema al cambiar
las necesidades del usuario a lo largo del tiempo. Si por ejemplo, tenemos un
proyecto que va a durar 5 años, es muy probable que los requisitos necesiten
adaptarse a los gustos y novedades del mercado.

Metodo en V
Es un proceso que representa la secuencia de pasos en el desarrollo del ciclo de
vida de un proyecto. Se describen las actividades y resultados que deben
producirse durante el desarrollo del producto. El lado izquierdo de la V representa
la descomposición de las necesidades, y la creación de las especificaciones del
sistema. El lado derecho de la V representa la integración de las piezas y su
verificación. V significa «Verificación y validación». Es muy similar al modelo de la
cascada clásico ya que es muy rígido y contiene una gran cantidad de iteraciones.
Caracteristicas
El Método-V fue desarrollado para regular el proceso de desarrollo de software por
la Administración Federal Alemana. Describe las actividades y los resultados que
se producen durante el desarrollo del software.
Proporciona una guía para la planificación y realización de proyectos. Los
siguientes objetivos están destinados a ser alcanzados durante la ejecución del
proyecto:
Minimización de los riesgos del proyecto
Mejora la transparencia del proyecto y control del proyecto, especificando los
enfoques estandarizados, describe los resultados correspondientes y funciones de
responsabilidad. Permite una detección temprana de las desviaciones y los
riesgos y mejora la gestión de procesos, reduciendo así los riesgos del proyecto.

Mejora y Garantía de Calidad

Como un modelo de proceso estándar, asegura que los resultados que se
proporcionan sean completos y contengan la calidad deseada. Los resultados
provisionales definidos se pueden comprobar en una fase temprana. La
uniformidad en el contenido del producto mejora la legibilidad, comprensibilidad y
verificabilidad.
Etapas del modelo:
La corriente de especificación (parte izquierda, Project definition) consiste
principalmente de:
Conceptos de operaciones: qué debe hacer el sistema a grandes rasgos.
Requisitos del sistema y arquitectura del mismo.
Diseño detallado.
La corriente de pruebas (parte derecha, Project test and integration), por su parte,
suele consistir de:
Integración de las distintas partes, prueba y verificación de las mismas.
Verificación y validación del sistema en conjunto.
Mantenimiento del sistema.
Donde se puede usar:
en personalización, configuración o codificación. desarrollo de software
Ventajas y desventajas:
VENTAJAS:
•El modelo en V hace más explicita la tarea parte de la iteración de las actividades
del proceso.
•Las pruebas de cada fase ayudaran a corregir posibles errores sin tener que
esperar a que sean rectificados en la etapa final del proceso.
•Con las pruebas unitarias y de integración se consigue obtener exactitud en los
programas.
DESVENTAJAS:
•Al encontrarse errores luego de realizar las pruebas se pierde tiempo y dinero, ya
que cada prueba se realiza luego de haber terminado la implementación.
En el caso de este modelo son, obviamente, más las ventajas que encontramos,
hace el proceso más dinámico, con la opción de realizar pruebas que nos
ayudarán a corregir posibles errores durante su fase de desarrollo además de
poseer ventajas realmente notables que lo convierten en un modelo más completo
y robusto que nos ayudaran a obtener un sistema de mejor calidad.

Diente de tiburón
Dientes de Sierra
El modelo diente de sierra muestra las percepciones del sistema por parte del
usuario y el desarrollador del software en diferentes niveles de abstracción a lo
largo del tiempo. En cada fase de desarrollo del proyecto, el contacto directo con
el cliente permite la retroalimentación del proceso y la adaptación a las
necesidades y requerimientos. Sin llevar un proceso exhaustivo y excesivo de
documentación, se recolectaron los puntos críticos y de corrección que el cliente
entregaba a los desarrolladores. Al inicio del proyecto los desarrolladores y el
cliente están en el mismo nivel de abstracción,. Durante el desarrollo estos puntos
de vista difieren un poco. El usuario permanece en el nivel de los requerimientos,
mientras que los desarrolladores se enfocan en la factibilidad. El proceso de
desarrollo de software tiene que asegurar que ambos puntos de vista se reúnan al
final del proyecto. El modelo de diente de sierra logra este objetivo introduciendo
nuevas actividades que fueron acordadas junto con el cliente, para esto se
incluyeron actividades tales como reuniones, pruebas junto con el cliente y
aclaración de los requerimientos.

Espiral
es un enfoque de desarrollo de software que puede ser considerado como una
respuesta a los inconvenientes del desarrollo en cascada. El modelo en espiral
describe el ciclo de vida de un software por medio de espirales, que se repiten
hasta que se puede entregar el producto terminado.
Caracteristicas
Una característica clave del desarrollo en espiral es la minimización de los riesgos
en el desarrollo de software, lo que podría resultar en un aumento de los costes
totales, más esfuerzo y un lanzamiento retardado. Estos riesgos son
contrarrestados por el enfoque incremental, haciendo primero prototipos, que
luego pasan al menos una vez, por las fases de desarrollo de software. El
desarrollo en espiral es genérico y puede combinarse con otros métodos de
desarrollo clásicos y ágiles, por lo que también se denomina modelo o desarrollo
de segundo orden.
Etapas del modelo:
Objetivo y determinación alternativa:
Los objetivos se determinan conjuntamente con el cliente. Al mismo tiempo, se
discuten posibles alternativas y se especifican las condiciones marco (por ejemplo,
sistemas operativos, entornos y lenguajes de programación).
Análisis y evaluación de riesgos:
Se identifican y evalúan los riesgos potenciales. También se evalúan las
alternativas existentes. Los riesgos son registrados, evaluados y luego reducidos
utilizando prototipos, simulaciones y softwares de análisis. En este ciclo, existen
varios prototipos como plantillas de diseño o componentes funcionales
Desarrollo y prueba:
Los prototipos se amplían y se añaden funcionalidades. El código real es escrito,
probado y migrado a un entorno de prueba varias veces hasta que el software
pueda ser implementado en un entorno productivo.
Planificación del siguiente ciclo:
El siguiente ciclo se planifica al final de cada etapa. Si se producen errores, se
buscan soluciones, y si una alternativa es una mejor solución, se prefiere en el
siguiente ciclo.

Beneficios / Desventajas
El modelo de desarrollo en espiral se utiliza a menudo para proyectos más
grandes que están sujetos a riesgos. Dado que estos riesgos tienen un impacto
monetario directo, el control de los presupuestos de los clientes y de las empresas
promotoras es fundamental. El modelo en espiral se utiliza especialmente en los
nuevos entornos técnicos, ya que éstos suponen un riesgo.[2]
Los conflictos entre los requisitos de un software y su diseño se evitan
eficazmente mediante el enfoque cíclico, ya que los requisitos pueden
comprobarse constantemente y, si es necesario, modificarse. [3]
Se puede obtener feedback de los usuarios, desarrolladores y clientes en las
primeras fases del proyecto. Sin embargo, esta estructura también requiere una
gestión que tenga en cuenta los ciclos del producto y pueda responder
rápidamente a los riesgos. El control de tales proyectos es, por lo tanto,
relativamente complejo y también requiere una buena documentación para que se
registren todos los cambios.
Aunque el software se prueba bajo varios aspectos durante el ciclo de desarrollo y
prueba (unidad, prueba de aceptación e integración), a menudo sucede que los
prototipos se transfieren al sistema de producción. Por lo tanto, existe el riesgo de
que se introduzcan otros errores e incoherencias conceptuales en el producto final
posterior.
En los lugares donde se toman decisiones sobre los ciclos siguientes, existe el
riesgo de que se formen bucles y el proyecto tarde más tiempo si se toman
decisiones equivocadas. Por esta razón, las alternativas y su evaluación son
importantes.
RUP
Es un proceso de ingeniería de software, que hace una propuesta orientada por
disciplinas para lograr las tareas y responsabilidades de una organización que
desarrolla software.
Su meta principal es asegurar la producción de software de alta calidad que
cumpla con las necesidades de los usuarios, con una planeación y presupuesto
predecible.
Características
Dirigido por Casos de Uso: –Los casos de uso son los artefactos primarios para
establecer el comportamiento deseado del sistema
Centrado en la Arquitectura: –La arquitectura es utilizada para conceptualizar,
construir, administrar y evolucionar el sistema en desarrollo
Iterativo e Incremental:
–Maneja una serie de entregas ejecutables
–Integra continuamente la arquitectura para producir nuevas versiones mejoradas
Conceptualmente amplio y diverso
Enfoque orientado a objetos
En evolución continua
Adaptable
Repetible
Permite mediciones:
–Estimación de costos y tiempo, nivel de avance, etc.
Las fases son:
Inicio (Inception)
Elaboración
Construcción
Transición.
Donde se puede usar:
ingeniería y administración de procesos de software.

Ventajas
Requiere conocimientos del proceso y de UML.
Progreso visible en las etapas tempranas.
El uso de iteraciones (actividades).
Facilita la reutilizacion del código teniendo en cuenta que se realizan revisiones en
las primeras iteraciones lo cual ademas permite que se aprecien oportunidades de
mejoras en el diseño.
Desventajas
Por el grado de complejidad puede no resultar muy adecuado.
RUP es generalmente mal aplicado en el estilo cascada.