Metodologia

Metodología para el
Desarrollo de Software
Dr. José Ignacio Peláez Sánchez

E.T.S.I. Informática de Sistemas. 3er Curso. Año 2004/2005
Metodología
“Conjunto de actividades necesarias para

transformar los requisitos de los usuarios
en un sistema software“
José Ignacio Peláez Sánchez

Universidad de Málaga 2 de 297
Departamento de Lenguajes y Ciencias de la Computación
DUM
Desarrollo Unificado con Métrica

DUM
Características:
z Proporciona una guía para las actividades de un equipo de
desarrollo.
z Dirige las tareas de cada desarrollador por separado y del equipo
en conjunto.
z Especifica los productos que deben desarrollarse.
z Ofrece criterios para el control, medición de los productos y
actividades del proyecto.

DUM
El proceso consta de cinco fases:
1. Inicio.
2. Elaboración.
3. Construcción.
4. Transición.
5. Mantenimiento. Esta fase es responsabilidad del cliente, que bien
puede encomendársela a la propia organización de desarrollo de
software, o bien, puede encomendársela a otra.

DUM
Las cuatro primeras fases (Inicio, elaboración,
construcción, transición) atraviesan cinco flujos de trabajo
que son conocidos como iteración:
1. Captura de requisitos.
2. Análisis.
3. Diseño.
4. Implementación.
5. Prueba.

DUM
Antes de definir en detalle las cuatro fases es necesario
conocer el método de comunicación (casos de uso) que
se empleará durante el desarrollo del software.
También definiremos los tres aspectos fundamentales del

proceso de desarrollo que son los siguientes:
1. Dirigido por casos de uso.
2. Centrado en la arquitectura.
3. Iterativo e Incremental.

Dirigido por Casos de Uso
La comunicación en el proyecto se realiza mediante casos
de uso.
Para ello, se deben transformar los requisitos del lenguaje

natural a un método de representación comprensible para
TODOS los implicados en el proyecto, incluidos los clientes
y usuarios. ¿Cómo?. CASOS DE USO

Los casos de uso intervienen en los cinco flujos de trabajo
fundamentales:
z Se identifican (captura de requisitos).
z Se especifican (análisis).
z Se diseñan.
z Se implementan.
z Son fuente a partir de la cual se construyen los casos de prueba.

Los casos de uso ayudan a los jefes de proyecto a
planificar, asignar y controlar muchas tareas.
Cada caso de uso permite identificar varias tareas:
z Especificación.
z Diseño.
z Prueba.
z Otras.
Facilitan la asignación de tareas y pueden servir como
unidad de medida que incluya estimaciones de esfuerzo,
tiempo, tamaño y recursos necesarios.

Trazas.
z Definición:
9 Relaciones que establece un caso de uso entre los elementos que
genera en los distintos flujos de trabajo fundamentales.
z Características:
9 Permiten relacionar directamente un elemento de diseño o incluso de
implementación con el caso de uso que lo originó.
9 Aportan flexibilidad ante cambios en los requisitos.

Trazas:
z Definición.
z Características.
z Especificación:
9 Cada caso de uso, del modelo de casos de uso, se traducirá en una
realización de casos de uso, en el modelo de análisis.
9 Cada realización de caso de uso del modelo de análisis, que estará
expresada en términos del análisis, se traducirá en una realización de
casos de uso del modelo de diseño.
9 El modelo de diseño es un esquema de implementación, por tanto, la
implementación de una realización de caso de uso es directa.
9 Se pueden definir casos de prueba a partir de los casos de uso.

Trazas: Casos de Uso
Realización de caso Análisis

de uso
Realización de caso Diseño

de uso
Implementación
Pruebas

Centrado en la Arquitectura
La arquitectura es la visión común del sistema que todos
los implicados aceptan.
La arquitectura proporciona una ‘base del sistema’ para el

desarrollo del mismo, es decir, una vez encontrada esta
arquitectura el sistema se va completando
incrementalmente añadiendo elementos a la misma.

Incluye vistas de todos los modelos excepto el de
prueba:
z Casos de uso. Formado por todos los casos de uso y su relación
con los usuarios.
z Análisis. El objetivo es refinar los casos de uso, mostrar la
funcionalidad del sistema.
z Diseño. Definición de la estructura estática (subsistemas, clases e
interfaces) y de los casos de uso considerados colaboraciones
entre los elementos anteriores.
z Despliegue. Basado en nodos físicos, se ocupa de la
correspondencia nodos-componentes.
z Implementación. Basado en componentes, se ocupa de la
correspondencia clases-componentes.

Formarán parte de la arquitectura los elementos más
importantes, los que guían el trabajo:
z Subsistemas.
z Dependencias.
z Interfaces
z Colaboraciones
z Nodos.
z Clases activas.
Estos elementos describen los cimientos del sistema que
son necesarios para la comprensión, desarrollo y
producción del sistema.

Necesidades que cubre la arquitectura:
z Comprender el sistema.
z Organizar el desarrollo:
9 La división del sistema en subsistemas con interfaces claramente
definidas con un responsable establecido para cada subsistema
reduce la carga de comunicación entre los grupos de trabajo, por
tanto, las interfaces permiten el progreso independiente de software
a ambos lados de las mismas.
z Fomentar la reutilización:
9 Requiere un conocimiento del dominio del problema que permita
determinar si un componente concreto será útil al sistema. La clave
para la integración de estos componentes está en las interfaces tanto
del componente como del sistema.

z Organizar el desarrollo.
z Fomentar la reutilización.
z Hacer evolucionar el sistema:
9 Proporciona la seguridad de que el sistema evolucionará ante
modificaciones de diseño o implementación o ante la introducción de
nuevas funcionalidades.

Creación de la arquitectura:
z Borrador inicial de la parte que no es específica de los casos de
uso, por ejemplo la plataforma.
z Selección, especificación y realización de los casos de uso que
representen funciones clave del sistema.
z La arquitectura se va refinando a medida que se especifican más
casos de uso y a medida que la arquitectura se va refinando da
cabida a más casos de uso.
z El uso de iteraciones posibilitará la ejecución de esto último.

z Organizar el desarrollo.
z Fomentar la reutilización.
z Hacer evolucionar el sistema.

Relación Casos de Uso-Arquitectura
La función del sistema corresponderá a los casos de uso y
la forma del mismo a la arquitectura.
Existe una relación ‘cíclica’ entre la arquitectura y los

casos de uso; los casos de uso deben adaptarse a la
arquitectura, pero la arquitectura, a su vez, debe facilitar
la realización de los casos de uso.

Relación Casos de Uso-Arquitectura
Esta interdependencia introduce un problema:
z ¿Qué definir primero, los casos de uso (adaptando posteriormente
la arquitectura para facilitar su realización), o la arquitectura
(adaptando posteriormente los casos de uso a la misma)?
La repuesta es:
z Ninguna de las dos opciones.
z Se realizará un trabajo simultáneo. ¿cómo?
MEDIANTE ITERACIONES

Iterativo e Incremental
El tercer aspecto a destacar de la metodología es el
desarrollo incremental:
z La arquitectura se va completando en sucesivos pasos que le
añaden algo de funcionalidad hasta la conclusión del desarrollo,
cuando la arquitectura se haya convertido en el sistema en sí.
z Dichos pasos se denominan iteraciones.

Iteraciones:
z Definición:
9 Las iteraciones se entienden como ejecuciones reducidas del proyecto
que añaden nueva funcionalidad al sistema.
9 Para ejecutarlas se toma un conjunto de casos de uso (captura de
requisitos) según el criterio de planificación, y se realiza el trabajo
correspondiente a los mismos completamente (análisis, diseño,
implementación y prueba).
z Actividades:
9 Las iteraciones se planifican, admiten división en unidades menores
denominadas construcciones y finalmente, se evalúan.

Iteraciones:
z Definición.
z Actividades.
z Características:
9 Dan un carácter de simultaneidad al proyecto que permite respetar la
interdependencia entre arquitectura y casos de uso.
9 Permiten abordar los problemas más graves al principio del proyecto
evitando sorpresas desagradables cuando el proyecto está demasiado
avanzado y resulta muy costoso, o puede que inviable, realizar
modificaciones.
9 Añaden fiabilidad ya que cada iteración es probada, por tanto,
cuando se empieza una iteración se tiene la seguridad de que todo el
trabajo anterior es correcto.

Iteraciones:
z Definición.
z Actividades.
z Características:
9 Si la evaluación de una iteración es totalmente negativa se puede
cancelar el proyecto.
9 Cada iteración da como resultado una versión interna del sistema en
funcionamiento, facilitando la identificación de nuevos requisitos.
9 La identificación temprana de retrasos permite adaptar los
calendarios con suficiente antelación.
9 Por último, cabe destacar que aportan sensación de progreso al
proyecto.

Iteraciones:
z Definición.
z Actividades.
z Características.
z Planificación:
9 Debe estar orientada a que las primeras iteraciones proporcionen la
base de conocimiento para las siguientes.
9 Las primeras iteraciones del proyecto buscan incrementar la
comprensión de los requisitos, el problema, los riesgos y el dominio
de la solución.
9 Las restantes añaden incrementos que finalmente conformarán la
versión externa, es decir, el producto para el cliente.

Iteraciones:
z Definición.
z Actividades.
z Características.
z Planificación:
9 El objetivo es obtener una serie de iteraciones que siempre avanza,
para que no sea necesario volver varias iteraciones atrás para realizar
correcciones debido a algo aprendido en la última iteración.
9 Un factor importante es la ordenación, por importancia, tanto de los
casos de uso como de los riesgos.

Iteraciones:
z Definición.
z Actividades.
z Características.
z Planificación.

CONCEPTO DE RIESGO

Riesgos
Riesgos:
z Definición:
9 Un riesgo es un asunto que tiene cierto grado de probabilidad de
poner en peligro el éxito de un proyecto.
z Tipos:
9 Riesgos técnicos:
8 Relacionados con nuevas tecnologías.
8 Relativos a la arquitectura.
8 Relativos a la construcción del sistema adecuado que cumpla su
misión.
8 Relativos al rendimiento.

Riesgos
Riesgos:
z Definición.
z Tipos:
9 Riesgos técnicos.
9 Riesgos no técnicos:
8 Falta de experiencia en ciertos aspectos.
8 Lenguaje nuevo para la organización.
8 Calendario demasiado apretado.
8 Dependencia de empresas subcontratadas.
8 Incumplimiento del cliente de algún plazo de aprobación.

Riesgos
Riesgos:
z Definición.
z Tipos:
9 Riesgos no técnicos.
z Tratamiento:
9 Evitarlo (introducir cambios).
9 Limitarlo (restringirlo a una pequeña parte del proyecto).
9 Controlarlo (plan de contingencia).
9 Atenuarlo (forzar su aparición para aplicarle alguna de las opciones
anteriores).

Riesgos
Riesgos:
z Definición.
z Tipos:
9 Riesgos no técnicos.
z Tratamiento.

Conclusiones
Ahora resulta más fácil comprender que ‘los casos de uso dirigen el
proceso de desarrollo’.
Los casos de uso están presentes en los cinco flujos de trabajo
fundamentales
z Captura de requisitos.
z Análisis.
z Diseño.
z Implementación.
z Prueba.
Son la base en la planificación de las iteraciones.
La arquitectura debe adaptarse a los casos de uso para facilitar su
realización.

COMPRENSIÓN DEL SISTEMA

Comprensión del Contexto del Sistema
Un buen desarrollo de software requiere la comprensión del contexto
del sistema.
Esta compresión ayudará al equipo de desarrollo a tener una idea
más o menos próxima de lo que debe realizar el sistema.
Además permitirá a los desarrolladores hacer sugerencias al cliente
aumentando las posibilidades del sistema.
Existen dos formas de acercarse al contexto del sistema:
z Modelo de dominio.
z Modelo de negocio.

Modelo de Dominio
Modelo de dominio:
z Definición:
9 Un modelo de dominio captura los tipos de objetos más importantes
del contexto del sistema.
9 Los objetos del dominio representan ‘cosas que existen’ o eventos
que suceden en el entorno en que trabaja el sistema.
z Descripción:
9 Se describe mediante diagramas UML, principalmente el de clases.
z Tipos de clases y objetos:
9 Objetos del negocio que representan cosas que se manipulan en el
negocio, por ejemplo pedidos o contratos.
9 Objetos del mundo real y conceptos de los que el sistema debe hacer
un seguimiento, por ejemplo aviación enemiga.
9 Sucesos que ocurrirán o han ocurrido, por ejemplo llegada o salida de
un avión.

Modelo de Dominio
Modelo de dominio:
z Definición.
z Descripción.
z Tipos de clases y objetos.
z Desarrollo:
9 El objetivo es comprender y describir las clases más importantes
dentro del contexto del sistema.
9 Las clases candidatas se guardan como definiciones en el glosario de
términos para evitar que el modelo sea demasiado grande.
9 Si el dominio de negocio es muy pequeño basta con el glosario de
términos.
9 Tanto el modelo de dominio como el glosario de términos contribuyen
a unificar el lenguaje empleado por todos los implicados en el
proyecto.

Modelo de Dominio
Modelo de dominio:
z Definición.
z Descripción.
z Desarrollo.
z Uso:
9 Las clases del dominio y el glosario de términos se usan en el
desarrollo de los modelos de casos de uso y análisis:
8 Al describir los casos de uso y al diseñar la interfaz de usuario.
8 Para sugerir clases internas al sistema en desarrollo durante el análisis.
9 Un modelo del dominio es en realidad un caso especial de un modelo
del negocio que es más completo.

Modelo de Dominio
Modelo de dominio:
z Definición.
z Descripción.
z Desarrollo.
z Uso.

Modelo de Negocio
Modelo de negocio:
z Definición de negocio:
9 Entendemos por negocio el campo del que se ocupa el sistema, por
ejemplo, la metodología que se está presentando es un caso de uso
del negocio ‘del desarrollo de software’.
z Definición:
9 Es una técnica que permite comprender los procesos del negocio de
la organización.
z Objetivo:
9 El objetivo es identificar los casos de uso y las entidades de negocio
relevantes que el software debe soportar, modelando así sólo lo
necesario para comprender el contexto.

Modelo de Negocio
Modelo de negocio:
z Definición de negocio.
z Definición.
z Objetivo.
z Descripción:
9 El modelo de negocio está soportado por dos tipos de modelos UML,
el de casos de uso y el de objetos.
z Elementos:
9 Un modelo de caso de uso del negocio describe los procesos del
negocio de una empresa en términos de casos de uso y actores del
mismo que se corresponden con dichos procesos y con los clientes
respectivamente.

Modelo de Negocio
Modelo de negocio:
z Definición.
z Objetivo.
z Descripción.
z Elementos:
9 Un modelo de objetos del negocio es un modelo interno a un negocio.
Describe la realización de casos de uso del negocio en términos de entidades
del negocio y unidades de trabajo, mostrándolas en diagramas de interacción
o de actividad.
9 Una entidad del negocio es algo que los trabajadores toman, inspecciona,
manipulan producen o usan en un caso de uso del negocio.
9 Una unidad de trabajo es un conjunto de entidades que representa un todo
reconocible para el usuario final.

Modelo de Negocio
Modelo de negocio:
z Definición.
z Objetivo.
z Descripción.
z Elementos:
9 Las entidades del negocio y las unidades de trabajo se usan para
representar los mismos tipos de conceptos que las clases del dominio.
9 Se usarán otros diagramas para mostrar trabajadores, sus
interacciones y cómo usan las entidades de negocio y la unidades de
trabajos.

Modelo de Negocio
Modelo de negocio:
z Definición.
z Objetivo.
z Descripción.
z Elementos.
z Desarrollo:
9 Los modeladores confeccionan un modelo de casos de uso del
negocio que identifique actores del negocio y casos de uso del mismo
que usen los actores. Este modelo de casos de uso del negocio
permite comprender mejor qué valor proporciona éste a sus actores.

Modelo de Negocio
Modelo de negocio:
z Definición.
z Objetivo.
z Descripción.
z Elementos.
z Desarrollo:
9 Desarrollar un modelo de objetos del negocio compuesto por
trabajadores, entidades del negocio y unidades de trabajo que juntas
realizan los casos de uso del negocio. Se asocian a estos objetos las
reglas del negocio y otras normas impuestas por el negocio con el fin
de crear objetos que realicen los casos de uso del negocio de la
forma más eficaz posible (rápidamente, con precisión y a un coste
bajo).

Modelo de Negocio
Modelo de negocio:
z Definición.
z Objetivo.
z Descripción.
z Elementos.
z Desarrollo.

Relación entre los dos Modelos
Existen similitudes entre el modelo del dominio y el del negocio, de
hecho el de dominio es una versión simplificada del de negocio
centrada en las cosas, es decir, clases del dominio (entidades del
negocio) que necesitan usar los trabajadores.
Sin embargo, hay diferencias que hacen mucho más recomendable

realizar el más completo modelo del negocio.

Diferencias entre los Modelos
Diferencias entre el modelo de dominio y el de negocio:
z Origen de la información:
9 Las clases del dominio se obtienen de la base del conocimiento de
unos pocos expertos del dominio, o del conocimiento asociado con
sistemas similares al que se desarrolla.
9 Las entidades del negocio se derivan a partir de los clientes del
negocio, identificando los casos de uso del negocio y después
buscando las entidades. Cada entidad debe venir motivada por su
utilización en un caso de uso del negocio.
z Trazas:
9 La técnica de modelado del dominio puede hacer la traza de las
clases hasta la experiencia de los expertos del dominio. La técnica de
modelado del negocio puede hacer la traza de la necesidad de cada
elemento hasta los clientes.

z Origen de la información.
z Trazas.
z Identificación de operaciones:
9 La clases del dominio tienen atributos pero ninguna o pocas
operaciones.
9 Las entidades del negocio poseen operaciones a través de las cuales
se identifica cómo usarán los trabajadores el sistema.
9 Por tanto, la técnica de modelado del negocio no sólo identifica las
entidades sino también todos los trabajadores que participarán en la
realización de los casos de uso del negocio que utilizan a las
entidades.
9 Las operaciones de las entidades del negocio se derivarán de los
clientes y podrán ser trazadas hasta ellos.

z Trazas.
z Identificación de operaciones.
z Relación del modelo con los casos de uso del sistema:
9 A partir de los trabajadores identificados en el modelo del negocio se
deriva un primer conjunto de actores y casos de uso para el sistema
en construcción.
9 Esto permitirá realizar la traza de cada caso de uso del sistema a
través de los trabajadores y casos de uso del negocio hasta los
clientes del negocio. Además puede realizarse la traza desde un caso
de uso hasta los componentes que implementan el sistema.

z Trazas.
z Relación del modelo con los casos de uso del sistema:
9 El modelo del negocio y la ingeniería del software combinados
permiten hacer el seguimiento de las necesidades del cliente a lo
largo del camino completo a través de procesos del negocio,
trabajadores y caso de uso, hasta el código del software.
9 Sin embargo, usando el modelo del dominio, no hay forma evidente
de hacer traza entre éste y los casos de uso del sistema.

z Trazas.
z Relación del modelo con los casos de uso del sistema.

Fases para el Desarrollo

Fases del desarrollo de software
Fase de Inicio
Fase de Elaboración
Fase de Construcción
Fase de Transición
Mantenimiento

Ejemplo a Desarrollar
Ejemplo a desarrollar como ejercicio:
z Anillamiento de Aves.
z ¿En qué consiste el anillamiento?
Planteamiento general del problema.

PLANIFICACIÓN DE LAS FASES

Planificación
El proceso de desarrollo de software está dividido en
cuatro fases cada una de las cuales se ejecuta mediante
una o varias iteraciones.
Además, cada iteración consta de una o varias
construcciones.
Por tanto, existen dos tipos de planificación:
z El plan del proyecto, que engloba las cuatro fases.
z El plan de iteración, referente a una iteración concreta.
Los planes se controlarán mediante HITOS.

