2.

El Proceso Software

Ingeniería del Software I

3º 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
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
„ Conocer las actividades de gestión de proyectos

2.1. Modelos de Proceso

2.1.1 Modelos genéricos de desarrollo

2.1.2 Métodos de desarrollo
orientados a objetos
 Componentes de un método
Together
Rose

HERRAMIENTAS
UML
TECNICAS

PROCESO

Proceso: Define el marco de trabajo y permite un desarrollo UP

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

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 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ón
abstracta de un proceso. Presenta una descripción de
un proceso desde una perspectiva particular.
2.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 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
Definicióndede
Requisitos
Requisitos

Diseño
Diseñodeldelsistema
sistemayy
del software
del software

Implementación
Implementaciónyyprueba
prueba
de unidades
de unidades

Integración
Integraciónyy
prueba
pruebadel
delsistema
sistema

Operación
Operaciónyy
mantenimiento
mantenimiento
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 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

etapas
„ Es difícil responder a los cambios en los
requisitos del cliente
„ Por 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
especificación inicial. Se debe comenzar teniendo
en cuenta los requisitos bien-entendidos. El
sistema evoluciona según la nuevas propuestas
del 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

Actividades
concurrentes

Especificación Versión
Versión
Especificación Inicial
Inicial

Bosquejo
Bosquejodedelala Desarrollo Versiones
descripción Desarrollo Versiones
Versiones
descripción Versiones
intermedias
intermedias
intermedias
intermedias

Validación Versión
Versión
Validación final
final
Desarrollo evolutivo
La 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 el
prototipado rápido)
„ Aplicabilidad
„ Para sistemas interactivos pequeños o de tamaño
mediano
„ 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 resolver
incertidumbres en la especificación inicial.
„ Reimplementar con un enfoque más
estructurado, con un proceso basado en el
modelo en cascada.
 Desarrollo formal de sistemas

„ Se basa en la transformación de una

especificación “matemática” a un programa
ejecutable
„ Las transformaciones preservan la corrección
y el programa final es conforme con su
especificación

Desarrollo formal de sistemas

Integración
Integraciónyy
Definición
Definiciónde
de Especificación
Especificación Transformación
Transformación prueba
pruebadel
del
Requisitos
Requisitos formal
formal formal
formal sistema
sistema

Desmostración
de la corrección
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 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 componentes
„ Modificación de requisitos
„ Diseño del sistema con reutilización
„ Desarrollo 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

Diseño
Diseñodede
Especificación
Especificación Análisis
Análisisde
de Modificación
Modificacióndede sistemas
sistemascon
con
de
deRequisitos
Requisitos componentes
componentes requisitos
requisitos reutilización
reutilización

Desarrollo
Desarrolloee Validación
Validacióndel
del
integración
integración sistema
sistema

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 utilizado
„ Modelos de proceso que incluyen la iteración:
„ Desarrollo incremental
„ Desarrollo 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
funcionalidad que se hubiera determinado
„ Los requisitos del usuario se priorizan y los requisitos
de prioridad más alta se incluyen en los incrementos
más tempranos
„ Cuando el desarrollo de un incremento comienza, sus
requisitos son inamovibles, aunque los requisitos de
incrementos posteriores pueden continuar
desarrollándose

Desarrollo incremental

Definir Diseñar
Diseñarlala
Definirrequisitos
requisitos Asignar
Asignarrequisitos
requisitosaa
iniciales cada incremento arquitectura
arquitectura
iniciales cada incremento
del
delsistema
sistema

Desarrollar
Desarrollar Validar
Validar Integrar
Integrar Validar
Validar
incremento
incremento incremento
incremento incrementos
incrementos sistema
sistema
Sistema
final

Sistema incompleto
 Desarrollo incremental

incremento 4 analysis design code test

analysis design code test

incremento 3

incremento 2
analysis design code test Entrega del
incremento 2...

analysis design code test

Entrega del
incremento 1
incremento 1

tiempo

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.
„ 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
del proceso.
„ No hay fases fijas como la especificación o
diseño. Cada vuelta en la espiral determina
las actividades a realizar.

Desarrollo en espiral

Planificación
Análisis de riesgos
Comunicación con
el usuario

Ingeniería

Evaluación del
Desarrollo y validación
usuario
 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

