Modelo Incremental

El modelo incremental aplica secuencias lineales de forma escalonada mientras progresa el tiempo en el calendario. Cada secuencia lineal produce un incremento del software.

Cuando se utiliza un modelo incremental el primer incremento es un producto esencial. Es decir se afrontan requisitos básicos pero muchas funciones suplementarias (algunas conocidas otras no). Como un resultado de utilización y/o de evaluación, se desarrolla un plan para el incremento.

El plan afronta la modificación del producto central a fin de cumplir mejor las necesidades del cliente y la entrega de funciones, y características adicionales. Este proceso se repite siguiendo la entrega de cada incremento, hasta que se elabore el producto completo.

  http://osc.co.cr/wp-content/uploads/2011/06/incremental.jpeg

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 precisar los requerimientos posteriores del sistema.

· Minimización del riesgo de falla en el proyecto porque los errores se van corrigiendo progresivamente.

Desventajas

· Adaptación de los requisitos del cliente para lograr incrementos pequeños (no mas de 20.000 líneas de código) que añadan  funcionalidad al sistema.

Ejemplo: El software de tratamiento de textos desarrollando con el paradigma incremental podría extraer funciones de gestión de archivos básicos y de producción de documentos en el primer incremento; funciones de edición más sofisticadas y de producción de documentos en el segundo incremento; corrección ortográfica y gramatical en tercero; y una función avanzada de esquema de página en el cuarto. Se deberían tener en cuenta que el flujo del proceso de cualquier incremento puede incorporar el paradigma de construcción de prototipos. 

Nota: Una evolución de este enfoque se conoce como Programación Extrema (XP-Extreme Programming).                                                                                       

                                                                                                                                            

Página principal

Modelo Espiral

El modelo espiral para la ingeniería de software ha sido desarrollado para cubrir las mejores características tanto del ciclo de vida clásico, como de la creación de prototipos, añadiendo al mismo tiempo un nuevo elemento: El análisis de riesgo.

Durante la primera vuelta alrededor de la espiral se definen los objetivos, las alternativas y las restricciones, y se analizan e identifican los riesgos. Si el análisis de riesgo indica que hay una incertidumbre en los requisitos, se puede usar la creación de prototipos en el cuadrante de ingeniería para dar asistencia tanto al encargado de desarrollo como al cliente.

El cliente evalúa el trabajo de ingeniería (cuadrante de evaluación de cliente) y sugiere modificaciones. Sobre la base de los comentarios del cliente se produce la siguiente fase de planificación y de análisis de riesgo. En cada bucle alrededor de la espiral, la culminación del análisis de riesgo resulta en una decisión de "seguir o no seguir".

Con cada iteración alrededor de la espiral (comenzando en el centro y siguiendo hacia el exterior), se construyen sucesivas versiones del software, cada vez más completa y, al final, al propio sistema operacional.

El paradigma del modelo en espiral para la ingeniería de software es actualmente el enfoque más realista para el desarrollo de software y de sistemas a gran escala. Utiliza un enfoque evolutivo para la ingeniería de software, permitiendo al desarrollador y al cliente entender y reaccionar a los riesgos en cada nivel evolutivo. Utiliza la creación de prototipos como un mecanismo de reducción de riesgo, pero, lo que es más importante permite a quien lo desarrolla aplicar el enfoque de creación de prototipos en cualquier etapa de la evolución de prototipos.

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 niveles 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.

Desventajas

· Resulta difícil convencer a grandes clientes de que el enfoque evolutivo es controlable.

· Debido a su elevada complejidad no se aconseja utilizarlo en pequeños sistemas.

. Genera mucho tiempo en el desarrollo del sistema.

 

https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjWG7hydFV8yIkCdXybK1VqWZisoCvVD1MubVCnyJOnWbPQbnakPk7TBaBsFPedlSZxOM-FFqytvivCmwNPeyN2_FsEQFEyChpVc4s3AXq73wQ_2dyTOicb8LJEWhqD7RQoMR20Ce4rkv8/s320/seis+regiones.JPG

 

Páginaprincipal

Modelo Espiral WINWIN (Victoria&Victoria)

Hace énfasis en la etapa Comunicación con el Cliente definiendo un conjunto de actividades de negociación que se llevan a cabo al principio de cada ciclo.

 

El proceso de negociación busca que ambos ganen, tanto cliente como analista:

 

