UNIDAD 3

PARADIGMAS DE LA
INGENIERIA DE SOFTWARE
Paradigmas de ciclos de vida de
laCuando

ingeniería de software
no se sigue un ciclo de vida y apenas se planea, se tiende a
seguir el enfoque de “codificar y probar” lo que genera: una alta
probabilidad de falla en el software, poca flexibilidad para
modificaciones, no satisfacer plenamente los requisito y
descontento de los clientes [Piattini].
 Qué es un ciclo de vida:
 Un modelo de ciclo de vida es un marco de referencia que contiene
los procesos, las actividades y las tareas involucradas en el
desarrollo, la explotación y el mantenimiento de un producto de
software, abarcando la vida del sistema desde la definición de los
requisitos hasta la finalización de su uso [ISO/IEC 12207-1].
 Ciclo de vida del software es una aproximación lógica a la
adquisición, suministro, el desarrollo, la explotación y el
mantenimiento del software [IEEE 1074].
Paradigmas de ciclos de vida de la ingeniería
de software … (2)
 Algunas de las ventajas que aporta el enfoque de ciclo de vida
[Piattini]:
 En las primeras fases, aunque no haya líneas de código, pensar el diseño
es avanzar en la construcción del sistema, pues posteriormente resulta
más fácil la codificación.
 Asegura un desarrollo progresivo, con controles sistemáticos, que
permite detectar precozmente los defectos.
 Se controla el sobrepasar los plazos de entrega y los costes excesivos
mediante un adecuado seguimiento del progreso.
 La documentación se realiza de manera formal y estandarizada
simultáneamente al desarrollo, lo que facilita la comunicación interna
entre el equipo de desarrollo y la de éste con los usuarios. También
aumenta la visibilidad y posibilidad de control para la gestión del
proyecto.
 Supone una guía para el personal de desarrollo, marcando las tareas a
realizar en cada momento.
 Minimiza la necesidad de rehacer el trabajo y los problemas de puesta a
punto.
Paradigmas de ciclos de vida de la ingeniería
de software … (3)
 Actividades agrupadas en procesos que se pueden realizar durante
el ciclo de vida del software [ISO 12207-1].
PROCESOS PRINCIPALES PROCESOS DE SOPORTE
DOCUMENTACIÓN
ADQUISICIÓN
GESTIÓN DE LA CONFIGURACIÓN

SUMINISTRO ASEGURAMIENTO DE LA CALIDAD

VERIFICACIÓN

VALIDACIÓN
EXPLOTACIÓN
REVISIÓN CONJUNTA
DESARROLLO
AUDITORIA
MANTENIMIENTO

RESOLUCIÓN DE PROBLEMAS

PROCESOS DE LA ORGANIZACIÓN
GESTIÓN INFRAESTRUCTURA

MEJORA FORMACIÓN
Ciclos de vida convencionales
 Modelo secuencial (clásico)
 Análisis de los requisitos del software
 Se debe comprender el dominio de la información, la función requerida, comportamiento,
rendimiento e interconexión.
 Diseño
 Proceso de muchos pasos centrado en cuatro atributos: estructura de datos, arquitectura de
software, representación de la interfaz y detalle procedimental.
 Generación de código
 El diseño es traducido a formato legible por la máquina.
 Pruebas
 Detección de errores y asegurar que una entrada definida produce resultados esperados.
 Mantenimiento
 Cambios en el software que implican aplicar todos los pasos precedentes en orden.

Ingeniería de
sistemas de información

Análisis Diseño Código Prueba

Ingeniería de Software
 IEEE: "Standar Glossary of Software Engineering
Terminology“.
 Enfoque sistemático para el desarrollo de operación,
mantenimiento y eliminación del software, donde
software se define como aquellos programas,
procedimientos, reglas y documentación posible
asociada con la computación, así como los datos
pertenecientes a la operación de un sistema de
cómputo.
III. Productos de Software
 Productos genéricos.
 Productos que son producidos por una organización para ser vendidos al
mercado.
 Productos hechos a medida.
 Sistemas que son desarrollados bajo pedido a un desarrollador específico.

 La mayor parte del gasto del software es en productos

