1.

Proceso Unificado (UP)

Un proceso de desarrollo de software es un conjunto de actividades que permiten
transformar las necesidades de un usuario en un sistema de software. Al referirnos con el
término usuario nos representa personas o algo (como ser la interacción con otros
sistemas) que participa con él sistema.
El proceso unificado está basado en componentes (parte física y reemplazable de un
sistema) interconectados a través de interfaces (son las operaciones que definen el
servicio de un componente o una clase) claramente definidas. Se utiliza el Lenguaje
Unificado de Modelado UML para especificar y documentar un sistema.
Dicho proceso está dirigido por los casos de uso, permiten definir las necesidades
de los usuarios representando los requisitos funcionales - ¿Qué debe hacer el sistema? -.
Es una porción de funcionalidad del sistema que proporciona un resultado importante al
usuario. Una vez que han sido detectados podemos definir el modelo de casos de uso, y
sobre la base de ellos se continúa especificando el desarrollo del software.
Se crean una serie de modelos de diseño e implementación que procesa cada uno de
los casos de uso, estos modelos son examinados para que consoliden al modelo de los
casos de uso que define la funcionalidad del sistema.
A su vez cuando el modelo de implementación es probado debe corroborar que se
implementan correctamente cada caso de uso. Podemos observar que los casos de uso
definen el comienzo de la especificación del sistema como así también la comprobación
de este.
Los casos de uso no se desarrollan aisladamente y algunos de ellos (los candidatos)
son utilizados para guiar la especificación de la arquitectura del sistema, y a su vez la
arquitectura influye en la selección de los casos de uso. Por lo tanto, la arquitectura como
los casos de uso se modifica a medida que avanza el ciclo de desarrollo.
La arquitectura permite visualizar una imagen completa del sistema antes de que
comience su construcción, describiendo diferentes vistas e incluyendo los diferentes
aspectos estáticos y dinámicos del sistema.
La misma se ve afectada por muchos factores como ser: la plataforma en la que tiene
que funcionar el software (sistema operativo, gestión de base de datos, protocolo de
comunicación, etc.), también deberá tenerse en cuenta los bloques de reutilización con
los que se dispone (interfaces gráficas, librerías adquiridas, etc.), sistemas heredados, y
requisitos no funcionales (rendimiento, fiabilidad, seguridad, acceso, etc.). Estos aspectos
determinan que los casos de uso y la arquitectura evolucionan paralelamente.
La arquitectura debe centrase sobre la compresión general de los casos de uso
claves, abarcan entre un 5% a un 10% del total de todos los casos de uso, los cuales
constituyen las funciones fundamentales del sistema. Los casos de usos claves, se utilizan
para no desvirtuarse de los detalles más significativos y suprimir aquellos que por el
momento son irrelevantes.
Al principio la arquitectura no especifica casos de uso, sino que manifiesta la
plataforma. Posteriormente se especifican los casos de uso claves y por cada uno de ellos
se especifica en detalle y en términos de subsistemas (agrupación de clases o de otros
subsistemas), clases y componentes. A medida que los casos de uso se especifican y
maduran, se descubre más de la arquitectura. Este proceso continúa hasta que se
considere que la arquitectura es estable.

Diseño de Sistemas Página 1 de 16 UTN

 Para comprender y constatar un trabajo es práctico dividirlo en partes más pequeñas
o mini-proyectos. Cada mini-proyecto es una iteración refleja los pasos a realizar
resultando un incremento en el crecimiento del producto. Las iteraciones deben ser
seleccionadas y ejecutadas en forma planificada.
Cada iteración seleccionará un grupo de casos de uso que extienden la utilidad del
producto desarrollado, analizando los riesgos más importantes. Se comienza con los
casos de uso y se continúa con el flujo de trabajo (modelo de negocio, requisitos,
(análisis y diseño), implementación, prueba y despliegue).
En la iteración se crea un diseño utilizando la arquitectura seleccionada como guía,
implementando el diseño mediante componentes, y verificando que los componentes
satisfagan los casos de uso.
El desarrollo es iterativo e incremental controlado reduce el costo de los riesgos,
ya que los costos de un solo incremento son menores que los costos que se ocasionan del
producto entero, mediante la identificación de los riesgos en fases tempranas del
desarrollo. Permite también que se trabaje de manera más eficiente debido a que se
obtienen resultados claros a corto plazo y por medio de ellos se clarifican las necesidades
de los usuarios, las cuales no pueden ser definidas completamente desde el principio.

