Manual de Procedimientos de Desarrollo de Sistemas Mediante Proceso Unificado

MANUAL DE PROCEDIMIENTOS
DISEO Y MODELADO DE SISTEMAS BASADOS EN EL

PROCESO UNIFICADO DE DESARROLLO DE SOFTWARE,
UTILIZANDO MICROSOFT VISIO 2003 FOR ENTERPRISE
ARCHITECTS PARA LA ELABORACIN DE DIAGRAMAS UML
Gustavo Federico Agostini
_________
OCTUBRE 2005
Tabla de Contenidos
Introduccin ................................................................................................................................. 5
CAPTULO I .................................................................................................................................. 6
Marco Terico - Introduccin .................................................................................................... 6
CAPTULO II ................................................................................................................................. 8
Marco Terico - Desarrollo ....................................................................................................... 8
El Proceso Unificado ............................................................................................................ 8
Introduccin ...................................................................................................................... 8
Aspectos dinmicos ....................................................................................................... 11
Inception ..................................................................................................................... 11
Elaboration ................................................................................................................. 13
Construction ............................................................................................................... 15
Transition ................................................................................................................... 16
Aspectos Estticos ......................................................................................................... 17
Roles .......................................................................................................................... 18
Activities ..................................................................................................................... 19
Artifacts ...................................................................................................................... 20
Workflows ................................................................................................................... 21
Disciplines .................................................................................................................. 22
Elementos secundarios .............................................................................................. 22
Resumiendo ................................................................................................................... 22
Lenguaje Unificado de Modelado UML .............................................................................. 25
Introduccin .................................................................................................................... 25
Diagrama de actividades ................................................................................................ 26
Diagrama de clases ........................................................................................................ 27
Diagrama de distribucin................................................................................................ 31
Diagrama de paquetes funcionales ................................................................................ 32
Diagramas de caso de uso ............................................................................................. 32
Diagrama de componentes ............................................................................................ 34
Diagrama de secuencia .................................................................................................. 34
Diagrama de estados ..................................................................................................... 36
Diagrama de colaboraciones.......................................................................................... 37
Diagrama de objetos ..................................................................................................... 38
Microsoft Visio 2003 for Enterprise Architects .................................................................... 39
Diagramas UML en Microsoft Visio ................................................................................ 39
CAPTULO III .............................................................................................................................. 43
Procedimientos de desarrollo ................................................................................................. 43
Captura de los requisitos funcionales del sistema ............................................................. 43
Diagrama de actividades .................................................................................................... 43
Primeros casos de uso ....................................................................................................... 44
Diagrama de clases preliminar ........................................................................................... 44
Plataforma Preliminar ......................................................................................................... 45
Descripcin de paquetes de funcionalidad ......................................................................... 45
Diagrama de casos de uso ................................................................................................. 45
Diagramas de secuencias .................................................................................................. 46
Diagramas de distribucin y de componentes ................................................................... 46
Diagramas adicionales ....................................................................................................... 46
Anexo I ........................................................................................................................................ 47
Especificacin de requisitos .................................................................................................... 47
Estructura Bsica ................................................................................................................ 47
Desarrollo resumido............................................................................................................ 47
Anlisis de Requisitos del Sistema ................................................................................ 47
1. Identificacin de los usuarios participantes ................................................................ 47
2. Planificacin y Realizacin de Entrevistas. Estudio de Documentacin. .................. 48
3. Catlogo de Requisitos del Sistema .......................................................................... 48
3.1. Objetivos y alcance del sistema.......................................................................... 49
3.2. Definiciones, acrnimos y abreviaturas .............................................................. 49
3.3. Descripcin general ............................................................................................ 49
3.4. Requisitos funcionales ........................................................................................ 49

3.5. Requisitos de usuario y tecnolgicos ................................................................. 49
3.6. Requisitos de interfaces externas ....................................................................... 50
3.7. Requisitos de rendimiento .................................................................................. 50
3.8. Requisitos de desarrollo y restricciones de diseo ............................................ 50
Bibliografa ................................................................................................................................. 51
Captulo I: Introduccin
Introduccin
Captulo I: introduce un marco terico, donde se deja en evidencia la

necesidad de la implementacin de una metodologa de desarrollo, y la
necesidad de utilizar UML para plasmar el diseo del sistema.
Captulo II: trata sobre el Proceso Unificado de Desarrollo de Software,
sus fases y principales caractersticas, da una descripcin de los diversos
diagramas utilizados en UML, as como los elementos utilizados en cada uno y
muestra un pantallazo sobre Microsoft Visio 2003 for Enterprise Architects.
Captulo III: da los pasos detallados para la construccin de un sistema
de software reuniendo todos los captulos anteriores.
Captulo I: Marco Terico Introduccin
CAPTULO I
Marco Terico - Introduccin
Un sistema de software surge como solucin a la necesidad de alguien

que desea manejar algn aspecto de la realidad mediante algn elemento de
tecnologa. Es aqu donde esta la gran complejidad del desarrollo de software.
Plasmar la realidad, por lo general tangible, en algo totalmente intangible.
Durante muchos aos surgieron muchas tcnicas y mtodos de programacin
para ayudar a los desarrolladores a poder modelar mejor la realidad a travs
del software. Sin duda alguna, el mayor avance lo propici la Orientacin a
Objetos (OO).
La tendencia actual en el software lleva a la construccin de sistemas
ms grandes y ms complejos. Esto es debido en parte al hecho de que los
computadores son ms potentes cada ao, y los usuarios, por tanto , esperan
ms de ellos. Queremos un software que este mejor adaptado a nuestras
necesidades, pero esto, a su vez, simplemente hace el software ms complejo.
Tambin lo queremos ms rpido. El tiempo de salida al mercado es otro
conductor importante [EPUDS00].
Un proyecto de software no solo involucra la complejidad de programar
en un lenguaje determinado, sino adems debe captar los requisitos que debe
cumplir el sistema, adaptarse a las tecnologas actuales, proporcionar
herramientas para evolucionar. Generalmente, el desarrollo no esta en manos
de una sola persona, por lo que un proyecto de software, adems, debe contar
con medios para poder comunicar claramente los objetivos y el diseo de
software entre los distintos miembros del equipo de desarrollo.
Para manejar de forma ordenada toda esta complejidad involucrada en
el desarrollo de un software, es necesario seguir una metodologa clara, una
gua que diga que hacer, cuando y como. La metodologa elegida por el
Departamento de Sistemas fue el Proceso Unificado, el cual es el resultado
de aos de experiencia y evolucin de distintas metodologas (Figura 1).
Como puede evidenciarse en la Figura 1, UML fue desarrollado en forma
paralela al Proceso Unificado. UML es el Lenguaje Unificado de Modelado
(Unified Modeling Language). UML es un leguaje visual de propsitos
generales usado para especificar, visualizar, construir y documentar los
distintos elementos involucrados en un sistema de software. Puede ser usado
con cualquier metodologa de desarrollo. Tiene cuatro partes que describen
aspectos estticos, dinmicos, de ambiente y organizacionales.
Captulo I: Marco Terico Introduccin
Figura 1 Breve historia del Proceso Unificado y de UML
Por qu es necesario UML? Simplemente porque no existe un estndar