genéricos, pero hay más esfuerzo en el desarrollo de los
sistemas hechos a medida.
Características de los Productos de Software
 Mantenibles.
 Debe ser posible que el software evolucione y que siga cumpliendo con sus
especificaciones.
 Confiabilidad.
 El software no debe causar daños físicos o económicos en el caso de fallos.

 Eficiencia.
 El software no debe desperdiciar los recursos del sistema.

 Utilización adecuada.
 El software debe contar con una interfaz de usuario adecuada y su
documentación.
V. Modelo de Ingeniería del
Proceso
 Requisitos
 Capturar los aspectos funcionales correspondientes, cómo un usuario
interactuaría con el sistema.
 Análisis
 Dar al sistema una estructura robusta y extensible bajo un ambiente de
implementación ideal.
 Diseño
 Adoptar y refinar las estructuras al ambiente de implementación particular.
 Implementación
 Codificar el sistema.
 Pruebas
 Validar y verificar el sistema.
 Integración
 Pegar componentes del sistema.
 Documentación
 Describir los distintos aspectos el sistema.
 Mantenimiento
 Extender la funcionalidad del sistema.
VI. Modelos de Desarrollo de Software
¿ Modelo ?
Representación formal o
simplificada del proceso de
software.
Modelos Genéricos del Desarrollo
de Software
 Cascada (Lineal Secuencial)
 Prototipado
 DRA (Reutilización)
 Evolutivo (Incremental)
 Espiral
 Espiral Win / Win
 Basado en componentes
 Programación Extrema
 Proceso unificado de desarrollo de software (PUDS)
Modelo lineal secuencial
 Las tareas se organizan en cascada, una después de la
otra.
 La salida de una etapa es la entrada de la siguiente.
 Creado en 1970 por el Departamento de la Defensa de
EE.UU.
 Su usó en las primeras aplicaciones es crítica y compleja.
Modelo lineal secuencial
Definición de
Requerimientos

Diseño del SW
y del Sistema

Implementación y
Prueba de unidad

Integración y Prueba
del sistema

Operación y
mantenimiento
 Paradigma clásico.
Definición alternativa
INGENIERÍADEL
SISTEMA
ANÁLISIS

DISEÑO

CODIFICACIÓN

PRUEBA

MANTENIMIENTO

Paradigmas de Ciclo de Vida 15

Ventajas
 Introduce disciplina al proceso.
 Pospone la implementación hasta que los objetivos
estén claros.
 Es el paradigma más usado y conocido en la industria
del software.
 Impone puntos de control claros.
 Costo de producción del producto.
 Es un modelo conducido con documentación .
Desventajas
 Los proyectos raramente siguen el flujo secuencial.
 El cliente no puede explicitar inicialmente todos los requisitos
 No existe una versión operativa hasta el final
 Dificultad de hacer cambios entre etapas.
 Alto riesgo en sistemas nuevos debido a problemas en las
especificaciones y en el diseño.
 Bajo riesgo para desarrollos bien comprendidos utilizando
tecnología conocida.
 La dificultad en esta modelo reside, en la dificultad de hacer
cambios entre etapas.
 El cliente debe tener paciencia para ver los resultados.
Ejemplo de aplicación
 Algunas aplicaciones para implementar el modelo
lineal secuencial:
 Problemas medianos / chicos.
 Problemas con requerimientos estables.
 Reingeniería de sistemas.
 Es recomendable cuando los requerimientos están
totalmente comprendidos.
¿ Qué es un prototipo?
 Un prototipo es una representación limitada del
diseño de un producto que permite a las partes
responsables de su creación experimentar su uso,
probarlo en situaciones reales y explorar su uso.
 Un prototipo puede ser cualquier cosa, desde un trozo
de papel con sencillos dibujos a un complejo software.
Modelo de prototipos
 Su principal objetivo es la obtención de
requerimientos y diseño.
 Reducir el riesgo de que la aplicación no se ajuste a las
necesidades del cliente.
 De la revisión de cada etapa se pueden revisar las
etapas anteriores.
Modelo de prototipos
FIN INICIO

Producto de Recolección y
ingeniería refinamiento
de requisitos