1.1. Ciclo de vida del proceso unificado

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 del sistema a desarrollar y consta de cuatro
fases: inicio, elaboración, construcción y transición y cada fase a su vez se subdivide
en iteraciones y cada iteración realiza un flujo de trabajo. Cada fase termina con un hito,
punto en el que deben tomarse importantes decisiones de negocio, ya que se deben tomar
decisiones cruciales de continuar o no el proyecto, y decidir sobre la planificación,
presupuesto y requisitos de este.

Diseño de Sistemas Página 2 de 16 UTN

 Planificación de fases
Si bien, cada fase no tiene identificado un tiempo y esfuerzo exacto, porque varía
según las características propias del proyecto, del equipo de desarrollo, las restricciones
impuestas por el usuario, etc.
Se puede considerar para un proyecto, un ciclo de desarrollo típico según la
siguiente tabla:

Inicio Elaboración Construcción Transición

Esfuerzo 5% 20 % 65 % 10%
Prog. 10 % 30 % 50 % 10%
Horarios

Diseño de Sistemas Página 3 de 16 UTN

 Teniendo esta tabla como referencia uno puede realizar un cálculo estimativo de los
recursos necesarios para llevar a cabo un proyecto de mediana envergadura. Debemos
mencionar que un ciclo de desarrollo es una pasada por todas fases.

Breve descripción de las fases

En la fase de inicio se desarrolla una descripción del producto final y se presenta el
análisis de negocio para el producto. Analizar, ¿Cuáles son las principales funciones del
sistema para los usuarios más importantes?, ¿Cómo podría ser la arquitectura del
sistema?, ¿Cuál es el plan de proyecto y cuánto costará desarrollar el producto?
En la fase de elaboración se especifican en detalle la mayoría de los casos de uso
del producto y se diseña la arquitectura el sistema. La arquitectura se expresa en forma de
vistas de todos los modelos del sistema, los cuales juntos representan al sistema entero.
Se realizan los casos de uso más significativos que se identificaron en la fase de inicio y
como resultado se obtiene la línea base, esqueleto del sistema con poco desarrollo de
software, de la arquitectura. Al final de esta fase nos encontramos en posición de
planificar las actividades y estimar los recursos necesarios para el desarrollo del sistema.
En la fase de construcción se crea el producto incrementando el software al
esqueleto. En esta fase la línea base de la arquitectura crece hasta convertirse en el
sistema desarrollado. Al final de esta fase el sistema contiene todos los casos de uso que
se han acordado entre la dirección y el cliente. Analizar, ¿Cubre el producto las
necesidades de algunos usuarios de manera suficiente como para hacer la entrega?
En la fase de transición cubre el período de prueba y el producto se convierte en
una versión beta. En esta versión un número reducido de usuarios con experiencia
prueban e informan los defectos y deficiencias. Los defectos se dividen en dos categorías
los que tienen suficientes impactos para justificar una versión incrementada delta y los
que pueden corregirse en la siguiente versión.
El proceso UP se basa en tres ideas básicas (casos de uso, arquitectura, y el
desarrollo iterativo e incremental). Para poder hacer que estas ideas funcionen se
necesita un proceso polifacético: que tenga en cuenta ciclos, fases, flujos de trabajo,
gestión de riesgos, control de calidad, gestión de proyecto y control de configuración.

Diseño de Sistemas Página 4 de 16 UTN

1.2. Las cuatro “P” en el desarrollo de software: Personas,
Proyecto, Producto y Proceso.

1.2.1. Personas
UP define la palabra trabajador al puesto a ser asignado a una persona o equipo,
requiriendo responsabilidad y habilidades para realizar determinadas actividades, el
término de rol se utiliza para determinar los papeles que cumple un trabajador. Un
trabajador puede participar en varios flujos de trabajo y puede asumir un rol diferente en
cada uno de ellos siendo responsable de un conjunto de actividades. Un trabajador no es
un cargo concreto dentro de una em presa.
Las herramientas empleadas para realizar un trabajo deben ser las adecuadas, no sólo
deben ayudar a los trabajadores a llevar a cabo sus propias tareas sino también deben
poder aislar toda información que no sea relevante.
Una persona puede ser varios trabajadores dentro de un proyecto. Las aptitudes
requeridas por algunos trabajadores pueden conseguirse mediante formación
(especificador de casos de uso), mientras que otras sólo pueden obtenerse por medio de la
experiencia (arquitecto).
Especificador de Ingeniero de Ingeniero de Pruebas
Casos de Uso Componentes de Integración

