Contenidos
Tema 3. n 3.1 Métodos actuales de desarrollo OO
El Método de desarrollo.
El Proceso Unificado
Miguel A. Laguna
Objetivos del tema
n Conocer las tendencias actuales en metodología de
desarrollo y los esfuerzos de estandarización
n Conocer la propuesta del MAP: Métrica 3
n Aprender los principios del Proceso Unificado de
Desarrollo
n Aprender la diferencia ente fase y disciplina
n Relacionar las técnicas de modelado de UML con las
distintas fases y disciplinas del Proceso Unificado
n
n
3.1.1 Concepto de Método y Proceso
3.1.2 Generaciones de métodos OO
n 3.2 El Proceso Unificado de Desarrollo o Unified
Process
n 3.2.1 UML no es suficiente
n 3.2.3 Características del Proceso Unificado
n 3.3 Fases y disciplinas (o flujos de trabajo)
n 3.3.1 Fases y puntos de control
n 3.3.2 Disciplinas (flujos de trabajo)
n 3.3.3 Artefactos
n 3.4 La fase de Inicio ( Inception)
n 3.5 La fase de Elaboración
n 3.6 Las fases de Construcción y Transición
3.1
Métodos actuales de desarrollo OO
n Concepto de Método
n Generaciones de Métodos OO:
n Métodos de primera y segunda generación
Métrica 3, Procesos Ágiles y Proceso Unificado
n
1
 Concepto de Método (o Metodología) ...Concepto de Método
n Resulta necesario establecer un enfoque sistemático
y disciplinado para llevar a cabo un desarrollo
n El desarrollo de un sistema se puede explicar también
software
como:
n Una secuencia de modelados que ayuda a construir, a partir de
n Definiciones: la realidad, uno o varios modelos, derivados unos de otros, con
n Una metodología de ingeniería del software es un proceso el objetivo de lograr un modelo final o sistema.
para producir software de forma organizada, empleando una
colección de técnicas y convenciones de notación
predefinidas n Y entonces:
(James Rumbaugh et al.) n Un método es una guía que define las reglas de paso de un
modelo a otro para evolucionar progresivamente hasta el
n Conjunto de procedimientos, técnicas, herramientas y un modelo final.
soporte documental que ayuda a los desarrolladores a
realizar nuevo software
(Mario Piattini et al.)

Modelado Generaciones de Métodos OO

n Años 60 y 70:
REALIDAD n COBOL, FORTRAN, C
Lenguaje de especificación n Métodos de análisis y diseño estructurados
n Años 80 y primeros 90:
Modelos n C++, Smalltalk, Ada
n Métodos OO de primera generación: OMT,
Lenguaje de Jacobson
Programación IMPLEMENTACIÓN
n Finales de los 90:
n Java
n Los modelos son representaciones semánticas
simplificadas de un sistema para analizarlo y n UML
comprenderlo a fin de diseñarlo mejor. n Métodos OO avanzados, Proceso Unificado

2
 Métodos estructurados y... ...Métodos orientados a objetos

Análisis Diseño Implementación

PROCESOS STD
DFD PROGRAMA Análisis Diseño Implementación

Clases
DATOS

RELACIONAL TABLAS
DER

Métodos OO (antes de UML) OMT ( Object Modeling Technique)

• Métodos dirigidos por los datos (data-driven) n Desarrollado en General Electric a finales de los 80
- OMT (Rumbaugh et al. 1991) n El método OO más difundido antes de UML/U P
- FUSION (Coleman et al. 1994) n Aunque tiene cuatro fases definidas, se centra de una forma
especial en el análisis
• Métodos dirigidos por responsabilidades
n Presenta una continuidad respecto a las métodos estructurados
(responsability-driven)
- RDD (Wirfs- Brock et al. 1990)
- OBA ( Rubin y Goldberg 1992)
n El libro “Object -Oriented Modeling and Design” escrito por
• Métodos dirigidos por casos de uso Rumbaugh et al. en 1991 es un best-seller mundial:
(use case-driven)
- OOSE/Objectory (Jacobson et al. 1992) & Rumbaugh, James, Blaha, Michael, Premerlani, William, Eddy,
Frederick, Lorensen, William. “Modelado y Diseño Orientados a
• Métodos dirigidos por estados (state-driven) Objetos. Metodología OMT”. 2ª Reimpresión. Prentice Hall. 1998.
- Shlaer y Mellor ( Shlaer y Mellor 1992)