Refinamiento del
prototipo Diseño Rápido

Evaluación del Construcción

prototipo del
por el cliente prototipo
Fases del Modelo
1. Recolección y refinamiento de requisitos.
2. Diseño rápido
3. Construcción del prototipo
4. Evaluación del prototipo por el cliente.
5. Refinamiento del prototipo.
6. Producto de Ingeniería
Ventajas
 El prototipo se usa para obtener los requerimientos del
usuario.
 Su principal propósito es obtener y validar los
requerimientos esenciales, manteniendo abiertas las
opciones de implementación. Esto implica que se
deben tomar los comentarios de los usuarios, pero
también se debe volver a los objetivos para no perder la
atención.
 Bajo riesgo para nuevas aplicaciones debido a que las
especificaciones y el diseño se llevan acabo paso a
paso.
Desventajas
 El cliente ve el prototipo y lo confunde con el sistema
real.
 El cliente no entiende la necesidad de volver a hacerlo.
 El equipo de desarrollo toma decisiones rápidas para
poder construir el prototipo , qué mas tarde son
difíciles de revertir (por ejemplo el lenguaje de
programación).
 Alto riesgo debido a falta de visibilidad
Ejemplo de aplicación
 Este modelo de desarrollo es recomendable utilizarlo
cuando se trata con clientes que tienen poca
experiencia en el desarrollo de sistemas de
información que no definen claramente lo que
quieren.
 Es recomendable cuando existen grandes riesgos
técnicos.
DRA
DRA
 Proceso de desarrollo de software que permite
construir sistemas utilizables en poco tiempo,
normalmente de 60 a 90 días, bajo ciertas
restricciones.
 Prevenir presupuestos rebasados
 Prevenir incumplimiento de fechas
 Llegar a un acuerdo temprano entre cliente y
desarrolladores con respecto al SW.
DRA
 Imagen
Fases DRA
 Modelado de Gestión
 Modelado de datos
 Modelado de proceso
 Generación de aplicaciones
 Prueba y entrega
Ventajas
 Velocidad del desarrollo: Los aumentos de la velocidad
son debido al uso de la herramienta CASE.
 Calidad: según lo definido por el RAD, es el grado al
cual un uso entregado resuelve las necesidades de
usuarios así como el grado al cual un sistema
entregado tiene costes de mantenimiento bajos. El
RAD aumenta calidad con la implicación del usuario
en las etapas del análisis y del diseño.
Desventajas
 Características reducidas.
 Escalabilidad reducida: debido a que el RAD se
desarrolló como prototipo.
Ejemplo de aplicación
 Se puede utilizar cuando se desarrolla:
 Una aplicación no crítica.
 Una aplicación independiente.
 Alcance del proyecto limitado.
 Distribución limitada.
 Utilizando bibliotecas preexistentes.
Herramientas RAD
 Microsoft Visual Studio
 NetBeans
 Microsoft Visual Basic
 Clarion
 Oracle
 Coldfusion
Modelo evolutivo
Incremental
 Es un modelo cuyas etapas consisten en incrementos
expandidos de un producto de software operativo,
conducidos por la evolución determinada según la
experiencia operativa.
 Los incrementos se distribuyen a medida que se
complementan.
 Incremento integrado: es una unidad de software
autocontenida que realiza algún propósito útil.
Incremental
Fases Incremental
 Son las mismas que en modelo en cascada.
Ventajas
 Se puede financiar el proyecto por partes.
 Apropiado para proyectos grandes de larga duración.
 No se necesita tanto personal al principio como para
una implementación completa
Desventajas
 Para proyectos grandes requiere recursos humanos
suficientes.
 Los clientes y desarrolladores deben estar
comprometidos en las rápidas actividades.
 Si el sistema no se puede modularizar será
problemático.
 No es adecuado con riesgos técnicos altos.
 Se pueden aumentar los costos debido a pruebas.
Ejemplo de aplicación
 Apropiado para proyectos grandes de larga duración.
