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

José Ignacio Peláez SánchezUniversidad de MálagaDepartamento de Lenguajes y Ciencias de la Computación

2 de 297

Metodología

“Conjunto de actividades necesarias para transformar los requisitos de los usuarios

en un sistema software“


3 de 297

DUMDesarrollo Unificado con Métrica


4 de 297

DUM

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


5 de 297

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.


6 de 297

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.


7 de 297

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.


8 de 297

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


9 de 297


Los casos de uso intervienen en los cinco flujos de trabajo fundamentales:

Se identifican (captura de requisitos).Se especifican (análisis).Se diseñan.Se implementan.Son fuente a partir de la cual se construyen los casos de prueba.


10 de 297


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:

Especificación.Diseño.Prueba.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.


11 de 297


Trazas.

Definición:Relaciones que establece un caso de uso entre los elementos que genera en los distintos flujos de trabajo fundamentales.

Características:Permiten relacionar directamente un elemento de diseño o incluso de implementación con el caso de uso que lo originó.Aportan flexibilidad ante cambios en los requisitos.


12 de 297


Trazas:Definición.Características.Especificación:

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.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.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.Se pueden definir casos de prueba a partir de los casos de uso.


13 de 297

Dirigido por Casos de UsoTrazas: Casos de Uso

Realización de caso de uso

Realización de caso de uso

Implementación

Análisis

Diseño

Pruebas


14 de 297

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.


15 de 297


Incluye vistas de todos los modelos excepto el de prueba:

Casos de uso. Formado por todos los casos de uso y su relación con los usuarios.Análisis. El objetivo es refinar los casos de uso, mostrar la funcionalidad del sistema.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. Despliegue. Basado en nodos físicos, se ocupa de la correspondencia nodos-componentes.Implementación. Basado en componentes, se ocupa de la correspondencia clases-componentes.


16 de 297


Formarán parte de la arquitectura los elementos más importantes, los que guían el trabajo:

Subsistemas.Dependencias.InterfacesColaboracionesNodos.Clases activas.

Estos elementos describen los cimientos del sistema que son necesarios para la comprensión, desarrollo y producción del sistema.


17 de 297


Necesidades que cubre la arquitectura:Comprender el sistema.Organizar el desarrollo:

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.

Fomentar la reutilización: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.


18 de 297


Necesidades que cubre la arquitectura:Comprender el sistema.Organizar el desarrollo.Fomentar la reutilización.Hacer evolucionar el sistema:

Proporciona la seguridad de que el sistema evolucionará ante modificaciones de diseño o implementación o ante la introducción de nuevas funcionalidades.


19 de 297


Creación de la arquitectura:Borrador inicial de la parte que no es específica de los casos de uso, por ejemplo la plataforma.Selección, especificación y realización de los casos de uso que representen funciones clave del sistema.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.El uso de iteraciones posibilitará la ejecución de esto último.


20 de 297


Necesidades que cubre la arquitectura:Comprender el sistema.Organizar el desarrollo.Fomentar la reutilización.Hacer evolucionar el sistema.


21 de 297

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.


22 de 297

Relación Casos de Uso-Arquitectura

Esta interdependencia introduce un problema: ¿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: Ninguna de las dos opciones. Se realizará un trabajo simultáneo. ¿cómo?

MEDIANTE ITERACIONES


23 de 297

Iterativo e Incremental

El tercer aspecto a destacar de la metodología es el desarrollo incremental:

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í. Dichos pasos se denominan iteraciones.


24 de 297


Iteraciones:Definición:

Las iteraciones se entienden como ejecuciones reducidas del proyecto que añaden nueva funcionalidad al sistema. Para ejecutarlas se toma un conjunto de casos de uso (captura derequisitos) 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).

Actividades:Las iteraciones se planifican, admiten división en unidades menores denominadas construcciones y finalmente, se evalúan.


25 de 297


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

Dan un carácter de simultaneidad al proyecto que permite respetar la interdependencia entre arquitectura y casos de uso.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.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.


26 de 297


Iteraciones:Definición.

Actividades.Características:

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


27 de 297



Actividades.Características.Planificación:

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


28 de 297



Actividades.Características.Planificación:

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.Un factor importante es la ordenación, por importancia, tanto de los casos de uso como de los riesgos.


29 de 297



Actividades.Características.Planificación.


30 de 297

CONCEPTO DE RIESGO


31 de 297

Riesgos

Riesgos:Definición:

Un riesgo es un asunto que tiene cierto grado de probabilidad de poner en peligro el éxito de un proyecto.

Tipos:Riesgos técnicos:

Relacionados con nuevas tecnologías.Relativos a la arquitectura.Relativos a la construcción del sistema adecuado que cumpla su misión.Relativos al rendimiento.


32 de 297

Riesgos

Riesgos:Definición.Tipos:

Riesgos técnicos.Riesgos no técnicos:

Falta de experiencia en ciertos aspectos.Lenguaje nuevo para la organización.Calendario demasiado apretado.Dependencia de empresas subcontratadas.Incumplimiento del cliente de algún plazo de aprobación.


33 de 297

Riesgos


Riesgos técnicos.Riesgos no técnicos.

Tratamiento:Evitarlo (introducir cambios).Limitarlo (restringirlo a una pequeña parte del proyecto).Controlarlo (plan de contingencia).Atenuarlo (forzar su aparición para aplicarle alguna de las opciones anteriores).


34 de 297

Riesgos


Riesgos técnicos.Riesgos no técnicos.

Tratamiento.


35 de 297

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

Captura de requisitos.Análisis.Diseño. Implementación.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.


36 de 297

COMPRENSIÓN DEL SISTEMA


37 de 297

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:

Modelo de dominio.Modelo de negocio.


38 de 297

Modelo de Dominio

Modelo de dominio:Definición:

Un modelo de dominio captura los tipos de objetos más importantes del contexto del sistema. Los objetos del dominio representan ‘cosas que existen’ o eventos que suceden en el entorno en que trabaja el sistema.

Descripción:Se describe mediante diagramas UML, principalmente el de clases.

Tipos de clases y objetos:Objetos del negocio que representan cosas que se manipulan en el negocio, por ejemplo pedidos o contratos.Objetos del mundo real y conceptos de los que el sistema debe hacer un seguimiento, por ejemplo aviación enemiga.Sucesos que ocurrirán o han ocurrido, por ejemplo llegada o salida de un avión.


39 de 297

Modelo de Dominio

Modelo de dominio:Definición.Descripción.Tipos de clases y objetos.Desarrollo:

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


40 de 297

Modelo de Dominio

Modelo de dominio:Definición.

Descripción.Tipos de clases y objetos.Desarrollo.Uso:

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:

Al describir los casos de uso y al diseñar la interfaz de usuario.Para sugerir clases internas al sistema en desarrollo durante el análisis.

Un modelo del dominio es en realidad un caso especial de un modelo del negocio que es más completo.


41 de 297

Modelo de Dominio

Modelo de dominio:Definición.

Descripción.Tipos de clases y objetos.Desarrollo.Uso.


42 de 297

Modelo de Negocio

Modelo de negocio:Definición de negocio:

Entendemos por negocio el campo del que se ocupa el sistema, porejemplo, la metodología que se está presentando es un caso de uso del negocio ‘del desarrollo de software’.

Definición:Es una técnica que permite comprender los procesos del negocio de la organización.

Objetivo: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.


43 de 297

Modelo de Negocio

Modelo de negocio:Definición de negocio.Definición.Objetivo.Descripción:

El modelo de negocio está soportado por dos tipos de modelos UML, el de casos de uso y el de objetos.

Elementos: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 clientesrespectivamente.


44 de 297

Modelo de Negocio

Modelo de negocio:Definición de negocio.Definición.Objetivo.Descripción.Elementos:

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.Una entidad del negocio es algo que los trabajadores toman, inspecciona, manipulan producen o usan en un caso de uso del negocio. Una unidad de trabajo es un conjunto de entidades que representa un todo reconocible para el usuario final.


45 de 297

Modelo de Negocio

Modelo de negocio:Definición de negocio.Definición.Objetivo.Descripción.Elementos:

Las entidades del negocio y las unidades de trabajo se usan pararepresentar los mismos tipos de conceptos que las clases del dominio. Se usarán otros diagramas para mostrar trabajadores, sus interacciones y cómo usan las entidades de negocio y la unidades de trabajos.


46 de 297

Modelo de Negocio

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

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.


47 de 297

Modelo de Negocio

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

Desarrollar un modelo de objetos del negocio compuesto por trabajadores, entidades del negocio y unidades de trabajo que juntasrealizan 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 laforma más eficaz posible (rápidamente, con precisión y a un coste bajo).


48 de 297

Modelo de Negocio

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


49 de 297

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.


50 de 297

Diferencias entre los Modelos

Diferencias entre el modelo de dominio y el de negocio:Origen de la información:

Las clases del dominio se obtienen de la base del conocimiento de unos pocos expertos del dominio, o del conocimiento asociado consistemas similares al que se desarrolla. 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.

Trazas: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.


51 de 297


Diferencias entre el modelo de dominio y el de negocio:Origen de la información.Trazas.Identificación de operaciones:

La clases del dominio tienen atributos pero ninguna o pocas operaciones. Las entidades del negocio poseen operaciones a través de las cuales se identifica cómo usarán los trabajadores el sistema.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.Las operaciones de las entidades del negocio se derivarán de los clientes y podrán ser trazadas hasta ellos.


52 de 297


Diferencias entre el modelo de dominio y el de negocio:Origen de la información.Trazas.Identificación de operaciones.Relación del modelo con los casos de uso del sistema:

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


53 de 297


Diferencias entre el modelo de dominio y el de negocio:Origen de la información.Trazas.Identificación de operaciones.Relación del modelo con los casos de uso del sistema:

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. Sin embargo, usando el modelo del dominio, no hay forma evidentede hacer traza entre éste y los casos de uso del sistema.


54 de 297


Diferencias entre el modelo de dominio y el de negocio:Origen de la información.Trazas.Identificación de operaciones.Relación del modelo con los casos de uso del sistema.


55 de 297

Fases para el Desarrollo


56 de 297

Fases del desarrollo de software

Fase de InicioFase de ElaboraciónFase de ConstrucciónFase de Transición

Mantenimiento


57 de 297

Ejemplo a Desarrollar

Ejemplo a desarrollar como ejercicio:Anillamiento de Aves.¿En qué consiste el anillamiento?

Planteamiento general del problema.


58 de 297

PLANIFICACIÓN DE LAS FASES


59 de 297

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:

El plan del proyecto, que engloba las cuatro fases. El plan de iteración, referente a una iteración concreta.

Los planes se controlarán mediante HITOS.


60 de 297

Planificación

Hitos:Definición:

Criterios que se deben cumplir al llegar a un determinado punto del desarrollo.

Necesidad:Seguimiento de la planificación.Evaluación del trabajo realizado. Sincronización del proyecto (si es llevado a cabo por distintos grupos en paralelo).

Tipos:Principales, al final de cada fase.Secundarios, al final de una iteración o de una construcción.


61 de 297

Planificación

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

Fase de Inicio:Objetivos del ciclo de vida.

Fase de Elaboración:Arquitectura del ciclo de vida.

Fase de Construcción:Capacidad operativa inicial.

Fase de Transición:Lanzamiento del producto.


62 de 297

Planificación

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


63 de 297

FASE DE INICIO


64 de 297

VISIÓN GENERAL DE LA FASE


65 de 297

Objetivos de la Fase

Objetivos:Delimitar el ámbito y el alcance del sistema:

Se pretende conocer el entorno (ámbito) del sistema, es decir, el campo del que se ocupa el sistema. 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.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.


66 de 297

Objetivos de la Fase

Objetivos:Delimitar el ámbito y el alcance del sistema.Justificar la puesta en marcha del proyecto:

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.Opcionalmente se puede realizar un prototipo exploratorio que muestre que se puede llegar a desarrollar el sistema, pero que no tiene porqué ser definitivo.


67 de 297

Planificación de la Fase

Planificación:Alcance:

Se desarrolla un plan para crear una arquitectura candidata sólo hasta el punto de establecer si el proyecto es factible.

Actividades:Reunir la información recogida antes de comenzar el proyecto.Organizarla.Reunir un grupo de gente para que la trate.Descubrir qué falla en términos de los objetivos de la fase de inicio.


68 de 297

Hitos de la Fase

Hito principal << Objetivos del ciclo de vida>>.¿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?¿Se ha llegado a un acuerdo con todas las personas involucradas sobre los requisitos fundamentales del sistema?¿Se vislumbra una arquitectura que implemente estas características?¿Se han identificado los riesgos críticos para el desarrollo exitoso del proyecto? ¿Se prevé una forma de tratarlos?¿El uso del producto generará beneficios que justifiquen lo invertido en su construcción? ¿Es factible para su organización llevar adelante el proyecto? ¿Están los inversores de acuerdo con los objetivos?


69 de 297

Evaluación de la Fase

Evaluación:Ámbito del sistema:

¿Está claro lo que va a formar parte del sistema?¿Se han identificado todos los actores?¿Se ha expuesto la naturaleza general de las interfaces?¿Puede, lo que está incluido en el ámbito, constituir por sí mismo un sistema que funcione?

Ambigüedades en los requisitos:¿Se han identificado y detallado los requisitos de los casos de uso necesarios para alcanzar los objetivos de esta fase?¿Se han identificado y detallado los requisitos adicionales?


70 de 297

Fase de Inicio

Evaluación:Ámbito del sistema.Ambigüedades en los requisitos.Arquitectura candidata:

¿Satisface esta arquitectura las necesidades de los usuarios?¿Es factible que funcione?