Planificación
Hitos:
z Definición:
9 Criterios que se deben cumplir al llegar a un determinado punto del
desarrollo.
z Necesidad:
9 Seguimiento de la planificación.
9 Evaluación del trabajo realizado.
9 Sincronización del proyecto (si es llevado a cabo por distintos grupos
en paralelo).
z Tipos:
9 Principales, al final de cada fase.
9 Secundarios, al final de una iteración o de una construcción.

Planificación
Hitos:
z Definición.
z Necesidad.
z Tipos.
z Hitos principales:
9 Fase de Inicio:
8 Objetivos del ciclo de vida.
9 Fase de Elaboración:
8 Arquitectura del ciclo de vida.
9 Fase de Construcción:
8 Capacidad operativa inicial.
9 Fase de Transición:
8 Lanzamiento del producto.

Planificación
Hitos:
z Definición.
z Necesidad.
z Tipos.
z Hitos principales.

FASE DE INICIO

VISIÓN GENERAL DE LA FASE

Objetivos de la Fase
Objetivos:
z Delimitar el ámbito y el alcance del sistema:
9 Se pretende conocer el entorno (ámbito) del sistema, es decir, el
campo del que se ocupa el sistema.
9 Dentro de este campo, con el que debe familiarizarse el equipo, se
delimita el alcance del sistema, es decir, qué tareas de todas las
posibles dentro del ámbito realiza el sistema.
9 La decisión sobre qué debe realizar el sistema, teniendo en cuenta
‘dónde’ se encuadra el mismo, debe hacerse de acuerdo con el
cliente.

Objetivos de la Fase
Objetivos:
z Delimitar el ámbito y el alcance del sistema.
z Justificar la puesta en marcha del proyecto:
9 El objetivo es conocer las posibilidades de llevar a cabo el sistema,
comprobando si las tareas encomendadas son viables y si los riesgos
que comportan dichas tareas pueden ser tratados.
9 Opcionalmente se puede realizar un prototipo exploratorio que
muestre que se puede llegar a desarrollar el sistema, pero que no
tiene porqué ser definitivo.

Planificación de la Fase
Planificación:
z Alcance:
9 Se desarrolla un plan para crear una arquitectura candidata sólo
hasta el punto de establecer si el proyecto es factible.
z Actividades:
9 Reunir la información recogida antes de comenzar el proyecto.
9 Organizarla.
9 Reunir un grupo de gente para que la trate.
9 Descubrir qué falla en términos de los objetivos de la fase de inicio.

Hitos de la Fase
Hito principal << Objetivos del ciclo de vida>>.
z ¿Se ha determinado con claridad el ámbito del sistema?¿Se ha
determinado lo que va a estar dentro del sistema y lo que va a estar
fuera de él?
z ¿Se ha llegado a un acuerdo con todas las personas involucradas sobre
los requisitos fundamentales del sistema?
z ¿Se vislumbra una arquitectura que implemente estas características?
z ¿Se han identificado los riesgos críticos para el desarrollo exitoso del
proyecto? ¿Se prevé una forma de tratarlos?
z ¿El uso del producto generará beneficios que justifiquen lo invertido en su
construcción?
z ¿Es factible para su organización llevar adelante el proyecto?
z ¿Están los inversores de acuerdo con los objetivos?

Evaluación de la Fase
Evaluación:
z Ámbito del sistema:
9 ¿Está claro lo que va a formar parte del sistema?
9 ¿Se han identificado todos los actores?
9 ¿Se ha expuesto la naturaleza general de las interfaces?
9 ¿Puede, lo que está incluido en el ámbito, constituir por sí mismo un
sistema que funcione?
z Ambigüedades en los requisitos:
9 ¿Se han identificado y detallado los requisitos de los casos de uso
necesarios para alcanzar los objetivos de esta fase?
9 ¿Se han identificado y detallado los requisitos adicionales?

Fase de Inicio
Evaluación:
z Ámbito del sistema.
z Ambigüedades en los requisitos.
z Arquitectura candidata:
9 ¿Satisface esta arquitectura las necesidades de los usuarios?
9 ¿Es factible que funcione?
8 ¿Puede usar de forma apropiada la tecnología sobre la que va a
ser construida?
8 ¿Puede ser eficiente?
8 ¿Puede explotar los recursos existentes?
8 ¿Puede ser fiable y tolerante a fallos?
8 ¿Será robusta y flexible al cambio?
8 ¿Evolucionará fácilmente si se añaden requisitos?

Fase de Inicio
Evaluación:
z Arquitectura candidata.
z Mitigar riesgos críticos:
9 ¿Se han identificado todos los riesgos críticos?
9 ¿Se han mitigado los riesgos identificados o existe un plan para
mitigarlos?
z Juzgar el valor del análisis de negocio inicial.

Fase de Inicio
Evaluación:
z Arquitectura candidata.
z Mitigar riesgos críticos.
z Juzgar el valor del análisis de negocio inicial.

DESARROLLO DE LA FASE

Fase de Inicio
Primera iteración:
z Actividades preliminares:
9 Ajustar la metodología al proyecto y seleccionar herramientas para la
automatización del proceso.
9 Reunir gente con el talento necesario para el proyecto.
9 Crear relaciones que den lugar a un equipo efectivo.
9 Entender el dominio, que a menudo es desconocido para el equipo.
9 Percibir la naturaleza del proyecto, será más difícil si se trata de un
desarrollo nuevo que si se trata de la extensión de un producto ya
existente.
9 Familiarizar al equipo con las herramientas apropiadas.

Ajuste al entorno de desarrollo
Se inicia en esta fase y se culmina en la de elaboración.
Entorno de desarrollo:
z Procesos (configuración).
z Herramientas para llevarlos a cabo.
z Servicios (administración del sistema, copia de seguridad y
telecomunicaciones).

PSI 1.1 Fin Inicio PSI 1.2 Fin Inicio PSI 1.3 Fin Inicio PSI-SEG 1.1 Fin Inicio PSI-SEG 1.2
Completa Completa Completa Completa Completa
Fase Preliminar

Fase de Inicio
Actividades fundamentales:
z Definición del ámbito del sistema.
z Esbozar arquitectura candidata.
z Análisis inicial del negocio.
Trabajo a realizar en cada iteración:

z Planificación.
z Flujos de trabajo fundamentales.
z Evaluación.

Fase de Inicio
z Definición del ámbito del sistema.
z Esbozar arquitectura candidata.
z Análisis inicial del negocio.

z Planificación.
z Flujos de trabajo fundamentales.
z Evaluación.

Flujos de trabajo fundamentales
Captura de requisitos.
Análisis.
Diseño.
Implementación.
Prueba.

Captura de Requisitos
Captura de requisitos:
z Actividades:
9 Enumerar requisitos candidatos, lista de características.
9 Comprender el contexto del sistema.
9 Representar requisitos funcionales como casos de uso.
8 Encontrar actores y casos de uso.
8 Establecer prioridad.
8 Detallar los que se estimen necesarios para cumplir los objetivos
de la fase.
9 Recopilar requisitos no funcionales.

Análisis
Análisis:
z Objetivo:
9 El resultado debe ser un modelo inicial de análisis que defina con
precisión los casos de uso y que guíe el establecimiento de la
arquitectura candidata.
z Actividades:
9 Análisis de la arquitectura:
8 Identificar paquetes de análisis.
8 Clases de entidad.
8 Requisitos especiales comunes (persistencia, tolerancia a fallos,
etc...)
9 Analizar un caso de uso
8 Identificación de clases de análisis.
8 Descripción de interacciones entre objetos de análisis.
8 Captura de requisitos especiales

Análisis
Análisis:
z Objetivo:
z Actividades:
9 Análisis de la arquitectura.
9 Analizar un caso de uso.
9 Analizar una clase:
8 Trabajo mínimo.
9 Analizar un paquete:
8 Trabajo mínimo.

Resumen Análisis
Análisis:
z Objetivo:
z Actividades:
9 Analizar una clase.
9 Analizar un paquete.

Diseño
Diseño (Se puede desarrollar un prototipo de demostración):
z Actividades:
9 Diseño de la arquitectura:
8 Realizar los casos de uso como colaboraciones entre subsistemas
o clases.
8 Identificar mecanismos genéricos de diseño que serán necesarios
en las capas subyacentes de los subsistemas identificados.
8 Se elige el software del sistema y los marcos de trabajo que se
emplearán en la capa intermedia.
8 Se llevan a cabo tanto los requisitos funcionales representados
por los casos de uso como los no funcionales.
8 Si el sistema es distribuido se incluye una versión reducida del
modelo de despliegue

Diseño
Diseño:
z Actividades
9 Diseño de la arquitectura.
9 Identificar nodos y configuraciones de red.
9 Identificar subsistemas e interfaces:
8 Subsistemas de aplicación.
8 Subsistemas intermedios y de software del sistema.
8 Dependencias entre subsistemas .
8 Interfaces entre subsistemas .
9 Identificar clases de diseño relevantes para la arquitectura:
8 A partir de clases del análisis.
8 Identificar clases activas.
9 Identificación de mecanismos genéricos de diseño (conjuntos de
elementos del diseño encargados de los requisitos especiales).

Diseño
Diseño:
z Actividades
9 Identificar subsistemas e interfaces.
9 Identificar clases de diseño relevantes para la arquitectura.
9 Identificación de mecanismos genéricos de diseño.
9 Diseñar un caso de uso:
8 Trabajo mínimo.
9 Diseñar una clase:
8 Trabajo mínimo.
9 Diseñar un subsistema:
8 Trabajo mínimo.

Resumen del Diseño
Diseño:
z Actividades
9 Identificar subsistemas e interfaces.
9 Identificar clases de diseño relevantes para la arquitectura.
9 Identificación de mecanismos genéricos de diseño.
9 Diseñar un caso de uso.
9 Diseñar una clase.
9 Diseñar un subsistema.

Implementación y Prueba
Implementación:
z Sólo necesaria si se va a realizar el prototipo.
Prueba:
z Trabajo mínimo.

Arquitectura por capas
Capa específica de la aplicación
Capa general de la aplicación
Capa middleware
Capa de software del sistema

Capas:
z Definición:
9 Una capa es un conjunto de subsistemas que tiene el mismo grado de
generalidad.
z Características:
9 Las capas inferiores (middleware y de software del sistema) pueden
establecerse sin considerar los casos de uso ya que no son
dependientes del negocio.
9 Las capas superiores (general y específica de la aplicación) se crean a
partir de los casos de uso arquitectónicamente significativos, es decir,
son dependientes del negocio.
9 La capa general contiene subsistemas no específicos que pueden ser
reutilizados por muchas aplicaciones diferentes dentro del mismo
dominio o negocio.

Capas:
z Definición.
z Características.
z Interdependencia:
9 Los desarrolladores de las capas superiores construyen sobre las
capas inferiores estables, así subsistemas diferentes pueden reutilizar
casos de uso, subsistemas de bajo nivel, clases, interfaces,
colaboraciones y componentes de las capas inferiores.

Capas:
z Definición.
z Características.
z Interdependencia.

Análisis inicial del negocio
Análisis del negocio:
z Objetivo:
9 El análisis inicial de negocio sirve para determinar si se entra en la
fase de elaboración.
z Aspectos:
9 Costes económicos: exigencias de recursos del proyecto, costes de la
inversión.
9 Estimaciones de beneficios y de aceptación (de mercado o interna).

z Objetivo.
z Aspectos.
z Actividades:
9 Esbozar una apuesta económica:
8 Se toman los casos de uso como medida de tamaño para realizar
las estimaciones. La cantidad de horas-personas necesarias para
diseñar, implementar y probar un caso de uso depende de:
• Complejidad del sistema propuesto.
• Tamaño.
• Tipo de aplicación.

z Objetivo.
z Aspectos.
z Actividades:
9 Estimar la recuperación de la inversión:
8 Si es un software comercial deben estimarla los expertos en
ventas, si es para uso interno el cliente debe especificar el ahorro
esperado.

z Objetivo.
z Aspectos.
z Actividades.

Evaluación de iteraciones
Evaluación:
z Participantes:
9 Se crea un grupo de evaluación que incluye representantes del cliente
y/o de los usuarios.
z Posibles criterios para ampliar el número de iteraciones:
9 Ampliación del modelo de casos de uso.
9 Desarrollo de un prototipo exploratorio.
9 Sospecha de que no se hayan encontrado todos los riesgos críticos.
9 Si no han sido mitigados todos los riesgos críticos o no han sido
suficientemente cubiertos por un plan de emergencia
z Conclusión:
9 El resultado final de la evaluación determina si se sigue adelante o se
abandona el proyecto.

Planificación de la fase de Elaboración
Se determina alrededor del 80% de los casos de uso sin pasar por
alto nada que sea importante para la arquitectura para poder realizar
una apuesta económica exacta.
De los casos de uso identificados será necesario analizar
aproximadamente la mitad.
Del conjunto de casos de uso analizados se selecciona la parte más
significativa para el diseño de la línea de base de la arquitectura, que
incluye una descripción de la arquitectura y nuevas versiones de
todos los modelos.
Se determina el número de iteraciones y qué requisitos se
implementarán y probarán en cada iteración.

Productos Generados
1. Lista de características.
2. Primera versión del modelo de negocio.
3. Esbozo de los modelos de casos de uso, análisis, diseño y despliegue.
Los de implementación y pruebas serán rudimentarios. Primera
versión de los requisitos adicionales.
4. Primer esquema de la descripción de la arquitectura candidata que
perfila las vistas de los modelos de casos de uso, análisis, diseño e
implementación.
5. Prototipo exploratorio (opcional).
6. Lista inicial de riesgos y clasificación de casos de uso.
7. Rudimentos de un plan para el proyecto en su totalidad.
8. Primer borrador del análisis de negocio, incluyendo el contexto del
negocio y los criterios de éxito como estimación de beneficios,
reconocimiento de mercado y estimación del proyecto.

PSI 2.3
Primera versión
del plan de
trabajo, esbozo
o
EVS 3.1
ici
In
Catálogo de normas, se
PSI 3.1 PSI 3.2 Inicio Inicio
intenta completar
Información
Fin Inicio Requisitos aunque puede que sea
o
ici
relevante, generales, necesario hacerlo en la
cio
In
Fin Fin
In i completa completa fase posterior
cio PSI 3.2 Inicio-Inicio

PSI 2.1 PSI 2.2
Ini Modelo de negocio
Descripción de Fin Inicio
Catálogo de usuarios, PSI 4.1 PSI 4.2 PSI 4.3 EVS 1.2 EVS 1.3
procesos afectados, Inicio Inicio Inicio Inicio
completa aunque el se Inicio Inicio Necesidades de Fin Inicio Fin Inicio Usuarios y
completa Modelo de Requisitos de Dependencias
añaden usuarios a lo información, requisitos plan de
Procesos, los procesos, con otros
largo del proyecto. funcionales, diagrama Fin Fin trabajo de
completo completa proyectos,
Fin Fin de clases, completa visión global esta fase
del alcance
Fin
del sistema
EVS 3.3
Inicio
Catalogación
de requisitos
EVS 2.1
Inicio
Fin
io
Descripción de
Inic
sistemas actuales
completa si se
Inicio
tiene en cuenta la
Fin
arquitectura, si no
o i
se completa en la
Inic
EVS 3.2 EVS 2.4 EVS 2.3 EVS 2.2

siguiente fase
Inicio Inicio Diagnóstico Inicio Fin Descripción lógica Inicio Fin Participantes Inicio Fin
Identificación de la situación de los sistemas del estudio de
de requisitos actual, actuales, modelo la situación
completa físico, diagrama de actual
clases, completa
PSI 4.3 Fin-Inicio

Modelo de negocio
PSI 5.1 PSI 5.2 PSI 5.3 PSI 6.1
Inicio Inicio Inicio Inicio
Identificación Descripción Valoración de Sistemas que
de sistemas de sistemas sistemas Fin Inicio se conservan
afectados, afectados, afectados, y mejoras
completa Fin Fin completa Fin Fin completa propuestas,
completa
Fi
Fin n
In
io ici
o
Inic
Inicio Fin
Fin Fin Fin Fin
Inicio Inicio
Fin Fin
ASI 3.2 Fin-Inicio
DSI 3.3 División en subsistemas
Diseño de
DSI 3.1 DSI 3.2 Inicio Inicio interfaz de DSI 3.4
Identificación Interacción de Descripción de
Inicio Inicio Fin Fin usuario, caso
de clases de clases casos de uso en
o
muy concreto
ici
diseño anteriormente términos de

In
adicionales, identificadas, Inicio Inicio subsistemas e

n Fin Fin
ASI 9.3 Fin-Inicio Fi diseño de realización de interfaces, alto
Fin Fin
o
casos de uso casos de uso nivel

ici
Modelo de clases
In
DSI 4.1
n
Identificación Fi
de clases de
diseño, a
partir de las Inicio DSI 4.2 DSI 4.3 DSI 4.4 DSI 4.5 DSI 4.6 DSI 6.1 DSI 6.4
Inicio Inicio Inicio Inicio Inicio Inicio Inicio Inicio Inicio
de análisis Asociaciones Atributos de Pseudocódigo Especificación Distribución
Fi n y las clases
Operaciones Jerarquía del
de algún Fin Inicio Fin Inicio
de las clases, modelo de a alto nivel del de los datos a
Fi n agregaciones identificadas, método modelo físico muy alto nivel,
de las clases
Fin Fin caso concreto
Fin Fin caso concreto Fin Fin clases Fin Fin concreto de datos si modelo de
identificadas mejora la datos no
DSI 3.3,3.4,6.4 Fin-Inicio
comprensión optimizado.
Productos obtenidos del sistema
DSI 7.2 DSI 8.1 DSI 8.2 DSI 10.1 DSI 10.2
Análisis de Especificación Inicio Inicio Especificación Inicio Inicio
consistencia Fin Inicio del entorno
Inicio Inicio Definición de del entorno de Niveles de
de los componentes pruebas para prueba
tecnológico
productos y subsistemas Fin Fin el prototipo Fin Fin
necesaria CSI 2.1 Inicio-Inicio
obtenidos necesarios
para la
Inicio
Fin
para el Código del prototipo
realización del
prototipo. CSI 3.1 CSI 3.2
prototipo
Preparación Realización y
Fin Inicio
Fin
Fin
del entorno de evaluación de

pruebas pruebas
cio
unitarias unitarias
Ini
Inicio
Inicio
CSI 2.1 Fin-Inicio
Inicio
Fin
Código del prototipo
Fin
CSI 1.2 CSI 2.1 CSI 4.1 CSI 4.2 CSI 4.3
Inicio Inicio
Preparación Preparación
DSI 10.3 Realización Evaluación de
del entorno de Generación Fin Inicio del entorno de Fin Inicio de pruebas de pruebas de
de código pruebas de
construcción Plan de integración Fin Fin integración
para el integración
pruebas
prototipo
CSI 2.1 Fin-Inicio
Fi
n Código del prototipo
In CSI 5.1 CSI 5.2 CSI 5.3
ici Inicio Inicio
o Preparación
Fin Inicio Realización Evaluación de
del entorno de
de pruebas pruebas del
pruebas del
sistema
del sistema Fin Fin sistema
Ejemplo Fase de
Inicio

FASE DE ELABORACIÓN

Objetivos:
z Crear una línea de base para la arquitectura que cubra la
funcionalidad arquitectónicamente significativa del sistema y las
características que las personas involucradas consideren
importantes.
z Identificar los riesgos significativos, es decir, los que podrían
perturbar los costes y planificaciones de fases posteriores,
reduciéndose a actividades que puedan ser medidas y
presupuestadas.
z Especificar los niveles a alcanzar por los atributos de calidad, como
la fiabilidad y los tiempos de respuesta.
z Recopilar los casos de uso del (aproximadamente) 80% de los
requisitos funcionales, suficiente para planificar la fase de
construcción.

Objetivos:
z Preparar una propuesta de planificación cubierta, personal
necesario y coste dentro de los límites establecidos por las
prácticas de negocio.
z Continuar la observación y control de los riesgos críticos restantes
y e identificar los riesgos significativos hasta el punto de poder
estimar su impacto en el análisis de negocio y en particular en la
apuesta económica.
z Completar los detalles del plan del proyecto.

