Administracion I - Cibertec 2011-I

Análisis y Diseño de
Sistemas II – Teoría
Administración y Sistemas
2
CARRERAS PROFESIONALES CIBERTEC

ANÁLISIS Y DISEÑO DE SISTEMAS II – TEORÍA 3
ÍNDICE
Presentación 5
Red de contenidos 6
Sesiones de aprendizaje
TEMA 1 : Análisis orientado a objetos 7
Modelo de análisis y Arquitectura de análisis.
TEMA 2 : Análisis de casos de uso 19
TEMA 3 : Casos Prácticos 35
TEMA 4 : Análisis de clases 39
TEMA 5 : Modelo conceptual 51
TEMA 7 : SEMANA DE EXÁMENES PARCIALES
TEMA 8 : Ingeniería de requisitos 67
TEMA 9 : Pirámide de requisitos 83
TEMA 10 : Gestión de requisitos en RUP 99
TEMA 11 : Trazabilidad de requisitos 125
TEMA 13 : Ingeniería de requisitos orientada a aspectos 133
ANEXO 1 141
TEMA 15 : Sustentación del Proyecto 143
TEMA 16 : Sustentación del Proyecto
TEMA 17 : SEMANA DE EXÁMENES FINALES
Glosario 176
CIBERTEC CARRERAS PROFESIONALES

4

PRESENTACIÓN
Análisis y Diseño de Sistemas II pertenece a la línea formativa y se dicta en la

carrera de Administración y Sistemas. El curso imparte conocimientos
relacionados con el Modelo de Análisis del software y el proceso de ingeniería de
requisitos. En este último proceso se muestra el enfoque orientado a aspectos, el
cual es un paradigma relativamente nuevo y que se impone como la mejor
alternativa para identificar aspectos que no pueden encapsularse dentro de una
unidad funcional, debido a que se diseminan por todo el sistema y son conocidos
como crosscutting concerns.
El manual para el curso ha sido diseñado bajo la modalidad de unidades de

aprendizaje, las que se desarrollan durante semanas determinadas. En cada una
de ellas, hallará los logros, que debe alcanzar al final de la unidad; el tema
tratado, el cual será ampliamente desarrollado; y los contenidos, que debe
desarrollar, es decir, los subtemas. Por último, encontrará las actividades que
deberá desarrollar en cada sesión, que le permitirán reforzar lo aprendido en la
clase.
El curso es teórico - práctico: consiste en un taller de desarrollo de proyectos

de software. En primer lugar, se inicia con la presentación de la disciplina de
análisis del RUP, el desarrollo del modelo de análisis para obtener la
arquitectura inicial del software. Se concluye con la comprensión de la
ingeniería de requisitos, la gestión de cambios de requisitos y el enfoque
orientado a aspectos en el proceso de la ingeniería de requisitos.

6
RED DE CONTENIDOS
Análisis y Diseño de Sistemas II
Análisis Orientado Ingeniería de

a Objetos Requisitos
Modelo de Proceso de la
Análisis Ingeniería de
Requisitos
Arquitectura
de Análisis Pirámide de
requisitos
Análisis de
casos de uso Gestión de
Requisitos
según RUP
Análisis de
clases
Trazabilidad de
requisitos
Modelo
Conceptual
Ingeniería de
Requisitos
Orientado a
Aspectos

UNIDAD DE
APRENDIZAJE
1
TEMA
ANÁLISIS ORIENTADO A OBJETOS
LOGRO DE LA UNIDAD DE APRENDIZAJE
Al finalizar la primera unidad, el alumno modula la arquitectura de análisis que da

soporte a los procesos del negocio, diagrama la estructura y el comportamiento de sus
funcionalidades mediante diagramas de clases y diagramas de comunicación
respectivamente. Asimismo, crea el esquema conceptual de la base de datos. Los
artefactos serán creados utilizando la herramienta CASE IBM Rational Software
Architect (RSA).
TEMARIO
1. Análisis Orientado a Objetos.

2. Modelo de Análisis
3. Análisis de la arquitectura.
ACTIVIDADES PROPUESTAS
1. Los alumnos crean la arquitectura de análisis a partir de un diagrama de casos

de uso estructurado.

8
1. ANÁLISIS ORIENTADO A OBJETOS

El Análisis Orientado a Objetos es parte de la disciplina Análisis y Diseño de RUP,
la cual tiene como propósito:
 Transformar los requisitos en un diseño del sistema a crear.
 Definir una arquitectura robusta para el sistema.
 Adaptar el diseño para que funcione en el ambiente de implementación,
diseñándolo para un desempeño esperado.
El flujo de trabajo de Análisis y Diseño toma los casos de uso documentados del
flujo de trabajo de la Captura de Requisitos y del Modelado de Negocios y los
traslada a elementos de diseño que serán usados para construir el sistema. Por
medio de varias actividades y modelos, el flujo de trabajo de Análisis y Diseño
busca transformar la información obtenida de los stakeholders en información que
los programadores podrán usar. El flujo de trabajo de esta disciplina se muestra
en la figura No. 1.1..
Figura 1.1. Flujo de Trabajo de la disciplina Análisis y Diseño.
En la fase de Inicio, la disciplina de Análisis y Diseño se preocupa por establecer

si la visión del sistema es factible, y en determinar las tecnologías potenciales
para la solución de software (dentro de la actividad Perform Architectural
Synthesis). Si se considera que pocos riesgos se asocian al desarrollo (porque el
dominio se entiende muy bien, el sistema no es novedoso o cualquier otra razón
parecida) entonces éste aspecto se omite del flujo de trabajo.

En la parte inicial de la fase de Elaboración se enfoca el esfuerzo en crear una

arquitectura inicial del sistema (en la actividad Define a Candidate Architecture)
la cual proporcionará un punto inicial para todo el trabajo de análisis. Si la
arquitectura ya existe (porque fue creada en iteraciones anteriores o en proyectos
anteriores) el trabajo se enfoca en cambios para refinar la arquitectura (actividad
Refine the Architecture) y en analizar el comportamiento y crear un conjunto
inicial de elementos los cuales proporcionarán un comportamiento apropiado (en
la actividad Analyze Behavior).
Después de que los elementos iniciales son identificados, se refinan en

iteraciones futuras. La actividad Design Components produce un conjunto de
componentes los cuales proveen un comportamiento adecuado para satisfacer los
requisitos del sistema. Si el sistema incluye una base de datos, entonces la
actividad de Design the Database se ejecuta en paralelo. El resultado es un
conjunto inicial de componentes los cuales en un futuro son refinados dentro de la
Implementación.
1.1. Artefactos del Análisis

En la disciplina de Análisis y Diseño son muchos los artefactos que definen
cómo el sistema se implementará. En el curso consideraremos los tipos de
artefactos orientados al análisis, éstos son:
 Modelo de Análisis.
 Elementos del modelo de análisis: paquetes de análisis, clases de
análisis y realizaciones de análisis de casos de uso.
 Diagramas de realizaciones de análisis de casos de uso: diagrama de
clases, diagramas de comunicación y diagramas de secuencia.
Artefacto Descripción
Representa la vista interna del sistema. Define un
modelo de objetos que describe la realización de casos
de uso, y que sirve como una abstracción del modelo de
diseño.
Analysis Model
Los paquetes del análisis proporcionan un medio para
organizar los artefactos del modelo de análisis en piezas
manejables.
Analysis Package Un paquete de análisis contiene clases y realizaciones
de casos de uso a nivel de análisis.
Es una clase utilizada para modelar la interacción entre
el entorno del sistema y su funcionamiento interno.
Modela las partes del sistema que dependen de su
Boundary Class entorno.
Representa la lógica de negocio de la aplicación, es
decir, el control, la coordinación y la secuencia entre
objetos. Encapsula el comportamiento de uno o más
Control Class casos de uso.
Tabla 1.1. Artefactos del Análisis

10
La entidad es una clase utilizada para modelar

la información y comportamiento asociado que
deben ser almacenados.
Entity Class Modela las partes del sistema que son
independientes de su entorno.
La realización de análisis de un caso de uso es

una colaboración que describe cómo se realiza
el caso de uso en términos de clases de
Use Case Realization análisis y sus interacciones.
El diagrama de clases describe la estructura de

un caso de uso.
Diagrama de interacción que describe el

comportamiento del caso de uso centrado en
cómo es la comunicación entre los objetos.
Diagrama de interacción que describe el

comportamiento del caso de uso centrado en la
secuencia cronológica de objetos.
Tabla 1.1. Artefactos del Análisis (Continuación).
2. MODELO DE ANÁLISIS
El análisis orientado a objetos se traduce en el Modelo de Análisis, el cual es
usado para representar la estructura global del sistema, describe la realización de
casos de uso y sirve como una abstracción del Modelo de Diseño.
Durante el análisis, se identifica de manera continua nuevos paquetes del

análisis, clases y requisitos comunes a medida que el modelo de análisis
evoluciona, y los paquetes de análisis concretos continuamente se refinan y
mantienen.
Las actividades que se realizan en la etapa de análisis son:

 Análisis de la Arquitectura
 Análisis de Casos de Uso
 Análisis de Clases
 Análisis de Paquetes.
Según Ivar Jacobson “El modelo de análisis es un nivel de diseño intermedio

entre las etapas de captura de requisitos y la de diseño.”
Este modelo de análisis no es un diagrama final que describe todos los posibles
conceptos y sus relaciones, es un primer intento por definir los conceptos claves
que describen el sistema. Este artefacto es opcional, pero también tiene a su vez

la propiedad de ser temporal en el caso en que se planea su desarrollo. Su

utilidad radica en que permite una apreciación global conceptual del sistema.
El Modelo de Análisis puede contener: las clases y paquetes de análisis, las
realizaciones de los casos de uso, las relaciones y los diagramas. Es opcional
detallar aquí las realizaciones de los casos de uso ya que estas pueden estar en
el modelo de diseño donde se recomienda que se encuentre.
A diferencia del Modelo de Casos de Uso que captura la funcionalidad del

sistema, el Modelo de Análisis da forma a la arquitectura para soportar las
funcionalidades que en el anterior modelo se expresan.
Características principales:
 Proporciona un diseño preliminar, pues contiene paquetes que se usan
para organizar el modelo de análisis en piezas más manejables, que
representan abstracciones o subsistemas y una primera vista del diseño.
 Puede ayudar a descubrir la necesidad de clases adicionales.
 Proporciona una prueba de completitud a los casos de uso, antes de pasar
al diseño.
 Proporciona un diseño preliminar de la arquitectura del sistema, denotando
los paquetes de análisis de alto nivel.
El modelo de análisis contiene los siguientes artefactos:

 Diagrama de Arquitectura de Análisis, el cual muestra los paquetes de
análisis y sus dependencias.
 Paquete de análisis, el cual contiene realizaciones de casos de uso y
clases de análisis.
 Clases de análisis, son de tres tipos: boundary, control y entity y los cuales
representan elementos del patrón MVC (Model View Controller).
 Realización de caso de uso a nivel de análisis, es una colaboración que
contiene diagramas de clases y diagramas de interacción para definir la
estructura y comportamiento del caso de uso respectivamente.
 Modelo Conceptual, es un diagrama de clases que muestra todas las
clases del tipo entity. Conocido también como Modelo del Dominio.
1.1. Modelo de Casos de Uso Vs. Modelo de Análisis

El siguiente cuadro muestra una comparación entre el Modelo de Casos de
Uso y el Modelo de Análisis:

12
Modelo de Casos de Uso Modelo de Análisis

Descrito con el lenguaje del cliente. Descrita en el lenguaje de los
Vista externa del sistema. desarrolladores. Vista interna del sistema.
Estructurado por los casos de uso. Estructurado por clases y paquetes
estereotipados.
Utilizado como contrato entre el cliente y Utilizado por los desarrolladores para
los desarrolladores sobre que debería y comprender como debería darse forma al
que NO debería hacer el sistema. sistema, es decir, cómo debe estar diseñado
e implementado.
Puede contener redundancias, No debería contener redundancias,
inconsistencias, entre los requisitos. inconsistencias, entre los requisitos.
Captura la funcionalidad del sistema, Esboza como llevar a cabo la funcionalidad
incluida la funcionalidad significativa dentro del sistema, incluida la funcionalidad
para la arquitectura. significativa para la arquitectura.
Define los casos de uso que se Define las realizaciones de casos de uso, y
analizarán con más profundidad en el cada una de ellas representa el análisis de
modelo de análisis. un caso de uso del modelo de casos de uso.
Cuadro 1.1. Comparación del MCU Vs. MA
3. ANÁLISIS DE LA ARQUITECTURA
El rol responsable de esta tarea es el Arquitecto de software. Esta tarea permite

definir una arquitectura candidata basada en la experiencia obtenida de sistemas
similares o en dominios del problema similares, y restringir las técnicas
arquitectónicas a ser usadas en el sistema. Se definen los diagramas de las
vistas arquitectónicas, mecanismos claves y los modelos para el sistema. Cabe
destacar que analizar la arquitectura resulta beneficioso en el caso donde se
desarrollen sistemas que no se hayan hecho antes.
El propósito del análisis de la arquitectura es esbozar el modelo de análisis y la

arquitectura mediante la identificación de paquetes del análisis, clases de análisis
de entidad evidentes y requisitos especiales comunes.
3.1. Pasos a realizar
El Análisis de la Arquitectura se realiza como sigue:

 Identificación de los paquetes de análisis
 Definición de las dependencias entre los paquetes de análisis
 Identificación de clases de entidad obvias por cada paquete de análisis
 Identificación de los requisitos especiales comunes
 Identificación de las características fundamentales de un requisito
especial.
3.1.1. Identificación de paquetes de análisis

Los paquetes de análisis constituyen una división del sistema de
software que tiene sentido desde el punto de vista de los expertos en
el dominio.
La descomposición del software en paquetes se establece cuando

uno tiene una idea que considera suficientemente fiable de la cantidad

de trabajo y del número y la complejidad de los diagramas, situación a

la cual se puede haber llegado tanto al principio de la etapa de
análisis como un tiempo después. Una identificación inicial de los
paquetes del análisis se hace de manera natural basándonos en los
requisitos funcionales y en el dominio del problema, es decir, en la
aplicación o negocio que estamos considerando.
Debido a que los requisitos funcionales se capturan en la forma de

casos de uso, una forma directa de identificar paquetes del análisis es
asignar la mayor parte de un cierto número de casos de uso a un
paquete concreto.
Entre las asignaciones adecuadas de casos de uso a un paquete en

concreto se tiene:
1. Los casos de uso requeridos para dar soporte a un
determinado proceso de negocio.
2. Los casos de uso requeridos para dar soporte a un
determinado actor del sistema.
Para identificar los paquetes se basa en lo siguiente:

1. Tener un diagrama de casos de uso con los roles bien
definidos.
2. Los casos de uso que estén bajo la responsabilidad de un
actor deben tener contenidos estrechamente relacionados.
3. Los casos de uso que están relacionados mediante relaciones
de generalización deben pertenecer al mismo paquete.
Figura 1.2. Casos de Uso con relación de generalización
4. Los casos de uso relacionados mediante relaciones de

extensión y sólo se extienden a partir de un caso de uso base
deben pertenecer al mismo paquete del caso de uso base.
Figura 1.3. Casos de Uso con relación extend

14
5. Los casos de uso incluidos tienden a generar su propio

paquete la mayor parte de veces. Si los casos de uso base que
incluyen al caso de uso son funcionalidades con distintos
contenidos entonces se debe crear un paquete para el caso de
uso incluido.
<<include>>
Figura 1.4. Casos de uso con relación include
3.1.2. Definición de dependencias entre paquetes de análisis

El objetivo es conseguir paquetes que sean relativamente
independiente y débilmente acoplados pero que posean una cohesión
interna alta. Es inteligente intentar reducir el número de relaciones
entre clases en paquetes diferentes debido a que ello reduce las
dependencias entre paquetes.
Figura 1.5. Características de los paquetes de análisis
Los paquetes identificados se organizarán en la Capa de Aplicación,

la cual se subdivide en dos capas internas:
a) Capa Específica: Aquí se ubican los paquetes identificados con

excepción de los reutilizables (Nivel Superior).
b) Capa General: Aquí se ubican los paquetes reutilizables y los

paquetes de servicio (Nivel Inferior).
Para identificar las dependencias entre paquetes es conveniente

revisar el diagrama de casos de uso estructurado según análisis, esto
con el fin de ubicar las relaciones que existen entre los casos de uso.
Las dependencias se crean a partir de los paquetes de análisis que
contienen los casos de uso base.

A continuación se muestra un ejemplo de distribución de paquetes en

las capas de la aplicación y sus dependencias para definir la
arquitectura de análisis.
Figura 1.6. Capas y dependencias entre paquetes de análisis.
3.1.3. Identificación de clases de entidad obvias

 Sólo se debe concentrar en identificar las clases del tipo entity por
cada caso de uso.
 La mayoría de las clases se identificarán al crear las realizaciones
de caso de uso (en la actividad del análisis de caso de uso).
 Tener cuidado de no identificar demasiadas clases en esta etapa y
quedar atrapados en demasiados detalles.
Ejemplo:
“Reserva”, “Habitacion”  Clases del dominio del problema
“DetalleReserva”  Clase de la asociación entre Reserva y Habitacion
3.1.4. Identificación de requisitos especiales comunes

 El arquitecto es el responsable de identificar los requisitos
especiales comunes de forma que los desarrolladores puedan
referirse a ellos como requisitos especiales sobre realizaciones de
CU y clases del análisis determinadas.
 Limitaciones o restricciones sobre :
 Persistencia
 Distribución y concurrencia
 Característica de seguridad
 Tolerancia de fallos
 Gestión de transacciones.
3.1.5. Identificación de características fundamentales de un requisito especial

común
En esta etapa se debe indicarse las características de cada requisito
especial común. Por ejemplo, las características de un requisito de
persistencia son:

16
 Rango de tamaño
 Volumen
 Periodo de persistencia
 Frecuencia de actualizados
 Fiabilidad
Identifique los paquetes de análisis y sus dependencias para realizar la Arquitectura de
Análisis a partir del siguiente Diagrama de Caso de Uso Estructurado:
Caso: Cotización

Resumen
 El modelo de análisis, es usado para representar la estructura global del sistema,

describe la realización de casos de uso, sirve como una abstracción del Modelo de
Diseño y se centra en los requisitos no funcionales.
 El propósito del análisis de la arquitectura es esbozar el modelo de análisis y la

arquitectura mediante la identificación de paquetes del análisis, clases análisis del
tipo entidad evidentes y requisitos especiales comunes.
 Las actividades del Análisis de la Arquitectura son como sigue:
 Identificación de paquetes de análisis

 Definición de las dependencias entre los paquetes de análisis
 Identificación de clases de entidad obvias por cada paquete de análisis
 Identificación de los requisitos especiales comunes
 Identificación de las características fundamentales de un requisito especial.
 Los paquetes se usan para organizar el modelo de análisis en piezas más

manejables, que representan abstracciones o subsistemas y una primera vista del
diseño.
Un paquete de análisis debe ser débilmente acoplado y altamente cohesivo.
Los paquetes de análisis identificados se organizarán en la Capa de Aplicación, la

cual se subdivide en dos capas internas:
 Capa Específica: Aquí se ubican los paquetes identificados con excepción

de los reutilizables (Nivel Superior).
 Capa General: Aquí se ubican los paquetes reutilizables y los paquetes de

servicio (Nivel Inferior).
 Si desea saber más acerca de estos temas, puede consultar el siguiente libro.
 VISUAL MODELING WITH IBM RATIONAL ARCHITECT SOFTWARE ARCHI-

TECT AND UML por Terry Quatrani y Jim Palistrant
En el capítulo 6 de este libro se describe cómo crear un modelo de análisis.

18

UNIDAD DE
APRENDIZAJE
1
TEMA
ANÁLISIS DE CASOS DE USO

Architect (RSA).
TEMARIO
1. Análisis de casos de uso

2. Caso práctico
1. Los alumnos crean la realización de un caso de uso.

20
1. ANÁLISIS DE CASOS DE USO

El Análisis de Caso de Uso, es el proceso de examinar los casos de uso para
descubrir los objetos y clases de análisis del sistema a desarrollar. Las clases
identificadas deben agruparse en los paquetes según criterios de Arquitectura de
Software.
El rol responsable de esta tarea es el Diseñador. Esta tarea describe cómo

desarrollar las Realizaciones de los Casos de Uso del nivel de análisis de un caso
de uso particular. Tiene los siguientes propósitos:
 Identificar las clases que llevan a cabo el flujo de eventos de un caso de

uso.
 Distribuir el comportamiento de casos de uso a las clases identificadas,
usando realizaciones de casos de uso a nivel de análisis.
 Identificar atributos, responsabilidades y relaciones entre las clases.
 Observar los mecanismos arquitectónicos.
Análisis
de Casos
de Uso
Figura 2.1. Análisis de Casos de Uso

Para llevar a cabo el análisis de casos de uso se realiza lo siguiente:
 Crear la realización de análisis de casos de uso.
 Encontrar clases de análisis del comportamiento de casos de uso.
 Crear el diagrama de clases (estructura del caso de uso).
 Crear el diagrama de comunicación (comportamiento del caso de
uso).

1.1.1. Crear la realización de análisis de casos de uso

Una realización de caso de uso describe cómo un caso de uso en
particular es modelado, primero en el modelo de análisis y después en
el modelo de diseño, en términos de objetos colaboradores.
En una realización de caso de uso se especifica qué clases deben ser

construidas para implementar cada caso de uso.
En UML, las realizaciones de caso de uso se representan con

colaboraciones estereotipadas. El icono para una colaboración es una
elipse con líneas punteadas que se sitúa al lado izquierdo del nombre
de la colaboración, tal como se ilustra en la siguiente figura.
Figura 2.2. Colaboración
1.1.2. Encontrar clases de análisis

Este paso se realiza por cada caso de uso. Para ello, se analizan los
escenarios de Caso de Uso para identificar las clases que participan en
ellos.
Especificación
de Caso de Uso
Figura 2.3. Un flujo completo de un caso de uso debe distribuirse

en clases de análisis
Tal como se muestra en la figura 2.3, a partir de una especificación de

caso de uso (ECU) se pueden obtener las clases de análisis. Existen
tres tipos de clases de análisis: boundary, control y entity. A
continuación se describe a cada una de ellas:
 Boundary. Describe una interacción entre el sistema con los

usuarios y con otros sistemas. Pueden representar abstracciones
de formularios, de protocolos de comunicaciones o interfaces de
programación de aplicaciones (API).

22
Las características importantes de este tipo de clase cuando

modela un API con otro sistema son:
a. Las funciones que provee el otro sistema

b. La información a ser pasada al otro sistema
c. El “protocolo” de comunicación usado para “hablar” con el
otro sistema.
Por regla general, al menos una clase boundary sirve como

medio de comunicación entre un actor y el correspondiente caso
de uso.
Ejemplo:
En el caso de uso “Procesar Facturación” hay información que
debe ser enviada a un Sistema de Facturación externo. Se
puede crear una clase de interfaz llamada
CI_SistemaFacturacion para representar la interfaz al sistema
externo.
 Entity. Se emplean para modelar aquella información o

comportamiento que posee una vida larga en el sistema.
Normalmente están asociadas a algún fenómeno o concepto,
como una persona, un objeto del mundo real, o un suceso del
mundo real.
El número de clases entidad variará dependiendo de los

conceptos que requieren almacenamiento persistente dentro del
caso de uso. Estas clases sufren un proceso de refinamiento a
medida que se ubica a la misma clase entidad dentro de distintas
realizaciones de caso de uso.
Ejemplo:
En el caso de uso “Mantener empleados” en el cual se puede
registrar, modificar o desactivar empleados es evidente que la
información que debe ser manipulada es del empleado. Para ello
se crea una clase entidad Empleado.
 Control. Se utilizan para modelar la coordinación, secuencia,

transacciones y control de otros objetos. También para
representar derivaciones y cálculos complejos, cómo la lógica de
negocio, que no pueden asociarse a ninguna información
concreta de larga duración almacenada por el sistema.
Por regla general se trata de encapsular la lógica de control de

un caso de uso dentro de una clase Control. Suele ser un buen
hábito de diseño utilizar únicamente una clase control por cada
caso de uso, y así encapsular en un sólo elemento la lógica del
caso de uso correspondiente. Por otro lado, todos los casos de
uso ubicados en un mismo paquete de análisis comparten la
misma clase control.
Ejemplo:

En un paquete de análisis denominado Evaluación se ubica los

casos de uso “Evaluar empleado”, “Procesar evaluación de
desempeño” y “Consultar estadísticas de Evaluaciones”. Para los
tres casos de uso se crea una clase control CC_Evaluacion que
coordina el trabajo de los tres casos de uso.
Según la metodología OOSE de Ivan Jacobson, las clases de análisis

son clases estereotipadas para crear modelos ideales de objetos. Esta
metodología se basa en el patrón MVC (Model-View-Controller /
Modelo Vista Controlador), que define clases enfocadas a la
separación de responsabilidades para conseguir componentes
extensibles y reutilizables.
En la siguiente figura se muestran los tipos de clases enfocados a los

elementos del patrón MVC.
Figura 2.4. Clases de análisis enfocadas al patrón MVC
Cada clase de análisis debe tener un estereotipo1, como mecanismo

que el UML provee para extender la notación. Los estereotipos se
muestran en el compartimiento del nombre de la clase encerrado entre
<<>> (guillemets) o con un icono; también se pueden representar con
la forma de la imagen del icono en lugar de una clase. Estas
representaciones se muestran a continuación:
Figura 2.5. Clases de interfaz (boundary)
1
Un estereotipo (Stereotype en inglés), es un nuevo tipo de elemento de modelado que
extiende la semántica del meta modelo, basados en tipos existentes o clases del meta modelo.

24
Figura 2.6. Clases de control (control)
Figura 2.7. Clases de entidad (entity)
1.1.3. Crear el diagrama de clases

Este paso permite representar las clases participantes y sus relaciones
para un determinado caso de uso.
Figura 2.8. Diagrama de clases de análisis
1.1.4. Crear diagramas de comunicación

El diagrama de comunicación es un tipo de diagrama de interacción; en
esta etapa no se usa diagramas de secuencia porque no es importante
la cronología de las interacciones. Un diagrama de comunicación
muestra la colaboración dinámica entre los objetos, es decir, describe
el comportamiento de un caso de uso mostrando explícitamente las
relaciones de los objetos participantes.

La realización de un caso de uso puede tener uno o más diagramas de

comunicación, esto es debido a que se representa el flujo básico, sub-
flujos y flujos alternativos.
Por ejemplo, a continuación se muestra el diagrama de comunicación

para describir el comportamiento del caso de uso Mantener
competencias.
Figura 2.9. Diagrama de comunicación

26
2. CASO PRÁCTICO
A continuación se presenta un caso práctico para identificar clases de análisis a
partir de un escenario de caso de uso.
Registrar Inscripción en Cursos
1. Escenario : Registrar inscripción en cursos – Crear horario
2. Encontrando objetos entidad

 Los objetos de Entidad se identifican examinando los sustantivos y frases de
sustantivos en los escenarios
 Los sustantivos encontrados pueden ser :
 Objetos específicos ó genéricos
 Descripciones del estado de un objeto
 Entidades externas y/o actores
 Ninguno de los anteriores (frases fuera de contexto).
3. Filtrando sustantivos
 Cuando se identifican sustantivos tengan presente que
 Varios términos pueden referirse al mismo objeto
 Un término puede referirse a más de un objeto
 El lenguaje natural es muy ambiguo.

 De esta manera se pueden identificar muchos objetos sin importancia

 La lista de sustantivos se debe filtrar
 Advertencia
 Cualquier sustantivo puede ser convertido en verbo; cualquier verbo puede
ser convertido en sustantivo.
 Los resultados dependen en gran parte de la capacidad de redacción del o
los autores.
4. Sustantivos del Escenario
5. Filtrando el escenario

28
6. Análisis de los objetos filtrados en escenario
7. Creando Clases Entidad

 Los objetos de entidad encontrados se agrupan en clases
- Los objetos genéricos representan clases
- Las instancias de objetos con estructura y/o comportamiento similar se
agrupan en clases
 Este es solo un intento inicial