¿Puede usar de forma apropiada la tecnología sobre la que va a ser construida?¿Puede ser eficiente?¿Puede explotar los recursos existentes?¿Puede ser fiable y tolerante a fallos?¿Será robusta y flexible al cambio?¿Evolucionará fácilmente si se añaden requisitos?


71 de 297

Fase de Inicio

Evaluación:Ámbito del sistema.Ambigüedades en los requisitos.Arquitectura candidata.Mitigar riesgos críticos:

¿Se han identificado todos los riesgos críticos?¿Se han mitigado los riesgos identificados o existe un plan para mitigarlos?

Juzgar el valor del análisis de negocio inicial.


72 de 297

Fase de Inicio

Evaluación:Ámbito del sistema.Ambigüedades en los requisitos.Arquitectura candidata.Mitigar riesgos críticos.Juzgar el valor del análisis de negocio inicial.


73 de 297

DESARROLLO DE LA FASE


74 de 297

Fase de Inicio

Primera iteración:Actividades preliminares:

Ajustar la metodología al proyecto y seleccionar herramientas para la automatización del proceso.Reunir gente con el talento necesario para el proyecto.Crear relaciones que den lugar a un equipo efectivo.Entender el dominio, que a menudo es desconocido para el equipo.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.Familiarizar al equipo con las herramientas apropiadas.


75 de 297

Ajuste al entorno de desarrollo

Se inicia en esta fase y se culmina en la de elaboración.Entorno de desarrollo:

Procesos (configuración). Herramientas para llevarlos a cabo.Servicios (administración del sistema, copia de seguridad y telecomunicaciones).

PSI 1.1Completa

PSI 1.2Completa

PSI 1.3Completa

PSI-SEG 1.1Completa

PSI-SEG 1.2Completa

Fin Inicio Fin Inicio Fin Inicio Fin Inicio


77 de 297

Fase Preliminar


78 de 297

Fase de Inicio

Actividades fundamentales:Definición del ámbito del sistema.Esbozar arquitectura candidata.Análisis inicial del negocio.

Trabajo a realizar en cada iteración:Planificación.Flujos de trabajo fundamentales.Evaluación.


79 de 297

Fase de Inicio

Actividades fundamentales:Definición del ámbito del sistema.Esbozar arquitectura candidata.Análisis inicial del negocio.

Trabajo a realizar en cada iteración:Planificación.Flujos de trabajo fundamentales.Evaluación.


80 de 297

Flujos de trabajo fundamentales

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


81 de 297

Captura de Requisitos

Captura de requisitos:Actividades:

Enumerar requisitos candidatos, lista de características.Comprender el contexto del sistema.Representar requisitos funcionales como casos de uso.

Encontrar actores y casos de uso.Establecer prioridad.Detallar los que se estimen necesarios para cumplir los objetivos de la fase.

Recopilar requisitos no funcionales.


82 de 297

Análisis

Análisis:Objetivo:

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.

Actividades:Análisis de la arquitectura:

Identificar paquetes de análisis.Clases de entidad.Requisitos especiales comunes (persistencia, tolerancia a fallos, etc...)

Analizar un caso de usoIdentificación de clases de análisis.Descripción de interacciones entre objetos de análisis.Captura de requisitos especiales


83 de 297

Análisis

Análisis:Objetivo:Actividades:

Análisis de la arquitectura.Analizar un caso de uso.Analizar una clase:

Trabajo mínimo.Analizar un paquete:

Trabajo mínimo.


84 de 297

Resumen Análisis

Análisis:Objetivo:Actividades:

Análisis de la arquitectura.Analizar un caso de uso.Analizar una clase.Analizar un paquete.


85 de 297

Diseño

Diseño (Se puede desarrollar un prototipo de demostración):

Actividades:Diseño de la arquitectura:

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


86 de 297

Diseño

Diseño:Actividades

Diseño de la arquitectura.Identificar nodos y configuraciones de red.Identificar subsistemas e interfaces:

Subsistemas de aplicación.Subsistemas intermedios y de software del sistema.Dependencias entre subsistemas .Interfaces entre subsistemas .

Identificar clases de diseño relevantes para la arquitectura:A partir de clases del análisis.Identificar clases activas.

Identificación de mecanismos genéricos de diseño (conjuntos de elementos del diseño encargados de los requisitos especiales).


87 de 297

Diseño

Diseño:Actividades

Diseño de la arquitectura.Identificar nodos y configuraciones de red.Identificar subsistemas e interfaces.Identificar clases de diseño relevantes para la arquitectura.Identificación de mecanismos genéricos de diseño.Diseñar un caso de uso:

Trabajo mínimo.Diseñar una clase:

Trabajo mínimo.Diseñar un subsistema:

Trabajo mínimo.


88 de 297

Resumen del Diseño

Diseño:Actividades

Diseño de la arquitectura.Identificar nodos y configuraciones de red.Identificar subsistemas e interfaces.Identificar clases de diseño relevantes para la arquitectura.Identificación de mecanismos genéricos de diseño.Diseñar un caso de uso.Diseñar una clase.Diseñar un subsistema.


89 de 297

Implementación y Prueba

Implementación:Sólo necesaria si se va a realizar el prototipo.

Prueba:Trabajo mínimo.


90 de 297

Arquitectura por capas

Capa middleware

Capa general de la aplicación

Capa específica de la aplicación

Capa de software del sistema


91 de 297


Capas:Definición:

Una capa es un conjunto de subsistemas que tiene el mismo grado de generalidad.

Características:Las capas inferiores (middleware y de software del sistema) pueden establecerse sin considerar los casos de uso ya que no son dependientes del negocio. 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. La capa general contiene subsistemas no específicos que pueden ser reutilizados por muchas aplicaciones diferentes dentro del mismodominio o negocio.


92 de 297


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

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.


93 de 297


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


94 de 297

Análisis inicial del negocio

Análisis del negocio:Objetivo:

El análisis inicial de negocio sirve para determinar si se entra en lafase de elaboración.

Aspectos:Costes económicos: exigencias de recursos del proyecto, costes de la inversión. Estimaciones de beneficios y de aceptación (de mercado o interna).


95 de 297


Análisis del negocio:Objetivo.Aspectos.Actividades:

Esbozar una apuesta económica: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.


96 de 297


Análisis del negocio:Objetivo.Aspectos.Actividades:

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


97 de 297


Análisis del negocio:Objetivo.Aspectos.Actividades.


98 de 297

Evaluación de iteraciones

Evaluación:Participantes:

Se crea un grupo de evaluación que incluye representantes del cliente y/o de los usuarios.

Posibles criterios para ampliar el número de iteraciones:Ampliación del modelo de casos de uso.Desarrollo de un prototipo exploratorio.Sospecha de que no se hayan encontrado todos los riesgos críticos.Si no han sido mitigados todos los riesgos críticos o no han sido suficientemente cubiertos por un plan de emergencia

Conclusión:El resultado final de la evaluación determina si se sigue adelante o se abandona el proyecto.


99 de 297

Planificación de la fase de Elaboración

Se determina alrededor del 80% de los casos de uso sin pasar poralto 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.


100 de 297

Productos Generados1. 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.1Descripción de

procesos afectados, completa

PSI 2.2

Catálogo de usuarios, completa aunque el se añaden usuarios a lo largo del proyecto.

PSI 2.3Primera versión

del plan de trabajo, esbozo

Fin Inicio

Inicio

Inicio

PSI 3.1

Información relevante, completa

Inicio

Inicio

PSI 3.2

Requisitos generales, completa

Fin Inicio

EVS 3.1

Catálogo de normas, se intenta completar

aunque puede que sea necesario hacerlo en la

fase posterior

Inicio Inicio

PSI 4.1

Modelo de Procesos, completo

PSI 5.1Identificación de sistemas afectados, completa

Inicio Inicio

Inic

ioIn

icio

PSI 4.2Necesidades de

información, requisitos funcionales, diagrama de clases, completa

PSI 4.3

Requisitos de los procesos,

completa

EVS 1.3Usuarios y

plan de trabajo de esta fase

EVS 2.1

Descripción de sistemas actuales

completa si se tiene en cuenta la arquitectura, si no se completa en la

siguiente fase

Fin Fin

Fin InicioFin InicioInicio Inicio

Fin Fin

Inicio Inicio

Fin Fin

EVS 3.3

Catalogación de requisitos

EVS 3.2

Identificación de requisitos

EVS 2.4Diagnóstico

de la situación actual,

completa

EVS 2.3

Descripción lógica de los sistemas

actuales, modelo físico, diagrama de clases, completa

EVS 2.2Participantes del estudio de

la situación actual

Inic

io

F

in

Inicio FinInicio Fin Inicio Fin

EVS 1.2

Dependencias con otros proyectos,

visión global del alcance del sistema

Inic

io

Ini

cio

Inicio Inicio

Fin

F

in

PSI 5.2Descripción de sistemas afectados, completa

PSI 5.3Valoración de

sistemas afectados, completa

PSI 6.1Sistemas que se conservan

y mejoras propuestas,

completa

PSI 3.2 Inicio-Inicio

Modelo de negocio

PSI 4.3 Fin-Inicio

Modelo de negocio

Inicio Inicio

Fin Fin

Inicio Inicio

Fin Fin

Fin Inicio

Fin

Inic

io

Inic

io

Inic

io

Fin

F

in

Inic

io

F

in

Inic

io

Inic

io

Fin

F

in

Inic

io

Fin

Inic

io

Ini

cio

Fin

F

in

DSI 4.1Identificación de clases de

diseño, a partir de las de análisis


diseño adicionales, diseño de

casos de uso

DSI 4.2Asociaciones

y agregaciones de las clases identificadas

DSI 3.3Diseño de interfaz de

usuario, caso muy concreto

DSI 3.4Descripción de

casos de uso en términos de

subsistemas e interfaces, alto

nivel

DSI 3.2Interacción de

clases anteriormente identificadas, realización de casos de uso

DSI 4.3Atributos de las clases

identificadas, caso concreto

DSI 4.4

Operaciones de las clases, caso concreto

DSI 4.5

Jerarquía del modelo de

clases

DSI 4.6Pseudocódigo

de algún método concreto

DSI 6.1

Especificación a alto nivel del modelo físico de datos si mejora la

comprensión del sistema

DSI 6.4

Distribución de los datos a muy alto nivel,

modelo de datos no

optimizado.

DSI 7.2Análisis de

consistencia de los

productos obtenidos

DSI 8.1

Especificación del entorno tecnológico necesaria

para la realización del

prototipo

DSI 8.2

Definición de componentes y subsistemas

necesarios para el

prototipo.

DSI 10.1Especificación del entorno de pruebas para el prototipo

DSI 10.2

Niveles de prueba

DSI 10.3

Plan de pruebas

CSI 1.2

Preparación del entorno de construcción

para el prototipo

CSI 2.1

Generación de código

CSI 3.1Preparación

del entorno de pruebas unitarias

CSI 3.2Realización y evaluación de

pruebas unitarias

CSI 4.1Preparación

del entorno de pruebas de integración

CSI 4.2

Realización de pruebas de

integración

CSI 5.1Preparación

del entorno de pruebas del

sistema

CSI 5.2

Realización de pruebas del sistema

ASI 9.3 Fin-Inicio

Modelo de clases

Inicio

Inicio

Inicio Inicio

Fin Fin

Inicio Inicio

Fin Fin

Inicio Inicio

Fin Fin

ASI 3.2 Fin-Inicio

División en subsistemas

CSI 4.3

Evaluación de pruebas de integración

CSI 5.3

Evaluación de pruebas del

sistema

Fin

Fin

Fin Fin

Inicio Inicio Inicio Inicio

Fin Fin

Inicio Inicio

Fin Fin

Inicio Inicio

Fin Fin

Inicio Inicio

Fin Fin

Fin Inicio

DSI 3.3,3.4,6.4 Fin-Inicio

Productos obtenidos

Fin Inicio

Fin Inicio Inicio InicioInicio Inicio

Fin Fin

Inicio Inicio

Fin Fin

Inic

io

Inic

io

Fin

F

in

Inic

io

F

in

Inic

io

F

in

Fin

Ini

cio

Fin Inicio

Fin Inicio

Fin Inicio

Fin Inicio

Fin Inicio

Inicio Inicio

Fin Fin

Inicio Inicio

Fin Fin

CSI 2.1 Inicio-Inicio

Código del prototipo

CSI 2.1 Fin-Inicio


CSI 2.1 Fin-Inicio



104 de 297

Ejemplo Fase de Inicio


105 de 297

FASE DE ELABORACIÓN


106 de 297

Fase de Elaboración

Objetivos: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.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. Especificar los niveles a alcanzar por los atributos de calidad, como la fiabilidad y los tiempos de respuesta. Recopilar los casos de uso del (aproximadamente) 80% de los requisitos funcionales, suficiente para planificar la fase de construcción.


107 de 297


Objetivos:Preparar una propuesta de planificación cubierta, personal necesario y coste dentro de los límites establecidos por las prácticas de negocio.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.Completar los detalles del plan del proyecto.


108 de 297


Punto de vista: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: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.


109 de 297


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


110 de 297


Hito principal:Arquitectura del ciclo de vida:

¿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?¿Se han identificado y mitigado los riesgos graves hasta el punto de asegurar que no trastornarán el plan de proyecto?¿Se ha desarrollado un plan de proyecto hasta el nivel necesario para respaldar una agenda, costes y calidad realistas y que cubran laapuesta?¿Proporcionará el proyecto, tal como está planificado y presupuestado en este momento, una recuperación de la inversión?¿Se ha obtenido la aprobación de los inversores?


111 de 297


Evaluación:Extensión de requisitos:

¿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?¿Se han detallado lo suficiente como para lograr los objetivos de esta fase?