Punto de vista:
z Para lograr los objetivos se toma un punto de vista general del
sistema, salvo en el caso en el que los riesgos técnicos
predominen o sean más significativos, en el que habrá que
profundizar hasta establecer una arquitectura sólida.
Conclusión:
z Al final de esta fase se decide si se abandona el proyecto o si se
lleva a cabo, en cuyo caso se realiza una apuesta económica y de
planificación que queda reflejada en un contrato. Por tanto, las
decisiones deben tomarse en base a estimaciones muy precisas.

Actividades preliminares:
z Se completa la planificación realizada en la fase de inicio.
z Se adapta el equipo de trabajo añadiendo personal para cubrir
nuevas necesidades.
z Se establecen los cambios necesarios en la definición del entorno
de desarrollo.

Hito principal:
z Arquitectura del ciclo de vida:
9 ¿Se ha creado un línea de base de la arquitectura?¿Es adaptable y
robusta?¿Puede evolucionar a lo largo de la vida del producto?
9 ¿Se han identificado y mitigado los riesgos graves hasta el punto de
asegurar que no trastornarán el plan de proyecto?
9 ¿Se ha desarrollado un plan de proyecto hasta el nivel necesario para
respaldar una agenda, costes y calidad realistas y que cubran la
apuesta?
9 ¿Proporcionará el proyecto, tal como está planificado y presupuestado
en este momento, una recuperación de la inversión?
9 ¿Se ha obtenido la aprobación de los inversores?

Evaluación:
z Extensión de requisitos:
9 ¿Se han identificado los requisitos, actores, y casos de uso necesarios
para diseñar la línea de base de la arquitectura?¿Se han identificado
los riesgos significativos?
9 ¿Se han detallado lo suficiente como para lograr los objetivos de esta
fase?
z Definición de la línea de base de la arquitectura:
9 ¿Satisface la línea de base de la arquitectura no sólo los requisitos
recopilados formalmente hasta ahora, sino también las necesidades
de todos los usuarios?
9 ¿Parece la línea de base de la arquitectura lo bastante robusta como
para resistir la fase de construcción y la adición de características que
puedan ser necesarias en posteriores versiones del sistema?

Evaluación:
z Extensión de requisitos.
z Definición de la línea de base de la arquitectura.
z Mitigar los riesgos significativos:
9 ¿Se han mitigado de forma adecuada los riesgos críticos, ya sea
eliminándolos o preparando un plan de emergencia?
9 ¿Se han identificado los riesgos significativos?
9 ¿Son los riesgos que aún permanecen en la lista de riesgos
susceptibles de ser eliminados de forma rutinaria en la fase de
construcción?

Evaluación:
z Mitigar los riesgos significativos.
z Valía del análisis de negocio:
9 ¿Está el plan del proyecto lo bastante definido como para apostar por
un precio, agenda y calidad?
9 ¿Parece verosímil que el análisis de negocio logre la recuperación de
la inversión o alcance el margen de beneficios que el negocio
impone?
9 ¿Estamos listos para redactar un contrato por un precio fijo o el
equivalente para un desarrollo interno?

Evaluación:
z Mitigar los riesgos significativos.
z Valía del análisis de negocio.

z Recopilación de la mayor parte de los requisitos:
9 Se identifica el 80% de los casos de uso.
9 Se describen entre el 40 y el 80% de los mismos.
9 La mitad de los casos de uso descritos se analizan.
9 Se seleccionan los que permitan obtener la arquitectura y mitigar los
riesgos para su diseño, implementación y prueba.
z Desarrollo de la línea de base de la arquitectura:
9 Se establece un orden de prioridad en los casos de uso y se realiza el
análisis, diseño e implementación a nivel de la arquitectura. También
se analizan clases y paquetes diseñándose clases y subsistemas.
9 Se construye el entorno de pruebas y se prueba la línea de base.
9 Los paquetes durante el análisis y los subsistemas durante el diseño
son críticos para generar las vistas de la arquitectura.

z Cuatro grupos de actividades ejecutándose en paralelo:
9 Planificación.
9 Flujos de trabajos fundamentales.
9 Evaluación.
9 Preparación más detallada del entorno de desarrollo.

Consideraciones:
z El número de iteraciones depende del ámbito del sistema, los
riesgos, el grado de novedad, la complejidad de las solución
técnica y la experiencia de los desarrolladores.
z Al ser el equipo pequeño se pueden ensayar diferentes soluciones
iterando hasta alcanzar una arquitectura estable que permita
realizar la fase de construcción, en la que aumenta el número de
personas.
z Se debe construir prestando más atención a la calidad y la
extensibilidad que en la fase de inicio.

Diferencias entre línea base y descripción
La descripción se realiza a alto nivel pero debe representar lo que
cada participante necesita para hacer su trabajo.
La línea base de la arquitectura debe ser operativa, por tanto, puede
ser necesarios incluir elementos no significativos para obtener esta
operatividad, estos elementos no serán incluidos en la descripción de
la arquitectura, la información necesaria para la validación o
verificación de la arquitectura tampoco será incluida en la descripción
aunque sí en la línea base.

z Actividades:
9 Encontrar casos de uso y actores.
9 Determinar la prioridad de los casos de uso.
9 Detallar un caso de uso.
9 Estructurar el modelo de casos de uso:
8 Mecanismos como extensión o generalización.
9 Desarrollar prototipos de las interfaces de usuario:
8 Casos muy concretos, en esta fase casi nunca se desarrollan.

Análisis:
z Elementos de trabajo:
9 Se trabaja con los casos de uso significativos desde el punto de vista
de la arquitectura y con los casos de uso complejos que se necesite
refinar para comprender mejor los detalles de la apuesta económica.
z Adaptar los requisitos a la arquitectura:
9 Si un cambio facilita el trabajo y su impacto es menor se negociará
con el cliente.
z Actividades:
8 Extender el análisis de la fase de inicio hasta el punto de que
pueda servir de línea de base de la arquitectura ejecutable.

Análisis:
z Elementos de trabajo.
z Adaptar los requisitos a la arquitectura.
z Actividades:
8 Se realiza una partición a alto nivel del sistema en paquetes de
análisis en base a la vista del modelo de casos de uso, los
requisitos relacionados con éstos, el glosario, y el análisis de
negocio.
8 Se identifican los mecanismos de análisis necesarios para los
requisitos especiales comunes como persistencia, distribución y
concurrencia, características de seguridad, tolerancia a fallos y
gestión de transacciones incluyendo colaboraciones y paquetes
genéricos.
8 Identificación de mecanismos subyacentes para implementar los
casos de uso.

Análisis:
z Análisis de la arquitectura.
z Actividades:
9 Analizar un caso de uso:
8 Se refinarán los casos de uso complejos y los que tienen impacto
en otros casos de uso, junto con los que son importantes
arquitectónicamente. Del resto de casos de uso sólo es necesario
comprender que no tendrán impacto.

Análisis:
z Actividades:
9 Analizar una clase:
8 Refinar las clases de análisis identificadas anteriormente
mezclando las responsabilidades que se les asignaron en los
diferentes casos de uso.
8 Se identifican los mecanismo de análisis y cómo fueron usados
por cada clase.
8 Los paquetes de servicio identificados en el análisis de la
arquitectura se refinan y mantienen

Análisis:
z Actividades:

Diseño:
z Alcance:
9 Se diseña e implementa menos del 10% de los casos de uso.
z Actividades:
8 Identificar la arquitectura en capas:
• Se vuelven a considerar la capa de software del sistema y la
capa intermedia y se seleccionan los productos que se van a
utilizar finalmente.
• Se seleccionan sus productos como implementación de los
mecanismos de diseño correspondientes a los componentes
de análisis identificados anteriormente.

Diseño:
z Alcance.
z Actividades:
8 Identificar la arquitectura en capas:
• Se pueden construir/desarrollar en paralelo con el análisis.
8 Identificar subsistemas y sus interfaces:
• En los niveles más altos de la arquitectura.
• En base a los paquetes del modelo de análisis se identifican
los subsistemas correspondientes y se incluyen en el
modelo de diseño
8 Identificar clases de diseño arquitectónicamente significativas
• Traducción de las clases de análisis significativas a clases de
diseño

Diseño:
z Alcance.
z Actividades:
8 Identificar de nodos y configuración de red (sistemas
distribuidos):
• Se estudia la concurrencia y distribución requerida por el
sistema.
• Se generan nuevas versiones de la vista de la arquitectura
de los modelos de diseño y despliegue y se incluyen en la
descripción de la arquitectura.

Diseño:
z Alcance.
z Actividades:
9 Diseño de un caso de uso:
8 Se entra en muchos más detalles que en el análisis, es necesario
adaptar el modelo de análisis al de diseño para que éste pueda
funcionar, ya que está limitado por los mecanismos de diseño.
8 Los paquetes y las clases de análisis proporcionan una forma
directa de encontrar subsistemas y clases de diseño.
9 Diseño de una clase:
8 Se diseñan las clases que participarán en las realizaciones de los
casos de uso del apartado anterior.

Diseño:
z Alcance.
z Actividades:
9 Diseño de un caso de uso.
9 Diseño de una clase.
9 Diseño de un subsistema:
8 Se diseñan los subsistemas resultantes del diseño de la
arquitectura, se actualiza si es necesario la vista de la
arquitectura del modelo de diseño.

Diseño:
z Alcance.
z Actividades:
9 Diseño de un caso de uso.
9 Diseño de una clase.
9 Diseño de un subsistema.

Implementación:
z Línea base de la arquitectura:
9 Deberá estar bajo el control de alguna herramienta.
8 Se implementan y prueban los componentes arquitectónicamente
significativos a partir de los elementos de diseño homólogos.
8 El resultado es la línea de base implementada a partir de menos
del 10% de los casos de uso.
z Actividades:
9 Implementación de la arquitectura:
8 En base a la vista de la arquitectura de los modelos de diseño y
de despliegue se identifican los componentes necesarios para
implementar los subsistemas de servicio.
8 Los componentes ejecutables se asignan a los nodos en los que
van a ejecutarse.
8 Se genera la vista de la arquitectura del modelo de
implementación.

Implementación:
z Línea base de la arquitectura.
z Actividades:
9 Implementación de la arquitectura.
9 Implementación de una clase (subsistemas implícitos):
8 Se implementan las clases de diseño relevantes para la creación
de la línea de base de la arquitectura en términos de
componentes.
8 Las pruebas unitarias aseguran que cada componente funciona
como una unidad.
8 La línea de base de la arquitectura resultante es una versión
ejecutable preliminar del sistema.
9 Integrar el sistema:
8 Se establece un plan de integración y se integran los subsistemas
y los componentes correspondientes en una línea de base de la
arquitectura ejecutable.

Implementación:
z Línea base de la arquitectura.
z Actividades:
9 Implementación de una clase (subsistemas implícitos).
9 Integrar el sistema.

Prueba:
z Alcance:
9 Hay que asegurarse de que los subsistemas de servicio y de diseño
de todas las capas funcionan, sólo se podrán probar componentes
ejecutables.
9 En las capas más bajas de la arquitectura se prueban los mecanismos
de distribución, almacenamiento, recuperación (persistencia) y
concurrencia de objetos, así como otros mecanismos.
9 Se comprueba no sólo la funcionalidad sino también el rendimiento.
9 En las capas específicas y generales de la aplicación las pruebas
miden la facilidad de escalar el sistema al incorporar nuevos
subsistemas que usan interfaces y previstas.

Prueba:
z Alcance.
z Actividades:
9 Planificar las pruebas:
8 Se seleccionan los objetivos que evaluarán la línea de base de la
arquitectura.
9 Diseñar las pruebas:
8 Se identifican los casos de prueba necesarios y se preparan
procedimientos de prueba para comprobar la sucesiva
integración de subsistemas hasta completar la línea de base de la
arquitectura.
9 Realizar pruebas de integración:
8 Se comprueba cada construcción.
9 Realizar pruebas del sistema:
8 Una vez se ha integrado el sistema se prueba.

Prueba:
z Alcance.
z Actividades.
z Evaluación:
9 Se revisan los resultados de las pruebas para verificar que se
cumplen los objetivos originales o para decidir cómo modificar los
casos de prueba para alcanzar dichos objetivos.

Prueba:
z Alcance.
z Actividades.
z Evaluación.

Desarrollo del análisis de negocio
z Alcance:
9 Se mitigan los riesgos y se desarrolla la línea de base de la
arquitectura para poder comenzar la fase de construcción con la
seguridad de construir el producto dentro de los límites del negocio.
9 Límites del negocio:
8 La planificación, esfuerzo y costes estimados para una calidad
dada.
8 La recuperación de la inversión, indicando que el sistema
propuesto será económicamente un éxito.
9 Se deben estrechar los márgenes de error ampliamente respecto a
la fase de inicio, preparándose la apuesta económica y
desarrollándose el análisis de negocio dentro de los márgenes de la
práctica empresarial.

z Alcance.
z Actividades:
9 Preparar la apuesta económica:
8 La fase de construcción se desarrollará desde el punto de vista
del negocio, independientemente del tipo de acuerdo:
• Contrato con un cliente.
• Acuerdo con un departamento de la empresa.
• Desarrollo de un producto para su lanzamiento al mercado.
8 Las estimaciones del software se basan en el tamaño del
proyecto y la productividad de la organización de desarrollo.
8 La productividad se deriva de la experiencia.

z Alcance.
z Actividades:
9 Preparar la apuesta económica:
8 El tamaño estimado se basa en el trabajo realizado en esta fase
que permite estimar el que se realizará en la fase de
construcción, lo proporciona la línea de base de la arquitectura.
8 Si el proyecto presenta riesgos de cierta magnitud se investigan
hasta estimar cuánto tiempo y esfuerzo llevará superarlos.
9 Actualizar la recuperación de la inversión:
8 En caso de ser un producto para la venta los expertos en ventas
deberán considerar número de unidades vendidas, precio y
periodo de ventas.
8 Si es un producto interno el departamento “destino” deberá
estimar su ahorro.
8 El margen de error es muy grande.

z Alcance.
z Actividades:
9 Preparar la apuesta económica.
9 Actualizar la recuperación de la inversión.

Evaluación:
z Actividades:
9 Comprobar que la línea de base de la arquitectura representa una
arquitectura capaz de llevar a cabo los objetivos iniciales y mitigar los
riesgos.
9 Al final de cada iteración se evalúa si se han conseguido los objetivos
establecidos, en caso contrario se reorientan las iteraciones
siguientes.
9 Al final de esta fase la evaluación debe convencer a todos los
implicados en el proyecto de que se han mitigado los riesgos graves y
se ha construido una línea de base de la arquitectura estable.
z Ventajas:
9 Al haber involucrado al cliente en los hitos secundarios, éste estará
más preparado para encarar los hitos principales y habrá tenido
oportunidad de sugerir mejoras, de participar en el proceso.

Evaluación:
z Actividades.
z Ventajas.
z Conclusión:
9 Si la evaluación es satisfactoria el sistema podrá ser construido de
acuerdo al plan del proyecto y a la apuesta económica para la fase de
construcción.

Evaluación:
z Actividades.
z Ventajas.
z Conclusión.

Planificación de la fase de Construcción
Se planifica de forma detallada la primera iteración de la fase de
construcción y se esbozan en términos generales las iteraciones
restantes.
El número de iteraciones depende del tamaño y complejidad del
proyecto.
En cada iteración se esbozan una serie de construcciones que
añadirán piezas relativamente pequeñas
Se planifica el orden en que se investigarán los riesgos remanentes
con objeto de mitigar cada uno de ellos antes de que aparezca en la
secuencia de construcciones o iteraciones.

Planificación de la fase de Construcción
Secuenciar las construcciones e iteraciones:
z En proyectos grandes con restricciones temporales se realiza esta
tarea buscando rutas que permitan trabajar en paralelo.
z El trabajo en paralelo se centra en los subsistemas establecidos en
la línea de base de la arquitectura ya que las interfaces
previamente definidas permitirán trabajar en los distintos
subsistemas de forma independiente.
z Estos subsistemas determinan el despliegue de los participantes
en esta fase.
z Esta independencia en el trabajo se basa en unas interfaces
sólidas.

Productos generados
1. Modelo de negocio completo que describa el contexto del sistema.
2. Nueva versión de todos los modelos; casos de uso, análisis, diseño,
despliegue e implementación.
3. Línea de base de la arquitectura.
4. Descripción de la arquitectura que incluya vistas de los modelos.
5. Lista de riesgos actualizada.
6. Plan de proyecto para las fases de construcción y transición.
7. Manual de usuario preliminar (opcional).
8. Análisis de negocio completo, incluida la apuesta económica.

Inicio Inicio
Fin Fin
ASI 4.2 Inicio-Inicio, Fin-Fin
Realización de casos de
uso
ASI 4.1 ASI 5.1 ASI 5.2 ASI 5.3
Inicio Inicio Inicio Inicio Inicio Inicio
Identificación
n io
Identificación
Fi Inic
Responsabilidades de Identificación de
de clases de
y atributos de las agregaciones generalizaciones
análisis Fin Fin Fin Fin Fin Fin
clases anteriores y
asociaciones

ASI 4.2
io
io
Inic
n c io
Casos de uso
Inic
Análisis de
Fi Ini
arquitectónicamente
realizaciones de casos
significativos Fin de uso, descripción de
ASI 2.4
Ini ci o interacción de objetos
Fin
Fin
Validación de Fin
casos de uso
Inicio ASI 1.3 Inicio-Inicio
Inicio Normas y estándares
anteriores Inicio
Fin ASI 9.1
ASI 3.1 Inicio Inicio ASI 3.2 ASI 9.2
Fin Descripción Verificación
Fin Inicio Análisis de
de la
de Integración de Fin Inicio consistencia muy
Fi
In
n
subsistemas e subsistemas arquitectura

exhaustivo de la
ici
Fin Fin del sistema

o
interfaces arquitectura
In
c io
i
Ini
cio
Fin
Fi
n
ASI 8.3 ASI 8.4 ASI 8.5

Definición de Identificación Formatos de
alguna y impresión,
pantalla especificación caso muy
necesaria de los concreto
para la diálogos
comprensión considerados
de un caso de críticos
uso concreto
Fin
Fin
Ini
io c
Inicio
Inicio Inicio
Fin Fin
Fin
In
ic
Fi Ini
n
io
c io
In
In
ici
Fin
o
Fi icio
n
I
Finnicio
Inic
i
Fin o
Inicio Inicio
Fin Fin
Ini
Fin cio
Inic
io
Fin
Inic
Inicio
io
Fin
Fi n I n ic
io
Fin
Inicio
Fin
Fi n
Inic
io
EVS-CAL 2.3
EVS 4.2 Inicio-Inicio, Fin-Fin EVS 5.3 Inicio-Inicio, Fin-Fin Análisis de EVS 6.2 Fin-Inicio EVS 6.3 Fin-Inicio
Alternativas de solución Alternativas de solución consistencia Solución propuesta Solución aprobada
EVS-CAL 1.1 EVS-CAL 1.2 EVS-CAL 1.3 EVS-CAL 2.1 EVS-CAL 2.2 Inicio Inicio de la
EVS-CAL 3.1 EVS-CAL 3.2
Inicio Inicio Inicio Inicio Inicio Inicio arquitectura
Se constituye el Determinación Identificación Necesidad del Alcance del plan Fin Fin Ajuste del
Aprobación
equipo de Fin Inicio de sistemas de plan de de plan a la Fin Inicio del plan de la
calidad y el plan objeto del propiedades aseguramiento aseguramiento solución
Fin Fin Fin Fin Fin Fin Fin Inicio solución
de acción aseguramiento de calidad de la calidad de de la calidad de selecionada
de la calidad cada alternativa cada alternativa
ASI 2.4 Inicio-Inicio ASI 9.3 Inicio-Inicio, Fin-Fin ASI 10.3 Fin-Inicio
EVS-CAL 3.1 Fin-Inicio Catálogo de requisitos Validación de la arquitectura Plan de pruebas
Plan para la solución ASI-CAL 3.1 ASI-CAL 3.2 ASI-CAL 4.1
Inicio Inicio
ASI-CAL 1.1
Revisión del Revisión de Fin Inicio Revisión del
Definición catálogo de consistencia plan de
detallada del Inicio Inicio ASI-CAL 2.1 requisitos de productos pruebas
plan de
Inicio Inicio Fin Fin
Actividades y
aseguramiento
tareas del
de la calidad de
la solución Fin Fin plan
In
ici
DSI 7.2 Inicio-Inicio, Fin-FIn