Modelo evolutivo
Espiral
 El modelo en espiral trata de mejorar los ciclos de vida clásicos.
 Incorpora objetivos de calidad y gestión de riesgos.
 Permite iteraciones, vuelta atrás y finalizaciones rápidas.
 Cada ciclo empieza identificando:
 Los objetivos de la porción correspondiente
 Las alternativas
 Restricciones
 Cada ciclo se completa con una revisión que incluye todo el ciclo
anterior y el plan para el siguiente.
Espiral
 El modelo combina las actividades del desarrollo con
la gestión de riesgos , para minimizar y controlar el
riesgo.
 Riesgo: circunstancias potencialmente adversas que
pueden perjudicar el proceso de desarrollo y la calidad
de los productos.
 Administración del riesgo: disciplina cuyos objetivos
son manejar y eliminar items del riesgo del software
antes que se transformen en amenaza.
Espiral
 1era Etapa
 Identifica los objetivos de la porción del producto bajo
consideración, en términos de la calidad a lograr.
 Plantear alternativas: comprar, diseñar, reusar y las restricciones a
dichas alternativas.
 2da Etapa
 Se evalúan las alternativas y se identifican las áreas de riesgo
potencial.
 La evaluación del riesgo puede requerir distintas clases de
actividades a ser planificadas (simulación, prototipos)
Espiral
 3era Etapa
 Consiste del desarrollo y verificación del próximo nivel
del producto. El proceso está conducido por el riesgo.
 4ta Etapa
 Se revisan los resultados para planificar la próxima
vuelta en espiral.
Modelo de Proceso de Espiral
Determine objetivos
Evalúe alternativas,
identifique y resuelva
alternativas y riesgos
restricciones Análisis de
Riesgos
Análisis de
Riesgos
Análisis de
Riesgos Prototipo
Prototipo Operacional
Análisis Prototipo 3
de Proto 2
REVISIÓN RiesgosTipo 1
Simulaciones, modelos y benchmarks
Plan de requerimientos Concepto de
Plan del ciclo de vida
Operación Requeri
mientos de Diseño Diseño
SW del Detallado
Plan de Validación de Producto Codificación
Desarrollo Requerimientos
Prueba de
Plan de Integración Diseño Unidades
Prueba de
y Prueba V &V
Planea la Prueba de Integración
Aceptación Desarrolla y verifica
siguiente fase
Servicio el siguiente nivel
del producto
Fases Espiral
 Comunicación con el cliente: Permite establecer comunicación
entre el desarrollador y el cliente.
 Planificación: Para definir los recursos , el tiempo y otras
informaciones relacionadas con el proyecto.
 Análisis de riesgos: Para evaluar riesgos técnicos y operativos.
 Ingeniería: Para construir una o más presentaciones de la
aplicación.
 Construcción y adaptación: Para construir, probar, instalar y
proporcionar soporte al usuario.
 Evaluación del cliente: Para obtener la reacción del cliente según
la evaluación de las representaciones del software.
Ventajas
 El análisis del riesgo se hace de forma explícita y clara.
 Une los mejores elementos de los restantes modelos.
 Reduce riesgos del proyecto.
 Incorpora objetivos de calidad.
 Integra el desarrollo con el mantenimiento.
 Constituye un enfoque realista del desarrollo de sistemas de
software de gran escala. En la medida que progresa cliente y
desarrollador comprenden y manejan mejor los riesgos.
 Considera los riesgos técnicos en todas sus etapas.
Ventajas
 Centra su atención en la reutilización de componentes
y eliminación de errores en información descubierta
en fases iniciales.
 Los objetivos de calidad son el primer objetivo.
 Integra desarrollo con mantenimiento.
 Provee un marco de desarrollo de hardware/software.
Desventajas
 Genera mucho tiempo en el desarrollo del sistema.
 Modelo costoso.
 Requiere experiencia en la identificación de riesgos.
 No existe demasiada experiencia en su uso.
Desventajas
 El desarrollo contractual especifica el modelo del
proceso y los resultados a entregar por adelantado.
 Requiere de experiencia en la identificación de riesgos.
 Requiere refinamiento para uso generalizado.
Modelos recientes
 Técnicas de cuarta generación (T4G)
 Se orientan hacia la posibilidad de especificar el software utilizando formas de lenguaje especializado, o