Definición de la línea de base de la arquitectura:¿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?¿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?


112 de 297

Fase de ElaboraciónEvaluación:

Extensión de requisitos.Definición de la línea de base de la arquitectura.Mitigar los riesgos significativos:

¿Se han mitigado de forma adecuada los riesgos críticos, ya sea eliminándolos o preparando un plan de emergencia?¿Se han identificado los riesgos significativos?¿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?


113 de 297


Evaluación:Extensión de requisitos.Definición de la línea de base de la arquitectura.Mitigar los riesgos significativos.Valía del análisis de negocio:

¿Está el plan del proyecto lo bastante definido como para apostar porun precio, agenda y calidad?¿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?¿Estamos listos para redactar un contrato por un precio fijo o elequivalente para un desarrollo interno?


114 de 297


Evaluación:Extensión de requisitos.Definición de la línea de base de la arquitectura.Mitigar los riesgos significativos.Valía del análisis de negocio.


115 de 297


Actividades fundamentales:Recopilación de la mayor parte de los requisitos:

Se identifica el 80% de los casos de uso.Se describen entre el 40 y el 80% de los mismos.La mitad de los casos de uso descritos se analizan.Se seleccionan los que permitan obtener la arquitectura y mitigar los riesgos para su diseño, implementación y prueba.

Desarrollo de la línea de base de la arquitectura: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. Se construye el entorno de pruebas y se prueba la línea de base.Los paquetes durante el análisis y los subsistemas durante el diseño son críticos para generar las vistas de la arquitectura.


116 de 297


Trabajo a realizar en cada iteración:Cuatro grupos de actividades ejecutándose en paralelo:

Planificación.Flujos de trabajos fundamentales.Evaluación.Preparación más detallada del entorno de desarrollo.


117 de 297


Consideraciones: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.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.Se debe construir prestando más atención a la calidad y la extensibilidad que en la fase de inicio.


118 de 297

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, puedeser 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.


119 de 297


Captura de requisitos:Actividades:

Encontrar casos de uso y actores.Determinar la prioridad de los casos de uso.Detallar un caso de uso.Estructurar el modelo de casos de uso:

Mecanismos como extensión o generalización.Desarrollar prototipos de las interfaces de usuario:

Casos muy concretos, en esta fase casi nunca se desarrollan.


120 de 297


Análisis:Elementos de trabajo:

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.

Adaptar los requisitos a la arquitectura:Si un cambio facilita el trabajo y su impacto es menor se negociarácon el cliente.


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.


121 de 297

Flujos de trabajo fundamentalesAnálisis:

Elementos de trabajo.Adaptar los requisitos a la arquitectura.Actividades:

Análisis de la arquitectura: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.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.Identificación de mecanismos subyacentes para implementar los casos de uso.


122 de 297


Análisis:Elementos de trabajo.Adaptar los requisitos a la arquitectura.Análisis de la arquitectura.Actividades:

Análisis de la arquitectura.Analizar un caso de uso:

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.


123 de 297

Flujos de trabajo fundamentalesAnálisis:

Elementos de trabajo.Adaptar los requisitos a la arquitectura.Actividades:

Análisis de la arquitectura.Analizar un caso de uso.Analizar una clase:

Refinar las clases de análisis identificadas anteriormente mezclando las responsabilidades que se les asignaron en los diferentes casos de uso. Se identifican los mecanismo de análisis y cómo fueron usados por cada clase.

Analizar un paquete:Los paquetes de servicio identificados en el análisis de la arquitectura se refinan y mantienen


124 de 297


Análisis:Elementos de trabajo.Adaptar los requisitos a la arquitectura.Actividades:



125 de 297


Diseño:Alcance:

Se diseña e implementa menos del 10% de los casos de uso.


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.


126 de 297


Diseño:Alcance.Actividades:

Diseño de la arquitectura:Identificar la arquitectura en capas:

• Se pueden construir/desarrollar en paralelo con el análisis.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

Identificar clases de diseño arquitectónicamente significativas• Traducción de las clases de análisis significativas a clases de

diseño


127 de 297



Diseño de la arquitectura: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.


128 de 297

Flujos de trabajo fundamentalesDiseño:

Alcance.Actividades:

Diseño de la arquitectura.Diseño de un caso de uso:

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.Los paquetes y las clases de análisis proporcionan una forma directa de encontrar subsistemas y clases de diseño.

Diseño de una clase:Se diseñan las clases que participarán en las realizaciones de los casos de uso del apartado anterior.


129 de 297



Diseño de la arquitectura.

Diseño de un caso de uso.Diseño de una clase.Diseño de un subsistema:

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.


130 de 297



Diseño de la arquitectura.

Diseño de un caso de uso.Diseño de una clase.Diseño de un subsistema.


131 de 297

Flujos de trabajo fundamentalesImplementación:

Línea base de la arquitectura:Deberá estar bajo el control de alguna herramienta.

Se implementan y prueban los componentes arquitectónicamente significativos a partir de los elementos de diseño homólogos. El resultado es la línea de base implementada a partir de menos del 10% de los casos de uso.

Actividades:Implementación de la arquitectura:

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. Los componentes ejecutables se asignan a los nodos en los que van a ejecutarse. Se genera la vista de la arquitectura del modelo de implementación.


132 de 297


Línea base de la arquitectura.Actividades:

Implementación de la arquitectura.Implementación de una clase (subsistemas implícitos):

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.Las pruebas unitarias aseguran que cada componente funciona como una unidad. La línea de base de la arquitectura resultante es una versión ejecutable preliminar del sistema.

Integrar el sistema: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.


133 de 297


Implementación:Línea base de la arquitectura.Actividades:

Implementación de la arquitectura.Implementación de una clase (subsistemas implícitos).Integrar el sistema.


134 de 297


Prueba:Alcance:

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. 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. Se comprueba no sólo la funcionalidad sino también el rendimiento. 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.


135 de 297


Prueba:Alcance.Actividades:

Planificar las pruebas:Se seleccionan los objetivos que evaluarán la línea de base de la arquitectura.

Diseñar las pruebas: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.

Realizar pruebas de integración:Se comprueba cada construcción.

Realizar pruebas del sistema:Una vez se ha integrado el sistema se prueba.


136 de 297


Prueba:Alcance.Actividades.Evaluación:

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.


137 de 297


Prueba:Alcance.Actividades.Evaluación.


138 de 297

Desarrollo del análisis de negocio

Análisis del negocio:Alcance:

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.Límites del negocio:

La planificación, esfuerzo y costes estimados para una calidad dada.La recuperación de la inversión, indicando que el sistema propuesto será económicamente un éxito.

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.


139 de 297

Desarrollo del análisis de negocioAnálisis del negocio:


Preparar la apuesta económica: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.

Las estimaciones del software se basan en el tamaño del proyecto y la productividad de la organización de desarrollo. La productividad se deriva de la experiencia.


140 de 297

Desarrollo del análisis de negocioAnálisis del negocio:


Preparar la apuesta económica: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.Si el proyecto presenta riesgos de cierta magnitud se investiganhasta estimar cuánto tiempo y esfuerzo llevará superarlos.

Actualizar la recuperación de la inversión: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. Si es un producto interno el departamento “destino” deberáestimar su ahorro. El margen de error es muy grande.


141 de 297

Desarrollo del análisis de negocio

Análisis del negocio:Alcance.Actividades:

Preparar la apuesta económica.Actualizar la recuperación de la inversión.


142 de 297


Evaluación:Actividades:

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.Al final de cada iteración se evalúa si se han conseguido los objetivos establecidos, en caso contrario se reorientan las iteraciones siguientes. 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.

Ventajas: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.


143 de 297


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

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.


144 de 297


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


145 de 297

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ñasSe 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.


146 de 297

Planificación de la fase de Construcción

Secuenciar las construcciones e iteraciones:En proyectos grandes con restricciones temporales se realiza esta tarea buscando rutas que permitan trabajar en paralelo.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. Estos subsistemas determinan el despliegue de los participantes en esta fase.Esta independencia en el trabajo se basa en unas interfaces sólidas.


147 de 297

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.

Inic

io

Ini

cio

Fin

F

in

ASI 2.4

Validación de casos de uso

anteriores

ASI 3.1Descripción

de subsistemas e

interfaces

ASI 4.1

Identificación de clases de

análisis

ASI 4.2Análisis de

realizaciones de casos de uso, descripción de interacción de objetos

ASI 8.3Definición de

alguna pantalla

necesaria para la

comprensión de un caso de uso concreto

ASI 3.2

Integración de subsistemas

ASI 5.1

Responsabilidades y atributos de las clases anteriores

ASI 5.2Identificación

de agregaciones

y asociaciones

ASI 5.3

Identificación de generalizaciones


y especificación

de los diálogos

considerados críticos

ASI 8.5Formatos de impresión, caso muy concreto

ASI 9.1Verificación

de la arquitectura del sistema

ASI 9.2Análisis de

consistencia muy exhaustivo de la

arquitectura

ASI 2.3 Inicio-Inicio, Fin-FinCasos de uso

arquitectónicamente significativos

Inicio

Inicio

Fin

Fin

Inicio

Inicio

Fin

Fin

Inicio InicioFinFin

Inicio

Inicio

Fin

Fin

Inicio Inicio

Fin Fin

Inicio Inicio

Fin Fin

Inicio Inicio

Fin Fin

Inicio Inicio

Fin Fin


Fin I

nicio

Fin Inicio

Fin Inicio

Fin

Ini

cio

Fin Inicio

ASI 1.3 Inicio-Inicio

Normas y estándares

ASI 4.2 Inicio-Inicio, Fin-FinRealización de casos de

uso

Fin Inicio

Inic

io

Ini

cio

Fin

F

in

Inicio InicioFin Fin

Inic

io

F

in


Inicio

In

icio

Fin

Fin

Inic

io

Ini

cio

Fin

F

in

Inicio Inicio

Fin

Fin


Inic

io

Ini

cio

Fin

F

in

Fin Inicio

EVS-CAL 1.2Determinación

de sistemas objeto del

aseguramiento de la calidad

EVS-CAL 1.3Identificación

de propiedades de calidad

EVS-CAL 2.1Necesidad del

plan de aseguramiento de la calidad de cada alternativa

EVS-CAL 2.2Alcance del plan

de aseguramiento de la calidad de cada alternativa

EVS-CAL 2.3Análisis de

consistencia de la

arquitecturaEVS-CAL 3.1

Ajuste del plan a la solución

selecionada

EVS-CAL 1.1Se constituye el

equipo de calidad y el plan

de acción

EVS-CAL 3.2

Aprobación del plan de la

solución

EVS 4.2 Inicio-Inicio, Fin-Fin

Alternativas de solución

EVS 6.2 Fin-Inicio

Solución propuesta

Fin Inicio

Inicio Inicio

Fin Fin



Inicio Inicio

Fin Fin

Inicio Inicio

Fin Fin


Fin InicioFin Inicio

EVS 6.3 Fin-Inicio

Solución aprobada

ASI-CAL 1.1Definición

detallada del plan de

aseguramiento de la calidad de

la solución

ASI-CAL 2.1

Actividades y tareas del

plan

ASI-CAL 3.1

Revisión del catálogo de requisitos

ASI-CAL 3.2

Revisión de consistencia de productos

DSI-CAL 1.1Revisión de consistencia de productos

del diseño

DSI-CAL 1.2

Aceptación de la arquitectura

del sistema

DSI-CAL 2.1Revisión de

pruebas unitarias, del sistema y de aceptación

DSI-CAL 2.2

Revisión del plan de pruebas

CSI-CAL 2.1

Revisión de pruebas unitarias

CSI-CAL 2.2

Revisión de pruebas de integración

CSI-CAL 2.3

Revisión de pruebas del

sistema


Catálogo de requisitos

DSI 7.2 Inicio-Inicio, Fin-FInAnálisis de consistencia de

la arquitectura

DSI 7.3 Fin-Inicio

Aceptación del diseño

DSI 10.2 Inicio-Inicio, Fin-Fin

Pruebas

EVS-CAL 3.1 Fin-Inicio

Plan para la solución

Inicio Inicio

Fin Fin

Inicio Inicio

Inicio

Inicio

ASI 9.3 Inicio-Inicio, Fin-Fin

Validación de la arquitectura

Inicio Inicio

Fin Fin

ASI-CAL 4.1


ASI 10.3 Fin-Inicio

Plan de pruebas

Fin Inicio

Fin Inicio


Pruebas

Inicio Inicio

Fin Fin

CSI-CAL 1.1

Revisión de normas de

construcción

CSI 2.2 Inicio-Inicio, Fin-Fin

Código generado

Fin Inicio


Pruebas unitarias


Pruebas de integración


Pruebas del sistema

Inicio Inicio

Fin Fin

Inicio Inicio

Fin Fin

Fin Inicio

EVS-GC 1.1

Requisitos de la gestión de la configuración

EVS-GC 2.1

Plan de gestión de la configuración

EVS-GC 2.2Entorno

tecnológico para la

gestión de la configuración

GC 1.1Identificación y registro de

productos generados en

esta fase


productos globales

GPI 1.1

Estimación del esfuerzo, identificación de elementos a desarrollar

GPI 1.2

Cálculo del esfuerzo

GPI 2.1

Selección de la estrategia de desarrollo

GPI 2.2Adaptación de

la metodología al proyecto

GPI 2.3

Calendario de hitos y

entregas

GPI 2.4

Planificación general del proyecto

GPI 2.5

Aceptación de la

planificación

GPS 1.1

Asignación de tareas a

miembros del proyecto

GPS 3.1

Seguimiento de tareas

GPS 2.1Comunicación

de la asignación de

tareas al equipo

GPS 4.2

Propuesta de solución a la incidencia GPS 4.1