Juan Guillermo

Diseño de Sistemas Página 5 de 16 UTN

1.2.2. Proyecto
El proyecto permite gestionar el desarrollo del producto de software. El resultado de
un proyecto finaliza con una versión del producto o aplicativo. Si el aplicativo a construir
es nuevo la finalización del proyecto inicial es su primera versión los próximos proyectos
modificarán o agregaran nuevos servicios y se incrementará un hito en el mismo número
de versión o incrementará en uno la versión.
Cada proyecto responde a un ciclo de vida constituido en tres etapas:

 Secuencia de cambio: cada ciclo, cada fase y cada iteración modifican el

sistema de ser una cosa a otra. El primer ciclo de desarrollo es un caso especial
que convierte el sistema de nada a algo. Cada ciclo conlleva a una versión, y
más allá de una secuencia de ciclos, el cambio continúa por generaciones.

 Serie de iteraciones: dentro de cada fase de un ciclo los trabajadores llevan a

cabo las actividades de la fase a través de una serie de iteraciones. Cada
iteración implementa un conjunto de casos de uso relacionados o atenúa
riesgos. En una iteración los desarrolladores progresan a través de una serie de
flujos de trabajo: requisitos, diseño, implementación y prueba. Por lo tanto, al
realizar cada uno de los flujos podemos ver a una iteración como un mini-
proyecto.

 Un patrón organizativo: un proyecto implica a un equipo de personas

asignadas para lograr un resultado dentro de las restricciones del negocio, es
decir, tiempo, coste y calidad.
La idea de proceso es proporcionar un patrón o plantilla para indicar que
trabajadores serán necesarios para el proyecto y cuáles serán artefactos
utilizados la realización en la creación del producto de software.

1.2.3. Producto
El producto hace referencia al sistema entero, y no sólo al código que se entrega.
Denominamos sistemas a todos los artefactos necesarios para poder representarlo en una
forma compresible para las máquinas, los trabajadores y los interesados.
Artefacto se denomina a cualquier tipo de información creada, producida, cambiada
o utilizada por los trabajadores en el desarrollo del sistema. En UML son los diagramas y
su texto anexado, los bocetos de la interfaz de usuario y los prototipos (primer molde de
algo), los componentes, los planes de prueba y los procedimientos de prueba.
Existen dos tipos de artefactos: los artefactos de ingeniería creados en las distintas
fases del proceso UP. Y los de gestión (análisis de negocios, plan de desarrollo, y plan de
asignación de recursos).
El tipo de artefacto más utilizado por UML es el modelo y cada trabajar necesita
una perspectiva diferente del conjunto de modelos. Representamos estos conceptos en las
diferentes gráficas.

Diseño de Sistemas Página 6 de 16 UTN

 Arquitecto Ingeniero de Prueba

Jefe de Proyecto Sistema Diseñadores

Analistas Usuarios

Un modelo es una abstracción del sistema para especificar un punto de vista en un

