Esta presentación muestra los distintos modelos de desarrollo de software y las actividades involucradas en cada una de sus etapas.

1. UNIDAD IV
I-2013
Modelos de desarrollo
de software
Prof. Yaskelly Yedra
INGENIERÍA DE
SOFTWARE
Actividades en el proceso de desarrollo de software

2. 2
Modelo de proceso de DS
1. Modelo secuencial
2. Modelo de proceso incremental
3. Modelo de proceso evolutivo
4. Modelos basados en transformaciones
5. Modelos especializados en proceso
6. Proceso Unificado (PU)
 Modelo en Cascada

3. 3
Modelo en Cascada
Encadenamiento secuencial de las actividades
Cada etapa produce documentos que son la entrada a
la siguiente.
Para desarrollar una etapa debe concluirse la anterior.
El modelo original no se adapta a ciertas aplicaciones.
Los costos al descubrir errores en etapas avanzadas
son muy altos (es rígido).
Se incorporan variantes al modelo.

4. 4
Validación
Instalación, Explotación
Test y pruebas previas a la Operación
Operación y Mantenimiento
Estudio de Viabilidad
Análisis
Especificación
Requisitos del
Software
Diseño
Especificación de diseño
Diseño Preliminar y
Detallado
Codificación
Aplicación
Codificación y Depuración
A alguien se le ha ocurrido la Brillante idea de Informatizar
¿?
Investigación Inicial, Identificación de Necesidades,
Encuesta, etc.
Requisitos del
Sistema
Modelo en Cascada

5. 5
Definición de
Requisitos
Diseño del Software
y del Sistema
Implementación y
Prueba de unidades
Integración y Prueba
del Sistema
Operación y
Mantenimiento
Modelo en Cascada
• Separa y secuencia las fases, (no es
estrictamente secuencial, a veces se
solapan las etapas)
• También se le conoce como
“modelo lineal secuencial” o
“ciclo de vida clasico”

6. 6
Modelo en Cascada
Definición
Análisis
Diseño
Desarrollo
Pruebas
Mantenim.
Definición de requisitos:
• Las restricciones y metas del sistema se definen a partir de la
interacción con el interesado.
• Se comprende la naturaleza de la aplicación y el dominio de información,
así como su funcionalidad, rendimiento e interconexión
• Se reúnen todos los requisitos que debe cumplir el software

7. 7
Modelo en Cascada
Definición
Análisis
Diseño
Desarrollo
Pruebas
Mantenim.
Se concentra en cuatro características básicas:
Estructura de datos
Arquitectura del software
Representaciones de interfaz
Detalle procedimental (algoritmo)

8. 8
Modelo en Cascada
Definición
Análisis
Diseño
Desarrollo
Pruebas
Mantenim.
• Se llama también Implementación
• Generación de código entendible por la máquina
• Actualmente se investiga mucho sobre la manera de
generar código automáticamente

9. 9
Modelo en Cascada
Definición
Análisis
Diseño
Desarrollo
Pruebas
Mantenim.
• Proceso de depuración de programas
• Chequear la validez de las sentencias
• Pruebas para detectar errores, asegurando que a
partir de los datos de entrada si se genere la salida
deseada

10. 10
Modelo en Cascada
Definición
Análisis
Diseño
Desarrollo
Pruebas
Mantenim.
• Corrección de errores no detectados en la etapa de
pruebas
• Posibles mejoras funcionales debidas a nuevos
requisitos del cliente
• En esta fase se vuelven a aplicar todas las etapas
anteriores sobre el software existente

11. 11
Modelo en cascada: ventajas-desventajas
El gran problema de este modelo es la dificultad de
realizar cambios después que el proceso ha avanzado
Partición inflexible del proyecto en etapas
Dificultad de responder a los cambios de los requisitos
del cliente
Se retrasa la localización y corrección de errores
Inflexibilidad del modelo: dificultad para responder a
cambios en los requisitos
Este modelo es apropiado cuando los requisitos están
bien definidos

12. 12
Modelo de proceso de DS
1. Modelos secuencial
2. Modelo de proceso incremental
3. Modelo de proceso evolutivo
4. Modelos basados en transformaciones
5. Modelos especializados en proceso
6. Proceso Unificado (PU)
 Modelo Incremental
 Modelo DRA