- Las clases pueden cambiar a medida que se examinan más escenarios
8. Clases entidad identificadas en el escenario del caso de uso
Una materia ofrecida por la universidad que

es parte de un Plan de Estudios
Cursos a enseñar en un semestre
Secciones de cursos escogidas para un

semestre por un estudiante
Estudiantes inscritos en una sección de

curso ofrecido
Un curso ofrecido en un lugar y horarios

específicos

9. Encontrando Clases Boundary (limite)

 Para cada par de actor físico y escenario cree una clase boundary.
- Durante el diseño, esta clase se transformara dependiendo de los
mecanismos de interfase escogidos.
 Añada más clases boundary para modelar navegación entre interfaces (por
ejemplo pantallas) en el mismo caso de uso.
 Ejemplo :
- Al estudiante se le presentan diferentes opciones en el caso de uso
“Registrar Inscripción en Cursos”.
Se crea una clase boundary llamada CI_Inscripcion para permitirle al
estudiante seleccionar la opción deseada.
- El estudiante debe ingresar las secciones de los cursos escogidos al

sistema en el escenario “Crear Horario”
Se crea una clase boundary llamada CI_Horario para recibir y procesar
la información ingresada por el estudiante.
10. Candidatos a Clase Boundary en el escenario del CU
11. Bosquejo de pantalla
Se pueden crear “storyboards”, prototipos y bosquejos de pantallas para

comunicar el “look & feel” de la clase boundary al usuario. Por ejemplo a
continuación se muestra la interfaz CI_Horario.

30
12. Encontrando Clases Control
 Las clases de control contienen información de secuencia para coordinar

los casos de uso.
 En este nivel de análisis, típicamente se añade una clase control para cada
caso de uso. Es responsable del flujo de eventos en el caso de uso
 Las clases de control NO deben ejecutar funciones cuya responsabilidad
pertenece a clases de entidad o de límite.
 Esto es solo un corte inicial. A medida que se desarrollan mas casos de uso
y escenarios, las clases de control puede eliminarse, dividirse o combinarse
13. Clases Control en el CU
 Se añade una clase de control llamada CC_Inscripcion.
 Recibe información de la clase boundary CI_Horario

 Para cada opción ingresada
o Valida que la sección este abierta
o Valida que no existan conflictos de horario
o Valida que el curso este en el plan de estudio del estudiante
o Valida que los prerrequisitos se cumplan
o Asigna al estudiante a la Sección
14. Diagramas de Vistas de Clases Participantes (VOPC)
 Un diagrama de clases muestra una o mas clases en un mismo plano,

usando la nomenclatura que se ha presentado antes.
 Cada Realización de Caso de Uso tiene uno o más diagramas de clases
que muestran las clases participantes en el CU y sus relaciones.
 Tales diagramas son llamados Vista de Clases Participantes (“View of
Participating Classes”) lo que se resume como VOPC.
15. En el siguiente gráfico se muestra las clases participantes en el caso de uso

“Registrar Inscripción en Cursos”

1. A partir de la Especificación de Caso de Uso realice los siguientes diagramas:
a) Diagrama de clases de análisis
b) Diagrama de comunicación del flujo básico
c) Diagrama de comunicación de los subflujos
d) Diagrama de comunicación de los flujos alternativos
ESPECIFICACIÓN DE CASO DE USO: Mantener Competencias
1. Descripción
El caso de uso permite mantener actualizado el registro de las Competencias que
se utilizan como criterios de evaluación de un empleado. De acuerdo a su
necesidad el Gerente RRHH puede agregar, actualizar y desactivar una
competencia.
2. Actor(es)
Gerente RRHH
3. Flujo de Eventos
El caso de uso se inicia cuando el Gerente RRHH selecciona la opción
“Competencias” en la interfaz del menú principal.
3.1. Flujo Básico

1. El sistema muestra la interfaz “MANTENER COMPETENCIA” con la lista de
competencias con los campos: código, tipo, nombre y descripción. Además
muestra las opciones: Agregar Competencia, Actualizar Competencia y
Desactivar Competencia.
2. Si el Gerente RRHH elige una competencia
a. Si elige “Actualizar” ver el Subflujo Actualizar Competencia.
b. Si elige “Desactivar” ver el Subflujo Desactivar Competencia.
3. Si el Gerente RRHH NO elige una competencia
a. Si elige “Agregar” ver el Subflujo Agregar Competencia.
4. El sistema finaliza el caso de uso.
3.2. Subflujos
3.2.1. Agregar Competencia

1. El sistema muestra la interfaz COMPETENCIA con los siguientes
campos: código de la competencia (sólo lectura), tipo, nombre y
descripción. Además muestra las opciones: Aceptar y Cancelar.
2. El Gerente RRHH ingresa los datos de la Competencia.
3. El Gerente RRHH selecciona la opción Aceptar.
4. El sistema valida los datos ingresados.
5. El sistema genera un nuevo código de Competencia.
6. El sistema graba un nuevo registro de Competencia y muestra el
MSG “Competencia creada con código Nro. 999999”.
7. El Gerente RRHH cierra la interfaz COMPETENCIA y regresa a la
interfaz MANTENER COMPETENCIAS con la lista de Competencias
actualizada y el subflujo finaliza.
32
3.2.2. Actualizar Competencia

1. El sistema muestra los datos de la Competencia seleccionada en la
interfaz COMPETENCIA: código de la competencia (sólo lectura), tipo,
nombre y descripción. Además muestra las opciones: Aceptar y
Cancelar.
2. El Gerente RRHH actualiza los datos de la Competencia.
3. El Gerente RRHH selecciona la opción Aceptar.
4. El sistema valida los datos ingresados de la Competencia.
5. El sistema actualiza el registro de Competencia y muestra el MSG
“Competencia actualizada satisfactoriamente”.
6. El Gerente RRHH cierra la interfaz COMPETENCIA y regresa a la
interfaz MANTENER COMPETENCIAS con la lista de Competencias
actualizada y el subflujo finaliza.
3.2.3. Desactivar Competencia

1. El sistema muestra el MSG: “¿Está seguro que desea desactivar la(s)
Competencia(s) seleccionada(s)?”.
2. El gerente RRHH selecciona la opción YES para confirmar la
desactivación.
3. El sistema actualiza el registro de la(s) Competencia(s) en estado
“Desactivada”.
4. El sistema muestra la interfaz MANTENER COMPETENCIA con la lista
de Competencias actualizada y termina el subflujo.
3.3. Flujos Alternativos

1. Datos de la Competencia Inválidos
En el paso 4 de los subfujos Agregar y Actualizar Competencia, si los datos
ingresados son nulos o inválidos el sistema muestra el MSG: “Se han
encontrado datos inválidos” y los subflujos continúan en el paso 2.
2. Competencias ya existe
En el paso 4 de los subfujo Agregar Competencia, si el sistema detecta que la
competencia ya existe muestra el MSG: “Competencia ya existe” y el subflujo
finaliza.
3. No confirma Desactivación
En el paso 2 de los subflujo Desactivar Competencia, si el Gerente RRHH
selecciona NO, finaliza el subflujo.
4. Precondiciones
1. El Gerente RRHH está identificado en el sistema.
2. Lista disponible de Competencias.
5. Poscondiciones
1. En el sistema queda registrado la nueva Competencia.
2. En el sistema queda actualizado el registro de la Competencia.
3. En el sistema queda desactivada la Competencia.
6. Puntos de Extensión
Ninguno.
7. Requisitos Especiales
Ninguno.
8. Prototipos

Resumen
 Para llevar a cabo el análisis de casos de uso se realiza lo siguiente:

 Crear la realización de análisis de casos de uso.
 Encontrar clases de análisis del comportamiento de casos de uso.
 Crear el diagrama de clases (estructura del caso de uso).
 Crear el diagrama de comunicación (comportamiento del caso de uso).
 Una realización de casos de uso describe cómo un caso de uso en particular es

modelado dentro del modelo de análisis primero y después dentro del modelo de
diseño, en términos de objetos colaboradores.
 Existen tres tipos de clases de análisis: Interfaz (boundary), Control (control) y

Entidad (entity).
 VISUAL MODELING WITH IBM RATIONAL ARCHITECT SOFTWARE ARCHI-

TECT AND UML por Terry Quatrani y Jim Palistrant
En el capítulo 6 de este libro se describe cómo crear un modelo de análisis.

34

UNIDAD DE
APRENDIZAJE
1
TEMA
CASO PRÁCTICO

Architect (RSA).
TEMARIO
1. Caso Práctico: Realizaciones de casos de uso
1. Los alumnos crean la realización de un caso de uso.

2. Los alumnos rinden la Evaluación Continua Nº 1.

1) A partir de la Especificación de Caso de Uso realice los siguientes diagramas:
a) Diagrama de clases de análisis
b) Diagrama de comunicación del flujo básico
c) Diagrama de comunicación de los flujos alternativos
Especificación de Caso de Uso: Cotizar Productos
1. Breve Descripción
Este caso de uso consiste en registrar una cotización para el cliente que lo solicite.
Esta cotización se emitirá en estado pendiente y cuando el cliente la apruebe, el
vendedor le cambiará el estado y la enviará vía fax firmada. Con este documento
se procederá a generar las notas de pedido y facturación.
2. Flujo de Eventos
2.1. Flujo Básico
1. El Caso de Uso se inicia cuando el Vendedor selecciona “Cotizar Productos”
en la interfaz del menú principal.
2. El sistema muestra la interfaz “Cotización de Productos” con los campos:
 Datos del cliente: RUC/DNI, apellidos, nombres, dirección y teléfono.
 Datos de los productos a cotizar: código, descripción, margen de
ganancia (MG), precio de venta unitario (PVU), precio de costo unitario
(PCU).
 Datos de la cotización: Número de Cotización, precio de venta neto
(PVN), el precio de venta total (PVT), la disponibilidad de entrega y el
Tipo de pago.
 Además se tiene las opciones: “Buscar Cliente”, “Buscar Productos”,
“Grabar Cotización”, “Registrar Nuevo Cliente”, “Generar N. Pedido y
Facturación” y “Salir”.
3. El vendedor solicita buscar al cliente.
4. El sistema Incluye el caso de uso “Buscar Cliente”.
5. El sistema muestra los datos del cliente: nombres, apellidos, dirección y
teléfono.
6. El vendedor solicita buscar Productos.
7. El sistema Incluye el caso de uso “Buscar Productos”.
8. El sistema muestra la descripción y PCU del producto seleccionado.
9. El Vendedor ingresa el PVU (tentativo) del producto negociado con el Cliente.
10. El sistema muestra el margen de ganancia (PVU – PCU).
11. El Vendedor acepta el precio de venta PVU (acordado).
12. Si el Vendedor quiere adicionar otro producto se repite el flujo del paso 5 al 9.
13. El Vendedor ingresa la disponibilidad de entrega de los productos cotizados
(inmediata o en un tiempo determinado) y el tipo de pago (adelanto, %pago o
al crédito).
14. El sistema calcula y muestra el precio de venta neto (PVN) y el precio de
venta total (PVT).
15. El Vendedor solicita “Grabar Cotización”.
16. El sistema obtiene el último número de Cotización y autogenera un código.
17. El sistema graba la cotización en estado “Pendiente” con su detalle (por
producto), muestra el Nro. de Cotización, imprime la cotización y muestra el
mensaje “Cotización No. 9999999 grabada correctamente”.
18. El Vendedor solicita “Salir”, el sistema cierra la interfaz y el caso de uso
ANÁLISIS Y DISEÑO DE SISTEMAS II (TEORÍA) 37
termina.
2.2.1. Cliente no existe

Si el sistema no retorna con datos del cliente, enviará el mensaje “Cliente no
encontrado” y ofrecerá la posibilidad de registrar al nuevo cliente.
2.2.2. Cotización no registrada
Si el sistema no llega a grabar la cotización y/o detalles enviará el mensaje
“Cotización no registrada” y el caso de uso finaliza.
2.2.3. Productos no existen
Si el sistema no encuentra el (los) producto(s), enviará el mensaje “Producto no
encontrado” y el caso de uso finaliza.
1. Aprovisionamiento de papel para emitir la cotización.
4. Precondiciones
1. Tener registrados los productos con sus respectivos códigos y precios de
costos unitarios.
5. Poscondiciones
1. La cotización queda registrado con su detalle en estado “Pendiente”, en
espera de cambio a estado “Aceptada”.
6. Puntos de extensión
1. En el paso 5, el sistema extiende al caso de uso Mantener Clientes – Flujo
básico “Registrar Cliente”.
2. En el punto 17, el sistema extiende al caso de uso “Generar Nota de
Pedido y Facturación” si el Cliente aprueba por teléfono la cotización.
7. Prototipo

38

UNIDAD DE
APRENDIZAJE
1
TEMA
ANÁLISIS DE CLASES

Architect (RSA).
TEMARIO
1. Análisis de Clases.
2. Tarjetas CRC.
1. Los alumnos confeccionan las tarjetas CRC de las clases que participan en el
caso de uso especificado.

40
1. ANÁLISIS DE CLASES
El objetivo de esta actividad es describir cada una de las clases que se ha
encontrado en el análisis de casos de uso, identificando las responsabilidades
que tienen asociadas, sus atributos, y las relaciones entre ellas.

Los pasos que se realizan en esta actividad son:
 Identificación de responsabilidades y atributos
 Identificación de asociaciones y agregaciones
 Identificación de generalizaciones
1.1.1. Identificación de responsabilidades y atributos

El objetivo de esta tarea es identificar las responsabilidades y
atributos relevantes de una clase.
Las responsabilidades de una clase definen la funcionalidad de esa

clase, y están basadas en el estudio de los papeles que desempeñan
sus objetos dentro de los distintos casos de uso. A partir de estas
responsabilidades, se puede comenzar a encontrar las operaciones
que van a pertenecer a la clase. Éstas deben ser relevantes, simples,
y participar en la descripción de la responsabilidad.
Los atributos de una clase especifican propiedades de la clase, y se

identifican por estar implicados en sus responsabilidades. Los tipos
de estos atributos deberían ser conceptuales y conocidos en el
dominio.
De manera opcional, se elabora una especificación para cada clase,

que incluye: la lista de sus operaciones y las clases que colaboran
para cubrir esas operaciones y una descripción de las
responsabilidades, atributos y operaciones de esa clase.
Para aquellas clases cuyo comportamiento dependa del estado en el

que se encuentren se realiza, también de manera opcional, un
diagrama de transición de estados.
1.1.2. Identificación de asociaciones y agregaciones

En esta tarea se estudian los mensajes establecidos entre los objetos
del diagrama de interacción para determinar qué asociaciones
existen entre las clases correspondientes. Estas asociaciones suelen
corresponderse con expresiones verbales incluidas en las
especificaciones.
Las relaciones surgen como respuesta a las demandas en los

distintos casos de uso, y para ello puede existir la necesidad de
definir agregaciones y herencia entre objetos.
Una asociación esta caracterizada por:

 Los papeles que desempeña.
 Su direccionalidad, que representa el sentido en el que se debe
interpretar.

 Su cardinalidad, que representa el número de instancias

implicadas en la asociación.
Dichas características pueden obtenerse a partir de la especificación

de los casos de uso.
1.1.3. Identificación de generalizaciones

El objetivo de esta tarea es representar una organización de las
clases que permita una implementación sencilla de la herencia y una
agrupación semántica de las diferentes clases.
2. Tarjetas Clase – Responsabilidad - Colaboración

A fines de la década de 1980, uno de los centros más grandes de tecnología de
objetos era el laboratorio de investigación de Tektronix, en Portland, Oregon,
Estados Unidos. Este laboratorio tenía algunos de los principales usuarios de
Smalltalk y muchas de las ideas clave de la tecnología de objetos se desarrollaron
allí. Dos de sus programadores renombrados de Smalltalk eran Ward
Cunningham y Kent Beck.
Tanto Cunningham como Beck estaban y siguen preocupados por cómo enseñar
los profundos conocimientos de Smalltalk que habían logrado. De esta pregunta
sobre cómo enseñar objetos surgió la sencilla técnica de las tarjetas de Clase-
Responsabilidad-Colaboración (CRC).
En lugar de utilizar diagramas para desarrollar modelos, como lo hacían la

mayoría de los metodólogos, Cunningham y Beck representaron las clases en
tarjetas 4 x 6 [pulgadas]. Y en lugar de indicar atributos y métodos en las tarjetas,
escribieron responsabilidades y colaboradores.
2.1. Descripción de las tarjetas CRC

La tarjeta se divide en tres compartimientos, tal como se muestra en la figura
4.1. En el compartimiento superior izquierdo se escribe el nombre de la clase
candidata; en el compartimiento inferior izquierdo, las responsabilidades; y en
el derecho, los colaboradores.
Figura 4.1 Tarjeta de Clase-Responsabilidad-Colaboración (CRC)
Las responsabilidades de una clase pueden recopilarse combinando todos

los roles que cumple en las diferentes realizaciones de caso de uso.
Identificar las realizaciones de caso de uso en las cuales participa mediante
el estudio de sus diagramas de clases e interacción.

42
En el diagrama de comunicación cuando se tiene que describir los flujos

básico y alternativos, un mensaje debería reflejar el propósito del objeto
invocante en la interacción con el objeto invocado. Este propósito es el origen
de una responsabilidad del objeto receptor y podría llegar hacer el nombre de
una responsabilidad.
Los colaboradores son otras clases que pueden colaborar con esta clase
para realizar una parte de la funcionalidad del sistema. El compartimiento de
colabores proporciona una forma de grabar reacciones entre clases.
Uno de los principales beneficios de las tarjetas de CRC es que alientan la

disertación animada entre los desarrolladores. Son especialmente eficaces
cuando se está en medio de un caso de uso para ver cómo lo van a
implementar las clases. Los desarrolladores escogen tarjetas a medida que
cada clase colabora en el caso de uso. Conforme se van formando ideas
sobre las responsabilidades, se pueden escribir en las tarjetas. Es importante
pensar en las responsabilidades, ya que evita pensar en las clases como
simples repositorios de datos, y ayuda a que el equipo se centre en
comprender el comportamiento de alto nivel de cada clase.
2.2. Limitaciones de las tarjetas CRC

Aunque las tarjetas CRC pueden ser una herramienta poderosa para
empezar el diseño, tienen limitaciones inherentes. El primer problema es que
no tienen un escalamiento exitoso. En un proyecto muy complejo, puede
agobiarse con las tarjetas CRC; el simple hecho de mantener un registro de
todas ellas puede ser difícil. El problema se torna más difícil aún al tratar de
mantener sincronizados entre sí, a las tarjetas y los modelos de UML de las
clases.
Por otro lado, las tarjetas CRC tampoco capturan la interrelación entre clases.
Aunque es cierto que todas las colaboraciones se toman en cuenta, la
naturaleza de la colaboración no se modela bien. Al ver las tarjetas CRC no
se puede saber quién crea a quién, si las clases se agregan unas a otras, o si
una responsabilidad corresponde a una o más clases colaboradoras.
En resumen, las tarjetas CRC son un buen inicio por mantener documentadas
las clases de análisis, pues a partir de ellas se tendrá una visión general del
comportamiento de una clase con respecto de otras, pero una vez que se
tenga conocimiento de las clases y lleguen a su etapa de diseño, estas
tarjetas ya no les será útil y quizá ya no necesitará actualizarlas.

3. Caso Práctico
A continuación se explicará cómo confeccionar las tarjetas CRC para las clases
participantes del caso de uso Pagar Préstamos de Terceros.
PASO 1: Revisar la Especificación del caso de uso
Especificación de Caso de uso: Pagar Préstamos de Terceros

1. Breve descripción
El caso de uso permite a un Cliente del Banco efectuar el pago de préstamos de
terceros con cargo en su cuenta de ahorros. Además, actualiza el saldo contable
en el “Sistema Contable”.
2. Actores
Cliente
3. Flujo de Eventos
3.1. Flujo Básico
1. El caso de uso comienza cuando el Cliente selecciona la opción Pago de
Préstamos y la sub opción Préstamos de Terceros en la interfaz del menú
principal.
2. El sistema muestra la interfaz “Pago de Préstamos de Terceros” con los
campos número de cuenta de préstamo, monto y moneda. Además,
muestra una lista con las cuentas de cargo (cuenta de ahorros).
3. El Cliente ingresa cuenta de préstamo, monto y selecciona moneda.
4. El Cliente selecciona una cuenta de cargo.
5. El Cliente selecciona continuar.
6. El sistema verifica saldo de cuenta.
7. El sistema muestra la interfaz “Confirmación de Pago” con los datos:
cuenta del préstamo, cuenta de cargo, monto y moneda del préstamo.
Además muestra el mensaje “Ingresar su clave para confirmar”.
8. El cliente ingresa su clave de acceso.
9. El cliente confirma la operación.
10. El sistema registra la transacción con el Número de Operación, cuenta de
préstamo, cuenta de cargo, monto, moneda del préstamo y fecha y hora
de la transacción.
11. El sistema actualiza el saldo contable en el “Sistema Contable” y actualiza
el saldo de la cuenta de cargo.
12. El sistema muestra el número de la operación y el MSG: ”Pago de
préstamo efectuado correctamente”.
13. El cliente selecciona “Salir”, se cierra la interfaz y el caso de uso finaliza.

3.2.1. Pago no efectuado
Si el sistema detecta que el saldo de la cuenta de cargo es insuficiente
para realizar el pago, el sistema muestra el MSG “Saldo insuficiente para
efectuar pago” y el caso de uso continúa en el paso 2.
4. Pre Condiciones
1. El cliente logeado al sistema con su número de tarjeta y clave.
2. Disponible las cuentas de ahorro (cuentas de cargo).

44
5. Post Condiciones
1. En el sistema quedará registrado la transacción.
2. En el sistema quedará actualizado el saldo de la cuenta de ahorros.
3. Se actualizará el saldo contable en el “Sistema Contable”.
6. Puntos de extensión
1. En el paso 9, si la moneda de la cuenta de cargo es diferente a la del
préstamo, el sistema extiende al caso de uso “Convertir moneda” a una cuenta
de ahorros del cliente.
1. Alta seguridad en el manejo de las claves y cuentas.
8. Prototipos
PASO 2: Realizar el diagrama de clases

PASO 3: Realizar el diagrama de comunicación del flujo básico y del flujo alternativo
Flujo Básico
PASO 4: Confeccionar las tarjetas CRC por cada clase de análisis
Se empezará a realizar las tarjetas CRC en orden alfabético por tipo de clase. Primero
empezaremos con los boundary, luego con la clase control y al final con los entity.
Nombre de Clase: CI_ConfirmacionPago

Responsabilidad Colaboradores
1. Solicitar clave de acceso CC_Prestamo
2. Solicitar la confirmación de operación
3. Mostrar interfaz con datos del pago
4. Mostrar mensaje “Ingresar clave”
5. Mostrar nro. de transacción
6. Mostrar mensaje “Pago efectuado correctamente”
Nombre de Clase: CI_MenuPrincipal

1. Solicitar la selección de “Pago de CC_Prestamo
Préstamos/Préstamos Personales”
Nombre de Clase: CI_PagoPrestamoTerceros

1. Solicitar la selección de “Continuar “ CC_Prestamo
2. Solicitar la selección de moneda
3. Solicitar la selección de cuenta de cargo
4. Solicitar cuenta de préstamos
5. Solicitar monto
6. Mostrar lista de monedas
7. Mostrar cuentas de ahorro
8. Mostrar mensaje “Saldo insuficiente”
Nombre de Clase: CI_SistContable

1. Actualizar saldo contable CC_Prestamo
Nombre de Clase: CC_Prestamo

1. Cargar monedas CI_MenuPrincipal
2. Cargar cuentas de ahorros CI_PagoPrestamoTerceros
3. Verificar saldo de cuenta de ahorro CI_ConfirmacionPago
4. Verificar clave de acceso CI_SistemaContable
5. Registrar transacción TarjetaXCliente
6. Actualizar saldos de cuentas Moneda
CtaAhorros
Transacción
Nombre de Clase: CtaAhorros

1. Obtener cuentas de ahorro CC_Prestamo
2. Obtener saldos
3. Disminuir saldos
Nombre de Clase: Moneda

1. Obtener monedas CC_Prestamo
Nombre de Clase: TarjetaXCliente

1. Obtener clave de acceso CC_Prestamo
Nombre de Clase: Transaccion

1. Obtener máximo número de transacción CC_Prestamo
2. Guardar datos

48
A partir de la Especificación de Caso de Uso realice los siguientes artefactos:
1. Diagrama de clases de análisis
2. Diagrama de comunicación del flujo básico
3. Diagrama de comunicación de los flujos alternativos
4. Tarjeta CRC de las clases
Especificación de caso de uso: Reservar pistas de juego

1. Descripción:
El caso de uso permite al encargado de reservas de un club de deportes,
registrar una reserva de pista para un socio. El sistema se comunica con el
Sistema de Cuentas por Cobrar (SCC), para registrar las reservas pendientes
de pago del socio.
2. Actores
Encargado de reservas
3. Flujo de Eventos
3.1. Flujo Básico

1. El caso de uso comienza cuando el Encargado de reservas selecciona
la subopción “Reservar pistas” de la opción “Reservas” de la interfaz del
menú principal.
2. El sistema muestra la interfaz “RESERVAS PISTAS” con una Lista de
todas las reservas de pistas del día, ordenadas por hora prevista, y
campos para realizar una reserva.
 Datos de la lista son: número de reserva, nombre completo del socio
que reservó, número de pista, hora de entrada y número de horas
que estará ocupada la pista.
 Datos de la Reserva son: código de socio, fecha y hora de reserva,
número de pista y número de horas que estará ocupada la pista.
 Además presenta las opciones: Grabar reserva, Buscar socio y
Consultar disponibilidad de pistas.
3. El Encargado de reservas ingresa el código del socio.
4. El Encargado de reservas selecciona “Consultar disponibilidad de
pistas”.
5. El sistema incluye el caso de uso Consultar disponibilidad de
pistas.
6. El sistema muestra la fecha y hora de reserva, nro. de pista y nro. de
horas que estará ocupada la pista.
7. El Encargado de reservas selecciona “Grabar reserva”.
8. El sistema valida los datos ingresados.
9. El sistema genera el número de reserva y registra la reserva de pista,
registra el estado de la pista como reservada en le fecha y horas
indicadas.
10. El sistema se comunica con el SCC, para registrar la reserva pendiente
de pago del socio con los siguientes datos: número de reserva, fecha
de registro, código de socio, número de pista, horas de uso y monto a
pagar.
11. El sistema muestra el MSG “Reserva generada” y el caso de uso
termina.

3.2.1. Código de Socio no Válido

Si el sistema detecta que el código del socio no es válido, muestra el
MSG “Código de Socio incorrecto” y el sistema ofrecerá la posibilidad
de buscar al socio y el caso de uso continúa en el punto 7.
4. Pre Condiciones
1. El Encargado de reservas logeado al sistema.
2. Comunicación activa con el SCC.
3. Lista de Socios registrados.
4. Lista de pistas de juego disponibles.
5. Post Condiciones
1. El sistema quedará registrado la reserva de pista de juego.
2. La disponibilidad de la pista de juego quedará registrada como reservada en
la fecha y horas especificadas.
3. En el SCC quedará registrado la reserva del socio pendiente de pago.
1. En el punto 3, si el socio no muestra su carné en el cual se indica su
código, el Sistema extiende al Caso de Uso “Buscar socio”.
1. Comunicación con SCC.
8. Prototipos

50
Resumen
 Para llevar a cabo el análisis de clases se realiza lo siguiente:

 Identificación de responsabilidades y atributos
 Identificación de Asociaciones y Agregaciones
 Identificación de Generalizaciones
 La tarjeta CRC es una técnica para identificar responsabilidades y colaboradores

de una clase. Su objetivo es facilitar la comunicación y documentar los resultados
del análisis.
 La tarjeta se divide en tres compartimientos. En el compartimiento superior

izquierdo se escribe el nombre de la clase candidata; en el compartimiento inferior
izquierdo, las responsabilidades; y en el derecho, los colaboradores.
 Si desea saber más acerca de estos temas, puede consultar el siguiente enlace.
 http://c2.com/doc/oopsla89/paper.html