Gestión de incidencias, análisis del

impacto

GPS 4.3

Registro de la incidencia

GPS 10.1

Resumen final de una tarea

finalizada

GPS 11.1Actualización

de la planificación

de tareas

GPS 11.2Simulación,

extrapolación de la situación del proyecto

GPS 11.3

Informe de seguimiento

GPS 12.1

Reunión interna de

seguimiento

PSI 9.2, EVS 3.2 Inicio-Inicio, Fin-Fin

Arquitectura y requisitos

EVS 6.2 Fin-Inicio

Solución propuesta

Inicio InicioInicio Inicio

Fin Fin

EVS 6.2 Fin-Inicio

Solución propuesta

Inicio Inicio

Fin Fin

Fin Inicio Fin Inicio Fin InicioInicio Inicio

Fin Fin

Fin Inicio

GPI 2.4 Inicio-Inicio, Fin-Fin

Planificación del proyecto

Fin Inicio




Fin Inicio

Fin Inicio

Fin Fin

Inicio Inicio

GPS 3.1 Inicio-Inicio, Fin-Fin


Inicio Inicio

Fin Fin

Inicio Inicio

Fin Fin

Inicio Inicio

Fin Fin


155 de 297

FASE DE CONSTRUCCIÓN


156 de 297

Fase de Construcción

Objetivos: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.

El producto tendrá la calidad adecuada y cumplirá los requisitos. Su construcción tendrá lugar dentro de los límites del plan de negocio.

Mitigar todos los riesgos, excepto los que derivan de la operación con el sistema que son tratados en la fase de transición. Ajustar la construcción a la arquitectura.

Sin embargo, se puede modificar la arquitectura para incorporar los cambios que surjan en esta fase si es necesario.


157 de 297

Fase de ConstrucciónActividades (A partir de la línea de base de la arquitectura):

Culminación de las tareas de identificación de requisitos, análisis, diseño e implementación iniciadas en fases anteriores.

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.

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.Mantenimiento de la integridad de la arquitectura, modificándola sólo cuando sea necesario.Integración y prueba de cada subsistema y del sistema completo.Seguimiento de riesgos críticos arrastrados de fases anteriores y mitigación si se materializan.Actualización de la lista de riesgos.


158 de 297


Enfoque: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: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.


159 de 297


Hito principal:Capacidad operativa inicial:

¿Es el nivel de capacidad el adecuado para realizar las pruebas beta en el entorno del usuario?Es muy importante el secuenciamiento de construcciones e iteraciones.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.


160 de 297


Tareas preliminares:Planificación:

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.

Asignación de personal: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. El número de trabajadores es aproximadamente el doble del de la fase de elaboración.

Establecimiento de criterios de evaluación: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.


161 de 297

Fase de ConstrucciónTareas preliminares:

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

El material adicional debe ser evaluado: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?

Material de cursos:• Diapositivas, notas, ejemplos y tutoriales. • ¿Son suficientes para dar soporte a los usuarios en la fase

de transición?


162 de 297


Tareas preliminares:Planificación.Asignación de personal.Establecimiento de criterios de evaluación.


163 de 297


Trabajo a realizar en cada iteración:Cuatro grupos de actividades ejecutándose en paralelo:

La planificación.Los cinco flujos de trabajo fundamentales.La evaluación.El análisis de negocio.


164 de 297

Fase de ConstrucciónConstrucción del sistema:

A medida que se van realizando iteraciones el énfasis se desplaza desde los flujos de trabajo iniciales hacia los finales.Los requisitos y la arquitectura son estables. 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. Los incrementos se ordenan de forma progresiva para que no sea necesario volver atrás. 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. Pueden aparecer riesgos nuevos a medida que se realizanconstrucciones y los usuarios prueban nuevos incrementos.


165 de 297


Captura de requisitos:Objetivo:

Identificar y detallar todos los requisitos.Actividades:

Encontrar actores y casos de uso:Si es necesario se actualizan los casos de uso y el modelo de casos de uso.

Desarrollar un prototipo de la interfaz de usuario: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. 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.


166 de 297


Captura de requisitos:Objetivo.Actividades:

Encontrar actores y casos de uso. Desarrollar un prototipo de la interfaz de usuario:

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.

Determinar la prioridad de los casos de uso: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.


167 de 297



Encontrar actores y casos de uso. Desarrollar un prototipo de la interfaz de usuario.Determinar la prioridad de los casos de uso.Detallar un caso de uso:

Se detallan completamente los casos de uso y escenarios restantes, trabajando con ellos según su importancia.

Estructurar el modelo de casos de uso:Ya que la arquitectura es estable los cambios deben referirse alos casos de uso aún no desarrollados.


168 de 297



Encontrar actores y casos de uso. Desarrollar un prototipo de la interfaz de usuario.Determinar la prioridad de los casos de uso.Detallar un caso de uso.Estructurar el modelo de casos de uso.


169 de 297


Análisis:Alcance:

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. La vista de la arquitectura, la parte realizada en la fase de elaboración, será sólo un subconjunto del modelo de análisis.

Objetivo:Si se mantiene el objetivo será completarlo al final de esta fase.


Actualizaciones, trabajo mínimo.Analizar un caso de uso.


170 de 297


Análisis:Alcance.Objetivo.Actividades:

Análisis de la arquitectura.Analizar un caso de uso.Analizar una clase.Analizar un paquete:

Se refinan para adaptarlos a los nuevos casos de uso.


171 de 297


Análisis:Alcance:Objetivo:Actividades:



172 de 297


Diseño:Alcance:

Se diseña e implementa el 90% de los casos de uso, los no incluidos en la línea de base de la arquitectura.Se actualizarán, introduciendo mejoras, los modelos de diseño y despliegue.


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.


173 de 297


Implementación:Alcance:

Se implementan y se llevan a cabo las pruebas de unidad de todos los componentes, trabajando a partir del modelo de diseño. Se obtiene la versión operativa inicial, que representa el 100% de los casos de uso. 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.

Actividades:Implementación de la arquitectura:

Actualizaciones, poco trabajo.


174 de 297


Implementación:Alcance.Actividades:

Implementación de la arquitectura.Implementación de una clase y de un subsistema:

Se implementan las clases y subsistemas del modelo de implementación, y las clases stub cuando sea necesario para armar una construcción.

Realizar prueba de unidad:Si es necesario se corregirá el diseño y la implementación del componente.


175 de 297



Implementación de la arquitectura.Implementación de una clase y de un subsistema.Realizar prueba de unidad.Integrar el sistema:

Se crea un plan de integración de construcciones que perfile la secuencia de construcciones. El plan muestra los casos de uso o escenarios que se van a implementar en la construcción.Normalmente se empiezan a construir las capas inferiores (la delsoftware del sistema o la intermedia), las construcciones siguientes se expandirán hacia arriba (capas general y específica de la aplicación).


176 de 297




Es difícil montar una construcción sin las funciones de apoyo que proporcionan las capas inferiores.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.


177 de 297




Al final de cada iteración se conecta el sistema entero y se hacen pruebas de integración y regresión.Esta planificación establece la secuencia de construcciones e iteraciones de esta fase. 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.


178 de 297



Implementación de la arquitectura.Implementación de una clase y de un subsistema.Realizar prueba de unidad.Integrar el sistema.

Representación de componentes no construidos:Facilitan la limitación del tamaño de la construcción.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.Driver proporciona estímulos a los otros componentes que forman parte de la construcción que se está probando.


179 de 297



Implementación de la arquitectura.Implementación de una clase y de un subsistema.Realizar prueba de unidad.Integrar el sistema.

Representación de componentes no construidos.


180 de 297

Flujos de trabajo fundamentalesPrueba:

Actividades:Planificar pruebas:

Se seleccionan los objetivos que comprueben las sucesivas construcciones y finalmente el propio sistema.

Diseñar pruebas:Se determina cómo probar los requisitos en el conjunto de construcciones, para verificar los requisitos que puedan ser comprobados. 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. 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.


181 de 297


Prueba:Actividades:

Planificar pruebas.Diseñar pruebas. Realizar pruebas de integración:

Se ejecutan los casos de prueba siguiendo los procedimientos de prueba. Si la construcción supera las pruebas, se van añadiendo construcciones adicionales y se van comprobando. 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.


182 de 297

Flujos de trabajo fundamentalesPrueba:

Actividades:

Planificar pruebas.Diseñar pruebas. Realizar pruebas de integración.Realizar pruebas del sistema:

Cuando se termina una iteración se obtiene una versión parcial del sistema y se realizan las pruebas del sistema. Se ejecutan los casos de prueba del sistema siguiendo los procedimientos de prueba del sistema. Si se detectan fallos se registran y se notifican.

Al final de esta fase se comprueba la versión operativa inicial


183 de 297


Prueba:Actividades:

Planificar pruebas.Diseñar pruebas. Realizar pruebas de integración.Realizar pruebas del sistema.Evaluar las pruebas:

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. Si una prueba no alcanza sus objetivos los casos y procedimientos de prueba deberán ser modificados.


184 de 297


Prueba:Actividades:

Planificar pruebas.Diseñar pruebas. Realizar pruebas de integración.Realizar pruebas del sistema.Evaluar las pruebas.


185 de 297

Control del análisis de negocio

Actividades:Se compara el progreso real al final de cada iteración con la agenda, esfuerzo y costes planificados en la fase de elaboración.Se revisan los datos de productividad del proyecto.

Medición del progreso: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: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.


186 de 297

Evaluación de las iteraciones

Actividades:Revisar lo logrado en una iteración contrastándolo con lo que se había planificado.Planificar en cuál de las iteraciones siguientes se realizará el trabajo no completado.Actualizar la lista de riesgos.Completar el plan de la iteración siguiente.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.Autorizar la entrada en la fase de transición.Actualizar el plan del proyecto.


187 de 297

Planificación de la fase de Transición

Aspectos conocidos:Se sabe que se van a producir versiones beta para los usuarios.Sólo se podrá planificar: selección de encargados de probar las versiones beta, preparar instrucciones de prueba etc...

Aspectos desconocidos:Respuesta de los usuarios:

Riesgo.Problema.Fallo.Sugerencia.

Personal:Si se tiene experiencia se podrá estimar la cantidad aproximada de personal especializado necesario para abordar los problemas que los usuarios descubran.


188 de 297

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 1.1Procesos y

requisitos de la solución, glosario,

modelo de negocio, se completa la labor de la fase anterior

ASI 8.1

Definición final de los principios

generales de interfaz de

usuario

ASI 1.3

Catálogo de normas

Inicio Inicio

ASI 2.3

Análisis riguroso de los casos de uso de ASI 2.2

ASI 2.2

Especificación de casos de uso

restantes

ASI 2.1Modelo de

casos de uso, se completa si es necesario

Inicio Inicio

Fin Fin

Inicio Inicio

Fin Fin

ASI 2.4


anteriores

ASI 3.1Introducción de

actualizaciones y mejoras en los subsistemas

ASI 4.1


análisis

ASI 4.2Análisis de



formatos individuales de pantalla

ASI 3.2Revisar

consistencia si se introdujeron

modificaciones en la tarea anterior

ASI 5.1


ASI 5.2

Identificación de agregaciones y asociaciones, revisión de la

especificación de subisistemas para

su posible optimización

ASI 5.3


ASI 8.4Especificación del comportamiento dinámico de las

interfaces

ASI 8.5

Especificación de formatos

de impresión,

ASI 9.1

Verificación de todos los

modelos

ASI 9.2

Análisis de consistencia de

todos los modelos

Inicio

Inicio

Fin

Fin

Inicio

Inicio

Fin

Fin

Inicio InicioFinFin

Inicio

Inicio

Fin

Fin

Inicio Inicio

Fin Fin

Inicio Inicio

Fin Fin

Inicio Inicio

Fin Fin

Inicio Inicio

Fin Fin


Fin I

nicio

Fin Inicio

Fin Inicio

Fin

Ini

cio

Fin Inicio



Inicio Inicio

Fin Fin

Inicio Inicio

Fin Fin


Casos de uso restantes

ASI 4.2 Inicio-Inicio, Fin-FinRealización de casos de uso

Fin Inicio

Inic

io

Ini

cio

Fin

F

in

Inic

ioFi

n

Inicio Inicio

Fin Fin

Inicio

In

icio

Fin

Fin

Inic

io

Inic

io

Fin

Fi

n

DSI 7.1

Verificación del diseño

(Calidad), modelo de datos

optimizado

DSI 7.2

Análisis de consistencia del diseño

DSI 7.3Aceptación del análisis realizado

anteriormente

DSI 11.1Especificación

de requisitos de documentación

de usuarios beta

DSI 8.2Definición de

componentes y subsistemas de implementación como traducción directa del diseño

DSI 8.3

Especificación en psedocódigo de componentes

DSI 1.3,1.4 Inicio-Inicio,DSI 1.6,3.3,3.4,6.4 Fin-Inicio

Productos de diseño

Inicio Inicio

Fin Fin

Fin Inicio

DSI 1.7 Fin-Inicio

Operación y seguridad

Inicio Inicio

Fin

Fin Inicio InicioFin Fin



DSI 11.2

Requisitos de implantación

DSI 12.1

Aprobación del diseño del

sistema


Fin Inicio

DSI 7.3,8.4,9.4,10.3 Fin-InicioProductos de diseño

DSI 8.4

Especificación del modelo físico de

datos

Inicio Inicio

Fin Fin

DSI 10.2

Especificación de los niveles

de prueba

DSI 10.3

Especificación del plan de

pruebas

CSI 3.1Preparación


CS 4.1Preparación


CSI 5.1Preparación


sistema

CSI 5.2


CSI 3.2Realización y evaluación de las pruebas

unitariasCSI 4.2


integración