o
DSI 7.3 Fin-Inicio DSI 10.2 Inicio-Inicio, Fin-Fin DSI 10.3 Inicio-Inicio, Fin-Fin
Análisis de consistencia de
la arquitectura Aceptación del diseño Pruebas Pruebas
In
DSI-CAL 1.1 DSI-CAL 1.2 DSI-CAL 2.1 DSI-CAL 2.2

ici
Inicio Inicio
o
Revisión de Revisión de
Fin Inicio Aceptación de Revisión del
consistencia Fin Inicio pruebas
la arquitectura plan de
de productos unitarias, del
del sistema pruebas
del diseño sistema y de Fin Fin
aceptación
CSI 2.2 Inicio-Inicio, Fin-Fin CSI 3.2 Inicio-Inicio, Fin-Fin CSI 4.3 Inicio-Inicio, Fin-Fin CSI 5.3 Inicio-Inicio, Fin-Fin
Código generado Pruebas unitarias Pruebas de integración Pruebas del sistema
CSI-CAL 1.1 CSI-CAL 2.1 CSI-CAL 2.2 CSI-CAL 2.3
Revisión de Fin Inicio Revisión de Revisión de Revisión de
normas de pruebas pruebas de pruebas del
construcción unitarias Fin Fin integración Fin Fin sistema
PSI 9.2, EVS 3.2
Inicio-Inicio, Fin-Fin
EVS 6.2 Fin-Inicio
Arquitectura y
requisitos Solución propuesta
EVS-GC 1.1 EVS-GC 2.1 EVS-GC 2.2 GC 1.1 GC 2.1
Inicio Inicio
Entorno Identificación Identificación
Requisitos de la Inicio Inicio Plan de
tecnológico y registro de y registro de
gestión de la gestión de la
para la productos productos
configuración configuración Fin Fin gestión de la generados en globales
configuración esta fase
EVS 6.2 Fin-Inicio

Solución propuesta
GPI 1.1 GPI 1.2 GPI 2.1 GPI 2.2 GPI 2.3 GPI 2.4 GPI 2.5
Estimación Adaptación de
Fin Inicio Selección de Fin Inicio Fin Inicio Planificación Fin Inicio Aceptación de
del esfuerzo, Cálculo del la Calendario de
la estrategia general del la
identificación esfuerzo metodología hitos y
Fin Fin de desarrollo Fin Fin proyecto planificación
de elementos al proyecto entregas
a desarrollar
GPI 2.4 Inicio-Inicio, Fin-Fin GPS 3.1 GPS 4.2

Planificación del proyecto Propuesta de
Seguimiento
GPS 1.1 Inicio Inicio GPS 2.1 Inicio Inicio solución a la
de tareas GPS 4.1 GPS 4.3
Comunicación incidencia
Asignación de Fin Fin Fin Fin
de la Gestión de
tareas a
Fin Inicio asignación de Inicio Inicio incidencias, Fin Inicio Registro de la
miembros del tareas al análisis del incidencia
proyecto Fin Fin
Fin equipo impacto
Inic
i o
GPS 10.1
Resumen final
Ini n
de una tarea
cio
Fi
finalizada
Ini
cio n
Fi
GPS 3.1 Inicio-Inicio, Fin-Fin

Seguimiento de tareas
GPS 11.1 GPS 11.2 GPS 11.3 GPS 12.1
Actualización Simulación,
Reunión
de la extrapolación Informe de
interna de
planificación de la situación seguimiento
Fin Fin Fin Fin Fin Fin seguimiento
de tareas del proyecto
FASE DE CONSTRUCCIÓN

Objetivos:
z Se pretende tener un producto preparado para ser distribuido
como versión beta, es decir, para ser sometido a pruebas en un
entorno distinto al de desarrollo.
9 El producto tendrá la calidad adecuada y cumplirá los requisitos.
9 Su construcción tendrá lugar dentro de los límites del plan de
negocio.
z Mitigar todos los riesgos, excepto los que derivan de la operación
con el sistema que son tratados en la fase de transición.
z Ajustar la construcción a la arquitectura.
9 Sin embargo, se puede modificar la arquitectura para incorporar los
cambios que surjan en esta fase si es necesario.

Actividades (A partir de la línea de base de la arquitectura):
z Culminación de las tareas de identificación de requisitos, análisis,
diseño e implementación iniciadas en fases anteriores.
9 Se detallan los casos de uso y escenarios restantes, se modifica si es
necesario la descripción de la arquitectura y se cierran los modelos de
análisis, diseño e implementación.
z Asignación de prioridad a los casos de uso, agrupándolos en
construcciones e iteraciones y desarrollándolos en un orden que
evite la vuelta atrás.
z Mantenimiento de la integridad de la arquitectura, modificándola
sólo cuando sea necesario.
z Integración y prueba de cada subsistema y del sistema completo.
z Seguimiento de riesgos críticos arrastrados de fases anteriores y
mitigación si se materializan.
z Actualización de la lista de riesgos.

Enfoque:
z Se cambia el enfoque del proyecto, así mientras las fases de inicio
y elaboración se centraban en la acumulación del conocimiento
básico necesario para construir el proyecto, investigación, la de
construcción se centra en la construcción propiamente dicha del
sistema dentro de unos parámetros de coste, esfuerzo y agenda,
desarrollo.
Consideraciones:
z Esta fase requiere más personal, más tiempo y más iteraciones
que las anteriores, por eso es tan importante tener bien
preparados todos los detalles antes de empezar esta fase.

Hito principal:
z Capacidad operativa inicial:
9 ¿Es el nivel de capacidad el adecuado para realizar las pruebas beta
en el entorno del usuario?
9 Es muy importante el secuenciamiento de construcciones e
iteraciones.
9 Un buen secuenciamiento propicia que los prerrequisitos de cada
iteración sean los correctos, y evita tener que dar marcha atrás y
rehacer una iteración previa debido a algo aprendido más tarde.

Tareas preliminares:
z Planificación:
9 Es posible que la planificación de la fase de construcción se modifique
de acuerdo con la autorización recibida por los responsables
financieros.
z Asignación de personal:
9 La división del trabajo se realiza basándose en la que en la línea de
base de la arquitectura se representa con subsistemas e interfaces.
9 El número de trabajadores es aproximadamente el doble del de la
fase de elaboración.
z Establecimiento de criterios de evaluación:
9 Los criterios de evaluación para los casos de uso se basan en los
requisitos funcionales y no funcionales relacionados con el caso de
uso.

z Planificación.
z Asignación de personal.
z Establecimiento de criterios de evaluación:
9 El material adicional debe ser evaluado:
8 Material de usuario:
• Guías de usuario, textos de ayuda, notas de versión,
manuales de usuario.
• ¿Son suficientes para dar soporte a los usuarios en la fase
de transición?
8 Material de cursos:
• Diapositivas, notas, ejemplos y tutoriales.
• ¿Son suficientes para dar soporte a los usuarios en la fase
de transición?

z Planificación.
z Asignación de personal.
z Establecimiento de criterios de evaluación.

z Cuatro grupos de actividades ejecutándose en paralelo:
9 La planificación.
9 Los cinco flujos de trabajo fundamentales.
9 La evaluación.
9 El análisis de negocio.

Construcción del sistema:
z A medida que se van realizando iteraciones el énfasis se desplaza
desde los flujos de trabajo iniciales hacia los finales.
z Los requisitos y la arquitectura son estables.
z Se completa la realización de los casos de uso diseñando los
subsistemas y clases necesarias, implementándolos como
componentes y probándolos tanto de forma individual como en
construcciones.
z Los incrementos se ordenan de forma progresiva para que no sea
necesario volver atrás.
z Construir con incrementos relativamente pequeños reduce el
ámbito de los flujos fundamentales y aísla en gran parte los
riesgos y defectos haciéndolos más fáciles de localizar y tratar.
z Pueden aparecer riesgos nuevos a medida que se realizan
construcciones y los usuarios prueban nuevos incrementos.

z Objetivo:
9 Identificar y detallar todos los requisitos.
z Actividades:
9 Encontrar actores y casos de uso:
8 Si es necesario se actualizan los casos de uso y el modelo de
casos de uso.
9 Desarrollar un prototipo de la interfaz de usuario:
8 Si hay casos de uso que requieren una interfaz de usuario muy
complicada, será necesario realizar un prototipo para que los
usuarios lo prueben y lo amolden a sus necesidades.
8 Esta tarea es necesario realizarla en el flujo de requisitos no de
diseño, convirtiéndose el prototipo en la especificación de la
interfaz de usuario.

z Objetivo.
z Actividades:
9 Desarrollar un prototipo de la interfaz de usuario:
8 Para sistemas comerciales se realizará el prototipo
independientemente de la complejidad de la interfaz de usuario
pues el coste de sustituir la interfaz una vez el producto ha sido
distribuido es muy grande.
9 Determinar la prioridad de los casos de uso:
8 A medida que se identifican casos de uso se añaden a la
clasificación realizada en la fase anterior con objeto de establecer
su prioridad.

z Objetivo.
z Actividades:
9 Desarrollar un prototipo de la interfaz de usuario.
9 Detallar un caso de uso:
8 Se detallan completamente los casos de uso y escenarios
restantes, trabajando con ellos según su importancia.
9 Estructurar el modelo de casos de uso:
8 Ya que la arquitectura es estable los cambios deben referirse a
los casos de uso aún no desarrollados.

z Objetivo.
z Actividades:
9 Desarrollar un prototipo de la interfaz de usuario.
9 Detallar un caso de uso.
9 Estructurar el modelo de casos de uso.

Análisis:
z Alcance:
9 Se tienen en cuenta todos los casos de uso pero eso no significa que
haya que extender el modelo de análisis, puede que éste no se
mantenga y se cree uno nuevo.
9 La vista de la arquitectura, la parte realizada en la fase de
elaboración, será sólo un subconjunto del modelo de análisis.
z Objetivo:
9 Si se mantiene el objetivo será completarlo al final de esta fase.
z Actividades:
8 Actualizaciones, trabajo mínimo.

Análisis:
z Alcance.
z Objetivo.
z Actividades:
8 Se refinan para adaptarlos a los nuevos casos de uso.

Análisis:
z Alcance:
z Objetivo:
z Actividades:

Diseño:
z Alcance:
9 Se diseña e implementa el 90% de los casos de uso, los no incluidos
en la línea de base de la arquitectura.
9 Se actualizarán, introduciendo mejoras, los modelos de diseño y
despliegue.
z Actividades:
8 Por lo general no se añaden subsistemas de diseño ni de servicio.
Se pueden añadir subsistemas similares o alternativos a los
existentes.

Implementación:
z Alcance:
9 Se implementan y se llevan a cabo las pruebas de unidad de todos los
componentes, trabajando a partir del modelo de diseño.
9 Se obtiene la versión operativa inicial, que representa el 100% de los
casos de uso.
9 En cada construcción se van completando partes de los componentes
hasta que tras la última construcción, esto es, la última iteración,
todos los componentes está completos.
z Actividades:
9 Implementación de la arquitectura:
8 Actualizaciones, poco trabajo.

Implementación:
z Alcance.
z Actividades:
9 Implementación de una clase y de un subsistema:
8 Se implementan las clases y subsistemas del modelo de
implementación, y las clases stub cuando sea necesario para
armar una construcción.
9 Realizar prueba de unidad:
8 Si es necesario se corregirá el diseño y la implementación del
componente.

Implementación:
z Alcance.
z Actividades:
9 Implementación de una clase y de un subsistema.
9 Realizar prueba de unidad.
8 Se crea un plan de integración de construcciones que perfile la
secuencia de construcciones.
8 El plan muestra los casos de uso o escenarios que se van a
implementar en la construcción.
8 Normalmente se empiezan a construir las capas inferiores (la del
software del sistema o la intermedia), las construcciones
siguientes se expandirán hacia arriba (capas general y específica
de la aplicación).

Implementación:
z Alcance.
z Actividades:
8 Es difícil montar una construcción sin las funciones de apoyo que
proporcionan las capas inferiores.
8 Se reunirán clases completas y stub en una construcción
ejecutable de acuerdo con el plan de construcción, realizando
construcciones cada vez mayores, mientras los encargados de las
pruebas de integración y regresión las comprueban.

Implementación:
z Alcance.
z Actividades:
8 Al final de cada iteración se conecta el sistema entero y se hacen
pruebas de integración y regresión.
8 Esta planificación establece la secuencia de construcciones e
iteraciones de esta fase.
8 A menudo existen dependencias de compilación de las capas
superiores respecto a las capas inferiores, puede que haya que
planificar la compilación de abajo a arriba.

Implementación:
z Alcance.
z Actividades:
z Representación de componentes no construidos:
9 Facilitan la limitación del tamaño de la construcción.
9 Stub Æelemento muy sencillo que simplemente proporciona una
respuesta a un estímulo, a todos aquellos que un componente puede
recibir de otros componentes de la construcción.
9 Driver Æproporciona estímulos a los otros componentes que forman
parte de la construcción que se está probando.

Implementación:
z Alcance.
z Actividades:
z Representación de componentes no construidos.

Prueba:
z Actividades:
9 Planificar pruebas:
8 Se seleccionan los objetivos que comprueben las sucesivas
construcciones y finalmente el propio sistema.
9 Diseñar pruebas:
8 Se determina cómo probar los requisitos en el conjunto de
construcciones, para verificar los requisitos que puedan ser
comprobados.
8 Se preparan casos y procedimientos de prueba, de los de
construcciones precedentes se seleccionan los que aún sean
útiles y se modifican para utilizarlos en pruebas de regresión de
las construcciones posteriores.
8 Se verifican los componentes que deben ser comprobados
conjuntamente, pruebas de integración, verificando las interfaces
entre los componentes y comprobando que éstos pueden
trabajar conjuntamente.

Prueba:
z Actividades:
9 Planificar pruebas.
9 Diseñar pruebas.
9 Realizar pruebas de integración:
8 Se ejecutan los casos de prueba siguiendo los procedimientos de
prueba.
8 Si la construcción supera las pruebas, se van añadiendo
construcciones adicionales y se van comprobando.
8 Si se detectan fallos se registran y se notifican al jefe de
proyecto, éste determinará el siguiente paso a dar:
• Prolongar el trabajo de la construcción.
• Corregir en la siguiente.
• Si el fallo es muy grave, asignar un equipo cualificado para
investigarlo.

Prueba:
z Actividades:
9 Diseñar pruebas.
9 Realizar pruebas de integración.
9 Realizar pruebas del sistema:
8 Cuando se termina una iteración se obtiene una versión parcial
del sistema y se realizan las pruebas del sistema.
8 Se ejecutan los casos de prueba del sistema siguiendo los
procedimientos de prueba del sistema.
8 Si se detectan fallos se registran y se notifican.
8 Al final de esta fase se comprueba la versión operativa inicial

Prueba:
z Actividades:
9 Diseñar pruebas.
9 Realizar pruebas del sistema.
9 Evaluar las pruebas:
8 A medida que transcurren las pruebas de integración y del
sistema se revisarán los resultados al final de cada construcción
en función de los objetivos fijados en el plan de pruebas, que
puede haber sido modificado.
8 Si una prueba no alcanza sus objetivos los casos y
procedimientos de prueba deberán ser modificados.

Prueba:
z Actividades:
9 Diseñar pruebas.
9 Realizar pruebas del sistema.
9 Evaluar las pruebas.

Control del análisis de negocio
Actividades:
z Se compara el progreso real al final de cada iteración con la
agenda, esfuerzo y costes planificados en la fase de elaboración.
z Se revisan los datos de productividad del proyecto.
Medición del progreso:
z El código desarrollado no es una buena medida puesto que uno de
los objetivos es la reutilización de código, una medida más
efectiva es la finalización de construcciones e iteraciones de
acuerdo con el plan.
Actualización:
z A medida que se adquiere un mayor conocimiento sobre los costes
y capacidades del producto, puede ser necesario actualizar el
análisis del negocio y comunicar el nuevo análisis a los inversores.

Evaluación de las iteraciones
Actividades:
z Revisar lo logrado en una iteración contrastándolo con lo que se
había planificado.
z Planificar en cuál de las iteraciones siguientes se realizará el
trabajo no completado.
z Actualizar la lista de riesgos.
z Completar el plan de la iteración siguiente.
z Al final de la última iteración de esta fase, determinar si el
producto ha superado las pruebas del sistema y si ha alcanzado la
capacidad operativa inicial.
z Autorizar la entrada en la fase de transición.
z Actualizar el plan del proyecto.

Planificación de la fase de Transición
Aspectos conocidos:
z Se sabe que se van a producir versiones beta para los usuarios.
z Sólo se podrá planificar: selección de encargados de probar las
versiones beta, preparar instrucciones de prueba etc...
Aspectos desconocidos:
z Respuesta de los usuarios:
9 Riesgo.
9 Problema.
9 Fallo.
9 Sugerencia.
Personal:
z Si se tiene experiencia se podrá estimar la cantidad aproximada
de personal especializado necesario para abordar los problemas
que los usuarios descubran.

Productos generados
1. Plan de proyecto para la fase de transición.
2. Sistema software ejecutable, versión con capacidad operativa inicial.
Ésta es la construcción final de la fase.
3. Todos los artefactos, incluyendo los modelos del sistema.
4. Descripción de la arquitectura, mínimamente modificada y
actualizada.
5. Versión preliminar del manual de usuario, lo suficientemente
detallado como para guiar a los usuarios de la versión beta.
6. Análisis de negocio, que refleja la situación al final de la fase.
7. La operación del software en la comunidad de usuarios durante la
fase de transición puede desvelar que algún producto no es correcto,
en ese caso se modificará para que lo sea.

ASI 8.1
Definición
ASI 1.3 final de los
principios
ASI 1.1 Inicio Inicio Catálogo de Inicio Inicio generales de
Procesos y normas interfaz de
ASI 2.1 ASI 2.2 ASI 2.3
requisitos de la Fin Fin usuario Inicio Inicio Inicio Inicio
solución, glosario, Modelo de
Especificación de Análisis riguroso
modelo de negocio, Inicio Inicio casos de uso,
casos de uso de los casos de
se completa si
se completa la labor
Fin Fin Fin Fin restantes Fin Fin uso de ASI 2.2
de la fase anterior es necesario

Realización de casos de uso
ASI 4.1 ASI 5.1 ASI 5.2 ASI 5.3
Identificación Identificación de
Responsabilidades agregaciones y Identificación de
de clases de
n io
y atributos de las asociaciones, generalizaciones

análisis
Fi Inic
Fin Fin clases anteriores Fin Fin revisión de la Fin Fin

especificación de
subisistemas para
o
su posible
n i
Fi Inic
optimización
Inicio
ASI 4.2
io
Inic Análisis de
Casos de uso restantes realizaciones de casos
Fin de uso, descripción de
ASI 2.4 io
Inic in interacción de objetos
Fin
Validación de
F Fin
casos de uso
anteriores Inicio
Fin ASI 9.1
ASI 3.1 ASI 3.2 ASI 9.2
Fin Inicio Inicio
Introducción de Revisar Verificación Fin Inicio Análisis de
Fin Inicio
Fi
actualizaciones y consistencia si se de todos los

In
consistencia de
n
ici
mejoras en los introdujeron modelos

Fin Fin todos los modelos
o
subsistemas modificaciones en
la tarea anterior
cio
In
Ini
ici
o
Fin
Fi
n
ASI 8.3 ASI 8.4 ASI 8.5