notaciones gráficas que describan el problema a resolver en los términos que el cliente entienda.
 Las herramientas de 4G facilitan la especificación de algunas características de alto nivel del software;
luego traducen directamente dichas especificaciones a código fuente.
 Un entorno de desarrollo T4G debería tener herramientas como:
 Lenguajes no procedimentales de consulta a bases de datos
 Generación de informes
 Manejo de datos
 Interacción y definición de pantallas
 Generación de códigos con capacidades gráficas de alto nivel
 Capacidades de hoja de cálculo
 Al igual que los modelos anteriores las T4G inician con la recolección de requisitos; idealmente la
descripción de requisitos debería traducirse a un prototipo operativo. Sin embargo es importante hacer
un mayor esfuerzo en la estrategia de diseño para evitar consecuencias como: poca calidad,
mantenimiento pobre y poca aceptación por parte del cliente.
 Se pueden identificar ventajas y desventajas de las T4G
 Ventajas: (1) Reducción drástica del tiempo de desarrollo y (2) Mayor productividad en la gente que construye
el software.
 Desventajas: (1) Las T4G no son más fáciles de utilizar que los lenguajes de programación, (2) El código
fuente producido generalmente es ineficiente y (3) El mantenimiento es cuestionable

CUIDADO Cliente RECOMENDADO T4G

Cliente T4G
Traducción Traducción
Descripción Directa Descripción Directa
Prototipo Diseño en Prototipo
de de
Operativo Términos T4G Operativo
Requisitos Requisitos
Modelos recientes … (2)
 Desarrollo basado en componentes
 Incorpora muchas características del modelo espiral.
 Configura aplicaciones desde componentes preparados de software (clases).
 Conduce a la reutilización del software.

Identificar
componentes
Análisis candidatos
Planificación
de riesgos

Construir Buscar
la Iteración componentes en
del sistema la biblioteca
Comunicación
con el cliente
Poner nuevos Extraer
componentes en componentes
la biblioteca si están
disponibles

Extraer
componentes
Evaluación si no están
del cliente disponibles
Construcción y
adaptación de la ingeniería
Modelos

recientes… (4)
Programación extrema XP
 Disciplina de desarrollo de software creada por Kent Beck para proyectos cortos con requerimientos
cambiantes o poco claros (respaldada por gran parte de la industria y rechazada por otro tanto).
 Se basa en la simplicidad, la comunicación y el reciclado continúo de código.
 Pretende:
 La satisfacción del cliente
 Potenciar al máximo el trabajo en grupo
 Reducir el costo del cambio en las etapas de vida del sistema
 Combinar las que han demostrado ser las mejores practicas de desarrollo de software y llevarlas al
extremo.
 Establece cuatro variables
 Coste
 Tiempo
 Calidad
 Ámbito
 Plantea cuatro valores
 Comunicación
 Sencillez
 Retroalimentación
 Valentía
 Define cuatro actividades básicas
 Codificar
 Hacer pruebas
 Escuchar
 Diseñar
Metodologías estructuradas
 Pasan de una visión general del problema (abstracción cercana a las
personas) hasta llegar a un nivel de abstracción más sencillo (abstracción
cercana al hardware).
 Esta visión se puede enfocar en las funciones del sistema, estructura de los
datos o ambos, lo que da lugar a las siguientes metodologías:
 Orientadas a los procesos
 Se centra en la transformación de los datos de entrada para generar la salida
esperada.
 Orientadas a los datos
 Estructuras de datos jerárquicas
 Se centran en las entradas y salidas; primero se definen las estructuras de datos y, a partir
de éstas, se derivan los componentes procedimentales.
 Estructuras de datos no jerárquicas
 Los tipos de datos son el corazón del sistema ya que son más estables que los procesos.
 Mixtas
 Se enfocan tanto en el proceso como en los datos tomando desde diversos puntos
de vista.
Metodologías