13. 13
Modelo de Proceso Incremental
Aplica el enfoque del modelo en cascada, pero
aplicado en forma iterativa
Cada secuencia lineal produce incrementos que
agregan funcionalidades adicionales o mejoras al
sistema
Cada etapa debe cumplir con sus requisitos
Incrementos parciales de la herramienta completa las
diferentes versiones del proyecto
El modelo de proceso incremental, al igual que la
construcción de prototipos y otros enfoques
evolutivos, es iterativo por naturaleza.

14. 14
Modelo de Proceso Incremental
Incremento 2
Incremento n
... ... ... ...
Análisis Diseño Código Pruebas
Análisis Diseño Código Pruebas
Análisis Diseño Código Pruebas
Incremento 1
Entrega del
1er
incremento
Entrega del
2do
incremento
Entrega de
n-ésimo
incremento

15. 15
Modelo de Proceso Incremental
Ventajas:
 Los clientes no tienen que esperar hasta que el sistema se
entregue completamente para comenzar a hacer uso de él.
 Los clientes pueden usar los incrementos iniciales como prototipo
para precisar los requisitos posteriores del sistema.
 Minimización del riesgo de falla en el proyecto porque los errores
se van corrigiendo progresivamente.
Desventaja:
 Adaptación de los requisitos del cliente para lograr incrementos
pequeños (no mas de 20.000 líneas de código) que añadan
funcionalidad al sistema.
Nota: Una evolución de este enfoque se conoce como Programación
Extrema (XP-Extreme Programming).

16. 16
Modelo de proceso de DS
1. Modelos secuencial
2. Modelo de proceso incremental
3. Modelo de proceso evolutivo
4. Modelos basados en transformaciones
5. Modelos especializados en proceso
6. Proceso Unificado (PU)
 Modelo Incremental
 Modelo DRA

17. 17
Modelo de Desarrollo Rápido de
Aplicaciones (DRA)
Basado en el Modelo en Cascada, pero con una aplicación más
rápida, basada en componentes o generación de código.
Modelo llevado a cabo por varias equipos de trabajo que siguen
las etapas del proceso de manera simultanea.
Modelo aplicable a la construcción de sistemas de información
fácilmente modularizables.
El Modelo DRA necesita clientes y desarrolladores
comprometidos con el proceso.
Varios equipos de desarrolladores de software trabajan en
paralelo sobre diferentes funciones del sistema

18. 18
Modelo de Desarrollo Rápido de
Aplicaciones (DRA)
Equipo No. 1
Equipo No. 2
Equipo No. N..
Comunicación
Planeación
Modelado
Modelado del negocio
Modelado de los datos
Modelado del proceso
Modelado
Modelado del negocio
Modelado de los datos
Modelado del proceso
Modelado
Modelado del negocio
Modelado de los datos
Modelado del proceso
60-90 días
Despliegue
Integración
Entrega
Retroalimentación
Construcción
Reutilización de componentes
Generación automática de código
Pruebas
Construcción
Reutilización de componentes
Generación automática de código
Pruebas
Construcción
Reutilización de componentes
Generación automática de código
Pruebas

19. 19
Modelo de Desarrollo Rápido de
Aplicaciones (DRA): Desventajas
No funciona para proyectos a grandes escala, necesitaría
suficiente RRHH para crear el número correcto de equipos.
Si los desarrolladores y clientes no se comprometen con las
actividades necesarias para completar el sistema en un marco
de tiempo muy breve, el proyecto DRA fallaría.
Si un sistema no se puede modular en forma apropiada, la
construcción de los componentes para el DRA será
problemática
El DRA sería inapropiado cuando los riesgos técnicos son
altos (integración de nuevas tecnologías)

20. 20
Modelo de proceso de DS
1. Modelos secuencial
2. Modelo de proceso incremental
3. Modelo de proceso evolutivo
4. Modelos basados en transformaciones
5. Modelos especializados en proceso
6. Proceso Unificado (PU)
 Construcción de prototipos
 Modelo espiral
 Modelo de desarrollo concurrente

21. 21
Los modelos evolutivos se caracterizan porque
permiten a los ingenieros del software, desarrollar de
manera iterativa, nuevas versiones del software cada
vez más completas
Las actividades de especificación, desarrollo y
validación se entrelazan en vez de separarse, esto
permite una rápida retroalimentación entre ellas
Existen dos tipos de desarrollo evolutivos:
 Desarrollo exploratorio
 Prototipos desechables