Definición de Especificación del
Especificación
formatos Inicio Inicio comportamiento Inicio Inicio de formatos
individuales dinámico de las
de impresión,
de pantalla interfaces
Fi
n
Fin
In
cio i
Inicio
Inicio Inicio
Fin Fin
F
Ini in Fi Ini
cio n cio
Ini Fi
cio n In
Fi icio
n
Inicio Inicio
Fin Fin
DSI 1.7 Fin-Inicio DSI 7.3,8.4,9.4,10.3 Fin-Inicio
Operación y seguridad Productos de diseño
DSI 1.3,1.4 Inicio-Inicio, DSI 7.3 DSI 11.2 DSI 12.1
DSI 1.6,3.3,3.4,6.4 Fin-Inicio
Aceptación
Aprobación del
Productos de diseño del análisis Inicio Inicio Requisitos de Fin Inicio
DSI 11.1 diseño del
DSI 7.1 DSI 7.2 realizado implantación
Inicio Inicio Fin Inicio Especificación Fin Fin sistema CSI 7.1 CSI 7.2
anteriormente
de requisitos de Inicio Inicio Especificación
Verificación del Análisis de Primera versión
Inicio Inicio documentación Inicio Inicio de recursos y
diseño consistencia del esquema de
(Calidad), del diseño
Fin Fin de usuarios
Fin Fin formación de entorno de
Fin Fin beta Fin Fin formación
modelo de datos usuarios finales
optimizado In
Fi icio
n DSI 10.2
In Especificación
ic
Fi io Inicio Inicio de los niveles
n DSI 8.2 de prueba
Definición de Fin Fin
componentes y DSI 8.3 DSI 8.4 CSI 1.1
Inicio Inicio
subsistemas de Implantación
Inicio Inicio Especificación en Especificación del
io
Fin
implementación Fin Inicio de la BD o el
I ni c como traducción Fin Fin psedocódigo de modelo físico de
sistema de
componentes Fin Fin datos
directa del diseño Inic ficheros
Fi n i o
io
Inic DSI 1.7 Fin-Inicio
I ni c
n
io
F i
Fin Operación y seguridad
CSI 2.1 CSI 2.2 CSI 6.1
Generación del Generación de
Completar el
código de los código de los
manual de
componentes procedimientos
Fin Fin Fin Fin usuarios beta
de DSI 8.2 de operación y
seguridad
CSI 8.1
Preparación
Inicio Inicio del entorno de
DSI 9.1 Inicio Inicio DSI 9.2 Inicio Inicio DSI 9.3 Inicio Inicio DSI 9.4
migración y
Especificación Diseño de Diseño de Revisión del Fin Fin carga inicial
del entorno de procedimientos componentes plan de
de datos
migración y de migración y de migración migración y
Fin Fin Fin Fin Fin Fin
carga inicial carga inicial y carga inicial carga inicial F in
In i c CSI 8.2 CSI 8.3
io
Generación de Realización y
código de los
Inicio Inicio evaluación de
CSI 2.2 Inicio-Inicio, Fin-Fin
componentes y las pruebas
Código generado
procedimientos de migración
CSI 3.1 CSI 3.2 de la migración y Fin Fin y carga inicial
DSI 10.2 Inicio-Inicio, Fin-Fin Preparación Realización y CSI 2.2 Inicio-Inicio, Fin-Fin
carga inicial de de datos
Pruebas del entorno de Fin Inicio evaluación de Código generado datos
DSI 10.3 pruebas las pruebas CS 4.1 CSI 4.2 CSI 4.3
Fin Inicio unitarias unitarias Inicio Inicio
Preparación
Especificación Fin Inicio Realización Evaluación de
del entorno de
del plan de Fin Inicio de pruebas de pruebas de
pruebas de
pruebas integración Fin Fin integración
integración
Fin
CSI 2.2 Fin-Inicio
Inic
io Código generado
CSI 5.1 CSI 5.2 CSI 5.3
Inicio Inicio
Preparación
del entorno de
pruebas del
sistema
DSI 7.3 Fin-Inicio
Aceptación del diseño
ASI 2.4 Inicio-Inicio, Fin-Fin ASI 9.3 Inicio-Inicio, Fin-Fin ASI 10.3 Fin-Inicio ASI 11.1 Fin-Inicio DSI 10.2 Inicio-Inicio, Fin-Fin
Análisis de consistencia de DSI-CAL 1.2
Catálogo de requisitos Validación de la arquitectura Plan de pruebas ASI aprobado la arquitectura Aceptación de la Pruebas
ASI-CAL 2.1 ASI-CAL 3.1 ASI-CAL 3.2 ASI-CAL 4.1 ASI-CAL 5.1 DSI-CAL 1.1 arquitectura del DSI-CAL 2.1
Inicio Inicio Inicio Inicio sistema, incluida
Actividades y Revisión del Revisión de Revisión del Revisión de Revisión de
Fin Inicio Registro de
tareas del Fin Inicio Fin Inicio consistencia Fin Inicio la interfaz de Fin Inicio pruebas
catálogo de consistencia plan de aprobación
plan de de productos usuario y el unitarias, del
requisitos de productos pruebas del ASI
calidad Fin Fin del diseño modelo de datos sistema y de
optimizado aceptación
DSI 10.3, DSI-CAL 2.1

Inicio-Inicio, Fin-Fin DSI 11.1 Inicio-Inicio, Fin-Fin DSI 11.2 Inicio-Inicio, Fin-Fin DSI 12.1 Fin-Inicio CSI 2.2 Inicio-Inicio, Fin-Fin CSI 3.2 Inicio-Inicio, Fin-Fin CSI 4.3 Inicio-Inicio, Fin-Fin CSI 5.3 Inicio-Inicio, Fin-Fin
Pruebas Documentación de usuario Implantación DSI aprobado Código generado Pruebas unitarias Pruebas de integración Pruebas del sistema
DSI-CAL 2.2 Inicio Inicio DSI-CAL 3.1 Inicio Inicio DSI-CAL 3.2 DSI-CAL 4.1 CSI-CAL 1.1 CSI-CAL 2.1
Inicio Inicio CSI-CAL 2.2
Revisión de
Revisión del Revisión de Registro de Revisión de Fin Inicio Revisión de Revisión de Revisión de
plan de
requisitos de
requisitos de
Fin Inicio aprobación
Fin Inicio normas de pruebas pruebas de pruebas del
documentación
pruebas Fin Fin Fin Fin implantación del DSI construcción unitarias Fin Fin integración Fin Fin sistema
de usuario
CSI 6.1, CSI-CAL 2.3

Inicio-Inicio, Fin-Fin CSI 7.2 Inicio-Inicio, Fin-Fin
Manual de usuario Esquemas de formación GC 1.1 GC 2.1
CSI-CAL 3.1 Inicio Inicio CSI-CAL 4.1 Identificación Identificación
y registro de y registro de
productos productos
manuales de esquemas de
generados en globales
usuario Fin Fin formación
esta fase
GPS 3.1 GPS 13.1 GPS 4.2

Inicio Inicio
Propuesta de
Seguimiento Aceptación GPS 2.1
GPS 1.1 Inicio Inicio Fin Inicio solución a la
de tareas interna GPS 4.1 GPS 4.3
de la Gestión de
tareas a
Fin Inicio asignación de Fin Inicio incidencias, Fin Inicio Registro de la
proyecto Fin equipo impacto
Inic
io
GPS 10.1
Resumen final
de una tarea
finalizada
GPS 7.1
Aprobación
de la solución
GPS 5.1 GPS 6.1
Inicio Inicio GPS 6.2
Inicio Inicio GPS 6.3 Fin Inicio GPS 8.1
Registro de la Estimación
Fin Inicio Alternativas y
petición de Análisis de la Análisis del del esfuerzo
propuesta de Fin Inicio
cambio de petición impacto para el
Fin Fin Fin Fin solución
requisitos cambio
GPS 9.1
GPS 8.1 Inicio-Inicio, Fin-Fin GPS 3.1 Fin-Inicio
Registro de la
Cambio Seguimiento
solución
GPS 8.2 adoptada GPS 11.1 GPS 11.2 GPS 11.3 GPS 12.1
Fin Inicio Inicio Inicio Inicio Inicio Inicio Inicio
Simulación,
Reunión
Planificación Inicio Inicio Actualización extrapolación Informe de
interna de
de cambios de tareas de la situación seguimiento
Fin Fin Fin Fin Fin Fin Fin Fin seguimiento
del proyecto
ASI 10.3 Fin-Inicio

ASI 2.1 Inicio-Inicio ASI 10.3 Inicio-Inicio, Fin-Fin
Fin del ASI DSI 8.4 Inicio-Inicio, Fin-Fin CSI 7.1 Inicio-Inicio, Fin-Fin
Catálogo de requisitos Pruebas
ASI-SEG 4.1 Entorno de construcción Formación usuarios finales
ASI-SEG 2.1 ASI-SEG 3.1
Inicio Inicio Clasificación y DSI-SEG 3.1 Inicio Inicio CSI-SEG 3.1
Estudio de Inclusión de catalogación Requisitos de
funciones y criterios de Plan de
de los seguridad del
mecanismos seguridad en formación de
productos del entorno de
de seguridad Fin Fin las pruebas Fin Fin seguridad
ASI construcción
necesarios
DSI 1.7, ASI-SEG 4.1,2.1 DSI 10.3 Fin-Inicio CSI 5.3 Fin-Inicio
CSI 3.2,4.2,5.2 Inicio-Inicio, Fin-Fin Fin del DSI Fin del CSI
Pruebas Pruebas DSI-SEG 5.1 CSI-SEG 4.1
DSI-SEG 4.1 CSI-SEG 2.1 Clasificación y Clasificación y
Inicio Inicio
catalogación catalogación
Diseño de Evaluación de
de los de los
pruebas de las pruebas
productos del productos del
seguridad Fin Fin de seguridad
DSI CSI
FASE DE TRANSICIÓN

Fase de Transición
Alcance:
z Se acomete la prueba de la versión beta del sistema generada en
la fase de construcción.
Actividades:
z Preparación de las actividades, como la preparación del entorno.
z Aconsejar al cliente sobre actualizaciones del entorno en el que se
ejecutará el software.
z Preparación de manuales y en general del material necesario para
la entrega del producto.
z Ajustar el software para que funcione con los parámetros actuales
del entorno de usuario.
z Corregir los defectos encontrados a lo largo de las pruebas
realizadas a la versión beta.
z Realizar las modificaciones necesarias cuando se detecten
problemas que no habían sido previstos.
Fase de Transición
Actividades para la organización de
desarrollo:
z Encontrar, discutir, evaluar y registrar las ‘lecciones
aprendidas’ a lo largo del desarrollo del sistema actual.
z Registrar aspectos útiles para la versión siguiente.

Fase de Transición
Objetivos:
z Cumplir los requisitos para todos los usuarios, funcionalidad
completa.
9 El sistema operará en el entorno de usuario, donde pueden
ponerse de manifiesto problemas, riesgos y defectos que no
surgieron durante las pruebas del sistema la final de la fase de
construcción.

Fase de Transición
Objetivos:
z Gestionar todos los aspectos relativos a la operación en el entorno
de usuario, incluyendo la corrección de los defectos remitidos por
los usuarios de la versión beta o por los encargados de las
pruebas de aceptación (estas pruebas son responsabilidad del
cliente).
9 El usuario puede descubrir con retraso nuevas necesidades, si son
muy importantes y casan bien con el producto existente pueden
añadirse, una nueva característica debe acarrear cambios lo bastante
pequeños como para introducirlos sin afectar seriamente al plan del
proyecto.
8 Si la característica va a afectar a la planificación su importancia
debe ser vital.
8 En la mayoría de los casos se añade a una lista de características
para el desarrollo de la siguiente versión.

Fase de Transición
Respuestas:
z Tipos:
9 Si el sistema hace lo que demandan sus usuarios y el negocio.
9 Riesgos inesperados.
9 Problemas no resueltos.
9 Fallos.
9 Ambigüedades y lagunas en la documentación del usuario.
9 Áreas en las que los usuarios muestren deficiencias y necesiten
información o formación.
z Consecuencias:
9 Partiendo de una respuesta de este tipo, se modifica el sistema o
algún artefacto relacionado.
9 No se busca reformular el producto sino encontrar pequeñas
deficiencias que pasaron inadvertidas y que pueden ser corregidas en
el marco de la línea de base de la arquitectura existente.

Fase de Transición
Ayuda para el uso del producto:
z El material de usuarios y cursos iniciado en la fase anterior debe
ser reescrito de forma técnica antes de distribuir el producto a los
clientes normales, debido a que éstos tendrán una preparación
menor que los usuarios beta.
z La relación con el cliente puede contemplar la ayuda para crear un
entorno apropiado para el producto, la formación para usar el
producto de forma efectiva, ayudar a los usuarios a llevar en
paralelo la operación del nuevo sistema con el sistema al que
reemplaza o ayudar a la conversión de Bases de Datos a la nueva
configuración.
z Si el producto es para la venta estos servicios se construyen en el
programa de instalación, completando el servicio de asistencia
telefónica.

Fase de Transición
Hito principal:
z Lanzamiento del producto:
9 ¿Es capaz de operar con éxito en entornos de usuarios típicos?

Fase de Transición
Tipos de acuerdos contractuales:
z Producción por parte de un fabricante de software para la venta
en un determinado mercado a muchos clientes:
9 Aunque el tamaño del mercado puede variar, siempre se da una
relación uno a muchos (un vendedor a muchos clientes) que influye
en las tareas de esta fase.
z Producción por parte de un casa software para un único cliente:
9 Único cliente con una única sede.
9 Único cliente con muchas suborganizaciones y sedes.
9 La organización software desarrolla software inicialmente para un
único cliente o sede y luego lo adapta a otras sedes o clientes.
9 La organización software desarrolla software para otro departamento
de la misma empresa bajo acuerdos contables específicos.

Al comienzo de la fase de Transición
Situación inicial:
z La fase de transición comienza con una versión operativa inicial
que ha pasado las pruebas internas del sistema y la evaluación del
hito principal del final de la fase de construcción.
Actividades preliminares:
z En esta fase se preparan artefactos adicionales, tales como
programas de instalación, de conversión o migración de datos.
z Se modifican los desarrollados durante la fase de construcción
para preparar el programa ejecutable para su distribución más allá
de sus propios límites, dependiendo del patrón elegido.

Fase de Transición
Planificación:
z Aspectos conocidos:
9 Referentes a la producción de la versión beta, la preparación de la
documentación para las pruebas o la selección de usuarios.
z Aspectos desconocidos:
9 Resultados de las pruebas beta.
z Versión beta:
9 Se presupone que la versión beta requerirá poca reelaboración pues
ese es el propósito del desarrollo iterativo, menos de un 5% aunque
siempre se debe considerar que será mayor que cero.
9 Este trabajo se ha hecho en conjunción con el cliente por tanto la
versión beta debe estar muy próxima a lo que los clientes esperan.

Fase de Transición
Planificación:
z Aspectos conocidos.
z Aspectos desconocidos.
z Versión beta.
z Resultados:
9 No existe un producto software perfecto, así el objetivo es un
software “lo bastante bueno”.
9 Los productos se distribuyen con algún porcentaje de defectos, con
ciertos requisitos postergados a versiones posteriores o con algunas
necesidades descubiertas por los usuarios de la versión beta para las
que la fase de transición carece de recursos.

Fase de Transición
Planificación:
z Versión beta.
z Resultados.
z Motivos que propician despreciar la posibilidad de
reelaboración:
9 Demasiada presión de la agenda que conduce a cometer errores
debido a las prisas.
9 Ausencia de pruebas del sistema y evaluación adecuadas al final de la
fase de construcción.
9 Error al evaluar el considerable trabajo que aún queda en la fase de
transición.
9 La disposición de considerar la reelaboración como mala, como
admisión de la incompetencia del proyecto.

Fase de transición
Planificación:
z Versión beta.
z Resultados.
z Motivos que propician despreciar la posibilidad de
reelaboración.

Fase de Transición
Asignación de personal:
z Necesidades:
9 Necesidades de personal similares a las de la fase de construcción
pero con un énfasis diferente.
z Características:
9 La respuesta a los resultados de las pruebas beta o de aceptación
puede requerir personal más orientado al servicio que al desarrollo.
9 Una vez encontrado un fallo realizar una traza hasta el origen
requiere un conocimiento profundo del sistema o de la parte en que
se originó.
9 Considerar el beneficio de una mejora requiere no sólo expertos en el
sistema, sino en la naturaleza de la aplicación.

Fase de Transición
Evaluación:
z Alcance:
9 Sólo es necesario evaluar los problemas que surjan
z Criterios:
9 ¿Han cubierto los usuarios beta las funciones claves?
9 ¿Ha superado el producto las pruebas de aceptación realizadas por el
cliente? Los criterios de prueba vienen fijados por contrato entre la
organización de desarrollo y el cliente. Las pruebas de aceptación
hacen funcionar el sistema en modo de producción durante un
periodo de tiempo previamente acordado.
9 ¿Tiene el material de usuario una calidad aceptable?
9 ¿Está listo el material de cursos necesario, incluyendo la guía del
profesor, en su caso?
9 ¿Parecen los usuarios y clientes satisfechos con el producto?

Fase de Transición
Actividades en cada iteración:
z Se realizan cuatro grupos se actividades en paralelo:
9 Planificación.
9 Los cinco flujos de trabajo fundamentales.
9 Evaluación.
9 Análisis más profundo del negocio.

Poca actividad, limitada a corregir problemas encontrados durante las
pruebas en el entorno de usuario.
El trabajo normalmente consiste en poco más que hacer pequeñas
mejoras de diseño destinadas a corregir problemas o defectos o para
efectuar mejoras de última hora.
La atención se centra en la corrección de defectos detectados durante
el uso inicial, asegurarse de que la corrección en sí está bien y hacer
pruebas de regresión para asegurar que estas modificaciones no
introduzcan nuevos defectos.
La atención se centra en la implementación y en las pruebas.

Fase de Transición
Qué se hace en esta fase:
z Preparar la versión beta, o de pruebas de aceptación, a partir de
la versión con capacidad operativa inicial producida durante la
fase de construcción.
z Instalar o preparar la instalación de la versión beta en los lugares
escogidos, junto a las actividades relacionadas con dichos lugares,
tales como la migración de datos desde el sistema anterior.
z Actuar a partir de la información recogida en las instalaciones de
pruebas.
z Adaptar el producto corregido a las circunstancias de los usuarios.
z Completar los artefactos del proyecto.
z Determinar cuándo se acaba el proyecto.

Fase de Transición
z Preparación de la versión beta:
9 La mayor parte de los usuarios beta serán experimentados.
9 Al principio de la fase de transición se reúne la documentación
preparada con anterioridad necesaria para los usuarios beta.
9 Además se les proporcionará instrucciones específicas sobre las
pruebas beta y sobre cómo informar de los hallazgos y observaciones.
9 Una vez seleccionados los usuarios beta se les proporciona la versión
beta y el material de acompañamiento.

Fase de Transición
z Preparación de la versión beta.
z Instalación de la versión beta:
9 Habrá un gran número de lugares en los que se realicen pruebas
beta, y el personal de transición no estará presente, por tanto, deben
darse instrucciones específicas sobre:
8 Cómo instalar el software de pruebas.
8 Cómo operar con él.
8 En qué aspectos y problemas deben centrarse los clientes y los
usuarios beta.
8 Cómo informar de los fallos y problemas encontrados.
9 Si la versión es un actualización o sustitución de software existente se
debe proporcionar información sobre la migración o la conversión de
datos, es posible que haya que operar con los dos sistemas en
paralelo.

Fase de Transición
z Instalación de la versión beta:
9 En las pruebas de aceptación por lo general estarán presentes
miembros del personal del proyecto.
9 Habrá un documento formal de pruebas de aceptación aunque será
complementado mediante comunicaciones informales.
9 Cuando sea posible los problemas se resolverán en el entorno de
usuario, si es necesario se remitirán a los miembros cualificados del
proyecto.