nivel de abstracción (especificación, diseño, etc.). Es una abstracción autocontenida ya
que un usuario de un modelo no necesita más información de otros modelos para
interpretarlo. Los usuarios saben que sucederá cuando se dispare un evento, ocurrencia de
un estímulo que puede ejecutar una transición de estados descrito en el modelo.
Cuando modelamos un sistema también deberíamos tener en cuenta los elementos
relevantes de su entorno. Los cuales son definidos como actores, representan los tipos de
usuarios que colaboran con el sistema internos y externos.
Los trabajadores que modelan los requisitos funcionales, no se preocupan de cómo
es el sistema por dentro, si analizan lo que pueden hacer los usuarios con él sistema por
medio de los casos de uso y los actores. Los trabajadores que modelan el diseño piensan
en elementos estructurales como subsistemas y clases, piensan en cómo estos elementos
funcionan en un contexto dado y como colaboran para proporcionar los casos de uso. Las
dos son interpretaciones diferentes, pero mutuamente consistentes de lo que hará el
sistema para responder a los diferentes estímulos externos provenientes de los actores.
Son diferentes debido a que están pensados para ser utilizados por diferentes trabajadores
con diferentes tareas y objetivos. El modelo de casos de uso es una vista externa del
sistema que captura los usos del sistema y el modelo de diseño es una vista interna que
representa la construcción del sistema.
El modelo de análisis también puede contener diagramas de actividad y todo
aquello que nos permita especificar el sistema desde una perspectiva conceptual. El
modelo de diseño puede contener más cosas, como diagramas de estados o diagramas
de interacción, también contiene colaboraciones (una sociedad de clases, interfaces y
otros elementos que trabajan juntos para proporcionar un comportamiento cooperativo).
Cada subsistema puede ser contenedor de construcciones similares implicando la
existencia una jerarquía de elementos en este modelo.
Un sistema contiene todas las relaciones, conexión semántica entre elementos, y
restricciones entre elementos incluidos en diferentes modelos. Por lo tanto, un sistema
no es sólo una colección de sus modelos, sino que contiene también las relaciones entre
ellos. Esta relación en UML es llamada dependencia de traza o traza.

Diseño de Sistemas Página 7 de 16 UTN

 Las relaciones de traza entre elementos en modelos distintos no añaden información
semántica sirven para ayudar a comprender los modelos relacionados, simplemente los
conectan. La posibilidad de crear trazas es muy importante en el desarrollo de software
por razones como la comprensibilidad y la propagación de cambios.

1.2.4. Proceso
Describimos un proceso como el término de flujo de trabajo, donde el mismo es un
conjunto de actividades. No se obtiene por medio de la división del proceso en
subprocesos más pequeños que interactúan, ni se utilizará diagramas de flujos
tradicionales para describir cómo descomponemos el proceso en partes más pequeñas.
Por el contrario, primero identificaremos los distintos trabajadores participantes en
el proceso. Después identificamos los artefactos que necesitamos crear durante el proceso
para cada tipo de trabajador. Una vez que los hemos identificados, podemos describir
como fluye el proceso a través de los diferentes trabajadores, y cómo ellos crean y
utilizan los artefactos de los demás.
A partir de este momento podemos identificar fácilmente las actividades que estos
trabajadores deben realizar cuando se activan.
Un flujo de trabajo es un estereotipo, permite la creación de nuevos tipos de bloques
de construcción derivados de otros existentes pero que no son específicos a un problema
particular. Esto implica que los trabajadores y los artefactos que participan en un flujo de
trabajo pueden participar en otros flujos de trabajo. Representación del flujo de trabajo de
los requisitos.

Diseño de Sistemas Página 8 de 16 UTN

Analista Identificar Actores Estructurar el Modelo de
y Casos de Uso Casos de Uso

Arquitecto Priorizar Casos de Uso

Especificador Detallar un Caso de Uso

de Casos de Uso

Diseñador de Esbozar Interfaz de Usuario

Interfaz

Flujos de Control de Proceso

Negocio Modelo de
Casos de Uso de
Negocio

Requisitos Modelo de
Casos de Uso

Modelo de
Análisis Análisis

Diseño Modelo de
Diseño

Implementación Modelo de
Implementación

Prueba Modelo de
Prueba

Despliegue
Modelo de
Despliegue

Diseño de Sistemas Página 9 de 16 UTN

