Rational Unified Process (Rup)

INDICE
INDICE ………………………………………………………… 1
INTRODUCCION ……………………………………………. 4
CAPITULO 1
METODOLOGÌAS MODERNAS PARA EL DESARROLLO DE SOFTWARE
SPI (Software Process Improvement) …………………………… 7

SPS (Software Process Personal) ................................................... 15
UML (Unified Modelling Language) ............................................ 16
Cascada Iterativa ………………………………………………... 18
CAPITULO 2
RATIONAL UNIFIED PROCESS (RUP) CONCEPTOS Y FILOSOFÌA
Generalidades ……………………………………………………. 21
El desarrollo Iterativo …………………………………………… 22
Ingeniería de Requerimientos …………………………………... 23
Iteraciones RUP ………………………………………………… 28
Arquitectura de Componentes ………………………………….. 29
La Calidad del Software ………………………………………… 29
CAPITULO 3
AL INTERIOR DE RATIONAL UNIFIED PROCESS (RUP) ESQUEMA

DETALLADO
Dimensiones del RUP …………………………………………... 33

Fase de Concepción …………………………………………….. 35
Fase de Elaboración …………………………………………….. 35
Fase de Construcción …………………………………………… 36
1
Fase de Transición …………………………………………… 36
Work Flows …………………………………………………. 36
Modelamiento del Negocio ………………………………….. 39
Ampliación de Requerimientos …………………………….. 40
Análisis Preliminar ………………………………………….. 40
Análisis Detallado …………………………………………… 41
Revisión de Requisitos ……………………………………… 41
Especificaciones …………………………………………….. 42
Diseño Arquitectónico ……………………………………… 43
Casos de Uso ……………………………………………….. 43
Diagrama de Clases ………………………………………… 47
Diagrama de Objetos ……………………………………….. 52
Diagrama de Comportamiento ……………………………… 53
Diagrama de Interacción ……………………………………. 62
Diagrama de Implementación ……………………………… 66
Entidad /Relación …………………………………………... 70
Normalización ……………………………………………… 77
Interfaces de Entrada /Salida ………………………………. 90
Construcción Base de Datos ……………………………… 94
Objetos de Base de Datos ………………………………….. 96
Prueba de objetos ………………………………………….. 97
Entrega de Proyectos ……………………………………… 107
WorkFlow de Colaboración ………………………………. 107
Configuración y Administración de Cambios ……………. 108
Administración del Proyecto ……………………………… 109
Medioambiente …………………………………………… 109
CAPITULO 4
DESCRIPCION DE CASOS DE ESTUDIO USANDO RUP
Plan de Desarrollo de Software ……………………………… 110

Detalle del modelo ……………………………………………. 136
Análisis de Resultados ……………………………………….. 144
2
CONCLUSIONES .................................................................. 149
RECOMENDACIONES ……………………………………. 150
BIBLIOGRAFIA ……………………………………………. 151
3
INTRODUCCIÓN
El Proceso Racional Unificado o RUP (Rational Unified Process), es un proceso
de desarrollo de software y junto con el Lenguaje Unificado de Modelado UML,
constituye la metodología estándar más utilizada para el análisis, implementación
y documentación de sistemas orientados a objetos. RUP es en realidad un
refinamiento realizado por Rational Software del más genérico Proceso Unificado.
Sus principales características son:
 Forma disciplinada de asignar tareas y responsabilidades (quién hace qué,
cuándo y cómo)
 Pretende implementar las mejores prácticas en Ingeniería de Software
como:
 Desarrollo iterativo
 Administración de requisitos
 Uso de arquitectura basada en componentes
 Control de cambios
 Modelado visual del software
 Verificación de la calidad del software
El RUP es un producto de Rational (IBM). Se caracteriza por ser iterativo e
incremental, estar centrado en la arquitectura y guiado por los casos de uso.
Incluye artefactos (que son los productos tangibles del proceso como por ejemplo,
el modelo de casos de uso, el código fuente, etc.) y roles (papel que desempeña
4
una persona en un determinado momento, una persona puede desempeñar
distintos roles a lo largo del proceso).
El RUP divide el proceso de desarrollo en ciclos, teniendo un producto final al
terminar cada ciclo, cada uno de estos se divide en fases que finalizan con un
hito donde se debe tomar una decisión importante:
 Inicio se hace un plan de fases, se identifican los principales casos de uso
y se identifican los riesgos
 Elaboración: se hace un plan de proyecto, se completan los casos de uso y
se eliminan los riesgos
 Construcción: se concentra en la elaboración de un producto totalmente
operativo y eficiente y el manual de usuario
 Transición: se implementa el producto en el cliente y se entrena a los
usuarios. Como consecuencia de esto suelen surgir nuevos requisitos a ser
analizados.
En el capitulo 1 abordaré el tema de las nuevas metodologías para el desarrollo de
software, las mismas que garantizan un excelente producto, reducción de tiempo y
costos.
En el capitulo 2 describo de una manera breve las características, conceptos y
filosofía del RUP, es decir lo más general del esta metodología.
En el capitulo 3 detallo las dimensiones y fases del RUP, la utilización de
Lenguaje de Modelado Unificado, y sobre Wolkflows o grupos de trabajo.
5
CAPITULO 1
METODOLOGÌAS MODERNAS PARA EL DESARROLLO DE
SOFTWARE
Métodos con Orientación a los Objetos
SPI (Software Process Improvement)
SPS (Personal Software Process)
UML (Unified Modelling Language)
Cascada iterativa
1. Metodologías Modernas para el Desarrollo de Software
1.1. Métodos con Orientación a los Objetos (OO)
Hoy en día la tecnología orientada a objetos ya no se aplica solamente a
los lenguajes de programación, además se viene aplicando en el análisis y
diseño con mucho éxito, al igual que en las bases de datos. Es que para
hacer una buena programación orientada a objetos hay que desarrollar
todo el sistema aplicando esta tecnología, de ahí la importancia del
análisis y el diseño orientado a objetos.
La programación orientada a objetos es una de las formas más populares
de programar y viene teniendo gran acogida en el desarrollo de proyectos
de software desde los últimos años.
6
Para el desarrollo de software orientado a objetos no basta usar un
lenguaje orientado a objetos, también se necesitará realizar un análisis y
diseño orientado a objetos.
El modelamiento visual es la clave para realizar el análisis orientado a
objetos (OO). Desde los inicios del desarrollo de software OO han
existido diferentes metodologías para hacer esto del modelamiento, pero
sin lugar a duda, el Lenguaje de Modelamiento Unificado (UML) puso fin
a la guerra de metodologías.
Según los mismos diseñadores del lenguaje UML, éste tiene como fin
modelar cualquier tipo de sistemas (no solamente de software) usando los
conceptos de la orientación a objetos; además este lenguaje debe ser
entendible para los humanos y máquinas.
El UML consta de todos los elementos y diagramas que permiten modelar
los sistemas en base al paradigma orientado a objetos. Los modelos
orientados a objetos cuando se construyen en forma correcta, son fáciles
de comunicar, cambiar, expandir, validar y verificar. Este modelamiento
en UML es flexible al cambio y permite crear componentes plenamente
reutilizables.
1.2. Software Process Improvement
A continuación se describe la base conceptual y fundamental para el
desarrollo de un marco enfocado a la mejora de procesos software que
combina las técnicas de estimación tradicionales con la utilización
extensiva de modelos dinámicos de simulación como herramienta para
7
asesorar en el proceso de evolución entre los diferentes niveles de madurez
propuestos por el modelo de referencia Modelo de Capacidad y Madurez
(CMM).
1.2.1. Simulación del Proceso de Desarrollo de Software
1.2.1.1.Modelo de Simulación.- es un modelo computacional,
consistente en la abstracción o representación simplificada de
un sistema dinámico complejo.
1.2.1.2.Modelo de Simulación del Proceso Software.- se centra en
determinados aspectos o procesos del desarrollo, mantenimiento
o evolución de la producción de software. A continuación se
indican las razones principales para la simulación del proceso
software:
 Gestión Estratégica.
La simulación puede ayudar a resolver un amplio rango de
cuestiones relacionadas con la gestión estratégica. Los modelos
de simulación recogen el comportamiento de la organización en
una serie de parámetros que se instancian a valores diferentes
según la cuestión que se trate de resolver. Los directores de
proyectos pueden comparar los resultados de los diferentes
escenarios simulados obteniendo un conocimiento extra que les
ayude en la toma de decisiones.
8
 Planificación
La simulación del proceso software se puede aplicar tanto en la
planificación inicial del proyecto como en las sucesivas
planificaciones o modificaciones que se realicen conforme el
proyecto progresa.
 Control y Gestión Operacional
La simulación también puede proporcionar un soporte efectivo
para las actividades de control y gestión operacional de los
proyectos software. La simulación también puede favorecer el
estudio de las consecuencias de un cambio en las prioridades
del proyecto, en las necesidades de contratación o en la
planificación inicial.
 Mejora del Proceso y Cambio Tecnológico.
La simulación puede facilitar el proceso de toma de decisiones
en el ámbito de la mejora del proceso ya que permite predecir
el impacto potencial de un cambio en el proceso antes de que
éste se haga efectivo en la práctica.
 Comprensión
El propio proceso de construcción de un modelo de simulación
permite ampliar el conocimiento que se tiene acerca de la
organización y de sus procesos de desarrollo, ya que resulta
necesario conocer y comprender correctamente los lazos de
realimentación, sus efectos y los retrasos existentes en el
proceso, entre otros aspectos, para que el modelo sea preciso.
9
 Formación y Aprendizaje
La simulación es un medio para que el personal pueda practicar
o aprender gestión de proyectos. Un entorno de entrenamiento
basado en simulación permite aprender los resultados más
probables de las decisiones de gestión más frecuentes y que, a
menudo, resultan incorrectas como, por ejemplo, adelantar
excesivamente la etapa de codificación, eliminar las revisiones
o reducir el esfuerzo asignado a las actividades de prueba. El
entrenamiento basado en la simulación también ayuda a los
directores de proyectos a aceptar resultados muy diferentes a
los que esperaban cuando tomaron la decisión.
1.2.2. Desarrollo del Dynamic Integrated Framework for Software
Process Improvement (DIFSPI)
La utilización de la simulación para la mejora de procesos dentro del
modelo CMM no es una idea nueva, de hecho ya propone al modelo
CMM como un marco incremental excelente para la obtención de
experiencia a través de la simulación de proyectos.
Una de las características definitorias del empleo de modelos
dinámicos en cualquier área de la ingeniería es que sea cual fuere el
modelo, éste requiere satisfacer un determinado nivel de calidad o
fiabilidad antes de poder ser utilizado en la práctica. De hecho, la
potencia y versatilidad de los sistemas de simulación actuales
facilitan en gran medida la construcción de modelos dinámicos que
pueden llegar a ser realmente complejos. Sin embargo, si la
10
organización no dispone de la suficiente información para inicializar
y definir los parámetros y funciones que gobiernan la evolución del
comportamiento del modelo, éste resultará inútil.
La Figura 1.1 muestra las relaciones existentes entre el nivel de
madurez de una organización, la utilización de modelos dinámicos y
las ventajas derivadas. Por ello, para utilizar un modelo dinámico en
estos niveles será necesario definir, en primer lugar, los procesos
generales de los proyectos software y las métricas requeridas para
estos procesos. El proceso de diseño del modelo dinámico aporta una
gran ayuda en este momento.
Los datos resultantes de la simulación de un modelo dinámico
pueden utilizarse en la realización de predicciones sobre la
evolución del proyecto. Los modelos dinámicos favorecen la
11
comprensión de esta naturaleza integrada de la gestión de proyectos
al describirla a través de sus procesos, estructuras e interrelaciones
principales.
Desde un punto de vista general, podría decirse que los proyectos
se componen de procesos que pertenecen a una de las siguientes
categorías principales:
 Proceso de Gestión de Proyectos. Esta categoría recoge a
todos aquellos procesos relacionados con la descripción,
organización, control y dirección del proyecto.
 Proceso Software o de Ingeniería. En ambos niveles, la
utilización de modelos dinámicos para simular los procesos
reales y para la definición y construcción de bases de datos
históricas será la característica predominante.
Se puede observar los procesos que componen un proyecto en la
Figura 1.2
12
1.2.3. Utilización de la Simulación en los Diferentes Niveles de
Madurez
El modelo CMM proporciona un marco de trabajo incremental
excelente para ganar experiencia a través de la simulación. El
desarrollo de un modelo de simulación puede resultar una tarea
relativamente fácil; no así validarlo con datos reales. Las
organizaciones que utilicen un modelo dinámico de simulación deben
poseer la información suficiente que permita validar sus procesos
simulados. A continuación, se describe la aplicación de los modelos
dinámicos de simulación a cada uno de los niveles del modelo CMM.
 Nivel 1
En este nivel es del todo recomendable introducir la idea del
proceso de software como una entidad dinámica cuyo
comportamiento está gobernado por lazos de realimentación.
Resulta muy útil colocar a los directores de proyectos en
entornos de simulación que les permitan llevar a cabo
experimentos y practicar juegos de simulación. De esta
manera, se pretende que el director tome contacto con los
entornos de simulación y con la potencialidad y ventajas del
empleo de este tipo de modelos.
 Nivel 2
Conforme se progresa hacia el nivel 2, las organizaciones
pueden comenzar a diseñar modelos de sus procesos y
examinar algunas de las propiedades de sus comportamientos.
13
En concreto, se pueden desarrollar modelos de gestión de
proyectos muy generales (sin un alto nivel de detalle) que
permitan simular aspectos tales como la planificación, el
seguimiento y supervisión del proyecto.
 Nivel 3
Las organizaciones del nivel 3 aplican un énfasis especial sobre
la ingeniería del producto, la definición formal de los procesos
de ingeniería y la instrumentación de estos procesos. Ya que los
procesos de ingeniería conducen muchos de los procesos de
gestión, la simulación precisa del nivel de ingeniería resultará
en una precisión mejorada en el nivel de gestión.
El nivel 3 también otorga una gran importancia a la definición,
mantenimiento y reutilización de procesos en una organización.
 Nivel 4
Los modelos de los niveles 3 y 4 no difieren significativamente
en su nivel de detalle o instrumentación. En el nivel 4, el
objetivo es operar los procesos dentro de límites de rendimiento
cuantitativo.
 Nivel 5
Es posible comparar la salida de la simulación del cambio en un
proceso, con la salida real de ese proceso sin modificar. Existe
también una importante conexión entre la simulación, el flujo
de trabajo y las métricas. Por tanto, la simulación soporta el
flujo de trabajo apuntando al lugar donde éste debe ser
14
instrumentado, mientras que el flujo de trabajo proporciona los
datos que permiten validar la simulación.
1.3. Personal Software Process
El Proceso Personal de Software (PSP) se caracteriza porque es de uso
personal y se aplica a programas pequeños de menos de 10.000 líneas de
código. Se centra en la administración del tiempo y en la administración de
la calidad a través de la eliminación temprana de defectos. En el PSP se
excluyen los siguientes temas: Trabajo en equipo, Administración de
configuraciones y Administración de requerimientos.
El PSP se orienta el conjunto de áreas clave del proceso que debe manejar
un desarrollador cuando trabaja de forma individual. Los siguientes son los
niveles y las Key Process Areas (KPAs) que se manejan en cada uno:
 Nivel 1 - Inicial:
o Seguimiento y control de proyectos
o Planeación de los proyectos
 Nivel 2 - Repetible:
o Revisión entre colegas.
o Ingeniería del producto de software.
o Manejo integrado del software.
o Definición del proceso de software.
o Foco del proceso de software.
 Nivel 3 - Definido:
o Control de calidad.
15
o Administración cuantitativa del proyecto.
 Nivel 4 - Controlado:
o Administración de los cambios del proceso.
o Administración del cambio tecnológico.
o Prevención de defectos.
El PSP tiene varias fases:
 PSP0: Proceso Base.
 PSP0.1: Complementos al proceso base.
 PSP1 y PSP1.1: Planeación personal.
PSP2 y PSP2.1: Control de calidad personal.
1.4. Lenguaje de Modela do Unificado (UML)
Es un lenguaje de modelado visual que se usa para especificar, visualizar,
construir y documentar artefactos de un sistema de software. Se usa para
entender, diseñar, configurar, mantener y controlar la información sobre
los sistemas a construir.
UML capta la información sobre la estructura estática y el
comportamiento dinámico de un sistema. Un sistema se modela como una
colección de objetos discretos que interactúan para realizar un trabajo que
finalmente beneficia a un usuario externo.
16
1.4.1. Comportamiento Dinámico
Hay dos formas de modelar el comportamiento, una es la historia de la
vida de un objeto y la forma como interactúa con el resto del mundo y
la otra es por los patrones de comunicación de un conjunto de objetos
conectados, es decir la forma en que interactúan entre sí. La visión de
la interacción de los objetos se representa con los enlaces entre objetos
junto con el flujo de mensajes y los enlaces entre ellos.
1.4.2. Construcciones de Implementación
Los modelos UML tienen significado para el análisis lógico y para la
implementación física. Un componente es una parte física reemplazable
de un sistema y es capaz de responder a las peticiones descritas por un
conjunto de interfaces. Un nodo es un recurso computacional que define
una localización durante la ejecución de un sistema. Puede contener
componentes y objetos.
1.4.3. Organización del Modelo
La información del modelo debe ser dividida en piezas coherentes, para
que los equipos puedan trabajar en las diferentes partes de forma
concurrente. El conocimiento humano requiere que se organice el
contenido del modelo en paquetes de tamaño modesto. Los paquetes
son unidades organizativas, jerárquicas y de propósito general de los
modelos de UML. Pueden usarse para almacenamiento, control de
acceso, gestión de la configuración y construcción de bibliotecas que
contengan fragmentos de código reutilizable.
17
1.4.4. Mecanismos de Extensión
UML tiene una limitada capacidad de extensión pero que es suficiente
para la mayoría de las extensiones que requiere el día a día sin la
necesidad de un cambio en el lenguaje básico. Un estereotipo es una
nueva clase de elemento de modelado con la misma estructura que un
elemento existente pero con restricciones adicionales.
1.4.5. Críticas a UML
A pesar de su status de estándar ampliamente reconocido y utilizado, UML
siempre ha sido muy criticado por su carencia de una semántica precisa, lo
que ha dado lugar a que la interpretación de un modelo UML no pueda ser
objetiva. Otro problema de UML es que no se presta con facilidad al
diseño de sistemas distribuidos. No se puede usar UML para señalar que
un objeto es persistente, o remoto, o que existe en un servidor que corre
continuamente y que es compartido entre varias instancias de ejecución del
sistema analizado.
1.5. Modelo Cascada Iterativa y Creciente
1.5.1. El Desarrollo Iterativo y Creciente (o incremental) es un proceso
de desarrollo de software, creado en respuesta a las debilidades del
modelo tradicional de cascada.
La idea principal detrás de mejoramiento iterativo es desarrollar un
sistema de programas de manera incremental, permitiéndole al
desarrollador sacar ventaja de lo que se ha aprendido a lo largo del
desarrollo anterior, incrementando, versiones entregables del sistema.
18
El aprendizaje viene de dos vertientes: el desarrollo del sistema, y su
uso. Los pasos claves en el proceso es comenzar con una
implementación simple de los requerimientos del sistema, e
iterativamente mejorar la secuencia evolutiva de versiones hasta que
el sistema completo esté implementado. En cada iteración, se realizan
cambios en el diseño y se agregan nuevas funcionalidades y
capacidades al sistema.
El proceso en sí mismo consiste de:
 Etapa de Inicialización