Deter mine ob jectiv es

Evaluate alternatives
alternatives and iden tif y, resol ve risk s
c ons traint s
Risk
analysis
Risk
analysis
Risk
analysis Opera-
Prototype 3 tional
Prototype 2 protoype
Risk
REVIE W analysis Proto-
type 1
Require me nt s plan Simulations, models, benchmarks
Life-cycle plan Concept of
Operation S/W
requirements Prod uct Detaile d
desi gn
Requirement de si gn
De velop ment
plan validation Code
Uni t tes t
Integrati on Design
a nd test p la n V&V Inte gr ati on
Plan ne xt p hase test
Accep tance
Serv ice test Develop, v erif y
next-level p rod uct
2.1.2
Métodos de desarrollo
orientados 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
 Métodos estructurados y...

Análisis Diseño Implementación

PROCESOS

STD
DFD PROGRAMA
DATOS

RELACIONAL TABLAS
DER

...Métodos orientados a objetos

Análisis Diseño Implementación

Clases
 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?

Interfaz de
usuario Texto GUI

Lenguaje de Procedimental OO
programación C, Cobol C++, Java

SGBD Relacional OO ?
 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 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
clases

Diagramas de
estados

DFDs

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 en
un desarrollo orientado al objeto:
„ Macro procesos
„ Micro procesos

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

Applications", 2nd edition. Benjamin Cummings, 1993.
Método de Booch
„ Diferencia:
„ Modelos estático y dinámico
„ Modelos lógico y físico

Modelo dinámico
Estructura
Modelo Estático
de objetos

Modelo Lógico Estructura de clases

Arquitectura
de procesos
Arquitectura de módulos
Modelo Físico

... Método de Booch

Clase Clase utilidad

Nombre de la clase Nombre de la clase

utilidad
Atributos
Métodos() Atributos
{restricciones} Métodos()

Clase parametrizada
Argumentos Argumentos
formales actuales

Nombre de la Nombre de la
clase clase
parametrizada instanciada
 OOSE (Jacobson)
„ 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 Construcción Pruebas

Proceso de análisis:

Especificación Análisis de Análisis de

de requisitos Requisitos Robustez

Modelo de Modelo de
requisitos 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

<<extends>>

Cliente local
<<uses>> Giro

Identificación

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

Oriented Software Engineering: A Use Case Driven Approach”.
Addison-Wesley, 1994.
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 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ón
„ Implantació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 Sistemas

Se 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 ágiles
„ Propuesta por Beck en 1999.
„ Nuevo enfoque basado en el desarrollo y la
entrega 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”.

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
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 su
solución
„ Los conceptos de modelado son independientes de cómo se
visualizan
„ Notación
„ Un conjunto de vistas y notaciones para presentar la
información de modelado subyacente que permite a las
personas 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 el
desarrollo
 UML no es un método

Personas, Equipos,
Experiencia

Lenguaje
Proceso
de Modelado
?

¿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:
„ Reproducible
„ Definido
„ Medible en cuanto a rendimiento
„ Optimizable...

Nuevos Sistema
Proceso
software
Requisitos Nuevo
 Dos elementos complementarios

UML Proceso
Unificado

• Estándar • Proceso
OMG marco
adaptable
• No es un
estándar en sí

Antecedentes del Proceso Unificado

Unified Process
SPEM
1999
(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)
 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
 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 de
riesgos

Conducido por Casos de uso

Requisitos Análisis Diseño Implement. Pruebas

Los casos de uso integran todas las actividades

Capturar, clarificar y Realizar los casos de Verificar que se

validar los casos de uso uso satisfacen los casos
de uso
Centrado en la Arquitectura
„ La arquitectura describe los elementos
fundamentales 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

Vista
Vista de
de
Vista
Vista Lógica
Lógica Realización
Realización
Vista de
Casos de Uso

Vista
Vista de
de Vista
Vista de
de
Procesos
Procesos Despliegue
Despliegue
(Philippe Kruchten)
 Arquitectura y Modelos

Modelo de Modelo de Modelo de Modelo de Modelo de Modelo de

casos de uso análisis diseño despliegue Implement. Pruebas

Modelos

Vistas

La arquitectura incorpora una colección de vistas de los modelos

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 sistema
„ Una 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
Funcionalidad
del sistema Incremento2