1.3. Proceso dirigido por casos de uso
El objetivo de UP es guiar a los desarrolladores en la implementación y distribución
de eficientes sistemas para poder ajustarse a las necesidades de los usuarios. La eficiencia
se mide en términos de coste, calidad y tiempo de desarrollo.
Entender y comprender las necesidades del cliente no es tarea fácil ni trivial, siendo
vital poseer algún modo de capturar estas necesidades y poder fácilmente transmitirlas a
todas las personas implicadas en el proyecto. Después deberemos diseñar una
implementación funcional que se ajuste a estas necesidades. Por último, deberemos
verificar como las necesidades del cliente se han cumplido mediante la prueba del
sistema. Debido a esta complejidad el proceso se describe como una serie de flujo de
trabajo para poder construir el sistema gradualmente.
Los casos de uso han sido adoptados casi universalmente para la captura de
requisitos de sistemas software en general, y de sistemas basados en componentes (parte
física y reemplazable de un sistema que se ajusta a un conjunto de interfaces). Dirigiendo
al proceso de desarrollo de sistemas en su totalidad
Un caso de uso es una secuencia de acciones que el sistema lleva a cabo para ofrecer
algún 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.
Durante el análisis y diseño, el modelo de casos de uso se transforma en un modelo
de diseño a través de un modelo de análisis. Estos dos últimos modelos son estructuras
compuestas por clasificadores, mecanismo que describe las características estructurales y
de comportamiento (actores, clases, interfaces, tipos de datos, componentes y nodos), y
por un conjunto de realizaciones de casos de uso para describir cómo esa estructura
realiza los casos de uso.
Los clasificadores son, en general, elementos “parecidos a las clases” tienen
atributos y operaciones y se los puede describir con diagramas de estados. Algunos de
ellos pueden instanciarse y participar en colaboraciones, etc.
El modelo de análisis es una especificación detallada de los requisitos y funciona
como una primera aproximan del modelo de diseño. Los desarrolladores lo utilizan para
comprender de manera más precisa los casos de uso, refinándolos en forma de
colaboraciones entre clasificadores conceptuales a diferencia de los clasificadores de
diseño que serán objetos de implementación.
Es utilizado para crear un sistema más robusto y flexible, fomenta la reutilización de
los componentes de manera más considerable. Es diferente al modelo de diseño porque es
un esquema conceptual en lugar de ser un esquema de implementación. Dependiendo de
su envergadura (tamaño y/o complejidad) puede ser transitorio y sobrevivir solo en las
primeras iteraciones o mantenerse durante toda la vida del sistema.
Existe una relación directa, mediante dependencias débiles de traza, entre
realizaciones de casos de uso de análisis y las correspondientes realizaciones de casos de
uso de diseño. Cada elemento del modelo de análisis es trazable a partir de elementos del
modelo de diseño que lo realiza.

Diseño de Sistemas Página 10 de 16 UTN

 El modelo de diseño posee las siguientes características:

 El modelo de diseño es jerárquico, pero también contiene relaciones que

atraviesan la jerarquía. La utilización de las relaciones es habitual en UML:
asociaciones, generalizaciones y dependencias.

 Las realizaciones de los casos de uso son estereotipos de colaboraciones, una

colaboración representa cómo los clasificadores participan y desempeñan
papeles en hacer algo útil, como la realización de un caso de uso.

 El modelo de diseño es también un esquema de la implementación, existe una

correspondencia directa entre subsistemas del modelo de diseño y componentes
del modelo de implementación.
A través del modelo de análisis se puede incursionar en cada caso de uso de análisis,
siendo posible identificar las clases de análisis participantes en la realización del caso de
uso de análisis. Estas observaciones se realizan para que los desarrolladores puedan
asignarles las responsabilidades definidas en los casos de uso a las clases de análisis
identificadas. Una manera posible de detectar las responsabilidades es por medio de las
tarjetas CRC (Clase Responsabilidad Colaboración).
Los desarrolladores diseñan las clases y las realizaciones de los casos de uso de
diseño para obtener mejor rendimiento de los productos y tecnologías, (framework de
GUI, bases de datos, etc.), que se utilizarán para implementar el sistema. Las clases de
diseño se agrupan en subsistemas y pueden definirse interfaces entre ellos.
Los desarrolladores también preparan el modelo de despliegue, donde definen la
organización física del sistema en términos de nodos de cómputos y verifican que los
casos de uso pueden implementarse como componentes ejecutables en esos nodos.
La implementación se realiza por medio de clases diseñadas mediante un conjunto
de ficheros (código fuente) en el modelo de implementación, a partir de los cuales se
pueden producir (compilar y enlazar) ejecutables como (DDl o JavaBeans o componentes
ActiveX, etc.),
Durante el flujo de trabajo de prueba los ingenieros de prueba verifican que el
sistema implementa la funcionalidad descripta en los casos de uso y que satisfacen los
requisitos del sistema. Un caso de uso de prueba define una colección de entradas,
condiciones de ejecución y resultados. La mayoría de los casos de uso de prueba se crean
directamente a los casos de uso.
Una ventaja del Proceso Unificado (UP) y diferencia de este modelo con sus
anteriores es que la prueba puede planificarse al principio del ciclo de desarrollo. Tan
pronto se hayan capturado los casos de uso, es posible comenzar a especificar los casos
de uso de prueba (prueba de caja negra) y determinar el orden en el cual realizarlos,
integrarlos y probarlos. A medida que se vayan realizando los casos de uso en el diseño,
pueden detallarse las pruebas de los casos de uso (prueba de caja blanca). Un caso de uso
puede contener diferentes caminos alternativos de acciones a ejecutar, pero un caso de
uso de prueba candidato solamente realiza uno de ellos. A esta sola ejecución se la
denomina escenario, por lo tanto, la realización total del caso de uso estará conformado

