Professional Documents
Culture Documents
Sistemas II – Teoría
Administración y Sistemas
2
Í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 6 : Casos Prácticos 59
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 12 : Casos Prácticos 131
TEMA 13 : Ingeniería de requisitos orientada a aspectos 133
TEMA 14 : Casos Prácticos 138
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
PRESENTACIÓN
RED DE CONTENIDOS
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
TEMARIO
ACTIVIDADES PROPUESTAS
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..
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.
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.
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
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.
3. ANÁLISIS DE LA ARQUITECTURA
<<include>>
Ejemplo:
Rango de tamaño
Volumen
Periodo de persistencia
Frecuencia de actualizados
Fiabilidad
ACTIVIDADES PROPUESTAS
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
Si desea saber más acerca de estos temas, puede consultar el siguiente libro.
UNIDAD DE
APRENDIZAJE
1
TEMA
TEMARIO
ACTIVIDADES PROPUESTAS
Análisis
de Casos
de Uso
Especificación
de 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.
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.
Ejemplo:
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.
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.
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.
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.
5. Filtrando el escenario
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.
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.2. Subflujos
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
Si desea saber más acerca de estos temas, puede consultar el siguiente libro.
UNIDAD DE
APRENDIZAJE
1
TEMA
CASO PRÁCTICO
TEMARIO
ACTIVIDADES PROPUESTAS
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.
3. Requisitos Especiales
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
UNIDAD DE
APRENDIZAJE
1
TEMA
ANÁLISIS DE CLASES
TEMARIO
1. Análisis de Clases.
2. Tarjetas CRC.
ACTIVIDADES PROPUESTAS
1. Los alumnos confeccionan las tarjetas CRC de las clases que participan en el
caso de uso especificado.
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.
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).
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.
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.
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.
7. Requisitos Especiales
1. Alta seguridad en el manejo de las claves y cuentas.
8. Prototipos
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.
ACTIVIDADES PROPUESTAS
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
2. Actores
Encargado de reservas
3. Flujo de Eventos
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.
6. Puntos de Extensión
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”.
7. Requisitos Especiales
1. Comunicación con SCC.
8. Prototipos
Resumen
Si desea saber más acerca de estos temas, puede consultar el siguiente enlace.
http://c2.com/doc/oopsla89/paper.html
UNIDAD DE
APRENDIZAJE
1
TEMA
MODELO CONCEPTUAL
TEMARIO
1. Modelo Conceptual.
ACTIVIDADES PROPUESTAS
1. MODELO CONCEPTUAL
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
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).
Ejemplos:
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.
Ejemplo:
b) Agregación Compuesta
Ejemplo:
• Tipos de Asociaciones:
o Asociación Binaria
o Asociación Ternaria
o Asociación Reflexiva
Recepcionista
registra
genera
Cliente Orden Servicio
• Multiplicidad
Item
Muchos
*
Item
1 a 40
1..40
Item
5 Exactamente 5
• Clases Asociativas
Ejemplo:
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.
ACTIVIDADES PROPUESTAS
1. A partir de la Especificación del Caso de Uso “Reservar pistas de juego”, de la
sesión anterior, confeccione el Modelo Conceptual.
Resumen
• 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).
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
UNIDAD DE
APRENDIZAJE
1
TEMA
CASO PRÁCTICO
TEMARIO
1. Casos Prácticos.
ACTIVIDADES PROPUESTAS
ACTIVIDADES PROPUESTAS
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
2. Actores
Personal de Admisión.
3. Flujo de Eventos
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.
6. Puntos de Extensión
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”.
7. Requisitos Especiales
Ninguno
8. Prototipos
UNIDAD DE
APRENDIZAJE
2
TEMA
INGENIERÍA DE REQUISITOS
TEMARIO
1. La Ingeniería de Requisitos
2. El proceso de Ingeniería de Requisitos
ACTIVIDADES PROPUESTAS
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.
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.
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.
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.
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:
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.
6
IEEE, Institute of Electrical and Electronics Engineers.
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%
É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
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
Problema
identificado
Análisis del problema y
especificación del cambio
Implementación
del cambio
Requisito
revisado
Figura 8.6. Gestión de cambios en los requisitos
ACTIVIDADES PROPUESTAS
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.
Resumen
Si desea saber más acerca de estos temas, puede consultar los siguientes libros.
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.
UNIDAD DE
APRENDIZAJE
2
TEMA
PIRÁMIDE DE REQUISITOS
TEMARIO
1. Pirámide de requisitos
2. Características de un buen requisito
3. Documentos de requisitos
ACTIVIDADES PROPUESTAS
1. Los alumnos clasifican los requisitos de una lista propuesta según las categorías
descritas en la pirámide de requisitos.
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.
Estos tipos de requisitos pueden ser presentados en la forma de una pirámide, tal
como se muestra en la Figura 9.1.
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
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
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.
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.
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.
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:
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:
La pregunta es, ¿qué número debe ser considerado "muchos" -10, 100,
1000?
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:
2.4. Correcto
Si un requisito contiene hechos, éstos deben ser ciertos. Por ejemplo, este
requisito no está escrito correctamente:
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:
2.7. Independiente
Para entender el requisito, no debería haber necesidad de conocer a ningún
otro requisito:
2.8. Atómico
El requisito debe contener un elemento de trazabilidad individual. Por
ejemplo:
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.
2.10. Abstracto
Los requisitos no deben contener información innecesaria de diseño e
implementación:
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:
REQ3: Para los usuarios en los EE.UU., las fechas se muestran en el formato
mm/dd/aaaa.
2.12. No redundante
Cada requisito debe ser expresado una sola vez y no debe solaparse con
otro requisito:
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:
ACTIVIDADES PROPUESTAS
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.
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”.
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.
Resumen
Los requisitos suplementarios son todos los requisitos que no pueden ser
expresados con casos de uso.
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
Si desea saber más acerca de estos temas, puede consultar el siguiente libro.
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
TEMARIO
ACTIVIDADES PROPUESTAS
Necesidades de Solicitudes de
Captura de requisitos
stakeholders stakeholders
1
En inglés es conocido como Requirements Management Plan (RMP).
1
En inglés Stakeholder Requests
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:
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).
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.
Reservar Habitación
1. Breve Descripció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.
6. Puntos de Extensión
1. En el paso 5, el sistema extiende al caso de uso Mantener Clientes – Flujo
básico “Agregar Cliente”.
7. Requisitos Especiales
Ninguno.
8. Prototipos
Interfaz RESERVA
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.
Paso Variable T1 T2 T3 T4 T5 T6
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.
Paso Variable T1 T2 T3 T4 T5 T6
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”.
Paso Variable T1 T2 T3 T4 T5 T6
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”
En las páginas que recogen los datos personales del usuario, habrá un
enlace a una página describiendo la política de privacidad.
ACTIVIDADES PROPUESTAS
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ó:
Resumen
Si desea saber más acerca de estos temas, puede consultar el siguiente libro.
UNIDAD DE
APRENDIZAJE
2
TEMA
11
TRAZABILIDAD DE REQUISITOS
TEMARIO
ACTIVIDADES PROPUESTAS
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.
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.
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.
ACTIVIDADES PROPUESTAS
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
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.
ACTIVIDADES PROPUESTAS
ACTIVIDADES PROPUESTAS
1. A partir de la especificación de caso de uso mostrada en la semana 4, realice seis
casos de prueba.
UNIDAD DE
APRENDIZAJE
2
TEMA
13
TEMARIO
ACTIVIDADES PROPUESTAS
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.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.
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.
Funcionalidad básica
(Base concerns)
Intereses
(Concerns)
Intereses transversales
(Crosscutting concerns)
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.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.
ACTIVIDADES PROPUESTAS
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.
Resumen
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.”
Si desea saber más acerca de estos temas, puede consultar los siguientes libros.
http://revista.eia.edu.co/articulos9/43-52%20(articulo%203).pdf
UNIDAD DE
APRENDIZAJE
2
TEMA
14
CASOS DE ESTUDIO
TEMARIO
1. Caso práctico.
ACTIVIDADES PROPUESTAS
ACTIVIDADES PROPUESTAS
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.
ANEXO
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
1.2. Alcance
Este plan proporciona la guía para la gestión del [nombre del proyecto]
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.
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.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.
Cliente
Usuario
Stakeholder
Gestor de Proyecto
Aseguramiento de la
Calidad
Líder de equipo
Especificador de
Requisitos
Gerente de
Configuración
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]
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
3.2. Trazabilidad
3.2.1. Criterios de Trazabilidad para Tipos de Requisitos
Stakeholder Request
Feature
[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.”]
Característica (FEAT)
Case de Uso (UC)
Término de Glosario (TERM)
[Use esta sección para describir las vistas que has creado para tu proyecto]
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.1. Criterios de Evaluación
[Especifique los criterios de evaluación]
5.2.2. Artefactos
Tareas/Artefactos Descripción Fecha de Inicio Fecha Final
[Describa
nuevas tareas y
artefactos aquí.]
5.3. Construcción
5.3.1. Criterios de Evaluación
[Especifique los criterios de evaluación]
5.3.2. Artefactos
Tareas/Artefactos Descripción Fecha de Inicio Fecha Final
[Describa
nuevas tareas y
artefactos aquí.]
5.4. Transición
5.4.1. Criterios de Evaluación
[Especifique los criterios de evaluación]
5.4.2. Artefactos
Tareas/Artefactos Descripción Fecha de Inicio Fecha Final
[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.]
Historial de Revisiones
Fecha Versión Descripción Autor
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]
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]
El problema de
afecta a
El impacto asociado es
Para
Quienes
Que
No como
Nuestro producto
Resumen de Stakeholders
[Hay varios stakeholders con un interés en el desarrollo. Presente una lista de
estos stakeholders]
Resumen de Usuarios
Entorno de usuario
[Descripción del entorno de trabajo del usuario, características de los PC’s a
utilizar, sistemas operativos, etc.]
Perfiles de Usuario
6. Restricciones
[A definir por el cliente]
7. Precedencia y Prioridad
[A definir por el cliente]
Estándares Aplicables
[A definir por el cliente]
Requisitos de Sistema
[A definir por el cliente]
Requisitos de Desempeño
[A definir por el cliente]
Requisitos de Entorno
[A definir por el cliente]
9. Requisitos de Documentación
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]
Propuesta: [Personal
[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]
Propuesta: [Personal
[Sí / No] [Alto / [A asignado al
[A definir
5.2.1 <Una sub- 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]
Propuesta: [Personal
[Sí / No] [Alto / [A asignado al
[A definir
5.2.2 <Otra sub- 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]
Propuesta: [Personal
[Sí / No] [Alto / [A asignado al
[A definir
5.3 <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]
Galería de Arte
Especificación de Requisitos de Software
Versión 1.0
Historial de Versiones
Fecha Versión Descripción Autor
<dd/mmm/yy> <x.x> <detalles> <nombre>
1. Funcionalidad
El sistema debe:
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
No aplica a este proyecto.
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.
10. Licenciamiento
No aplica a este proyecto.
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.
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.
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.
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.
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.