Desarrollo Evolutivo: Prototipado

22. 22
Desarrollo exploratorio (prototipado exploratorio o evolutivo)
 El objetivo es trabajar con clientes hasta evolucionar a un
sistema final, a partir de una especificación inicial El sistema
empieza con las partes del sistema que se comprenden mejor. El
sistema evoluciona agregando nuevos atributos propuestos por
el cliente
Prototipaje desechable
 Persiguen objetivos más bien de exploración, por lo que poseen
un corto ciclo de vida. Permiten crear opciones individuales de
requisitos, diseño e implementación repentinas, de modo de
satisfacer un nuevo requerimiento para luego ser desechado. La
razón de su empleo radica en aprender lecciones necesarias a
un costo mínimo.
Desarrollo Evolutivo: Prototipado

23. 23
Descripción
del sistema
Versión
Inicial
Versión
Final
Versiones
Intermedias
Especificación
Desarrollo
Validación
Actividades
Concurrentes
Desarrollo Evolutivo: Prototipado

24. 24
Recolección y
refinamiento
de requisitos
Diseño
Rápido de la
aplicación
Construcción
de prototipos
El cliente
evalúa
el prototipo
Desarrollo del
producto final
Desarrollo Evolutivo: Prototipado

25. 25
El proceso no es visible
 Los administradores tienen que hacer entregas
regulares para medir el progreso. Si los sistemas se
desarrollan rápidamente, no es rentable producir
documentos que reflejen cada versión del sistema.
A menudo los sistemas tienen una estrategia
definida
 Los cambios continuos tienden a corromper la
estructura del software. Incorporar cambios en él se
convierte cada vez en una tarea difícil y costosa.
Desarrollo Evolutivo: Prototipado
Desventajas

26. 26
Desarrollo Evolutivo: Prototipado
Ventajas
Se detectan malos entendidos entre los desarrolladores
y los usuarios
Se detectan servicios no detectados antes
Dificultades de uso o servicios confusos pueden ser
identificados y refinados
Staff de desarrollo de software puede encontrar
requisitos incompletos o inconsistentes con el
desarrollo del prototipo
El prototipo sirve como una base de la especificación
para la producción de un sistema de calidad

27. 27
Desarrollo Evolutivo: Prototipado
Problemas
 Poca visibilidad en el proceso
 Los sistemas están pobremente especificados
 Se requieren habilidades especiales.
Aplicabilidad
 Para sistemas interactivos pequeños o
medianos.
 Para partes de sistemas grandes (p.ej. la
interfaz de usuario).
 Para sistemas de corta vida.

28. 28
Modelo de proceso de DS
1. Modelos secuencial
2. Modelo de proceso incremental
3. Modelo de proceso evolutivo
4. Modelos basados en transformaciones
5. Modelos especializados en proceso
6. Proceso Unificado (PU)
 Construcción de prototipos
 Modelo espiral
 Modelo de desarrollo concurrente

29. 29
Modelo en Espiral
Conjuga la naturaleza iterativa de la construcción de
prototipos con los aspectos controlados y
sistemáticos del Modelo en Cascada.
Se desarrolla en una serie de entregas evolutivas,
puede ser en forma de documento o prototipo.
Durante las ultimas iteraciones se produce versiones
cada vez más completas
Se divide en un conjunto de actividades del marco de
trabajo que define el equipo de desarrollo de IS

30. 30
Modelo en Espiral
Provee una visión del proceso que soporta la gestión
de riesgos.
RIESGO: circunstancia potencialmente adversa que puede
impactar al proceso y al producto
GESTION DE RIESGOS: disciplina que identifica, trata y elimina
los potenciales riesgos
Se centra en identificar y eliminar los riesgos en el
desarrollo de software
Es cíclico y en cada nivel se asegura mayor robustez,
mientras que disminuye su grado de riesgo

31. 31
El proceso se representa como una espiral en lugar
de una secuencia de actividades
Cada vuelta en la espiral representa una fase en el
proceso
Ninguna fase es fija, tal como la especificación o el
diseño - las vueltas en la espiral son elegidas
dependiendo lo que se requiera
Se evalúan los riesgos explícitamente y se
resuelven a lo largo del proceso
Modelo en Espiral

32. 32
Fases del Modelo de Espiral
Planteamiento de Objetivos
 Se identifican los objetivos específicos para cada
