Metodologías Clásicas

Cascada

También llamado Lineal secuencial, es el enfoque metodológico que ordena rigurosamente las etapas del proceso para el desarrollo de software, de tal forma que el inicio de cada etapa debe esperar a la finalización de la etapa anterior.

Es el más básico de todos los modelos y ha servido como bloque de construcción para los demás paradigmas de ciclo de vida.

Fases:

1. Ingeniería y Análisis del Sistema: Debido a que el software es siempre parte de un sistema mayor, el trabajo comienza estableciendo los requisitos de todos los elementos del sistema y luego asignando algún subconjunto de estos requisitos al software.
2. Análisis de los requisitos del software: el proceso de recopilación de los requisitos se centra e intensifica especialmente en el software. El ingeniero de software debe comprender el ámbito de la información del software así como la función, el rendimiento y las interfaces requeridas.
3. Diseño: el diseño del software se enfoca en cuatro atributos distintos del programa; la estructura de los datos, la arquitectura del software, el detalle procedimental y la caracterización de la interfaz. El proceso de diseño traduce los requisitos en una representación del software con la calidad requerida antes de que comience la codificación.
4. Codificación: el diseño debe traducirse en una forma legible para la maquina. Si el diseño se realiza de una manera detallada, la codificación puede realizarse mecánicamente.
5. Prueba: una vez que se ha generado el código comienza la prueba del programa. La prueba se centra en la lógica interna del software y en las funciones externas, realizando pruebas que aseguren que la entrada definida produce los resultados que realmente se requieren.
6. Mantenimiento: el software sufrirá cambios después de que se entrega al cliente. Los cambios ocurrirán debidos a que se haya encontrado errores, a que el software deba adaptarse a cambios del entorno externo (sistema operativo o dispositivos periféricos) o a que el cliente requiera ampliaciones funcionales o del rendimiento.

Ventajas: 

• Sencillez.
• Organización sin mezcla de fases.
• Ayuda a localizar errores en las primeras etapas del proyecto a un bajo costo.
• Ayuda a minimizar los gastos de la planificación porque permite realizarla sin problemas.
• La calidad del producto resultante es alta.

Desventajas: 

• Gran dependencia en los requerimientos iniciales.
• Difícilmente un cliente va ha establecer al principio todos los requerimientos necesarios, por lo que provoca un gran atraso en este modelo, ya que es muy restrictivo y no permite movilizarse entre fases.
• El modelo genera pocos signos visibles de progreso hasta el final. Esto puede dar la impresión de un desarrollo lento, existe la incertidumbre de los clientes si sus proyectos serán entregados a tiempo.
• Inicio de la codificación muy tarde en el ciclo de vida del proyecto.
• Es difícil incorporar nuevas cosas si se quiere actualizar.

Incremental

El modelo incremental fue propuesto por Harlan Mills en el año 1980. Surgió el enfoque incremental de desarrollo como una forma de reducir la repetición del trabajo en el proceso de desarrollo y dar oportunidad de retrasar la toma de decisiones en los requisitos hasta adquirirexperiencia con el sistema. Este modelo se conoce también bajo las siguientes denominaciones:

• Método de las comparaciones limitadas sucesivas.
• Ciencia de salir del paso.
• Método de atacar el problema por ramas.

El modelo incremental combina elementos del modelo lineal secuencial(aplicados repetidamente) con la filosofía interactiva de construcción de prototipos. Aplica secuencias lineales de forma escalonada mientras progresa el tiempo en el calendario. 

Es decir, bajo este modelo se entrega software “por partes funcionales mas pequeñas”, pero re-utilizables, llamadas incrementos. En general cada incremento se construye sobre aquel que ya fue entregado.

El proceso se divide en 4 partes:

• Análisis
• Diseño
• Código 
• Prueba

El modelo incremental aplica secuencias lineales de forma escalonada mientras procesa el tiempo en calendario. Cada secuencia lineal produce un incremento del software. el primer incremento generalmente es un producto esencial denominado núcleo.

