Actividad 2 Unidad 1

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

...