3
 ... OMT Método de Booch

n Es uno de los más conocidos

n En su versión de 1993 este método cubre las fases de análisis y
Diagramas de diseño dentro de un desarrollo OO.
clases
n Define una gran cantidad de símbolos para representar las
distintas decisiones de diseño.
Diagramas de
estados n Se definen dos tipos de procesos que describen los niveles en
un desarrollo orientado al objeto:
DFDs n Macro procesos
n Micro procesos

& Booch, G. "Object-Oriented Analysis and Design with

Applications", 2nd edition. Benjamin Cummings, 1993.

Método de Booch ... Método de Booch

n Diferencia:
Clase Clase utilidad
n Modelos estático y dinámico
n Modelos lógico y físico Nombre de la clase
Nombre de la clase
utilidad
Atributos
Modelo dinámico Métodos() Atributos
{restricciones} Métodos()
Estructura
Modelo Estático
de objetos
Clase parametrizada
Modelo Lógico Estructura de clases
Arquitectura Argumentos Argumentos
formales actuales
de procesos
Nombre de la Nombre de la
Arquitectura de módulos
Modelo Físico clase clase
parametrizada instanciada

4
 OOSE (Jacobson) ...OOSE: Casos de Uso
n Es un método que se basa en la idea de los casos de uso como
n Aunque tiene su propia notación, lo más característico son los
forma de analizar los requisitos del usuario casos de uso

n El ciclo de vida es similar al modelo básico pero se empieza muy

pronto con la interfaz de usuario:
Cliente remoto Giro por Internet
Análisis Construcción Pruebas
<<extends>>

Cliente local
Proceso de análisis:
<<uses>> Giro

Identificación

Especificación Análisis de Análisis de

de requisitos Requisitos Robustez

& Jacobson, I., Christerson, M., Jonsson, P., Övergaad, G. “Object

Modelo de Modelo de Oriented Software Engineering: A Use Case Driven Approach ”.
requisitos análisis Addison -Wesley, 1992.

Métodos OO (después de UML) Métrica Versión 3

n Evolución de métodos clásicos n Cubre desarrollo estructurado y orientado a objetos

n Métrica versión 3
n Además del desarrollo, contempla procesos de Planificación y
n Métodos “ágiles” Mantenimiento
n eXtreme Programming (XP)
n Facilita la realización de los procesos de apoyo u organizativos
n Métodos “marco” adaptables
n OPEN n Procesos principales de desarrollo en Métrica 3:
n Proceso Unificado (Unified Process) n Estudio de Viabilidad del Sistema
n Análisis del Sistema de Información
n Diseño del Sistema de Información
n Construcción del Sistema de Información
n Implantación y aceptación

5
Métrica Versión 3 Métrica 3. Análisis
n 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 Métrica 3. Construcción del Sistemas

Se genera el código de los componentes, se
n Objetivo : definir la arquitectura del sistema, desarrollan los procedimientos de operación y
el entorno tecnológico y la especificación seguridad y se elaboran los manuales de usuario
detallada de los componentes del sistema final y de explotación

6
eXtreme Programming (XP)

n Como reacción a los procesos muy

burocratizados surgen los métodos ágiles
3.2
n Características de eXtreme Programming:
El Proceso Unificado de Desarrollo
n Ciclos muy cortos de desarrollo
(Unified Process)
n Sistemas con funcionalidad mínima
n Únicamente las tareas de alta prioridad
n Importancia de las personas n UML no es suficiente
n Conjunto de “buenas prácticas”: n Características del Proceso Unificado

n Programación por pares

n Pruebas continuas
n Refactorización (refactoring) continua

Componentes de un Método UML no es un método

n Elementos de modelado
n Un conjunto fundamental de conceptos de modelado para
capturar el conocimiento semántico sobre un problema y su
solución
n Los conceptos de modelado son independientes de cómo se
visualizan
n Notación Personas, Equipos,
n Un conjunto de vistas y notaciones para presentar la Experiencia
información de modelado subyacente que permite a las
personas examinarlos y modificarlos