Se crea una versión del sistema. La meta de esta etapa es crear un
producto con el que el usuario pueda interactuar, y por ende
retroalimentar el proceso. Debe ofrecer una muestra de los aspectos
claves del problema y proveer una solución lo suficientemente
simple para ser comprendida e implementada fácilmente. Para
guiar el proceso de iteración, una lista de control de proyecto se
crea, y esta lista contiene un historial de todas las tareas que
necesitan ser realizadas. Incluye cosas como nueva funcionalidades
para ser implementadas, y áreas de rediseño de la solución ya
existente. Esta lista de control se revisa periódica y constantemente
como resultado de la fase de análisis.
 Etapa de Iteración
Esta etapa involucra el rediseño e implementación de una tarea de la
lista de control de proyecto, y el análisis de la versión más reciente del
19
sistema. La meta del diseño e implementación de cualquier iteración es
ser simple, directa y modular, para poder soportar el rediseño de la
etapa o como una tarea añadida a la lista de control de proyecto. El
código puede, en ciertos casos, representar la mayor fuente de
documentación del sistema. El análisis de una iteración se basa en la
retroalimentación del usuario y en el análisis de las funcionalidades
disponibles del programa. Involucra el análisis de la estructura,
modularidad, usabilidad, confiabilidad, eficiencia y eficacia (alcanzar
las metas).
20
CAPITULO 2
RATIONAL UNIFIED PROCESS (RUP)
Generalidades
El desarrollo Iterativo
Ingeniería de Requerimientos
Métodos de Aproximaciones sucesivas
Iteraciones RUP
La Calidad del Software
1. Proceso unificado de desarrollo de software (rup)
1.1. Generalidades
El RUP es un producto de Rational (IBM). Se caracteriza por ser iterativo
e incremental, estar centrado en la arquitectura y guiado por los casos de
uso. Incluye artefactos (que son los productos tangibles del proceso como
por ejemplo, el modelo de casos de uso, el código fuente, etc.) y roles
(papel que desempeña una persona en un determinado momento, una
persona puede desempeñar distintos roles a lo largo del proceso).
1.1.1. Características Principales
 Tiene una forma disciplinada de asignar tareas y responsabilidades
(quién hace qué, cuándo y cómo)
 Pretende implementar las mejores prácticas en Ingeniería de
Software
21
RUP provee a cada miembro del equipo de las guías de proceso,
plantillas y mentores de herramientas necesarios para que el tema
completo tome ventaja de, entre otras, las siguientes mejores
prácticas:
 Desarrollo iterativo
 Administración de requisitos
 Uso de arquitectura basada en componentes
 Control de cambios
 Modelado visual del software
 Verificación de la calidad del software
1.2. El desarrollo Iterativo
El RUP es un proceso de desarrollo de software dirigido por casos de uso,
centrado en la arquitectura, iterativo e incremental. RUP pretende
implementar las mejores prácticas en ingeniería de software, con el
objetivo de asegurar la producción de software de calidad, dentro de plazos
y presupuestos predecibles
El desarrollo iterativo Permite una comprensión creciente de los
requerimientos, a la vez que se va haciendo crecer el sistema. RUP sigue
un modelo iterativo que aborda las tareas más riesgosas primero. Así se
logra reducir los riesgos del proyecto y tener un subsistema ejecutable
tempranamente.
RUP divide el proceso de desarrollo en ciclos, donde se obtiene un
producto al final de cada ciclo. Cada ciclo se divide en cuatro Fases:
22
Concepción, Elaboración, Construcción, y Transición. Cada fase concluye
con un hito bien definido donde deben tomarse ciertas decisiones.
Estas fases se puede observar en la Figura 2.1.
2.3. Ingeniería de Requerimientos
La Ingeniería de Requerimientos y sus Principales Actividades
¿Qué son requerimientos?
Es una condición o capacidad que debe estar presente en un sistema o
componentes de sistema para satisfacer un contrato, estándar, especificación u
otro documento formal. Los requerimientos puedes dividirse en
requerimientos funcionales y requerimientos no funcionales.
23
Los requerimientos funcionales definen las funciones que el sistema será
capaz de realizar. Describen las transformaciones que el sistema realiza sobre
las entradas para producir salidas.
Los requerimientos no funcionales tienen que ver con características que de
una u otra forma puedan limitar el sistema, como por ejemplo, el rendimiento
(en tiempo y espacio), interfaces de usuario, fiabilidad (robustez del sistema,
disponibilidad de equipo), mantenimiento, seguridad, portabilidad, estándares,
etc.
2.3.1. Características de los requerimientos.
Las características de un requerimiento son sus propiedades
principales.
Necesario: Un requerimiento es necesario si su omisión provoca
una deficiencia en el sistema a construir, y además su capacidad,
características físicas o factor de calidad no pueden ser
reemplazados por otras capacidades del producto o del proceso.
Conciso: Un requerimiento es conciso si es fácil de leer y entender.
Consistente: Un requerimiento es consistente si no es
contradictorio con otro requerimiento.
No ambiguo: Un requerimiento no es ambiguo cuando tiene una
sola interpretación.
2.3.2. Dificultades para Definir los Requerimientos
 Los requerimientos no son obvios y vienen de muchas fuentes.
24
 Existen muchos tipos de requerimientos y diferentes niveles de
detalle.
 La cantidad de requerimientos en un proyecto puede ser difícil
de manejar.
 Nunca son iguales.
 Los requerimientos están relacionados unos con otros, y a su
vez se relacionan con otras partes del proceso.
 Cada requerimiento tiene propiedades únicas y abarcan áreas
funcionales específicas.
 Un requerimiento puede cambiar a lo largo del ciclo de
desarrollo.
 Son difíciles de cuantificar, ya que cada conjunto de
requerimientos es particular para cada proyecto.
2.3.3. Importancia de la Ingeniería de Requerimientos:
Los principales beneficios que se obtienen de la Ingeniería de
Requerimientos son:
 Permite gestionar las necesidades del proyecto en forma
estructurada: Cada actividad de la IR consiste de una serie de
pasos organizados y bien definidos.
 Mejora la calidad del software: La calidad en el software tiene
que ver con cumplir un conjunto de requerimientos
(funcionalidad, facilidad de uso, confiabilidad, desempeño,
etc.).
25
 Mejora la comunicación entre equipos: La especificación de
requerimientos representa una forma de consenso entre
clientes y desarrolladores.
 Evita rechazos de usuarios finales: La ingeniería de
requerimientos obliga al cliente a considerar sus
requerimientos cuidadosamente y revisarlos dentro del marco
del problema, por lo que se le involucra durante todo el
desarrollo del proyecto.
2.3.4. Personal involucrado en la Ingeniería de Requerimientos
Realmente, son muchas las personas involucradas en el desarrollo
de los requerimientos de un sistema.
Los roles más importantes pueden clasificarse como sigue:
Usuario final: Son las personas que usarán el sistema desarrollado.
Usuario Líder: Son los individuos que comprenden el ambiente
del sistema o el dominio del problema en donde será empleado el
software desarrollado. Ellos proporcionan al equipo técnico los
detalles y requerimientos de las interfaces del sistema.
Personal de Mantenimiento: Para proyectos que requieran un
mantenimiento eventual, estas personas son las responsables de la
administración de cambios, de la implementación y resolución de
anomalías. Son quienes van a validar si los requerimientos
satisfacen las necesidades del cliente.
26
Otras personas que pueden estar involucradas, dependiendo de la
magnitud del proyecto, pueden ser: administradores de proyecto,
documentadores, diseñadores de base de datos, entre otros.
2.3.5. Técnicas y Herramientas Utilizadas en la Ingeniería de
Requerimientos
Por lo común, los encuestados son usuarios de los sistemas
existentes o usuarios en potencia del sistema propuesto. En algunos
casos, son gerentes o empleados que proporcionan datos para el
sistema propuesto o que serán afectados por él.
Las preguntas que deben realizarse en esta técnica, deben ser
preguntas de alto nivel y abstractas que pueden realizarse al inicio
del proyecto para obtener información sobre aspectos globales del
problema del usuario y soluciones potenciales.
Las preguntas pueden ser enfocadas a un elemento del sistema,
tales como usuarios, procesos, etc. A esta técnica se le conoce
también como torbellino de ideas, tormenta de ideas,
desencadenamiento de ideas, movilización verbal, bombardeo de
ideas, sacudidas de cerebros, promoción de ideas, tormenta
cerebral, avalancha de ideas, tempestad en el cerebro y tempestad
de ideas, entre otras.
27
2.4. Iteraciones RUP
En función de la cada vez mayor complejidad solicitada para los sistemas
de software, ya no es posible trabajar secuencialmente, es decir definir
primero el problema completo, luego diseñar toda la solución, construir el
software y finalmente, testear el producto; ahora es necesario un enfoque
iterativo, que permita una comprensión creciente del problema a través de
refinamientos sucesivos, llegando a una solución efectiva luego de
múltiples iteraciones acotadas en complejidad.
RUP utiliza y soporta este enfoque iterativo que ayuda a atacar los riesgos
mediante la producción de releases ejecutables progresivos y frecuentes
que permiten la opinión e involucramiento del usuario.
A través de las iteraciones que generan releases ejecutables, se logra
detectar en forma temprana los desajustes e inconsistencias entre los
requerimientos, el diseño, el desarrollo y la implementación del sistema,
manteniendo al team de desarrollo focalizado en producir resultados.
Un proceso iterativo incremental debería analizar el impacto de cada nuevo
cambio para no destruir lo anterior completamente, sino modificarlo
ligeramente para extenderlo al mínimo costo. Este es el proceso que usa el
RUP y similares.
28
Un proceso incremental no iterativo sería implantar primero un módulo,
luego el siguiente; y cada módulo nuevo agrega nueva funcionalidad pero
cada uno se construye en una fase y se cierra.
2.5. Arquitectura de Componentes
El proceso de software debe focalizarse en el desarrollo temprano de una
arquitectura robusta ejecutable, antes de comprometer recursos para el
desarrollo en gran escala. RUP describe como diseñar una arquitectura
flexible, que se acomode a los cambios, comprensible intuitivamente y
promueve una más efectiva reutilización de software. Soporta el desarrollo
de software basado en componentes, módulos no triviales que completan
una función clara. RUP provee un enfoque sistemático para definir una
arquitectura utilizando componentes nuevos y preexistentes.
2.6. La Calidad del Software
¿Que es la calidad del software?
La calidad del software es el conjunto de cualidades que lo caracterizan y
que determinan su utilidad y existencia. La calidad es sinónimo de
eficiencia, flexibilidad, corrección, confiabilidad, mantenibilidad,
portabilidad, usabilidad, seguridad e integridad.
La calidad del software es medible y varía de un sistema a otro o de un
programa a otro. Un software elaborado para el control de naves espaciales
debe ser confiable al nivel de "cero fallas"; un software hecho para
29
ejecutarse una sola vez no requiere el mismo nivel de calidad; mientras que
un producto de software para ser explotado durante un largo período (10
años o más), necesita ser confiable, mantenible y flexible para disminuir
los costos de mantenimiento y perfeccionamiento durante el tiempo de
explotación. La calidad del software puede medirse después de elaborado
el producto.
¿Como obtener un software de calidad?
La obtención de un software con calidad implica la utilización de
metodologías o procedimientos estándares para el análisis, diseño,
programación y prueba del software que permitan uniformar la filosofía de
trabajo, en aras de lograr una mayor confiabilidad, mantenibilidad y
facilidad de prueba, a la vez que eleven la productividad, tanto para la labor
de desarrollo como para el control de la calidad del software.
El principio administrativo contempla las funciones de planificación y
control del desarrollo del software, así como la organización del ambiente o
centro de ingeniería de software.
La adopción de una buena política contribuye en gran medida a lograr la
calidad del software, pero no la asegura. Para el aseguramiento de la
calidad es necesario su control o evaluación.
30
¿Como controlar la calidad del software?
Para controlar la calidad del software es necesario, ante todo, definir los
parámetros, indicadores o criterios de medición, ya que usted no puede
controlar lo que no se puede medir.
El software posee determinados índices medibles que son las bases para la
calidad, el control y el perfeccionamiento de la productividad de acuerdo
con los estándares establecidos para el desarrollo del software.
31
CAPITULO 3
AL INTERIOR DE RATIONAL UNIFIED PROCESS (RUP) ESQUEMA

DETALLADO
Dimensiones de RUP
Fases
Concepción ( Inception)
Elaboración
Construcción
Transición
Work Flows
WorkFlow de Proceso
Modelamiento del negocio
Requerimientos
Ampliación de requerimientos
Análisis
Análisis preliminar
Análisis detallado
Revisión de requisitos
Especificaciones
Diseño
Arquitectónico
Casos de uso
Clases
Objetos
Comportamiento
Estados
Actividad
Interacción
Secuencia
Colaboración
Implementación
Componentes
Despliegue
Datos
Entidad / Relación
Normalización
Interfaces de E/S
Construcción
BDD
Objetos
Prueba de objetos
Enlace de Objetos
Formularios e interfaces
Reportes
Test (prueba)
32
Modular
De integración
Entrega
WorkFlow de Colaboración
Configuración y Administración de cambios
Administración del Proyecto
Medioambiente
3. Al Interior de Rational Unified Process (rup) Esquema
Detallado
3.1. Dimensiones de RUP
RUP provee un enfoque disciplinado en la asignación de tareas y
responsabilidades dentro de una organización de desarrollo. Su meta es
asegurar la producción de software de muy alta calidad que satisfaga las
necesidades de los usuarios finales, dentro de un calendario y presupuesto
predecible.
El Proceso Unificado tiene dos dimensiones:
 Un Eje Horizontal que representa el tiempo y muestra los aspectos del
ciclo de vida del proceso a lo largo de su desenvolvimiento
 Un Eje Vertical que representa las disciplinas, las cuales agrupan
actividades de una manera lógica de acuerdo a su naturaleza.
La primera dimensión representa el aspecto dinámico del proceso
conforme se va desarrollando, se expresa en términos de fases, iteraciones
e hitos.
33
La segunda dimensión representa el aspecto estático del proceso: cómo es
descrito en términos de componentes del proceso, disciplinas, actividades,
flujos de trabajo, artefactos y roles.
3.1.1. Fases del RUP
El proceso iterativo de RUP se organiza en fases, cada fase se
concluye con una piedra de milla principal (ver Figura 3.1). Es
importante resaltar que la inclusión de piedras de millas o puntos
de revisión, es sumamente importante y en estos puntos se revisan
los requerimientos establecidos para cada fase, basados en los
controles de calidad. De esta manera, si un producto o proceso no
pasa el punto de revisión de calidad, se rediseña o se cancela,
evitando así, los problemas de coste extra y de productos de mala
calidad, que no satisfacen los requerimientos establecidos a nivel
educativo, comunicacional, técnico y de diseño gráfico. Los puntos
de revisión están basados a su vez en cuestionarios elaborados a
34
partir de métricas establecidas producto de la experiencia y de la
investigación.
A continuación se presentan los objetivos de cada fase, junto con
una tabla comparativa especificando las actividades que se
agregaron para el desarrollo de software educativo según la
metodología de RUP.
3.1.1.1. Fase de Comienzo o Inicio
Está principalmente dirigida al entendimiento de los requerimientos
y determinar el alcance del esfuerzo de desarrollo. Se define la
idea, la visión y el alcance del proyecto. Esta fase incluye la fase de
análisis y diseño. Se incluye un análisis de las necesidades
educativas y del entorno educativo, así como el diseño
instruccional del proyecto. En este plan creativo se integra el
trabajo de diseñadores gráficos, analistas de sistemas y docentes
especialistas en el área. Esta fase se culmina con los objetivos del
ciclo de vida.
3.1.1.2. Fase de Elaboración
Planificar las actividades necesarias y los recursos requeridos,
especificando las características y el diseño de la arquitectura del
software. Esta fase culmina con la arquitectura del ciclo de vida.
35
3.1.1.3. Fase de Construcción
Desarrollar el producto y evolucionar la visión; la arquitectura y los
planes hasta que el producto en una primera versión esté listo para
ser enviado a la comunidad de usuarios. Esta fase culmina con la
capacidad inicial de operación.
3.1.1.4. Fase de Transición
Realizar la transición del producto a los usuarios, lo cual incluye:
manufactura, envío, entrenamiento, soporte y mantenimiento del
producto hasta que el cliente esté satisfecho. Esta fase culmina con
la versión de producto, la cual a su vez concluye el ciclo.
3.1.2. Work Flows
3.1.2.1. Definición
Workflow, entendido como el flujo de procesos administrativos o
de negocio, es el conjunto de actividades o tareas realizadas en
secuencia o en paralelo por dos o más miembros de un equipo de
trabajo para lograr un objetivo común siguiendo unas reglas de
negocio preestablecidas.
Si una sola persona realiza la tarea, no realiza workflow. Como su
nombre lo sugiere, una actividad es workflow si "fluye" de un
individuo a otro.
Si un proceso no sigue unas reglas y ruta preestablecidas, no se
trata de workflow, sino de un proceso de colaboración.
36
3.1.2.2. Tipos de Workflow
Una vez posicionado el workflow dentro de la categoría más
amplia de soluciones de groupware, se presentan los diversos tipos
de aplicaciones de workflow, se segmentará el mercadeo de
workflow y las diferentes categorías de producto.
Existen tres tipos diferentes de aplicaciones de workflow:
 Workflow de Producción
 Workflow Colaborativo
 Workflow Administrativo
