Modelos de Roger S.

Pressman
Los modelos prescriptivos de proceso se propusieron originalmente para ordenar el caos de desarrollo de software. La historia ha indicado que estos modelos convencionales han trado consigo cierta cantidad de estructuras tiles para el trabajo en la ingeniera del software, y han proporcionado un camino a seguir razonablemente efectivo para los equipos de software. Sin embargo, el trabajo de la ingeniera del software y el producto resultante an permanecen al borde del caos. Los modelos prescriptivos de proceso definen un conjunto distinto de actividades, acciones, tareas, fundamentos y productos de trabajo que se requieren para desarrollar software de alta calidad. Estos modelos de proceso no son perfectos, pero proporcionan una gua til para el trabajo de la ingeniera de software. Estos modelos proporcionan estabilidad, control y organizacin a una actividad que si no se controla puede volverse catica. Sin importar el modelo de proceso seleccionado, los ingenieros de software han elegido de manera tradicional un marco de trabajo genrico para el proceso, el cual incluye las siguientes actividades dentro del marco: Comunicacin, Planeacion, Modelado, Construccion y desarrollo. Todos los modelos de proceso del software se ajustan a las actividades genricas del marco de trabajo ya descritas, pero cada uno aplica una importancia diferente a estas actividades y definen un flujo de trabajo que invoca cada actividad del marco de trabajo (asi como acciones y tareas de la ingeniera del software) de una manera diferente.
El proceso es el conocimiento incorporado, y puesto que el conocimiento esta inicialmente disperso, el desarrollo de software implcito, latente e incompleto en gran medida es un proceso social de aprendizaje. El proceso es un dialogo en el que se rene el conocimiento y se incluye en el software para convertirse en software. El proceso proporciona una iteracin entre los usuarios y los diseadores, entre los usuarios y las herramientas de desarrollo, y entre los diseadores y las herramientas de desarrollo (tecnologa). Es un proceso interactivo donde la herramienta de desarrollo se usa como medio de comunicacin, con cada iteracin del dialogo se obtiene mayor conocimiento. Howard Baetjer

EL MODELO EN CASCADA Tambin llamado el ciclo de vida clsico, sugiere un enfoque sistemtico, secuencial hacia el desarrollo del software. El modelo en Cascada establece que el software debe ser construido, rigurosamente, a travs de una transformacin sucesiva de documentos, siguiendo una estrategia lineal de desarrollo. Primero saber qu se quiere y despus, cuando se conozca todo lo que se quiere, empezar a construirlo. El modelo de cascada tambin conocido como modelo lineal secuencial sugiere un enfoque sistemtico, secuencial para el desarrollo del software que comienza en un nivel de sistemas y progresa con el anlisis, diseo, codificacin, pruebas y mantenimiento. Est basado en el ciclo convencional de una ingeniera, tiene las siguientes actividades que se muestran:
Comunicacin inicio del proyecto recopilacin de requisitos

Planeacion Estimacin Itinerario seguimiento Modelado Anlisis diseo

Construccin cdigo prueba

Figura Modelo de Cascada

Despliegue Entrega Soporte retroalimentacin

Desventajas Los proyectos reales raramente siguen el flujo secuencial que propone el modelo, siempre hay iteraciones y se crean problemas en la aplicacin del paradigma. Normalmente, es difcil para el cliente establecer explcitamente al principio todos los requisitos. El ciclo de vida clsico lo requiere y tiene dificultades en acomodar posibles incertidumbres que pueden existir al comienzo de muchos productos.

 El cliente debe tener paciencia. Hasta llegar a las etapas finales del proyecto, no estar disponible una versin operativa del programa. Un error importante no detectado hasta que el programa este funcionando puede ser desastroso. Se tiene un Alto riesgo en sistemas nuevos debido a problemas en las especificaciones y en el diseo. Bajo riesgo para desarrollos bien comprendidos utilizando tecnologa conocida. Este modelo, que se lleva a cabo de forma descendente, exige que para pasar a la siguiente fase hay que concluir correctamente la anterior, de manera que los posibles errores sean fcilmente detectables. As, la salida de una fase es la entrada de la siguiente. La Ventaja de este mtodo radica en su sencillez ya que sigue los pasos intuitivos necesarios a la hora de desarrollar el software. MODELO INCREMENTAL El modelo incremental aplica secuencias lineales de forma escalonada mientras avanza el tiempo. Corrige la necesidad de una secuencia no lineal de pasos de desarrollo. Cada secuencia lineal produce un incremento del software. Por ejemplo, el software de tratamiento de textos desarrollado con el paradigma incremental podra extraer funciones de gestin de archivos bsicos y de produccin de documentos en el primer incremento; funciones de edicin mas sofisticadas y de produccin de documentos en el segundo incremento; correccin ortogrfica y gramatical en el tercero; y una funcin avanzada de esquema de pagina en el cuarto. Se debera tener en cuenta que el flujo del proceso de cualquier incremento pude incorporar el paradigma de construccin de prototipos.