n Proceso
Tiene como cometido la formalización de las actividades Lenguaje
n
Proceso
relacionadas con la elaboración de sistemas software de Modelado
n Experiencia
n Una colección de reglas y heurísticas para llevar a cabo el
desarrollo
?

7
 ¿Qué es un Proceso? Dos elementos complementarios
n 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
n

debe ser hecho UML Proceso

Unificado
§ Debe ser:
n Reproducible
n Definido
n Medible en cuanto a rendimiento • Estándar • Proceso
n Optimizable... OMG marco
adaptable
Nuevos Proceso Sistema
• Estándar en
software fase de
Requisitos Nuevo
propuesta

Antecedentes del Proceso Unificado Software Process Engineering Metamodel

Unified Process
SPEM
OMG
1999
(2002) SPEM,
2002
Rational Unified Process 5.0
1998

Estándares
OMG
Rational Objectory Process 4.1
1996-1997

UML
Objectory Process 1.0- 3.8
Rational 1987-1995

Ericsson ( Jacobson)

8
 UP es un Proceso “marco” Características del Proceso Unificado

n Está dirigido por los casos de uso:

n Desde la especificación hasta el mantenimiento

n Se centra en la arquitectura:
n La arquitectura es prioritaria desde el principio hasta el
final
n No existe un proceso Universal n Se facilita el refinamiento progresivo de la arquitectura
n UP es flexible y extensible:
n Permite varias estrategias de desarrollo n Iterativo e incremental:
n Se pueden definir diferentes conjuntos de productos n El trabajo se divide en iteraciones pequeñas en función
de la importancia de los casos de uso y el análisis de
n Se pueden definir actividades y encargados de las
riesgos
mismas

Conducido por Casos de uso Centrado en la Arquitectura

n La arquitectura describe los elementos
fundamentales del sistema:
n Subsistemas
Requisitos Análisis Diseño Implement. Pruebas
n Dependencias
n Interfaces
Los casos de uso integran todas las actividades n Colaboraciones
n Nodos
n Clases activas...
Capturar , clarificar y Realizar los casos de Verificar que se
validar los casos de u s o uso satisfacen los casos
de uso n Incluye decisiones importantes sobre:
n Organización del sistema
n Elementos estructurales, interfaces y su comportamiento
n Composición y comportamiento de los subsistemas
n El estilo de la arquitectura que guía esta organización

9
 Modelo de Arquitectura: 4 + 1 vistas Arquitectura y Modelos
n Los modelos son instrumentos para visualizar, especificar,
construir y documentar la arquitectura del sistema
Modelo de Modelo de Modelo de Modelo de Modelo de Modelo de
casos de uso análisis diseño despliegue Implement. Pruebas
n Cada vista es una parte de u n modelo
Modelos

Vista de
Vista Lógica
Realización
Vista de
Casos de Uso
Vistas
Vista de Vista de
Procesos Despliegue La arquitectura incorpora una colección de vistas de los modelos
(Philippe Kruchten)

Estructura y función Proceso iterativo e incremental

...Pero la característica fundamental de UP:
n Es un proceso iterativo
n Se basa en la ampliación y el refinamiento del sistema
n Una serie de desarrollos cortos (mini proyectos de 2 a 6
semanas, cada iteración reproduce el ciclo de vida a menor
Casos de uso Arquitectura escala)
n No sólo se mejora sino que el sistema también crece:
Proceso iterativo e incremental
Funcionalidad
• Los casos de uso especifican las funciones del sistema Incremento2
• La arquitectura especifica la la estructura Análisis Diseño Implementación Prueba
• Los casos de uso y la arquitectura deben estar en Incremento1

equilibrio
Análisis Diseño Implementación Prueba

Tiempo

10
 Proceso iterativo e incremental Iterativo: varias espirales
n El resultado de cada iteración es un sistema ejecutable
(aunque sea incompleto y no esté listo para su instalación) Etapa de Ingeniería Etapa de Producción
n Un sistema instalable requiere varias iteraciones
Inicio Elaboración Construcción Transición
§ 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)
Visión Arquitectura Versiones Beta Productos
§ La realimentación del usuario es fundamental en este proceso
§ El progreso es visible

Cada iteración comprende: Incremental