Reacción a los resultados de las pruebas
z Instalación de la versión beta.
z Reacción a los resultados de las pruebas:
9 Una vez recopilados y analizados los resultados de las pruebas se
dividen en dos categorías: fallos de codificación, relativamente
menores sólo precisan ser localizados y corregidos, y problemas más
importantes con mayores ramificaciones que pueden llegar incluso a
un cambio de la arquitectura.
8 Fallos:
• Un fallo es un defecto en un componente, éste puede ser
rastreado hasta una deficiencia en los modelos de diseño,
análisis o incluso de casos de uso. El defecto se corregirá, se
probará y se realizarán pruebas de regresión.
• ¿Parece verosímil que el defecto esté relacionado con otros
aún no descubiertos?

Fase de Transición
z Reacción a los resultados de las pruebas.
8 Fallos:
• ¿Puede ser corregido sin que afecte a la arquitectura o el
diseño?
• ¿Ha sido corregido sin introducir nuevos defectos?
8 Problemas más amplios:
• Consideración más extensa que corregir un fallo.
• Puede requerir una iteración de pruebas adicional, puede
sugerir cambios, mejoras o características que deban
tratarse formalmente.

Fase de Transición
8 Fallos.
• A medida que se realizan cambios se deben llevar a cabo el
control de configuración.
• Los cambios que excedan los recursos, retrasen la
distribución o modifiquen la arquitectura deben postergarse,
si es posible, hasta el siguiente ciclo de desarrollo.

Fase de Transición
8 Fallos.
• Se trabajará en modo de seguimiento para asegurarse de
que la corrección de problemas y defectos respeta la
arquitectura.
• Los problemas no se podrán corregir de forma que dañen la
arquitectura, esto puede requerir algún ajuste en la
arquitectura en cuyo caso se actualizará su descripción.

Fase de Transición
z Adaptación a entornos variados:
9 Relación de mercado:
8 El mercado puede consistir en un conjunto muy diverso de
destinatarios, para el que deberán prepararse diferentes
versiones del programa ejecutable, estas variantes incluyen país,
idioma, moneda y otras unidades de medida.
• Si el producto va a funcionar en nodos diferentes de una red
puede que necesite ser modificado para cada nodo.
8 Se ampliará la documentación preliminar de las pruebas beta
para ajustarse a las necesidades de los usuarios normales ya que
éstos serán menos experimentados.

Fase de Transición
9 Relación de mercado:
8 Se prepararán procedimientos de instalación y un guión para el
servicio de asistencia telefónica.
• Si un sistema precisa que se instalen diferentes partes en
diferentes nodos, cada nodo puede precisar diferentes
procedimientos de instalación.

Fase de Transición
9 Relación de mercado.
9 Relación de cliente individual:
8 Diferencias respecto a la relación anterior:
• Representantes del cliente han participado en las fases
anteriores.
• Han observado las pruebas finales del sistema, de acuerdo a
las premisas del contratista software.

Fase de Transición
• La organización software ha ayudado a instalar el sistema en
la sede inicial del cliente. En el caso de sistemas grandes y
complejos, puede haber realizado el grueso del trabajo de
instalación.

Fase de Transición
• Los representantes del contratista han observado las
pruebas de aceptación y pueden haber realizado
correcciones sobre el terreno cuando esto fue posible. En
caso de problemas más serios, han remitido los detalles a su
propia organización con el fin de conseguir la ayuda de
expertos para realizar los cambios y correcciones.

Fase de Transición
• La pruebas de aceptación concluyen cuando el cliente y el
proveedor determinan que el sistema cumple con los
requisitos previamente acordados. Pueden haberse
detectado necesidades adicionales o cambios en las
necesidades que lleven a una una ampliación del contrato.

Fase de Transición
9 Relación de cliente individual.
9 Migración y conversión de datos:
8 Cuando hay un sistema ya existente que va a ser reemplazado.

Fase de Transición
8 Responsabilidades:
• Sustitución del sistema antiguo por el nuevo, ya sea con la
asunción completa de todas las tareas por parte del nuevo o
con la operación paralela de ambos hasta que el cliente
quede satisfecho con el nuevo sistema.
• Transferencia de datos del antiguo al nuevo, puede implicar
un cambio de formato.
Fase de Transición
8 Responsabilidades:
• Instrucciones para las transferencias y añadir a la
documentación pruebas para verificar la corrección de la
instalación.
• Generar información explicativa adicional para el servicio de
asistencia telefónica, especialmente para ayudar a los
usuarios si la instalación no ha sido correcta.

Fase de Transición
z Finalización de los artefactos:
9 Correcciones necesarias.
9 Al final de esta fase se habrá verificado a través del uso real que
todos los artefactos son consistentes unos con otros.

Fase de Transición
z Finalización de los artefactos.
z ¿Cuándo acaba el proyecto?
9 Para productos de cara al mercado se acaba cuando una amplia masa
de clientes queda satisfecha, entonces se lanza la mercado una
versión comercial.
8 Tanto el entorno como el producto continuarán evolucionando,
pero se responderá a esta evolución en versiones posteriores o,
en caso de una modificación muy grande, en un nuevo ciclo de
desarrollo.
8 Esta fase acaba cuando el proyecto transfiera la responsabilidad
del mantenimiento continuado a una organización de apoyo.
Fase de Transición
9 Para productos contratados por un cliente, se determina que éste
estará satisfecho una vez el sistema pase las pruebas de aceptación.
8 Este punto depende de la interpretación de los requisitos
detallados en el contrato original, firmado al final de la fase de
elaboración, y modificado a través en fases posteriores.
8 El mantenimiento puede acordarse con el proveedor software en
el mismo contrato o en otro, puede llevarlo a cabo el propio
cliente o éste puede contratarlo a un tercero, en cualquier caso
la fase de transición habrá concluido.

Fase de Transición

Finalización del análisis de negocio
z Situación:
9 Hay más información disponible sobre la que juzgar el acierto del
análisis de negocio.
z Control del progreso:
9 Se compara el progreso real en la fase frente a la agenda, esfuerzo y
coste planificado para la fase.
9 Al final de esta fase (final del proyecto en términos presupuestarios)
se revisa el tiempo, personas-hora, coste, porcentajes de defectos y
otras métricas que la empresa pueda utilizar en relación con las cifras
planificadas para el proyecto en su conjunto con objeto de:
8 Ver si el proyecto ha alcanzado los objetivos planeados.
8 Determinar las razones por las que no lo ha hecho, si este es el
caso.
8 Añadir las métricas del proyecto a la Base de Datos de métricas
de la empresa para su uso futuro.

z Situación.
z Control del progreso.
z Revisión del plan de negocio:
9 Este plan prevé si el proyecto tendrá éxito económico.
8 Si el proyecto responde a una producción bajo contrato:
• Definir si el precio contratado ha cubierto los costes del
proyecto, se pueden tener en cuenta cuestiones como abrir
un nuevo área de negocio o si alguno de los componentes o
subsistemas puede llevar a una reducción de costes en
futuros proyectos.
8 Si el proyecto es una producción de cara al mercado:
• El éxito se mide de acuerdo a si el producto alcanzará un
margen de beneficios sobre el capital invertido en el
desarrollo.

z Situación.
z Revisión del plan de negocio.
z Finalización:
9 No se dispone de todos los datos pero si se sabe el capital invertido y
se tiene un mejor conocimiento de las previsiones futuras que al
comienzo del proyecto.
9 Se reunirán todos los datos y se formará un grupo para revisar el
plan.

z Situación.
z Revisión del plan de negocio.
z Finalización.

Fase de Transición
Evaluación:
z Personal:
9 Se reúne un pequeño grupo para evaluar esta fase y analizar el ciclo
de desarrollo en su totalidad.
z Hallazgos:
9 Pueden ser de utilidad para futuros ciclos de desarrollo.
9 Tipos:
8 Evaluación de las iteraciones y de las fases:
• Si se han llevado a cabo las tres fases anteriores de forma
efectiva las pruebas beta sólo detectarán fallos rutinarios
que se corregirán rápidamente
• Si se fracasó al identificar todos los riesgos importantes, al
desarrollar la arquitectura, o al realizar el diseño, la fase de
transición debe ampliarse hasta alcanzar un sistema
mínimamente satisfactorio.

Fase de Transición
Evaluación:
z Personal.
z Hallazgos:
9 Tipos:
8 Evaluación de las iteraciones y de las fases:
• Puede que haya que postergar características originalmente
especificadas en los requisitos para una versión posterior.
• Las deficiencias serán registrados para que el proyecto que
trabaje con la nueva versión se desarrolle mejor.

Fase de Transición
Evaluación:
z Personal.
z Hallazgos:
9 Tipos:
8 Evaluación de las iteraciones y de las fases.
8 Valoración del proyecto:
• Se analiza lo que la organización del proyecto ha hecho bien y lo
que ha hecho mal. El objetivo es proporcionar un registro que
permita mejorar la organización de futuros proyectos y llevar a cabo
el proceso de desarrollo con mayor éxito.
• Se deben registrar aquellos aspectos del sistema útiles para el
equipo de mantenimiento y el equipo de la siguiente versión. Por
ejemplo se registran no sólo las razones para elegir un diseño sino
también las razones para rechazar otros.

Fase de Transición
Evaluación:
z Personal.
z Hallazgos:
9 Tipos:
8 Valoración del proyecto:
• Se deben considerar detalladamente los aspectos del
proceso de desarrollo en sí:
-¿Se necesita más formación general?
-¿Qué áreas requieren formación especializada?
-¿Deberían proseguir las actividades de asesoramiento?
-¿La experiencia de este proyecto con aspectos
especializados de la nueva metodología ha permitido
desarrollar intuiciones que beneficiarán a futuros proyectos?

Fase de Transición
Evaluación:
z Personal.
z Hallazgos:
9 Tipos:
8 Valoración del proyecto.

Planificación de la próxima versión
“Casi todos los sistemas software entran en un nuevo

ciclo de desarrollo de forma casi inmediata. El nuevo ciclo
repite las cuatro fases”

Productos generados
1. El propio software ejecutable, incluyendo el software de instalación.
2. Documentos legales como contratos, licencias, renuncias de derechos
y garantías.
3. La versión completa y corregida de la línea de base de la versión del
producto, incluyendo todos los modelos del sistema.
4. La descripción completa y actualizada de la arquitectura.
5. Manuales y material de formación del usuario final, del operador y del
administrador del sistema.
6. Referencias, incluyendo de la web, para la ayuda del cliente, acerca
de dónde encontrar más información, cómo informar de defectos o
dónde encontrar información sobre defectos y actualizaciones.

CSI 6.1
Adaptar el
manual de
DSI 11.1 Inicio Inicio
usuario para CSI 7.1 CSI 7.2 CSI 9.1
Especificación
Fin Fin usuarios finales Inicio Inicio
de requisitos de Completar el Especificación Aprobación
documentación Inicio Inicio esquema de de recursos y Fin Inicio de la versión
de usuarios formación de Fin Fin entorno de operativa
Fin Fin
beta usuarios finales formación inicial del
sistema

Formación usuarios finales
IAS 2.3 IAS 2.4
Preparación de Fin Inicio Seguimiento de

la formación de la formación de
IAS 1.1 Fin Inicio usuarios finales usuarios finales IAS 8.1 IAS 8.2 IAS 8.3
Definición del Identificación

Inicio Inicio Determinación
plan de
Inicio Inicio de niveles de
Descripción Fin Inicio del acuerdo de
de servicios
implantación Fin Fin servicio Fin Fin servicio
Inicio
Fin
IAS 2.1 IAS 2.2 IAS 3.1

Inicio
Plan de CSI 6.1 Fin-Inicio IAS 5.1 Fin-Inicio

Fin
Fin Inicio Formación del Fin Inicio Preparación

formación del Producto software Pruebas de implantación
equipo de de la
IAS 1.2 equipo de IAS 3.2 IAS 4.1 IAS 5.2 IAS 5.3
Fin Inicio implantación
implantación instalación Inicio Inicio
Especificación Instalación del Fin Inicio Migración y Fin Inicio Realización Evalluación
del equipo de Fin Inicio producto carga inicial de pruebas de Fin Fin de pruebas de
implantación software de datos implantación implantación
Fin
Ini IAS 4.1 Fin-Inicio
c io Producto listo, datos cargados
IAS 5.1 IAS 6.1 IAS 6.2 IAS 6.3
Preparación Realización
Preparación Evaluación de
para las Fin Inicio de las
Fin Fin pruebas de pruebas de Fin Fin
implantación de aceptación
aceptación aceptación
IAS 5.3,6.3,8.3 Fin-Inicio

Sistema desarrollado
IAS 7.1 Inicio Inicio IAS 7.2 IAS 9.1 IAS 9.2 IAS 10.1 IAS 10.2
Convocatoria
Preparación de la Formalización Fin Inicio Fin Inicio Fin Inicio Preparación Fin Inicio Activación del
de Aprobación
infraestructura de Fin Fin del plan de del entorno de sistema en
presentación del sistema
mantenimiento mantenimiento producción producción
del sistema
DSI 11.1 Inicio-Inicio, Fin-Fin
Documentación de usuario
ASI-CAL 2.1 ASI-CAL 4.1 DSI-CAL 1.1 DSI-CAL 2.1 DSI-CAL 2.2 Inicio Inicio DSI-CAL 3.1 Inicio Inicio DSI-CAL 3.2
Inicio Inicio
Actividades y Revisión de Revisión de Revisión de
Revisión del Revisión del Revisión de
tareas del consistencia pruebas requisitos de
plan de plan de requisitos de
plan de de productos unitarias, del documentación
pruebas Fin Fin pruebas Fin Fin Fin Fin implantación
calidad del diseño sistema y de de usuario
aceptación
CSI 6.1 Inicio-Inicio, Fin-Fin CSI 7.2 Inicio-Inicio, Fin-Fin CSI 9.1 Fin-Inicio
Manual de usuario Esquemas de formación Versión operativa
CSI-CAL 1.1 CSI-CAL 2.1
Inicio Inicio CSI-CAL 3.1 Inicio Inicio CSI-CAL 4.1 CSI-CAL 5.1
Registro de la
Revisión de Fin Inicio Revisión de Revisión de Revisión de Revisión de Revisión de Fin Inicio aprobación del
normas de pruebas pruebas de pruebas del manuales de esquemas de
sistema de
construcción unitarias Fin Fin integración Fin Fin sistema Fin Fin usuario Fin Fin formación
información
IAS 1.1,1.2, CSI-CAL 5.1

Inicio-Inicio, Fin-Fin IAS 5.3 Inicio-Inicio, Fin-Fin IAS 6.3 Inicio-Inicio, Fin-Fin IAS 7.2 Inicio-Inicio, Fin-Fin IAS 9.2 Inicio-Inicio, Fin-Fin
Implantación Pruebas de implantación Pruebas de aceptación Plan de mantenimiento Sistema aprobado
IAS-CAL 1.1 IAS-CAL 2.1 IAS-CAL 2.2 IAS-CAL 3.1 IAS-CAL 3.2 IAS-CAL 4.1 IAS-CAL 5.1
Inicio Inicio
Revisión del Revisión de la Registro de la Revisión de la Registro de la Registro de
Fin Inicio Fin Inicio Fin Inicio Fin Inicio Revisión del Fin Inicio
plan de realización de aceptación o realización de aceptación o aprobación de la
plan de
implantación pruebas de rechazo de las pruebas rechazo de implantación del
Fin Fin mantenimiento
del sistema implantación las pruebas de aceptación las pruebas sistema
de del sistema de aceptación
implantación del sistema
GC 1.1 GC 2.1
Identificación Identificación
productos productos
esta fase
GPS 3.1 GPS 13.1 GPS 4.2
Inicio Inicio
Propuesta de
Seguimiento Aceptación
Asignación de Fin Fin Fin Fin Fin Fin
de la Gestión de
tareas a
proyecto Fin Fin
Fin equipo impacto
Inic
io
GPS 10.1
Resumen final
de una tarea
finalizada
GPS 7.1
Aprobación
de la solución
GPS 5.1 GPS 6.1
requisitos cambio
GPS 9.1
Registro de la
Cambio Seguimiento
solución
Simulación,
Reunión
interna de
del proyecto

Formación usuarios finales DSI-SEG 5.1 CSI-SEG 4.1
CSI-SEG 3.1 CSI-SEG 2.1 Clasificación y Clasificación y
GPF 1.1 GPF 1.2 Plan de Evaluación de
de los de los
Identificación Identificación formación de las pruebas
y registro de y registro de seguridad de seguridad
DSI CSI
productos productos
globales globales
IAS 1.1 Inicio-Inicio, Fin-Fin IAS 3.1 Inicio-Inicio, Fin-Fin IAS 5.2 Inicio-Inicio, Fin-Fin IAS 10.2 Fin-Inicio
Plan de implantación Instalación del software Pruebas de implantación IAS completado
IAS-SEG 1.1 IAS-SEG 2.1 IAS-SEG 3.1 IAS-SEG 4.1 IAS-SEG 5.1
Estudio de la Medidas de Evaluación de Clasificación y Medidas de
seguridad seguridad del las pruebas catalogación seguridad en
requerida entorno de de seguridad de los el entorno de
para el IAS operación de la productos del producción
implantación IAS
Mantenimiento

MSI 4.3 Fin-Inicio MSI 3.3 Inicio-Inicio, Fin-Fin MSI 4.2 Inicio-Inicio, Fin-Fin
Corrección Pruebas de regresión Pruebas de regresión
MSI-CAL 1.1 MSI-CAL 2.1 MSI-CAL 3.1
Inicio Inicio
Revisión del
Evaluación de
Revisión del plan de
pruebas de
mantenimiento pruebas de
Fin Fin regresión
regresión
MSI 2.2 Inicio-Inicio, Fin-Fin MSI 4.3 Fin-Inicio MSI 3.3 Inicio-Inicio, Fin-Fin MSI 2.2 Inicio-Inicio, Fin-Fin
Propuesta de solución Fin del MSI Modificación Producto modificado
MSI-SEG 1.1 MSI-SEG 2.1 MSI-SEG 2.2 MSI-SEG 3.1 MSI-GC 1.1 MSI-GC 1.2 MSI-GC 1.3
Inicio Inicio
Estudio de Cambios en Clasificación y Registro de la
Registro de la
seguridad Estudio de la los catalogación de Registro del nueva versión
nueva versión
requerida en petición mecanismos los productos cambio de un
Fin Fin del sistema
el MSI de seguridad del MSI producto
GPS 3.1 GPS 13.1 GPS 4.2

Inicio Inicio
Propuesta de
de la Gestión de
tareas a
proyecto Fin Fin
Fin equipo impacto
Inic
io
GPS 10.1
Resumen final
de una tarea
finalizada
GPS 7.1
Aprobación
de la solución
GPS 5.1 GPS 6.1
requisitos cambio
GPS 9.1
Registro de la
Cambio Seguimiento
solución
Simulación,
Reunión
interna de
del proyecto
GPF 1.1 GPF 1.2

Cierre del Archivo de la
proyecto, documentación
inclusión en el de gestión del
histórico de proyecto
proyectos
Resumen

Aspectos relativos a la metodología
Manejo de la complejidad:
z El desarrollo de software guiado por los casos de uso a través de
los flujos de trabajo; captura de requisitos, análisis, diseño,
implementación y prueba.
z El desarrollo guiado por la arquitectura, el esqueleto de los
elementos estructurales y del comportamiento que permite que el
sistema evolucione sin sobresaltos.
z El desarrollo a partir del uso de bloques de construcción y
componentes, facilitando la reutilización.
z El desarrollo llevado a cabo a través de iteraciones y
construcciones dentro de las iteraciones, lo que resulta un
crecimiento incremental del producto.

Aspectos relativos a la metodología
Manejo de la complejidad:
z El desarrollo con riesgos controlados.
z El desarrollo visualizado y registrado usando UML.
z El desarrollo evaluado en los hitos.