CSI 4.3


CSI 5.3


sistema


Pruebas

Fin Inicio

Fin Inicio

Fin Inicio

Fin Inicio

Fin Inicio

Fin Inicio

Inicio Inicio

Fin Fin

Inicio Inicio

Fin Fin


Código generado


Código generado

CSI 2.2 Fin-Inicio

Código generado

CSI 1.1Implantación de la BD o el sistema de

ficheros

Fin Inicio

CSI 2.1Generación del código de los componentes

de DSI 8.2

CSI 2.2Generación de código de los

procedimientos de operación y

seguridad

CSI 6.1

Completar el manual de

usuarios beta

Inicio Inicio

Fin Fin

DSI 1.7 Fin-Inicio


Inicio Inicio

Fin Fin


DSI 9.1Especificación del entorno de

migración y carga inicial

DSI 9.2Diseño de

procedimientos de migración y

carga inicial

DSI 9.3Diseño de

componentes de migración y carga inicial

DSI 9.4Revisión del

plan de migración y carga inicial

Inicio Inicio

Fin Fin

Inicio Inicio

Fin Fin

Inicio Inicio

Fin Fin

CSI 8.1Preparación

del entorno de migración y carga inicial

de datos

CSI 8.2

Generación de código de los

componentes y procedimientos

de la migración y carga inicial de

datos

CSI 8.3

Realización y evaluación de las pruebas de migración y carga inicial

de datos

CSI 7.1

Primera versión del esquema de

formación de usuarios finales

CSI 7.2Especificación de recursos y

entorno de formación

Inici

o

In

icio

Fin

Fin

Inicio Inicio

Fin FinInicio InicioFin Fin

Inicio Inicio

Fin Fin


Fin Inicio

ASI-CAL 2.1Actividades y

tareas del plan de calidad

ASI-CAL 3.1


ASI-CAL 3.2



del diseño

DSI-CAL 1.2Aceptación de la arquitectura del sistema, incluida

la interfaz de usuario y el

modelo de datos optimizado



DSI-CAL 2.2





la arquitectura

DSI 7.3 Fin-Inicio

Aceptación del diseñoDSI 10.2 Inicio-Inicio, Fin-Fin

Pruebas

Inicio Inicio



Inicio Inicio

Fin Fin

ASI-CAL 4.1


ASI 10.3 Fin-Inicio

Plan de pruebas

Fin Inicio Fin Inicio

DSI 10.3, DSI-CAL 2.1 Inicio-Inicio, Fin-Fin

PruebasCSI-CAL 2.1


CSI-CAL 2.2


CSI-CAL 2.3


sistema

CSI-CAL 1.1


construcción


Código generado

Fin Inicio


Pruebas unitarias




Pruebas del sistema

Inicio Inicio

Fin Fin

Inicio Inicio

Fin Fin



esta fase


productos globales

ASI-CAL 5.1

Registro de aprobación

del ASI

DSI-CAL 3.1Revisión de requisitos de

documentación de usuario

DSI-CAL 3.2

Revisión de requisitos de implantación

DSI-CAL 4.1


del DSI

CSI-CAL 3.1

Revisión de manuales de

usuario

CSI-CAL 4.1

Revisión de esquemas de

formación

ASI 11.1 Fin-Inicio

ASI aprobado


Inicio Inicio

Fin Fin


Documentación de usuario


Implantación

Inicio Inicio

Fin FinFin Inicio

DSI 12.1 Fin-Inicio

DSI aprobado

Fin Inicio

Inicio Inicio

Fin Fin

CSI 6.1, CSI-CAL 2.3 Inicio-Inicio, Fin-FinManual de usuario


Esquemas de formación

GPS 1.1



GPS 3.1




tareas al equipo

GPS 4.2

Propuesta de solución a la

incidencia GPS 4.1Gestión de incidencias, análisis del

impacto

GPS 4.3


GPS 10.1


finalizada

Fin Inicio



Fin Inicio

GPS 13.1

Aceptación interna

Inicio Inicio

Fin Fin

Fin Inicio

Fin Inicio

GPS 5.1Registro de la

petición de cambio de requisitos

GPS 6.1

Análisis de la petición

GPS 6.2

Análisis del impacto

GPS 6.3

Alternativas y propuesta de

solución

GPS 7.1

Aprobación de la solución GPS 8.1

Estimación del esfuerzo

para el cambio

GPS 8.2

Planificación de cambios

GPS 9.1

Registro de la solución adoptada GPS 11.1

Actualización de tareas



GPS 11.3


GPS 12.1

Reunión interna de

seguimiento

GPS 3.1 Fin-Inicio

Seguimiento

Inicio Inicio

Fin Fin

Inicio Inicio

Fin Fin

Inicio Inicio

Fin Fin

Inicio Inicio

Fin Fin

Fin Inicio

Inicio Inicio

Fin Fin

Fin Inicio


Fin Inicio

Fin Inicio


Cambio

ASI-SEG 2.1Estudio de funciones y mecanismos de seguridad necesarios

ASI-SEG 3.1Inclusión de criterios de

seguridad en las pruebas




Pruebas

Inicio Inicio

Fin Fin

ASI-SEG 4.1Clasificación y catalogación

de los productos del

ASI

ASI 10.3 Fin-Inicio

Fin del ASI

DSI-SEG 3.1Requisitos de seguridad del

entorno de construcción

CSI-SEG 4.1Clasificación y catalogación


CSI

CSI 5.3 Fin-Inicio

Fin del CSI

DSI-SEG 5.1Clasificación y catalogación


DSI

DSI 10.3 Fin-Inicio

Fin del DSI

CSI-SEG 3.1

Plan de formación de

seguridad


Entorno de construcción


Formación usuarios finales

Inicio Inicio

Fin Fin

DSI-SEG 4.1

Diseño de pruebas de seguridad

CSI-SEG 2.1

Evaluación de las pruebas

de seguridad

DSI 1.7, ASI-SEG 4.1,2.1 Inicio-Inicio, Fin-Fin

Pruebas CSI 3.2,4.2,5.2 Inicio-Inicio, Fin-Fin

Pruebas

Inicio Inicio

Fin Fin


194 de 297

FASE DE TRANSICIÓN


195 de 297

Fase de TransiciónAlcance:

Se acomete la prueba de la versión beta del sistema generada en la fase de construcción.

Actividades:Preparación de las actividades, como la preparación del entorno.Aconsejar al cliente sobre actualizaciones del entorno en el que se ejecutará el software.Preparación de manuales y en general del material necesario para la entrega del producto.Ajustar el software para que funcione con los parámetros actuales del entorno de usuario.Corregir los defectos encontrados a lo largo de las pruebas realizadas a la versión beta.Realizar las modificaciones necesarias cuando se detecten problemas que no habían sido previstos.


196 de 297

Fase de Transición

Actividades para la organización de desarrollo:

Encontrar, discutir, evaluar y registrar las ‘lecciones aprendidas’ a lo largo del desarrollo del sistema actual.Registrar aspectos útiles para la versión siguiente.


197 de 297

Fase de Transición

Objetivos:Cumplir los requisitos para todos los usuarios, funcionalidad completa.

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 deconstrucción.


198 de 297

Fase de Transición

Objetivos: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).

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.

Si la característica va a afectar a la planificación su importancia debe ser vital. En la mayoría de los casos se añade a una lista de características para el desarrollo de la siguiente versión.


199 de 297

Fase de TransiciónRespuestas:

Tipos:Si el sistema hace lo que demandan sus usuarios y el negocio.Riesgos inesperados.Problemas no resueltos.Fallos.Ambigüedades y lagunas en la documentación del usuario.Áreas en las que los usuarios muestren deficiencias y necesiten información o formación.

Consecuencias:Partiendo de una respuesta de este tipo, se modifica el sistema o algún artefacto relacionado.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.


200 de 297

Fase de Transición

Ayuda para el uso del producto: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.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.Si el producto es para la venta estos servicios se construyen en el programa de instalación, completando el servicio de asistencia telefónica.


201 de 297

Fase de Transición

Hito principal:Lanzamiento del producto:

¿Es capaz de operar con éxito en entornos de usuarios típicos?


202 de 297

Fase de TransiciónTipos de acuerdos contractuales:

Producción por parte de un fabricante de software para la venta en un determinado mercado a muchos clientes:

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.

Producción por parte de un casa software para un único cliente:Único cliente con una única sede.Único cliente con muchas suborganizaciones y sedes.La organización software desarrolla software inicialmente para un único cliente o sede y luego lo adapta a otras sedes o clientes.La organización software desarrolla software para otro departamento de la misma empresa bajo acuerdos contables específicos.


203 de 297

Al comienzo de la fase de Transición

Situación inicial: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:En esta fase se preparan artefactos adicionales, tales como programas de instalación, de conversión o migración de datos.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.


204 de 297

Fase de Transición

Planificación:Aspectos conocidos:

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.

Aspectos desconocidos:Resultados de las pruebas beta.

Versión beta: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.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.


205 de 297

Fase de Transición

Planificación:Aspectos conocidos.Aspectos desconocidos.Versión beta.Resultados:

No existe un producto software perfecto, así el objetivo es un software “lo bastante bueno”. 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.


206 de 297

Fase de TransiciónPlanificación:

Aspectos conocidos.Aspectos desconocidos.Versión beta.Resultados.Motivos que propician despreciar la posibilidad de reelaboración:

Demasiada presión de la agenda que conduce a cometer errores debido a las prisas.Ausencia de pruebas del sistema y evaluación adecuadas al final de la fase de construcción.Error al evaluar el considerable trabajo que aún queda en la fase de transición.La disposición de considerar la reelaboración como mala, como admisión de la incompetencia del proyecto.


207 de 297

Fase de transición

Planificación:Aspectos conocidos.Aspectos desconocidos.Versión beta.Resultados.Motivos que propician despreciar la posibilidad de reelaboración.


208 de 297

Fase de Transición

Asignación de personal:Necesidades:

Necesidades de personal similares a las de la fase de construcción pero con un énfasis diferente.

Características:La respuesta a los resultados de las pruebas beta o de aceptación puede requerir personal más orientado al servicio que al desarrollo. 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ó. Considerar el beneficio de una mejora requiere no sólo expertos en el sistema, sino en la naturaleza de la aplicación.


209 de 297

Fase de Transición

Evaluación:Alcance:

Sólo es necesario evaluar los problemas que surjanCriterios:

¿Han cubierto los usuarios beta las funciones claves?¿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.¿Tiene el material de usuario una calidad aceptable?¿Está listo el material de cursos necesario, incluyendo la guía del profesor, en su caso?¿Parecen los usuarios y clientes satisfechos con el producto?


210 de 297

Fase de Transición

Actividades en cada iteración:Se realizan cuatro grupos se actividades en paralelo:

Planificación.Los cinco flujos de trabajo fundamentales.Evaluación.Análisis más profundo del negocio.


211 de 297


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.


212 de 297

Fase de Transición

Qué se hace en esta fase: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.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.Actuar a partir de la información recogida en las instalaciones de pruebas.Adaptar el producto corregido a las circunstancias de los usuarios.Completar los artefactos del proyecto.Determinar cuándo se acaba el proyecto.


213 de 297

Fase de Transición

Qué se hace en esta fase:Preparación de la versión beta:

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


214 de 297

Fase de Transición

Qué se hace en esta fase:Preparación de la versión beta.Instalación de la versión beta:

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:

Cómo instalar el software de pruebas.Cómo operar con él.En qué aspectos y problemas deben centrarse los clientes y los usuarios beta.Cómo informar de los fallos y problemas encontrados.

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.


215 de 297

Fase de Transición

Qué se hace en esta fase:Preparación de la versión beta.Instalación de la versión beta:

En las pruebas de aceptación por lo general estarán presentes miembros del personal del proyecto. Habrá un documento formal de pruebas de aceptación aunque serácomplementado mediante comunicaciones informales. 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.


216 de 297

Reacción a los resultados de las pruebasQué se hace en esta fase:

Preparación de la versión beta.Instalación de la versión beta.Reacción a los resultados de las pruebas:

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.

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?


217 de 297

Fase de Transición

Qué se hace en esta fase:Preparación de la versión beta.Instalación de la versión beta.Reacción a los resultados de las pruebas.

Fallos:• ¿Puede ser corregido sin que afecte a la arquitectura o el

diseño?• ¿Ha sido corregido sin introducir nuevos defectos?

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.


218 de 297

Fase de Transición


Fallos.Problemas más amplios:

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


219 de 297

Fase de Transición


Fallos.Problemas más amplios:

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


220 de 297

Fase de TransiciónQué se hace en esta fase:

Preparación de la versión beta.Instalación de la versión beta.Reacción a los resultados de las pruebas.Adaptación a entornos variados:

Relación de mercado: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.

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.


221 de 297

Fase de Transición

Qué se hace en esta fase:Preparación de la versión beta.Instalación de la versión beta.Reacción a los resultados de las pruebas.Adaptación a entornos variados:

Relación de mercado: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.


222 de 297

Fase de Transición


Relación de mercado.Relación de cliente individual:

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.


223 de 297

Fase de Transición



Diferencias respecto a la relación anterior:• 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.


224 de 297

Fase de Transición



Diferencias respecto a la relación anterior:• 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.


225 de 297

Fase de Transición



Diferencias respecto a la relación anterior:• 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.


226 de 297

Fase de Transición


Relación de mercado.Relación de cliente individual.Migración y conversión de datos:

Cuando hay un sistema ya existente que va a ser reemplazado.


227 de 297

Fase de Transición



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.


228 de 297


Preparación de la versión beta.Instalación de la versión beta.Reacción a los resultados de las pruebas.Adaptación a entornos variados:


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.


229 de 297

Fase de Transición