Este modelo es particularmente útil cuando no se cuenta con una dotación de personal suficiente. Los primeros pasos los pueden realizar un grupo reducido de personas y en cada incremento se añadirá personal, de ser necesario. Por otro lado los incrementos se pueden planear para gestionar riesgos técnicos.

El modelo incremental consiste en un desarrollo inicial de la arquitectura completa del sistema, seguido de sucesivos incrementos funcionales. Cada incremento tiene su propio ciclo de vida y se basa en el anterior, sin cambiar su funcionalidad ni sus interfaces. Una vez entregado un incremento, no se realizan cambios sobre el mismo, sino únicamente corrección de errores. Dado que la arquitectura completa se desarrolla en la etapa inicial, es necesario conocer los requerimientos completos al comienzo del desarrollo.

Características:

• Se evitan proyectos largos y se entrega "algo de valor" a los usuarios con cierta frecuencia.
• El usuario se involucra mas.
• Dificil de evaluar el costo total.
• Dificil 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.
• En lugar de entrega del sistema en una sola entrega, el desarrollo y la entrega están fracturados bajo incrementos, con cada incremento que entrega parte dela funcionalidad requerida.

Ventajas:

• Los clientes no tienen que esperar hasta que el sistema se entregue completamente para comenzar a hacer uso de él.
• Los clientes pueden usar los incrementos iniciales como prototipo para precisarlos requerimientos posteriores del sistema.
• Minimización del riesgo de falla en el proyecto porque los errores se van corrigiendo progresivamente. 
• El resultado puede ser muy positivo.
• 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 realimentado, reduciendo sus desventajas sólo al ámbito de cada incremento.
• Resulta más sencillo acomodar cambios al acotar el tamaño de los incrementos.

Desventajas:

• 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.
• Difícil de aplicar a sistemas transaccionales que tienden a ser integrados y a operar como un todo.
• Riesgos largos y complejos.
•  Pueden aumentar el coste debido a las pruebas.
•  Los errores en los requisitos se detectan tarde. 

Evolutiva

Esta metodología fue propuesto por Mills en 1980.Surge porque en los primeros desarrollos se podía esperar largo tiempo hasta que el software estuviese listo.

Permiten desarrollar versiones cada vez más completas y complejas, hasta llegar al objetivo final deseado. Se asume que NO todos los requerimientos son conocidos desde el primer momento.

La metodología consiste en el desarrollo de n iteraciones:

1) Iteración

Se desarrolla la primera versión, que recoge los requisitos conocidos.

2) Iteración

Los usuarios utilizan el software desarrollado, generándose una nueva lista de requerimientos, con la que se desarrolla una nueva versión en la siguiente fase y así sucesivamente.

El usuario ve la materialización del proyecto más rápido que si hubiera que hacer un estudio largo para concretar las especificaciones. Además, puede modificar/añadir requerimientos sin afectar al proyecto y conseguir algo que se ajuste mejor a sus necesidades. 

Existen dos tipos de desarrollo evolutivo: 

1. Desarrollo Exploratorio
   El objetivo de este enfoque es explorar con el usuario los requisitos hasta llegar a un sistema final. El desarrollo comienza con las partes que se tiene más claras. El sistema evoluciona conforme se añaden nuevas características propuestas por el usuario.
2. Enfoque utilizando prototipos

        El   objetivo es entender los requisitos   del usuario y trabajar para mejorar  la calidad           de los requisitos. A diferencia del desarrollo exploratorio, se comienza por   definir los         requisitos que no están claros para el usuario y se utiliza un prototipo para experimentar       con ellos. El prototipo ayuda a terminar de definir estos requisitos.

Ventajas:

• La especificación puede desarrollarse de forma creciente.
• Es más efectivo que el modelo de cascada, ya que cumple con las necesidades inmediatas del cliente.
• Los usuarios y desarrolladores logran un mejor entendimiento del sistema. Esto se refleja en una mejora de la calidad del software.
• Hay que implicar a los usuarios.