fase del proyecto.
Identificación y reducción de riesgos.
 Los riesgos clave se identifican y analizan, y la
información sirve para minimizar los riesgos.
Desarrollo y Validación.
 Se elige un modelo apropiado para la siguiente fase
del desarrollo.
Planeación.
 Se revisa el proyecto y se trazan planes para la
siguiente ronda del espiral.

33. 33
33
I
Identifica
Objetivos,
alternativas,
restricciones
II
Evalúa
alternativas,
identifica y
resuelve riesgos
IV
Revisión de
resultados y
Planificación de
la siguiente fase
III
Desarrolla,
verifica
requisitos, plan del
ciclo de vida
Análisis
de riesgo
Prototipo 1
Prototipo 2
Prototipo 3
PrototipoAnálisis
de riesgo
Análisis
de riesgo
Análisis
de riesgo
Diseño
detallado
Plan de
desarrollo
Integración y
plan de test
Validación
del diseño
Diseño
requisitos
Validación
de req.
Código
Test
Unitario
Integración
y test
Simulación, modelación
Elmodeloespiral progreso
Incepción
liberación

34. 34
Ventajas del Modelo de Espiral
Ventajas
 Centra su atención en la reutilización de
componentes y eliminación de errores en información
descubierta en fases iniciales.
 Útil para proyectos grandes.
 Permite usar el prototipado en todas las etapas de la
evolución para reducir el riesgo.
 Mantiene el enfoque sistemático de los pasos
sugeridos por el modelo lineal secuencial, pero lo
incorpora dentro de un marco iterativo más real.

35. 35
Ventajas del Modelo de Espiral
Desventajas
 Requiere de experiencia en la identificación
de riesgos.
 Requiere refinamiento para uso generalizado
 Difícil de convencer a los clientes de que es
controlable.
 Requiere mucha habilidad para el análisis de
riesgos y de esta habilidad depende su éxito.
 No ha sido utilizado tanto como el lineal
secuencial o el de prototipos.
 Se necesita mucha experiencia

36. 36
Ventajas del Modelo de Espiral
Evolución del Modelo Espiral
 Para aplicaciones basadas en web

37. 37
Modelo de proceso de DS
1. Modelos secuencial
2. Modelo de proceso incremental
3. Modelo de proceso evolutivo
4. Modelos basados en transformaciones
5. Modelos especializados en proceso
6. Proceso Unificado (PU)
 Construcción de prototipos
 Modelo espiral
 Modelo de desarrollo concurrente

38. 38
Modelo de Desarrollo Concurrente
Provee una meta descripción del proceso de software
Mientras que en el Espiral la principal contribución es que
las actividades del software ocurran repetidamente, en el
Concurrente es la capacidad de describir las múltiples
actividades del software que ocurren simultáneamente.
Dado que los requisitos cambian, es muy probable que una
vez haya comenzado la fase de diseño, sea necesario
incorporar cambios. En estos casos NO se debe detener el
diseño, sino que se debe continuar “si es posible” al mismo
tiempo que se modifican los requisitos.
En este modelo, diversas actividades pueden estar
ocurriendo concurrentemente, pero se encuentran en
diferentes estados.

39. 39
Modelo de Desarrollo Concurrente
Ninguna
Bajo
Desarrollo
Cambios en
espera Bajo
Revisión
Bajo
Modificación
En línea
base
Realizado
Representa un
estado de una
actividad de IS
Actividad de análisis

40. 40
Modelo de proceso de DS
1. Modelo secuencial
2. Modelo de proceso incremental
3. Modelo de proceso evolutivo
4. Modelos basados en transformaciones
5. Modelos especializados en proceso
6. Proceso Unificado (PU)

41. 41
Harramientas CASE
Acrónimo de Computer Aided Software Engineering
(Ingeniería del software asistida por ordenador).
Tecnología software que proporciona la automatización de
las tareas de desarrollo, mantenimiento y dirección del
software.
El CASE proporciona un conjunto de herramientas bien
integradas que ahorran trabajo, enlazando y automatizando
todas las fases del ciclo de vida del software.
Ejemplos de CASE
Herramientas de diagramación
Diccionario de datos
Herramientas de validación de
especificaciones
Generadores de código
Generadores de documentación