actual en lo que a documentacin de sistemas refiere. UML fue adoptado como
estndar de hecho (de facto) por la comunidad de desarrolladores de software
y tiene el respaldo completo del Grupo de Administracin de Objetos (Object
Management Group, OMG). De esta forma un sistema puede fcil y claramente
ser trasladado de un grupo de desarrollo a otro, sin que se pierdan detalles de
diseo, ya que se usa un lenguaje comn entre todos.
Captulo II: Marco Terico Desarrollo
CAPTULO II
Marco Terico - Desarrollo
El Proceso Unificado
Introduccin
El proceso de desarrollo de software tiene 4 roles principales:
1.- Organizar las actividades a ejecutarse por el equipo de
desarrolladores.
2.- Especificar que elementos deben ser desarrollados y en que tiempo.
3.- Dirigir las tareas de cada desarrollador as como del equipo completo.
4.- Ofrecer criterios de monitorizacin y medicin del desarrollo.
Existen bsicamente dos tipos de ciclos de vida de software:
en cascada (waterfall) o secuencial

iterativo
El principal objetivo de un desarrollo de software como ya vimos es

captar con la mayor precisin posible las necesidades o los requisitos de los
clientes. El ciclo de vida en cascada, parte de creer que los requisitos pueden
ser congelados en el tiempo, es decir, que los clientes no cambian sus
necesidades a medida que avanza el proyecto. En la mayora de los proyectos
chicos de software esto es as, pero en general, los requisitos cambian y
mucho. Realizar rectificaciones en un proyecto con ciclo de vida en cascada es
muy caro, porque estas se realizan cuando el software ya ha sido
implementado.
Es por ello que surge el ciclo de vida iterativo. La idea es ir
aproximndose gradualmente al software final mediante varios ciclos o
iteraciones. Estas iteraciones no son mas que pequeos ciclos en cascada que
se ejecutan uno detrs de otro, lo que permite captar el dinamismo de los
requisitos del cliente, y satisfacer as con mayor precisin a sus necesidades.
Tambin permite corregir errores desde el principio, lo que es ms eficiente y
menos costoso. Las tareas se pueden realizar en paralelo, ya que cada rea
del equipo (planificacin, diseo, implementacin, etc.) puede ir trabajando con
mayor anticipacin.
La figura 2 muestra un diagrama de un ciclo de vida iterativo, mientras
que la figura 3 muestra la relacin entre un ciclo de vida en cascada y uno
iterativo.
Figura 2. Ciclo de Vida Iterativo
Podemos mencionar algunas de las ventajas de usar un ciclo de vida iterativo:
Enfrenta anticipadamente los problemas de alto riesgo (tcnicos, de

requisitos, de objetivos, etc.)
Progreso visible rpidamente
Realimentacin temprana con los distintos participantes del proyecto
(stakeholders).
Maneja muy bien la complejidad, el equipo de desarrollo no se ve
aplastado por la espera de una etapa muy larga de planificacin o de
pasos muy largos y complejos.
Se aprende a medida que se desarrolla, lo que permite usar estos
conocimientos para ir mejorando de iteracin en iteracin.
10
Figura 3. Relacin entre un ciclo de vida en cascada y uno iterativo
El Proceso Unificado (UP) o el Proceso Racional Unificado (RUP) es un

proceso de ingeniera de software, que provee una asignacin disciplinada
de tareas y responsabilidades, garantizando la creacin de un software de
alta calidad, que cubra con todas las expectativas del cliente, acotando
tiempo y presupuesto.
Sus principales caractersticas son:
ciclo de vida iterativo y evolutivo

administracin de requisitos dinmicos
Uso de componentes
Uso de una arquitectura para el desarrollo de software
Modelado visual utilizando UML
Administracin de cambios
Desarrollo guiado por casos de usos
RUP se divide en dos dimensiones o dos aspectos:

o Aspectos estticos: aquellos que no dependen del tiempo
como ser los roles, responsabilidades, tareas, etc.
o Aspectos dinmicos: aquellos que dependen del tiempo.
11
Aspectos dinmicos
RUP se divide en 4 etapas o fases del desarrollo:
1234-
Inception
Elaboration
Construction
Transition
En cada una de estas etapas se realizan las iteraciones. La figura 4

muestra un diagrama representativo.
Figura 4. Ciclo de desarrollo en RUP
Cada fase o etapa viene seguida de una pequea etapa de evaluacin y

decisin (milestone) en donde se evala la factibilidad del proyecto de acuerdo
a su desarrollo, a la cobertura de las necesidades del cliente, a sus objetivos,
etc., y se decide si se sigue adelante con el proyecto o se lo descarta.
Ahora explicaremos brevemente cada una de estas fases.
Inception
Aqu se establece la idea, especificando una visin del producto final y
su plan de negocio y se define el mbito del proyecto. Esta fase concluye con
el milestone llamado: Evaluacin de los objetivos del ciclo de vida (LCO).
12
Los objetivos principales de la fase de inicio incluyen:
Establecer el mbito y los limites del proyecto de software incluyendo

un concepto operacional, criterios de aceptacin y una descripcin de
lo que pretende ser y no ser parte del producto
Discriminar o discernir los principales y ms crticos casos de uso,
esto es, los principales comportamientos que llevaran a cabo las
funcionalidades del software y que darn forma a la mayor parte de
sistema.
Exhibir o demostrar al menos una arquitectura para algunos de los
escenarios principales.
Estimar la agenda a seguir, y los costos a afrontar a lo largo de todo
el proyecto, como as tambin proveer de estimaciones detalladas
para la fase que sigue, la fase de elaboracin.
Estimar los posibles riesgos, manifestando las posibles fuentes.
Las principales actividades de esta fase son:
Definir el mbito del proyecto, es decir, capturar el contexto y los

requisitos y las restricciones fundamentales para poder generar
criterios de aceptacin del producto final.
Preparar y planificar un caso de negocio y evaluar las alternativas
para el manejo de los posibles riesgos, del staff, del plan de proyecto
y de las actividades teniendo en cuenta el costo, tiempo y
rentabilidad.
Sintetizar una arquitectura candidata, evaluando las actividades de
diseo, analizando la compra/desarrollo/reutilizacin de componentes
a fin de estimar a ciencia cierta los costos, los tiempos y los recursos
a invertir.
Los resultados de esta fase concluyen en la creacin de los siguientes

elementos:
Un documento que enfatice la visin, es decir, una panormica

general de los requisitos fundamentales del proyecto, sus aspectos
claves y las principales restricciones.
Un estudio de los casos de uso, que liste todos los casos de usos y
sus actores que puedan ser identificados en esta etapa temprana.
Un glosario inicial del proyecto.
Un plan de negocio inicial que incluya:
o El contexto del negocio
o Criterios de xito (proyeccin del rdito, reconocimiento del
mercado, etc.).
o Pronostico financiero
Una evaluacin inicial de los riesgos
Un plan de proyecto que muestre las fases y las iteraciones.
13
Un modelo inicial de casos de uso (completo en un 10% a 20%).

Un modelo de dominio, que es ms sofisticado que un glosario.
Un modelo de negocio si fuese necesario.
Una descripcin preliminar de los casos de desarrollo que
especifique los procesos usados.
Milestone LCO:
Los criterios de evaluacin de la fase inicial son:
Los distintos involucrados en el proyecto concuerdan en la definicin

del mbito, y la estimacin de los costos y de la agenda a utilizar.
El entendimiento de los requisitos evidenciados por la fidelidad de los
principales casos de uso.
Credibilidad de las estimaciones de los costos y tiempos, prioridades,
riesgos y procesos de desarrollo.
Profundidad y ancho de cualquier prototipo de arquitectura que fuese
desarrollado.
Gastos actuales vs. gastos planificados.
Si el proyecto no pasa esta etapa de prueba puede ser cancelado o

repensado considerablemente.
Elaboration
En esta etapa se planifican las actividades necesarias y los recursos
requeridos, se especifican las caractersticas y el diseo de la arquitectura.
Esta fase culmina en una etapa de evaluacin llamada: Arquitectura del ciclo
de vida (LCA).
Los principales objetivos de esta fase son:
Definir, validar y referenciar la arquitectura en forma prctica y rpida.

