Modelos de Desarrollo de Software

Ing. Marco Antonio Cuevas Gómez Materia: Fundamentos de Ingeniería de

Software Ing. Marlene Mijangos

Instituto Superior de La Venta

Introducción

En la Ingeniería del Software, el desarrollo del mismo contempla el uso de modelos, métodos, paradigmas o filosofías que se usan para la creación de del software, cada uno con sus ventajas y desventajas, cabe destacar que ninguno de ellos se considera “perfecto” en estructura, algunos de ellos solo sirven para pequeños proyectos, y otros son complejos y extensos que abarcan hasta los detalles mas mínimos que contemplan al software.

Modelo construye y compone

Uno de los primeros métodos existentes en el modelado de software, básicamente se desarrolla sin especificar requerimientos y sin diseño, para luego hacer tantos programas como sea posible hasta satisfacer al cliente, este método sirve para programas pequeños y desechables, ya que no contempla los costos y tiempo en que se puedan realizar los cambios que en fases terminales pueden ser excesivos. El mantenimiento también puede ser muy problemático para un sistema desarrollado bajo este escenario.

Desarrollo del Software Diseño

¿Cumple con los requisitos del Cliente?

Software Terminado

Si

No, Modificar

Desarrollo del Software Diseño

Software Terminado

El modelo es simple, se compone de 3 partes, la primera engloba el diseño y el desarrollo, pues solo se toma los datos otorgados por el cliente, y sin hacer una análisis muy extenso, y se comienza con el desarrollo del software. Al terminar, se presenta un software completo y terminado.

¿Cumple con los requisitos del Cliente?

Esta en vez de ser considerada una parte del modelo, es mejor vista como una evaluación integral del software que se termino en la primera etapa, aquí puede suceder dos cosas, que el cliente acepte el programa, o que lo rechace, añadiendo o eliminado características del software que se termino el primera parte. Al finalizar la evaluación se procede con repetir el proceso de desarrollo y diseño; o se continua hacia la etapa final

Esta es la ultima etapa del modelo, aquí solo se ven pequeños detalles preliminares del software que solo tienen que ver con la parte exterior del mismo. El software se considera terminado y listo para usarse.

Modelo de Cascada/Cascada Modificada

Originalmente este modelo se basa en el conjunto de varios modelos en unificación. Hace el desarrollo mas estructurado, y además expresa la relación entre las fases subsecuentes. Originalmente era un modelo estrictamente secuencial, esto significaba que cada fase debe terminar para que la siguiente pueda comenzar. El punto crítico es que una fase no ha terminado hasta que la documentación y/o otros productos asociados con esa fase hayan sido completados. No permitía la retroalimentación o la re definición de las fases anteriores.

Después se creo la cascada modificada, en este caso permitía la retroalimentación y daba mas libertades en la terminación de las tareas, “congelando” algunas desde ciertos puntos para dar paso a otras. Además se agregaron los pasos de verificación y validación, para poder checar que el sistema es el correcto y cumple con los requisitos del cliente.

Especificaciones

Diseño General

Diseño en detalle

Programación

Integración

Implementación

Mantenimiento

Prueba

Prueba

Prueba de Unidad

Prueba de Integración

Validación

Validación

Especificaciones Las ideas del cliente se plasman aquí, el equipo de trabajo tiene la tarea de analizar e interpretar todos posibles requerimientos, limitaciones y características del software en este punto.

Diseño General Ya cuando se interpretan los datos, se empieza a visualizar un modelo general del software, que abarca todos los puntos desde la programación, el diseño visual, etc.

Diseño en detalle

Esta revisión es la mas extensa de todas, ya que abarca los elementos mas importantes del todo el programa, mas allá de el orden de estructuración y la micro administración, es la parte donde el programador da soluciones a los problemas o limitaciones expuestos por el cliente.

Programación Después de haber terminado el diseño completo, se comienza con la creación de software, esta es una de las partes mas importantes, donde se refleja la calidad del diseño y su potencial implementación en un sistema complejo.

Integración Sirve para garantizar que las diferentes partes de software de acoplen exitosamente hacia el sistema en si.

Implementación Después de el ensamblaje, se pone en producción el

software.

Mantenimiento

Para todos los procedimientos correctivos y las actualizaciones secundarias del software (mantenimiento continuo). Con esto finaliza todo el proceso de cascada.