En este link muestra un paper sobre las Tarjetas CRC.

UNIDAD DE
APRENDIZAJE
1
TEMA
MODELO CONCEPTUAL

Architect (RSA).
TEMARIO
1. Modelo Conceptual.
1. Los alumnos desarrollan el Modelo Conceptual de un caso propuesto.

52
1. MODELO CONCEPTUAL
Las clases del modelo conceptual se obtienen a partir de los objetos de

información que fluyen entre las actividades. Una característica importante
que resaltar es que el modelado de los casos de uso del sistema y el
modelado conceptual se realizan en paralelo, esto es crucial para obtener
casos de uso correctos, puesto que es necesario entender bien el dominio
para poder escribir casos de uso que sean realmente útiles.
Realización de los
Definición de la 1ra. casos de uso:
Capa: Aplicación Diagramas de
Clases y
Diagramas de
Comunicación
Revisión de los
paquetes y sus
contenidos
Modelo Conceptual
Modelo Lógico
Modelo Físico
Figura 5.1. El Modelo Conceptual en el Flujo de Trabajo de Análisis y Diseño
1.1. Importancia del Modelo Conceptual
1. El Modelo Conceptual Orientado a Objetos beneficiará a dos equipos de

trabajo:
 Equipo de Desarrolladores
En esta etapa del desarrollo, merece la pena detenerse en la
identificación de los conceptos y no tanto en las relaciones entre ellos.
Este modelo incluirá los conceptos y sus relaciones y se describirá
mediante un diagrama de clases UML, en el que los conceptos se
representan mediante clases (del dominio).
 Equipo de Base de Datos

En esta etapa luego del modelo conceptual, se obtiene el proceso del
modelo lógico al diseño físico donde se podrá identificar las tablas
relacionales del proyecto de Base de Datos como componente RUP.

1.2. Construcción del Modelo Conceptual
1.2.1 Identificar las clases persistentes con sus atributos
• La Clase es la unidad básica que encapsula toda la información de

un objeto (un objeto es una instancia de una clase). A través de ella
podemos modelar el entorno en estudio (una Casa, un Auto, una
Cuenta Corriente, etc.).
• Los Atributos rrepresentan las propiedades de la clase que se
encuentran en todas las instancias de la clase. Definen la
estructura de una clase y de sus objetos.
• Los atributos corresponden a sustantivos y sus valores pueden ser
sustantivos o adjetivos.
• Dentro de una clase, los nombres de los atributos deben ser únicos
(aunque puede aparecer el mismo nombre de atributo en diferentes
clases).
• Los atributos pueden representarse sólo mostrando su nombre, su
tipo e incluso su valor por defecto.
- Public: Indica que el atributo será visible tanto dentro
como fuera de la clase, es decir, es accesible desde
todos lados.
- Prívate: Indica que el atributo sólo será accesible

desde dentro de la clase (sólo sus métodos lo
pueden acceder).
- Protected: Indica que el atributo no será accesible

desde fuera de la clase, pero si podrá estar disponible
para métodos de la clase además de las subclases
que se deriven.
Figura 5.2. Miembros de una clase

54
• Para los Identificadores, en el momento de incluir atributos en la

descripción de una clase se debe distinguir entre los atributos que
reflejan las características de los objetos en el mundo real, y los
identificadores que son utilizados por razones de implementación.
Figura 5.3. Clase con identificador Vs. clase sin identificador
• Guías prácticas para la definición de Clases y Atributos

- Las clases poseen información descriptivas; los atributos no.
- Los atributos multivaluados deben ser clasificados como
clases.
- Convertir en una clase a un atributo que tenga una relación
muchos-a-uno con otra clase.
- Asociar atributos a las clases que ellos describen más
directamente. Los atributos deben ser inherentes a la clase.
- Evitar los identificadores compuestos en la medida que sea
posible.
1.2.2 Definir Jerarquías

Generalización y Especialización son conceptos fundamentales en el
Modelo Conceptual que permiten la reducción de la expresión. Las
jerarquías de clases son a menudo las bases de inspiración para las
jerarquías de las clases de software que exploten la herencia y
reduzcan la duplicación de código.
Figura 5.3. Jerarquía de clases.
• Permiten gestionar la complejidad mediante un ordenamiento lógico.

• 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.
• Nombres usados: clase padre - clase hija, superclase - subclase,
clase base - clase derivada
• Las subclases heredan características de sus superclases, es decir,
los atributos y operaciones (y asociaciones) de la superclase están
disponibles en sus subclases.
Figura 5.4. Notación de la generalización
Ejemplos:
1.2.3. Identificar Agregaciones

• La Agregación indica una relación de “un todo conformado por
partes”
• Existen 2 tipos de agregaciones:
o Agregación Débil o Compartida
o Agregación Fuerte o Compuesta
• La agregación representa una relación parte de entre objetos.
• En UML se proporciona una escasa caracterización de la
agregació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.

56
Figura 5.5. Agregaciones entre clases
a) Agregación Compartida
Es un tipo de relación utilizada para modelar la relación todo-parte
entre objetos. La parte puede estar simultáneamente en varias
instancias del todo.
La agregación existe de preferencia entre conceptos no físicos.
Ejemplo:
b) Agregación Compuesta
Es un tipo de relación utilizada para modelar la relación todo-parte

entre objetos. Significa que la parte es miembro de solamente un
objeto todo, es decir la existencia de la parte depende del todo. La
composición se representa con un diamante relleno.
El objeto todo es el único dueño del objeto parte.
Ejemplo:

1.2.4. Asociar Clases

• La asociación es una relación entre clases que indica una conexión
significativa e interesante.
• Está representada como una línea entre clases con nombre. La
asociación es inherentemente bidireccional.
• Es convencional leer la asociación de izquierda a derecha o de
arriba hacia abajo.
• Las asociaciones pueden ser binarias, ternarias, o de mayor grado.
• Criterios para identificar asociaciones
o Enfocarse en aquellas asociaciones para las cuales el
conocimiento de la relación necesita ser conservado en el
tiempo. (Asociaciones que se necesitan saber).
o Demasiadas asociaciones tienden a confundir.
o Evitar mostrar asociaciones redundantes o derivables.
o Pueden existir múltiples asociaciones entre dos clases.
• Tipos de Asociaciones:
o Asociación Binaria
o Asociación Ternaria
o Asociación Reflexiva
Recepcionista
registra
genera
Cliente Orden Servicio
Figura 5.6. Asociación Binaria.
Figura 5.7. Asociación Ternaria.
Figura 5.8. Asociación Reflexiva.

58
• Multiplicidad
o Restringe el número de objetos de una clase que se pueden

implicar en una relación determinada en cualquier momento en
el tiempo. La frase “en cualquier momento en el tiempo” es
vital para entender las multiplicidades.
o Define cuantas instancias de la clase A pueden estar

asociadas con una instancia de la clase B.
o En el siguiente ejemplo, se visualiza que en cualquier

momento en el tiempo un objeto Ítem esta alojado por
exactamente un objeto Almacén. Sin embargo, con el tiempo
un objeto Ítem podría estar alojado por una serie de objetos
Almacén. Se puede resumir diciendo que un objeto Almacén
aloja varios objetos de Ítem.
Almacen aloja Item

1 *
o Si la multiplicidad no se indica explícitamente, esta pendiente,

no existe.
o La multiplicidad presenta las relaciones con valores de datos

de acuerdo al detalle siguiente :
Item
Muchos
*
Item Uno o muchos

1..*
Item Cero o muchos

0..*
Item Cero o uno

0..1
Item
1 a 40
1..40
Item
5 Exactamente 5
Item Exactamente 3,5 u 8

3,5,8
Figura 5.9. Multiplicidad

• Clases Asociativas
o Un atributo está relacionado con la asociación.

o Las instancias de la clase asociativa dependen del tiempo de
vida de la asociación.
o En una asociación de muchos a muchos entre dos clases y
existe información asociada con la propia asociación.
1.2.5. Definir Operaciones

Las operaciones son funciones o transformaciones que se aplican a
todos los objetos de una clase particular. La operación puede ser una
acción ejecutada por el objeto o sobre el objeto.
Ejemplo:
1.2.6. Documentar Reglas de Negocio

Las reglas del negocio identificadas durante el análisis de los requisitos
se continuarán refinando a lo largo de la elaboración del modelo
conceptual.
Es importante que la documentación de cada regla del negocio sea

ejemplificada con una situación real.

60
Ejemplo: Modelo Conceptual del Caso Cotización
El ejemplo nos muestra la relación entre las clases persistentes (entity), tenemos
generalización (Persona-Cliente-Vendedor), Clase Asociativa (Cotización-Producto-
DetalleCotizacion), agregación compuesta (provincia-distrito) y asociaciones entre
ellas y sucursal.

1. A partir de la Especificación del Caso de Uso “Reservar pistas de juego”, de la
sesión anterior, confeccione el Modelo Conceptual.

62
Resumen
 En el modelo conceptual, las clases se obtienen a partir de los objetos de

información que fluyen entre las actividades. El modelado de los casos de uso del
sistema y el modelado conceptual se realizan en paralelo, esto es crucial para
obtener casos de uso correctos, puesto que es necesario entender bien el dominio
para poder escribir casos de uso que sean realmente útiles.
 El modelo conceptual orientado a objetos beneficiará a dos equipos de trabajo :
• Equipo de Desarrolladores
En esta etapa del desarrollo, merece la pena detenerse en la identificación de
los conceptos y no tanto en las relaciones entre ellos. Este modelo incluirá los
conceptos y sus relaciones y se describirá mediante un diagrama de clases
UML, en el que los conceptos se representan mediante clases (del dominio).
• Equipo de Base de Datos

En esta etapa luego del modelo conceptual, se obtiene el proceso del modelo
lógico al diseño físico donde se podrá identificar las tablas relacionales del
proyecto de Base de Datos como componente RUP
 Si desea saber más acerca de estos temas, puede consultar la siguiente página.
http://www.gdl.cinvestav.mx/telecom/uploads/Prope_2008/Programacion/Programa
cion%20OOP-1.pdf
Aquí hallará en síntesis la información relacionada al modelo conceptual y la

multiplicidad.

UNIDAD DE
APRENDIZAJE
1
TEMA
CASO PRÁCTICO

Architect (RSA).
TEMARIO
1. Casos Prácticos.
1. Los alumnos desarrollan la arquitectura de análisis, las realizaciones de casos

de uso y el modelo conceptual a partir de la Especificación de Caso de Uso.

64
1. A partir de la Especificación de Caso de Uso realice los siguientes artefactos:
a. Diagrama de clases de análisis
b. Diagrama de comunicación del flujo básico
c. Modelo conceptual
CASO PRÁCTICO Nº 1: CLINICA “MI SALUD”

Se desea construir un sistema de información que automatice la admisión de
pacientes, ya sea ambulatoria y emergencia; servicios prioritarios que ofrece la Clínica.
A continuación se describe el Caso de Uso “Admitir pacientes”.
Nombre del caso de Uso: Admitir Pacientes

El caso de uso permite aceptar la admisión para la atención médica en la Clínica.
2. Actores
Personal de Admisión.
3. Flujo de Eventos
3.1. Flujo Básico

1. El Personal de Admisión solicita “Admitir Pacientes” en la interfaz del menú
principal.
2. El sistema muestra la interfaz “Proceso de Admisión“ con el MSG “Ingrese
opción Ambulatoria y Emergencia”.
3. El Personal de Admisión selecciona una de las opciones y luego presiona
“Buscar Paciente”.
4. El sistema incluye el caso de uso “Buscar Paciente”.
5. El sistema muestra Apellidos y Nombres del paciente, Nro. De Historia
Clínica, peso, talla y edad.
6. El sistema muestra un cuadro de atención médica del paciente desde el
primer día de atención a la clínica, especificando los problemas de salud
(diagnostico, tratamiento y resultado).
7. El Personal de Admisión selecciona la opción Médico Disponible
8. El sistema incluye el caso de uso “Buscar Médico”.
9. El sistema muestra la lista de médicos disponibles para la atención y
muestra el mensaje “Elegir Médico”.
10. El Personal de Admisión selecciona el Médico generando la cita respectiva.
11. El Personal de Admisión confirma el cobro de la cita médica para el
paciente.
12. El sistema registra la información del cobro de la cita médica, y actualiza la
cantidad de citas médicas correspondiente al médico elegido e imprime la
cita correspondiente.
13. El Personal de Admisión selecciona “Salir” y el caso de uso finaliza.

3.2.1. Cita completa

Si el el médico seleccionado ha completado su cita para el sistema
muestra el MSG “Citas completas “, debiendo seleccionar otro medico,
el caso de uso continua en el paso 7.
4. Pre Condiciones
1. El Personal de Admisión logeado al sistema.
2. Lista de Pacientes registrados.
3. Lista de médicos disponibles.
5. Post Condiciones
1. El sistema quedará registrado la reserva de pista de juego.
2. La disponibilidad de la pista de juego quedará registrada como reservada en la
fecha y horas especificadas.
3. En el SCC quedará registrado la reserva del socio pendiente de pago.
1. En el punto 3, si el socio no muestra su carné en el cual se indica su código, el
Sistema extiende al Caso de Uso “Buscar socio”.
Ninguno
8. Prototipos

66

UNIDAD DE
APRENDIZAJE
2
TEMA
INGENIERÍA DE REQUISITOS
Al finalizar la segunda unidad, el alumno documenta los requisitos funcionales y no

funcionales de un software que da soporte a un proceso de negocio, y controla sus
cambios haciendo uso de la herramienta CASE IBM Rational Requisite PRO.
TEMARIO
1. La Ingeniería de Requisitos
2. El proceso de Ingeniería de Requisitos
1. Los alumnos indican los factores que causan problemas a los proyectos de
software conocidos como challenged project.
2. Los alumnos indican brevemente los aspectos más significativos de tres
estrategias no convencionales para la gestión de requisitos.

68
1. INGENIERÍA DE REQUISITOS
En el proceso de desarrollo de un sistema, sea Web o de escritorio, el equipo de
desarrollo se enfrenta al problema de la identificación de requisitos. La definición
de las necesidades del sistema es un proceso complejo, pues en él hay que
identificar los requisitos que el sistema debe cumplir para satisfacer las
necesidades de los usuarios finales y de los clientes.
Para realizar este proceso, no existe una única técnica estandarizada y

estructurada que ofrezca un marco de desarrollo que garantice la calidad del
resultado. Por el contrario, existe un conjunto de técnicas, cuyo uso proponen las
diferentes metodologías para el desarrollo de aplicaciones y que en general,
buscan en recopilar la mayor cantidad de requisitos correctos para así conformar
una buena estructura que servirá de base para el desarrollo de un proyecto. Se
debe tener en cuenta que la selección de las técnicas y el éxito de los resultados
que se obtengan, depende en gran medida tanto del equipo de análisis y
desarrollo, como de los propios clientes o usuarios participantes.
La Ingeniería de Requisitos (IR) es un proceso que propone la utilización de

técnicas repetibles y sistemáticas para asegurar la completitud, consistencia y
relevancia de los requisitos de un sistema. Este proceso no sólo se realiza en las
primeras etapas del desarrollo de un proyecto, sino que influye decisivamente en
el resto del proceso de desarrollo y mantenimiento.
1.1. Antecedentes
Las principales causas del surgimiento de la IR o gestión de requisitos, como
algunos autores la denominan, fueron los resultados de las investigaciones
realizadas por diversas entidades a raíz de la denominada "Crisis del
Software1". Estos resultados brindaron interesantes pistas sobre dónde poner
el foco para mejorar el trabajo durante el ciclo de desarrollo de software y por
consiguiente reducir los fracasos y problemas.
Algunas de las instituciones que realizaron informes y análisis estadísticos

son: GAO2 cuyo personal analizaron proyectos de desarrollo de software para
el gobierno norteamericano, el ESPITI3 que realizó investigaciones sobre los
principales problemas en el desarrollo de software a nivel europeo, y cuyos
resultados son muy similares a los obtenidos por The Standish Group4,
indicando que los mayores problemas de proyectos de desarrollo en Estados
Unidos están relacionados con la gestión de requisitos.
La seriedad y el profesionalismo del grupo Standish lo convirtieron en un

referente mundial sobre los factores que inciden en el éxito o fracaso de los
proyectos de TI, exponiendo sus análisis periódicas desde 1994 en "The
CHAOS Report5".
1
Crisis del software es un término acuñado al hecho de que muchos desarrollos de software no
han concluido, por motivos diversos, satisfactoriamente.
2
Government Account Office - Oficina de Contabilidad del Gobierno de EEUU.
3
European Software Process Improvement Training Initiative.
4
The Standish Group es un grupo consultor, fundado en 1985 por un grupo de profesionales
de West Yarmouth, Massachussets. Su visión es obtener información de los proyectos fallidos
de TI. Su objetivo es encontrar las causas de los problemas y fracasos de proyectos TI.
5
The CHAOS Report presenta informes de los resultados de encuestas que The Standish
Group realiza a los responsables de proyectos de desarrollo de software.

A continuación se exponen las circunstancias que han convencido a la gran

parte de la comunidad de la ingeniería del software de la necesidad, cada vez
mayor, de una ingeniería de requisitos.
En 1979, GAO realizó un estudio seleccionando nueve proyectos de

desarrollo de software para el gobierno norteamericano cuyos contratos
sumaban una cantidad total de 6.800.000 dólares. De esta cantidad, sólo
119.000 dólares correspondían a un proyecto que se había utilizado tal como
se había entregado. Dicho proyecto se trataba de un pre-procesador de
COBOL, por lo que era un problema relativamente simple cuyos requisitos
eran comprendidos por clientes y desarrolladores y que además no
cambiaron durante el desarrollo.
El resto de los 6.8 millones de dólares se distribuyeron como puede verse en

la figura 8.1, en la que puede destacarse el enorme porcentaje de dinero
invertido en proyectos cancelados o no satisfactorios.
Fuente: Informe de GAO - 1979.
Figura 8.1. Resultado del informe de GAO (1979)
Después de 15 años, el estudio que el grupo Standish realizó en 1994 fue

mucho más amplio y significativo que el del GAO. El grupo consultor realizó
encuestas a directores de proyectos de TI sobre la situación del desarrollo de
software y sus principales problemas en Estados Unidos. Los resultados de
estos informes muestran que casi un tercio de los proyectos de desarrollo de
software se cancelan durante su desarrollo y que más del 50 por ciento
presenta graves desviaciones respecto a plazos y presupuestos iniciales.
Los resultados generales, que pueden verse en la figura 8.2, si se compara

con los de GAO presentan una mejora en los proyectos que se entregan
cumpliendo todos sus requisitos, 2% frente al 16.2%, pero empeoran
ligeramente respecto a los que se abandonan durante el desarrollo, 28.7%
frente a 31.1%.
Sin incluir al 16.2% de los proyectos terminados correctamente, la media del

gasto final fue del 189% del presupuesto original, el tiempo necesario para su
realización del 222% del plazo original y se cumplieron una media del 61% de
los requisitos iniciales; cifras que se dieron tanto en pequeñas como en
grandes compañías.

70
Fuente: Informe CHAOS por The Standish Group [TSG 1994].
Figura 8.2. Resultado del informe CHAOS (1994)
En este sentido, el grupo consultor citado clasifica los proyectos en tres

categorías:
 Proyectos exitosos (successful): Aquellos que son completados a

tiempo y según el presupuesto, con todas las características y
funcionalidades especificadas inicialmente.
 Proyectos con desafíos o problemas (challenged): Aquellos
completados y en operación pero con retrasos de implementación, por
encima del presupuesto y/o con menos funcionalidades de las
requeridas inicialmente.
 Proyectos con fracasos (impaired): Aquellos proyectos cancelados en
algún momento durante el ciclo de desarrollo.
Por otro lado, los directores de los proyectos que participaron en el estudio
indicaron que, en su opinión, los tres principales factores de éxito eran:
 Implicación de los usuarios.

 Apoyo de los directivos.
 Enunciado claro de los requisitos.
Mientras que los tres principales factores de fracaso eran:
 Falta de información por parte de los usuarios.

 Especificaciones y requisitos incompletos.
 Especificaciones y requisitos cambiantes.
Estas mismas causas de fracaso son también las identificadas en un informe

similar (el informe ESPITI) realizado en la Unión Europea en 1996. Los
principales problemas que se identificaron fueron:
 Los requisitos no reflejan las necesidades reales del cliente.

 Los requisitos son inconsistentes y/o incompletos.
 Es muy caro realizar cambios de requisitos, luego de haberlos
acordados con el cliente.

Estos informes ponen de manifiesto el hecho de que, a pesar de que las

herramientas para construir software han evolucionado enormemente, se
sigue produciendo software que no es satisfactorio para los clientes y
usuarios. Esto indica que los principales problemas que han dado origen a la
crisis del software residen en las primeras etapas del desarrollo, cuando hay
que decidir las características del producto software a desarrollar; por lo que
no es de extrañar que aquellos proyectos en los que no se determinan
correctamente los requisitos y cambian frecuentemente durante el desarrollo,
superen con creces el tiempo y presupuesto inicial.
1.2. Definición
Existen varias definiciones acerca de la ingeniería de requisitos que nos
proporcionan varios autores según su nivel de experiencia, sentido común o
simplemente por su forma de ver los requisitos respecto al desarrollo de un
determinado proyecto. En esta disciplina principalmente se identifican dos
aspectos muy importantes, el primero que es el propósito del sistema que se
va a desarrollar y el segundo, el contexto en el que será usado. En base a
estas características, se citan algunas definiciones:
Según IEEE6
 Proceso de estudio de las necesidades de los usuarios con el objeto
de llegar a una definición del sistema HW/SW.
Según Pamela Zave

 Rama de la ingeniería del software que trata con el establecimiento
de los objetivos, funciones y restricciones de los sistemas software.
Asimismo, se ocupa de la relación entre estos factores con el objeto
de establecer especificaciones precisas.
Según Barry Boehm

 Ingeniería de Requisitos es la disciplina para desarrollar una
especificación completa, consistente y no ambigua, la cual servirá
como base para acuerdos comunes entre todas las partes
involucradas y en dónde se describen las funciones que realizará el
sistema.
Según Pericles Loucopoulos

 Trabajo sistemático de desarrollo de requisitos, a través de un
proceso iterativo y cooperativo de análisis del problema,
documentando los resultados en una variedad de formatos y
probando la exactitud del conocimiento adquirido.
Según Julio César Sampaio do Prado Leite

 Es el proceso mediante el cual se intercambian diferentes puntos de
vista para recopilar y modelar lo que el sistema va a realizar. Este
proceso utiliza una combinación de métodos, herramientas y actores,
cuyo producto es un modelo del cual se genera un documento de
requisitos.
6
IEEE, Institute of Electrical and Electronics Engineers.

72
1.3. Impacto de la ingeniería de requisitos en los proyectos

Para entender el impacto de la IR en los proyectos de desarrollo veamos
datos interesantes sobre la situación de dichos proyectos obtenidos del
análisis realizado por The Standish Group publicados en The CHAOS Report
desde 1994:
Evolución de los resultados del análisis CHAOS

Report
100%
50%
0%
1994 1996 1998 2000 2002 2004 2006 2009
Failed 31% 40% 28% 23% 15% 18% 19% 24%
Challenged 53% 33% 46% 49% 51% 53% 46% 44%
Successful 16% 27% 26% 28% 34% 29% 35% 32%
Elaboración: La autora Successful Challenged Failed
Figura 8.3. Evolución de los resultados del análisis CHAOS Report
En la figura se observa que a partir del año 2000 existe un incremento

continuo del éxito de los proyectos frente al porcentaje de proyectos
fracasados. Sin embargo, si nos fijamos en los porcentajes del último año, el
44% de proyectos challenged nos indica que seguimos teniendo problemas
para entregar los productos.
Las causas que provocan el fracaso de un proyecto TI son diversas, las

mismas que deben ser gestionadas para minimizar su impacto en los
proyectos. El grupo Standish logró identificar, los 10 componentes más
importantes que hacen exitoso un proyecto y aquellos que llevan al fracaso.
Estos componentes se muestran en la siguiente tabla.
Éxito Fracaso
1 Usuarios involucrados Requisitos incompletos
2 Apoyo ejecutivo No se involucra al usuario
3 Requisitos claros Falta de recursos
4 Planificación adecuada Expectativas no realistas
5 Expectativas realistas Falta de apoyo ejecutivo
6 Hitos de proyectos pequeños Cambios en requisitos y especificaciones
7 Personal competente Falta de planificación
8 Propiedad clara del proyecto Ya no necesitan el sistema
9 Visión y objetivos claros Falta de gestión de TI
10 Equipo de alto rendimiento y bien orientado Incompetencia tecnológica
Tabla 8.1. Componentes de éxito y fracaso de proyectos de software

1.4. Importancia de la Ingeniería de Requisitos

Los principales beneficios que se obtienen de la ingeniería de requisitos 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 capacidad de predecir cronogramas de proyectos, así como
sus resultados: La IR proporciona un punto de partida para controles
subsecuentes y actividades de mantenimiento, tales como estimación
de costos, tiempo y recursos necesarios.
 Disminuye los costos y retrasos del proyecto: Muchos estudios han
demostrado que reparar errores por un mal desarrollo no descubierto a
tiempo, es sumamente caro; especialmente aquellas decisiones
tomadas durante la RE.
 Mejora la calidad del software: La calidad en el software tiene que ver
con cumplir un conjunto de requisitos (funcionalidad, facilidad de uso,
confiabilidad, desempeño, etc.).
 Mejora la comunicación entre equipos: La especificación de requisitos
representa una forma de consenso entre clientes y desarrolladores. Si
este consenso no ocurre, el proyecto no será exitoso.
 Evita rechazos de usuarios finales: La ingeniería de requisitos obliga al
cliente a considerar sus requisitos cuidadosamente y revisarlos dentro
del marco del problema, por lo que se le involucra durante todo el
desarrollo del proyecto.

74
2. EL PROCESO DE INGENIERÍA DE REQUISITOS

La meta del proceso de la IR es crear y mantener un documento de requisitos del
sistema. Según Ian Sommerville, este proceso se puede dividir en cuatro
grandes actividades:
1. Estudio de viabilidad, que corresponde a una evaluación de si el sistema
es útil para el negocio.
2. Obtención y análisis de requisitos, el cual consiste en el descubrimiento
de requisitos.
3. Especificación de requisitos, que conlleva a la documentación de los
requisitos obtenidos.
4. Validación de requisitos, que consiste en comprobar si los requisitos
obtenidos cumplen las necesidades del usuario. La satisfacción de los
usuarios (stakeholders en general) se considera la mejor métrica de la
calidad de un sistema.
La Figura 8.4 ilustra la relación entre estas actividades y los documentos que se
elaboran en cada una de ellas.
Estudio de Obtención y
viabilidad análisis de
requisitos
Especificación
Informe de de requisitos
viabilidad
Validación de
requisitos
Modelos
del sistema
Requisitos
del sistema
Documento
de requisitos
Figura 8.4. Proceso de la Ingeniería de Requisitos
Las actividades que se muestran para este proceso se refieren al descubrimiento,

documentación y validación de requisitos. Sin embargo, en casi todos los
sistemas los requisitos cambian. Las personas involucradas desarrollan una mejor
comprensión de lo que quieren que haga el software; la organización que compra
el sistema cambia; se hacen modificaciones a los sistemas hardware, software y
al entorno organizacional. El proceso de gestionar estos cambios en los requisitos
se denomina “Gestión de Requisitos”, tema que se abordará al final de esta
sección.

2.1. Estudio de viabilidad

Esta actividad debería realizarse si el equipo de desarrollo se enfrenta a un
sistema nuevo. Consiste en rendir un informe tanto al equipo de desarrollo del
proyecto como al usuario o cliente, donde se recomendará si merece o no la
pena seguir con la IR y el proceso de desarrollo del sistema.
Un estudio de viabilidad es un estudio de corto plazo y orientado a resolver