3.1.2.3. Workflow de Producción
En las aplicaciones de workflow de producción, el workflow es la
tarea principal de los participantes. Dicho personal puede tener
actividades adicionales en su trabajo diario, pero fundamentalmente
la realización de workflow.
El workflow de producción suele estar circunscrito a un sólo
departamento, la escalabilidad, o capacidad de "crecer" no es
importante.
3.1.2.4. Workflow Colaborativo
Involucra procesos estructurados o semi-estructurados que
permiten a varias personas participar en un grupo de trabajo,
ejemplos de ello lo constituyen el diseño arquitectónico o
ingenieril, generación de informes, producción de material
publicitario, revisión de documentos legales, etc. Por tanto, las
37
características esenciales de workflow colaborativo son las
siguientes:
 El "documento" y el "proceso" son claves. Es importante
para la aplicación preservar la integridad tanto del
documento como del proceso.
 El workflow colaborativo debe ser muy flexible ya que el
trabajo creativo puede tomar rumbos inesperados.
 Las soluciones de workflow colaborativo suelen estar
centradas en el "documento".
3.1.2.5. Workflow Administrativo
Involucra procesos administrativos tales como ordenes de compra,
hojas de tiempos y movimientos, reportes de gastos, cambios de
ordenes, reportes de calidad y muchas otras actividades que
traspasan las barreras departamentales e inclusive de la empresa
misma. Los atributos de una buena herramienta son:
 Existen un gran número de procesos administrativos en
cada organización, por ello la solución debe ser capaz de
manejar muchos procesos diferentes.
 El workflow administrativo es diferente para cada
organización y también cambia con frecuencia; de ahí la
gran importancia de poder cambiar los procesos fácilmente.
38
 El workflow administrativo está destinado a cada escritorio
y se prevé que será el segmento más grande del mercado del
workflow.
3.1.3. Modelamiento del Negocio
Identificar el área correcta para cambiar y mejorar es un objetivo supremo
para el éxito total de una organización. Los peligros de poner en marcha
el mejoramiento de un proceso del negocio, sin tener un claro
entendimiento de cómo impactarán estos cambios a la empresa, pueden ser
sustanciales. Por tanto, son necesarias herramientas que ayuden a los
gerentes a entender fácilmente sus procesos de negocio y cómo afectarán
las modificaciones de esos procesos a la compañía en su conjunto.
El método de Modelamiento del negocio es una técnica para modelar
procesos del negocio. Los modelos del negocio proporcionan maneras de
expresar procesos del negocio o estrategias en términos de actividades
económicas y comportamiento colaborativo, así que permiten entender
mejor los procesos del negocio y a los participantes de estos procesos. Los
modelos son provechosos para documentar, comprender y comunicar la
complejidad. Documentando procesos del negocio desde varias
perspectivas, los modelos del negocio pueden ayudan a los gerentes a
entender su entorno.
3.1.3.1. Modelamiento de Negocios e Investigación Operacional
La simulación de negocios ha crecido a partir de la investigación de
operaciones de los años 50´s. Con la llegada de computadoras, cada vez
39
más baratas y de gran potencia, y el software de uso cada vez más sencillo,
ahora las técnicas de modelamiento de negocios permiten que
incluso gerentes no técnicos prueben y diseñen varias opciones o
panoramas, para ayudarse en la toma de decisiones.
Otro factor que ha contribuido al incremento del uso del método de
modelamiento de negocios, es el aumento de la velocidad del cambio en
los negocio. No hay suficiente tiempo de probar productos nuevos en la
realidad, y corregir errores, una vez que estos se han producido, es a
menudo extremadamente costoso.
3.2. Ampliación de Requerimientos
3.2.1. Análisis
3.2.1.1. Análisis Preliminar
El primer problema que se presenta es la captura de los requisitos
del usuario. Para empezar, necesitamos recoger los requisitos de los
usuarios o clientes de una manera sistemática y organizada. Para
ello precisamos de unas directrices o líneas guía, ya que en general
los usuarios expresan los requerimientos de la aplicación de forma
muy variable, tanto en la forma como en el contenido. Nos interesa
pues sistematizar la captura, con el fin de hacer los requisitos
manejables y analizables.
40
3.2.1.2. Análisis Detallado
Una vez conseguidos los requisitos, pasamos a la fase de análisis.
En ella, lo que haremos es analizar los requisitos obtenidos de los
usuarios con el fin de comprenderlos, y a partir de ellos desarrollar
una especificación de la aplicación, que deberá ser completa y
consistente, y deberá estar expresada de una manera al menos semi
formal, no simplemente textual. En este proceso, encontraremos
habitualmente gran cantidad de problemas en los requisitos, áreas
no especificadas, requisitos contradictorios, y afirmaciones
(aparentemente) vagas e irrelevantes. Eso nos llevará de vuelta a
los usuarios con el fin de mejorar la calidad de los requisitos: pero
debemos abordarles sabiendo lo que queremos conseguir, qué
aspectos de los requisitos obtenidos inicialmente nos interesa
aclarar, y el porqué.
3.2.1.3. Revisión de Requisitos
Para un sistema del que se sabe bien lo que se espera de él, y con
relativa estabilidad de los requisitos durante el desarrollo, resultaría
más apropiado un modelo de gestión formal que uno ágil, pero
siempre que se lleve a cabo una de las partes más difíciles los
requisitos.
Muchas veces se eligen ciclos de desarrollo iterativo sobre
prototipado, no por la incertidumbre del sistema, sino para eludir
las tareas de la ingeniería formal de requisitos.
41
Los requisitos suelen ser asignatura pendiente en muchos proyectos
de software.
Obtenerlo, analizarlos y especificarlos sin ambigüedades ni
omisiones, de forma que resulten verificables y cuantificablemente
medibles no es fácil. Y si no resulta fácil con los requisitos
funcionales, cuando se trata de requisitos de seguridad, el terreno se
vuelve aún más difícil.
3.2.1.4. Especificaciones
Escribir una especificación es un gran modo de fijar todas esas
molestas decisiones de diseño, grandes y pequeñas, que quedan
disimuladas si no tienes una especificación. Incluso las decisiones
de poca entidad pueden quedar fijadas por una especificación. Por
ejemplo, si estáis construyendo un sitio web en el que la gente se
puede dar de alta, todos podéis estar de acuerdo en que, si un
usuario pierde su contraseña, se la enviaréis por e-mail. Magnífico.
Pero no es suficiente para escribir el código. Para escribir el
código, necesitas saber las palabras precisas que irán en el e-mail.
En la mayoría de las empresas, a los programadores no se les
confían palabras que un usuario pudiera llegar a ver (y por buenas
razones, la mayor parte de las veces). Por tanto, es probable que
alguien de marketing o relaciones públicas o que haya estudiado
filología sea requerido para que defina el texto preciso del mensaje.
42
3.2.2. Diseño Arquitectónico
3.2.2.1. Casos de uso
Casos de Uso es una técnica para capturar información de cómo un
sistema o negocio trabaja, o de cómo se desea que trabaje. No
pertenece estrictamente al enfoque orientado a objeto, es una técnica
para captura de requisitos. Los Casos de Uso son descripciones de la
funcionalidad del sistema; y están basados en el lenguaje natural, es
decir, es accesible por los usuarios.
3.2.2.1.1. Actores
 Principales: personas que usan el sistema.
 Secundarios: personas que mantienen o administran el
sistema.
 Material Externo: dispositivos materiales imprescindibles
que forman parte del ámbito de la aplicación y deben ser
utilizados.
 Otros Sistemas: sistemas con los que el sistema interactúa.
La misma persona física puede interpretar varios papeles como
actores distintos, el nombre del actor describe el papel
desempeñado.
Los Casos de Uso se determinan observando y precisando, actor
por actor, las secuencias de interacción, los escenarios, desde el
punto de vista del usuario. Los casos de uso intervienen durante
43
todo el ciclo de vida. El proceso de desarrollo estará dirigido por
los casos de uso. Un escenario es una instancia de un caso de
uso. En la Figura 3.2 se puede observar un ejemplo de caso de
uso, con sus diferentes actores.
44
3.2.2.1.2. UML Define Cuatro Tipos de Relación en los
Diagramas de Casos de Uso
 Comunicación: indica la comunicación entre el actor y el caso
de uso.
 Inclusión: una instancia del Caso de Uso origen incluye
también el comportamiento descrito por el Caso de Uso destino.
«include» reemplazó al denominado «uses»
 Extensión: el Caso de Uso origen extiende el comportamiento
del Caso de Uso destino. «extend»
 Herencia: el Caso de Uso origen hereda la especificación del
Caso de Uso destino y posiblemente la modifica y/o amplía.
En la Figura 3.3 se puede observar las relaciones en los
diagramas de Caso de Uso.
45
3.2.2.1.3. Parámetros para la Construcción de un Caso de
Uso
Un caso de uso debe ser simple, inteligible, claro y conciso.
Generalmente hay pocos actores asociados a cada Caso de Uso.
Preguntas clave:
 Cuáles son las tareas del actor?
 Qué información crea, guarda, modifica, destruye o lee el
actor?
 Debe el actor notificar al sistema los cambios externos?
 Debe el sistema informar al actor de los cambios internos?
3.2.2.1.4. La Descripción del Caso de Uso Comprende
 El inicio: cuándo y qué actor lo produce?
 El fin: cuándo se produce y qué valor devuelve?
 La interacción actor-caso de uso: qué mensajes
intercambian ambos?
 Objetivo del caso de uso: qué lleva a cabo o intenta?
 Cronología y origen de las interacciones
 Repeticiones de comportamiento: qué operaciones son
iteradas?
 Situaciones opcionales: qué ejecuciones alternativas se
presentan en el caso de uso?
46
3.2.2.2. Diagrama de Clases
El Diagrama de Clases es el diagrama principal para el análisis y
diseño. Un diagrama de clases presenta las clases del sistema con sus
relaciones estructurales y de herencia. La definición de clase incluye
definiciones para atributos y operaciones. El modelo de casos de uso
aporta información para establecer las clases, objetos, atributos y
operaciones.
En la figura 3.1, de puede observar el diagrama de clases.
3.2.2.2.1. Mecanismos de Abstracción:
 Clasificación / Instanciación
 Composición / Descomposición
 Agrupación / Individualización
47
 Especialización / Generalización
La clasificación es uno de los mecanismos de abstracción más
utilizados. La clase define el ámbito de definición de un
conjunto de objetos, y cada objeto pertenece a una clase, Los
objetos se crean por instanciación de las clases.
Cada clase se representa en un rectángulo con tres
compartimientos:
 nombre de la clase
 atributos de la clase
 operaciones de la clase
Los atributos de una clase no deberían ser manipulables
directamente por el resto de objetos. Por esta razón se crearon
niveles de visibilidad para los elementos que son:
 (-) Privado: es el más fuerte. Esta parte es totalmente