42. 42
Surge como consecuencia de la aparición del CASE y de
los generadores de código.
Este ciclo de vida puede considerarse como una serie de
transformaciones:
 El objetivo del sistema se transforma en
especificaciones de requisitos.
 Las especificaciones de requisitos se transforman en
especificaciones de diseño.
 Las especificaciones de diseño se transforman en
código.
Modelo Basado en Transformaciones

43. 43
Modelo Basado en Transformaciones
Ventajas
 Posibilidad de comprobación de errores en etapas
iniciales del desarrollo.
 Posibilidad de realizar el mantenimiento a nivel de
especificación, evitando tener que modificar un
código que esté pobremente estructurado después
de repetidos procesos de optimización.
 Soporte para la validación de los requisitos.
 Soporte de reusabilidad.
 Potencia la especificación orientada al problema.

44. 44
Modelo Basado en Transformaciones
Desventajas
 Requieren especificaciones iniciales muy
detalladas.
 Restringen el ámbito de la aplicación.
 Requieren una maduración previa del
proceso de desarrollo.

45. 45
Modelo de proceso de DS
1. Modelos secuencial
2. Modelo de proceso incremental
3. Modelo de proceso evolutivo
4. Modelos basados en transformaciones
5. Modelos especializados en proceso
6. Proceso Unificado (PU)
 Modelo basado en componentes
 Modelo de métodos formales

46. 46
Modelo Basado en Componentes
Se basa en la reutilización de componentes
Requiere de una librería de componentes
La reutilización puede ser de componentes de
especificación, de programas, etc.
La reusabilidad permite reducir el tiempo y los
costos asociados a la construcción de productos
de software
Requiere de herramientas de asistencia para las
nuevas actividades que se generan.

47. 47
Modelo Basado en Componentes
La tecnología de objetos proporciona el marco
de trabajo técnico para un modelo de proceso
basado en componentes para la IS.
El paradigma orientado a objetos enfatiza en la
creación de clases que encapsulan tanto los
datos como los algoritmos que se utilizan para
manejar los datos.
Si se diseñan e implementan las clases
correctamente, podrían ser reutilizables por las
diferentes aplicaciones y arquitecturas de
sistemas basados en computadores.

48. 48
Modelo Basado en Componentes
El modelo de desarrollo basado en componentes
incorpora muchas de las características del
modelo en espiral.
Es evolutivo por naturaleza y exige un enfoque
iterativo para la creación de software.
Configura aplicaciones desde componentes
preparados de software.
El modelo basado en componentes conduce a la
reutilización del software, proporcionando
beneficios a los ingenieros de software.

49. 49
Un sistema está integrado a partir de componentes
Etapas del proceso
 Analisis de componentes
 Modificación de requisitos
 Diseño del sistema con reuso
 Desarrollo e integración
Modelo Basado en Componentes
Análisis de
componentes
Especificación de
requisitos
Modificación de
requisitos
Desarrollo e
integración
Validación del
sistema
Diseño del sistema
con reutilización

50. 50
Ventaja
 Optimiza los tiempos de respuesta a los requisitos del
cliente y facilita la labor del programador pues hay un
alto aprovechamiento del código.
 Facilita mantenimiento del software.
Desventaja
 Puede no tenerse los componentes adecuados para
los requisitos del sistema.
 Si las nuevas versiones de los componentes no están
bajo el control de quien los utiliza se pierde parte de la
evolución del sistema.
Modelo Basado en Componentes

51. 51
Modelo Basado en Componentes
Evolución del Modelo Espiral aplicado a la reutilización
de componentes
Planificación
Análisis
de Riesgo
Construcción
y adaptación de
la ingeniería
Evaluación
Del Cliente
Comunicación
con el Cliente
Identificar
componentes
candidatos
Construir
la iteración
del sistema
Poner nuevos
componentes
en la biblioteca
Extraer
Componentes
Si están
disponibles
Buscar
Componentes
en biblioteca
Extraer
Componentes
Si No están
disponibles

52. 52
Modelo de proceso de DS
1. Modelos secuencial
2. Modelo de proceso incremental
3. Modelo de proceso evolutivo
4. Modelos basados en transformaciones
5. Modelos especializados en proceso
6. Proceso Unificado (PU)
 Modelo basado en componentes
 Modelo de métodos formales