varias cuestiones, tales como:
1. ¿Contribuye el sistema a los objetivos generales de la organización?
2. ¿Se puede implementar el sistema utilizando la tecnología actual y
dentro de las restricciones de coste y tiempo?
3. ¿Puede integrarse el sistema con otros sistemas existentes en la
organización?
La cuestión de si el sistema contribuye a los objetivos del negocio es crítica.
Si no contribuye a estos objetivos, entonces no tiene un valor real en el
negocio.
Llevar a cabo un estudio de viabilidad, que normalmente se lleva a cabo en

dos o tres semanas, comprende la evaluación y recopilación de la
información, y la redacción de informes. La fase de evaluación de la
información identifica la información requerida para contestar las tres
preguntas anteriores. Una vez que dicha información se ha identificado, se
debería hablar con las fuentes de información, como los jefes de los
departamentos donde se utilizará el sistema, los ingenieros de software que
están familiarizados con el tipo de sistema propuesto, los expertos en
tecnología y los usuarios finales del sistema; para descubrir las respuestas a
estas preguntas.
Una vez que se tiene la información, se redacta el informe del estudio de

viabilidad. Al final de este informe, se presenta una recomendación sobre si
debe continuar o no el desarrollo del sistema.
2.2. Obtención y análisis de requisitos

En esta actividad, el desarrollador o su equipo de desarrollo entran en
contacto con el usuario final o con el cliente para determinar el alcance del
proyecto o del sistema que se desea construir, además, se debe identificar
cuáles son los servicios que prestará el sistema, su rendimiento, sus
necesidades y restricciones, y cuáles son los objetivos esperados.
La obtención y análisis de requisitos pueden afectar a varias personas de la

organización. El término stakeholder se utiliza para referirse a cualquier
persona o grupo que se verá afectado por el sistema, directa o
indirectamente. Entre los stakeholders se encuentran los usuarios finales que
interactúan con el sistema, los ingenieros que desarrollan o dan
mantenimiento a otros sistemas relacionados, los gerentes del negocio, los
expertos en el dominio del sistema y todos aquellos que puedan verse
afectados por su instalación.
Obtener y comprender los requisitos de los stakeholders es difícil por varias

razones:

76
1. Los stakeholders a menudo no conocen lo que desean obtener del

sistema excepto en términos muy generales; puede resultarles difícil
expresar lo que quieren que haga el sistema o pueden hacer
demandas irreales debido a que no conocen el coste de sus
solicitudes.
2. Los stakeholders expresan los requisitos con sus propios términos de
forma natural y con un conocimiento implícito de su propio trabajo. Los
ingenieros de requisitos, sin experiencia en el dominio del cliente,
deben comprender estos requisitos.
3. Diferentes stakeholders tienen requisitos distintos, que pueden
expresar de varias formas. Los ingenieros de requisitos tienen que
considerar todas las fuentes potenciales de requisitos y descubrir las
concordancias y los conflictos.
4. Los factores políticos pueden influir en los requisitos del sistema. Por
ejemplo, los directivos pueden solicitar requisitos específicos del
sistema que incrementarán su influencia en la organización.
5. El entorno económico y de negocios en el que se lleva a cabo el
análisis es dinámico. Inevitablemente, cambia durante el proceso de
análisis. Por lo tanto, la importancia de ciertos requisitos puede
cambiar. Pueden emerger nuevos requisitos de nuevos stakeholders
que no habían sido consultados previamente.
Estas razones ponen de manifiesto que es imposible satisfacer

completamente a todos los stakeholders. Es labor del ingeniero de requisitos,
durante el proceso, organizar frecuentes negociaciones con ellos para que se
puedan llegar a acuerdos. De lo contrario, si algún stakeholder piensa que
sus opiniones no se han considerado adecuadamente, deliberadamente
puede intentar socavar el proceso de IR.
A continuación se presenta una “plantilla de requisitos” o “tarjeta de

requisitos” (inspirada en el libro de S. Robertson y J. Robertson “Mastering
the Requirements Process”, Addison-Wesley, 1999) que puede ser útil en
proyectos reales. Varias de estas tarjetas, se pueden utilizar para recoger
información relevante durante las primeras fases del proceso.
Figura 8.5. Tarjeta de Requisitos

La explicación de cada sección es la siguiente:
 Requisito #: Número que identifica a cada requisito

 Clasificación: En qué apartado del documento de requisitos debería
figurar. En otras palabras, a qué parte del sistema afecta. Por
ejemplo: pedidos, contabilidad, ventas, etc.
 Tipo: Funcional, no funcional
 Descripción: Una frase que describe el requisito, tipo “feature”.
 Razón: ¿Por qué es importante este requisito?
 Origen: ¿quién lo pide?
 Prioridad: Importancia del requisito. Puede valorarse de 0 a 3, por
ejemplo.
 Dependencias: Otros requisitos de los que depende
 Conflictos: Requisitos que, de alguna forma, contradicen a éste
 Referencias: Especificar qué otros documentos son necesarios para
comprender el requisito.
 Historia: Historia de los cambios al requisito.
2.3. Especificación de requisitos

En esta etapa se debe obtener un documento de especificación de
requisitos (ERS, Especificación de Requisitos del Software), en el cual se
llega a definir de una forma completa, precisa y verificable cada uno de los
requisitos o necesidades que debe satisfacer el sistema a desarrollar,
además de sus respectivas restricciones (software, hardware).
La diversidad de personas que forman parte de un proyecto software hace

que sea necesario establecer un marco de terminología común. Por esta
razón son muchas las propuestas que abogan por desarrollar un glosario de
términos en el que se recogen y definen los conceptos más relevantes y
críticos para el sistema.
2.4. Validación de requisitos

Consiste en mostrar o comprobar que cada uno de los requisitos obtenidos
define el sistema o proyecto que se va a construir y que desea el cliente. En
esta etapa solamente entran aquellos requisitos que se mencionaron ya en la
especificación.
Pueden utilizarse, en conjunto o de forma individual, varias técnicas de

validación de requisitos:
1. Revisiones de requisitos. Los requisitos son analizados
sistemáticamente por un equipo de revisores.
2. Construcción de prototipos. En este enfoque de validación, se muestra

un modelo ejecutable del sistema a los usuarios finales y a los
clientes. Éstos pueden experimentar con este modelo para ver si
cumple sus necesidades reales.

78
3. Generación de casos de prueba. Los requisitos deben poder probarse.

Si las pruebas para éstos se conciben como parte del proceso de
validación, a menudo revela los problemas en los requisitos. Si una
prueba es difícil o imposible de diseñar, normalmente significa que los
requisitos serán difíciles de implementar y deberían ser considerados
nuevamente. Desarrollar pruebas para los requisitos del usuario antes
de que se escriba código es una parte fundamental de la
programación extrema.
4. Matrices de trazabilidad. Esta técnica consiste en marcar los objetivos

del sistema y chequearlos contra los requisitos del mismo. Es
necesario ir viendo qué objetivos cubre cada requisito, de esta forma
se podrán detectar inconsistencias u objetivos no cubiertos.
En definitiva, la validación de requisitos realmente significa asegurarse de

que el documento de requisitos represente una descripción clara del sistema,
y es una verificación final de que los requisitos cubren las necesidades de los
usuarios.
La diferencia con el análisis es clara, pues mientras que en el análisis se

trabaja sobre el boceto del documento de requisitos, en la validación se utiliza
el documento final, lo que equivale a decir, los requisitos "depurados".
2.5. Gestión de Requisitos

Los requisitos cambian y esto persiste a lo largo de la vida del sistema. Los
cambios ocurren por:
 Cambios tecnológicos
 Cambios en las estrategias o prioridades del negocio
 Modificaciones en leyes y/o regulaciones
 Porque al analizar el problema, no se hacen las preguntas correctas a
las personas correctas
 Porque cambió el problema que se estaba resolviendo
 Porque los usuarios cambiaron su forma de pensar o sus percepciones
 Porque cambió el ambiente de negocios
 Porque cambió el mercado en el cual se desenvuelve el negocio
Los cambios deben controlarse y documentarse. Hay que convivir con el

cambio. Por lo tanto, es esencial planear posibles cambios a los requisitos
cuando el sistema sea desarrollado y utilizado y este proceso se hace
indispensable, más aún, cuando se trata de sistemas software grandes.
La gestión de requisitos es el conjunto de actividades que ayudan al equipo

de trabajo a identificar, controlar y seguir los requisitos y sus cambios en
cualquier momento. Básicamente, consiste en planificar la gestión de
requisitos y gestionar sus cambios. De este modo, se asegura la
consistencia entre los requisitos y el sistema construido (o en construcción) y
claro está que consume grandes cantidades de tiempo y esfuerzo abarcando
todo el ciclo de vida del producto.

2.5.1. Planificación de la gestión de requisitos

Esta primera etapa es esencial en el proceso de gestión de requisitos,
pues como se mencionó anteriormente, la gestión de requisitos tiene
un coste elevado. Para cada proyecto, la etapa de planificación
establece el nivel de detalle necesario en la gestión de requisitos.
Durante la etapa de gestión de requisitos, habrá que decidir sobre:

 La identificación de requisitos
 Un proceso de gestión del cambio
 Políticas de rastreo o trazabilidad: Definen la relación entre
requisitos y la de éstos y el diseño del sistema.
Información de rastreo de la fuente: Identificación de quién
propone el cambio y la razón
Información de rastreo de los requisitos: Vincula los requisitos

dependientes en el RAD. Es necesario para comprobar cómo se
ven afectados otros requisitos por el cambio propuesto y la
magnitud de este impacto.
Información de rastreo del diseño: Vincula los requisitos a los

componentes de diseño (clases, métodos, módulos,...) en que
serán implementados. Necesario para evaluar cómo se ve
afectado el diseño y la implementación por el cambio propuesto.
 Ayuda de herramientas CASE
2.5.2. Gestión del cambio de los requisitos

La gestión del cambio se debe aplicar a todos los cambios
propuestos. La ventaja de ello es que se asegura que todos los
cambios propuestos son tratados de forma consistente y todos los
cambios en el documento de requisitos se hacen de forma controlada.
Problema
identificado
Análisis del problema y
especificación del cambio
Análisis del problema y

cálculo de costes
Implementación
del cambio
Requisito
revisado
Figura 8.6. Gestión de cambios en los requisitos

80
1. Indique cuáles son los factores que causan problemas a los proyectos de software
(Project challenged) según el reporte CHAOS del grupo Standish.
2. Investigue otras estrategias no convencionales para gestión de requisitos, y

comente brevemente los aspectos más significativos de cada una de ellas. Por
ejemplo, a continuación se citan algunas de ellas:
a) El enfoque orientado a objetivos

b) El enfoque basado en puntos de vista
c) El enfoque orientado a aspectos.

Resumen
 La ingeniería de requisitos nace como respuesta a la crisis del software, debido a

que de todos los problemas que se presentan en los proyectos de software
indudablemente el principal motivo para esos costos y tiempos elevados es la falta
de un adecuado manejo o gestión de requisitos.
 El proceso de ingeniería de requisitos incluye un estudio de viabilidad, así como la

obtención, análisis, especificación, validación y gestión de requisitos.
 Los cambios en los negocios, organizacionales y técnicos inevitablemente

conducen a cambios en los requisitos de un sistema software. La gestión de
requisitos es el proceso de gestionar y controlar estos cambios.
 El proceso de gestión de requisitos incluye la gestión de la planificación, en la cual

se diseñan las políticas y procedimientos para la gestión de requisitos; y del
cambio, en la que se analiza los cambios propuestos en los requisitos y se evalúa
su impacto.
 Si desea saber más acerca de estos temas, puede consultar los siguientes libros.
 “FÁBRICAS DE SOFTWARE: EXPERIENCIAS, TECNOLOGÍAS Y ORGANI-

ZACIÓN” de Mario Piattini y Javier Garzás, 1ª edición.
El capítulo 6 trata la gestión de requisitos desde varios enfoques, aparte de la
convencional.
 “INGENIERÍA DEL SOFTWARE” de Ian Sommerville, 7ª edición.

El capítulo 7 trata el proceso de la ingeniería de requisitos.
 Además, puede consultar las siguientes páginas.
 http://www.csus.edu/indiv/v/velianitis/161/ChaosReport.pdf
Aquí se expone los resultados del reporte CHAOS de 1994.
 http://www.materiabiz.com/mbz/ityoperaciones/nota.vsp?nid=29672
Aquí encontrará el artículo “El 71 por ciento de los proyectos de sistemas
fracasan. ¿Por qué?”. Escrito por Silvio Szostak, Profesor del Programa de
Negocios y Tecnología de la Universidad Torcuato Di Tella, Buenos Aires.
Este artículo describe los resultados del reporte CHAOS del 2004.
 http://www.standishgroup.com/newsroom/chaos_2009.php
En este link el grupo Standish expone un resumen del reporte CHAOS 2009.

82

UNIDAD DE
APRENDIZAJE
2
TEMA
PIRÁMIDE DE REQUISITOS

cambios haciendo uso de la herramienta CARE IBM Rational Requisite PRO.
TEMARIO
1. Pirámide de requisitos
2. Características de un buen requisito
3. Documentos de requisitos
1. Los alumnos clasifican los requisitos de una lista propuesta según las categorías
descritas en la pirámide de requisitos.

84
1. PIRÁMIDE DE REQUISITOS
Un requisito se define como una condición o capacidad a la que debe ajustarse el
sistema que se construye para satisfacer un contrato, norma, especificación u otro
documento formalmente impuesto.
Dependiendo del formato, fuente y características comunes, los requisitos pueden

dividirse en diferentes tipos. A continuación se indican algunos tipos de
requisitos que a menudo son usados en proyectos:
 Necesidades del stakeholder.

 Características
 Casos de uso
 Requisitos suplementarios
 Casos de prueba
 Escenarios
Estos tipos de requisitos pueden ser presentados en la forma de una pirámide, tal
como se muestra en la Figura 9.1.
Figura 9.1. Pirámide de Requisitos
En el nivel superior están las necesidades de stakeholders. En los niveles

inferiores están las características, casos de uso y requisitos suplementarios. Los
diferentes niveles marcan el nivel de detalle, pues cuanto menor sea el nivel, la
exigencia de detalle de un requisito será mayor. Por ejemplo, una necesidad de
stakeholder podría ser: "Los datos deben ser persistentes." La característica
puede refinar este requisito así: "El sistema debe utilizar una base de datos
relacional." Y, en el nivel de la especificación suplementaria, el requisito es aún
más específico: "El sistema debe usar el motor de base de datos Oracle 9i."
Esto pone de manifiesto que cuanto más se avance en el nivel inferior de la

pirámide, más detallado será el requisito. Una de las mejores prácticas de gestión
de requisitos es tener por lo menos dos niveles de abstracción de requisitos.

1.1. Necesidad del stakeholder

Describe lo que el sistema debería hacer para mejorar o reducir el costo de
un proceso de negocio, incrementar ganancias o alcanzar regulaciones y
otras obligaciones. Proporcionado por un stakeholder.
Ejemplo:
ID Necesidad Stakeholder
“Necesito notificar al jefe de soporte
STRQ1 cuando una solicitud de soporte es Técnico
iniciada”
“Necesito asignar solicitudes de soporte Jefe de
STRQ2
a un ingeniero de soporte específico” soporte
“Necesito mantener informado al cliente Gerente
STRQ3
del progreso de una solicitud de soporte” general
Tabla 9.1. Ejemplo de Necesidades de stakeholders
1.2. Característica del sistema

Es un servicio que el sistema provee para satisfacer una o más necesidades
del afectado. Formulada por el analista del negocio. Están descritas en el
documento Visión. Estos son algunos ejemplos:
ID Característica Descripción
El sistema funcionará La solicitud de soporte pasará
FEAT1 orientado al trabajo en por una serie de etapas y
flujo asignaciones
Un sistema de notificación de
Capacidad de notificación
FEAT2 correo centralizado será
por e-mail
utilizado por el flujo de trabajo
Tabla 9.2. Ejemplo de Características del sistema
1.3. Caso de uso

Es la descripción del comportamiento del sistema en términos de secuencia
de acciones. También es un formato en el que los stakeholders expresan sus
necesidades. El formato de un caso de uso creado por un stakeholder es el
mismo que eventualmente es utilizado por un analista. Sin embargo, el
analista debe revisar el caso de uso proporcionado por el usuario.
El propósito de un caso de uso es facilitar los acuerdos entre los

desarrolladores, clientes y usuarios acerca de lo que el sistema debe hacer.
También es la base para las realizaciones de casos de uso, las cuales
juegan un papel importante en la disciplina del análisis y diseño.
Los casos de uso son un buen camino para expresar requisitos funcionales
del sistema, es por ello que son utilizados para representar el
comportamiento del sistema mediante un diagrama conocido como Diagrama
de casos de uso, en el cual contiene actores (roles de usuarios), casos de
uso y las relaciones entre ellos.
A continuación se muestra algunos ejemplos de casos de uso para un

sistema de control de reservaciones y hospedaje de un hotel:

86
ID Caso de Uso Descripción

Este caso de uso permite
registrar la reserva de uno o
UC1 Generar reserva de habitaciones
más habitaciones disponibles
para un cliente que lo solicita.
El caso de uso permite
consultar la disponibilidad de
Consultar disponibilidad de
UC2 una habitación por algún
habitaciones
criterio de búsqueda: categoría,
tipo y/o rango de precios.
El caso de uso permite realizar
la búsqueda de un cliente por
UC3 Buscar clientes algún criterio de búsqueda:
nombres, apellido paterno y/o
apellido materno.
El caso de uso permite
mantener actualizado el
registro de los clientes del
UC4 Mantener clientes hotel. De acuerdo a su
necesidad el recepcionista
puede agregar, actualizar y
desactivar un cliente.
Tabla 9.3. Ejemplo de Casos de uso del sistema
1.4. Requisito suplementario

También conocido como requisito de arquitectura o factores de calidad en el
contexto de desarrollo de software. Son todos los requisitos que no pueden
ser expresados con casos de uso.
Para capturar requisitos suplementarios se debe usar el enfoque sugerido por

Peter Eeles7:
 Crear una lista de categorías de los requisitos suplementarios (según

FURPS + por ejemplo).
 Crear preguntas para cada categoría.
 Explicar al cliente el impacto y costo de cada decisión.
 Capturar la respuesta del cliente a cada pregunta.
 Asignar prioridad y peso a cada requisito.
Por otro lado, también se obtienen estos tipos de requisitos a partir de las
características (features) identificados en un nivel anterior de la pirámide de
requisitos. Se han hecho muchos intentos para clasificar los requisitos
suplementarios. Una de las primeras clasificaciones fue publicada por McCall
y Matsumoto, en 1980 y se muestra en la Tabla 9.4.
7
Arquitecto Ejecutivo de TI, trabajando en IBM Rational Software.

Categoría Sub categoría

Integridad
Corrección
Operación Confiabilidad
Facilidad de uso
Eficiencia
Mantenibilidad
Revisión Comprobabilidad
Flexibilidad
Portabilidad
Transición Interoperabilidad
Reusabilidad
Tabla 9.4. Clasificación propuesta por McCall and Matsumoto
La ISO - Organización Internacional para la Normalización utiliza la siguiente

clasificación, dado a conocer en 1991.

Precisión
Seguridad
Funcionalidad Interoperabilidad
Idoneidad
Conformidad
Madurez
Confiabilidad Tolerancia a fallos
Recuperación
Facilidad de uso Facilidad de uso
Eficiencia Eficiencia
Comprobabilidad
Mutabilidad
Mantenibilidad
Fácil de analizar
Estabilidad
Adaptabilidad
Portabilidad Conformidad
De fácil reemplazo
Tabla 9.5. Clasificación utilizada por ISO
El curso sigue la clasificación propuesta por Robert Grady, en 1992, y

adaptado por Rational Software. Esta clasificación es llamada FURPS+,
acrónimo en inglés que significa Funcionalidad, facilidad de uso,
Confiabilidad, Rendimiento y de Soporte. El + incluye diferentes tipos de
restricciones como de Diseño, de implementación, Físicos e Interfaces. La
plantilla de la especificación de requisitos de software encontrada en RUP
también contiene las siguientes secciones:
 Documentación de usuario en línea y sistema de ayuda

 Componentes adquiridos
 Licenciamiento
 Requisitos legales, copyright y otros
 Estándares aplicables.

88
Estas categorías se muestran en la siguiente tabla. Se consideran los

requisitos FURPS, dos categorías cubiertos por + y dos categorías de la
plantilla de RUP.

Funcionalidad
Accesibilidad
Estética
Consistencia de Interfaz de
Facilidad de uso
usuario
Ergonomía
Fácil de usar
Disponibilidad
Robustez
Precisión
Recuperación
Confiabilidad
Tolerancia a fallos
Seguro
Seguridad
Corrección
Rendimiento
Tiempo de respuesta
Tiempo de recuperación
Rendimiento
Tiempo de Inicio/Apagado
Capacidad
Utilización de recursos
Comprobabilidad
Adaptabilidad
Mantenibilidad
Configurabilidad
Actualización
Fácil de instalar
Escalabilidad
Rendimiento Portabilidad
Reutilización
Interoperabilidad
Conformidad
Fácil de reemplazar
Mutabilidad
Fácil de analizar
Fácil de localizar
Restricciones de
diseño
Requisitos de
Interfaz
Documentación de
usuario en línea y
sistema de ayuda
Requisitos legales,
copyright y otros
Tabla 9.6. Clasificación de Requisitos Suplementarios

1.5. Caso de prueba

Consiste en una especificación de entradas de pruebas, ejecución de
condiciones y resultados esperados.
Los casos de prueba son creados para determinar si el requisito de un

sistema, funcional o no funcional, es parcial o completamente satisfactorio.
Algunos casos de prueba los puede crear el desarrollador, otros los testers y
otros los clientes o usuarios.
Los casos de prueba que se crean pueden ser utilizados para las pruebas
manuales, así como para pruebas automatizadas utilizando herramientas,
tales como IBM Rational Robot e IBM Rational Functional Tester.
1.6. Escenario
Un escenario es una instancia de un caso de uso. Es una secuencia
específica de acciones obtenidas del flujo de eventos de un caso de uso. Por
ejemplo, a continuación se muestra los posibles escenarios de un caso de
uso que tiene cuatro flujos alternativos A1, A2, A3 y A4. Para encontrar un
escenario, se necesita dibujar las posibles líneas que siguen un camino
desde el flujo básico B.
Figura 9.2. Escenarios de un caso de uso.

90
2. CARACTERÍSTICAS DE UN BUEN REQUISITO

Un requisito debe cumplir varios criterios para ser considerado un "buen
requisito". Las características que presentan los requisitos son:
 No ambiguo  Factible
 Verificable  Independiente
 Claro  Atómico
 Correcto  Necesario
 Comprensible  Abstracto
Además de estos criterios para los requisitos individuales, tres criterios se aplican
al conjunto de requisitos. El conjunto debe ser:
 Consistente
 No redundante
 Completo
2.1. No ambiguo
Un requisito no es ambiguo cuando tiene una sola interpretación. El lenguaje
usado en su definición, no debe causar confusiones al lector. A veces la
ambigüedad se introduce por utilizar acrónimos:
REQ1: El sistema será implementado utilizando ASP.
En este ejemplo ¿ASP se refiere a Active Server Pages o Application

Service Provider? Para solucionar este problema, es mejor indicar el
nombre completo y especificar el acrónimo entre paréntesis:
REQ1: El sistema será implementado utilizando Active Server Pages (ASP).
A continuación otro ejemplo:
REQ2: El sistema no aceptará contraseñas con más de 15 caracteres.
No está claro lo que el sistema se supone debe hacer:
 ¿El sistema no permitirá al usuario ingresar más de 15 caracteres?

 ¿El sistema truncará la cadena ingresada a 15 caracteres?
 ¿El sistema mostrará un mensaje de error si el usuario ingresa más
de 15 caracteres?
El enunciado correcto para este requisito debe ser así:
REQ2: El sistema no aceptará las contraseñas de más de 15 caracteres. Si el

usuario ingresa más de 15 caracteres, al digitar su contraseña, un mensaje de
error le pedirá al usuario que debe corregirlo.
Una cierta ambigüedad puede ocurrir a través de la colocación de una

palabra:
REQ3: En la pantalla "Vuelos ", el usuario sólo puede ver un registro.

¿Esto significa que el usuario puede "ver solamente" y no eliminar o

actualizar, o significa que el usuario puede “ver sólo un registro”, no dos o
tres?
Una forma de solucionar el problema es volver a escribir el requisito desde el

punto de vista del sistema:
REQ3: En la pantalla "Vuelos ", el sistema mostrará un solo vuelo.
2.2. Verificable
Un requisito es verificable cuando puede ser cuantificado de manera que
permita hacer uso de los siguientes métodos de verificación: inspección,
análisis, demostración o pruebas.
Para que un requisito sea verificable, éste debe ser claro, preciso y no
ambiguo. Algunas de estas palabras pueden hacer que un requisito no sea
verificable:
 Algunos adjetivos: robusto, seguro, preciso, eficaz, eficiente, ampliable,

flexible, fácil de mantener, confiable, amigable, adecuada
 Algunos adverbios y frases adverbiales: rápido, seguro, de manera
oportuna
 Palabras o acrónimos no específicos: etc., y/o, TBD
 Pronombres indefinidos: algunos, muchos, más, mucho, varios,
cualquier, cualquiera, cualquier cosa, algunos, alguien, etc
 Algunos verbos en infinitivo: gestionar, controlar
 Voz pasiva: el sujeto de la oración recibe la acción del verbo en lugar de
su realización
El requisito que se enuncia a continuación presenta un pronombre indefinido:
REQ1: El sistema deberá resistir el uso concurrente por muchos usuarios.
La pregunta es, ¿qué número debe ser considerado "muchos" -10, 100,
1000?
Una mejor alternativa de enunciarlo es:
REQ1: El sistema deberá resistir el uso concurrente de a lo más 500 usuarios.
2.3. Claro
Un requisito es claro si es fácil de leer y entender. Su redacción debe ser
simple y clara para aquellos que vayan a consultarlo en un futuro. Por
ejemplo esta es una frase compleja para un requisito:
REQ1 A veces el usuario introducirá Código del aeropuerto, que el sistema

comprenderá, pero a veces será sustituida por el nombre de la ciudad más
cercana, por lo que el usuario no necesita saber cuál es el código del
aeropuerto, y seguirá siendo entendido por el sistema.
Esta frase puede ser sustituida por una más sencilla:

92
REQ1 El sistema deberá identificar el aeropuerto ya sea sobre la base de un

Código de Aeropuerto o de un Nombre de Ciudad.
2.4. Correcto
Si un requisito contiene hechos, éstos deben ser ciertos. Por ejemplo, este
requisito no está escrito correctamente:
REQ1 El sistema deberá aplicar descuentos en las planillas de los

trabajadores (incluyendo el 18% de los aportes del sistema de pensiones).
El porcentaje de aportación depende de la entidad administradora de fondos

de pensiones, por lo que la cifra indicada del 18% es incorrecta.
2.5. Comprensible
Los requisitos deberían ser gramaticalmente correctos y escritos en un estilo
consistente. Un estándar de convenciones debe ser utilizada. Tal es así que
la palabra "deberá" se debe utilizar en lugar de "podrá", "debe", o "puede".
2.6. Factible
El requisito debería ser factible dentro de las limitaciones existentes, tales
como tiempo, dinero y recursos disponibles:
REQ1: El sistema tendrá una interfaz de lenguaje natural que comprenderá

comandos dados en el idioma Inglés.
Este requisito puede no ser factible en un corto lapso de tiempo de

desarrollo.
2.7. Independiente
Para entender el requisito, no debería haber necesidad de conocer a ningún
otro requisito:
REQ1: La lista de vuelos disponibles incluirá los números de vuelo, hora de

salida y tiempo de llegada para cada vuelo.
REQ2: Esta debería ser ordenado por precio.
La palabra "Esta" en la segunda frase se refiere al requisito anterior. Sin

embargo, si se cambia el orden de los requisitos, este requisito no será
comprensible. Lo correcto es especificar la lista que debe ser ordenada, así:
REQ2: La lista de vuelos disponibles deberá ser ordenado por precio.
2.8. Atómico
El requisito debe contener un elemento de trazabilidad individual. Por
ejemplo:

REQ1: El sistema deberá proporcionar la posibilidad de reservar el vuelo,

comprar un ticket, reservar una habitación de hotel, reservar un auto, y
proporcionar información sobre lugares de interés.
Este requisito se compone de cinco requisitos atómicos, lo que hace muy

difícil la trazabilidad. Lo correcto sería:
REQ1: El sistema deberá proporcionar la posibilidad de reservar el vuelo.
REQ2: El sistema deberá permitir comprar un ticket.
REQ3: El sistema deberá proporcionar la opción de reservar una habitación

de hotel
REQ4: El sistema deberá permitir reservar un auto
REQ5: El sistema deberá proporcionar información sobre lugares de interés.
Oraciones que incluyen las palabras "y" o "pero" debería revisarse para ver si
se puede romper en varios requisitos atómicos.
2.9. Necesario
Un requisito 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.
Por ejemplo el siguiente requisito debe ser removido porque no proporciona

ninguna información adicional de lo que el sistema debe hacer:
REQ1: Todos los requisitos especificados en el documento Visión deberían

ser implementados y probados.
2.10. Abstracto
Los requisitos no deben contener información innecesaria de diseño e
implementación:
REQ1: La información del sistema deberá ser almacenada en un archivo de

texto.
En el ejemplo, cómo se almacena la información es transparente para el

usuario y debe ser decisión del diseñador o del arquitecto.
2.11. Consistente
Un requisito es consistente si no es contradictorio con otro requisito.
Por ejemplo puede darse el caso en que dos requisitos utilicen términos
diferentes para un mismo concepto:
REQ1: El sistema deberá permitir reservar una habitación.

94
REQ2: El sistema deberá permitir registrar el hospedaje a partir de una

separación de habitación registrada.
Para evitar esta situación conviene estandarizar términos. Entonces, los

requisitos anteriores se escriben mejor así:
REQ1: El sistema deberá permitir reservar una habitación.
REQ2: El sistema deberá permitir registrar el hospedaje a partir de una

reserva de habitación registrada.
Los enunciados siguientes muestran conflictos que pueden resolverse

mediante el análisis de las condiciones en las que el requisito se lleva a
cabo:
REQ3: Las fechas deberán ser mostradas en el formato mm/dd/aaaa.
REQ4: Las fechas deberán ser mostradas en el formato dd/mm/aaaa.
Aquí, si el REQ1 fue presentado por un usuario americano y el REQ2 por un

usuario francés, los requisitos anteriores podrán ser escritos así:
REQ3: Para los usuarios en los EE.UU., las fechas se muestran en el formato
mm/dd/aaaa.
REQ4: Para los usuarios en Francia, las fechas se muestran en el formato

dd/mm/aaaa.
2.12. No redundante
Cada requisito debe ser expresado una sola vez y no debe solaparse con
otro requisito:
REQ1: Un calendario estará disponible para ayudar a la entrada de la fecha

de vuelo.
REQ2: El sistema deberá mostrar un calendario pop-up para ingresar

cualquier fecha.
En estos ejemplos es fácil darse cuenta que el primer requisito (en relación
con la fecha, sólo del vuelo) es un subconjunto del segundo (en relación con
cualquier fecha introducida por el usuario).
2.13. Completo
Un requisito está completo si no necesita ampliar detalles en su redacción,
es decir, si se proporciona la información suficiente para su comprensión sin
necesidad de agregar otro requisito para su entendimiento.

3. DOCUMENTOS DE REQUISITOS
Los siguientes tipos de documento se utilizan comúnmente en la gestión de
requisitos:
 Plan de Gestión de Requisitos. Este documento establece los lineamientos

para el establecimiento de los documentos de requisitos, tipos, características,
y la trazabilidad con el fin de gestionar los requisitos del proyecto.
 Solicitudes de los stakeholders. En este documento se especifican las

necesidades de los stakeholders.
 Visión. Este documento da la visión total del sistema: principales

características, necesidades de los stakeholders y servicios esenciales
proporcionados.
 Glosario. Es importante que todos los stakeholders utilicen términos

consistentes para expresar sus necesidades. El glosario es una herramienta
para capturar y definir los términos utilizados en el proyecto.
 Especificación de casos de uso. Las especificaciones de casos de uso sirven

como un formato para expresar el flujo de eventos de los requisitos
funcionales. Un caso de uso es una secuencia de acciones llevadas a cabo por
un sistema que produce un resultado observable (una salida de trabajo) de
valor a un actor en particular.
 Especificación de requisitos suplementarios. Este documento captura los

requisitos que no puede vincularse directamente a cualquier caso de uso
específico, y sobre todo si se trata de los requisitos no funcionales y
restricciones de diseño.
 Especificación de requisitos de software. Este documento captura todos los

requisitos del sistema software, es decir, contiene la lista de los requisitos
funcionales y no funcionales.
 Plan de pruebas. Este documento describe el objetivo de las pruebas

(componentes, aplicaciones, sistemas), las etapas de la prueba, y los
tipos de pruebas que serán abordados por este plan. Es recomendable
realizar las pruebas de forma automática, por ejemplo utilizando IBM
Rational TestManager.

96
De acuerdo a la pirámide de requisitos, a qué tipo de requisito corresponde cada uno
de los siguientes enunciados:
NOTA: Utilice STRQ, FEAT, UC o SUPL para indicar si se trata de una necesidad de
stakeholder, característica del sistema, caso de uso o requisito suplementario
respectivamente.
R01. El sistema deberá garantizar que su despliegue se pueda realizar, ya sea en el

lado del servidor o del cliente, sobre plataforma hardware de 32 bits o de 64 bits
sin que esto afecte el rendimiento del mismo.
R02. El sistema deberá contar con un Manual Técnico de Referencia para la

Aplicación, el cual estará orientado a profesionales capacitados en aspectos
técnicos del área de sistemas.
R03. La clave de los usuarios considerará las siguientes políticas:

- Expirar según parametrización del sistema
- Tener mínimo una longitud de 8 caracteres
- Contener letras y números
- No puede contener espacios
- No pueden repetirse las 3 últimas contraseñas
- No contendrá el nombre o apellido de la persona dueña del usuario
R04. El código fuente del sistema deberá cumplir con el estándar de codificación
definido en el documento “Estándares y Nomenclaturas de Código Fuente”.
R05. El sistema utilizará el idioma castellano para los mensajes y textos en la

pantalla.
R06. El sistema será utilizado por clientes de todo el mundo. Adicionalmente, la

Organización Pro-Turismo exige que para anunciar servicios en su portal, éstos
deben estar provistos en español, inglés y portugués. Estos tres idiomas deben
ser soportados por el producto desarrollado.
R07. El sistema deberá permitir la creación, modificación, activación, desactivación y

autorización de los roles de usuarios definidos.
R08. El sistema deberá prever contingencias que pueden afectar la prestación

estable y permanente del servicio.
La siguiente es la lista de las contingencias que se deben tener en cuenta y se
pueden considerar críticas:
 Sobrecarga del sistema por volumen de usuarios.
 Caída del sistema por sobrecarga de procesos.
 Caída del sistema por sobrecarga de transacciones.
 Caída del sistema por volumen de datos excedido en la base de datos.
R09. El sistema deberá contar con el manual de FAQ (Frequent Asked Questions),
en línea e impreso, que es un resumen con las respuestas a las preguntas más
frecuentes que se hacen los usuarios.
R10. El sistema deberá utilizar una base de datos relacional.

Resumen
 La pirámide de requisitos muestra una jerarquía de requisitos de acuerdo al nivel

de detalle en que se expresan. En los niveles inferiores de la pirámide se
encuentran los requisitos con mayor nivel de detalle.
 Los requisitos suplementarios son todos los requisitos que no pueden ser
expresados con casos de uso.
 Un requisito debe presentar las siguientes características para ser considerado un

"buen requisito":
1. No ambiguo 6. Factible
2. Verificable 7. Independiente
3. Claro 8. Atómico
4. Correcto 9. Necesario
5. Comprensible 10. Abstracto
Además de estos criterios para los requisitos individuales, tres criterios se aplican
para un conjunto de requisitos:
1. Consistente
2. No redundante
3. Completo
 Los documentos que se utilizan comúnmente en la gestión de requisitos son:
1. Plan de gestión de requisitos

2. Solicitudes de stakeholders
3. Visión
4. Glosario de términos
5. Especificación de caso de uso
6. Especificación de requisitos suplementarios
7. Especificación de requisitos del software
8. Pan de pruebas

98
 “REQUIREMENTS MANAGEMENT USING IBM RATIONAL REQUISITE PRO”

de Peter Zielczynski.
El primer capítulo trata la gestión de requisitos, el cual empieza con la
descripción de la pirámide de requisitos y características de un buen requisito y
termina con una descripción breve del proceso de gestión de requisitos.
 http://www.ibm.com/developerworks/rational/library/04/r-3217/index.html
Este artículo ilustra un método formal de derivación de casos de prueba
funcional de casos de uso, incluyendo cómo crear un caso de uso, derivar todos
los escenarios, y crear casos de prueba razonable, así como el uso de IBM
Rational Requisite Pro para la trazabilidad de los casos de uso con escenarios y
casos de prueba.

UNIDAD DE
APRENDIZAJE
2
TEMA
10
GESTIÓN DE REQUISITOS EN RUP

TEMARIO
1. Visión General de la Gestión de Requisitos en RUP.
1. Los alumnos, a partir de una lista de necesidades de stakeholders para una

agencia de viajes, crean las características del sistema (FEATURES) indicando
las estrategias de transformación utilizadas.
2. Los alumnos, a partir de una especificación de caso de uso crea los casos de
prueba.

100
1. VISIÓN GENERAL DE LA GESTIÓN DE REQUISITOS EN RUP

En RUP, una descripción simplificada del proceso de gestión de requisitos
contiene los siguientes pasos:
 Establecimiento de un plan de gestión de requisitos
 Captura de requisitos
 Desarrollo del documento Visión
 Creación de casos de uso
 Especificación suplementaria
 Creación de casos de prueba de casos de uso
 Creación de casos de prueba de la especificación suplementaria
 Diseño del sistema.
El primer paso, plan de gestión de los requisitos, define los requisitos de la

pirámide. En cada uno de los siguientes siete pasos, uno de los elementos de la
pirámide es construido.
En la tabla 10.1 se describe que tipos de requisitos y qué documentos se crean en

cada paso. Como puede apreciar, el proceso, a partir del segundo paso, navega a
través de la pirámide de arriba hacia abajo y de izquierda a derecha.
Paso Tipo de requisito Documentos
Establecimiento de un plan Plan de gestión de

-
de gestión de requisitos requisitos
Necesidades de Solicitudes de
Captura de requisitos
stakeholders stakeholders
Desarrollo del documento

Características Visión, Glosario
Visión
Casos de uso, Especificación de

Creación de casos de uso
escenarios caso de uso
Especificación Requisitos Especificación

suplementaria suplementarios suplementaria
Creación de casos de Plan de casos de

Casos de prueba
prueba de casos de uso prueba
Creación de casos de
Plan de casos de
prueba de la especificación Casos de prueba
prueba
suplementaria
Diagrama de
Diseño del sistema clases, diagramas Diagramas UML
de interacción
Tabla 10.1. Requisitos y documentos creados en el proceso de gestión de
requisitos según RUP

La gestión de requisitos es un proceso iterativo. En una iteración típica, se pasa

por todos los niveles de la pirámide. Incluso en la misma iteración, podemos
retornar a algunos pasos y repetir la actividad. Por ejemplo, durante la creación de
un caso de prueba, podemos descubrir que en algunos falta información, y
necesitamos más aportaciones de los stakeholders, por lo tanto retrocedemos un
paso para "la captura de requisitos." Para mantener la integridad del modelo, es
importante actualizar todos los requisitos afectados. En las iteraciones iniciales se
da énfasis en los primeros pasos (nivel superior de la pirámide),
y en las últimas iteraciones se pasa más tiempo en el nivel inferior de la pirámide.
A continuación se describe brevemente estos pasos.
1.1. Establecimiento de un plan de gestión de requisitos

Una de las primeras tareas en el proyecto es el desarrollo de un Plan de
Gestión de Requisitos1. Este plan describe el enfoque global de la gestión de
requisitos en el proyecto. El documento da detalles de cómo los requisitos
son creados, organizados, modificados y rastreados durante el ciclo de vida
del proyecto. También se describen todos los tipos de requisitos y sus
atributos utilizados en el proyecto.
Aquí hay algunas preguntas que pueden ser contestadas en el plan:
 ¿Se utilizará alguna herramienta de gestión de requisitos?

 ¿Qué tipos de requisitos serán rastreados en el proyecto?
 ¿Cuáles son los atributos de estos requisitos?
 ¿Dónde se crearán los requisitos, únicamente en una base de datos o en
documentos?
 ¿Entre qué requisitos necesitamos aplicar la trazabilidad?
 ¿Qué documentos se requieren?
 ¿Qué requisitos y documentos que se utilizarán como un contrato con los
clientes?
 Si una parte del proyecto se subcontrata, ¿qué requisitos y documentos
serán utilizados como un contrato con un vendedor?
 ¿Vamos a seguir la metodología RUP o alguna otra?
 ¿El cliente necesita documentos específicos para cumplir con su proceso
de desarrollo?
 ¿Cómo la gestión de cambios se llevará a cabo?
 Suponiendo que se utiliza Requisite Pro, ¿todo el sistema se almacenará
en un Proyecto Requisite Pro o se crearán varios proyectos?
 ¿Qué proceso garantizará que todos los requisitos serán implementados
y verificados?
 ¿Para qué requisitos o vistas tenemos que generar informes?
1
En inglés es conocido como Requirements Management Plan (RMP).

102
1.2. Captura de requisitos

Este paso se concentra en capturar todas las necesidades de stakeholders
utilizando una o más técnicas que se citan a continuación:
 Entrevistas. Diálogo individual con un stakeholder.

 Cuestionarios. Un conjunto de preguntas preparadas para un gran
grupo de stakeholders.
 Workshops. Reunión de stakeholders por un periodo intensivo.
 Storyboards. Uso de una herramienta visual gráfica para mostrar el
comportamiento del sistema.
 Role-playing. A cada miembro del grupo se le asigna un rol, usualmente
uno de los usuarios.
 Sesiones de lluvias de ideas (brainstorming). Presentación de ideas
durante una sesión breve e intensiva.
 Prototipos. Desarrollo de un prototipo para obtener retroalimentación
 Casos de uso. Descripción de la interacción entre un usuario y el
sistema presentado como una secuencia de pasos.
La técnica a usar dependerá de la naturaleza de los requisitos y el tipo de

stakeholder. Es buena práctica especificar el resultado de esta tarea en el
documento Solicitudes de stakeholder1 y almacenar cada uno de los
requisitos en una base de datos. Esto permitirá asignarles varios atributos,
como la prioridad o dificultad. También permite realizar el seguimiento de los
requisitos y derivarlos a otros tipos de requisitos.
Un punto importante que resaltar es que se debe tener cuidado de no perder

o mal interpretar un requisito en este nivel, de lo contrario este problema se
propagará durante todo el ciclo de desarrollo.
Las necesidades de stakeholders no necesariamente tienen los atributos de

un buen requisito mencionados en la sesión anterior; pero los requisitos que
se encuentran en niveles inferiores a estas, sí los presentan. Este tipo de
requisito se encuentra en el nivel superior de la pirámide, tal como se ilustra
en la figura 10.1.
Figura 10.1. Necesidades de stakeholders en la pirámide
1
En inglés Stakeholder Requests

1.3. Desarrollo del documento Visión

El documento Visión es uno de los más importantes documentos creados en
la gestión de requisitos en RUP y el cual puede ser utilizado como un
contrato entre los desarrolladores y clientes para los requisitos técnicos.
El propósito del documento Visión es:

 Definir los límites del sistema
 Identificar restricciones impuestas en el sistema
 Conseguir acuerdos con los clientes sobre el alcance del proyecto
 Crear una base sobre la cual se definen los documentos de casos de
uso y especificaciones de requisitos suplementarios
La Visión es un repositorio de los requisititos del tipo “Característica”

(Feature) y son listados en la sección “Características del Producto” del
documento. Este tipo de requisitos se resalta en la figura 10.2.
Figura 10.2. Características del sistema en la pirámide
Las características se derivan de las necesidades de los stakeholders. Es

importante no perder de vista qué característica fue derivado de las
necesidades de stakeholders.
Para crear uno o varios requisitos FEAT (Features) a partir de los requisitos
STRQ (Stakeholders request) se aplica alguna de las siguientes estrategias
de transformación:
 Copiar: Si no se requieren cambios, el STRQ puede ser copiado a

FEAT exactamente como es.
 Dividir: Si el requisito no es atómico, podemos dividir en dos o más
requisitos.
 Aclaración: Aclaración o explicación, se puede aplicar cuando el
requisito original es poco claro o ambiguo.
 Cualificación: Logramos cualificar mediante la adición de restricciones
o condiciones al requisito. Puede ayudar a resolver las necesidades
contradictorias.
 Combinación: Si los requisitos son redundantes o se superponen se
pueden combinar en uno solo.
 Generalización: Si la necesidad no es abstracta, e incluye algunos
detalles innecesarios, podemos aplicar la generalización.

104
 Cancelación: A veces el requisito debe ser eliminado. Esto puede

suceder cuando el requisito es no viable, innecesaria, o incompatible
con otro requisito.
 Completar: Si el conjunto de requisitos es incompleta, puede ser
necesario añadir requisitos en esta etapa.
 Corrección: Corrección puede significar una nueva redacción del
requisito para corregir la gramática, ortografía o puntuación; o
cambiar una parte de la necesidad que no es cierta.
 Unificación: Los requisitos que usan un vocabulario inconsistente
pueden ser unificadas (estandarizadas).
 Adición de detalles: Si el requisito no es lo suficientemente preciso,
podemos añadir más detalles. Esta técnica
se utiliza a menudo para obtener requisitos verificables de los que no
han sido especificados como tal.
Una vez creados los requisitos del tipo características, se debe especificar
sus atributos. Los atributos, los cuales son propiedades de los requisitos,
ayudan a organizar y analizar los requisitos del proyecto. Se pueden crear
reglas para decidir, sobre la base de atributos, cuáles de los requisitos se
implementarán en la siguiente iteración, fase o lanzamiento (release).
A continuación se indican los atributos que usualmente presentan las

características:
 Prioridad (generalmente se usa para determinar el orden de
implementación)
 Estado (seguimiento del progreso del desarrollo del requisito:
propuesto, aprobado, incorporado y validado)
 Dificultad (lo difícil que puede ser la implementación de este requisito,
los valores por defecto son de alta, media y baja)
 Estabilidad (la probabilidad de que el requisito no va a cambiar
durante el proyecto)
 Riesgo (la probabilidad de resultados relacionados con este requisito:
problemas con su implementación, incumplimiento de los plazos, etc.)
 Planificación de la iteración (por ejemplo, E1-la primera iteración en la
fase de elaboración)
 Iteración actual
 Origen (fuente del requisito)
 Nombre del contacto (normalmente la persona responsable de este
requisito)
 Mejora de Requisito
 Defecto
 Autor
 Localización (documento en el que el que se encuentra)
Aparte de las enunciadas en la lista anterior, el equipo de desarrollo puede

agregar otros atributos si así lo prefiere. Por ejemplo, el atributo Importancia
el cual incluye los valores: obligatorio y deseable. En situaciones extremas,
múltiples atributos pueden almacenar estos valores de importancia, el cual
no es lo mismo que prioridad, porque la importancia según el usuario puede
no ser la misma importancia según el gerente del proyecto.

1.4. Creación de casos de uso

Los requisitos funcionales son mejor descritos en forma de casos de uso.
Ellos son derivados de características y a partir de los casos de uso se
derivan sus escenarios, tal como se ilustra en la figura 10.3.
Figura 10.3. Casos de uso y sus escenarios en la pirámide
El propósito de los casos de uso es facilitar acuerdos entre desarrolladores,

clientes y usuarios acerca de lo que el sistema debe hacer. De este modo,
un caso de uso puede ser usado como un contrato entre los desarrolladores
y clientes. Este también es la base para las realizaciones de casos de uso,
los cuales juegan un papel importante en análisis y diseño; documentación y
casos de prueba.
Los siguientes son algunas características de casos de uso:

 Son iniciados por un actor.
 Modelan una interacción entre el actor y el sistema.
 Describen una secuencia de acciones.
 Capturan requisitos funcionales.
 Proporcionan algún valor a un actor.
 Representan un completo y significativo flujo de eventos.
La creación de casos de uso incluye las siguientes actividades:

 Encontrar actores
 Encontrar casos de uso y detallarlos
 Estructurar el modelo de casos de uso
2.4.1. Encontrar actores

En esta actividad se identifican a los actores a partir de los
stakeholders.
Un actor puede ser un rol de usuario o un sistema que recibe o

entrega información. En algunos casos, representaremos al tiempo
como actor para indicar que el caso de uso se inicia en un momento
específico.

106
2.4.2. Encontrar casos de uso

Los casos de uso se identifican a partir de las características
especificadas en el paso anterior (Desarrollo del documento Visión) y
para cada actor identificado hasta el momento. Más casos de uso se
pueden obtener, aparte de los derivados de las características,
utilizando la técnica workshop con stakeholders. Una vez identificado
los casos de uso se procede a describirlos mediante el documento
Especificación de Caso de Uso, tal como se muestra en la siguiente
página para el caso de uso “Reservar Habitación”.
Por último, se crean diagramas de casos de uso para representar a los

actores, casos de uso y las relaciones entre ellos. Se puede utilizar
cualquier herramienta CASE para realizar este tipo de diagrama.
Estos diagramas se crean en un paquete denominado Modelo de

casos de uso. Para pequeños sistemas, el modelo de casos de uso
puede contener sólo un diagrama de casos de uso; mientras que para
grandes sistemas, se necesitará dividir el sistema en varios
diagramas. No existen reglas estrictas acerca de cómo el modelo
debería dividirse. A continuación se indican algunas opciones de
agrupación:
 Todos los casos de uso iniciado por el mismo actor o grupo de
actores
 Los casos de uso relacionados con el mismo tipo de tareas
 Los casos de uso relacionados para dar soporte a un proceso de
negocio
2.4.3. Estructurar el modelo de casos de uso

Después de crear el modelo de casos de uso inicial, se procede a
estructurarlo. El objetivo principal de la estructuración del modelo es
eliminar redundancias, hacer que los casos de uso sean más fáciles
de entender y mantener.
En primer lugar, hay que analizar los casos de uso y encontrar las
partes de los flujos que contengan pasos similares. Luego podemos
aplicar algunos de los tres tipos de relaciones entre casos de uso:
 Include: Para representar que un caso de uso incluye el
comportamiento de otro.
 Extend: Para representar que un caso de uso extiende a otro caso
de uso, el cual se activa cuando se da una condición.
 Generalización: Este tipo de relación se da tanto entre casos de
uso como entre actores.
Si dos o más casos de uso son similares, se puede extraer lo común

y trasladar el comportamiento a un caso de uso base y luego los casos
de uso derivados agregan y modifican el comportamiento definido en
el caso de uso base. Debido a que este tipo de estructura no es
comprendido por los stakeholders, IBM Rational sugiere evitar su uso.
En el caso de actores, la generalización es especialmente utilizada si

un conjunto de actores inician el mismo caso de uso.

Especificación de caso de uso: Reservar Habitación
Reservar Habitación
El caso de uso permite a la Recepcionista de un hotel generar una reserva de
habitación(es). Además de saber en que estados se encuentran: reservado,
ocupado o disponible.
2. Actor(es)
Recepcionista
3. Flujo de Eventos
El Caso de uso se inicia cuando la Recepcionista selecciona la opción “Reservar
Habitación” en la interfaz del menú principal.
3.1. Flujo Básico

1. El sistema muestra la interfaz RESERVA con los siguientes datos:
 Datos del cliente: Código, nombres y apellidos.
 Datos de la Reserva: Fecha de llegada, fecha de salida y cantidad de
días a hospedarse.
 Datos de las habitaciones: Número de habitación, Tipo, Costo por
día, Nombre del huésped de la Habitación y una opción para
Agregar Habitación.
Además incluye una cuadricula que contiene la lista de todas las
habitaciones reservadas y las opciones: Buscar Cliente, Agregar
Cliente, Buscar Habitación, Eliminar Habitación, Grabar Reserva y
Salir.
2. La Recepcionista selecciona “Buscar Cliente”.
3. El sistema Incluye el Caso de Uso Buscar Cliente.
4. El sistema muestra los datos del cliente.
5. La recepcionista ingresa la fecha de llegada y la fecha de salida.
6. El sistema calcula la cantidad de días.
7. La recepcionista solicita “Buscar Habitación” disponible.
8. El sistema Incluye el Caso de Uso Buscar Habitación.
9. El sistema muestra la habitación seleccionada.
10. La Recepcionista ingresa el nombre de la persona para la habitación
seleccionada.
11. La Recepcionista selecciona agregar Habitación
12. El sistema calcula el pago de la habitación, el subtotal, el monto total y lo

108
agrega a la cuadricula del detalle de la reserva.

13. Si la Recepcionista quiere seleccionar otra habitación, se repite del paso
7 al 12.
14. La Recepcionista selecciona “Grabar Reserva”.
15. El sistema autogenera un número de reserva.
16. El sistema graba la reserva con su detalle y actualiza la(s)
disponibilidad(es) de la(s) habitación(es) en estado “Reservado”.
17. El sistema muestra el número de reserva y el MSG “Reserva generada”
con el Nro. 99999”.
18. La recepcionista cierra la interfaz RESERVA y regresa a la interfaz del
menú principal del sistema y finaliza el caso de uso.
3.2. Subflujos
Ninguno.

3.3.1. Cliente no existe
Si el sistema detecta que el cliente no existe muestra el MSG: “Cliente no
existe” y ofrecerá la posibilidad de registrar al nuevo cliente.
3.3.2. Fechas incorrectas
Si el sistema detecta que alguna de las fechas ingresadas (de llegada y
salida) es incorrecta muestra el MSG: “Fechas incorrectas” y el caso de uso
continúa en el paso 5.
3.3.3. Habitaciones no disponibles
Si el sistema detecta que no hay habitaciones disponibles muestra el MSG:
“No hay habitaciones disponibles” y finaliza el caso de uso.
3.3.4. Eliminar Habitación de Cuadricula
La recepcionista selecciona una habitación y selecciona eliminar, el sistema
elimina de la cuadricula la habitación selecciona y el caso de uso continúa.
4. Precondiciones
1. El Recepcionista está logeado en el sistema.
2. Lista de Clientes disponibles.
3. Lista de habitaciones disponibles.
5. Poscondiciones
1. En el sistema queda registrado la reserva.
2. Las disponibilidades de las habitaciones seleccionadas se actualizan en
estado “Reservadas”.

1. En el paso 5, el sistema extiende al caso de uso Mantener Clientes – Flujo
básico “Agregar Cliente”.
Ninguno.
8. Prototipos
Interfaz RESERVA

110
1.5. Especificación suplementaria

La especificación suplementaria captura todos los requisitos que no pueden
ser expresados en casos de uso. Sin embargo, esto no significa que todos
los requisitos funcionales están en los casos de uso y que todos los
requisitos no funcionales están en la Especificación Suplementaria. La
Especificación de Casos de uso también contiene los requisitos no
funcionales, si se aplican a un solo caso de uso. La Especificación
Suplementaria contiene todos los requisitos funcionales genéricos que no
están asociadas con ningún caso de uso específico. La tabla 10.2 ilustra qué
tipo de requisito se encuentra en un documento.
Tipo de Especificación
Especificación de caso de uso
requisito suplementaria
Requisitos
Flujo básico y flujos alternativos funcionales
Funcional relacionados a un caso de uso relacionados a
específico. más de un caso
de uso.
Requisitos no
funcionales
Especificación no funcional
No Funcional relacionados a
relacionada a un solo caso de uso.
muchos casos de
uso.
Tabla 10.2. Requisitos en documentos de Especificación
Recientemente, el nombre del artefacto fue cambiado en Rational Unified

