Modelos De Desarrollo De SW

Modelo Incremental

El Modelo Incremental combina elementos del MLS con la filosofía interactiva de construcción de prototipos.

En una visión genérica, el proceso se divide en 4 partes: Análisis, Diseño, Código y Prueba. Sin embargo, para la producción del Software, se usa el principio de trabajo en cadena o “Pipeline”, utilizado en muchas otras formas de programación. Con esto se mantiene al cliente en constante contacto con los resultados obtenidos en cada incremento.

Es el mismo cliente el que incluye o desecha elementos al final de cada incremento a fin de que el software se adapte mejor a sus necesidades reales. El proceso se repite hasta que se elabore el producto completo.

De esta forma el tiempo de entrega se reduce considerablemente.

Al igual que los otros métodos de modelado, el Modelo Incremental es de naturaleza interactiva pero se diferencia de aquellos en que al final de cada incremento se entrega un producto completamente operacional.

El Modelo Incremental 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 se puede ver aquí en forma grafica:

- Se evitan proyectos largos y se entrega algo de valor a los usuarios con cierta frecuencia.

- El usuario se involucra más.

- Difícil de evaluar el coste total.

- Difícil 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 muy positivo.

Pipeline

La arquitectura en pipeline (basada en filtros) consiste en ir transformando un flujo de datos en un proceso comprendido por varias fases secuenciales, siendo la entrada de cada una la salida de la anterior.

Esta arquitectura es muy común en el desarrollo de programas para el intérprete de comandos, ya que se pueden concatenar comandos fácilmente con tuberías (pipe).

También es una arquitectura muy natural en el paradigma de programación funcional, ya que equivale a la composición de funciones matemáticas.

Interprete de comandos

Parte fundamental de un sistema operativo que ordena la ejecución de mandatos obtenidos del usuario por medio de una interfaz alfanumérica.

Características

- Se evitan proyectos largos y se entrega “algo de valor” a los usuarios con cierta frecuencia.

- El usuario se involucre más.

- Difícil de evaluar el costo total.

- Difícil 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 muy positivo.

Ventajas:

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

- Permite entregar al cliente un producto más rápido en comparación del modelo de cascada.

- Resulta más sencillo acomodar cambios al acotar el tamaño de los incrementos.

- Por su versatilidad requiere de una planeación cuidadosa tanto a nivel administrativo como técnico.

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.

Modelo de Espiral

El modelo en espiral es un tipo de modelo basado en el desarrollo iterativo. Se diferencia del modelo iterativo incremental en que más que representarlo como una secuencia de actividades se representa como una espiral donde cada ciclo en la espiral representa una fase del proceso del software. Así, por ejemplo, el ciclo más interno podría referirse a la especificación de requerimientos y el siguiente ciclo al diseño.

Cada ciclo de la espiral se divide en cuatro sectores:

1. Determinar los objetivos: En esta fase del proyecto se definen los objetivos específicos. Se identifican las restricciones del proceso y del sistema software, y se traza un plan detallado de gestión. Se identifican los riesgos. Dependiendo de estos riesgos se planean estrategias alternativas.

2. Análisis del riesgo: Se lleva a cabo un análisis detallado para cada uno de los riesgos del proyecto identificados. Se definen los pasos a seguir para reducir los riesgos.

3. Desarrollar y validar: Después de la evaluación de riesgos, se elige un modelo para el desarrollo del sistema software y se desarrolla.

4. Planificación: El proyecto se revisa y se toma la decisión 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.

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, el propio sistema software totalmente funcional.

La diferencia principal entre este modelo y los vistos hasta ahora es la evaluación del riesgo. El riesgo es todo aquello que pueda ir mal. Por ejemplo, si la intención es utilizar un lenguaje de programación, un riesgo posible es que los compiladores disponibles no produzcan código objeto eficiente. Los riesgos originan problemas en el proyecto como por ejemplo, el exceso de costes. Por lo tanto, la disminución de los riesgos es una actividad muy importante.

Un ciclo de espiral comienza con la elaboración de los objetivos tanto funcionales como de rendimiento. Después se enumeran algunas formas posibles de alcanzar estos objetivos identificando las fuentes de riesgos posibles. El siguiente paso es resolver estos riesgos y llevar a cabo las actividades de desarrollo. Finalmente se planifica el siguiente ciclo de la espiral.

Modelo de Construcción de Prototipos

En Ingeniería de software El Modelo de prototipos que 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 nosotros podemos iniciar el verdadero desarrollo del software.

El diseño rápido se centra en una representación de aquellos aspectos del software que serán visibles para el cliente o el usuario final. Este diseño conduce a la construcción de un prototipo, el cual es evaluado por el cliente para una retroalimentación; gracias a ésta se refinan los requisitos del software que se desarrollará. La interacción 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.

ETAPAS

 Plan rápido

 Modelado, diseño rápido

 Construcción del Prototipo

 Desarrollo, entrega y retroalimentación

 Comunicación

VENTAJAS

 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 del 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-máquina.

La construcción de prototipos se puede utilizar como un modelo del proceso independiente, se emplea más comúnmente como una técnica susceptible de implementarse dentro del contexto de cualquiera de los modelos del proceso expuestos. Sin importar la forma en que éste se aplique, el paradigma de construcción de prototipos ayuda al desarrollador 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. De esta manera, este ciclo de vida en particular, involucra al cliente más profundamente para adquirir el producto.

Desventajas

 El usuario tiende a crearse unas expectativas cuando ve el prototipo de cara al sistema final. A causa de la intención de crear un prototipo de forma rápida, 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 función. Es frecuente que el usuario se muestre reacio a ello y pida que sobre ese prototipo se construya el sistema final, lo que lo convertiría en un prototipo evolutivo, pero partiendo de un estado poco recomendado.

 En aras de desarrollar rápidamente el prototipo, el desarrollador suele tomar algunas decisiones de implementación poco convenientes (por ejemplo, elegir un lenguaje de programación incorrecto porque

...