Referenciar (crear una referencia de) la visin.
Referenciar un plan de alta fidelidad para la fase de construccin.
Demostrar que la arquitectura soportara la visin por un costo
razonable en un tiempo razonable.
Las principales actividades son:
Se elabora la visin, esto es, se establecen conocimientos slidos y

completamente articulados de la mayora de los casos de uso crticos
que derivan en la arquitectura y las decisiones sobre planificacin.
Se elaboran los procesos, la infraestructura y el ambiente de
desarrollo y se cuadran los procesos, las herramientas y el soporte
de automatizacin.
14
La arquitectura es elaborada y los componentes seleccionados. Se

evalan los componentes potenciales y las decisiones de
hacer/comprar/reusar son lo suficientemente entendidas como para
determinar los costos de la fase de construccin y la agenda a
utilizar. Los componentes seleccionados de la arquitectura son
integrados y evaluados contra los escenarios primarios. Las
lecciones aprendidas de estas actividades pueden lar lugar al
rediseo de la arquitectura, tomando en consideracin diseos
alternativos o reconsiderando los requisitos.

elementos:
Modelo de casos de usos (al menos completo en un 80%) en el cual

se hayan identificado todos los casos de uso, todos los actores y la
mayora de la descripcin de esos casos de uso haya sido
desarrollada.
Requisitos suplementarios que capturen las necesidades no
funcionales y cualquier requisito que no este asociado con ningn
caso de uso.
Una descripcin de la arquitectura del software.
Un prototipo ejecutable de la arquitectura.
Una lista revisada de los riesgos y una revisin del plan de negocios.
Un plan de desarrollo para todo el proyecto, incluyendo un plan
granular que muestre las iteraciones y los criterios de evaluacin
para cada iteracin.
Un caso de desarrollo actualizado que especifique el proceso a usar.
Un manual preliminar para el usuario (opcional)
Milestone LCA:
Esta etapa de evaluacin requiere las respuestas a las siguientes
preguntas:
La visin del producto, es estable?

La arquitectura, es estable?
La demostracin ejecutable muestra que la mayora de los riesgos
han sido atendidos y creblemente resueltos?
La fase de construccin es lo suficientemente detallada y exacta?
Es respaldada por estimaciones fundamentadas?
Todos los involucrados en el proyecto estn de acuerdo en que la
visin del producto puede ser alcanzada cuando se ponga en marcha
el desarrollo del sistema completo, utilizando la arquitectura actual?
Los gastos actuales son aceptables en relacin con los gastos
propuestos?
15
Si esta evaluacin falla el proyecto puede ser abortado o considerablemente

repensado.
Construction
En esta etapa se construye el producto en si, desarrollando la visin, la
arquitectura y los planes hasta que el producto esta listo para ser entregado a
la comunidad de usuarios. La fase de construccin concluye con la etapa de
evaluacin denominada: Capacidad Inicial de Operacin (IOC).
Los principales objetivos son:
Minimizar los costos de desarrollo optimizando los recursos y

evitando el trabajo innecesario.
Alcanzar una alta calidad tan rpido como sea posible.
Obtener versiones tiles (versiones alpha, beta, etc.) tan rpido como
sea posible.
Las principales actividades desarrolladas en esta etapa son:
Administracin y control de recursos y optimizacin de procesos.

Desarrollo y test completo de los componentes, evalundolos con los
criterios antes definidos.
Evaluacin del producto completo comparndolo con los criterios de
aceptacin definidos por la visin.

elementos:
El producto de software integrado en una plataforma adecuada.

Los manuales para el usuario.
Una descripcin completa de la ltima versin conseguida.
Milestone IOC:
preguntas:
El producto final es lo suficientemente estable y maduro como para

ser instalado e introducido en la comunidad de usuarios?
Todos los involucrados con el producto en la comunidad de usuarios
estn listos para la transicin?
Los gastos actuales siguen siendo aceptables con relacin a los
gastos propuestos?
16
Si esta evaluacin no es satisfactoria, la instalacin e introduccin del

producto en la comunidad de usuarios podr ser retrasada hasta una revisin
del producto.
Transition
En esta etapa el producto es entregado a los usuarios, lo cual incluye
instalacin, entrenamiento, soporte y mantenimiento del producto hasta que los
usuarios estn satisfechos. Esta fase termina en la etapa de evaluacin
denominada: Versin de Producto (PR), la que tambin concluye el ciclo de
desarrollo.
Esta etapa incluye:
Tests betas para comparar el rendimiento y desenvolvimiento del

producto con las expectativas del usuario.
Operacin en forma paralela entre el nuevo sistema desarrollado y el
anterior al cual se lo esta reemplazando.
Conversin de las bases de datos operacionales.
Capacitacin de usuarios y responsables de mantenimiento.
Entrega del producto a los equipos de marketing, distribucin y venta.
Los principales objetivos son:
Lograr que el usuario puede ser un auto-soporte.

Lograr reunir el consenso de todos los involucrados con el producto
en que el mismo esta completo y es consistente con los criterios de
evaluacin propuestos por la visin.
Lograr terminar con el ciclo lo antes posible para un manejo de
costos efectivo.
Las principales actividades son:
Ingeniera de producto final, esto es, instalacin del nuevo sistema

teniendo en cuenta el sobrelapamiento con el sistema viejo, paquete
comercial, produccin, entrega al departamento de venta y
capacitacin de personal.
Refinamiento de actividades incluyendo el arreglo de bugs y
mejoras al sistema para alcanzar niveles mas altos de performance y
utilizacin.
Evaluacin del nivel de instalacin comparndolo con los criterios de
aceptacin provistos por la visin del producto.
Milestone PR:
preguntas:
17
El usuario esta satisfecho?

Los gastos actuales son aceptables en comparacin con los
previstos?
Aspectos Estticos
Un proceso describe quien esta haciendo que, como y cuando. El
proceso racional unificado esta representado por cinco elementos primarios:
1)
2)
3)
4)
5)
Roles: El quien
Activities: El como
Artifacts: el que
Workflows: el cuando
Disciplines: El contenedor de todos los anteriores
Los tres primeros estn representados en la figura 5.
Figura 5. Roles, Activities y Artifacts.
Un ejemplo de Workflow se da en la figura 6.
18
Figura 6. Ejemplo de Workflow.
Roles
El concepto central en el proceso es el rol. Un rol define un
comportamiento y las responsabilidades de un individuo o de un conjunto de
individuos trabajando como un equipo. Este rol esta expresando de acuerdo a
las actividades que realiza y las responsabilidades de este rol son referidas a
elementos que el individuo crea, modifica o controla. Los roles no son ni
individuos, ni ttulos de trabajo, son comportamientos, es decir que un individuo
puede tener mas de un rol en un determinado proceso.
Los roles estn organizados en seis categoras principales. Aqu hay una
lista de los roles en esas categoras.
1. Rol de Analista
a. Analista de procesos de negocio
b. Diseador de negocios
c. Analista de Sistemas
d. Especificador de Requisitos
2. Rol de Desarrollador
3.
4.
5.
6.
19
a. Arquitecto de Software
b. Diseador
c. Diseador de la Interfaz de usuario (UI)
d. Diseador de cpsulas
e. Diseador de base de datos
f. Implementador
g. Integrador
Rol de Evaluador
a. Analista de evaluaciones
b. Diseador de evaluaciones
c. Evaluador
Rol de Administrador
a. Administrador de proyecto
b. Administrador de control de cambios
c. Administrador de configuraciones
d. Administrador de evaluaciones
e. Administrador de despliegue
f. Ingeniero de Procesos
g. Administrador de revisiones
Rol de Produccin y soporte
a. Administrador del sistema
b. Escritor tcnico
c. Artista grafico
d. Especialista de herramientas
e. Desarrollador de cursos
Roles adicionales
a. Revisor
b. Coordinador de revisiones
c. Cualquier otro rol
d. Stakeholder
Activities
Los roles tienen actividades que definen el trabajo que realizan. Una
actividad es una unidad de trabajo realizada por un individuo en un rol
determinado y que produce resultados significativos en el contexto del
proyecto. Las actividades tienen un propsito claro, usualmente creando o
actualizando elementos, como un modelo, una clase, o un plan.
Algunas actividades son:
Planificacin e iteracin, realizadas por el rol: Administrador de

