Ingeniería en Sistemas de

Información
Diseño de Sistemas de Información
 Contenidos de la Unidad I
Diseño y Metodologías de Desarrollo

SEM Temas TEMAS A DESARROLLAR Bibliografía

4 i Proceso Unificado Larman
2ª. Edición
Cap. 2 (págs.
13/26)
 i - Proceso Unificado

 “Las personas son más importantes que cualquier

proceso”.
 “Buenas personas con un buen proceso siempre actuarán
mejor que buenas personas sin procesos”. Grady Booch.
 Proceso de desarrollo de software => describe un
enfoque para construir, desarrollar y mantener software.
 Proceso Unificado => proceso iterativo para proyectos
que usan Análisis / Diseño Orientado a Objetos (A/DOO).
 Desarrollo iterativo => enfoque para el desarrollo de
software => requiere entrenamiento y conocimientos.
 i - Proceso Unificado

 Proceso Unificado [JBR99] => proceso de desarrollo de

software exitoso para construir sistemas orientados a
objetos.
 => fomenta muchas buenas prácticas => la más destacada
=> desarrollo iterativo.
 => el desarrollo se organiza en una serie de mini-proyectos
cortos, de duración fija (4 semanas) llamados iteraciones.
 Resultado de cada iteración => un sistema que puede ser
probado, integrado y ejecutado.
 Cada iteración => incluye sus propias actividades de
análisis, diseño, implementación y pruebas.
 i - Proceso Unificado

 El ciclo de vida iterativo => ampliación y

refinamiento sucesivos del sistema mediante
múltiples iteraciones, que convergen hacia un
sistema adecuado.
 El sistema crece incrementalmente en el
tiempo, iteración tras iteración => enfoque
también llamado “Desarrollo iterativo e
incremental” (Figura siguiente).
i - Proceso Unificado
 i - Proceso Unificado

 Ejemplo => iteración de 2 semanas => Lunes => clarificar tareas y

requisitos de la iteración, hacer ingeniería inversa => pasar el
código de la última iteración a diagramas UML (con CASE),
imprimir y mostrar diagramas interesantes.
 Martes => diseño por parejas en pizarras => dibujar diagramas
UML, escribir pseudocódigo y notas de diseño.
 8 días restantes => implementar, probar, ampliar diseño,
integrar, pruebas de sistema.
 Otras actividades => presentaciones y evaluaciones con el
personal involucrado en el proyecto (stakeholders), y planificar
la siguiente iteración.
 i - Proceso Unificado

 No hay prisa por codificar.

 Hay que perfeccionar todos los detalles del diseño antes de
programar.
 => diseño con modelado basado en diagramas, utilizando
dibujos UML realizados con rapidez y a grandes rasgos =>
desarrolladores pueden dedicar un día entero, a diseñar en
parejas.
 Resultado de cada iteración => sistema ejecutable e incompleto
=> no preparado para ser puesto en producción.
 => El sistema podría no estar listo para su puesta en producción
hasta después de muchas iteraciones (10 ó 15).
 i - Proceso Unificado

 Salida de cada iteración => subconjunto con calidad de

sistema final => NO un prototipo experimental o desechable.
 Cada iteración => aborda nuevos requisitos y amplía el
sistema incrementalmente.
 Una iteración => podría volver sobre software que ya existe y
mejorarlo => una iteración podría mejorar el rendimiento de
un subsistema, en lugar de extenderlo con nuevas
características.
 => No luchar contra el inevitable cambio que ocurre en el
desarrollo de software.
 Aceptar el Cambio => aptitud clave del desarrollo iterativo.
 i - Proceso Unificado

 => No es agregar “características” de forma incontrolada.

 Cada iteración => elección de un pequeño conjunto de
requisitos y, rápidamente, diseñar, implementar y probar.
 En las primeras iteraciones, la elección de los requisitos y el
diseño podrían no ser exactamente lo que se desea al final.
 La retroalimentación temprana es valiosa.
 Los usuarios pueden ver rápidamente una parte del sistema y