Qué se hace en esta fase:Preparación de la versión beta.Instalación de la versión beta.Reacción a los resultados de las pruebas.Adaptación a entornos variados:Finalización de los artefactos:

Correcciones necesarias.Al final de esta fase se habrá verificado a través del uso real que todos los artefactos son consistentes unos con otros.


230 de 297


Preparación de la versión beta.Instalación de la versión beta.Reacción a los resultados de las pruebas.Adaptación a entornos variados:Finalización de los artefactos.¿Cuándo acaba el proyecto?

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.

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. Esta fase acaba cuando el proyecto transfiera la responsabilidaddel mantenimiento continuado a una organización de apoyo.


231 de 297


Preparación de la versión beta.Instalación de la versión beta.Reacción a los resultados de las pruebas.Adaptación a entornos variados:Finalización de los artefactos.¿Cuándo acaba el proyecto?

Para productos contratados por un cliente, se determina que éste estará satisfecho una vez el sistema pase las pruebas de aceptación.

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


232 de 297

Fase de Transición

Qué se hace en esta fase:Preparación de la versión beta.Instalación de la versión beta.Reacción a los resultados de las pruebas.Adaptación a entornos variados:Finalización de los artefactos.¿Cuándo acaba el proyecto?


233 de 297

Finalización del análisis de negocioAnálisis del negocio:

Situación:Hay más información disponible sobre la que juzgar el acierto del análisis de negocio.

Control del progreso:Se compara el progreso real en la fase frente a la agenda, esfuerzo y coste planificado para la fase.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:

Ver si el proyecto ha alcanzado los objetivos planeados.Determinar las razones por las que no lo ha hecho, si este es elcaso.Añadir las métricas del proyecto a la Base de Datos de métricas de la empresa para su uso futuro.


234 de 297

Finalización del análisis de negocioAnálisis del negocio:

Situación.Control del progreso.Revisión del plan de negocio:

Este plan prevé si el proyecto tendrá éxito económico. 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.

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.


235 de 297

Finalización del análisis de negocio

Análisis del negocio:Situación.Control del progreso.Revisión del plan de negocio.Finalización:

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.Se reunirán todos los datos y se formará un grupo para revisar el plan.


236 de 297

Finalización del análisis de negocio

Análisis del negocio:Situación.Control del progreso.Revisión del plan de negocio.Finalización.


237 de 297

Fase de TransiciónEvaluación:

Personal:Se reúne un pequeño grupo para evaluar esta fase y analizar el ciclo de desarrollo en su totalidad.

Hallazgos:Pueden ser de utilidad para futuros ciclos de desarrollo.Tipos:

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.


238 de 297

Fase de Transición

Evaluación:Personal.Hallazgos:

Tipos: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.


239 de 297

Fase de Transición


Tipos:Evaluación de las iteraciones y de las fases.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.


240 de 297

Fase de Transición


Tipos:Evaluación de las iteraciones y de las fases.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?


241 de 297

Fase de Transición


Tipos:Evaluación de las iteraciones y de las fases.Valoración del proyecto.


242 de 297

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”


243 de 297

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.



de usuarios beta

CSI 6.1Adaptar el manual de

usuario para usuarios finales

Inicio InicioFin Fin CSI 7.1

Completar el esquema de formación de

usuarios finales



Inicio Inicio


CSI 9.1Aprobación

de la versión operativa inicial del sistema

Fin Inicio

IAS 1.1

Definición del plan de

implantación

IAS 2.3

Preparación de la formación de usuarios finales

IAS 2.4

Seguimiento de la formación de usuarios finales IAS 8.1

Identificación de niveles de

servicio

IAS 8.2

Descripción de servicios

IAS 8.3

Determinación del acuerdo de

servicio

IAS 1.2

Especificación del equipo de implantación

IAS 2.1Plan de

formación del equipo de

implantación

IAS 2.2

Formación del equipo de

implantación

IAS 3.1

Preparación de la

instalación IAS 3.2

Instalación del producto software

IAS 4.1

Migración y carga inicial

de datos

IAS 5.2

Realización de pruebas de implantación

IAS 5.3

Evalluación de pruebas de implantación

IAS 5.1

Preparación pruebas de

implantación

IAS 6.1Preparación

para las pruebas de aceptación

IAS 6.2Realización

de las pruebas de aceptación

IAS 6.3


de aceptación

IAS 9.1Convocatoria

de presentación del sistema

IAS 9.2

Aprobación del sistema

IAS 10.1

Preparación del entorno de

producción

IAS 7.1

Preparación de la infraestructura de

mantenimiento

IAS 7.2

Formalización del plan de

mantenimiento

IAS 10.2

Activación del sistema en producción

Inic

io

Ini

cio

Fin

F

in



CSI 6.1 Fin-Inicio

Producto software

IAS 5.1 Fin-Inicio

Pruebas de implantación

Inicio Inicio

Fin FinFin Inicio Fin Inicio

Fin Inicio


Fin Inicio

Inicio Inicio

Fin FinFin Inicio

Inicio Inicio

Fin Fin

IAS 4.1 Fin-Inicio

Producto listo, datos cargados

Fin Inicio

Fin Inicio

Fin Inicio

Inicio Inicio

Fin Fin


Inicio Inicio

Fin FinFin Inicio

Fin Inicio

IAS 5.3,6.3,8.3 Fin-Inicio

Sistema desarrollado

Fin Inicio Fin Inicio Fin Inicio



ASI-CAL 4.1



del diseño



DSI-CAL 2.2


Inicio Inicio

Fin Fin



DSI-CAL 3.2


Inicio Inicio

Fin Fin



Inicio Inicio

Fin Fin

CSI-CAL 2.1


CSI-CAL 2.2


CSI-CAL 2.3


sistema

CSI-CAL 1.1


construcción

Fin InicioInicio Inicio

Fin Fin

Inicio Inicio

Fin Fin

CSI-CAL 3.1


usuario

CSI-CAL 4.1


formación

Inicio Inicio

Fin Fin

CSI 6.1 Inicio-Inicio, Fin-FinManual de usuario



CSI-CAL 5.1Registro de la aprobación del

sistema de información

IAS-CAL 1.1Revisión del

plan de implantación del sistema

IAS-CAL 2.1Revisión de la realización de

pruebas de implantación

IAS-CAL 2.2Registro de la aceptación o rechazo de las pruebas

de implantación

IAS-CAL 3.1Revisión de la realización de las pruebas

de aceptación del sistema



IAS-CAL 4.1

Revisión del plan de

mantenimiento

IAS-CAL 5.1Registro de

aprobación de la implantación del

sistema

GC 1.1Identificación y registro de productos

generados en esta fase


productos globales

Inicio Inicio

Fin Fin

Fin Inicio

CSI 9.1 Fin-Inicio

Versión operativa

IAS 1.1,1.2, CSI-CAL 5.1 Inicio-Inicio, Fin-Fin

Implantación

Inicio Inicio

Fin Fin

Fin Inicio

IAS 5.3 Inicio-Inicio, Fin-FinPruebas de implantación

IAS 6.3 Inicio-Inicio, Fin-FinPruebas de aceptación


IAS 7.2 Inicio-Inicio, Fin-FinPlan de mantenimiento

Fin Inicio

IAS 9.2 Inicio-Inicio, Fin-FinSistema aprobado



GPS 6.1


GPS 6.2


GPS 6.3


solución

GPS 7.1



para el cambio

GPS 8.2


GPS 9.1





GPS 11.3


GPS 12.1

Reunión interna de

seguimiento

GPS 3.1 Fin-Inicio

Seguimiento

Inicio Inicio

Fin Fin

Inicio Inicio

Fin Fin

Inicio Inicio

Fin Fin

Inicio Inicio

Fin Fin

Fin Inicio

Inicio Inicio

Fin Fin

Fin Inicio


Fin Inicio

Fin Inicio


Cambio

GPS 1.1



GPS 3.1




tareas al equipo

GPS 4.2



impacto

GPS 4.3


GPS 10.1


finalizada

Fin Inicio




Fin Inicio

Fin Inicio

GPS 13.1

Aceptación interna

Inicio Inicio

Fin Fin

GPF 1.1Identificación y registro de

productos globales


productos globales

CSI-SEG 3.1


seguridad


Formación usuarios finales CSI-SEG 4.1Clasificación y catalogación


CSI



DSI

CSI-SEG 2.1


de seguridad

IAS-SEG 1.1Estudio de la

seguridad requerida

para el IAS

IAS-SEG 2.1Medidas de

seguridad del entorno de operación

IAS-SEG 3.1


de seguridad de la

implantación

IAS-SEG 4.1Clasificación y catalogación


IAS


seguridad en el entorno de producción

IAS 1.1 Inicio-Inicio, Fin-FinPlan de implantación

IAS 3.1 Inicio-Inicio, Fin-FinInstalación del software


IAS 10.2 Fin-Inicio

IAS completado


247 de 297

Mantenimiento

MSI-CAL 1.1

Revisión del mantenimiento

MSI-CAL 2.1Revisión del

plan de pruebas de regresión

MSI-CAL 3.1

Evaluación de pruebas de regresión

MSI-SEG 3.1Clasificación y

catalogación de los productos

del MSI

MSI-SEG 1.1Estudio de seguridad

requerida en el MSI

MSI-SEG 2.1

Estudio de la petición

MSI-SEG 2.2Cambios en

los mecanismos de seguridad

MSI-GC 1.1

Registro del cambio

MSI-GC 1.2Registro de la nueva versión

de un producto

MSI-GC 1.3

Registro de la nueva versión

del sistema

GPS 1.1



GPS 3.1




tareas al equipo

GPS 4.2



impacto

GPS 4.3


GPS 10.1


finalizada

Fin Inicio




Fin Inicio

Fin Inicio

GPS 13.1

Aceptación interna

Inicio Inicio

Fin Fin

MSI 4.3 Fin-Inicio

Corrección

MSI 3.3 Inicio-Inicio, Fin-Fin

Pruebas de regresión



Inicio Inicio

Fin Fin


Propuesta de solución

Inicio Inicio

Fin Fin

MSI 4.3 Fin-Inicio

Fin del MSI


Modificación


Producto modificado



GPS 6.1


GPS 6.2


GPS 6.3


solución

GPS 7.1



para el cambio

GPS 8.2


GPS 9.1





GPS 11.3


GPS 12.1

Reunión interna de

seguimiento

GPF 1.1Cierre del proyecto,

inclusión en el histórico de proyectos

GPF 1.2Archivo de la

documentación de gestión del

proyecto

GPS 3.1 Fin-Inicio

Seguimiento

Inicio Inicio

Fin Fin

Inicio Inicio

Fin Fin

Inicio Inicio

Fin Fin

Inicio Inicio

Fin Fin

Fin Inicio

Inicio Inicio

Fin Fin

Fin Inicio


Fin Inicio

Fin Inicio


Cambio


251 de 297

Resumen


252 de 297

Aspectos relativos a la metodología

Manejo de la complejidad: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.El desarrollo guiado por la arquitectura, el esqueleto de los elementos estructurales y del comportamiento que permite que el sistema evolucione sin sobresaltos.El desarrollo a partir del uso de bloques de construcción y componentes, facilitando la reutilización.El desarrollo llevado a cabo a través de iteraciones y construcciones dentro de las iteraciones, lo que resulta un crecimiento incremental del producto.


253 de 297

Aspectos relativos a la metodología

Manejo de la complejidad:El desarrollo con riesgos controlados.El desarrollo visualizado y registrado usando UML.El desarrollo evaluado en los hitos.


254 de 297

Cuestiones importantes

Obtención correcta de requisitos:A través del modelado de casos de uso, análisis, diseño e implementación

Obtención correcta de la arquitectura: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: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.


255 de 297

Cuestiones importantes

Comunicación con UML: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: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:Identificarlos (críticos, significativos, rutinarios), ponerlos en una lista y mitigarlos antes de que se manifiesten.


256 de 297

Visión Global de las Iteraciones

Iteración Fase Preliminar

PSI 1.1Completa

PSI 1.2Completa

PSI 1.3Completa

PSI-SEG 1.1Completa

PSI-SEG 1.2Completa

Fin Inicio Fin Inicio Fin Inicio Fin Inicio

Iteración Fase de Inicio

PSI 2.1Descripción de

procesos afectados, completa

PSI 2.2

Catálogo de usuarios, completa aunque el se añaden usuarios a lo largo del proyecto.

PSI 2.3Primera versión

del plan de trabajo, esbozo

Fin Inicio

Inicio

Inicio

PSI 3.1

Información relevante, completa

Inicio

Inicio

PSI 3.2

Requisitos generales, completa

Fin Inicio

EVS 3.1

Catálogo de normas, se intenta completar

aunque puede que sea necesario hacerlo en la

fase posterior

Inicio Inicio

PSI 4.1

Modelo de Procesos, completo

PSI 5.1Identificación de sistemas afectados, completa

Inicio Inicio

Inic

ioIn

icio

PSI 4.2Necesidades de

información, requisitos funcionales, diagrama de clases, completa

PSI 4.3

Requisitos de los procesos,

completa

EVS 1.3Usuarios y

plan de trabajo de esta fase

EVS 2.1

Descripción de sistemas actuales

completa si se tiene en cuenta la arquitectura, si no se completa en la

siguiente fase

Fin Fin

Fin InicioFin InicioInicio Inicio

Fin Fin

Inicio Inicio

Fin Fin

EVS 3.3

Catalogación de requisitos

EVS 3.2

Identificación de requisitos

EVS 2.4Diagnóstico

de la situación actual,

completa

EVS 2.3

Descripción lógica de los sistemas

actuales, modelo físico, diagrama de clases, completa

EVS 2.2Participantes del estudio de

la situación actual