proyecto
Encontrar los casos de uso y los actores, por el Analista de Sistemas
Rever el diseo, realizado por el Revisor de diseo
Ejecutar una evaluacin de performance, por el evaluador de
performance
20
Las actividades se pueden descomponer en una serie de pasos, lo cuales se

pueden agrupar en tres categoras:
1) Pasos de anlisis
2) Pasos de realizacin
3) Pasos de evaluacin
Artifacts
Las actividades utilizan ciertos artifacts1, de entrada, y generan ciertos
otros, de salida. Un artifact es una pieza de informacin que es producida,
modificada o usada por un proceso. Los artifacts son los productos tangibles
del proyecto.
Toman varias formas:
Un modelo, como el modelo de casos de uso o el modelo de diseo

Un elemento de un modelo, como una clase, un caso de uso o un
subsistema
Un documento, como el plan de negocio
Cdigo fuente
Archivos ejecutables
Los artifacts ms habituales de RUP se encuentran en la figura 7.
Figura 7. Artifacts habituales en RUP.

1
La traduccin exacta de Artifact no existe, pero podra interpretarse como elemento, objeto,
etc.
21
Estos son algunos ejemplos de artifacts:
Un modelo de diseo UML guardado en Rational XDE

Un plan de proyecto guardado en Microsoft Project
Una base de datos de los requisitos del proyecto guardado en
Rational Requisite PRO
Los artifacts estn agrupados en conjuntos, segn la categora a la que

pertenezcan. Las categoras son:
Conjunto de Administracin
Conjunto de Requisitos
Conjunto de Diseo
Conjunto de Implementacin
Conjunto de Desarrollo
La evolucin de estos conjuntos a lo largo del proyecto se muestra en la

figura 8.
Figura 8. Evolucin de los conjuntos de elementos.
Workflows
Una simple enumeracin de roles, actividades y elementos no
constituyen un proceso. Necesitamos describir las secuencias principales de
las actividades que producen resultados de valor y muestran las interaccin
entre los roles. Un Workflow es una secuencia de actividades que produce un
resultado de gran valor. Es anlogo, en UML, al diagrama de secuencia, de
colaboracin o de actividad.
22
Existen tres tipos de Workflows:
Core Workflows o Flujos de trabajos centrales asociados a cada

disciplina
Detalles de Workflows, para refinar el Core Workflow
Planes de Iteracin
Disciplines
Los disciplines2 son contenedores usados para organizar las actividades
del proceso. Hay nueve disciplinas principales en RUP y representan una
particin, en grupos lgicos segn las especialidades, de todos los roles y las
actividades. Se dividen en disciplinas tcnicas y de soporte, esto es:
1.
2.
3.
4.
5.
6.
a- Disciplinas tcnicas
Disciplina de modelado de negocios
Disciplina de requisitos
Disciplina de anlisis y diseo
Disciplina de implementacin
Disciplina de evaluacin
Disciplina de despliegue
b- Disciplinas de soporte
7. Disciplina de administracin de proyecto
8. Disciplina de administracin de configuracin y cambio
9. Disciplina de ambientacin
Elementos secundarios
patrones o guas (donde se une UML con RUP)

plantillas
herramientas instructoras
definicin de conceptos
Resumiendo
RUP, o el proceso racional unificado, es un proceso de desarrollo de
software, una metodologa, una recomendacin de cmo crear un software en
forma rpida y eficiente, logrando un producto de gran calidad en la que todos
los involucrados participan, mediante la utilizacin de un ciclo de vida iterativo.
Bsicamente se divide en dos dimensiones.
Traduciremos disciplines como disciplinas, aunque esta ltima no engloba todo el significado
que se pretende.
23
La primera dimensin es esttica donde se ponen en evidencia las

distintas disciplinas del proyecto, que no son ni mas ni menos que un conjunto
de roles, actividades, artifacts y Workflows. Existen diversos roles dependiendo
del comportamiento que se manifieste, actividades que realizan estos roles y
artifacts que consumen y generan en dichas actividades. Todas estas
actividades se relacionan entre si en un Workflow o flujo de trabajo.
La segunda dimensin es dinmica y pone en evidencia las distintas
etapas por las que atraviesa un ciclo de desarrollo de software. Se observan
cuatro etapas, cada una con una seguida de una etapa de evaluacin
pertinente.
La primera etapa, inception phase, es la dedicada a verificar mas que
nada la viabilidad del proyecto, identificando los casos de usos principales,
captando los principales requisitos pedidos por el cliente, elaborando un
cronograma de trabajo completo para generar con todo esto una estimacin de
los costos a enfrentar.
La segunda etapa, elaboration phase, es la dedicada a crear los distintos
modelos, verificar si el proyecto sigue por el rumbo que el cliente quiere,
redefinir el cronograma, y analizar los costos actuales versus los costos
previstos. Esta fase allana todo el camino a la siguiente fase, la de
construccin.
La tercera etapa, construction phase, es la dedicada a crear los distintos
documentos, como as tambin una versin final ejecutable del proyecto.
La cuarta etapa, transition phase, es la etapa de despliegue, lo que
incluye instalacin del producto, evaluacin, capacitacin de los usuarios,
soporte, etc. En esta etapa se captan las posibles mejoras y se replantea otro
ciclo de desarrollo para mejoras o correccin de bugs.
As, RUP queda definido por el siguiente grafico que muestra las dos
dimensiones, la esttica y la dinmica, y muestra el esfuerzo invertido por cada
disciplina en las distintas fases:
24
Algunos pensamientos contrarios a RUP son:
Usted piensa que la fase de inception es lo mismo que la fase donde

se captan los requisitos, la fase de elaboracin es igual a la de
diseo y la fase de construccin igual a la de implementacin (esto
es, superponiendo un ciclo de vida en cascada con RUP).
Usted piensa que la fase de elaboration es una etapa de desarrollo
minucioso de modelos que sern codificados en la etapa de
construccin.
Usted trata de captar la mayora de los requisitos antes de comenzar
con el diseo o la implementacin.
Trata de tener un diseo completo antes de programar.
Invierte un largo tiempo en captar los requisitos y disear antes de
comenzar a programar.
Usted piensa que la duracin de cada iteracin es de
aproximadamente 4 meses y no de 4 semanas (exceptuando
proyectos de ms de 100 personas).
Piensa que los diagramas UML y el diseo deben ser lo mas precisos
posibles y que la programacin es una simple traduccin de estos
diagramas.
Piensa que adoptar RUP significa hacer la mayor cantidad de
actividades y documentos, y piensa que RUP es una gran serie de
pasos a seguir.
25
Lenguaje Unificado de Modelado UML

