Un modelo de desarrollo es una representacin abstracta de un proceso de software, cada modelo representa el proceso de desarrollo de software de una manera

en particular. A pesar de estar definidos claramente, no representan necesariamente la realidad de cmo se debe desarrollar el software, sino que establece un enfoque comn.

Un modelo puede ser modificado y adaptado de acuerdo a las necesidades del software en desarrollo.

En forma general podemos clasificar los modelos de desarrollo en 3 grupos: 1. El modelo en cascada. Considera las actividades fundamentales del proceso de especificacin, desarrollo, validacin y evolucin, y los representa como fases separadas del proceso. 2. Desarrollo evolutivo. Este enfoque entrelaza las actividades de especificacin, desarrollo y validacin. Un sistema inicial se desarrolla rpidamente a partir de especificaciones abstractas y se refina basndose en las peticiones del cliente para producir un sistema que satisfaga sus necesidades. 3. Ingeniera del software basada en componentes. Este enfoque se basa en la existencia de un nmero significativo de componentes reutilizables. El proceso de desarrollo del sistema se enfoca en integrar estos componentes en el sistema ms que en desarrollarlos desde cero.

Los modelos evolutivos son iterativos, se caracteriza por la forma en que permiten a los ingenieros en software desarrollar versiones cada vez ms completas del software. Los modelos que se clasifican en las siguientes categoras.
Construccin de prototipos Modelos en espiral Modelo de desarrollo concurrente En los modelos evolutivos se produce un sistema inicial que evoluciona segn las necesidades del cliente hasta cumplir con los requisitos de este, para luego producir un sistema que satisfaga sus necesidades. Este enfoque enlaza las actividades de especificacin, desarrollo y validacin.

En Ingeniera de software la construccin de prototipos pertenece a los modelos de desarrollo evolutivo, El prototipo debe ser construido en poco tiempo, usando los programas adecuados y no se debe utilizar mucho dinero pues a partir de que este sea aprobado es que el desarrollador puede iniciar el verdadero desarrollo del software.

La construccin de prototipos se puede utilizar como un modelo del proceso independiente. El paradigma de construccin de prototipos ayuda al desarrollador de software y al cliente a entender de mejor manera cul ser el resultado de la construccin cuando los requisitos estn satisfechos.

Plan rpido
Modelado, diseo rpido Construccin del prototipo Desarrollo, entrega y retroalimentacin.

ETAPAS

Comunicacin.

 El cliente conoce los objetivos generales para el software, pero no identifica los requisitos detallados de entrada, procesamiento o salida 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. 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 Una vez identificados todos los requisitos mediante el prototipo, se construye el producto de ingeniera.

 El usuario tiende a crearse unas expectativas cuando ve el prototipo de cara al sistema final. A causa de la intencin de crear un prototipo de forma rpida, se suelen desatender aspectos importantes, tales como la calidad y el mantenimiento a largo plazo, lo que obliga en la mayor parte de los casos a reconstruirlo una vez que el prototipo ha cumplido su funcin. El desarrollador suele tomar algunas decisiones de implementacin poco convenientes. Con el paso del tiempo, el desarrollador puede olvidarse de la razn que le llev a tomar tales decisiones, con lo que se corre el riesgo de que dichas elecciones pasen a formar parte del sistema final.

El modelo en espiral se divide en un nmero de actividades estructurales, tambin llamadas regiones de tareas el ciclo de vida del modelo en espiral se divide cuatro sectores: Definicin de objetivos. En esta fase se identifica las restricciones del proceso y le producto, y dependiendo los riesgos para trazar objetivos y respectivamente panes estratgicos. Evaluacin y reduccin de riesgos. Se hace un anlisis detallado para casa riesgo y se establece los pasos para reducirlos. Desarrollo y validacin. Despus de evaluar los riesgos, se elige un modelo para el desarrollo del sistema.

Planificacin. El proyecto se revisa y se toma la decisin de si debe continuar con un ciclo posterior de la espiral.

Las caractersticas que se pueden indicar del modelo en espiral son:

El software se desarrolla en una serie de versiones incremntales. Durante las primeras iteraciones.
La versin incremental podra ser un modelo en papel o un prototipo. A medida que se va incrementando el nmero de iteraciones, se producen versiones cada vez ms completas.

 Puede adaptarse y aplicarse a lo largo de la vida del software. 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 niveles evolutivos. Permite a quien lo desarrolla aplicar el enfoque de construccin de prototipos en cualquier etapa de evolucin del producto. Demanda una consideracin directa de los riesgos tcnicos en todas las etapas del proyecto. Reduce los riesgos antes de que se conviertan en problemticos.

 Puede resultar difcil convencer los grandes clientes de que el enfoque evolutivo es controlable Si un riesgo importante no es descubierto y gestionado, indudablemente surgirn problemas. Como es un modelo relativamente nuevo no es muy utilizado. Otros inconvenientes que pueden surgir es convencer al cliente que es un enfoque controlable, por lo que se requiere de experiencia en la identificacin de riesgos y refinamiento para su uso generalizado.

Davis Sitaram describe el modelo de desarrollo concurrente de la siguiente forma: El modelo concurrente se define una serie de acontecimientos que dispararan transiciones de estado a estado para cada una de las actividades de la ingeniera del software proporcionando una visin certera del estado actual del proyecto. Se puede representar en forma de esquema como una serie de actividades tcnicas importantes, tareas y estados asociados a ellas.

Los sucesos generados dentro de una actividad dada o algn otro lado de la red de actividad inicia las transiciones entre los estado de una actividad.

Los aspectos del nivel de sistemas se afrontan mediante dos actividades: diseo y realizacin.

La concurrencia se logra de dos formas:

Las actividades del sistema y de componente ocurren simultneamente y pueden modelarse con el enfoque orientado a objetos descrito anteriormente.

Una aplicacin cliente/servidor tpica se implementa con muchos componentes, cada uno de los cuales se pueden disear y realizar concurrentemente.

Ventajas

Excelente para proyectos en los que se conforman grupos de trabajo independientes. Proporciona una imagen exacta del estado actual de un proyecto.

Desventajas

Si no se dan las condiciones sealadas no es aplicable. Si no existen grupos de trabajo no se puede trabajar en este mtodo