Actividad Modelos de desarrollo de software

Objetivo: Identificar las principales características y similitudes entre los modelos de desarrollo de software vistos durante la unidad.

1. Análisis individual los diferentes métodos de desarrollo de software vistos en la presente unidad y sus características principales.

Modelo Etapas Ventajas Desventajas

Modelo en cascada

Es el modelo más antiguo de desarrollo de software y base para la generación de otros modelos.

Propone la construcción de software a través de una secuencia simple de fases. Cada fase contiene una serie de actividades para lograr un objetivo, y cada una depende de la meta lograda en la anterior por eso se representa con una flecha hacia abajo. Las flechas de regreso representan

retroalimentación ° Análisis: Analista y cliente definen todos los requerimientos del sistema (especificación detallada).

° Diseño: A partir del análisis se diseñan las estructuras de datos, bases de datos, interfaces y procedimientos.

° Codificación: El diseño se traduce a código para la generación del software.

° Pruebas: Se hace la revisión del código para comprobar que no tenga errores.

° Mantenimiento: se realiza después de la entrega del software, asegura que el sistema siga funcionando y da seguimiento a las mejoras que el cliente solicite. ° Es más sencillo planear las actividades del ciclo completo.

° La calidad del producto es alta.

° Permite trabajar con personal inexperto.

° Es el modelo más conocido.

° Es fácil de aprender.

° En la no siempre sigue el orden propuesto, los cambios pueden causar confusión al equipo del proyecto por la poca interacción.

° Es difícil que el cliente exponga todos los requerimientos y aquí se requieren definidos desde el comienzo.

° se requiere paciencia, ya que el cliente verá alguna versión del trabajo hasta avanzado el proyecto, cualquier error será cada vez más difícil y costoso corregirlo.

° Este modelo genera estados de “bloqueo”, cuando una etapa sufre algún retraso, algunos miembros del equipo deberán esperar a otros para completar su actividad.

Modelo de construcción de prototipos

fue creado como herramienta para identificar requerimientos del software.

Facil saber los requerimientos del cliente y le ayuda a detallar las necesidades que tiene en la

construcción del software.

Existen varias formas, algunas de ellas son:

1. Un borrador de historia, se plantea a manera historieta las funcionalidades del sistema, por ejemplo una interfaz con las opciones del menú, el área de despliegue de resultados, si se requiere la imagen corporativa. Apoyándose de la descripción de la historia podemos exponer la interactividad del sistema con los usuarios. En la construcción puede ser utilizando un block de notas de papel o recursos software que faciliten el desarrollo de interacción hombre-máquina y permitan simular el proceso que se solicita. Asi el cliente se da idea de cómo va a funcionar sin tener que construirlo, y se discute con el analista.

2. Un modelo que implementa alguna función importante del sistema. Es decir; construir una aplicación rápida sin aspectos de diseño ni la base de datos completa, lo mínimo para simular un proceso interno del sistema o la validación de alguna fórmula. De esta manera se obtiene el entendimiento del

requerimiento por parte del equipo de desarrollo.

Los prototipos pueden servir como documentación de apoyo y especificar requerimientos, pero no se recomienda como primera versión del sistema, pues seguramente se han construido de una manera rápida y con pocos detalles. 1. Recolección de requisitos: Analista y cliente definen la especificación de requerimientos.

2. Diseño rápido:

Se hace el diseño del prototipo.

3. Construcción del prototipo en cualquiera de las herramientas seleccionadas.

4. Evaluación del prototipo:

Cliente y usuario revisan el prototipo, generan observaciones.

5. Refinamiento del prototipo: Las observaciones cliente - usuarios sirven para mejorar el prototipo que nuevamente es construido y regresa al paso 2.

6. El ciclo concluye cuando cliente -usuario carecen de observaciones y el prototipo es claro para analista y equipo de desarrollo.

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

° El cliente puede confundir las primeras versiones del prototipo con el producto final.

° El cliente puede desilusionarse al saber que los prototipos no son el producto y que este aún no se ha construido.

° Se requiere compromiso y trabajo del cliente para estar revisando los prototipos.

° No se sabe exactamente cuánto será el tiempo de desarrollo, ni cuantos prototipos se desarrollaran.

° Si un prototipo falla, el costo del proyecto puede resultar muy caro.

° El desarrollador puede caer en la tentación de utilizar un prototipo, por ejemplo la interfaz gráfica de un módulo y continuarlo para construir el sistema sin tomar en cuenta calidad necesaria para el proyecto.

Modelo incremental

Combina elementos del modelo cascada (aplicados repetidamente)

con la filosofía interactiva de construcción de prototipos.

Cada secuencia cascada

produce un incremento.

Al utilizar este modelo, el primer incremento a menudo es un producto esencial (núcleo). Es decir, se afrontan requisitos básicos, para muchas funciones suplementarias (algunas conocidas, otras no) que quedan sin extraer.

El cliente utiliza el producto central (o sufre la revisión detallada). Como resultado de utilización y/o de evaluación, se desarrolla un plan para el incremento siguiente. 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.

El proceso se repite siguiendo la entrega de cada incremento, hasta que se elabore el productivo completo.

° Construir un sistema pequeño es menos riesgoso que construir un sistema grande.

° Si un error es detectado, sólo la última iteración necesita ser descartada.

° Al desarrollar parte de las funcionalidades, es más fácil determinar si los

requerimientos planeados para los niveles subsiguientes son correctos ° Se puede suponer que los requerimientos han sido definidos desde el inicio del proyecto.

° Se necesita experiencia para definir los incrementos de forma de distribuir las tareas de manera proporcional.

° Se corre el riesgo de que el desarrollo se prolongue demasiado en cuestiones de tiempo

Modelo vida espiral

Es un modelo evolutivo que acompaña la naturaleza interactiva de construcción de prototipos con los aspectos controlados y sistemáticos del modelo cascada.

Se proporciona el potencial para el desarrollo rápido de versiones incrementales del software. Durante 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 de ingeniería del sistema.

Se incorpora un elemento nuevo en el proceso de desarrollo de software como lo es el “análisis de riesgos” y define entre 3 y 6 regiones de tareas.

1. Comunicación con el cliente.- Cliente y analista establecen las políticas de

Comunicación.

2. Planificación.- Determinan tiempos, objetivos, restricciones, etc. del proyecto.

3. Análisis de riesgos.- Identificación y gestión del riesgo.

4. Ingeniería.- Desarrollo y verificación del producto del siguiente nivel.

5. Construcción y adaptación.-Actividades para desarrollar, realizar pruebas,

Instalación y mantenimiento al software.

6. Evaluación del cliente.- Validación del cliente hasta su aprobación y liberación

° No se requiere tener todos los requerimientos definidos desde el inicio del proyecto.

° Es evolutivo, lo cual permite al cliente ir definiendo mejor sus requerimientos y también junto con el equipo ir gestionando los riesgos.

° Se pueden construir prototipos para disminuir el riesgo del proyecto, cuando no se cuenta con requerimientos claros.

° Representa de mejor manera un proceso de desarrollo real, con respecto al modelo cascada.

° Los requerimientos se van validando con cada iteración.

° Genera la apariencia de ser interminable.

° Es muy complejo.

° Se requiere trabajo y participación del cliente de manera continúa.

° El modelo es relativamente nuevo por lo que no se cuenta con los casos suficientes para demostrar su

...