proceso unificado
TRANSCRIPT
IIE Instituto de Ingeniería Eléctrica.DesaSoft Desarrollo de Software para Ingeniería Eléctrica.Guías de clase. Parte II: Ingeniería de Software.
El Proceso Unificado (UP).
Índice de contenido
El Proceso Unificado (UP).................................................................................................................1Incrementos e iteraciones........................................................................................................1Características del UP..............................................................................................................2Disciplinas y artefactos............................................................................................................3Fases del UP............................................................................................................................3Marco de desarrollo del UP.....................................................................................................3Plan, fases, artefactos, disciplinas............................................................................................3Otras herramientas del UP.......................................................................................................5
Especificación Complementaria......................................................................................5Visión y Análisis del Negocio..........................................................................................6Glosario..........................................................................................................................6
UP: fase Inicio.........................................................................................................................6UP: fase Elaboración................................................................................................................7Referencias y lecturas recomendadas.......................................................................................8
Lecturas recomendadas..................................................................................................8Referencias.....................................................................................................................8
El Proceso Unificado (UP, “Unified Process”) combina prácticas comúnmente aceptadas como "buenas prácticas", tales como el ciclo de vida iterativo y desarrollo dirigido por el riesgo, en una descripción consistente y bien documentada.
Un proceso es orientado por el riesgo cuando intenta identificar y definir estrategias para enfrentar los riesgos más graves del proyecto, resolviendo primero los puntos más difíciles, elaborando planes de contingencia y tratando de anticipar las dificultades.
Incrementos e iteraciones.
Los llamados ciclos por fases intentan poner en manos del usuario un sistema con prestaciones parciales, que se va completando con nuevas prestaciones en fases sucesivas. Así, el usuario tiene en producción algunas funcionalidades mientras se van desarrollando las otras. Existen entonces al menos dos sistemas funcionando en paralelo:
• el sistema operacional o sistema en producción, en uso por el cliente. Puede ser una implementación parcial, una implementación anterior con funcionalidades nuevas o sustituidas, una implementación nueva con partes de la anterior u otra variante coherente.
• el sistema en desarrollo, la siguiente versión, que está siendo preparada para reemplazar la versión en producción, que puede aún conservar partes de implementaciones anteriores o faltarle funcionalidades.
El desarrollo incremental genera versiones comenzando con un subsistema funcional pequeño, al cual se le va agregando funcionalidad con cada versión. El desarrollo iterativo entrega un sistema completo desde el principio, y luego cambia la funcionalidad de algún subsistema en cada nueva versión. Ambos enfoques pueden combinarse en un desarrollo iterativo e incremental.
1 de 8
Desarrollo incremental y desarrollo iterativo
Características del UP.
• desarrollo iterativo e incremental: el proyecto se organiza en una serie de miniproyectos cortos de duración fija (2 a 6 semanas) llamadas iteraciones, que elige un conjunto reducido de requerimientos, los diseña, implementa y prueba. El resultado de cada iteración es un sistema que puede ser probado, integrado y ejecutado. La salida es un subconjunto con calidad de producción final.
• rápida retroalimentación y asimilación de los cambios, posibilitada por el tamaño limitado de lo realizado en cada iteración.
• se abordan, resuelven y prueban primeramente las decisiones de diseño críticas o de alto riesgo.
• si no se logra cumplir lo previsto dentro del plazo estipulado, se aconseja transferir tareas o requisitos para una iteración posterior, pero no modificar la fecha de entrega de la iteración actual.
Desarrollo iterativo e incremental en el UP
2 de 8
Disciplinas y artefactos.
El UP se organiza en disciplinas o flujos de trabajo. Un flujo de trabajo o disciplina (en el sentido del UP) es un conjunto de actividades realizadas en un área determinada. Las actividades producen artefactos. Un artefacto es un término general empleado para referirse a cualquier resultado del trabajo, ya sea un texto, un diagrama, una página web, código en lenguaje de programación u otros.
Fases del UP.
1. Inicio: visión aproximada, análisis del quehacer de la empresa cliente ("el negocio"), alcance del proyecto, estimaciones (imprecisas) de plazos y costos. Se define la viabilidad del proyecto.
2. Elaboración: visión refinada, implementación iterativa del núcleo central de la aplicación, resolución de los riesgos más altos, identificación de nuevos requisitos y nuevos alcances, estimaciones más ajustadas.
3. Construcción: implementación iterativa del resto de los requisitos de menor riesgo y elementos más sencillos, preparación para el despliegue (entrega, instalación y configuración).
4. Transición: pruebas beta, despliegue.
Marco de desarrollo del UP.
El cuadro siguiente resume las disciplinas del UP y sus artefactos asociados, indicando también, para las siguientes fases, el grado aproximado de desarrollo de cada uno de estos artefactos.
c: comienzo de la construcción del artefacto.r: refinamiento del artefacto (ampliación, corrección).
Componentes del UP Fases del UP
Disciplina ArtefactoIteraciones:
InicioI1
ElaboraciónE1...En
ConstrucciónC1...Cn
TransiciónT1...Tn
Modelado del negocio Modelo del dominio c
Requerimientos Modelo de Casos de UsoVisión y Análisis del NegocioEspecificación ComplementariaGlosario
cccc
rrrr
Diseño Modelo de DiseñoDocumento de ArquitecturaModelo de Datos
ccc
r
r
Implementación Modelo de implementación c r r
Gestión del proyecto Plan de desarrollo c r r r
Pruebas Modelo de Pruebas c r
Entorno Marco de desarrollo c r
No todos los proyectos requieren todos los artefactos, ni con igual grado de profundidad o detalle. Los artefactos son opcionales, y se recomienda usar pocos artefactos, eligiendo los de mayor valor práctico para cada proyecto.
3 de 8
Plan, fases, artefactos, disciplinas.
En el UP (“Unified Process”, proceso unificado) de desarrollo de software, se reconocen las fases de Inicio, Elaboración, Construcción y Transición, en cada una de las cuales se cumplen una o más iteraciones. El desarrollo es iterativo e incremental; en cada iteración se agrega algo más, y el sistema está en continuo crecimiento hasta su entrega. En cada iteración hay análisis de requerimientos, diseño, implementación y verificación, así como puesta a punto y coordinación de todos los artefactos.
La figura siguiente muestra la relación entre los distintos artefactos y su aplicación en las distintas disciplinas reconocidas en el UP. Las flechas indican algunos aportes significativos de unos artefactos hacia otros.
UP: Fases, Hitos, Planes de Fase y Planes de Iteración.
Iteraciones: períodos de trabajo con objetivos, tareas y entregables.Fases: las etapas del proceso unificado.Hitos: instantes donde se entrega algo o se controla el avance del proyecto.Plan de Fase: objetivos, estimación de fechas, hitos, entregables.Plan de Iteración: objetivos, tareas, entregables; en detalle para la presente iteración.
• El texto de los Casos de Uso sugiere términos, conceptos, atributos y asociaciones en el Modelo de Dominio.
• El Modelo de Dominio sugiere nombres de las clases, asociaciones y atributos del Diagrama de Clases de Diseño.
• Los Contratos de Operaciones describen los cambios de estado en el Modelo de Dominio; los cambio se producen en los objetos (creación, destrucción), sus atributos y sus asociaciones. Los Contratos de Operaciones se hacen, opcionalmente, para las operaciones descritas en el Diagrama de Secuencia del Sistema particularmente críticas o difíciles de entender.
• Algunos de los términos del Modelo de Dominio se aclaran o elaboran en el Glosario. • Los Diagramas de Interacción (Colaboración o Secuencia) y los Diagramas de Clases de
Diseño permiten a los programadores implementar los componentes de software y las Pruebas de verificación.
4 de 8
Artefactos en las diferentes disciplinas del UP
Otras herramientas del UP.
Especificación Complementaria.
La Especificación Complementaria reúne requerimientos, restricciones e información que resulta difícil reflejar en los Casos de Uso o en el Glosario. Si bien los requerimientos propios de un Caso de Uso deben figurar en él en la sección Requerimientos Especiales, algunos desarrolladores prefieren reunirlos además en este documento, como manera de tenerlos en cuenta globalmente.La Especificación Complementaria comprende elementos tales como:
• requerimientos especiales de funcionalidad, confiabilidad, rendimiento, soporte. • informes. • restricciones de software y hardware (plataformas, sistema operativo, red, ...). • restricciones de desarrollo (herramientas a emplear, procedimientos).
5 de 8
• otras restricciones de diseño e implementación. • internacionalización (caracteres, moneda, unidades de medida, ...). • exigencias de documentación (usuario, administrador, instalación, ayuda, ...). • licencias, restricciones legales. • empaquetado (“packaging”), la forma física en que se entrega. • normas (técnicas, de seguridad, de calidad, ...). • ambiente físico (calor, humedad, luz, vibraciones, interferencia electromagnética, ...). • aspectos operacionales (respaldos, restauración, gestión de errores...). • reglas de la empresa, restricciones y comportamientos, el modo de trabajo del cliente. • información complementaria de interés (cómo se gestionan las compras a crédito, ...).
Visión y Análisis del Negocio.
La Visión y Análisis del Negocio (o Visión) es un documento donde se describe la totalidad del sistema de manera general pero suficiente para servir como contrato formal o informal entre el cliente y el desarrollador. Muestra los problemas y objetivos a más alto nivel que los Casos de Uso, enfatiza la globalidad.
Algunas características propias del documento de Visión son:• contiene una descripción del problema concisa, precisa, entendible por todos los
involucrados. • muestra objetivos funcionales y no funcionales considerados importantes, que pueden
corresponder a varios casos de uso. • se expresa como características del sistema, sentencias concisas, de alto nivel, que resumen
las funciones y restricciones del sistema. • usa no más de 2 niveles descriptivos; no puede tener un nivel de detalle excesivo.
El documento de Visión presenta el peligro de una duplicación inútil: no debe repetir los Casos de Uso, sino resumirlos en un documento único, con énfasis en el panorama global por contraposición a la visión más detallada de los casos de uso.
Glosario.
El Glosario es una lista de los términos relevantes y sus definiciones. Tiene como propósito evitar interpretaciones dispares o ambiguas de términos técnicos o propios del dominio del problema. No reúne todos los términos, sólo aquellos donde se entiende necesario dar una definición precisa. Puede incluir términos compuestos o expresiones de uso habitual, no sólo palabras aisladas (términos atómicos). Por ejemplo, "autorización de pago" puede contener varios elementos distintos.
El Glosario es un antecedente del Diccionario de Datos, un documento de elaboración posterior donde los términos no sólo de definen sino que se caracterizan con atributos tales como alias, formato (tipo, largo, unidad), relaciones con otro términos. El Diccionario de Datos se confecciona típicamente en la fase de Elaboración.
UP: fase Inicio.
En el Proceso Unificado (UP), el propósito de la fase Inicio es establecer una vista general de los objetivos del proyecto, determinar si es viable y decidir si se continuará el proyecto. Si es así, se realizarán investigaciones más profundas del problema en la fase de Elaboración. La fase Inicio podría ser muy breve si se trata de un problema conocido, o se ha decidido realizar el proyecto de todas formas.
La tabla siguiente muestra los artefactos típicos de la fase Inicio. Siguiendo los principios del desarrollo iterativo, estos artefactos se trabajan sólo parcialmente en esta etapa, apenas lo necesario para cumplir el objetivo de esta fase: entender lo suficiente el problema como para decidir su viabilidad. Recordemos una vez más que los artefactos son opcionales, su utilidad depende del problema, y también que es mejor restringirse a unos pocos artefactos útiles en la
6 de 8
práctica.
UP: fase InicioArtefacto Descripción, propósito
Visión y Análisis del Negocio
Describe objetivos, funcionalidades y restricciones en forma concisa (de alto nivel); es un resumen del proyecto apto para la toma de decisiones.
Modelado de Casos de Uso
Describe los requerimientos funcionales y no funcionales (restricciones) relacionados.
Especificación Complementaria Describe otros requerimientos.
Glosario Define los términos más importantes del dominio del problema.
Lista de RiesgosPlan de Gestión del Riesgo
Describe los riesgos técnicos, de recursos o del negocio implicados en el proyecto, y formula un plan con medidas preventivas y correctivas para enfrentar cada uno.
Prototipos, prueba de conceptos
Código escrito para aclarar la visión del problema, probar soluciones técnicas, asegurar la viabilidad.
Plan de IteraciónDescribe qué se hará en la primera iteración de la fase de Elaboración subsiguiente.
Plan de FasePlan de Desarrollo
Estimación gruesa de la duración y esfuerzo requeridos para la fase de Elaboración.Propuesta o selección de herramientas de desarrollo, actividades de formación, recursos adicionales.
Marco de DesarrolloDescripción de los pasos del UP y los artefactos considerados más adecuados para este proyecto; es la adaptación del UP para este proyecto particular.
UP: fase Elaboración.
La Elaboración tiene por objeto construir el núcleo central de la arquitectura, resolver los elementos de alto riesgo, definir la mayor parte de los requerimientos y estimar los recursos necesarios. En esta fase,
• se descubren los restantes requerimientos y se estabiliza la mayoría de ellos. • se implementan y prueban los elementos básicos de la arquitectura.• se reducen o eliminan los riesgos e incertidumbres más importantes del desarrollo (se ha
implementado una solución básica, o se ha probado su viabilidad en código). Durante el estudio de los requerimientos se han puesto de manifiesto las capacidades que ha de
tener el sistema. La arquitectura del sistema identifica las capacidades del sistema con las componentes de software que las implementarán, así como las relaciones entre estas componentes. En esta etapa se construye el núcleo central de la arquitectura del sistema, incluyendo:
• empleo de técnicas de diseño e implementación "amplias y superficiales", más bien abarcativas que de detalle:
• identificación de procesos, capas de software, paquetes, subsistemas;• establecimiento de sus responsabilidades;• clarificación y prueba de las interfaces internas (entre componentes) y externas (con
los actores).• refinamiento de las interfaces locales incluyendo parámetros y valores de retorno.• integración de componentes existentes.• implementación de los flujos básicos y extensiones más significativas o de mayor incidencia
en el diseño, la implementación, las pruebas o sobre otros componentes.La tabla siguiente muestra los artefactos típicos de la fase Elaboración.
7 de 8
UP: fase ElaboraciónArtefacto Descripción, propósito
Modelo del Dominio
Visualización de los conceptos del dominio.
Modelo de Diseño
Diagramas descriptivos del diseño lógico, sin referencias al modo de implementación. Comprende diagramas de clases del software, diagramas de interacción, diagrama de paquetes y otros.
Documento de Arquitectura
Describe la correlación entre los componentes de software y los requerimientos. Es un resumen de las ideas principales del diseño.
Modelo de DatosComprende esquemas de bases de datos, estrategias de transformación entre objetos y no objetos (e.g. cómo guardar los objetos en archivos, o cómo reconstruirlos a partir de información guardada en archivos).
Modelo de Pruebas
Descripción de lo qué se probará y cómo se probará; compara el resultado obtenido contra el resultado esperado.
Modelo de Implementación Código fuente, ejecutables, bases de datos, otros.
Prototipos UIGuiones de Casos de Uso
Construcción de prototipos de la interfaz de usuario (UI, “User Interface”).Modelos de facilidad de uso, navegación dentro del sistema (e.g. entre menús, entre ventanas).
Referencias y lecturas recomendadas.
El contenido de este documento está basado en las fuentes citadas a continuación, cuya lectura o consulta no pretenden sustituir.
Lecturas recomendadas.
• [Larman2003] Larman, Craig. UML y patrones. Una introducción al análisis y diseño orientado a objetos y al Proceso Unificado, 2a. edición. Madrid, 2003.ISBN 8420534382.
• [Fowler1997] Fowler, Martin y Scott, Kendall. UML distilled. Applying the Standard Object Modelling Language. Addison Wesley Longman, Inc., 1997. ISBN 0201325632.
• [Pfleeger2002] PFLEEGER, SHARI LAWRENCE. Ingeniería de software, teoría y práctica, 1a. edición. Buenos Aires, Pearson educación, 2002. ISBN: 9879460715.
Referencias.
• [Jacobson2000] Jacobson, Ivar; Booch, Grady; Rumbaugh, James. El proceso unificado de desarrollo de software. Pearson Educación, Madrid, 2000. ISBN: 8478290362.
• [Booch1999] Booch, Grady; Jacobson, Ivar; Rumbaugh, James. El lenguaje unificado de modelado. Pearson Educación, Madrid, 2000. ISBN: 8478290281.
Errores, omisiones, comentarios: Víctor González Barbone, vagonbar en fing.edu.uy
Desarrollo de Software para Ingeniería Eléctrica Rev. 20090509Instituto de Ingeniería Eléctrica Facultad de Ingeniería Universidad de la República, Uruguay.
8 de 8