Inic

io

F

in

Inicio FinInicio Fin Inicio Fin

EVS 1.2

Dependencias con otros proyectos,

visión global del alcance del sistema

Inic

io

Ini

cio

Inicio Inicio

Fin

F

in

PSI 5.2Descripción de sistemas afectados, completa

PSI 5.3Valoración de

sistemas afectados, completa

PSI 6.1Sistemas que se conservan

y mejoras propuestas,

completa

PSI 3.2 Inicio-Inicio

Modelo de negocio

PSI 4.3 Fin-Inicio

Modelo de negocio

Inicio Inicio

Fin Fin

Inicio Inicio

Fin Fin

Fin Inicio

Fin

Inic

io

Inic

io

Inic

io

Fin

F

in

Inic

io

F

in

Inic

io

Inic

io

Fin

F

in

Inic

io

Fin

Inic

io

Ini

cio

Fin

F

in


diseño, a partir de las de análisis


diseño adicionales, diseño de

casos de uso

DSI 4.2Asociaciones

y agregaciones de las clases identificadas

DSI 3.3Diseño de interfaz de

usuario, caso muy concreto

DSI 3.4Descripción de

casos de uso en términos de

subsistemas e interfaces, alto

nivel

DSI 3.2Interacción de

clases anteriormente identificadas, realización de casos de uso

DSI 4.3Atributos de las clases

identificadas, caso concreto

DSI 4.4

Operaciones de las clases, caso concreto

DSI 4.5

Jerarquía del modelo de

clases

DSI 4.6Pseudocódigo

de algún método concreto

DSI 6.1

Especificación a alto nivel del modelo físico de datos si mejora la

comprensión del sistema

DSI 6.4

Distribución de los datos a muy alto nivel,

modelo de datos no

optimizado.

DSI 7.2Análisis de

consistencia de los

productos obtenidos

DSI 8.1

Especificación del entorno tecnológico necesaria

para la realización del

prototipo

DSI 8.2

Definición de componentes y subsistemas

necesarios para el

prototipo.

DSI 10.1Especificación del entorno de pruebas para el prototipo

DSI 10.2

Niveles de prueba

DSI 10.3

Plan de pruebas

CSI 1.2

Preparación del entorno de construcción

para el prototipo

CSI 2.1

Generación de código

CSI 3.1Preparación


CSI 3.2Realización y evaluación de

pruebas unitarias

CSI 4.1Preparación


CSI 4.2


integración

CSI 5.1Preparación


sistema

CSI 5.2


ASI 9.3 Fin-Inicio

Modelo de clases

Inicio

Inicio

Inicio Inicio

Fin Fin

Inicio Inicio

Fin Fin

Inicio Inicio

Fin Fin

ASI 3.2 Fin-Inicio

División en subsistemas

CSI 4.3


CSI 5.3


sistema

Fin

Fin

Fin Fin


Fin Fin

Inicio Inicio

Fin Fin

Inicio Inicio

Fin Fin

Inicio Inicio

Fin Fin

Fin Inicio

DSI 3.3,3.4,6.4 Fin-Inicio

Productos obtenidos

Fin Inicio

Fin Inicio Inicio InicioInicio Inicio

Fin Fin

Inicio Inicio

Fin Fin

Inic

io

Inic

io

Fin

F

in

Inic

io

F

in

Inic

io

F

in

Fin

Ini

cio

Fin Inicio

Fin Inicio

Fin Inicio

Fin Inicio

Fin Inicio

Inicio Inicio

Fin Fin

Inicio Inicio

Fin Fin

CSI 2.1 Inicio-Inicio


CSI 2.1 Fin-Inicio


CSI 2.1 Fin-Inicio


Iteración Fase de Elaboración

Inic

io

Ini

cio

Fin

F

in

ASI 2.4


anteriores

ASI 3.1Descripción

de subsistemas e

interfaces

ASI 4.1


análisis

ASI 4.2Análisis de



alguna pantalla

necesaria para la

comprensión de un caso de uso concreto

ASI 3.2

Integración de subsistemas

ASI 5.1



de agregaciones

y asociaciones

ASI 5.3



y especificación

de los diálogos

considerados críticos

ASI 8.5Formatos de impresión, caso muy concreto

ASI 9.1Verificación

de la arquitectura del sistema

ASI 9.2Análisis de

consistencia muy exhaustivo de la

arquitectura

ASI 2.3 Inicio-Inicio, Fin-FinCasos de uso

arquitectónicamente significativos

Inicio

Inicio

Fin

Fin

Inicio

Inicio

Fin

Fin

Inicio InicioFinFin

Inicio

Inicio

Fin

Fin

Inicio Inicio

Fin Fin

Inicio Inicio

Fin Fin

Inicio Inicio

Fin Fin

Inicio Inicio

Fin Fin


Fin I

nicio

Fin Inicio

Fin Inicio

Fin

Ini

cio

Fin Inicio



ASI 4.2 Inicio-Inicio, Fin-FinRealización de casos de

uso

Fin Inicio

Inic

io

Ini

cio

Fin

F

in


Inic

io

F

in


Inicio

In

icio

Fin

Fin

Inic

io

Ini

cio

Fin

F

in

Inicio Inicio

Fin

Fin


Inic

io

Ini

cio

Fin

F

in

Fin Inicio

EVS-CAL 1.2Determinación

de sistemas objeto del

aseguramiento de la calidad

EVS-CAL 1.3Identificación

de propiedades de calidad

EVS-CAL 2.1Necesidad del

plan de aseguramiento de la calidad de cada alternativa

EVS-CAL 2.2Alcance del plan

de aseguramiento de la calidad de cada alternativa

EVS-CAL 2.3Análisis de

consistencia de la

arquitecturaEVS-CAL 3.1

Ajuste del plan a la solución

selecionada

EVS-CAL 1.1Se constituye el

equipo de calidad y el plan

de acción

EVS-CAL 3.2

Aprobación del plan de la

solución



EVS 6.2 Fin-Inicio

Solución propuesta

Fin Inicio

Inicio Inicio

Fin Fin



Inicio Inicio

Fin Fin

Inicio Inicio

Fin Fin


Fin InicioFin Inicio

EVS 6.3 Fin-Inicio

Solución aprobada

ASI-CAL 1.1Definición

detallada del plan de

aseguramiento de la calidad de

la solución

ASI-CAL 2.1

Actividades y tareas del

plan

ASI-CAL 3.1


ASI-CAL 3.2



del diseño

DSI-CAL 1.2

Aceptación de la arquitectura

del sistema



DSI-CAL 2.2


CSI-CAL 2.1


CSI-CAL 2.2


CSI-CAL 2.3


sistema




la arquitectura

DSI 7.3 Fin-Inicio

Aceptación del diseño


Pruebas

EVS-CAL 3.1 Fin-Inicio

Plan para la solución

Inicio Inicio

Fin Fin

Inicio Inicio

Inicio

Inicio



Inicio Inicio

Fin Fin

ASI-CAL 4.1


ASI 10.3 Fin-Inicio

Plan de pruebas

Fin Inicio

Fin Inicio


Pruebas

Inicio Inicio

Fin Fin

CSI-CAL 1.1


construcción


Código generado

Fin Inicio


Pruebas unitarias




Pruebas del sistema

Inicio Inicio

Fin Fin

Inicio Inicio

Fin Fin

Fin Inicio

EVS-GC 1.1

Requisitos de la gestión de la configuración

EVS-GC 2.1

Plan de gestión de la configuración

EVS-GC 2.2Entorno

tecnológico para la

gestión de la configuración



esta fase


productos globales

GPI 1.1

Estimación del esfuerzo, identificación de elementos a desarrollar

GPI 1.2

Cálculo del esfuerzo

GPI 2.1

Selección de la estrategia de desarrollo

GPI 2.2Adaptación de

la metodología al proyecto

GPI 2.3

Calendario de hitos y

entregas

GPI 2.4

Planificación general del proyecto

GPI 2.5

Aceptación de la

planificación

GPS 1.1



GPS 3.1




tareas al equipo

GPS 4.2



impacto

GPS 4.3


GPS 10.1


finalizada

GPS 11.1Actualización

de la planificación

de tareas



GPS 11.3


GPS 12.1

Reunión interna de

seguimiento

PSI 9.2, EVS 3.2 Inicio-Inicio, Fin-Fin

Arquitectura y requisitos

EVS 6.2 Fin-Inicio

Solución propuesta

Inicio InicioInicio Inicio

Fin Fin

EVS 6.2 Fin-Inicio

Solución propuesta

Inicio Inicio

Fin Fin

Fin Inicio Fin Inicio Fin InicioInicio Inicio

Fin Fin

Fin Inicio

GPI 2.4 Inicio-Inicio, Fin-Fin

Planificación del proyecto

Fin Inicio




Fin Inicio

Fin Inicio

Fin Fin

Inicio Inicio



Inicio Inicio

Fin Fin

Inicio Inicio

Fin Fin

Inicio Inicio

Fin Fin

Iteración Fase de Construcción

ASI 1.1Procesos y

requisitos de la solución, glosario,

modelo de negocio, se completa la labor de la fase anterior

ASI 8.1

Definición final de los principios

generales de interfaz de

usuario

ASI 1.3

Catálogo de normas

Inicio Inicio

ASI 2.3

Análisis riguroso de los casos de uso de ASI 2.2

ASI 2.2

Especificación de casos de uso

restantes

ASI 2.1Modelo de

casos de uso, se completa si es necesario

Inicio Inicio

Fin Fin

Inicio Inicio

Fin Fin

ASI 2.4


anteriores

ASI 3.1Introducción de

actualizaciones y mejoras en los subsistemas

ASI 4.1


análisis

ASI 4.2Análisis de



formatos individuales de pantalla

ASI 3.2Revisar

consistencia si se introdujeron

modificaciones en la tarea anterior

ASI 5.1


ASI 5.2

Identificación de agregaciones y asociaciones, revisión de la

especificación de subisistemas para

su posible optimización

ASI 5.3


ASI 8.4Especificación del comportamiento dinámico de las

interfaces

ASI 8.5

Especificación de formatos

de impresión,

ASI 9.1

Verificación de todos los

modelos

ASI 9.2

Análisis de consistencia de

todos los modelos

Inicio

Inicio

Fin

Fin

Inicio

Inicio

Fin

Fin

Inicio InicioFinFin

Inicio

Inicio

Fin

Fin

Inicio Inicio

Fin Fin

Inicio Inicio

Fin Fin

Inicio Inicio

Fin Fin

Inicio Inicio

Fin Fin


Fin I

nicio

Fin Inicio

Fin Inicio

Fin

Ini

cio

Fin Inicio



Inicio Inicio

Fin Fin

Inicio Inicio

Fin Fin


Casos de uso restantes

ASI 4.2 Inicio-Inicio, Fin-FinRealización de casos de uso

Fin Inicio

Inic

io

Ini

cio

Fin

F

in

Inic

ioFi

n

Inicio Inicio

Fin Fin

Inicio

In

icio

Fin

Fin

Inic

io

Inic

io

Fin

Fi

n

DSI 7.1

Verificación del diseño

(Calidad), modelo de datos

optimizado

DSI 7.2

Análisis de consistencia del diseño

DSI 7.3Aceptación del análisis realizado

anteriormente



de usuarios beta

DSI 8.2Definición de

componentes y subsistemas de implementación como traducción directa del diseño

DSI 8.3

Especificación en psedocódigo de componentes

DSI 1.3,1.4 Inicio-Inicio,DSI 1.6,3.3,3.4,6.4 Fin-Inicio

Productos de diseño

Inicio Inicio

Fin Fin

Fin Inicio

DSI 1.7 Fin-Inicio


Inicio Inicio

Fin

Fin Inicio InicioFin Fin



DSI 11.2

Requisitos de implantación

DSI 12.1

Aprobación del diseño del

sistema


Fin Inicio

DSI 7.3,8.4,9.4,10.3 Fin-InicioProductos de diseño

DSI 8.4

Especificación del modelo físico de

datos

Inicio Inicio

Fin Fin

DSI 10.2

Especificación de los niveles

de prueba

DSI 10.3

Especificación del plan de

pruebas

CSI 3.1Preparación


CS 4.1Preparación


CSI 5.1Preparación


sistema

CSI 5.2


CSI 3.2Realización y evaluación de las pruebas

unitariasCSI 4.2


integración

CSI 4.3


CSI 5.3


sistema


Pruebas

Fin Inicio

Fin Inicio

Fin Inicio

Fin Inicio

Fin Inicio

Fin Inicio

Inicio Inicio

Fin Fin

Inicio Inicio

Fin Fin


Código generado


Código generado

CSI 2.2 Fin-Inicio

Código generado

CSI 1.1Implantación de la BD o el sistema de

ficheros

Fin Inicio

CSI 2.1Generación del código de los componentes

de DSI 8.2

CSI 2.2Generación de código de los

procedimientos de operación y

seguridad

CSI 6.1

Completar el manual de

usuarios beta

Inicio Inicio

Fin Fin

DSI 1.7 Fin-Inicio


Inicio Inicio

Fin Fin


DSI 9.1Especificación del entorno de

migración y carga inicial

DSI 9.2Diseño de

procedimientos de migración y

carga inicial

DSI 9.3Diseño de

componentes de migración y carga inicial

DSI 9.4Revisión del

plan de migración y carga inicial

Inicio Inicio

Fin Fin

Inicio Inicio

Fin Fin

Inicio Inicio

Fin Fin

CSI 8.1Preparación

del entorno de migración y carga inicial

de datos

CSI 8.2

Generación de código de los

componentes y procedimientos

de la migración y carga inicial de

datos

CSI 8.3

Realización y evaluación de las pruebas de migración y carga inicial