Diseño de Sistemas Página 11 de 16 UTN

 Se presentó al (UP) como una secuencia de pasos y hasta el momento solamente se
ha realizado una sola iteración. Debemos recordar que la construcción del producto de
software estará constituida por varias iteraciones y a su vez cada iteración debe cumplir
con el flujo de trabajo de trabajo: negocio, requisitos, análisis, diseño, implementación y
prueba.
Existen varios motivos del porqué los casos de uso son buenos, pero se pueden
destacar dos razones importantes.
1. Proporcionan un medio sistemático e intuitivo de capturar requisitos
funcionales, centrándose en el valor agregado para el actor.
2. Dirigen todo el proceso de desarrollo, debido a que la mayoría de las
actividades como el análisis, diseño y prueba se realizan partiendo de los casos
de uso.
1. Los casos de uso son las funciones proporcionadas por el sistema para brindar
valor agregado a los usuarios. Tomando la perspectiva de cada tipo de usuario,
podemos capturar los casos de uso que necesitan estos usuarios para poder
realizar su trabajo. Pero si pensamos en el sistema como un conjunto de buenas
funciones sin abocarse a los casos de uso utilizados por usuarios concretos,
probablemente será difícil determinar si esas funciones son importantes o
incluso si son buenas. ¿A quién ayuda? ¿Qué necesidades del negocio
satisfacen? ¿Cuáles son los valores agregados que brindan al negocio?
Los mejores casos de usos son aquellos que brindan el mayor valor agregado
al negocio que implementará el sistema. Al ser intuitivos los usuarios y clientes
no deben aprender ninguna notación compleja. Siempre que sea posible hacer la
descripción de un caso de uso en lenguaje narrativo, su lectura será más sencilla
para la comunicación entre el cliente y el grupo de desarrolladores. Pero para
comprender la complejidad de las acciones del caso se utilizarán gráficos más
documentos.
El modelo de casos de uso se utiliza para conseguir un acuerdo entre los
usuarios y el cliente para conocer que debería hacer el sistema manejados por
los usuarios. Siendo posible pensar también como una especificación completa
de todas las formas posibles de utilizar el sistema. A su vez estas
especificaciones pueden ser utilizadas como parte de del contrato con el cliente.
Además, el modelo de casos de uso nos ayuda a delimitar el sistema definiendo
todo lo que debe hacer para sus usuarios.
2. A través de los casos de uso los desarrolladores pueden encontrar las clases
adecuadas para las realizaciones de los casos de uso, también permiten crear las
interfaces de usuario que facilitan la labor de las tareas que deben cumplir los
usuarios. No solamente inician el proceso de construcción del producto de
software, sino que además los enlazan con otro modelo (el caso de uso es
trazado con el caso de uso de análisis que a su vez este es trazado con el caso de
uso de diseño, y nuevamente el caso de uso también es trazado con el caso de
uso de prueba quién es trazado además con el caso de uso de diseño).
Una manera de asegurarse la captura de los casos de uso correcto es cuando
el sistema está en ejecución y nos permite una validación adicional de los casos
de uso con las necesidades reales del usuario.

Diseño de Sistemas Página 12 de 16 UTN

 Además, los casos de uso ayudan a los jefes de proyectos a planificar,
asignar y controlar muchas de las tareas que los desarrolladores realizan. Por
cada caso de uso a especificar es una tarea, cada caso de uso de análisis a
especificar es una tarea, cada caso de uso de diseño a especificar es una tarea,
cada caso de uso de prueba a especificar es una tarea. Y también para el jefe de
proyecto le es posible estimar el esfuerzo y el tiempo necesario para llevar a
cabo dichas tareas.
Como se ha mencionado anteriormente la trazabilidad es un aspecto
importante de la gestión de proyecto. Cuando se cambia un caso de uso, las
realizaciones, clases, componentes y casos de prueba correspondientes tienen
que comprobarse para ser actualizadas. De la misma manera cuando un
componente de fichero (código fuente) se modifica, las clases casos de uso y
casos de uso de prueba afectados también deben ser comprobados.