Análisis Diseño Implementación Prueba

Incremento1

Análisis Diseño Implementación Prueba

Tiempo

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
 Iterativo: varias espirales

Etapa de Ingeniería Etapa de Producción

Inicio Elaboración Construcción Transición

Visión Arquitectura Versiones Beta Productos

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 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)
 Incremental
„ Primero, la arquitectura,
„ Después, se van añadiendo los detalles según avanza el desarrollo

Etapa de Ingeniería Etapa de producción

Inicio Elaboración Construcción Transición

Implementación

Implementación

Implementación

Implementación
Diseño

Diseño

Diseño

Diseño
Instalación

Instalación

Instalación

Instalación
Requisitos

Requisitos

Requisitos

Requisitos
Gestión Gestión Gestión Gestión

Visión Arquitectura Versiones Beta Productos

2.3
Fases y disciplinas
(o flujos de trabajo)

„ Fases y puntos de control

„ Disciplinas (Flujos de trabajo)
„ Artefactos
 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 en

fases
„ Las fases se dividen en iteraciones

Ciclo de desarrollo

iteración fase

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:
„ Inicio

„ Elaboración

„ Etapa de Producción: equipos grandes, actividades

predecibles, menos riesgos (programación, pruebas). Las
fases son:
„ Construcción

„ Transición

Inicio Elaboración Construcción Transición

tiempo

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
 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 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

Inicio Elaboración Construcción Transición

tiempo

Visión Arquitectura Capacidad Producto

básica inicial final

Release
Release Release Release Release Release Release Release
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)
 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 disciplinas

Fases

Disciplinas: Inicio Elaboración Construcción Transición

Requisitos

Análisis

Diseño

Implementación

Pruebas

Iteraciones iter. iter. iter. iter. ite r. iter. iter.

preliminares #1 #2 #n #n+1 #n+2 #m #m+1

Iteraciones
 Fases y disciplinas: SPEM
„ La propuesta de proceso estándar admite distintas
combinaciones de disciplinas y fases
Disciplinas: Inicio Elaboración Construcción Transición

Modelado del negocio

Requisitos

Diseño

Implementación

Prueba

Despliegue

Gestión de la
Configuración

Gestión del Proyecto

Entorno

Iteraciones

El detalle de cada disciplina

„ Pero hay que definir cada disciplina en detalle

Disciplinas: Construcción Transición

Inicio Elaboración

Modelado del negocio

Requisitos

Diseño

Implementación

Prueba

Despliegue

Gestión de la
Configuración

Gestión del Proyecto

Entorno

Iteraciones
 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 producen

las disciplinas (incluyen otros artefactos)

Disciplinas de desarrollo y modelos

Los diagramas UML
representan vistas de
cada modelo
Requisitos Modelo de
casos de uso

Análisis Modelo de
análisis

Diseño Modelo de Modelo de

diseño despliegue

Implementación Modelo de
Implement.

Pruebas Modelo de
Pruebas

Cada disciplina se
asocia con modelos
Modelo de casos de uso
Diagramas
de casos de uso
Modelo de
casos de uso Diagramas Diagramas
de clases de objetos
Modelo de
análisis
Diagramas
de componentes

Modelo de Diagramas
diseño de despliegue

Diagramas
Modelo de de secuencia
despliegue

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

Modelos de análisis y diseño

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

Modelo de Diagramas
diseño de despliegue

Diagramas
Modelo de de secuencia
despliegue

Diagramas
Modelo de de colaboración
Implement.
Diagramas
de estados
Modelo de
Pruebas
Diagramas
de actividades
 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 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”

Disciplina Artefacto Inicio Elabora- Construc- Tran-

ción ción sición

Requisitos Modelo de casos de uso I R

Visión I R
Glosario I R
Modelo del dominio I
Análisis Modelo de análisis I R
Diseño Modelo de diseño I R
Arquitectura I R
Modelo de datos I R

Implementación Modelo de implementación I R R

Pruebas Modelo de pruebas I R

Gestión del Plan de desarrollo I R R R
Proyecto
Entorno Caso de desarrollo I R
2.5.
Disciplinas de gestión de
proyectos

Objetivos de la gestión de proyectos

„ Organizar, planificar y programar los

