Disciplinas del PUD

Estas son las disciplinas principales:

Modelado de negocio: Cuando se requiere comprender el negocio a gran escala o reingeniería de procesos del negocio, esto incluye el modelado dinámico con Diag. De actividades, reglas de negocio, usuarios, etc.

Captura de Requisitos: Listado de requisitos para una aplicación, como escritura de casos de uso en alto nivel e identificación de requisitos no funcionales.

Análisis: Especificación expandida de casos de usos en formato esencial. Modelo de dominio. Diagrama de secuencias y colaboración. Diag. de estados.

Diseño: Todos los aspectos de diseño, incluyendo la arquitectura global, objetos, base de datos, red, interfaz de usuarios, etc.

Implementación: Significa programar y construir el sistema utilizando una herramienta de desarrollo. Implementar la base de datos en un SGBD.

Prueba: Realizar planes de pruebas y documentar los casos de pruebas aplicando técnicas como de caja blanca, caja negra, u otras.

Fase de Inicio

El objetivo de la fase de inicio es desarrollar el análisis de negocio hasta el punto necesario para justificar la puesta en marcha del proyecto.

Lo que se intenta es hacer una idea de la arquitectura para asegurarse de que existe una arquitectura que puede soportar el ámbito del sistema.

Productos de la Fase de Inicio

Una lista de características

Una primera versión del modelo de negocio (o del dominio) que describe el contexto del sistema

Un esbozo de los modelos que representan una primera versión del modelo de casos de uso, el modelo de análisis y el modelo de diseño.

Un primer esquema de la descripción de una arquitectura candidata, que perfila las vistas de los modelos de casos de uso, análisis, diseño e implementación.

Posiblemente, un prototipo exploratorio que muestra el uso del nuevo sistema

Una lista inicial de riesgos y una clasificación de casos de uso

Un plan tentativo para el proyecto en su totalidad, incluyendo el plan general de las fases

Un primer borrador del análisis de negocio, que incluye:

Contexto del negocio y Criterios de éxito.

Fase de Elaboración

Al comienzo de la fase de elaboración, se recibe de la fase de inicio un plan para la fase de elaboración, un modelo de casos de uso parcialmente completo y una descripción de la arquitectura candidata.

También se dispone de un prototipo que muestre el funcionamiento del sistema.

Sin embargo, no se puede pretender construir sobre ese prototipo

Ejecución de los flujos de trabajo fundamentales:

Recopilación de requisitos: En este punto encontraremos, estableceremos la prioridad y estructuraremos los casos de uso.

Análisis:

Durante la fase de inicio, comenzamos a hacer un borrador del modelo de análisis. Ahora, construiremos sobre este borrador, pero podemos descubrir que es necesario desechar partes sustanciales de él.

Diseño:

El arquitecto es responsable del diseño de los aspectos arquitectónicamente significativos del sistema, tal como están descritos en la vista de la arquitectura del modelo de diseño.

La vista de la arquitectura del modelo de diseño incluye subsistemas, clases, interfaces y realizaciones de casos de uso arquitectónicamente significativos, incluidos éstos en la vista del modelo de casos de uso

Implementación:

Se implementa y prueba los componentes arquitectónicamente significativos a partir de los elementos de diseño arquitectónicamente significativos.

El resultado es la línea base de la arquitectura, implementada normalmente a partir de menos del 10 por ciento de los casos de uso.

Prueba:

Aquí el objetivo es asegurarse de que los subsistemas de todos los niveles y de todas las capas funcionen.

Sólo podemos probar los componentes ejecutables.

Preferiblemente un modelo completo de negocio que describe el contexto del sistema

Una nueva versión de todos los modelos: casos de uso, análisis, diseño, despliegue e implementación.

Una línea base de la arquitectura

Una descripción de la arquitectura, incluyendo vistas de los modelos de casos de uso, análisis, diseño, despliegue e implementación Una lista de riesgos actualizada

El plan del proyecto para las fases de construcción y transición

Un manual de usuario preliminar

El análisis de negocio completo, incluida la apuesta económica

Fase de Construcción

El propósito primordial de esta fase es dejar listo un producto software en su versión operativa inicial, a veces llamada “versión beta”.

El producto debería tener la calidad adecuada para su aplicación y asegurarse de cumplir los requisitos.

La construcción debería tener lugar dentro de los límites del plan de negocio.

Recordemos que para cumplir los objetivos de la fase de elaboración, se han recopilado casi todos los requisitos, pero aún no han sido detallados completamente.

Ejecución de los flujos de trabajo fundamentales:

Captura de requisitos:

en la fase de construcción se recorrerá todo el camino hasta lograr el sistema inicial con capacidad operativa, así que hay que realizar la recopilación completa de requisitos

Análisis:

Aquí consideraremos de nuevo las actividades de análisis de la arquitectura, analizar un caso de uso, analizar una clase y analizar un paquete, iniciadas en la fase de elaboración.

Diseño:

Normalmente, en esta fase se diseña e implementa el 90 por ciento restante de los casos de uso (aquellos que no fueron utilizados para desarrollar la línea base de la arquitectura).

Implementación:

Implementa y lleva a cabo las pruebas de unidad de todos los componentes, trabajando principalmente a partir del modelo de diseño. El resultado es la versión operativa inicial, que representa el 100 por 100 de los casos de uso.

El proyecto lleva a cabo la mayor parte del trabajo de la fase de construcción, construyendo los componentes

Prueba:

Los esfuerzos de los ingenieros de pruebas para descubrir lo que puede ser comprobado de forma efectiva y para desarrollar casos de prueba y procedimientos de prueba para hacerlo, tendrán su fruto en la fase de construcción.

Productos de la Fase de Construcción

El plan de proyecto para la fase de transición

El sistema software ejecutable. Ésta es la construcción final de la fase

Todos los artefactos, incluyendo los modelos del sistema

La descripción de la arquitectura, mínimamente modificada y actualizada

Una versión preliminar del manual de usuario, lo suficientemente detallado como para guiar a los usuarios de la beta

Fase de Transición

Una vez que el proyecto entra en la fase de transición, el sistema ha alcanzado la capacidad operativa inicial.

El jefe de proyecto ha considerado que el sistema ofrece la confianza suficiente como para operar en el entorno del usuario, aunque no sea necesariamente perfecto

El usuario puede descubrir con retraso la necesidad de determinadas características.

Si son muy importantes y casan bien con el producto existente, el jefe de proyecto puede aceptar añadirlas.

Sin embargo, los cambios deben ser lo suficientemente pequeños como para que puedan ser introducidos sin afectar seriamente el plan del proyecto.

Ejecución de los flujos de trabajo fundamentales:

En esta fase, la actividad es baja en los cinco flujos de trabajo.

Como casi todo el trabajo se realizó en la fase de construcción, el nivel de actividad en esta fase es bajo, justo lo necesario para corregir los problemas encontrados durante las pruebas en el entorno del usuario.

Normalmente, las actividades de diseño disminuyen durante la fase de transición.

La atención se desplaza a la corrección de defectos para :

eliminar los fallos que ocurran durante el uso inicial, a asegurarse de que las correcciones en sí están bien, y a hacer pruebas de regresión para asegurar que estas modificaciones no introduzcan nuevos defectos

Productos de la Fase de Transición

El propio software ejecutable, incluyendo el software de instalación Documentos legales como contratos, licencias, renuncias de derechos y garantías

La versión completa y corregida de línea base de la versión del producto, incluyendo todos los modelos del sistema La descripción completa y actualizada de la arquitectura

Manuales y material de formación del usuario final, del operador y del administrador del sistema

Referencias para la ayuda del cliente, acerca de dónde encontrar más información, cómo informar de defectos o dónde encontrar información sobre defectos y actualizaciones.