TEMA4

Metodologa para el Desarrollo de Software
Dr. Jos Ignacio Pelez Snchez E.T.S.I. Informtica de Sistemas. 3er Curso. Ao 2004/2005
Metodologa
Conjunto de actividades necesarias para transformar los requisitos de los usuarios en un sistema software
Jos Ignacio Pelez Snchez Universidad de Mlaga

Departamento de Lenguajes y Ciencias de la Computacin
2 de 297
DUM
Desarrollo Unificado con Mtrica

3 de 297
DUM
Caractersticas:
Proporciona una gua 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, medicin de los productos y actividades del proyecto.

4 de 297
DUM
El proceso consta de cinco fases:
1. Inicio. 2. Elaboracin. 3. Construccin. 4. Transicin. 5. Mantenimiento. Esta fase es responsabilidad del cliente, que bien
puede encomendrsela a la propia organizacin de desarrollo de software, o bien, puede encomendrsela a otra.

5 de 297
DUM
Las cuatro primeras fases (Inicio, elaboracin, construccin, transicin) atraviesan cinco flujos de trabajo que son conocidos como iteracin:
1. Captura de requisitos. 2. Anlisis. 3. Diseo. 4. Implementacin. 5. Prueba.

6 de 297
DUM
Antes de definir en detalle las cuatro fases es necesario conocer el mtodo de comunicacin (casos de uso) que se emplear durante el desarrollo del software. Tambin 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.

7 de 297
Dirigido por Casos de Uso

La comunicacin en el proyecto se realiza mediante casos de uso. Para ello, se deben transformar los requisitos del lenguaje natural a un mtodo de representacin comprensible para TODOS los implicados en el proyecto, incluidos los clientes y usuarios. Cmo?. CASOS DE USO

8 de 297

Los casos de uso intervienen en los cinco flujos de trabajo fundamentales:
Se identifican (captura de requisitos). Se especifican (anlisis). Se disean. Se implementan. Son fuente a partir de la cual se construyen los casos de prueba.

9 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:
Especificacin. Diseo. Prueba. Otras.
Facilitan la asignacin de tareas y pueden servir como unidad de medida que incluya estimaciones de esfuerzo, tiempo, tamao y recursos necesarios.

10 de 297

Trazas. Definicin:
Relaciones que establece un caso de uso entre los elementos que genera en los distintos flujos de trabajo fundamentales.
Caractersticas:
Permiten relacionar directamente un elemento de diseo o incluso de implementacin con el caso de uso que lo origin. Aportan flexibilidad ante cambios en los requisitos.

11 de 297

Trazas: Definicin. Caractersticas. Especificacin:
Cada caso de uso, del modelo de casos de uso, se traducir en una realizacin de casos de uso, en el modelo de anlisis. Cada realizacin de caso de uso del modelo de anlisis, que estar expresada en trminos del anlisis, se traducir en una realizacin de casos de uso del modelo de diseo. El modelo de diseo es un esquema de implementacin, por tanto, la implementacin de una realizacin de caso de uso es directa. Se pueden definir casos de prueba a partir de los casos de uso.

12 de 297

Trazas:
Casos de Uso Realizacin de caso de uso Realizacin de caso de uso Implementacin Pruebas
Anlisis
Diseo

13 de 297
Centrado en la Arquitectura
La arquitectura es la visin comn 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 aadiendo elementos a la misma.

14 de 297
Incluye vistas de todos los modelos prueba: excepto el de
Casos de uso. Formado por todos los casos de uso y su relacin con los usuarios. Anlisis. El objetivo es refinar los casos de uso, mostrar la funcionalidad del sistema. Diseo. Definicin de la estructura esttica (subsistemas, clases e interfaces) y de los casos de uso considerados colaboraciones entre los elementos anteriores. Despliegue. Basado en nodos fsicos, se ocupa de la correspondencia nodos-componentes. Implementacin. Basado en componentes, se ocupa de la correspondencia clases-componentes.

15 de 297
Formarn parte de la arquitectura los elementos ms importantes, los que guan el trabajo:
Subsistemas. Dependencias. Interfaces Colaboraciones Nodos. Clases activas.
Estos elementos describen los cimientos del sistema que son necesarios para la comprensin, desarrollo y produccin del sistema.
16 de 297
Necesidades que cubre la arquitectura: Comprender el sistema. Organizar el desarrollo:
La divisin del sistema en subsistemas con interfaces claramente definidas con un responsable establecido para cada subsistema reduce la carga de comunicacin entre los grupos de trabajo, por tanto, las interfaces permiten el progreso independiente de software a ambos lados de las mismas.
Fomentar la reutilizacin:
Requiere un conocimiento del dominio del problema que permita determinar si un componente concreto ser til al sistema. La clave para la integracin de estos componentes est en las interfaces tanto del componente como del sistema.

17 de 297
Necesidades que cubre la arquitectura: Comprender el sistema. Organizar el desarrollo. Fomentar la reutilizacin. Hacer evolucionar el sistema:
Proporciona la seguridad de que el sistema evolucionar ante modificaciones de diseo o implementacin o ante la introduccin de nuevas funcionalidades.

18 de 297
Creacin de la arquitectura:
Borrador inicial de la parte que no es especfica de los casos de uso, por ejemplo la plataforma. Seleccin, especificacin y realizacin de los casos de uso que representen funciones clave del sistema. La arquitectura se va refinando a medida que se especifican ms casos de uso y a medida que la arquitectura se va refinando da cabida a ms casos de uso. El uso de iteraciones posibilitar la ejecucin de esto ltimo.

19 de 297
Necesidades que cubre la arquitectura: Comprender el sistema. Organizar el desarrollo. Fomentar la reutilizacin. Hacer evolucionar el sistema.

20 de 297
Relacin Casos de Uso-Arquitectura

La funcin del sistema corresponder a los casos de uso y la forma del mismo a la arquitectura. Existe una relacin cclica 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 realizacin de los casos de uso.

21 de 297
Relacin Casos de Uso-Arquitectura

Esta interdependencia introduce un problema:
Qu definir primero, los casos de uso (adaptando posteriormente la arquitectura para facilitar su realizacin), o la arquitectura (adaptando posteriormente los casos de uso a la misma)?
La repuesta es:
Ninguna de las dos opciones. Se realizar un trabajo simultneo. cmo?
MEDIANTE ITERACIONES

22 de 297
Iterativo e Incremental
El tercer aspecto a destacar de la metodologa es el desarrollo incremental:
La arquitectura se va completando en sucesivos pasos que le aaden algo de funcionalidad hasta la conclusin del desarrollo, cuando la arquitectura se haya convertido en el sistema en s. Dichos pasos se denominan iteraciones.

23 de 297
Iteraciones: Definicin:
Las iteraciones se entienden como ejecuciones reducidas del proyecto que aaden nueva funcionalidad al sistema. Para ejecutarlas se toma un conjunto de casos de uso (captura de requisitos) segn el criterio de planificacin, y se realiza el trabajo correspondiente a los mismos completamente (anlisis, diseo, implementacin y prueba).
Actividades:
Las iteraciones se planifican, admiten divisin en unidades menores denominadas construcciones y finalmente, se evalan.

24 de 297
Iteraciones: Definicin. Actividades. Caractersticas:
Dan un carcter de simultaneidad al proyecto que permite respetar la interdependencia entre arquitectura y casos de uso. Permiten abordar los problemas ms graves al principio del proyecto evitando sorpresas desagradables cuando el proyecto est demasiado avanzado y resulta muy costoso, o puede que inviable, realizar modificaciones. Aaden fiabilidad ya que cada iteracin es probada, por tanto, cuando se empieza una iteracin se tiene la seguridad de que todo el trabajo anterior es correcto.

25 de 297
Iteraciones: Definicin. Actividades. Caractersticas:
Si la evaluacin de una iteracin es totalmente negativa se puede cancelar el proyecto. Cada iteracin da como resultado una versin interna del sistema en funcionamiento, facilitando la identificacin de nuevos requisitos. La identificacin temprana de retrasos permite adaptar los calendarios con suficiente antelacin. Por ltimo, cabe destacar que aportan sensacin de progreso al proyecto.

26 de 297
Iteraciones: Definicin. Actividades. Caractersticas. Planificacin:
Debe estar orientada a que las primeras iteraciones proporcionen la base de conocimiento para las siguientes. Las primeras iteraciones del proyecto buscan incrementar la comprensin de los requisitos, el problema, los riesgos y el dominio de la solucin. Las restantes aaden incrementos que finalmente conformarn la versin externa, es decir, el producto para el cliente.

27 de 297
Iteraciones: Definicin. Actividades. Caractersticas. Planificacin:
El objetivo es obtener una serie de iteraciones que siempre avanza, para que no sea necesario volver varias iteraciones atrs para realizar correcciones debido a algo aprendido en la ltima iteracin. Un factor importante es la ordenacin, por importancia, tanto de los casos de uso como de los riesgos.

28 de 297
Iteraciones: Definicin. Actividades. Caractersticas. Planificacin.

29 de 297
CONCEPTO DE RIESGO

30 de 297
Riesgos
Riesgos: Definicin:
Un riesgo es un asunto que tiene cierto grado de probabilidad de poner en peligro el xito de un proyecto.
Tipos:
Riesgos tcnicos: Relacionados con nuevas tecnologas. Relativos a la arquitectura. Relativos a la construccin del sistema adecuado que cumpla su misin. Relativos al rendimiento.

31 de 297
Riesgos
Riesgos: Definicin. Tipos:
Riesgos tcnicos. Riesgos no tcnicos: Falta de experiencia en ciertos aspectos. Lenguaje nuevo para la organizacin. Calendario demasiado apretado. Dependencia de empresas subcontratadas. Incumplimiento del cliente de algn plazo de aprobacin.

32 de 297
Riesgos
Riesgos tcnicos. Riesgos no tcnicos.
Tratamiento:
Evitarlo (introducir cambios). Limitarlo (restringirlo a una pequea parte del proyecto). Controlarlo (plan de contingencia). Atenuarlo (forzar su aparicin para aplicarle alguna de las opciones anteriores).

33 de 297
Riesgos
Riesgos tcnicos. Riesgos no tcnicos.
Tratamiento.

34 de 297
Conclusiones
Ahora resulta ms fcil comprender que los casos de uso dirigen el proceso de desarrollo. Los casos de uso estn presentes en los cinco flujos de trabajo fundamentales
Captura de requisitos. Anlisis. Diseo. Implementacin. Prueba.
Son la base en la planificacin de las iteraciones. La arquitectura debe adaptarse a los casos de uso para facilitar su realizacin.

35 de 297
COMPRENSIN DEL SISTEMA

36 de 297
Comprensin del Contexto del Sistema

Un buen desarrollo de software requiere la comprensin del contexto del sistema. Esta compresin ayudar al equipo de desarrollo a tener una idea ms o menos prxima de lo que debe realizar el sistema. Adems 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.

37 de 297
Modelo de Dominio
Modelo de dominio: Definicin:
Un modelo de dominio captura los tipos de objetos ms 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.
Descripcin:
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 aviacin enemiga. Sucesos que ocurrirn o han ocurrido, por ejemplo llegada o salida de un avin.
38 de 297
Modelo de Dominio
Modelo de dominio: Definicin. Descripcin. Tipos de clases y objetos. Desarrollo:
El objetivo es comprender y describir las clases ms importantes dentro del contexto del sistema. Las clases candidatas se guardan como definiciones en el glosario de trminos para evitar que el modelo sea demasiado grande. Si el dominio de negocio es muy pequeo basta con el glosario de trminos. Tanto el modelo de dominio como el glosario de trminos contribuyen a unificar el lenguaje empleado por todos los implicados en el proyecto.

39 de 297
Modelo de Dominio
Modelo de dominio: Definicin. Descripcin. Tipos de clases y objetos. Desarrollo. Uso:
Las clases del dominio y el glosario de trminos se usan en el desarrollo de los modelos de casos de uso y anlisis:
Al describir los casos de uso y al disear la interfaz de usuario. Para sugerir clases internas al sistema en desarrollo durante el anlisis.
Un modelo del dominio es en realidad un caso especial de un modelo del negocio que es ms completo.

40 de 297
Modelo de Dominio
Modelo de dominio: Definicin. Descripcin. Tipos de clases y objetos. Desarrollo. Uso.

41 de 297
Modelo de Negocio
Modelo de negocio: Definicin de negocio:
Entendemos por negocio el campo del que se ocupa el sistema, por ejemplo, la metodologa que se est presentando es un caso de uso del negocio del desarrollo de software.
Definicin:
Es una tcnica que permite comprender los procesos del negocio de la organizacin.
Objetivo:
El objetivo es identificar los casos de uso y las entidades de negocio relevantes que el software debe soportar, modelando as slo lo necesario para comprender el contexto.

42 de 297
Modelo de Negocio
Modelo de negocio: Definicin de negocio. Definicin. Objetivo. Descripcin:
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 trminos de casos de uso y actores del mismo que se corresponden con dichos procesos y con los clientes respectivamente.

43 de 297
Modelo de Negocio
Modelo de negocio: Definicin de negocio. Definicin. Objetivo. Descripcin. Elementos:
Un modelo de objetos del negocio es un modelo interno a un negocio. Describe la realizacin de casos de uso del negocio en trminos de entidades del negocio y unidades de trabajo, mostrndolas en diagramas de interaccin 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.

44 de 297
Modelo de Negocio
Modelo de negocio: Definicin de negocio. Definicin. Objetivo. Descripcin. Elementos:
Las entidades del negocio y las unidades de trabajo se usan para representar los mismos tipos de conceptos que las clases del dominio. Se usarn otros diagramas para mostrar trabajadores, sus interacciones y cmo usan las entidades de negocio y la unidades de trabajos.

45 de 297
Modelo de Negocio
Modelo de negocio: Definicin de negocio. Definicin. Objetivo. Descripcin. 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.

46 de 297
Modelo de Negocio
Modelo de negocio: Definicin de negocio. Definicin. Objetivo. Descripcin. Elementos. Desarrollo:
Desarrollar un modelo de objetos del negocio compuesto por trabajadores, entidades del negocio y unidades de trabajo que juntas realizan los casos de uso del negocio. Se asocian a estos objetos las reglas del negocio y otras normas impuestas por el negocio con el fin de crear objetos que realicen los casos de uso del negocio de la forma ms eficaz posible (rpidamente, con precisin y a un coste bajo).

47 de 297
Modelo de Negocio
Modelo de negocio: Definicin de negocio. Definicin. Objetivo. Descripcin. Elementos. Desarrollo.

48 de 297
Relacin entre los dos Modelos

Existen similitudes entre el modelo del dominio y el del negocio, de hecho el de dominio es una versin 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 ms recomendable realizar el ms completo modelo del negocio.

49 de 297
Diferencias entre los Modelos

Diferencias entre el modelo de dominio y el de negocio: Origen de la informacin:
Las clases del dominio se obtienen de la base del conocimiento de unos pocos expertos del dominio, o del conocimiento asociado con sistemas similares al que se desarrolla. Las entidades del negocio se derivan a partir de los clientes del negocio, identificando los casos de uso del negocio y despus buscando las entidades. Cada entidad debe venir motivada por su utilizacin en un caso de uso del negocio.
Trazas:
La tcnica de modelado del dominio puede hacer la traza de las clases hasta la experiencia de los expertos del dominio. La tcnica de modelado del negocio puede hacer la traza de la necesidad de cada elemento hasta los clientes.
50 de 297

Diferencias entre el modelo de dominio y el de negocio: Origen de la informacin. Trazas. Identificacin de operaciones:
La clases del dominio tienen atributos pero ninguna o pocas operaciones. Las entidades del negocio poseen operaciones a travs de las cuales se identifica cmo usarn los trabajadores el sistema. Por tanto, la tcnica de modelado del negocio no slo identifica las entidades sino tambin todos los trabajadores que participarn en la realizacin de los casos de uso del negocio que utilizan a las entidades. Las operaciones de las entidades del negocio se derivarn de los clientes y podrn ser trazadas hasta ellos.

51 de 297

Diferencias entre el modelo de dominio y el de negocio: Origen de la informacin. Trazas. Identificacin de operaciones. Relacin 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 construccin. Esto permitir realizar la traza de cada caso de uso del sistema a travs de los trabajadores y casos de uso del negocio hasta los clientes del negocio. Adems puede realizarse la traza desde un caso de uso hasta los componentes que implementan el sistema.

52 de 297

Diferencias entre el modelo de dominio y el de negocio: Origen de la informacin. Trazas. Identificacin de operaciones. Relacin del modelo con los casos de uso del sistema:
El modelo del negocio y la ingeniera del software combinados permiten hacer el seguimiento de las necesidades del cliente a lo largo del camino completo a travs de procesos del negocio, trabajadores y caso de uso, hasta el cdigo del software. Sin embargo, usando el modelo del dominio, no hay forma evidente de hacer traza entre ste y los casos de uso del sistema.

53 de 297

Diferencias entre el modelo de dominio y el de negocio: Origen de la informacin. Trazas. Identificacin de operaciones. Relacin del modelo con los casos de uso del sistema.

54 de 297
Fases para el Desarrollo

55 de 297
Fases del desarrollo de software

Fase Fase Fase Fase de de de de Inicio Elaboracin Construccin Transicin
Mantenimiento

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

57 de 297
PLANIFICACIN DE LAS FASES

58 de 297
Planificacin
El proceso de desarrollo de software est dividido en cuatro fases cada una de las cuales se ejecuta mediante una o varias iteraciones. Adems, cada iteracin consta de una o varias construcciones. Por tanto, existen dos tipos de planificacin:
El plan del proyecto, que engloba las cuatro fases. El plan de iteracin, referente a una iteracin concreta.
Los planes se controlarn mediante HITOS.

59 de 297
Planificacin
Hitos: Definicin:
Criterios que se deben cumplir al llegar a un determinado punto del desarrollo.
Necesidad:
Seguimiento de la planificacin. Evaluacin del trabajo realizado. Sincronizacin del proyecto (si es llevado a cabo por distintos grupos en paralelo).
Tipos:
Principales, al final de cada fase. Secundarios, al final de una iteracin o de una construccin.

60 de 297
Planificacin
Hitos: Definicin. Necesidad. Tipos. Hitos principales:
Fase de Inicio:
Objetivos del ciclo de vida.
Fase de Elaboracin:
Arquitectura del ciclo de vida.
Fase de Construccin:
Capacidad operativa inicial.
Fase de Transicin:
Lanzamiento del producto.

61 de 297
Planificacin
Hitos: Definicin. Necesidad. Tipos. Hitos principales.

62 de 297
FASE DE INICIO