proyectos 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 de
gestión
Tareas en la gestión de proyectos
9 Planificación y calendarización del proyecto
• Tareas a realizar y plan de trabajo
9 Estimación del coste del proyecto
9 Supervisión y revisión del proyecto
• Para comparar los progresos y costes reales con
los planeados y hacer ajustes
9 Selección y evaluación del personal
9 Redacción y presentación de informes

Planificación del proyecto

„ Es la actividad que más tiempo consume en

la administración de un proyecto
„ Es un proceso iterativo que se completa
cuando el proyecto mismo termina.
„ El plan del proyecto debe ser revisado
regularmente a la vista de la evolución del
mismo
„ Es imposible planificar sin estimar.
 Estimación del coste del software
„ Se trata de predecir los recursos que se
requieren 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?

Productividad del programador

„ Se intenta determinar una medida de

la cantidad de software y de
documentación asociada que produce
un programador individual
„ Hay que tener en cuenta que existen
muchas soluciones software con
distintas características: más
eficiente, más mantenible, …
„ Hay varias propuestas de métricas
para medir diversos aspectos del
software
 Métricas de la productividad

„ 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ódigo
fuente, 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.

Puntos de función

weighting factor
measurement parameter count simple avg. complex
number of user inputs X 3 4 6 =
number of user outputs X 4 5 7 =
number of user inquiries X 3 4 6 =
number of files X 7 10 15 =
number of ext.interfaces X 5 7 10 =
count-total
complexity multiplier
function points
Calidad y productividad

„ Las métricas basadas en volumen/unidad de

tiempo (líneas/programador-mes) son
imperfectas porque no tienen en cuenta
factores como la fiabilidad, el mantenimiento,
…
„ La productividad se puede aumentar
generalmente a costa de la calidad

Técnicas de estimación
„ No hay una forma simple de hacer una
estimación exacta del esfuerzo requerido para
desarrollar 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 proyecto

tienden a “autorealizarse”
„ La estimación determina el presupuesto y el producto
se ajusta para cumplir el presupuesto
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 una
estimació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 el
tiempo y los recursos necesarios para
terminar cada tarea
„ Organizar las tareas concurrentemente para
hacer un uso óptimo de la mano de obra
„ Minimizar las dependencias entre tareas para
evitar retrasos producidos cuando una tarea
espera a otra para terminar
„ Depende de la intuición y la experiencia de
los administradores del proyecto
Estructura de un plan de proyecto
En él se fijan los recurso disponibles, se divide
el 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 y
productos 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
Problemas en la planificación

„ Estimar la dificultad de los problemas, y por

lo tanto el coste de desarrollar una solución,
es difícil
„ La productividad no es proporcional al
número de personas que trabajan en una
tarea
„ Añadir personal al final del proyecto produce
má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 la

planificación del proyecto
„ Muestran la descomposición del proyecto en
tareas. Las tareas no deben ser demasiado
pequeñas.
„ Los diagramas de redes de actividades
muestran las dependencias de las tareas y el
camino crítico
„ Los diagramas de barras muestran la
planificación sobre el calendario
 Duración de las tareas y dependencias

Tarea Duración (días) Dependencias

T1 8
T2 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

14/7/99 15 days
15 days
M1 T3
8 days T9
T1 5 days 4/8/99 25/8/99
25/7/99
T6 M4 M6
4/7/99 M3
start 20 days 7 days
15 days
T7 T11
T2

25/7/99 10 days 11/8/99 5/9/99

10 days
M2 M7 M8
T4 T5 15 days
T10 10 days
18/7/99
T12
M5
25 days
T8 Finish
19/9/99
 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
Start
T4
T1
T2
M1
T7
T3
M5
T8
M3
M2
T6
T5
M4
T9
M7
T10
M6
T11
M8
T12
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

Fred T4
T8 T11
T12
Jane T1
T3
T9
Anne T2
T6 T10

Jim T7

Mary T5
 Gestión del riesgo
ƒ El análisis de riesgos consiste en evaluar el
proyecto, la tecnología y los recursos con el
fin determinar y comprender la naturaleza y
el origen de los riesgos

ƒ Posibles riesgos:
ƒ Comerciales (competencia, etc.)
„ Financieros (económicos, etc.)
„ Técnicos (¿base tecnológica sólida y
probada?)
„ De desarrollo (¿equipo experimentado?)