Desventajas: 

• Es difícil predecir el coste y duración de un proyecto, por lo que es conveniente limitar el número de fases, recursos y plazos si es un proyecto con principio y fin.
• Para el rápido desarrollo se necesitan herramientas que pueden ser incompatibles con otras o que poca gente sabe utilizar.
• Hay que mantener muy bien la documentación del proyecto para facilitar el control de versiones y su mantenimiento
• Puede resultar costoso si hay que reiniciar el desarrollo.

Espiral

El creador del modelo en espiral fue Barry Boehm, ideó y promulgó un modelo desde un enfoque distinto al tradicional en Cascada. Su Modelo de Ciclo de Vida en Espiral tiene en cuenta fuertemente el riesgo que aparece a la hora de desarrollar software.

Es un modelo de proceso de software evolutivo donde se conjuga la naturaleza de construcción de prototipos con los aspectos controlados y sistemáticos del modelo lineal y secuencial. Proporciona el potencial para el desarrollo rápido de versiones incrementales del software que no se basa en fases claramente definidas y separadas para crear un sistema.

En el modelo espiral, el software se desarrolla en una serie de versiones incrementales. Durante las primeras iteraciones la versión incremental podría ser un modelo en papel o un prototipo, durante las últimas iteraciones se producen versiones cada vez más completas del sistema diseñado.

El modelo espiral tuvo varias modificaciones que son:

   1.  Modelo Original de Boehm.

Cada vuelta se divide en 4 sectores: 

• Planeación : determinación de los objetivos, alternativas y restricciones
• Análisis de riesgo : análisis de alternativas e identificación/resolución de riesgos
• Ingeniería : desarrollo del producto hasta "el siguiente nivel".
• Evaluación : valoración por parte del cliente de los resultados obtenidos  El movimiento de la espiral, ampliando con cada iteración su amplitud radial, indica que cada vez se van construyendo versiones sucesivas del software, cada vez más completas. Uno de los puntos más interesantes del modelo, es la introducción al proceso de desarrollo a las actividades de análisis de los riesgos asociados al desarrollo y a la evaluación por parte del cliente de los resultados del software.

2.     Modelo Típico de Seis Regiones.

• Comunicación con el cliente: las tareas requeridas para establecer comunicación entre el desarrollador y el cliente.
• Planificación: las tareas requeridas para definir recursos, el tiempo y otras informaciones relacionadas con el proyecto. Son todos los requerimientos.
• Análisis de riesgos: las tareas requeridas para evaluar riesgos técnicos y otras informaciones relacionadas con el proyecto.
• Ingeniería: las tareas requeridas para construir una o más representaciones de la aplicación.
• Construcción y adaptación: las tareas requeridas para construir, probar, instalar y proporcionar soporte al usuario.
• Evaluación del cliente: las tareas requeridas para obtener la reacción del cliente según la evaluación de las representaciones del software creadas durante la etapa de ingeniería e implementación durante la etapa de instalación.

3.    Modelo WINWIN.

                                               

El modelo en espiral WINWIN de Boehm, define un conjunto de actividades de negociación al principio de cada paso alrededor de la espiral. Más que una simple actividad de comunicación con el cliente se definen las siguientes actividades:

• Identificación del sistema o subsistemas clave de los directivos.
• Determinación de las condiciones de victoria de los directivos.
• Negociación de las condiciones de victoria de los directivos para reunirlas en un conjunto de condiciones para todos los afectados

Ventajas: 

• El modelo en espiral puede adaptarse y aplicarse a lo largo de la vida del software de computadora. 
• Como el software evoluciona a medida que progresa el proceso, el desarrollador y el cliente comprenden y reaccionan mejor ante riesgos en cada uno de los nivele evolutivos. 
• El modelo en espiral permite a quien lo desarrolla aplicar el enfoque de construcción de prototipos en cualquier etapa de evolución del producto. 
• El modelo en espiral demanda una consideración directa de los riesgos técnicos en todas las etapas del proyecto y si se aplica adecuadamente debe reducir los riesgos antes de que se conviertan en problemas. 
• En la utilización de grandes sistemas a doblado la productividad.