invisible (excepto para clases friends en terminología
C++)
 (#) Los atributos/operaciones protegidos están visibles
para las clases friends y para las clases derivadas de la
original.
 (+) Los atributos/operaciones públicos son visibles a
otras clases (cuando se trata de atributos se está
transgrediendo el principio de encapsulación)
48
3.2.2.2.2. Relaciones entre Clases
Los enlaces entre objetos pueden representarse entre las
respectivas clases y sus formas de relación son:
 Asociación y Agregación (vista como un caso particular
de asociación)
 Generalización/Especialización.
Las relaciones de Agregación y Generalización forman
jerarquías de clases.
3.2.2.2.3. Asociación
La asociación expresa una conexión bi direccional entre
objetos. Una asociación es una abstracción de la relación
existente en los enlaces entre los objetos. Puede
determinarse por la especificación de multiplicidad
(mínima...máxima)
 Uno y sólo uno
 0..1 Cero o uno
 M..N Desde M hasta N (enteros naturales)
 Cero o muchos
 0..* Cero o muchos
 1..* Uno o muchos (al menos uno)
49
3.2.2.2.4. Agregación:
La agregación representa una relación parte_de entre
objetos. En UML se proporciona una escasa
caracterización de la agregación. Esta relación puede ser
caracterizada con precisión determinando las relaciones
de comportamiento y estructura que existen entre el
objeto agregado y cada uno de sus objetos componentes.
Una agregación se podría caracterizar según:
Puede el objeto parte comunicarse directamente con
objetos externos al objeto agregado?
No => inclusiva
Si => no inclusiva
Puede cambiar La composición del objeto agregado?
Si => dinámica
No => estática
Diagrama de Clases y Diagramas de Objetos pertenecen
a dos vistas complementarias del modelo. Un Diagrama
de Clases muestra la abstracción de una parte del
dominio. Un Diagrama de Objetos representa una
situación concreta del dominio. Las clases abstractas no
son instanciadas.
50
3.2.2.2.5. Generalización
Permite gestionar la complejidad mediante un
ordenamiento taxonómico de clases, se obtiene usando
los mecanismos de abstracción de Generalización y/o
Especialización. La Generalización consiste en factorizar
las propiedades comunes de un conjunto de clases en una
clase más general. Los nombres usados: clase padre -
clase hija. Otros nombres: superclase - subclase, clase
base - clase derivada. Las subclases heredan propiedades
de sus clases padre, es decir, atributos y operaciones (y
asociaciones) de la clase padre están disponibles en sus
clases hijas. La Generalización y Especialización son
equivalentes en cuanto al resultado: la jerarquía y
herencia establecidas. Generalización y Especialización
no son operaciones reflexivas ni simétricas pero sí
transitivas. La especialización es una técnica muy eficaz
para la extensión y reutilización.
La noción de clase está próxima a la de conjunto. Dada
una clase, podemos ver el conjunto relativo a las
instancias que posee o bien relativo a las propiedades de
la clase. Generalización y especialización expresan
relaciones de inclusión entre conjuntos
51
3.2.2.3. Diagrama de Objetos
Objeto es una entidad discreta con límites bien definidos y con
identidad, es una unidad atómica que encapsula estado y
comportamiento. La encapsulación en un objeto permite una alta
cohesión y un bajo acoplamiento. El Objeto es reconocido
también como una instancia de la clase a la cual pertenece. La
encapsulación presenta tres ventajas básicas:
 Se protegen los datos de accesos indebidos
 El acoplamiento entre las clases se disminuye
 Favorece la modularidad y el mantenimiento
Un objeto se puede ver desde dos perspectivas relacionadas:
como una entidad de un determinado instante de tiempo que
posee un valor específico (Un objeto puede caracterizar una
entidad física -coche-) y como un poseedor de identidad que
tiene distintos valores a lo largo del tiempo.
Cada objeto posee su propia identidad exclusiva y se puede
hacer referencia a él mediante una denominación exclusiva que
permite accederle. El Modelado de Objetos permite representar
el ciclo de vida de los objetos a través de sus interacciones. En
UML, un objeto se representa por un rectángulo con un nombre
subrayado como se puede ver en la Figura 3.5.
52
La regla general para la notación de instancias consiste en
utilizar el mismo símbolo geométrico que el descriptor. En la
instancia se muestran los posibles valores pero las propiedades
compartidas sólo se ponen de manifiesto en el descriptor. La
notación canónica es un rectángulo con tres compartimientos.
En el primero va el nombre del objeto, en el segundo sus
atributos y en el tercero sus operaciones. Este último puede ser
omitido si así se prefiere.
3.2.2.4. Diagrama de Comportamiento
Muestra el conjunto de estados por los cuales pasa un objeto
durante su vida en una aplicación, junto con los cambios que
permiten pasar de un estado a otro.
53
Estos diagramas son útiles sólo para los objetos con un
comportamiento significativo. Cada objeto está en un estado en
cierto instante. El estado está caracterizado parcialmente por los
valores algunos de los atributos del objeto. El estado en el que se
encuentra un objeto determina su comportamiento
3.2.2.4.1. Diagrama de Estado
Identifica un periodo de tiempo del objeto (no instantáneo) en el
cual el objeto está esperando alguna operación, tiene cierto
estado característico o puede recibir cierto tipo de estímulos. Se
representa mediante un rectángulo con los bordes redondeados,
que puede tener tres compartimientos: uno para el nombre, otro
para el valor característico de los atributos del objeto en ese
estado y otro para las acciones que se realizan al entrar, salir o
estar en un estado (entry, exit o do, respectivamente).
3.2.2.4.1.1. Eventos
Es una ocurrencia que puede causar la transición de un estado a
otro de un objeto. Esta ocurrencia puede ser una de varias cosas:
 Condición que toma el valor de verdadero o falso
 Recepción de una señal de otro objeto en el modelo
 Recepción de un mensaje
 Paso de cierto período de tiempo, después de entrar al
estado o de cierta hora y fecha particular
54
El nombre de un evento tiene alcance dentro del paquete en el
cual está definido, no es local a la clase que lo nombre.
3.2.2.4.2. Envío de Mensajes
Además de mostrar y transición de estados por medio de
eventos, puede representarse el momento en el cual se envían
mensajes a otros objetos. Esto se realiza mediante una línea
punteada dirigida al diagrama de estados del objeto receptor del
mensaje.
3.2.2.4.3. Transición Simple
Una transición simple es una relación entre dos estados que
indica que un objeto en el primer estado puede entrar al segundo
estado y ejecutar ciertas operaciones, cuando un evento ocurre y
si ciertas condiciones son satisfechas. Se representa como una
línea sólida entre dos estados, que puede venir acompañada de
un texto.
3.2.2.4.4. Transición Interna
Es una transición que permanece en el mismo estado, en vez de
involucrar dos estados distintos. Representa un evento que no
causa cambio de estado. Se denota como una cadena adicional
en el compartimiento de acciones del estado.
55
3.2.2.4.5. Acciones:
Podemos especificar la solicitud de un servicio a otro objeto
como consecuencia de la transición. Se puede especificar el
ejecutar una acción como consecuencia de entrar, salir, estar en
un estado, o por la ocurrencia de un evento.
3.2.2.4.6. Generalización de Estados:
 Podemos reducir la complejidad de estos diagramas usando
la generalización de estados.
 Distinguimos así entre super estado y sub estados.
 Un estado puede contener varios sub estados disjuntos.
 Los subestados heredan las variables de estado y las
transiciones externas.
 La agregación de estados es la composición de un estado a
partir de varios estados independientes.
La composición es concurrente por lo que el objeto estará en
alguno de los estados de cada uno de los subestados
concurrentes. La destrucción de un objeto es efectiva cuando el
flujo de control del autómata alcanza un estado final no anidado.
La llegada a un estado final anidado implica la subida al
superestado asociado, no el fin del objeto.
3.2.2.4.7. Subestados
56
Un estado puede descomponerse en subestados, con transiciones
entre ellos y conexiones al nivel superior. Las conexiones se ven
al nivel inferior como estados de inicio o fin, los cuales se
suponen conectados a las entradas y salidas del nivel
inmediatamente superior.
3.2.2.4.8. Transacción Compleja
Una transición compleja relaciona tres o más estados en una
transición de múltiples fuentes y/o múltiples destinos. Se
representa como una línea vertical de la cual salen o entran
varias líneas de transición de estado.
3.2.2.4.9. Transición a Estados Anidados
Una transición de hacia un estado complejo (descrito mediante
estados anidados) significa la entrada al estado inicial del
subdiagrama. Las transiciones que salen del estado complejo se
entienden como transiciones desde cada uno de los subestados
hacia afuera (a cualquier nivel de profundidad).
3.2.2.4.10. Transiciones Temporizadas
 Las esperas son actividades que tienen asociada cierta
duración.
 La actividad de espera se interrumpe cuando el evento
esperado tiene lugar.
57
 Este evento desencadena una transición que permite salir del
estado que alberga la actividad de espera. El flujo de control
se transmite entonces a otro estado.
Todo lo expuesto anteriormente se puede observar en la Figura
3.6.
58
3.2.2.5. Diagrama de Actividades
El Diagrama de Actividad es una especialización del Diagrama
de Estado, organizado respecto de las acciones y usado para
especificar:
 Un método
 Un caso de uso
 Un proceso de negocio (Workflow)
Un estado de actividad representa una actividad: un paso en el
flujo de trabajo o la ejecución de una operación. Un grafo de
actividades describe grupos secuenciales y concurrentes de
actividades. Los grafos de actividades se muestran en diagramas
de actividades. Las actividades se enlazan por transiciones
automáticas. Cuando una actividad termina se desencadena el
paso a la siguiente actividad.
Un diagrama de actividades es provechoso para entender el
comportamiento de alto nivel de la ejecución de un sistema, sin
profundizar en los detalles internos de los mensajes. Los
parámetros de entrada y salida de una acción se pueden mostrar
usando las relaciones de flujo que conectan la acción y un estado
de flujo de objeto.
Un grafo de actividades contiene estados de actividad que
representa la ejecución de una secuencia en un procedimiento, o
el funcionamiento de una actividad en un flujo de trabajo. En
59
vez de esperar un evento, como en un estado de espera normal,
un estado de actividad espera la terminación de su cómputo.
Cuando la actividad termina, entonces la ejecución procede al
siguiente estado de actividad dentro del diagrama. una transición
de terminación es activada en un diagrama de actividades
cuando se completa la actividad precedente.
Los estados de actividad no tienen transiciones con eventos
explícitos, peor pueden ser abortados por transiciones en estados
que los incluyen.
Un grafo de actividades puede contener también estados de
acción, que son similares a los de actividad pero son atómicos y
no permiten transiciones mientras están activos. Los estados de
acción se deben utilizar para las operaciones cortas de
mantenimiento.
Un diagrama de actividades puede contener bifurcaciones, así
como divisiones de control en hilos concurrentes. los hilos
concurrentes representan actividades que se pueden realizar
concurrentemente por los diversos objetos o personas. La
concurrencia se representa a partir de la agregación, en la cual
cada objeto tiene su propio hilo. Las actividades concurrentes se
pueden realizar simultáneamente o en cualquier orden. Un
diagrama de actividades es como un organigrama tradicional,
excepto que permite el control de concurrencia además del
control secuencial, esto se puede observar en l a Figura 3.7.
60
Un estado de actividad se representa como una caja con los
extremos redondeados que contiene una descripción de
actividad. Las transacciones simples de terminación se muestran
como flechas. Las ramas se muestran como condiciones de
guarda en transiciones o como diamantes con múltiples flechas
de salida etiquetadas. Una división o una unión de control se
representan con múltiples flechas que entran o salen de la barra
gruesa de sincronización.
61
Cuando es necesario incluir eventos externos, la recepción de un
evento se puede mostrar como un disparador en una transición, o
como un símbolo especial que denota la espera de una señal.
A menudo es útil organizar las actividades en un modelo según
su responsabilidad. Esta clase de asignación puede mostrarse
organizando las actividades en regiones distintas separadas por
líneas en el diagrama. Debido a su aspecto, esto es conocido
como Calles.
Un diagrama de actividades puede mostrar el flujo de objetos
como valores. Para un valor de salida, se dibuja una flecha con
línea discontinua desde la actividad al objeto. Para un valor de
entrada, se dibuja una flecha con línea discontinua desde el
objeto a una actividad.
3.2.2.6. Diagramas de Interacción
La vista de interacción describe secuencias de intercambios de
mensajes entre los roles que implementan el comportamiento de un
sistema. Un rol clasificador, o simplemente "un rol", es la
descripción de un objeto, que desempeña un determinado papel
dentro de una interacción, distinto de los otros objetos de la misma
clase. Esta visión proporciona una vista integral del
comportamiento del sistema, es decir, muestra el flujo de control a
través de muchos objetos. La vista de interacción se exhibe en dos
62
diagramas centrados en distintos aspectos pero complementarios:
centrados en los objetos individuales y centrados en objetos
cooperantes.
Los objetos interactúan para realizar colectivamente los
servicios ofrecidos por las aplicaciones. Los diagramas de
interacción muestran cómo se comunican los objetos en una
interacción. Existen dos tipos de diagramas de interacción: el
Diagrama de Colaboración y el Diagrama de Secuencia.
3.2.2.6.1. Diagrama de Secuencia
El Diagrama de Secuencia es más adecuado para observar la
perspectiva cronológica de las interacciones, muestra la
secuencia explícita de mensajes y son mejores para
especificaciones de tiempo real y para escenarios complejos. El
Diagrama de Colaboración ofrece una mejor visión espacial
mostrando los enlaces de comunicación entre objetos, muestra
las relaciones entre objetos y son mejores para comprender
todos los efectos que tiene un objeto y para el diseño de
procedimientos. El diagrama de Colaboración puede obtenerse
automáticamente a partir del correspondiente diagrama de
Secuencia (o viceversa), como se puede ver en la Figura 3.8.
63
3.2.2.6.1.1. Características
 Muestra la secuencia de mensajes entre objetos durante
un escenario concreto
 Cada objeto viene dado por una barra vertical
 El tiempo transcurre de arriba abajo
 Cuando existe demora entre el envío y la atención se
puede indicar usando una línea oblicua
3.2.2.6.2. Diagrama de Colaboración
Es una descripción de una colección de objetos que interactúan
para implementar un cierto comportamiento dentro de un
64
contexto. Describe una sociedad de objetos cooperantes unidos
para realizar un cierto propósito. Una colaboración contiene
ranuras que son rellenadas por los objetos y enlaces en tiempo
de ejecución. Una ranura de colaboración se llama Rol porque
describe el propósito de un objeto o un enlace dentro de la
colaboración.
Un rol clasificador representa una descripción de los objetos que
pueden participar en una ejecución de la colaboración, un rol de
asociación representa una descripción de los enlaces que pueden
participar en una ejecución de colaboración. Un rol de
clasificador es una asociación que está limitada por tomar parte
en la colaboración. Las relaciones entre roles de clasificador y
asociación dentro de una colaboración sólo tienen sentido en ese
contexto. En general fuera de ese contexto no se aplican las
mismas relaciones.
Una Colaboración tiene un aspecto estructural y un aspecto de
comportamiento. El aspecto estructural es similar a una vista
estática: contiene un conjunto de roles y relaciones que definen
el contexto para su comportamiento. El comportamiento es el
conjunto de mensajes intercambiados por los objetos ligados a
los roles. Tal conjunto de mensajes en una colaboración se llama
Interacción. Una colaboración puede incluir una o más
interacciones, como se puede observar en la Figura 3.9.
65
3.2.2.7. Diagrama de Implementación
3.2.2.7.1. Diagramas de Componentes
Los diagramas de componentes describen los elementos físicos
del sistema y sus relaciones. Muestran las opciones de
realización incluyendo código fuente, binario y ejecutable. Los
componentes representan todos los tipos de elementos software
que entran en la fabricación de aplicaciones informáticas.
Pueden ser simples archivos, paquetes de Ada, bibliotecas
cargadas dinámicamente, etc. Las relaciones de dependencia se
utilizan en los diagramas de componentes para indicar que un
componente utiliza los servicios ofrecidos por otro componente.
Un diagrama de componentes representa las dependencias entre
componentes software, incluyendo componentes de código
fuente, componentes del código binario, y componentes
ejecutables. Un módulo de software se puede representar como
componente. Algunos componentes existen en tiempo de
66
compilación, algunos en tiempo de enlace y algunos en tiempo
de ejecución, otros en varias de éstas.
Un componente de sólo compilación es aquel que es
significativo únicamente en tiempo de compilación. Un
componente ejecutable es un programa ejecutable.
Un diagrama de componentes tiene sólo una versión con
descriptores, no tiene versión con instancias. Para mostrar las
instancias de los componentes se debe usar un diagrama de
despliegue.
Un diagrama de componentes muestra clasificadores de
componentes, las clases definidas en ellos, y las relaciones entre
ellas. Los clasificadores de componentes también se pueden
anidar dentro de otros clasificadores de componentes para
mostrar relaciones de definición.
Un diagrama que contiene clasificadores de componentes y de
nodo se puede utilizar para mostrar las dependencias del
compilador, que se representa como flechas con líneas
discontinuas (dependencias) de un componente cliente a un
componente proveedor del que depende. Los tipos de
dependencias son específicos del lenguaje y se pueden
representar como estereotipos de las dependencias.
El diagrama también puede usarse para mostrar interfaces y las
dependencias de llamada entre componentes, usando flechas con
67
líneas discontinuas desde los componentes a las interfaces de
otros componentes.
El diagrama de componente hace parte de la vista física de un
sistema, la cual modela la estructura de implementación de la
aplicación por sí misma, su organización en componentes y su
despliegue en nodos de ejecución. Esta vista proporciona la
oportunidad de establecer correspondencias entre las clases y
los componentes de implementación y nodos. La vista de
implementación se representa con los diagramas de
componentes como se puede observar en la Figura 3.10.
68
3.2.2.7.2. Diagramas de Despliegue
Los Diagramas de Despliegue muestran la disposición física
de los distintos nodos que componen un sistema y el reparto
de los componentes sobre dichos nodos.
La vista de despliegue representa la disposición de las
instancias de componentes de ejecución en instacias de
nodos conectados por enlaces de comunicación. Un nodo es
un recurso de ejecución tal como un computador, un
dispositivo o memoria.
Los nodos se interconectan mediante soportes
bidireccionales que pueden a su vez estereotiparse. Esta vista
permite determinar las consecuencias de la distribución y la
asignación de recursos. Las instancias de los nodos pueden
contener instancias de ejecución, como instancias de
componentes y objetos.
El modelo puede mostrar dependencias entre las instancias y
sus interfaces, y también modelar la migración de entidades
entre nodos u otros contenedores, como se puede observar
en la Figura 3.11.
69
3.2.3. Datos
3.2.3.1. Entidad / Relación
El diagrama de entidad-relación (también conocido como DER, o
diagrama E-R) es un modelo de red que describe con un alto nivel
de abstracción la distribución de datos almacenados en un sistema.
Para el analista, el DER representa un gran beneficio, porque
enfatiza las relaciones entre almacenes de datos en el DFD que de
otra forma se hubiera visto sólo en la especificación de procesos.
Por ejemplo, un DER típico se muestra en la Figura 3.11. Cada
una de las cajas rectangulares corresponden a un almacén de datos
70
en DFD y puede verse que hay relaciones que normalmente no se
aprecian en un DFD.
Hay cuatro componentes principales en un diagrama de entidad-
relación:
1. Tipos de objetos.
2. Relaciones.
3. Indicadores asociativos de tipo de objeto.
4. Indicadores de supertipo/subtipo.
3.2.3.1.1. Tipos de Objetos
El tipo de objeto se representa en un diagrama de entidad-
relación por medio de una caja rectangular. Representa una
colección de objetos (cosas) del mundo real cuyos miembros
individuales o instancias tienen las siguientes características:
71
 Cada una puede identificarse de manera única por algún
medio. Por ejemplo, si se tiene un tipo de objeto conocido
como cliente, debemos ser capaces de distinguir uno de otro
(tal vez por un número de cuenta, por su apellido, o por su
número de Seguro Social).
 Cada uno juega un papel necesario en el sistema que se
construye, es decir, para que el tipo de objeto sea legítimo,
debe poder decirse que el sistema no puede operar sin tener
acceso a esos miembros.
 Cada uno puede describirse por uno o más datos. Es decir,
un cliente puede describirse por medio de datos tales como
nombre, domicilio, límite de crédito y número telefónico.
El objeto es algo material del mundo real, y el tipo de objeto es
su representación en el sistema. Sin embargo, un objeto pudiera
ser algo no material: por ejemplo, horarios, planes, estándares,
estrategias y mapas.
Una persona (o cualquier cosa material) pudiera ser diversos
tipos de objetos distintos en distintos modelos de datos, o incluso
en un mismo modelo. Juan Pérez, por ejemplo puede ser
empleado en un modelo de datos y cliente en otro. También
pudiera ser empleado y cliente dentro del mismo modelo.
72
3.2.3.1.2. Relaciones
Una relación representa un conjunto de conexiones entre objetos,
y se representa por medio de un rombo. La Figura 3.13 muestra
una relación sencilla, que pudiera existir entre dos o más objetos.
Cada instancia de la relación representa una asociación entre cero
o más ocurrencias de un objeto y cero o más ocurrencias del otro.
Así, en la figura 4.2.3, la relación etiquetada como compras
puede contener las siguientes instancias individuales:
 Instancia 1: el cliente 1 compra el artículo 1
 Instancia 2: el cliente 2 compra los artículos 2 y 3.
 Instancia 3: el cliente 3 no compra ningún artículo.
La relación representa algo que debe ser recordado por el
sistema: algo que no pudo haberse calculado ni derivado
mecánicamente. Así, el modelo de datos de la figura 4.2.3 indica
que existe alguna razón relacionada con el usuario para recordar
el hecho de que el cliente 1 compra el artículo 1, etc. Y también
indica que no existe nada priori que hubiera permitido determinar
que el cliente 1 compró el artículo 1 y nada más.
73
3.2.3.1.3. Notación Alternativa para Relaciones
El diagrama E-R son multidireccionales, esto es, puede leerse
siguiendo cualquier dirección. Y no muestran cardinalidad, es
decir, no muestran el número de objetos que participan en la
relación. Una notación alternativa utilizada por algunos analistas
muestra tanto la cardinalidad como la ordinalidad.
3.2.3.1.4. Indicadores Asociativos de Tipo de Objeto
El indicador asociativo de tipo de objeto representa algo que
funciona como objeto y como relación. Por ejemplo, un cliente
que adquiere un artículo. En donde la relación de compra no hace
más que asociar un cliente con uno o más artículos. Pero suponga
que existen datos que deseamos recordar acerca de cada instancia
de una compra (por ejemplo a qué hora del día se hizo). ¿Dónde
se podría almacenar dicha información? "Hora del día" no es un
atributo de cliente, ni de artículo. Más bien, se asocia "Hora del
día" con la compra misma, y esto se muestra en un diagrama
como el que ilustra la Figura 3.14.
74
Nótese que compra ahora se escribe dentro de una caja
rectangular conectada por medio de líneas dirigidas, a un
rombo de relación sin nombre. Esto pretende indicar que
compra funciona como:
Un tipo de objeto, algo acerca de lo cual se desea almacenar
información. En este caso la hora en la cual se realizó la
compra y el descuento, que se dio al cliente. Una relación que
conecta los dos tipos de objetos cliente y artículo. Lo que
significa aquí es que cliente y artículo se mantienen solo.
Existirían con o sin la compra.
3.2.3.1.5. Indicadores de Subtipo/Supertipo
Los tipos de objetos de subtipo/supertipo consisten en tipos de
objeto de una o más subcategorías, conectados por una
relación. La Figura 3.15 muestra un subtipo /supertipo típico:
la categoría general es empleado y las subcategorias son
empleados asalariados y empleados por horas. Nótese que los
subtipos se conectan al supertipo por medio de una relación sin
nombre. Note también que el supertipo se conecta con una
línea que contiene una barra.
75
3.2.3.1.6. Reglas para la Construcción de Diagramas de
Entidad- Relación.
El primer DER típicamente se creará a apartir de entrevista
iniciales con el usuario, y de su conocimiento de la materia en
cuanto al negocio del usuario. Después de desarrollar el primer
DER, el siguiente paso es asignar los datos del sistema a los
diversos tipos de objetos. Se supone, que se sabe cuales son los
datos. Esto puede suceder en cualquier de tres maneras:
 Si el modelo del proceso (DFD) ya se ha desarrollado o se
está desarrollando paralelamente al modelo de datos,
entonces el diccionario de datos ya existirá.
 Si el modelo del proceso no se ha desarrollado o no tiene
intención de desarrollar, entonces pudiera tener que
empezar por entrevistar a todos los usuarios apropiados para
construir una lista exhaustiva de datos y sus definiciones.
 Si está trabajando con un grupo de administración de datos,
hay una buena probabilidad de que ya exista un diccionario
de datos, que podría obtener durante el proyecto.
Existe un número de situaciones en las que los refinamientos
del DER llevan a la eliminación de tipos de objetos y relaciones
redundantes o erróneas. Las más comunes son:
 Tipos de objetos que consisten en un identificador.
76
 Tipos de objetos para los cuales existe una sola
instancia.
 Tipos asociativos de objetos flotantes.
 Relaciones derivadas.
3.2.3.2 Normalización
Normalización es un conjunto de reglas que sirven para ayudar a
los diseñadores a desarrollar un esquema que minimice los
problemas de lógica. Cada regla está basada en la que le antecede.
La normalización se adoptó porque el viejo estilo de poner todos
los datos en un solo lugar, como un archivo o una tabla de la base
de datos, era ineficiente y conducía a errores de lógica cuando se
trataba de manipular los datos. Por ejemplo, vea la base de datos
Mi Tienda. Si almacena todos los datos en la tabla Clientes, ésta
podría verse como se muestra a continuación:
Clientes
ID_Cliente
Nombre
Apellidos
Nombre_Producto1
Costo_Producto1
Imagen_Producto1
Nombre_Producto2
Costo_Producto2
Imagen_Producto2
77
Fecha_Pedido
Cantidad_Pedido
Nombre_Cia_Envios
La tabla se ha descrito de manera abreviada pero aun así representa
la idea general.
¿Cómo podría añadir un nuevo cliente en su tabla Clientes?
Debería añadir un producto y un pedido también. ¿Qué tal si
quisiera emitir un informe de todos los productos que vende? No
podría separar fácilmente los productos de los clientes con una
simple instrucción SQL. Lo bello de las bases de datos relacionales,
si están bien diseñadas, es que puede hacer esto fácilmente.
La normalización también hace las cosas fáciles de entender. Los
seres humanos tenemos la tendencia de simplificar las cosas al
máximo. Lo hacemos con casi todo desde los animales hasta con
los automóviles. Vemos una imagen de gran tamaño y la hacemos
menos compleja agrupando cosas similares juntas. Las guías que la
normalización provee crean el marco de referencia para simplificar
la estructura. En la base de datos de muestra es fácil detectar que
usted tiene tres diferentes grupos: clientes, productos y pedidos. Si
sigue las guías de la normalización, podría crear las tablas
basándose en estos grupos.
El proceso de normalización tiene un nombre y una serie de reglas
78
para cada fase. Esto puede parecer un poco confuso al principio,
pero poco a poco irá entendiendo el proceso, así como las razones
para hacerlo de esta manera. A la mayoría de la gente le encantan
las hojas de cálculo por la forma en la que manejan sus datos. El
tiempo que le lleve reconfigurar su esquema para ajustarlo al
proceso de normalización, siempre será bien invertido. Al fin y al
cabo, esto le tomará menos tiempo que el que tendría que invertir,
para cortar y pegar sus columnas de datos para generar el informe
que quiere su jefe.
Otra ventaja de la normalización de su base de datos es el consumo
de espacio. Una base de datos normalizada puede ocupar menos
espacio en disco que una no normalizada. Hay menos repetición de
datos, lo que tiene como consecuencia un mucho menos uso de
espacio en disco.
3.2.3.2.1. Grados de Normalización
Existen básicamente tres niveles de normalización: Primera Forma
Normal (1NF), Segunda Forma Normal (2NF) y Tercera Forma
Normal (3NF). Cada una de estas formas tiene sus propias reglas.
Cuando una base de datos se conforma a un nivel, se considera
normalizada a esa forma de normalización. Por ejemplo,
supongamos que su base de datos cumple con todas las reglas del
segundo nivel de normalización.
79
Se considera que está en la Segunda Forma Normal. No siempre es
una buena idea tener una base de datos conformada en el nivel más
alto de normalización. Puede llevar aun nivel de complejidad que
pudiera ser evitado si estuviera en un nivel más bajo de
normalización.
3.2.3.2.1.1. Primera Forma Normal
La regla de la Primera Forma Normal establece que las columnas
repetidas deben eliminarse y colocarse en tablas separadas. Ésta es
una regla muy fácil de seguir.
Observe el esquema de la tabla Clientes de la base de datos.
Clientes
ID Cliente
Nombre
Apellidos
Nombre_Producto1
Costo_Producto1
Imagen_Producto1
Nombre_Producto2
Costo_Producto2
80
Imagen_Producto2
Fecha_Pedido
Cantidad_Pedido
Nombre Cia Envios
La tabla tiene varias columnas repetidas. Éstas se refieren

principalmente a los productos. De acuerdo con la regla, debe
eliminar las columnas repetidas y crearles su propia tabla.
Eliminación de datos repetidos en una base de datos
Clientes Pedidos
ID_Clientes Nombre_Productos
Nombre Costo_Producto
Apellidos Imagen_Producto
Direccion
Numero_Pedido
Fecha_Pedido
Cantidad_Pedido
Clave_Cia_Envios
Nombre_Ci_ Envios
81
Ahora tiene dos tablas. Pero todavía hay un problema. No hay
forma de relacionar los datos de la tabla original con los de la
nueva tabla. Para hacerlo, debe añadir un campo clave a la segunda
tabla de forma que se establezca la relación. Añada a la tabla
Productos una clave primaria que se llame ID_Producto y añada
una clave a la tabla Clientes que la relacione con la tabla Productos.
El campo ID_Producto es el candidato ideal.
Clientes Pedidos
ID_Productos ID_Productos
ID_Clientes Nombre_Productos
Nombre Costo_Producto
Apellidos Imagen_Producto
Direccion
Numero_Pedido
Fecha_Pedido
Cantidad_Pedido
Clave_Cia_Envios
82
Así, se ha establecido una relación uno a varios. Ésta representa lo
que la base de datos estará haciendo en la vida real. El cliente
tendrá muchos productos que podrá comprar, sin importar cuántos
clientes quieran comprarlos también. Además, el cliente necesitará
haber pedido un producto para ser un cliente. Usted ya no está
obligado a añadir un cliente cada vez que añade un nuevo producto
a su inventario.
Poner la base de datos en la Primera Forma Normal resuelve el
problema de los encabezados de columna múltiples. Muy a
menudo, los diseñadores de bases de datos inexpertos harán algo
similar a la tabla no normalizada. Una y otra vez, crearán columnas
que representen los mismos datos. En una empresa de servicios de
electricidad, había una base de datos para el control de refacciones
de una planta nuclear. La tabla de su base de datos, la cual contenía
los números de parte de las refacciones, tenía una columna repetida
más de treinta veces. Cada vez que una nueva parte se tenía que dar
de alta, se creaba una nueva columna para almacenar la
información. Obviamente, el diseño de la base de datos era bastante
pobre y, por lo mismo, resultaba una pesadilla para su
rogramadores-administradores.
La normalización ayuda a clarificar la base de datos ya organizarla
en partes más pequeñas y más fáciles de entender. En lugar de tener
83
que entender una tabla gigantesca y monolítica que tiene muchos
diferentes aspectos, usted sólo tiene que entender objetos pequeños
y más tangibles, así como las relaciones que guardan con otros
objetos también pequeños. No es necesario mencionar que un
mejor entendimiento del funcionamiento de su base de datos
conducirá aun mejor aprovechamiento de sus activos.
3.2.3.2.1.2. Segunda Forma Normal
La regla de la Segunda Forma Normal establece que todas las
dependencias parciales se deben eliminar y separar dentro de sus
propias tablas. Una dependencia parcial es un término que describe
a aquellos datos que no dependen de la clave de la tabla para
identificarlos. En la base de datos de muestra, la información de
pedidos está en cada uno de los registros. Sería mucho más simple
utilizar únicamente el número del pedido. El resto de la
información podría residir en su propia tabla. Una vez que haya
organizado la información de pedidos.
Eliminación de las dependencias parciales- Segunda Forma Normal
Clientes Pedidos Productos
ID_Productos ID_Productos ID_Producto
ID_Clientes Nombre_Productos Fecha_Compra
Nombre Cantidad_Pedido
Costo_Producto
84
Apellidos Imagen_Productos
Direccion
Numero_Pedido
Nombre_Cia_Envios
De nuevo, al organizar el esquema de esta forma puede reflejar el
mundo real en su base de datos. Tendría que hacer algunos cambios
en sus reglas del negocio para que esto fuera aplicable, pero para
ilustrar la normalización, así está bien.
Una de las mayores desventajas de la normalización es el tiempo
que lleva hacerlo. La mayoría de la gente está demasiado ocupada,
y emplear tiempo para asegurarse de que sus datos están
normalizados cuando todo funciona más o menos bien, parece ser
un desperdicio de tiempo. Pero no es así. Usted tendrá que emplear
más tiempo arreglando una base de datos no normalizada que el
que emplearía en una normalizada.
Al haber alcanzado la Segunda Forma Normal, usted puede
disfrutar de algunas de las ventajas de las bases de datos
relacionales. Por ejemplo, puede añadir nuevas columnas a la tabla
Clientes sin afectar a las tablas Productos y Pedidos. Lo mismo
aplica para las otras tablas. Alcanzar este nivel de normalización
permite que los datos se acomoden de una manera natural dentro de
los límites esperados.
85
Una vez que ha alcanzado el nivel de la Segunda Forma Normal, se
han controlado la mayoría de los problemas de lógica. Puede
insertar un registro sin un exceso de datos en la mayoría de las
tablas. Observando un poco más de cerca la tabla Clientes, vemos
la columna Nombre_Cia_Envios. Ésta no es dependiente del
cliente. El siguiente nivel de normalización explicará cómo
solucionar esto.
3.2.3.2.1.3. Tercera Forma Normal.
La regla de la Tercera Forma Normal señala que hay que eliminar y
separar cualquier dato que no sea clave. El valor de esta columna
debe depender de la clave. Todos los valores deben identificarse
únicamente por la clave. En la base de datos de muestra, la tabla
Clientes contiene la columna Nombre_Cia_Envios, la cual no se
identifica únicamente por la clave. Podría separar estos datos de la
tabla y ponerlos en una tabla aparte.
Eliminación de los datos que no son claves para la Tercera Forma
Normal
Cliente
ID_cliente, ID_Producto, Numero Pedido. ID_Cia_Envios,
Nombre, Apellido, Direccion
Productos
ID_Producto, Nombre_Producto, Costos_Productos,
Foto_Producto
86
PedidoMaestro
ID_Pedido, Fecha_Pedido, Cantidad_Pedidos
PedidoDetallado
ID_PedidoDetallado, ID_Pedido, Fecha_Pedido
Cias_Envios
ID_Cia_Envios, Nombre_Cia_Envios.
Ahora todas sus tablas están en la Tercera Forma Normal. Esto le
da más flexibilidad y previene errores de lógica cuando inserta o
borra registros. Cada columna en la tabla está identificada de
manera única por la clave, y no hay datos repetidos. Esto provee un
esquema limpio y elegante, que es fácil de trabajar y expandir.
Qué tan lejos debe llevar la normalización?
La siguiente decisión es ¿qué tan lejos debe llevar la
normalización? La normalización es una ciencia subjetiva.
Determinar las necesidades de simplificación depende de usted. Si
su base de datos va a proveer información aun solo usuario para un
propósito simple y existen pocas posibilidades de expansión,
normalizar sus datos hasta la 3FN sea quizá algo extremoso. Las
reglas de normalización existen como guías para crear tablas que
sean fáciles de manejar, así como flexibles y eficientes.
A veces puede ocurrir que normalizar sus datos hasta el nivel más
87
alto no tenga sentido. Por ejemplo, suponga que añade una columna
extra para la dirección en su base de datos. Es muy normal tener
dos líneas para la dirección. El esquema de la tabla podría verse
como se muestra a continuación:
ID_Cliente
Nombre
Apellidos
Direccion1
De acuerdo con las reglas, si aplica la Primera Forma Normal, la
columna de dirección debería sacarse de esta tabla y
reemplazarse con la clave de una nueva tabla. El resultado de este
esquema se nuestra a continuación:
ID_Ciente ID_Direccion
Nombre ID_Cliente
Apellidos Direccion
La base de datos ahora cumple con la Primera Forma Normal. Los
clientes pueden tener más de una dirección. El problema aquí es
88
que usted ha complicado demasiado una idea simple, por tratar de
seguir las reglas de normalización. En el ejemplo mostrado, la
segunda dirección es totalmente opcional. Está ahí sólo para
colectar información que pudiera utilizarse como información de
contacto. No hay necesidad de partir la tabla en dos y forzar las
reglas de la normalización. En esta instancia, el exceso de
normalización frustra el propósito para el que se utilizan los datos.
Añade, de manera innecesaria, un nivel más de complejidad. Una
buena forma de determinar si está llevando demasiado lejos su
normalización, es ver el número de tablas que tiene. Un número
grande de tablas pudiera indicar que está normalizando demasiado.
Observe su esquema.
¿Está dividiendo tablas sólo para seguir las reglas o estas divisiones
son en verdad prácticas? Éstas son el tipo de cosas que usted, el
diseñador de la base de datos, necesita decidir. La experiencia y el
sentido común lo pueden auxiliar para tomar la decisión correcta.
La normalización no es una ciencia exacta es subjetiva.
Existen seis niveles más de normalización que no se han discutido
aquí. Ellos son Forma Normal Boyce-Codd, Cuarta Forma Normal
(4NF), Quinta Forma Normal (5NF) o Forma Normal de
Proyección-Unión, Forma Normal de Proyección-Unión Fuerte,
Forma Normal de Proyección-Unión Extra Fuerte y Forma Normal
de Clave de Dominio. Estas formas de normalización pueden llevar
las cosas más allá de lo que necesita. Éstas existen para hacer una
89
base de datos realmente relacional. Tienen que ver principalmente
con dependencias múltiples y claves relacionales.
3.2.3.3. Interfaces de E/S
Introducción:
Un sistema de información es un conjunto de elementos que
interactúan entre sí con el fin de apoyar las actividades de una
empresa o negocio.
El equipo computacional: el hardware necesario para que el sistema
de información pueda operar.
El recurso humano que interactúa con el Sistema de Información, el
cual está formado por las personas que utilizan el sistema.
Un sistema de información realiza cuatro actividades básicas:
entrada, almacenamiento, procesamiento y salida de información.
3.2.3.3.1.1. Entrada de Información
Es el proceso mediante el cual el Sistema de Información toma los
datos que requiere para procesar la información. Las entradas
pueden ser manuales o automáticas. Las manuales son aquellas que
se proporcionan en forma directa por el usuario, mientras que las
automáticas son datos o información que provienen o son tomados
de otros sistemas o módulos. Esto último se denomina interfases
automáticas.
90
Las unidades típicas de entrada de datos a las computadoras son las
terminales, las cintas magnéticas, las unidades de diskette, los
códigos de barras, los escáners, la voz, los monitores sensibles al
tacto, el teclado y el mouse, entre otras.
3.2.3.3.1.2. Almacenamiento de Información
El almacenamiento es una de las actividades o capacidades más
importantes que tiene una computadora, ya que a través de esta
propiedad el sistema puede recordar la información guardada en la
sección o proceso anterior. Esta información suele ser almacenada
en estructuras de información denominadas archivos. La unidad
típica de almacenamiento son los discos magnéticos o discos duros,
los discos flexibles o diskettes y los discos compactos (CD-ROM).
3.2.3.3.1.3. Procesamiento de Información
Es la capacidad del Sistema de Información para efectuar cálculos
de acuerdo con una secuencia de operaciones preestablecida. Estos
cálculos pueden efectuarse con datos introducidos recientemente en
el sistema o bien con datos que están almacenados. Esta
característica de los sistemas permite la transformación de datos
fuente en información que puede ser utilizada para la toma de
decisiones, lo que hace posible, entre otras cosas, que un tomador
de decisiones genere una proyección financiera a partir de los datos
que contiene un estado de resultados o un balance general de un
año base.
91
3.2.3.3.1.4. Salida de Información
La salida es la capacidad de un Sistema de Información para sacar
la información procesada o bien datos de entrada al exterior. Las
unidades típicas de salida son las impresoras, terminales, diskettes,
cintas magnéticas, la voz, los graficadores y los plotters, entre
otros. Es importante aclarar que la salida de un Sistema de
Información puede constituir la entrada a otro Sistema de
Información o módulo. En este caso, también existe una interfase
automática de salida. Por ejemplo, el Sistema de Control de
Clientes tiene una interfase automática de salida con el Sistema de
Contabilidad, ya que genera las pólizas contables de los
movimientos procesales de los clientes.
A continuación se muestran las diferentes actividades que puede
realizar un Sistema de Información de Control de Clientes:
3.2.3.3.2. Actividades que realiza un Sistema de Información:
Entradas:
 Datos generales del cliente: nombre, dirección, tipo
de cliente, etc.
 Políticas de créditos: límite de crédito, plazo de
pago, etc.
 Facturas (interfase automático).
 Pagos, depuraciones, etc.
92
Proceso:
 Cálculo de antigüedad de saldos.
 Cálculo de intereses moratorios.
 Cálculo del saldo de un cliente.
Almacenamiento:
 Movimientos del mes (pagos, depuraciones).
 Catálogo de clientes.
 Facturas.
Salidas:
 Reporte de pagos.
 Estados de cuenta.
 Pólizas contables (interfase automática)
 Consultas de saldos en pantalla de una terminal.
3.2.3.3.3. Tipos y Usos de los Sistemas de Información
Durante los próximos años, los Sistemas de Información cumplirán
tres objetivos básicos dentro de las organizaciones:
 Automatización de procesos operativos.
 Proporcionar información que sirva de apoyo al proceso
de toma de decisiones.
 Lograr ventajas competitivas a través de su
implantación y uso.
93
3.3. Construcción
3.3.1. Base de Datos
Los programas de bases de datos son administradores de información
que ayudan a aligerar la sobrecarga de información. Los programas de
bases de datos son una aplicación: sirven para convertir los
computadores en herramientas productivas.
Una base de datos es una colección integrada de datos almacenados en
diferentes tipos de registros. Los registros se interrelacionan por medio
de relaciones propias de los datos y no mediante su ubicación física en
el almacenamiento.
El propósito de una base de datos es representar las relaciones entre las
entidades de interés. Organizar los datos de este modo facilita la
integración de las áreas dentro de la organización y simplifican las
preguntas específicas, incluso las formuladas por quienes no son
programadores.
Tener bases de datos no elimina la necesidad de archivos en un sistema
de información:
Los archivos de transacciones son necesarios para capturar detalles de
las actividades de la organización. Los archivos maestros también
pueden requerirse en virtud de que no todos los datos necesitan residir
en la base de datos. Los archivos de clasificación son esenciales
cuando se deben reordenar los datos.
94
Las ventajas de las bases de datos computarizadas, frente a las de papel
son que
 Facilitan: el almacenamiento de grandes cantidades de
información: Conforme aumenta la masa de información,
mayor será el beneficio de una base de datos.
 La recuperación rápida y flexible de información; la
organización y reorganización de la información; la impresión
y distribución de información en varias formas.
Una base de datos esta formada por uno o más archivos. Un archivo es
una colección de información relacionada (en este caso se trata de un
archivo de datos creado por un programa de base de datos).
Un archivo en una base de datos es una colección de registros. Un
registro es la información relacionada con una persona, producto o
suceso.
Cada trozo discreto de información en un registro se denomina campo.
El tipo de información que puede contener un campo está determinado
por el tipo de campo: de texto, numérico, de fecha. Además de estos
campos estándar puede haber campos que contengan gráficos,
fotografías digitalizadas, sonidos y videos. Los campos calculados
contienen fórmulas similares a las de una hoja de cálculo y exhiben
valores calculados a partir de valores de otros campos numéricos.
95
La mayoría de las bases de datos ofrecen más de una forma de ver los
datos, entre ellas:
o Vistas de formulario: muestran un registro cada vez;
o Vistas de lista: exhiben varios registros en listas similares a
una hoja de cálculo.
En ambos casos se pueden acomodar los campos sin modificar los
datos subyacentes.
3.3.1.1. Objetos de la Base de Datos
Tablas: unidades donde crearemos el conjunto de datos de nuestra
base de datos. Estos datos estarán ordenados en columnas
verticales. Aquí definiremos los campos y sus características.
Consultas: Aquí definiremos las preguntas que formularemos a la
base de datos con el fin de extraer y presentar la información
resultante de diferentes formas (pantalla, impresora...)
Formulario: Elemento en forma de ficha que permite la gestión de
lo datos de una forma más cómoda y visiblemente más atractiva.
Informe: Permite preparar los registros de la base de datos de
forma personalizada para imprimirlos.
96
Macro: Conjunto de instrucciones que se pueden almacenar para
automatizar tareas repetitivas.
Módulo: Programa o conjunto de instrucciones en lenguaje Visual
Basic.
3.3.2. Enlace de Objetos
Es posible crear orígenes de datos a partir de cualquier objeto que
expone una o más propiedades públicas. No se requieren interfaces
concretas ni constructores públicos predeterminados para crear un
origen de datos desde un objeto. Todas las propiedades públicas se
muestran en la ventana Orígenes de datos y pueden arrastrarse a
formularios para crear controles enlazados a datos.
3.4. Test (Prueba)
3.4.1. Disciplina de Pruebas de Software
Esta disciplina complementa a la gestión de la calidad, toda vez que
tiene como propósito principal el aseguramiento y el control de la
calidad del producto final, el software. Las actividades de esta
disciplina se llevan a cabo a lo largo de las cuatro fases, sin
embargo consideramos crítico establecer con el Cliente el alcance
de las pruebas necesarias para cada proyecto, por lo que a
continuación exponemos brevemente las principales formas como
se puede probar un sistema, cada una de las cuales tiene un objetivo
específico y una técnica que lo soporta.
97
Prueba de Estructura Web.- Es el tipo de prueba que se enfoca
en certificar que todos los enlaces del sitio web estén conectados a
la página web que le corresponde, y que no hay contenido que no
pueda ser consultado de ninguna manera (contenido huérfano).
Prueba de Funcionalidad.- Es el tipo de prueba que se enfoca en
certificar que el funcionamiento del sistema esté acorde a lo
descrito en el documento de especificaciones funcionales, esto es
que provea los casos de uso que ahí se indican, y de la manera
como ahí se especifica.
Prueba de Seguridad Funcional.- Es el tipo de prueba que se
enfoca en certificar que los datos y las funciones del sistema solo
son accesibles por los actores debidamente autorizados, acorde a lo
descrito en el documento de especificaciones funcionales.
Prueba de Volumen Funcional.- Es el tipo de prueba que se
enfoca en certificar la capacidad del sistema de manejar volúmenes
de datos extremos, acorde a lo descrito en el documento de
especificaciones funcionales.
Prueba de Robustez.- Es el tipo de prueba que se enfoca en
certificar la capacidad de resistencia a fallar que tiene el sistema,
acorde a lo descrito en el documento de especificaciones técnicas.
98
Prueba de Estructura de Programas.- Es el tipo de prueba que se
enfoca en comprobar que los programas han sido codificados de
acuerdo a los estándares de programación establecidos.
Prueba de Resistencia (Stress).- Es el tipo de prueba que se
enfoca en comprobar cuál es el comportamiento del sistema bajo
condiciones anormales, por ejemplo carencia de recursos de
memoria, procesador, sistemas externos con los que interactúa y
carga excesiva de trabajo. El objetivo de estas pruebas es
identificar las partes débiles del sistema, de modo que se puedan
establecer los planes de contingencia adecuados y se puedan
presupuestar los planes de adquisición correspondientes.
Prueba de Concurrencia.- Es el tipo de prueba que se enfoca en
certificar la capacidad del sistema de atender múltiples solicitudes
departe de los actores que acceden a un mismo recurso (un dato que
esté almacenado en memoria, un conjunto de registros en base de
datos o una interfaz con un dispositivo de hardware o un sistema
externo). Este tipo de pruebas también reciben el nombre de
pruebas de contención.
Prueba de Rendimiento.- Es el tipo de prueba que se enfoca en
comprobar los tiempos de respuesta del sistema en una cantidad
limitada de escenarios de trabajo (a nivel de número de usuarios y
99
número de transacciones), bajo una configuración de hardware y
software constante. Este tipo de pruebas también reciben el
nombre de pruebas de carga. Los resultados de este tipo de pruebas
permitirán establecer los planes de contingencia apropiados y
presupuestar los planes de adquisición necesarios.
Prueba de Instalación.- Es el tipo de prueba que se enfoca en
certificar que el sistema está operativo y listo para ser utilizado
después de ser instalado sobre la configuración de hardware y
software establecida en el manual de instalación.
Prueba de Vulnerabilidad.- Es el tipo de prueba que se enfoca en
comprobar las vulnerabilidades del entorno de comunicaciones
donde el sistema va a funcionar (la red), con la finalidad de
establecer los planes de contingencia adecuados y de presupuestar
los planes de adquisición correspondientes.
3.4.2. Preparación del Entorno de las Pruebas
Unitarias
En esta tarea se preparan todos los recursos necesarios para realizar
las pruebas unitarias de cada uno de los componentes del sistema
de información.
Para ello, se asegura la disponibilidad del entorno y de los datos
necesarios para ejecutar estas pruebas, se preparan las bibliotecas o
librerías oportunas para la realización de las mismas, así como los
100
procedimientos manuales o automáticos necesarios, conforme a la
especificación del entorno definida en el plan de pruebas.
Productos
o De entrada
 Plan de Pruebas
o De salida
 Entorno de Pruebas Unitarias
Participantes
o Técnicos de Sistemas
o Programadores
o Tarea: Realización y Evaluación de las Pruebas Unitarias
El objetivo de esta tarea es comprobar el correcto funcionamiento
de los componentes del sistema de información, codificados en la
actividad Generación del Código de los Componentes y
Procedimientos, conforme a las verificaciones establecidas en el
plan de pruebas para el nivel de pruebas unitarias, en la actividad
Especificación Técnica del Plan de Pruebas.
Para cada verificación establecida, se realizan las pruebas con los
casos de pruebas asociados, efectuando el correspondiente análisis
y evaluación de los resultados, y generando un registro conforme a
los criterios establecidos en el plan de pruebas.
Seguidamente, se analizan los resultados de las pruebas unitarias,
evaluándose las mismas para comprobar que los resultados son los
esperados.
101
Productos
o De entrada
o Producto Software
o Entorno de Pruebas Unitarias
o Plan de Pruebas
o De salida
o Resultado y evaluación de las Pruebas Unitarias
Prácticas
o Pruebas Unitarias
o Pruebas de Integración
Participantes
o Equipo del Proyecto
3.4.3. Ejecución de las Pruebas de Integración
El objetivo de las pruebas de integración es verificar si los componentes o
subsistemas interactúan correctamente a través de sus interfaces, tanto
internas como externas, cubren la funcionalidad establecida, y se ajustan a
los requisitos especificados en las verificaciones correspondientes.
Esta actividad se realiza en paralelo a las actividades Generación del
Código de los Componentes y Procedimientos y Ejecución de las Pruebas
Unitarias.
3.4.4. Preparación del Entorno de las Pruebas de Integración
102
En esta tarea se disponen todos los recursos necesarios para realizar las
pruebas de integración de los componentes y subsistemas que conforman
el sistema de información.
Productos
o De entrada
o Plan de Pruebas
o De salida
o Entorno de Pruebas de Integración
Participantes
o Especialistas en Comunicaciones
o Equipo de Arquitectura
3.4.5. Realización de las Pruebas de Integración
El objetivo de esta tarea es verificar el correcto funcionamiento de
las interfaces existentes entre los distintos componentes y
subsistemas, conforme a las verificaciones establecidas para el
nivel de pruebas de integración.
e informe de los resultados de cada verificación, y generando un
registro conforme a los criterios establecidos en el plan de pruebas.
103
Productos de Entrada
o Producto Software
o Entorno de Pruebas de Integración
o Plan de Pruebas
Productos de Salida
o Resultado de las Pruebas de Integración
Prácticas
o Pruebas de Integración
Participantes
3.4.6. Evaluación del Resultado de las Pruebas de Integración
El objetivo de esta tarea es analizar los resultados de las pruebas de
integración y efectuar su evaluación. - Indicar si el plan de pruebas
debe volver a realizarse total o parcialmente, y si será necesario
contemplar nuevos casos de prueba no considerados anteriormente.
o Resultado de las Pruebas de Integración
o Plan de Pruebas
Productos de Salida
o Evaluación del Resultado de las Pruebas de Integración
Participantes
o Analistas
104
3.4.7. Ejecución de las Pruebas del Sistema
El objetivo de las pruebas del sistema es comprobar la integración
del sistema de información globalmente, verificando el
funcionamiento correcto de las interfaces entre los distintos
subsistemas que lo componen y con el resto de sistemas de
información con los que se comunica.
En la realización de estas pruebas es importante comprobar la
cobertura de los requisitos, dado que su incumplimiento puede
comprometer la aceptación del sistema por el equipo de operación
responsable de realizar las pruebas de implantación del sistema,
que se llevarán a cabo en el proceso Implantación y Aceptación del
Sistema.
3.4.8. Preparación del Entorno de las Pruebas del Sistema
En esta tarea se preparan todos los recursos necesarios para realizar
las pruebas del sistema, de acuerdo a las características del entorno
establecidas en el plan de pruebas.
o Plan de Pruebas (DSI 10.3)
Productos de Salida
o Entorno de Pruebas del Sistema
Participantes
o Especialistas en Comunicaciones
o Equipo de Arquitectura
105
3.4.9. Realización de las Pruebas del Sistema
El objetivo de esta tarea es comprobar la integración de todos los
subsistemas y componentes del sistema de información, así como la
interacción del mismo con otros sistemas de información con los
que se relaciona, de acuerdo a las verificaciones establecidas para
el nivel de pruebas del sistema.
e informe de los resultados y generando un registro conforme a los
criterios establecidos en el plan de pruebas.
o Producto Software
o Entorno de Pruebas del Sistema
o Plan de Pruebas (DSI 10.3)
Productos de salida
o Resultado de las Pruebas del Sistema
Prácticas
o Pruebas del Sistema
Participantes
3.4.10. Evaluación del Resultado de las Pruebas del Sistema
El objetivo de esta actividad es analizar los resultados de las
pruebas del sistema de información y efectuar su evaluación. -
106
Indicar si el plan de pruebas debe volver a realizarse total o
parcialmente, y si será necesario contemplar nuevos casos de
prueba no considerados anteriormente.
o Resultado de las pruebas del Sistema
o Plan de Pruebas
Productos de Salida
o Evaluación del Resultado de las Pruebas del Sistema
Participantes
o Analistas
o Jefe de Proyecto
3.5. Entrega de Proyecto
La entrega del proyecto se realiza cuando se pone el producto en manos de
los usuarios finales, se requiere desarrollar nuevas versiones actualizadas
del producto, completar la documentación, entrenar al usuario en el
manejo del producto, y en general tareas relacionadas con el ajuste,
configuración, instalación y usabilidad del producto.
3.6. Workflow Colaborativo
Involucra procesos estructurados o semi-estructurados que permiten a
varias personas participar en un grupo de trabajo, ejemplos de ello lo
constituyen el diseño arquitectónico o ingenieril, generación de informes,
producción de material publicitario, revisión de documentos legales, etc.
Estos procesos involucran típicamente un "documento" que hace las veces
de contenedor de la información, viajando de paso en paso y en cada uno
107
de ellos el partícipe realiza una tarea o acción sobre el "documento". Por
tanto, las características esenciales de workflow colaborativo son las
siguientes:
 El "documento" y el "proceso" son claves. Es importante para la
aplicación preservar la integridad tanto del documento como del
proceso.
 Fundamentalmente participan "knowledge workers", por tanto está
restringido a ciertos grupos "creativos" dentro de la organización.
 Es importante que una buena solución no sea "intrusiva" ya que el
trabajo de conocimiento es un proceso mental que involucra la
creatividad, la que no se desea restringir o encasillar.
 El workflow colaborativo debe ser muy flexible ya que el trabajo
creativo puede tomar rumbos inesperados.
 Las soluciones de workflow colaborativo suelen estar centradas en
el "documento".
3.6.1. Administración y Configuración del Cambio
 Consiste en controlar los cambios y mantener la integridad de
los productos que incluye el proyecto.
 Incluye:
 Identificar los elementos configurables.
 Restringir los cambios en los elementos configurables.
 Auditar los cambios hechos a estos elementos.
108
 Definir y mantener las configuraciones de estos
elementos.
 Los métodos, procesos y herramientas usadas para
proveer la administración y configuración del cambio
pueden ser consideradas como el sistema de
administración de la configuración.
3.6.2. Administración de Proyectos
El propósito de la Administración de Proyectos es:
 Proveer un marco de trabajo para administrar los proyectos
intensivos de software.
 Proveer guías prácticas para la planeación, soporte,
ejecución y monitoreo de proyectos.
 Proveer un marco de trabajo para la administración del
riesgo.
3.6.3. Medio Ambiente
 Se enfoca en las actividades necesarias para configurar el
proceso al proyecto.
 Describe las actividades requeridas para desarrollar las
líneas guías de apoyo al proyecto.
 El propósito de las actividades de ambiente es proveer a las
organizaciones de desarrollo de software del ambiente
necesario (herramientas y procesos) que den soporte al
equipo de desarrollo.
109
CAPITULO 4
DESCRIPCION DE CASOS DE ESTUDIO USANDO RUP
Descripción del caso de USO
Detalle del modelo
Análisis de Resultados
4. Plan de Desarrollo de Software
4.1. Propósito
El propósito del Plan de Desarrollo de Software es proporcionar la
información necesaria para controlar el proyecto. En él se describe el
enfoque de desarrollo del software.
4.2. Alcance
El Plan de Desarrollo del Software describe el plan global usado para el
desarrollo del “Sistema para Gestión de Artículos Deportivos LSI 03”. El
detalle de las iteraciones individuales se describe en los planes de cada
iteración, documentos que se aportan en forma separada. Posteriormente,
el avance del proyecto y el seguimiento en cada una de las iteraciones
ocasionará el ajuste de este documento produciendo nuevas versiones
actualizadas.
110
4.3. Vista General del Proyecto
4.3.1. Propósito, Alcance y Objetivos
Deportes LSI 03 lleva a cabo la venta al por mayor de artículos
deportivos a nivel internacional. Por ello, Deportes LSI 03
considera necesario el desarrollo de un nuevo sistema de gestión de
los artículos deportivos que forman parte de sus catálogos, así
como las bases de datos que recogen datos tanto estadísticos,
empresariales como de nóminas, plantillas de personal, etc.
El proyecto debe proporcionar una propuesta para el desarrollo de
todos los subsistemas implicados en la gestión de artículos
deportivos y bases de datos departamentales”. Estos subsistemas se
pueden diferenciar en siete grandes bloques:
 Gestión de Ventas
 Gestión de Almacenes
 Gestión de Envíos
 Departamento de Recursos Humanos.
 Departamento de Marketing.
 Departamento de Logística.
 Contabilidad y Facturación.
111
4.3.2. Entregables del Proyecto
Es preciso destacar que de acuerdo a la filosofía de RUP (y de todo
proceso iterativo e incremental), todos los artefactos son objeto de
modificaciones a lo largo del proceso de desarrollo, con lo cual,
sólo al término del proceso podríamos tener una versión definitiva
y completa de cada uno de ellos.
4.3.3. Plan de Desarrollo del Software
Es el presente documento.
4.3.4. Modelo de Casos de Uso del Negocio
Es un modelo de las funciones de negocio vistas desde la
perspectiva de los actores externos (Agentes de registro,
solicitantes finales, otros sistemas etc.). Este modelo se representa
con un Diagrama de Casos de Uso usando estereotipos específicos
para este modelo.
4.3.5. Modelo de Casos de Uso
El modelo de Casos de Uso presenta las funciones del sistema y los
actores que hacen uso de ellas. Se representa mediante Diagramas
de Casos de Uso.
112
4.3.6. Visión
Este documento define la visión del producto desde la perspectiva
del cliente, especificando las necesidades y características del
producto. Constituye una base de acuerdo en cuanto a los requisitos
del sistema.
4.3.7. Modelo de Implementación
Este modelo es una colección de componentes y los subsistemas
que los contienen. Estos componentes incluyen: ficheros
ejecutables, ficheros de código fuente, y todo otro tipo de ficheros
necesarios para la implantación y despliegue del sistema. (Este
modelo es sólo una versión preliminar al final de la fase de
Elaboración, posteriormente tiene bastante refinamiento).
4.3.8. Casos de Prueba
Estos casos de prueba son aplicados como pruebas de regresión en
cada iteración. Cada caso de prueba llevará asociado un
procedimiento de prueba con las instrucciones para realizar la
prueba, y dependiendo del tipo de prueba dicho procedimiento
podrá ser automatizable mediante un script de prueba.
113
4.3.9. Evolución del Plan de Desarrollo del Software
El Plan de Desarrollo del Software se revisará semanalmente y se
refinará antes del comienzo de cada iteración.
4.4. Organización del Proyecto
4.4.1. Participantes en el Proyecto
El resto del personal del proyecto (por la parte del la empresa
adjudicataria), considerando las fases de Inicio, Elaboración y dos
iteraciones de la fase de Construcción, estará formado por los
siguientes puestos de trabajo y personal asociado:
 Jefe de Proyecto. Experiencia en metodologías de
desarrollo, herramientas CASE y notaciones, en particular
la notación UML y el proceso de desarrollo RUP.
 Analista de Sistemas. El perfil establecido es: Ingeniero en
Informática con conocimientos de UML, uno de ellos al
menos con experiencia en sistemas afines a la línea del
proyecto
 Analistas - Programadores. Con experiencia en el entorno
de desarrollo del proyecto, con el fin de que los prototipos
puedan ser lo más cercanos posibles al producto final.
 Ingeniero de Software. El perfil establecido es: Ingeniero
en Informática recién titulado que participará como becario
en el convenio universidad-empresa, realizando labores de
gestión de requisitos, gestión de configuración,
114
documentación y diseño de datos. Encargada de las pruebas
funcionales del sistema.
4.4.2. Interfaces Externas
Deportes LSI 03 definirá los participantes del proyecto que
proporcionarán los requisitos del sistema, y entre ellos quiénes
serán los encargados de evaluar los artefactos de acuerdo a cada
subsistema y según el plan establecido.
El equipo de desarrollo interactuará activamente con los
participantes de Deportes LSI 03 para especificación y validación
de los artefactos generados.
4.4.3. Roles y Responsabilidades
 Responsabilidad del Jefe de Proyecto
El jefe de proyecto también establece un conjunto de
prácticas que aseguran la integridad y calidad de los
artefactos del proyecto. Gestión de riesgos. Planificación y
control del proyecto.
 Responsabilidad Analista de Sistemas
Captura, especificación y validación de requisitos,
interactuando con el cliente y los usuarios mediante
entrevistas. Elaboración del Modelo de Análisis y Diseño.
Colaboración en la elaboración de las pruebas funcionales y
el modelo de datos.
115
 Responsabilidad Programador
Construcción de prototipos. Colaboración en la elaboración
de las pruebas funcionales, modelo de datos y en las
validaciones con el usuario
 Responsabilidad Ingeniero de Software
Gestión de requisitos, gestión de configuración y cambios,
elaboración del modelo de datos, preparación de las pruebas
funcionales, elaboración de la documentación. Elaborar
modelos de implementación y despliegue.
4.5.Gestión del Proceso
4.6. Plan del Proyecto
En esta sección se presenta la organización en fases e iteraciones y el
calendario del proyecto.
4.6.1.1. Plan de las Fases
Nro.
Fase Duración
Iteraciones
Fase de Inicio 1 3 semanas
Fase de Elaboración 1 2 semanas
Fase de Construcción 2 7 semanas
Fase de Transición - -
Los hitos que marcan el final de cada fase.
116
4.6.1.1.1. Fase de Inicio
En esta fase desarrollará los requisitos del producto desde la
perspectiva del usuario, los cuales serán establecidos en el artefacto
Visión. La aceptación del cliente / usuario del artefacto Visión y el
Plan de Desarrollo marcan el final de esta fase.
4.6.1.1.2. Fase de Elaboración
Al final de esta fase, todos los casos de uso correspondientes a
requisitos que serán implementados en la primera release de la fase
de Construcción deben estar analizados y diseñados (en el Modelo
de Análisis / Diseño). La revisión y aceptación del prototipo de la
arquitectura del sistema marca el final de esta fase.
4.6.1.1.3. Fase de Construcción
Se comienza la elaboración de material de apoyo al usuario. El hito
que marca el fin de esta fase es la versión de la release 3.0, con la
capacidad operacional parcial del producto que se haya considerado
como crítica, lista para ser entregada a los usuarios para pruebas
beta.
4.6.1.1.4. Fase de Transición
En esta fase se prepararán dos releases para distribución,
asegurando una implantación y cambio del sistema previo de
manera adecuada, incluyendo el entrenamiento de los usuarios.
117
4.6.1.2. Calendario del Proyecto
Como se ha comentado, el proceso iterativo e incremental de RUP
está caracterizado por la realización en paralelo de todas las
disciplinas de desarrollo a lo largo del proyecto, con lo cual la
mayoría de los artefactos son generados muy tempranamente en el
proyecto pero van desarrollándose en mayor o menor grado de
acuerdo a la fase e iteración del proyecto.
Disciplinas / Artefactos generados o modificados

Comienzo Aprobación
durante la Fase de Inicio
Modelado del Negocio
Modelo de Casos de Uso del Negocio y Modelo Semana 1 Semana 3

de Objetos del Negocio 14/10 – 20/10 28/10 – 3/11
Requisitos
Semana 1 Semana 3
Glosario
14/10 – 20/10 28/10 – 3/11
Semana 2 Semana 3
Visión
21/10 – 27/10 28/10 – 3/11
Semana 3
Modelo de Casos de Uso siguiente fase
28/10 – 3/11
Semana 3
Especificación de Casos de Uso siguiente fase
28/10 – 3/11
Semana 3
Especificaciones Adicionales siguiente fase
28/10 – 3/11
Análisis / Diseño
Semana 2
Modelo de Análisis / Diseño siguiente fase
21/10 – 27/10
Semana 2
Modelo de Datos siguiente fase
21/10 – 27/10
118
Implementación
Semana 3
Prototipos de Interfaces de Usuario siguiente fase
28/10 – 3/11
Semana 3
Modelo de Implementación siguiente fase
28/10 – 3/11
Pruebas
Semana 3
Casos de Pruebas Funcionales siguiente fase
28/10 – 3/11
Despliegue
Semana 3
Modelo de Despliegue siguiente fase
28/10 – 3/10
Gestión de Cambios y Configuración Durante todo el proyecto
Gestión del proyecto
Plan de Desarrollo del Software en su Semana 1 Semana 3

versión 1.0 y planes de las Iteraciones 14/10 – 20/10 28/10 – 3/11
Ambiente Durante todo el proyecto
Disciplinas / Artefactos
generados o modificados durante la Comienzo Aprobación
Fase de Elaboración
Modelado del Negocio
Modelo de Casos de Uso del Negocio y Semana 1

aprobado
Modelo de Objetos del Negocio 14/10 – 20/10
Requisitos
Semana 1
Glosario aprobado
14/10 – 20/10
Semana 2
Visión aprobado
21/10 – 27/10
Semana 3 Semana 5
Modelo de Casos de Uso
28/10 – 3/11 11/12 – 17/12
Semana 3 Semana 5
Especificación de Casos de Uso
28/10 – 3/11 11/12 – 17/12
119
Semana 3 Semana 5
Especificaciones Adicionales
28/10 – 3/11 11/12 – 17/12
Análisis / Diseño
Semana 2 Revisar en
Modelo de Análisis / Diseño
21/10 – 27/10 cada iteración
Semana 2 Revisar en
Modelo de Datos
Implementación
Semana 3 Revisar en
Prototipos de Interfaces de Usuario
Semana 3 Revisar en
Modelo de Implementación
Pruebas
Semana 3 Revisar en
Casos de Pruebas Funcionales
Despliegue
Semana 3 Revisar en
Modelo de Despliegue
Gestión de Cambios y Configuración Durante todo el proyecto
Gestión del proyecto
Plan de Desarrollo del Software en su Semana 4 Revisar en

versión 2.0 y planes de las Iteraciones 4/11 – 10/11 cada iteración
Ambiente Durante todo el proyecto
120
4.6.1.3. Seguimiento y Control del Proyecto
4.6.1.3.1. Gestión de Requisitos
Los requisitos del sistema son especificados en el artefacto Visión.
Estos atributos permitirán realizar un efectivo seguimiento de cada
requisito.
4.6.1.3.2. Control de Plazos
El calendario del proyecto tendrá un seguimiento y evaluación
semanal por el jefe de proyecto y por el Comité de Seguimiento y
Control.
4.6.1.3.3. Control de Calidad
Los defectos detectados en las revisiones y formalizados también
en una Solicitud de Cambio tendrán un seguimiento para asegurar
la conformidad respecto de la solución de dichas deficiencias Para
la revisión de cada artefacto y su correspondiente garantía de
calidad se utilizarán las guías de revisión y checklist (listas de
verificación) incluidas en RUP.
4.6.1.3.4. Gestión de Riesgos
A partir de la fase de Inicio se mantendrá una lista de riesgos
asociados al proyecto y de las acciones establecidas como
estrategia para mitigarlos o acciones de contingencia. Esta lista será
evaluada al menos una vez en cada iteración.
121
4.6.1.3.5. Gestión de Configuración
Se realizará una gestión de configuración para llevar un registro de
los artefactos generados y sus versiones. También se incluirá la
gestión de las Solicitudes de Cambio y de las modificaciones que
éstas produzcan, informando y publicando dichos cambios para que
sean accesibles a todo los participantes en el proyecto.
4.6.1.3.6. Modelado del Negocio de la Empresa de Deportes Lsi 03
A continuación se presentan los modelos definidos en RUP como
modelo del negocio .También se muestran los diagramas de
componentes y diagramas de despliegue del proyecto.
4.6.1.4. Empresa de Deporte
Cada sucursal de ventas dispone de un almacén regional que
suministra los pedidos de los clientes a los países que conforman
una región determinada, siendo el almacén central el que abastece
al resto de almacenes. El diagrama que representa los diferentes
subsistemas en los que se ha dividido la empresa a nivel de
abstracción es el siguiente:
122
4.6.1.5. Modelado del Negocio
La empresa interactúa con distintos elementos externos, entre los
que se identifican el cliente externo (persona o entidad que solicita
la compra de productos a la empresa), el proveedor (persona o
entidad que reabastece de productos a la empresa) y por último la
empresa de transportes, que es una subcontrata encargada de servir
los pedidos desde los distintos almacenes regionales a los clientes
de la empresa.
123
4.7.Visión
4.7.1. Propósito
El propósito de éste documento es recoger, analizar y definir las
necesidades de alto nivel y las características del sistema de
gestión de una empresa de distribución de artículos deportivos. El
documento se centra en la funcionalidad requerida por los
participantes en el proyecto y los usuarios finales.
4.7.2. Alcance
Dicho sistema será desarrollado por el grupo de desarrollo de
software LSI 03.
El sistema permitirá a los encargados de la empresa controlar todo
lo relativo a la distribución de los artículos (gestión de stock,
gestión de pedidos, gestión de clientes, etc.).
4.7.3. Posicionamiento
4.7.4. Oportunidad de Negocio
Este sistema permitirá a la empresa informatizar el control de todas
sus actividades (gestión de stock en cada almacén, gestión de
pedidos, etc.), lo cual supondrá un acceso rápido y sencillo a los
datos, gracias a interfaces gráficas sencillas y amigables.
124
Sentencia que define el Problema
El problema de Controlar el stock existente en los distintos
almacenes afecta a:
Departamento de logística, departamento de contabilidad
facturación, Departamento de recursos humanos, Departamento de
marketing.
El impacto asociado es: Almacenar toda la información referente
almacenes, pedidos y órdenes de compra recibidas, y que esta
información esté al instante accesible.
Una solución adecuada sería: Informatizar el proceso, usando una
red local con una base de datos accesible desde los distintos nodos
de la red y generar interfaces amigables y sencillas con las que
acceder a dicha base de datos.
4.7.5. Entorno de Usuario
Los usuarios entrarán al sistema identificándose sobre un ordenador
con un sistema operativo Windows 2000 y tras este paso entrarán a
la parte de aplicación diseñada para cada uno según su papel en la
empresa.
125
4.7.6. Representante del Área Técnica y Sistemas de Información
Representante Patricio Orlando Letelier Torres
Descripción Representante Global de la Empresa
Deportes LSI 03.
Tipo Experto de Sistemas.
Responsabilidades Encargado de mostrar las necesidades de
cada usuario del sistema. Además, lleva a
cabo un seguimiento del desarrollo del
proyecto y aprobación de los requisitos y
funcionalidades del sistema
Criterio de Éxito A definir por el cliente
Grado de Revisión de requerimientos, estructura del

participación sistema
Comentarios Ninguno
126
4.8.Perfiles de Usuario
4.8.1. Ingeniero de Logística.
Representante Logística
Descripción Jefe del Departamento de Logística de la Empresa.
Tipo Gurú.
Responsabilidades Responsable del Departamento de Logística,
encargado de la gestión del almacén central, del
aprovisionamiento del resto de almacenes y del
contacto con los proveedores. Control de
estadísticas para la optimización de recursos.
Grado de participación A definir por el cliente
Comentarios Ninguno
4.8.2. Jefe de Almacén
Representante Almacén
Descripción Jefe del almacén de una región determinada.
Tipo Usuario casual del sistema.
Responsabilidades Supervisor del buen funcionamiento del
almacén y de gestionar las incidencias de los
pedidos, ya sea tratando con otro almacén, o
bien en contacto con el Ingeniero de Logística.
Capacidad de toma de decisiones en cuanto a
distribución de mercancías desde otro almacén
y cancelación de pedidos que han sido
127
atendidos.
Grado de participación A definir por el cliente
Comentarios Ninguno.
4.8.3. Técnico de Almacén
Representante Almacén
Descripción Responsable del almacén de una región
determinada.
Tipo Usuario experto.
Responsabilidades Encargado directo del almacén, control de stocks y
distribución de los productos, preparación y
atención de las órdenes de pedido y solicitudes de
envío al cliente. Gestión de incidencias a través del
de un técnico comercial para que se ponga en
contacto con el cliente, o bien por medio del jefe de
almacén.
Grado de A definir por el cliente

participación
128
4.8.4. Representante de Ventas
Representante Ventas
Descripción Representante de ventas de los productos
Responsabilidades Responsable de ventas del producto a los clientes,
mediante visitas al domicilio del cliente. Informa
de las ofertas y confecciona las órdenes de pedido.
También participa en las incidencias de pedidos
poniéndose en contacto con el cliente para la
resolución de los mismos. Puede cancelar pedidos
en estado de elaboración.

participación
4.8.5. Operadora
Descripción Operadora de ventas de los productos
Responsabilidades Responsable de ventas del producto a los clientes a
través del teléfono. Informa de las ofertas y
confecciona las órdenes de pedido. También
participa en las incidencias de pedidos poniéndose
en contacto con el cliente para la resolución de los
mismos.
129

participación
4.8.6. Jefe de Ventas
Descripción Jefe del Departamento de Ventas de una región
determinada.
Responsabilidades Supervisor del Departamento de Ventas, encargado
de otorgar incentivos y del control de estadísticas.

participación
4.8.7. Encargado de Transporte
Representante Envíos
Descripción Encargado de Transportes de un almacén
determinado.
Responsabilidades Supervisor del transporte de mercancías desde el
almacén hasta el domicilio de los clientes. Carga
los pedidos en el camión, registra en el sistema los
datos del envío y una vez entregado el pedido al
130
cliente, introduce el recibo de entrega en la base de
datos.

participación
4.8.8. Contable
Representante Contabilidad / Facturación
Descripción Empleado del Departamento de Contabilidad y
Facturación.
Responsabilidades Encargado de la facturación y cobranzas, política de
cobro de los clientes.

participación
131
4.8.9. Empleado de Marketing
Representante Marketing
Descripción Empleado del Departamento de Marketing.
Tipo Usuario eventual.
Responsabilidades Responsable de ofertas de lanzamiento,
publicidad, política de ventas y otros aspectos
relacionados con el marketing.

participación
4.8.10. Cliente Online
Descripción Comprador de productos.
Tipo Usuario casual.
Responsabilidades Realiza compras online y consulta del estado de
pedidos como del catálogo. También puede darse
de alta, darse de baja o modificar sus datos de
cliente.

participación
132
4.8.11. Empleado de Recursos Humanos
Representante Recursos Humanos
Descripción Empleado del Departamento de Recursos Humanos.
Responsabilidades Responsable de las entrevistas de trabajo y registra
los datos de las mismas, incluyendo la gestión de
una base de datos de currículos de trabajadores en
potencia. También realiza la gestión de contratos y
nóminas del personal.

participación
4.8.12. Jefe de Recursos Humanos
Representante Recursos Humanos
Descripción Empleado del Departamento de Recursos Humanos.
Responsabilidades Responsable de la gestión de personal, es decir,
gestión de contrataciones y gestión de despidos.
También es responsable de la redistribución de la
plantilla.

participación
133
4.8.13. Descripción Global del Producto
Atributos de Características
Número y
nombre de la Estado Beneficio Esfuerzo Riesgo Estabilidad Asignación
característica
Propuesta: Sí
Depart. de [A definir [A definir
Aprobada: Sí
Recursos Útil Bajo por el por el Ninguna
Incorporada:
Humanos cliente] cliente]
No
Propuesta: Sí
[A definir [A definir
Depart. de Aprobada: Sí
Útil Bajo por el por el Ninguna
Marketing Incorporada:
cliente] cliente]
No
Propuesta: Sí
Depart. de Aprobada: Sí
Importante Medio por el por el Ninguna
Logística Incorporada:
cliente] cliente]
No
Propuesta: Sí
Control de [A definir [A definir
Aprobada: Sí
estadísticas de Útil Medio por el por el Ninguna
Incorporada:
datos cliente] cliente]
No
J.A.
Mocholí,
Propuesta: Sí Germán
Gestión de Aprobada: Sí Mira,
Crítica Alto por el por el
Almacén Incorporada: Miguel
cliente] cliente]
Sí Mascilla y
Eduardo
Bueno
Propuesta: Sí
Atención de [A definir [A definir José
Aprobada: Sí
órdenes de Crítica Alto por el por el Antonio
Incorporada:
pedido cliente] cliente] Mocholí
Sí
Gestión de Propuesta: Sí [A definir [A definir
Útil Medio Ninguna
incidencias de Aprobada: Sí por el por el
134
pedido Incorporada: cliente] cliente]
No
Propuesta: Sí
Consulta de [A definir [A definir
Aprobada: Sí Eduardo
estado de los Importante Medio por el por el
Incorporada: Bueno
pedidos cliente] cliente]
Sí
José
Antonio
Propuesta: Sí
[A definir [A definir Mocholí,
Gestión de Aprobada: Sí
Crítica Alto por el por el Germán
Ventas Incorporada:
cliente] cliente] Mira y
Sí
Miguel
Mascilla
José
Antonio
Propuesta: Sí
Elaborar [A definir [A definir Mocholí,
Aprobada: Sí
pedidos y Útil Medio por el por el Germán
Incorporada:
ofertas cliente] cliente] Mira y
Sí
Miguel
Mascilla
135
4.9. Análisis / Diseño
4.9.1. Modelo de Análisis/Diseño: Diagrama de Clases
136
4.10. Modelo de Datos: Modelo Relacional
137
4.11. Implementación
4.11.1. Prototipos de Interfaz de Usuario
Interfaz que se Presenta en la Identificación
En Caso de Seleccionar Incidencia Pedido
138
Para Consultar los Detalles de una Incidencia
139
4.11.2. Componentes/Despliegue
140
4.11.3. Diagrama de Componentes Comunes
141
4.11.4. Diagrama de Componentes Ventas
142
4.11.5. Diagrama de Despliegue
143
4.12. Pruebas
Orden pedido
Código Fecha Estado Usuario C.P. Loc. Nº Forma