n Planifica ción de la iteración (estudio de riesgos) n Primero, la arquitectura ,
n Después, se van añadiendo los detalles según avanza el desarrollo
n Análisis de Casos de u so y escenarios

n Diseño de opciones arquitectónicas

Etapa de Ingeniería Etapa de producción

n Codificación y pruebas. La integración del nuevo código con el Inicio Elaboración Construcción Transición
existente de iteraciones anteriores se hace gradualmente durante
la construcción

Implemen tación

Implemen tación

Implemen tación

Implemen tación
Diseño

Diseño

Diseño

Diseño
Instalación

Instalación

Instalación

Instalación
Requisitos

Requisitos

Requisitos

Requisitos
n Evaluación de la entrega ejecutable (evaluación del prototipo en
función de las pruebas y de los criterios definidos)
Gestión Gestión Gestión Gestión
n Preparación de la entrega (documentación e instalación del
prototipo)
Visión Arquitectura Versiones Beta Productos

11
 Gestión del riesgo
§ El análisis de ries gos consiste en evaluar el proyecto, la
tecnología y los recursos con el fin determinar y comprender la 3.3
naturaleza y el origen de los riesgos
Fases y disciplinas
§ Posibles riesgos: (o flujos de trabajo)
§ Comerciales (competencia, etc.)
n Financieros (económicos, etc.)
n Técnicos (¿base tecnológica sólida y probada?)
n De desarrollo (¿equipo experimentado?) n Fases y puntos de control
n Disciplinas (Flujos de trabajo)
§ Cada iteración se centra en los riesgos más importantes n Artefactos

Elementos del Proceso Unificado Planificación temporal del proyecto

n Fases:
n Es preciso diferenciar temporalmente las fases del ciclo de vida § UP propone una serie de ciclos de desarrollo:
n La división temporal necesita... § Hay que separar claramente la etapa de Ingeniería
de la etapa de Producción
Puntos de control o hitos:
n Cada una de las dos grandes etapas se dividen en
n

Separan las etapas, las fases, las iteraciones

fases
n

n Disciplinas o Flujos de trabajo: n Las fases se dividen en iteraciones

n Organizan las actividades fundamentales de gestión y desarrollo Ciclo de desarrollo
n Se pueden solapar en el tiempo.
iteración fase
n El resultado de las actividades de los flujos de trabajo son...

n Artefactos:
n Cualquier tipo de información producida por los desarrolladores de un
sistema (diagramas UML, código, ejecutables, casos de prueba...)
n Se construyen de forma incremental
Etapa de Ingeniería Etapa de Producción

12
 Etapas y fases del ciclo de vida Objetivos de las fases

§ Etapa de Ingeniería: equipos pequeños, actividades poco § Inicio del proyecto (inception)
predecibles (análisis, viabilidad, planificación). Las fases son: n Define el ámbito y objetivos del proyecto
n Inicio
§ Elaboración
n Elaboración
n Define la funcionalidad y una arquitectura
básica
n Etapa de Producción: equipos grandes, actividades
predecibles, menos riesgos (programación, pruebas). Las § Construcción
fases son: n El producto se desarrolla a través de iteraciones
n Construcción
§ Transición
n Transición
n Se libera el producto y se entrega al usuario
Inicio Elaboración Construcción Transición para su uso real

tiempo

Hitos Hitos principales y secundarios

n Los hitos son puntos de control en los cuales los

Inicio Elaboración Construcción Transición
participantes en el proyecto revisan el progreso del
proyecto. tiempo

n Se pretende: Visión Arquitectura Capacidad Producto

n Sincronizar las expectativas y la realidad básica inicial final
n Identificar los riesgos
n Se evalua la situación global del proyecto
n Se necesitan:
n Resultados tangibles para comparar con las expectativas
n Varios niveles: Release
Release Release Release Release Release Release Release
Una iteración es una secuencia de actividades con un plan establecido
n Hitos principales al final de cada fase y unos criterios de evaluación, cuyo resultado es una versión
n Hitos secundarios final de cada iteración ejecutable (hito secundario)

13
 Disciplinas o flujos de trabajo Fases, iteraciones y disciplinas
Fases
n Organizan las actividades fundamentales de gestión y
Disciplinas: Inicio Elaboración Construcción Transición
desarrollo del proyecto
Requisitos

n Disciplinas de desarrollo: requisitos, análisis, diseño,