Las validaciones son solo para verificar que tan aceptadas son los análisis que fueron realizados, y para verificar si el software esta listo para ser entregado . Las pruebas se hacen en el núcleo del proceso, ya sea para verificar el código, la programación y la implementación de software antes de entregarse al cliente y cumplir con las expectativas esperadas.

Modelo de construcción de prototipos

Este modelo tiene 3 pasos : *Escuchar al cliente para definir detalladamente los objetivos del producto, los requisitos y las áreas donde se necesita mas información *Construir y revisar la maqueta (prototipo). *El cliente prueba la maqueta (prototipo) y lo utiliza para refinar los requisitos del software. Este método es útil cuando nuestros clientes no están seguros del lo que realmente quieren, además de involucrarlo en el desarrollo del mismo para conseguir los resultados que se quieren. El problema con los prototipos es que generalmente no representan actualmente el sistema que se desarrolla, algunas veces porque son creaciones que esta “forzadas” para su uso (muy grandes, mal optimizados, lentos).

Especificaciones

Diseño General

Diseño en detalle

Programación

Integración

Implementación

Mantenimiento

Prueba

Prueba

Prueba de Unidad

Validación

Este método no diferencia mucho del de cascada modificada, solo añade prototipos al final de las fases que involucran programación.

Prototipo 1

Prototipo 2

Prototipo 3

Métodos de Rápido de Desarrollo de Software

El desarrollo de software de "métodos rápidos" (también denominado Modelo rápido o abreviado AG) reduce el tiempo del ciclo de vida del software y por lo tanto, acelera el desarrollo de nuevo software. En primera instancia, se entrega una versión prototipo y después se integran la funcionalidades de manera iterativa para satisfacer los requisitos del cliente y controlar todo el ciclo de desarrollo.

Los métodos rápidos se originaron por la inestabilidad del entorno técnico y el hecho de que el cliente a veces es incapaz de definir cada uno de los requisitos al inicio del proyecto. El término "rápido" es una referencia a la capacidad de adaptarse a los cambios de contexto y a los cambios de especificaciones que ocurren durante el proceso de desarrollo

Modelo RAD (Diseño Rápido de Aplicaciones)

Es un modelo de proceso de desarrollo de software de cascada que enfatiza un ciclo de desarrollo extremadamente corto. Este modelo se puede usar si y solamente si se comprenden bien los requisitos y se limita el ámbito del proyecto, si es fácil dividir al sistema en partes (o módulos) pequeños y se utiliza un enfoque de construcción basado en objetos reusables donde haya una retroalimentación en cada parte del proyecto.

Particularmente este método rápido requiere recursos humanos suficientes como para crear el número correcto de equipos; además de necesitar que el cliente y el desarrollador se comprometan en las actividades necesarias para completar un sistema en un tiempo corto; un ciclo de desarrollo corto basado en tres fases (requisitos, diseño y construcción) con un plazo de entrega ideal de 90 a 120 días como máximo.

Modelado de gestión

Modelado de datos

Modelado de procesos

Generación de aplicaciones

Pruebas y Volumen

Equipo 1

90 a 120 Días

El flujo de información entre las funciones de gestión se modela de forma que responda a las siguientes preguntas: ¿Qué información conduce el proceso de gestión? ¿Qué información se genera? ¿Quién la genera? ¿A dónde va la información? ¿Quién la proceso? El flujo de información definido como parte de la fase de modelado de gestión se refina como un conjunto de objetos de datos necesarios para apoyar la empresa. Se definen las características (llamadas atributos) de cada uno de los objetos y las relaciones entre estos objetos. Los objetos de datos definidos en la fase de modelado de datos quedan transformados para lograr el flujo de información necesario para implementar una función de gestión. Las descripciones del proceso se crean para añadir, modificar, suprimir, o recuperar un objeto de datos. Es la comunicación entre los objetos. El DRA asume la utilización de técnicas de cuarta generación. En lugar de crear software con lenguajes de programación de tercera generación, el proceso DRA trabaja para volver a utilizar componentes de programas ya existentes (cuando es posible) o a crear componentes reutilizables (cuando sea necesario). En todos los casos se utilizan herramientas automáticas para facilitar la construcción del software. Como el proceso DRA enfatiza la reutilización, ya se han comprobado muchos de los componentes de los programas. Esto reduce tiempo de pruebas. Sin embargo, se deben probar todos los componentes nuevos y se deben ejercitar todas las interfaces a fondo.

Modelado de gestión

Modelado de datos