Cuestiones importantes
Obtención correcta de requisitos:
z A través del modelado de casos de uso, análisis, diseño e
implementación
Obtención correcta de la arquitectura:
z Permite la partición del sistema y que las particiones colaboren
entre sí. Solidifica las interfaces entre las particiones permitiendo
la distribución del trabajo entre equipos diferentes.
Uso de componentes:
z Las firmes interfaces de la arquitectura permiten el desarrollo
basado en componentes. Los bloques de construcción reutilizables
reducen costes de desarrollo y tiempo, además, mejoran la
calidad.

Cuestiones importantes
Comunicación con UML:
z Es un lenguaje gráfico con el que se puede pensar, visualizar,
analizar, comunicar y registrar. Facilita la comunicación a través
de fases, versiones y generaciones
Iteraciones:
z Tareas pequeñas, grupos de trabajo pequeños, ligazón con la
gestión de riesgos y controles y realimentaciones frecuentes.
Gestión de riesgos:
z Identificarlos (críticos, significativos, rutinarios), ponerlos en una
lista y mitigarlos antes de que se manifiesten.

Visión Global de las Iteraciones

Iteración Fase Preliminar
PSI 1.1 Fin Inicio PSI 1.2 Fin Inicio PSI 1.3 Fin Inicio PSI-SEG 1.1 Fin Inicio PSI-SEG 1.2
Completa Completa Completa Completa Completa
Iteración Fase de Inicio
PSI 2.3
Primera versión
del plan de
trabajo, esbozo
o
EVS 3.1
ici
In
Catálogo de normas, se
PSI 3.1 PSI 3.2 Inicio Inicio
intenta completar
Información
Fin Inicio Requisitos aunque puede que sea
o
ici
relevante, generales, necesario hacerlo en la
cio
In
Fin Fin
In i completa completa fase posterior
cio PSI 3.2 Inicio-Inicio

PSI 2.1 PSI 2.2
Ini Modelo de negocio
Descripción de Fin Inicio
Catálogo de usuarios, PSI 4.1 PSI 4.2 PSI 4.3 EVS 1.2 EVS 1.3
procesos afectados, Inicio Inicio Inicio Inicio
completa aunque el se Inicio Inicio Necesidades de Fin Inicio Fin Inicio Usuarios y
completa Modelo de Requisitos de Dependencias
añaden usuarios a lo información, requisitos plan de
Procesos, los procesos, con otros
largo del proyecto. funcionales, diagrama Fin Fin trabajo de
completo completa proyectos,
Fin Fin de clases, completa visión global esta fase
del alcance
Fin
del sistema
EVS 3.3
Inicio
Catalogación
de requisitos
EVS 2.1
Inicio
Fin
io
Descripción de
Inic
sistemas actuales
completa si se
Inicio
tiene en cuenta la
Fin
arquitectura, si no
o i
se completa en la
Inic
EVS 3.2 EVS 2.4 EVS 2.3 EVS 2.2

siguiente fase
Inicio Inicio Diagnóstico Inicio Fin Descripción lógica Inicio Fin Participantes Inicio Fin
Identificación de la situación de los sistemas del estudio de
de requisitos actual, actuales, modelo la situación
completa físico, diagrama de actual
clases, completa
PSI 4.3 Fin-Inicio

Modelo de negocio
PSI 5.1 PSI 5.2 PSI 5.3 PSI 6.1
Identificación Descripción Valoración de Sistemas que
de sistemas de sistemas sistemas Fin Inicio se conservan
afectados, afectados, afectados, y mejoras
completa Fin Fin completa Fin Fin completa propuestas,
completa
Fi
Fin n
In
io ici
o
Inic
Inicio Fin
Fin Fin Fin Fin
Inicio Inicio
Fin Fin
ASI 3.2 Fin-Inicio
DSI 3.3 División en subsistemas
Diseño de
DSI 3.1 DSI 3.2 Inicio Inicio interfaz de DSI 3.4
Identificación Interacción de Descripción de
Inicio Inicio Fin Fin usuario, caso
de clases de clases casos de uso en
o
muy concreto
ici
diseño anteriormente términos de

In
adicionales, identificadas, Inicio Inicio subsistemas e

n Fin Fin
ASI 9.3 Fin-Inicio Fi diseño de realización de interfaces, alto
Fin Fin
o
casos de uso casos de uso nivel

ici
Modelo de clases
In
DSI 4.1
n
Identificación Fi
de clases de
diseño, a
partir de las Inicio DSI 4.2 DSI 4.3 DSI 4.4 DSI 4.5 DSI 4.6 DSI 6.1 DSI 6.4
Inicio Inicio Inicio Inicio Inicio Inicio Inicio Inicio Inicio
de análisis Asociaciones Atributos de Pseudocódigo Especificación Distribución
Fi n y las clases
Operaciones Jerarquía del
de algún Fin Inicio Fin Inicio
de las clases, modelo de a alto nivel del de los datos a
Fi n agregaciones identificadas, método modelo físico muy alto nivel,
de las clases
Fin Fin caso concreto
Fin Fin caso concreto Fin Fin clases Fin Fin concreto de datos si modelo de
identificadas mejora la datos no
DSI 3.3,3.4,6.4 Fin-Inicio
comprensión optimizado.
Productos obtenidos del sistema
DSI 7.2 DSI 8.1 DSI 8.2 DSI 10.1 DSI 10.2
Análisis de Especificación Inicio Inicio Especificación Inicio Inicio
consistencia Fin Inicio del entorno
Inicio Inicio Definición de del entorno de Niveles de
de los componentes pruebas para prueba
tecnológico
productos y subsistemas Fin Fin el prototipo Fin Fin
necesaria CSI 2.1 Inicio-Inicio
obtenidos necesarios
para la
Inicio
Fin
para el Código del prototipo
realización del
prototipo. CSI 3.1 CSI 3.2
prototipo
Preparación Realización y
Fin Inicio
Fin
Fin
del entorno de evaluación de

pruebas pruebas
cio
unitarias unitarias
Ini
Inicio
Inicio
CSI 2.1 Fin-Inicio
Inicio
Fin
Código del prototipo
Fin
CSI 1.2 CSI 2.1 CSI 4.1 CSI 4.2 CSI 4.3
Inicio Inicio
Preparación Preparación
DSI 10.3 Realización Evaluación de
del entorno de Generación Fin Inicio del entorno de Fin Inicio de pruebas de pruebas de
de código pruebas de
construcción Plan de integración Fin Fin integración
para el integración
pruebas
prototipo
CSI 2.1 Fin-Inicio
Fi
n Código del prototipo
In CSI 5.1 CSI 5.2 CSI 5.3
ici Inicio Inicio
o Preparación
del entorno de
pruebas del
sistema
Iteración Fase de Elaboración
Inicio Inicio
Fin Fin
Realización de casos de
uso
ASI 4.1 ASI 5.1 ASI 5.2 ASI 5.3
Identificación
n io
Identificación
Fi Inic
Responsabilidades de Identificación de
de clases de
y atributos de las agregaciones generalizaciones
análisis Fin Fin Fin Fin Fin Fin
clases anteriores y
asociaciones

ASI 4.2
io
io
Inic
n c io
Casos de uso
Inic
Análisis de
Fi Ini
arquitectónicamente
realizaciones de casos
significativos Fin de uso, descripción de
ASI 2.4
Ini ci o interacción de objetos
Fin
Fin
Validación de Fin
casos de uso
anteriores Inicio
Fin ASI 9.1
ASI 3.1 Inicio Inicio ASI 3.2 ASI 9.2
Fin Descripción Verificación
Fin Inicio Análisis de
de la
de Integración de Fin Inicio consistencia muy
Fi
In
n
subsistemas e subsistemas arquitectura

exhaustivo de la
ici
Fin Fin del sistema

o
interfaces arquitectura
In
c io
i
Ini
cio
Fin
Fi
n
ASI 8.3 ASI 8.4 ASI 8.5

Definición de Identificación Formatos de
alguna y impresión,
pantalla especificación caso muy
necesaria de los concreto
para la diálogos
comprensión considerados
de un caso de críticos
uso concreto
Fin
Fin
Ini
io c
Inicio
Inicio Inicio
Fin Fin
Fin
In
ic
Fi Ini
n
io
c io
In
In
ici
Fin
o
Fi icio
n
I
Finnicio
Inic
i
Fin o
Inicio Inicio
Fin Fin
Ini
Fin cio
Inic
io
Fin
Inic
Inicio
io
Fin
Fi n I n ic
io
Fin
Inicio
Fin
Fi n
Inic
io
EVS-CAL 2.3
EVS 4.2 Inicio-Inicio, Fin-Fin EVS 5.3 Inicio-Inicio, Fin-Fin Análisis de EVS 6.2 Fin-Inicio EVS 6.3 Fin-Inicio
Alternativas de solución Alternativas de solución consistencia Solución propuesta Solución aprobada
EVS-CAL 1.1 EVS-CAL 1.2 EVS-CAL 1.3 EVS-CAL 2.1 EVS-CAL 2.2 Inicio Inicio de la
EVS-CAL 3.1 EVS-CAL 3.2
Inicio Inicio Inicio Inicio Inicio Inicio arquitectura
Se constituye el Determinación Identificación Necesidad del Alcance del plan Fin Fin Ajuste del
Aprobación
equipo de Fin Inicio de sistemas de plan de de plan a la Fin Inicio del plan de la
calidad y el plan objeto del propiedades aseguramiento aseguramiento solución
Fin Fin Fin Fin Fin Fin Fin Inicio solución
de acción aseguramiento de calidad de la calidad de de la calidad de selecionada
de la calidad cada alternativa cada alternativa
ASI 2.4 Inicio-Inicio ASI 9.3 Inicio-Inicio, Fin-Fin ASI 10.3 Fin-Inicio
EVS-CAL 3.1 Fin-Inicio Catálogo de requisitos Validación de la arquitectura Plan de pruebas
Plan para la solución ASI-CAL 3.1 ASI-CAL 3.2 ASI-CAL 4.1
Inicio Inicio
ASI-CAL 1.1
Revisión del Revisión de Fin Inicio Revisión del
Definición catálogo de consistencia plan de
detallada del Inicio Inicio ASI-CAL 2.1 requisitos de productos pruebas
plan de
Inicio Inicio Fin Fin
Actividades y
aseguramiento
tareas del
de la calidad de
la solución Fin Fin plan
In
ici

o
DSI 7.3 Fin-Inicio DSI 10.2 Inicio-Inicio, Fin-Fin DSI 10.3 Inicio-Inicio, Fin-Fin
Análisis de consistencia de
la arquitectura Aceptación del diseño Pruebas Pruebas
In
DSI-CAL 1.1 DSI-CAL 1.2 DSI-CAL 2.1 DSI-CAL 2.2

ici
Inicio Inicio
o
Fin Inicio Aceptación de Revisión del
consistencia Fin Inicio pruebas
la arquitectura plan de
de productos unitarias, del
del sistema pruebas
del diseño sistema y de Fin Fin
aceptación
CSI 2.2 Inicio-Inicio, Fin-Fin CSI 3.2 Inicio-Inicio, Fin-Fin CSI 4.3 Inicio-Inicio, Fin-Fin CSI 5.3 Inicio-Inicio, Fin-Fin
Código generado Pruebas unitarias Pruebas de integración Pruebas del sistema
CSI-CAL 1.1 CSI-CAL 2.1 CSI-CAL 2.2 CSI-CAL 2.3
Revisión de Fin Inicio Revisión de Revisión de Revisión de
normas de pruebas pruebas de pruebas del
construcción unitarias Fin Fin integración Fin Fin sistema
PSI 9.2, EVS 3.2
EVS 6.2 Fin-Inicio
Arquitectura y
requisitos Solución propuesta
EVS-GC 1.1 EVS-GC 2.1 EVS-GC 2.2 GC 1.1 GC 2.1
Inicio Inicio
Entorno Identificación Identificación
Requisitos de la Inicio Inicio Plan de
tecnológico y registro de y registro de
gestión de la gestión de la
para la productos productos
configuración configuración Fin Fin gestión de la generados en globales
configuración esta fase
EVS 6.2 Fin-Inicio

Solución propuesta
GPI 1.1 GPI 1.2 GPI 2.1 GPI 2.2 GPI 2.3 GPI 2.4 GPI 2.5
Estimación Adaptación de
Fin Inicio Selección de Fin Inicio Fin Inicio Planificación Fin Inicio Aceptación de
del esfuerzo, Cálculo del la Calendario de
la estrategia general del la
identificación esfuerzo metodología hitos y
Fin Fin de desarrollo Fin Fin proyecto planificación
de elementos al proyecto entregas
a desarrollar
GPI 2.4 Inicio-Inicio, Fin-Fin GPS 3.1 GPS 4.2

Planificación del proyecto Propuesta de
Seguimiento
de tareas GPS 4.1 GPS 4.3
de la Gestión de
tareas a
proyecto Fin Fin
Fin equipo impacto
Inic
i o
GPS 10.1
Resumen final
Ini n
de una tarea
cio
Fi
finalizada
Ini
cio n
Fi
GPS 3.1 Inicio-Inicio, Fin-Fin

Seguimiento de tareas
GPS 11.1 GPS 11.2 GPS 11.3 GPS 12.1
Actualización Simulación,
Reunión
de la extrapolación Informe de
interna de
planificación de la situación seguimiento
Fin Fin Fin Fin Fin Fin seguimiento
de tareas del proyecto
Iteración Fase de Construcción
ASI 8.1
Definición
ASI 1.3 final de los
principios
ASI 1.1 Inicio Inicio Catálogo de Inicio Inicio generales de
Procesos y normas interfaz de
ASI 2.1 ASI 2.2 ASI 2.3
requisitos de la Fin Fin usuario Inicio Inicio Inicio Inicio
solución, glosario, Modelo de
Especificación de Análisis riguroso
modelo de negocio, Inicio Inicio casos de uso,
casos de uso de los casos de
se completa si
se completa la labor
Fin Fin Fin Fin restantes Fin Fin uso de ASI 2.2
de la fase anterior es necesario

Realización de casos de uso
ASI 4.1 ASI 5.1 ASI 5.2 ASI 5.3
Identificación Identificación de
Responsabilidades agregaciones y Identificación de
de clases de
n io
y atributos de las asociaciones, generalizaciones

análisis
Fi Inic
Fin Fin clases anteriores Fin Fin revisión de la Fin Fin

especificación de
subisistemas para
o
su posible
n i
Fi Inic
optimización
Inicio
ASI 4.2
io
Inic Análisis de
Casos de uso restantes realizaciones de casos
Fin de uso, descripción de
ASI 2.4 io
Inic in interacción de objetos
Fin
Validación de
F Fin
casos de uso
anteriores Inicio
Fin ASI 9.1
ASI 3.1 ASI 3.2 ASI 9.2
Fin Inicio Inicio
Introducción de Revisar Verificación Fin Inicio Análisis de
Fin Inicio
Fi
actualizaciones y consistencia si se de todos los

In
consistencia de
n
ici
mejoras en los introdujeron modelos

Fin Fin todos los modelos
o
subsistemas modificaciones en
la tarea anterior
cio
In
Ini
ici
o
Fin
Fi
n
ASI 8.3 ASI 8.4 ASI 8.5

Definición de Especificación del
Especificación
formatos Inicio Inicio comportamiento Inicio Inicio de formatos
individuales dinámico de las
de impresión,
de pantalla interfaces
Fi
n
Fin
In
cio i
Inicio
Inicio Inicio
Fin Fin
F
Ini in Fi Ini
cio n cio
Ini Fi
cio n In
Fi icio
n
Inicio Inicio
Fin Fin
DSI 1.7 Fin-Inicio DSI 7.3,8.4,9.4,10.3 Fin-Inicio
Operación y seguridad Productos de diseño
DSI 1.3,1.4 Inicio-Inicio, DSI 7.3 DSI 11.2 DSI 12.1
DSI 1.6,3.3,3.4,6.4 Fin-Inicio
Aceptación
Aprobación del
Productos de diseño del análisis Inicio Inicio Requisitos de Fin Inicio
DSI 11.1 diseño del
DSI 7.1 DSI 7.2 realizado implantación
Inicio Inicio Fin Inicio Especificación Fin Fin sistema CSI 7.1 CSI 7.2
anteriormente
de requisitos de Inicio Inicio Especificación
Verificación del Análisis de Primera versión
Inicio Inicio documentación Inicio Inicio de recursos y
diseño consistencia del esquema de
(Calidad), del diseño
Fin Fin de usuarios
Fin Fin formación de entorno de
Fin Fin beta Fin Fin formación
modelo de datos usuarios finales
optimizado In
Fi icio
n DSI 10.2
In Especificación
ic
Fi io Inicio Inicio de los niveles
n DSI 8.2 de prueba
Definición de Fin Fin
componentes y DSI 8.3 DSI 8.4 CSI 1.1
Inicio Inicio
subsistemas de Implantación
Inicio Inicio Especificación en Especificación del
io
Fin
implementación Fin Inicio de la BD o el
I ni c como traducción Fin Fin psedocódigo de modelo físico de
sistema de
componentes Fin Fin datos
directa del diseño Inic ficheros
Fi n i o
io
Inic DSI 1.7 Fin-Inicio
I ni c
n
io
F i
Fin Operación y seguridad
CSI 2.1 CSI 2.2 CSI 6.1
Generación del Generación de
Completar el
código de los código de los
manual de
componentes procedimientos
Fin Fin Fin Fin usuarios beta
de DSI 8.2 de operación y
seguridad
CSI 8.1
Preparación
Inicio Inicio del entorno de
DSI 9.1 Inicio Inicio DSI 9.2 Inicio Inicio DSI 9.3 Inicio Inicio DSI 9.4
migración y
Especificación Diseño de Diseño de Revisión del Fin Fin carga inicial
del entorno de procedimientos componentes plan de
de datos
migración y de migración y de migración migración y
Fin Fin Fin Fin Fin Fin
carga inicial carga inicial y carga inicial carga inicial F in
In i c CSI 8.2 CSI 8.3
io
Generación de Realización y
código de los
Inicio Inicio evaluación de
componentes y las pruebas
Código generado
procedimientos de migración
CSI 3.1 CSI 3.2 de la migración y Fin Fin y carga inicial
DSI 10.2 Inicio-Inicio, Fin-Fin Preparación Realización y CSI 2.2 Inicio-Inicio, Fin-Fin
carga inicial de de datos
Pruebas del entorno de Fin Inicio evaluación de Código generado datos
DSI 10.3 pruebas las pruebas CS 4.1 CSI 4.2 CSI 4.3
Fin Inicio unitarias unitarias Inicio Inicio
Preparación
Especificación Fin Inicio Realización Evaluación de
del entorno de
del plan de Fin Inicio de pruebas de pruebas de
pruebas de
pruebas integración Fin Fin integración
integración
Fin
CSI 2.2 Fin-Inicio
Inic
io Código generado
CSI 5.1 CSI 5.2 CSI 5.3
Inicio Inicio
Preparación
del entorno de
pruebas del
sistema
DSI 7.3 Fin-Inicio
Aceptación del diseño
ASI 2.4 Inicio-Inicio, Fin-Fin ASI 9.3 Inicio-Inicio, Fin-Fin ASI 10.3 Fin-Inicio ASI 11.1 Fin-Inicio DSI 10.2 Inicio-Inicio, Fin-Fin
Análisis de consistencia de DSI-CAL 1.2
Catálogo de requisitos Validación de la arquitectura Plan de pruebas ASI aprobado la arquitectura Aceptación de la Pruebas
ASI-CAL 2.1 ASI-CAL 3.1 ASI-CAL 3.2 ASI-CAL 4.1 ASI-CAL 5.1 DSI-CAL 1.1 arquitectura del DSI-CAL 2.1
Inicio Inicio Inicio Inicio sistema, incluida
Actividades y Revisión del Revisión de Revisión del Revisión de Revisión de
Fin Inicio Registro de
tareas del Fin Inicio Fin Inicio consistencia Fin Inicio la interfaz de Fin Inicio pruebas
catálogo de consistencia plan de aprobación
plan de de productos usuario y el unitarias, del
requisitos de productos pruebas del ASI
calidad Fin Fin del diseño modelo de datos sistema y de
optimizado aceptación
DSI 10.3, DSI-CAL 2.1