decir => “Sí, es lo que pedí, pero ahora que lo pruebo, lo que
realmente quiero es distinto”
 Este “si… pero” no es una falla => sino una forma de descubrir
qué tiene valor real para el personal involucrado.
 i - Proceso Unificado

 Además de clarificar los requisitos, esta retroalimentación

probará si el diseño y la implementación parcial van en
camino correcto, o si en la siguiente iteración se necesita un
cambio.
 Cuanto antes se resuelvan y prueben decisiones de diseño
críticas y arriesgadas, mejor => gracias al desarrollo iterativo.
 => el trabajo se desarrolla en una serie de ciclos
estructurados de construir-retroalimentar-adaptar.
 => la desviación del sistema del “verdadero camino” en las
primeras iteraciones será mayor que en las últimas.
 En el tiempo, el sistema converge hacia este camino.
i - Proceso Unificado
 i - Proceso Unificado

Beneficios del desarrollo iterativo:

 Pronta Mitigación de riesgos altos.
 Progreso visible en las primeras etapas.
 Temprana retroalimentación => compromiso de los usuarios =>
sistema refinado que se ajusta más a sus necesidades.
 Gestión de la complejidad => el equipo no se ve abrumado por
pasos muy largos y complejos.
 El conocimiento adquirido en una iteración se utiliza para
mejorar el desarrollo, iteración a iteración.
 i - Proceso Unificado

Duración de las iteraciones

 De 2 a 6 semanas.
 Pasos pequeños, rápida retroalimentación, y adaptación.
 Iteraciones largas destruyen el propósito del desarrollo
iterativo e incrementan el riesgo del proyecto.
 Menos de 2 semanas => difícil completar el trabajo para
obtener resultados significativos y retroalimentación.
 Más de 6 u 8 semanas => la complejidad se hace
abrumadora, y se retrasa la retroalimentación.
 Lo corto es bueno.
 i - Proceso Unificado

 El sistema parcial debería integrarse, probarse y

estabilizarse en la fecha planificada => los retrasos son
frustrantes.
 Si parece difícil cumplir con el plazo fijado => eliminar tareas
o requisitos de la iteración, e incluirlos en una iteración
posterior => no retrasar la fecha de terminación prevista.
 Equipos muy grandes (de cientos de desarrolladores)
podrían requerir iteraciones de más de 6 semanas para
compensar los costos de coordinación y comunicación =>
pero no se recomiendan más de 3 a 6 semanas.
 i - Proceso Unificado

2 Ideas fundamentales en UP:

 1°) Desarrollo iterativo => iteraciones cortas, y adaptables.
 2°) Uso de tecnologías de objetos => A/DOO y Programación
Orientada a Objetos.
Conceptos claves y buenas prácticas del UP =>
 Abordar cuestiones de alto riesgo y muy valiosas en las primeras
iteraciones.
 Involucrar continuamente a los usuarios para evaluación,
retroalimentación y requisitos
 Construir en las primeras iteraciones una arquitectura que
constituya un núcleo central consistente.
 i - Proceso Unificado

Las fases del UP

 UP organiza el trabajo e iteraciones en 4 fases fundamentales:
 1. Inicio => visión aproximada, análisis del negocio, alcance,
estimaciones imprecisas.
 2. Elaboración => visión refinada, implementación iterativa del
núcleo central de la arquitectura, resolución de los riesgos altos,
identificación de más requisitos.
 3. Construcción => implementación iterativa del resto de
requisitos de menor riesgo y elementos más fáciles, preparación
para el despliegue.
 4. Transición => pruebas beta, despliegue.
 i - Proceso Unificado

 => no se corresponde con el ciclo de vida “en cascada” =>

primero se definen todos los requisitos y, después, se
diseña.

 Fase de Inicio => no es de requisitos => sino de viabilidad =>