estructuradas … (2)
Existen diversas metodologías estructuradas:
 Orientadas a procesos:
 De Marco.
 Gane y Sarson
 Yourdon/Constantine
 Orientadas a datos jerárquicos
 JSP y JSD
 LCP
 Orientadas a datos no jerárquicos
 IE
 Metodologías mixtas
 Merise
 SSADM
 Métrica
 Las especificaciones estructuradas utilizan:
 DFD (Diagramas de flujo de datos, Dataflow Diagram)
 Diagramas E-R (Entidad-Relación), o alternativamente DED (Diagramas de Estructura de Datos)
 Diagramas HVE (Historia de vida de las entidades)
 Diagramas de transición de estados (STD, State Transition Diagram)
 Diccionario de datos
 Especificación de procesos
 Lenguaje estructurado
 Pre y post condiciones
 Tablas y árboles de decisión
 Diagramas de estructura
Metodologías orientadas a
objetos
 De forma general:
 El dominio del problema se caracteriza mediante un conjunto de objetos con
atributos y comportamientos específicos.
 Los objetos son manipulados mediante una colección de métodos y se
comunican mediante un protocolo de mensaje.
 Los objetos son clasificados en clases y subclases.
 Se retoman muchas de las ideas de las metodologías estructuradas pero
con el apoyo de lenguajes orientados a objetos.
 En los 90’s había diversos enfoques orientados a objetos:
 Booch
 Rumbaugh
 Jacobson
 Otros más (Shaler y Mellor, Coleman)
 En el 95 comienza el método unificado (Booch, Rumbaugh).
 El mismo año se une Jacobson
 Nace Rational Rose
 De ahí surge UML aceptado por el OMG
(Object Management Group) en el 97
Metodologías orientadas a objetos … (2)
 Actualmente las especificaciones orientadas a objetos utilizan el lenguaje estándar
predominante UML (Unified Modeling Lenguage) el cual combina notaciones
provenientes desde:
 Modelado orientado a objetos
 Modelado de datos
 Modelado de componentes
 Modelado de flujos de trabajo (workflows)
 Los diagramas que expresan gráficamente las partes de un modelo son:
PUDS

60
El proceso unificado de desarrollo de
software
• Es un proceso ORIENTADO A OBJETOS
• El proceso es:
• Guiado por casos de uso
• Centrado en la arquitectura
• Con un ciclo de vida iterativo e incremental

PARTE
DINÁMICA

CICLO Debe ofrecer un

marco de trabajo INTERFAZ
DE VIDA
genérico

PARTE
ESTÁTICA 61
El proceso unificado de
desarrollo de software
• El Proceso Unificado de Desarrollo
usa UML
UML Notación

Herramientas Proceso

• RATIONAL ROSE
PROCESO UNIFICADO DE
• VISIO DESARROLLO DE RATIONAL

62
1. Guiado por
casos de uso
 Los sistemas se crean para dar servicio
a los usuarios.
 Qué REQUISITOS se necesitan
 Un CASO de USO es una pieza de
FUNCIONALIDAD de un sistema que le
proporciona a algún USUARIO un
RESULTADO o VALOR.

63
Casos de uso
Todos juntos constituyen el
modelo de casos de uso
(MCU)

FUNCIONALIDAD COMPLETA

PARA TODOS LOS USUARIOS

64
 EJEMPLO DE
MODELO DE
Consultar Catálogo
CASOS DE USO
<<includes>>

Actualizar Catálogo

Persona Reservar Libro

EncargadoBiblio
<<extends>>

Tomar Préstamo Copia

Libro
- No disponible

<<extends>> Tomar Préstamo

Revista

Extender Préstamo
- No reservado

Socio Devolver Revista

TrabajadorBiblio
Devolver Copia Libro

65
Desarrollo guiado por casos de uso
(CU)
LOS CASOS DE USO:
CAPTURAN REQUISITOS
SE ESPECIFICAN (ANALIZAN)
SE DISEÑAN
SE IMPLEMENTAN
Y SE PRUEBAN
66
 Tomar Préstamo 1.- CASO DE USO Desarrollo guiado
por CASOS DE
USO
Persona

2.- ANÁLISIS DEL

CASO DE USO

: IU-1 : GestorLibro : Libro elLibro:Libro

1: Introducir Signatura y NumeroDeSocio

Se repite hasta que se
2: Aceptar encuentre un libro
con la signatura que
3.- DISEÑO DEL 3: obtenerLibro(signaturaLibro:String) estamos buscando