Generación de aplicaciones

Pruebas y Volumen

Modelado de procesos

Método de Desarrollo de Sistema Dinámico (DSDM)

Este método se creo y desarrolló para completar lo que le faltaba al método RAD al proporcionar una estructura que tome en cuenta el ciclo de desarrollo completo. En comparación del RAD, esta presenta mas fases, pero dentro del mismo ciclo temporal.

•Las características principales del método DSDM son las siguientes:

•Participación del usuario

•Desarrollo iterativo y creciente

•Frecuencia de entrega mejorada

•Pruebas integradas en cada fase

•La aceptación de los productos entregados depende directamente del cumplimiento de los requisitos.

Método de Proceso Unificado (UP) y Unificado Racional

(RUP)

El método proceso unificado (UP) es un proceso de desarrollo iterativo y creciente. Esto significa que el proyecto se divide en fases más cortas y que se envía una nueva versión gradual al final de cada fase; se podría considerar como un RAD con un sistema de prototipos al termino de cada fase de desarrollo.

Este enfoque está basado en el modelo UML para la descripción de la arquitectura del software (funcional, de aplicación y física) y para el desarrollo del caso del usuario. Dicho modelo describe los requisitos y las demandas del usuario.

El RUP es un método de desarrollo iterativo promovido por la compañía Rational Software, adquirida por IBM.

Este método especifica, principalmente, la constitución del equipo y las escalas de tiempo, así como un número de modelos de documento, mas los métodos usados en el UP.

Modelo XP - Programación extrema

El método XP (Programación extrema) define un conjunto de prácticas óptimas para el desarrollo de aplicaciones en excelentes condiciones al colocar al cliente en el centro del proceso de desarrollo, manteniendo una cercana relación con dicho cliente.

La Programación extrema se basa en los siguientes conceptos:

•Los equipos de desarrollo trabajan directamente con el cliente durante ciclos cortos de una o dos semanas como máximo.

•La entrega de las versiones del software ocurre muy temprano y en intervalos muy cortos para maximizar la interacción con el usuario.

•Existe una fuerte colaboración entre el equipo de desarrollo mientras trabaja en el código.

•El código se prueba y depura a lo largo del proceso de desarrollo.

•Existen indicadores que miden el progreso del proyecto para poder actualizar el plan de desarrollo.

Modelos evolutivos

Esta familia de modelos se utilizan en las siguientes circunstancias:

- Si los requisitos cambian conforme el desarrollo avanza.

- Si las fechas de mercado hacen imposible tener un producto completo y hay que introducir una versión limitada.

- Si los requisitos centrales están bien definidos pero todavía hay que definir los detalles de las extensiones del producto.

Veremos a continuación 2 modelos de este tipo:

- Incremental

- Espiral de Boehm (Tradicional y Moderno)

Modelo incremental

Combina elementos del modelo de cascada (aplicados repetitivamente) con la filosofía interactiva de construcción de prototipos.

El primer incremento es un producto esencial (llamado núcleo), se afrontan requisitos básicos y muchas funciones extras (algunas conocidas o no) quedan para los siguientes incrementos. El cliente usa el producto central y en base a la utilización y/o evaluación se desarrolla un plan para el incremento siguiente. Este proceso se repite hasta que se elabora el producto completo.

Es interactivo, al igual que el de construcción de prototipos y otros enfoques evolutivos. Pero a diferencia del modelo de construcción de prototipos, el modelo incremental entrega un producto operacional en cada incremento.

Es útil cuando la dotación de personal no está disponible para una implementación completa. El primer incremento se pueden implementar con pocas personas. Si el producto central es bien recibido, se puede añadir mas personal.

Modelo incremental

Los pasos de este modelo solo están limitados por la cantidad de incrementos que se realicen el todo el proyecto, la combinación de cascada y prototipos hace de este método muy rápido y eficiente en la creación de proyectos de tamaño considerable.

Bibliografía

http://alarcos.inf-cr.uclm.es/doc/ISOFTWAREI/Tema03.pdf

http://alarcos.inf-cr.uclm.es/doc/ISOFTWAREI/Tema04.pdf

http://eclases.tripod.com/id12.html

http://ldc.usb.ve/~vtheok/cursos/ci3711/apuntes/99-01-14/Info/Modelo%20RAD.htm

http://curiosisimos.files.wordpress.com/2009/12/modelo-de-desarrollo-rapido-de-aplicaciones.pdf