Process (RUP) de "Especificación Complementaria" al plural
"Especificaciones suplementarias" para reflejar el hecho de que podemos
usar más de un documento para capturar requisitos suplementarios.
En la pirámide, los requisitos suplementarios están en el mismo nivel que los

casos uso, como se muestra en la figura 10.4.
Figura 10.4. Requisitos suplementarios en la pirámide
Muchas características que se definen en el documento Visión se convierten

en requisitos suplementarios. Su inclusión en la Especificación Suplementaria
proporciona una oportunidad para añadir más detalles y organizar los

requisitos en la sección apropiada del documento, de acuerdo a la categoría

FURPS + a la que pertenecen. Un método consiste en ir a través de todas las
características, identificar cuáles no se abordaron en los casos de uso, y
traducirlos a requisitos suplementarios, los cuales son descritos con más
detalle y más específicos. Muy a menudo no se necesitan cambios, y
podemos usar la misma formulación como en las características.
1.6. Creación de casos de prueba de casos de uso

En muchos proyectos la importancia de este paso no es reconocido. A
menudo, a los testers se les da una impresión de Especificación de caso de
uso y, a continuación, ellos realizan las pruebas manuales. Sin embargo, si
descuidamos la creación formal de los casos de prueba, se puede terminar
con una cobertura pobre de un universo de pruebas ejecutando muchas
pruebas duplicadas.
Figura 10.5. Casos de prueba para verificar casos de uso en la pirámide
Cuando tengamos todos los escenarios derivados de un caso de uso, se

crean los casos de prueba. Para ello, se sigue cuatro pasos:
 Identificar las variables para cada paso del caso de uso.
 Identificar opciones significativamente diferentes para cada variable.
 Combinar opciones en estudio en los casos de prueba.
 Asignar valores a las variables.
A continuación se describe con más detalle cada paso.
1.6.1. Identificar variables para cada paso del caso de uso

En primer lugar, tenemos que identificar todas las variables de
entrada en los pasos que lo requieran del escenario dado. Por
ejemplo, si en algún paso el usuario introduce un ID de usuario y
contraseña, hay dos variables. Una variable es el ID de usuario, y el
segundo es la contraseña. La variable puede ser también una
selección que el usuario puede hacer (como la selección de un vuelo
procedente de una lista).
A continuación se muestra las variables que se utilizan en los pasos

del flujo básico del caso de uso “Reservar Habitación”:

112
B5. La recepcionista ingresa la fecha de llegada y la fecha de salida.

 Fecha de llegada de reserva
 Fecha de salida de reserva
B10. La Recepcionista ingresa el nombre de la persona para la
habitación seleccionada.
 Nombre del huésped de la Habitación
1.6.2. Identificar opciones significativamente diferentes para cada variable

Las opciones son "significativamente diferentes" si se pueden activar
diferentes comportamientos del sistema. Las siguientes directrices
describen algunos casos específicos.
Una opción puede ser considerada significativamente diferentes si:
 Se activa un flujo de procesos diferentes (por lo general un

flujo alternativo).
Ejemplo: Ingreso de una contraseña no válida activará el

Flujo Alternativo 2.
 Se activa un mensaje de error diferente.
Ejemplo 1: Si un e-mail es demasiado largo, el mensaje será

"E-mail no debe tener más de 50 caracteres."
Ejemplo 2: Si un e-mail no contiene el @ (arroba), el mensaje

será “E-mail no válido."
 Se produce un aspecto diferente en la interfaz de usuario.
Ejemplo: Si el método de pago es una tarjeta de crédito, la

pantalla deberá mostrar los campos donde la
el usuario puede introducir el número de tarjeta de crédito,
fecha de expiración, y nombre del titular.
 Se produce diferentes selecciones disponibles en listas

desplegables.
Ejemplo: La pantalla de registro de cliente deberá contener

listas desplegables para el País y Estado/Provincia.
Provincia/Estado se rellena en función del país seleccionado:
para EE.UU. deberá mostrar todos los estados, para Canadá
todas las provincias, y para otros países
sucederá lo mismo, es decir, dependiendo del país se cargarán
o provincias o estados.
 Es una entrada para una regla de negocio.
Ejemplo: Si el pedido se realiza después de las 6 p.m., y el

usuario selecciona Envío Nocturno, un mensaje deberá
informar al usuario de que el libro llegará pasado mañana.

Esta regla de negocio plantea dos opciones distintas:

- Envío nocturno con pedidos antes de las 6 p.m.
- Envío nocturno con pedidos después de las 6 p.m.
 Es una condición límite.

Ejemplo: La contraseña debe tener por lo menos seis
caracteres.
En este caso se debe comprobar lo siguiente:

- Contraseña con cinco caracteres
- Contraseña con seis caracteres
 Si está probando números, usted puede considerar las

siguientes opciones significativamente diferentes:
- Número regular, razonable desde el punto de vista de la

aplicación
- Cero
- Número negativo
- Un número con dos decimales
- El mayor número que se puede escribir (por ejemplo,
99999999999999 – tantos nueves como puede ingresarse
en el campo de texto).
A continuación se muestra algunas opciones de valor de prueba para

todas las variables del flujo básico del caso de uso “Reservar
Habitación”:
B5. La recepcionista ingresa la fecha de llegada y la fecha de salida.

 Fecha de llegada de reserva
- Fecha futura válida ingresada manualmente
- Fecha futura válida ingresada de un calendario
- Fecha pasada
- Fecha actual
- 30 o 31 de Febrero
- Ninguna fecha
- Válida con una año después de la actual
 Fecha de salida de reserva

- Fecha razonable ingresada manualmente
- Fecha razonable ingresada de un calendario
- Fecha pasada
- Fecha igual a la de llegada
- 30 o 31 de Febrero
- Fecha anterior a la de llegada

114
B10. La Recepcionista ingresa el nombre de la persona para la

habitación seleccionada.
 Nombre del huésped de la habitación
- Nombre regular
- Nombre largo (máximo número de caracteres permitido)
- Nombre conteniendo un apóstrofe (tal como D’ Natali)
- Nombre con un carácter más del permitido
- Un carácter
- En blanco
- Dos palabras con un espacio entre ellos
1.6.3. Combinar opciones en estudio en los casos de prueba

El paso anterior se identificaron todas las opciones significativamente
diferentes para las pruebas. Ahora tenemos que combinarlas en la
secuencia de pasos del caso de prueba. Una forma de hacerlo es
crear una Matriz de Asignación de Casos de Prueba, tal como se
ilustra en la tabla 10.3.
Paso Variable T1 T2 T3 T4 T5 T6
Tabla 10.3. Matriz de Asignación de Casos de Prueba
Las filas de esta matriz contendrán todas las variables para todos los
valores que requieran la entrada del usuario. En la primera columna
se especificará el número del paso del flujo básico del caso de uso
(obtenido de la Especificación de Caso de Uso), en la segunda
columna se indicará el nombre de la variable, y las columnas
restantes contendrán las pruebas (o tests en inglés) de los casos. Las
pruebas pueden ser etiquetadas con T1, T2 y así sucesivamente.
Es necesario estimar cuántos casos de prueba cubrirá un escenario.

Una estimación aproximada puede ser el mayor número de opciones
significativamente diferentes para una variable. Si calcula de forma
incorrecta, no hay problema porque se puede añadir o eliminar una
columna, mientras se va llenando la matriz.
Por lo general, de cinco a siete casos de prueba cubren escenarios

típicos. Sin embargo, algunos casos específicos de aplicación
requieren más casos de prueba. Tenemos que crear una matriz por
escenario elegido para la prueba.
La tabla 10.4 que se muestra, corresponde a la Matriz de Asignación

de Casos de Prueba para el flujo básico del caso de uso “Reservar
Habitación”:

B5 Fecha de llegada de reserva
B5 Fecha de salida de reserva
B10 Nombre del huésped de la habitación
Tabla 10.4. Matriz de Asignación de Casos de Prueba con todas las variables para el Caso de Uso “Reservar Habitación”
En la primera fila de cada variable, se ingresa todas las opciones que se necesita probar. En cada columna se ingresará una opción diferente,
tal como se muestra en la tabla 10.5. Algunas de las opciones son incorrectas porque se necesita probar si el sistema responde con el
mensaje de error adecuado o previene al usuario del ingreso incorrecto.
Si para una variable existen más opciones que columnas de pruebas, entonces se crea otra fila para ingresar dichas variables, considerando
una combinación razonable de opciones válidas, adicionales si se requiere, por cada opción incorrecta de la fila anterior. Por ejemplo, en la
segunda fila para la variable “Fecha de llegada de reserva” se ingresaron opciones correctas para las pruebas T3, T5 y T6 que tienen opciones
incorrectas en la fila anterior. En otros casos será necesario agregar más filas para completar las pruebas, tal como se hizo en la variable
“Fecha de salida de reserva”.
Fecha de llegada de Válida Válida de un
B5 Pasada Actual Incorrecta Ninguna
reserva manualmente calendario
Válida con una año después Válida Válida de un
de la actual manualmente calendario
Fecha de salida de Válida Válida de un Igual a la de
B5 Pasada Incorrecta Ninguna
reserva manualmente calendario llegada
Válida con un año después de Válida Válida de un
la actual manualmente calendario
Válida con una semana Válida de un Válida
después de la fecha de llegada calendario manualmente
Nombre del huésped de la Con máxima Mayor longitud
B10 Regular Con un apóstrofe Un carácter En blanco
habitación longitud de la permitida
Dos palabras Regular
Tabla 10.5. Matriz con las opciones combinada para las variables del Caso de Uso “Reservar Habitación”

ANÁLISIS Y DISEÑO DE SISTEMAS I (TEORÍA) 116
1.6.4. Asignar valores a las variables

En este paso, se dividen todos los casos de prueba de la Matriz creada
en el paso anterior, creando una tabla separada para cada caso de
prueba. Luego, se reemplaza las opciones definidas para cada variable
con valores para realizar las pruebas. Además, se agregan más filas
para las acciones, tales como clic sobre un botón o selección de item
de lista desplegable.
Por ejemplo para el caso de prueba T1 del caso de uso “Reservar

Habitación” se crea la siguiente tabla. Note que se agregaron filas que
contienen acciones en los pasos B2, B7, B10 y B11.
Resultado Resultado Pasa/ Comen-
Paso Variable T1
esperado actual Falla tarios
Buscar Datos de un
B2 Buscar Cliente cliente cliente
Fecha de llegada
B5 01-12-2009 Aceptar
de reserva
Cantidad de
Fecha de salida
B5 05-12-2009 días de
de reserva hospedaje
Datos de
Buscar Buscar una
B7
Habitación Habitación habitación
disponible
Nombre del
Miguel
B10 huésped de la Vásquez
Aceptar
habitación
Pago de la
habitación
(subtotal y
Agregar Agregar monto total)
B11
Habitación Habitación en la
cuadrícula
de detalle
de reservas
Número de
Grabar
B14 Grabar reserva reserva
reserva
generada
Tabla 10.6. Caso de prueba
1.7. Creación de casos de prueba de la especificación suplementaria

No existe un criterio unificado para crear casos de prueba para requisitos
complementarios debido a que estos requisitos son de diferente naturaleza.
A continuación se presenta los métodos de creación de casos de prueba
para requisitos suplementarios:
 Ejecutar casos de prueba seleccionados en diferentes entornos
 Agregando una comprobación adicional a todos los casos de uso
 Comprobando y modificando casos de uso específicos
 Realizar la acción descrita en el requisito
 Listas de verificación

 Pruebas de caja blanca

 Pruebas automatizadas
1.7.1. Ejecutar casos de prueba seleccionados en diferentes entornos

Este método se utiliza en requisitos suplementarios que requieren que la
aplicación trabaje en diferentes entornos tales como browser de Internet,
sistemas operativos, etc. Por ejemplo, sea el siguiente requisito:
La interfaz basada en Web será ejecutado en Internet Explorer (versión

6.0 y versiones posteriores) y Netscape (versión 6 y posteriores).
Para realizar la prueba de este requisito se selecciona un caso de prueba

de algún escenario de caso de uso y luego se ejecuta en los diferentes
navegadores de Internet indicados. Esto significa que el caso de prueba
será ejecutado usando IExplorer y luego usando Netscape.
La siguiente figura muestra este método. El escenario seleccionado es

probado en diferentes entornos, por lo tanto se tiene un caso de prueba
por entorno.
Figura 10.6. Casos de prueba para verificar requisitos

suplementarios a partir de un escenario.
1.7.2. Agregando una verificación adicional a todos los casos de uso

Muchos requisitos describen la apariencia o el comportamiento de
algunos controles en la interfaz de usuario. Aquí hay algunos ejemplos:
En cada página un botón Siguiente sugerirá un flujo predeterminado.
En las pantallas de entrada de datos del sistema deberá indicar qué

campos son obligatorios colocando una estrella junto al campo.
El sistema deberá mostrar un calendario pop-up cuando se introduce
una fecha.
Campos de entrada múltiple en una sola página se alinearán
verticalmente.

Cuando se muestra un cuadro de diálogo, el foco del cursor deberá

situarse en el primer campo de texto en el cuadro de diálogo.
Por cada entrada no válida para el usuario, el sistema mostrará un

mensaje de error significativo, explicando qué formato se espera para el
dato ingresado.
Cantidades de moneda se calculan y se almacenan con una precisión de

dos cifras decimales.
Cada característica del sistema debe ser descrito en ayudas en línea,

disponible en el menú en cada página.
En las páginas que recogen los datos personales del usuario, habrá un
enlace a una página describiendo la política de privacidad.
La mejor manera de incorporar las pruebas de estas características es

agregando un control a todos los casos de prueba que se ha creado
para casos de uso diferentes. Debido a que los casos de prueba
derivados de casos de uso cubren cada posible pantalla de la
aplicación, sólo puede agregar los controles pertinentes, durante su
visita a cada una de las pantallas específicas. De esta forma, podemos
estar seguros de que la función se verificó en todos los lugares en los
que sea aplicable. En la figura 10.7 se muestra que todos los casos de
prueba se actualizan con un requisito suplementario específico.
Figura 10.7. Verificación adicional a casos de prueba

1.7.3. Comprobando y modificando casos de uso específicos

A pesar de que algunos requisitos se describen en las especificaciones
suplementarias, están asociadas con algunos casos de uso específico.
Esto puede ocurrir cuando dicha funcionalidad no está realmente
relacionada con el caso de uso principal, pero desempeña un papel de
apoyo o administrativos. Como ejemplo, podemos tener a los requisitos
relacionados con la seguridad y acceso protegido con contraseña a
algunas partes de la aplicación:
Una contraseña será necesaria para acceder a las pantallas del

administrador.
Para presentar las ofertas, los proveedores de hotel, los proveedores de

automóviles, y representantes de las aerolíneas deberán iniciar sesión en
el sistema utilizando sus nombres de usuario y contraseñas.
La figura 10.8 muestra la actualización que se hace al caso de uso, y

después se propaga a través de escenarios de y casos de prueba.
Figura 10.8. Algunos requisitos suplementarios afectan a los casos de

uso y sus escenarios y casos de prueba creados a partir de ellos
1.7.4. Realizar la acción descrita en el requisito

Muy a menudo tenemos que realizar la acción descrita en el requisito
debido a que en muchos casos, la tarea no requiere la creación de
escenarios formales y casos de prueba. Por ejemplo:
Un error de registro que contiene información sobre todos los errores

críticos deberá ser accesible por el administrador del sistema a través de
Internet, por lo que se puede comprobar de forma remota en cualquier
momento.
Para probar este requisito, alguien que tenga el rol de administrador

ingresará al sistema a través de Internet y comprobará si podrá acceder
a un registro de errores.

1.7.5. Listas de verificación

Algunos requisitos no necesitan ninguna prueba complicada, por lo que
sólo puede comprobarse para ver si se han cumplido agregándolo en
una lista de verificación. Por ejemplo:
El sistema usará una base de datos de Oracle.
O se utiliza Oracle, o no - simplemente se marca en la lista de

verificación.
Algunos otros ejemplos de este tipo de pruebas, simplemente marcando

una lista de verificación podrían incluir las siguientes:
Todos los errores del sistema se registrarán y se pondrán a disposición

del administrador.
Todas las transacciones (compra de tickets, hacer una reserva, la

actualización de una reserva, y anulación de una reserva) se registrarán y
se pondrán a disposición del administrador.
El sistema usará una arquitectura J2EE.
Si la arquitectura requiere de un servidor de aplicaciones, se utilizará

IBM WebSphere.
La Guía del administrador estará disponible en formato PDF.
1.7.6. Pruebas de caja blanca

Algunas pruebas deben hacerse con conocimiento del código de la
aplicación o alguna otra aplicación interna. Esto se denomina prueba de
caja blanca.
Al mostrar una lista de habitaciones disponibles, el sistema no puede

perder ninguna habitación disponible para las fechas solicitadas.
Para comprobar este requisito, tenemos que acceder directamente a la

base de datos y verificar el contenido de la tabla de disponibilidad de
habitaciones, Luego se compara los resultados con la lista obtenida a
través de nuestro sistema.
Otros casos de prueba requieren comprobar si un algoritmo específico se

ha aplicado correctamente:
Para realizar la búsqueda de la lista de los vuelos de retorno deberá

incluir el Algoritmo de ruta más corta de Dijkstra.
1.7.7. Pruebas automatizadas

La prueba automatizada es muy útil en el control de requisitos de
rendimiento y confiabilidad tales como los siguientes:

El tiempo promedio de respuesta del sistema deberá ser inferior a dos

segundos.
El sistema tendrá capacidad para 1000 vuelos reservados por minuto.
El sistema deberá adaptarse a 5000 usuarios concurrentes.
El sistema puede no estar disponible no más de un minuto por cada 24

horas.
Para obtener un rendimiento y pruebas de fiabilidad, no es necesario

para automatizar todos los casos de prueba. Podemos
seleccionar entre dos y tres casos de prueba. Vale la pena la selección
de un caso de prueba que representa el escenario más utilizado y que
contenga varias operaciones.
Las herramientas de IBM, disponibles para realizar pruebas, son

Rational Robot, Rational Test Manager, Rational Clear Quest Test
Manager, Rational Functional Tester y Rational performance Tester.
1.8. Diseño del sistema

Los requisitos son la base para el diseño del sistema, el cual es realizado
utilizando diagramas de UML. Muchas de las herramientas, tales como
Rational Rose, Rational Software Architect, Infosphere Data Architect y
Rational Software Modeler, pueden facilitar la creación de todos los
diagramas necesarios.
Un método es crear diagramas de interacción de los escenarios y, al mismo

tiempo, asignar funcionalidad a las clases. La siguiente figura utiliza la
pirámide de requisitos para representar esta actividad.
Figura 10.9. Diseño de sistemas

1. A partir de la lista de necesidades de stakeholders para una agencia de viajes,
derive características del sistema (FEATURES) e indique qué tipo de
transformación utilizó:
STRQ1: El vuelo de ida y de vuelta se ordenan por el menor número de paradas.

STRQ2: Los vuelos disponibles serán ordenados por precio.
STRQ3: El sistema tendrá una navegación clara.
STRQ4: El sistema ofrecerá la posibilidad de reservar vuelos, comprar un ticket,
reservar una habitación de hotel, reservar un automóvil y proporcionar información
sobre lugares de interés.

Resumen
 En RUP, una descripción simplificada del proceso de gestión de requisitos contiene

los siguientes pasos:
 Establecimiento de un plan de gestión de requisitos

 Captura de requisitos
 Desarrollo del documento Visión
 Creación de casos de uso
 Especificación suplementaria
 Creación de casos de prueba de casos de uso
 Creación de casos de prueba de la especificación suplementaria
 Diseño del sistema
 Cada paso de la gestión de requisitos, a partir del segundo, navega a través de la

pirámide de requisitos de arriba hacia abajo y de izquierda a derecha.
 Los requisitos son más específicos en los niveles inferiores de la pirámide
 “REQUIREMENTS MANAGEMENT USING IBM RATIONAL REQUISITE PRO”

de Peter Zielczynski.
Del capítulo 3 al 11 se describe con más detalle cada uno de los pasos de la
gestión de requisitos según RUP.


UNIDAD DE
APRENDIZAJE
2
TEMA
11
TRAZABILIDAD DE REQUISITOS

TEMARIO
1. Trazabilidad entre requisitos.

2. Los alumnos crean matrices de trazabilidad entre características del sistema y
casos de uso.
3. Los alumnos crean matrices de trazabilidad entre características del sistema y
requisitos suplementarios.

1. TRAZABILIDAD ENTRE REQUISITOS

La trazabilidad es una técnica que proporciona una relación entre los diferentes
niveles de requisitos en el sistema. Esta técnica ayuda a determinar el origen de
cualquier requisito. La figura 11.1 ilustra cómo los requisitos se trazan desde el
nivel superior hacia abajo. Todas las necesidades por lo general se asignan a
algunas características. En general, es una relación de muchos a muchos, porque
una necesidad puede rastrear a muchas características, y una característica
puede obtenerse de muchas necesidades. Un caso común también es que una
necesidad rastrea a una característica. En el siguiente nivel también notamos que
las características mapean a los casos de uso en una relación de muchos a
muchos. Las características también trazan a los requisitos suplementarios en una
relación de muchos a muchos.
Figura 11.1. Trazabilidad de Requisitos
Cada caso de uso traza a uno o más escenarios, así es que existe una relación de
uno a muchos entre los casos de uso y escenarios. Los escenarios también tienen
una relación de uno a muchos con los casos de prueba.
La trazabilidad desempeña varios roles importantes porque permite:
1. Verificar si la aplicación cumple con todos los requisitos: Todo lo que el

cliente pidió fue implementado.
2. Verificar si la aplicación hace sólo lo que se pidió: No implementa algo que
el cliente nunca solicitó.
3. Realizar un análisis de impacto: ¿Qué elementos se verán afectados si se
considera la adición de un nuevo requisito o cambiar una ya existente?
4. Ayudar con la gestión del cambio: Cuando algún requisito cambia,
queremos saber qué casos de prueba deben rehacerse para probar este
cambio.
La trazabilidad es una propiedad de los requisitos aplicable al resto del desarrollo

que permite conocer las dependencias entre los distintos artefactos que se van
generando.

Cada vez que se crea o cambia un nuevo artefacto (un objetivo, un requisito, un
elemento de modelado, un módulo, un fichero de código fuente, una prueba, etc.)
se debe registrar de qué elementos de nivel superior y de su mismo nivel
depende. Esta tarea es la única forma de poder realizar un análisis de impacto
cuando se solicita un cambio, pues todos los que dependen del artefacto, tanto
directa como indirectamente, están expuestos a posibles cambios.
La siguiente figura muestra la estructura de trazabilidad utilizada en un proyecto.
Figura 11.2. Diagrama de Trazabilidad
Un elemento de la trazabilidad es un elemento del proyecto que debe ser

explícitamente trazado a partir de otro elemento textual o modelo para hacer un
seguimiento de las dependencias entre ellos. La siguiente tabla describe todos los
tipos de requisitos a utilizar en el proyecto.
Elemento de
trazabilidad Tipo de documento Descripción
(Tipo de requisito)
Necesidad de Solicitudes de Necesidades claves de stakeholders
stakeholder (STRQ) stakeholder los cuales describen requisitos de
alto nivel.
Característica (FEAT) Visión Son condiciones y capacidades del
sistema.
Caso de uso (UC) Especificación de caso Requisitos funcionales capturados
de uso en casos de uso.
Requisito Especificación de Requisitos no funcionales que no
suplementario (SUPL) suplementaria son capturados en el modelo de
casos de uso.
Tabla 11.1. Tabla de descripción de elementos de trazabilidad

1. A partir de la especificación de la lista de requisitos dada por su profesor realice
las siguientes matrices de trazabilidad:
a. Características versus casos de uso.
b. Características versus requisitos suplementarios.

Resumen
 La trazabilidad es una propiedad de los requisitos aplicable al resto del desarrollo

que permite conocer las dependencias entre los distintos artefactos que se van
generando.
 http://www.ibm.com/developerworks/rational/library/04/r-3217/index.html
Este artículo ilustra el uso de IBM Rational Requisite Pro para la trazabilidad de
los casos de uso con escenarios y casos de prueba.


UNIDAD DE
APRENDIZAJE
2
TEMA
12
CASO PRÁCTICO

TEMARIO
1. Caso Práctico.
1. Los alumnos crean casos de prueba para casos de uso y requisitos

suplementarios.

1. A partir de la especificación de caso de uso mostrada en la semana 4, realice seis
casos de prueba.
2. A partir de la especificación de requisitos de software de una Galería de Arte,

mostrada en el anexo, indique qué método se utilizaría para realizar las pruebas de
los requisitos no funcionales.

UNIDAD DE
APRENDIZAJE
2
TEMA
13
INGENIERÍA DE REQUISITOS ORIENTADO A

ASPECTOS

TEMARIO
1. El paradigma orientado a aspectos.

2. Ingeniería de requisitos orientado a aspectos
1. Los alumnos realizan un informe sobre los problemas que se deben atacar en el
proceso de desarrollo basado en componentes.
2. Los alumnos realizan un informe sobre el análisis de requisitos en la primera
fase del enfoque Theme.

1. PARADIGMA ORIENTADO A ASPECTOS

El Desarrollo de Software Orientado a Aspectos (DSOA) es un paradigma en auge
que se está convirtiendo en una alternativa para mejorar el desarrollo de sistemas
complejos. Primero, surgió la Programación Orientada Aspectos (POA), centrada
en la fase de implementación y, posteriormente, se planteó el desarrollo de
sistemas OA, que propone la utilización del concepto de aspecto a lo largo de
todo el ciclo de vida. Así, los aspectos identificados en la ingeniería de requisitos o
la especificación y el análisis se utilizan en el diseño o la implementación.
Este enfoque proporciona técnicas para la identificación y separación de los

aspectos, así como su composición posterior. Igualmente permite identificar los
que son concerns1 aspectuales y los que no lo son, concretamente durante las
fases tempranas del desarrollo. Además, permiten mantener la trazabilidad de
tales concerns en etapas posteriores. De este modo, se consigue una mejora en
la modularización de los sistemas, obteniéndose un código menos enmarañado y
evitándose la mezcla entre funcionalidad del sistema y los aspectos extra-
funcionales, lo que, además, facilita el mantenimiento y la evolución. Para ello, las
técnicas para desarrollar sistemas OA amplían las técnicas tradicionales,
permitiendo el encapsulamiento de los aspectos en módulos independientes. Es
decir, encapsulan las propiedades que atraviesan varios componentes de un
sistema.
1.1. Antecedentes
Los conceptos de orientación a aspectos nacieron en 1997, cuando Gregor
Kiczales propuso una nueva idea: “la Programación Orientada a Aspectos” o
Aspect Oriented Programming en su denominación inglesa. A partir de
entonces, la POA y otras técnicas y tecnologías, que se centraban en la
modularización del código que atraviesa varios componentes para realizar
una cierta función, se agruparon bajo el nombre de Advanced Separation of
Concerns. Después de varios años, en 2002, se adoptó la denominación
actual Desarrollo de Software Orientado a Aspectos para referirse a las
técnicas y tecnologías que pretenden la modularización de los intereses de
corte transversal o entremezclado, conocido como crosscutting concerns, a lo
largo del ciclo de vida. Desde entonces, los investigadores que trabajaban en
torno a la orientación a aspectos comenzaron a estudiar las relaciones entre
aspectos así como las propiedades de la composición aspectual.
Originalmente, la identificación, especificación e implementación de los

aspectos se realizaba en la fase de implementación, viéndose los
programadores en la necesidad de ser ellos los encargados de rediseñar el
sistema para evitar el código entrelazado. En la actualidad, la responsabilidad
de identificación y especificación de aspectos se ha desplazado a fases
iniciales del ciclo de vida: durante la especificación de requisitos y la
arquitectura del software, dejando a los programadores la responsabilidad
exclusiva de su implementación.
1
Concern se define como algo en lo que se tiene interés a lo largo del desarrollo de un
sistema. IEEE especifica que los intereses para un sistema son “esas competencias que
pertenecen al desarrollo del sistema, sus operaciones o cualquier otro aspecto que sea crítico o
de otra forma importante para uno o más participantes.