El modelo incremental entrega el software en partes pequeas, pero utilizables, llamadas incrementos. En general, cada incremento se construye sobre aqu el que ya ha sido entregado. Cuando se utiliza un modelo incremental, el primer incremento a menudo es un producto esencial. Es decir, se afrontan requisitos bsicos, pero muchas funciones suplementarias (algunas conocidas, otras no) quedan sin extraer. El cliente utiliza el producto central (o sufre la revisin detalla). Como un resultado de utilizacin y/o de evaluacin, se desarrolla un plan para el incremento siguiente. El plan afronta la modificacin del producto central a fin de cumplir mejor las necesidades del cliente y la entrega de funciones, y caractersticas adicionales. Este proceso se repite siguiendo la entrega de cada incremento. Hasta que se elabore el producto completo.

El modelo de proceso incremental, como la construccin de prototipos y otros enfoques evolutivos, es iterativo por naturaleza. Pero a diferencia de la construccin de prototipos, el modelo incremental se centra en la entrega de un producto operacional con cada incremento. Los primero incrementos son versiones incompletas del producto final, pero proporcionan al usuario la funcionalidad que precisa y tambin una plataforma para la evaluacin. El desarrollo incremental es particularmente til cuando el personal no esta disponible para una implementacin completa en la fecha lmite que se haya establecido para el proyecto. Los primeros incrementos se pueden implementar con menos personas. Este modelo constituyo un avance sobre el modelo en cascada pero tambin presenta problemas. Aunque permite el cambio continuo de requisitos, aun existe el problema de determinar si los requisitos propuestos son validos. Los errores en los requisitos se presentan tarde y su correccin resulta tan costosa como en el modelo en cascada. Incremento 2
Comunicacin inicio del proyecto recopilacin de requisitos

Incremento n
Planeacion Estimacin Itinerario seguimiento

Incremento 1
Comunicacin inicio del proyecto recopilacin de requisitos

Despliegue Entrega Soporte retroalimentacin Despliegue Entrega Soporte retroalimentacin

Modelado Anlisis diseo

Planeacion Estimacin Itinerario seguimiento

Construccin cdigo prueba

Modelado Anlisis diseo

Construccin cdigo prueba

Figura Modelo Incremental

Desventajas Los primero incrementos son versiones Incompletas del producto final, pero proporcionan al usuario la funcionalidad que necesita y una plataforma para evaluarlo. Con el pasar de los incrementos se solicitara ms personal para implementar el incremento siguiente. Tambin existe que los primeros incrementos se puede implementar con menos gente, adems que el primer incremento es un producto esencial. Es decir, se incorporan los requisitos bsicos.

MODELO DE PROTOTIPOS El Modelo de prototipos, en Ingeniera de software, pertenece a los modelos de desarrollo evolutivo. El prototipo debe ser construido en poco tiempo, usando los programas adecuados y no se debe utilizar muchos recursos. Los modelos evolutivos son iterativos; los caracteriza la forma en que permiten que los ingenieros de software desarrollen versiones cada vez ms completas del software. El diseo rpido se centra en una representacin de aquellos aspectos del software que sern visibles para el cliente o el usuario final. Este diseo conduce a la construccin de un prototipo, el cual es evaluado por el cliente para una retroalimentacin; gracias a sta se refinan los requisitos del software que se desarrollar. La interaccin ocurre cuando el prototipo se ajusta para satisfacer las necesidades del cliente. Esto permite que al mismo tiempo el desarrollador entienda mejor lo que se debe hacer y el cliente vea resultados a corto plazo. A menudo un cliente define un conjunto de objetivos generales para el software, pero no identifica los requisitos detallados de entrada, procesamiento o salida. 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 debera tomar la interaccin humana mquina, entonces en este caso cuando utilizamos la construccin de prototipos. A menudo un cliente define un conjunto de objetivos generales para el software, pero no identifica los requisitos detallados de entrada, procesamiento o salida. 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 debera