• El cliente obtiene el producto que satisface gran parte de sus necesidades.
• El desarrollador intenta obtener requisitos que le permitan cumplir con tiempos de entrega realistas.

Además del énfasis realizado en la negociación inicial, el modelo en espiral WINWIN introduce tres hitos en el proceso, llamados puntos de fijación (BOE96), que ayuda a establecer la completitud de un ciclo alrededor de la espiral y proporcionan hitos de decisión antes de continuar el proyecto de software.

El primer punto de fijación, llamado objetivos del ciclo de vida (OCV), define un conjunto de objetivos para cada actividad principal de la ingeniería de software.

Ejemplo:

Un conjunto de objetivos asociados a la definición de los requisitos del producto/ sistema del nivel mas alto.

El segundo punto de fijación, llamado arquitectura del ciclo de vida (ACV), establece los objetivos que se deben conocer mientras que se define la arquitectura del software y el sistema

Ejemplo:

El equipo del proyecto de software debe demostrar que ha evaluado la funcionalidad de los componentes del software utilizables y que ha considerado su impacto en las decisiones de arquitectura.

El tercer punto de fijación es la capacidad operativa inicial (COI) y representa un conjunto de objetivos asociados a la preparación del software para la instalación/distribución, preparación del lugar previamente a la instalación, y la asistencia precisada de todas las partes que utilizará o mantendrá el software.

https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhrIHwd7CYk8-VuWhwGpLDuEqtdKrXQWzz5jPVolbPabj2b910GVAJ255JAriwgvKbF4wNPhton9c3Bw1abB8IcQQS7ZucrIua6qJeldl_3s30DjIrtybVsgvIeqx1mEC3zbXSx_rwzP2I/s400/winwin.JPG

 

Página principal

Modelo Concurrente

El modelo de proceso concurrente se puede sentar en forma de esquema como una serie de actividades técnicas importantes, tareas y estados asociados a ellas. Por ejemplo, la actividad de ingeniería definida para el modelo en espiral, se lleva acabo invocando las tareas siguientes: modelado de construcción de prototipos y/o análisis, especificación de requisitos y diseño. 

El modelo de proceso unificado  

Proporciona una representación esquemática de una actividad dentro del modelo de proceso concurrente. La actividad, análisis se puede encontrar en uno de los estados destacados en cualquier momento dado. De forma similar, otras actividades (por ejemplo el diseño o comunicación con el cliente) se pueden representar de una forma analógica. 

Todas las actividades existen concurrentemente, pero residen en estados diferentes, por ejemplo, al principio del proyecto la actividad de comunicación con el cliente ha finalizado su primera interacción y está en el estado de cambios en espera. La actividad de análisis (que está en el estado ninguno mientras que se iniciaba la comunicación inicial con el cliente) ahora hace una transacción al estado bajo desarrollo. Sin embargo, si el cliente indica que se deben hacer cambios en requisitos, la actividad análisis cambia del estado bajo desarrollo al estado cambios en espera.  

El modelo de proceso concurrente define una serie de acontecimientos que dispararan transiciones de estado a estado para cada una de las actividades de la ingeniería del software. Por ejemplo, durante las primeras etapas del diseño, no se contempla una inconsistencia del modelo de análisis. Esto genera la corrección del modelo de análisis de sucesos, que dispara la actividad de análisis del estado hecho al estado cambios en espera. 

El modelo de proceso concurrente se utiliza a menudo como el paradigma de desarrollo de aplicaciones cliente/servidor. Un sistema cliente/servidor se compone de un conjunto de componentes funcionales. Cuando se aplica a cliente/servidor, el modelo de proceso concurrente define actividades en dos dimensiones: una dimensión de sistemas y una dimensión de componentes. Los aspectos del nivel de sistemas se afrontan mediante tres actividades: diseño, ensamblaje y uso.  

Las dimensiones de componentes se afrontan con dos actividades: diseño y realización. La concurrencia se logra de dos formas 

Las actividades de sistemas y de componentes ocurren simultáneamente y pueden modelarse con el enfoque orientado a objetos. Una aplicación cliente/servidor típica se implementa con muchos componentes, cada uno de los cuales se pueden diseñar y realizar concurrentemente. En realidad, el modelo del proceso concurrente es aplicable a todo tipo de desarrollo de software y proporciona una imagen exacta del estado actual de un proyecto.

 

http://i53.tinypic.com/15mfssi.jpg

Página principal