de datos

CSI 7.1

Primera versión del esquema de

formación de usuarios finales



Inici

o

In

icio

Fin

Fin

Inicio Inicio


Inicio Inicio

Fin Fin


Fin Inicio



ASI-CAL 3.1


ASI-CAL 3.2



del diseño

DSI-CAL 1.2Aceptación de la arquitectura del sistema, incluida

la interfaz de usuario y el

modelo de datos optimizado



DSI-CAL 2.2





la arquitectura

DSI 7.3 Fin-Inicio

Aceptación del diseñoDSI 10.2 Inicio-Inicio, Fin-Fin

Pruebas

Inicio Inicio



Inicio Inicio

Fin Fin

ASI-CAL 4.1


ASI 10.3 Fin-Inicio

Plan de pruebas


DSI 10.3, DSI-CAL 2.1 Inicio-Inicio, Fin-Fin

PruebasCSI-CAL 2.1


CSI-CAL 2.2


CSI-CAL 2.3


sistema

CSI-CAL 1.1


construcción


Código generado

Fin Inicio


Pruebas unitarias




Pruebas del sistema

Inicio Inicio

Fin Fin

Inicio Inicio

Fin Fin



esta fase


productos globales

ASI-CAL 5.1


del ASI



DSI-CAL 3.2


DSI-CAL 4.1


del DSI

CSI-CAL 3.1


usuario

CSI-CAL 4.1


formación

ASI 11.1 Fin-Inicio

ASI aprobado


Inicio Inicio

Fin Fin




Implantación

Inicio Inicio

Fin FinFin Inicio

DSI 12.1 Fin-Inicio

DSI aprobado

Fin Inicio

Inicio Inicio

Fin Fin

CSI 6.1, CSI-CAL 2.3 Inicio-Inicio, Fin-FinManual de usuario



GPS 1.1



GPS 3.1




tareas al equipo

GPS 4.2

Propuesta de solución a la

incidencia GPS 4.1Gestión de incidencias, análisis del

impacto

GPS 4.3


GPS 10.1


finalizada

Fin Inicio



Fin Inicio

GPS 13.1

Aceptación interna

Inicio Inicio

Fin Fin

Fin Inicio

Fin Inicio



GPS 6.1


GPS 6.2


GPS 6.3


solución

GPS 7.1



para el cambio

GPS 8.2


GPS 9.1





GPS 11.3


GPS 12.1

Reunión interna de

seguimiento

GPS 3.1 Fin-Inicio

Seguimiento

Inicio Inicio

Fin Fin

Inicio Inicio

Fin Fin

Inicio Inicio

Fin Fin

Inicio Inicio

Fin Fin

Fin Inicio

Inicio Inicio

Fin Fin

Fin Inicio


Fin Inicio

Fin Inicio


Cambio

ASI-SEG 2.1Estudio de funciones y mecanismos de seguridad necesarios

ASI-SEG 3.1Inclusión de criterios de

seguridad en las pruebas




Pruebas

Inicio Inicio

Fin Fin

ASI-SEG 4.1Clasificación y catalogación


ASI

ASI 10.3 Fin-Inicio

Fin del ASI

DSI-SEG 3.1Requisitos de seguridad del

entorno de construcción

CSI-SEG 4.1Clasificación y catalogación


CSI

CSI 5.3 Fin-Inicio

Fin del CSI



DSI

DSI 10.3 Fin-Inicio

Fin del DSI

CSI-SEG 3.1


seguridad


Entorno de construcción



Inicio Inicio

Fin Fin

DSI-SEG 4.1

Diseño de pruebas de seguridad

CSI-SEG 2.1


de seguridad

DSI 1.7, ASI-SEG 4.1,2.1 Inicio-Inicio, Fin-Fin

Pruebas CSI 3.2,4.2,5.2 Inicio-Inicio, Fin-Fin

Pruebas

Inicio Inicio

Fin Fin

Iteración Fase de Transición



de usuarios beta

CSI 6.1Adaptar el manual de

usuario para usuarios finales

Inicio InicioFin Fin CSI 7.1

Completar el esquema de formación de

usuarios finales



Inicio Inicio


CSI 9.1Aprobación

de la versión operativa inicial del sistema

Fin Inicio

IAS 1.1

Definición del plan de

implantación

IAS 2.3

Preparación de la formación de usuarios finales

IAS 2.4

Seguimiento de la formación de usuarios finales IAS 8.1

Identificación de niveles de

servicio

IAS 8.2

Descripción de servicios

IAS 8.3

Determinación del acuerdo de

servicio

IAS 1.2

Especificación del equipo de implantación

IAS 2.1Plan de

formación del equipo de

implantación

IAS 2.2

Formación del equipo de

implantación

IAS 3.1

Preparación de la

instalación IAS 3.2

Instalación del producto software

IAS 4.1

Migración y carga inicial

de datos

IAS 5.2

Realización de pruebas de implantación

IAS 5.3

Evalluación de pruebas de implantación

IAS 5.1

Preparación pruebas de

implantación

IAS 6.1Preparación

para las pruebas de aceptación

IAS 6.2Realización

de las pruebas de aceptación

IAS 6.3


de aceptación

IAS 9.1Convocatoria

de presentación del sistema

IAS 9.2

Aprobación del sistema

IAS 10.1

Preparación del entorno de

producción

IAS 7.1

Preparación de la infraestructura de

mantenimiento

IAS 7.2

Formalización del plan de

mantenimiento

IAS 10.2

Activación del sistema en producción

Inic

io

Ini

cio

Fin

F

in



CSI 6.1 Fin-Inicio

Producto software

IAS 5.1 Fin-Inicio

Pruebas de implantación

Inicio Inicio

Fin FinFin Inicio Fin Inicio

Fin Inicio


Fin Inicio

Inicio Inicio

Fin FinFin Inicio

Inicio Inicio

Fin Fin

IAS 4.1 Fin-Inicio

Producto listo, datos cargados

Fin Inicio

Fin Inicio

Fin Inicio

Inicio Inicio

Fin Fin


Inicio Inicio

Fin FinFin Inicio

Fin Inicio

IAS 5.3,6.3,8.3 Fin-Inicio

Sistema desarrollado




ASI-CAL 4.1



del diseño



DSI-CAL 2.2


Inicio Inicio

Fin Fin



DSI-CAL 3.2


Inicio Inicio

Fin Fin



Inicio Inicio

Fin Fin

CSI-CAL 2.1


CSI-CAL 2.2


CSI-CAL 2.3


sistema

CSI-CAL 1.1


construcción

Fin InicioInicio Inicio

Fin Fin

Inicio Inicio

Fin Fin

CSI-CAL 3.1


usuario

CSI-CAL 4.1


formación

Inicio Inicio

Fin Fin

CSI 6.1 Inicio-Inicio, Fin-FinManual de usuario



CSI-CAL 5.1Registro de la aprobación del

sistema de información

IAS-CAL 1.1Revisión del

plan de implantación del sistema

IAS-CAL 2.1Revisión de la realización de

pruebas de implantación


de implantación

IAS-CAL 3.1Revisión de la realización de las pruebas




IAS-CAL 4.1

Revisión del plan de

mantenimiento

IAS-CAL 5.1Registro de

aprobación de la implantación del

sistema

GC 1.1Identificación y registro de productos

generados en esta fase


productos globales

Inicio Inicio

Fin Fin

Fin Inicio

CSI 9.1 Fin-Inicio

Versión operativa

IAS 1.1,1.2, CSI-CAL 5.1 Inicio-Inicio, Fin-Fin

Implantación

Inicio Inicio

Fin Fin

Fin Inicio


IAS 6.3 Inicio-Inicio, Fin-FinPruebas de aceptación


IAS 7.2 Inicio-Inicio, Fin-FinPlan de mantenimiento

Fin Inicio

IAS 9.2 Inicio-Inicio, Fin-FinSistema aprobado



GPS 6.1


GPS 6.2


GPS 6.3


solución

GPS 7.1



para el cambio

GPS 8.2


GPS 9.1





GPS 11.3


GPS 12.1

Reunión interna de

seguimiento

GPS 3.1 Fin-Inicio

Seguimiento

Inicio Inicio

Fin Fin

Inicio Inicio

Fin Fin

Inicio Inicio

Fin Fin

Inicio Inicio

Fin Fin

Fin Inicio

Inicio Inicio

Fin Fin

Fin Inicio


Fin Inicio

Fin Inicio


Cambio

GPS 1.1



GPS 3.1




tareas al equipo

GPS 4.2



impacto

GPS 4.3


GPS 10.1


finalizada

Fin Inicio




Fin Inicio

Fin Inicio

GPS 13.1

Aceptación interna

Inicio Inicio

Fin Fin


productos globales


productos globales

CSI-SEG 3.1


seguridad


Formación usuarios finales CSI-SEG 4.1Clasificación y catalogación


CSI



DSI

CSI-SEG 2.1


de seguridad

IAS-SEG 1.1Estudio de la

seguridad requerida

para el IAS


seguridad del entorno de operación

IAS-SEG 3.1


de seguridad de la

implantación

IAS-SEG 4.1Clasificación y catalogación


IAS


seguridad en el entorno de producción

IAS 1.1 Inicio-Inicio, Fin-FinPlan de implantación

IAS 3.1 Inicio-Inicio, Fin-FinInstalación del software


IAS 10.2 Fin-Inicio

IAS completado

Iteración Fase de Mantenimiento

MSI-CAL 1.1

Revisión del mantenimiento

MSI-CAL 2.1Revisión del

plan de pruebas de regresión

MSI-CAL 3.1

Evaluación de pruebas de regresión

MSI-SEG 3.1Clasificación y

catalogación de los productos

del MSI

MSI-SEG 1.1Estudio de seguridad

requerida en el MSI

MSI-SEG 2.1

Estudio de la petición

MSI-SEG 2.2Cambios en

los mecanismos de seguridad

MSI-GC 1.1

Registro del cambio

MSI-GC 1.2Registro de la nueva versión

de un producto

MSI-GC 1.3

Registro de la nueva versión

del sistema

GPS 1.1



GPS 3.1




tareas al equipo

GPS 4.2



impacto

GPS 4.3


GPS 10.1


finalizada

Fin Inicio




Fin Inicio

Fin Inicio

GPS 13.1

Aceptación interna

Inicio Inicio

Fin Fin

MSI 4.3 Fin-Inicio

Corrección





Inicio Inicio

Fin Fin


Propuesta de solución

Inicio Inicio

Fin Fin

MSI 4.3 Fin-Inicio

Fin del MSI


Modificación


Producto modificado



GPS 6.1


GPS 6.2


GPS 6.3


solución

GPS 7.1



para el cambio

GPS 8.2


GPS 9.1





GPS 11.3


GPS 12.1

Reunión interna de

seguimiento

GPF 1.1Cierre del proyecto,

inclusión en el histórico de proyectos

GPF 1.2Archivo de la

documentación de gestión del

proyecto

GPS 3.1 Fin-Inicio

Seguimiento

Inicio Inicio

Fin Fin

Inicio Inicio

Fin Fin

Inicio Inicio

Fin Fin

Inicio Inicio

Fin Fin

Fin Inicio

Inicio Inicio

Fin Fin

Fin Inicio


Fin Inicio

Fin Inicio


Cambio


285 de 297

Implantación en una Nueva Organización


286 de 297

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:

Directriz de ingeniería.Implementación de la transición.


287 de 297

Directriz de Ingeniería

Punto de partida:El ejecutivo inicial explica porqué la empresa está cambiando a un proceso software mejorado.

La directriz cubre:La situación actual del negocio y el hecho de que estácambiando.Lo que esperan los clientes en la actualidad.La competencia a la que se enfrenta la empresa.Los retos que afronta la empresa.Los riesgos de no realizar cambios.Lo que la empresa debe hacer sobre el proceso software en particular.


288 de 297


Aspectos importantes:Garantía de apoyo:

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.Al comenzar un nuevo proyecto con un nuevo proceso se depende dela plena integración de cuatro aspectos:

Proceso.Herramientas.Formación.Asesoría.


289 de 297


Aspectos importantes:Garantía de apoyo.Continuidad en los proyectos existentes:

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.

Confianza en el propio futuro: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.


290 de 297

Implementación de la transición

Participantes:El líder:

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.El líder debe comprender la nueva metodología para lo que debe realizar alguna formación y conseguir asesoría personalizada. Tendrá la confianza tanto de los ejecutivos que le subvencionan como de los participantes en el proyecto. Debe saber trabajar tanto con gestores como con personal técnico. Adaptará la nueva metodología a las necesidades del primer proyecto, es decir, comenzará desde cero.


291 de 297


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

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.

El asesor:Puede ser interno o externo. Habrá participado previamente en proyectos que siguiesen la nueva metodología.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.


292 de 297


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


293 de 297


Condiciones:Se empieza por un proyecto real y crítico. 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.


294 de 297


Consideraciones adicionales: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.Reestructurar el proceso paso a paso lleva mucho tiempo y a menudo falla.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.


295 de 297

Especificación de la metodología

Es un marco de trabajo que debe ser adaptado a una serie de variables:

Tamaño del sistema en curso.Dominio con el que ha de trabajar el sistema.Complejidad del sistema.Las cualidades de la organización del proyecto y sus miembros.


296 de 297

Adaptación del proceso

Aspectos constantes:La cuatro fases.Los cinco flujos de trabajo fundamentales.

Aspectos variables:La longitud relativa de las fases.El número de iteraciones para cada fase bajo diferentes circunstancias.Cuándo considerar suficientemente definidas:

La arquitectura candidata.La mitigación de riesgos.La línea de base de la arquitectura.El análisis del negocio.


297 de 297

Adaptación del proceso

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

metodologia

Documents