tomar la interaccin humana mquina, entonces en este caso cuando utilizamos la construccin de prototipos.

VENTAJAS: No modifica el flujo del ciclo de vida. Reduce el riesgo de construir productos que no satisfagan las necesidades de los usuarios. Reduce costos y aumenta la probabilidad de xito. Exige disponer de las herramientas adecuadas. No presenta calidad ni robustez. Una vez identificados todos los requisitos mediante el prototipo, se construye el producto de ingeniera.

DESVENTAJAS A los usuarios les gusta el sistema real y a los desarrolladores les gusta construir algo de inmediato. Sin embargo, la construccin de prototipos se torna problemtica por las siguientes razones: El cliente ve funcionando lo que para l es la primera versin del prototipo que ha sido construido con chicle y cable para embalaje, y puede decepcionarse al indicarle que el sistema an no ha sido construido.

El desarrollador puede caer en la tentacin de aumentar el prototipo para construir el sistema final sin tener en cuenta los obligaciones de calidad y de mantenimiento que tiene con el cliente.

MODELO EN ESPIRAL El modelo espiral propuesto originalmente por Boehm en 1988, es un modelo de proceso de software evolutivo ha sido desarrollado para cubrir las mejores caractersticas tanto del ciclo de vida clsico, como de la creacin de prototipos, aadiendo al mismo tiempo un nuevo elemento: el anlisis de riesgo. Proporciona el potencial para el desarrollo rpido de versiones incrementales del software. En este modelo el software se desarrolla en una serie de versiones incrementales. Durante las primeras iteraciones, la versin incremental podra ser un modelo en papel o un prototipo. En las ltimas iteraciones, se producen versiones cada vez mas completas del sistema diseado. El modelo representado mediante la espiral de la figura 4.2 define cuatro actividades principales, tambin llamadas regiones de tareas o sectores: 1. Planificacin. Durante la primera vuelta alrededor de la espiral se definen los objetivos, las alternativas y las restricciones, se analizan e identifican los riesgos. Si el anlisis de riesgo indica que hay una incertidumbre en los requisitos, se puede usar la creacin de prototipos en el cuadrante de ingeniera para dar asistencia tanto al encargado de desarrollo como al cliente.[1] 2. Anlisis de riesgo. El proyecto se revisa y se toma la decisin de si se debe continuar con un ciclo posterior de la espiral. Si se decide continuar, se desarrollan los planes para la siguiente fase del proyecto. [1] 3. Ingeniera. En este sector se desarrolla y se valida. Despus de la evaluacin de riesgos, se elige un modelo para el desarrollo del sistema.[1] 4. Evaluacin del cliente. El cliente evala el trabajo de ingeniera (cuadrante de evaluacin de cliente) y sugiere modificaciones. Sobre la base de los comentarios del cliente se produce la siguiente fase de planificacin y de anlisis de riesgo. En cada bucle alrededor de la espiral, la culminacin del anlisis de riesgo resulta en una decisin de "seguir o no seguir".[1]

Con cada iteracin alrededor de la espiral (comenzando en el centro y siguiendo hacia el exterior), se construyen sucesivas versiones del software, cada vez ms completas y, al final, el propio sistema operacional. El paradigma del modelo en espiral para la Ingeniera de Software es actualmente el enfoque ms realista para el desarrollo de software y de sistemas a gran escala. Utiliza un enfoque evolutivo, permitiendo al desarrollador y al cliente entender y reaccionar a los riesgos en cada nivel. Utiliza la creacin de prototipos como un mecanismo de reduccin de riesgo, pero, lo que es ms importante permite a quien lo desarrolla aplicar el enfoque de creacin de prototipos en cualquier etapa de la evolucin de prototipos.

Planificacin
Anlisis de riesgo Anlisis de riesgo Anlisis de riesgo Prototipo 3 Revisin AR Prototipo 2 Prototipo 1
Plan de requisitos, Plan de ciclo de vida Plan de desarrollo Concepto de operacin Requisitos

Anlisis de Riesgos

Prototipo Operativo

Simulaciones, Modelos, Estndares

de Software Validacin de requisitos Diseo del producto de Diseo detallado software Codificacin Verificacin y validacin de diseo Prueba de Unidad Prueba de Integracin Prueba de aceptacin

Plan de prueba e Integracin

Evaluacin del Cliente

Implementacin

Ingeniera

Figura 4.2 Modelo de Espiral de Boehm

Sommerville, Ian (2005), Ingeniera de software, Ed. Addison Wesley 7 ed