implementación, pruebas, etc. Análisis

n Disciplinas de gestión o soporte: gestión de proyecto, Diseño

gestión de configuraciones, entorno, evaluación, etc.
Implementación
n Al contrario de lo que ocurre con las fases, las
distintas actividades del equipo de desarrollo se Pruebas
pueden solapar en el tiempo.
Iteraciones iter. iter. iter. iter. iter. iter. iter.
preliminares #1 #2 #n #n+1 #n+2 #m #m+1

Iteraciones

Fases y disciplinas: SPEM El detalle de cada disciplina

n La propuesta de proceso estándar admite distintas n Pero hay que definir cada disciplina en detalle
combinaciones de disciplinas y fases
Disciplinas: Inicio Elaboración Construcción Transición Disciplinas: Inicio Elaboración Construcción Transición

Modelado del negocio Modelado del negocio

Requisitos Requisitos

Diseño Diseño

Implementación Implementación

Prueba Prueba

Despliegue Despliegue
Gestión de la Gestión de la
Configuración Configuración

Gestión del Proyecto Gestión del Proyecto

Entorno Entorno

Iteraciones Iteraciones

14
Artefactos Disciplinas y modelos principales
Los diagramas UML
n Definición de artefacto (o producto): representan vistas de
n Cualquier tipo de información producida por los cada modelo
desarrolladores de un sistema. Requisitos Modelo de
casos de uso

n Se construyen de forma incremental Análisis Modelo de

análisis

n Tipos de artefactos Diseño Modelo de Modelo de

despliegue
n Diagramas UML diseño

n Código fuente
n Ejecutables Implementación Modelo de
Implement.
n Casos de prueba...

Pruebas Modelo de
n Los modelos son los artefactos básicos que producen Pruebas
las disciplinas (incluyen otros artefactos) Cada disciplina se
asocia con modelos

Modelo de casos de uso Modelos de análisis y diseño

Diagramas Diagramas
de casos de uso de casos de uso
Modelo de Modelo de
casos de uso Diagramas Diagramas casos de uso Diagramas Diagramas
de clases de objetos de clases de objetos
Modelo de Modelo de
análisis Diagramas análisis Diagramas
de componentes de componentes

Modelo de Diagramas Modelo de Diagramas

diseño de despliegue diseño de despliegue

Diagramas Diagramas
Modelo de de secuencia Modelo de de secuencia
despliegue despliegue

Diagramas Diagramas
Modelo de de colaboración Modelo de de colaboración
Implement. Implement.
Diagramas Diagramas
de estados de estados
Modelo de Modelo de
Pruebas Pruebas
Diagramas Diagramas
de actividades de actividades

15
 El “Caso de desarrollo” Ejemplo de un “Caso de desarrollo”
n El número de posibles diagramas, modelos, vistas, Disciplina Artefacto Inicio Elabora- Construc- Tran-
ficheros fuente, casos de pruebas, etc. es muy grande ción ción sición

Requisitos Modelo de casos de uso I R

Visión I R
n Es preciso definir los artefactos que son necesarios en R
Glosario I
cada desarrollo concreto Modelo del dominio I
Análisis Modelo de análisis I R
n Uno de los artefactos iniciales es el “Caso de desarrollo”: Diseño Modelo de diseño I R
n Qué artefacto es necesario en cada disciplina Arquitectura I R
Modelo de datos I R
n En qué fase se crea
n En qué fases se actualiza Implementación Modelo de implementación I R R
Pruebas Modelo de pruebas I R
n Esta posibilidad permite tanto desarrollos “pesados” Gestión del Plan de desarrollo I R R R
como “ágiles” Proyecto
Entorno Caso de desarrollo I R

La fase de Inicio (Inception)

n Al comenzar un proyecto hay que contestar

algunas preguntas:
3.4
La fase de Inicio (Inception) n ¿Cuál es la visión del sistema?
n ¿Es viable?
n ¿Se puede comprar o hay que fabricar el sistema?
n ¿Cuánto va a costar?
n Y, finalmente ¿seguimos adelante o paramos?

16
 Objetivos de la fase de Inicio Criterios de evaluación de la fase

Al comienzo de la fase de Inicio, se establecen:

n El objetivo es desarrollar el análisis de
negocio hasta el punto necesario para la
puesta en marcha del proyecto
n Para ello, es necesario:
n Delimitar el alcance y objetivos del proyecto
n Definir la funcionalidad y capacidades del producto
n Tener una idea de la arquitectura (arquitectura
candidata)
n Una planificación provisional
n Los criterios de evaluación de la fase. Al final,
tendremos que haber sido capaces de:
n Fijar el ámbito del sistema
n Resolver ambigüedades en los requisitos
n Determinar una arquitectura candidata
Mitigar los riesgos críticos
n

Analizar las posibilidades de “negocio” (evaluar el “caso de

n Reducir los riesgos cuanto antes n

negocio”)
n Hacer estimaciones iniciales de costes, agenda

Disciplinas en la fase de Inicio Artefactos de la fase de Inicio

n Requisitos Artefacto Descripción
n Enumerar los requisitos iniciales (características del sistema) Visión Grandes objetivos y restricciones
n Comprender el contexto del sistema Lista de características
n Representar los requisitos como casos de uso Especificación adicional Requisitos no funcionales
n Recoger los requisitos no funcionales Modelo de casos de uso Describe los requisitos funcionales
n Análisis Glosario Terminología básica del dominio
n Análisis de la arquitectura Modelo inicial de dominio Define el contexto
n Análisis de los casos de uso (de algunos representativos) Modelo de análisis Esbozo inicial
n Diseño Modelo de diseño
n Esbozo de la arquitectura Prototipos (desechables) Validar la tecnología
n Implementación Plan de desarrollo Recursos (incluye Plan de la 1ª iteración)
n ¿Prototipo desechable? Lista de riesgos Riesgos posibles y forma de abordarlos
n Pruebas Análisis de negocio ¿Beneficios?
n No Caso de desarrollo Cómo vamos aplicar UP a este proyecto

17

3.5
La fase de Elaboración
Criterios de evaluación de la fase
Al comienzo de la fase de Elaboración:
n Se planifica la fase y se forma el equipo
n Se establecen criterios de evaluación que habrá que
cumplir al final:
n Respecto a los requisitos:
n ¿Se han identificado? ¿Se han detallado lo suficiente?
n En cuanto a la arquitectura:
n ¿Satisface los requisitos? ¿Es robusta?
n Los riesgos:
n ¿Se han eliminado los críticos? ¿Se ha completado la
lista?
n Evaluar el proyecto:
n ¿Se puede fijar un precio y una fecha de entrega?
Objetivos de la fase de Elaboración
n Tanto la funcionalidad como el dominio del
problema se estudian en profundidad
n Se define la arquitectura básica
n Se planifica el proyecto considerando recursos
disponibles
Disciplinas en la fase de elaboración
n Requisitos
n Encontrar los casos de uso y actores
Determinar la prioridad de los casos de uso
n
n Detallar los casos de uso
n Estructurar el modelo de casos de uso
Construir prototipos de las interfaces de usuario
n
n Análisis
n Análisis de la arquitectura
n Análisis de los casos de uso
n Análisis de clases y paquetes
n Diseño
n Diseño de la arquitectura (estilo, subsistemas)
n Diseño de los casos de uso
n Implementación
n Implementación de la arquitectura base (para una fracción de
casos de uso)
n Integración del sistema (con bibliotecas de servicios, frameworks)
n Pruebas
n Planificar y diseñar las pruebas
n Realizar pruebas de integración y de sistema
18
 Artefactos de la fase de Elaboración

Artefacto Descripción 3.6

Modelo de casos de uso
Modelo de dominio
Modelo de análisis
Modelo de diseño
Arquitectura del sistema
La mayoría de los casos de uso
Conceptos del dominio
Las fases de
Diagramas de clases Construcción y Transición
Diagramas de interacción
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 Todo lo relacionado con la interfaz

de usuario
Modelo de datos Traducción a esquemas de bases de datos

Fase de Construcción Disciplinas en la fase de Construcción