pedido Ventas envío envío envío pago
1 07/09/2002 En 48265791- 46985 Manises 3 Contado
elaboración L
2 25/10/2002 En 26359874- 46758 Xativa 6 Contado
elaboración J
3 10/11/2002 No 48265791- 46985 Manises 3 Crédito
atendido L
Empleado
NIF Usuario Contraseña Nombre Teléfono Cargo

22596826- pepe adidas José 962468597 Técnico
F Martínez almacén
Muñoz
26359874- luis reebok Luis 961387596 Representa
J Fernández nte de
Vila Ventas
48265791- maria nike Maria 963478952 Operadora
L López
Escudero
144
Producto
Referencia Precio(€) Nombre Max_razonable

Descripción Proveedor
1 67 Zapatillas Zapatillas 456 200

illas
2 34 Mochila Mochila ilas 456 100
3 28 Sudadera Sudadera 456 350
eras
Línea pedido
Código Referencia Cantidad Precio(€) Cantidad

pedido Asig.
1 1 1 67 0
2 1 1 67 0
3 2 2 68 0
Producto-Almacén
Referencia Almacén Stock Stock Asig.

1 VAL 1000 1
2 VAL 500 2
3 VAL 6 0
Almacén
Cód Nom Direc Teléfo País Fax Email Cod_