Introduccin
Hoy en da la programacin de aplicaciones debe manejar la complejidad,
creciente, que nos rodea. Una forma de manejar esta complejidad es a travs
del Diseo Orientado a Objeto (DOO). Este diseo modela el mundo que nos
rodea en un conjunto definido de objetos que poseen propiedades y realizan y
se les pueden realizar acciones. Estos objetos son clasificados o agrupados en
clases que poseen caractersticas generales de los objetos, es decir que los
objetos son instancias de alguna clase. Claro esta que estas clases no estn
aisladas e interactan unas con otras de una determinada manera. Esto
conduce a que los objetos estn relacionados y se comuniquen entre ellos a
travs de mensajes. Esta interrelacin de clases conforma una estructura bien
definida que puede tornarse compleja de manejar si no se utilizan diagramas
pertinentes que simplifiquen y estandaricen un proceso de negocio.
Dentro de las fases de desarrollo de un sistema, la etapa de recopilacin de
informacin, anlisis del dominio, diagramacin son fundamentales para captar
adecuadamente las necesidades del cliente, satisfacer las expectativas del
usuario y facilitar la tarea de los programadores.
UML (Unified Modeling Language), provee un lenguaje estndar que permite
construir un conjunto de diagramas que modelan un sistema orientado a
objetos. Estos diagramas son:
Diagramas de actividades
Diagramas de clases
Diagramas de distribucin
Diagramas de paquetes
Diagramas de caso de uso
Diagramas de componentes
Diagramas de secuencias
Diagramas de colaboraciones
Diagramas de objetos
Diagramas de estado
26
Diagrama de actividades
Principales elementos:
Inicio de diagrama
Fin de diagrama
Bifurcacin del flujo
Envo y recepcin de
indicaciones
Actividades concurrentes
Este diagrama tiene como funcin mostrar las actividades realizadas en

un proceso de negocio determinado a fin dar una imagen global del proceso e
27
incorporar trminos propios del dominio. Se lo utiliza como una primera medida
y generalmente es deducido de entrevistas realizadas con los distintos
destinatarios del sistema.
Diagrama de clases
Principales componentes:
Clase
Clase con
responsabilidades
explicitas
28
Clase con
restricciones
explicitas
Nota relacionada
a una clase
Asociacin entre
dos clases (sin
incluir la
multiplicidad)
Asociacin
tripartita
29
Herencia de
clases: La
subclase hereda
atributo y
acciones de la
superclase y
agrega las suyas
propias
Dependencia de
uso: La clase
dependiente usa
la clase de
dependencia
Agregacin: La
clase total esta
compuesta por
sus clases partes,
que son no
exclusivas de su
clase total.
Composicin: La
clase total esta
compuesta por
todas sus clases
partes que son
exclusivas de su
clase total
30
Interfaz: Una
clase utiliza un
conjunto de
operaciones que
se relacionan con
ella
Clase abstracta:
es una clase que
no contiene
instancias
Clase
parametrizada: es
una clase
utilizada para
crear clases.
El diagrama de clases es el diagrama fundamental de UML. En el se

muestran las distintas clases y sus interrelaciones, de modo de aproximar el
modelo a la realidad. Se deriva a partir de las entrevistas, de donde se extraen
sustantivos, adjetivos y verbos de tal forma que:
Sustantivos Clases
Adjetivos Atributos
Verbos Relaciones
De la lista de sustantivos hay que sacar aquellos sustantivos que son
atributos, aquellos que son sinnimos entre si y los que representes clases
fuera del dominio tratado. Por otro lado se pueden agregar clases extras segn
el criterio del modelador.
En cuanto a las relaciones, primero se establecen las relaciones de
asociacin entre las distintas clases involucradas, luego se especifican las
etiquetas de esas relaciones (acciones) y por ultimo la multiplicidad. Se utilizan
relaciones tripartitas o mltiples (mas de tres) cuando dos o mas clases se
interrelacionan. Despus se determina que clases son componentes de otras, y
se forma un diagrama utilizando relaciones de agregacin. De ah llenamos las
clases con sus atributos y acciones.
Este diagrama se ira depurando a medida que se realicen nuevas
entrevistas.
31
Diagrama de distribucin
Nodo
Nodo con informacin extra
Nota aclaratoria
Relacin de comunicacin entre

nodos
Este diagrama es el ms orientado al hardware interviniente en el

sistema a desarrollar. Una vez creado el diagrama de clases, se puede
determinar en forma preliminar que tecnologa se utilizara y como se relacionan
los distintos dispositivos involucrados.
32
Diagrama de paquetes funcionales

Componentes principales:
Paquete funcional
Caso de uso funcional
Este diagrama no es parte de la especificacin propia de UML, sino que

el paquete es un elemento de extensin de UML, pero puede considerrselo en
el anlisis ya que resume las principales funcionalidades de un sistema. Una de
las formas de describir un sistema es a travs de las tareas que los distintos
roles realizan. Cada tarea ser un caso de uso a considerar, y este diagrama
agrupa todos los casos de uso en paquetes funcionales. Se deduce desde las
entrevistas.
Diagramas de caso de uso

Actor: Quien inicia el caso de uso

o quien es el beneficiario del
caso de uso
Caso de uso: Conjunto de

escenarios que determinan una
tarea
Relacin de inclusin: Un caso
de uso incluye a otro
Relacin de extensin: Un caso
de uso es una extensin de otro
33
Herencia de casos de usos: Un
caso de uso hereda el sentido y
comportamiento de otro caso de
uso
Herencia de actores: un actor

hereda el sentido y
comportamiento de otro actor
Este diagrama se deriva del diagrama de paquetes, con ayuda de los

usuarios correspondientes del sistema. Muestra en forma detallada como se
desarrolla cada tarea, mostrando los escenarios que esas tareas incluyen y los
pasos necesarios para llevar a cabo cada escenario. UML es orientado a casos
de usos, porque de aqu se desprende el diagrama de componentes y el
diagrama de secuencias que facilitarn la tarea a los programadores, como as
tambin la interfaz de usuario y el diagrama de distribucin que da una idea de
la distribucin fsica (hardware) a utilizar.
En un diagrama de caso de uso se especifican:
Descripcin breve del caso de uso

Conjeturas o Suposiciones (derivaran en componentes de software)
Condiciones previas (como era antes)
Condiciones resultantes (como ser despus)
Pasos
Actor iniciante
Actor beneficiado
Cada caso de uso es tratado en forma independiente en una nueva hoja.
34
Diagrama de componentes
Componente de software
Interfaz de un componente de
software
Dependencia entre
componentes
Este diagrama es de gran ayuda para los programadores. En el se

detallan todos los componentes de software como ser: bases de datos, tablas,
documentos, archivos, ejecutables, etc., y muestra la relacin existente entre
ellos. Tambin muestra en nombre de la interfaz que interactuar con este
componente.
Diagrama de secuencia
Nombre del de los objetos
(componentes del caso de
uso), lnea de vida del
objeto y activacin (tiempo
que tarda en realizar la
actividad)
Relaciones de paso de
mensajes entre objetos.
Simple: Transferencia del
control de un objeto a otro.
Sincrnico: espera la
respuesta al mensaje antes
de continuar.
Asincrnico: No espera una
respuesta antes de
continuar.
35
Actor: es el que inicia el

caso de uso al que
describe el diagrama de
secuencias.
Estado: Se puede incluir el

smbolo de estado para
mostrar el cambio de un
estado en relacin con el
tiempo.
Este diagrama muestra la interaccin entre los objetos en relacin con el

tiempo, es decir describe temporalmente un caso de uso. Es de gran utilidad
para saber en que momento un objeto se activa y bajo que circunstancias lo
hace.
36
Diagrama de estados
Este diagrama es utilizado para mostrar los distintos estados en los que
puede encontrarse un sistema, las propiedades de ese estado, sus eventos
asociados y las transiciones que conducen a estos estados.
37
Diagrama de colaboraciones
Este diagrama es una mezcla del diagrama de objetos con el diagrama