63 de 297
VISIN GENERAL DE LA FASE

64 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 decisin sobre qu debe realizar el sistema, teniendo en cuenta dnde se encuadra el mismo, debe hacerse de acuerdo con el cliente.

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

66 de 297
Planificacin de la Fase
Planificacin: Alcance:
Se desarrolla un plan para crear una arquitectura candidata slo hasta el punto de establecer si el proyecto es factible.
Actividades:
Reunir la informacin recogida antes de comenzar el proyecto. Organizarla. Reunir un grupo de gente para que la trate. Descubrir qu falla en trminos de los objetivos de la fase de inicio.

67 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 caractersticas? Se han identificado los riesgos crticos para el desarrollo exitoso del proyecto? Se prev una forma de tratarlos? El uso del producto generar beneficios que justifiquen lo invertido en su construccin? Es factible para su organizacin llevar adelante el proyecto? Estn los inversores de acuerdo con los objetivos?

68 de 297
Evaluacin de la Fase
Evaluacin: 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?
Ambigedades 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?

69 de 297
Fase de Inicio
Evaluacin: mbito del sistema. Ambigedades en los requisitos. Arquitectura candidata:
Satisface esta arquitectura las necesidades de los usuarios? Es factible que funcione? Puede usar de forma apropiada la tecnologa 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 fcilmente si se aaden requisitos?

70 de 297
Fase de Inicio
Evaluacin: mbito del sistema. Ambigedades en los requisitos. Arquitectura candidata. Mitigar riesgos crticos:
Se han identificado todos los riesgos crticos? Se han mitigado los riesgos identificados o existe un plan para mitigarlos?
Juzgar el valor del anlisis de negocio inicial.

71 de 297
Fase de Inicio
Evaluacin: mbito del sistema. Ambigedades en los requisitos. Arquitectura candidata. Mitigar riesgos crticos. Juzgar el valor del anlisis de negocio inicial.

72 de 297
DESARROLLO DE LA FASE

73 de 297
Fase de Inicio
Primera iteracin: Actividades preliminares:
Ajustar la metodologa al proyecto y seleccionar herramientas para la automatizacin 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 ms difcil si se trata de un desarrollo nuevo que si se trata de la extensin de un producto ya existente. Familiarizar al equipo con las herramientas apropiadas.

74 de 297
Ajuste al entorno de desarrollo

Se inicia en esta fase y se culmina en la de elaboracin. Entorno de desarrollo: Procesos (configuracin). Herramientas para llevarlos a cabo. Servicios (administracin del sistema, copia de seguridad y telecomunicaciones).

75 de 297
PSI 1.1 Completa
Fin
Inicio PSI 1.2 Completa
Fin
Fin
Inicio PSI-SEG 1.1 Completa
Fin
Fase Preliminar

77 de 297
Fase de Inicio
Actividades fundamentales: Definicin del mbito del sistema. Esbozar arquitectura candidata. Anlisis inicial del negocio. Trabajo a realizar en cada iteracin: Planificacin. Flujos de trabajo fundamentales. Evaluacin.

78 de 297
Fase de Inicio
Actividades fundamentales: Definicin del mbito del sistema. Esbozar arquitectura candidata. Anlisis inicial del negocio. Trabajo a realizar en cada iteracin: Planificacin. Flujos de trabajo fundamentales. Evaluacin.

79 de 297
Flujos de trabajo fundamentales

Captura de requisitos. Anlisis. Diseo. Implementacin. Prueba.

80 de 297
Captura de Requisitos
Captura de requisitos:
Actividades: Enumerar requisitos candidatos, lista de caractersticas. 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.

81 de 297
Anlisis
Anlisis:
Objetivo: El resultado debe ser un modelo inicial de anlisis que defina con precisin los casos de uso y que gue el establecimiento de la arquitectura candidata. Actividades: Anlisis de la arquitectura: Identificar paquetes de anlisis. Clases de entidad. Requisitos especiales comunes (persistencia, tolerancia a fallos, etc...) Analizar un caso de uso Identificacin de clases de anlisis. Descripcin de interacciones entre objetos de anlisis. Captura de requisitos especiales
82 de 297
Anlisis
Anlisis:
Objetivo: Actividades: Anlisis de la arquitectura. Analizar un caso de uso. Analizar una clase: Trabajo mnimo. Analizar un paquete: Trabajo mnimo.

83 de 297
Resumen Anlisis
Anlisis:
Objetivo: Actividades: Anlisis de la arquitectura. Analizar un caso de uso. Analizar una clase. Analizar un paquete.

84 de 297
Diseo
Diseo (Se puede desarrollar un prototipo de demostracin): Actividades:
Diseo de la arquitectura: Realizar los casos de uso como colaboraciones entre subsistemas o clases. Identificar mecanismos genricos de diseo que sern necesarios en las capas subyacentes de los subsistemas identificados. Se elige el software del sistema y los marcos de trabajo que se emplearn 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 versin reducida del modelo de despliegue

85 de 297
Diseo
Diseo:
Actividades Diseo de la arquitectura. Identificar nodos y configuraciones de red. Identificar subsistemas e interfaces: Subsistemas de aplicacin. Subsistemas intermedios y de software del sistema. Dependencias entre subsistemas . Interfaces entre subsistemas . Identificar clases de diseo relevantes para la arquitectura: A partir de clases del anlisis. Identificar clases activas. Identificacin de mecanismos genricos de diseo (conjuntos de elementos del diseo encargados de los requisitos especiales).
86 de 297
Diseo
Diseo:
Actividades Diseo de la arquitectura. Identificar nodos y configuraciones de red. Identificar subsistemas e interfaces. Identificar clases de diseo relevantes para la arquitectura. Identificacin de mecanismos genricos de diseo. Disear un caso de uso: Trabajo mnimo. Disear una clase: Trabajo mnimo. Disear un subsistema: Trabajo mnimo.

87 de 297
Resumen del Diseo

Diseo:
Actividades Diseo de la arquitectura. Identificar nodos y configuraciones de red. Identificar subsistemas e interfaces. Identificar clases de diseo relevantes para la arquitectura. Identificacin de mecanismos genricos de diseo. Disear un caso de uso. Disear una clase. Disear un subsistema.

88 de 297
Implementacin y Prueba
Implementacin: Slo necesaria si se va a realizar el prototipo. Prueba: Trabajo mnimo.

89 de 297
Arquitectura por capas
Capa especfica de la aplicacin Capa general de la aplicacin Capa middleware Capa de software del sistema

90 de 297

Capas: Definicin:
Una capa es un conjunto de subsistemas que tiene el mismo grado de generalidad.
Caractersticas:
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 especfica de la aplicacin) se crean a partir de los casos de uso arquitectnicamente significativos, es decir, son dependientes del negocio. La capa general contiene subsistemas no especficos que pueden ser reutilizados por muchas aplicaciones diferentes dentro del mismo dominio o negocio.

91 de 297

Capas: Definicin. Caractersticas. 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.

92 de 297

Capas: Definicin. Caractersticas. Interdependencia.

93 de 297
Anlisis inicial del negocio

Anlisis del negocio: Objetivo:
El anlisis inicial de negocio sirve para determinar si se entra en la fase de elaboracin.
Aspectos:
Costes econmicos: exigencias de recursos del proyecto, costes de la inversin. Estimaciones de beneficios y de aceptacin (de mercado o interna).

94 de 297

Anlisis del negocio: Objetivo. Aspectos. Actividades:
Esbozar una apuesta econmica: Se toman los casos de uso como medida de tamao para realizar las estimaciones. La cantidad de horas-personas necesarias para disear, implementar y probar un caso de uso depende de: Complejidad del sistema propuesto. Tamao. Tipo de aplicacin.

95 de 297

Anlisis del negocio: Objetivo. Aspectos. Actividades:
Estimar la recuperacin de la inversin: Si es un software comercial deben estimarla los expertos en ventas, si es para uso interno el cliente debe especificar el ahorro esperado.

96 de 297

Anlisis del negocio: Objetivo. Aspectos. Actividades.

97 de 297
Evaluacin de iteraciones
Evaluacin: Participantes:
Se crea un grupo de evaluacin que incluye representantes del cliente y/o de los usuarios.
Posibles criterios para ampliar el nmero de iteraciones:

Ampliacin del modelo de casos de uso. Desarrollo de un prototipo exploratorio. Sospecha de que no se hayan encontrado todos los riesgos crticos. Si no han sido mitigados todos los riesgos crticos o no han sido suficientemente cubiertos por un plan de emergencia
Conclusin:
El resultado final de la evaluacin determina si se sigue adelante o se abandona el proyecto.
98 de 297
Planificacin de la fase de Elaboracin

Se determina alrededor del 80% de los casos de uso sin pasar por alto nada que sea importante para la arquitectura para poder realizar una apuesta econmica exacta. De los casos de uso identificados ser necesario analizar aproximadamente la mitad. Del conjunto de casos de uso analizados se selecciona la parte ms significativa para el diseo de la lnea de base de la arquitectura, que incluye una descripcin de la arquitectura y nuevas versiones de todos los modelos. Se determina el nmero de iteraciones y qu requisitos se implementarn y probarn en cada iteracin.

99 de 297
Productos Generados
1. Lista de caractersticas. 2. Primera versin del modelo de negocio. 3. Esbozo de los modelos de casos de uso, anlisis, diseo y despliegue. Los de implementacin y pruebas sern rudimentarios. Primera versin de los requisitos adicionales. 4. Primer esquema de la descripcin de la arquitectura candidata que perfila las vistas de los modelos de casos de uso, anlisis, diseo e implementacin. 5. Prototipo exploratorio (opcional). 6. Lista inicial de riesgos y clasificacin de casos de uso. 7. Rudimentos de un plan para el proyecto en su totalidad. 8. Primer borrador del anlisis de negocio, incluyendo el contexto del negocio y los criterios de xito como estimacin de beneficios, reconocimiento de mercado y estimacin del proyecto.
100 de 297
PSI 2.3 Primera versin del plan de trabajo, esbozo
ici o
EVS 3.1 PSI 3.1 Informacin relevante, completa PSI 3.2
In
Inicio
Inicio
Fin
Inicio
cio In i
Requisitos generales, completa
Fin
Fin
Catlogo de normas, se intenta completar aunque puede que sea necesario hacerlo en la fase posterior PSI 3.2 Inicio-Inicio Modelo de negocio
PSI 2.1 Descripcin de procesos afectados, completa
PSI 2.2
Fin
Inicio
Catlogo de usuarios, completa aunque el se aaden usuarios a lo largo del proyecto.
Ini
In
ici o
cio
PSI 4.1
Inicio
Inicio
Inicio
Inicio
Modelo de Procesos, completo
Fin
Fin
PSI 4.2 Necesidades de informacin, requisitos funcionales, diagrama de clases, completa
Inicio Fin
Inicio Fin
PSI 4.3 Requisitos de los procesos, completa
EVS 1.2
Fin
Inicio
EVS 3.3 Catalogacin de requisitos
Dependencias con otros proyectos, visin global del alcance del sistema
Fin
Inicio
EVS 1.3 Usuarios y plan de trabajo de esta fase
Inicio
io Inic
Fin
EVS 2.1 Descripcin de sistemas actuales completa si se tiene en cuenta la arquitectura, si no se completa en la siguiente fase
Inicio
i Inic
EVS 3.2
Fin
Inicio
Identificacin de requisitos
Inicio
EVS 2.4 Diagnstico de la situacin actual, completa
EVS 2.3
Inicio
Fin
Descripcin lgica de los sistemas actuales, modelo fsico, diagrama de clases, completa
Inicio
Fin
EVS 2.2 Participantes del estudio de la situacin actual
Inicio
Fin
PSI 4.3 Fin-Inicio Modelo de negocio PSI 5.1 Identificacin de sistemas afectados, completa
Inicio
Inicio
Fin
Fin
PSI 5.2 Descripcin de sistemas afectados, completa
Inicio
Inicio
Fin
Fin
PSI 5.3 Valoracin de sistemas afectados, completa
Fin
Inicio
PSI 6.1 Sistemas que se conservan y mejoras propuestas, completa
Inicio
Fin
Fin
Fi n
Inic
io
In ici o
Inicio
Fin
Inicio Fin
Inicio Fin
Inicio Fin
Inicio Fin
Inicio Fin
Inicio Fin
ASI 3.2 Fin-Inicio DSI 3.3 Diseo de interfaz de usuario, caso muy concreto Divisin en subsistemas DSI 3.4 Descripcin de casos de uso en trminos de subsistemas e interfaces, alto nivel
ASI 9.3 Fin-Inicio Modelo de clases DSI 4.1 Identificacin de clases de diseo, a partir de las de anlisis
n Fi
In ici
DSI 3.1 Identificacin de clases de diseo adicionales, diseo de casos de uso
Inicio Fin
Inicio Fin
DSI 3.2 Interaccin de clases anteriormente identificadas, realizacin de casos de uso
Inicio Fin
Inicio Fin
Inicio Fin
In
ici o
Inicio Fin
n Fi
Inicio
Fi n
Inicio
Fi n
DSI 4.2 Asociaciones y agregaciones de las clases identificadas
Inicio Fin
Inicio Fin
DSI 4.3 Atributos de las clases identificadas, caso concreto
Inicio Fin
Inicio Fin
DSI 4.4 Operaciones de las clases, caso concreto
Inicio Fin
Inicio Fin
DSI 4.5 Jerarqua del modelo de clases
Inicio Fin
Inicio Fin
DSI 4.6 Pseudocdigo de algn mtodo concreto
DSI 6.1
DSI 6.4
Fin
Inicio
DSI 3.3,3.4,6.4 Fin-Inicio Productos obtenidos DSI 7.2 Anlisis de consistencia de los productos obtenidos DSI 8.1 DSI 8.2
Especificacin a alto nivel del modelo fsico de datos si mejora la comprensin del sistema
Fin
Inicio
Distribucin de los datos a muy alto nivel, modelo de datos no optimizado.
Fin
Inicio
Especificacin del entorno tecnolgico necesaria para la realizacin del prototipo
Inicio
Inicio
Inicio
Definicin de componentes y subsistemas necesarios para el prototipo.
Inicio Fin
Fin
DSI 10.1 Especificacin del entorno de pruebas para el prototipo
DSI 10.2
Inicio Fin
Inicio
Niveles de prueba
Fin Inicio Fin

CSI 3.1 Preparacin del entorno de pruebas unitarias
CSI 2.1 Inicio-Inicio Cdigo del prototipo CSI 3.2 Realizacin y evaluacin de pruebas unitarias CSI 2.1 Fin-Inicio
Fin
Fin
Fin
Inicio
Inicio
Inicio
Inicio
Fin
Ini cio
CSI 1.2 Preparacin del entorno de construccin para el prototipo
CSI 2.1 Generacin de cdigo
Fin
Cdigo del prototipo CSI 4.1 Preparacin del entorno de pruebas de integracin CSI 4.2
Inicio Fin
Inicio Fin
CSI 4.3 Evaluacin de pruebas de integracin
DSI 10.3 Plan de pruebas
Fin
Inicio
Fin
Inicio
Realizacin de pruebas de integracin CSI 2.1 Fin-Inicio
Fi n In ici o
CSI 5.1 Preparacin del entorno de pruebas del sistema
Cdigo del prototipo CSI 5.2
Inicio Fin
Inicio Fin
CSI 5.3 Evaluacin de pruebas del sistema
Fin
Inicio
Realizacin de pruebas del sistema
Ejemplo Fase de Inicio

104 de 297
FASE DE ELABORACIN

105 de 297
Fase de Elaboracin
Objetivos: Crear una lnea de base para la arquitectura que cubra la funcionalidad arquitectnicamente significativa del sistema y las caractersticas que las personas involucradas consideren importantes. Identificar los riesgos significativos, es decir, los que podran perturbar los costes y planificaciones de fases posteriores, reducindose 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 construccin.
106 de 297
Fase de Elaboracin
Objetivos: Preparar una propuesta de planificacin cubierta, personal necesario y coste dentro de los lmites establecidos por las prcticas de negocio. Continuar la observacin y control de los riesgos crticos restantes y e identificar los riesgos significativos hasta el punto de poder estimar su impacto en el anlisis de negocio y en particular en la apuesta econmica. Completar los detalles del plan del proyecto.

107 de 297
Fase de Elaboracin
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 tcnicos predominen o sean ms significativos, en el que habr que profundizar hasta establecer una arquitectura slida. Conclusin: 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 econmica y de planificacin que queda reflejada en un contrato. Por tanto, las decisiones deben tomarse en base a estimaciones muy precisas.

108 de 297
Fase de Elaboracin
Actividades preliminares: Se completa la planificacin realizada en la fase de inicio. Se adapta el equipo de trabajo aadiendo personal para cubrir nuevas necesidades. Se establecen los cambios necesarios en la definicin del entorno de desarrollo.

109 de 297
Fase de Elaboracin
Hito principal: Arquitectura del ciclo de vida:
Se ha creado un lnea 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 trastornarn 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 la apuesta? Proporcionar el proyecto, tal como est planificado y presupuestado en este momento, una recuperacin de la inversin? Se ha obtenido la aprobacin de los inversores?

110 de 297
Fase de Elaboracin
Evaluacin: Extensin de requisitos:
Se han identificado los requisitos, actores, y casos de uso necesarios para disear la lnea de base de la arquitectura?Se han identificado los riesgos significativos? Se han detallado lo suficiente como para lograr los objetivos de esta fase?
Definicin de la lnea de base de la arquitectura:

Satisface la lnea de base de la arquitectura no slo los requisitos recopilados formalmente hasta ahora, sino tambin las necesidades de todos los usuarios? Parece la lnea de base de la arquitectura lo bastante robusta como para resistir la fase de construccin y la adicin de caractersticas que puedan ser necesarias en posteriores versiones del sistema?

111 de 297
Fase de Elaboracin
Evaluacin: Extensin de requisitos. Definicin de la lnea de base de la arquitectura. Mitigar los riesgos significativos:
Se han mitigado de forma adecuada los riesgos crticos, ya sea eliminndolos o preparando un plan de emergencia? Se han identificado los riesgos significativos? Son los riesgos que an permanecen en la lista de riesgos susceptibles de ser eliminados de forma rutinaria en la fase de construccin?

112 de 297
Fase de Elaboracin
Evaluacin: Extensin de requisitos. Definicin de la lnea de base de la arquitectura. Mitigar los riesgos significativos. Vala del anlisis de negocio:
Est el plan del proyecto lo bastante definido como para apostar por un precio, agenda y calidad? Parece verosmil que el anlisis de negocio logre la recuperacin de la inversin o alcance el margen de beneficios que el negocio impone? Estamos listos para redactar un contrato por un precio fijo o el equivalente para un desarrollo interno?

113 de 297
Fase de Elaboracin
Evaluacin: Extensin de requisitos. Definicin de la lnea de base de la arquitectura. Mitigar los riesgos significativos. Vala del anlisis de negocio.

114 de 297
Fase de Elaboracin
Actividades fundamentales: Recopilacin 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 diseo, implementacin y prueba.
Desarrollo de la lnea de base de la arquitectura:

Se establece un orden de prioridad en los casos de uso y se realiza el anlisis, diseo e implementacin a nivel de la arquitectura. Tambin se analizan clases y paquetes disendose clases y subsistemas. Se construye el entorno de pruebas y se prueba la lnea de base. Los paquetes durante el anlisis y los subsistemas durante el diseo son crticos para generar las vistas de la arquitectura.

115 de 297
Fase de Elaboracin
Trabajo a realizar en cada iteracin: Cuatro grupos de actividades ejecutndose en paralelo:
Planificacin. Flujos de trabajos fundamentales. Evaluacin. Preparacin ms detallada del entorno de desarrollo.

116 de 297
Fase de Elaboracin
Consideraciones: El nmero de iteraciones depende del mbito del sistema, los riesgos, el grado de novedad, la complejidad de las solucin tcnica y la experiencia de los desarrolladores. Al ser el equipo pequeo se pueden ensayar diferentes soluciones iterando hasta alcanzar una arquitectura estable que permita realizar la fase de construccin, en la que aumenta el nmero de personas. Se debe construir prestando ms atencin a la calidad y la extensibilidad que en la fase de inicio.

117 de 297
Diferencias entre lnea base y descripcin

La descripcin se realiza a alto nivel pero debe representar lo que cada participante necesita para hacer su trabajo. La lnea base de la arquitectura debe ser operativa, por tanto, puede ser necesarios incluir elementos no significativos para obtener esta operatividad, estos elementos no sern incluidos en la descripcin de la arquitectura, la informacin necesaria para la validacin o verificacin de la arquitectura tampoco ser incluida en la descripcin aunque s en la lnea base.

118 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 extensin o generalizacin. Desarrollar prototipos de las interfaces de usuario: Casos muy concretos, en esta fase casi nunca se desarrollan.

119 de 297

Anlisis: 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 econmica.
Adaptar los requisitos a la arquitectura:

Si un cambio facilita el trabajo y su impacto es menor se negociar con el cliente.
Actividades:
Anlisis de la arquitectura: Extender el anlisis de la fase de inicio hasta el punto de que pueda servir de lnea de base de la arquitectura ejecutable.

120 de 297

Anlisis: Elementos de trabajo. Adaptar los requisitos a la arquitectura. Actividades:
Anlisis de la arquitectura: Se realiza una particin a alto nivel del sistema en paquetes de anlisis en base a la vista del modelo de casos de uso, los requisitos relacionados con stos, el glosario, y el anlisis de negocio. Se identifican los mecanismos de anlisis necesarios para los requisitos especiales comunes como persistencia, distribucin y concurrencia, caractersticas de seguridad, tolerancia a fallos y gestin de transacciones incluyendo colaboraciones y paquetes genricos. Identificacin de mecanismos subyacentes para implementar los casos de uso.
121 de 297

Anlisis: Elementos de trabajo. Adaptar los requisitos a la arquitectura. Anlisis de la arquitectura. Actividades:
Anlisis de la arquitectura. Analizar un caso de uso: Se refinarn los casos de uso complejos y los que tienen impacto en otros casos de uso, junto con los que son importantes arquitectnicamente. Del resto de casos de uso slo es necesario comprender que no tendrn impacto.

122 de 297

Anlisis de la arquitectura. Analizar un caso de uso. Analizar una clase: Refinar las clases de anlisis identificadas anteriormente mezclando las responsabilidades que se les asignaron en los diferentes casos de uso. Se identifican los mecanismo de anlisis y cmo fueron usados por cada clase. Analizar un paquete: Los paquetes de servicio identificados en el anlisis de la arquitectura se refinan y mantienen
123 de 297

Anlisis de la arquitectura. Analizar un caso de uso. Analizar una clase. Analizar un paquete.

124 de 297

Diseo: Alcance:
Se disea e implementa menos del 10% de los casos de uso.
Actividades:
Diseo de la arquitectura: 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 implementacin de los mecanismos de diseo correspondientes a los componentes de anlisis identificados anteriormente.

125 de 297

Diseo: Alcance. Actividades:
Diseo de la arquitectura: Identificar la arquitectura en capas: Se pueden construir/desarrollar en paralelo con el anlisis. Identificar subsistemas y sus interfaces: En los niveles ms altos de la arquitectura. En base a los paquetes del modelo de anlisis se identifican los subsistemas correspondientes y se incluyen en el modelo de diseo Identificar clases de diseo arquitectnicamente significativas Traduccin de las clases de anlisis significativas a clases de diseo
126 de 297

Diseo de la arquitectura: Identificar de nodos y configuracin de red (sistemas distribuidos): Se estudia la concurrencia y distribucin requerida por el sistema. Se generan nuevas versiones de la vista de la arquitectura de los modelos de diseo y despliegue y se incluyen en la descripcin de la arquitectura.

127 de 297

Diseo de la arquitectura. Diseo de un caso de uso: Se entra en muchos ms detalles que en el anlisis, es necesario adaptar el modelo de anlisis al de diseo para que ste pueda funcionar, ya que est limitado por los mecanismos de diseo. Los paquetes y las clases de anlisis proporcionan una forma directa de encontrar subsistemas y clases de diseo. Diseo de una clase: Se disean las clases que participarn en las realizaciones de los casos de uso del apartado anterior.

128 de 297

Diseo de la arquitectura.
Diseo de un caso de uso. Diseo de una clase.

Diseo de un subsistema: Se disean los subsistemas resultantes del diseo de la arquitectura, se actualiza si es necesario la vista de la arquitectura del modelo de diseo.

129 de 297

Diseo de la arquitectura.
Diseo de un caso de uso. Diseo de una clase.

Diseo de un subsistema.

130 de 297

Implementacin: Lnea base de la arquitectura:
Deber estar bajo el control de alguna herramienta. Se implementan y prueban los componentes arquitectnicamente significativos a partir de los elementos de diseo homlogos. El resultado es la lnea de base implementada a partir de menos del 10% de los casos de uso.
Actividades:
Implementacin de la arquitectura: En base a la vista de la arquitectura de los modelos de diseo 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 implementacin.
131 de 297

Implementacin: Lnea base de la arquitectura. Actividades:
Implementacin de la arquitectura. Implementacin de una clase (subsistemas implcitos): Se implementan las clases de diseo relevantes para la creacin de la lnea de base de la arquitectura en trminos de componentes. Las pruebas unitarias aseguran que cada componente funciona como una unidad. La lnea de base de la arquitectura resultante es una versin ejecutable preliminar del sistema. Integrar el sistema: Se establece un plan de integracin y se integran los subsistemas y los componentes correspondientes en una lnea de base de la arquitectura ejecutable.
132 de 297

Implementacin: Lnea base de la arquitectura. Actividades:
Implementacin de la arquitectura. Implementacin de una clase (subsistemas implcitos). Integrar el sistema.

133 de 297

Prueba: Alcance:
Hay que asegurarse de que los subsistemas de servicio y de diseo de todas las capas funcionan, slo se podrn probar componentes ejecutables. En las capas ms bajas de la arquitectura se prueban los mecanismos de distribucin, almacenamiento, recuperacin (persistencia) y concurrencia de objetos, as como otros mecanismos. Se comprueba no slo la funcionalidad sino tambin el rendimiento. En las capas especficas y generales de la aplicacin las pruebas miden la facilidad de escalar el sistema al incorporar nuevos subsistemas que usan interfaces y previstas.

134 de 297

Prueba: Alcance. Actividades:
Planificar las pruebas: Se seleccionan los objetivos que evaluarn la lnea de base de la arquitectura. Disear las pruebas: Se identifican los casos de prueba necesarios y se preparan procedimientos de prueba para comprobar la sucesiva integracin de subsistemas hasta completar la lnea de base de la arquitectura. Realizar pruebas de integracin: Se comprueba cada construccin. Realizar pruebas del sistema: Una vez se ha integrado el sistema se prueba.
135 de 297

Prueba: Alcance. Actividades. Evaluacin:
Se revisan los resultados de las pruebas para verificar que se cumplen los objetivos originales o para decidir cmo modificar los casos de prueba para alcanzar dichos objetivos.

136 de 297

Prueba: Alcance. Actividades. Evaluacin.

137 de 297
Desarrollo del anlisis de negocio

Anlisis del negocio: Alcance:
Se mitigan los riesgos y se desarrolla la lnea de base de la arquitectura para poder comenzar la fase de construccin con la seguridad de construir el producto dentro de los lmites del negocio. Lmites del negocio: La planificacin, esfuerzo y costes estimados para una calidad dada. La recuperacin de la inversin, indicando que el sistema propuesto ser econmicamente un xito. Se deben estrechar los mrgenes de error ampliamente respecto a la fase de inicio, preparndose la apuesta econmica y desarrollndose el anlisis de negocio dentro de los mrgenes de la prctica empresarial.
138 de 297

Anlisis del negocio: Alcance. Actividades:
Preparar la apuesta econmica: La fase de construccin 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 tamao del proyecto y la productividad de la organizacin de desarrollo. La productividad se deriva de la experiencia.

139 de 297

Preparar la apuesta econmica: El tamao estimado se basa en el trabajo realizado en esta fase que permite estimar el que se realizar en la fase de construccin, lo proporciona la lnea de base de la arquitectura. Si el proyecto presenta riesgos de cierta magnitud se investigan hasta estimar cunto tiempo y esfuerzo llevar superarlos. Actualizar la recuperacin de la inversin: En caso de ser un producto para la venta los expertos en ventas debern considerar nmero 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.
140 de 297

Preparar la apuesta econmica. Actualizar la recuperacin de la inversin.

141 de 297
Evaluacin:
Actividades: Comprobar que la lnea de base de la arquitectura representa una arquitectura capaz de llevar a cabo los objetivos iniciales y mitigar los riesgos. Al final de cada iteracin se evala si se han conseguido los objetivos establecidos, en caso contrario se reorientan las iteraciones siguientes. Al final de esta fase la evaluacin debe convencer a todos los implicados en el proyecto de que se han mitigado los riesgos graves y se ha construido una lnea de base de la arquitectura estable.
Ventajas:
Al haber involucrado al cliente en los hitos secundarios, ste estar ms preparado para encarar los hitos principales y habr tenido oportunidad de sugerir mejoras, de participar en el proceso.

142 de 297
Evaluacin: Actividades. Ventajas. Conclusin:
Si la evaluacin es satisfactoria el sistema podr ser construido de acuerdo al plan del proyecto y a la apuesta econmica para la fase de construccin.

143 de 297
Evaluacin: Actividades. Ventajas. Conclusin.

144 de 297
Planificacin de la fase de Construccin

Se planifica de forma detallada la primera iteracin de la fase de construccin y se esbozan en trminos generales las iteraciones restantes. El nmero de iteraciones depende del tamao y complejidad del proyecto. En cada iteracin se esbozan una serie de construcciones que aadirn piezas relativamente pequeas Se planifica el orden en que se investigarn los riesgos remanentes con objeto de mitigar cada uno de ellos antes de que aparezca en la secuencia de construcciones o iteraciones.

145 de 297
Planificacin de la fase de Construccin

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 lnea de base de la arquitectura ya que las interfaces previamente definidas permitirn 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 slidas.

146 de 297
Productos generados
1. Modelo de negocio completo que describa el contexto del sistema. 2. Nueva versin de todos los modelos; casos de uso, anlisis, diseo, despliegue e implementacin. 3. Lnea de base de la arquitectura. 4. Descripcin de la arquitectura que incluya vistas de los modelos. 5. Lista de riesgos actualizada. 6. Plan de proyecto para las fases de construccin y transicin. 7. Manual de usuario preliminar (opcional). 8. Anlisis de negocio completo, incluida la apuesta econmica.

147 de 297
Inicio Fin Fin
Inicio
ASI 4.2 Inicio-Inicio, Fin-Fin Realizacin de casos de uso ASI 4.1
Fi Inic n io
Inicio
Inicio
ASI 5.1 Responsabilidades y atributos de las clases anteriores
Inicio
Inicio
Identificacin de clases de anlisis
Fin
Fin
Fin
Fin
ASI 5.2 Identificacin de agregaciones y asociaciones
Inicio
Inicio
ASI 5.3 Identificacin de generalizaciones
Fin
Fin
Validacin de casos de uso anteriores
Fin
Inicio Fin
Inicio Fin
n Fi
Inicio
Fin
ASI 1.3 Inicio-Inicio Normas y estndares ASI 9.1 Verificacin de la arquitectura del sistema
ASI 2.3 Inicio-Inicio, Fin-Fin Casos de uso arquitectnicamente significativos ASI 2.4 i ci o
io Inic Fin
In
Fin
ASI 4.2 Anlisis de realizaciones de casos de uso, descripcin de interaccin de objetos
Fi Ini n c io
ASI 3.1 Descripcin de subsistemas e interfaces
Inicio
Inicio
ASI 3.2 Integracin de subsistemas
io Inic
ASI 9.2
Fin
Inicio
Fin
Inicio
Fin
Fin
Anlisis de consistencia muy exhaustivo de la arquitectura
In ici o i In cio
n Fi
c Ini Fin
ASI 8.3 Definicin de alguna pantalla necesaria para la comprensin de un caso de uso concreto ASI 8.4 Identificacin y especificacin de los dilogos considerados crticos ASI 8.5 Formatos de impresin, caso muy concreto
io
Inicio
Inicio
Inicio
Inicio
Fin
Fin Ini c io
Inicio
Inicio Fin
Fin
In ic io In ici o
Inicio Fin
Fi Ini n c io
Fin
In Fi icio n
I Finnicio Inic i Fin o
Inicio Fin
Inicio Fin
Ini Fin cio
Inic io Fin
Inicio
Fin
Inic
Fi n
io I n ic io
Fin
Inicio
Fi n Inic io
Fin
EVS 4.2 Inicio-Inicio, Fin-Fin Alternativas de solucin EVS-CAL 1.1 Se constituye el equipo de calidad y el plan de accin EVS-CAL 1.2 Determinacin de sistemas objeto del aseguramiento de la calidad
EVS 5.3 Inicio-Inicio, Fin-Fin Alternativas de solucin
Inicio
Inicio
Fin
Inicio
Fin
Fin
EVS-CAL 1.3 Identificacin de propiedades de calidad
Inicio Inicio
Fin
Fin
EVS-CAL 2.1 Necesidad del plan de aseguramiento de la calidad de cada alternativa
Inicio Inicio
Fin
Fin
EVS-CAL 2.2 Alcance del plan de aseguramiento de la calidad de cada alternativa
Inicio Fin Fin
Inicio Fin
EVS-CAL 2.3 Anlisis de consistencia de la arquitectura
EVS 6.2 Fin-Inicio Solucin propuesta EVS-CAL 3.1 Ajuste del plan a la solucin selecionada
EVS 6.3 Fin-Inicio Solucin aprobada EVS-CAL 3.2
Fin
Inicio
Inicio
Aprobacin del plan de la solucin
ASI 2.4 Inicio-Inicio EVS-CAL 3.1 Fin-Inicio Plan para la solucin ASI-CAL 1.1 Definicin detallada del plan de aseguramiento de la calidad de la solucin Catlogo de requisitos ASI-CAL 3.1 Revisin del catlogo de requisitos
ASI 9.3 Inicio-Inicio, Fin-Fin Validacin de la arquitectura ASI-CAL 3.2 Revisin de consistencia de productos
ASI 10.3 Fin-Inicio Plan de pruebas ASI-CAL 4.1
Inicio Inicio
Fin
Inicio
Inicio
Inicio
ASI-CAL 2.1 Actividades y tareas del plan
Inicio
Inicio
Fin
Fin
Revisin del plan de pruebas
Fin
Fin
In ici o In ici o
DSI 7.2 Inicio-Inicio, Fin-FIn Anlisis de consistencia de la arquitectura DSI-CAL 1.1 Revisin de consistencia de productos del diseo DSI 7.3 Fin-Inicio Aceptacin del diseo DSI-CAL 1.2 DSI 10.2 Inicio-Inicio, Fin-Fin Pruebas DSI-CAL 2.1 Revisin de pruebas unitarias, del sistema y de aceptacin DSI 10.3 Inicio-Inicio, Fin-Fin Pruebas
Inicio Inicio
DSI-CAL 2.2 Revisin del plan de pruebas
Fin
Inicio
Aceptacin de la arquitectura del sistema
Fin
Inicio
Fin
Fin
CSI 2.2 Inicio-Inicio, Fin-Fin Cdigo generado CSI-CAL 1.1 Revisin de normas de construccin
CSI 3.2 Inicio-Inicio, Fin-Fin Pruebas unitarias CSI-CAL 2.1
CSI 4.3 Inicio-Inicio, Fin-Fin Pruebas de integracin
CSI 5.3 Inicio-Inicio, Fin-Fin Pruebas del sistema CSI-CAL 2.3 Revisin de pruebas del sistema
Inicio Inicio
CSI-CAL 2.2 Revisin de pruebas de integracin
Inicio Inicio
Fin
Inicio
Revisin de pruebas unitarias
Fin
Fin
Fin
Fin
PSI 9.2, EVS 3.2 Inicio-Inicio, Fin-Fin Arquitectura y requisitos EVS-GC 1.1 Requisitos de la gestin de la configuracin
EVS 6.2 Fin-Inicio Solucin propuesta EVS-GC 2.1
Inicio Inicio
Inicio Inicio
Plan de gestin de la configuracin
Fin
Fin
EVS-GC 2.2 Entorno tecnolgico para la gestin de la configuracin
GC 1.1 Identificacin y registro de productos generados en esta fase
GC 2.1 Identificacin y registro de productos globales
EVS 6.2 Fin-Inicio Solucin propuesta GPI 1.1 Estimacin del esfuerzo, identificacin de elementos a desarrollar
Inicio Inicio
GPI 1.2 Clculo del esfuerzo
GPI 2.1
Fin
Inicio
Fin
Fin
Seleccin de la estrategia de desarrollo
Fin
Inicio
GPI 2.2 Adaptacin de la metodologa al proyecto
GPI 2.3
Inicio Inicio
GPI 2.4 Planificacin general del proyecto
GPI 2.5
Fin
Inicio
Calendario de hitos y entregas
Fin
Inicio
Fin
Fin
Aceptacin de la planificacin
GPI 2.4 Inicio-Inicio, Fin-Fin Planificacin del proyecto GPS 1.1 Asignacin de tareas a miembros del proyecto
GPS 3.1 Seguimiento de tareas GPS 2.1 Comunicacin de la asignacin de tareas al equipo
GPS 4.2
Inicio Fin Fin

Fin
Inicio Fin
Inicio Fin Inicio Fin
Inicio Fin
Propuesta de solucin a la incidencia
Inicio
Inic i
Inicio Fin
GPS 4.1 Gestin de incidencias, anlisis del impacto
GPS 4.3
Fin
Inicio
Registro de la incidencia
o
GPS 10.1 Resumen final de una tarea finalizada
cio Ini n Fi Ini cio n Fi
GPS 3.1 Inicio-Inicio, Fin-Fin Seguimiento de tareas GPS 11.1 Actualizacin de la planificacin de tareas
Inicio Inicio
Fin
Fin
GPS 11.2 Simulacin, extrapolacin de la situacin del proyecto
Inicio Inicio
GPS 11.3 Informe de seguimiento
Inicio Inicio
GPS 12.1 Reunin interna de seguimiento
Fin
Fin
Fin
Fin
FASE DE CONSTRUCCIN

155 de 297
Fase de Construccin
Objetivos: Se pretende tener un producto preparado para ser distribuido como versin 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 construccin tendr lugar dentro de los lmites del plan de negocio.
Mitigar todos los riesgos, excepto los que derivan de la operacin con el sistema que son tratados en la fase de transicin. Ajustar la construccin a la arquitectura.
Sin embargo, se puede modificar la arquitectura para incorporar los cambios que surjan en esta fase si es necesario.

156 de 297
Fase de Construccin
Actividades (A partir de la lnea de base de la arquitectura): Culminacin de las tareas de identificacin de requisitos, anlisis, diseo e implementacin iniciadas en fases anteriores.
Se detallan los casos de uso y escenarios restantes, se modifica si es necesario la descripcin de la arquitectura y se cierran los modelos de anlisis, diseo e implementacin.
Asignacin de prioridad a los casos de uso, agrupndolos en construcciones e iteraciones y desarrollndolos en un orden que evite la vuelta atrs. Mantenimiento de la integridad de la arquitectura, modificndola slo cuando sea necesario. Integracin y prueba de cada subsistema y del sistema completo. Seguimiento de riesgos crticos arrastrados de fases anteriores y mitigacin si se materializan. Actualizacin de la lista de riesgos.
157 de 297
Fase de Construccin
Enfoque: Se cambia el enfoque del proyecto, as mientras las fases de inicio y elaboracin se centraban en la acumulacin del conocimiento bsico necesario para construir el proyecto, investigacin, la de construccin se centra en la construccin propiamente dicha del sistema dentro de unos parmetros de coste, esfuerzo y agenda, desarrollo. Consideraciones: Esta fase requiere ms personal, ms tiempo y ms iteraciones que las anteriores, por eso es tan importante tener bien preparados todos los detalles antes de empezar esta fase.

158 de 297
Fase de Construccin
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 iteracin sean los correctos, y evita tener que dar marcha atrs y rehacer una iteracin previa debido a algo aprendido ms tarde.

159 de 297
Fase de Construccin
Tareas preliminares: Planificacin:
Es posible que la planificacin de la fase de construccin se modifique de acuerdo con la autorizacin recibida por los responsables financieros.
Asignacin de personal:
La divisin del trabajo se realiza basndose en la que en la lnea de base de la arquitectura se representa con subsistemas e interfaces. El nmero de trabajadores es aproximadamente el doble del de la fase de elaboracin.
Establecimiento de criterios de evaluacin:

Los criterios de evaluacin para los casos de uso se basan en los requisitos funcionales y no funcionales relacionados con el caso de uso.

160 de 297
Fase de Construccin
Tareas preliminares: Planificacin. Asignacin de personal. Establecimiento de criterios de evaluacin:
El material adicional debe ser evaluado: Material de usuario: Guas de usuario, textos de ayuda, notas de versin, manuales de usuario. Son suficientes para dar soporte a los usuarios en la fase de transicin? Material de cursos: Diapositivas, notas, ejemplos y tutoriales. Son suficientes para dar soporte a los usuarios en la fase de transicin?

161 de 297
Fase de Construccin
Tareas preliminares: Planificacin. Asignacin de personal. Establecimiento de criterios de evaluacin.

162 de 297
Fase de Construccin
Trabajo a realizar en cada iteracin: Cuatro grupos de actividades ejecutndose en paralelo:
La planificacin. Los cinco flujos de trabajo fundamentales. La evaluacin. El anlisis de negocio.

163 de 297
Fase de Construccin
Construccin 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 realizacin de los casos de uso diseando los subsistemas y clases necesarias, implementndolos como componentes y probndolos tanto de forma individual como en construcciones. Los incrementos se ordenan de forma progresiva para que no sea necesario volver atrs. Construir con incrementos relativamente pequeos reduce el mbito de los flujos fundamentales y asla en gran parte los riesgos y defectos hacindolos ms fciles de localizar y tratar. Pueden aparecer riesgos nuevos a medida que se realizan construcciones y los usuarios prueban nuevos incrementos.
164 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 diseo, convirtindose el prototipo en la especificacin de la interfaz de usuario.

165 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 aaden a la clasificacin realizada en la fase anterior con objeto de establecer su prioridad.

166 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 segn su importancia. Estructurar el modelo de casos de uso: Ya que la arquitectura es estable los cambios deben referirse a los casos de uso an no desarrollados.

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. Estructurar el modelo de casos de uso.

168 de 297

Anlisis: Alcance:
Se tienen en cuenta todos los casos de uso pero eso no significa que haya que extender el modelo de anlisis, puede que ste no se mantenga y se cree uno nuevo. La vista de la arquitectura, la parte realizada en la fase de elaboracin, ser slo un subconjunto del modelo de anlisis.
Objetivo:
Si se mantiene el objetivo ser completarlo al final de esta fase.
Actividades:
Anlisis de la arquitectura: Actualizaciones, trabajo mnimo. Analizar un caso de uso.
169 de 297

Anlisis: Alcance. Objetivo. Actividades:
Anlisis de la arquitectura. Analizar un caso de uso. Analizar una clase. Analizar un paquete: Se refinan para adaptarlos a los nuevos casos de uso.

170 de 297

Anlisis: Alcance: Objetivo: Actividades:
Anlisis de la arquitectura. Analizar un caso de uso. Analizar una clase. Analizar un paquete.

171 de 297

Diseo:
Alcance: Se disea e implementa el 90% de los casos de uso, los no incluidos en la lnea de base de la arquitectura. Se actualizarn, introduciendo mejoras, los modelos de diseo y despliegue. Actividades: Diseo de la arquitectura: Por lo general no se aaden subsistemas de diseo ni de servicio. Se pueden aadir subsistemas similares o alternativos a los existentes.

172 de 297

Implementacin: Alcance:
Se implementan y se llevan a cabo las pruebas de unidad de todos los componentes, trabajando a partir del modelo de diseo. Se obtiene la versin operativa inicial, que representa el 100% de los casos de uso. En cada construccin se van completando partes de los componentes hasta que tras la ltima construccin, esto es, la ltima iteracin, todos los componentes est completos.
Actividades:
Implementacin de la arquitectura: Actualizaciones, poco trabajo.

173 de 297

Implementacin: Alcance. Actividades:
Implementacin de la arquitectura. Implementacin de una clase y de un subsistema: Se implementan las clases y subsistemas del modelo de implementacin, y las clases stub cuando sea necesario para armar una construccin. Realizar prueba de unidad: Si es necesario se corregir el diseo y la implementacin del componente.

174 de 297

Implementacin de la arquitectura. Implementacin de una clase y de un subsistema. Realizar prueba de unidad. Integrar el sistema: Se crea un plan de integracin de construcciones que perfile la secuencia de construcciones. El plan muestra los casos de uso o escenarios que se van a implementar en la construccin. Normalmente se empiezan a construir las capas inferiores (la del software del sistema o la intermedia), las construcciones siguientes se expandirn hacia arriba (capas general y especfica de la aplicacin).
175 de 297

Implementacin de la arquitectura. Implementacin de una clase y de un subsistema. Realizar prueba de unidad. Integrar el sistema: Es difcil montar una construccin sin las funciones de apoyo que proporcionan las capas inferiores. Se reunirn clases completas y stub en una construccin ejecutable de acuerdo con el plan de construccin, realizando construcciones cada vez mayores, mientras los encargados de las pruebas de integracin y regresin las comprueban.

176 de 297

Implementacin de la arquitectura. Implementacin de una clase y de un subsistema. Realizar prueba de unidad. Integrar el sistema: Al final de cada iteracin se conecta el sistema entero y se hacen pruebas de integracin y regresin. Esta planificacin establece la secuencia de construcciones e iteraciones de esta fase. A menudo existen dependencias de compilacin de las capas superiores respecto a las capas inferiores, puede que haya que planificar la compilacin de abajo a arriba.

177 de 297

Implementacin de la arquitectura. Implementacin de una clase y de un subsistema. Realizar prueba de unidad. Integrar el sistema.
Representacin de componentes no construidos:

Facilitan la limitacin del tamao de la construccin. Stub elemento muy sencillo que simplemente proporciona una respuesta a un estmulo, a todos aquellos que un componente puede recibir de otros componentes de la construccin. Driver proporciona estmulos a los otros componentes que forman parte de la construccin que se est probando.
178 de 297

Implementacin de la arquitectura. Implementacin de una clase y de un subsistema. Realizar prueba de unidad. Integrar el sistema.
Representacin de componentes no construidos.

179 de 297

Prueba: Actividades:
Planificar pruebas: Se seleccionan los objetivos que comprueben las sucesivas construcciones y finalmente el propio sistema. Disear pruebas: Se determina cmo 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 an sean tiles y se modifican para utilizarlos en pruebas de regresin de las construcciones posteriores. Se verifican los componentes que deben ser comprobados conjuntamente, pruebas de integracin, verificando las interfaces entre los componentes y comprobando que stos pueden trabajar conjuntamente.
180 de 297

Planificar pruebas. Disear pruebas. Realizar pruebas de integracin: Se ejecutan los casos de prueba siguiendo los procedimientos de prueba. Si la construccin supera las pruebas, se van aadiendo 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 construccin. Corregir en la siguiente. Si el fallo es muy grave, asignar un equipo cualificado para investigarlo.
181 de 297

Prueba: Actividades: Planificar pruebas.
Disear pruebas. Realizar pruebas de integracin. Realizar pruebas del sistema: Cuando se termina una iteracin se obtiene una versin 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 versin operativa inicial

182 de 297

Planificar pruebas. Disear pruebas. Realizar pruebas de integracin. Realizar pruebas del sistema. Evaluar las pruebas: A medida que transcurren las pruebas de integracin y del sistema se revisarn los resultados al final de cada construccin en funcin 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 debern ser modificados.

183 de 297

Planificar pruebas. Disear pruebas. Realizar pruebas de integracin. Realizar pruebas del sistema. Evaluar las pruebas.

184 de 297
Control del anlisis de negocio

Actividades: Se compara el progreso real al final de cada iteracin con la agenda, esfuerzo y costes planificados en la fase de elaboracin. Se revisan los datos de productividad del proyecto. Medicin del progreso: El cdigo desarrollado no es una buena medida puesto que uno de los objetivos es la reutilizacin de cdigo, una medida ms efectiva es la finalizacin de construcciones e iteraciones de acuerdo con el plan. Actualizacin: A medida que se adquiere un mayor conocimiento sobre los costes y capacidades del producto, puede ser necesario actualizar el anlisis del negocio y comunicar el nuevo anlisis a los inversores.

185 de 297
Evaluacin de las iteraciones

Actividades: Revisar lo logrado en una iteracin contrastndolo con lo que se haba planificado. Planificar en cul de las iteraciones siguientes se realizar el trabajo no completado. Actualizar la lista de riesgos. Completar el plan de la iteracin siguiente. Al final de la ltima iteracin 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 transicin. Actualizar el plan del proyecto.
186 de 297
Planificacin de la fase de Transicin

Aspectos conocidos: Se sabe que se van a producir versiones beta para los usuarios. Slo se podr planificar: seleccin 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.
187 de 297
Productos generados
1. Plan de proyecto para la fase de transicin. 2. Sistema software ejecutable, versin con capacidad operativa inicial. sta es la construccin final de la fase. 3. Todos los artefactos, incluyendo los modelos del sistema. 4. Descripcin de la arquitectura, mnimamente modificada y actualizada. 5. Versin preliminar del manual de usuario, lo suficientemente detallado como para guiar a los usuarios de la versin beta. 6. Anlisis de negocio, que refleja la situacin al final de la fase. 7. La operacin del software en la comunidad de usuarios durante la fase de transicin puede desvelar que algn producto no es correcto, en ese caso se modificar para que lo sea.

188 de 297
ASI 8.1 ASI 1.3 ASI 1.1 Procesos y requisitos de la solucin, glosario, modelo de negocio, se completa la labor de la fase anterior Definicin final de los principios generales de interfaz de usuario
Inicio Fin
Inicio Fin
Catlogo de normas
Inicio
Inicio
Inicio Fin
Inicio Fin
ASI 2.1 Modelo de casos de uso, se completa si es necesario
Inicio Fin
Inicio Fin
ASI 2.2 Especificacin de casos de uso restantes
Inicio Fin
Inicio Fin
ASI 2.3 Anlisis riguroso de los casos de uso de ASI 2.2
ASI 4.2 Inicio-Inicio, Fin-Fin Realizacin de casos de uso ASI 4.1 Identificacin de clases de anlisis ASI 5.1 Responsabilidades y atributos de las clases anteriores ASI 5.2 Identificacin de agregaciones y asociaciones, revisin de la especificacin de subisistemas para su posible optimizacin ASI 5.3 Identificacin de generalizaciones
Inicio
Inicio
Inicio
Inicio
Inicio
Inicio
Fi Inic n io
Fin
Fin
Fin
Fin
Fin
Fin
Fi Inic n i
ASI 2.3 Inicio-Inicio, Fin-Fin Casos de uso restantes ASI 2.4 Validacin de casos de uso anteriores
Fin
Inicio
Inicio Fin
Inicio
Fin
io Inic in F
io Inic Fin
Inicio
ASI 1.3 Inicio-Inicio Normas y estndares ASI 9.1
Fin
n Fi
ASI 3.1 Introduccin de actualizaciones y mejoras en los subsistemas
Inicio
Inicio
Fin
Fin
ASI 3.2 Revisar consistencia si se introdujeron modificaciones en la tarea anterior
ASI 9.2
Fin
Inicio
Verificacin de todos los modelos
Fin
Inicio
Anlisis de consistencia de todos los modelos
o ici In o ici In
n Fi
Ini Fin
ASI 8.3 Definicin de formatos individuales de pantalla ASI 8.4 ASI 8.5 Especificacin del comportamiento dinmico de las interfaces Especificacin de formatos de impresin,
cio
Inicio
Inicio
Inicio
Inicio
Inicio
Inicio Fin
cio Ini in F
Inicio Fin
Fi Ini n cio
In Fi icio n
Inicio Inicio Fin Fin
i In
cio
Fin
Fi
n
cio n Ini Fi
DSI 1.7 Fin-Inicio Operacin y seguridad DSI 1.3,1.4 Inicio-Inicio, DSI 1.6,3.3,3.4,6.4 Fin-Inicio Productos de diseo DSI 7.1 Verificacin del diseo (Calidad), modelo de datos optimizado DSI 7.3 Aceptacin del anlisis realizado anteriormente DSI 11.2 DSI 11.1 Especificacin de requisitos de documentacin de usuarios beta
DSI 7.3,8.4,9.4,10.3 Fin-Inicio Productos de diseo DSI 12.1
Inicio
Inicio
DSI 7.2 Anlisis de consistencia del diseo
Fin
Inicio Fin
In Fi icio n
Inicio
Inicio Inicio Fin Fin Inicio Fin
Requisitos de implantacin
Fin
Inicio
Aprobacin del diseo del sistema
CSI 7.1 Primera versin del esquema de formacin de usuarios finales
Inicio Fin
Inicio Fin
Fin
Fin
Inicio Fin
Inicio Fin
CSI 7.2 Especificacin de recursos y entorno de formacin
DSI 10.2
In ic Fi io n
DSI 8.2 Definicin de componentes y subsistemas de implementacin como traduccin directa del diseo
Inicio Fin Inicio Fin Inic Fi n i o
Inicio Fin
Especificacin de los niveles de prueba DSI 8.3
Inicio Fin
Inicio Fin
DSI 8.4 Especificacin del modelo fsico de datos
io I ni c Fin
Inicio Fin
Inic io Fin
Especificacin en psedocdigo de componentes
Fin
Inicio
CSI 1.1 Implantacin de la BD o el sistema de ficheros
io I ni c in F
DSI 1.7 Fin-Inicio Operacin y seguridad CSI 2.1 Generacin del cdigo de los componentes de DSI 8.2
Inicio Inicio
Fin
Fin
CSI 2.2 Generacin de cdigo de los procedimientos de operacin y seguridad
Inicio
Inicio
CSI 6.1 Completar el manual de usuarios beta CSI 8.1 Preparacin del entorno de migracin y carga inicial de datos
Fin
Fin
DSI 9.1 Especificacin del entorno de migracin y carga inicial
Inicio
Inicio
Fin
Fin
DSI 9.2 Diseo de procedimientos de migracin y carga inicial
Inicio Inicio
Fin
Fin
DSI 9.3 Diseo de componentes de migracin y carga inicial
Inicio
Inicio
Fin
Fin
DSI 9.4 Revisin del plan de migracin y carga inicial
Inicio Fin
F in
Inicio Fin
In i c
CSI 2.2 Inicio-Inicio, Fin-Fin Cdigo generado DSI 10.2 Inicio-Inicio, Fin-Fin Pruebas DSI 10.3 Especificacin del plan de pruebas CSI 3.1 Preparacin del entorno de pruebas unitarias CSI 3.2 Realizacin y evaluacin de las pruebas unitarias CSI 2.2 Inicio-Inicio, Fin-Fin Cdigo generado CS 4.1 Preparacin del entorno de pruebas de integracin CSI 4.2
io
CSI 8.2 Generacin de cdigo de los componentes y procedimientos de la migracin y carga inicial de datos
CSI 8.3
Inicio Inicio
Fin
Fin
Realizacin y evaluacin de las pruebas de migracin y carga inicial de datos
Fin
Inicio
Fin
Inicio
Inicio
Inicio
Fin
Inicio
Fin
Fin Inic io
Inicio
CSI 2.2 Fin-Inicio Cdigo generado CSI 5.2
Realizacin de pruebas de integracin
Fin
Fin
Inicio
Inicio
Fin
Inicio
Fin
Fin
DSI 7.3 Fin-Inicio ASI 2.4 Inicio-Inicio, Fin-Fin Catlogo de requisitos ASI-CAL 2.1 Actividades y tareas del plan de calidad ASI 9.3 Inicio-Inicio, Fin-Fin Validacin de la arquitectura ASI-CAL 3.2 Revisin de consistencia de productos ASI 10.3 Fin-Inicio Plan de pruebas ASI-CAL 4.1 DSI 7.2 Inicio-Inicio, Fin-FIn ASI 11.1 Fin-Inicio ASI aprobado ASI-CAL 5.1 Anlisis de consistencia de la arquitectura DSI-CAL 1.1 Revisin de consistencia de productos del diseo Aceptacin del diseo DSI-CAL 1.2 Aceptacin de la arquitectura del sistema, incluida la interfaz de usuario y el modelo de datos optimizado DSI 10.2 Inicio-Inicio, Fin-Fin Pruebas DSI-CAL 2.1 Revisin de pruebas unitarias, del sistema y de aceptacin
Inicio
Inicio
ASI-CAL 3.1 Revisin del catlogo de requisitos
Inicio Inicio
Fin
Inicio
Fin
Fin
Fin
Inicio
Registro de aprobacin del ASI
Fin
Inicio
Fin
Inicio
Fin
Inicio
DSI 10.3, DSI-CAL 2.1 Inicio-Inicio, Fin-Fin Pruebas DSI-CAL 2.2 Revisin del plan de pruebas
DSI 11.1 Inicio-Inicio, Fin-Fin Documentacin de usuario
DSI 11.2 Inicio-Inicio, Fin-Fin Implantacin DSI-CAL 3.2 Revisin de requisitos de implantacin
DSI 12.1 Fin-Inicio DSI aprobado DSI-CAL 4.1
CSI 2.2 Inicio-Inicio, Fin-Fin Cdigo generado CSI-CAL 1.1
Inicio Inicio
Fin
Fin
DSI-CAL 3.1 Revisin de requisitos de documentacin de usuario
Inicio Inicio
Inicio Inicio
Inicio Inicio
Fin
Inicio
Fin
Fin
Registro de aprobacin del DSI
Fin
Inicio
Revisin de normas de construccin
Fin
Inicio
Fin
Fin
Fin
Fin
CSI 6.1, CSI-CAL 2.3 Inicio-Inicio, Fin-Fin Manual de usuario CSI-CAL 3.1 Revisin de manuales de usuario
CSI 7.2 Inicio-Inicio, Fin-Fin Esquemas de formacin
Inicio Inicio
CSI-CAL 4.1 Revisin de esquemas de formacin
Fin
Fin
GPS 3.1 Seguimiento de tareas
Inicio Inicio
GPS 13.1 Aceptacin interna GPS 2.1 Comunicacin de la asignacin de tareas al equipo
GPS 4.2 Propuesta de solucin a la incidencia
GPS 1.1 Asignacin de tareas a miembros del proyecto
Inicio Fin
Fin
Inicio Fin
Fin Fin
Inicio
Fin
Fin Inicio
Fin
Inic io
Inicio
GPS 4.3
Fin
Inicio
GPS 7.1 Aprobacin de la solucin
GPS 5.1 Registro de la peticin de cambio de requisitos
GPS 6.1
Inicio Inicio
GPS 6.2 Anlisis del impacto
Inicio Inicio
GPS 6.3 Alternativas y propuesta de solucin
Fin Fin
Inicio
Fin
Inicio
Anlisis de la peticin
Inicio
Fin
Fin
Fin
Fin
GPS 8.1 Estimacin del esfuerzo para el cambio
GPS 9.1 GPS 8.1 Inicio-Inicio, Fin-Fin Cambio GPS 8.2 Planificacin de cambios Registro de la solucin adoptada GPS 3.1 Fin-Inicio Seguimiento GPS 11.1 Actualizacin de tareas
Fin Inicio Fin
Inicio
Inicio Inicio
Inicio Fin
Fin
Fin
Inicio Inicio
Inicio Inicio
Fin
Fin
Fin
Fin
ASI 10.3 Fin-Inicio ASI 2.1 Inicio-Inicio Catlogo de requisitos ASI-SEG 2.1 Estudio de funciones y mecanismos de seguridad necesarios ASI 10.3 Inicio-Inicio, Fin-Fin Pruebas Fin del ASI ASI-SEG 4.1 Clasificacin y catalogacin de los productos del ASI DSI 8.4 Inicio-Inicio, Fin-Fin Entorno de construccin DSI-SEG 3.1 Requisitos de seguridad del entorno de construccin CSI 7.1 Inicio-Inicio, Fin-Fin Formacin usuarios finales
Inicio Inicio
Fin
Fin
ASI-SEG 3.1 Inclusin de criterios de seguridad en las pruebas
Inicio Inicio
CSI-SEG 3.1 Plan de formacin de seguridad
Fin
Fin
DSI 1.7, ASI-SEG 4.1,2.1 Inicio-Inicio, Fin-Fin Pruebas DSI-SEG 4.1 Diseo de pruebas de seguridad
DSI 10.3 Fin-Inicio CSI 3.2,4.2,5.2 Inicio-Inicio, Fin-Fin Pruebas Fin del DSI DSI-SEG 5.1 Clasificacin y catalogacin de los productos del DSI
CSI 5.3 Fin-Inicio Fin del CSI CSI-SEG 4.1 Clasificacin y catalogacin de los productos del CSI
Inicio Inicio
CSI-SEG 2.1 Evaluacin de las pruebas de seguridad
Fin
Fin
FASE DE TRANSICIN

194 de 297
Fase de Transicin
Alcance: Se acomete la prueba de la versin beta del sistema generada en la fase de construccin. Actividades: Preparacin de las actividades, como la preparacin del entorno. Aconsejar al cliente sobre actualizaciones del entorno en el que se ejecutar el software. Preparacin de manuales y en general del material necesario para la entrega del producto. Ajustar el software para que funcione con los parmetros actuales del entorno de usuario. Corregir los defectos encontrados a lo largo de las pruebas realizadas a la versin beta. Realizar las modificaciones necesarias cuando se detecten problemas que no haban sido previstos.
195 de 297
Fase de Transicin
Actividades desarrollo: para la organizacin de
Encontrar, discutir, evaluar y registrar las lecciones aprendidas a lo largo del desarrollo del sistema actual. Registrar aspectos tiles para la versin siguiente.

196 de 297
Fase de Transicin
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 de construccin.

197 de 297
Fase de Transicin
Objetivos: Gestionar todos los aspectos relativos a la operacin en el entorno de usuario, incluyendo la correccin de los defectos remitidos por los usuarios de la versin beta o por los encargados de las pruebas de aceptacin (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 aadirse, una nueva caracterstica debe acarrear cambios lo bastante pequeos como para introducirlos sin afectar seriamente al plan del proyecto. Si la caracterstica va a afectar a la planificacin su importancia debe ser vital. En la mayora de los casos se aade a una lista de caractersticas para el desarrollo de la siguiente versin.

198 de 297
Fase de Transicin
Respuestas: Tipos:
Si el sistema hace lo que demandan sus usuarios y el negocio. Riesgos inesperados. Problemas no resueltos. Fallos. Ambigedades y lagunas en la documentacin del usuario. reas en las que los usuarios muestren deficiencias y necesiten informacin o formacin.
Consecuencias:
Partiendo de una respuesta de este tipo, se modifica el sistema o algn artefacto relacionado. No se busca reformular el producto sino encontrar pequeas deficiencias que pasaron inadvertidas y que pueden ser corregidas en el marco de la lnea de base de la arquitectura existente.
199 de 297
Fase de Transicin
Ayuda para el uso del producto: El material de usuarios y cursos iniciado en la fase anterior debe ser reescrito de forma tcnica antes de distribuir el producto a los clientes normales, debido a que stos tendrn una preparacin menor que los usuarios beta. La relacin con el cliente puede contemplar la ayuda para crear un entorno apropiado para el producto, la formacin para usar el producto de forma efectiva, ayudar a los usuarios a llevar en paralelo la operacin del nuevo sistema con el sistema al que reemplaza o ayudar a la conversin de Bases de Datos a la nueva configuracin. Si el producto es para la venta estos servicios se construyen en el programa de instalacin, completando el servicio de asistencia telefnica.

200 de 297
Fase de Transicin
Hito principal: Lanzamiento del producto:
Es capaz de operar con xito en entornos de usuarios tpicos?

201 de 297
Fase de Transicin
Tipos de acuerdos contractuales: Produccin por parte de un fabricante de software para la venta en un determinado mercado a muchos clientes:
Aunque el tamao del mercado puede variar, siempre se da una relacin uno a muchos (un vendedor a muchos clientes) que influye en las tareas de esta fase.
Produccin por parte de un casa software para un nico cliente:

nico cliente con una nica sede. nico cliente con muchas suborganizaciones y sedes. La organizacin software desarrolla software inicialmente para un nico cliente o sede y luego lo adapta a otras sedes o clientes. La organizacin software desarrolla software para otro departamento de la misma empresa bajo acuerdos contables especficos.

202 de 297
Al comienzo de la fase de Transicin

Situacin inicial: La fase de transicin comienza con una versin operativa inicial que ha pasado las pruebas internas del sistema y la evaluacin del hito principal del final de la fase de construccin. Actividades preliminares: En esta fase se preparan artefactos adicionales, tales como programas de instalacin, de conversin o migracin de datos. Se modifican los desarrollados durante la fase de construccin para preparar el programa ejecutable para su distribucin ms all de sus propios lmites, dependiendo del patrn elegido.

203 de 297
Fase de Transicin
Planificacin: Aspectos conocidos:
Referentes a la produccin de la versin beta, la preparacin de la documentacin para las pruebas o la seleccin de usuarios.
Aspectos desconocidos:
Resultados de las pruebas beta.
Versin beta:
Se presupone que la versin beta requerir poca reelaboracin pues ese es el propsito del desarrollo iterativo, menos de un 5% aunque siempre se debe considerar que ser mayor que cero. Este trabajo se ha hecho en conjuncin con el cliente por tanto la versin beta debe estar muy prxima a lo que los clientes esperan.

204 de 297
Fase de Transicin
Planificacin: Aspectos conocidos. Aspectos desconocidos. Versin beta. Resultados:
No existe un producto software perfecto, as el objetivo es un software lo bastante bueno. Los productos se distribuyen con algn porcentaje de defectos, con ciertos requisitos postergados a versiones posteriores o con algunas necesidades descubiertas por los usuarios de la versin beta para las que la fase de transicin carece de recursos.

205 de 297
Fase de Transicin
Planificacin: Aspectos conocidos. Aspectos desconocidos. Versin beta. Resultados. Motivos que propician reelaboracin:
despreciar
la
posibilidad
de
Demasiada presin de la agenda que conduce a cometer errores debido a las prisas. Ausencia de pruebas del sistema y evaluacin adecuadas al final de la fase de construccin. Error al evaluar el considerable trabajo que an queda en la fase de transicin. La disposicin de considerar la reelaboracin como mala, como admisin de la incompetencia del proyecto.
206 de 297
Fase de transicin
Planificacin: Aspectos conocidos. Aspectos desconocidos. Versin beta. Resultados. Motivos que propician reelaboracin.
despreciar
la
posibilidad
de

207 de 297
Fase de Transicin
Asignacin de personal: Necesidades:
Necesidades de personal similares a las de la fase de construccin pero con un nfasis diferente.
Caractersticas:
La respuesta a los resultados de las pruebas beta o de aceptacin puede requerir personal ms 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 slo expertos en el sistema, sino en la naturaleza de la aplicacin.

208 de 297
Fase de Transicin
Evaluacin: Alcance:
Slo es necesario evaluar los problemas que surjan
Criterios:
Han cubierto los usuarios beta las funciones claves? Ha superado el producto las pruebas de aceptacin realizadas por el cliente? Los criterios de prueba vienen fijados por contrato entre la organizacin de desarrollo y el cliente. Las pruebas de aceptacin hacen funcionar el sistema en modo de produccin durante un periodo de tiempo previamente acordado. Tiene el material de usuario una calidad aceptable? Est listo el material de cursos necesario, incluyendo la gua del profesor, en su caso? Parecen los usuarios y clientes satisfechos con el producto?

209 de 297
Fase de Transicin
Actividades en cada iteracin: Se realizan cuatro grupos se actividades en paralelo:
Planificacin. Los cinco flujos de trabajo fundamentales. Evaluacin. Anlisis ms profundo del negocio.

210 de 297

Poca actividad, limitada a corregir problemas encontrados durante las pruebas en el entorno de usuario. El trabajo normalmente consiste en poco ms que hacer pequeas mejoras de diseo destinadas a corregir problemas o defectos o para efectuar mejoras de ltima hora. La atencin se centra en la correccin de defectos detectados durante el uso inicial, asegurarse de que la correccin en s est bien y hacer pruebas de regresin para asegurar que estas modificaciones no introduzcan nuevos defectos. La atencin se centra en la implementacin y en las pruebas.

211 de 297
Fase de Transicin
Qu se hace en esta fase: Preparar la versin beta, o de pruebas de aceptacin, a partir de la versin con capacidad operativa inicial producida durante la fase de construccin. Instalar o preparar la instalacin de la versin beta en los lugares escogidos, junto a las actividades relacionadas con dichos lugares, tales como la migracin de datos desde el sistema anterior. Actuar a partir de la informacin recogida en las instalaciones de pruebas. Adaptar el producto corregido a las circunstancias de los usuarios. Completar los artefactos del proyecto. Determinar cundo se acaba el proyecto.

212 de 297
Fase de Transicin
Qu se hace en esta fase: Preparacin de la versin beta:
La mayor parte de los usuarios beta sern experimentados. Al principio de la fase de transicin se rene la documentacin preparada con anterioridad necesaria para los usuarios beta. Adems se les proporcionar instrucciones especficas sobre las pruebas beta y sobre cmo informar de los hallazgos y observaciones. Una vez seleccionados los usuarios beta se les proporciona la versin beta y el material de acompaamiento.

213 de 297
Fase de Transicin
Qu se hace en esta fase: Preparacin de la versin beta. Instalacin de la versin beta:
Habr un gran nmero de lugares en los que se realicen pruebas beta, y el personal de transicin no estar presente, por tanto, deben darse instrucciones especficas sobre: Cmo instalar el software de pruebas. Cmo operar con l. En qu aspectos y problemas deben centrarse los clientes y los usuarios beta. Cmo informar de los fallos y problemas encontrados. Si la versin es un actualizacin o sustitucin de software existente se debe proporcionar informacin sobre la migracin o la conversin de datos, es posible que haya que operar con los dos sistemas en paralelo.
214 de 297
Fase de Transicin
Qu se hace en esta fase: Preparacin de la versin beta. Instalacin de la versin beta:
En las pruebas de aceptacin por lo general estarn presentes miembros del personal del proyecto. Habr un documento formal de pruebas de aceptacin aunque ser complementado mediante comunicaciones informales. Cuando sea posible los problemas se resolvern en el entorno de usuario, si es necesario se remitirn a los miembros cualificados del proyecto.

215 de 297
Reaccin a los resultados de las pruebas

Qu se hace en esta fase: Preparacin de la versin beta. Instalacin de la versin beta. Reaccin a los resultados de las pruebas:
Una vez recopilados y analizados los resultados de las pruebas se dividen en dos categoras: fallos de codificacin, relativamente menores slo precisan ser localizados y corregidos, y problemas ms 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 diseo, anlisis o incluso de casos de uso. El defecto se corregir, se probar y se realizarn pruebas de regresin. Parece verosmil que el defecto est relacionado con otros an no descubiertos?
216 de 297
Fase de Transicin
Qu se hace en esta fase: Preparacin de la versin beta. Instalacin de la versin beta. Reaccin a los resultados de las pruebas.
Fallos: Puede ser corregido sin que afecte a la arquitectura o el diseo? Ha sido corregido sin introducir nuevos defectos? Problemas ms amplios: Consideracin ms extensa que corregir un fallo. Puede requerir una iteracin de pruebas adicional, puede sugerir cambios, mejoras o caractersticas que deban tratarse formalmente.
217 de 297
Fase de Transicin
Fallos. Problemas ms amplios: A medida que se realizan cambios se deben llevar a cabo el control de configuracin. Los cambios que excedan los recursos, retrasen la distribucin o modifiquen la arquitectura deben postergarse, si es posible, hasta el siguiente ciclo de desarrollo.

218 de 297
Fase de Transicin
Fallos. Problemas ms amplios: Se trabajar en modo de seguimiento para asegurarse de que la correccin de problemas y defectos respeta la arquitectura. Los problemas no se podrn corregir de forma que daen la arquitectura, esto puede requerir algn ajuste en la arquitectura en cuyo caso se actualizar su descripcin.

219 de 297
Fase de Transicin
Qu se hace en esta fase: Preparacin de la versin beta. Instalacin de la versin beta. Reaccin a los resultados de las pruebas. Adaptacin a entornos variados:
Relacin de mercado: El mercado puede consistir en un conjunto muy diverso de destinatarios, para el que debern prepararse diferentes versiones del programa ejecutable, estas variantes incluyen pas, 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 documentacin preliminar de las pruebas beta para ajustarse a las necesidades de los usuarios normales ya que stos sern menos experimentados.
220 de 297
Fase de Transicin
Relacin de mercado: Se prepararn procedimientos de instalacin y un guin para el servicio de asistencia telefnica. Si un sistema precisa que se instalen diferentes partes en diferentes nodos, cada nodo puede precisar diferentes procedimientos de instalacin.

221 de 297
Fase de Transicin
Relacin de mercado. Relacin de cliente individual: Diferencias respecto a la relacin 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.

222 de 297
Fase de Transicin
Relacin de mercado. Relacin de cliente individual: Diferencias respecto a la relacin anterior: La organizacin 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 instalacin.

223 de 297
Fase de Transicin
Relacin de mercado. Relacin de cliente individual: Diferencias respecto a la relacin anterior: Los representantes del contratista han observado las pruebas de aceptacin y pueden haber realizado correcciones sobre el terreno cuando esto fue posible. En caso de problemas ms serios, han remitido los detalles a su propia organizacin con el fin de conseguir la ayuda de expertos para realizar los cambios y correcciones.

224 de 297
Fase de Transicin
Relacin de mercado. Relacin de cliente individual: Diferencias respecto a la relacin anterior: La pruebas de aceptacin 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 ampliacin del contrato.
225 de 297
Fase de Transicin
Relacin de mercado. Relacin de cliente individual. Migracin y conversin de datos: Cuando hay un sistema ya existente que va a ser reemplazado.

226 de 297
Fase de Transicin
Relacin de mercado. Relacin de cliente individual. Migracin y conversin de datos: Responsabilidades: Sustitucin del sistema antiguo por el nuevo, ya sea con la asuncin completa de todas las tareas por parte del nuevo o con la operacin 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.
227 de 297
Fase de Transicin
Relacin de mercado. Relacin de cliente individual. Migracin y conversin de datos: Responsabilidades: Instrucciones para las transferencias y aadir a la documentacin pruebas para verificar la correccin de la instalacin. Generar informacin explicativa adicional para el servicio de asistencia telefnica, especialmente para ayudar a los usuarios si la instalacin no ha sido correcta.
228 de 297
Fase de Transicin
Qu se hace en esta fase: Preparacin de la versin beta. Instalacin de la versin beta. Reaccin a los resultados de las pruebas. Adaptacin a entornos variados: Finalizacin de los artefactos:
Correcciones necesarias. Al final de esta fase se habr verificado a travs del uso real que todos los artefactos son consistentes unos con otros.

229 de 297
Fase de Transicin
Qu se hace en esta fase: Preparacin de la versin beta. Instalacin de la versin beta. Reaccin a los resultados de las pruebas. Adaptacin a entornos variados: Finalizacin de los artefactos. Cundo 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 versin comercial. Tanto el entorno como el producto continuarn evolucionando, pero se responder a esta evolucin en versiones posteriores o, en caso de una modificacin muy grande, en un nuevo ciclo de desarrollo. Esta fase acaba cuando el proyecto transfiera la responsabilidad del mantenimiento continuado a una organizacin de apoyo.
230 de 297
Fase de Transicin
Para productos contratados por un cliente, se determina que ste estar satisfecho una vez el sistema pase las pruebas de aceptacin. Este punto depende de la interpretacin de los requisitos detallados en el contrato original, firmado al final de la fase de elaboracin, y modificado a travs 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 transicin habr concluido.
231 de 297
Fase de Transicin

232 de 297
Finalizacin del anlisis de negocio

Anlisis del negocio: Situacin:
Hay ms informacin disponible sobre la que juzgar el acierto del anlisis 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 trminos presupuestarios) se revisa el tiempo, personas-hora, coste, porcentajes de defectos y otras mtricas que la empresa pueda utilizar en relacin 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 el caso. Aadir las mtricas del proyecto a la Base de Datos de mtricas de la empresa para su uso futuro.
233 de 297

Anlisis del negocio: Situacin. Control del progreso. Revisin del plan de negocio:
Este plan prev si el proyecto tendr xito econmico. Si el proyecto responde a una produccin 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 reduccin de costes en futuros proyectos. Si el proyecto es una produccin 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.

234 de 297

Anlisis del negocio: Situacin. Control del progreso. Revisin del plan de negocio. Finalizacin:
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 reunirn todos los datos y se formar un grupo para revisar el plan.

235 de 297

Anlisis del negocio: Situacin. Control del progreso. Revisin del plan de negocio. Finalizacin.

236 de 297
Fase de Transicin
Evaluacin: Personal:
Se rene un pequeo 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: Evaluacin de las iteraciones y de las fases: Si se han llevado a cabo las tres fases anteriores de forma efectiva las pruebas beta slo detectarn fallos rutinarios que se corregirn rpidamente Si se fracas al identificar todos los riesgos importantes, al desarrollar la arquitectura, o al realizar el diseo, la fase de transicin debe ampliarse hasta alcanzar un sistema mnimamente satisfactorio.

237 de 297
Fase de Transicin
Evaluacin: Personal. Hallazgos:
Tipos: Evaluacin de las iteraciones y de las fases: Puede que haya que postergar caractersticas originalmente especificadas en los requisitos para una versin posterior. Las deficiencias sern registrados para que el proyecto que trabaje con la nueva versin se desarrolle mejor.

238 de 297
Fase de Transicin
Tipos: Evaluacin de las iteraciones y de las fases. Valoracin del proyecto: Se analiza lo que la organizacin del proyecto ha hecho bien y lo que ha hecho mal. El objetivo es proporcionar un registro que permita mejorar la organizacin 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 versin. Por ejemplo se registran no slo las razones para elegir un diseo sino tambin las razones para rechazar otros.

239 de 297
Fase de Transicin
Tipos: Evaluacin de las iteraciones y de las fases. Valoracin del proyecto: Se deben considerar detalladamente los aspectos del proceso de desarrollo en s: -Se necesita ms formacin general? -Qu reas requieren formacin especializada? -Deberan proseguir las actividades de asesoramiento? -La experiencia de este proyecto con aspectos especializados de la nueva metodologa ha permitido desarrollar intuiciones que beneficiarn a futuros proyectos?
240 de 297
Fase de Transicin
Tipos: Evaluacin de las iteraciones y de las fases. Valoracin del proyecto.

241 de 297
Planificacin de la prxima versin
Casi todos los sistemas software entran en un nuevo ciclo de desarrollo de forma casi inmediata. El nuevo ciclo repite las cuatro fases

242 de 297
Productos generados
1. El propio software ejecutable, incluyendo el software de instalacin. 2. Documentos legales como contratos, licencias, renuncias de derechos y garantas. 3. La versin completa y corregida de la lnea de base de la versin del producto, incluyendo todos los modelos del sistema. 4. La descripcin completa y actualizada de la arquitectura. 5. Manuales y material de formacin del usuario final, del operador y del administrador del sistema. 6. Referencias, incluyendo de la web, para la ayuda del cliente, acerca de dnde encontrar ms informacin, cmo informar de defectos o dnde encontrar informacin sobre defectos y actualizaciones.

243 de 297
DSI 11.1 Especificacin de requisitos de documentacin de usuarios beta
Inicio Fin
CSI 6.1 Adaptar el manual de usuario para usuarios finales
Inicio Fin
CSI 7.1 Completar el esquema de formacin de usuarios finales
Inicio Fin
Inicio Fin
Fin
Inicio
CSI 9.1 Aprobacin de la versin operativa inicial del sistema
CSI 7.2 Inicio-Inicio, Fin-Fin Formacin usuarios finales IAS 2.3 Preparacin de la formacin de usuarios finales IAS 2.4
Fin
Inicio
IAS 1.1 Definicin del plan de implantacin
Fin
Inicio
Seguimiento de la formacin de usuarios finales
IAS 8.1 Identificacin de niveles de servicio
IAS 8.2
IAS 8.3
Inicio Fin
Inicio Fin
Descripcin de servicios
Inicio Fin
Inicio Fin
Fin
Inicio
Determinacin del acuerdo de servicio
Inicio
Fin
IAS 1.2 Especificacin del equipo de implantacin
Fin
Fin
Fin
Inicio
IAS 2.1 Plan de formacin del equipo de implantacin
Inicio
IAS 2.2
IAS 3.1 CSI 6.1 Fin-Inicio IAS 5.1 Fin-Inicio Pruebas de implantacin IAS 4.1 IAS 5.2
Fin
Fin
Inicio
Formacin del equipo de implantacin
Fin
Inicio
Preparacin de la instalacin
Producto software IAS 3.2 Instalacin del producto software
Inicio Fin
Inicio Fin
IAS 5.3 Evalluacin de pruebas de implantacin
Fin
Inicio
Inicio
Ini c
IAS 4.1 Fin-Inicio
Migracin y carga inicial de datos
Fin
Inicio
Realizacin de pruebas de implantacin
io
IAS 5.1 Preparacin pruebas de implantacin
Producto listo, datos cargados
Inicio Fin
Inicio Fin
IAS 6.1 Preparacin para las pruebas de aceptacin
Fin
Inicio
IAS 6.2 Realizacin de las pruebas de aceptacin
Inicio Fin
Inicio Fin
IAS 6.3 Evaluacin de las pruebas de aceptacin
IAS 5.3,6.3,8.3 Fin-Inicio Sistema desarrollado IAS 7.1 Preparacin de la infraestructura de mantenimiento
Inicio Fin
Inicio Fin
IAS 7.2 Formalizacin del plan de mantenimiento
Fin
Inicio
IAS 9.1 Convocatoria de presentacin del sistema
IAS 9.2
IAS 10.1
IAS 10.2
Fin
Inicio
Aprobacin del sistema
Fin
Inicio
Preparacin del entorno de produccin
Fin
Inicio
Activacin del sistema en produccin
DSI 11.1 Inicio-Inicio, Fin-Fin Documentacin de usuario ASI-CAL 2.1 Actividades y tareas del plan de calidad ASI-CAL 4.1 Revisin del plan de pruebas DSI-CAL 1.1 Revisin de consistencia de productos del diseo DSI-CAL 2.1 Revisin de pruebas unitarias, del sistema y de aceptacin
Inicio Inicio
Inicio Inicio
Fin
Fin
Fin
Fin
Inicio Inicio
DSI-CAL 3.2 Revisin de requisitos de implantacin
Fin
Fin
CSI 6.1 Inicio-Inicio, Fin-Fin Manual de usuario CSI-CAL 1.1 Revisin de normas de construccin CSI-CAL 2.1 CSI-CAL 2.2 Revisin de pruebas de integracin CSI-CAL 2.3 Revisin de pruebas del sistema CSI-CAL 3.1 Revisin de manuales de usuario
CSI 9.1 Fin-Inicio Versin operativa CSI-CAL 5.1 Registro de la aprobacin del sistema de informacin
Inicio Inicio
Inicio Inicio
Inicio Inicio
Inicio Inicio
Fin
Inicio
Fin
Inicio
Fin
Fin
Fin
Fin
Fin
Fin
Fin
Fin
IAS 1.1,1.2, CSI-CAL 5.1 Inicio-Inicio, Fin-Fin Implantacin IAS-CAL 1.1 Revisin del plan de implantacin del sistema
IAS 5.3 Inicio-Inicio, Fin-Fin Pruebas de implantacin IAS-CAL 2.1 Revisin de la realizacin de pruebas de implantacin IAS-CAL 2.2 Registro de la aceptacin o rechazo de las pruebas de implantacin
IAS 6.3 Inicio-Inicio, Fin-Fin Pruebas de aceptacin IAS-CAL 3.1 Revisin de la realizacin de las pruebas de aceptacin del sistema IAS-CAL 3.2 Registro de la aceptacin o rechazo de las pruebas de aceptacin del sistema
IAS 7.2 Inicio-Inicio, Fin-Fin Plan de mantenimiento IAS-CAL 4.1
IAS 9.2 Inicio-Inicio, Fin-Fin Sistema aprobado IAS-CAL 5.1 Registro de aprobacin de la implantacin del sistema
Inicio Inicio
Fin
Inicio
Fin
Inicio
Fin
Inicio
Fin
Inicio
Fin
Fin
Revisin del plan de mantenimiento
Fin
Inicio
Inicio Inicio
GPS 4.2
Inicio Fin
Fin
Inicio Fin
Fin
Fin Inicio
Inicio Fin
Fin
Inic
Inicio Fin
GPS 4.3
Fin
Inicio
io
GPS 10.1 Resumen final de una tarea finalizada GPS 7.1 Aprobacin de la solucin
GPS 6.1
Inicio Inicio
Inicio Inicio
Fin Fin
Inicio
Fin
Inicio
Inicio
Fin
Fin
Fin
Fin
Fin Inicio Fin
Inicio
Inicio Inicio
Inicio Fin
Fin
Fin
Inicio Inicio
Inicio Inicio
Fin
Fin
Fin
Fin
CSI 7.1 Inicio-Inicio, Fin-Fin Formacin usuarios finales CSI-SEG 3.1 GPF 1.1 Identificacin y registro de productos globales GPF 1.2 Identificacin y registro de productos globales Plan de formacin de seguridad CSI-SEG 2.1 Evaluacin de las pruebas de seguridad DSI-SEG 5.1 Clasificacin y catalogacin de los productos del DSI CSI-SEG 4.1 Clasificacin y catalogacin de los productos del CSI
IAS 1.1 Inicio-Inicio, Fin-Fin Plan de implantacin IAS-SEG 1.1 Estudio de la seguridad requerida para el IAS
IAS 3.1 Inicio-Inicio, Fin-Fin Instalacin del software IAS-SEG 2.1 Medidas de seguridad del entorno de operacin
IAS 5.2 Inicio-Inicio, Fin-Fin Pruebas de implantacin IAS-SEG 3.1 Evaluacin de las pruebas de seguridad de la implantacin
IAS 10.2 Fin-Inicio IAS completado IAS-SEG 4.1 Clasificacin y catalogacin de los productos del IAS IAS-SEG 5.1 Medidas de seguridad en el entorno de produccin
Mantenimiento

247 de 297
MSI 4.3 Fin-Inicio Correccin MSI-CAL 1.1 Revisin del mantenimiento
MSI 3.3 Inicio-Inicio, Fin-Fin Pruebas de regresin MSI-CAL 2.1 Revisin del plan de pruebas de regresin
MSI 4.2 Inicio-Inicio, Fin-Fin Pruebas de regresin
Inicio Inicio
MSI-CAL 3.1 Evaluacin de pruebas de regresin
Fin
Fin
MSI 2.2 Inicio-Inicio, Fin-Fin Propuesta de solucin MSI-SEG 1.1 Estudio de seguridad requerida en el MSI MSI-SEG 2.1 Estudio de la peticin
MSI 4.3 Fin-Inicio Fin del MSI MSI-SEG 2.2 Cambios en los mecanismos de seguridad MSI-SEG 3.1 Clasificacin y catalogacin de los productos del MSI
MSI 3.3 Inicio-Inicio, Fin-Fin Modificacin MSI-GC 1.1 Registro del cambio
MSI 2.2 Inicio-Inicio, Fin-Fin Producto modificado MSI-GC 1.2 Registro de la nueva versin de un producto MSI-GC 1.3 Registro de la nueva versin del sistema
Inicio Inicio
Fin
Fin
Inicio Inicio
GPS 4.2
Inicio Fin
Fin
Inicio Fin
Fin
Fin Inicio
Inicio Fin
Fin
Inic io
Inicio Fin
GPS 4.3
Fin
Inicio
GPS 6.1
Inicio Inicio
Inicio Inicio
Fin Fin
Inicio
Fin
Inicio
Inicio
Fin
Fin
Fin
Fin
Fin Inicio Fin
Inicio
Inicio Inicio
Inicio Fin
Fin
Fin
Inicio Inicio
Inicio Inicio
Fin
Fin
Fin
Fin
GPF 1.1 Cierre del proyecto, inclusin en el histrico de proyectos
GPF 1.2 Archivo de la documentacin de gestin del proyecto
Resumen

251 de 297
Aspectos relativos a la metodologa

Manejo de la complejidad: El desarrollo de software guiado por los casos de uso a travs de los flujos de trabajo; captura de requisitos, anlisis, diseo, implementacin 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 construccin y componentes, facilitando la reutilizacin. El desarrollo llevado a cabo a travs de iteraciones y construcciones dentro de las iteraciones, lo que resulta un crecimiento incremental del producto.

252 de 297
Aspectos relativos a la metodologa

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

253 de 297
Cuestiones importantes
Obtencin correcta de requisitos: A travs del modelado de casos de uso, anlisis, diseo e implementacin Obtencin correcta de la arquitectura: Permite la particin del sistema y que las particiones colaboren entre s. Solidifica las interfaces entre las particiones permitiendo la distribucin del trabajo entre equipos diferentes. Uso de componentes: Las firmes interfaces de la arquitectura permiten el desarrollo basado en componentes. Los bloques de construccin reutilizables reducen costes de desarrollo y tiempo, adems, mejoran la calidad.

254 de 297
Cuestiones importantes
Comunicacin con UML: Es un lenguaje grfico con el que se puede pensar, visualizar, analizar, comunicar y registrar. Facilita la comunicacin a travs de fases, versiones y generaciones Iteraciones: Tareas pequeas, grupos de trabajo pequeos, ligazn con la gestin de riesgos y controles y realimentaciones frecuentes. Gestin de riesgos: Identificarlos (crticos, significativos, rutinarios), ponerlos en una lista y mitigarlos antes de que se manifiesten.

255 de 297
Visin Global de las Iteraciones

256 de 297
Iteracin Fase Preliminar
PSI 1.1 Completa
Fin
Fin
Fin
Fin
Iteracin Fase de Inicio
PSI 2.3 Primera versin del plan de trabajo, esbozo
ici o
EVS 3.1 PSI 3.1 Informacin relevante, completa PSI 3.2
In
Inicio
Inicio
Fin
Inicio
cio In i
Requisitos generales, completa
Fin
Fin
Catlogo de normas, se intenta completar aunque puede que sea necesario hacerlo en la fase posterior PSI 3.2 Inicio-Inicio Modelo de negocio
PSI 2.1 Descripcin de procesos afectados, completa
PSI 2.2
Fin
Inicio
Catlogo de usuarios, completa aunque el se aaden usuarios a lo largo del proyecto.
Ini
In
ici o
cio
PSI 4.1
Inicio
Inicio
Inicio
Inicio
Modelo de Procesos, completo
Fin
Fin
PSI 4.2 Necesidades de informacin, requisitos funcionales, diagrama de clases, completa
Inicio Fin
Inicio Fin
PSI 4.3 Requisitos de los procesos, completa
EVS 1.2
Fin
Inicio
EVS 3.3 Catalogacin de requisitos
Dependencias con otros proyectos, visin global del alcance del sistema
Fin
Inicio
EVS 1.3 Usuarios y plan de trabajo de esta fase
Inicio
io Inic
Fin
EVS 2.1 Descripcin de sistemas actuales completa si se tiene en cuenta la arquitectura, si no se completa en la siguiente fase
Inicio
i Inic
EVS 3.2
Fin
Inicio
Identificacin de requisitos
Inicio
EVS 2.4 Diagnstico de la situacin actual, completa
EVS 2.3
Inicio
Fin
Descripcin lgica de los sistemas actuales, modelo fsico, diagrama de clases, completa
Inicio
Fin
EVS 2.2 Participantes del estudio de la situacin actual
Inicio
Fin
PSI 4.3 Fin-Inicio Modelo de negocio PSI 5.1 Identificacin de sistemas afectados, completa
Inicio
Inicio
Fin
Fin
PSI 5.2 Descripcin de sistemas afectados, completa
Inicio
Inicio
Fin
Fin
PSI 5.3 Valoracin de sistemas afectados, completa
Fin
Inicio
PSI 6.1 Sistemas que se conservan y mejoras propuestas, completa
Inicio
Fin
Fin
Fi n
Inic
io
In ici o
Inicio
Fin
Inicio Fin
Inicio Fin
Inicio Fin
Inicio Fin
Inicio Fin
Inicio Fin
ASI 3.2 Fin-Inicio DSI 3.3 Diseo de interfaz de usuario, caso muy concreto Divisin en subsistemas DSI 3.4 Descripcin de casos de uso en trminos de subsistemas e interfaces, alto nivel
ASI 9.3 Fin-Inicio Modelo de clases DSI 4.1 Identificacin de clases de diseo, a partir de las de anlisis
n Fi
In ici
DSI 3.1 Identificacin de clases de diseo adicionales, diseo de casos de uso
Inicio Fin
Inicio Fin
DSI 3.2 Interaccin de clases anteriormente identificadas, realizacin de casos de uso
Inicio Fin
Inicio Fin
Inicio Fin
In
ici o
Inicio Fin
n Fi
Inicio
Fi n
Inicio
Fi n
DSI 4.2 Asociaciones y agregaciones de las clases identificadas
Inicio Fin
Inicio Fin
DSI 4.3 Atributos de las clases identificadas, caso concreto
Inicio Fin
Inicio Fin
DSI 4.4 Operaciones de las clases, caso concreto
Inicio Fin
Inicio Fin
DSI 4.5 Jerarqua del modelo de clases
Inicio Fin
Inicio Fin
DSI 4.6 Pseudocdigo de algn mtodo concreto
DSI 6.1
DSI 6.4
Fin
Inicio
DSI 3.3,3.4,6.4 Fin-Inicio Productos obtenidos DSI 7.2 Anlisis de consistencia de los productos obtenidos DSI 8.1 DSI 8.2
Especificacin a alto nivel del modelo fsico de datos si mejora la comprensin del sistema
Fin
Inicio
Distribucin de los datos a muy alto nivel, modelo de datos no optimizado.
Fin
Inicio
Especificacin del entorno tecnolgico necesaria para la realizacin del prototipo
Inicio
Inicio
Inicio
Definicin de componentes y subsistemas necesarios para el prototipo.
Inicio Fin
Fin
DSI 10.1 Especificacin del entorno de pruebas para el prototipo
DSI 10.2
Inicio Fin
Inicio
Niveles de prueba
Fin Inicio Fin

CSI 3.1 Preparacin del entorno de pruebas unitarias
CSI 2.1 Inicio-Inicio Cdigo del prototipo CSI 3.2 Realizacin y evaluacin de pruebas unitarias CSI 2.1 Fin-Inicio
Fin
Fin
Fin
Inicio
Inicio
Inicio
Inicio
Fin
Ini cio
CSI 1.2 Preparacin del entorno de construccin para el prototipo
CSI 2.1 Generacin de cdigo
Fin
Cdigo del prototipo CSI 4.1 Preparacin del entorno de pruebas de integracin CSI 4.2
Inicio Fin
Inicio Fin
DSI 10.3 Plan de pruebas
Fin
Inicio
Fin
Inicio
Realizacin de pruebas de integracin CSI 2.1 Fin-Inicio
Fi n In ici o
Cdigo del prototipo CSI 5.2
Inicio Fin
Inicio Fin
Fin
Inicio
Iteracin Fase de Elaboracin
Inicio Fin Fin
Inicio
ASI 4.2 Inicio-Inicio, Fin-Fin Realizacin de casos de uso ASI 4.1
Fi Inic n io
Inicio
Inicio
ASI 5.1 Responsabilidades y atributos de las clases anteriores
Inicio
Inicio
Identificacin de clases de anlisis
Fin
Fin
Fin
Fin
ASI 5.2 Identificacin de agregaciones y asociaciones
Inicio
Inicio
ASI 5.3 Identificacin de generalizaciones
Fin
Fin
Validacin de casos de uso anteriores
Fin
Inicio Fin
Inicio Fin
n Fi
Inicio
Fin
ASI 1.3 Inicio-Inicio Normas y estndares ASI 9.1 Verificacin de la arquitectura del sistema
ASI 2.3 Inicio-Inicio, Fin-Fin Casos de uso arquitectnicamente significativos ASI 2.4 i ci o
io Inic Fin
In
Fin
Fi Ini n c io
ASI 3.1 Descripcin de subsistemas e interfaces
Inicio
Inicio
ASI 3.2 Integracin de subsistemas
io Inic
ASI 9.2
Fin
Inicio
Fin
Inicio
Fin
Fin
Anlisis de consistencia muy exhaustivo de la arquitectura
In ici o i In cio
n Fi
c Ini Fin
ASI 8.3 Definicin de alguna pantalla necesaria para la comprensin de un caso de uso concreto ASI 8.4 Identificacin y especificacin de los dilogos considerados crticos ASI 8.5 Formatos de impresin, caso muy concreto
io
Inicio
Inicio
Inicio
Inicio
Fin
Fin Ini c io
Inicio
Inicio Fin
Fin
In ic io In ici o
Inicio Fin
Fi Ini n c io
Fin
In Fi icio n
I Finnicio Inic i Fin o
Inicio Fin
Inicio Fin
Ini Fin cio
Inic io Fin
Inicio
Fin
Inic
Fi n
io I n ic io
Fin
Inicio
Fi n Inic io
Fin
EVS 4.2 Inicio-Inicio, Fin-Fin Alternativas de solucin EVS-CAL 1.1 Se constituye el equipo de calidad y el plan de accin EVS-CAL 1.2 Determinacin de sistemas objeto del aseguramiento de la calidad
EVS 5.3 Inicio-Inicio, Fin-Fin Alternativas de solucin
Inicio
Inicio
Fin
Inicio
Fin
Fin
EVS-CAL 1.3 Identificacin de propiedades de calidad
Inicio Inicio
Fin
Fin
EVS-CAL 2.1 Necesidad del plan de aseguramiento de la calidad de cada alternativa
Inicio Inicio
Fin
Fin
EVS-CAL 2.2 Alcance del plan de aseguramiento de la calidad de cada alternativa
Inicio Fin Fin
Inicio Fin
EVS-CAL 2.3 Anlisis de consistencia de la arquitectura
EVS 6.2 Fin-Inicio Solucin propuesta EVS-CAL 3.1 Ajuste del plan a la solucin selecionada
EVS 6.3 Fin-Inicio Solucin aprobada EVS-CAL 3.2
Fin
Inicio
Inicio
Aprobacin del plan de la solucin
ASI 2.4 Inicio-Inicio EVS-CAL 3.1 Fin-Inicio Plan para la solucin ASI-CAL 1.1 Definicin detallada del plan de aseguramiento de la calidad de la solucin Catlogo de requisitos ASI-CAL 3.1 Revisin del catlogo de requisitos
ASI 9.3 Inicio-Inicio, Fin-Fin Validacin de la arquitectura ASI-CAL 3.2 Revisin de consistencia de productos
ASI 10.3 Fin-Inicio Plan de pruebas ASI-CAL 4.1
Inicio Inicio
Fin
Inicio
Inicio
Inicio
ASI-CAL 2.1 Actividades y tareas del plan
Inicio
Inicio
Fin
Fin
Fin
Fin
In ici o In ici o
DSI 7.2 Inicio-Inicio, Fin-FIn Anlisis de consistencia de la arquitectura DSI-CAL 1.1 Revisin de consistencia de productos del diseo DSI 7.3 Fin-Inicio Aceptacin del diseo DSI-CAL 1.2 DSI 10.2 Inicio-Inicio, Fin-Fin Pruebas DSI-CAL 2.1 Revisin de pruebas unitarias, del sistema y de aceptacin DSI 10.3 Inicio-Inicio, Fin-Fin Pruebas
Inicio Inicio
Fin
Inicio
Aceptacin de la arquitectura del sistema
Fin
Inicio
Fin
Fin
CSI 2.2 Inicio-Inicio, Fin-Fin Cdigo generado CSI-CAL 1.1 Revisin de normas de construccin
Inicio Inicio
Inicio Inicio
Fin
Inicio
Fin
Fin
Fin
Fin
PSI 9.2, EVS 3.2 Inicio-Inicio, Fin-Fin Arquitectura y requisitos EVS-GC 1.1 Requisitos de la gestin de la configuracin
EVS 6.2 Fin-Inicio Solucin propuesta EVS-GC 2.1
Inicio Inicio
Inicio Inicio
Plan de gestin de la configuracin
Fin
Fin
EVS-GC 2.2 Entorno tecnolgico para la gestin de la configuracin
EVS 6.2 Fin-Inicio Solucin propuesta GPI 1.1 Estimacin del esfuerzo, identificacin de elementos a desarrollar
Inicio Inicio
GPI 1.2 Clculo del esfuerzo
GPI 2.1
Fin
Inicio
Fin
Fin
Seleccin de la estrategia de desarrollo
Fin
Inicio
GPI 2.2 Adaptacin de la metodologa al proyecto
GPI 2.3
Inicio Inicio
GPI 2.4 Planificacin general del proyecto
GPI 2.5
Fin
Inicio
Calendario de hitos y entregas
Fin
Inicio
Fin
Fin
Aceptacin de la planificacin
GPI 2.4 Inicio-Inicio, Fin-Fin Planificacin del proyecto GPS 1.1 Asignacin de tareas a miembros del proyecto
GPS 3.1 Seguimiento de tareas GPS 2.1 Comunicacin de la asignacin de tareas al equipo
GPS 4.2
Inicio Fin Fin

