Post on 19-Sep-2018
1
7. El Proceso Software
Ingeniería del Software I3º I.T.I.Gestión
Miguel A. Laguna
Contenidos
7.1 Modelos de Proceso7.1.1 Modelos genéricos de desarrollo 7.1.2 Métodos de desarrollo orientados a objetos
7.2 El Proceso Unificado de Desarrollo o UnifiedProcess7 3 Fases y disciplinas (o flujos de trabajo)7.3 Fases y disciplinas (o flujos de trabajo)
7.3.1 Fases y puntos de control7.3.2 Disciplinas (flujos de trabajo) 7.3.3 Artefactos
7.4 La fase de Inicio (Inception)7.5 La fase de Elaboración7.6 Las fases de Construcción y Transición
Objetivos del tema
Conocer los distintos modelos de proceso genéricos
Conocer las tendencias actuales en metodología de
desarrollo 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 las
fases y disciplinas del Proceso Unificado
7.1. Modelos de Proceso
7.1.1 Modelos genéricos de desarrollo 7.1.2 Métodos de desarrollo
orientados a objetos
¿Qué es un método?
Resulta necesario establecer un enfoque sistemático y disciplinado para llevar a cabo un desarrollo software
Definiciones:
5
Definiciones:Una metodología de ingeniería del software es un proceso para producir software de forma organizada, empleando una colección de técnicas y convenciones de notación predefinidas
(James Rumbaugh et al.)
Conjunto de procedimientos, técnicas, herramientas y un soporte documental que ayuda a los desarrolladores a realizar nuevo software
(Mario Piattini et al.)
El desarrollo de un sistema se puede explicar también como:
Una secuencia de modelados que ayuda a construir, a partir de la realidad, uno o varios modelos,
Otra visión de Método
6
p , ,derivados unos de otros, con el objetivo de lograr un modelo final o sistema.
Y entonces:Un método es una guía que define las reglas de paso de un modelo a otro para evolucionar progresivamente hasta el modelo final.
2
Modelado
REALIDAD
Lenguaje de especificación
7
Los modelos son representaciones semánticas simplificadas de un sistema para analizarlo y comprenderlo a fin de diseñarlo mejor.
IMPLEMENTACIÓNLenguaje de Programación
Modelos
PROCESO
TECNICAS
HERRAMIENTASUML
UP
TogetherRose
Componentes de un método
Proceso: Define el marco de trabajo y permite un desarrollo racional de la IS
Técnicas: Indican cómo construir técnicamente el software. Incluyen técnicas de modelado
Herramientas: Proporcionan el soporte automático o semiautomático para el proceso y para las técnicas
UP
El proceso software
Un conjunto estructurado de actividades y resultados asociados que conducen a la creación de un producto de software
Especificación: Definir la funcionalidad y las restricciones en sus operacionesDiseño e implementación: Producir software que cumple la especificaciónpValidació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ón abstracta de un proceso. Presenta una descripción de un proceso desde una perspectiva particular.
7.1.1 Modelos genéricos de desarrollo
Modelos de proceso genéricos
No son descripciones exhaustivas de los procesos software.Son abstracciones útiles que explican diferentes enfoques utilizables a la hora de desarrollar software.Son marcos de trabajo del proceso, no detallan las actividades específicas.Se denominan paradigmas de proceso
Modelos de proceso genéricos
El modelo de cascadaSepara y distingue cada fases de especificación y desarrollo
Desarrollo evolutivoSe interpolan la especificación y el desarrollo
Desarrollo formal de sistemasUn modelo matemático del sistema se transforma formalmente a una implementación
Desarrollo basado en reutilizaciónEl sistema se monta a partir de componentes existentes
3
Modelo en Cascada
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
Fases del modelo en cascada
Análisis y definición de requisitosDiseño del sistema y del softwareImplementación y prueba de unidadesIntegración y prueba del sistemaO ió t i i tOperación y mantenimiento
Una fase no comienza hasta que no hayan terminado las anteriores.La desventaja es la dificultad de tener en cuenta los cambios cuando el proceso ya está en marcha
Problemas del Modelo en cascada
Inflexibilidad al dividir el proyecto en estas etapasEs difícil responder a los cambios en los requisitos del clientePor lo tanto este modelo es apropiado sóloPor lo tanto, este modelo es apropiado sólo cuando los requisitos se comprenden muy bien.
Desarrollo evolutivo
Desarrollar una implementación inicial e ir refinándola hasta conseguir el sistema adecuado. Las actividades se realizan concurrentemente.Desarrollo exploratorio
El objetivo es trabajar con los clientes y desarrollar un sistema final con alguna gespecificación inicial. Se debe comenzar teniendo en cuenta los requisitos bien-entendidos. El sistema evoluciona según la nuevas propuestas del cliente.
Prototipos desechablesEl objetivo es comprender los requisitps del cliente y desarrollar un prototipo para evaluar hasta qué punto se han entendido.
Desarrollo evolutivo
Versión Inicial
Actividades concurrentes
Especificación
Bosquejo de la descripción
Versión final
Versiones intermedias
Versiones intermedias
Versiones intermedias
Desarrollo
Validación
Desarrollo evolutivoLa ventaja es que la especificación se desarrolla de
forma creciente.Problemas
Hay que documentar cada versión del sistemaLos sistemas tienen una estructura deficienteSe requieren herramientas y técnicas especialesSe requieren herramientas y técnicas especiales (p.e. conocimientos en lenguajes para el prototipado rápido)
AplicabilidadPara sistemas interactivos pequeños o de tamaño medianoPara partes de sistemas grandes (e.g. el interfaz de usuario)Para sistemas con vida corta
4
Proceso mixtoDesarrollar un prototipo desechable (con enfoque evolutivo) para resolver incertidumbres en la especificación inicial. Reimplementar con un enfoque más estructurado, con un proceso basado en el , pmodelo en cascada.
Desarrollo formal de sistemas
Se basa en la transformación de una especificación “matemática” a un programa ejecutableLas transformaciones preservan la corrección y el programa final es conforme con su y p gespecificación
Desarrollo formal de sistemas
Definición de Especificación Transformación Integración y Definición de Requisitos
Especificación formal
Transformación formal prueba del
sistema
Desmostración de la corrección
Desarrollo formal de sistemas
ProblemasSe necesitan habilidades y el entrenamiento especializados para aplicar la técnicaEs difícil especificar formalmente algunos aspectos del sistema tales como la interfaz de usuario
AplicabilidadSistemas críticos donde la seguridad o la fiabilidad debe garantizarse antes de que el sistema se ponga en explotación
Desarrollo con/para reutilización
Basado en la reutilización sistemática, los sistemas se integran con componentes existentes o con sistemas COTS (Commercial-off-the-shelf)Etapas del proceso
Análisis de componentesModificación de requisitosModificación de requisitosDiseño del sistema con reutilizaciónDesarrollo e integración
Este enfoque se está convirtiendo en el más importante pero todavía hay una experiencia limitada con él
Desarrollo con/para reutilización
Especificación de Requisitos
Análisis de componentes
Modificación de requisitos
Diseño de sistemas con reutilización
Desarrollo e integración
Validación del sistema
5
Modelos iterativos de proceso
En sistemas grandes, es conveniente utilizar diferentes enfoques en las distintas partes.Los requisitos del sistema SIEMPRE evolucionan en el transcurso de un proyecto.Siempre habrá una iteración en el proceso que obligue a rehacer las primeras fases del mismo.La necesidad de iterar aparece independientemente del modelo de proceso genérico utilizadoModelos de proceso que incluyen la iteración:
Desarrollo incrementalDesarrollo en espiral
Desarrollo incremental
Propuesto por Mills en 1980.En vez de entregar el sistema de una vez, tanto el desarrollo com las entregas se dividen en incrementos.Con cada incremento que entrega la parte de la q g pfuncionalidad que se hubiera determinadoLos requisitos del usuario se priorizan y los requisitos de prioridad más alta se incluyen en los incrementos más tempranosCuando el desarrollo de un incremento comienza, sus requisitos son inamovibles, aunque los requisitos de incrementos posteriores pueden continuar desarrollándose
Desarrollo incremental
Definir requisitos iniciales
Asignar requisitos a cada incremento
Diseñar la arquitectura del sistema
Desarrollar incremento
Validar incremento
Integrar incrementos
Validar sistema
Sistema incompleto
Sistema final
Desarrollo incremental
incremento 4 analysis design code test
analysis design code testincremento 2
incremento 3
incremento 1Entrega del
tiempo
incremento 1
Entrega delincremento 2...
analysis design code test
analysis design code test
Ventajas del desarrollo incremental
Los clientes no tienen que esperar hasta tener el sistema completo. El primer incremento satisface los requisitos más críticos.Los primero incrementos sirven como prototipo y ayudan en la tarea de detectar los posteriores requisitos.requisitos.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.
Desarrollo en espiral
Propuesto por Boehm en 1988.El proceso se representa como una espiral más que como una secuencia de actividades con vuelta hacia atrás.Cada vuelta en la espiral representa una fase d ldel proceso.No hay fases fijas como la especificación o diseño. Cada vuelta en la espiral determina las actividades a realizar.
6
Desarrollo en espiral
PlanificaciónAnálisis de riesgos
Comunicación conel usuario
Desarrollo y validaciónEvaluación del usuario
Ingeniería
Sectores del modelo en espiral
Definición de objetivosSe identifican los objetivos de cada fase, las alternativas y las restricciones.
Evaluación y reducción de riesgosSe determinan los riesgos de cada fase y se ponen en marcha las actividades que reduzcan estos riesgos.
Desarrollo y validaciónDesarrollo y validaciónSe elige el modelo de desarrollo más apropiado para el sistema de entre todos los modelos genéricos.
PlanificaciónSe revisa el proyecto y, si se continúa, se planifica la siguiente fase (nueva vuelta a la espiral).
Desarrollo en espiral
Riskanalysis
Riskanalysis
Riskanalysis
Prototype 2Prototype 3
Opera-tionalprotoype
Evaluate alternativesidentif y, resolve risks
Determine ob jectivesalternatives and
cons traints
Riskanalysis Proto-
type 1
Prototype 2 protoype
Concept ofOperation
Simulations, models, benchmarks
S/Wrequirements
Requirementvalidation
DesignV&V
Productdesign Detailed
desi gn
CodeUni t tes t
Integr ationtestAcceptance
testServ ice Develop, verif ynext-level product
Plan next p hase
Integrati onand test p lan
Develop mentplan
Require ments planLife-cycle plan
REVIEW
7.1.2 Métodos de desarrollo orientados a objetos
Generaciones de Métodos
Años 60 y 70:COBOL, FORTRAN, CMétodos de análisis y diseño estructurados
Años 80 y primeros 90:C++, Smalltalk, AdaC++, Smalltalk, AdaMétodos OO de primera generación: OMT, Jacobson
Finales de los 90:JavaUMLMétodos OO avanzados, Proceso Unificado
Análisis Diseño Implementación
DFDSTD
PROGRAMA
PRO
CE
SOS
Métodos estructurados y...
DERRELACIONAL TABLAS
DAT
OS
7
Análisis Diseño Implementación
ses
...Métodos orientados a objetos
Cla
s
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
P di t l
GUI
OO
Interfaz deusuario
L j d ProcedimentalC, Cobol
Relacional
OOC++, Java
OO ?
Lenguaje deprogramación
SGBD
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)- 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 80El método OO más difundido antes de UML/UPAunque tiene cuatro fases definidas, se centra de una forma especial en el análisisPresenta una continuidad respecto a las métodos estructurados
El libro “Object-Oriented Modeling and Design” escrito por Rumbaugh 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.
... OMT
Diagramas de estados
Diagramas de clases
estados
DFDs
8
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 y diseño dentro de un desarrollo OO.
Define una gran cantidad de símbolos para representar las distintas decisiones de diseño.
Se definen dos tipos de procesos que describen los niveles enSe definen dos tipos de procesos que describen los niveles en un desarrollo orientado al objeto:
Macro procesosMicro procesos
Booch, G. "Object-Oriented Analysis and Design with Applications", 2nd edition. Benjamin Cummings, 1993.
Clase
Nombre de la clase
AtributosMétodos()
{restricciones}
Clase utilidad
Nombre de la claseutilidad
AtributosMétodos()
... Método de Booch
Clase parametrizada
Nombre de laclase
parametrizada
Argumentosformales
Argumentosactuales
Nombre de laclase
instanciada
Método de Booch
Diferencia:Modelos estático y dinámicoModelos lógico y físico
Modelo dinámicoEstructura
Modelo Estático
Modelo Lógico
Modelo Físico
Estructura de clases
Arquitectura de módulos
Estructura
de objetos
Arquitectura de procesos
OOSE (Jacobson)
Análisis Construcción Pruebas
Es un método que se basa en la idea de los casos de uso como forma de analizar los requisitos del usuario
El ciclo de vida es similar al modelo básico pero se empieza muy pronto con la interfaz de usuario:
Análisis deRobustez
Especificaciónde requisitos
Modelo derequisitos
Modelo deanálisis
Análisis deRequisitos
Proceso de análisis:
...OOSE: Casos de Uso
Aunque tiene su propia notación, lo más característico son los casos de uso
Cliente remoto Giro por Internet
t d
Jacobson, I., Christerson, M., Jonsson, P., Övergaad, G. “Object Oriented Software Engineering: A Use Case Driven Approach”. Addison-Wesley, 1994.
Identificación
Cliente local
Giro<<uses>>
<<extends>>
Métodos OO (después de UML)
Evolución de métodos clásicosMétrica versión 3
Métodos “ágiles”eXtreme Programming (XP)
Métodos “marco” adaptablesMétodos marco adaptablesOPENProceso Unificado (Unified Process)
9
Métrica Versión 3
Cubre desarrollo estructurado y orientado a objetos
Además del desarrollo, contempla procesos de Planificación y Mantenimiento
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ónImplantación y aceptación
Métrica Versión 3
Métrica 3. Análisis
Objetivo: obtención de una especificación detallada del sistema que satisfaga las necesidades de los usuarios y sirva de base para el posterior diseño del sistema
Métrica 3. Diseño
Objetivo: definir la arquitectura del sistema, el entorno tecnológico y la especificación detallada de los componentes del sistema
Métrica 3. Construcción del SistemasSe genera el código de los componentes, se desarrollan los procedimientos de operación y seguridad y se elaboran los manuales de usuario final y de explotación
Métodos ágiles
Como reacción a los procesos muy burocratizados surgen los métodos ágilesPropuesta por Beck en 1999.Nuevo enfoque basado en el desarrollo y la entrega de incrementos de funcionalidad muyentrega de incrementos de funcionalidad muy limitada.Confía en la mejora constante del código, implicación del usuario en el equipo de desarrollo y la programación “sin complejos”.
10
eXtreme Programming (XP)
Características de eXtreme Programming:Ciclos muy cortos de desarrolloSistemas con funcionalidad mínimaÚnicamente las tareas de alta prioridadImportancia de las personasp p
Conjunto de “buenas prácticas”:Programación por paresPruebas continuasRefactorización (refactoring) continua
7.2 El Proceso Unificado de Desarrollo (Unified Process)
UML no es suficiente Características del Proceso Unificado
Componentes de un Método
Elementos de modeladoUn conjunto fundamental de conceptos de modelado para capturar el conocimiento semántico sobre un problema y su soluciónLos conceptos de modelado son independientes de cómo se visualizan
Notaciónd lUn conjunto de vistas y notaciones para presentar la
información de modelado subyacente que permite a las personas examinarlos y modificarlos
ProcesoTiene como cometido la formalización de las actividades relacionadas con la elaboración de sistemas software
ExperienciaUna colección de reglas y heurísticas para llevar a cabo el desarrollo
Personas, Equipos,
UML no es un método
Experiencia
Lenguajede Modelado Proceso
?
¿Qué es un Proceso?
Describe un conjunto de actividades que deben realizarse en un determinado orden
qué hacer, cómo hacerlo, cuando hacerlo y el motivo por el cual debe ser hecho
Debe ser:ReproducibleDefinidoMedible en cuanto a rendimientoOptimizable...
Nuevos
Requisitos
Sistema
Nuevo
Proceso software
Dos elementos complementarios
UML Proceso Unificado
• Proceso marco adaptable
• No es un estándar en sí
• Estándar OMG
11
Antecedentes del Proceso Unificado
Rational Unified Process 5.01998
Unified Process1999
SPEM(2002)
E tá d
Rational Objectory Process 4.11996-1997
Objectory Process 1.0-3.81987-1995
Ericsson (Jacobson)
Rational
UML
Estándares OMG
Software Process Engineering Metamodel
OMG SPEM, 2002
UP es un Proceso “marco”
No existe un proceso UniversalUP es flexible y extensible:
Permite varias estrategias de desarrolloSe pueden definir diferentes conjuntos de productosSe pueden definir actividades y encargados de las mismas
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 finalSe 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 de riesgos
Conducido por Casos de uso
Requisitos Implement. Pruebas
Los casos de uso integran todas las actividades
Análisis Diseño
Los casos de uso integran todas las actividades
Capturar, clarificar y validar los casos de uso
Realizar los casos de uso
Verificar que se satisfacen los casos de uso
Centrado en la Arquitectura
La arquitectura describe los elementos fundamentales del sistema:
Subsistemas DependenciasInterfacesColaboracionesNodosClases activas...
Incluye decisiones importantes sobre:Organización del sistemaElementos estructurales, interfaces y su comportamientoComposición y comportamiento de los subsistemasEl estilo de la arquitectura que guía esta organización
12
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
Vista deVista de
(Philippe Kruchten)
Vista LógicaVista Lógica Vista de Realización
Vista de Realización
Vista deProcesosVista deProcesos
Vista de DespliegueVista de
Despliegue
Vista deCasos de Uso
Arquitectura y Modelos
Modelos
Modelo de casos de uso
Modelo dediseño
Modelo de despliegue
Modelo de Implement.
Modelo de análisis
Modelo de Pruebas
La arquitectura incorpora una colección de vistas de los modelos
Vistas
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
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 sistemaUna serie de desarrollos cortos (mini proyectos de 2 a 6 semanas, cada iteración reproduce el ciclo de vida a menor escala)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
Etapa de Ingeniería Etapa de Producción
Inicio Elaboración Construcción Transición
Iterativo: varias espirales
Visión Arquitectura Versiones Beta Productos
13
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 elCodificación y pruebas. La integración del nuevo código con el existente de iteraciones anteriores se hace gradualmente durante la construcción
Evaluación de la entrega ejecutable (evaluación del prototipo en función de las pruebas y de los criterios definidos)
Preparación de la entrega (documentación e instalación del prototipo)
Primero, la arquitectura, Después, se van añadiendo los detalles según avanza el desarrollo
Etapa de Ingeniería Etapa de producción
Incremental
Inicio Elaboración Construcción Transición
Req
uisi
tos
Dis
eño
Impl
emen
taci
ón
Inst
alac
ión
Gestión
Req
uisi
tos
Dis
eño
Impl
emen
taci
ón
Inst
alac
ión
Gestión
Req
uisi
tos
Dis
eño
Impl
emen
taci
ón
Inst
alac
ión
Gestión
Req
uisi
tos
Dis
eño
Impl
emen
taci
ón
Inst
alac
ión
Gestión
Visión Arquitectura Versiones Beta Productos
7.3 Fases y disciplinas (o flujos de trabajo)
Fases y puntos de controlDisciplinas (Flujos de trabajo) Artefactos
Elementos del Proceso UnificadoFases:
Es preciso diferenciar temporalmente las fases del ciclo de vidaLa 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ónCada una de las dos grandes etapas se dividen en fasesL f di id i iLas fases se dividen en iteraciones
iteración fase
Ciclo de desarrollo
Etapa de Ingeniería Etapa de Producción
Etapas y fases del ciclo de vida
Etapa de Ingeniería: equipos pequeños, actividades poco predecibles (análisis, viabilidad, planificación). Las fases son:
InicioElaboración
Etapa de Producción: equipos grandes actividades
tiempo
Inicio Elaboración Construcción Transición
Etapa de Producción: equipos grandes, actividades predecibles, menos riesgos (programación, pruebas). Las fases son:
ConstrucciónTransición
14
Objetivos de las fases
Inicio del proyecto (inception)Define el ámbito y objetivos del proyecto
ElaboraciónDefine la funcionalidad y una arquitectura básica
ConstrucciónEl producto se desarrolla a través de iteraciones
TransiciónSe libera el producto y se entrega al usuario para su uso real
Hitos
Los hitos son puntos de control en los cuales los participantes en el proyecto revisan el progreso del proyecto.
Se pretende:Sincronizar las expectativas y la realidadSincronizar las expectativas y la realidadIdentificar los riesgosSe evalua la situación global del proyecto
Se necesitan:Resultados tangibles para comparar con las expectativas
Varios niveles:Hitos principales al final de cada faseHitos secundarios final de cada iteración
Hitos principales y secundarios
Visión Arquitecturabásica
Capacidad inicial
Productofinal
tiempo
Inicio Elaboración Construcción Transición
básica inicial final
Una iteración es una secuencia de actividades con un plan establecido y unos criterios de evaluación, cuyo resultado es una versión ejecutable (hito secundario)
Release Release Release Release Release Release ReleaseRelease
Disciplinas o flujos de trabajo
Organizan las actividades fundamentales de gestión y desarrollo 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, las distintas actividades del equipo de desarrollo se pueden solapar en el tiempo.
Fases, iteraciones y disciplinasFases
Requisitos
Análisis
Disciplinas: Inicio Elaboración Construcción Transición
iter.#1
iter.#2
iter.#n
iter.#n+1
iter.#n+2
iter.#m
iter.#m+1
Diseño
Implementación
Pruebas
Iteraciones
Iteraciones
preliminares
Fases y disciplinas: SPEM
La propuesta de proceso estándar admite distintas combinaciones de disciplinas y fases
Disciplinas:
Modelado del negocio
Requisitos
Di ñ
Inicio Elaboración Construcción Transición
Iteraciones
Diseño
Implementación
Prueba
Despliegue
Gestión de la Configuración
Gestión del Proyecto
Entorno
15
El detalle de cada disciplina
Pero hay que definir cada disciplina en detalle
Disciplinas:
Modelado del negocio
Requisitos
Di ñ
Inicio Elaboración Construcción Transición
Iteraciones
Diseño
Implementación
Prueba
Despliegue
Gestión de la Configuración
Gestión del Proyecto
Entorno
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 artefactosDiagramas UMLCódigo fuente Ejecutables Casos de prueba...
Los modelos son los artefactos básicos que producen las disciplinas
Disciplinas de desarrollo y modelos
Modelo de casos de uso
Modelo de análisis
Los diagramas UML representan vistas de cada modelo
Requisitos
Análisis
Modelo dediseño
Modelo de despliegue
Modelo de Implement.
Modelo de Pruebas
Cada disciplina se asocia con modelos
Diseño
Implementación
Pruebas
Modelo de casos de uso
Modelo de casos de uso
Modelo de
Modelo de análisis
Diagramas de casos de uso
Diagramasde componentes
Diagramas
Diagramasde objetos
Diagramasde clases
diseño
Modelo de despliegue
Modelo de Implement.
Modelo de Pruebas
Diagramasde colaboración
de despliegue
Diagramasde estados
Diagramasde secuencia
Diagramasde actividades
Modelos de análisis y diseñoDiagramas
de casos de uso
Diagramasde componentes
Diagramas
Diagramasde objetos
Diagramasde clases
Modelo de casos de uso
Modelo de
Modelo de análisis
Diagramasde colaboración
de despliegue
Diagramasde estados
Diagramasde secuencia
Diagramasde actividades
diseño
Modelo de despliegue
Modelo de Implement.
Modelo de Pruebas
7.4 La fase de Inicio (Inception)
16
La fase de Inicio (Inception)
Al comenzar un proyecto hay que contestar algunas preguntas:
¿Cuál es la visión del sistema?¿Es viable?¿Es viable?¿Se puede comprar o hay que fabricar el sistema?¿Cuánto va a costar?Y, finalmente ¿seguimos adelante o paramos?
Objetivos de la fase de Inicio
El objetivo es desarrollar el análisis de negocio hasta el punto necesario para la puesta en marcha del proyecto
llPara ello, es necesario:Delimitar el alcance y objetivos del proyectoDefinir la funcionalidad y capacidades del productoTener 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 de negocio”)
Disciplinas en la fase de InicioRequisitos
Enumerar los requisitos iniciales (objetivos y requisitos funcionales)Comprender el contexto del sistemaRepresentar los requisitos funcionales como casos de usoRecoger los requisitos no funcionales
AnálisisAnálisis de la arquitecturaAnálisis de los casos de uso (de algunos representativos)
DiseñoEsbozo de la arquitectura
Implementación¿Prototipo desechable?
PruebasNo
Artefactos de la fase de Inicio
Artefacto Descripción
VisiónEspecificación inicial de Requisitos Modelo de casos de uso
Grandes objetivos y restriccionesObjetivos y Requisitos funcionalesRequisitos no funcionalesDescribe los requisitos funcionales
GlosarioModelo inicial de dominio
Terminología básica del dominioDefine el contextoModelo inicial de dominio Define el contexto
Modelo de análisisModelo de diseñoPrototipos (desechables)
Esbozo inicial
Validar la tecnología
Plan de desarrolloLista de riesgos
Recursos (incluye Plan de la 1ª iteración)Riesgos posibles y forma de abordarlos
Análisis de negocioCaso de desarrollo
¿Beneficios?Cómo vamos aplicar UP a este proyecto
Modelo del Dominio y Requisitos
Modelo delDominio
Modelo de casos de uso
Conceptos, asociaciones y atributos *
*
GlosarioRequisitos
Diseño
. . .
Casos de uso
:System
diagramasdiagramas
Modelo de diseño
17
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 en cada desarrollo concreto
Uno de los artefactos iniciales es el “Caso de desarrollo”:Qué artefacto es necesario en cada disciplinaEn qué fase se creaEn qué fases se actualiza
Esta posibilidad permite tanto desarrollos “pesados” como “ágiles”
Ejemplo de un “Caso de desarrollo”
Disciplina Artefacto Inicio Elabora-ción
Construc-ción
Tran-sición
Requisitos Modelo de casos de usoVisiónGlosarioModelo del dominio
III
RRRI
Análisis Modelo de análisis I RAnálisis Modelo de análisis I R
Diseño Modelo de diseñoArquitecturaModelo de datos
III
RRR
Implementación Modelo de implementación I R R
Pruebas Modelo de pruebas I R
Gestión del Proyecto
Plan de desarrollo I R R R
Entorno Caso de desarrollo I R
7.5 La fase de Elaboración
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 equipoSe 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?
Disciplinas en la fase de elaboración
RequisitosEncontrar los casos de uso y actoresDeterminar la prioridad de los casos de usoDetallar los casos de usoEstructurar el modelo de casos de usoConstruir prototipos de las interfaces de usuario
AnálisisAnálisis de la arquitecturaqAnálisis de los casos de usoAnálisis de clases y paquetes
DiseñoDiseño de la arquitectura (estilo, subsistemas)Diseño de los casos de uso
ImplementaciónImplementación de la arquitectura base (para una fracción de casos de uso)Integración del sistema (con bibliotecas de servicios, frameworks)
PruebasPlanificar y diseñar las pruebasRealizar pruebas de integración y de sistema
18
Artefactos de la fase de Elaboración
Artefacto Descripción
Modelo de casos de usoModelo de dominio
La mayoría de los casos de usoConceptos del dominio
Modelo de análisis Diagramas de clases Diagramas de interacción
M d l d di ñ Di d t lModelo de diseñoArquitectura del sistema
Diagramas de paquetes y clases Ideas fundamentales del diseño que se utilizará en el sistema
Modelo de pruebas Qué debe ser probado y cuándo
Modelo de implementación Incluye diagramas de implementación y el código fuente disponible
Prototipos de la interfaz de usuario
Todo lo relacionado con la interfaz
Modelo de datos Traducción a esquemas de bases de datos
7.6 Las fases de Construcció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ónLa arquitectura básica se refina de manera incremental conforme se construye
Gran parte del trabajo es programación y pruebasSe documenta tanto el sistema construido como el manejoSe documenta tanto el sistema construido como el manejo del mismoEsta 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 implementadosDocumentación inicial para los usuarios
Disciplinas en la fase de Construcción
RequisitosCompletar los casos de uso y el detalle de los mismosDesarrollar prototipos de interfaz de usuario
AnálisisAnálisis de los casos de uso añadidosAnálisis de clases
DiseñoDiseño de los casos de uso añadidosDiseño de los casos de uso añadidos
ImplementaciónImplementación de la arquitectura Implementación de clases y subsistemasRealizar pruebas de unidadIntegración del sistema
PruebasPlanificar y diseñar las pruebasRealizar pruebas de integración Realizar pruebas de sistemaEvaluar las pruebas
Control en la fase de Construcción
Además de las disciplinas técnicas, es preciso llevar a cabo labores de gestión:
Control del análisis de negocioEvaluación de la fase de ConstrucciónPlanificación de la fase de Transición
Artefactos de la fase de Construcción
Artefacto Descripción
Modelo de casos de usoModelo de análisisModelo de diseñoModelo de pruebasArquitectura del sistema
Conjunto de artefactos producidos hasta ahora
Arquitectura definitivaArquitectura del sistema Arquitectura definitiva
Modelo de implementaciónModelo de pruebas
Incluye el código fuente
Sistema ejecutable Versión con capacidad operativa inicial (V. Beta)
Manual de usuario Versión inicial
Análisis de negocioPlan de proyecto
Situación actual del proyectoPlan para la fase de Transición
19
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 la información anterior
Estas tareas se realizan también en iteraciones
Al comienzo de la fase, se reasigna personal y se establecen los criterios 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?
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 inicialInstalar la versión en los lugares elegidos
Incluirá la migración de datosReaccionar a los resultados de las pruebas
Fallos en un componente, un diseño, un caso de usoProblemas de fondo
Adaptación del producto a entornos variadosAdaptació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
Larman, C. “UML y Patrones. Introducción al Análisis y Diseño Orientado a Objetos y al Proceso Unificado ”. Prentice Hall, 2004. cap. 2 (UP)
Sommerville, I. "Ingeniería del software" Pearson, 2005 (7ª ed.), cap. 4 (modelos de proceso), 5 y 26..29 (gestión)
Pressman, Roger S. "Ingeniería del software : un enfoque práctico MacGraw-Hill", 2005 (6ª ed) , cap. 21..27 (gestión)
Lecturas complementariasJacobson, I., Booch, G., Rumbaugh, J. “El Proceso Unificado de Desarrollo de Software”. Addison-Wesley, 2000.
Kruchten, Philippe. "A Software Development Process for a Team of One", The Rational edge. Feb 2004. http://www.therationaledge.com/
Ministerio de Administraciones 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