4: getSignatura()
CASO DE USO elLibro

5: getCopias()

6: isCopiaPrestada()

4.- IMPLEMENTACIÓN DEL CASO DE USO

5.- PRUEBA DEL CASO DE USO 67
2. Centrado en la arquitectura
La arquitectura de un sistema
software es un extracto de los
modelos del sistema
 Extracto: VISTA DE CADA MODELO
que da una idea de qué forma que
tiene el sistema completo

68
 Centrado en la
ARQUITECTURA
1

VISTA DEL MODELO DE CASOS VISTA

DE USODEL MODELO DEL DOMINIO /
VISTA DEL DIAGRAMA DE CLASES

: IU-1 : : : : :
2: 1: 3: G 2: 1: 3: G
r 4 r 4
() ()
o o

VISTA DEL MODELO DEL ANÁLISIS

VISTA DEL MODELO DEL DISEÑO
+ VISTAS DEL MODELO DE IMPLEMENTACIÓN Y PRUEBAS

SON VISTAS DE LOS MODELOS (NO MODELOS COMPLETOS).

SÓLO APARECEN LOS QUE CORRESPONDEN
A CASOS DE USOS CRÍTICOS
69
3. Ciclo de vida iterativo e
incremental
ITERATIVO
Se repiten VARIOS
MINIPROYECTOS
INCREMENTAL
Cada miniproyecto AMPLIA EL
PRODUCTO
70
 El CV del proceso unificado
 UN CICLO DE VIDA SE REPITE A LO
LARGO DEL TIEMPO
 TRAS CADA CICLO DE VIDA 
VERSIÓN NUEVA DEL PRODUCTO
 UN CICLO DE VIDA SE DIVIDE EN
FASES
 CADA FASE SE DIVIDE EN
ITERACIONES
 EN CADA ITERACIÓN SE REALIZAN
FLUJOS DE TRABAJO
71
El CV del proceso unificado
Flujos de
trabajo:
Fases
Actividades
Inicio Elaboración Construcción Transición

Requisitos

Análisis

Diseño

Implementación

Prueba

ite r. ite r. ite r. ite r. ite r. ite r. ite r.

Iteraciones: #1 #2 #n # n+ 1 # n+2 #m #m +1
72
El CV del proceso unificado
Versiones del producto
EN CONSTRUCCIÓN

Iniciación Elaboración construcciónPrdct Producto

Iniciación transición
iteración #1 iteración #2 fnll
lll iteración #n-1
iteración #3 final
iteración #n-1

Iniciación Elaboración Construcción Transición

NUEVA VERSIÓN DEL PRODUCTO (en este CV)

73
El producto
(del proceso unificado)

NO ES SÓLO CÓDIGO

EJECUTABLE
SON LOS MODELOS O
REPRESENTACIÓN DEL
SOFTWARE
DEBE AJUSTARSE A TODAS LAS
PERSONAS IMPLICADAS

74
Fases dentro del CV del proceso
unificado
FASE: PARTE DE UN CV
CADA FASE TERMINA EN UN
HITO
 HAY ARTEFACTOS DISPONIBLES
(SEGÚN LO PLANIFICADO)
 LOS RESULTADOS EN LOS HITOS
PERMITEN GESTIONAR
75
 Fases dentro del CV del
proceso unificado
• INICIACIÓN:
– DESCRIBIR PRODUCTO FINAL / ANÁLISIS DEL NEGOCIO
– IDENTIFICAR RIESGOS MÁS IMPORTANTES
– ESTABLECER PLANIFICACIÓN INICIAL DEL PROYECTO
– DECIDIR SI SE CONTINÚA
• ELABORACIÓN:
– ESTABLECER PLAN Y ARQUITECTURA ESTABLE
• CONSTRUCCIÓN: DESARROLLAR EL PRODUCTO
• TRANSICION: PROPORCIONAR SISTEMA A USUARIOS

76
 Iteraciones
 CADA FASE SE DIVIDE EN ITERACIONES
 CADA ITERACIÓN
 MINIPROYECTO (EN CASCADA) QUE EJECUTA
