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

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

3. 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.
Si
Desarrollo del
¿Cumple con los requisitos Software
Software
del Cliente? Terminado
Diseño
No, Modificar

4. El modelo es simple, se compone de 3 partes, la primera engloba el diseño y el
Desarrollo del desarrollo, pues solo se toma los datos otorgados por el cliente, y sin hacer una
Software análisis muy extenso, y se comienza con el desarrollo del software. Al terminar, se
Diseño presenta un software completo y terminado.
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,
¿Cumple con los requisitos o que lo rechace, añadiendo o eliminado características del software
del Cliente? 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
Software preliminares del software que solo tienen que ver con la parte exterior del
Terminado mismo. El software se considera terminado y listo para usarse.

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

6. Especificaciones
Validación
Diseño General
Prueba
Diseño en detalle
Prueba
Program ación
Prueba de Unidad
Integración
Prueba de Integración
Im plementación Validación
Mantenimiento

7. Las ideas del cliente se plasm an aquí, el equipo de trabajo tiene
Especificaciones la tarea de analizar e interpretar todos posibles requerim ientos,
lim itaciones y características del software en este punto.
Diseño General Ya cuando se interpretan los datos, se em pieza a visualizar un
m odelo general del software, que abarca todos los puntos
desde la program ación, el diseño visual, etc.
Esta revisión es la m as extensa de todas, ya que abarca los
Diseño en detalle elem entos m as im portantes del todo el program a, m as allá de
el orden de estructuración y la m icro adm inistración, es la
parte donde el program ador da soluciones a los problem as o
lim itaciones expuestos por el cliente.
Después de haber term inado el diseño com pleto, se com ienza con
Program ación la creación de software, esta es una de las partes m as im portantes,
donde se refleja la calidad del diseño y su potencial
im plementación en un sistem a com plejo.
Integración Sirve para garantizar que las diferentes partes de software de
acoplen exitosam ente hacia el sistem a en si.

8. Después de el ensam blaje, se pone en producción el
Im plementación
software.
Para todos los procedim ientos correctivos y las actualizaciones
Mantenimiento secundarias del software (m antenimiento 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.

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

10. Especificaciones
Validación
Diseño General
Prueba
Diseño en detalle
Prueba
Program ación
Prueba de Unidad
Prototipo 1 Integración
Prototipo 2 Im plementación
Prototipo 3 Mantenimiento
Este método no diferencia mucho del
de cascada modificada, solo añade
prototipos al final de las fases que
involucran programación.

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

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

13. Equipo 1
Modelado
de gestión
Modelado
de datos
Modelado
de
procesos
Generación de
aplicaciones
Pruebas y
Volum en
90 a 120 Días

14. Modelado 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
de gestión la proceso?
Modelado 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
de datos entre estos objetos.
Modelado Los objetos de datos definidos en la fase de modelado de datos quedan transformados para lograr el flujo de información necesario
de 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.
procesos
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
Generación de componentes reutilizables (cuando sea necesario). En todos los casos se utilizan herramientas automáticas para facilitar la
aplicaciones 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
Pruebas y tiempo de pruebas. Sin embargo, se deben probar todos los componentes nuevos y se deben ejercitar todas las interfaces a fondo.
Volum en

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

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

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

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

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

20. 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.
Modelo incremental

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