Técnico
igo bre ción no reg
VA Virso C/ 96347 Esp 96347 virso@on E 26485963
L Colón 9862 aña 9860 o.com -M
, 15-
78
145
Cliente
NIF/CIF Nomb Calle Teléfo Loc. C.C.C mail Repr

Cod re no e
igo senta
nte
1 4831568 Jaime C/ 961385 Manise 95- Jaim 2635
2-N Monzó Meli 396 s 264895- e75 9874
n as 00063526 @on -J
García 89 o.co
m
2 2249635 Javier C/ 962359 Xativa 48-59682- Javie 2635
9-P Soria Azori 684 00084548 r32@ 9874
Garrid n 95 ono.c -J
o om
Incidencias
Cod_ Nif_creador Creador Observaciones

Cod_incidencia Fecha
Pedido
1 6 11/12/2002 26485963M Antonio Reponer
Milla stock,
López producto 1
por debajo del
mínimo
2 7 21/12/2002 26485963M Antonio Pedido en
Milla atención más
López de 2 días
146
4.12.1. Especificación de Caso de Prueba
4.12.2. Descripción
Este artefacto cubre el conjunto de pruebas realizadas sobre
el Caso de Uso “Consultar Pedidos no Atendidos”. La única
prueba que se puede realizar a este caso de uso es
comprobar que la consulta funciona correctamente. El
entorno del cual partiremos para realizar la prueba será el
formulario de entrada de la aplicación.
4.12.3. Comprobar que la Consulta Funciona Correctamente
4.12.3.1. Entrada
 Introducimos ‘pepe’ en el campo usuario
 Introducimos ‘adidas’ en el campo contraseña
 Pulsamos entrar o el botón “aceptar” de la aplicación.
 Nos aparece la interfaz propia del técnico de almacén,