de secuencias. Se muestran las relaciones entre los objetos y la secuencia en
que estas interacciones se dan. Se define tambin el diagrama de colaboracin
parametrizada que es un diagrama utilizado para crear diagramas de
colaboracin especficos.
38
Diagrama de objetos
Principal componente:
El diagrama de objetos es una especificacin o instanciacin de un

diagrama de clases. Se reemplazan las clases por los objetos determinados.
39
Microsoft Visio 2003 for Enterprise Architects

Aunque Visio naci oficialmente en Noviembre de 1992, realmente
comenz a gestarse desde 1984. Fue creado por un equipo de desarrolladores
pertenecientes a Shapeware Corporation. Rpidamente alcanz popularidad y
fue una de las aplicaciones mas utilizadas para la generacin de diagramas de
distinta ndole. Ya en el ao 1999 contaba con un equipo de alrededor de 600
personas. En el ao 2000 Microsoft advirti el gran uso de Visio y lo adquiri
por la mdica suma de 1.5 Billones de dlares. Esta compra promocion an
ms el producto. En el ao 2003 comenz a integrar el paquete Office de
Microsoft3.
Fundamentalmente, Visio es un paquete de diagramas. Cuando muchos
usuarios de software escuchan el nombre Visio automticamente piensan en
diagramas. Esto es comprensible ya que Visio se define como un software para
la creacin de diagramas de negocios y otros similares. Los desarrolladores de
Visio, inteligentemente, expandieron el alcance de los diagramas incluyendo
diagramas para dominios o industrias especficas y, en particular, los dibujos y
diagramas de las tareas que ocurren dentro de estas industrias. Por ejemplo,
Visio puede crear un diagrama de un sitio web completo trazando los
hipervnculos desde una pgina a otra cuando uno le pasa como informacin la
pgina principal. Tambin puede generar un diagrama de base de datos a partir
de las tablas de una base de datos existente. Incluye adems herramientas
para trazar la jerarqua empresarial de las corporaciones y planos
arquitectnicos. Soporta automatizacin, dando a los desarrolladores COM la
posibilidad de incluir diagramas dentro de sus aplicaciones. El punto es que
Visio es una aplicacin poderosa que ha encontrado diversos usos en una
variedad de lugares. Visio no solo ofrece soporte para diagramas UML, sino
que tambin soporta otros diagramas orientados al software como por ejemplo
interfaces de usuario de Windows, COM, diagramas OLE y diagramas de flujo
de datos.
Para concluir con esta breve descripcin, Visio 2003 for Enterprise
Architects tiene la capacidad de generar cdigo fuente en los lenguajes Visual
Basic, C# y C++ a partir de los diagramas de UML4.
Diagramas UML en Microsoft Visio

Microsoft Visio cuenta con una librera de herramientas (Stencil) para
cada rea. Dentro del rea de Software encontramos, entre otros, el Stencil de
UML.
Para mas informacin referirse a: http://www.mvps.org/visio/History.htm

Existe bibliografa que explica el manejo en si de Microsoft Visio. [BB03], [FLMSSC02],
[MIC03].
4
40
Figura 9 Pantalla Inicial del Stencil de UML en Visio
Como vemos en la figura 9, en la parte izquierda del rea de trabajo se

encuentran ordenados los distintos elementos de UML segn los diagramas. A
continuacin se muestran todos los elementos posibles para UML en Visio:
41
42
Figura 10 Todos los elementos UML que posee Visio
En la figura 9 tambin se pueden apreciar dos ventanas ms: el

explorador del modelo y la ventana de salida (output). El primero muestra la
estructura, el esqueleto del modelo, mientras que la segunda muestra los
errores que se encuentran en el modelado.
Los distintos diagramas se realizan arrastrando el elemento que
corresponda al rea de trabajo. UML permite utilizar elementos de un diagrama
en otro, por lo que Visio permite realizar esta tarea tambin.
Captulo III: Procedimientos de desarrollo
43
CAPTULO III
Procedimientos de desarrollo
Captura de los requisitos funcionales del sistema

El primer paso en el desarrollo de un sistema es la captura de los
requisitos funcionales del sistema a partir de entrevistas con el cliente y los
futuros usuarios del mismo. La idea no es solo saber que va a hacer el sistema,
sino como le gustara a los usuarios que este se presentase.
Se debe elaborar un itinerario de entrevistas, elaborando un bosquejo de
las preguntas a realizar. En la primera entrevista se determinara el objetivo del
sistema y se planificaran las siguientes entrevistas de acuerdo a los temas
discutidos.
Si un tema es demasiado complejo o extenso se lo trata en una
entrevista aparte con la persona que ms entienda en dicho tema. Durante las
entrevistas es til realizar un alto y resumir, a fin de que el cliente vea si los
analistas estn entendiendo el tema.
En definitiva, la entrevista trata de sacar todos los requerimientos del
cliente, para describir en forma funcional y no funcional todo el sistema.
Es til y aconsejable realizar un diccionario de trminos del dominio
analizado, a fin de estandarizar un lenguaje comn.
Una vez captados los requisitos a travs de las entrevistas, se proceder
a la realizacin de la Especificacin de Requisitos de acuerdo a la IEEE 8305.
La estructura de esta especificacin se detalla en el Anexo I.
Diagrama de actividades
Una vez realizadas la entrevistas se proceder al desarrollo de los
correspondientes diagramas de actividades, que muestran en forma general la
secuencia de los procesos en un sistema, como as tambin las
responsabilidades de los distintos roles.
Es aconsejable que este diagrama se realice simultneamente con las
entrevistas de forma que sea el mismo cliente el que pueda determinar si el
diagrama es correcto o no y, adems, sirva como gua para una entrevista
estructurada.
5
El IEEE 830 fue desarrollado por el Instituto de Ingenieros Elctricos y Electrnicos en el ao

1998 para estandarizar la especificacin de requisitos en desarrollo de sistemas.
44
Si el diagrama fuese desarrollado en simultneo con las entrevistas, se

aconseja hacerlo sobre una pizarra, de forma que todos puedan seguir la
secuencia de las actividades desarrolladas en los distintos procesos.
Primeros casos de uso

En este momento del diseo se establecen, de acuerdo a las entrevistas,
los primeros casos de uso que darn las pautas generales del sistema, de
acuerdo a las caractersticas generales captadas en las entrevistas. El Proceso
Unificado es una metodologa basada en casos de uso y es por ello que este el
diagrama ms importante.
Diagrama de clases preliminar

Aqu el analista realizar una primera aproximacin al diagrama de
clases del sistema. Para ello se analizarn las entrevistas, listando sustantivos,
verbos y construcciones verbales. Algunos de los sustantivos se convertirn en
clases dentro del modelo, y algunos otros en atributos. Los verbos y
construcciones verbales podrn convertirse en operaciones o las etiquetas de
asociaciones. Para ello es til realizar una lista con todos los sustantivos,
verbos y construcciones verbales y de all comenzar el anlisis. Se descartan,
primeramente, los sustantivos que sean sinnimos de otros, y luego se
separan los sustantivos que sean atributos y no clases. De esta forma
quedaran bien diferenciados los sustantivos candidatos a ser clases y que se
plasmaran en un modelo inicial. Se agregaran las clases que se consideren
necesarias y que no hayan sido listadas.
Luego, se agrupan las clases segn los distintos procesos,
determinando las clases abstractas y las subclases que se relacionaran a esta
a travs de la generalizacin.
Una vez agrupadas las clases, se determinan las asociaciones simples y
mltiples, as como sus multiplicidades, de acuerdo a los verbos o frases
verbales que correspondan.
Por ltimo, se tratar clase por clase, determinando los atributos y las
operaciones que la clase realiza o permite que se realice sobre ella.
A medida que se avance sobre el modelo, es posible que sean
necesarias entrevistas adicionales para resolver puntos problemticos o
difusos.
45
Plataforma Preliminar
Una vez establecido un modelo de clases preliminar, podemos
establecer una primera idea de la plataforma de hardware a utilizar mediante el
diagrama de distribucin. Se tendr en cuenta tecnologa existente, nueva y
limitaciones establecidas al hardware.
Descripcin de paquetes de funcionalidad