53. 53
Modelo de Métodos Formales
El proceso de desarrollo se basa en la transformación
matemática formal de la especificación del sistema a un
programa ejecutable
Facilita la verificación de programas a través de un
riguroso análisis matemático.
La ejecución de este tipo de modelos requiere mucho
tiempo y esfuerzo.
Especificación
formal
Definición de
requisitos
Transformación
formal
Integración y
prueba del sistema

54. 54
Modelo de Métodos Formales
Ventaja
 Demostraciones formales de propiedades.
 Especificaciones sin ambigüedades.
 Útiles para sistemas críticos, dónde la seguridad debe
garantizarse antes que el sistema sea puesto en
funcionamiento.
Desventaja
 Difícil especificar algunos aspectos del sistema tales
como la interfaz de usuario
 La ejecución de este tipo de modelos requiere mucho
tiempo y esfuerzo.
 Pocos desarrolladores dominan el algebra y las
matemáticas para la especificación formal.

55. 55
Modelo de proceso de DS
1. Modelos secuencial
2. Modelo de proceso incremental
3. Modelo de proceso evolutivo
4. Modelos basados en transformaciones
5. Modelos especializados en proceso
6. Proceso Unificado (PU)
 Dirigido por caso de uso
 Centrado en la arquitectura
 Iterativo e incremental

56. 56
El Proceso Unificado (PU)
Quién está haciendo,
Qué es lo que está haciendo,
Cuándo debe hacerlo, y
Cómo obtener un cierto objetivo.
trabajadores
artefactos
fases del
proceso
encadenamiento
de actividades.
Define:
Modelo, documento, código
o pieza de información
producido en el proceso de
desarrollo de software

57. 57
Está basado en componentes e interfaces bien
definidas
Utiliza el Lenguaje Unificado de Modelado (UML)
Aspectos característicos:
– Dirigido por casos de uso
– Centrado en la arquitectura
– Iterativo e incremental
El Proceso Unificado (PU)
Ivar Jacobson, Grady Booch, James
Rumbaugh, “El Proceso Unificado
de Desarrollo Software”, Addison
Wesley, 1999

58. 58
Caso de uso: Fragmento de funcionalidad que
proporciona al usuario/cliente un resultado importante
Modelo de casos de uso: Funcionalidad total del sistema
¿Qué debe hacer el sistema … para cada usuario?
Guían el proceso de desarrollo
Dirigido por casos de uso
El Proceso Unificado (PU)

59. 59
Describe diferentes vistas del sistema
Incluye los aspectos estáticos y dinámicos más
significativos
La arquitectura y los casos de uso evolucionan en
paralelo
Responsable: el arquitecto:
 Empieza por la parte que no es específica de los casos de uso
 Trabaja con casos de uso claves
 Progresa con la especificación de más casos de uso
Centrado en la arquitectura
El Proceso Unificado (PU)
Proyección de la organización y
estructura de un sistema
enfocándose en aspectos
particulares

60. 60
Arquitectura: Vistas
El Proceso Unificado (PU)
Para modelar un sistema desde diferentes vistas se debe
responder:
¿Qué vistas se requiere?
Para cada vista:
¿Qué artefactos producir?
¿Con qué notación?

61. 61
Se divide el trabajo en mini-proyectos
Cada mini-proyecto es una iteración que resulta en un
incremento
La iteración
 Trata un conjunto de casos de uso
 Trata los riesgos más importantes
En cada iteración se persiguen unos objetivos concretos
El Proceso Unificado (PU)
Iterativo e incremental

62. 62
Beneficios de un proceso iterativo controlado:
 Coste del riesgo a un solo incremento
 Reduce el riesgo de no sacar el producto en el
calendario previsto
 Acelera el ritmo de desarrollo
 Se adapta mejor a las necesidades del cliente
El Proceso Unificado (PU)
Iterativo e incremental

63. 63
El Proceso Unificado (PU)
Iterativo e incremental
Permite desarrollar un sistema a través de
refinamientos sucesivos e incorporación de
nuevas funcionalidades, creando una solución
efectiva, en múltiples iteraciones.
 Alto nivel de reuso
 Apendizaje del grupo del proyecto durante el desarrollo
del software
 Adaptación a requisitos cambiantes
 Mitigación de los riesgos y realización de las pruebas en
etapas tempranas del desarrollo del software.