1.4. Proceso centrado en la Arquitectura

1.5. Proceso Iterativo e Incremental

1.6. Planificación y Evaluación

La planificación es necesaria a lo largo de todo el ciclo de desarrollo, se antepone a
los cinco flujos de trabajo realizados en cada iteración correspondiente a cada fase del
desarrollo y posteriormente se realiza la evaluación de ellos.
Antes de ponernos a planear es necesario saber qué es lo que tenemos que hacer.
Otro aspecto clave de la planificación es la administración de riesgos, se deberá realizar
la captura de los casos de uso e identificar y mitigar los riesgos por cada uno de ellos.
Un plan no estará completo sin la estimación de recursos que esté requerirá y, por
último, también debe llevarse a cabo la evaluación de la ejecución de cada iteración en
cada fase.
Se dividirá el trabajo en partes más pequeñas y comprensible. En fases y en cada una
de ellas en iteraciones. Dentro de cada iteración el proyecto deberá esforzarse en alcanzar
un equilibrio entre las secuencias de actividades que se ejecutan a lo largo de la iteración,
asignándoles una prioridad y sincronizándolas con facilidad.
En las primeras iteraciones trabajamos con riesgos críticos, casos de uso
fundamentales, cuestiones arquitectónicas, la elección del entorno de desarrollo, todas las
cuestiones orientaciones a la investigación. Mientras que en las últimas iteraciones
trabajamos en actividades orientadas al desarrollo, como la implementación y la prueba,
problemas de evaluación del rendimiento y el despliegue del sistema. El relacionar todas
estas actividades entre sí es una cuestión de equilibrio bastante delicada.
La secuencia para realizar en una planificación:
 La interacción con clientes en requisitos nuevos.

Diseño de Sistemas Página 13 de 16 UTN

  La preparación de una oferta para los clientes.
 La comprensión del contexto de un sistema creando un modelo de negocio.
 La planificación y administración de un proyecto.
 El establecimiento y administración de un entorno de desarrollo, es decir, el
proceso y las herramientas.
 La administración de riesgos.
 La instalación de un producto en su lugar de destino.
Utilizamos un ejemplo de un Laboratorio, guía de este curso, relevando la
concepción del negocio en “Minuta 1.1.1.doc” y el primer relevamiento realizado al
departamento de depósito en “Minuta 1.2.1.doc”.
Se ejemplifica el seguimiento de estos procesos en un (proyecto) y se planifica el
tiempo de la instalación para la plataforma del sistema. Por último, se detalla la
arquitectura y el equipamiento básico empleando el diagrama de emplazamiento
(Deployment view).
Este ejemplo es meramente utilizado para que el alumno pueda conceptualizar los
temas estudiados, pero, no significa que deba basarse en él para desarrollar sus prácticas
profesionales.
También si el alumno lo desea podrá practicar con el sector de producción el cual
cuenta un solo relevamiento realizado “Minuta 1.3.1.doc”.

Diseño de Sistemas Página 14 de 16 UTN

1.7. Ejemplificación
 Minuta 1.1.1.doc
El primer número contiene “1” se utiliza para la versión del producto, el
segundo número contiene “1” indicando el laboratorio en general y el tercer
número contiene “1” para relacionarlo con la iteración del documento Word.
Define el objetivo del producto y como se desarrollará.
 Arquitectura 1.1.1.doc
El primer número contiene “1” se utiliza para la versión del producto, el
segundo número contiene “1” indicando el laboratorio en general y el tercer
número contiene “1” para relacionarlo con la iteración del documento Word.
Especifica cómo estará constituida dicha arquitectura.
 Laboratorio 1.1.1. ea