Se intenta mediante este diagrama reunir las funcionalidades en
paquetes UML. Dentro de un paquete UML se mencionarn los casos de usos
concernientes a un proceso del sistema. De esta forma se logra un avance
importante hacia el desarrollo del diagrama de casos de uso definitivo.
Diagrama de casos de uso

Recordemos que cada caso de uso es una coleccin de situaciones y
cada una de stas es una secuencia de pasos. Para cada escenario en cada
caso de uso queremos mostrar:
Una breve descripcin del escenario

Conjeturas del escenario
El actor que inicia el caso de uso
Condiciones previas para el caso de uso
Pasos relacionados con el sistema en el escenario
Condiciones resultantes una vez finalizado el escenario
El actor beneficiado del caso de uso
Cada caso de uso ser expuesto, segn lo anterior, en hojas por

separado.
Es fundamental desarrollar los casos de usos con los usuarios del
sistema, y en especial desarrollar bien los Pasos relacionados con el sistema,
ya que mostrarn la forma en la que este funcionar.
Es importante especificar claramente las conjeturas que se adopten en
cada caso de uso.
Al finalizar esta etapa se tendrn los diagramas de casos de uso que
den soporte a las funcionalidades del sistema y es muy posible que a partir de
aqu se deba modificar el diagrama de clases.
46
Diagramas de secuencias
Ahora por cada caso de uso se realizar un diagrama de secuencias
donde se deje claramente especificada la secuencia (temporal) en la que se
desarrollaran las actividades involucradas en cada caso de uso. Si es
necesario se reformar el diagrama de clases.
Diagramas de distribucin y de componentes

Una vez establecidas y descriptas todas las funcionalidades del sistema,
mediante los casos de uso, el orden de las actividades, mediante el diagrama
de secuencias, y el total de las clases intervinientes, se podr proceder a
realizar el diagrama de componentes de software que evidenciar la interaccin
entre los distintos mdulos a desarrollar.
Asimismo, se realizar el diagrama de distribucin completo que
mostrar los recursos de hardware necesarios para poder poner en
funcionamiento el sistema a desarrollar. Recursos locales y remotos, redes,
computadoras, elementos de red, etc, sern mencionados en este diagrama.
Diagramas adicionales
Los restantes diagramas (de estado, de objetos y de colaboraciones), asi
como cualquier otro mtodo (como por ejemplo fichas CRC), pueden ser
utilizados. UML no es un lenguaje cerrado, solo establece pautas, herramientas
que sern usadas por cada desarrollador segn l considere necesario.
Anexo I: Especificacin de requisitos
47
Anexo I
Especificacin de requisitos
Estructura Bsica6
Anlisis de Requisitos del Sistema
1.
2.
3.
Identificacin de los usuarios participantes

Planificacin y realizacin de entrevistas
Catlogo de Requisitos del Sistema
3.1.
Objetivos y alcance del sistema
3.2.
Definiciones, acrnimos y abreviaturas
3.3.
Descripcin general
3.4.
Requisitos funcionales
3.5.
Requisitos de usuario y tecnolgicos
3.6.
Requisitos de interfaces externas
3.7.
Requisitos de rendimiento
3.8.
Requisitos de desarrollo y restricciones de diseo
Desarrollo resumido
Anlisis de Requisitos del Sistema
Este mdulo tiene como objetivo analizar y documentar las necesidades
funcionales que debern ser soportadas por el sistema a desarrollar. Para ello,
se identificarn los requisitos que ha de satisfacer el nuevo sistema mediante
entrevistas, el estudio de los problemas de las unidades afectadas y sus
necesidades actuales. Adems de identificar los requisitos se debern
establecer las prioridades, lo cual proporciona un punto de referencia para
validar el sistema final que compruebe que se ajusta a las necesidades del
usuario.
1. Identificacin de los usuarios participantes
Los objetivos de esta tarea son identificar a los responsables de cada
una de las unidades implicadas y a los principales usuarios implicados. Para
ello se consideran los siguientes aspectos:
Incorporacin de usuarios al equipo de proyecto.
Un detalle completo se puede encontrar en el documento elaborado por el IEEE (IEEE 830)
que se encuentra en el departamento de Sistemas [IEEE830].
48
Conocimiento de los usuarios de las funciones a automatizar.

Repercusin del nuevo sistema sobre las actividades actuales de los
usuarios.
Implicaciones legales del nuevo sistema
Es de destacar la necesidad de una participacin activa de los usuarios del

futuro sistema en las actividades de desarrollo del mismo, con objeto de
conseguir la mxima adecuacin del sistema a sus necesidades y facilitar el
conocimiento paulatino de dicho sistema, permitiendo una rpida implantacin.
2. Planificacin y Realizacin de Entrevistas. Estudio de Documentacin.
Esta tarea tiene como finalidad capturar los requisitos de usuarios para
el desarrollo del sistema. La entrevista consiste en una interaccin sistemtica
con un usuario para extraer los conocimientos de ste. Se deben realizar
entrevistas de tipo abierta y estructurada. En una entrevista abierta se plantean
preguntas ms o menos espontneas al usuario, mientras que en una
entrevista estructurada se planifican las preguntas que se deben plantear al
usuario durante la sesin. El proceso comprende:
Planificar las entrevistas a realizar: en la planificacin se incluir fecha,

hora y lugar de la entrevista, duracin estimada y guin de la entrevista.
Realizar las entrevistas y documentarlas debidamente.
Documentar los requisitos identificados con sus prioridades.
A partir de las entrevistas realizadas con los responsables y usuarios, se
identifican los requisitos que debe cumplir el sistema y se establecer
una prioridad para los mismos, de acuerdo a las necesidades
expresadas por los usuarios y a los objetivos a cubrir por el nuevo
sistema.
El estudio de la documentacin consiste en la educcin de requisitos de

los documentos e impresos que forman parte del sistema actual.
3. Catlogo de Requisitos del Sistema
El objetivo de la especificacin es definir en forma clara, precisa,
completa y verificable todas las funcionalidades y restricciones del sistema que
se desea construir. Esta documentacin est sujeta a revisiones por el grupo
de usuarios que se recogern por medio de sucesivas versiones del
documento, hasta alcanzar su aprobacin por parte del grupo de usuarios. Una
vez aprobado, servir de base al equipo de desarrollo para la construccin del
nuevo sistema.
49
3.1. Objetivos y alcance del sistema

En esta etapa se detallan los objetivos del sistema, describiendo
brevemente QU es lo que el sistema debe hacer. En el alcance del sistema se
describe en lenguaje natural el mbito del sistema, su dominio y sus lmites.
3.2. Definiciones, acrnimos y abreviaturas