donde pulsaremos la pestaña de “No Atendidos”.
 Seleccionamos uno de los pedidos en estado de no
atención.
 Pulsamos el botón “consultar” y el sistema muestra los
147
detalles de las líneas del pedido. Al salir, el pedido
figurará en el estado de “En Atención”.
4.12.4. Resultado Esperado
El sistema nos muestra una interfaz que consistirá en una lista con las
líneas de pedido del pedido solicitado.
4.12.5. Evaluación de la Prueba
Prueba superada con éxito
148
CONCLUSIONES
 El Proceso Unificado de Rational (RUP) es una metodología muy
potente de desarrollo basado en UML (Unified Modeling Language),
utilizada para la ingeniería de sistemas y de software.
 RUP describe como reutilizar los componentes existentes o
implementar nuevos componentes con tareas bien definidas, lo que
lleva a obtener un sistema fácil de mantener al que se le puede ir
incrementando las posibilidades de reutilización. Asegurando la
producción de software de alta calidad con un costo y tiempo
predecible para el usuario. Para ello RUP divide todo su proceso en
cuatro fases, dentro de las cuales se realizan varias iteraciones.
 Una de las características más importantes por las que se define RUP
es su enfoque iterativo, ya que esto implica que se estará evaluando a
lo largo de todo el proyecto, a fin de poder encontrar defectos lo antes
posible, y así poder reducir el costo por la corrección de defectos.
 RUP es una metodología impresionante y completa, pero con la