Inicio-Inicio, Fin-Fin DSI 11.1 Inicio-Inicio, Fin-Fin DSI 11.2 Inicio-Inicio, Fin-Fin DSI 12.1 Fin-Inicio CSI 2.2 Inicio-Inicio, Fin-Fin CSI 3.2 Inicio-Inicio, Fin-Fin CSI 4.3 Inicio-Inicio, Fin-Fin CSI 5.3 Inicio-Inicio, Fin-Fin
Pruebas Documentación de usuario Implantación DSI aprobado Código generado Pruebas unitarias Pruebas de integración Pruebas del sistema
DSI-CAL 2.2 Inicio Inicio DSI-CAL 3.1 Inicio Inicio DSI-CAL 3.2 DSI-CAL 4.1 CSI-CAL 1.1 CSI-CAL 2.1
Revisión de
Revisión del Revisión de Registro de Revisión de Fin Inicio Revisión de Revisión de Revisión de
plan de
requisitos de
requisitos de
Fin Inicio aprobación
Fin Inicio normas de pruebas pruebas de pruebas del
documentación
pruebas Fin Fin Fin Fin implantación del DSI construcción unitarias Fin Fin integración Fin Fin sistema
de usuario
CSI 6.1, CSI-CAL 2.3

Inicio-Inicio, Fin-Fin CSI 7.2 Inicio-Inicio, Fin-Fin
Manual de usuario Esquemas de formación GC 1.1 GC 2.1
CSI-CAL 3.1 Inicio Inicio CSI-CAL 4.1 Identificación Identificación
productos productos
manuales de esquemas de
usuario Fin Fin formación
esta fase
GPS 3.1 GPS 13.1 GPS 4.2

Inicio Inicio
Propuesta de
Seguimiento Aceptación GPS 2.1
GPS 1.1 Inicio Inicio Fin Inicio solución a la
de la Gestión de
tareas a
Fin Inicio asignación de Fin Inicio incidencias, Fin Inicio Registro de la
proyecto Fin equipo impacto
Inic
io
GPS 10.1
Resumen final
de una tarea
finalizada
GPS 7.1
Aprobación
de la solución
GPS 5.1 GPS 6.1
requisitos cambio
GPS 9.1
Registro de la
Cambio Seguimiento
solución
Simulación,
Reunión
interna de
del proyecto
ASI 10.3 Fin-Inicio

ASI 2.1 Inicio-Inicio ASI 10.3 Inicio-Inicio, Fin-Fin
Fin del ASI DSI 8.4 Inicio-Inicio, Fin-Fin CSI 7.1 Inicio-Inicio, Fin-Fin
Catálogo de requisitos Pruebas
ASI-SEG 4.1 Entorno de construcción Formación usuarios finales
ASI-SEG 2.1 ASI-SEG 3.1
Inicio Inicio Clasificación y DSI-SEG 3.1 Inicio Inicio CSI-SEG 3.1
Estudio de Inclusión de catalogación Requisitos de
funciones y criterios de Plan de
de los seguridad del
mecanismos seguridad en formación de
productos del entorno de
de seguridad Fin Fin las pruebas Fin Fin seguridad
ASI construcción
necesarios
DSI 1.7, ASI-SEG 4.1,2.1 DSI 10.3 Fin-Inicio CSI 5.3 Fin-Inicio
CSI 3.2,4.2,5.2 Inicio-Inicio, Fin-Fin Fin del DSI Fin del CSI
Pruebas Pruebas DSI-SEG 5.1 CSI-SEG 4.1
DSI-SEG 4.1 CSI-SEG 2.1 Clasificación y Clasificación y
Inicio Inicio
Diseño de Evaluación de
de los de los
seguridad Fin Fin de seguridad
DSI CSI
Iteración Fase de Transición
CSI 6.1
Adaptar el
manual de
DSI 11.1 Inicio Inicio
usuario para CSI 7.1 CSI 7.2 CSI 9.1
Especificación
Fin Fin usuarios finales Inicio Inicio
de requisitos de Completar el Especificación Aprobación
documentación Inicio Inicio esquema de de recursos y Fin Inicio de la versión
de usuarios formación de Fin Fin entorno de operativa
Fin Fin
beta usuarios finales formación inicial del
sistema

Formación usuarios finales
IAS 2.3 IAS 2.4
Preparación de Fin Inicio Seguimiento de

la formación de la formación de
IAS 1.1 Fin Inicio usuarios finales usuarios finales IAS 8.1 IAS 8.2 IAS 8.3
Definición del Identificación

Inicio Inicio Determinación
plan de
Inicio Inicio de niveles de
Descripción Fin Inicio del acuerdo de
de servicios
implantación Fin Fin servicio Fin Fin servicio
Inicio
Fin
IAS 2.1 IAS 2.2 IAS 3.1

Inicio
Plan de CSI 6.1 Fin-Inicio IAS 5.1 Fin-Inicio

Fin
Fin Inicio Formación del Fin Inicio Preparación

formación del Producto software Pruebas de implantación
equipo de de la
IAS 1.2 equipo de IAS 3.2 IAS 4.1 IAS 5.2 IAS 5.3
Fin Inicio implantación
implantación instalación Inicio Inicio
Especificación Instalación del Fin Inicio Migración y Fin Inicio Realización Evalluación
del equipo de Fin Inicio producto carga inicial de pruebas de Fin Fin de pruebas de
implantación software de datos implantación implantación
Fin
Ini IAS 4.1 Fin-Inicio
c io Producto listo, datos cargados
IAS 5.1 IAS 6.1 IAS 6.2 IAS 6.3
Preparación Realización
Preparación Evaluación de
para las Fin Inicio de las
Fin Fin pruebas de pruebas de Fin Fin
implantación de aceptación
aceptación aceptación
IAS 5.3,6.3,8.3 Fin-Inicio

Sistema desarrollado
IAS 7.1 Inicio Inicio IAS 7.2 IAS 9.1 IAS 9.2 IAS 10.1 IAS 10.2
Convocatoria
Preparación de la Formalización Fin Inicio Fin Inicio Fin Inicio Preparación Fin Inicio Activación del
de Aprobación
infraestructura de Fin Fin del plan de del entorno de sistema en
presentación del sistema
mantenimiento mantenimiento producción producción
del sistema
DSI 11.1 Inicio-Inicio, Fin-Fin
Documentación de usuario
ASI-CAL 2.1 ASI-CAL 4.1 DSI-CAL 1.1 DSI-CAL 2.1 DSI-CAL 2.2 Inicio Inicio DSI-CAL 3.1 Inicio Inicio DSI-CAL 3.2
Inicio Inicio
Actividades y Revisión de Revisión de Revisión de
Revisión del Revisión del Revisión de
tareas del consistencia pruebas requisitos de
plan de plan de requisitos de
plan de de productos unitarias, del documentación
pruebas Fin Fin pruebas Fin Fin Fin Fin implantación
calidad del diseño sistema y de de usuario
aceptación
CSI 6.1 Inicio-Inicio, Fin-Fin CSI 7.2 Inicio-Inicio, Fin-Fin CSI 9.1 Fin-Inicio
Manual de usuario Esquemas de formación Versión operativa
CSI-CAL 1.1 CSI-CAL 2.1
Inicio Inicio CSI-CAL 3.1 Inicio Inicio CSI-CAL 4.1 CSI-CAL 5.1
Registro de la
Revisión de Fin Inicio Revisión de Revisión de Revisión de Revisión de Revisión de Fin Inicio aprobación del
normas de pruebas pruebas de pruebas del manuales de esquemas de
sistema de
construcción unitarias Fin Fin integración Fin Fin sistema Fin Fin usuario Fin Fin formación
información
IAS 1.1,1.2, CSI-CAL 5.1

Inicio-Inicio, Fin-Fin IAS 5.3 Inicio-Inicio, Fin-Fin IAS 6.3 Inicio-Inicio, Fin-Fin IAS 7.2 Inicio-Inicio, Fin-Fin IAS 9.2 Inicio-Inicio, Fin-Fin
Implantación Pruebas de implantación Pruebas de aceptación Plan de mantenimiento Sistema aprobado
IAS-CAL 1.1 IAS-CAL 2.1 IAS-CAL 2.2 IAS-CAL 3.1 IAS-CAL 3.2 IAS-CAL 4.1 IAS-CAL 5.1
Inicio Inicio
Revisión del Revisión de la Registro de la Revisión de la Registro de la Registro de
Fin Inicio Fin Inicio Fin Inicio Fin Inicio Revisión del Fin Inicio
plan de realización de aceptación o realización de aceptación o aprobación de la
plan de
implantación pruebas de rechazo de las pruebas rechazo de implantación del
Fin Fin mantenimiento
del sistema implantación las pruebas de aceptación las pruebas sistema
de del sistema de aceptación
implantación del sistema
GC 1.1 GC 2.1
Identificación Identificación
productos productos
esta fase
GPS 3.1 GPS 13.1 GPS 4.2
Inicio Inicio
Propuesta de
de la Gestión de
tareas a
proyecto Fin Fin
Fin equipo impacto
Inic
io
GPS 10.1
Resumen final
de una tarea
finalizada
GPS 7.1
Aprobación
de la solución
GPS 5.1 GPS 6.1
requisitos cambio
GPS 9.1
Registro de la
Cambio Seguimiento
solución
Simulación,
Reunión
interna de
del proyecto

Formación usuarios finales DSI-SEG 5.1 CSI-SEG 4.1
CSI-SEG 3.1 CSI-SEG 2.1 Clasificación y Clasificación y
GPF 1.1 GPF 1.2 Plan de Evaluación de
de los de los
Identificación Identificación formación de las pruebas
y registro de y registro de seguridad de seguridad
DSI CSI
productos productos
globales globales
IAS 1.1 Inicio-Inicio, Fin-Fin IAS 3.1 Inicio-Inicio, Fin-Fin IAS 5.2 Inicio-Inicio, Fin-Fin IAS 10.2 Fin-Inicio
Plan de implantación Instalación del software Pruebas de implantación IAS completado
IAS-SEG 1.1 IAS-SEG 2.1 IAS-SEG 3.1 IAS-SEG 4.1 IAS-SEG 5.1
Estudio de la Medidas de Evaluación de Clasificación y Medidas de
seguridad seguridad del las pruebas catalogación seguridad en
requerida entorno de de seguridad de los el entorno de
para el IAS operación de la productos del producción
implantación IAS
Iteración Fase de Mantenimiento
MSI 4.3 Fin-Inicio MSI 3.3 Inicio-Inicio, Fin-Fin MSI 4.2 Inicio-Inicio, Fin-Fin
Corrección Pruebas de regresión Pruebas de regresión
MSI-CAL 1.1 MSI-CAL 2.1 MSI-CAL 3.1
Inicio Inicio
Revisión del
Evaluación de
Revisión del plan de
pruebas de
mantenimiento pruebas de
Fin Fin regresión
regresión
MSI 2.2 Inicio-Inicio, Fin-Fin MSI 4.3 Fin-Inicio MSI 3.3 Inicio-Inicio, Fin-Fin MSI 2.2 Inicio-Inicio, Fin-Fin
Propuesta de solución Fin del MSI Modificación Producto modificado
MSI-SEG 1.1 MSI-SEG 2.1 MSI-SEG 2.2 MSI-SEG 3.1 MSI-GC 1.1 MSI-GC 1.2 MSI-GC 1.3
Inicio Inicio
Estudio de Cambios en Clasificación y Registro de la
Registro de la
seguridad Estudio de la los catalogación de Registro del nueva versión
nueva versión
requerida en petición mecanismos los productos cambio de un
Fin Fin del sistema
el MSI de seguridad del MSI producto
GPS 3.1 GPS 13.1 GPS 4.2

Inicio Inicio
Propuesta de
de la Gestión de
tareas a
proyecto Fin Fin
Fin equipo impacto
Inic
io
GPS 10.1
Resumen final
de una tarea
finalizada
GPS 7.1
Aprobación
de la solución
GPS 5.1 GPS 6.1
requisitos cambio
GPS 9.1
Registro de la
Cambio Seguimiento
solución
Simulación,
Reunión
interna de
del proyecto
GPF 1.1 GPF 1.2

Cierre del Archivo de la
proyecto, documentación
inclusión en el de gestión del
histórico de proyecto
proyectos
Implantación en una Nueva Organización

Conversión a la nueva metodología
Debe estar apoyada por la dirección y originada por una
necesidad como responder a la competencia o aumentar unos
beneficios considerados insuficientes.
Pasos:
z Directriz de ingeniería.
z Implementación de la transición.

Directriz de Ingeniería
Punto de partida:
z El ejecutivo inicial explica porqué la empresa está cambiando a un
proceso software mejorado.
La directriz cubre:
z La situación actual del negocio y el hecho de que está
cambiando.
z Lo que esperan los clientes en la actualidad.
z La competencia a la que se enfrenta la empresa.
z Los retos que afronta la empresa.
z Los riesgos de no realizar cambios.
z Lo que la empresa debe hacer sobre el proceso software en
particular.

Aspectos importantes:
z Garantía de apoyo:
9 Los jefes de proyecto deben confiar en poder obtener apoyo
financiero continuado que cubra, entre otras cosas, la formación
inicial, el asesoramiento, y la formación continuada a medida que
cambian las necesidades.
9 Al comenzar un nuevo proyecto con un nuevo proceso se depende de
la plena integración de cuatro aspectos:
8 Proceso.
8 Herramientas.
8 Formación.
8 Asesoría.

Aspectos importantes:
z Garantía de apoyo.
z Continuidad en los proyectos existentes:
9 Los proyectos actuales y la mayoría de los que aparezcan en un
futuro inmediato tendrán que continuar con el proceso actual, la
implantación del nuevo proceso debe ser paulatina.
z Confianza en el propio futuro:
9 Algunas personas implicadas en la transición habrán tenido alguna
dificultad para mantenerse al día sobre los cambios acaecidos en el
sector. La confianza en su propio futuro ayudará a la transición.

Implementación de la transición
Participantes:
z El líder:
9 El ejecutivo del software necesitará un ingeniero técnicamente
cualificado que lidere el cambio día a día, es decir, que supervise la
transición.
9 El líder debe comprender la nueva metodología para lo que debe
realizar alguna formación y conseguir asesoría personalizada.
9 Tendrá la confianza tanto de los ejecutivos que le subvencionan como
de los participantes en el proyecto.
9 Debe saber trabajar tanto con gestores como con personal técnico.
9 Adaptará la nueva metodología a las necesidades del primer
proyecto, es decir, comenzará desde cero.

Participantes:
z El líder.
z El jefe del primer proyecto:
9 El ejecutivo del software también necesitará un jefe de proyecto que
crea en la necesidad del nuevo proceso y se sienta capacitado para
llevarlo a cabo.
z El asesor:
9 Puede ser interno o externo.
9 Habrá participado previamente en proyectos que siguiesen la nueva
metodología.
9 Debe tener la habilidad de anticipar problemas en el proyecto,
basándose en la experiencia, y debe ser capaz de colaborar con un
variado grupo de participantes; líder, jefe de proyecto, personal del
proyecto y el ejecutivo del software.

Participantes:
z El líder.
z El jefe del primer proyecto.
z El asesor.

Condiciones:
z Se empieza por un proyecto real y crítico.
z Se debe intentar no introducir demasiadas novedades al mismo
tiempo aparte del proceso y sus herramientas, tales como nuevo
sistema operativo, nueva tecnología de bases de datos, nuevo
lenguaje de programación o nueva plataforma distribuida.

Consideraciones adicionales:
z Un enfoque más gradual, puede caer en el error contrario del
relatado anteriormente. Debido a que el progreso es casi invisible,
el apoyo desaparece gradualmente y la transición fracasa.
z Reestructurar el proceso paso a paso lleva mucho tiempo y a
menudo falla.
z En cualquier caso, es mejor tener la transición bajo control
efectivo de los gestores al llevarla a cabo. Los errores resultantes
de un falta de control son difíciles de arreglar.

Especificación de la metodología
Es un marco de trabajo que debe ser adaptado a una serie de
variables:
z Tamaño del sistema en curso.
z Dominio con el que ha de trabajar el sistema.
z Complejidad del sistema.
z Las cualidades de la organización del proyecto y sus
miembros.

Adaptación del proceso
Aspectos constantes:
z La cuatro fases.
z Los cinco flujos de trabajo fundamentales.
Aspectos variables:
z La longitud relativa de las fases.
z El número de iteraciones para cada fase bajo diferentes
circunstancias.
z Cuándo considerar suficientemente definidas:
9 La arquitectura candidata.
9 La mitigación de riesgos.
9 La línea de base de la arquitectura.
9 El análisis del negocio.

Adaptación del proceso
Factores que influyen en los aspectos variables:
z El tamaño del sistema.
z La naturaleza de la aplicación.
z La experiencia de la organización del proyecto en el dominio.
z La complejidad del sistema.
z La experiencia del equipo del proyecto.
z El grado de capacidad de los gestores.
z El grado de colaboración de los implicados en el proyecto.


Metodologia

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Metodologia

Uploaded by

Copyright:

Available Formats

Metodología para el

Dr. José Ignacio Peláez Sánchez

“Conjunto de actividades necesarias para

José Ignacio Peláez Sánchez

José Ignacio Peláez Sánchez

José Ignacio Peláez Sánchez

José Ignacio Peláez Sánchez

José Ignacio Peláez Sánchez

 También definiremos los tres aspectos fundamentales del

José Ignacio Peláez Sánchez

Para ello, se deben transformar los requisitos del lenguaje

José Ignacio Peláez Sánchez

José Ignacio Peláez Sánchez

José Ignacio Peláez Sánchez

José Ignacio Peláez Sánchez

José Ignacio Peláez Sánchez

Realización de caso Análisis

Realización de caso Diseño

José Ignacio Peláez Sánchez

 La arquitectura proporciona una ‘base del sistema’ para el

José Ignacio Peláez Sánchez

José Ignacio Peláez Sánchez

José Ignacio Peláez Sánchez

José Ignacio Peláez Sánchez

José Ignacio Peláez Sánchez

José Ignacio Peláez Sánchez

José Ignacio Peláez Sánchez

 Existe una relación ‘cíclica’ entre la arquitectura y los

José Ignacio Peláez Sánchez

José Ignacio Peláez Sánchez

José Ignacio Peláez Sánchez

José Ignacio Peláez Sánchez

José Ignacio Peláez Sánchez

José Ignacio Peláez Sánchez

José Ignacio Peláez Sánchez

José Ignacio Peláez Sánchez

José Ignacio Peláez Sánchez

José Ignacio Peláez Sánchez

José Ignacio Peláez Sánchez

José Ignacio Peláez Sánchez

José Ignacio Peláez Sánchez

José Ignacio Peláez Sánchez

José Ignacio Peláez Sánchez

José Ignacio Peláez Sánchez

José Ignacio Peláez Sánchez

José Ignacio Peláez Sánchez

José Ignacio Peláez Sánchez

José Ignacio Peláez Sánchez

José Ignacio Peláez Sánchez

José Ignacio Peláez Sánchez

José Ignacio Peláez Sánchez

José Ignacio Peláez Sánchez

José Ignacio Peláez Sánchez

José Ignacio Peláez Sánchez

José Ignacio Peláez Sánchez

José Ignacio Peláez Sánchez

 Sin embargo, hay diferencias que hacen mucho más recomendable

José Ignacio Peláez Sánchez

José Ignacio Peláez Sánchez

José Ignacio Peláez Sánchez

José Ignacio Peláez Sánchez

José Ignacio Peláez Sánchez

José Ignacio Peláez Sánchez

También definiremos los tres aspectos fundamentales del

Para ello, se deben transformar los requisitos del lenguaje

La arquitectura proporciona una ‘base del sistema’ para el

Existe una relación ‘cíclica’ entre la arquitectura y los

Sin embargo, hay diferencias que hacen mucho más recomendable

Planteamiento general del problema.

Trabajo a realizar en cada iteración:

Trabajo a realizar en cada iteración: