RUP y UML1

1.4 Objetivos

1.4.1 Objetivo General

Aplicar el Proceso Unificado de Desarrollo en la Construcción de un Sistema de

Administración de Mensajería para Infotec.

1.4.2 Objetivos Específicos

Identificar y establecer iteraciones para los casos de uso.

Analizar el dominio del problema.

Establecer una base arquitectónica sólida.

Eliminar los elementos de más alto riesgo del proyecto.

Elaborar casos de uso de acuerdo al plan de iteraciones.

Desarrollar y probar el software.

2.1 El Proceso Unificado de Desarrollo – RUP

2.1.1 Introducción

El Proceso Unificado de Desarrollo (RUP) es un Proceso de Desarrollo de Software,

entendiéndose como tal al conjunto de actividades necesarias para convertir los

requisitos de un usuario en un sistema (Glosario) software.

El RUP se adapta a gran variedad de sistemas, áreas, tipos de organización y tamaños

de proyecto.

Se basa en componentes interconectados a través de interfaces (Glosario) y utiliza el

Lenguaje Unificado de Modelado (UML) para preparar todos los modelos de un sistema

software.

Las premisas del RUP son:

Dirigido por casos de uso

Centrado en la arquitectura

Iterativo e Incremental

2.1.1.1 La Vida del Proceso Unificado de Desarrollo de Software

El Proceso Unificado se repite a lo largo de una serie de ciclos que constituyen la vida de

un sistema. Cada ciclo concluye con una versión (Glosario) del producto para los

clientes.

El Proceso consta de cuatro fases: inicio, elaboración, construcción y transición. Cada

fase se subdivide a su vez en iteraciones. (Figura 2.1)

1

Iteración#n...

Iteración#n - 1

Elaboración

Iteración#2...

Iteración#1

Inicio Construcción Transición

Tiempo

Versiones

Figura 2.1: RUP y sus fases [RUP-2000]

2.1.1.2 Modelos

A pesar de que el usuario final considera como más importantes los componentes

ejecutables del sistema software, esto no es así. Cuanto más se comprenden los

requerimientos del usuario, la variación de los mismos es una constante a lo largo del

desarrollo del software y como consecuencia es necesaria la inversión en un nuevo

proyecto. Para ello los diseñadores requieren de todas las representaciones del producto

software que son los modelos:

De casos de uso con todos los casos de uso y sus relaciones con los usuarios.

De análisis con dos propósitos: refinar los casos de uso con más detalle y

establecer la asignación inicial de funcionalidad del sistema a un conjunto de

objetos que proporcionan el comportamiento.

De diseño que define: la estructura estática del sistema en forma de subsistemas,

clases e interfaces y los casos de uso reflejados como colaboraciones (Glosario)

entre los subsistemas, clases e interfaces.

De implementación que incluye componentes y la correspondencia de las clases

con los componentes.

De despliegue o de distribución que define los nodos físicos y la correspondencia

de los componentes con esos nodos.

De prueba que describe los casos de prueba que verifican los casos de uso.

Además es necesario contextualizar el negocio en el que se encuentra el sistema a

través de un Modelo de dominio o de negocio.

Los modelos son quizá el tipo de artefacto más interesante utilizado dentro del proceso,

los cuales recogen las perspectivas de los trabajadores (Glosario).

2.1.1.3 Fases

Las fases a través de las cuales se desarrolla el Proceso Unificado de Desarrollo se

muestran en la Figura 2.2.

2

Figura 2.2: Flujos de Trabajo, Fases y sus Iteraciones [RUP-2002]

2.1.1.3.1 Fase de inicio

Durante esta fase se desarrolla una descripción del producto final a partir de una buena

idea y se presenta el análisis del negocio para el producto.

Esencialmente, esta fase responde a las siguientes preguntas:

¿Cuáles son las principales funciones del sistema para sus usuarios más

importantes?

¿Cómo podría ser la arquitectura del sistema?

¿Cuál es el plan del proyecto y cuánto costará desarrollar el producto?

La respuesta a la primera pregunta se encuentra en un modelo de casos de uso

simplificado que contenga los casos de uso más críticos. Cuando lo tengamos, la

arquitectura es provisional, y consiste típicamente en un simple esbozo que muestra los

subsistemas más importantes. En esta fase, se identifican y priorizan los riesgos más

importantes, se planifica en detalle la fase de elaboración y se estima el proyecto de

manera aproximada.

2.1.1.3.2 Fase de elaboración

Durante esta fase, se especifican en detalle la mayoría de los casos de uso del producto

y se diseña la arquitectura del sistema. La relación entre la arquitectura del sistema y el

propio sistema es primordial.

Por tanto, la arquitectura se expresa en forma de vistas de los modelos del sistema, los

cuales juntos representan al sistema entero. Esto implica que hay vistas arquitectónicas

del modelo de casos de uso, del modelo de análisis, del modelo de implementación y

modelo de despliegue. La vista del modelo de implementación incluye componentes para

probar que la arquitectura es ejecutable. Durante esta fase del desarrollo, se realizan los

3

casos de uso más críticos que se identificaron en la fase de comienzo. El resultado de

esta fase es una línea base (Glosario) de la arquitectura.

2.1.1.3.3 Fase de construcción

Durante esta fase se crea el producto. En esta fase, la línea base de la arquitectura crece

hasta convertirse en el sistema completo. La descripción evoluciona hasta convertirse en

un producto preparado para ser entregado a la comunidad de usuarios.

Al final de esta fase, el producto contiene todos los casos de uso que la dirección y el

cliente han acordado para el desarrollo de esta versión. Sin embargo, puede que no esté

completamente libre de defectos. Muchos de estos defectos se descubrirán y

solucionarán durante la fase de transición.

2.1.1.3.4 Fase de transición

Esta fase cubre el periodo durante el cual el producto se convierte en versión beta. En la

versión beta un número reducido de usuarios con experiencia prueba el producto e

informa de defectos y deficiencias. Los desarrolladores corrigen los problemas e

incorporan algunas de las mejoras sugeridas en una versión general dirigida a la totalidad

de la comunidad de usuarios.

2.1.2 El Proceso Unificado de Desarrollo dirigido por casos de uso

Los desarrolladores comienzan capturando los requisitos del cliente en la forma de casos

de uso en el modelo de casos de uso. Pero los casos de uso son más que una

herramienta para capturar requisitos; dirigen el proceso de desarrollo en su totalidad.

Los casos de uso son la entrada fundamental cuando se identifican clases, subsistemas

(Glosario) e interfaces, cuando se identifican y especifican casos de prueba, y cuando se

panifican las iteraciones del desarrollo y la integración del sistema.

Los objetivos principales de la captura de requisitos son: encontrar los verdaderos

requisitos –aquellos que al implementarse añadirán el valor que los usuarios esperaban-

y representarlos de un modo adecuado para los clientes, usuarios y desarrolladores.

Cada tipo de usuario del sistema puede ser representado por un actor que utiliza el

sistema interactuando con los casos de uso. Un caso de uso es una secuencia de

acciones que el sistema lleva a cabo para ofrecer un resultado de valor para un actor.

El modelo de casos de uso está compuesto por todos los actores y todos los casos de

uso de un sistema.

El modelo de análisis es una especificación detallada de los requisitos y es una primera

aproximación del modelo de diseño. Se lo utiliza para comprender de mejor manera los

casos de uso descritos en el flujo de trabajo de los requisitos, refinándolos en forma de

colaboraciones entre clasificadores (Glosario).

4

El modelo de diseño es jerárquico debido a que pueden existir agrupaciones de clases en

subsistemas, los cuales están relacionados a través de interfaces. Las relaciones dadas

entre clases de diseño pueden ser: asociaciones, generalizaciones y dependencias

(Glosario).

El modelo de análisis difiere del modelo de diseño en el hecho de que el primero es un

modelo conceptual en lugar de ser un esquema de la implementación.

El modelo de despliegue verifica que los casos de uso se pueden implementar como

componentes que se ejecutan en los nodos de cómputo.

El modelo de implementación es un conjunto de componentes –ficheros ejecutables- que

son resultado de la implementación de las clases diseñadas. Los casos de uso

determinan el orden en el que los componentes son implementados e integrados.

El modelo de prueba es un conjunto de casos de prueba, los cuales tienen trazabilidad

directa con los casos de uso. El caso de prueba define una colección de entradas,

condiciones de ejecución y resultados, lo que se resume a verificar que el sistema

software haga lo que el usuario desea que haga.

Los casos de prueba pueden establecerse una vez definidos los casos de uso; es decir,

ya se tiene una visión sobre el orden en el cual se puede realizarlos, integrarlos y

probarlos.

2.1.3 El Proceso Unificado de Desarrollo centrado en la arquitectura

Todo producto tiene una función y una forma y ninguna es suficiente por sí misma. En

este caso, la función corresponde a los casos de uso y la forma a la arquitectura.

Por un lado los casos de uso deben encajar en la arquitectura cuando se llevan a cabo; y

por otro, la arquitectura debe permitir el desarrollo de todos los casos de uso requeridos,

ahora y en el futuro. En realidad, tanto la arquitectura como los casos de uso deben

evolucionar en paralelo.

Para el arquitecto de software y los desarrolladores, resulta muy útil el representar al

sistema desde diferentes perspectivas, que son vistas de los diferentes modelos del

sistema (de casos de uso, de análisis, de diseño, de despliegue, de implementación y de

prueba)

Dichas vistas son conjuntos o partes de cada uno de los modelos en su totalidad; es

decir, si se trata del modelo de casos de uso, la arquitectura se establecerá en base a

aquellos casos de uso que sean representativos arquitectónicamente.

La arquitectura de software abarca decisiones importantes sobre:

La organización del sistema software.

Los elementos estructurales que compondrán el sistema y sus interfaces, junto

con sus comportamientos.

5

La composición de los elementos estructurales y del comportamiento en

subsistemas progresivamente más grandes.

El estilo de la arquitectura (Glosario) que guía esta organización: los elementos

y sus interfaces, sus colaboraciones y su composición.

La arquitectura software también está afectada por: el uso, la funcionalidad, el

rendimiento, la flexibilidad, la reutilización, la facilidad de comprensión, las restricciones y

compromisos económicos y tecnológicos, y la estética.

2.1.4 El Proceso Unificado de Desarrollo: Iterativo e Incremental

El Proceso Unificado es iterativo e incremental, ya que cada una de las fases del

desarrollo tiene una serie de repeticiones que vienen a constituirse en mini proyectos.

Cada iteración dentro de cada una de las fases (Inicio, Elaboración, Construcción y

Transición) es un mini proyecto debido a que es controlada, lo que involucra que debe

seleccionarse y ejecutarse de una forma planificada.

Los desarrolladores basan la selección de lo que se implementará en una iteración en

dos factores:

La iteración trata un conjunto de casos de uso que juntos amplían la utilidad del

producto desarrollado hasta ahora.

La iteración trata los riesgos más importantes.

Dentro de cada iteración, los desarrolladores identifican y especifican los casos de uso

relevantes, crea un diseño utilizando la arquitectura seleccionada como guía,

implementan el diseño mediante componentes y verifican que los componentes

satisfagan los casos de uso.

El desarrollo de todo producto busca el equilibrio entre su funcionalidad –casos de uso- y

su forma –arquitectura-. Esto se consigue a lo largo de una serie de iteraciones; por lo

que la técnica de desarrollo iterativo e incremental constituye el tercer pilar fundamental

del Proceso Unificado de Desarrollo de Software.

Además, el Proceso Unificado es iterativo e Incremental debido a que:

Toma las riendas de los riesgos más significativos desde el principio.

Pone en marcha una arquitectura que guía el desarrollo del software.

Establece el marco de trabajo que dirige de mejor forma los inevitables cambios

en los requisitos y en otros aspectos.

Construye el sistema a lo largo del tiempo y no al final, en donde algún cambio se

vuelve muy costoso.

6

Con este proceso, el personal trabaja de manera más eficaz.

2.1.5 Captura de Requisitos

Los cinco flujos de trabajo – requisitos, análisis, diseño, implementación y prueba -

tienen lugar sobre las cuatro fases: inicio, elaboración, construcción y transición.

Durante este apartado trataremos el primer flujo de trabajo, es decir la captura de los

requisitos.

De manera general los desarrolladores esperan que sean los usuarios los que conozcan

cuales son los requisitos del futuro producto software; la verdad es contraria, francamente

los usuarios no saben con claridad cuáles son los requisitos que pueden convertirse en

software ni tampoco cómo especificarlos de manera precisa. Además de no tener una

concepción global del problema.

Por lo tanto los desarrolladores acuden a personas intermediarias –analistas- con la

esperanza de que ellos posean una visión en conjunto, lo cual tampoco es cierto.

La captura de requisitos debe enfocarse en dar soporte a la misión para la cual fue

concebido el sistema, es decir dar valor al negocio que lo utiliza y sus clientes.

El objeto del flujo de trabajo captura de requisitos, es crear un documento a través del

cual se fije un acuerdo entre el cliente y los desarrolladores sobre que debe y que no

debe realizar el sistema, para alcanzar dicho resultado se debe emplear un lenguaje

natural sin incluir formalidad.

Los pasos a seguir durante este flujo de trabajo se enumeran a continuación, los cuales

en la realidad no se llevan a cabo separadamente:

Enumerar los requisitos candidatos: consiste en elaborar una lista con muchas

ideas la cual crece a medida que se añaden nuevos elementos. Dichas ideas

pueden convertirse en verdaderos requisitos. Esta lista de características es

utilizada para planificar el trabajo. Cada característica consta de una breve

descripción y de ciertos atributos como: estado, coste estimado de

implementación, prioridad y nivel de riesgo asociado a la implementación.

Comprender el contexto del sistema: Existen dos maneras para poder expresar y

comprender el contexto de un sistema, a través de un modelo del dominio,

utilizado principalmente para pequeños sistemas o software empotrado, y de un

modelo del negocio. En este último se describen los procesos del negocio y en

dichos procesos intervienen trabajadores, sus responsabilidades y las

operaciones que llevan a cabo.

7

Capturar requisitos funcionales: se realiza a través del modelado de los casos de

uso, en donde un caso de uso es un modo de utilizar el sistema.

Capturar requisitos no funcionales: estos especifican propiedades del sistema,

como restricciones de la implementación o del entorno, rendimiento, plataforma,

mantenimiento, fiabilidad, etc.; la mayoría de estos requisitos afectan solo a

ciertos casos de uso y por tanto deberían conectarse a ese caso de uso (como

valores etiquetados).

Los trabajos a realizar y los artefactos resultantes en este flujo de trabajo, se muestran a

continuación (Tabla 2.1):

Tabla 2.1: Trabajos a realizar y Artefactos resultantes del flujo Captura de

Requisitos

Trabajo a realizar Artefactos resultantes

Enumerar requisitos candidatos Lista de características

Comprender el contexto del sistema Modelo del dominio o del negocio

Capturar los requisitos funcionales Modelo de casos de uso

Capturar los requisitos no funcionales Requisitos adicionales o casos de uso concretos

2.1.5.1. Modelo del Negocio

El objetivo es identificar los casos de uso del software y las entidades de negocio

relevantes que el software debe soportar. El modelo del negocio está soportado por dos

tipos de modelos: modelo de casos de uso y modelos de objetos.

Si el modelo del negocio no se realiza se corre el riesgo de que los desarrolladores den

atención superficial a la manera en el que el negocio está hecho. Ellos hacen lo que

saben hacer mejor, lo cual es diseñar y crear software sin tomar en cuenta los procesos

del negocio. Esta situación desafortunada podría resultar en una pérdida costosa de

esfuerzos. Adicionalmente existe un riesgo creciente de que los sistemas que sean

construidos no soporten las verdaderas necesidades de un negocio.

La tabla que se muestra a continuación describe la notación y los íconos del modelo de

negocio utilizados en el UML (Tabla 2.2).

8

Tabla 2.2: Elementos para la notación del Modelo de Negocio

Icono Nombre Definición UMLActor del negocio Alguien o algo, fuera del negocio que

interactúa con el negocio.

Trabajador del negocio Rol o conjunto de roles dentro del negocio. Un trabajador del negocio interactúa con otros trabajadores del negocio y manipula las entidades del negocio.

Entidad del negocio Una “cosa” mantenida o usada por los trabajadores del negocio.

Caso de Uso del negocio Una secuencia de acciones que un negocio lleva a cabo y que produce un resultado observable de valor para un actor de negocio particular

Realización de caso de uso del negocio

Una colección de diagramas que muestran como los elementos de la organización son desarrollados para soportar un proceso del negocio

Unidad Organizacional Una colección de trabajadores del negocio, entidades del negocio, relaciones, realizaciones de caso de uso del negocio, y otras unidades organizacionales.

UML provee diferentes diagramas. Cada diagrama a su vez, provee una diferente

perspectiva acerca del negocio:

Diagramas de caso de uso, describen el contexto del negocio

Diagramas de Actividad, describen los comportamientos en el negocio, o flujos de

trabajo del negocio.

Diagramas de Clase, describen la estructura estática en el negocio.

Diagramas de Interacción (diagramas de secuencia y colaboración) describen las

interacciones dinámicas entre empleados y cosas que ellos manipulan. Así, ellos

indican cómo son realizados los comportamientos descritos en los diagramas de

actividad.

Los varios diagramas del negocio se agrupan en dos modelos del negocio, uno mirando

al negocio desde una perspectiva externa, el otro mirándolo desde dentro:

9

1. Un modelo de caso de uso del negocio (Figura 2.3) el cual mira al negocio desde

una perspectiva externa, en donde se muestran los actores y los casos de uso

que dichos actores utilizan (diagramas actividad nivel alto).

2. Un modelo de objetos del negocio el cual detalla como los procesos del negocio

son implementados internamente, en donde se encuentran los trabajadores,

entidades del negocio y unidades de trabajo, que juntos realizan los casos de uso

del negocio. Aquí intervienen las reglas del negocio y otras normas impuestas

(diagramas de actividad detallados, diagramas de clase, diagramas de

interacción).

Modelo de Casos de Uso del Negocio

Modelo de Objetos del Negocio

Modelo de Casos de Uso Modelo de Diseño Modelo de Implementación

Modelo de Prueba

Figura 2.3: Modelado del Negocio y del Sistema

2.1.5.2 Artefactos

2.1.5.2.1 Modelo de Casos de Uso

El objetivo de este modelo es llegar a un consenso de los requerimientos del sistema

entre los desarrolladores y el cliente (condiciones y posibilidades que debe cumplir el

sistema)

Contiene: actores, casos de uso y sus relaciones.

Puede que el modelo sea muy complejo y difícil de entender, es preferible agrupar casos

de uso y/o actores en paquetes.

10

2.1.5.2.2 Actor

Los actores representan a cada tipo de usuario del sistema o a sistemas externos, con

los cuales el sistema interactúa.

La base para la identificación de los actores del modelo de caso de uso, son los actores

del negocio en el modelo del negocio.

Cada instancia de un actor representa a un usuario del sistema.

2.1.5.2.3 Caso de Uso

Representa una secuencia de acciones que el sistema llevará a cabo al interactuar con

los actores. Es un fragmento de funcionalidad que el sistema ofrece para obtener un

resultado de valor para el actor.

Especifica el comportamiento de cosas dinámicas

De acuerdo a UML un caso de uso es un clasificador, es decir posee atributos y

operaciones, esto involucra que pueda incluir, diagramas de estado, diagramas de

actividad, colaboraciones y diagramas de secuencia. Los atributos de cada instancia de

un caso de uso son manejados y manipulados por la misma, durante la ejecución de un

caso de uso.

Los diagramas de estados especifican el ciclo de vida de las instancias de los casos de

uso, en términos de estados y transiciones entre los estados. Cada transición es una

secuencia de acciones.

Los diagramas de actividad son más detallados que los diagramas de estados, porque

describen la secuencia temporal de acciones que tiene lugar dentro de cada transición.

Los diagramas de colaboración y de secuencia se emplean para describir las

interacciones entre una instancia típica de un actor y una instancia típica de un caso de

uso.

Una instancia de un caso de uso es la realización o ejecución de un caso de uso.

Las instancias de los casos de uso solamente interactúan con instancias de actores, para

simplificar la abstracción del sistema y facilitar el entendimiento del sistema por parte del

cliente. Las interacciones entre casos de uso serán analizadas en las etapas de análisis y

diseño a través de las realizaciones de casos de uso.

2.1.5.2.3.1 Flujo de Sucesos

Es la descripción de la secuencia de acciones que se llevan a cabo dentro de un caso de

uso

11

2.1.5.2.3.2 Requisitos Especiales

Es una descripción de los requisitos no funcionales propios de cada caso de uso.

2.1.5.2.4 Descripción de la Arquitectura

Es una vista de los casos de uso significativos para la arquitectura. Se utiliza como

entrada cuando se priorizan los casos de uso para su desarrollo.

2.1.5.2.5 Glosario

Se utiliza un glosario para definir términos comunes a todas las personas involucradas en

el desarrollo y de esta manera evitar confusiones. No es recomendable tomar como

entrada para el glosario el modelo del negocio o de dominio, porque este no estaría

centrado en el sistema sino en su contexto.

2.1.5.2.6 Prototipo de Interfaz de usuario

Estos prototipos no solo ayudan para desarrollar mejores interfaces de usuario, sino

también a comprender mejor las interacciones entre los usuarios y el sistema, así como

los casos de uso en su esencia.

2.1.5.3 Trabajadores

2.1.5.3.1 Analista de Sistemas

Tiene como responsabilidad el modelado de los casos de uso, requisitos funcionales y no

funcionales. Delimita el sistema encontrando los actores y casos de uso y define el

glosario para dar consistencia al modelo. Dirige el modelado y coordina la captura de

requisitos.

2.1.5.3.2 Especificador de Casos de Uso

Es responsable de detallar cada caso de uso a través del establecimiento del flujo de

sucesos.

2.1.5.3.3 Diseñador de Interfaz de Usuario

Realizan una interfaz visual por cada actor del sistema, entendiéndose por diseño de una

interfaz de usuario a la implementación visual de las interfaces, la implementación real la

realizan los desarrolladores.

2.1.5.3.4 Arquitecto

Describe la vista de la arquitectura del modelo de casos de uso, esta es una entrada que

sirve para priorizar los casos de uso a ser realizados en la etapa de desarrollo.

12

2.1.5.4 Flujo de Trabajo

Analista de Sistemas

Encontrar actores y casos de uso Estructurar el

modelo de casos de uso

Arquitecto

Priorizar casos de uso

Especificador de casos de

uso

Detallar un caso de uso

Diseñador de interfaces de

usuario

Prototipar la interfaz de

usuario

Figura 2.4: Flujo de Trabajo de Captura de Requisitos [RUP-2000]

2.1.5.4.1 Encontrar Casos de Uso

Los objetivos de esta actividad son:

Delimitar el sistema de su entorno

Esbozar qué y quiénes (actores) interactuarán con el sistema y qué acciones

(casos de uso) se esperará del sistema

Capturar y definir un glosario de términos comunes, esenciales para detallar las

funcionalidades del sistema.

Esta actividad tiene especial importancia porque permite al Analista de Sistemas obtener

de manera adecuada los requisitos, respaldándose del cliente, usuarios y otros analistas.

Esta actividad consta de los siguientes pasos:

Encontrar los actores

Encontrar los casos de uso

Describir brevemente cada caso de uso

Describir el modelo de casos de uso completo, que incluye la elaboración del

glosario.

13

2.1.5.4.1.1 Encontrar los Actores

Si se parte de un modelo de negocio, esta actividad se vuelve simple, cada actor o

trabajador del modelo del negocio se convierte en un actor del modelo de casos de uso.

En el caso en que no se cuente con estas entradas, el analista de sistemas con ayuda del

cliente debe identificar usuarios, a los cuales se los puede organizar en categorías

representadas por actores.

En ambos casos se tienen que reconocer tanto a los actores que identifican sistemas

externos como a los actores para el mantenimiento y operación del sistema.

Hay dos criterios útiles a la hora de elegir a los candidatos a actores:

Debería ser posible por lo menos identificar a un usuario que represente al actor

candidato.

Debería existir una coincidencia mínima entre los roles que desempeñan las

instancias de los actores en el sistema.

Es importante nombrar de manera correcta a los actores para tener mayor claridad en

cuanto a la semántica.

2.1.5.4.1.2 Encontrar los Casos de Uso

Cuando se cuenta con un modelo del negocio, la identificación de casos de uso parte de

transformar cada rol que cumple un trabajador dentro del modelo del negocio en un caso

de uso; caso contrario, el analista de sistemas encontrará los casos de uso a través de

talleres que se desarrollarían con los clientes y usuarios.

El analista de sistemas repasa cada uno de los actores para encontrar los casos de uso.

Algunos de los candidatos a casos de uso no llegarán a hacerlo, sino más bien formarán

parte de otros casos de uso. En definitiva lo que se pretende encontrar son casos de uso

de fácil entendimiento.

El nombre de un caso de uso a menudo empieza con un verbo e indica la interacción que

tiene con el actor en el sistema.

Una norma que se podría aplicar para identificar si un candidato a caso de uso es un

caso de uso como tal, es verificar si por sí solo brinda el resultado de valor que el actor

en concreto espera de él y no se trata de la continuación de otro caso de uso.

Para asegurarnos que un caso de uso no sea tan pequeño, verificamos si el mismo

entrega al actor un resultado de valor. Cuando se piensa en casos de uso para un actor

en concreto, evitamos, por el contrario, encontrar casos de uso muy grandes.

14

La arquitectura ya establecida sirve de base como lineamiento para los nuevos casos de

uso, ya que aquellos que no se ajusten a la misma deben de ser modificados.

2.1.5.4.1.3 Describir brevemente cada caso de uso

En primera instancia los analistas de sistemas plantean de forma incipiente los casos de

uso, incluso a veces solamente anotan sus nombres para luego describir de manera

breve la secuencia de acciones que se llevan a cabo dentro de cada uno de ellos.

2.1.5.4.1.4 Describir el modelo de casos de uso en su totalidad

El modelo de casos de uso tiene que ser descrito en su totalidad, es decir, se deben

describir las relaciones existentes entre casos de uso y entre casos de uso y actores.

En la notación de UML esta descripción es un valor etiquetado dentro del modelo.

2.1.5.4.2 Priorizar Casos de Uso

La vista arquitectónica del modelo de casos de uso permite priorizar los casos de uso que

deben desarrollarse en las primeras iteraciones. Aquellos casos de uso que no sean

significativos arquitectónicamente hablando pueden desarrollarse en iteraciones

posteriores.

Aunque es importante tener en cuenta a aquellos casos de uso que son significativos

arquitectónicamente, es necesario recalcar que aquí también intervienen factores como el

económico y sobre todo el fin del negocio.

2.1.5.4.3 Detallar un Caso de Uso

El objetivo principal de detallar un caso de uso es describir el flujo de sucesos que se

llevan a cabo dentro del mismo; es decir, como comienza, se desarrolla y termina el caso

de uso y su interacción con los actores.

Los especificadores de casos de uso ya pueden empezar a detallar cada caso de uso a

partir del modelo de casos de uso y los diagramas asociados.

Los especificadores de casos de uso deben estar en continuo contacto con los usuarios,

despejar sus dudas y discutir sobre mejoras a los procesos para así dejar bien definida la

secuencia de acciones que tiene cada caso de uso.

2.1.5.4.3.1 Estructuración de la descripción de Casos de Uso

La descripción de casos de uso define los estados que la instancia de un caso de uso

puede tener y la transición entre los mismos a través de una secuencia de acciones.

15

Es muy probable que el número de estados y las transiciones entre los mismos sea

grande y por lo tanto complejo, por lo que es necesario encontrar una solución; solución

que viene dada por el planteamiento inicial de un camino básico, considerado como el

más frecuente y normal y a partir del cual se identifican caminos alternativos.

La descripción del camino básico vendría en un apartado y la descripción de los caminos

alternativos en sus correspondientes, a continuación. A veces el camino alternativo es tan

pequeño que su descripción puede hacerse en línea, es decir en el mismo apartado de la

descripción del camino básico.

2.1.5.4.3.1.1 Aspectos a incluir en la descripción de un caso de uso

Estado inicial como precondición

Cómo y cuándo comienza el caso de uso

Orden requerido de las acciones, si existiese alguno

Cómo y cuándo terminan los casos de uso

Posibles estados finales como poscondiciones

Caminos de ejecución que no están permitidos

Descripción del camino básico junto con las descripciones de los caminos

alternativos

Interacción del sistema con los actores y qué cambios producen

Requisitos no funcionales que se asocian como valores etiquetados de UML para

el caso de uso en cuestión. En la descripción, estos requisitos no funcionales

formarían parte de una sección adicional.

2.1.5.4.3.2 Formalización de la descripción de Casos de Uso

Cuando se trata de sistemas en tiempo real, que poseen muchos estados y transiciones,

la descripción de los casos de uso se vuelve muy compleja, por lo que es necesario

emplear otras herramientas como son: diagramas de estado, diagramas de actividad o

diagramas de interacción.

2.1.5.4.4 Prototipar la interfaz de usuario

El objetivo de esta actividad es construir un prototipo de interfaz de usuario.

Una vez que los analistas han desarrollado un modelo de casos de uso, es necesario

diseñar una interfaz de usuario que permita al mismo llevar a cabo los casos de uso de

manera eficiente.

16

Primero es necesario hacer un diseño lógico de la interfaz de usuario, luego el diseño

físico y al final se desarrolla los prototipos que ilustren la manera en la que pueden utilizar

el sistema los usuarios para ejecutar los casos de uso.

De esta manera se comprenden las necesidades antes de intentar realizarlas.

2.1.5.4.5 Estructurar el modelo de casos de uso

Los objetivos de estructurar un caso de uso son:

Extraer descripciones de funcionalidad, generales y compartidas, las mismas que

pueden ser utilizadas por descripciones más específicas

Extraer descripciones de funcionalidad adicionales u opcionales, las que pueden

extender descripciones más específicas.

El proceso para llegar a estructurar un modelo de casos de uso, empieza por tener un

modelo de casos de uso esbozado, el cual lo describen los especificadores y por último el

analista extrae fragmento de funcionalidad comunes y/o fragmentos de funcionalidad

opcionales que se ven reflejados a través de las relaciones de generalización y extensión

entre casos de uso.

Los “casos de uso reales” deberían ser los primeros en identificarse, un caso de uso real

puede contener casos de uso concretos y casos de uso abstractos, entendiéndose por

caso de uso concreto al que se le puede instanciar, es decir aquellos que son utilizados

por un actor, mientras que un “caso de uso abstracto” encapsula funcionalidad útil para

otros casos de uso.

2.1.6 Análisis

La importancia de un modelo de análisis radica en que:

Especifica más precisamente los requisitos, en comparación con el modelo de

casos de uso que es producto del análisis de requisitos.

El modelo de análisis es una vista del funcionamiento interno del sistema y se

describe utilizando el lenguaje de los desarrolladores.

El modelo de análisis estructura los requisitos de tal manera que facilita su

mantenimiento (comprensión, preparación y modificación).

El modelo de análisis es una entrada fundamental cuando se da forma al sistema

en el diseño y la implementación.

17

Tabla 2.3: Modelo de Casos de Uso vs. Modelo de Análisis [RUP-2000]

Modelo de Casos de Uso Modelo de Análisis

Descrito con el lenguaje del cliente Descrito con el lenguaje del desarrollador

Vista externa del sistema Vista interna del sistema

Estructurado por los casos de uso; proporciona la estructura a la vista externa

Estructurado por clases y paquetes estereotipados; proporciona la estructura a la vista interna

Utilizado fundamentalmente como contrato entre el cliente y los desarrolladores sobre que debería y que no debería hacer el sistema

Utilizado fundamentalmente por los desarrolladores para comprender como debería darse forma al sistema, es decir; como debería ser diseñado e implementado

Puede contener redundancias, inconsistencias, etc; entre requisitos

No debería contener redundancias, inconsistencias, etc; entre requisitos.

Captura la funcionalidad del sistema, incluida la funcionalidad significativa para la arquitectura.

Esboza como llevar a cabo la funcionalidad dentro del sistema, incluida la funcionalidad significativa para la arquitectura; sirve como una primera aproximación al diseño

Define casos de uso que se analizarán con más profundidad en el modelo de análisis

Define realizaciones de casos de uso, y cada una de ellas representa el análisis de un caso de uso del modelo de casos de uso

2.1.6.1 Artefactos

2.1.6.1.1 Modelo de Análisis

Un modelo de análisis está representado por un sistema de análisis que contiene al

paquete de análisis de más alto nivel, pudiendo existir más paquetes.

2.1.6.1.2 Clase del Análisis

Una clase de análisis tiene tres estereotipos que se encuentran estandarizados en UML,

sin depender de que estereotipo se trate toda clase de análisis, tiene las siguientes

características.

Trata únicamente los requisitos funcionales, dejando los no funcionales para las

etapas de diseño e implementación.

Una clase de análisis es más conceptual que formal, es decir, también posee

comportamiento, atributos y asociaciones, pero todos ellos en un nivel más alto.

La interfaz que ofrece una clase de análisis es en términos de responsabilidades,

antes que de operaciones.

18

Los atributos en una clase de análisis, pueden llegar a ser clases en el diseño y la

implementación.

2.1.6.1.2.1 Clase de Interfaz

Figura 2.5: Estereotipo para la clase de análisis de Interfaz

Refleja la relación entre el sistema y sus actores, es decir modela las partes del sistema

que dependen de los últimos (Figura 2.5).

Representan a menudo abstracciones de ventanas, formularios, paneles, etc. Es

suficiente que estas clases describan lo que se obtiene con la interacción; no es

necesario que describan como se ejecuta físicamente la interacción.

Cada clase de interfaz debería asociarse con al menos un actor del sistema y viceversa.

2.1.6.1.2.2 Clase de Entidad

Figura 2.6: Estereotipo para la clase de análisis de Entidad

Una clase de entidad es utilizada para modelar la información que es a menudo

persistente (Figura 2.6).

Un objeto de entidad no necesariamente es pasivo, incluso puede tener un

comportamiento complejo relativo a la información que representa.

Una clase de entidad contribuye a entender de qué clase de información depende el

sistema.

2.1.6.1.2.3 Clase de Control

Figura 2.7: Estereotipo para la clase de análisis de Control

19

Representa la lógica del negocio (Figura 2.7), lo cual se puede relacionar con

transacciones, secuencias, control de otros objetos, etc; es decir, a una clase de control

no se le asocia ninguna información concreta de larga duración que almacena el sistema.

Es necesario resaltar que tampoco encapsulan interacciones con actores, esta tarea está

relacionada con las clases de interfaz.

2.1.6.1.3 Realización de Caso de Uso - Análisis

Refleja el comportamiento del caso de uso en términos de clases de análisis y sus

colaboraciones.

La realización de Casos de Usos por contener clases de análisis también se centra de

manera natural en los requisitos funcionales. Puede contener además de los diagramas

de clases, una descripción textual del flujo de sucesos, diagramas de interacción y

requisitos especiales.

2.1.6.1.3.1 Diagramas de Clases

Las clases de análisis pueden participar en varias realizaciones de casos de uso, aunque

algunas de las responsabilidades, atributos y asociaciones suelen ser relevantes para

una única realización de caso de uso.

2.1.6.1.3.2 Diagramas de Interacción

El objetivo fundamental es identificar requisitos y responsabilidades sobre los objetos

mas no identificar secuencias de interacción detalladas y en orden cronológico; es por

ello que, para reflejar la interacción entre los objetos de análisis es conveniente utilizar

diagramas de colaboración.

En dichos diagramas se muestra la interacción entre objetos creando enlaces entre ellos

y añadiendo mensajes a esos enlaces; dicho mensaje refleja el propósito del objeto que

invoca sobre el objeto invocado.

2.1.6.1.3.3 Flujo de Sucesos - Análisis

Su correspondiente en el modelo de casos de uso detalla los pasos de un caso de uso

desde una perspectiva externa, mientras que éste detalla los pasos del mismo caso de

uso, desde una perspectiva interna, es decir, lo que el sistema llevaría a cabo utilizando

objetos lógicos, que en este caso serían las instancias clases de análisis.

El flujo de sucesos - análisis, no es más que una descripción textual del diagrama de

colaboración.

20

2.1.6.1.3.4 Requisitos especiales

Son los requisitos no funcionales específicos de la realización del caso de uso y que ya

pudieron ser capturados en el flujo de trabajo de requisitos, aunque también pueden

aparecer nuevos.

Los requisitos especiales también son descripciones textuales sobre los requisitos no

funcionales de la realización del caso de uso.

2.1.6.1.4 Paquete del análisis

Son utilizados para organizar las clases de análisis o realizaciones de casos de uso –

análisis en partes más manejables.

Los paquetes de análisis se caracterizan por ser cohesivos y débilmente acoplados.

Además los paquetes de análisis deben crearse en base a los requisitos funcionales y al

dominio del problema, mas no en requisitos no funcionales o en el dominio de la solución.

En algunos casos los paquetes de análisis se convertirán en subsistemas, en las dos

capas de aplicación superiores del modelo de diseño, o se distribuirán entre ellos.

2.1.6.1.4.1 Paquetes de servicio

En el Proceso Unificado de Rational, el concepto de servicio está soportado por los

paquetes de servicio.

Un servicio es un conjunto de acciones que se relacionan funcionalmente y que son

utilizadas en varios casos de uso. Un servicio es indivisible ya que el sistema lo ofrece de

manera total o no lo ofrece. Un caso de uso también es una secuencia de acciones, pero

se relaciona directamente con los actores, mientras el servicio lo hace con los clientes.

Algunas de las características de los paquetes de servicio son:

El paquete de servicio contiene un conjunto de clases relacionadas

funcionalmente.

El paquete de servicio es indivisible.

Son participantes uno o más paquetes de servicio en un caso de uso, o un

paquete de servicio puede participar en una o más realizaciones de casos de uso.

Un paquete de servicio cuando es diseñado o implementado puede distribuirse de

manera separada.

Los paquetes de servicio son mutuamente excluyentes, pero dependientes entre

ellos.

Son importantes para las etapas subsiguientes ya que ayudan a estructurar los

modelos de diseño e implementación en términos de subsistemas de servicio.

21

2.1.6.1.5 Descripción de la Arquitectura

Es una vista de la arquitectura del modelo de análisis, que contiene elementos

significativos para la arquitectura.

Los artefactos significativos en esta vista pueden ser :

Una descomposición del modelo de análisis en paquetes de análisis y sus

dependencias

Las clases de entidad que contienen parte del dominio del problema, clases de

interfaz que contienen interfaces de comunicación importantes y clases de control

con una amplia cobertura. Generalmente una clase abstracta es significativa para

la arquitectura y no sus subclases.

Realizaciones de casos de uso con amplia cobertura (que implica muchas clases

de análisis).



Su responsabilidad recae en garantizar que el modelo de análisis sea correcto y

consistente. El modelo de análisis es correcto cuando realiza la funcionalidad que se

describe en el modelo de casos de uso.

Además el arquitecto también es responsable de la arquitectura del modelo de análisis.

2.1.6.2.2 Ingeniero de Casos de Uso

El ingeniero de casos de uso es responsable de la integridad de la realización de casos

de uso – análisis. Con integridad se entiende que la realización de casos de uso –

análisis cumpla con el objetivo de funcionalidad determinado para el caso de uso en el

modelo de casos de uso.

2.1.6.2.3 Ingeniero de Componentes

Este trabajador está encargado de definir y mantener la integridad de las clases de

análisis, es decir de que sus responsabilidades, atributos, relaciones y requisitos

especiales estén acordes a lo se que espera de ella, en la realización o realizaciones de

casos de uso – análisis en la(s) que participa.

El ingeniero de componentes también es responsable de mantener la integridad a nivel

de paquetes de análisis, lo que implica que el contenido de los mismos sea correcto y

que las dependencias con otros paquetes sean correctas y mínimas.

22

Generalmente, si un ingeniero de componentes está a cargo de un paquete de análisis,

también lo estará de las clases contenidas en él y del diseño de sus correspondientes

subsistemas en la etapa de diseño.


Arquitecto

Análisis de la arquitectura

Ingeniero de casos de uso

Analizar un caso de uso

Ingeniero de Componentes

Analizar una clase

Analizar un paquete

Figura 2.8: Flujo de Trabajo de Análisis [RUP-2000]

2.1.6.3.1 Análisis de la arquitectura

Esta actividad tiene como objetivo desarrollar el modelo de análisis y la arquitectura a

través de la identificación de paquetes de análisis, clases de análisis evidentes y

requisitos especiales comunes.

2.1.6.3.1.1 Identificación de paquetes de análisis

Debido a que los requisitos funcionales han sido capturados como casos de uso, un

paquete de análisis que represente cierta funcionalidad del sistema, debe empezar

agrupando el mayor número de casos de uso que reflejen dicha funcionalidad.

Para agrupar los casos de uso presentes en un paquete de análisis, se debe tomar en

cuenta lo siguiente:

Los casos de uso deben estar relacionados por su funcionalidad.

Los casos de uso que interactúen con un mismo actor del sistema.

Los casos de uso relacionados a través de relaciones de generalización o de

extensión.

2.1.6.3.1.1.1 Gestión de los aspectos comunes entre paquetes del análisis

En ciertas ocasiones una clase de análisis es compartida por varios paquetes de análisis.

Generalmente se trata de clases de entidad. La manera apropiada de gestionar esta

situación es extrayendo la clase compartida del paquete de análisis y colocarla en un

23

nuevo paquete, o simplemente dejarla fuera, para que los paquetes que la compartan

dependan del nuevo paquete o de la clase más general.

2.1.6.3.1.1.2 Identificación de paquetes de servicio

Un paquete de servicio es la agrupación de clases de análisis relacionadas por su

funcionalidad en cuanto a la prestación de un servicio especifico, y que probablemente

será una unidad de compra.

2.1.6.3.1.1.3 Definición de dependencias entre paquetes del análisis

Cuando los contenidos de los paquetes se encuentren relacionados, existe dependencia

entre ellos. La dependencia entre paquetes debe ser mínima guardando sin embargo una

cohesión interna alta. Esto evita que cualquier cambio en una clase de análisis afecte a

clases presentes en otros paquetes de análisis.

Para observar de forma más clara la dependencia, se estratifica el modelo de análisis de

acuerdo a la funcionalidad: general y especifica. En una capa superior pueden estar

todos los paquetes cuya funcionalidad sea más especifica que aquellos de los cuales

dependen.

2.1.6.3.1.2 Identificación de clases de entidad obvias

Partiendo de las entidades del negocio o clases del dominio, se pueden identificar clases

de entidad.

Las clases entidad identificadas no deben ser numerosas, sino aquellas que están

presentes en las realizaciones de los casos de uso y que son significativas para la

arquitectura.

Las asociaciones para las clases de entidad se pueden identificar a partir de sus

correspondientes en el modelo del negocio o del dominio.

2.1.6.3.1.3 Identificación de requisitos especiales comunes

El arquitecto debe identificar los requisitos especiales presentes para algunas clases de

análisis. Entre estos requisitos se encuentran por ejemplo restricciones en: persistencia,

seguridad, tolerancia a fallos, transaccionabilidad, etc.

2.1.6.3.2 Analizar un caso de uso

Se realiza esta actividad para:

Identificar clases de análisis.

Distribuir el comportamiento del caso de uso entre los objetos de análisis que

interactúan.

24

Captura de requisitos especiales.

2.1.6.3.2.1 Identificación de clases de análisis

En esta actividad identificamos las clases de control, interfaz y entidad necesarias para la

realización de los casos de uso. Es necesario especificar: nombre, responsabilidades,

atributos y relaciones.

Normas para la identificación de las clases de análisis:

Para la identificación de las clases de entidad, considerar qué información se va a

utilizar y manipular en la realización de los casos de uso.

Establecer una clase de interfaz central para cada actor humano. Si el actor

interactúa con una clase de interfaz previamente definida, se debe considerar el

reutilizarla.

Para cada clase de entidad definir una clase de interfaz primitiva.

Para cada actor que sea un sistema interno identificar una clase de interfaz

central.

Para el control de la realización del caso de uso es necesario identificar una o

más clases de control.

2.1.6.3.2.2 Descripción de interacciones entre objetos del análisis

A través de diagramas de colaboración se describe la interacción que mantienen los

objetos del análisis.

El diagrama de colaboración sigue paso a paso el flujo de sucesos del caso de uso.

Respecto a los diagramas de colaboración, se observa lo siguiente:

Un caso de uso es invocado a través de un mensaje enviado por una instancia de

un actor sobre un objeto de interfaz.

Debe existir al menos un objeto de una clase de análisis participando en un

diagrama de colaboración, para que no sea superflua.

Una responsabilidad de un clase se puede identificar por los mensajes que esta

recibe de otra clase participante en un diagrama de colaboración.

En este tipo de diagramas, no importa la secuencia, sino la relación entre los

objetos de análisis, y en los requisitos (como se recoge en los mensajes) sobre

cada uno de ellos en particular.

El diagrama de colaboración debería tratar todas las relaciones del caso de uso

que se está realizando.

25

2.1.6.3.2.3 Captura de requisitos especiales

Se refiere a la captura de requisitos especiales de la realización del caso de uso, los

cuales se tratarán en las etapas de diseño e implementación.

2.1.6.3.3 Analizar una clase

Se analiza una clase para :

Identificar y mantener las responsabilidades de una clase del análisis, basadas en

su papel en las realizaciones de caso de uso.

Identificar y mantener los atributos y relaciones de la clase de análisis.

Capturar requisitos especiales.

2.1.6.3.3.1 Identificar responsabilidades

Al analizar los diagramas de clases, los diagramas de interacción y los flujos de sucesos-

análisis de las realizaciones de casos de uso, podemos identificar los roles que cumple

cada clase, al agrupar todos los roles de una clase en las diferentes realizaciones de

caso de uso, hemos identificado sus responsabilidades.

2.1.6.3.3.2 Identificación de atributos

Un atributo especifica una propiedad de una clase del análisis. Para su correcta

identificación se sugiere las siguientes normas:

El nombre de un atributo debería ser un nombre.

El tipo de los atributos es conceptual.

Se deben reutilizar tipos de atributos.

Los atributos no se comparten por varias clases del análisis.

Los atributos no deben dificultar el entendimiento de una clase, si lo hacen deben

separarse para conformar otra clase.

Los atributos de las clases de entidad son fácilmente reconocibles, y se lo puede

realizar desde una clase del dominio o desde una clase de entidad del negocio.

Los atributos de las clases de interfaz con actores humanos son elementos de

información manipulados por los actores.

Los atributos de las clases de interfaz con otros sistemas representan

propiedades de la interfaz de comunicación.

Los atributos de las clases de control son variables debido a su corto tiempo de

existencia.

26

2.1.6.3.3.3 Identificación de asociaciones y agregaciones

Los enlaces en los diagramas de colaboración son instancias de asociaciones o

agregaciones entre las clases de análisis.

Estas relaciones a modelar no son las existentes en la vida real, sino las necesarias para

cumplir la funcionalidad del caso de uso.

La identificación incluye la multiplicidad de las relaciones, nombres de los roles,

autoasociaciones, clases de asociación, roles ordenados, roles cualificados y

asociaciones n-arias.

2.1.6.3.3.4 Identificación de generalizaciones

La identificación de este tipo de relaciones es útil para encontrar comportamiento

compartido de clases. Las generalizaciones deben mantenerse en un nivel alto o

conceptual. Esta identificación resulta en un mejor entendimiento del modelo de análisis.

2.1.6.3.3.5 Captura de requisitos especiales

Aquí se tratan los requisitos no funcionales de cada clase de análisis que serán tratados

en las etapas posteriores de diseño e implementación. Para ello es necesario referirse a

los requisitos especiales del caso de uso.

2.1.6.3.4 Analizar un paquete

El analizar un paquete tiene por objetivos los siguientes:

Garantizar la independencia de un paquete tanto como sea posible.

Garantizar que el paquete pueda realizar algunas clases del dominio o caso de

uso.

Describir la dependencia entre paquetes.

2.1.7 Diseño

El diseño permite modelar el sistema de tal forma que cumpla los requisitos que se

muestran claramente en el modelo de análisis (Tabla 2.4).

Los objetivos del diseño son:

Comprender en profundidad las restricciones relacionadas con los requisitos no

funcionales, así como con los lenguajes de programación, componentes

reutilizables, sistemas operativos, tecnologías de interfaz de usuario, etc.

27

Servir de base para las actividades de implementación. Así como también permitir

el descomponer estas actividades para que sean manejadas por diferentes grupos

de desarrollo y en lo posible en forma paralela.

Capturar en forma temprana las interfaces entre subsistemas.

Formar una abstracción sólida de la implementación del sistema, partiendo del

hecho de que la implementación es solo un refinamiento del diseño.

Tabla 2.4: Modelo de Análisis vs. Modelo de Diseño [RUP-2000]

Modelo de Análisis Modelo de Diseño

Modelo conceptual, porque es una abstracción del sistema y permite aspectos de la implementación.

Modelo físico porque es una plano de la implementación.

Genérico respecto al diseño. No genérico, específico para una implementación.

Tres estereotipos conceptuales sobre las clases: Control, Entidad e Interfaz.

Cualquier número de estereotipos (físicos) sobre las clases, dependiendo del lenguaje de implementación.

Menos formal Más formal

Menos caro de desarrollar (ratio al diseño 1:5) Más caro de desarrollar (ratio al análisis 5:1)

Menos capas Más capas

Dinámico (no muy centrado en la secuencia) Dinámico (muy centrado en las secuencias)

Bosquejo del diseño del sistema, incluyendo su arquitectura.

Manifiesto del diseño del sistema, incluyendo su arquitectura (una de sus vistas).

Creado de manera informal en talleres o similares.

Creado principalmente como “Programación Visual” en ingeniería de ida y vuelta; el modelo de diseño es realizado según la ingeniería de ida y vuelta con el modelo de implementación.

Puede no estar mantenido durante todo el ciclo de vida del software.

Debe ser mantenido durante todo el ciclo de vida del software.

Define una estructura que es una entrada esencial para modelar el sistema-incluyendo la creación del modelo de diseño.

Da forma al sistema mientras que intenta preservar la estructura definida por el modelo de análisis lo más posible.

28

2.1.7.1 Artefactos

2.1.7.1.1 Modelo de Diseño

Este artefacto describe la realización física de los casos de uso y el impacto que tienen

sobre el sistema los requisitos funcionales y no funcionales, así como otras restricciones

de implementación.

La realización de caso de uso-diseño está conformada por colaboraciones entre clases

de diseño y sus objetos.

2.1.7.1.2 Clase del diseño

Una clase de diseño representa una abstracción sólida de una clase de implementación

en el sentido de que:

El lenguaje que se utiliza para describir la clase y sus funciones, así como

parámetros, atributos, etc., es el mismo lenguaje de programación. Las clases de

diseño aparecen como estereotipos correspondientes a construcciones en el

lenguaje de programación.

Se especifica con frecuencia la visibilidad de los atributos y operaciones de una

clase. Por ejemplo: public, private o protected en C++.

Las relaciones entre clases de diseño se representan como atributos adicionales

en las clases cuando estas se implementan.

Los métodos, es decir las realizaciones de las operaciones de una clase, pueden

especificarse durante el diseño en forma de lenguaje natural o pseudocódigo, y

luego ser utilizado como comentario en la implementación.

Los requisitos que no puedan manejarse durante el diseño se especifican como

requisitos de implementación.

2.1.7.1.3 Realización de caso de uso – diseño

Una realización de caso de uso – diseño describe como se lleva a cabo o se realiza un

caso de uso en términos de colaboraciones entre clases de diseño y sus objetos.

Una realización del caso de uso – diseño tiene una traza directa con una realización de

caso de uso análisis, en el modelo de análisis. Siempre y cuando el modelo de análisis

sea mantenido durante toda la vida del software, en caso contrario la traza del caso de

uso – diseño es directa al caso de uso en el modelo de casos de uso.

La realización de caso de uso – diseño está conformada por diagramas de clases de

diseño, diagramas de interacción entre clases de diseño y flujos de eventos o sucesos.

29

2.1.7.1.3.1 Diagramas de clases

Una clase de diseño, sus objetos, así como los subsistemas que los contienen, en

muchas situaciones participan en la realización de diferentes casos de uso, presentando

en cada uno de ellos comportamientos diferentes, todos estos se reflejan en un diagrama

de clases de diseño que muestra las clases o subsistemas y sus relaciones.

2.1.7.1.3.2 Diagramas de Interacción

En la etapa de diseño es importante identificar la secuencia en que las interacciones

entre objetos y entre actores y objetos sucede. Para detallar estas interacciones y

ordenarlas en el tiempo se recomienda la utilización de diagramas de secuencia. En

estos diagramas además de clases, pueden participar también subsistemas con el fin de

diseñar los casos de uso a un nivel más alto y en una etapa temprana del ciclo de vida

del software.

2.1.7.1.3.3 Flujo de sucesos – diseño

Los diagramas de secuencia, en especial cuando se requiere de varios para indicar una

interacción entre clases, son difíciles de comprender por si mismos, es por ello que se

requiere de este artefacto para describir textualmente el flujo de sucesos.

2.1.7.1.3.4 Requisitos de la implementación

Este artefacto contiene los requisitos no funcionales que se han capturado durante esta

fase o en fases anteriores y que es mejor tratarlos durante la fase de implementación.

2.1.7.1.4 Subsistema de diseño

Los subsistemas de diseño son una forma de dividir a los artefactos de diseño para que

estos sean más manejables; pueden contener clases, realizaciones de caso de uso,

interfaces y otros subsistemas.

Los contenidos de los subsistemas deben tener una fuerte asociación; sin embargo entre

subsistemas deben existir pocas interfaces.

Como características los subsistemas tienen:

Manejar aspectos separados del diseño, a fin, por ejemplo, de mantener grupos

de diseño que trabajen en paralelo.

Los subsistemas presentes en las capas más altas de aplicación del sistema

suelen poseer trazas directas a los paquetes del análisis.

Pueden representar sistemas heredados y encapsularlos.

30

Los subsistemas pueden encapsular productos software reutilizados que residirán

en la capa intermedia o de software del sistema.

2.1.7.1.4.1 Subsistemas de servicio

Se identifica un subsistema de servicio a partir de un paquete de servicio en el modelo de

análisis, existiendo una trazabilidad directa entre ellos. Por lo tanto, los subsistemas de

servicio se ubican en las dos capas superiores de la aplicación.

De manera análoga, su funcionalidad radica en aislar los cambios en servicios

individuales del resto de subsistemas

Sin embargo, el subsistema de servicio incluye adicionalmente lo siguiente:

Puede tener que ofrecer sus servicios en términos de interfaces y de sus

operaciones.

Tienen que tratar con un número mayor de requisitos no funcionales, así como

con restricciones propias del ambiente de implementación.

Los subsistemas de servicio dan lugar a un componente ejecutable en la

implementación. En sistemas grandes puede existir la necesidad de implantar un

subsistema en varios nodos con funcionalidad diferente; por lo que debe crearse

un componente ejecutable para cada nodo.

2.1.7.1.5 Interfaz

El artefacto interfaz es utilizado para especificar las operaciones que proporcionan, tanto

las clases, como los subsistemas. De esta manera, cualquier cambio en la

implementación de las interfaces no implicará que se tengan que hacer cambios en los

clientes.

La mayoría de las interfaces entre subsistemas son relevantes para la arquitectura,

debido que definen las interacciones permitidas entre los subsistemas.

En ciertas ocasiones se prefiere diseñar interfaces de manera temprana en el ciclo de

vida del software, en vez de implementarlas en la etapa de implementación.

2.1.7.1.6 Descripción de la Arquitectura (Vista del Modelo de Diseño)

La descripción de la arquitectura no es más que una vista del modelo de diseño, en

donde se encuentran los artefactos relevantes para la arquitectura, los mismos que

pueden ser:

Los subsistemas, interfaces y dependencias entre ellos, debido a que constituyen

la estructura fundamental del sistema.

Clases de diseño fundamentales, que resulten de una trazabilidad directa de las

clases del análisis. También son consideradas las clases de diseño centrales y

31

generales, es decir que tengan relación con muchas clases de diseño o que

presenten mecanismos de diseño genéricos. Normalmente basta considerar como

relevantes para la arquitectura solamente a las clases abstractas y no a las

subclases, a menos que tengan un comportamiento relevante para la arquitectura.

Realizaciones de caso de uso – diseño que comprendan alguna funcionalidad

importante para la arquitectura, ya sea que su cobertura sea amplia, o que

contengan clases de diseño fundamentales como las mencionadas en el ítem

anterior.

2.1.7.1.7 Modelo de Despliegue

Especifica la distribución física del sistema a través de los nodos de cómputo.

Es una de las entradas principales para el diseño y la implementación, debido a que la

distribución del sistema tiene una influencia principal en su diseño.

Estas son algunas de las características del modelo de despliegue:

Un nodo es un recurso de cómputo (procesador o cualquier dispositivo hardware

parecido)

Las relaciones en el modelo de despliegue, representan los medios de

comunicación entre los nodos (Internet, Intranet, Bus y similares).

La funcionalidad de un nodo se define por los componentes que se distribuyen

sobre ese nodo.

El modelo de despliegue muestra la relación entre la arquitectura software y la

arquitectura hardware.

2.1.7.1.8 Descripción de la Arquitectura (Vista del Modelo de Despliegue)

De manera análoga a la descripción de la arquitectura del modelo de diseño, la

descripción de la arquitectura del modelo de despliegue es una vista de la arquitectura

del mismo, en el cual, debido a la importancia del modelo, se muestran todos sus

aspectos.



El arquitecto es el responsable de la integridad de los modelos de diseño y de

despliegue, es decir, que sean correctos, consistentes y legibles. Un modelo es correcto

cuando realiza la funcionalidad, y sólo la funcionalidad descrita en el modelo de casos de

uso, en los requisitos adicionales y en el modelo de análisis.

El arquitecto, además es responsable de la arquitectura de los modelos de diseño y de

despliegue. Sin embargo, no es responsable del mantenimiento de los diferentes

32

artefactos del modelo de diseño; esto es responsabilidad del ingeniero de casos de uso y

de componentes.

2.1.7.2.2 Ingeniero de Casos de Uso

El ingeniero de casos de uso es responsable de la integridad de las realizaciones de

casos de uso – diseño; es decir que realicen correctamente la funcionalidad de su

correspondiente realización de caso de uso – análisis, así como de la correspondiente

realización de casos de uso del modelo de casos de uso.

El ingeniero de casos de uso no es responsable de las clases, subsistemas, interfaces y

relaciones de diseño. Estos artefactos son responsabilidad del ingeniero de

componentes.

2.1.7.2.3 Ingeniero de Componentes

El ingeniero de componentes es responsable de las clases de diseño, sus atributos,

métodos, operaciones, relaciones y requisitos de implementación; procurando que cada

clase cumpla con lo que se espera de ella, según la funcionalidad de la realización del

caso de uso en la que está presente.

Es también responsable de los subsistemas y su integridad; es decir, garantizar que sus

contenidos (clases y sus relaciones) sean correctos. Además se preocupa de que las

dependencias con otros subsistemas sean correctas y mínimas.

Es conveniente que el ingeniero de componentes sea el encargado del subsistema y de

todos los elementos que éste posee, además de que sea él, el encargado de la

implementación de las clases y subsistemas de diseño


Arquitecto

Diseño de la arquitectura

Ingeniero de casos de uso

Diseñar un caso de uso


Diseñar una clase

Diseñar un subsistema

Figura 2.9: Flujo de Trabajo de Diseño [RUP-2000]

33

2.1.7.3.1 Actividad: Diseño de la arquitectura

Esta actividad tiene como propósito esbozar los modelos de diseño y despliegue y su

arquitectura, identificando:

Nodos y sus configuraciones de red

Subsistemas y sus interfaces.

Clases del diseño significativas para la arquitectura, como las clases activas.

Mecanismos de diseño genéricos que tratan requisitos comunes, como los

requisitos especiales sobre persistencia, distribución, rendimiento y demás, tal y

como se capturaron durante el análisis sobre las clases y las realizaciones de

caso de uso – análisis.

Durante esta actividad los arquitectos deben analizar las posibles opciones de

reutilización, sea de otros sistemas o de software general, lo que resulte de este análisis

debe incorporarse al modelo de diseño.

2.1.7.3.1.1 Identificación de nodos y configuraciones de red

La arquitectura de software se ve seriamente influenciada por las configuraciones físicas

de la red.

Entre los aspectos de configuraciones de red se puede resaltar:

¿Qué nodos se necesitan, y cuál debe ser su capacidad en términos de potencia

de proceso y tamaño de memoria?

¿Qué tipo de conexiones debe haber entre los nodos, y qué protocolos de

comunicaciones se deben utilizar sobre ellas?

¿Qué características deben tener las conexiones y los protocolos de

comunicaciones, en aspectos tales como ancho de banda, disponibilidad y

calidad?

¿Es necesario tener alguna capacidad de proceso redundante, modos de fallo,

migración de procesos, mantenimiento de copias de seguridad de los datos, o

aspectos similares?

Cada una de las configuraciones de red, se debe mostrar en un diagrama de despliegue

separado. Una vez que se cuente con ellas se puede comenzar a analizar cómo puede

distribuirse la funcionalidad entre ellas.

2.1.7.3.1.2 Identificación de subsistemas y de sus interfaces

Se utilizan subsistemas para hacer más manejable al modelo de diseño. Se pueden

identificar desde el inicio o a medida que el diseño evoluciona.

34

No todos los subsistemas se desarrollan en el proyecto, algunos de ellos pueden ser

productos reutilizados y otros son recursos existentes en la empresa.

2.1.7.3.1.3 Identificación de clases de diseño relevantes para la arquitectura

Resulta práctico identificar estas clases pronto dentro del ciclo de vida del software, sin

embargo se podrá realizar con claridad al diseñar las clases dentro de esta actividad. Se

debe evitar por parte de los diseñadores, identificar demasiadas clases, basta con

esbozar las clases relevantes para la arquitectura.

2.1.7.3.1.3.1 Identificación de clases del diseño a partir de clases del análisis

Un punto de partida es identificar las clases de diseño partiendo de las clases del análisis

relevantes para la arquitectura, así como identificar tentativamente sus relaciones

2.1.7.3.1.3.2 Identificación de clases activas

El arquitecto considera los requisitos de concurrencia para la identificación de las clases

activas, estos requisitos pueden ser:

Requisitos de rendimiento.

La distribución del sistema sobre los nodos.

Otros requisitos, como progresión, evitación de interbloqueo, evitación de la

inanición, entre otros.

El ciclo de vida de los objetos de una clase activa, permiten esbozar dicha clase. Luego

de identificados los objetos, se asignan a los nodos del modelo de despliegue.

Para esbozar inicialmente a las clases activas se puede utilizar como entradas al modelo

de análisis y despliegue, y luego hacer coincidir los diseños de las clases de análisis con

los nodos.

2.1.7.3.1.4 Identificación de mecanismos genéricos de diseño

Para identificar mecanismos genéricos, en primer paso, se estudia los requisitos

comunes en las realizaciones de caso de uso – análisis y en las clases de análisis y

como segundo, decidimos como tratarlos tomando en cuenta las tecnologías empleadas

en el diseño e implementación.

Los requisitos que deben tratarse están relacionados con:

Persistencia

Distribución transparente de objetos

Detección y recuperación de errores

Gestión de transacciones, etc.

2.1.7.3.2 Actividad: Diseño de un caso de uso

Sus objetivos son los siguientes:

35

Identificar las clases de diseño y/o los subsistemas que intervienen en el flujo de

sucesos del caso de uso.

Distribuir el comportamiento del caso de uso entre los objetos del diseño que

interactúan y/o entre los subsistemas.

Definir los requisitos sobre las operaciones de las clases de diseño y/o sobre los

subsistemas y sus interfaces.

Capturar requisitos de implementación del caso de uso.

2.1.7.3.2.1 Identificación de clases del diseño participantes

Se identifican las clases del diseño necesarias para realizar el caso de uso. Para lograr

hacerlo se parte de:

Identificar las clases de diseño que tienen una traza hacia las clases de la

correspondiente realización de caso de uso – análisis.

Identificar las clases de diseño que realizan los requisitos especiales de la

correspondiente realización de caso de uso – análisis.

Todas estas clases deben ser asignadas a un ingeniero de componentes.

Cualquier clase faltante y detectada por el ingeniero de casos de uso debe ser

comunicada al ingeniero de componentes y al arquitecto.

2.1.7.3.2.2 Descripción de las interacciones entre objetos del diseño

Una vez identificadas las clases del diseño, el siguiente paso es mostrar como

interactúan las instancias de los mismos, es decir: las instancias de los actores y los

objetos del diseño a través de mensajes que se envían de uno hacia otro. Esto se lo hace

a través de diagramas de secuencia. Cada realización de caso de uso puede tener uno o

más diagramas de secuencia dependiendo del número de flujos de sucesos necesarios

para llevar a cabo ese caso de uso.

Como entrada básica para realizar esta actividad, se tiene el correspondiente diagrama

de colaboración en la realización de caso de uso – análisis; del cual se partiría para

realizar un primer esbozo del diagrama de secuencias.

Cuando se diseñan diagramas de secuencia hay que tomar en cuenta lo siguiente:

El causante de la invocación primera es la instancia del actor hacia algún objeto

de diseño.

Todas las clases de diseño identificadas en la actividad anterior deben tener al

menos un objeto en el diagrama de secuencias.

36

La secuencia del diagrama debe ser la principal preocupación, ya que la

realización del caso de uso – diseño es la entrada principal para la

implementación del caso de uso.

2.1.7.3.2.3 Identificación de subsistemas e interfaces participantes

A veces es necesario diseñar la realización de casos de uso – diseño a través de

subsistemas en vez de hacerlo con los objetos de las clases de análisis. Este

procedimiento es útil en el caso de desarrollo descendente.

Para realizar el caso de uso de esta forma es necesario:

Identificar los paquetes de análisis que contienen las clases de análisis que

intervienen en la realización del caso de uso – análisis. Después se identifican los

subsistemas de diseño que tienen trazabilidad con dichos paquetes.

Identificar los subsistemas de diseño que contienen las clases de diseño que

realizan los requisitos especiales de las correspondientes realizaciones de caso

de uso – análisis.

2.1.7.3.2.4 Descripción de interacciones entre subsistemas

Para describir las interacciones entre subsistemas, se utilizarán diagramas de secuencias

con las siguientes diferencias:

Las líneas de vida en los diagramas de secuencia denotan subsistemas en lugar

de objetos de diseño.

Cada subsistema identificado en la actividad anterior debe tener al menos una

línea de vida en el diagrama de secuencias.

2.1.7.3.2.5 Captura de requisitos de implementación

En esta actividad se identifican todos los requisitos no funcionales de la realización del

caso de uso que serán tratados en la implementación.

2.1.7.3.3 Actividad: diseño de una clase

El propósito de esta actividad es estructurar las clases del diseño, las cuales deben de

cumplir su papel en las realizaciones de los casos de uso y los requerimientos no

funcionales.

2.1.7.3.3.1 Esbozar la clase de diseño

Tomando como entrada las clases de análisis y/o interfaces, se esbozan las clases de

diseño.

37

Si se toma como entrada una interfaz, se asigna directamente una clase de diseño para

que proporcione esa interfaz.

Si la entrada son una o varias clases del análisis, los métodos a utilizarse dependen del

estereotipo de la clase de análisis:

Diseñar clases de interfaz es dependiente de la tecnología de interfaz específica

que se utilice.

Diseñar clases de entidad que representen información persistente, implica

generalmente el uso de tecnologías de bases de datos específicas.

Diseñar clases de control es una tarea delicada, debido a que encapsulan

secuencias, coordinación de otros objetos o pura lógica del negocio. Es necesario

considerar los siguientes aspectos:

o Aspectos de distribución

o Aspectos de rendimiento

o Aspectos de transacción

Las clases de diseño identificadas en este paso deberán ser asignadas trazando

dependencias a las correspondientes clases de análisis.

2.1.7.3.3.2 Identificar Operaciones

En esta etapa se identifican las operaciones que las clases de diseño van a necesitar y

describimos esas operaciones utilizando la sintaxis de los lenguajes de programación.

Algunas de las entradas importantes en esta etapa son:

Las responsabilidades de cualquier clase del análisis que tenga una traza con la

clase del diseño.

Los requisitos especiales de cualquier clases de análisis que tenga una traza con

la clase del diseño.

Las interfaces que la clase de diseño necesita proporcionar. Las operaciones de

las interfaces también necesitan ser proporcionadas por la clase de diseño.

Las realizaciones de caso de uso – diseño, en las que la clase participa.

Las operaciones de la clase de diseño necesitan soportar todos los roles que las clases

desempeñan en las diferentes realizaciones de casos de uso.

2.1.7.3.3.3 Identificar atributos

Aquí se identifican los atributos requeridos por la clase de diseño y se describen

utilizando la sintaxis del lenguaje de programación. Se debe tener en cuenta las

siguientes normas cuando se identifican atributos:

38

Considerar los atributos sobre cualquier clase de análisis que tenga una traza con

la clase de diseño.

Los tipos de atributos disponibles están restringidos por el lenguaje de

programación.

Cuando se elige un tipo de atributo, intentar reutilizar uno que ya exista.

Una simple instancia de atributo no puede ser compartida por varios objetos de

diseño. Si esto fuera necesario, el atributo necesita ser definido en una clase

separada.

Si una clase de diseño llega a ser muy complicada de comprender por culpa de

sus atributos, algunos de estos atributos pueden ser separados en clases

independientes.

Si hay muchos atributos o son complejos los atributos de una clase, se puede

ilustrar ésta en un diagrama de clases separado que muestre solamente el

apartado de atributos.

2.1.7.3.3.4 Identificar asociaciones y agregaciones

Los objetos de diseño interactúan unos con otros en los diagramas de secuencia. Estas

interacciones suelen corresponder a asociaciones entre clases.

El número de relaciones entre clases debe estar minimizado.

Se debe tener en cuenta las siguientes directrices generales a la hora de definir o

redefinir las asociaciones y agregaciones:

Considerar las asociaciones y agregaciones involucrando la correspondiente clase

de análisis.

Refinar la multiplicidad de las asociaciones, nombres de rol, clases de asociación,

roles de ordenación, roles de cualificación y asociaciones n-arias de acuerdo con

el soporte del lenguaje de programación utilizado.

Refinar la navegabilidad de las asociaciones.

2.1.7.3.3.5 Identificar las generalizaciones

Se debe manejar las generalizaciones con la misma semántica que la definida por el

lenguaje de programación. Si el lenguaje no soporta generalización, de deben utilizar

asociaciones o agregaciones para suplirla.

39

2.1.7.3.3.6 Describir los métodos

Se puede utilizar los métodos en el diseño para especificar como se deben realizar las

operaciones. El método puede ser especificado utilizando lenguaje natural o

pseudocódigo.

En la mayoría de ocasiones los métodos no se especifican durante el diseño, esto se lo

realiza durante la implementación utilizando un lenguaje de programación.

2.1.7.3.3.7 Describir estados

Algunos objetos del diseño son estados controlados, lo cual significa que sus estados

determinan su comportamiento cuando reciben un mensaje. En estas ocasiones, se debe

utilizar un diagrama de estados para describir las diferentes transiciones de estado de un

objeto del diseño.

2.1.7.3.3.8 Tratar requisitos especiales

Aquí se debe tratar cualquier requisito que no se haya considerado en pasos anteriores.

Para realizar esto se debe analizar los requisitos formulados en las realizaciones de caso

de uso en los que la clase participa.

Puede ser necesario posponer hasta la implementación, el tratamiento de algunos

requisitos. Estos requisitos deberían anotarse como requisitos de implementación para la

clase del diseño.

2.1.7.3.4 Actividad: Diseño de un subsistema


Garantizar que el subsistema sea tanto como sea posible, independiente de otros

subsistemas y de sus interfaces.

Garantizar que el subsistema proporciona las interfaces correctas.

Garantizar que el subsistema cumple su propósito de ofrecer una realización

correcta de las operaciones tal y como se definen en las interfaces que

proporciona.

2.1.7.3.4.1 Mantenimiento de las dependencias entre subsistemas

Se debe definir y mantener dependencias entre subsistemas cuando los contenidos

(clases) de cada uno de ellos se mantienen asociados. Hay que recalcar que si el

subsistema proporciona interfaces, las dependencias se realizan hacia la interfaz.

Se debe intentar minimizar las dependencias entre subsistemas y/o interfaces, tratando

de reubicar las clases contenidas en un subsistema dependiente de otros subsistemas.

40

2.1.7.3.4.2 Mantenimiento de interfaces proporcionadas por el subsistema

Las operaciones definidas por las interfaces que proporciona un subsistema deben

soportar todos los roles que cumple el subsistema en las diferentes realizaciones de caso

de uso.

La técnica para mantener interfaces y sus operaciones es similar a la técnica para

mantener clases del diseño y sus operaciones.

2.1.7.3.4.3 Mantenimiento de los contenidos de los subsistemas

Los ingenieros de componentes deben refinar los contenidos de los subsistemas que los

arquitectos esbozaron. Se debe considerar que por cada interfaz que proporcione el

subsistema, debería haber clases de diseño u otros subsistemas que también

proporcionen la interfaz.

Para clarificar cómo el diseño interno de un subsistema realiza cualquiera de sus

interfaces o casos de uso, se puede crear colaboraciones en términos de los elementos

contenidos en el subsistema.

2.1.8 Implementación

Los propósitos de la implementación son:

Definir la organización del código, en términos de subsistemas de implementación

organizados en capas

Implementar clases y objetos en términos de componentes (Archivos fuentes,

binarios, ejecutables y otros)

Probar los componentes desarrollados como unidades

Integrar los resultados producidos por implementadores individuales (o equipos),

dentro de un sistema ejecutable.

2.1.8.1 Artefactos

2.1.8.1.1 Modelo de Implementación

Describe cómo los elementos del modelo de diseño se implementan en términos de

componentes. El modelo de implementación describe también cómo se organizan los

componentes de acuerdo con los mecanismos de estructuración y modularización

disponibles en el entorno de implementación y en el lenguaje o lenguajes de

programación utilizados, y cómo dependen los componentes unos de otros.

El modelo de implementación se representa con un sistema de implementación que

denota el subsistema de nivel superior del modelo. El utilizar otros subsistemas es por

tanto una forma de organizar el modelo de implementación en trozos más manejables.

41

2.1.8.1.2 Componente

Un componente es el empaquetamiento físico de los elementos de un modelo, como son

las clases en el modelo de diseño. Algunos estereotipos estándar de componentes son

los siguientes:

«executable» es un programa que puede ser ejecutado en un nodo.

«file» es un fichero que contiene código fuente o datos.

«library» es una librería estática o dinámica.

«table» es una tabla de base de datos.

«document» es un documento.

Durante la creación de componentes en un entorno de implementación particular estos

estereotipos pueden ser modificados para reflejar el significado real de estos

componentes. Los componentes tienen las siguientes características:

Los componentes tienen relaciones de traza con los elementos de modelo que

implementan.

Es normal que un componente implemente varios elementos, por ejemplo, varias

clases; sin embargo, la forma exacta en que se crea esta traza depende de cómo

van a ser estructurados y modularizados los ficheros de código fuente, dado el

lenguaje de programación que se esté usando.

Los componentes proporcionan las mismas interfaces que los elementos de

modelo que implementan.

Puede haber dependencias de compilación entre componentes, denotando qué

componentes son necesarios para compilar un componente determinado.

2.1.8.1.3 Subsistema de Implementación

Proporcionan una forma de organizar los artefactos del modelo de implementación en

trozos más manejables. Un subsistema puede estar formado por componentes, interfaces

y otros subsistemas (recursivamente). Además, un subsistema puede implementar —y

así proporcionar— las interfaces que representan la funcionalidad que exportan en forma

de operaciones.

Es importante entender que un subsistema de implementación se manifiesta a través de

un "mecanismo de empaquetamiento" concreto en un entorno de implementación

determinado, tales como:

Un paquete en Java.

Un proyecto en Visual Basic.

Un directorio de ficheros en un proyecto de C++.

42

Un subsistema en un entorno de desarrollo integrado como Rational Apex.

Un paquete en una herramienta de modelado visual como Rational Rose.

Los subsistemas de implementación están muy relacionados con los subsistemas de

diseño en el modelo de diseño. De hecho, los subsistemas de implementación deberían

seguir la traza uno a uno (isomórficamente) de sus subsistemas de diseño

correspondientes. Hay que recordar que un subsistema de diseño ya define:

Las dependencias sobre otros subsistemas o interfaces de otros subsistemas.

Las interfaces que han de ser proporcionadas por el subsistema.

Las clases de diseño o, de forma recursiva, subsistemas de diseño dentro del

subsistema que deberían proporcionar las interfaces proporcionadas por el

subsistema mismo.

Estos aspectos son importantes para el subsistema de implementación correspondiente

por las siguientes razones:

El subsistema de implementación debería definir dependencias análogas hacia

otros subsistemas de implementación o interfaces (correspondientes).

El subsistema de implementación debería proporcionar las mismas interfaces.

El sistema de implementación debería definir qué componentes o,

recursivamente, qué otros subsistemas de implementación dentro del subsistema

deberían proporcionar las interfaces proporcionadas por el subsistema. Además,

estos componentes (o subsistemas de implementación) contenidos deberían

seguir la traza de las clases (o subsistemas de diseño) correspondientes en el

subsistema de diseño que implementan.

Cualquier cambio en el modo en que los subsistemas proporcionan y usan interfaces, o

cualquier cambio en las interfaces mismas, está descrito en el flujo de trabajo del diseño.

Por tanto, estos cambios no son tratados en el flujo de trabajo de la implementación,

aunque también afectan al modelo de implementación.

Obsérvese que la correspondencia descrita también se da para los subsistemas de

servicio en el modelo de diseño. Por tanto, los subsistemas de implementación que

siguen la traza de los subsistemas de servicio residirán en un nivel inferior en la jerarquía

del modelo de implementación y cumplirán el mismo propósito que los subsistemas de

servicio, es decir, estructurar el sistema de acuerdo con los servicios que proporciona.

Por esta razón, los subsistemas de implementación que siguen el rastro de subsistemas

de servicio en el modelo de diseño encapsularán muy probablemente componentes

ejecutables que proporcionen los diversos servicios del sistema.

43

2.1.8.1.4 Interfaz

Las interfaces pueden ser utilizadas en el modelo de implementación para especificar las

operaciones implementadas por componentes y subsistemas de implementación.

Además los componentes y los subsistemas de implementación pueden tener

"dependencias de uso" sobre interfaces.

2.1.8.1.5 Descripción de arquitectura (vista del modelo de implementación)

La descripción de arquitectura contiene una visión de la arquitectura del modelo de

implementación, el cual representa sus artefactos significativos arquitectónicamente.

Los siguientes artefactos son usualmente considerados significativos arquitectónicamente

en el modelo de implementación:

La descomposición del modelo de implementación en subsistemas, sus interfaces

y las dependencias entre ellos.

Componentes clave, como los componentes que siguen la traza de las clases de

diseño significativas arquitectónicamente, los componentes ejecutables y los

componentes que son generales, centrales, que implementan mecanismos de

diseño genéricos de los que dependen muchos otros componentes.

2.1.8.1.6. Plan de integración de construcciones

Es importante construir el software incrementalmente en pasos manejables, de forma que

cada paso dé lugar a pequeños problemas de integración o prueba.

El resultado de cada paso es llamado "construcción", que es una versión ejecutable del

sistema, usualmente una parte específica del sistema. Cada construcción es entonces

sometida a pruebas de integración antes de que se cree ninguna otra construcción. Para

prepararse ante el fallo de una construcción se lleva un control de versiones de forma que

se pueda volver atrás a una construcción anterior. Los beneficios de este enfoque

incremental son los siguientes:

Se puede crear una versión ejecutable del sistema muy pronto, en lugar de tener

que esperar a una versión más completa. Las pruebas de integración comienzan

pronto, y las versiones ejecutables pueden ser utilizadas para hacer

demostraciones de las características del sistema tanto a los participantes

directos en el proyecto como a otras personas involucradas en él.

Es más fácil localizar defectos durante las pruebas de integración, porque sólo se

añade o refina en una construcción existente una parte pequeña y manejable del

sistema. Incluso mejor, los defectos están muy probablemente relacionados con la

parte nueva o refinada.

44

Las pruebas de integración tienden a ser más minuciosas que las pruebas del

sistema completo porque se centran en partes más pequeñas y más manejables.

La integración incremental es para, la integración del sistema lo que el desarrollo iterativo

controlado es para el desarrollo de software en general. Ambos se centran en un

incremento bastante pequeño y manejable de la funcionalidad.

Poniendo esto en un contexto de desarrollo iterativo, cada iteración resultará en al menos

una construcción. Sin embargo, la funcionalidad a ser implementada en una iteración

determinada es a menudo demasiado compleja para ser integrada en una sola

construcción. En lugar de esto, puede que se cree una secuencia de construcciones

dentro de una iteración, cada una de las cuales representará un paso manejable en el

que se hace un pequeño incremento al sistema, Cada iteración resultará entonces en un

incremento mayor del sistema, posiblemente acumulado a lo largo de varias

construcciones.

Un plan de integración de construcciones describe la secuencia de construcciones

necesarias en una iteración. Más concretamente, un plan de este tipo describe lo

siguiente para cada, construcción:

La funcionalidad que se espera que sea implementada en dicha construcción.

Consiste en una lista de casos de uso o escenarios o parte de ellos. Esta lista

puede también referirse a otros requisitos adicionales.

Las partes del modelo de implementación que están afectadas por la

construcción. Esto es una lista de los subsistemas y componentes necesarios

para implementar la funcionalidad supuesta por la construcción.



Durante la fase de implementación, el arquitecto es responsable de la integridad del

modelo de implementación y asegura que el modelo como un todo es correcto, completo

y legible

El modelo es correcto cuando implementa la funcionalidad descrita en el modelo de

diseño y en los requisitos adicionales (relevantes), y sólo esta funcionalidad.

El arquitecto es responsable también de la arquitectura del modelo de implementación, es

decir, de la existencia de sus partes significativas arquitectónicamente como se

representó en la vista de la arquitectura del modelo de despliegue. Recordemos que esta

vista es parte de la descripción de la arquitectura del sistema.

45

Por último, un resultado importante de la implementación es la asignación de

componentes ejecutables a nodos. El arquitecto es responsable de esta asignación, la

cual se representa en la vista de la arquitectura del modelo de despliegue.

Obsérvese que el arquitecto no es responsable del desarrollo en marcha ni del

mantenimiento de los diversos artefactos en el modelo de implementación; por el

contrario, esto es responsabilidad del ingeniero de componentes correspondiente.

2.1.8.2.2 Ingeniero de componentes

El ingeniero de componentes define y mantiene el código fuente de uno o varios

componentes, garantizando que cada componente implementa la funcionalidad correcta.

A menudo, el ingeniero de componentes también mantiene la integridad de uno o varios

subsistemas de implementación. Ya que los subsistemas de implementación siguen la

traza uno a uno a los subsistemas de diseño, la mayoría de los cambios en estos

subsistemas tienen lugar durante el diseño. Sin embargo, el ingeniero de componentes

necesita garantizar que los contenidos (por ejemplo, los componentes) de los

subsistemas de implementación son correctos, que sus dependencias con otros

subsistemas o interfaces son correctas y que implementan correctamente las interfaces

que proporcionan.

Es apropiado también que el ingeniero de componentes que es responsable de un

subsistema sea responsable de los elementos de modelo contenidos en él. Además, para

alcanzar un desarrollo tranquilo y sin problemas, es natural que un ingeniero de

componentes tenga la responsabilidad de un subsistema y de sus contenidos a lo largo

de las etapas de diseño e implementación. Un ingeniero de componentes debería, tanto,

diseñar e implementar las clases bajo su responsabilidad.

2.1.8.2.3 Integrador de sistemas

La integración del sistema está más allá del ámbito de cada ingeniero de componentes

individual. Por el contrario, esta responsabilidad recae sobre el integrador de sistemas.

Entre sus responsabilidades se incluye el planificar la secuencia de construcciones

necesarias en cada iteración y la integración de cada construcción cuando sus partes han

sido implementadas. La planificación da lugar a un plan de integración de construcciones.

2.1.8.3 Flujo de trabajo

Arquitecto

Implementación de la

arquitectura

46

Integrador de sistemas

Integrar sistemas


Implementar una clase

Implementar un subsistema

Realizar prueba de

unidadFigura 2.10: Flujo de Trabajo de Implementación [RUP-2000]

2.1.8.3.1 Actividad: Implementación de la Arquitectura

Esta actividad tiene por propósito:

Identificar componentes arquitectónicamente significativos

Asignar componentes a los nodos

Resulta trivial el identificar los subsistemas de implementación ya que provienen de una

trazabilidad uno a uno con respecto a los subsistemas de diseño. Tiene más importancia

el hecho de identificar los componentes que implementarán los subsistemas de diseño

correspondientes.

Aquí, el arquitecto mantiene la descripción de la arquitectura de los modelos de

implementación y despliegue.

2.1.8.3.1.1 Identificar componentes arquitectónicamente significativos

Es importante identificar de manera prematura los componentes que son significativos

para la arquitectura. Sin embargo solo se debe tener un esbozo de los mismos, ya que

ahondar en detalles sería inútil debido a que el trabajo habrá de volverse a hacer cuando

se implementen las clases.

2.1.8.3.1.1.1 Identificación de componentes ejecutables y asignación de estos a

nodos

La identificación de componentes ejecutables se resume a una trazabilidad uno a uno

con las clases activas en el diseño. Esto podría incluir la identificación de otros

componentes pero esto es secundario.

La asignación de estos componentes a nodos es muy importante para la arquitectura y

debería estar representada en una vista de la arquitectura del modelo de despliegue.

2.1.8.3.2 Integrar el sistema


47

Crear un plan de integración de construcciones que describa las construcciones

necesarias en una iteración y los requisitos de cada construcción.

Integrar cada construcción antes de que sea sometida a pruebas de integración.

2.1.8.3.2.1 Planificación de una construcción

Los contenidos de una construcción se planifican independientemente de que si se

cuenta o no con construcciones previas. Se parte de tener un cierto número de casos de

uso o escenarios (caminos a través de casos de uso) y otros requisitos que han de ser

implementados en la iteración actual.

Algunos de los criterios para crear una construcción son:

Una construcción debería añadir funcionalidad a la construcción previa

implementando casos de uso completos o escenarios de estos.

Una construcción no debería incluir demasiados componentes nuevos o refinados.

Una construcción debería estar basada en la construcción anterior, y debería

expandirse hacia arriba o a los lados en la jerarquía de subsistemas.

Cuando se tiene estos criterios en mente, se puede empezar a evaluar los requisitos,

tales como los casos de uso que han de ser implementados. Para cada caso de uso a

implementarse, se debe realizar lo siguiente:

1. Considerar el diseño del caso de uso.

2. Identificar los subsistemas y clases de diseño que participan en la realización de

caso de uso – diseño.

3. Identificar los subsistemas y componentes de implementación en el modelo de

implementación que siguen la traza de los subsistemas y clases de diseño

encontrados en el paso 2.

4. Considerar el impacto de implementar los requisitos de estos subsistemas de

implementación y de los componentes sobre la construcción en cuestión.

Los resultados se deben recoger en el plan de integración de la construcción y ser

comunicados a los ingenieros de componentes responsables de los subsistemas y

componentes de implementación afectados.

2.1.8.3.2.2 Integración de una construcción

La integración se la realiza recopilando las versiones correctas de los subsistemas de

implementación y de los componentes, compilándolos y enlazándolos para generar una

construcción.

La construcción resultante, se debe someter a pruebas de integración y a pruebas de

sistema si pasa las anteriores, y es la última construcción dentro de una iteración.

48

2.1.8.3.3 Actividad: Implementar un subsistema

Esta actividad tiene por propósito asegurar que un subsistema cumple su papel en cada

construcción, tal y como se especifica en el plan de integración de la construcción.

2.1.8.3.3.1 Mantenimiento de los contenidos de los subsistemas

Un subsistema cumple su propósito cuando los requisitos a ser implementados en la

construcción actual y aquellos que afectan al subsistema están implementados

correctamente por componentes dentro del subsistema.

Es necesario que el ingeniero de componentes conforme evoluciona el modelo de

implementación, refine el contenido de un subsistema, esto puede incluir:

Cada clase en el correspondiente subsistema de diseño que es necesaria en la

construcción actual debería ser implementada mediante componentes en el

subsistema de implementación.

Cada interfaz proporcionada por el subsistema de diseño correspondiente

requerido en la construcción debería también ser proporcionada por el subsistema

de implementación.

Una vez que se han realizado las actividades anteriores, los ingenieros de componentes

pueden empezar a implementar lo que es requerido por los componentes dentro del

subsistema.

2.1.8.3.4 Actividad: Implementar una Clase

Aquí se implementa una clase de diseño en un componente fichero, esto incluye lo

siguiente:

Esbozo de un componente fichero que contendrá el código fuente.

Generación de código fuente a partir de la clase de diseño y de las relaciones en

que participa.

Implementación de las operaciones de la clase de diseño en forma de métodos.

Comprobación de que el componente proporciona las mismas interfaces que la

clase de diseño.

2.1.8.3.4.1 Esbozo de los componentes fichero

Los componentes fichero contienen el código fuente que implementa una clase de

diseño, de allí que se debe esbozar el componente fichero y su ámbito. Es normal

implementar varias clases de diseño en un mismo componente fichero. Hay que recordar

que el tipo de modularización y las convenciones de los lenguajes de programación en

uso restringirán la forma en que los componentes fichero son esbozados.

49

2.1.8.3.4.2 Generación de código a partir de una clase de diseño

Aunque en el diseño muchos de los detalles relacionados con la clase de diseño y con

sus relaciones son descritos utilizando la sintaxis del lenguaje de programación elegido;

solo se genera la signatura de las operaciones que en sí han de ser implementadas.

Hay que anotar que puede resultar muy delicado generar código a partir de asociaciones

y agregaciones, y la forma en que esto se haga depende en gran medida del lenguaje de

programación utilizado.

2.1.8.3.4.3 Implementación de operaciones

Todas las operaciones de una clase de diseño deben ser implementadas a no ser que

estas sean virtuales y deban ser implementadas por descendientes.

La implementación de una operación incluye la elección de un algoritmo y unas

estructuras de datos apropiadas, y la codificación de las acciones requeridas por el

algoritmo.

2.1.8.3.4.4 Los componentes han de proporcionar las interfaces apropiadas

El componente resultante debería proporcionar las mismas interfaces que las clases de

diseño que este implementa.

2.1.8.3.5 Actividad: Realizar prueba de unidad

En esta actividad se prueba los componentes implementados como unidades

individuales. Existen varios tipos de pruebas de unidad:

La prueba de especificación o prueba de caja negra, que verifica el

comportamiento de la unidad observable externamente.

La prueba de estructura, o prueba de caja blanca que verifica la implementación

interna de la unidad.

También se pueden realizar otras pruebas, como las pruebas de rendimiento, utilización

de memoria, carga y capacidad.

2.1.8.3.5.1 Realización de pruebas de especificación

Esta prueba se realiza para verificar el comportamiento del componente sin tener en

cuenta cómo se implementa dicho comportamiento en el componente. Se tiene el cuenta

la salida que el componente devolverá cuando se le da una determinada entrada en un

determinado estado. El número de combinaciones de posibles entradas, estados iniciales

y salidas, es considerable, en su lugar, se divide en clases de equivalencia.

50

Una clase de equivalencia es un conjunto de valores de entrada, estado o salida para los

que se supone que un objeto se comporta de forma similar. Si prueba a un componente

para una combinación de clases de equivalencia se obtendrá un resultado similar a si se

hubiese probado todas las opciones posibles.

2.1.8.3.5.2 Realización de Pruebas de Estructura

Verifican el funcionamiento interno de un componente. El ingeniero de componentes

debería asegurarse de probar todo el código durante las pruebas de estructura, lo que

significa que cada sentencia ha de ser ejecutada al menos una vez.

2.1.9 Prueba

Los objetivos de la prueba son:

Verificar la interacción entre objetos

Verificar la correcta integración de todos los componentes del software

Verificar que todos los requerimientos han sido implementados correctamente.

Identificar y asegurar que los defectos han sido manejados anticipadamente en la

implementación del software.

2.1.9.1 Artefactos

2.1.9.1.1 Artefacto: Modelo de Pruebas

Este modelo describe principalmente como se prueban los componentes ejecutables en

el modelo de implementación con pruebas de integración y de sistema. También puede

describir como han de ser probados aspectos específicos del sistema.

2.1.9.1.2 Artefacto: Caso de Prueba

Éste especifica una forma de probar el sistema, incluyendo la entrada o resultado con la

que se ha de probar y las condiciones bajo las que ha de probarse.

Los más comunes casos de prueba son:

Un caso de prueba que especifica como probar un caso de uso o un escenario

especifico de un caso de uso.

Un caso de prueba que especifica como probar una realización de caso de uso –

diseño o un escenario especifico de la realización.

Existen casos de prueba que se utilizan para probar el sistema como un todo, así como:

Pruebas de Instalación.- Verifican que el sistema puede ser instalado en la

plataforma del cliente y que el sistema funcionará correctamente cuando sea

instalado.

51

Pruebas de Configuración.- Verifican que el sistema funcione correctamente en

diferentes configuraciones; de hardware, de red, etc.

Pruebas de Tensión.- Identifican problemas con el sistema cuando hay recursos

insuficientes o cuando se compite por recursos.

2.1.9.1.3 Artefacto: Procedimiento de Prueba

Especifica como realizar uno o varios casos de prueba o partes de estos. Generalmente

el como llevar a cabo un caso de prueba puede ser especificado por un procedimiento de

prueba, pero es frecuente reutilizar un procedimiento de prueba para varios casos de

prueba y reutilizar varios procedimientos de prueba para un caso de prueba.

2.1.9.1.4 Artefacto: Componente de Prueba

Permite automatizar uno o varios procedimientos de prueba o parte de ellos. Estos

pueden ser desarrollados utilizando un lenguaje script o de programación, o con

herramientas de automatización de pruebas.

Las acciones que realizan estos componentes principalmente son proporcionar entradas

de prueba, controlar y monitorizar los componentes a probar y posiblemente informando

de los resultados de las pruebas.

2.1.9.1.5 Artefacto: Plan de Prueba

Describe las estrategias, recursos y planificación de la prueba. Las estrategias de prueba

incluye la definición del tipo de pruebas a realizar para cada iteración y sus objetivos, el

nivel de cobertura de prueba y de código necesario y el porcentaje de pruebas que

deberían ejecutarse con un resultado específico.

2.1.9.1.6 Artefacto: Defecto

Un defecto es una anomalía del sistema que se detectó en una revisión. Este se puede

utilizar para localizar cualquier cosa que los desarrolladores necesitan registrar como

síntoma de un problema en el sistema que ellos necesitan controlar o resolver.

2.1.9.1.7 Artefacto: Evaluación de Prueba

Es una evaluación de los resultados de los esfuerzos de prueba, tales como la cobertura

del caso de prueba, la cobertura de código y el estado de los defectos.


2.1.9.2.1 Trabajador: Diseñador de Pruebas

Es responsable de la integridad del modelo de pruebas, asegurando que el modelo

cumple con su propósito. También planea las pruebas, o sea, decide los objetivos de la

52

prueba apropiados y la planificación de las pruebas. Además selecciona y describe los

casos de prueba y los correspondientes procedimientos de prueba. Y es responsable de

la evaluación de las pruebas de integración y de sistema cuando estas se ejecutan.

2.1.9.2.2 Trabajador: Ingeniero de Componentes

Es responsable de los componentes de prueba que automatizan algunos de los

procedimientos de prueba.

2.1.9.2.3 Trabajador: Ingeniero de Pruebas de Integración

Su responsabilidad es realizar las pruebas de integración que se necesitan para cada

construcción producida en el flujo de trabajo de la implementación. También se encarga

de documentar los defectos en los resultados de las pruebas de integración.

2.1.9.2.4 Trabajador: Ingeniero de Pruebas de Sistema

Es responsable de realizar las pruebas de sistema necesarias sobre una construcción

que muestra el resultado de una iteración completa. También documenta los defectos en

los resultados de las pruebas de sistema.


Ingeniero de pruebas

Planificar Prueba

Diseñar prueba

Evaluar prueba

Ingeniero de pruebas de integración

Realizar prueba de integración

Ingeniero de pruebas de

sistema

Realizar prueba de sistema


Implementar pruebas

Figura 2.11: Flujo de Trabajo de Prueba [RUP-2000]

2.1.9.3.1 Actividad: Planificar Prueba

Esta actividad tiene como propósito planificar los esfuerzos de prueba en una iteración, y

realiza las siguientes tareas:

53

Describir una estrategia de prueba

Estimar los requisitos para el esfuerzo de la prueba.

Planificar el esfuerzo de la prueba.

Los diseñadores de pruebas que desarrollan la estrategia de prueba deciden que tipo de

pruebas ejecutar, como ejecutar dichas pruebas, cuando ejecutarlas y como determinar si

el esfuerzo de prueba tiene éxito.

Hay que recalcar que ningún sistema puede ser probado completamente, por lo tanto se

debería identificar los casos, procedimientos y componentes de prueba con un mayor

retorno a la inversión en términos de mejora de calidad. El principio general consiste en

desarrollar casos y procedimientos de prueba con un solapamiento mínimo para probar

los casos de uso más importantes y probar los requisitos que están asociados a los

riesgos más altos.

2.1.9.3.2 Actividad: Diseñar Prueba

Los propósitos de esta actividad son:

Identificar y describir los casos de prueba para cada construcción.

Identificar y estructurar los procedimientos de prueba especificando como realizar

los casos de prueba.

2.1.9.3.2.1 Diseño de los casos de prueba de Integración

Estos casos de prueba se utilizan para verificar que los componentes interaccionan entre

sí de forma apropiada después de haber sido integrados en una construcción.

Los casos de prueba de integración se derivan de las realizaciones de casos de uso-

diseño (diagrama de secuencia), ya que estas describen como interactúan las clases y

los objetos.

Los diseñadores de pruebas buscan combinaciones de entrada, salida y estado inicial del

sistema que den lugar a escenarios interesantes que empleen clases que participan en

los diagramas.

2.1.9.3.2.2 Diseño de los casos de prueba de sistema

Estas pruebas se utilizan para probar que el sistema funciona correctamente como un

todo. En cada prueba de sistema se prueba principalmente combinaciones de casos de

uso instanciado bajo condiciones diferentes. Estas condiciones pueden ser diferentes

configuraciones de hardware, diferentes niveles de carga, diferentes números de actores

y diferentes tamaños de la base de datos. Al desarrollar los casos de prueba, los

diseñadores de pruebas deberían dar prioridad a las combinaciones de los casos de uso

que:

54

Se necesita que funcionen en paralelo.

Posiblemente funcionan en paralelo.

Posiblemente se influencian mutuamente si se ejecutan en paralelo.

Involucran varios procesadores.

Usan frecuentemente recursos del sistema, como procesos, procesadores, bases

de datos y software de comunicaciones, quizás de formas complejas e

impredecibles.

2.1.9.3.3 Actividad: Implementar Prueba

Esta activad tiene como propósito automatizar los procedimientos de prueba creando

componentes de prueba si esto es posible, pues no todos los procedimientos de prueba

pueden ser automatizados.

Los componentes de prueba usan a menudo grandes cantidades de datos de entrada

para ser probados y producen grandes cantidades de datos de salida como resultado de

las pruebas. Es de utilidad poder visualizar estos datos de forma clara e intuitiva de

manera que puedan especificarse correctamente y los resultados de las pruebas puedan

ser interpretados. Para esto se utiliza hojas de cálculo y bases de datos.

2.1.9.3.4 Actividad: Realizar Pruebas de Integración

El propósito de esta actividad es realizar las pruebas de integración necesarias para

cada una de las construcciones creadas en una iteración y recopilar los resultados de las

pruebas.

Las acciones a realizar en esta activad son:

Realizar las pruebas de integración relevantes a la construcción realizando los

procedimientos de prueba manualmente para cada caso de prueba o ejecutando

cualquier componente de prueba que automatice los procedimientos de prueba.

Comparar los resultados de las pruebas con los resultados esperados e investigar

los resultados de las pruebas que no coinciden con los esperados.

Informar de los defectos a los ingenieros de componentes responsables de los

componentes que se cree que contienen fallos.

Informar de los defectos a los diseñadores de pruebas, quienes usarán los

defectos para evaluar los resultados del esfuerzo de prueba.

2.1.9.3.5 Actividad: Realizar Prueba de Sistema

Aquí se realizan las pruebas de sistema necesarias en cada iteración y recopilar los

resultados de las pruebas.

55

La prueba de sistema puede empezar cuando las pruebas de integración indican que el

sistema satisface los objetivos de calidad de integración fijados en el plan de prueba de la

iteración actual.

La prueba de sistema se realiza de forma análoga a la que se realiza la prueba de

integración.

2.1.9.3.6 Actividad: Evaluar Prueba

Los diseñadores de pruebas evalúan los resultados de la prueba comparando los

resultados obtenidos con los objetivos esbozados en el plan de prueba. Estos preparan

métricas que les permiten determinar el nivel de calidad del software y qué cantidad de

pruebas es necesario hacer.

Las métricas que el ingeniero de pruebas observa son:

Compleción de la prueba, obtenida a partir de la cobertura de los casos de prueba

y de la cobertura de los componentes probados. Esta métrica indica el porcentaje

de casos de prueba que han sido ejecutados y el porcentaje de código que ha

sido probado.

Fiabilidad, la cual se basa en el análisis de las tendencias en los defectos

detectados y en las tendencias en las pruebas que se ejecutan con el resultado

esperado.

Basándose en el análisis de la tendencia de los defectos los diseñadores de pruebas

pueden sugerir otras acciones como:

Realizar pruebas adicionales para localizar más defectos, si la fiabilidad medida

sugiere que el sistema no está suficientemente maduro.

Relajar el criterio para las pruebas, si los objetivos de calidad de la iteración actual

se pusieron demasiado altos.

Aislar las partes del sistema que parecen tener una calidad aceptable y

entregarlas como resultado de la iteración actual.

Los diseñadores de pruebas documentan la compleción de la prueba, su fiabilidad y

sugieren acciones en una descripción de la evaluación de la prueba.

2.1.10 Flujo de Trabajo Genérico

En esta sección se detallará el patrón común que caracteriza a todas las iteraciones a

partir de las distintas iteraciones que ocurren durante las cuatro fases.

Este patrón genérico se utiliza como base sobre la que construir las iteraciones

concretas; el contenido de una iteración cambia para acomodarse a los objetivos

particulares de cada fase.

56

El flujo de trabajo de la iteración genérica incluye los cinco flujos de trabajo: requisitos,

análisis, diseño, implementación y prueba. Este también incluye la planificación, que

precede a los flujos de trabajo, y la evaluación, que va detrás de ellos. Se dará especial

énfasis a la planificación, evaluación y otras actividades comunes a todos los flujos de

trabajo.

La planificación es necesaria a lo largo de todo el ciclo de desarrollo, pero antes de que

se pueda planear es necesario saber qué es lo que se tiene que hacer; los cinco flujos de

trabajo fundamentales proporcionan un punto de partida. Otro aspecto clave de la

planificación es la administración de riesgos, es decir, la identificación y mitigación de

riesgos realizando el correspondiente conjunto de casos de uso. Por supuesto, un plan no

estará completo sin la estimación de recursos que este requerirá y, por último, también

debe llevarse a cabo la evaluación de la ejecución de cada iteración y fase.

2.1.10.1 La necesidad de equilibrio

En cada uno de los momentos en el ciclo de vida de un proyecto de desarrollo software

están activas muchas secuencias de actividades diferentes: se trabaja en nuevas

funciones, se diseña la arquitectura, se recibe comentarios de los usuarios, se mitiga

riesgos, se planifica el futuro, etc. Se debe equilibrar y sincronizar en todo momento estas

secuencias de actividades diferentes para controlar así esta complejidad.

Los desarrolladores dividen el trabajo, que es abrumadoramente complejo como un todo,

en partes más pequeñas y comprensibles, A lo largo del ciclo de vida de desarrollo

dividen el trabajo en fases, y cada una de estas fases en iteraciones.

Dentro de cada iteración el proyecto se esfuerza en alcanzar un equilibrio entre las

secuencias de actividad que se ejecutan a lo largo de la iteración, lo que significa que se

debería trabajar en las cosas apropiadas en cada iteración. Las cosas correctas en las

que trabajar en cada momento dependen del punto del ciclo de vida en que se encuentre;

la tarea de un proyecto es seleccionar las cosas correctas en las que trabajar en cada

secuencia de actividad. Determinar el equilibrio de las secuencias de actividades es

también importante para asegurar que son de una importancia parecida, de forma que

pueda asignárseles una prioridad y sincronizarlas con facilidad. Fallar en la consecución

de este tipo de equilibrio y ejecución eficiente se traduce en general en el desastre de

muchos ciclos de vida de desarrollo incrementales e iterativos.

En las primeras iteraciones se trabaja con riesgos críticos, casos de uso fundamentales,

cuestiones arquitectónicas, la elección del entorno de desarrollo, todas las cuestiones

orientadas a la investigación, mientras que en las últimas iteraciones se trabaja en

actividades orientadas al desarrollo, como la implementación y la prueba, problemas de

57

evaluación del rendimiento y el despliegue del sistema. El relacionar todas estas

actividades entre sí es una cuestión de equilibrio bastante delicada, lo que hace que el

desarrollo de software sea una tarea extraordinariamente difícil.

Lo que se hace en una iteración es entender estas secuencias de actividades diferentes y

buscar el equilibrio entre ellas.

2.1.10.2 La iteración genérica

En el Proceso Unificado los flujos de trabajo no ocurren sólo una vez, como sucede

teóricamente en el modelo en cascada, sino que se repiten más bien en cada iteración,

una y otra vez, como flujos de trabajo iterativos, En cada repetición, sin embargo, se

diferencian en los detalles, se enfrentan a los asuntos centrales de cada iteración.

2.1.10.2.1 Los flujos de trabajo fundamentales se repiten en cada iteración

La iteración genérica consiste en los cincos flujos de trabajo: requisitos, análisis, diseño,

implementación y prueba, e incluye también planificación y evaluación.

2.1.10.3 El planificar precede al hacer

Cuando se comienza la fase de inicio se conocen tres cosas:

Se va a llevar a cabo el proyecto en una serie de iteraciones en cuatro fases.

Se tiene la información sobre el sistema propuesto que los predecesores

recopilaron (y que llevaron a comenzar un proyecto).

Se tiene información básica propia sobre el dominio y sobre sistemas similares en

los que se ha trabajado en el pasado.

Partiendo de esta información se ha de planear el proyecto (plan de proyecto) y cada

iteración (plan de iteración). Al principio, con información limitada con la que trabajar,

ambos planes contienen poco detalle, pero conforme se trabaje en las fases de inicio y de

elaboración los planes llegan a estar más detallados.

2.1.10.3.1 Planear las cuatro fases

Gracias a las indicaciones del Proceso Unificado se conoce qué hay que hacer en cada

una de las fases. La tarea, en el plan del proyecto, es reducir estas indicaciones a

términos concretos:

Asignaciones de tiempo. Se decide cuánto tiempo asignar a cada fase y la fecha

en la que cada fase ha de haber sido completada. Estos tiempos, aunque

establecidos con precisión, pueden ser bastante inestables al principio de la fase

de inicio, pero se irán fijando conforme se vaya aprendiendo más. Después de

58

todo no es hasta el final de la fase de elaboración cuando se hace una propuesta

firme.

Hitos principales. Una fase termina cuando ha sido alcanzado el criterio actual. Al

principio estos criterios pueden ser poco más que creencias basadas en alguna

información, información que puede venir de la experiencia basada en el dominio,

de las similitudes del sistema propuesto con sistemas anteriores, de las

especificaciones del rendimiento que se pretende que el nuevo sistema alcance y

de la capacidad de la organización de desarrollo de software.

Iteraciones por fase. Dentro de cada fase el trabajo se lleva a cabo a lo largo de

varias iteraciones. El carácter de cada iteración está contenido en el plan de

proyecto.

Plan de proyecto. El plan de proyecto esboza un "mapa de carreteras" global, que

cubre la planificación, las fechas y criterios de los objetivos principales y la división

de las fases en iteraciones.

Se puede esperar que la primera iteración en la fase de inicio sea difícil, ya que además

de la iteración misma se ha de cubrir lo siguiente:

Ajustar el Proceso Unificado al proyecto y seleccionar herramientas para

automatizar el proceso.

Empezar a reunir a gente con el talento necesario para el proyecto.

Crear las relaciones que dan lugar a un equipo efectivo.

Entender el dominio, que a menudo es desconocido para el equipo.

Percibir la naturaleza del proyecto.

Familiarizar al equipo con las herramientas apropiadas para el proceso y el

proyecto.

2.1.10.3.2 Plan de iteraciones

Cada fase está formada por una o más iteraciones. La planificación de las iteraciones

pasa por un conjunto de pasos comparables con los seguidos en la planificación de las

fases:

Planificación de iteración. Se decide cuánto tiempo puede requerir cada iteración

y su fecha de terminación; al principio a grosso modo y después con más

precisión conforme se aprende.

Contenido de iteración. Mientras que el plan del proyecto esboza las iteraciones

planeadas en términos generales, cuando la fecha de comienzo de una iteración

se acerca, se planea lo que ha de hacerse más en detalle. El contenido de una

iteración se basa en lo siguiente:

59

o Los casos de uso que tienen que ser completados al menos parcialmente

durante la iteración.

o Los riesgos técnicos que han de ser identificados, transformados en casos

de uso y mitigados en ese momento.

o Los cambios que han sufrido los requisitos o los defectos que pueden

haber sido corregidos.

o Los subsistemas que han de ser implementados parcial o completamente.

Este punto varia dependiendo de la fase en que se considere.

El plan de la iteración actual está completamente detallado, y el de la siguiente va siendo

más detallado conforme se va aprendiendo. Los detalles de iteraciones posteriores

pueden estar limitados por el conocimiento disponible en ese momento:

Hitos secundarios. El alcanzar los criterios preestablecidos (preferiblemente en

la fecha planeada) marca la compleción de la iteración actual.

Plan de iteración. Las actividades de cada iteración son recopiladas en un

detallado plan de iteración. Al comienzo de cada iteración identificamos los

individuos disponibles para actuar como trabajadores.

El número de iteraciones planeado para cada fase depende, básicamente, de la

complejidad del sistema propuesto. Un proyecto muy simple podría ser realizado con una

sola iteración por fase, mientras que un proyecto más complicado podría requerir más

iteraciones. Por ejemplo;

Fase de inicio: una iteración, principalmente dedicada a definir el ámbito del

sistema.

Fase de elaboración: dos iteraciones, la primera para esbozar la arquitectura y la

segunda para completar la línea base de la arquitectura.

Fase de construcción: dos iteraciones, para asegurar que los incrementos

resultantes funcionan satisfactoriamente.

Fase de transición: una iteración.

Conforme el proyecto bajo consideración va siendo mayor y más complejo y requiere más

consideraciones nuevas se puede esperar que el tamaño de la organización del

desarrollo vaya creciendo. Habrá más iteraciones y sus duraciones variarán,

dependiendo del tamaño del sistema, entre una semana y tres meses por cada iteración.

2.1.10.3.3 Pensar a largo plazo

Durante el largo período de tiempo que el sistema puede durar, este puede presenciar

grandes cambios, como nuevas tecnologías, nuevas interfaces con el entorno del sistema

o plataformas avanzadas. Además, los planificadores deberían examinar si el negocio

60

necesitaría ser adaptado a otras organizaciones, como filiales o socios resultantes de

fusiones. Sin embargo, no se debe llegar al absurdo especulando con el futuro. No se

quiere construir una arquitectura rígida para el sistema si es posible prever que esta

cambiará en el futuro, pero tampoco queremos introducir una flexibilidad innecesaria en el

sistema, es decir, una flexibilidad que no será utilizada nunca.

2.1.10.3.4 Planear los criterios de evaluación

Las iteraciones son cortas comparadas con los proyectos tradicionales. Para que no

queden indefinidas los líderes del proyecto, además de establecer una planificación, han

de esbozar los objetivos clave de cada iteración. Para completar los objetivos, éstos

establecen criterios que indican la compleción de la iteración. Estos criterios, como el

conjunto de características mínimo en un momento determinado, permiten centrarse en

una iteración y ayudan a fijarse en lo temporalmente cercano.

Uno de los objetivos en una de las primeras iteraciones podría ser resolver las

ambigüedades en la expresión actual de los requisitos del cliente. Los criterios

especifican lo que los planificadores intentan que se llegue a conseguir en una iteración

en términos que puedan ser medidos, como rendimiento, u observados, como una

característica deseable.

El jefe del proyecto establece criterios de evaluación para cada iteración y para la fase

misma por adelantado. Cada una necesita un punto de terminación claro que permita a

los desarrolladores darse cuenta de que han terminado. Además, estos puntos de

terminación proporcionan los productos intermedios que los administradores pueden

utilizar para determinar el progreso del trabajo.

A grandes rasgos, los criterios de evaluación pueden clasificarse en dos categorías:

requisitos verificables y criterios más generales.

Los ingenieros de pruebas han estado participando en el desarrollo desde la fase de

inicio y son ellos los que identifican qué características de los casos de uso pueden ser

confirmadas haciendo pruebas. Ellos planean los casos de prueba que definen las

pruebas de integración y de regresión, así como las pruebas de sistema. En el desarrollo

iterativo el ciclo de pruebas también es iterativo. Cada una de las construcciones creadas

en una iteración es sometida a prueba. Los ingenieros de pruebas aumentan y refinan las

pruebas que se ejecutan sobre cada construcción, acumulándose así una cantidad de

pruebas que serán utilizadas como pruebas de regresión en etapas posteriores. Las

primeras iteraciones introducen más funciones nuevas y más pruebas que las últimas

iteraciones. Conforme avanza la integración de construcciones disminuye el número de

nuevas pruebas y se ejecuta un número creciente de pruebas de regresión para validar la

implementación del sistema realizada hasta ese momento. Por tanto, las primeras

61

construcciones e iteraciones requieren más planificación y diseño de pruebas, mientras

que en las últimas se realiza más ejecución y evaluación de pruebas.

Los criterios generales no se pueden reducir a caminos dentro del código que los

ingenieros de pruebas pueden probar; puede que éstos hayan de ser percibidos en

prototipos primero y en las series de construcciones en funcionamiento y de iteraciones

más tarde. Los usuarios, clientes y desarrolladores pueden ver pantallas e interfaces

gráficas de usuario con mayor perspicacia de la que pueden emplear en estudiar la

información estática contenida en los artefactos de los modelos.

Los criterios de evaluación dicen cómo verificar que los requisitos para una iteración han

sido desarrollados correctamente. Especifican en términos que pueden ser observados o

verificados hasta dónde intenta el jefe del proyecto que llegue la iteración. Al principio

estos criterios son un tanto vagos, pero van siendo más detallados conforme los casos de

uso, escenarios de los casos de uso, requisitos de rendimiento y casos de prueba

concretan cómo han de ser los incrementos sucesivos.

2.1.10.4 Los riesgos influyen en la planificación del proyecto

El modo en que se planifica el desarrollo de un nuevo sistema está influenciado en gran

medida por los riesgos que se perciben. Por tanto, uno de los primeros pasos, al principio

de la fase de inicio, es crear una lista de riesgos. Al principio, esto puede ser difícil por la

falta de información, pero probablemente se tiene alguna intuición de cuáles pueden ser

los riesgos. Conforme se va realizando el trabajo inicial se va apreciando cuáles serán los

riesgos críticos.

2.1.10.4.1 Administrar la lista de riesgos

Una cosa es saber de una forma vaga que el desarrollo de software implica riesgos y otra

distinta ponerlos donde todo el mundo pueda verlos, ser guiados por ellos y hacer algo

con ellos. Ese es el propósito de la lista de riesgos. No se trata de algo que se guarde en

un cajón o en una carpeta en el computador, todo lo que es preciso saber sobre un riesgo

para poder trabajar con él, incluyendo su identificador único, debería estar en la lista.

Esta lista incluye:

Descripción: comienza con una breve descripción y se van añadiendo detalles

conforme se va aprendiendo.

Prioridad: se le asigna una prioridad al riesgo; al principio el riesgo se clasificará

como crítico, significativo o rutinario, aunque conforme la lista se va desarrollando

es posible que se quieran añadir más categorías.

Impacto: indica qué partes del proyecto o del sistema se verán afectadas por el

riesgo.

62

Monitor: indica quién es responsable del seguimiento de un riesgo persistente.

Responsabilidad: indica qué individuo o unidad de la organización es responsable

de eliminar el riesgo.

Contingencia: indica lo que ha de hacerse en caso de que el riesgo se materialice.

En un proyecto de un cierto tamaño pueden encontrarse cientos de riesgos;

probablemente, en proyectos grandes los riesgos deberían ser almacenados en una base

de datos de forma que puedan ser ordenados y se puedan hacer búsquedas sobre ellos

de forma eficiente. Una de las razones por las que se sigue un desarrollo iterativo es que

el equipo no puede centrarse en todo al mismo tiempo; los riesgos se ordenan por nivel

de seriedad o por su influencia en el desarrollo y son resueltos en orden. Algunos riesgos

no tienen una solución fácil y permanecen en la lista de riesgos por algún tiempo.

Algunas organizaciones han encontrado útil destacar los "diez principales" de la lista

como una forma de centrar la atención.

La lista de riesgos no es un instrumento estático, la lista crece conforme se descubren

nuevos riesgos. Conforme son eliminados los riesgos o cuando pasamos un punto del

desarrollo en que un riesgo particular no puede materializarse son quitados de la lista. El

jefe del proyecto preside reuniones periódicas, a menudo coincidiendo con la terminación

de las iteraciones, para revisar el estado de los riesgos más importantes. Otros líderes

presiden sesiones para discutir riesgos menos importantes.

2.1.10.4.2 Los riesgos influyen en el plan de iteración

Durante la fase de inicio se identifican los riesgos críticos y el equipo intenta mitigarlos.

Exploran su naturaleza hasta el punto de preparar un plan de iteración. Para saber lo

suficiente para hacer un plan. A continuación, con ciertas entradas, se dan cuenta de que

el prototipo genera una salida inaceptable, es decir, un riesgo crítico. Estas entradas han

de estar dentro del rango de entradas especificado, quizás en sus límites, y aún así

causar salidas inaceptables.

Además de las influencias que pueden tener los riesgos más serios sobre el éxito de un

proyecto, todos los riesgos tienen algún impacto en la planificación, el coste o la calidad.

Algunos de estos riesgos pueden ser lo suficientemente serios como para prolongar la

planificación o incrementar el esfuerzo más allá del esfuerzo planeado. En casi todos los

casos un impacto en la planificación también afecta al esfuerzo y al coste. En algunos

casos, puede que un riesgo tenga poco impacto sobre la planificación o el coste pero

afecte negativamente a otros factores, como la calidad o el rendimiento.

63

2.1.10.4.3 Planificar la acción sobre los riesgos

El principio general es tener un plan de acción a seguir sobre los riesgos. Las fases y las

iteraciones dentro de las fases proporcionan el medio de planificar las acciones sobre los

riesgos. Es decir, se eliminan si es posible o al menos se da un plan de contingencia.

Cuando no existe un esfuerzo consciente para actuar pronto sobre los riesgos, éstos se

manifiestan usualmente al final de la planificación, mientras se realizan las pruebas de

integración y de sistema. Resolver a esa altura cualquier problema serio, que puede

requerir amplias modificaciones del sistema, puede retrasar la entrega durante varias

semanas o incluso más. En el enfoque iterativo la construcción de prototipos,

construcciones y artefactos descubre desde la primera fase los riesgos mientras hay aún

tiempo para tratarlos.

Es difícil identificar y describir algunos tipos de riesgos. Por muchas razones algunos

riesgos pueden ser "oscuros". Otra razón por la que los riesgos pueden pasar

desapercibidos es que algunas de las personas involucradas se confíen exageradamente

en lo que puede ser realizado con el precio marcado y en el tiempo deseado. Si hay

riesgos que no pueden ser identificados, entonces el proyecto no puede planificarlos en

iteraciones ni mitigarlos en ningún orden.

Sea cual sea la razón, en algunos proyectos se pasarán por alto algunos riesgos hasta

bastante avanzada la planificación, especialmente cuando el equipo del proyecto tenga

poca experiencia administrando riesgos. Con práctica y experiencia los equipos

mejorarán su capacidad para ordenar los riesgos de forma que se permita que el

proyecto proceda por un camino lógico. El objetivo es hacer que cada iteración en la fase

de construcción proceda libre de eventos y de acuerdo con el plan. Es improbable que

esto ocurra si el proyecto se encuentra con riesgos inesperados que no puedan ser

resueltos con rapidez.

2.1.10.5 Asignación de prioridades a los casos de uso

Cada iteración en el Proceso Unificado está guiada por un conjunto de casos de uso, o,

más exactamente, por un conjunto de escenarios a través de los casos de uso. Es más

exacto porque en las iteraciones iniciales no es necesario considerar casos de uso

completos, sino sólo los escenarios o caminos a través de los casos de uso más

apropiados para la tarea que tenemos entre manos. A veces, cuando se dice que se

selecciona casos de uso, se quiere decir que se está seleccionando los escenarios más

apropiados para la iteración.

La tarea que tiene como resultado esta selección se denomina dar prioridades a los

casos de uso. Las prioridades son asignadas a los casos de uso según deberían ser

64

éstos considerados en las iteraciones. Estos son clasificados a lo largo de varias

iteraciones; en las primeras iteraciones se clasifican algunos casos de uso (o escenarios

de ellos), pero muchos no han sido identificados en ella y por tanto no han sido

clasificados todavía. Todos los casos de uso que se identifican son también clasificados.

El resultado de la clasificación es una lista ordenada de casos de uso.

El control de esta clasificación es difícil. Se ordena los casos de uso de acuerdo con el

riesgo que conllevan. Obsérvese que aquí se usa el término riesgo en su sentido amplio.

No construir el sistema correcto es otro riesgo que se quiere mitigar pronto, encontrando

los requisitos apropiados. El proceso de selección está por tanto guiado por los riesgos.

Se coloca los riesgos que se identifican en una lista de riesgos y se transforma cada uno

de estos riesgos en un caso de uso que mitigará el riesgo cuando sea implementado. Ese

caso de uso será introducido entonces en la posición que le corresponde dentro de la

clasificación de casos de uso de acuerdo con su nivel de riesgo.

En las primeras iteraciones se dedica los casos de uso con mayor prioridad a los riesgos

relacionados con el ámbito del sistema y con la arquitectura. En las últimas iteraciones se

selecciona nuevos casos de uso para completar la arquitectura ya seleccionada con más

funcionalidad. Ponemos más músculos sobre el esqueleto. Los últimos casos de uso son

añadidos en algún orden lógico, que se corresponde con el orden utilizado para ordenar

la lista de casos de uso.

2.1.10.5.1 Riesgos específicos de un producto particular

Cada uno de estos riesgos es transformado en un caso de uso que, una vez

implementado correctamente, mitiga el riesgo. Se tiene que identificar estos riesgos uno

por uno, pues el tratar con ellos no es formalmente parte del proceso. Con "formalmente

parte del proceso" se quiere decir que el proceso proporciona un lugar específico en el

que tratar con cierto tipo de riesgo.

2.1.10.5.2 Riesgo de no conseguir la arquitectura correcta

Uno de los riesgos más serios es el de no construir un sistema que pueda evolucionar

suavemente por las fases siguientes o durante su tiempo de vida, es decir, el no

establecer una arquitectura flexible. Este riesgo es considerado explícitamente durante

las fases de inicio y de elaboración, cuando se debe asegurar de tener la arquitectura

correcta y podemos entonces fijarla (excepto cambios menores en la fase de

construcción).

¿Cómo se determina cuáles son los casos de uso más importantes para conseguir la

arquitectura correcta? ¿Cómo mitigar el riesgo de no conseguir una arquitectura estable.

65

Se buscó los casos de uso significativos arquitectónicamente, que son los que cubren las

principales tareas o funciones que el sistema ha de realizar.

La respuesta se encuentra en los casos de uso críticos. Además, los casos de uso que

tienen requisitos no funcionales importantes, como de rendimiento, tiempos de respuesta,

etc., entran en esta categoría. Normalmente estos casos de uso ayudan a encontrar el

esqueleto del sistema sobre el que añadir al resto de las funciones requeridas.

Otras categorías de casos de uso son:

Secundarios. Estos casos de uso sirven de apoyo a los casos de uso críticos.

Involucran funciones secundarias, como las de supervisión y compilación de

estadísticas operativas. En su mayor parte esta categoría de casos de uso tiene

sólo un impacto modesto sobre la arquitectura, aunque pueden todavía necesitar

ser desarrollados pronto.

Auxiliares. Estos casos de uso no son claves para la arquitectura o para los

riesgos críticos. Este nivel de casos de uso raramente entra en juego durante las

iteraciones en las fases de inicio y de elaboración, y si lo hace es sólo para

completar los casos de uso críticos o importantes.

Opcionales. Pocos casos de uso pueden ser críticos o importantes, puede incluso

que éstos no estén siempre presentes. Puede que necesitemos trabajar con ellos

porque afecten a la arquitectura cuando están presentes.

Además, se quiere estar seguro de que se ha considerado todos los casos de uso que

podrían tener algún impacto sobre la arquitectura. No se quiere dejar ninguna

funcionalidad en la sombra para descubrir demasiado tarde que no se tiene una

arquitectura estable. Necesitamos tener una alta cobertura de los casos de uso que

puedan afectar la arquitectura. Tener esta alta cobertura es importante, no sólo para

encontrar la arquitectura sino para asegurar que se puede predecir con precisión los

costes de desarrollo del producto en el primer ciclo. Se debe evitar el riesgo de darse

cuenta demasiado tarde de que no se puede dar cabida a una funcionalidad descubierta

recientemente.

Esta es la razón por la que se necesita cubrir alrededor del 80 por ciento de los casos de

uso en la fase de elaboración. Con "cubrir" se quiere decir que se entiende los casos de

uso y el impacto que pueden tener sobre el sistema. En la práctica, como promedio, se

identifica alrededor del 80 por ciento de los casos de uso y se los incluye en el modelo de

casos de uso, pero usualmente no es necesario describirlos todos en detalle. En un

proyecto típico se puede encontrar necesario describir sólo partes de los casos de uso.

Algunas de estas descripciones pueden ser breves, de sólo unas pocas líneas, sí eso es

66

suficiente para aclarar que se necesita saber en esa fase. En proyectos relativamente

simples en los que trabajan sobre los requisitos podemos detallar una parte menor de los

casos de uso. En proyectos más grandes y con grandes riesgos se puede encontrar

recomendable describir en detalle el 80 por ciento o más de los casos de uso.

2.1.10.5.3 Riesgo de no conseguir los requisitos correctos

Otro serio riesgo es no conseguir un sistema que haga lo que los usuarios quieren

realmente que haga. Las formas de tratar este riesgo son también parte del proceso. Al

final de la fase de elaboración se quiere estar seguro de que se está construyendo el

sistema correcto. Este descubrimiento no puede demorarse porque en la fase de

construcción el dinero empieza a fluir en grandes cantidades. ¿Cuáles son los casos de

uso necesarios para asegurar que se está desarrollando el sistema correcto para los

usuarios? ¿Cuáles son los casos de uso que aseguran que el sistema puede evolucionar

en las otras fases de forma que se podrá añadir todos los requisitos necesarios para la

primera entrega? No se puede dejar ninguna funcionalidad en la sombra. Se necesita

saber que lo que se construye puede crecer.

Por supuesto, la primera parte de la respuesta es hacer el flujo de trabajo de los

requisitos bien. Se podría crear un modelo de negocio (o un modelo de dominio más

limitado en algunos casos). La segunda parte de la respuesta es, basándose en las

iteraciones iniciales y en la construcción de prototipos, construir el sistema que quieren

los usuarios y obtener información sobre él tan pronto como sea posible. Sólo se puede

estar seguro de que se ha construido el sistema correcto a partir del uso real.

2.1.10.6 Recursos necesitados

Se puede pensar que el plan iterativo del desarrollo de software basado en fases tiene un

mérito considerable, pero varias cuestiones pueden importunar:

¿Cuánto van a costar las fases de inicio y de elaboración, tanto en términos de

esfuerzo como en términos de cualificación del personal necesario?

¿De dónde va a venir el dinero necesario para pagar estas fases?

¿Cuánto tiempo van a durar estas dos fases?

¿Por cuántos meses van a retrasar las primeras fases lo que mucha gente

considera como el negocio real del desarrollo de software, es decir, la

construcción?

67

2.1.10.6.1 Los proyectos difieren enormemente

No es un secreto que los sistemas de software difieren enormemente en su preparación

para empezar el desarrollo. Por ejemplo:

1. Un producto completamente nuevo o sin precedentes es un dominio inexplorado.

Nadie sabe mucho sobre lo que va a hacerse o incluso si es posible, hacerlo. Hay

poca experiencia en la que basarse y se tendrá que depender de gente

experimentada para hacer conjeturas basadas en su experiencia. Bajo estas

circunstancias el que quiere el sistema es responsable de financiar las fases de

inicio y de elaboración. Las fases han de ser financiadas casi como si se tratara

de investigación, es decir, como si se tratara de un valor añadido. Ni siquiera se

sabe lo suficiente como para fijar en las fases de inicio o de elaboración un

presupuesto o una planificación. En este tipo de situaciones definir el ámbito,

encontrar una arquitectura candidata, identificar los riesgos críticos y hacer el

análisis de negocio son tareas de la fase de inicio que consumen mucho tiempo.

De forma similar, alcanzar los objetivos de la fase de elaboración, es decir, llevar

el proyecto hasta el punto en que se pueda planear la fase de construcción, lleva

más tiempo.

2. Un producto de un tipo que ha sido realizado anteriormente en un campo en el

cual, productos anteriores proporcionan ejemplos pero no componentes

reutilizables. Estos productos previos proporcionan una guía para la arquitectura

candidata, pero puede llevar unos días asegurarse de que la arquitectura anterior

encaja realmente. Bajo estas circunstancias, la fase de inicio será probablemente

breve (pocas semanas). Puede requerir sólo un par de personas experimentadas

a tiempo completo, pero posiblemente se basará en el conocimiento de otras

personas experimentadas que el pequeño equipo del proyecto necesita consultar.

Ya que este tipo de producto ha sido real antes, es improbable tener grandes

riesgos, pero puede ser necesario dedicar algunos días a asegurarse de esto.

3. Hay un producto ya existente, pero este ha de ser actualizado. Hasta cierto punto,

partes del código existente pueden ser encapsuladas y utilizadas en el nuevo

sistema. El equipo inicial ha de encontrar una arquitectura candidata, y ya que

otras organizaciones han reutilizado productos existentes, el equipo sabe que

puede hacerse. Sin embargo, si la organización que propone hacer el trabajo no lo

ha hecho antes puede que no se conozca la información relacionada con el coste

y con planificación. Habrá que concebir una línea base para la arquitectura y se

tendrá que identificar una interfaz entre el sistema nuevo y el viejo empezando

con los casos de uso y con encontrar los subsistemas, siendo uno de los

68

subsistemas una encapsulación de las partes del sistema existente que no

necesitan ser cambiadas.

4. Existen los componentes, ya sea en el mercado o en la misma empresa. La

organización de software espera que un porcentaje considerable del nuevo

sistema, quizás entre un 50 y un 90 por ciento, pueda construirse a partir de estos

componentes, pero puede ser necesario hacer encajar los componentes, lo que

requeriría código nuevo. El proyecto necesitará identificar y especificar las

interfaces entre los componentes reutilizados y los nuevos y entre los sistemas

externos y los usuarios. Desarrollar a partir de componentes lleva tiempo y

esfuerzo, y el equipo puede tener riesgos, sin embargo, el desarrollo basado en

componentes es más rápido y más barato que cuando se empieza desde cero.

Con estos ejemplos no se intenta definir diferentes categorías, sino que representan más

bien posiciones solapadas. Se tiene que pensar, por tanto, en términos de estados de

comienzo. ¿Cuánta experiencia tiene la organización en el área de aplicación? ¿Cómo es

de grande la base de componentes reutilizables en la que se puede apoyar? ¿Es esta

propuesta algo más que una nueva entrega de un producto ya existente? ¿Mejorará el

estado del arte? ¿Es un sistema distribuido (donde sólo se ha realizado trabajos no

distribuidos)?

2.1.10.6.2 Una nueva línea de productos requiere experiencia

En la mayoría de los casos, para sistemas nuevos o difíciles, el equipo ha de adquirir más

información de la que posee. La fuente natural de esta información son las personas

informadas en el campo del sistema propuesto. Incluso cuando se dispone de requisitos

detallados, el equipo necesita estas entrevistas para encontrar la arquitectura y centrarse

en los riesgos. Sin embargo, las personas informadas son la mitad de la batalla. Los

usuarios normales pueden conocer tan sólo su parte del proceso completo; o puede que

éstos no sepan lo que los sistemas de computación son capaces de hacer.

Un fallo común cuando se comienza el trabajo en una nueva línea de productos es

intentar hacerlo sin reutilizar el conocimiento. Como la mayor parte del conocimiento

sobre la forma en que funciona la compañía reside en las mentes de las personas más

que en los documentos (los cuales no se leen de todos modos), reutilizar el conocimiento

básicamente se reduce a "reutilizar" a la gente experimentada. Este fallo se descubre a sí

mismo cuando se asigna personal nuevo al equipo inicial del proyecto en lugar de

asignar personal experimentado en las formas de hacer las cosas de la compañía,

cuando no en la nueva línea de producios misma.

69

Cuando una compañía planea desarrollar una nueva línea de productos esta sabe en una

parte de su mente colectiva que este trabajo requiere su gente más competente y

experimentada. Al mismo tiempo, sin embargo, en otra parte de su mente colectiva está

pensando que este tipo de personas es muy importante para mantener el negocio actual

funcionando. Tienen que mantener satisfechos a sus clientes, ya que la compañía ha de

mantener fluyendo la fuente de dinero existente.

No hay una respuesta fácil a este dilema. Los ejecutivos para quienes esta gente

experimentada está trabajando se encuentran entre estos dos objetivos. En la práctica,

muchos de los altos ejecutivos han estado ligados a la línea actual durante muchos años,

y están por tanto psicológicamente casados con ella. A menudo, muchos de ellos son

reacios a arriesgar el negocio actual dejando marchar al nuevo proyecto a su gente clave.

Como consecuencia de esto, el nuevo equipo tendrá poca gente con experiencia, y

puede que éstos no sean los líderes más fuertes; puede que ésta sea la gente que los

ejecutivos estaban deseando dejar marchar. Estos nuevos líderes tendrán entonces que

completar sus equipos con una gran cantidad de gente nueva, a menudo directamente de

la universidad.

Además de su inexperiencia, la gente nueva traerá consigo una particular actitud cultural.

Éstos tienden a ver viejo, como pasado de moda, todo lo que la compañía ha estado

haciendo. Para ellos sólo es bueno lo nuevo. Los recién llegados no aciertan a apreciar la

importancia de las materias que no aprendieron en la universidad, como los métodos de

producción y la administración del ciclo de vida.

Hemos observado que las compañías a menudo fallan al elegir el personal para el

desarrollo de una nueva línea de productos; generalmente este personal no tiene el

talento necesario para desarrollarla de forma que ésta esté lista para el mercado en el

momento apropiado. Normalmente, las deficiencias no se corrigen hasta la segunda

generación del producto, de forma que, en esencia, la primera versión se convierte en

una prueba para preparar el terreno, aunque puede que esta no haya sido la intención

original de la compañía.

2.1.10.6.3 El pago del coste de los recursos utilizados

Mantener el equipo que trabaja en las dos primeras fases, aunque sea pequeño, cuesta

dinero. De hecho, la dificultad de conseguir fondos para costear estas dos primeras fases

ha sido una de las causas que han llevado a las organizaciones fabricantes de software a

acometer la fase de construcción prematuramente, dando lugar a veces a fallos bien

conocidos, ¿De dónde han de venir estos fondos?:

En el caso de una organización fabricante de software que produce un producto

para vender, los fondos son parte de los "gastos generales" y, como tales, están

70

bajo el control de la dirección. A largo plazo, sin embargo, estos fondos proceden

de los clientes, es decir, estas organizaciones han de establecer los precios

actuales lo suficientemente altos como para cubrir el coste de desarrollar futuros

productos.


para un cliente dentro de la misma empresa, el coste de las primeras dos fases es

parte de los "gastos generales" de la compañía, de los fondos transferidos a ella

por el cliente o de los fondos asignados a ella por la alta dirección de la empresa.

Lo que indican las dos últimas formas de financiación es que la dirección fuera de

la organización fabricante de software ha de entender el valor de las primeras

fases y asignar fondos para financiarlas.


para una corporación distinta, el coste de las dos primeras fases puede venir de

sus gastos generales propios. Sin embargo, obtener este dinero de los gastos

generales sólo es posible si ya se ha invertido en desarrollos parecidos para

proyectos anteriores. Si el proyecto encaja dentro del negocio normal de la

organización este tipo de fondos puede ser suficiente pero si el proyecto

propuesto es más arriesgado de lo normal entonces el cliente debe contribuir a la

financiación de las dos primeras fases.

La realidad es que en las primeras dos fases se lleva a cabo un trabajo importante, y que

realizarlo lleva tiempo y cuesta dinero. Además de los fondos el llevarlas a cabo requiere

colaboración del cliente. Esta cooperación también cuesta dinero (aunque puede que

ésta no sea incluida formalmente en las cuentas).

2.1.10.7 Evaluar las iteraciones y las fases

Si se quieren conocer completamente los beneficios de la forma de trabajo iterativo, el

proyecto debe evaluar la parte del trabajo que se ha completado al final de cada iteración

o fase. El jefe de proyecto es responsable de esta evaluación. Este análisis se hace no

sólo para evaluar la iteración en sí, sino para impulsar estos otros dos objetivos:

Reconsiderar el plan de la iteración siguiente a la luz de lo que el equipo ha

aprendido realizando ésta y realizar los cambios necesarios en éste.

Modificar el proceso, adaptar las herramientas, prolongar la preparación y realizar

otras acciones como sugiere la experiencia de la iteración evaluada.

El primer objetivo de una evaluación es examinar lo que ha sido realizado en términos del

criterio de evaluación actual. El segundo objetivo es el de comparar el progreso realizado

con el plan de la iteración o del proyecto:

71

¿Avanza el proyecto dentro del presupuesto y siguiendo la planificación?

¿Está alcanzando los requisitos de calidad, de acuerdo con los resultados de las

pruebas o la observación de los prototipos, componentes y construcciones?

Idealmente, el proyecto cumplirá los criterios. El jefe del proyecto distribuye los

resultados de la evaluación a las personas relacionadas con el proyecto y archiva el

documento correspondiente. Este documento no se actualizará, cuando se informe de

la siguiente evaluación se creará un nuevo documento.

2.1.10.7.1 Criterios no alcanzados

Las evaluaciones raramente van tan bien. Frecuentemente alguna iteración no alcanza

los criterios satisfactoriamente. El proyecto puede tener que prolongar este trabajo

durante siguiente iteración (o hasta la iteración posterior apropiada). Este trabajo puede

implicar:

Modificar o extender el modelo de casos de uso.

Modificar o extender la arquitectura.

Modificar o extender los subsistemas desarrollados hasta entonces.

Buscar otros riesgos.

Incorporar ciertas habilidades al equipo.

También es posible que, simplemente, se necesite más tiempo para poder llevar a cabo

el plan existente. Si éste es el caso, el proyecto podría extender la planificación de la

primera iteración, aunque si esto ocurre entonces se debería especificar una fecha límite

firme.

2.1.10.7.2 Los criterios mismos

También es importante tener en cuenta los criterios de evaluación mismos. El equipo

puede haber establecido los criterios en un momento en que todavía no tenía disponible

toda la información relevante. A lo largo de la iteración podría haber descubierto

necesidades adicionales o que las necesidades que enumeró inicialmente se han

mostrado innecesarias. Por tanto, los evaluadores podrían tener que cambiar los criterios,

y no sólo comprobar si se alcanzan estos criterios.

2.1.10.7.3 La siguiente iteración

Un hito principal marca la terminación de una fase, el punto en el que no sólo el equipo

del proyecto sino todas las personas involucradas en él, en particular las autoridades que

proporcionan los fondos y los representantes de los usuarios, coinciden en que el

proyecto ha alcanzado el criterio del hito y que está justificado el paso a la siguiente fase.

72

Sobre la base de la evaluación, el jefe de proyecto (asistido por algunas de las personas

que trabajaron en la iteración o en la fase y por algunas de las personas que participarán

en la siguiente fase) hace lo siguiente:

Determina que el trabajo está listo para pasar a la siguiente iteración.

Si se necesita rehacer algún trabajo asigna en cuáles de las siguientes iteraciones

debería realizarse.

Planea en detalle la siguiente iteración.

Actualiza el plan, en menos detalle, de las iteraciones posteriores a la siguiente.

Actualiza la lista de riesgos y el plan del proyecto.

Compara el coste y la planificación de la iteración con los planeados.

Se puede observar que, en el desarrollo basado en componentes, el número de líneas de

código escritas no es un indicador fiable del progreso. Puesto que un desarrollador puede

reutilizar bloques (subsistemas, clases y componentes) ya diseñados, se puede avanzar

mucho sin escribir mucho código.

2.1.10.7.4 Evolución del conjunto de modelos

Una característica clave del desarrollo iterativo en fases es la evolución del conjunto de

modelos. Esta evolución contrasta con lo que ocurre en el modelo en cascada, donde se

imagina que los requisitos se completan primero, a continuación el análisis y así

sucesivamente. En el desarrollo iterativo, los modelos crecen juntos a través de las fases.

En las primeras iteraciones unos modelos van por delante de otros, por ejemplo, el

modelo de casos de uso va por delante del modelo de implementación. En lugar de que

un modelo evolucione casi independientemente del siguiente modelo se piensa en

términos de un estado del sistema entero que evoluciona a un estado más avanzado del

sistema entero. Cada iteración representa un avance en el estado del sistema completo,

el cual se refleja en el movimiento gradual hacia la compleción del conjunto de modelos.

Considerar el grado en que esta evolución ha progresado en cada evaluación será un

indicador importante para el grupo evaluador.

2.1.11 La Fase de Inicio

El objetivo principal de esta fase es establecer el análisis de negocio, aunque este

análisis se seguirá desarrollando en la fase de elaboración conforme se vaya disponiendo

de más información. La fase de inicio no es un estudio completo del sistema propuesto,

sino que en ella se busca el porcentaje (50 % aproximadamente) de casos de uso

necesarios para fundamentar el análisis de negocio inicial. Para realizar este análisis se

siguen cuatro pasos:

73

Delimitar el ámbito del sistema propuesto, es decir, definir los límites del sistema y

empezar a identificar las interfaces con sistemas relacionados que están fuera de

los límites.

Describir o esbozar una propuesta de la arquitectura del sistema, y en especial de

aquellas partes del sistema que son nuevas, arriesgadas o difíciles. En este paso

sólo se llega hasta una descripción de la arquitectura, raramente hasta un

prototipo ejecutable; esta descripción de la arquitectura consiste en unas primeras

versiones de los modelos. El principal objetivo es hacer creíble el que se pueda

crear una arquitectura estable del sistema en la siguiente fase. Esta arquitectura

no es construida en esta fase, simplemente se hace creíble el que se pueda crear

una. La construcción de esta arquitectura es el producto más importante de la

fase de elaboración.

Identificar riesgos críticos, es decir, los que afectan a la capacidad de construir el

sistema, y determinar si podemos encontrar una forma de mitigarlos, quizás en

una etapa posterior. En esta fase consideramos sólo los riesgos que afectan la

viabilidad, es decir, aquellos que amenazan el desarrollo con éxito del sistema.

Cualquier riesgo no crítico que se identifique es colocado en la lista de riesgos

para su posterior consideración detallada en la fase siguiente.

Demostrar a usuarios o clientes potenciales que el sistema propuesto es capaz de

solventar sus problemas o de mejorar sus objetivos de negocio construyendo un

prototipo. En la fase de inicio podemos construir un prototipo para mostrar una

solución al problema de los clientes o usuarios potenciales, el cual demuestra las

ideas básicas del nuevo sistema haciendo énfasis en su uso. Este prototipo tiende

a ser exploratorio, es decir, que demuestra una posible solución pero que puede

que no dé lugar al producto final, sino que acabe descartándose. Por el contrario,

un prototipo arquitectónico, desarrollado en la fase de elaboración, suele ser

capaz de evolucionar, es decir, un prototipo capaz de adaptarse sufriendo

modificaciones en la etapa siguiente.

Se continúa con estos esfuerzos hasta el momento en que desarrollar el sistema parece

ser rentable económicamente, es decir, hasta que se concluye que el sistema

proporcionará ingresos u otros beneficios proporcionales a la inversión necesaria con un

margen suficiente para construirlo. En otras palabras, se ha realizado una primera versión

del análisis de negocio, el cual será refinado en la fase siguiente, la de elaboración.

La intención es minimizar los gastos en tiempo de planificación, esfuerzo y fondos en esta

fase hasta que se decida si el sistema es viable o no. En el caso de un sistema

completamente nuevo en un dominio poco explorado esta consideración puede llevar un

74

tiempo y un esfuerzo considerables y puede extenderse a varias iteraciones. En el caso

de un sistema bien conocido en un dominio establecido o en el caso de tratarse de la

extensión de un sistema a una nueva versión, los riesgos y casos desconocidos pueden

ser mínimos, permitiendo que esta primera fase se complete en pocos días.

2.1.12 La Fase de Elaboración

El resultado principal de la fase de elaboración es una arquitectura estable para guiar el

sistema a lo largo de su vida futura. Esta fase también lleva el estudio del sistema

propuesto al punto de planificar la fase de construcción con gran precisión. Con estos dos

grandes objetivos ,la arquitectura y la estimación de costes con gran precisión, el equipo

hace lo siguiente:

1. Crea una línea base para la arquitectura que cubre la funcionalidad del sistema

significativa arquitectónicamente y las características importantes para las

personas involucradas. Esta línea base consiste en los artefactos de los modelos,

la descripción de la arquitectura y en una implementación ejecutable de ésta. Esta

línea base no sólo demuestra que se puede construir una arquitectura estable,

sino que encierra a la arquitectura.

2. Identifica los riesgos significativos, es decir, los riesgos que podrían perturbar los

planes, costes y planificaciones de fases posteriores, y los reduce a actividades

que pueden ser medidas y presupuestadas.

3. Especifica los niveles a alcanzar por los atributos de calidad, como la fiabilidad

(porcentajes de defectos) y los tiempos de respuesta.

4. Recopila casos de uso para aproximadamente el 80 por ciento de los requisitos

funcionales, suficiente para planificar la fase de construcción.

5. Prepara una propuesta de la planificación cubierta, personal necesario y coste

dentro de los límites establecidos por las prácticas de negocio.

Los requisitos y la arquitectura (en el análisis, el diseño y la implementación) representan

el grueso del esfuerzo en las fases de inicio y de elaboración.

2.1.13 La Fase de Construcción

El objetivo general de la fase de construcción viene indicado por su tarea fundamental: la

capacidad de operación inicial. Es decir, un producto listo para ser distribuido como

versión beta y ser sometido a pruebas. Esta fase emplea más personal a lo largo de un

periodo de tiempo más amplio que ninguna otra fase, y es por esto por lo que es tan

importante tener todos los detalles bien preparados antes de empezar con la

75

construcción. Generalmente esta fase requiere un mayor número de iteraciones que las

fases anteriores.

En muchos casos el tener un trabajo de requisitos, análisis y diseño pobre parece

implicar que la construcción lleve una cantidad de tiempo demasiado grande. En estos

casos los desarrolladores tienen que construir el sistema como pueden, empleando más

tiempo de lo necesario para que se satisfagan los requisitos y para eliminar los defectos.

Una de las grandes ventajas de construir software utilizando un enfoque que use

múltiples fases y un desarrollo iterativo e incremental es que permite equilibrar la

asignación de recursos y de tiempo a lo largo del ciclo de vida.

Entre las actividades de la fase de construcción tenemos:

1. La extensión de la identificación, descripción y realización de casos de uso a

todos los casos de uso.

2. La finalización del análisis (posiblemente quedan todavía más de la mitad de los

casos de uso por ser analizados cuando comienza la fase de construcción), del

diseño, de la implementación y de la prueba (posiblemente queda un 90 por

ciento).

3. El mantenimiento de la integridad de la arquitectura, modificándola cuando sea

necesario.

4. La monitorización. de los riesgos críticos y significados arrastrados desde las dos

primeras fases, y su mitigación si se materializan.

2.1.14 La Fase de Transición

La fase de transición comienza a menudo con la entrega de una versión beta del sistema,

es decir, la organización distribuye un producto software capaz ya de un funcionamiento

inicial a una muestra representativa de la comunidad de usuarios. El funcionamiento del

producto en el entorno de los usuarios es frecuentemente una prueba del estado de

desarrollo del producto más severa que el funcionamiento en el entorno del que lo

desarrolla.

Entre las actividades de la transición se incluyen:

Preparar las actividades, como la preparación del lugar.

Aconsejar al cliente sobre la actualización del entorno (hardware, sistemas

operativos, protocolos de comunicaciones, etc.) en los que se supone que el

software va a funcionar.

Preparar los manuales y otros documentos para la entrega del producto. En la

fase de construcción se prepara una documentación preliminar para los usuarios

de las versiones beta.

76

Ajustar el software para que funcione con los parámetros actuales del entorno del

usuario.

Corregir los defectos encontrados a lo largo de las pruebas realizadas a la versión

beta,

Modificar el software al detectar problemas que no habían sido previstos.

La fase de transición termina con la entrega del producto final. Sin embargo, antes de que

el equipo del proyecto abandone el proyecto, los líderes del equipo llevan a cabo un

estudio del sistema con los siguientes objetivos:

Encontrar, discutir, evaluar y registrar las "lecciones aprendidas" para referencias

futuras

Registrar asuntos útiles para la entrega o versión siguiente.

2.1.15 Cómo hacer que el Proceso Unificado funcione

El desarrollo de software para sistemas críticos sigue siendo excesivamente complejo. En

esta sección final se reúne todos los elementos, con objeto de atar cabos. Además, se

ampliarán dos nuevas áreas. Primero, si el proceso software es complejo por sí mismo,

de esto se deriva que la gestión de este proceso también es compleja. Segundo, la

transición entre no tener proceso o seguir un proceso ad hoc, y el Proceso Unificado no

va a ser un asunto sencillo.

2.1.15.1 El Proceso Unificado ayuda a manejar la complejidad

En primer lugar, se tiene las cuatro fases: inicio, elaboración, construcción y transición.

Más allá de las fases del ciclo inicial, y debido a que los grandes sistemas software están

en continuo desarrollo, llegan versiones posteriores y, tras revisiones generales, nuevas

generaciones. Dentro de estas fases se entremezclan los flujos de trabajo, la

arquitectura, la gestión de riesgos, las iteraciones e incrementos, como:

El desarrollo de software guiado por los casos de uso a través de los flujos de

trabajo: requisitos, análisis, diseño, implementación y pruebas

El desarrollo guiado por la arquitectura, el esqueleto de los elementos

estructurales y de comportamiento que permite que el sistema evolucione sin

sobresaltos.

El desarrollo a partir del uso de bloques de construcción y componentes,

facilitando la reutilización.

El desarrollo llevado a cabo a través de iteraciones y construcciones dentro de las

iteraciones, lo que resulta de un crecimiento incremental del producto.

El desarrollo con riesgos controlados.

77

El desarrollo visualizado y registrado usando el Lenguaje Unificado de Modelado

(UML).

El desarrollo evaluado en los hitos.

Cuatro hitos controlan el proceso: los objetivos del ciclo de vida, la arquitectura del ciclo

de vida, la capacidad operativa inicial y el lanzamiento del producto.

2.1.15.1.1 Los objetivos del ciclo de vida

El primer hito clarifica los objetivos del ciclo de vida del producto al plantear cuestiones

como:

¿Se ha determinado con claridad el ámbito del sistema? ¿Se ha determinado lo

que va a estar dentro del sistema y lo que va a estar fuera de él?

¿Se ha llegado a un acuerdo con todas las personas involucradas sobre los

requisitos fundamentales del sistema?

¿Se vislumbra una arquitectura que implemente estas características?

¿Se han identificado los riesgos críticos para el desarrollo exitoso del proyecto?

¿Se prevé una forma de mitigarlos?

¿El uso del producto generará beneficios que justifiquen lo invertido en su

construcción?

¿Es factible para la organización llevar adelante el proyecto?

¿Están los inversores de acuerdo con los objetivos?

Contestar a estas preguntas es asunto de la fase de inicio.

2.1.15.1.2 La arquitectura del ciclo de vida

El segundo hito clarifica la arquitectura para el ciclo de vida del producto a través de

cuestiones como:

¿Se ha creado una línea base de la arquitectura? ¿Es adaptable y robusta?

¿Puede evolucionar a lo largo de la vida del producto?

¿Se han identificado y mitigado los riesgos graves hasta el punto de asegurar que

no trastornarán el plan de proyecto?

¿Se ha desarrollado un plan de proyecto hasta el nivel necesario para respaldar

una agenda, costes y calidad realistas y que cubran la apuesta?

¿Proporcionará el proyecto, tal y como está planificado y presupuestado en este

momento, una recuperación adecuada de la inversión?

¿Se ha obtenido la aprobación de los inversores?

Contestar a estas preguntas es asunto de la fase de elaboración

78

2.1.15.1.3 Capacidad operativa inicial

El tercer hito establece que el proyecto ha alcanzado la capacidad operativa inicial: ¿El

producto ha alcanzado un nivel de capacidad adecuada para su operación inicial en el

entorno del usuario, en particular para realizar las pruebas beta?

Esta es la pregunta clave del tercer hito. Al comenzar a acercarse a este hito, se tiene

una línea base de la arquitectura, se ha investigado los riesgos, se tiene un plan de

proyecto y se tiene recursos. De modo que construimos el producto. Si se ha decidido por

los objetivos y la arquitectura del ciclo de vida, la construcción se desarrolla sin

sobresaltos. Una labor importante en esta fase es el secuenciamiento de construcciones

e iteraciones. Una buena secuencia indica que los prerrequisitos de cada iteración son

los correctos. Una buena secuencia evita tener que dar marcha atrás y rehacer una

iteración previa debido a algo aprendido más tarde.

No obstante, a pesar de nuestros esfuerzos para evitar problemas, algunos seguirán

apareciendo. Lo que hay que hacer aquí es superar los problemas del día a día. La

construcción del sistema es el objetivo de la fase de construcción.

2.1.15.1.4 Lanzamiento del producto

El cuarto hito determina que el producto está listo para su lanzamiento sin restricciones a

la comunidad de usuarios: ¿Es el producto capaz de operar con éxito en entornos de

usuario típicos?

Aún hay trabajo que hacer una vez alcanzada la capacidad operativa inicial; en concreto,

las pruebas beta, las pruebas de aceptación, y la corrección de los problemas y defectos

que surjan de la operación en el entorno de trabajo. Cuando se tiene algo con lo que los

usuarios se sientan satisfechos, se distribuirá el producto.

Estas tareas son asunto de la fase de transición.

2.1.15.2 Los temas importantes

Estos temas son el recorrido a través de los cuatro hitos principales y la vinculación de

unos con otros, pero también los requisitos, la arquitectura, el desarrollo basado en

componentes, el Lenguaje Unificado de Modelado, las iteraciones o la gestión de riesgos.

(El orden en que mencionamos los temas no refleja su importancia. Todos son

importantes. Todos tienen que combinarse unos con otros.)

Obtener correctamente los requisitos Se debe obtenerlos correctamente a través del

modelado de casos de uso, el análisis, etc. El mejor comienzo del Proceso Unificado está

guiado por los casos de uso.

79

Obtener correctamente la arquitectura Cualquier proyecto de tamaño considerable

tiene que estar centrado en la arquitectura. La arquitectura permite la partición del

sistema y el que estas particiones colaboren entre sí. La arquitectura solidifica las

interfaces entre las particiones, permitiendo que haya equipos trabajando de forma

independiente a cada lado de la interfaz y manteniéndola correcta. La vigilancia de la

arquitectura controla el proyecto desde un punto de vista técnico.

Usar Componentes Las firmes interfaces de la arquitectura (así como las interfaces

estándar de grupos estándar), son uno de los elementos que hacen posible el desarrollo

basado en componentes. Los bloques de construcción reutilizables reducen los costes de

desarrollo, ponen los productos en el mercado de forma más rápida y mejoran la calidad.

Pensar y Comunicarse en UML El desarrollo de software es algo más que escribir

código. UML (junto con otras características del Proceso Unificado) convierte el desarrollo

de software en una disciplina de ingeniería. Es un lenguaje gráfico con el que la gente del

software puede pensar, visualizar, analizar, comunicar y registrar.

Sin un medio de comunicación estándar como UML, habría gran dificultad en comprender

lo que otras personas y equipos están haciendo. Habría dificultades para transmitir la

información a través de las fases y a las versiones y generaciones posteriores.

Iterar Las iteraciones y construcciones proporcionan ventajas: tareas pequeñas, grupos

de trabajo pequeños, una ligazón con la gestión de riesgos, controles frecuentes, y

frecuentes realimentaciones.

Gestionar los riesgos Se debe identificar los riesgos; críticos, significativos, rutinarios,

ponerlos en una lista de riesgos, y mitigarlos antes de que se manifiesten en el proceso

de desarrollo.

2.1.15.3 La dirección lidera la conversión al Proceso Unificado

Más allá de la tarea de gestionar y controlar un proceso en curso, está la de llevar una

empresa, pública o privada, de los viejos métodos a la nueva senda. El ámbito

empresarial y gubernamental tiene, en la actualidad, muchas organizaciones que han

avanzado poco en la senda del proceso software. Por supuesto que desarrollan software,

ya que lo hacen de alguna forma, pero no lo están haciendo de forma organizada y

repetible. Así mismo, hay muchas otras organizaciones que disponen de alguna clase de

proceso software, pero que están, quizá de una forma vaga, insatisfechas con él.

También éstas desarrollan software, a veces con un éxito considerable, pero sienten que

debe haber algún camino mejor. Por supuesto que lo hay. ¿Cómo poner en marcha estas

organizaciones por el buen camino?

80

Un solo profesional que ocupe un puesto bajo en el escalafón no está en condiciones de

llevar a cabo esta transición. Puede ser el que actúe de líder de la nueva senda, una vez

que la organización haya decidido adoptarla. No, ésta es claramente una responsabilidad

del ejecutivo que esté en la cima de la empresa de desarrollo de software. Es él quien

debe liderar, porque esto afecta a toda su organización; el que tiene que entender la idea

de que existe un camino mejor y que es bueno transitarlo; el que tiene que sentir que la

competencia convierte en imperativo hacer algo pronto. Quizás reciba el germen de esta

idea de un colega cuya organización esté ya en marcha en el área del proceso software.

2.1.15.3.1 La necesidad de actuar

Debido a que el nuevo camino afectará a otras partes de la organización de desarrollo de

software y a toda la empresa, el primer ejecutivo debe buscar el apoyo de otros

ejecutivos. Puede hacer esto a través de una declaración de necesidad de actuar.

Básicamente, esta declaración establece que la forma en la que se están haciendo las

cosas ya no es válida. Que cuesta mucho. Que la calidad es baja y, lo que

probablemente es más importante, que el tiempo de entrega es demasiado largo. Incluso

si estamos utilizando nuestro software internamente, no estamos logrando los beneficios

competitivos de la mejora del software a un ritmo adecuado. Ganancias año a año de un

cinco por ciento ya no son lo bastante buenas. Ahora son posibles grandes ganancias en

estas tres áreas; costes, agenda y calidad, porque otras empresas lo han demostrado.

La declaración de la necesidad de actuar lleva a lo que debe ser esta acción. Por lo

general, las organizaciones de desarrollo de software no están en el negocio del

desarrollo de métodos, bloques de construcción ni componentes. Hay otras

organizaciones haciendo esto. Por ejemplo, existen organizaciones que producen y

venden componentes. Hay organizaciones, como Rational Software Corporation que

respaldan el Proceso Unificado. La labor del ejecutivo del software es descubrir dónde

puede conseguir la ayuda que su organización necesita.

Dado que las opciones no son muchas, para la mayoría de las organizaciones sólo hay

un camino: el desarrollo de software basado en componentes. Decidir si tratamos de

hacer mucho por nuestra propia cuenta, como en la banca, seguros, defensa,

telecomunicaciones, etc., o si tratamos de encontrar un sistema prefabricado, de construir

sobre bloques de construcción reutilizables, es un problema que debe resolver el

ejecutivo del software en función de su propia situación. En la mayoría de los casos habrá

aún algún desarrollo de software que realizar internamente. Alguien tendrá que adquirir

los bloques de construcción; alguien tendrá que ajustarlos a las necesidades específicas

de la empresa. Esto requiere un proceso software. En muchos casos, los ejecutivos del

81

software descubrirán que el Proceso Unificado es la respuesta a esa parte de sus

necesidades.

2.1.15.3.2 La directriz de reingeniería

El ejecutivo inicial explicará cuidadosa y extensamente, y sin exagerar en la directriz de

reingeniería, por qué la empresa está cambiando a un proceso software mejorado. La

directriz cubre:

La situación actual del negocio y el hecho de que está cambiando.

Lo que esperan los clientes en la actualidad.

La competición a la que se enfrenta la empresa.

Los retos que afronta la empresa.

El diagnóstico al que llevan estos retos.

Los riesgos que traerá el no realizar cambios.

Lo que la empresa debe hacer sobre el proceso software en particular.

Garantía de apoyo Los jefes de proyecto tienen que tener confianza en obtener apoyo

financiero continuado. Entre otras cosas, esta garantía cubre la formación inicial, el

asesoramiento mientras el Jefe de proyecto vigila las aplicaciones iniciales del nuevo

proceso, y la formación continuada a medida que cambian las necesidades. No se debe

intentar realizar la transición al nuevo proceso sin tener a alguien que lo haya hecho

antes. Los asesores saben cómo hacerlo. Pueden ser externos o internos. El comenzar

un nuevo proyecto con un nuevo proceso depende de la plena integración de cuatro

apoyos: proceso, herramientas, formación y asesoría.

Continuidad de los proyectos existentes En una empresa de cierto tamaño, con

muchos proyectos en curso, los proyectos actuales y la mayoría de los que aparezcan en

un futuro inmediato tendrán que continuar con el proceso actual. No se puede formar a

todo el mundo a la vez. No todo proyecto puede permitirse el posible trastorno de realizar

cambios considerables.

Al mismo tiempo, la directriz de reingeniería debería dejar claro que el personal y los jefes

de proyecto que continúen con los proyectos existentes no van a ser dejados de lado.

Cuando les toque el turno, serán formados y asignados a proyectos que se realicen bajo

el Proceso Unificado. La transición lleva tiempo. Necesariamente, la empresa debe

continuar con el negocio existente como parte del precio para estar ahí en el futuro. Se

formará a estas otras personas de manera que puedan participar en las discusiones

sobre lo que va a venir. No deben sentirse como proscritos. Si lo hacen, pueden dañar

seriamente el esfuerzo de transición.

82

Confianza en el propio futuro Las personas implicadas en esta transición son

profesionales del software. Este campo ha cambiado de forma drástica a lo largo de su

vida, corta según los estándares históricos. Algunos han tenido dificultades para

mantenerse al día. Los mandos intermedios, preocupados como están por tareas

administrativas, sienten especialmente esta carga. Si se sienten razonablemente

confiados en su propio futuro, esto ayudará a la transición. Las empresas que

tradicionalmente han cuidado de sí mismas tienen ventaja en esto, pero todas tienen que

ser conscientes de su importancia.

2.1.15.3.3 Implementación de la transición

El ejecutivo del software se enfrenta con los problemas de implementación.

El líder. El primer problema es tener una organización a través de la cual implementar la

transición. Ya que el propio ejecutivo del software tendrá probablemente todo su tiempo

ocupado, necesita un ingeniero técnicamente cualificado para liderar el cambio día a día,

es decir, para supervisar la transición. Este líder debe comprender el Proceso Unificado

y, para lograr tal comprensión, debe realizar alguna formación y conseguir asesoría

personalizada.

Este líder será, probablemente, un jefe de proyecto que sea técnicamente competente.

Podría ser un arquitecto con capacidades de dirección de proyectos. Habrá estudiado el

Proceso Unificado, estará convencido de que puede ayudar a la empresa y estará

deseoso de defender su punto de vista. Sin embargo, y al mismo tiempo, tendrá la

confianza tanto de los ejecutivos que le subvencionan, como de las personas que

participan en el proyecto. Sabrá cómo trabajar tanto con los gestores como con el

personal técnico. Será una persona que sea buena convenciendo a otros. Normalmente,

estará interesado en métodos y proceso, pero al mismo tiempo será lo suficientemente

maduro como para no comenzar desde cero con su propio y exclusivo método. Al

contrario, adaptará el Proceso Unificado a las necesidades particulares del primer

proyecto.

No es necesario que el líder haya estado antes en un proyecto que siguiese el Proceso

Unificado. De hecho, no es probable que haya tenido esta oportunidad, ya que habrá

estado trabajando para la organización desde hace algún tiempo. Sólo es necesario que

comprenda, lo que significa hacerlo. Basta con que esté deseoso de ponerse a hacerlo,

con ayuda, por supuesto, del Jefe de proyecto y el asesor, de los que hablamos a

continuación.

El jefe del primer proyecto. Además de este líder (por cierto, si no es capaz de

encontrar este hombre o mujer excepcional que hemos descrito, elija al mejor de los que

83

tenga y déle toda la ayuda que necesite), el ejecutivo del software responsable también

necesitará un jefe de excepcionalmente capaz. Necesitará uno que sienta hasta la

médula que es importante tanto adoptar el nuevo proceso como llevarlo a cabo. El

proyecto aún tiene que desarrollarse con éxito ante las caras de perplejidad que pueden

estar presenciando la adopción del nuevo proceso.

El asesor. La formación no lo es todo. En particular, no proporciona experiencia directa

en recorrer la nueva senda. Por tanto, el líder y el jefe de proyecto necesitarán estar

respaldados por un asesor (interno o externo) que haya estado en proyectos que

siguiesen el Proceso Unificado. El asesor no necesita tener experiencia de gestión,

aunque no es malo que la tenga. Necesitará dos talentos especiales. Uno es la habilidad

para anticipar problemas en el proyecto. Esta habilidad, por supuesto, estará basada en

haber estado anteriormente en un proyecto que adoptase el Proceso Unificado. Segundo,

tiene que ser capaz de colaborar con la variada gente con la que se encontrará, en

particular el líder, pero también el jefe de proyecto, el personal del proyecto y el ejecutivo

que lo financia.

Por dónde empezar. El primer proyecto debería ser uno real cuyos resultados fuesen

importantes. El primer proyecto debiera ser crítico, pero su agenda no debería ser

demasiado crítica. Todos los proyectos importantes tienen agendas apretadas.

En realidad, el trabajo bajo el Proceso Unificado discurre de forma más rápida que bajo

métodos más antiguos. Se buscan antes los riesgos, se desarrolla antes una arquitectura,

de modo que, en realidad, la construcción discurre más rápidamente. Además, el primer

proyecto estará guiado por asesores. Son asesores porque habrán participado

anteriormente en el proceso. Saben hacerlo funcionar.

En la práctica, aplicar la propuesta completa en un proyecto real es seguro, aunque esto

no significa hacer demasiadas cosas al mismo tiempo. El proceso, sí. Las herramientas

que van con el proceso, sí; si las herramientas están bien integradas. Pero, un nuevo

sistema operativo, una nueva tecnología de base de datos, un nuevo lenguaje de

programación, una nueva plataforma distribuida, probablemente no. Dependiendo de las

circunstancias, podría ser capaz de usar una tecnología nueva más. No en un sistema

tan grande como el primero.

84

2.2 Herramientas

2.2.1 UML

2.2.1.1 Introducción

UML es una especificación de notación orientada a objetos. Se basa en las anteriores

especificaciones BOOCH, RUMBAUGH y JACOBSON. Divide cada proyecto en un

número de diagramas que representan las diferentes vistas del proyecto. Estos

diagramas juntos son los que representan la arquitectura del proyecto.

Con UML se debe olvidar del protagonismo excesivo que se le da al diagrama de clases,

este representa una parte importante del sistema, pero solo una vista estática, es decir

muestra al sistema “parado”. Se conoce su estructura pero no que le sucede a sus

diferentes partes cuando el sistema empieza a funcionar. UML introduce nuevos

diagramas que representa una visión dinámica del sistema. Es decir, gracias al diseño de

la parte dinámica del sistema nos podemos dar cuenta en la fase de diseño, de

problemas de la estructura al propagar errores o de las partes que necesitan ser

sincronizadas, así como del estado de cada una de las instancias en cada momento. El

diagrama de clases continua siendo muy importante, pero se debe tener en cuenta que

su representación es limitada, y que ayuda a diseñar un sistema robusto con partes

reutilizables, pero no a solucionar problemas de propagación de mensajes ni de

sincronización o recuperación ante estados de error. En resumen, un sistema debe estar

bien diseñado, pero también debe funcionar bien.

UML también intenta solucionar el problema de propiedad de código que se da con los

desarrolladores, al implementar un lenguaje de modelado común para todos los

desarrollos se crea una documentación también común, que cualquier desarrollador con

conocimientos de UML será capaz de entender, independientemente del lenguaje

utilizado para el desarrollo.

UML es ahora un estándar, no existe otra especificación de diseño orientado a objetos,

ya que es el resultado de las tres opciones existentes en el mercado. Su utilización es

independiente del lenguaje de programación y de las características de los proyectos, ya

que UML ha sido diseñado para modelar cualquier tipo de proyectos, tanto informáticos

como de arquitectura, o de cualquier otro ramo.

UML permite la modificación de todos sus miembros mediante estereotipos y

restricciones. Un estereotipo permite indicar especificaciones del lenguaje al que se

refiere el diagrama de UML. Una restricción identifica un comportamiento forzado de una

85

clase o relación, es decir mediante la restricción se está forzando el comportamiento que

debe tener el objeto al que se le aplica.

2.2.1.2 Objetivos del UML

UML es un lenguaje de modelado de propósito general que pueden usar todos los

modeladores. No tiene propietario y está basado en el común acuerdo de gran

parte de la comunidad informática.

UML no pretende ser un método de desarrollo completo. No incluye un proceso de

desarrollo paso a paso. UML incluye todos los conceptos que se consideran

necesarios para utilizar un proceso moderno iterativo, basado en construir una

sólida arquitectura para resolver requisitos dirigidos por casos de uso.

Ser tan simple como sea posible pero manteniendo la capacidad de modelar toda

la gama de sistemas que se necesita construir. UML necesita ser lo

suficientemente expresivo para manejar todos los conceptos que se originan en

un sistema moderno, tales como la concurrencia y distribución, así como también

los mecanismos de la ingeniería de software, como son la encapsulación y

componentes.

Debe ser un lenguaje universal, como cualquier lenguaje de propósito general.

Imponer un estándar mundial.

2.2.1.3 Arquitectura del UML

Arquitectura de cuatro capas, definida a fin de cumplir con la especificación Meta Object

Facility del OMG:

Meta-metamodelo: define el lenguaje para especificar metamodelos.

Metamodelo: define el lenguaje para especificar modelos.

Modelo: define el lenguaje para describir un dominio de información.

Objetos de usuario: define un dominio de información específico.

2.2.1.4 Áreas conceptuales de UML

Los conceptos y modelos de UML pueden agruparse en las siguientes áreas

conceptuales:

2.2.1.4.1 Estructura estática

Cualquier modelo preciso debe primero definir su universo, esto es, los conceptos clave

de la aplicación, sus propiedades internas, y las relaciones entre cada una de ellas. Este

conjunto de construcciones es la estructura estática. Los conceptos de la aplicación son

modelados como clases, cada una de las cuales describe un conjunto de objetos que

almacenan información y se comunican para implementar un comportamiento. La

86

información que almacena es modelada como atributos; La estructura estática se expresa

con diagramas de clases y puede usarse para generar la mayoría de las declaraciones de

estructuras de datos en un programa.

2.2.1.4.2 Comportamiento dinámico

Hay dos formas de modelar el comportamiento, una es la historia de la vida de un objeto

y la forma como interactúa con el resto del mundo y la otra es por los patrones de

comunicación de un conjunto de objetos conectados, es decir la forma en que interactúan

entre sí. La visión de un objeto aislado es una máquina de estados, muestra la forma en

que el objeto responde a los eventos en función de su estado actual. La visión de la

interacción de los objetos se representa con los enlaces entre objetos junto con el flujo de

mensajes y los enlaces entre ellos. Este punto de vista unifica la estructura de los datos,

el control de flujo y el flujo de datos.

2.2.1.4.3 Construcciones de implementación

Los modelos UML tienen significado para el análisis lógico y para la implementación

física. Un componente es una parte física reemplazable de un sistema y es capaz de

responder a las peticiones descritas por un conjunto de interfaces. Un nodo es un recurso

computacional que define una localización durante la ejecución de un sistema. Puede

contener componentes y objetos.

2.2.1.4.4 Organización del modelo

La información del modelo debe ser dividida en piezas coherentes, para que los equipos

puedan trabajar en las diferentes partes de forma concurrente. El conocimiento humano

requiere que se organice el contenido del modelo en paquetes de tamaño modesto. Los

paquetes son unidades organizativas, jerárquicas y de propósito general de los modelos

de UML. Pueden usarse para almacenamiento, control de acceso, gestión de la