En la siguiente figura se representa la implementación básica basada en los

lenguajes de procedimiento generalizado (LPG) versus una implementación
basada en POA. En la parte izquierda puede verse que el código está
entremezclado y resulta difícil de entender, depurar y modificar. En cambio,
siguiendo el DSOA, en la parte derecha de la figura, los diferentes intereses
están separados, con lo que resulta más fácil entenderlas y trabajar con ellas.
Figura 13.1. Implementación LPG versus Implementación POA
El enfoque OA ha demostrado ser una tecnología potente para manejar la

separación de intereses. Esta separación permite la construcción de un
software mejor modularizado, facilitando la reutilización, el mantenimiento y la
evolución de los sistemas. El problema principal para la adopción de estas
técnicas en proyectos a gran escala es la falta de un proceso de desarrollo
claro. Por otra parte, una de las principales ventajas de las propuestas de
DSOA es que permiten a los desarrolladores reaccionar fácilmente ante los
cambios no previstos.
1.2. Definición de un aspecto

En el DSOA hay dos términos importantes que resaltar: componente y
aspecto.
Un componente es el módulo de software que puede ser encapsulado en un

procedimiento, tales como un objeto, método, procedimiento o API. Los
componentes son unidades funcionales en las que se descompone el
sistema.
Un aspecto es aquel módulo software que no puede ser encapsulado en un

procedimiento. No son unidades funcionales en las que se puede dividir un
sistema, sino propiedades que afectan a la ejecución o semántica de los
componentes, por ejemplo, la gestión de la memoria o sincronización de
hilos.
Una de las primeras definiciones que aparecieron del concepto de aspecto

fue publicada en 1995, y se describía de la siguiente manera: Un aspecto es
una unidad que se define en términos de información parcial de otras
unidades.
La definición de aspecto ha evolucionado a lo largo del tiempo, pero con la

que se trabaja actualmente es la citada por Gregor Kiczales, quien expresa lo

siguiente: Un aspecto es una unidad modular que se disemina por la

estructura de otras unidades funcionales. Los aspectos existen tanto en
la etapa de diseño como en la de implementación. Un aspecto de diseño
es una unidad modular del diseño que se entremezcla en la estructura
de otras partes del diseño. Un aspecto de programa o de código es una
unidad modular del programa que aparece en otras unidades modulares
del programa.
2. INGENIERÍA DE REQUISITOS ORIENTADO A ASPECTOS

La ingeniería de requisitos orientada a aspectos proporciona soporte para la
separación de los intereses bajo una perspectiva dual, esto es mediante la
separación de las funcionalidades principales de la aplicación2 de otras partes con
un propósito específico, de corte transversal3 a la funcionalidad principal.
Funcionalidad básica
(Base concerns)
Intereses
(Concerns)
Intereses transversales
(Crosscutting concerns)
Figura 13.2. Tipos de intereses.
Las técnicas de ingeniería de requisitos OA reconocen la importancia de

considerar los intereses de corte transversal ya que facilitan la detección de los
conflictos que puedan surgir debido al enmarañamiento que puedan producir los
requisitos identificados como transversales. La identificación temprana de estos
conflictos facilita su resolución también en fases iniciales. Ejemplos de estos tipos
de intereses a considerar en las etapas iniciales son las relacionadas a requisitos
no funcionales tales como: autenticación, rendimiento, gestión de memoria,
auditoria, tiempo de respuesta, la sincronización de procesos concurrentes, el
manejo de errores, etc.
2.1. Enfoques de la ingeniería de requisitos orientada por aspectos

Los enfoques que se describen a continuación tratan sobre el uso de
aspectos en la ingeniería de requisitos.
3.2.1 Separación multidimensional de intereses (MDSOC)

Este enfoque es pionero en el tratamiento de los aspectos en la fase de
requisitos. Se basa en el enfoque de Puntos de Vista (Viewpoints) y su
fortaleza está centrada en el tratamiento de las reglas de composición
de los intereses, así como en la definición y manejo de conflictos. La
orientación multidimensional permite analizar el espacio de intereses del
problema de forma homogénea. Para lograr esto define un interés como
la agrupación de requisitos funcionales y no funcionales de cada punto
de vista del sistema.
2
También llamados intereses bases o “base concerns” en el idioma inglés.
3
Este término corresponde a “crosscutting concerns” en su denominación inglesa.

3.2.2 Aspectos en modelos de objetivos de requisitos (ARGM)

Este enfoque integra las propuestas I* de Eric Yu y NFR (Non-
Functional Requirements Framework) cuyo principal autor es Lawrence
chung, agregando el concepto de aspectos. Utiliza un grafo en forma de
V, llamado V-Graph, que contiene en sus vértices superiores objetivos
funcionales (goals) y objetivos de calidad (softgoals) que pueden cruzar
diferentes objetivos funcionales; en su vértice inferior se ubican las
tareas u operaciones que debe realizar el sistema. Define un proceso
sistemático e iterativo que va descomponiendo los objetivos hasta llegar
al nivel de las tareas. Durante el proceso de descomposición se verifica
el nivel de contribución de dichas tareas para el cumplimiento de los
objetivos de calidad, lo cual permitirá detectar los conflictos que puedan
presentarse y tomar acciones al respecto; si una tarea se encuentra
relacionada con más de un objetivo, se convierte en candidata a
aspecto.
3.2.3 Theme/Doc
Theme/Doc es la primera fase del enfoque Theme que describe un
proceso de desarrollo orientado por temas. La aproximación se centra
en el concepto de tema que representa una pieza de funcionalidad,
asunto o interés que se quiere modelar de forma separada del sistema.
Theme/Doc parte de una descripción textual de los requisitos en la cual

se realiza un análisis gramatical para detectar las relaciones entre los
requisitos y las acciones minor actions; a partir de estas acciones se
derivan las acciones de mayor granularidad major action o asuntos que
representan la solución de software y que entran al proceso de diseño
siguiendo las características de Theme/UML.
3.2.4 Requisitos y crosscutting concerns

Lars Rosenhainer se enfoca en la identificación de requisitos y
crosscutting concerns en documentos de requisitos ya existentes. Para
Rosenhainer un requisito es una clase especial de concern. Los
requisitos que atraviesan transversalmente a otros son referidos como
requisitos crosscutting. La expresión crosscutting concern es usada
como un sinónimo para las relaciones entre dos requisitos que está
establecida por uno atravesando transversalmente el otro. Sin embargo,
no todas las dependencias de requisitos son de naturaleza crosscutting.
3.2.5 Framewok orientado a aspectos

Isabel Brito propone un enfoque cuyo principal objetivo es desarrollar un
framework orientado a aspectos en el contexto de ingeniería de
requisitos. Para lograrlo, necesita desarrollar un modelo que soporte la
identificación de intereses, desarrollar un lenguaje para especificar
intereses, proponer un método sistemático para manejar conflictos,
identificar y mapear influencias de aspectos en etapas de desarrollo
posteriores para establecer trade-off antes de que la arquitectura sea
derivada, y por último desarrollar una herramienta simple que soporte la
especificación y composición de intereses.
Este modelo de ingeniería de requisitos se compone de varias tareas, y

a su vez estas, se componen de subtareas. Estas tareas consisten en
identificar intereses del sistema, a partir del uso de documentos y

catálogos existentes (conteniendo terminología de requisitos no

funcionales), luego especificarlos, es decir, asignar responsabilidades,
prioridades, etc., la siguiente tarea es modelar estos intereses en UML y
la última es componer los intereses, que tiene que ver con identificar
match points (abstracciones de join points en AspectJ), identificar
crosscutting concerns y manejar conflictos.
3.2.6 Enfoque basado en casos de uso

Ivar Jacobson trata la orientación a aspectos en todas las fases de la
ingeniería de software. Este enfoque trata los requisitos funcionales
desde los casos de uso que representan la función básica del sistema
(peer use cases). Los requisitos no funcionales se representan en casos
de uso que extienden un caso de uso de infraestructura, el cual se
parametriza al igual que el actor que lo usa, los parámetros representan
el comportamiento que se cruzará en la funcionalidad de los casos de
uso base. En el análisis y el diseño los casos de uso se representan en
una estructura de composición que se identifica con el estereotipo <use
case slice> y agrupa elementos de modelo que colaboran para lograr
los requisitos del sistema tanto funcionales como no funcionales.
1. Realice un informe explicando cuál es el problema que se debe solucionar en el
desarrollo basado en componentes descrito en el capítulo 1 del libro “Aspect-
Oriented Software Development With Use Cases” de Ivar Jacobson.
2. Realice un informe explicando en qué consiste el análisis de requisitos con

Theme/Doc descrito en el capítulo 1 del libro “Aspect-Oriented Analysis and
Design: The Theme Approach” de Siobhán Clarke y Elisa Baniassad.

Resumen
 Originalmente, la identificación, especificación e implementación de los aspectos

se realizaba en la fase de implementación, viéndose los programadores en la
necesidad de ser ellos los encargados de rediseñar el sistema para evitar el código
entrelazado. En la actualidad, la responsabilidad de identificación y especificación
de aspectos se ha desplazado a la ingeniería de requisitos.
 Los conceptos de orientación a aspectos nacieron en 1997, cuando Gregor

Kiczales propuso una nueva idea: “la Programación Orientada a Aspectos”.
 Gregor Kiczales expresa que “un aspecto es una unidad modular que se disemina
por la estructura de otras unidades funcionales. Los aspectos existen tanto en la
etapa de diseño como en la de implementación. Un aspecto de diseño es una
unidad modular del diseño que se entremezcla en la estructura de otras partes del
diseño. Un aspecto de programa o de código es una unidad modular del programa
que aparece en otras unidades modulares del programa.”
 La ingeniería de requisitos orientada a aspectos proporciona soporte para la

separación de los intereses bajo una perspectiva dual, esto es mediante la
separación de las funcionalidades principales de la aplicación (base concerns) de
otras partes con un propósito específico, de corte transversal a la funcionalidad
principal (crosscutting concerns).
 Si desea saber más acerca de estos temas, puede consultar los siguientes libros.
 “ASPECT-ORIENTED ANALYSIS AND DESIGN: THE THEME APPROACH.” de

Siobhán Clarke y Elisa Baniassad, 1ª edición.
Aquí encontrará la descripción completa del proceso de desarrollo orientado por
temas.
 “ASPECT-ORIENTED SOFTWARE DEVELOPMENT WITH USE CASES” de

Ivar Jacobson, 1ª edición.
En este libro se describe el desarrollo de software orientado a aspectos con
casos de uso.
 http://revista.eia.edu.co/articulos9/43-52%20(articulo%203).pdf
Aquí se presenta un artículo que hace un análisis comparativo entre algunos de

los enfoques, mencionados en esta sesión, a partir de los criterios de alcance,
trazabilidad, composición de requisitos, manejo de conflictos, mapeo, validación-
verificación y escalabilidad. Los resultados obtenidos permiten detectar las
oportunidades que el enfoque de aspectos ofrece para mejorar el proceso de los
requisitos.


UNIDAD DE
APRENDIZAJE
2
TEMA
14
CASOS DE ESTUDIO

TEMARIO
1. Caso práctico.

2. Los alumnos crean las matrices de asignación de casos de prueba y de las
opciones combinadas de variables para dos casos de uso.

1. A partir de la especificación de caso de uso “Admitir Pacientes”, mostrada en la
semana 6, confeccione la Matriz de asignación de casos de prueba y la Matriz de
opciones combinadas de variables.
2. A partir de la especificación de caso de uso “Comprar Entradas”, mostrada en la

semana 6, confeccione la Matriz de asignación de casos de prueba y la Matriz de
opciones combinadas de variables.

ANEXO
PLANTILLAS DE DOCUMENTOS DE LA GESTIÓN DE

REQUISITOS
CONTENIDO
 Plan de Gestión de Requisitos

 Visión
 Especificación de Requisitos de Software

<Nombre del Proyecto>

Plan de Gestión de Requisitos
Version <1.0>

Historial de Revisiones
Fecha Versión Descripción Autor
<dd/mmm/aaaa> <x.x> <detalles> <nombre>

Tabla de Contenidos
1. Introducción
1.1 Propósito
1.2 Alcance
1.3 Definiciones, Acrónimos, y Abreviaturas
1.4 Referencias
1.5 Descripción
2. Gestión de Requisitos
2.1 Organización, Responsabilidades, e Interfaces
2.1.1 Cliente
2.1.2 Usuario
2.1.3 Stakeholder
2.1.4 Gerente de Proyecto
2.1.5 Aseguramiento de la calidad (QA)
2.1.6 Desarrollador
2.1.7 Líder de Equipo
2.1.8 Gerente de Configuración
2.1.9 Especificador de Requisitos
2.2 Tabla de Contactos
2.3 Herramientas, Entorno, e Infraestructura
3. Artefactos de Requisitos
3.1 Descripción de Artefactos
3.1.1 Tipos de Documentos
3.1.2 Tipos de Requisitos
3.1.3 Atributos
3.1.4 Lista de Valores
3.2 Trazabilidad
3.2.1 Criterios de Trazabilidad para los Tipos de Requisitos
3.3 Reportes y Medidas
4. Gestión de Cambios de Requisitos
4.1 Proceso y aprobación de Solicitud de Cambios
4.1.1 Una solicitud de cambio, mejora o defecto es propuesto por un
stakeholder.
4.1.2 Impacto de cambios sobre artefactos, costos y cronogramas.
4.1.3 Asignación de responsables para la implementación de cambios.
4.1.4 Los cambios son incorporados en la construcción y pruebas.
4.1.5 Las solicitudes de cambio son validadas y cerradas.
4.1.6 Control de Cambios
4.1.7 Gerente de Control de Cambios [nombre, título, organización,
información de contacto]
4.1.8 Gerente de Proyecto [nombre, título, organización, información de
contacto]
4.1.9 Gerente de Configuración [nombre, título, organización, información
de contacto]
4.1.10 Stakeholders [nombre, título, organización, información de contacto]
4.1.11 Líneas base del Proyecto
4.2 Workflows y Actividades
4.2.1 Gestión de Solicitud de Requisitos
5. Hitos
5.1 Inicio
5.1.1 Criterios de Evaluación
5.1.2 Artefactos
5.2 Elaboración


5.2.2 Artefactos
5.3 Construcción
5.3.2 Artefactos
5.4 Transición
5.4.2 Artefactos
6. Entrenamiento y Recursos

Plan de Gestión de Requisitos

1. Introducción
Este documento describe los criterios que utiliza el proyecto para establecer
documentos de requisitos estándar, tipos de requisitos, atributos de requisito, y
trazabilidad. Se define una estrategia general para la gestión de requisitos y sirve
como un recurso para todas las personas que participan en este proyecto.
1.1. Propósito
El propósito de este plan es establecer y documentar un enfoque sistemático para capturar,
organizar y documentar los requisitos del sistema. Este plan también establece y mantiene un
acuerdo entre el cliente y el equipo del proyecto sobre las necesidades cambiantes del
sistema.
1.2. Alcance
Este plan proporciona la guía para la gestión del [nombre del proyecto]
1.3. Definiciones, Acrónimos, y Abreviaturas

Para el vocabulario común para este proyecto, por favor consulte el documento Glosario.
1.4. Referencias
[Esta sección proporciona una lista completa de todos los documentos referenciados
en otras partes del Plan de Gestión de Requisitos. Identificar cada documento por el
título, número de informe si procede, la fecha, y la organización de la edición.
Especifique las fuentes de las que las referencias se pueden obtener. Esta
información puede ser proporcionada por referencia a un apéndice o a otro
documento. La lista incluye dos libros recomendados y un white paper publicado por
Rational Software Corporation que se ocupan específicamente de gestión de
requisitos. También se refiere a Rational Unified Process.]
Kruchten, Philippe. 1999. The Rational Unified Process. Menlo Park, CA: Addison Wesley
Leffingwell, D. and Don Widrig. 2000. Managing Software Requirements. Menlo Park, CA:
Addison Wesley.
Spence, I. and L. Probasco. 1998. Traceability Strategies for Managing Requirements with
Use Cases. Cupertino, CA: Rational Software Corporation.
Rational Unified Process®, Version 2003 Copyright © 1987 – 2003. Rational Software
Corporation
1.5. Descripción
[Esta sección describe lo que el resto del Plan de Gestión de Requisitos contiene y
explica cómo está organizado el documento.]
Este documento contiene detalles específicos y estrategias para la gestión de los requisitos de
[nombre del proyecto]. El documento detalla cómo los requisitos están organizados y
administrados dentro de nuestro proyecto. También se describe cómo los requisitos son
identificados, atributos asignados, rastreados, y modificados.
El documento describe la gestión de los procesos de cambio de los requisitos. En él se

describen los flujos de trabajo y actividades relacionadas con el mantenimiento del control de
los requisitos de proyecto.

Se especifican los hitos que deben alcanzarse y las normas que deben ser respetadas de
manera que podamos garantizar y evaluar el cumplimiento de los requisitos que se
especifican.
2. Gestión de Requisitos
2.1. Organización, Responsabilidades, e Interfaces
[Describa quién va a ser responsable de realizar las diferentes actividades descritas
en los flujos de trabajo de requisitos. Funciones básicas se describen a continuación.
Si el proyecto incluye a muchos individuos que comparten roles, puede usar la tabla
de abajo para completar apropiadamente los nombres, roles e información de
contacto.]
2.1.1. Cliente
Una persona u organización, interna o externa a la organización de la producción, que asume
la responsabilidad financiera para el sistema. En un sistema grande puede que no sea el
usuario final. El cliente es el destinatario final del producto desarrollado y sus artefactos.
2.1.2. Usuario
Una persona quién usará el sistema desarrollado.
2.1.3. Stakeholder
Una persona u organización que es afectado por el resultado del sistema.
2.1.4. Gerente de Proyecto

El rol que toma las deciones del proyecto.
2.1.5. Aseguramiento de la Calidad (QA)

Tiene la responsabilidad de los informes de la gestión del proyecto y es responsable de
garantizar que las normas del proyecto sean correctas y verificables, seguido por todo el
personal del proyecto.
2.1.6. Desarrollador
Una persona responsable del desarrollo de los requisitos funcionales de acuerdo a las normas
y procedimientos del proyecto. Esto puede incluir la realización de actividades en cualquiera
de las disciplinas: requisitos, análisis y diseño, implementación y prueba.
2.1.7. Líder de equipo

El líder del equipo es el intermediario entre el gestor del proyecto y desarrolladores. El líder
del equipo es responsable de asegurar que una tarea sea asignada y monitoreada hasta su
finalización. El líder del equipo es responsable de garantizar que el personal siga las normas
de desarrollo del proyecto, y se adhieren a los programas del proyecto.
2.1.8. Gerente de Configuración

Es responsable de la creación de la estructura del producto en el sistema de Gestión del
Cambio, para la definición y la asignación de espacios de trabajo para los desarrolladores, y
para la integración.
2.1.9. Especificador de Requisitos

Es responsable de la descripción de uno o más casos de uso del sistema.

2.2. Tabla de Contactos

[Use este cuadro de referencia rápida para la información del contacto.]
Rol Nombre Título Organización Contacto
Cliente
Usuario
Stakeholder
Gestor de Proyecto
Aseguramiento de la
Calidad
Líder de equipo
Especificador de
Requisitos
Gerente de
Configuración
2.3. Herramientas, Entorno, e Infraestructura

[Describe el entorno de computación y herramientas de software para ser utilizados
en el cumplimiento de las funciones de gestión de requisitos a través del proyecto o
del ciclo de vida del producto.]
Herramienta Descripción Información Soporte Técnico Website

de Licencia
Rational Para gestión de support@rational.com www.rational.com

RequisitePro requisitos

3. Artefactos de los Requisitos

3.1. Descripción
[Describe los artefactos de requisitos (documentos, tipos de requisitos y atributos de
requisitos) y define como van a ser identificados, marcados y enumerados.]
3.1.1. Tipos de Documentos
[Esta tabla describe los tipos de documento por defecto incluido en esta plantilla, y
sus tipos requisito asociado por defecto. Usted debe agregar sus tipos de documentos
personalizados a esta tabla a medida que los crea.]
Tipo de Requisito por

Tipo de Documento Descripción
Defecto
Solicitudes de Solicitudes claves de Necesidades de

Stakeholder (SST) stakeholders Stakeholder (STRQ)
[Si usted utiliza una herramienta
de solicitud de la Gestión del
Cambio, tales como Rational
ClearQuest, a continuación, las
solicitudes de las partes
interesadas a menudo se
almacenan en esa herramienta y
no se dupliquen en la
herramienta de gestión de
requisitosf you use a Change
Request Management tool, such
as Rational ClearQuest, then
stakeholder requests are often
stored in that tool and not
duplicated in the requirements
management tool.]
Vision (VIS) Condiciones o capacidades de Característica (FEAT)

este lanzamiento del sistema.
Especificación de Elaboración y descripción de un Caso de Uso (UC)

Caso de Uso (ECU) caso de uso.
Glossary (GLS) Usado para capturar un Término del Glosario

vocabulario de uso común. (TERM)
Supplementary Describe los requisitos del Requisito Suplementario

Requirements sistema que no son fácilmente (SUPL)
Specification (SUP) capturados por los casos de uso.
Plan de Gestión de Este tipo de documento describe NINGUNO

Requisitos (PGR) los requisitos y estrategias
específicas para la gestión y el
desarrollo del proyecto.

3.1.2. Tipos de Requisitos

[Esta tabla describe los tipos de requisitos por defecto incluido in esta plantilla. Usted
debería agregar sus tipos requisitos personalizados a esta tabla a medida que los
crea.]
Tipo de Requisito Descripción Atributos
Necesidades de Una solicitud de cualquier Prioridad de Stakeholder, Origen

Stakeholder (STRQ) tipo por parte de un
stakeholder, por ejemplo
un cambio de requisito, un
requisito adicional un
defecto.
Característica (FEAT) Una servicio externamente Prioridad, Tipo, Estado, Dificultad,
observable proporcionado Estabilidad, Riesgo, Iteración
por el sistema que satisface Planeada, Iteración Actual, Origen,
las necesidades del Nombre de Contacto, Requisito de
usuario. mejora, Defecto, Obsoleto
Término del Glosario Un término usado como
(TERM) vocabulario común a un
proyecto.
Caso de Uso (UC) Una descripción del Propiedad, Prioridad, Estado,
comportamiento del Dificultad, Estabilidad, Riesgo, Afecta
sistema, en términos de a la arquitectura, Nombre de Contacto,
secuencias y acciones. Iteración Planeada, Iteración Actual,
Requisito de mejora, Defecto, Obsoleto
Requisito Una descripción de un Prioridad, Estado, Dificultad,
Suplementario requisito no funcional. Estabilidad, Riesgo, Requisito de
(SUPL) mejora, Defecto, Nombre de Contacto,
Obsoleto
3.1.3. Atributos
[Para cada tipo de requisito que ha identificado, defina una lista de atributos que se
utilizaran y explique brevemente lo que significan.
Usted puede describir los atributos y sus valores por cada tipo de requisito en
diferentes secciones.
A continuación se describen los atributos utilizados en los requisitos del proyecto.]

Descripción
Atributo [Describa los criterios para el establecimiento de valores de Tipo Lista de Valores Tipo de Requisito
atributos]
Este atributo es asignado por el Gerente del proyecto o el Alto

analista de negocio. Determina la importancia relativa a las
Prioridad List Medio FEAT, UC, SUPL
características de implementación. Permite manejar el
alcance del proyecto y determinar la prioridad de desarrollo. Bajo
Este atributo es asignado por el equipo de calidad mientras se Propuesto
evalúan las solicitudes de los stakeholders. Sus valores
pueden ser: Aprobado
Estado Propuesto a través de una solicitud de stakeholder List Incorporado FEAT, UC, SUPL
Aprobado por el Gerente del proyecto y/o Aseguramiento de
la Calidad
Incorporado para su ejecución
Validado
Validado por Aseguramiento de la Calidad
Asignado por el líder del equipo y describe el número de
Iteración Planeada Integer n/a FEAT, UC
iteraciones necesarios para terminar el requisito.
Describe la iteración actual del requisito, permitiendo tener
Iteración Actual Integer FEAT, UC
un seguimiento de acuerdo al calendario. n/a
Asignado por el equipo de desarrollo para especificar que un
requisito necesita más tiempo y recursos que otros, estimando
Alto
el número del equipo o de persona-semanas, líneas de código
requeridas o puntos de función. Este atributo es utilizado para
Dificultad manejar el alcance y determinar la complejidad de desarrollo. List FEAT, SUPL, UC
Sus valores pueden ser: Medio
Alto o muy difícil porque es probable que sea costoso en
términos de recursos o dinero
Medio o difícil pero puede ser realizado sin riesgos
Bajo
Bajo o fácil

Es asignado por el analista y equipo de desarrollo, y está

basado sobre la probabilidad que la característica pueda
cambiar o que la comprensión de que el equipo de proyecto Alto
cambie. Sus valores pueden ser:
Estabilidad Alto si el requisito no cambia List FEAT, SUPL, UC
Medio si el requisito puede cambiar, pero es lo Medio
suficientemente estable para iniciar el trabajo
Bajo si es muy probable el cambio del requisito, por lo que es
necesario realizar un estudio adicional para ser considerado
en el trabajo. Bajo
Cronograma-Alto
Cronograma -Medio
Especifica el nivel de ocurrencia de una amenaza sobre un Cronograma -Bajo

Riesgo List FEAT, SUPL, UC
requisito Tecnología-Alto
Tecnología -Medio
Tecnología -Bajo
Help Desk
Socios
Origen Utilizado para especificar quién solicitó el requisito. Debe ser List Competidores FEAT, STRQ
considerado junto con la prioridad.
Grandes Consumidores
Usuarios finales
Nombre de Contacto Nombre del contacto que especificó el requisito Text n/a FEAT, SUPL, UC
Requisito de mejora Usado para integrarse con ClearQuest Text n/a FEAT, SUPL, UC
Defecto Usado para integrarse con ClearQuest Text n/a FEAT, SUPL, UC

Funcional
Facilidad de Uso
Confiabilidad
Rendimiento
Soporte
Tipo Para especificar a qué tipo de requisito corresponde. List FEAT
Restricciones de
Diseño
Requisitos de
Implementación
Requisitos Físicos
Requisitos de Interfaz
Nombre
Breve Descripción
Flujo Básico
Sub flujo
Propiedad Específico a un caso de uso, utilizado para elaborar el texto List Flujo Alternativo UC
de un caso de uso
Requisito Especial
Pre-Condición
Post-Condición
Punto de Extensión

Obsoleto Para especificar si un requisito ya no será utilizado. List True/False FEAT, UC, SUPL
Afecta a la arquitectura Es asignado por el desarrollador para especificar si el List UC

True/False
requisito afecta o no a la arquitectura del sistema.
Alto
Prioridad para El nivel de prioridad que un stakeholder asigna a su
List Medio STRQ
Stakeholder necesidad.
Bajo

3.2. Trazabilidad
3.2.1. Criterios de Trazabilidad para Tipos de Requisitos
Stakeholder Request
Feature
Use Case Supplementary Requirement
[Para cada tipo de requisito que usted ha identificado, liste algunas reglas adicionales
o directrices que se aplican a los enlaces de trazabilidad. Describa las limitaciones
aplicables, tales como "todas las características aprobadas deben rastrear a uno o
más Casos de Uso o a uno o más Requisitos Suplementarios.”]
Tipo de Requisito Directrices Notas
Necesidad de Stakeholder (STRQ)
Característica (FEAT)
Case de Uso (UC)
Término de Glosario (TERM)
Requisito Suplementario (SUPL) .
3.2.2. Informes y Medidas
[Describa el contenido, formato y propósito de los informes y medidas de requisitos.

Use las plantillas de la tabla para describir los informes que usted genera usando
RequisitePro’s Requirements Metrics tool. Para más información revise RequisitePro
online help]
Descripciones de la Vista:
[Use esta sección para describir las vistas que has creado para tu proyecto]

Nombre de la Descripción Tipo de Atributos Rango de

vista de Requisito Valor del
trazabilidad Atributo
Características FEAT, STRQ n/a Not Traced