Desventajas:

• Resulta difícil convencer a grandes clientes de que el enfoque evolutivo es controlable.
• Genera mucho tiempo en el desarrollo del sistema.
• Debido a su elevada complejidad no se aconseja utilizarlo en pequeños sistemas.
• Modelo costoso.
• Requiere experiencia en la identificación de riesgos.

Prototipo

Cuando el cliente tiene una necesidad legitima, pero está desorientado sobre los detalle, el primer paso es desarrollar un prototipo.

El prototipo es una versión funcional de un sistema de información o de parte de éste, pero su propósito es el de servir de modelo preliminar.

Una vez en operación, el prototipo se refinará más aún hasta que cumpla con precisión los requerimientos de los usuarios. Una vez finalizado el diseño, el prototipo se puede convertir en un sistema en producción refinado.

La creación de prototipos consiste en construir rápida y económicamente un sistema experimental para que lo evalúen los usuarios finales.

La iteración ocurre cuando el prototipo se pone a punto para satisfacer las necesidades del cliente, permitiendo al mismo tiempo que el desarrollador comprenda mejor lo que necesita hacer.

Lo ideal seria que el prototipo sirviera como mecanismo para identificar los requisitos de software.

Etapas: 

Características:

• El prototipo funcional evolutivo desarrolla un comportamiento que satisface los requisitos y necesidades que se han entendido claramente. Realiza por tanto, un proceso real de datos, para contrastarlo con el usuario.
• Se va modificando y desarrollando sobre la marcha, según las apreciaciones del cliente. Esto ralentiza el proceso de desarrollo y disminuye la fiabilidad, puesto que el software está constantemente variando, pero, a la larga, genera un producto más seguro, en cuanto a la satisfacción de las necesidades del cliente.

Ciclo de vida:

Ventajas:

• Útil cuando los requerimientos son inciertos o cuando la interfaz del usuario final es muy importante.
• Promueve la participación del usuario.
• 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 de 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-maquina.
• Se puede reutilizar el código.
• Ayuda al desarrollo de software y al cliente a entender de mejor manera cuál será el resultado de la construcción cuando los requisitos estén satisfechos.

Desventajas: 

• Impropio para sistemas complejos y grandes.
• Puede omitir pasos en el análisis, la documentación y las pruebas.
• El usuario quiere empezar a trabajar desde el primer momento con el prototipo para
  solucionar su problema particular, cuando el prototipo es solo un modelo de lo que será el
  producto.

_________________________________________________________________________

Bibliografia: 

http://librosweb.es/libro/tdd/capitulo_1/modelo_en_cascada.html

http://www.ecured.cu/Modelo_en_cascada

https://procesosoftware.wikispaces.com/Modelo+Incremental

http://ingenieria.uatx.mx/labastida/files/2013/01/Modelo-Incremental.pdf

http://jorgetrejos.blogspot.mx/2010/08/modelo-evolutivo.html

http://arantxa.ii.uam.es/~proyectos/teoria/C5_Proyectos%20de%20desarrollo%20software.pdf

 http://sofware1nathalygrijalva.blogspot.mx/2012/10/modelo-espiral.html

http://es.geocities.com/modeloespiral/definicion.htm

http://148.202.148.5/cursos/cc321/fundamentos/unidad1/espiral.htm

https://books.google.com.mx/books?id=KD8ZZ66PF-gC&pg=PA395&dq=metodolog%C3%ADa+prototipo&hl=es&sa=X&ved=0ahUKEwiihPyq253LAhUW32MKHTQcCQEQ6AEILzAC#v=onepage&q=metodolog%C3%ADa%20prototipo&f=false

_________________________________________________________________________