El primer número contiene “1” se utiliza para la versión del producto, el
segundo número contiene “1” indicando el laboratorio en general y el tercer
número contiene “1” para relacionarlo con la iteración del gráfico Enterprise
Architect.
El Enterprise Architect (EA) crea por defecto un modelo gráfico
denominado “Business Process Model” “Modelo de Proceso de Negocio”. A este
modelo lo renombramos con el nombre de nuestro proyecto Laboratorio y lo
estereotipamos como “Negocio”. un primer paquete y un modelo de casos de
uso con el nombre (“Use Case Model”) y los cambiamos por (“Modelo Caso
Uso <Negocio>”), además contiene dos paquetes (“Actors” y “Primary Use
Cases”) los cuales se eliminan desapareciendo automáticamente del modelo de
casos de uso como así también se eliminan todas sus notas.
Dentro del modelo de casos de uso (“Modelo Caso Uso <Negocio>”) se
crea un nuevo paquete denominado (“Laboratorio <Negocio>”) el cual es
ilustrado en el modelo de casos de uso (“Modelo Caso Uso <Negocio>”). El
(“Laboratorio <Negocio>”) contiene diferentes paquetes para representar a los
diferentes departamentos del Laboratorio (“Compras <Negocio>”, “Control
Calidad <Negocio>”, “Depósito <Negocio>” y “Producción <Negocio>”) y
estos departamentos utilizan algunos artefactos de documentación agrupados en
el paquete (“Artefacto <Negocio>”). El total de estos cinco paquetes son
graficados en el modelo de casos de uso (“Laboratorio <Negocio>”).
El modelo de casos de uso (“Artefacto <Negocio>”) contiene la definición
de los elementos generales para la construcción del modelo de casos de uso del
negocio utilizamos el paquete con su respectivo modelo de casos de uso
denominado (“Actor <Negocio>”) con todos los actores del negocio encontrados
hasta el momento.
El modelo de caso de uso de negocio (“Depósito <Negocio>”) muestra el
primer gráfico de estos casos hallados en la (“Minuta 1.2.1). Se identificaron tres
casos de uso de negocio para realizar la gestión de depósito: recepcionar materia
prima, entregar materia prima aprobada y recepcionar producto terminado.
Los paquetes (“Compras <Negocio>”, “Control Calidad <Negocio>” y
“Producción <Negocio>”) no se desarrollan en este curso, pero del paquete
producción se ha entregado la (“Minuta 1.3.1”) la cual describe el relevamiento

Diseño de Sistemas Página 15 de 16 UTN

 del sector para que el alumno pueda desarrollarse tomando si así lo desea este
curso como ejemplo.
Se incorpora un nuevo modelo de despliegue y automáticamente crea un
paquete y modelo de despliegue llamados (“Deployment Model”) y los
cambiamos por (“Modelo Despliegue), además crea tres paquetes por defecto
(“Nodes”, “Artifacts”, y “Topology”) cambiados por (“Nodo”, “Artefacto” y
“Topología”) y cada uno de ellos contiene su respectivo modelo de despliegue
los cuales también son cambiados. Internamente creamos otro paquete y se crea
automáticamente su modelo de despliegue llamados (“Arquitectura”). El
paquete (“Arquitectura”) es graficado en el modelo de despliegue (“Modelo
Despliegue”).
Al paquete (“Arquitectura”) le movimos tres paquetes por defecto
(“Nodo”, “Artefacto” y “Topología”) ilustrados en el modelo de despliegue
(“Arquitectura”).
El modelo de despliegue denominado (“Nodo”) contiene en su interior el
diagrama de la estructura de hardware del Laboratorio organizado en tres
paquetes y tres modelos de despliegue por defecto (“Clients”, “Devices” y
Servers”) cambiados por (“Cliente”, Dispositivo” y “Servidor”) y cada uno de
ellos contiene los elementos del diagrama de hardware.
 Minuta 1.2.1.doc
El primer número contiene “1” se utiliza para la versión del producto, el
segundo número contiene “2” indicando el departamento de depósito y el tercer
número contiene “1” para relacionarlo con la iteración del documento Word.
Define el objetivo del departamento de depósito y su funcionalidad.
 Planificación 1.1.1.mpp
El primer número contiene “1” se utiliza para la versión del producto, el
segundo número contiene “1” indicando el laboratorio en general y el tercer
número contiene “1” para relacionarlo con la iteración del gráfico Proyect.
Se registra el tiempo incurrido de cada actividad realizada hasta el momento
permitiendo poder estimar las próximas tareas a desarrollar por el equipo para
cumplir con el producto.

Diseño de Sistemas Página 16 de 16 UTN