No Trazadas de
Necesidades de
Stakeholder
Requisitos SUPL, FEAT n/a Not Traced

Suplementarios
No Trazadas de
Características
Casos de Uso No UC, FEAT n/a Not Traced

Trazadas de
Características
Todas las FEAT todo todo

Características
Características FEAT, STRQ n/a todo

Trazadas de
Necesidades de
Stakeholder
Todos los TERM todo todo

Términos del
Glosario
Características FEAT, STRQ n/a suspect only

Impactadas por
Cambios de
Necesidades de
Stakeholder
Requisitos SUPL, FEAT n/a suspect only

Suplementarios
Impactados por
Cambios de
Características

Casos de Uso UC, FEAT n/a suspect only

Impactados por
Cambios de
Características
Todas las STRQ todo todo

Necesidades de
Stakeholder
Todos los SUPL todo todo

Requisitos
Suplementarios
Requisitos SUPL, FEAT n/a todo

Suplementarios
Trazados de
Características
Estudio de los UC nombre, breve nombre, breve

Casos de Uso descripción descripción
Casos de Uso UC, FEAT n/a todo

Trazados de
Características
4. Gestión de Cambio de Requisitos

4.1. Proceso de Solicitud de Cambios y Aprobación
[Describa el proceso por el cual los problemas y cambios son propuestos, revisados e
implantados. Esto debe incluir el proceso de negociación de los cambios de requisitos
con los clientes y cualquier proceso contractual, actividades y limitaciones.]
4.1.1. Una solicitud de cambio, mejora o defecto es propuesto por un stakeholder.
[Describa aquí.]
4.1.2. The CCB reviews impact on artifacts, costs, and schedule.
[Describa aquí.]
4.1.3. Responsibility for implementing changes is assigned to appropriate workers.
[Describa aquí.]
4.1.4. Changes are incorporated into a build and tested.
[Describa aquí.]
4.1.5. The change requests are validated and closed.
[Describa aquí.]
4.1.6. Change Control Board (CCB)
[Describa aquí.]

4.1.7. Change Control Manager [name, title, organization, contact information]

[Describa aquí.]
4.1.8. Project Manager [name, title, organization, contact information]
[Describa aquí.]
4.1.9. Configuration Manager [name, title, organization, contact information]
[Describa aquí.]
4.1.10. Stakeholders [name, title, organization, contact information]
[Describa aquí.]
4.1.11. Project Baselines
[Las líneas base proporcionan una norma oficial en la que se basa el trabajo
posterior y al que sólo se autorizan los cambios a realizar. Describa en qué puntos
durante el proyecto o líneas base del ciclo de vida del producto se han de establecer.
Las líneas bases más comunes se darían al final de la fase de inicio, elaboración,
construcción y transición. Las líneas base también podrían ser generados al final de
iteraciones en las diversas fases o incluso con más frecuencia.]
Iteración Rol Primario Descripción Plazo
4.2. Workflows y Actividades

[Describa los workflows y actividades.]
4.2.1. Gestión de Solicitudes de Cambio
Actividad Descripción Responsa- Estado de

bilidad Requisito
correspondiente
Submit CR Any stakeholder on the project can submit a Submitter Proposed

Change Request (CR). The Change Request is
logged into the Change Request Tracking System
(e.g., Rational ClearQuest) and is placed into the
CCB Review Queue, by setting the Change
Request State to Proposed.
Review CR The function of this activity is to review CCB Proposed

Proposed Change Requests. An initial review of
the contents of the Change Request is done in the
CCB Review meeting to determine if it is a valid
request. If so, then a determination is made if the
change is in or out of scope for the current
release(s), based on priority, schedule, resources,

level-of-effort, risk, severity and any other

relevant criteria as determined by the group.
Confirm If a Change Request is suspected of being a CCB Proposed

Duplicate Duplicate or Rejected as an invalid request (e.g., Delegate
or Reject operator error, not reproducible, the way it
works, etc.), a delegate of the CCB is assigned to
confirm the duplicate or rejected Change Request
and to gather more information from the
submitter, if necessary.
Update CR If more information is needed (More Info) to Submitter Proposed

evaluate a Change Request, or if a Change
Request is rejected at any point in the process
(e.g., confirmed as a Duplicate, Rejected, etc.),
the submitter is notified and may update the
Change Request with new information. The
updated Change Request is then re-proposed to
the CCB Review Queue for consideration of the
new data.
Assign & Once a Change Request is Opened, the Project Project Approved
Schedule Manager will then assign the work to the Manager
Work appropriate team member – depending on the
type of request (e.g., enhancement request,
defect, documentation change, test defect, etc.) –
and make any needed updates to the project
schedule.
Make The assigned team member performs the set of Assigned Incorporated
Changes activities defined within the appropriate section Team
of the process (e.g., requirements, analysis & Member
design, implementation, produce user-support
materials, design test, etc.) to make the changes
requested. These activities will include all normal
review and unit test activities as described within
the normal development process. The Change
Request will then be marked as Resolved.
Verify After the changes are Resolved by the assigned Tester Incorporated
Changes in team member (analyst, developer, tester, tech
Test Build writer, etc.), the changes are placed into a test
queue to be assigned to a tester and Verified in a
test build of the product.
Verify Once the resolved changes have been Verified in CCB Validated
Changes in a test build of the product, the Change Request is Delegate
Release placed into a release queue to be verified against (System
Build a release build of the product, produce release Integrator)
notes, etc. and Close the Change Request.

5. Hitos
5.1. Inicio
5.1.1. Criterios de Evaluación
[Especifique los criterios de evaluación]
5.1.2. Artefactos
Tareas/Artefactos Descripción Fecha de Inicio Fecha Final
[Describa
nuevas tareas y
artefactos aquí.]
5.2. Elaboración
5.2.2. Artefactos
[Describa
nuevas tareas y
artefactos aquí.]
5.3. Construcción
5.3.2. Artefactos
[Describa
nuevas tareas y
artefactos aquí.]

5.4. Transición
5.4.2. Artefactos
[Describa
nuevas tareas y
artefactos aquí.]
6. Entrenamiento y Recursos
[Describa las herramientas de software, personal y entrenamiento requerido
para implementar las actividades específicas de la Gestión de Requisitos.]

<Nombre del proyecto>

Visión
Versión 1.0

Historial de Revisiones

Visión
1. Introducción
Propósito
[Breve descripción del propósito del presente documento, como puede ser
servir de soporte a la especificación de las características software y de los
atributos de las mismas, por ejemplo. También reflejar si el sistema que se
modela está dividido en otros subsistemas o bien el propósito general de la
empresa]
Alcance
[Definición del alcance del presente documento, es decir, todo ámbito del que
recoge características o detalles]
Definiciones, Acrónimos, y Abreviaciones

RUP: Son las siglas de Rational Unified Process. Se trata de una metodología
para describir el proceso de desarrollo de software.
Referencias
- Glosario.
- Plan de desarrollo de software.
- RUP (Rational Unified Process).
- Diagrama de casos de uso.
2. Posicionamiento
Oportunidad de Negocio
[Ventajas que obtendrá la empresa al implantar el sistema informático]
Sentencia que define el problema
El problema de
afecta a
El impacto asociado es
una adecuada solución sería
Sentencia que define la posición del Producto
Para
Quienes
El nombre del producto
Que
No como
Nuestro producto

3. Descripción de Stakeholders (Participantes en el Proyecto) y Usuarios

[Para proveer de una forma efectiva productos y servicios que se ajusten a las
necesidades de los usuarios, es necesario identificar e involucrar a todos los
participantes en el proyecto como parte del proceso de modelado de requisitos.
También es necesario identificar a los usuarios del sistema y asegurarse de que el
conjunto de participantes en el proyecto los representa adecuadamente. Esta
sección muestra un perfil de los participantes y de los usuarios involucrados en el
proyecto, así como los problemas más importantes que éstos perciben para
enfocar la solución propuesta hacia ellos. No describe sus requisitos específicos
ya que éstos se capturan mediante otro artefacto. En lugar de esto proporciona la
justificación de por qué estos requisitos son necesarios.]
Resumen de Stakeholders
[Hay varios stakeholders con un interés en el desarrollo. Presente una lista de
estos stakeholders]
Nombre Descripción Responsabilidades
[Nombre del [Descripción breve [Resumen de las responsabilidades

Stakeholder] del Stakeholder] principales de los stakeholders
relacionadas con el sistema bajo
desarrollo. Por ejemplo, un
stakeholder:
- asegura que el sistema será
mantenible
- asegura que el producto tiene
demanda en el mercado
- monitorea el desarrollo del
proyecto
- aprueba los avances]
Resumen de Usuarios
Nombre Descripción Stakeholder
[Nombre de un [Descripción de Si el usuario no está directamente

usuario del responsabilidad representado en el negocio, identifique qué
sistema] es del usuario] stakeholders representa los intereses de este
usuario]
[Nombre de [Descripción de Si el usuario no está directamente
otro usuario del responsabilidad representado en el negocio, identifique qué
sistema] es del usuario] stakeholders representa los intereses de este
usuario]
Entorno de usuario
[Descripción del entorno de trabajo del usuario, características de los PC’s a
utilizar, sistemas operativos, etc.]

Perfil de los Stakeholders

[Describa cada stakeholder en el sistema rellenando la tabla siguiente para
cada stakeholder. Recuerde que los tipos de stakeholder pueden ser usuarios,
departamentos o diseñadores técnicos. Un perfil completo cubriría los temas
siguientes para cada tipo de stakeholder.]
3.4.1 <Nombre del Stakeholder>
Representante [nombre del stakeholder]

Descripción [Descripción breve del tipo de stakeholder]
Tipo [Califique la experticia o área de experticia del
stakeholder, sus conocimientos y grado de instrucción.
Puede ser un guru, experto, usuario, usuario casual,
etc.]
Responsabilidades [Lista de las principales responsabilidades de los
stakeholders en relación con el sistema, es decir,
teniendo en cuenta sus intereses en el sistema.]
Criterio de Éxito [¿Qué identifica como éxito en el proyecto para este
stakholder?]
Grado de [¿Cúales roles jugará este stakeholder dentro del
participación proceso?]
Comentarios [Cualquier comentario adicional]
Perfiles de Usuario
3.5.1 <Nombre de un usuario>
Representante [Nombre(s) de la persona que representa este usuario]

Descripción [Descripción breve del tipo de usuario]
Tipo [Califique la experticia o área de experticia del usuario,
sus conocimientos y grado de instrucción. Puede ser un
guru, experto, usuario, usuario casual, etc.]
Responsabilidades [Lista de las principales responsabilidades dl usuario en
relación con el sistema, es decir, teniendo en cuenta sus
intereses en el sistema.]
Criterio de Éxito [¿Qué identifica como éxito en el proyecto para este
usuario?]
Grado de [¿Cuáles roles jugará este usuario dentro del proceso?]
participación
Comentarios [Problemas que interfieren con el éxito y cualquier otra
información pertinente. Incluirían elementos que pueden
hacen el trabajo del usuario más fácil o más difícil.]

4. Descripción Global del Producto
4.1 Perspectiva del producto

[Ámbito de aplicación del sistema y expectativas del mismo]
4.2 Resumen de características

A continuación se mostrará un listado con los beneficios que obtendrá el cliente
a partir del producto:
Beneficio del cliente Características que lo apoyan
4.3 Suposiciones y dependencias

[Todas las suposiciones y dependencias deben ser definidas por el cliente]
4.4 Costo y precio

[El costo y precio del sistema con todas las características software son
decisión entre cliente y empresa de desarrollo software]
5. Características Globales del Producto
5.1 <Una característica principal de software>

[Descripción de una característica software, ámbito y propiedades de la misma]
5.2 <Otra característica principal de software>

[Descripción de una característica software, ámbito y propiedades de la misma]
5.2.1 <Una subcaracterística software>

[Descripción de una característica software que deriva de una
característica software jerárquicamente superior, ámbito y propiedades
de la misma]
6. Restricciones
[A definir por el cliente]
7. Precedencia y Prioridad
8. Otros Requisitos del Producto

Estándares Aplicables

Requisitos de Sistema
Requisitos de Desempeño
Requisitos de Entorno
9. Requisitos de Documentación
9.1 Manual de Usuario

9.2 Ayuda en Línea

9.3 Guías de Instalación, Configuración, y Fichero Léame

10. Atributos de Características
Número y
nombre de la Estado Beneficio Esfuerzo Riesgo Estabilidad Asignación
característica
Propuesta: [Personal
[A
[Sí / No] [Alto / asignado al
[A definir definir
5.1 <Una Aprobada: Medio / [A definir por desarrollo de
por el por el
característica> [Sí / No] Bajo] el cliente] esta
cliente] cliente]
Incorporada: característica]
[Sí / No]
[Sí / No] [Alto / [A asignado al
[A definir
5.2 <Otra Aprobada: Medio / definir [A definir por desarrollo de
por el
característica> [Sí / No] Bajo] por el el cliente] esta
cliente]
Incorporada: cliente] característica]
[Sí / No]
[A definir
5.2.1 <Una sub- Aprobada: Medio / definir [A definir por desarrollo de
por el
cliente]
[Sí / No]
[A definir
5.2.2 <Otra sub- Aprobada: Medio / definir [A definir por desarrollo de
por el
cliente]
[Sí / No]
[A definir
5.3 <Otra Aprobada: Medio / definir [A definir por desarrollo de
por el
cliente]
[Sí / No]

Galería de Arte
Especificación de Requisitos de Software
Versión 1.0

Historial de Versiones
<dd/mmm/yy> <x.x> <detalles> <nombre>

Especificación de Requisitos de Software

Esta sección contiene la descripción de los requisitos de software con nivel de detalle suficiente
para que los analistas y diseñadores definan el sistema para satisfacerlos y que los testadores
prueben que el sistema los satisface.
1. Funcionalidad
El sistema debe:
1.1. Asociados a los casos de uso del sistema.

1.6. Registrar las solicitudes de servicio de exposición
1.7. Registrar información del artista.
1.8. Registrar información de obras.
1.9. Elaborar el Documento de Rechazo de Pedido.
1.10. Registrar resultados de la evaluación artística.
1.11. Aprobar o rechazar obras artísticamente.
1.12. Elaborar el Documento de Rechazo de Obras.
1.13. Registrar resultados de la evaluación económica.
1.14. Registrar precio y ganancia de las obras.
1.15. Elaborar el Documento de Venta de Obras.
1.16. Elaborar reporte de solicitudes mensuales.
1.17. Elaborar reporte de obras rechazadas por la galería.
1.18. Elaborar reporte de obras en venta de la galería.
1.19. Registrar usuarios del sistema.
1.20. Registrar perfiles de usuarios del sistema.
1.21. Cambiar contraseña del usuario.
1.22. Realizar login al sistema.
1.23. Administrar copias de seguridad.
1.2. Asociados a aspectos generales.

1.2.1. Obligar al usuario a que el cambio de contraseña sea cada 60 días.
1.2.2. Incluir un mecanismo que permita su actualización automática sin la
intervención del usuario.
1.2.3. Mantener un registro de los errores. Para cada error el sistema debe registrar: el
código del error, una descripción del error, la fecha y la hora del error.
1.2.4. Permitir que los reportes sean exportados a Hoja de Cálculo con formato
Microsoft Excel 2000.
2. Usabilidad
2.1. El sistema permitirá a los usuarios el registro de la solicitud de servicio como
promedio en 30 segundos.
2.2. El sistema permitirá a los usuarios de la galería realizar búsquedas sin entrenamiento
previo.
2.3. El aspecto de la interfaz gráfica del sistema facilitará su empleo a usuarios con
conocimientos mínimos en informática sin entrenamiento especializado más allá del
uso de un web browser.
2.4. El sistema se ajustará a los estándares CUA (Common User Access) de IBM.
2.5. En caso de error del usuario el sistema informará claramente: el mensaje del error y la
solución.
2.6. El lenguaje empleado en la interfaz gráfica del sistema respetará los términos usados
en el negocio.

3. Confiabilidad
3.1. El sistema debe estar disponible 24x7x365 días al año.
3.2. El tiempo promedio entre fallas (MTBF) del sistema será de 30 días
3.3. La duración promedio de una reparación (MTTR) del sistema no debe ser mayor de
20 minutos.
3.4. El sistema estará disponible al 95 por ciento entre las 8:00 AM y las 6:00 PM.
3.5. El sistema cumplirá los procedimientos definidos en el reglamento de la Institución
(GA-2006JX).
4. Rendimiento
4.1. Durante el proceso de evaluación de las solicitudes de servicio el sistema permitirá el
acceso concurrente de 100 especialistas de arte y de ventas como promedio.
4.2. Durante el proceso de solicitud de servicio el sistema permitirá el acceso concurrente
de 70 anfitriones como promedio.
4.3. El sistema almacenará la información de hasta 5000 artistas y 40 000 obras de arte.
4.4. El tiempo de respuesta promedio del sistema para las operaciones involucradas en el
proceso de evaluación es de 5 segundos.
4.5. El 95 por ciento de las transacciones del sistema no deben exceder los 5 segundos.
4.6. El sistema debe soportar un promedio de 50 transacciones por minuto.
5. Soporte
5.1. El cliente Web del sistema soportará los navegadores Microsoft Internet Explorer 6.0
o superior y FireFox 1.5 o superior para Linux y para Windows.
5.2. El sistema será compatible con Windows 2000 profesional y Windows XP.
5.3. El sistema permitirá a un usuario su instalación sin entrenamiento previo.
5.4. El tiempo máximo para corregir una falla será una semana.
5.5. El sistema debe incluir un mecanismo que permita su actualización automática sin la
intervención del usuario.
6. Consideraciones de Diseño
6.1. El sistema debe alinearse con los sistemas de la Corporación y tener una disposición
acorde con la información mostrada en dichos sistemas.
6.2. El sistema debe operar en cualquier computador personal con procesador Pentium IV
o superior, 256 Mb de memoria RAM y disco duro de 20 Gb.
6.3. La tecnología a utilizar será ser J2EE sobre plataforma AS400El sistema deberá ser
compatible con la maquina virtual de java 1.1 o superior.
6.4. El sistema deberá tener Seguridad de encriptamiento sobre las imágenes
6.5. La arquitectura lógica deberá considerarse en tres capas.
6.6. El motor de base de datos deberá ser DB2 de IBM como principal y MySQL como
secundario.
7. Documentación de Usuario en Línea y Sistema de Ayuda
No aplica a este proyecto.
8. Componentes Adquiridos
9. Interfaces
9.1. Interfaces de Usuario
9.1.1. El diseño de la interfaz gráfica del sistema se alineará al estándar definido en la
empresa para las aplicaciones Web.

9.1.2. Las interfaces de usuario estarán basadas en un diseño web en el que predominará
los colores institucionales de ABC S.A., según la imagen adjunta.
9.1.3. El logotipo estará siempre presente en la parte superior izquierda de todas las
interfaces.
9.1.4. El tipo de letra general será verdana de tamaño general de 3 para web.
9.1.5. El ancho de la página se limita a un tamaño de pantalla de 640x480 píxel sin scroll
horizontal.
9.1.6. Las barras de scroll se activarán una vez que el texto sobrepase este límite.
9.1.7. En ancho de la pantalla deberá estar limitado a 600 píxel con un 20% de espacio
superior horizontal que ocupa todo el ancho de la pantalla para el logo en la parte
izquierda y sobre la derecha las opciones que se pudieran presentar. El 80% restante
corresponde al cuerpo de la pantalla.
Logo Título de página Opciones de menú de la
página
Cuerpo de la página
9.1.8. Los gráficos que se presenten en las interfaces, tendrán un peso no mayor a los 100 kb.
9.1.9. Los reportes mostrarán el logotipo y nombre de la empresa ABC S.A.
9.2. Interfaces de Hardware

9.3. Interfaces de Software

9.3.1. El sistema se conectará con el sistema existente WEBNews para recibir el contenido de
las noticias.
9.4. Interfaces de Comunicaciones

10. Licenciamiento
11. Requerimientos Legales, Copyright y Otros

12. Estándares Aplicables


Glosario
Abstracción
Características esenciales de una entidad que la distingue de otros tipos de entidades.
Define una frontera desde la perspectiva del observador.
AORE Aspect-Oriented Software Requirement

Ingeniería de requisitos orientada a aspectos, la cual provee un conjunto de enfoques
para gestionar intereses y requisitos transversales que podrían modularizarse para
luego componerlos con otros intereses.
API
Una API representa una interfaz de comunicación entre componentes de software. Se
trata del conjunto de llamadas a ciertas bibliotecas que ofrecen acceso a ciertos
servicios desde los procesos y representa un método para conseguir abstracción en la
programación, generalmente (aunque no necesariamente) entre los niveles o capas
inferiores y los superiores del software.
Artefacto
Pieza discreta de información que es utilizada o producida por un proceso de
desarrollo de software.
Aspecto
Módulo software que no puede ser encapsulado en un procedimiento. Los aspectos no
son unidades funcionales en las que se pueda dividir un sistema, sino propiedades
que afectan a la ejecución o semántica de los componentes. Son conocidos también
como intereses transversales.
Elemento
Constituyente atómico de un modelo.
Especificación
Descripción textual de la sintaxis y la semántica de un bloque de construcción
específico; descripción declarativa de lo que algo es o hace.
Estereotipo
Extensión del vocabulario de UML que permite crear nuevos bloques de construcción
derivados a partir de los existentes pero específicos a un problema concreto.
Framework
En el desarrollo de software es una estructura de soporte definida en la cual otro
proyecto de software puede ser organizado y desarrollado. Típicamente, puede incluir
soporte de programas, bibliotecas y un lenguaje interpretado entre otros software para
ayudar a desarrollar y unir los diferentes componentes de un proyecto.
Representa una arquitectura de software que modela las relaciones generales de las
entidades del dominio. Provee una estructura y una metodología de trabajo la cual
extiende o utiliza las aplicaciones del dominio.

Gestión de Requisitos
Actividad para gestionar los cambios en los requisitos del sistema. La gestión implica
el control de cambios y el impacto de los cambios.
Heurística
Capacidad de un sistema para realizar de forma inmediata innovaciones positivas para
sus fines. La capacidad heurística es un rasgo característico de los humanos, desde
cuyo punto de vista puede describirse como el arte y la ciencia del descubrimiento y de
la invención o de resolver problemas mediante la creatividad y el pensamiento lateral o
pensamiento divergente.
Ingeniería de Requisitos
Es un área de investigación que procura atacar un punto fundamental en el proceso,
que es la definición de lo que se quiere producir.
Intereses (concerns)
Todo aquello que resulta importante para una aplicación (requisitos, infraestructura,
código, etc.).
Ingeniería de Software
Rama de la ingeniería que aplica los principios de la ciencia de la computación y las
matemáticas para lograr soluciones costo-efectivas a los proyectos de desarrollo o
mantenimiento de software de calidad.
Notación
Sistema de signos convencionales que se adoptan para expresar un conjunto de
conceptos sobre el sistema de software por desarrollar.
OMG Object Management Group

Consorcio del cual forman parte las empresas más importantes que se dedican al
desarrollo de software.
Refinamiento
Relación que representa una especificación más completa de algo que ya ha sido
especificado a cierto nivel de detalle.
Requisito
Característica, propiedad o comportamiento deseado de un sistema.
RUP Rational Unified Process

Proceso Unificado de Rational, metodología del proceso de ingeniería de software que
proporciona un enfoque disciplinado para asignar tareas y responsabilidades dentro de
una organización del desarrollo.
Stakeholder
Persona, grupo u organización que tenga directa o indirecta participación en una
organización, ya que puede afectar o ser afectados por la organización de acciones,
objetivos y políticas. Actores claves en una organización de negocios incluyen los
acreedores, clientes, directores, empleados, gobierno (y sus organismos), los
propietarios (accionistas), los proveedores, los sindicatos y la comunidad en la que se
basa el negocio de sus recursos.

UML Unified Modeling Language

Lenguaje Unificado de Modelado, notación estándar para el modelado de sistemas
Software.
Validación de los requisitos

Proceso de confirmación, por parte de los usuarios o del cliente, de que los requisitos
especificados son válidos, consistentes, completos, etc.
Verificación de los requisitos

Proceso de comprobación de que los requisitos realmente cubren las necesidades del
cliente.
Vista
Proyección de un modelo, que se ve desde una perspectiva o un punto de vista dado,
y que omite entidades que no son relevantes desde esa perspectiva.

Administracion I - Cibertec 2011-I

Caricato da

Informazioni sul documento

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Administracion I - Cibertec 2011-I

Caricato da

Copyright:

Formati disponibili

Análisis y Diseño de

CARRERAS PROFESIONALES CIBERTEC

CIBERTEC CARRERAS PROFESIONALES

CARRERAS PROFESIONALES CIBERTEC

Análisis y Diseño de Sistemas II pertenece a la línea formativa y se dicta en la

El manual para el curso ha sido diseñado bajo la modalidad de unidades de

El curso es teórico - práctico: consiste en un taller de desarrollo de proyectos

CIBERTEC CARRERAS PROFESIONALES

Análisis y Diseño de Sistemas II

Análisis Orientado Ingeniería de

CARRERAS PROFESIONALES CIBERTEC

ANÁLISIS ORIENTADO A OBJETOS

LOGRO DE LA UNIDAD DE APRENDIZAJE

Al finalizar la primera unidad, el alumno modula la arquitectura de análisis que da

1. Análisis Orientado a Objetos.

1. Los alumnos crean la arquitectura de análisis a partir de un diagrama de casos

CIBERTEC CARRERAS PROFESIONALES

1. ANÁLISIS ORIENTADO A OBJETOS

Figura 1.1. Flujo de Trabajo de la disciplina Análisis y Diseño.

En la fase de Inicio, la disciplina de Análisis y Diseño se preocupa por establecer

CARRERAS PROFESIONALES CIBERTEC

En la parte inicial de la fase de Elaboración se enfoca el esfuerzo en crear una

Después de que los elementos iniciales son identificados, se refinan en

1.1. Artefactos del Análisis

Tabla 1.1. Artefactos del Análisis

CIBERTEC CARRERAS PROFESIONALES

La entidad es una clase utilizada para modelar

La realización de análisis de un caso de uso es

El diagrama de clases describe la estructura de

Diagrama de interacción que describe el

Diagrama de interacción que describe el

Tabla 1.1. Artefactos del Análisis (Continuación).

Durante el análisis, se identifica de manera continua nuevos paquetes del

Las actividades que se realizan en la etapa de análisis son:

Según Ivar Jacobson “El modelo de análisis es un nivel de diseño intermedio

CARRERAS PROFESIONALES CIBERTEC

la propiedad de ser temporal en el caso en que se planea su desarrollo. Su

A diferencia del Modelo de Casos de Uso que captura la funcionalidad del

El modelo de análisis contiene los siguientes artefactos:

1.1. Modelo de Casos de Uso Vs. Modelo de Análisis

CIBERTEC CARRERAS PROFESIONALES

Modelo de Casos de Uso Modelo de Análisis

El rol responsable de esta tarea es el Arquitecto de software. Esta tarea permite

El propósito del análisis de la arquitectura es esbozar el modelo de análisis y la

3.1. Pasos a realizar

El Análisis de la Arquitectura se realiza como sigue:

3.1.1. Identificación de paquetes de análisis

La descomposición del software en paquetes se establece cuando

CARRERAS PROFESIONALES CIBERTEC

de trabajo y del número y la complejidad de los diagramas, situación a

Debido a que los requisitos funcionales se capturan en la forma de

Entre las asignaciones adecuadas de casos de uso a un paquete en

Para identificar los paquetes se basa en lo siguiente:

Figura 1.2. Casos de Uso con relación de generalización

4. Los casos de uso relacionados mediante relaciones de

Figura 1.3. Casos de Uso con relación extend

CIBERTEC CARRERAS PROFESIONALES

5. Los casos de uso incluidos tienden a generar su propio

Figura 1.4. Casos de uso con relación include

3.1.2. Definición de dependencias entre paquetes de análisis

Figura 1.5. Características de los paquetes de análisis

Los paquetes identificados se organizarán en la Capa de Aplicación,

a) Capa Específica: Aquí se ubican los paquetes identificados con

b) Capa General: Aquí se ubican los paquetes reutilizables y los