estudio para decidir si continuar o no.
 Fase de Elaboración => no es de requisitos ni de diseño =>
se implementa, de forma iterativa, la arquitectura - núcleo
central y se mitigan cuestiones de alto riesgo.
i - Proceso Unificado
 i - Proceso Unificado

Disciplinas del UP
 Disciplina => conjunto de actividades (y artefactos
relacionados) en un área determinada.
 Artefacto => cualquier producto del trabajo: código,
gráficos, esquema de base de datos, documentos,
diagramas, modelos, etc.

3 Disciplinas en UP que interesan en Diseño:

 Modelado del Negocio => Al desarrollar una aplicación =>
Modelamos los objetos del dominio.
 Consiste en el modelado de procesos de negocio de toda
la empresa.
 i - Proceso Unificado

 Requisitos => Análisis de requisitos para una aplicación =>

casos de uso y requisitos no funcionales.

 Diseño => incluye arquitectura global, objetos, bases de

datos, red, etc.

 Implementación otra disciplina siguiente al Diseño =>

programar y construir el sistema.

 Como se ilustra en la Figura siguiente, el esfuerzo en cada

disciplina cambia a lo largo del tiempo.
 i - Proceso Unificado

 En las primeras iteraciones => se aplica esfuerzo mayor a

requisitos y al diseño, y en las posteriores disminuye, cuando
requisitos y diseño central se estabilizan.
 i - Proceso Unificado

Disciplinas y fases
 Relacionando Disciplinas con las fases del UP
(inicio, elaboración…), la Figura siguiente
muestra cómo cambia el esfuerzo relativo en
cada fase.
 En elaboración => las iteraciones tienen alto
trabajo de requisitos y diseño, y algo de
implementación.
 En la construcción => más importancia a la
implementación y menos al análisis de
requisitos.
i - Proceso Unificado
 i - Proceso Unificado

Marco de Desarrollo
 La elección de los artefactos de UP para un proyecto se vuelca
en un documento breve => Marco de Desarrollo => la Tabla
siguiente => describe los artefactos para un caso de estudio.
 i - Proceso Unificado

UP ágil
 Consiste en aplicar el espíritu de un proceso ágil en UP.
 Opte por un conjunto pequeño de actividades y artefactos
del UP => manténgalo simple.
 No hay un plan detallado para todo el proyecto => Hay un
plan de alto nivel (Plan de Fase) => estima fecha de
terminación del proyecto y otros hitos importantes, pero no
detalles.
 La planificación detallada se lleva a cabo, de manera
adaptable, de iteración en iteración.
 Use pocos artefactos (sólo los que va a necesitar) y mucho
desarrollo iterativo.
 i - Proceso Unificado

No se entendió UP cuando…

 Se piensa que inicio = requisitos, elaboración = diseño, y

construcción = implementación.
 Se piensa que el objetivo de la elaboración es definir
modelos de manera completa y cuidadosa => que se
traducen a código durante la construcción.
 Se intenta definir la mayoría de los requisitos antes de
comenzar el diseño o la implementación.
 Se intenta definir la mayoría del diseño antes de
comenzar a implementar.
 i - Proceso Unificado

 Se intenta definir toda una arquitectura antes de

programar y probar iterativamente.
 Se dedica mucho tiempo a trabajar sobre requisitos y
diseño antes de comenzar a programar.
 Se cree que una iteración adecuada es de 4 meses, en
vez de 4 semanas.
 Se piensa que realizar diagramas UML y actividades de
diseño es definir diseños y modelos de manera
completa y precisa con gran detalle.
 i - Proceso Unificado

 Se piensa que adoptar el UP significa crear muchos

documentos.
 Se piensa a UP como un proceso formal y exigente con
muchos pasos que seguir.
 Se intenta planificar un proyecto en detalle desde el
principio hasta el final; intenta predecir todas las
iteraciones y lo que debería ocurrir en cada una.
 ¡MUCHAS GRACIAS!
Hasta la Próxima Clase