2-proceso unificado
TRANSCRIPT
5/17/2018 2-Proceso Unificado - slidepdf.com
http://slidepdf.com/reader/full/2-proceso-unificado 1/69
2. El Proceso Software
Ingeniería del Software I3º I.T.I.Gestión
Miguel A. Laguna
Contenidos
2.1 Modelos de Proceso 2.1.1 Modelos genéricos de desarrollo 2.1.2 Métodos de desarrollo orientados a objetos
2.2 El Proceso Unificado de Desarrollo o Unified Process 2.3 Fases y disciplinas (o flujos de trabajo)
2.3.1 Fases y puntos de control 2.3.2 Disciplinas (flujos de trabajo) 2.3.3 Artefactos
2.4 Disciplinas de gestión
2.5 La fase de Inicio (Inception ) 2.6 La fase de Elaboración 2.7 Las fases de Construcción y Transición
5/17/2018 2-Proceso Unificado - slidepdf.com
http://slidepdf.com/reader/full/2-proceso-unificado 2/69
Objetivos del tema
Conocer los distintos modelos de proceso genéricos
Conocer las tendencias actuales en metodología dedesarrollo y los esfuerzos de estandarización
Aprender los principios del Proceso Unificado
Aprender la diferencia ente fase y disciplina en el
Proceso Unificado
Relacionar las técnicas de modelado de UML con lasfases y disciplinas del Proceso Unificado
Conocer las actividades de gestión de proyectos
2.1. Modelos de Proceso
2.1.1 Modelos genéricos de desarrollo2.1.2 Métodos de desarrollo
orientados a objetos
5/17/2018 2-Proceso Unificado - slidepdf.com
http://slidepdf.com/reader/full/2-proceso-unificado 3/69
PROCESO
TECNICAS
HERRAMIENTAS
Proceso: Define el marco de trabajo y permite un desarrolloracional de la IS
Técnicas: Indican cómo construir técnicamente el software.Incluyen técnicas de modelado
Herramientas: Proporcionan el soporte automático osemiautomático para el proceso y para las técnicas
UML
UP
TogetherRose
Componentes de un método
El proceso software
Un conjunto estructurado de actividades y resultadosasociados que conducen a la creación de un productode software Especificación: Definir la funcionalidad y las restricciones en
sus operaciones Diseño e implementación: Producir software que cumple la
especificación Validación: Asegurar que hace lo que el cliente desea. Evolución: Seguir cumpliendo los cambios en las
necesidades del usuario.
Un modelo de proceso es una representaciónabstracta de un proceso. Presenta una descripción de
un proceso desde una perspectiva particular.
5/17/2018 2-Proceso Unificado - slidepdf.com
http://slidepdf.com/reader/full/2-proceso-unificado 4/69
2.1.1Modelos genéricos de desarrollo
Modelos de proceso genéricos
No son descripciones exhaustivas de losprocesos software.
Son abstracciones útiles que explicandiferentes enfoques utilizables a la hora dedesarrollar software.
Son marcos de trabajo del proceso, nodetallan las actividades específicas.
Se denominan paradigmas de proceso
5/17/2018 2-Proceso Unificado - slidepdf.com
http://slidepdf.com/reader/full/2-proceso-unificado 5/69
Modelos de proceso genéricos
El modelo de cascada Separa y distingue cada fases de especificación y
desarrollo Desarrollo evolutivo
Se interpolan la especificación y el desarrollo
Desarrollo formal de sistemas Un modelo matemático del sistema se transforma
formalmente a una implementación
Desarrollo basado en reutilización El sistema se monta a partir de componentes
existentes
Modelo en Cascada
Definición de
Requisitos
Definición de
Requisitos
Diseño del sistema y
del software
Diseño del sistema y
del software
Implementación y prueba
de unidades
Implementación y prueba
de unidades
Integración y
prueba del sistema
Integración y
prueba del sistema
Operación ymantenimiento
Operación ymantenimiento
5/17/2018 2-Proceso Unificado - slidepdf.com
http://slidepdf.com/reader/full/2-proceso-unificado 6/69
Fases del modelo en cascada
Análisis y definición de requisitos Diseño del sistema y del software Implementación y prueba de unidades Integración y prueba del sistema Operación y mantenimiento
Una fase no comienza hasta que no hayanterminado las anteriores.
La desventaja es la dificultad de tener en cuentalos cambios cuando el proceso ya está en marcha
Problemas del Modelo en cascada
Inflexibilidad al dividir el proyecto en estasetapas
Es difícil responder a los cambios en losrequisitos del cliente
Por lo tanto, este modelo es apropiado sólocuando los requisitos se comprenden muybien.
5/17/2018 2-Proceso Unificado - slidepdf.com
http://slidepdf.com/reader/full/2-proceso-unificado 7/69
Desarrollo evolutivo
Desarrollar una implementación inicial e ir refinándolahasta conseguir el sistema adecuado. Las actividadesse realizan concurrentemente.
Desarrollo exploratorio El objetivo es trabajar con los clientes y
desarrollar un sistema final con algunaespecificación inicial. Se debe comenzar teniendoen cuenta los requisitos bien-entendidos. Elsistema evoluciona según la nuevas propuestasdel cliente.
Prototipos desechables El objetivo es comprender los requisitps del cliente
y desarrollar un prototipo para evaluar hasta quépunto se han entendido.
Desarrollo evolutivo
Bosquejo de la
descripción
Bosquejo de la
descripción
VersiónInicial
VersiónInicial
Versión
final
Versión
final
Versiones
intermedias
Versiones
intermedias
Versiones
intermedias
Versiones
intermedias
Actividades
concurrentes
Especificación
Especificación
Desarrollo
Desarrollo
Validación
Validación
5/17/2018 2-Proceso Unificado - slidepdf.com
http://slidepdf.com/reader/full/2-proceso-unificado 8/69
Desarrollo evolutivoLa ventaja es que la especificación se desarrolla de
forma creciente. Problemas
Hay que documentar cada versión del sistema Los sistemas tienen una estructura deficiente Se requieren herramientas y técnicas especiales
(p.e. conocimientos en lenguajes para elprototipado rápido)
Aplicabilidad Para sistemas interactivos pequeños o de tamañomediano Para partes de sistemas grandes (e.g. el interfaz
de usuario) Para sistemas con vida corta
Proceso mixto Desarrollar un prototipo desechable (con
enfoque evolutivo) para resolverincertidumbres en la especificación inicial.
Reimplementar con un enfoque másestructurado, con un proceso basado en elmodelo en cascada.
5/17/2018 2-Proceso Unificado - slidepdf.com
http://slidepdf.com/reader/full/2-proceso-unificado 9/69
Desarrollo formal de sistemas
Se basa en la transformación de unaespecificación “matemática” a un programa
ejecutable Las transformaciones preservan la corrección
y el programa final es conforme con suespecificación
Desarrollo formal de sistemas
Definición de
Requisitos
Definición de
RequisitosEspecificación
formal
Especificación
formalTransformación
formal
Transformación
formal
Integración y
prueba del
sistema
Integración y
prueba del
sistema
Desmostraciónde la corrección
5/17/2018 2-Proceso Unificado - slidepdf.com
http://slidepdf.com/reader/full/2-proceso-unificado 10/69
Desarrollo formal de sistemas
Problemas Se necesitan habilidades y el entrenamiento
especializados para aplicar la técnica Es difícil especificar formalmente algunos aspectos
del sistema tales como la interfaz de usuario
Aplicabilidad Sistemas críticos donde la seguridad o la fiabilidad
debe garantizarse antes de que el sistema seponga en explotación
Desarrollo con/para reutilización
Basado en la reutilización sistemática, los sistemas seintegran con componentes existentes o con sistemasCOTS (Commercial-off-the-shelf)
Etapas del proceso Análisis de componentes Modificación de requisitos Diseño del sistema con reutilización Desarrollo e integración
Este enfoque se está convirtiendo en el másimportante pero todavía hay una experiencia limitadacon él
5/17/2018 2-Proceso Unificado - slidepdf.com
http://slidepdf.com/reader/full/2-proceso-unificado 11/69
Desarrollo con/para reutilización
Especificación
de Requisitos
Especificación
de RequisitosAnálisis de
componentes
Análisis de
componentesModificación de
requisitos
Modificación de
requisitos
Diseño de
sistemas con
reutilización
Diseño de
sistemas con
reutilización
Desarrollo e
integración
Desarrollo e
integraciónValidación del
sistema
Validación del
sistema
Modelos iterativos de proceso
En sistemas grandes, es conveniente utilizardiferentes enfoques en las distintas partes.
Los requisitos del sistema SIEMPRE evolucionan en eltranscurso de un proyecto.
Siempre habrá una iteración en el proceso queobligue a rehacer las primeras fases del mismo.
La necesidad de iterar aparece independientementedel modelo de proceso genérico utilizado
Modelos de proceso que incluyen la iteración: Desarrollo incremental Desarrollo en espiral
5/17/2018 2-Proceso Unificado - slidepdf.com
http://slidepdf.com/reader/full/2-proceso-unificado 12/69
Desarrollo incremental
Propuesto por Mills en 1980.
En vez de entregar el sistema de una vez, tanto eldesarrollo com las entregas se dividen enincrementos.
Con cada incremento que entrega la parte de lafuncionalidad que se hubiera determinado
Los requisitos del usuario se priorizan y los requisitosde prioridad más alta se incluyen en los incrementosmás tempranos
Cuando el desarrollo de un incremento comienza, susrequisitos son inamovibles, aunque los requisitos deincrementos posteriores pueden continuardesarrollándose
Desarrollo incremental
Definir requisitos
iniciales
Definir requisitos
iniciales
Asignar requisitos a
cada incremento
Asignar requisitos a
cada incremento
Diseñar la
arquitecturadel sistema
Diseñar la
arquitecturadel sistema
Desarrollar
incremento
Desarrollar
incrementoValidar
incremento
Validar
incrementoIntegrar
incrementos
Integrar
incrementosValidar
sistema
Validar
sistema
Sistema incompleto
Sistema
final
5/17/2018 2-Proceso Unificado - slidepdf.com
http://slidepdf.com/reader/full/2-proceso-unificado 13/69
Desarrollo incremental
analys
is desi
gn co
de t
estincremento 2
incremento 3
incremento 4
incremento 1Entrega del
tiempo
incremento 1
Entrega del
incremento 2...
anal
ysis design co
de tes
t
analy
sis de
sign c
o
de test
analy
sis de
sign c
ode test
Ventajas del desarrollo incremental
Los clientes no tienen que esperar hasta tener elsistema completo. El primer incremento satisface losrequisitos más críticos.
Los primero incrementos sirven como prototipo yayudan en la tarea de detectar los posterioresrequisitos.
Existe un riesgo bajo de fallar en el proyecto total. Los servicios de sistema con la prioridad más alta
tienden a ser los más probados. … pero puede ser difícil ajustar los requisitos a los
incrementos.
5/17/2018 2-Proceso Unificado - slidepdf.com
http://slidepdf.com/reader/full/2-proceso-unificado 14/69
Desarrollo en espiral
Propuesto por Boehm en 1988. El proceso se representa como una espiral
más que como una secuencia de actividadescon vuelta hacia atrás. Cada vuelta en la espiral representa una fase
del proceso. No hay fases fijas como la especificación o
diseño. Cada vuelta en la espiral determinalas actividades a realizar.
Desarrollo en espiral
Planificación Análisis de riesgos
Desarrollo y validaciónEvaluación delusuario
Comunicación conel usuario
Ingeniería
5/17/2018 2-Proceso Unificado - slidepdf.com
http://slidepdf.com/reader/full/2-proceso-unificado 15/69
Sectores del modelo en espiral
Definición de objetivos Se identifican los objetivos de cada fase, las alternativas y
las restricciones.
Evaluación y reducción de riesgos Se determinan los riesgos de cada fase y se ponen en
marcha las actividades que reduzcan estos riesgos.
Desarrollo y validación Se elige el modelo de desarrollo más apropiado para el
sistema de entre todos los modelos genéricos.
Planificación Se revisa el proyecto y, si se continúa, se planifica la
siguiente fase (nueva vuelta a la espiral).
Desarrollo en espiral
Risk analysis
Risk
analysisRisk
analysis
Risk analysis Proto-
type 1
Prototype 2
Prototype 3Opera-tionalprotoype
Concept of Operation
Simulations, models, benchmarks
S/Wrequirements
Requirementvalidation
DesignV&V
Product
design Detaileddesign
Code
Unit test
Integr ationtest
AcceptancetestService Develop, verify
next-le vel product
Evaluate alternativesidentif y, resolve risks
Determine objectivesalternatives and
constraints
Plan next phase
Integrationand test plan
Develop mentplan
Require ments planLife-cycle plan
REVIEW
5/17/2018 2-Proceso Unificado - slidepdf.com
http://slidepdf.com/reader/full/2-proceso-unificado 16/69
2.1.2
Métodos de desarrolloorientados a objetos
Generaciones de Métodos
Años 60 y 70: COBOL, FORTRAN, C Métodos de análisis y diseño estructurados
Años 80 y primeros 90: C++, Smalltalk, Ada Métodos OO de primera generación: OMT,
Jacobson
Finales de los 90: Java UML Métodos OO avanzados, Proceso Unificado
5/17/2018 2-Proceso Unificado - slidepdf.com
http://slidepdf.com/reader/full/2-proceso-unificado 17/69
Análisis Diseño I mplementación
DFDSTD
PROGRAMA P R O C
E S O S
DER
RELACIONAL TABLAS D A T O S
Métodos estructurados y...
Análisis Diseño I mplementación
C l a s e s
...Métodos orientados a objetos
5/17/2018 2-Proceso Unificado - slidepdf.com
http://slidepdf.com/reader/full/2-proceso-unificado 18/69
Desventajas (¿superadas?)
Diseñar módulos reutilizables añade costes. Beneficios a medio/largo plazo. Falta de madurez. Falta de productos (bibliotecas, CASE, ...). Falta de eficiencia. Falta de formación. Forma de trabajo diferente a la tradicional. Falta de estándares.
“Si yo tuviera que vender mi gato (al menos
a un informático) no diría que es amable,autosuficiente y que come ratones:más bien argumentaría que es ...orientado-a-objetos” (Roger King)
Evolución de la OO
1980 1990 Hoy 200?
Texto
ProcedimentalC, Cobol
Relacional
GUI
OOC++, Java
OO ?
I nterfaz deusuario
Lenguaje deprogramación
SGBD
5/17/2018 2-Proceso Unificado - slidepdf.com
http://slidepdf.com/reader/full/2-proceso-unificado 19/69
Métodos OO (antes de UML)
• Métodos dirigidos por los datos (data-driven)- OMT (Rumbaugh et al. 1991)- FUSION (Coleman et al. 1994)
• Métodos dirigidos por responsabilidades(responsability-driven)
- RDD (Wirfs-Brock et al. 1990)- OBA (Rubin y Goldberg 1992)
• Métodos dirigidos por casos de uso(use case-driven)
- OOSE/Objectory (Jacobson et al. 1992)
• Métodos dirigidos por estados (state-driven)- Shlaer y Mellor (Shlaer y Mellor 1992)
OMT (Object Modeling Technique)
Desarrollado en General Electric a finales de los 80 El método OO más difundido antes de UML/UP Aunque tiene cuatro fases definidas, se centra de una forma
especial en el análisis Presenta una continuidad respecto a las métodos estructurados
El libro “Object-Oriented Modeling and Design” escrito porRumbaugh et al. en 1991 es un best-seller mundial:
Rumbaugh, James, Blaha, Michael, Premerlani, William, Eddy,Frederick, Lorensen, William. “ Modelado y Diseño Orientados a
Objetos. Metodología OMT ”. 2ª Reimpresión. Prentice Hall. 1998.
5/17/2018 2-Proceso Unificado - slidepdf.com
http://slidepdf.com/reader/full/2-proceso-unificado 20/69
... OMT
Diagramas deestados
DFDs
Diagramas declases
Método de Booch
Es uno de los más conocidos
En su versión de 1993 este método cubre las fases de análisis ydiseño dentro de un desarrollo OO.
Define una gran cantidad de símbolos para representar lasdistintas decisiones de diseño.
Se definen dos tipos de procesos que describen los niveles enun desarrollo orientado al objeto: Macro procesos Micro procesos
Booch, G. "Object-Oriented Analysis and Design with Applications", 2nd edition. Benjamin Cummings, 1993.
5/17/2018 2-Proceso Unificado - slidepdf.com
http://slidepdf.com/reader/full/2-proceso-unificado 21/69
Método de Booch
Diferencia: Modelos estático y dinámico
Modelos lógico y físico
Modelo dinámico
Modelo Estático
Modelo Lógico
Modelo Físico
Estructura de clases
Arquitectura de módulos
Estructura
de objetos
Arquitectura
de procesos
Clase
Nombre de la clase
AtributosMétodos()
{restricciones}
Clase utilidad
Nombre de la claseutilidad
AtributosMétodos()
Clase parametrizada
Nombre de la
claseparametrizada
Argumentos
formales
Argumentos
actuales
Nombre de la
claseinstanciada
... Método de Booch
5/17/2018 2-Proceso Unificado - slidepdf.com
http://slidepdf.com/reader/full/2-proceso-unificado 22/69
OOSE (Jacobson)
Análisis Construcción Pruebas
Análisis deRobustez
Especificaciónde requisitos
Modelo de
requisitos
Modelo de
análisis
Análisis deRequisitos
Proceso de análisis:
Es un método que se basa en la idea de los casos de uso comoforma de analizar los requisitos del usuario
El ciclo de vida es similar al modelo básico pero se empieza muypronto con la interfaz de usuario:
...OOSE: Casos de Uso
Aunque tiene su propia notación, lo más característico son loscasos de uso
Jacobson, I., Christerson, M., Jonsson, P., Övergaad, G. “Object Oriented Software Engineering: A Use Case Driven Approach”.Addison-Wesley, 1994.
Identificación
Cliente remoto Giro por Internet
Cliente local
Giro<<uses>>
<<extends>>
5/17/2018 2-Proceso Unificado - slidepdf.com
http://slidepdf.com/reader/full/2-proceso-unificado 23/69
Métodos OO (después de UML)
Evolución de métodos clásicos Métrica versión 3
Métodos “ágiles” eXtreme Programming (XP)
Métodos “marco” adaptables OPEN Proceso Unificado (Unified Process)
Métrica Versión 3
Cubre desarrollo estructurado y orientado a objetos
Además del desarrollo, contempla procesos de Planificación yMantenimiento
Facilita la realización de los procesos de apoyo u organizativos
Procesos principales de desarrollo en Métrica 3: Estudio de Viabilidad del Sistema Análisis del Sistema de Información Diseño del Sistema de Información
Construcción del Sistema de Información Implantación y aceptación
5/17/2018 2-Proceso Unificado - slidepdf.com
http://slidepdf.com/reader/full/2-proceso-unificado 24/69
Métrica Versión 3
Métrica 3. Análisis
Objetivo: obtención de unaespecificación detallada del sistemaque satisfaga las necesidades de losusuarios y sirva de base para el
posterior diseño del sistema
5/17/2018 2-Proceso Unificado - slidepdf.com
http://slidepdf.com/reader/full/2-proceso-unificado 25/69
Métrica 3. Diseño
Objetivo: definir la arquitectura del sistema,el entorno tecnológico y la especificacióndetallada de los componentes del sistema
Métrica 3. Construcción del SistemasSe genera el código de los componentes, sedesarrollan los procedimientos de operación yseguridad y se elaboran los manuales de usuariofinal y de explotación
5/17/2018 2-Proceso Unificado - slidepdf.com
http://slidepdf.com/reader/full/2-proceso-unificado 26/69
Métodos ágiles
Como reacción a los procesos muyburocratizados surgen los métodos ágiles
Propuesta por Beck en 1999. Nuevo enfoque basado en el desarrollo y la
entrega de incrementos de funcionalidad muylimitada.
Confía en la mejora constante del código,implicación del usuario en el equipo dedesarrollo y la programación “sin complejos”.
eXtreme Programming (XP)
Características de eXtreme Programming: Ciclos muy cortos de desarrollo Sistemas con funcionalidad mínima Únicamente las tareas de alta prioridad Importancia de las personas
Conjunto de “buenas prácticas”: Programación por pares Pruebas continuas Refactorización (refactoring) continua
5/17/2018 2-Proceso Unificado - slidepdf.com
http://slidepdf.com/reader/full/2-proceso-unificado 27/69
2.2
El Proceso Unificado de Desarrollo(Unified Process)
UML no es suficiente Características del Proceso Unificado
Componentes de un Método
Elementos de modelado Un conjunto fundamental de conceptos de modelado para
capturar el conocimiento semántico sobre un problema y susolución
Los conceptos de modelado son independientes de cómo sevisualizan
Notación Un conjunto de vistas y notaciones para presentar la
información de modelado subyacente que permite a laspersonas examinarlos y modificarlos
Proceso Tiene como cometido la formalización de las actividades
relacionadas con la elaboración de sistemas software Experiencia
Una colección de reglas y heurísticas para llevar a cabo eldesarrollo
5/17/2018 2-Proceso Unificado - slidepdf.com
http://slidepdf.com/reader/full/2-proceso-unificado 28/69
Personas, Equipos,
Experiencia
UML no es un método
Lenguajede Modelado
Proceso
?
¿Qué es un Proceso?
Describe un conjunto de actividades que debenrealizarse en un determinado orden qué hacer, cómo hacerlo, cuando hacerlo y el motivo por el cual
debe ser hecho
Debe ser: Reproducible Definido Medible en cuanto a rendimiento Optimizable...
Nuevos
Requisitos
Sistema
Nuevo
Procesosoftware
5/17/2018 2-Proceso Unificado - slidepdf.com
http://slidepdf.com/reader/full/2-proceso-unificado 29/69
Dos elementos complementarios
UML ProcesoUnificado
• Procesomarco
adaptable• No es un
estándar en sí
• EstándarOMG
Antecedentes del Proceso Unificado
Rational Unified Process 5.01998
Rational Objectory Process 4.11996-1997
Objectory Process 1.0-3.81987-1995
Ericsson (Jacobson)
Rational UML
Unified Process
1999SPEM(2002)
EstándaresOMG
5/17/2018 2-Proceso Unificado - slidepdf.com
http://slidepdf.com/reader/full/2-proceso-unificado 30/69
Software Process Engineering Metamodel
OMG
SPEM,
2002
UP es un Proceso “marco”
No existe un proceso Universal UP es flexible y extensible:
Permite varias estrategias de desarrollo Se pueden definir diferentes conjuntos de productos Se pueden definir actividades y encargados de las
mismas
5/17/2018 2-Proceso Unificado - slidepdf.com
http://slidepdf.com/reader/full/2-proceso-unificado 31/69
Características del Proceso Unificado
Está dirigido por los casos de uso:
Desde la especificación hasta el mantenimiento
Se centra en la arquitectura: La arquitectura es prioritaria desde el principio hasta el
final Se facilita el refinamiento progresivo de la arquitectura
Iterativo e incremental: El trabajo se divide en iteraciones pequeñas en función
de la importancia de los casos de uso y el análisis deriesgos
Conducido por Casos de uso
Requisitos Implement. Pruebas
Los casos de uso integran todas las actividades
Análisis Diseño
Capturar, clarificar yvalidar los casos de uso
Realizar los casos deuso
Verificar que sesatisfacen los casosde uso
5/17/2018 2-Proceso Unificado - slidepdf.com
http://slidepdf.com/reader/full/2-proceso-unificado 32/69
Centrado en la Arquitectura
La arquitectura describe los elementosfundamentales del sistema: Subsistemas Dependencias Interfaces Colaboraciones Nodos Clases activas...
Incluye decisiones importantes sobre: Organización del sistema Elementos estructurales, interfaces y su comportamiento Composición y comportamiento de los subsistemas El estilo de la arquitectura que guía esta organización
Modelo de Arquitectura: 4 + 1 vistas
Los modelos son instrumentos para visualizar, especificar,construir y documentar la arquitectura del sistema
Cada vista es una parte de un modelo
(Philippe Kruchten)
Vista Lógica
Vista LógicaVista de
Realización
Vista de
Realización
Vista de
Procesos
Vista de
ProcesosVista de
Despliegue
Vista de
Despliegue
Vista de
Casos de Uso
5/17/2018 2-Proceso Unificado - slidepdf.com
http://slidepdf.com/reader/full/2-proceso-unificado 33/69
Arquitectura y Modelos
La arquitectura incorpora una colección de vistas de los modelos
Vistas
Modelos
Modelo decasos de uso
Modelo dediseño
Modelo dedespliegue
Modelo deImplement.
Modelo deanálisis
Modelo dePruebas
Estructura y función
Casos de uso Arquitectura
• Los casos de uso especifican las funciones
• La arquitectura especifica la la estructura
• Los casos de uso y la arquitectura deben estar en
equilibrio
5/17/2018 2-Proceso Unificado - slidepdf.com
http://slidepdf.com/reader/full/2-proceso-unificado 34/69
Proceso iterativo e incremental
...Pero la característica fundamental de UP: Es un proceso iterativo
Se basa en la ampliación y el refinamiento del sistema Una serie de desarrollos cortos (mini proyectos de 2 a 6
semanas, cada iteración reproduce el ciclo de vida a menorescala)
No sólo se mejora sino que el sistema también crece:Proceso iterativo e incremental
Análisis Diseño Implementación Prueba
Tiempo
Funcionalidaddel sistema
Análisis Diseño Implementación PruebaIncremento1
Incremento2
Proceso iterativo e incremental
El resultado de cada iteración es un sistema ejecutable
(aunque sea incompleto y no esté listo para su instalación)
Un sistema instalable requiere varias iteraciones
Evolución de prototipos ejecutables
Los objetivos de una iteración se establecen en función de la
evaluación de las iteraciones precedentes
Concepto de “time-boxing”: cada iteración debe tener una
duración fija (el máximo, 6 meses) En lugar de retrasar el final de una iteración se recomienda eliminar
algunos de los requisitos (se dejan para la siguiente iteración)
La realimentación del usuario es fundamental en este proceso
El progreso es visible
5/17/2018 2-Proceso Unificado - slidepdf.com
http://slidepdf.com/reader/full/2-proceso-unificado 35/69
Etapa de Ingeniería Etapa de Producción
Visión Arquitectura Versiones Beta Productos
Inicio Elaboración Construcción Transición
Iterativo: varias espirales
Cada iteración comprende:
Planificación de la iteración (estudio de riesgos)
Análisis de Casos de uso y escenarios
Diseño de opciones arquitectónicas
Codificación y pruebas. La integración del nuevo código con elexistente de iteraciones anteriores se hace gradualmente durantela construcción
Evaluación de la entrega ejecutable (evaluación del prototipo enfunción de las pruebas y de los criterios definidos)
Preparación de la entrega (documentación e instalación delprototipo)
5/17/2018 2-Proceso Unificado - slidepdf.com
http://slidepdf.com/reader/full/2-proceso-unificado 36/69
Primero, la arquitectura, Después, se van añadiendo los detalles según avanza el desarrollo
Inicio Elaboración Construcción Transición
Etapa de Ingeniería Etapa de producción
R e q u i s i t o s
D i s e ñ o
I m p
l e m e n t a c i ó n
I n s t a l a c i ó n
Gestión
R e q u i s i t o s
D i s e ñ o
I m p
l e m e n t a c i ó n
I n s t a l a c i ó n
Gestión
R e q u i s i t o s
D i s e ñ o
I m p
l e m e n t a c i ó n
I n s t a l a c i ó n
Gestión
R e q u i s i t o s
D i s e ñ o
I m p
l e m e n t a c i ó n
I n s t a l a c i ó n
Gestión
Incremental
Visión Arquitectura Versiones Beta Productos
2.3Fases y disciplinas
(o flujos de trabajo)
Fases y puntos de control Disciplinas (Flujos de trabajo) Artefactos
5/17/2018 2-Proceso Unificado - slidepdf.com
http://slidepdf.com/reader/full/2-proceso-unificado 37/69
Elementos del Proceso Unificado Fases:
Es preciso diferenciar temporalmente las fases del ciclo de vida La división temporal necesita...
Puntos de control o hitos: Separan las etapas, las fases, las iteraciones
Disciplinas o Flujos de trabajo: Organizan las actividades fundamentales de gestión y desarrollo Se pueden solapar en el tiempo. El resultado de las actividades de los flujos de trabajo son...
Artefactos: Cualquier tipo de información producida por los desarrolladores de un
sistema (diagramas UML, código, ejecutables, casos de prueba...) Se construyen de forma incremental
Planificación temporal del proyecto
UP propone una serie de ciclos de desarrollo: Hay que separar claramente la etapa de Ingeniería
de la etapa de Producción Cada una de las dos grandes etapas se dividen enfases Las fases se dividen en iteraciones
iteración fase
Ciclo de desarrollo
Etapa de Ingeniería Etapa de Producción
5/17/2018 2-Proceso Unificado - slidepdf.com
http://slidepdf.com/reader/full/2-proceso-unificado 38/69
Etapas y fases del ciclo de vida
tiempo
Inicio Elaboración Construcción Transición
Etapa de Ingeniería: equipos pequeños, actividades pocopredecibles (análisis, viabilidad, planificación). Las fases son:
Inicio Elaboración
Etapa de Producción: equipos grandes, actividadespredecibles, menos riesgos (programación, pruebas). Lasfases son: Construcción
Transición
Objetivos de las fases
Inicio del proyecto (inception) Define el ámbito y objetivos del proyecto
Elaboración Define la funcionalidad y una arquitectura
básica
Construcción El producto se desarrolla a través de iteraciones
Transición Se libera el producto y se entrega al usuario
para su uso real
5/17/2018 2-Proceso Unificado - slidepdf.com
http://slidepdf.com/reader/full/2-proceso-unificado 39/69
Hitos
Los hitos son puntos de control en los cuales losparticipantes en el proyecto revisan el progreso del
proyecto.
Se pretende: Sincronizar las expectativas y la realidad Identificar los riesgos Se evalua la situación global del proyecto
Se necesitan: Resultados tangibles para comparar con las expectativas
Varios niveles: Hitos principales al final de cada fase Hitos secundarios final de cada iteración
Hitos principales y secundarios
Visión Arquitecturabásica
Capacidadinicial
Productofinal
tiempo
Inicio Elaboración Construcción Transición
Una iteración es una secuencia de actividades con un plan establecidoy unos criterios de evaluación, cuyo resultado es una versiónejecutable (hito secundario)
Release Release Release Release Release Release ReleaseRelease
5/17/2018 2-Proceso Unificado - slidepdf.com
http://slidepdf.com/reader/full/2-proceso-unificado 40/69
Disciplinas o flujos de trabajo
Organizan las actividades fundamentales de gestión ydesarrollo del proyecto
Disciplinas de desarrollo: requisitos, análisis, diseño,implementación, pruebas, etc.
Disciplinas de gestión o soporte: gestión de proyecto,gestión de configuraciones, entorno, evaluación, etc.
Al contrario de lo que ocurre con las fases, lasdistintas actividades del equipo de desarrollo sepueden solapar en el tiempo.
Fases, iteraciones y disciplinas
iter.#1
iter.#2
iter.#n
iter.#n+1
iter.#n+2
iter.#m
iter.#m+1
Fases
Requisitos
Diseño
Implementación
Pruebas
Análisis
Disciplinas:
Iteraciones
Iteraciones
preliminares
Inicio Elaboración Construcción Transición
5/17/2018 2-Proceso Unificado - slidepdf.com
http://slidepdf.com/reader/full/2-proceso-unificado 41/69
Fases y disciplinas: SPEM
La propuesta de proceso estándar admite distintascombinaciones de disciplinas y fases
Iteraciones
Disciplinas:
Modelado del negocio
Requisitos
Diseño
Implementación
Prueba
Despliegue
Gestión de laConfiguración
Gestión del Proyecto
Entorno
Inicio Elaboración Construcción Transición
El detalle de cada disciplina
Pero hay que definir cada disciplina en detalle
Iteraciones
Disciplinas:
Modelado del negocio
Requisitos
Diseño
Implementación
Prueba
Despliegue
Gestión de la
Configuración
Gestión del Proyecto
Entorno
Inicio Elaboración Construcción Transición
5/17/2018 2-Proceso Unificado - slidepdf.com
http://slidepdf.com/reader/full/2-proceso-unificado 42/69
Artefactos
Definición de artefacto (o producto): Cualquier tipo de información producida por los
desarrolladores de un sistema.
Se construyen de forma incremental
Tipos de artefactos Diagramas UML Código fuente Ejecutables
Casos de prueba...
Los modelos son los artefactos básicos que producenlas disciplinas (incluyen otros artefactos)
Disciplinas de desarrollo y modelos
Modelo decasos de uso
Modelo dediseño
Modelo dedespliegue
Modelo deImplement.
Modelo deanálisis
Modelo dePruebas
Los diagramas UMLrepresentan vistas decada modelo
Cada disciplina seasocia con modelos
Requisitos
Diseño
Implementación
Pruebas
Análisis
5/17/2018 2-Proceso Unificado - slidepdf.com
http://slidepdf.com/reader/full/2-proceso-unificado 43/69
Modelo de casos de uso
Modelo decasos de uso
Modelo dediseño
Modelo dedespliegue
Modelo deImplement.
Modelo deanálisis
Modelo dePruebas
Diagramasde casos de uso
Diagramasde colaboración
Diagramasde componentes
Diagramasde despliegue
Diagramasde objetos
Diagramasde estados
Diagramasde secuencia
Diagramasde clases
Diagramasde actividades
Modelos de análisis y diseñoDiagramas
de casos de uso
Diagramasde colaboración
Diagramasde componentes
Diagramasde despliegue
Diagramasde objetos
Diagramasde estados
Diagramasde secuencia
Diagramasde clases
Diagramasde actividades
Modelo decasos de uso
Modelo dediseño
Modelo dedespliegue
Modelo deImplement.
Modelo de
análisis
Modelo dePruebas
5/17/2018 2-Proceso Unificado - slidepdf.com
http://slidepdf.com/reader/full/2-proceso-unificado 44/69
El “Caso de desarrollo”
El número de posibles diagramas, modelos, vistas,ficheros fuente, casos de pruebas, etc. es muy grande
Es preciso definir los artefactos que son necesarios encada desarrollo concreto
Uno de los artefactos iniciales es el “Caso de desarrollo”: Qué artefacto es necesario en cada disciplina En qué fase se crea En qué fases se actualiza
Esta posibilidad permite tanto desarrollos “pesados” como “ágiles”
Ejemplo de un “Caso de desarrollo”
R R R IPlan de desarrolloGestión delProyecto
R ICaso de desarrolloEntorno
R IModelo de pruebasPruebas
R R IModelo de implementaciónImplementación
R R R
III
Modelo de diseño ArquitecturaModelo de datos
Diseño
R IModelo de análisis Análisis
R R
R I
II
I
Modelo de casos de uso Visión
GlosarioModelo del dominio
Requisitos
Tran-sición
Construc-ción
Elabora-ción
Inicio ArtefactoDisciplina
5/17/2018 2-Proceso Unificado - slidepdf.com
http://slidepdf.com/reader/full/2-proceso-unificado 45/69
2.5.
Disciplinas de gestión deproyectos
Objetivos de la gestión de proyectos
Organizar, planificar y programar losproyectos de software
Disciplinas y técnicas: Planificación y estimación de costes Garantía de calidad Gestión de la Configuración Gestión de personal …
También existen herramientas gráficas degestión
5/17/2018 2-Proceso Unificado - slidepdf.com
http://slidepdf.com/reader/full/2-proceso-unificado 46/69
Planificación y calendarización del proyecto• Tareas a realizar y plan de trabajo
Estimación del coste del proyecto Supervisión y revisión del proyecto
• Para comparar los progresos y costes reales conlos planeados y hacer ajustes
Selección y evaluación del personalRedacción y presentación de informes
Tareas en la gestión de proyectos
Planificación del proyecto
Es la actividad que más tiempo consume enla administración de un proyecto
Es un proceso iterativo que se completacuando el proyecto mismo termina.
El plan del proyecto debe ser revisadoregularmente a la vista de la evolución delmismo
Es imposible planificar sin estimar.
5/17/2018 2-Proceso Unificado - slidepdf.com
http://slidepdf.com/reader/full/2-proceso-unificado 47/69
Estimación del coste del software
Se trata de predecir los recursos que serequieren para un determinado proceso de
desarrollo de software
Preguntas fundamentales en la estimación: ¿Cuánto esfuerzo se requiere para completar una
actividad? ¿Cuánto tiempo de calendario se necesita para
terminar una actividad? ¿Cuál es el coste total de una actividad?
Se intenta determinar una medida dela cantidad de software y dedocumentación asociada que produce
un programador individual Hay que tener en cuenta que existen
muchas soluciones software condistintas características: máseficiente, más mantenible, …
Hay varias propuestas de métricas
para medir diversos aspectos delsoftware
Productividad del programador
5/17/2018 2-Proceso Unificado - slidepdf.com
http://slidepdf.com/reader/full/2-proceso-unificado 48/69
Métricas relacionadas con el tamaño. Basadas en el tamaño de alguna salida de una
actividad del proceso: número de líneas del códigofuente, número de instrucciones del código objeto,número de páginas de la documentación, etc.
Métricas relacionadas con la función. Basadas en una estimación de la funcionalidad del
software entregado: los puntos de función.
Métricas de la productividad
Puntos de función
complexity multiplierfunction points
number of user inputs
number of user outputs
number of user inquiries
number of files
number of ext.interfaces
measurement parameter
3
4
3
7
5
countweighting factor
simple avg. complex
4
5
4
10
7
6
7
6
15
10
=
=
=
=
=
count-total
X
X
X
X
X
5/17/2018 2-Proceso Unificado - slidepdf.com
http://slidepdf.com/reader/full/2-proceso-unificado 49/69
Las métricas basadas en volumen/unidad detiempo (líneas/programador-mes) son
imperfectas porque no tienen en cuentafactores como la fiabilidad, el mantenimiento,…
La productividad se puede aumentargeneralmente a costa de la calidad
Calidad y productividad
Técnicas de estimación
No hay una forma simple de hacer unaestimación exacta del esfuerzo requerido paradesarrollar un sistema de software Las estimaciones iniciales se basan en información
poco precisa que aportan los usuarios El software puede tener que ejecutarse en
ordenadores no conocidos o utilizar tecnología nueva El personal del proyecto es desconocido
Las estimaciones de los costes del proyectotienden a “autorealizarse” La estimación determina el presupuesto y el productose ajusta para cumplir el presupuesto
5/17/2018 2-Proceso Unificado - slidepdf.com
http://slidepdf.com/reader/full/2-proceso-unificado 50/69
Técnicas de estimación
Modelado algorítmico de costes. Se analizan los costes de otros proyectos realizados. Se
utiliza una fórmula matemática para predecir los costes del
proyecto actual Opinión de expertos.
Se consulta a varios expertos y entre ellos acuerdan unaestimación.
Estimación por analogía. Se estima por analogía con otros proyectos completados
sobre el mismo dominio de aplicación. Ley de Parkinson.
El trabajo se extiende para llenar el tiempo disponible. El coste se determina según los recursos disponibles.
Precio para ganar. Se acuerda la funcionalidad aceptable para el sistema
teniendo en cuenta el coste acordado.
Calendario del proyecto
Partir el proyecto en tareas y estimar eltiempo y los recursos necesarios paraterminar cada tarea
Organizar las tareas concurrentemente parahacer un uso óptimo de la mano de obra Minimizar las dependencias entre tareas para
evitar retrasos producidos cuando una tareaespera a otra para terminar
Depende de la intuición y la experiencia delos administradores del proyecto
5/17/2018 2-Proceso Unificado - slidepdf.com
http://slidepdf.com/reader/full/2-proceso-unificado 51/69
Estructura de un plan de proyecto
En él se fijan los recurso disponibles, se divideel trabajo y se crea un calendario de
trabajo. Debe incluir:1. Introducción. Objetivos del proyecto y restricciones
económicas y temporales
2. Organización del proyecto. Organización del equipo, personas involucradas
y sus tareas
3. Análisis de riesgo. Posibles riesgos con su probabilidad y
estrategias de reducción de riesgos propuestas
Estructura de un plan de proyecto
4. Requisitos de recursos de hardware y de software. Precios de lo que hay que comprar y fechas de entrega
5. División del trabajo.
División del proyecto en actividades, marca hitos yproductos a entregar
6. Calendario del proyecto. Dependencias entre actividades, tiempo estimado
requerido y asignación de personal
7. Mecanismos de supervisión e informe. Cuándo y qué tipo de informe debe producirse
5/17/2018 2-Proceso Unificado - slidepdf.com
http://slidepdf.com/reader/full/2-proceso-unificado 52/69
Problemas en la planificación
Estimar la dificultad de los problemas, y porlo tanto el coste de desarrollar una solución,
es difícil La productividad no es proporcional al
número de personas que trabajan en unatarea
Añadir personal al final del proyecto producemás retraso por la sobrecarga en la
comunicación Lo inesperado siempre ocurre
Diagramas para la gestión de proyectos
Las notaciones gráficas ilustran laplanificación del proyecto
Muestran la descomposición del proyecto en
tareas. Las tareas no deben ser demasiadopequeñas. Los diagramas de redes de actividades
muestran las dependencias de las tareas y elcamino crítico
Los diagramas de barras muestran laplanificación sobre el calendario
5/17/2018 2-Proceso Unificado - slidepdf.com
http://slidepdf.com/reader/full/2-proceso-unificado 53/69
Duración de las tareas y dependencias
Tarea Duración (días) Dependencias
T1 8T2 15
T3 15 T1 (M1)
T4 10
T5 10 T2, T4 (M2)
T6 5 T1, T2 (M3)
T7 20 T1 (M1)
T8 25 T4 (M5)
T9 15 T3, T6 (M4)T10 15 T5, T7 (M7)
T11 7 T9 (M6)
T12 10 T11 (M8)
Red de actividades
start
T2
M3T6
Finish
T10
M7T5
T7
M2T4
M5
T8
4/7/99
8 days
14/7/99 15 days
4/8/99
15 days
25/8/99
7 days
5/9/99
10 days
19/9/99
15 days
11/8/99
25 days
10 days
20 days
5 days
25/7/99
15 days
25/7/99
18/7/99
10 days
T1
M1 T3
T9
M6
T11
M8
T12
M4
5/17/2018 2-Proceso Unificado - slidepdf.com
http://slidepdf.com/reader/full/2-proceso-unificado 54/69
Actividades en el calendario
4/7 11/7 18/7 25/7 1/8 8/8 15/8 22/8 29/8 5/9 12/9 19/9
T4
T1
T2
M1
T7
T3
M5
T8
M3
M2
T6
T5
M4
T9
M7
T10
M6
T11
M8
T12
Start
Finish
Asignación de personal
4/7 11/7 18/7 25/ 1/8 8/8 15/8 22/8 29/8 5/9 12/9 19/9
T4
T8 T11T12
T1
T3
T9
T2
T6 T10
T7
T5
Fred
Jane
Anne
Mary
Jim
5/17/2018 2-Proceso Unificado - slidepdf.com
http://slidepdf.com/reader/full/2-proceso-unificado 55/69
Gestión del riesgo
El análisis de riesgos consiste en evaluar elproyecto, la tecnología y los recursos con el
fin determinar y comprender la naturaleza yel origen de los riesgos
Posibles riesgos: Comerciales (competencia, etc.) Financieros (económicos, etc.)
Técnicos (¿base tecnológica sólida yprobada?) De desarrollo (¿equipo experimentado?)
Tabla de riesgos
Escala 1..51=impacto
bajo5=catástrofe
Escala 1..51=impacto
bajo5=catástrofe
RiesgoRiesgo ProbabilidadProbabilidad ImpactoImpacto GestiGestióónn yy
MitigaciMitigacióónn deldel
RiesgoRiesgo
Ejemplo:Softwareempotradodepende dehardware nodisponible
60% 4(crítico)
Ajustar pruebas a ladisponiblilidad delHW
Utilizar simulación
5/17/2018 2-Proceso Unificado - slidepdf.com
http://slidepdf.com/reader/full/2-proceso-unificado 56/69
Garantía de calidad
Coste de los fallos encontrados en distintas etapas
100
10
1
Req.Diseño
Prog.
Pruebas En uso
0.751.00
1.503.00
10.00
60.00-100.00
Pruebadel sistema
Conceptos de calidad
¿Cómo se aplica al software? Control de calidad: inspecciones, revisiones,
pruebas Aseguramiento de la calidad: análisis, auditoría e
informes
Estándares de calidad: ISO 90003 guía para la aplicación de la ISO 9001:2000 para la
adquisición, suministro, desarrollo, instalación ymantenimiento de SOFTWARE y servicios de soporte.
5/17/2018 2-Proceso Unificado - slidepdf.com
http://slidepdf.com/reader/full/2-proceso-unificado 57/69
Garantía de calidad
Revisionesformales
Planifica-ción de laspruebas
Métricas
Análisis&
Informes
Proceso y
Estandares
Productividad y
calidad baja.Riesgo alto.
- Los procesos de software son estables y repetibles.- La organización establece políticas de gerencia deproyectos y procesos.- La planificación se basa en proyectos similares.- Existen estándares definidos y exigidos.
- El proceso se enmarca en un sistema de gerencia deproyectos basado en experiencias pasadas.
Repetible
Productividad ycalidad escasa.Riesgo máximo
- Ausencia de gestión de proyectos.- El proceso de software es cambiante e irregular:- Los planes, estimaciones y calidad son impredecibles.- El rendimiento depende de la capacidad individual de
los miembros del grupo.- Se establecen programas de formación del personal dedesarrollo y mantenimiento.
Inicial
ResultadosCaracterísticasNivel
MODELO DE MADUREZ DE LA CAPACIDAD
5/17/2018 2-Proceso Unificado - slidepdf.com
http://slidepdf.com/reader/full/2-proceso-unificado 58/69
MODELO DE MADUREZ DE LA CAPACIDAD
Productividad ycalidad total.Riesgo nulo.
- Los procesos se mejoran continuamente.- La organización busca lograr el nivel máximo decapacidad.- Se incorporan nuevas tecnologías y métodos para mejorarlos procesos.
Optimizado
Productividad ycalidad alta.Riesgo mínimo.
- Los procesos son medibles o cuantificables- La productividad y la calidad se miden y registran paracada proyecto de la organización.- Se fijan metas cuantitativas de la calidad del software.-Mediante el uso de métricas de software, se crea una basecuantitativa para la evaluación y estimación en proyectosfuturos.
Gestionado
Productividad ycalidad media.Riesgo medio.
-Los procesos son definidos: estandarizados, documentadose institucionalizados.- Los procesos de ingeniería y gerencia son estables y seintegran en uno sólo.- Existe un entendimiento común de los procesos, funcionesy responsabilidades.- La organización mantiene un grupo dedicado a ladefinición, mejoramiento y difusión del proceso deIngeniería de Software.
Definido
ResultadosCaracterísticasNivel
Gestión de la configuración del software
datos
otros
códigoPruebas
Plan
Requisitos técnicos
Cambios enRequisitos de negocio
modelos de software
Cambios enRequisitos de usuario
Cambios en
5/17/2018 2-Proceso Unificado - slidepdf.com
http://slidepdf.com/reader/full/2-proceso-unificado 59/69
Gestión de la configuración del software
programas documentación
datosHay cambiosen muchas
piezas
Gestión de la configuración del software
Existen herramientas que ayudan al control delas versiones a medida que avanzan (SourceForge)
PROCESO
TECNICAS
HERRAMIENTAS
• identificación• control de versiones• control de cambios
• auditoría• informes• construcción
5/17/2018 2-Proceso Unificado - slidepdf.com
http://slidepdf.com/reader/full/2-proceso-unificado 60/69
2.5La fase de Inicio (Inception )
La fase de Inicio (Inception)
Al comenzar un proyecto hay que contestaralgunas preguntas:
¿Cuál es la visión del sistema? ¿Es viable? ¿Se puede comprar o hay que fabricar el sistema? ¿Cuánto va a costar? Y, finalmente ¿seguimos adelante o paramos?
5/17/2018 2-Proceso Unificado - slidepdf.com
http://slidepdf.com/reader/full/2-proceso-unificado 61/69
Objetivos de la fase de Inicio
El objetivo es desarrollar el análisis de
negocio hasta el punto necesario para lapuesta en marcha del proyecto
Para ello, es necesario: Delimitar el alcance y objetivos del proyecto Definir la funcionalidad y capacidades del producto Tener una idea de la arquitectura (arquitectura
candidata) Reducir los riesgos cuanto antes Hacer estimaciones iniciales de costes, agenda
Criterios de evaluación de la fase
Al comienzo de la fase de Inicio, se establecen:
Una planificación provisional
Los criterios de evaluación de la fase. Al final,tendremos que haber sido capaces de: Fijar el ámbito del sistema
Resolver ambigüedades en los requisitos
Determinar una arquitectura candidata
Mitigar los riesgos críticos
Analizar las posibilidades de “negocio” (evaluar el “caso denegocio”)
5/17/2018 2-Proceso Unificado - slidepdf.com
http://slidepdf.com/reader/full/2-proceso-unificado 62/69
Disciplinas en la fase de Inicio Requisitos
Enumerar los requisitos iniciales (características del sistema) Comprender el contexto del sistema Representar los requisitos como casos de uso Recoger los requisitos no funcionales
Análisis Análisis de la arquitectura Análisis de los casos de uso (de algunos representativos)
Diseño Esbozo de la arquitectura
Implementación ¿Prototipo desechable?
Pruebas No
Artefactos de la fase de Inicio
Recursos (incluye Plan de la 1ª iteración)Riesgos posibles y forma de abordarlos
Plan de desarrolloLista de riesgos
Terminología básica del dominioDefine el contexto
GlosarioModelo inicial de dominio
Esbozo inicial
Validar la tecnología
Modelo de análisisModelo de diseñoPrototipos (desechables)
Grandes objetivos y restricciones
Requisitos no funcionales
Describe los requisitos funcionales
VisiónLista de característicasEspecificación adicional
Modelo de casos de uso
¿Beneficios?Cómo vamos aplicar UP a este proyecto
Análisis de negocioCaso de desarrollo
Descripción Artefacto
5/17/2018 2-Proceso Unificado - slidepdf.com
http://slidepdf.com/reader/full/2-proceso-unificado 63/69
Modelo del Dominio y Requisitos
Glosario
Modelo delDominio
Requisitos
Diseño
. . .
Modelo de casos de uso
Casosde uso
:System
foo( x )
diagramas
Conceptos, asociaciones
y atributos
bar( y )
diagramas
**
Modelo de diseño
2.6
La fase de Elaboración
5/17/2018 2-Proceso Unificado - slidepdf.com
http://slidepdf.com/reader/full/2-proceso-unificado 64/69
Objetivos de la fase de Elaboración
Tanto la funcionalidad como el dominio del
problema se estudian en profundidad Se define la arquitectura básica
Se planifica el proyecto considerando recursos
disponibles
Criterios de evaluación de la fase
Al comienzo de la fase de Elaboración:
Se planifica la fase y se forma el equipo Se establecen criterios de evaluación que habrá que
cumplir al final: Respecto a los requisitos:
¿Se han identificado? ¿Se han detallado lo suficiente? En cuanto a la arquitectura:
¿Satisface los requisitos? ¿Es robusta? Los riesgos:
¿Se han eliminado los críticos? ¿Se ha completado la
lista? Evaluar el proyecto:
¿Se puede fijar un precio y una fecha de entrega?
5/17/2018 2-Proceso Unificado - slidepdf.com
http://slidepdf.com/reader/full/2-proceso-unificado 65/69
Disciplinas en la fase de elaboración
Requisitos Encontrar los casos de uso y actores Determinar la prioridad de los casos de uso
Detallar los casos de uso Estructurar el modelo de casos de uso Construir prototipos de las interfaces de usuario
Análisis Análisis de la arquitectura Análisis de los casos de uso Análisis de clases y paquetes
Diseño Diseño de la arquitectura (estilo, subsistemas) Diseño de los casos de uso
Implementación Implementación de la arquitectura base (para una fracción de
casos de uso) Integración del sistema (con bibliotecas de servicios, frameworks )
Pruebas Planificar y diseñar las pruebas Realizar pruebas de integración y de sistema
Artefactos de la fase de Elaboración
Todo lo relacionado con la interfazPrototipos de la interfazde usuario
Qué debe ser probado y cuándoModelo de pruebas
Incluye diagramas de implementación y el códigofuente disponible
Modelo de implementación
Diagramas de paquetes y clasesIdeas fundamentales del diseño que se utilizaráen el sistema
Modelo de diseño Arquitectura del sistema
Diagramas de clasesDiagramas de interacción
Modelo de análisis
La mayoría de los casos de usoConceptos del dominio
Modelo de casos de usoModelo de dominio
Traducción a esquemas de bases de datosModelo de datos
Descripción Artefacto
5/17/2018 2-Proceso Unificado - slidepdf.com
http://slidepdf.com/reader/full/2-proceso-unificado 66/69
2.7
Las fases deConstrucción y Transición
Fase de Construcción
El producto se desarrolla a través de iteraciones Cada iteración involucra análisis, diseño e implementación La arquitectura básica se refina de manera incremental
conforme se construye
Gran parte del trabajo es programación y pruebas Se documenta tanto el sistema construido como el manejo
del mismo Esta fase proporciona un producto construido junto con la
documentación
Al comienzo de esta fase, se asigna personal y se fijan los
criterios de evaluación: Lista de casos de uso implementados Documentación inicial para los usuarios
5/17/2018 2-Proceso Unificado - slidepdf.com
http://slidepdf.com/reader/full/2-proceso-unificado 67/69
Disciplinas en la fase de Construcción
Requisitos Completar los casos de uso y el detalle de los mismos Desarrollar prototipos de interfaz de usuario
Análisis Análisis de los casos de uso añadidos Análisis de clases
Diseño Diseño de los casos de uso añadidos
Implementación Implementación de la arquitectura Implementación de clases y subsistemas Realizar pruebas de unidad Integración del sistema
Pruebas Planificar y diseñar las pruebas Realizar pruebas de integración Realizar pruebas de sistema Evaluar las pruebas
Control en la fase de Construcción
Además de las disciplinas técnicas, es preciso llevar acabo labores de gestión: Control del análisis de negocio
Evaluación de la fase de Construcción Planificación de la fase de Transición
5/17/2018 2-Proceso Unificado - slidepdf.com
http://slidepdf.com/reader/full/2-proceso-unificado 68/69
Artefactos de la fase de Construcción
Versión con capacidad operativa inicial (V. Beta)Sistema ejecutable
Versión inicialManual de usuario
Incluye el código fuenteModelo de implementaciónModelo de pruebas
Conjunto de artefactos producidos hasta ahora
Arquitectura definitiva
Modelo de casos de uso
Modelo de análisisModelo de diseñoModelo de pruebas
Arquitectura del sistema
Situación actual del proyectoPlan para la fase de Transición
Análisis de negocioPlan de proyecto
Descripción Artefacto
Fase de Transición
Se libera el producto y se entrega al usuario para un uso real
Se incluyen tareas de instalación, configuración, entrenamiento,soporte, mantenimiento, etc.
Los manuales de usuario se completan y refinan con lainformación anterior
Estas tareas se realizan también en iteraciones
Al comienzo de la fase, se reasigna personal y se establecen loscriterios de evaluación: ¿Han sido capaces los usuarios de llevar a cabo todos los casos de
usos?
¿Ha superado el producto las pruebas de aceptación? ¿Tiene el manual de usuario una calidad suficiente? ¿Están listos los cursos de formación para los usuarios? ¿Están los usuarios satisfechos?
5/17/2018 2-Proceso Unificado - slidepdf.com
http://slidepdf.com/reader/full/2-proceso-unificado 69/69
Disciplinas en la fase de Transición
El esquema de actividades es distinto del resto de las fases: Preparar la versión de pruebas de aceptación a partir de la versión
inicial
Instalar la versión en los lugares elegidos Incluirá la migración de datos Reaccionar a los resultados de las pruebas
Fallos en un componente, un diseño, un caso de uso Problemas de fondo
Adaptación del producto a entornos variados
¿Cuándo acaba el proyecto? En un producto “a medida”, el punto clave son las pruebas de
aceptación En un producto de venta masiva, el proyecto no acaba nunca
realmente
Bibliografía Recomendada
Somm erville, I . "Ingeniería del software" Pearson, 2005 (7ª ed.) Pressman, Roger S. "Ingeniería del software : un enfoque práctico
MacGraw-Hill", 2005 (6ª ed) Jacobson, I ., Booch, G., Rumbaugh, J. “El Proceso Unificado de
Desarrollo de Software ”. Addison-Wesley, 2000. Larman, C. “UML y Patrones. Introducción al Análisis y Diseño Orientado a Objetos y al Proceso Unificado ”. Prentice Hall, 2004.
Lecturas complementarias
Kruchten, Philippe. "A Software Development Process for a Team of
One", The Rational edge. Feb 2004. http://www.therationaledge.com/
Minister io de Administ raciones Públicas. “MÉTRICA. Versión 3.
Metodología de Planificación, Desarrollo y Mantenimiento de sistemas
de información ”. http://www.map.es/csi/metrica3/. 2001