n El producto se desarrolla a través de iteraciones n Requisitos
n Completar los casos de uso y el detalle de los mismos
n Cada iteración involucra análisis, diseño e implementación
n Desarrollar prototipos de interfaz de usuario
n La arquitectura básica se refina de manera incremental
n Análisis
conforme se construye
n Análisis de los casos de uso añadidos
n Análisis de clases
n Gran parte del trabajo es programación y pruebas n Diseño
n Se documenta tanto el sistema construido como el manejo n Diseño de los casos de uso añadidos
del mismo n Implementación
n Implementación de la arquitectura
n Esta fase proporciona un producto construido junto con la
n Implementación de clases y subsistemas
documentación n Realizar pruebas de unidad
n Integración del sistema
n Al comienzo de esta fase, se asigna personal y se fijan los n Pruebas
criterios de evaluación: n Planificar y diseñar las pruebas
n Realizar pruebas de integración
n Lista de casos de uso implementados
n Realizar pruebas de sistema
n Documentación inicial para los usuarios n Evaluar las pruebas

19
Control en la fase de Construcción Artefactos de la fase de Construcción
n Además de las disciplinas técnicas, es preciso llevar a Artefacto Descripción
cabo labores de gestión:
Modelo de casos de uso Conjunto de artefactos producidos hasta ahora
n Control del análisis de negocio
Modelo de análisis
n Evaluación de la fase de Construcción Modelo de diseño
n Planificación de la fase de Transición Modelo de pruebas
Arquitectura del sistema Arquitectura definitiva
Modelo de implementación Incluye el código fuente
Modelo de pruebas

Sistema ejecutable Versión con capacidad operativa inicial (V. Beta)

Manual de usuario Versión inicial

Análisis de negocio Situación actual del proyecto

Plan de proyecto Plan para la fase de Transición

Fase de Transición Disciplinas en la fase de Transición

n Se libera el producto y se entrega al usuario para un uso real
n Se incluyen tareas de instalación, configuración, entrenamiento,
soporte, mantenimiento, etc.
n Los manuales de usuario se completan y refinan con la
información anterior
Estas tareas se realizan también en iteraciones
n
n El esquema de actividades es distinto del resto de las fases:
n Preparar la versión de pruebas de aceptación a partir de la versión
inicial
n Instalar la versión en los lugares elegidos
n Incluirá la migración de datos
n Reaccionar a los resultados de las pruebas
n Fallos en un componente, un diseño, un caso de uso
Problemas de fondo
n
n Adaptación del producto a entornos variados

n Al comienzo de la fase, se reasigna personal y se establecen los

n ¿Cuándo acaba el proyecto?
criterios de evaluación:
n En un producto “a medida”, el punto clave son las pruebas de
n ¿Han sido capaces los usuarios de llevar a cabo todos los casos de
usos? aceptación
n ¿Ha superado el producto las pruebas de aceptación? n En un producto de venta masiva, el proyecto no acaba nunca
n ¿Tiene el manual de usuario una calidad suficiente? realmente
n ¿Están listos los cursos de formación para los usuarios?
n ¿Están los usuarios satisfechos?

20
Bibliografía Recomendada Lecturas complementarias

& Beck, K. “Una explicación de la Programació n Extrema. Aceptar

& Jacobson, I., Booch, G., Rumbaugh, J. “El Proceso Unificado
de Desarrollo de Software ”. Addison -Wesley, 2000. el cambio ”. Addison Wesley, 2002.

& Kruchten , P. “The 4+1 view model of architecture ” , IEEE

& Larman , C. “UML y Patrones. Introducci ón al Análisis y Diseño
Orientado a Objetos”. Prentice Hall, 1999. (existe una segunda Software, 12(6):42-50. November, 1995.
edición en inglés de 2002)
& Royce, W. “Software Project Management. A Unified

& Ministerio de Administraciones Públicas. “MÉ TRICA. Framework”. Addison Wesley, 1998.
Versió n 3. Metodología de Planificación, Desarrollo y
Mantenimiento de sistemas de información”. & Kruchten , Philippe. "A Software Development Process for a
http://www.map.es/csi/metrica3/. 2001. Team of One", The Rational edge. Feb 2002.

http://www.therationaledge.com/

SPEM

n Roles, Work Products y Actividades

Software Process
Engineering Metamodel

Miguel A. Laguna

21
SPEM: estructura SPEM: dependencias

SPEM: Estructura del proceso SPEM: componentes de un proceso

22
SPEM: Ciclo de vida SPEM: notación (1)

SPEM: notación (2) SPEM: notación (3)

23