Tabla de riesgos

Riesgo Probabilidad Impacto Gestió

Gestión y
Mitigació
Mitigación del
Riesgo
Escala
Escala 1..5
1..5
1=impacto
1=impacto
Ejemplo: bajo
bajo
Software 5=catástrofe
5=catástrofe
empotrado
depende de
hardware no
disponible Ajustar pruebas a la
disponiblilidad del
60% 4(crítico) HW
Utilizar simulación
 Garantía de calidad

Coste de los fallos encontrados en distintas etapas

100 60.00-100.00

10 10.00
3.00
1.50
1.00
1 0.75

Diseño Pruebas En uso

Req. Prog. Prueba
del 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 y
mantenimiento de SOFTWARE y servicios de soporte.
Garantía de calidad

Proceso y
Revisiones
Estandares formales

Análisis
& Planifica-
Informes ción de las
pruebas
Métricas

MODELO DE MADUREZ DE LA CAPACIDAD

Nivel Características Resultados

- 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. Productividad y
- Se establecen programas de formación del personal de
Inicial calidad escasa.
desarrollo y mantenimiento. Riesgo máximo

- Los procesos de software son estables y repetibles.

- La organización establece políticas de gerencia de
proyectos y procesos.
- La planificación se basa en proyectos similares.
- Existen estándares definidos y exigidos. Productividad y
Repetible - El proceso se enmarca en un sistema de gerencia de calidad baja.
proyectos basado en experiencias pasadas. Riesgo alto.
MODELO DE MADUREZ DE LA CAPACIDAD
Nivel Características Resultados
-Los procesos son definidos: estandarizados, documentados
e institucionalizados.
- Los procesos de ingeniería y gerencia son estables y se
integran en uno sólo. Productividad y
Definido - Existe un entendimiento común de los procesos, funciones calidad media.
y responsabilidades. Riesgo medio.
- La organización mantiene un grupo dedicado a la
definición, mejoramiento y difusión del proceso de
Ingeniería de Software.

- Los procesos son medibles o cuantificables

- La productividad y la calidad se miden y registran para
cada proyecto de la organización. Productividad y
Gestionado - Se fijan metas cuantitativas de la calidad del software. calidad alta.
-Mediante el uso de métricas de software, se crea una base Riesgo mínimo.
cuantitativa para la evaluación y estimación en proyectos
futuros.

- Los procesos se mejoran continuamente.

- La organización busca lograr el nivel máximo de Productividad y
Optimizado capacidad. calidad total.
- Se incorporan nuevas tecnologías y métodos para mejorar Riesgo nulo.
los procesos.

Gestión de la configuración del software

Cambios en
Requisitos de negocio
Cambios en
Requisitos técnicos
Cambios en otros
Requisitos de usuario

modelos de software

Plan
datos
Pruebas
código
Gestión de la configuración del software

programas documentación

Hay cambios
en muchas datos
piezas

Gestión de la configuración del software

• identificación
• control de versiones
HERRAMIENTAS
• control de cambios
TECNICAS • auditoría
• informes
PROCESO
• construcción

Existen herramientas que ayudan al control de

las versiones a medida que avanzan (SourceForge)
2.5
La fase de Inicio (Inception)

La fase de Inicio (Inception)

„ Al comenzar un proyecto hay que contestar

algunas 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?
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

„ 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 de
negocio”)
 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

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

Modelo del
Dominio
Conceptos, asociaciones
*
y atributos *

Modelo de casos de uso

:System
foo( x )
Requisitos Glosario ...
bar( y )

Casos
de uso
diagramas diagramas

Modelo de diseño

Diseño

2.6
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 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?
 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

Artefacto Descripción
Modelo de casos de uso La mayoría de los casos de uso
Modelo de dominio Conceptos del dominio
Modelo de análisis Diagramas de clases
Diagramas de interacción
Modelo de diseño Diagramas de paquetes y clases
Arquitectura del sistema 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
2.7
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ó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
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 a
cabo 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
 Artefactos de la fase de Construcción

Artefacto Descripción
Modelo de casos de uso Conjunto de artefactos producidos hasta ahora
Modelo de análisis
Modelo de diseño
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
„ 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
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

Sommerville, 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/

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