64. 64
El Proceso Unificado (PU)
Modelado del
Negocio
Implementación
Prueba
Entrega
Análisis y Diseño
Disciplinas
Fundamentales
Requisitos
Fases
Elaboración Construcción TransiciónInicio
Iteraciones y disciplinas

65. 65
El Proceso Unificado (PU)
tiempo
Inicio Elaboración Construcción Transición
Define el alcance y
factibilidad del proyecto.
(análisis de requisitos).
Fases del ciclo de vida

66. 66
El Proceso Unificado (PU)
tiempo
Inicio Elaboración Construcción Transición
Planifica el proyecto,
especifica las
características y la
arquitectura base.
(Análisis y diseño)
Fases del ciclo de vida

67. 67
El Proceso Unificado (PU)
Fases del ciclo de vida
tiempo
Inicio Elaboración Construcción Transición
Construye el producto
(implementación)

68. 68
El Proceso Unificado (PU)
Fases del ciclo de vida
tiempo
Inicio Elaboración Construcción Transición
Entrega del producto al
cliente o a los usuarios.

69. 69
El Proceso Unificado (PU)
69
Modelado del
Negocio
Implementación
Prueba
Entrega
Análisis y Diseño
Disciplinas
Fundamentales
Requisitos
Fases
Elaboración Construcción TransiciónInicio
Iteraciones y disciplinas
Esbozar:
Modelo de Casos de Uso
Especificaciones complementarias
Glosario

70. 70
El Proceso Unificado (PU)
70
Modelado del
Negocio
Implementación
Prueba
Entrega
Análisis y Diseño
Disciplinas
Fundamentales
Requisitos
Fases
Elaboración Construcción TransiciónInicio
Iteraciones y disciplinas
Refinar:
 Modelo de Casos de Uso
 Especificaciones Complementarias
 Glosario

71. 71
El Proceso Unificado (PU)
71
Modelado del
Negocio
Implementación
Prueba
Entrega
Análisis y Diseño
Disciplinas
Fundamentales
Requisitos
Fases
Elaboración Construcción TransiciónInicio
Iteraciones y disciplinas
Esbozar:
 Modelo de Diseño
 Documento de la Arquitectura

72. 72
El Proceso Unificado (PU)
72
Modelado del
Negocio
Implementación
Prueba
Entrega
Análisis y Diseño
Disciplinas
Fundamentales
Requisitos
Fases
Elaboración Construcción TransiciónInicio
Iteraciones y disciplinas
Refinar:
 Modelo de Diseño

73. 73
El Proceso Unificado (PU)
73
Modelado del
Negocio
Implementación
Prueba
Entrega
Análisis y Diseño
Disciplinas
Fundamentales
Requisitos
Fases
Elaboración Construcción TransiciónInicio
Iteraciones y disciplinas
Esbozar:
 Modelo de implementación

74. 74
El Proceso Unificado (PU)
74
Modelado del
Negocio
Implementación
Prueba
Entrega
Análisis y Diseño
Disciplinas
Fundamentales
Requisitos
Fases
Elaboración Construcción TransiciónInicio
Iteraciones y disciplinas
Refinar:
 Modelo de implementación

75. 75
El Proceso Unificado (PU)
Artefactos que se producen

76. 76
El Proceso Unificado (PU)
Inclusión de la construcción de la interfaz

77. 77
Cascada
 Separa y secuencia las fases
Evolutivo
 Especificación y desarrollo son intercalados
De transformaciones
 Un modelo formal del sistema es transformado en
otro modelo de más bajo nivel de abstracción
Basado en componentes
 El sistema es producto de ensamblaje de
componentes
Modelo de proceso de DS (conclusiones)

78. 78
¿Qué modelo utilizar ?
Para sistemas bien comprendidos se puede aplicar el
Modelo en Cascada. La fase de análisis de riesgos es
relativamente fácil.
Con Requisitos estables y sistemas de seguridad
críticos, se pueden utilizar Modelos Formales.
Con especificaciones incompletas, se puede utilizar el
Modelo de Prototipaje.
Pueden utilizarse modelos híbridos en distintas partes
del desarrollo.

79. 79
Modelos de Procesos Híbridos
Los sistemas grandes están hechos usualmente de
varios subsistemas.
No es necesario utilizar el mismo modelo de proceso
para todos los subsistemas.
El prototipado es recomendado cuando existen
especificaciones de alto riesgo.
El modelo de cascada es utilizado en desarrollos bien
comprendidos.