Esta etapa tiene como fin establecer el vocabulario de trminos que
forman parte del sistema, de manera que TODOS los participantes "hablen el
mismo idioma".
3.3. Descripcin general
Esta seccin nos presenta una descripcin general a grandes rasgos del
sistema con el fin de conocer las principales funciones que debe soportar, los
datos asociados, las restricciones impuestas y cualquier otro factor que pueda
influir en la construccin del mismo. Una buena manera de realizar la
descripcin es plantearla con un enfoque descendente; es decir, a nivel
subsistemas, detallando las funciones por debajo de los mismos.
3.4. Requisitos funcionales
Descripcin en lenguaje natural de las funciones desglosadas en la
etapa anterior, detallando las entradas, las salidas y la descripcin del proceso
desde el punto de vista del usuario. Las descripciones de entradas y salidas
deben ser en lo posible grficas, o bien los documentos que se usan
corrientemente.
3.5. Requisitos de usuario y tecnolgicos
Requisitos de usuario: debe describirse el nivel de conocimiento de cada
usuario (novato, intermedio, experto) para la realizacin de interfaces,
manuales de usuario, ayuda y capacitacin de los mismos.
Requisitos tecnolgicos: se describen las necesidades desde el punto de
vista tecnolgico, es decir equipos de clientes y servidores, velocidades de
transmisin de datos, caractersticas que debe tener el sistema operativo y el
sistema gestor de base de datos, y cualquier equipo que forma parte del
sistema. Este documento es solamente un conjunto de criterios que me permite
luego elegir el software y hardware adecuado para el sistema.
50
3.6. Requisitos de interfaces externas

En esta etapa se capturan los requerimientos que describen cmo debe
ser la comunicacin del sistema con el usuario y el mundo exterior. Se deben
capturar las interfaces con el usuario, interfaces hardware, interfaces software
e interfaces de comunicacin.
3.7. Requisitos de rendimiento
Pretende definir una serie de parmetros MENSURABLES del sistema
que imponen restricciones sobre el mismo. Generalmente estn asociados a
tiempos de respuesta, tiempos de espera y duracin de tareas batch. Estos
requerimientos son muy importantes ya que la no-satisfaccin de los mismos
implica un fracaso del sistema, por lo que deben tener una prioridad alta.
3.8. Requisitos de desarrollo y restricciones de diseo
Requisitos de desarrollo: se definen los requerimientos planteados por el
equipo de trabajo: qu metodologa se seguir, qu ciclo de vida, qu
herramientas se utilizarn, etc.
Restricciones de diseo: son requisitos que nos impone la naturaleza del
dominio del problema. Estos son: ajuste a estndares (por ejemplo una
determinada manera de codificar un dato), limitaciones hardware (por los
equipos disponibles), seguridad (por los distintos niveles de acceso a la
informacin que deben tener los usuarios), mantenimiento (se debe tener en
cuenta la ampliacin del sistema), adaptacin al entorno y polticas de borrado.
Bibliografa
51
Bibliografa
[BJR99] - James Rumbaugh, Ivar Jacobson, Grady Booch . 1999. The Unified
Modeling Language Reference Manual. Addison-Wesley.
[PK03] - Philippe Kruchten. 2003. The Rational Unified Process An Introduction.
Third Edition. Addison-Wesley.
[CL02] - Craig Larman. 2002. Applying UML and Patterns. Second Edition.
Prentice Hall.
[FLMSSC02] - Andrew Filev, Tony Loton, Kevin McNeish, Ben Schoellmann,
John Slater, Chaur Wu. 2002. Professional UML with Visual Studio .NET.
Unmasking Visio for Enterprise Architects. Wrox Press Ltd.
[BJR00] - Ivar Jacobson, Grady Booch, James Rumbaugh. 2000. El Proceso
Unificado de Desarrollo de Software. Pearson Addison Wesley.
[JS02] - Joseph Schmuller. 2002. Sams Teach Yourself UML in 24 Hours.
Second Edition. Sams Publishing.
[BB03] - Bonnie Biafore. 2003. Visio 2003 Bible. Wiley Publishing, Inc.
[MIC03] - Microsoft Corporation. 2003. Gua del usuario de Microsoft Office
Visio 2003. Microsoft Press.
[IEEE830] - IEEE (Institute of Electrical and Electronic Engineers). 1998. IEEE
Recommended Practice for Software Requirements Specifications.

Manual de Procedimientos de Desarrollo de Sistemas Mediante Proceso Unificado

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Manual de Procedimientos de Desarrollo de Sistemas Mediante Proceso Unificado

Uploaded by

Copyright:

Available Formats

MANUAL DE PROCEDIMIENTOS

DISEO Y MODELADO DE SISTEMAS BASADOS EN EL

Gustavo Federico Agostini

3.4. Requisitos funcionales ........................................................................................ 49

Captulo I: introduce un marco terico, donde se deja en evidencia la

Captulo I: Marco Terico Introduccin

Un sistema de software surge como solucin a la necesidad de alguien

Captulo I: Marco Terico Introduccin

Figura 1 Breve historia del Proceso Unificado y de UML

Por qu es necesario UML? Simplemente porque no existe un estndar

Captulo II: Marco Terico Desarrollo

en cascada (waterfall) o secuencial

El principal objetivo de un desarrollo de software como ya vimos es

Captulo II: Marco Terico Desarrollo

Figura 2. Ciclo de Vida Iterativo

Podemos mencionar algunas de las ventajas de usar un ciclo de vida iterativo:

Enfrenta anticipadamente los problemas de alto riesgo (tcnicos, de

Captulo II: Marco Terico Desarrollo

Figura 3. Relacin entre un ciclo de vida en cascada y uno iterativo

El Proceso Unificado (UP) o el Proceso Racional Unificado (RUP) es un

ciclo de vida iterativo y evolutivo

RUP se divide en dos dimensiones o dos aspectos:

Captulo II: Marco Terico Desarrollo

En cada una de estas etapas se realizan las iteraciones. La figura 4

Figura 4. Ciclo de desarrollo en RUP

Cada fase o etapa viene seguida de una pequea etapa de evaluacin y

Captulo II: Marco Terico Desarrollo

Los objetivos principales de la fase de inicio incluyen:

Establecer el mbito y los limites del proyecto de software incluyendo

Las principales actividades de esta fase son:

Definir el mbito del proyecto, es decir, capturar el contexto y los

Los resultados de esta fase concluyen en la creacin de los siguientes

Un documento que enfatice la visin, es decir, una panormica

Captulo II: Marco Terico Desarrollo

Un modelo inicial de casos de uso (completo en un 10% a 20%).

Los distintos involucrados en el proyecto concuerdan en la definicin

Si el proyecto no pasa esta etapa de prueba puede ser cancelado o

Definir, validar y referenciar la arquitectura en forma prctica y rpida.

Las principales actividades son:

Se elabora la visin, esto es, se establecen conocimientos slidos y

Captulo II: Marco Terico Desarrollo

La arquitectura es elaborada y los componentes seleccionados. Se

Los resultados de esta fase concluyen en la creacin de los siguientes

Modelo de casos de usos (al menos completo en un 80%) en el cual

La visin del producto, es estable?

Captulo II: Marco Terico Desarrollo

Si esta evaluacin falla el proyecto puede ser abortado o considerablemente

Minimizar los costos de desarrollo optimizando los recursos y

Las principales actividades desarrolladas en esta etapa son:

Administracin y control de recursos y optimizacin de procesos.

Los resultados de esta fase concluyen en la creacin de los siguientes

El producto de software integrado en una plataforma adecuada.

El producto final es lo suficientemente estable y maduro como para

Captulo II: Marco Terico Desarrollo

Si esta evaluacin no es satisfactoria, la instalacin e introduccin del

Tests betas para comparar el rendimiento y desenvolvimiento del

Los principales objetivos son:

Lograr que el usuario puede ser un auto-soporte.

Las principales actividades son:

Ingeniera de producto final, esto es, instalacin del nuevo sistema

Captulo II: Marco Terico Desarrollo

El usuario esta satisfecho?

Los tres primeros estn representados en la figura 5.