complejidad que éste posee para empezar a aplicarla en una
organización. Recalcando que no es un inconveniente para poderlo
implementar.
 Una de las grandes ventajas que posee esta metodología son los casos
de uso y casos de prueba, ya que los casos de uso facilitan las tareas
de programación y los casos de prueba garantizan un plan de pruebas
bastante bueno y robusto.
149
RECOMENDACIONES
 Es recomendable utilizar RUP ya que describe como reutilizar los
componentes existentes o implementar nuevos componentes con tareas
bien definidas, el que me lleva a obtener un sistema fácil de mantener
al que se le puede ir incrementando las posibilidades de reutilización.
 RUP asegura la producción de software de alta calidad con un costo y
tiempo predecible para el usuario.
 Se recomienda el uso de esta metodología por la filosofía de desarrollo

incremental intrínseca que presenta. Es cíclica, permite administrar el
desarrollo de proyectos de software son aseguramiento de calidad.
 En los Planes de estudio de centros universitarios con especialidad en
informática, es recomendable la inclusión de este proceso
metodológico
 Se debe utilizar RUP ya que esto implica que se estará evaluando a lo
largo de todo el proyecto, a fin de poder encontrar defectos lo antes
posible, y así poder reducir el costo por la corrección de defectos.
150
BIBLIOGRAFÍA
http://es.wikipedia.org/wiki/Lenguaje_Unificado_de_Modelado
http://www3.uji.es/~mmarques/f47/apun/node83.html
http://www.itlp.edu.mx/publica/tutoriales/basedat1/tema2_5.htm
http://es.wikipedia.org/wiki/Personal_Software_Process
http://www.sc.ehu.es/jiwdocoj/remis/docs/dinamw.doc
http://atenea.ucauca.edu.co/~gramirez/archivos/AnotacionesRUP.pdf
http://www.histaintl.com/servicios/consulting/rup.htm
http://www.monografias.com/trabajos12/ingreq/ingreq.shtml
http://dis.unal.edu.co/~fgonza/courses/2003/ingSoft1/CAP4.pdf
http://www.monografias.com/trabajos6/resof/resof.shtml
https://www.microsoft.com/spanish/msdn/arquitectura/das/guias/AppArchCh2.asp
http://www.elguille.info/colabora/NET2005/Percynet_ConstruyendoSoftCalidad.h
tm
http://www.e-
gattaca.com/eContent/library/documents/DocNewsNo27DocumentNo10.DOC
http://java.ciberaula.com/articulo/tecnologia_orientada_objetos/
http://www.academia-interactiva.com/ise.pdf
http://www.mailxmail.com/curso/informatica/componentespcs/capitulo35.htm
http://www.duiops.net/manuales/access/access9.htm
http://es.wikipedia.org/wiki/Personal_Software_Process
"SEI/Continuos Technology Transition Workshop"; Workshop Notes; Software
Engineering Institute, 1995
151
"A conceptual Framework for Software Technology Transition"; P.Fowler,
L.Levine; CMU/SEI-93-TR-31; Software Engineering Institute, 1993
"Desarrollo de un Prototipo de Sistema Experto para Transferencia de Tecnologia
Software"; M.I.Garcia; Tesis de Master en Ingenieria del Conocimiento; Facultad
de Informatica, U.P.M.; 1994
"Crossing the Chasm: Marketing and Selling Technology Products to Mainstream
Customers"; G.Moore; Harper Business, 1991
"Defining Software Processes"; Workshop Notes; Software Engineering Institute,
1995.
"Capability Maturity Model for Software. Version 1.1"; M.C.Paulk, et al.;
CMU/SEI- 93-TR-24; Software Engineering Institute, 1993
"An Integrated Approach to Software Process Improvement"; R.Radice,
B.Peterson; Software Engineering Institute, 1994
 "Process Change Guide: Introducing Software Processes, Methods and
Tools to PSD Projects"; Draft-Version Gen-1.3b; Xerox Production
Systems/Printing Systems, Nov. 1995
 "Process Guide for SCM Adoption"; Draft-Version 1.2; Angelica de
Antonio; Software Engineering Institute, Sep. 1995
 "A Framework for Process Guide Specialization for KPAs"; Draft-Version
1.1; Angelica de Antonio; Software Engineering Institute, Sep. 1995
152
 Panel "Introducing KPAs: Three Approaches"; Chris Comparetta, Al
Willett, Angelica de Antonio; Software Engineering Symposium,
Pittsburgh, Septiembre 1995.
 "Complexity Reduction in Information Systems Modelling", Anne Helga
Seltveit; IDT-Rapport 1994:8, Universitetet I Trondheim, Norges Tekniske
Hogskole
153

Rational Unified Process (Rup)

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Rational Unified Process (Rup)

Transféré par

Droits d'auteur :

Formats disponibles

INDICE

METODOLOGÌAS MODERNAS PARA EL DESARROLLO DE SOFTWARE

SPI (Software Process Improvement) …………………………… 7

RATIONAL UNIFIED PROCESS (RUP) CONCEPTOS Y FILOSOFÌA

AL INTERIOR DE RATIONAL UNIFIED PROCESS (RUP) ESQUEMA

Dimensiones del RUP …………………………………………... 33

DESCRIPCION DE CASOS DE ESTUDIO USANDO RUP

Plan de Desarrollo de Software ……………………………… 110

El Proceso Racional Unificado o RUP (Rational Unified Process), es un proceso

de desarrollo de software y junto con el Lenguaje Unificado de Modelado UML,

constituye la metodología estándar más utilizada para el análisis, implementación

y documentación de sistemas orientados a objetos. RUP es en realidad un

Sus principales características son:

 Forma disciplinada de asignar tareas y responsabilidades (quién hace qué,

 Pretende implementar las mejores prácticas en Ingeniería de Software

 Uso de arquitectura basada en componentes

 Modelado visual del software

 Verificación de la calidad del software

El RUP es un producto de Rational (IBM). Se caracteriza por ser iterativo e

incremental, estar centrado en la arquitectura y guiado por los casos de uso.

distintos roles a lo largo del proceso).

El RUP divide el proceso de desarrollo en ciclos, teniendo un producto final al

hito donde se debe tomar una decisión importante:

 Inicio se hace un plan de fases, se identifican los principales casos de uso

y se identifican los riesgos

 Elaboración: se hace un plan de proyecto, se completan los casos de uso y

se eliminan los riesgos

 Construcción: se concentra en la elaboración de un producto totalmente

operativo y eficiente y el manual de usuario

 Transición: se implementa el producto en el cliente y se entrena a los

usuarios. Como consecuencia de esto suelen surgir nuevos requisitos a ser

En el capitulo 1 abordaré el tema de las nuevas metodologías para el desarrollo de

software, las mismas que garantizan un excelente producto, reducción de tiempo y

En el capitulo 2 describo de una manera breve las características, conceptos y

filosofía del RUP, es decir lo más general del esta metodología.

En el capitulo 3 detallo las dimensiones y fases del RUP, la utilización de

Lenguaje de Modelado Unificado, y sobre Wolkflows o grupos de trabajo.

METODOLOGÌAS MODERNAS PARA EL DESARROLLO DE

Métodos con Orientación a los Objetos

SPI (Software Process Improvement)

SPS (Personal Software Process)

UML (Unified Modelling Language)

1. Metodologías Modernas para el Desarrollo de Software

1.1. Métodos con Orientación a los Objetos (OO)

Hoy en día la tecnología orientada a objetos ya no se aplica solamente a

los lenguajes de programación, además se viene aplicando en el análisis y

hacer una buena programación orientada a objetos hay que desarrollar

todo el sistema aplicando esta tecnología, de ahí la importancia del

análisis y el diseño orientado a objetos.

La programación orientada a objetos es una de las formas más populares

de programar y viene teniendo gran acogida en el desarrollo de proyectos

de software desde los últimos años.

lenguaje orientado a objetos, también se necesitará realizar un análisis y

diseño orientado a objetos.

El modelamiento visual es la clave para realizar el análisis orientado a

objetos (OO). Desde los inicios del desarrollo de software OO han

existido diferentes metodologías para hacer esto del modelamiento, pero

sin lugar a duda, el Lenguaje de Modelamiento Unificado (UML) puso fin

modelar cualquier tipo de sistemas (no solamente de software) usando los

conceptos de la orientación a objetos; además este lenguaje debe ser

entendible para los humanos y máquinas.

El UML consta de todos los elementos y diagramas que permiten modelar

los sistemas en base al paradigma orientado a objetos. Los modelos

orientados a objetos cuando se construyen en forma correcta, son fáciles