FLUJOS DE TRABAJO
 PRODUCE UN INCREMENTO EN PRODUCTO
 TAL Y COMO ESTABA
 SE REDUCE EL RIESGO
 SE PUEDE PERDER SÓLO LO REALIZADO EN ESA
ITERACIÓN

77
 Iteraciones
Como se puede ver, el Proceso
Unificado de Desarrollo
incluye actividades
ITERACIÓN correspondientes a un Proceso
de Gestión de Proyectos

PLANIFICACIÓN DE EVALUACIÓN DE LA
LA ITERACIÓN ITERACIÓN

REQUISITOS ANÁLISIS DISEÑO IMPLEMENTACIÓN PRUEBAS

ACTIVIDADES DE LOS FLUJOS DE TRABAJO FUNDAMENTALES

78
Flujos de trabajo
 CAPTURA DE REQUISITOS:
 IDENTIFICAR REQUISITOS DEL
SISTEMA
 CONSTRUIR UN MODELO DEL MISMO
 MODELO DE CASOS DE USO
 MODELO DEL DOMINIO (o NEGOCIO)

 ANÁLISIS:
 ESPECIFICAR REQUISITOS
 CONSTRUIR MODELO DEL ANÁLISIS
79
 Flujos de trabajo
• DISEÑO:
– ENCONTRAR LA FORMA DEL SISTEMA
(SOLUCIÓN)
– CONSTRUIR MODELO DEL DISEÑO
• IMPLEMENTACIÓN:
– CODIFICAR EL DISEÑO (SOLUCIÓN)
– CONSTRUIR MODELO DE IMPLEMENTACIÓN
• PRUEBAS:
– VERIFICAR LA IMPLEMENTACIÓN
– CONSTRUIR MODELO DE PRUEBAS

80
ANEXO
Fases: Iniciación
Establecer la planificación del proyecto
 ¿Qué va a hacer el sistema para cada uno de sus usuarios
principales?
 Un MCU simplificado con los CU más críticos
 ¿Cómo sería la arquitectura para un sistema como ese?
 Borrador con los subsistemas principales
 ¿Cuál es el plan y cuánto va a costar desarrollar el producto?
 Identificar los riesgos principales y priorizarlos, planificar
elaboración y presupuesto aproximado

81
ANEXO
Fases: Elaboración
Establecer un plan para el proyecto y una arquitectura correcta
 Especificar en detalle los CU + críticos
 Diseñar la arquitectura
 Mediante vistas de todos los modelos del SI
 Vista arquitectónica de MCU, M. Análisis, M. Diseño, M.
Implementación (con los componentes que demuestran que la
arquitectura es ejecutable) y M. Distribución.
 Al final de esta fase se debe poder planificar las
actividades y estimar los recursos para poder completar
el proyecto. ¿Son los CU, arquitectura y planes lo
suficientemente estables y los riesgos bajo control
suficiente para firmar un contrato para terminar el
trabajo de desarrollo?

82
ANEXO
Fases: Construcción
Desarrollar el sistema
 Se construye el producto. En esta fase:
 La arquitectura se completa para construir un sistema bien
cimentado
 La visión evoluciona hasta convertirse en un producto
preparado para los usuarios
 Es donde se gastan la mayoría de los recursos
 La arquitectura del sistema es estable. Sin embargo, se
pueden realizar cambios mínimos a la misma.
 ¿El producto se ajusta suficientemente a las necesidades de
los usuarios de algunos usuarios como para enviarselo ya?

83
ANEXO
Fases: Transición
Proporcionar el sistema a los usuarios finales
 El producto se encuentra en fase beta
 Un grupo reducido de usuarios experimentados prueba el
producto e informa de los defectos y deficiencias y
sugieren mejoras.
 Los desarrolladores corrigen las deficiencias e incorporan
algunas de las mejoras propuestas en una versión para un
grupo de usuarios mayor.
 En esta fase se encuentran actividades como la venta,
formación de los usuarios, ofrecimiento de ayuda en línea
y corrección de defectos descubiertos tras la
implantación. Los defectos: (1) los que justifican la
aparición de una nueva versión del sistema, (2) los que se
pueden dejar para la siguiente versión que se cree.

84