configuración y construcción de bibliotecas que contengan fragmentos de código

reutilizable.

2.2.1.4.5 Mecanismos de extensión

UML tiene una limitada capacidad de extensión pero que es suficiente para la mayoría de

las extensiones que requiere el día a día sin la necesidad de un cambio en el lenguaje

básico. Un estereotipo es una nueva clase de elemento de modelado con la misma

estructura que un elemento existente pero con restricciones adicionales.

2.2.1.5 Diagramas

Cada diagrama usa la anotación pertinente y la suma de estos diagramas crean las

diferentes vistas. Las vistas existentes en UML son:

87

Vista casos de uso: Se forma con los diagramas de casos de uso, colaboración,

estados y actividades.

Vista de diseño: Se forma con los diagramas de clases, objetos, colaboración,


Vista de procesos: Se forma con los diagramas de la vista de diseño. Recalcando

las clases y objetos referentes a procesos.

Vista de implementación: Se forma con los diagramas de componentes,

colaboración, estados y actividades.

Vista de despliegue: Se forma con los diagramas de despliegue, interacción,


Se dispone de dos tipos diferentes de diagramas, los que dan una vista estática del

sistema y los que dan una visión dinámica. Los diagramas estáticos son:

Diagrama de clases: muestra las clases, interfaces, colaboraciones y sus

relaciones. Son los más comunes y dan una vista estática del proyecto.

Diagrama de objetos: Es un diagrama de instancias de las clases mostradas en el

diagrama de clases. Muestra las instancias y como se relacionan entre ellas. Se

da una visión de casos reales.

Diagrama de componentes: Muestran la organización de los componentes del

sistema. Un componente se corresponde con una o varias clases, interfaces o

colaboraciones.

Diagrama de despliegue: Muestra los nodos y sus relaciones. Un nodo es un

conjunto de componentes. Se utiliza para reducir la complejidad de los diagramas

de clases y componentes de un gran sistema. Sirve como resumen e índice.

Diagrama de casos de uso: Muestran los casos de uso, actores y sus relaciones.

Son muy importantes para modelar y organizar el comportamiento del sistema.

Lo diagramas dinámicos son:

Diagrama de secuencia, Diagrama de colaboración: Muestran a los diferentes

objetos y las relaciones que pueden tener entre ellos, los mensajes que se envían

entre ellos. Son dos diagramas diferentes, que se puede pasar de uno a otro sin

pérdida de información, pero que nos dan puntos de vista diferentes del sistema.

En resumen, cualquiera de los dos es un Diagrama de Interacción.

Diagrama de estados: muestra los estados, eventos, transiciones y actividades de

los diferentes objetos. Son útiles en sistemas que reaccionen a eventos.

88

Diagrama de actividades: Es un caso especial del diagrama de estados. Muestra

el flujo entre los objetos. Se utilizan para modelar el funcionamiento del sistema y

el flujo de control entre objetos.

Como se puede ver el número de diagramas es muy alto, en la mayoría de los casos

excesivos, y UML permite definir solo los necesarios, ya que no todos son necesarios en

todos los proyectos.

2.2.1.6 Diagrama de casos de uso

Se emplean para visualizar el comportamiento del sistema, una parte de él o de una sola

clase. De forma que se pueda conocer como responde esa parte del sistema. El

diagrama de casos de uso es muy útil para definir como debería ser el comportamiento

de una parte del sistema, ya que solo especifica como deben comportarse y no como

están implementadas las partes que define. Por ello es un buen sistema el documentar

partes del código que deban ser reutilizables por otros desarrolladores. El diagrama

también puede ser utilizado para que los expertos de dominio se comuniquen con los

informáticos sin llegar a niveles de complejidad.

La notación gráfica de este diagrama incluye figuras como las siguientes:

Casos de uso (Figura 2.12): representado por una elipse, cada caso de uso contiene un

nombre, que indique su funcionalidad. Los casos de uso pueden tener relaciones con

otros caso de uso.

Figura 2.12. Caso de uso

Sus relaciones son:

Include: Representado por una flecha.

Extends: Una relación de un caso de Uso A hacia un caso de uso B indica que el caso de

uso B implementa la funcionalidad del caso de uso A.

Generalization: Es la típica relación de herencia.

Actores (Figura 2.13): se representan por un muñeco.

Figura 2.13: Actor

89

Sus relaciones son:

Communicates (Figura 2.14): Comunica un actor con un caso de uso, o con otro actor.

Figura 2.14: Relación de Comunicación

2.2.1.7 Diagrama de Clases

Forma parte de la vista estática del sistema. En el diagrama de clases como ya hemos

comentado será donde definiremos las características de cada una de las clases,

interfaces, colaboraciones y relaciones de dependencia y generalización. Es decir, es

donde daremos rienda suelta a nuestros conocimientos de diseño orientado a objetos,

definiendo las clases e implementando las ya típicas relaciones de herencia y agregación.

En el diagrama de clases debemos definir a estas y a sus relaciones.

2.2.1.7.1 La Clase

Una clase (Figura 2.15) está representada por un rectángulo que dispone de tres

apartados, el primero para indicar el nombre, el segundo para los atributos y el tercero

para los métodos.

Cada clase debe tener un nombre único, que las diferencie de las otras.

Un atributo representa alguna propiedad de la clase que se encuentra en todas las

instancias de la clase. Los atributos pueden representarse solo mostrando su nombre,

mostrando su nombre y su tipo, e incluso su valor por defecto.

Un método u operación es la implementación de un servicio de la clase, que muestra un

comportamiento común a todos los objetos. En resumen es una función que le indica a

las instancias de la clase que hagan algo.

Para separar las grandes listas de atributos y de métodos se pueden utilizar estereotipos.

Figura 2.15: Clase

2.2.1.7.1.1 Atributos

Los atributos o características de una Clase pueden ser de tres tipos, los que definen el

grado de comunicación y visibilidad de ellos con el entorno, estos son:

90

public (+): Indica que el atributo será visible tanto dentro como fuera de la clase,

es decir, es accesible desde todos lados.

private (-): Indica que el atributo sólo será accesible desde dentro de la clase (sólo

sus métodos lo pueden accesar).

protected (#): Indica que el atributo no será accesible desde fuera de la clase,

pero si podrá ser accesado por métodos de la clase además de las subclases que

se deriven.

2.2.1.7.1.2 Métodos:

Los métodos u operaciones de una clase son la forma en como esta interactúa con su

entorno, éstos pueden tener las características:

public (+): Indica que el método será visible tanto dentro como fuera de la clase,

es decir, es accesible desde todos lados.

private (-): Indica que el método sólo será accesible desde dentro de la clase (sólo

otros métodos de la clase lo pueden accesar).

protected (#): Indica que el método no será accesible desde fuera de la clase,

pero si podrá ser accesado por métodos de la clase además de métodos de las

subclases que se deriven.

2.2.1.7.2 Relaciones entre clases

Existen tres relaciones diferentes entre clases, Dependencias, Generalización y

Asociación. En las relaciones se habla de una clase destino y de una clase origen. La

origen es desde la que se realiza la acción de relacionar. Es decir desde la que parte la

flecha, la destino es la que recibe la flecha. Las relaciones se pueden modificar con

estereotipos o con restricciones.

En UML, la cardinalidad de las relaciones indica el grado y nivel de dependencia, se

anotan en cada extremo de la relación y estas pueden ser:

Uno a muchos: 1..* (1..n)

0 a muchos: 0..* (0..n)

Número fijo: m (m denota el número).

2.2.1.7.2.1 Dependencia

Es una relación de uso (Figura 2.16), es decir una clase usa a otra, que la necesita para

su cometido. Se representa con una flecha discontinua que va desde la clase utilizadora

a la clase utilizada.

91

Figura 2.16: Relación de Dependencia

Con la dependencia se muestra que un cambio en la clase utilizada puede afectar al

funcionamiento de la clase utilizadora, pero no al contrario.

Cabe destacar que el objeto creado no se almacena dentro del objeto que lo crea.

Aunque las dependencias se pueden crear tal cual, es decir sin ningún estereotipo

(palabra que aparece al lado de la línea que representa la dependencia) UML permite dar

más significado a las dependencias, es decir concretar más, mediante el uso de

estereotipos.

Estereotipos:

Bind: La clase utilizada es una plantilla, y necesita de parámetros para ser

utilizada, con Bind se indica que la clase se instancia con los parámetros

pasándole datos reales para sus parámetros.

Derive: Se utiliza al indicar relaciones entre dos atributos, indica que el valor de un

atributo depende directamente del valor de otro. Es decir el atributo edad depende

directamente del atributo Fecha nacimiento.

Friend: Especifica una visibilidad especial sobre la clase relacionada. Es decir

podrá ver las interioridades de la clase destino.

InstanceOF: Indica que el objeto origen es una instancia del destino.

Instantiate: indica que el origen crea instancias del destino.

Powertype: indica que el destino es un contenedor de objetos del origen, o de sus

hijos.

Refine: se utiliza para indicar que una clase es la misma que otra, pero más

refinada, es decir dos vistas de la misma clase, la destino con mayor detalle.

2.2.1.7.2.2 Herencia (Especialización / Generalización)

Indica que una subclase hereda los métodos y atributos especificados por una Super

Clase (Figura 2.17), por ende la Subclase además de poseer sus propios métodos y

atributos, posee las características y atributos visibles de la Super Clase (public y

protected).

Figura 2.17: Relación de Herencia

92

Aunque la representación común es suficiente en la mayoría de los casos, UML permite

modificar la relación de Generalización con estereotipos y restricciones.

Estereotipos:

Implementación: El hijo hereda la implementación del padre, sin publicar ni

soportar sus interfaces.

Restricciones:

Complete: La generalización ya no permite más hijos.

Incomplete: Podemos incorporar más hijos a la generalización.

Disjoint: solo puede tener un tipo en tiempo de ejecución, una instancia del padre

solo podrá ser de un tipo de hijo.

Overlapping: puede cambiar de tipo durante su vida, una instancia del padre

puede ir cambiando de tipo entre los de sus hijos.

2.2.1.7.2.3 Asociación

Especifica que los objetos de una clase están relacionados con los elementos de otra

clase (Figura 2.18). Se representa mediante una línea continua, que une las dos clases.

Podemos indicar el nombre, multiplicidad en los extremos, su rol, y agregación.

Cabe destacar que no es una relación fuerte, es decir, el tiempo de vida de un objeto no

depende del otro.

Figura 2.18: Relación de Asociación

2.2.1.8 Diagrama de componentes

Se utilizan para modelar la vista estática de un sistema. Muestra la organización y las

dependencias entre un conjunto de componentes. No es necesario que un diagrama

incluya todos los componentes del sistema, normalmente se realizan por partes. Cada

diagrama describe un apartado del sistema.

En el se encuentran librerías, tablas archivos, ejecutables y documentos que formen

parte del sistema.

Uno de los usos principales es que puede servir para ver que componentes pueden

compartirse entre sistemas o entre diferentes partes de un sistema.

Un componente (Figura 2.19) puede tener una interface que permitirá tener acceso a su

contenido.

93

Figura 2.19: Componente

Como se ha indicado antes, todo objeto UML puede ser modificado mediante

estereotipos, los estándar que define UML son:

Executable

Library

Table

File

Document

Se puede modelar diferentes partes del sistema, y modelar diferentes entidades que no

tienen nada que ver entre ellas, estas son:

Ejecutables y bibliotecas

Tablas

API

Código fuente

Páginas HTML

2.2.1.9 Diagrama de despliegue

En el diagrama de despliegue se indica la situación física de los componentes lógicos

desarrollados. Es decir se sitúa el software en el hardware que lo contiene. Cada

dispositivo hardware se representa como un nodo.

Un nodo se representa como un cubo, un nodo es un elemento donde se ejecutan los

componentes, representan el despliegue físico de estos componentes.

En la figura (Figura 2.20) se muestra dos nodos, el cliente y el servidor, cada uno de ellos

contiene componentes. El componente del cliente utiliza un interface de uno de los

componentes del servidor. Se muestra la relación existente entre los dos Nodos. A esta

relación se podría asociarle un estereotipo para indicar con que tipo de conexión se

dispone entre el cliente y el servidor, así como modificar su cardinalidad, para indicar que

se soporta diversos clientes.

94

Figura 2.20: Diagrama de Despliegue [PERE-2003]

Como los componentes pueden residir en más de un nodo se puede situar el componente

de forma independiente, sin que pertenezca a ningún nodo, y relacionarlo con los nodos

en los que se sitúa.

2.2.1.10 Diagrama de secuencia

El diagrama de secuencia forma parte del modelado dinámico del sistema. Se modelan

las llamadas entre clases desde un punto concreto del sistema. Es útil para observar la

vida de los objetos en el sistema, identificar llamadas a realizar o posibles errores del

modelado estático, que imposibiliten el flujo de información o de llamadas entre los

componentes del sistema.

En el diagrama de secuencia se muestra el orden de las llamadas en el sistema. Se

utiliza un diagrama para cada llamada a representar. Es imposible representar en un solo

diagrama de secuencia todas las secuencias posibles del sistema, por ello se escoge un

punto de partida. El diagrama se forma con los objetos que forman parte de la secuencia,

estos se sitúan en la parte superior de la pantalla, normalmente en la izquierda se sitúa al

que inicia la acción. De estos objetos sale una línea que indica su vida en el sistema.

Esta línea simple se convierte en una línea gruesa cuando representa que el objeto tiene

el foco del sistema, es decir cuando el está activo.

Los componentes de un diagrama de secuencia son

Objeto / Actor (Figura 2.21): El rectángulo representa una instancia de un Objeto

en particular, y la línea punteada representa la línea de vida del objeto.

95

Figura 2.21: Objeto

Mensaje a Otro Objeto (Figura 2.22): Se representa por una flecha entre un objeto

y otro, representa la llamada de un método (operación) de un objeto en particular.

Figura 2.22: Mensaje a otro objeto

Mensaje al Mismo Objeto (Figura 2.23): No solo llamadas a métodos de objetos

externos pueden realizarse, también es posible visualizar llamadas a métodos

desde el mismo objeto en estudio

Figura 2.23: Mensaje al mismo objeto

2.2.1.11 Diagrama de estados

Muestra el conjunto de estados por los cuales pasa un objeto durante su vida en una

aplicación (Figura 2.24), junto con los cambios que permiten pasar de un estado a otro.

Son útiles sólo para los objetos con un comportamiento significativo. Cada objeto está en

un estado en cierto instante. El estado está caracterizado parcialmente por los valores de

los atributos del objeto. El estado en el que se encuentra un objeto determina su

comportamiento. Cada objeto sigue el comportamiento descrito en el Diagrama de

Estados asociado a su clase.

96

Figura 2.24: Diagrama de estado [UML-2000]

Los componentes de un Diagrama de estados son:

Estado: Identifica un periodo de tiempo del objeto (no instantáneo) en el cual el

objeto está esperando alguna operación, tiene cierto estado característico o

puede recibir cierto tipo de estímulos. Se representa mediante un rectángulo con

los bordes redondeados, que puede tener tres compartimientos: uno para el

nombre, otro para el valor característico de los atributos del objeto en ese estado

y otro para las acciones que se realizan al entrar, salir o estar en un estado (entry,

exit o do, respectivamente).

Eventos: Es una ocurrencia que puede causar la transición de un estado a otro de

un objeto.

Envío de mensajes: Además de mostrar la transición de estados por medio de

eventos, puede representarse el momento en el cual se envían mensajes a otros

objetos. Esto se realiza mediante una línea punteada dirigida al diagrama de

estados del objeto receptor del mensaje.

2.2.1.12 Diagrama de actividades

El Diagrama de Actividad es una especialización del Diagrama de Estado (Figura 2.25),

organizado respecto de las acciones y usado para especificar:

Un método

Un caso de uso

97

Un proceso de negocio (Workflow)

Un estado de actividad representa una actividad: un paso en el flujo de trabajo o la

ejecución de una operación. Un grafo de actividades describe grupos secuenciales y

concurrentes de actividades. Los grafos de actividades se muestran en diagramas de

actividades. Las actividades se enlazan por transiciones automáticas. Cuando una

actividad termina se desencadena el paso a la siguiente actividad.

Un diagrama de actividades es provechoso para entender el comportamiento de alto nivel

de la ejecución de un sistema, sin profundizar en los detalles internos de los mensajes.

Los parámetros de entrada y salida de una acción se pueden mostrar usando las

relaciones de flujo que conectan la acción y un estado de flujo de objeto.

Figura 2.25: Diagrama de Actividades [UML-2000]

Un grafo de actividades contiene estados de actividad que representa la ejecución de una

secuencia en un procedimiento, o el funcionamiento de una actividad en un flujo de

trabajo. En vez de esperar un evento, como en un estado de espera normal, un estado de

98

actividad espera la terminación de su cómputo. Cuando la actividad termina, entonces la

ejecución procede al siguiente estado de actividad dentro del diagrama. una transición de

terminación es activada en un diagrama de actividades cuando se completa la actividad

precedente. Los estados de actividad no tienen transiciones con eventos explícitos, peor

pueden ser abortados por transiciones en estados que los incluyen.

2.2.6 Rational Rose

Rational Rose es la herramienta CASE totalmente orientada a objetos, desarrollada por la

empresa Rational.

A través de Rational Rose, el desarrollador puede realizar todos los diagramas de UML y

aplicarlos según sus necesidades; incluso existe una plantilla para elaborarlos según el

orden propuesto por el Proceso Unificado de Desarrollo.

Una de las ventajas de modelar los diagramas UML a través de Rational Rose, es que

existe la posibilidad de obtener el código en lenguajes de programación como Java o

Visual Basic; este último es el utilizado para la implementación de cada uno de los

métodos de las clases en el Modelo de Diseño.

Una vez creadas las clases de diseño, Rational Rose permite crear cualquier tipo de

componentes, con solo asignar las mencionadas clases a los componentes creados. El

tipo de componentes depende del Lenguaje base utilizado. De allí solo basta generar el

código.

La actualización entre el modelo de Rational y el código generado, es factible de hacerse

en ambos sentidos. Si se actualiza en el sentido código – modelo; Rational Rose crea un

paquete con el resultado de la Ingeniería Reversa aplicada.

2.2.9 Power Designer 10.0

Al igual que Rational Rose, Power Designer es una herramienta CASE propiedad de la

casa Sybase. La diferencia fundamental radica en que Power Designer tiene la

posibilidad de apoyar en el modelamiento de datos, pero es incipiente para modelar

empleando UML, este siendo el fuerte de Rational Rose.

Además de realizar el modelamiento de datos, Power Designer genera el archivo .sql,

necesario para crear las tablas y restricciones en la instancia de Base de Datos. Este

proceso se encuentra detallado en el Anexo B.

Power Designer permite adicionalmente, generar el Diccionario de Datos, el mismo que

se encuentra como anexo a este documento (Anexo A).

99

CONCLUSIONES Y RECOMENDACIONES

4.1 Conclusiones

1. Durante la aplicación del Proceso Unificado Rational, se realizaron las tareas tal

como la teoría aconseja hacerlo. En general en el medio latinoamericano se

menosprecia el valor de una metodología o proceso para crear software,

demeritando la profesión de Ingeniero de Sistemas, ya que generalmente se cede

al chantaje profesional del jefe o del cliente quien ordena la construcción

inmediata del software saltándose etapas fundamentales que no le permitirán al

producto ser de calidad y crecer con la empresa. Haciendo una comparación, el

construir software sin etapas como la captura adecuada de requerimientos,

análisis y diseño y gestión de proyectos, resulta similar a que un ingeniero

construya una casa sin planos, o que un medico cirujano realice una intervención

sin hacer estudios sobre el problema de salud. Resulta totalmente inadecuado el

seguir manteniendo los paradigmas erróneos de que las etapas omitidas se

pueden llevar a cabo durante la marcha, pues se conoce por experiencia, que el

tiempo no lo permite. Entonces donde queda la ética profesional.

2. El Proceso Unificado Rational se basa en la experiencia acumulada de lideres y

organizaciones durante 30 años de trabajo práctico. Incluye principios y técnicas

que permiten llegar a un fin único “software de calidad” bajo todos los parámetros

que esto involucre. Es un proceso que se adapta a diferentes campos de

aplicación y necesidades organizacionales. Es sobre todo un marco de trabajo

conjunto para todos los involucrados en el desarrollo del proyecto, así como una

manera de mantener la relación entre el equipo y el cliente.

3. A diferencia de metolodologías estructuradas, e incluso, orientadas a objetos, el

Proceso Unificado de Desarrollo de Software enmarca, además de los flujos de

trabajo conocidos como Análisis, Diseño, Implementación y Pruebas, un flujo de

trabajo de gestión del proyecto, el cual se lo lleva a cabo al inicio de cada

iteración. Esta característica convierte al Proceso Unificado de Desarrollo en un

verdadero Proceso de Ingeniería de Software, adquiriendo mayor jerarquía que

cualquier metodología.

100

4. El Proceso Unificado de Desarrollo de Software solventa de mejor manera los

requerimientos de los usuarios del sistema y de los clientes del negocio, ya que se

encuentra totalmente basado en casos de uso.

5. El tiempo de desarrollo empleado, utilizando el Proceso Unificado de Desarrollo

de Software, se justifica con el beneficio de obtener un producto de calidad bajo

conceptos como: escalabilidad, modularidad, fiabilidad y desempeño.

6. El RUP pone atención a las áreas de alto riesgo de manera temprana,

desarrollando una versión inicial del sistema, que define su arquitectura. No

asume un sistema fijo de requisitos establecidos al inicio del proyecto; sino

permite que el cliente y usuario refine los requisitos mientras el proyecto se

desarrolla.

7. El RUP es un proceso bastante genérico, que puede ser adaptado a una variedad

amplia de proyectos, en cuanto a tamaño y dominio se refiera, lo que no sucede

con otros procesos, tal es el caso de eXtreme Programming (XP) metodología que

ha tomado auge.

8. El RUP es un proceso que enfatiza en la alta productividad del equipo de

desarrollo, asignando tareas y responsabilidades. Todos los integrantes del grupo

de desarrollo tienen acceso a la misma base de conocimiento. Todos los

trabajadores, dentro del RUP, manejan un lenguaje común. Para el desarrollo de

este proyecto las tareas fueron distribuidas en base al mejor criterio de sus

autores y no como lo aconseja el RUP.

9. La plataforma Microsoft a la que se tuvo que regir la aplicación resultó un cuello

de botella al momento de realizar las tareas de implantación. La inestabilidad que

presenta esta plataforma es mundialmente reconocida y por ello da cabida al

surgimiento de nuevas tecnologías más seguras y estables. Si bien no se le

puede quitar el mérito de ser fácil de usar y presentar una interfaz intuitiva, estas

facilidades son opacadas por las fallas en la funcionalidad misma de sus

herramientas, lo que debería ser lo fundamental.

101

4.2 Recomendaciones

Para las personas involucradas en el desarrollo de cualquier producto software,

recomendamos:

1. La adopción de cualquier metodología o proceso para el desarrollo de cualquier

tipo de aplicación o componente software. Evitar el “desarrollo rápido”, que

involucra obviar fases tan importantes como son la captura apropiada de

requerimientos y el análisis.

2. Evaluar el alcance del proyecto y en base a aquello escoger la metodología o

proceso que más se ajuste al mismo. No siempre es bueno emplear RUP en todo

desarrollo, y esto se debe, principalmente, al tiempo y recursos que involucra

llevar a cabo todo el proceso.

3. Si se ha escogido emplear el RUP en el desarrollo de un proyecto, conformar un

grupo de trabajo sólido al que se le pueda asignar tareas y responsabilidades.

Adicionalmente a esto, evaluar la factibilidad económica y tecnológica, debido a

todos los recursos que se emplean en el RUP, antes de la firma de cualquier

contrato.

4. La herramienta de desarrollo necesariamente sea orientada a objetos, ya que el

RUP se basa en dicho concepto. La generación de componentes de software

requiere la existencia de clases o análogos.

5. Utilizar herramientas CASE que faciliten la generación, pero sobre todo la

representación del producto software. En este proyecto fueron dos las

herramientas utilizadas: Rational Rose para el modelamiento orientado a objetos y

Power Designer 7.0 para el modelamiento de datos.

Para INFOTEC:

1. Delegar a un funcionario para la administración de la aplicación. Dicho funcionario

no requiere tener conocimientos de bases de datos, únicamente requiere tener

claros los conceptos referentes a la información del sistema. Esta persona que

tendrá acceso a todas las opciones de la aplicación.

102

BIBLIOGRAFÍA

Addison Wesley, Ivan Jacobson, Grady Booch, James Rumbaugh. Madrid (2000)

El Proceso Unificado de Desarrollo de Software, Primera Edición. ISBN: 84-7829-

036-2


El Lenguaje Unificado de Modelado, Primera Edición. ISBN: 84-7829-028-1


El Lenguaje Unificado de Modelado. Manual de Referencia, Primera Edición.

ISBN: 84-7829-037-0

REFERENCIA DE SITIOS WEB

http://www.rational.com

103

http://www.rational.com/

RUP y UML1

Documents

Transcript of RUP y UML1