Fin
Inicio Fin
Inicio Fin
Inicio
Inic i
Inicio Fin
GPS 4.3
Fin
Inicio
o
cio Ini n Fi Ini cio n Fi
GPS 3.1 Inicio-Inicio, Fin-Fin Seguimiento de tareas GPS 11.1 Actualizacin de la planificacin de tareas
Inicio Inicio
Fin
Fin
Inicio Inicio
Inicio Inicio
Fin
Fin
Fin
Fin
Iteracin Fase de Construccin
ASI 8.1 ASI 1.3 ASI 1.1 Procesos y requisitos de la solucin, glosario, modelo de negocio, se completa la labor de la fase anterior Definicin final de los principios generales de interfaz de usuario
Inicio Fin
Inicio Fin
Catlogo de normas
Inicio
Inicio
Inicio Fin
Inicio Fin
ASI 2.1 Modelo de casos de uso, se completa si es necesario
Inicio Fin
Inicio Fin
ASI 2.2 Especificacin de casos de uso restantes
Inicio Fin
Inicio Fin
ASI 2.3 Anlisis riguroso de los casos de uso de ASI 2.2
ASI 4.2 Inicio-Inicio, Fin-Fin Realizacin de casos de uso ASI 4.1 Identificacin de clases de anlisis ASI 5.1 Responsabilidades y atributos de las clases anteriores ASI 5.2 Identificacin de agregaciones y asociaciones, revisin de la especificacin de subisistemas para su posible optimizacin ASI 5.3 Identificacin de generalizaciones
Inicio
Inicio
Inicio
Inicio
Inicio
Inicio
Fi Inic n io
Fin
Fin
Fin
Fin
Fin
Fin
Fi Inic n i
ASI 2.3 Inicio-Inicio, Fin-Fin Casos de uso restantes ASI 2.4 Validacin de casos de uso anteriores
Fin
Inicio
Inicio Fin
Inicio
Fin
io Inic in F
io Inic Fin
Inicio
ASI 1.3 Inicio-Inicio Normas y estndares ASI 9.1
Fin
n Fi
ASI 3.1 Introduccin de actualizaciones y mejoras en los subsistemas
Inicio
Inicio
Fin
Fin
ASI 3.2 Revisar consistencia si se introdujeron modificaciones en la tarea anterior
ASI 9.2
Fin
Inicio
Verificacin de todos los modelos
Fin
Inicio
Anlisis de consistencia de todos los modelos
o ici In o ici In
n Fi
Ini Fin
ASI 8.3 Definicin de formatos individuales de pantalla ASI 8.4 ASI 8.5 Especificacin del comportamiento dinmico de las interfaces Especificacin de formatos de impresin,
cio
Inicio
Inicio
Inicio
Inicio
Inicio
Inicio Fin
cio Ini in F
Inicio Fin
Fi Ini n cio
In Fi icio n
Inicio Inicio Fin Fin
i In
cio
Fin
Fi
n
cio n Ini Fi
DSI 1.7 Fin-Inicio Operacin y seguridad DSI 1.3,1.4 Inicio-Inicio, DSI 1.6,3.3,3.4,6.4 Fin-Inicio Productos de diseo DSI 7.1 Verificacin del diseo (Calidad), modelo de datos optimizado DSI 7.3 Aceptacin del anlisis realizado anteriormente DSI 11.2 DSI 11.1 Especificacin de requisitos de documentacin de usuarios beta
DSI 7.3,8.4,9.4,10.3 Fin-Inicio Productos de diseo DSI 12.1
Inicio
Inicio
DSI 7.2 Anlisis de consistencia del diseo
Fin
Inicio Fin
In Fi icio n
Inicio
Inicio Inicio Fin Fin Inicio Fin
Requisitos de implantacin
Fin
Inicio
Aprobacin del diseo del sistema
CSI 7.1 Primera versin del esquema de formacin de usuarios finales
Inicio Fin
Inicio Fin
Fin
Fin
Inicio Fin
Inicio Fin
DSI 10.2
In ic Fi io n
DSI 8.2 Definicin de componentes y subsistemas de implementacin como traduccin directa del diseo
Inicio Fin Inicio Fin Inic Fi n i o
Inicio Fin
Especificacin de los niveles de prueba DSI 8.3
Inicio Fin
Inicio Fin
DSI 8.4 Especificacin del modelo fsico de datos
io I ni c Fin
Inicio Fin
Inic io Fin
Especificacin en psedocdigo de componentes
Fin
Inicio
CSI 1.1 Implantacin de la BD o el sistema de ficheros
io I ni c in F
DSI 1.7 Fin-Inicio Operacin y seguridad CSI 2.1 Generacin del cdigo de los componentes de DSI 8.2
Inicio Inicio
Fin
Fin
CSI 2.2 Generacin de cdigo de los procedimientos de operacin y seguridad
Inicio
Inicio
CSI 6.1 Completar el manual de usuarios beta CSI 8.1 Preparacin del entorno de migracin y carga inicial de datos
Fin
Fin
DSI 9.1 Especificacin del entorno de migracin y carga inicial
Inicio
Inicio
Fin
Fin
DSI 9.2 Diseo de procedimientos de migracin y carga inicial
Inicio Inicio
Fin
Fin
DSI 9.3 Diseo de componentes de migracin y carga inicial
Inicio
Inicio
Fin
Fin
DSI 9.4 Revisin del plan de migracin y carga inicial
Inicio Fin
F in
Inicio Fin
In i c
CSI 2.2 Inicio-Inicio, Fin-Fin Cdigo generado DSI 10.2 Inicio-Inicio, Fin-Fin Pruebas DSI 10.3 Especificacin del plan de pruebas CSI 3.1 Preparacin del entorno de pruebas unitarias CSI 3.2 Realizacin y evaluacin de las pruebas unitarias CSI 2.2 Inicio-Inicio, Fin-Fin Cdigo generado CS 4.1 Preparacin del entorno de pruebas de integracin CSI 4.2
io
CSI 8.2 Generacin de cdigo de los componentes y procedimientos de la migracin y carga inicial de datos
CSI 8.3
Inicio Inicio
Fin
Fin
Realizacin y evaluacin de las pruebas de migracin y carga inicial de datos
Fin
Inicio
Fin
Inicio
Inicio
Inicio
Fin
Inicio
Fin
Fin Inic io
Inicio
CSI 2.2 Fin-Inicio Cdigo generado CSI 5.2
Realizacin de pruebas de integracin
Fin
Fin
Inicio
Inicio
Fin
Inicio
Fin
Fin
DSI 7.3 Fin-Inicio ASI 2.4 Inicio-Inicio, Fin-Fin Catlogo de requisitos ASI-CAL 2.1 Actividades y tareas del plan de calidad ASI 9.3 Inicio-Inicio, Fin-Fin Validacin de la arquitectura ASI-CAL 3.2 Revisin de consistencia de productos ASI 10.3 Fin-Inicio Plan de pruebas ASI-CAL 4.1 DSI 7.2 Inicio-Inicio, Fin-FIn ASI 11.1 Fin-Inicio ASI aprobado ASI-CAL 5.1 Anlisis de consistencia de la arquitectura DSI-CAL 1.1 Revisin de consistencia de productos del diseo Aceptacin del diseo DSI-CAL 1.2 Aceptacin de la arquitectura del sistema, incluida la interfaz de usuario y el modelo de datos optimizado DSI 10.2 Inicio-Inicio, Fin-Fin Pruebas DSI-CAL 2.1 Revisin de pruebas unitarias, del sistema y de aceptacin
Inicio
Inicio
ASI-CAL 3.1 Revisin del catlogo de requisitos
Inicio Inicio
Fin
Inicio
Fin
Fin
Fin
Inicio
Registro de aprobacin del ASI
Fin
Inicio
Fin
Inicio
Fin
Inicio
DSI 10.3, DSI-CAL 2.1 Inicio-Inicio, Fin-Fin Pruebas DSI-CAL 2.2 Revisin del plan de pruebas
DSI 11.1 Inicio-Inicio, Fin-Fin Documentacin de usuario
DSI 11.2 Inicio-Inicio, Fin-Fin Implantacin DSI-CAL 3.2 Revisin de requisitos de implantacin
DSI 12.1 Fin-Inicio DSI aprobado DSI-CAL 4.1
CSI 2.2 Inicio-Inicio, Fin-Fin Cdigo generado CSI-CAL 1.1
Inicio Inicio
Fin
Fin
Inicio Inicio
Inicio Inicio
Inicio Inicio
Fin
Inicio
Fin
Fin
Registro de aprobacin del DSI
Fin
Inicio
Revisin de normas de construccin
Fin
Inicio
Fin
Fin
Fin
Fin
CSI 6.1, CSI-CAL 2.3 Inicio-Inicio, Fin-Fin Manual de usuario CSI-CAL 3.1 Revisin de manuales de usuario
Inicio Inicio
Fin
Fin
Inicio Inicio
GPS 4.2 Propuesta de solucin a la incidencia
Inicio Fin
Fin
Inicio Fin
Fin Fin
Inicio
Fin
Fin Inicio
Fin
Inic io
Inicio
GPS 4.3
Fin
Inicio
GPS 6.1
Inicio Inicio
Inicio Inicio
Fin Fin
Inicio
Fin
Inicio
Inicio
Fin
Fin
Fin
Fin
Fin Inicio Fin
Inicio
Inicio Inicio
Inicio Fin
Fin
Fin
Inicio Inicio
Inicio Inicio
Fin
Fin
Fin
Fin
ASI 10.3 Fin-Inicio ASI 2.1 Inicio-Inicio Catlogo de requisitos ASI-SEG 2.1 Estudio de funciones y mecanismos de seguridad necesarios ASI 10.3 Inicio-Inicio, Fin-Fin Pruebas Fin del ASI ASI-SEG 4.1 Clasificacin y catalogacin de los productos del ASI DSI 8.4 Inicio-Inicio, Fin-Fin Entorno de construccin DSI-SEG 3.1 Requisitos de seguridad del entorno de construccin CSI 7.1 Inicio-Inicio, Fin-Fin Formacin usuarios finales
Inicio Inicio
Fin
Fin
ASI-SEG 3.1 Inclusin de criterios de seguridad en las pruebas
Inicio Inicio
CSI-SEG 3.1 Plan de formacin de seguridad
Fin
Fin
DSI 1.7, ASI-SEG 4.1,2.1 Inicio-Inicio, Fin-Fin Pruebas DSI-SEG 4.1 Diseo de pruebas de seguridad
DSI 10.3 Fin-Inicio CSI 3.2,4.2,5.2 Inicio-Inicio, Fin-Fin Pruebas Fin del DSI DSI-SEG 5.1 Clasificacin y catalogacin de los productos del DSI
CSI 5.3 Fin-Inicio Fin del CSI CSI-SEG 4.1 Clasificacin y catalogacin de los productos del CSI
Inicio Inicio
CSI-SEG 2.1 Evaluacin de las pruebas de seguridad
Fin
Fin
Iteracin Fase de Transicin
DSI 11.1 Especificacin de requisitos de documentacin de usuarios beta
Inicio Fin
CSI 6.1 Adaptar el manual de usuario para usuarios finales
Inicio Fin
CSI 7.1 Completar el esquema de formacin de usuarios finales
Inicio Fin
Inicio Fin
Fin
Inicio
CSI 9.1 Aprobacin de la versin operativa inicial del sistema
CSI 7.2 Inicio-Inicio, Fin-Fin Formacin usuarios finales IAS 2.3 Preparacin de la formacin de usuarios finales IAS 2.4
Fin
Inicio
IAS 1.1 Definicin del plan de implantacin
Fin
Inicio
Seguimiento de la formacin de usuarios finales
IAS 8.1 Identificacin de niveles de servicio
IAS 8.2
IAS 8.3
Inicio Fin
Inicio Fin
Descripcin de servicios
Inicio Fin
Inicio Fin
Fin
Inicio
Determinacin del acuerdo de servicio
Inicio
Fin
IAS 1.2 Especificacin del equipo de implantacin
Fin
Fin
Fin
Inicio
IAS 2.1 Plan de formacin del equipo de implantacin
Inicio
IAS 2.2
IAS 3.1 CSI 6.1 Fin-Inicio IAS 5.1 Fin-Inicio Pruebas de implantacin IAS 4.1 IAS 5.2
Fin
Fin
Inicio
Formacin del equipo de implantacin
Fin
Inicio
Preparacin de la instalacin
Producto software IAS 3.2 Instalacin del producto software
Inicio Fin
Inicio Fin
IAS 5.3 Evalluacin de pruebas de implantacin
Fin
Inicio
Inicio
Ini c
IAS 4.1 Fin-Inicio
Migracin y carga inicial de datos
Fin
Inicio
Realizacin de pruebas de implantacin
io
IAS 5.1 Preparacin pruebas de implantacin
Producto listo, datos cargados
Inicio Fin
Inicio Fin
IAS 6.1 Preparacin para las pruebas de aceptacin
Fin
Inicio
IAS 6.2 Realizacin de las pruebas de aceptacin
Inicio Fin
Inicio Fin
IAS 6.3 Evaluacin de las pruebas de aceptacin
IAS 5.3,6.3,8.3 Fin-Inicio Sistema desarrollado IAS 7.1 Preparacin de la infraestructura de mantenimiento
Inicio Fin
Inicio Fin
IAS 7.2 Formalizacin del plan de mantenimiento
Fin
Inicio
IAS 9.1 Convocatoria de presentacin del sistema
IAS 9.2
IAS 10.1
IAS 10.2
Fin
Inicio
Aprobacin del sistema
Fin
Inicio
Preparacin del entorno de produccin
Fin
Inicio
Activacin del sistema en produccin
DSI 11.1 Inicio-Inicio, Fin-Fin Documentacin de usuario ASI-CAL 2.1 Actividades y tareas del plan de calidad ASI-CAL 4.1 Revisin del plan de pruebas DSI-CAL 1.1 Revisin de consistencia de productos del diseo DSI-CAL 2.1 Revisin de pruebas unitarias, del sistema y de aceptacin
Inicio Inicio
Inicio Inicio
Fin
Fin
Fin
Fin
Inicio Inicio
DSI-CAL 3.2 Revisin de requisitos de implantacin
Fin
Fin
CSI 6.1 Inicio-Inicio, Fin-Fin Manual de usuario CSI-CAL 1.1 Revisin de normas de construccin CSI-CAL 2.1 CSI-CAL 2.2 Revisin de pruebas de integracin CSI-CAL 2.3 Revisin de pruebas del sistema CSI-CAL 3.1 Revisin de manuales de usuario
CSI 9.1 Fin-Inicio Versin operativa CSI-CAL 5.1 Registro de la aprobacin del sistema de informacin
Inicio Inicio
Inicio Inicio
Inicio Inicio
Inicio Inicio
Fin
Inicio
Fin
Inicio
Fin
Fin
Fin
Fin
Fin
Fin
Fin
Fin
IAS 1.1,1.2, CSI-CAL 5.1 Inicio-Inicio, Fin-Fin Implantacin IAS-CAL 1.1 Revisin del plan de implantacin del sistema
IAS 5.3 Inicio-Inicio, Fin-Fin Pruebas de implantacin IAS-CAL 2.1 Revisin de la realizacin de pruebas de implantacin IAS-CAL 2.2 Registro de la aceptacin o rechazo de las pruebas de implantacin
IAS 6.3 Inicio-Inicio, Fin-Fin Pruebas de aceptacin IAS-CAL 3.1 Revisin de la realizacin de las pruebas de aceptacin del sistema IAS-CAL 3.2 Registro de la aceptacin o rechazo de las pruebas de aceptacin del sistema
IAS 7.2 Inicio-Inicio, Fin-Fin Plan de mantenimiento IAS-CAL 4.1
IAS 9.2 Inicio-Inicio, Fin-Fin Sistema aprobado IAS-CAL 5.1 Registro de aprobacin de la implantacin del sistema
Inicio Inicio
Fin
Inicio
Fin
Inicio
Fin
Inicio
Fin
Inicio
Fin
Fin
Revisin del plan de mantenimiento
Fin
Inicio
Inicio Inicio
GPS 4.2
Inicio Fin
Fin
Inicio Fin
Fin
Fin Inicio
Inicio Fin
Fin
Inic
Inicio Fin
GPS 4.3
Fin
Inicio
io
GPS 10.1 Resumen final de una tarea finalizada GPS 7.1 Aprobacin de la solucin
GPS 6.1
Inicio Inicio
Inicio Inicio
Fin Fin
Inicio
Fin
Inicio
Inicio
Fin
Fin
Fin
Fin
Fin Inicio Fin
Inicio
Inicio Inicio
Inicio Fin
Fin
Fin
Inicio Inicio
Inicio Inicio
Fin
Fin
Fin
Fin
CSI 7.1 Inicio-Inicio, Fin-Fin Formacin usuarios finales CSI-SEG 3.1 GPF 1.1 Identificacin y registro de productos globales GPF 1.2 Identificacin y registro de productos globales Plan de formacin de seguridad CSI-SEG 2.1 Evaluacin de las pruebas de seguridad DSI-SEG 5.1 Clasificacin y catalogacin de los productos del DSI CSI-SEG 4.1 Clasificacin y catalogacin de los productos del CSI
IAS 1.1 Inicio-Inicio, Fin-Fin Plan de implantacin IAS-SEG 1.1 Estudio de la seguridad requerida para el IAS
IAS 3.1 Inicio-Inicio, Fin-Fin Instalacin del software IAS-SEG 2.1 Medidas de seguridad del entorno de operacin
IAS 5.2 Inicio-Inicio, Fin-Fin Pruebas de implantacin IAS-SEG 3.1 Evaluacin de las pruebas de seguridad de la implantacin
IAS 10.2 Fin-Inicio IAS completado IAS-SEG 4.1 Clasificacin y catalogacin de los productos del IAS IAS-SEG 5.1 Medidas de seguridad en el entorno de produccin
Iteracin Fase de Mantenimiento
MSI 4.3 Fin-Inicio Correccin MSI-CAL 1.1 Revisin del mantenimiento
MSI 3.3 Inicio-Inicio, Fin-Fin Pruebas de regresin MSI-CAL 2.1 Revisin del plan de pruebas de regresin
MSI 4.2 Inicio-Inicio, Fin-Fin Pruebas de regresin
Inicio Inicio
MSI-CAL 3.1 Evaluacin de pruebas de regresin
Fin
Fin
MSI 2.2 Inicio-Inicio, Fin-Fin Propuesta de solucin MSI-SEG 1.1 Estudio de seguridad requerida en el MSI MSI-SEG 2.1 Estudio de la peticin
MSI 4.3 Fin-Inicio Fin del MSI MSI-SEG 2.2 Cambios en los mecanismos de seguridad MSI-SEG 3.1 Clasificacin y catalogacin de los productos del MSI
MSI 3.3 Inicio-Inicio, Fin-Fin Modificacin MSI-GC 1.1 Registro del cambio
MSI 2.2 Inicio-Inicio, Fin-Fin Producto modificado MSI-GC 1.2 Registro de la nueva versin de un producto MSI-GC 1.3 Registro de la nueva versin del sistema
Inicio Inicio
Fin
Fin
Inicio Inicio
GPS 4.2
Inicio Fin
Fin
Inicio Fin
Fin
Fin Inicio
Inicio Fin
Fin
Inic io
Inicio Fin
GPS 4.3
Fin
Inicio
GPS 6.1
Inicio Inicio
Inicio Inicio
Fin Fin
Inicio
Fin
Inicio
Inicio
Fin
Fin
Fin
Fin
Fin Inicio Fin
Inicio
Inicio Inicio
Inicio Fin
Fin
Fin
Inicio Inicio
Inicio Inicio
Fin
Fin
Fin
Fin
GPF 1.1 Cierre del proyecto, inclusin en el histrico de proyectos
GPF 1.2 Archivo de la documentacin de gestin del proyecto
Implantacin en una Nueva Organizacin

285 de 297
Conversin a la nueva metodologa

Debe estar apoyada por la direccin y originada por una necesidad como responder a la competencia o aumentar unos beneficios considerados insuficientes. Pasos: Directriz de ingeniera. Implementacin de la transicin.

286 de 297
Directriz de Ingeniera
Punto de partida: El ejecutivo inicial explica porqu la empresa est cambiando a un proceso software mejorado. La directriz cubre: La situacin 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.
287 de 297
Aspectos importantes: Garanta de apoyo:
Los jefes de proyecto deben confiar en poder obtener apoyo financiero continuado que cubra, entre otras cosas, la formacin inicial, el asesoramiento, y la formacin continuada a medida que cambian las necesidades. Al comenzar un nuevo proyecto con un nuevo proceso se depende de la plena integracin de cuatro aspectos: Proceso. Herramientas. Formacin. Asesora.

288 de 297
Aspectos importantes: Garanta de apoyo. Continuidad en los proyectos existentes:
Los proyectos actuales y la mayora de los que aparezcan en un futuro inmediato tendrn que continuar con el proceso actual, la implantacin del nuevo proceso debe ser paulatina.
Confianza en el propio futuro:

Algunas personas implicadas en la transicin habrn tenido alguna dificultad para mantenerse al da sobre los cambios acaecidos en el sector. La confianza en su propio futuro ayudar a la transicin.

289 de 297
Implementacin de la transicin
Participantes: El lder:
El ejecutivo del software necesitar un ingeniero tcnicamente cualificado que lidere el cambio da a da, es decir, que supervise la transicin. El lder debe comprender la nueva metodologa para lo que debe realizar alguna formacin y conseguir asesora 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 tcnico. Adaptar la nueva metodologa a las necesidades del primer proyecto, es decir, comenzar desde cero.

290 de 297
Participantes: El lder. El jefe del primer proyecto:
El ejecutivo del software tambin 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 metodologa. Debe tener la habilidad de anticipar problemas en el proyecto, basndose en la experiencia, y debe ser capaz de colaborar con un variado grupo de participantes; lder, jefe de proyecto, personal del proyecto y el ejecutivo del software.

291 de 297
Participantes: El lder. El jefe del primer proyecto. El asesor.

292 de 297
Condiciones: Se empieza por un proyecto real y crtico. Se debe intentar no introducir demasiadas novedades al mismo tiempo aparte del proceso y sus herramientas, tales como nuevo sistema operativo, nueva tecnologa de bases de datos, nuevo lenguaje de programacin o nueva plataforma distribuida.

293 de 297
Consideraciones adicionales: Un enfoque ms gradual, puede caer en el error contrario del relatado anteriormente. Debido a que el progreso es casi invisible, el apoyo desaparece gradualmente y la transicin fracasa. Reestructurar el proceso paso a paso lleva mucho tiempo y a menudo falla. En cualquier caso, es mejor tener la transicin bajo control efectivo de los gestores al llevarla a cabo. Los errores resultantes de un falta de control son difciles de arreglar.

294 de 297
Especificacin de la metodologa
Es un marco de trabajo que debe ser adaptado a una serie de variables: Tamao del sistema en curso. Dominio con el que ha de trabajar el sistema. Complejidad del sistema. Las cualidades de la organizacin del proyecto y sus miembros.

295 de 297
Adaptacin del proceso

Aspectos constantes: La cuatro fases. Los cinco flujos de trabajo fundamentales. Aspectos variables: La longitud relativa de las fases. El nmero de iteraciones para cada fase bajo diferentes circunstancias. Cundo considerar suficientemente definidas:
La arquitectura candidata. La mitigacin de riesgos. La lnea de base de la arquitectura. El anlisis del negocio.
296 de 297
Adaptacin del proceso

Factores que influyen en los aspectos variables: El tamao del sistema. La naturaleza de la aplicacin. La experiencia de la organizacin 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 colaboracin de los implicados en el proyecto.

297 de 297

TEMA4

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

TEMA4

Cargado por

Copyright:

Formatos disponibles

Metodologa para el Desarrollo de Software

Jos Ignacio Pelez Snchez Universidad de Mlaga

Jos Ignacio Pelez Snchez Universidad de Mlaga

Jos Ignacio Pelez Snchez Universidad de Mlaga

Jos Ignacio Pelez Snchez Universidad de Mlaga

Jos Ignacio Pelez Snchez Universidad de Mlaga

Jos Ignacio Pelez Snchez Universidad de Mlaga

Dirigido por Casos de Uso

Jos Ignacio Pelez Snchez Universidad de Mlaga

Dirigido por Casos de Uso

Jos Ignacio Pelez Snchez Universidad de Mlaga

Dirigido por Casos de Uso

Jos Ignacio Pelez Snchez Universidad de Mlaga

Dirigido por Casos de Uso

Jos Ignacio Pelez Snchez Universidad de Mlaga

Dirigido por Casos de Uso

Jos Ignacio Pelez Snchez Universidad de Mlaga

Dirigido por Casos de Uso

Jos Ignacio Pelez Snchez Universidad de Mlaga

Jos Ignacio Pelez Snchez Universidad de Mlaga

Jos Ignacio Pelez Snchez Universidad de Mlaga

Jos Ignacio Pelez Snchez Universidad de Mlaga

Jos Ignacio Pelez Snchez Universidad de Mlaga

Jos Ignacio Pelez Snchez Universidad de Mlaga

Jos Ignacio Pelez Snchez Universidad de Mlaga

Relacin Casos de Uso-Arquitectura

Jos Ignacio Pelez Snchez Universidad de Mlaga

Relacin Casos de Uso-Arquitectura

Jos Ignacio Pelez Snchez Universidad de Mlaga

Jos Ignacio Pelez Snchez Universidad de Mlaga

Jos Ignacio Pelez Snchez Universidad de Mlaga

Jos Ignacio Pelez Snchez Universidad de Mlaga

Jos Ignacio Pelez Snchez Universidad de Mlaga

Jos Ignacio Pelez Snchez Universidad de Mlaga

Jos Ignacio Pelez Snchez Universidad de Mlaga

Jos Ignacio Pelez Snchez Universidad de Mlaga

Jos Ignacio Pelez Snchez Universidad de Mlaga

Jos Ignacio Pelez Snchez Universidad de Mlaga

Jos Ignacio Pelez Snchez Universidad de Mlaga

Jos Ignacio Pelez Snchez Universidad de Mlaga

Jos Ignacio Pelez Snchez Universidad de Mlaga

Jos Ignacio Pelez Snchez Universidad de Mlaga

COMPRENSIN DEL SISTEMA

Jos Ignacio Pelez Snchez Universidad de Mlaga

Comprensin del Contexto del Sistema

Jos Ignacio Pelez Snchez Universidad de Mlaga

Tipos de clases y objetos:

Jos Ignacio Pelez Snchez Universidad de Mlaga

Jos Ignacio Pelez Snchez Universidad de Mlaga

Jos Ignacio Pelez Snchez Universidad de Mlaga

Jos Ignacio Pelez Snchez Universidad de Mlaga

Jos Ignacio Pelez Snchez Universidad de Mlaga

Jos Ignacio Pelez Snchez Universidad de Mlaga

Jos Ignacio Pelez Snchez Universidad de Mlaga

Jos Ignacio Pelez Snchez Universidad de Mlaga

Jos Ignacio Pelez Snchez Universidad de Mlaga

Jos Ignacio Pelez Snchez Universidad de Mlaga

Relacin entre los dos Modelos

Jos Ignacio Pelez Snchez Universidad de Mlaga

Diferencias entre los Modelos

Diferencias entre los Modelos

Jos Ignacio Pelez Snchez Universidad de Mlaga

Diferencias entre los Modelos

Jos Ignacio Pelez Snchez Universidad de Mlaga