UNIVERSIDAD PRIVADA TELESUP
INGENIERร A DE REQUERIMIENTOS
Pรกgina 1
UNIVERSIDAD PRIVADA TELESUP ÍNDICE DE CONTENIDO I. PREFACIO II. DESARROLLO DE LOS CONTENIDOS UNIDAD DE APRENDIZAJE 1: INTRODUCCIÓN A LA INGENIERÍA DE REQUISITOS 1. Introducción a. Presentación y contextualización b. Competencia (logro) c. Capacidades d. Actitudes e. Ideas básicas y contenido 2. Desarrollo de los temas a. Tema 01: La Ingeniería de Requerimientos. b. Tema 02: Proceso de la ingeniería de requisitos. c. Tema 03: Proceso de la ingeniería de requisitos (continuación). d. Tema 04: Clasificación y captura de requisitos. 3. Lecturas recomendadas 4. Actividades 5. Autoevaluación 6. Resumen UNIDAD DE APRENDIZAJE 2: REQUERIMIENTOS - RUP 1. Introducción a. Presentación y contextualización b. Competencia (logro) c. Capacidades d. Actitudes e. Ideas básicas y contenido 2. Desarrollo de los temas a. Tema 01: Casos Prácticos para capturar los requisitos b. Tema 02: Métodos de Recolección de Información. c. Tema 03: Proceso Unificado de desarrollo. d. Tema 04: Modelado del Negocio 3. Lecturas recomendadas 4. Actividades 5. Autoevaluación 6. Resumen UNIDAD DE APRENDIZAJE 3: ANALISIS DE REQUERIMIENTOS 1. Introducción a. Presentación y contextualización b. Competencia (logro) c. Capacidades d. Actitudes e. Ideas básicas y contenido 2. Desarrollo de los temas a. Tema 01: Diagrama de Casos de Uso del sistema b. Tema 02: Modelo Conceptual c. Tema 03: Modelo de Análisis de Objetos d. Tema 04: Diagrama de secuencia 3. Lecturas recomendadas 4. Actividades 5. Autoevaluación 6. Resumen UNIDAD DE APRENDIZAJE 4: MODELO DE ANÁLISIS DE REQUERIMIENTOS AVANZADO 1. Introducción a. Presentación y contextualización b. Competencia c. Capacidades d. Actitudes e. Ideas básicas y contenido 2. Desarrollo de los temas a. Tema 01: Diagrama de colaboraciones b. Tema 02: Modelo lógico de clases. c. Tema 03: Modelo de diseño aplicado a los requerimientos. d. Tema 04: Diagrama de componentes y despliegue. 3. Lecturas recomendadas 4. Actividades 5. Autoevaluación 6. Resumen III. GLOSARIO IV. FUENTES DE INFORMACIÓN V. SOLUCIONARIO
INGENIERÍA DE REQUERIMIENTOS
03 04 -159 04 – 55 05 05 05 05 05 05 06-51 07 16 23 36 51 52 53 55 56-91 57 57 57 57 57 57 58-87 59 64 74 82 88 88 89 91 92-124 93 93 93 93 93 93 94-120 95 104 112 117 121 121 122 124 125-147 126 126 126 126 126 126 127128 133 138 143 147 148 148 151 152 154 156
Página 2
UNIVERSIDAD PRIVADA TELESUP PREFACIO
La asignatura de Ingeniería de Requerimientos, es de naturaleza teórico práctico y pertenece al área de formación profesional. La presente asignatura surge como un requerimiento del estudiante de Ingeniería de Sistemas para integrar la tecnología de la Ingeniería de Requerimientos Orientada a Objetos en el desarrollo e implementación de sistemas de información. Debido al creciente proceso de automatización de las organizaciones, se requiere de la disposición de herramientas y técnicas específicas orientadas al objeto para la construcción e implementación de sistemas de información y soporte fundamental para toma de decisiones de la alta dirección. El conocimiento de las metodologías de la Ingeniería de Requerimientos cumple un rol preponderante en la formación académica del estudiante de Ingeniería de Sistemas, pues los capacita en la comunicación eficaz con las empresas y clientes, entender sus necesidades y aportar las soluciones más adecuadas para cada caso. Comprende cuatro unidades de aprendizaje: I. Introducción a la ingeniería de requisitos. II Requerimientos - RUP. III. Análisis de Requerimientos. IV. Modelo de Análisis de Requerimientos Avanzado.
ESTRUCTURA DE LOS CONTENIDOS UNIDAD DE APRENDIZAJE I: INTRODUCCIÓN A LA INGENIERÍA DE REQUISITOS LA INGENIERÍA DE REQUERIMIENTOS
PROCESO DE LA INGENIERÍA DE REQUISITOS
PROCESO DE LA INGENIERÍA DE REQUISITOS CONTINUACIÓN
CLASIFICACIÓN Y CAPTURA DE REQUISITOS
UNIDAD DE APRENDIZAJE II: REQUERIMIENTOS - RUP CASOS PRACTICO PARA CAPTURAR LOS REQUISITOS
MÉTODOS DE RECOLECCIÓN DE INFORMACIÓN.
PROCESO UNIFICADO DE DESARROLLO.
MODELADO DEL NEGOCIO
UNIDAD DE APRENDIZAJE III: ANALISIS DE REQUERIMIENTOS DIAGRAMA DE CASOS DE USO DEL SISTEMA
MODELO CONCEPTUAL
MODELO DE ANÁLISIS DE OBJETOS
DIAGRAMA DE SECUENCIA
UNIDAD DE APRENDIZAJE IV: MODELO DE ANÁLISIS DE REQUERIMIENTOS AVANZADO DIAGRAMA DE COLABORACIONES
MODELO LÓGICO DE CLASES.
MODELO DE DISEÑO APLICADO A LOS REQUERIMIENTOS.
DIAGRAMA DE COMPONENTES Y DESPLIEGUE.
Al finalizar esta asignatura usted será capaz de "Conceptualizar y aplicar las técnicas y métodos de la ingeniería de requerimientos en base a las necesidades, especificaciones del cliente utilizando diferentes modelos del proceso unificado relacional en todo el ciclo de vida del software, diseñando modelos de análisis y modelo de objetos para capturar correctamente los requisitos del cliente”. INGENIERÍA DE REQUERIMIENTOS
Página 3
UNIVERSIDAD PRIVADA TELESUP
UNIDAD DE APRENDIZAJE
INTRODUCCIÓN A LA INGENIERÍA DE REQUISITOS
COMPETENCIA: Al finalizar esta unidad usted será capaz de “Analizar y reconocer la importancia de la ingeniería de requisitos en el desarrollo de sistemas de información organizacionales.” INGENIERÍA DE REQUERIMIENTOS
Página 4
UNIVERSIDAD PRIVADA TELESUP INTRODUCCIÓN
a)Presentación y contextualización El alumno desarrolla una actitud analítica y critica que le permita valorar la importancia la ingeniería de Requerimientos en el desarrollo de sistemas de información para la organización. Aprenderá los conceptos principales de la ingeniería de requisitos, y su relación con los sistemas de información. Se explica el proceso de la IR, con sus respectivas fases o etapas, en la cual aprenderá las actividades que debe llevar a cabo en cada una de ellas.
b)Competencia (Logro) Analiza y reconoce la importancia de la ingeniería de requisitos en el desarrollo de sistemas de información organizacionales.
c) Capacidades 1. Comprende los conceptos fundamentales de la ingeniería de requisitos. 2. Comprende la importancia del proceso de ingeniería de requisitos. 3. Entiende y aplica las actividades que tiene que tener cada una de las fases del proceso de ingeniería de requisitos. 4. Comprende, relaciona y clasifica los distintos tipos de requisitos.
d)Actitudes Desarrolla una actitud emprendedora mediante la toma de iniciativas, promoción de actividades y toma de decisiones en relación a la actividad asignada. Actúa con responsabilidad personal, al cumplir con los horarios establecidos y el respeto a las normas de convivencia. Cumple con la presentación de los trabajos encomendados de manera individual y en equipo, respetando la iniciativa y aportes de los integrantes. Desarrolla la creatividad, la innovación, la actitud emprendedora y el respeto a la honestidad intelectual.
e) Presentación de ideas básicas y contenido esenciales de la Unidad La Unidad de Aprendizaje 1: Introducción a la ingeniería de requisitos, comprende el desarrollo de los siguientes temas: TEMA 01: LA INGENIERÍA DE REQUERIMIENTOS TEMA 02: PROCESO DE LA INGENIERÍA DE REQUISITOS. TEMA 03: PROCESO DE LA INGENIERÍA DE REQUISITOS (CONTINUACIÓN). TEMA 04: CLASIFICACIÓN Y CAPTURA DE REQUISITOS. INGENIERÍA DE REQUERIMIENTOS
Página 5
UNIVERSIDAD PRIVADA TELESUP
TEMA La Ingeniería de Requerimientos
INGENIERÍA DE REQUERIMIENTOS
Página 6
UNIVERSIDAD PRIVADA TELESUP
DESARROLLO DE LOS TEMAS
Tema 1: La Ingeniería de Requerimientos INGENIERÍA DE REQUISITOS Un ejemplo: La base de la ingeniería de requisitos, radica en conocer cuáles son las necesidades, especificaciones y requerimientos del cliente, parece muy fácil llegar a cumplir este objetivo, no obstante el principal problema en el diseño de los sistemas de información, incluso el diseño de base de datos, es la mala especificación de los requerimientos del cliente, por la sencilla razón que muchas veces ni el cliente mismo sabe lo que necesita, en consecuencia la ingeniería de requisitos, es una rama de la ingeniería del software, que nos ayuda a entender al cliente y capturar mejor los requerimientos.
Me entendió Claro, si , si,… entiendo
En el prologo a un libro de Ralph Young sobre las prácticas efectivas en los requisitos, el autor de este libro escribió: Es tu peor pesadilla. Un cliente entra en tu oficina, se sienta, te mira directo a los ojos, y dice:”Yo sé que usted piensa que entiende lo que digo, pero lo que usted no entiende es que lo que digo no es realmente lo que quiero decir”.
INGENIERÍA DE REQUERIMIENTOS
Página 7
UNIVERSIDAD PRIVADA TELESUP
Esto sucede de manera invariable cuando el proyecto está avanzado, después de que
han
relativos
realizado al
tiempo
los
compromisos
de
entrega,
las
reputaciones están en juego y el dinero está en serio peligro.
Todos los que hemos trabajado en el negocio de los sistemas y el software por más de unos cuantos años hemos vivido esta pesadilla, y solo unos pocos de nosotros hemos aprendido a continuar aun con esta circunstancia.
Nosotros tenemos dificultades cuando tratamos de obtener requisitos de nuestros clientes. Tenemos problemas al comprender la información que adquirimos.
Permitimos que el cambio nos controle en lugar de establecer mecanismos para controlarlo.
Con frecuencia, registramos los requisitos de una manera desorganizada e invertimos muy poco tiempo en verificar lo que registramos.
En resumen, se falla al establecer un cimiento sólido para el sistema o software. Cada uno de estos problemas representa un reto. Cuando estos se combinan, la imagen es desalentadora incluso para los gerentes y profesionales del software más experimentados. Pero existen soluciones.
INGENIERÍA DE REQUERIMIENTOS
Página 8
UNIVERSIDAD PRIVADA TELESUP Para PRESSMAN, Roger S. La ingeniería de requisitos proporciona el mecanismo apropiado para entender:
o
Lo que el cliente quiere, analizar las necesidades.
o
Evaluar la factibilidad.
o
Negociar una solución razonable
o
Especificar la solución sin ambigüedades.
o
Validar la especificación
o
Administrar los requisitos conforme éstos se transforman en un sistema operacional.
El proceso de la ingeniería de requisitos se lleva a cabo a través de siete distintas funciones: Inicio, Obtención, Elaboración, Negociación, Especificación, Validación y Gestión.
Según F.P.Brooks dice:
Lo más difícil en la construcción de un sistema de software es decidir precisamente qué construir. No existe tarea con mayor capacidad de lesionar al sistema, cuando se hace mal. Ninguna otra tarea es tan difícil de rectificar a posteriori.
La evidencia empírica demuestra que: Los requisitos contienen demasiados errores Muchos de estos errores no se detectan al principio Muchos de estos errores podrían ser detectados al principio No detectar estos errores incrementará los costes (tiempo, dinero) de forma exponencial Además, los programadores obedecen los requisitos (cuando existen).
INGENIERÍA DE REQUERIMIENTOS
Página 9
UNIVERSIDAD PRIVADA TELESUP El no capturar los requisitos correctamente conlleva:
Como
mínimo
en
un
incremento de costos y La
posible
pérdida
del
proyecto,
A continuación se describe otras consecuencias, que es necesario analizarlas con detenimiento:
o
El sistema resultante no satisfará a los usuarios.
o
Se producirán desacuerdos entre usuarios y desarrolladores.
o
Puede ser imposible demostrar si el software cumple, o no, los requisitos.
o
Se gastará tiempo y dinero en construir el sistema equivocado
En cuanto a la cantidad de requisitos que tiene un sistema de información es variada, podemos hablar de sistemas con 10 requisitos o 30 requisitos, pero también podemos tener sistemas con cientos de requisitos, miles de requisitos, 5000 requisitos o más de 50000 requisitos.
En EEUU $250 mil millones de dólares en unos 175.000 proyectos aproximadamente, de ese conjunto la realidad es la siguiente:
– 31,1% (23%) son cancelados – 52,7% (49%) cuestan un 190% más de lo estimado – Un
16,2% (28%) será finalizado a tiempo y dentro del presupuesto, pero el
producto final poseerá (aprox.) la mitad de los requisitos iniciales. Fuente: http://www.standishgroup.com
Es alarmante prácticamente un porcentaje muy bajo de proyectos terminan a tiempo y dentro del presupuesto, pero no con todos los requisitos iniciales.
INGENIERÍA DE REQUERIMIENTOS
Página 10
UNIVERSIDAD PRIVADA TELESUP La crisis del software y los requisitos:
o
Boehm, 1975: 45% de los errores tienen su orígen en los requisitos y en el diseño preliminar.
o
DeMarco, 1984: 56% de los errores que tienen lugar en un proyecto Sw. Se deben a una mala Especificación de Requisitos.
o
Chaos Report: Los factores principales que conducen al fracaso en los proyectos Sw.
Falta de comunicación con los usuarios
Son:
Requisitos incompletos Cambios a los requisitos
Otras historias de terror relacionadas con la mala especificación en los requisitos de un software de computadora.
Uno de los estudios más conocidos es el del General Accounting Office
(GAO) de EEUU. Este estudio de 1979 reveló que 47% del dinero empleado en proyectos software se destinó a sistemas que no llegaron a utilizarse. Otro 29% se empleó en proyectos que no llegaron a finalizar. Otro 19% se empleó en software que tuvo que ser profundamente modificado tras su entrega. Finalmente, tan sólo un 2% del dinero se empleó en proyectos software que sí cumplieron con sus requisitos, pero se trataba de proyectos más bien pequeños o de poca envergadura. En 1981, Victor Basili encontró cerca de 88 errores en una ERS de 400
páginas para el proyecto “A-7E Operational Flight Program”. Esta ERS había sido escrita por un grupo de expertos en especificación de requisitos. Recientemente, la NASA ha sufrido varios accidentes espectaculares cuyo
origen se atribuye a problemas durante la definición de los requisitos.
INGENIERÍA DE REQUERIMIENTOS
Página 11
UNIVERSIDAD PRIVADA TELESUP Cuánto cuesta el solucionar errores en el proceso de software: Etapa
Coste de reparación
Requisitos
1-2
Diseño
5
Codificación
10
Pruebas unitarias
20
Pruebas sistema
50
En producción
200
Acumulación de los errores:
Problema
Especificación de Requisitos
Diseño
Implementación
Prueba
Especificación Correcta
Diseño Correcto
Especificación Incorrecta
Diseño Erróneo
Diseño basado en la Especificación Errónea
Programas Correctos
Programas Erróneos
Funciones Correctas
Errores Corregibles
Programas basados en un Diseño Erróneo
Errores Incorregibles
Prog. basados en la Especificación Errónea
Errores Ocultos
Como se observa, los errores cometidos en los requisitos son los más peligrosos, pues sus consecuencias contaminan todas las restantes fases del ciclo de vida.
INGENIERÍA DE REQUERIMIENTOS
Página 12
UNIVERSIDAD PRIVADA TELESUP ¿Qué podemos hacer?
o o
Tomar conciencia del problema. Estar a la defensiva. No conocemos todas las respuestas, pero conocemos muchas de las preguntas. Tenemos experiencia.
o
Podemos minimizar el impacto de los errores en los requisitos
o
Podemos tratar de organizar mejor las tareas relacionadas con los requisitos
o
Más recursos para la fase de requisitos.
Existen soluciones definitivas
o o
No se ha encontrado solución universalmente válida. Hay serias dudas acerca de si dicha solución existe:
Nos movemos en la frontera socio-técnica de los sistemas: borrosa, voluble e inconsistente.
Los requisitos es donde lo formal se encuentra con lo informal (M.Jackson).
Los
requisitos
están
vivos:
emergen,
interactúan,
cambian,
desaparecen.
o
Desconfíen de quien ofrezca la solución definitiva a estos problemas.
INGENIERÍA DE REQUERIMIENTOS
Página 13
UNIVERSIDAD PRIVADA TELESUP Ingeniería de Requisitos Para remediar en lo posible los problemas antes descritos surge la [ingeniería Patronesde derequisitos. pensamiento:
:La IR trata de los principios, métodos, técnicos y herramientas que permiten descubrir, documentar y mantener los requisitos para sistemas basados en computadoras, de forma sistemática y repetible.
¿Qué son los requisitos? Información acerca del problema a solucionar. [Patrones de pensamiento: Propiedades y comportamiento del sistema. Restricciones de diseño y fabricación del producto. : Descripciones acerca de cómo el futuro sistema ayudará a sus usuarios a realizar mejor sus tareas. Restricciones acerca de la tecnología que será utilizada en la construcción del sistema (protocolos, SSOO, COTS, etc.). Restricciones acerca de las propiedades emergentes del sistema (requisitos no funcionales).
INGENIERÍA DE REQUERIMIENTOS
Página 14
UNIVERSIDAD PRIVADA TELESUP
TEMA Proceso de la Ingeniería de Requisitos
INGENIERÍA DE REQUERIMIENTOS
Página 15
UNIVERSIDAD PRIVADA TELESUP
Tema
2:
Proceso
de
la
Ingeniería
de
Requerimientos ¿QUÉ ES UN PROCESO?
Conjunto de actividades o fases que cuando se asocian consiguen un producto y persiguen un objetivo o fin.
El señor Roger S. Pressman dijo: La
ingeniería
de
requisitos
proporciona
el
mecanismo apropiado para entender lo que el cliente quiere, analizar las necesidades, evaluar la factibilidad, negociar una solución razonable, especificar la solución sin ambigüedades, validar la especificación, y administrar los requisitos conforme éstos se transforman en un sistema operacional.
El proceso de la ingeniería de requisitos se lleva a cabo a través de siete distintas etapas o funciones del proceso:
Inicio
Obtención
ETAPAS O FUNCIONES DEL
Elaboración
Validación
Negociación
PROCESO
Especificación
Gestión
INGENIERÍA DE REQUERIMIENTOS
Página 16
UNIVERSIDAD PRIVADA TELESUP LA CAPTURA DE REQUISITOS ESTÁ DIVIDIDA EN 7 ETAPAS1. INICIO Inicio del proyecto, algunas veces se puede iniciar con una conversación, pero generalmente inicia con la identificación de necesidades del negocio. Por lo general, las semillas de los desastres o riesgos más importantes en software se siembran en los primeros tres meses desde el comienzo del proyecto. CAPERS JONES.
OBTENCIÓN Realmente parece muy fácil preguntarle al cliente, cuáles son sus necesidades, ámbito del proyecto o inclusive, el alineamiento que tiene con los objetivos estratégicos del negocio, pero muchas veces es complicado.
Los siguientes aspectos nos ayudarán a entender mejor porque es tan complicado:
Problemas de Ámbito Tamaño del proyecto mal definido o no tan claro, esto puede confundir al analista con requisitos innecesarios para los objetivos del negocio.
1
PRESSMAN, Roger S; INGENIERIA DE SOFTWARE
INGENIERÍA DE REQUERIMIENTOS
Página 17
UNIVERSIDAD PRIVADA TELESUP
Problemas de Comprensión Cuando los actores clave del negocio, los que usaran el sistema tienen poca comprensión de lo que necesitan, o simplemente no saben cómo comunicárselo al analista.
Problemas de Volatilidad
Los requerimientos planteados al inicio del proyecto cambian continuamente.
ELABORACIÓN Toda la información adquirida del cliente se plasma en un modelo. Es una acción del modelado del análisis, y se compone de una serie de tareas de modelado y refinamiento. La elaboración se conduce mediante la creación y el refinamiento de escenarios del usuario que describen la forma en que el usuario final (y otros actores) interactúan con el sistema. El resultado final de la elaboración es un modelo de análisis que define el dominio de la información, las funciones y el comportamiento del problema.
NEGOCIACIÓN Por lo general, el cliente siempre requiere más de lo que se pueda lograr en el tiempo planeado, el ingeniero
de
requisitos
tiene
que
negociar
realizando estimaciones y costos del proyecto.
INGENIERÍA DE REQUERIMIENTOS
Página 18
UNIVERSIDAD PRIVADA TELESUP ESPECIFICACIONES Una especificación puede ser un documento escrito, un
conjunto
de
modelos
gráficos,
un
modelo
matemático formal, una colección de escenarios de uso, un prototipo o cualquier combinación de estos. La especificación es el producto del trabajo final que genera la ingeniería de requisitos. Sirve como base para las actividades de la ingeniería de software siguientes. Describe la función y el desempeño de un sistema basado en computadoras y las restricciones que regirán su desarrollo. .
VALIDACIÓN Proceso que verifica si las especificaciones son correctas. Examina la especificación para asegurar que todos los requisitos de software se han establecido de manera precisa; que se han detectado las inconsistencias, omisiones y errores y que estos han sido corregidos, y que los productos de trabajo cumplen con los estándares establecido para el proceso, proyecto y producto.
GESTIÓN
Conjunto de actividades que ayudan al equipo de proyecto a identificar, controlar y rastrear los requisitos y los cambios a estos en cualquier momento mientras se desarrolla el proyecto.
Una vez identificados los requisitos se desarrollan las tablas de rastreabilidad. En las tablas se relaciona cada uno de los requisitos con aspectos específicos del software. INGENIERÍA DE REQUERIMIENTOS
Página 19
UNIVERSIDAD PRIVADA TELESUP Por ejemplo: En un sistema de comercialización ASPECTOS Modulo de Clientes
REQUISITOS
RF01:
Registro
de
Registro
de
clientes RF02:
Modulo de documentos
X X
proveedores RF03:
Modulo de proveedores
Registra
X
Registrar
X
Registrar
X
factura RF03: Boletas RF04:
Guías de remisión RF05:
Registrar
parámetros
del
X
X
X
software
Es preciso mencionar que la etapa de gestión debe utilizarse solamente en proyectos con cientos de requisitos.
NOTA: hay que tener en cuenta que las 7 etapas de la captura de requisitos, son lo mismo que las 7 actividades
Ya se explicó las 7 etapas del proceso de la ingeniería
de
requisitos,
entonces
según
los
explicado anteriormente llegamos a la siguiente afirmación. El proceso de Ingeniería de Requisitos es un conjunto estructurado de actividades que sirven para derivar, validar y mantener los requisitos de un sistema (hardware, software o hardware + software).
INGENIERÍA DE REQUERIMIENTOS
Página 20
UNIVERSIDAD PRIVADA TELESUP VARIACIONES EN EL PROCESO: Según la naturaleza del proyecto: Dirigido al mercado A medida
Según la naturaleza de la aplicación: Riesgo Recursos Incertidumbre
Por supuesto que el proceso variaría si se presentan situaciones como las anteriores, si los recursos son escasos, o los actores clave del negocio no ayudan con los requerimientos o existe una cierta incertidumbre, en los procesos del negocio.
Otros Problemas se Pueden Presentar Si: El proceso de requisitos es excesivamente largo y costoso. Los implicados en el proceso se quejan de falta de tiempo u otros recursos. Se reciben quejas acerca de la inteligibilidad del documento de requisitos. Los implementadores se quejan del trabajo perdido por culpa de errores en los requisitos. Los usuarios no utilizan muchas de las capacidades del sistema. En cuanto el producto se entrega, se recibe una inmensa cantidad de solicitudes de cambios. Lleva demasiado tiempo alcanzar un acuerdo cuando se proponen cambios a los requisitos. INGENIERÍA DE REQUERIMIENTOS
Página 21
UNIVERSIDAD PRIVADA TELESUP
TEMA Proceso De Ingeniería De Requisitos (Continuación)
INGENIERÍA DE REQUERIMIENTOS
Página 22
UNIVERSIDAD PRIVADA TELESUP
Tema 3: Proceso de ingeniería de requisitos (continuación) Otra forma de definir las etapas o actividades del proceso de software se representa en el siguiente gráfico: REQUISITOS
Puntos de Decisión
INFORMALES
Necesidades, Conocimiento del Dominio, Estimadores, Leyes, etc.
EDUCCIÓN DE
ANALISIS Y NEGOCIACIÓN DE
REQUISITOS
REQUISITOS
Documento de Requisitos e
Acuerdo acerca de los Requisitos
Informe de Validación
VALIDACIÓN DE
ESPECIFICACIÓN DE
REQUISITOS
REQUISITOS
BORRADOR DEL DOCUMENTO DE REQUISITOS
INGENIERÍA DE REQUERIMIENTOS
Página 23
UNIVERSIDAD PRIVADA TELESUP
En el dibujo, los cuadros redondeados son tareas
o
etapas.
Los
cuadrados
son
productos (inputs o outputs). En el resto de este material se explicará cada componente de este proceso.
La separación que aquí se ofrece es más conceptual que real. Las distintas tareas que se ejecutan durante el proceso de requisitos suceden en paralelo y se solapan unas con otras. Por ejemplo, durante un proceso de educción de requisitos empleando prototipado, es inevitable realizar una pequeña validación de los requisitos que se van obteniendo, o incluso una pequeña negociación, si estamos tratando con varios usuarios a la vez.
Ahora se describe con detalle cada una de las etapas del proceso de ingeniería de requisitos, las etapas son:
Educción de requisitos
Análisis y negociación de requisitos
Especificación de requisitos
Validación de requisitos
INGENIERÍA DE REQUERIMIENTOS
Página 24
UNIVERSIDAD PRIVADA TELESUP LA EDUCCIÓN DE REQUISITOS La educción de requisitos se refiere a la captura y descubrimiento de los requisitos. Es una actividad más “humana” que técnica. Se identifica a los interesados (stakeholders) y se establecen las primeras relaciones entre ellos y el equipo de desarrollo.
FUENTES DE REQUISITOS
Los requisitos pueden proceder de: Metas: Factores críticos de éxito (de la empresa) CONOCIMIENTO DEL DOMINIO DE LA APLICACIÓN Si el analista tiene experiencia en realizar sistemas para compañías de seguros, puede sugerir requisitos que no son obvios para los usuarios, o puede deducir mejor las consecuencias de los requisitos propuestos por los usuarios. Por ejemplo, un usuario quiere consultar por pantalla todas las pólizas que venzan durante el mes.
Para que ello sea posible, el software deberá obligar, cada vez que se crea una póliza, que
se
introduzca
su
fecha
de
vencimiento. Esto puede resultar obvio
a
Terminología: Los interesados: Los afectados sistema.
por
el
para un informático, pero no lo es tanto para un usuario inexperto.
El entorno organizacional: Los procesos de negocio.
INGENIERÍA DE REQUERIMIENTOS
Página 25
UNIVERSIDAD PRIVADA TELESUP PROBLEMAS DE LA EDUCCIÓN Entre ellos tenemos:
Los usuarios no pueden/saben describir muchas de sus tareas Mucha información importante no llega a verbalizarse A veces hay que “inventar” los requisitos sistemas orientados a miles de usuarios: web, mercado La educción no debería ser un proceso pasivo, sino cooperativo
HACER PREGUNTAS NO ES SUFICIENTE Ejemplo: “Diseñar un medio de transporte”
Diseñador: ¿para cuándo? • Cliente: 18 meses Diseñador: ¿qué hay que transportar? • Cliente: personas Diseñador: ¿Cuántas personas a la vez? • Cliente: Una Diseñador: ¿Qué clase de energía lo mueve? • Cliente: El pasajero Diseñador: ¿sobre qué clase de superficie? • Cliente: Una superficie plana y dura
• Diseñador: ¿Cuál es la distancia máxima a recorrer? Cliente: Unos 2 km. • Diseñador: ¿Cuál es el coste? Cliente: Unos 300 soles cada vez que se use. Etc. Finalmente: se fabrica un triciclo.
INGENIERÍA DE REQUERIMIENTOS
Página 26
UNIVERSIDAD PRIVADA TELESUP El Cliente (alcalde de Cusco): destaca su gran portabilidad (?). Dice: “Es muy portable pero ¿cómo se utiliza cuando llegue el momento de rescatar a un alpinista? Dice: “Lo que quería era un dispositivo que ayude a rescatar alpinistas”.
Entonces
lo
que
necesitamos
es
aprender algunas técnicas para poder registrar correctamente los requisitos del cliente, ahora veremos algunas técnicas de educción.
TÉCNICAS DE EDUCCIÓN Entre ellas tenemos: Preliminares:
Requisitos en contexto de uso
Utilizar preguntas libres de contexto Brainstorming o lluvia de ideas
Prototipado:
Creatividad?
Útiles cuando la incertidumbre es total
Entrevistas:
acerca del futuro sistema. Hay dos tipos
Es el método “tradicional”
principales:
Observación análisis de tareas
y
– Evolutivo
Casos de uso / – De usar y tirar (prototipos en papel, Escenarios:
INGENIERÍA DE REQUERIMIENTOS
mago de Oz, etc.)
Página 27
UNIVERSIDAD PRIVADA TELESUP ANÁLISIS DE REQUISITOS Y NEGOCIACIÓN DE REQUISITOS
El objetivo es describir el funcionamiento y el comportamiento del sistema, el modelo cambia en forma dinámica conforme los ingenieros del software aprenden más acerca del sistema que se va a construir y los clientes entienden mejor lo que necesitan.
Consiste en detectar y resolver conflictos entre requisitos
Se precisan los límites del sistema y la interacción con su entorno Se trasladan los requisitos de usuario a requisitos del software (implementables). Se realizan tres tareas fundamentales: Clasificación Modelización Negociación
CLASIFICACIÓN DE LOS REQUISITOS En el análisis de requisitos, éstos se clasifican En funcionales vs. no funcionales (Capacidades vs. Restricciones) Por prioridades Por coste de implementación Por niveles (alto nivel, bajo nivel) Según su volatilidad/estabilidad Si son requisitos sobre el proceso o sobre el producto
INGENIERÍA DE REQUERIMIENTOS
Página 28
UNIVERSIDAD PRIVADA TELESUP
MODELIZACIÓN CONCEPTUAL Ciertos aspectos de los requisitos se expresan mediante modelos de datos, de control, de estados, de interacción, de objetos, etc. La meta es entender mejor el problema, más que iniciar el diseño de la solución (idealmente) El tipo de modelo elegido depende de: La naturaleza del problema La experiencia del modelizador La disponibilidad de herramientas Por decreto. El cliente impone una notación
Muy Importante: Tradicionalmente se entendía que “el análisis” se reducía a modelizar (DFDs, modelos de objetos, etc), pero el análisis de requisitos NO es exclusivamente un proceso de modelización, como ya se ha dicho. Por otro lado, no existe “la mejor” forma de modelizar requisitos. En realidad, no hay evidencia empírica que demuestre, en general, la superioridad de unas notaciones de modelización frente a otras.
NEGOCIACIÓN DE REQUISITOS
En todo proceso de IR intervienen distintos individuos con distintos cargos, necesidades y, a veces, enfrentados intereses Estos conflictos entre requisitos se descubren durante el análisis. Todo conflicto descubierto debería disparar un proceso de (re)negociación. Los conflictos NUNCA se deben resolver “por decreto”.
INGENIERÍA DE REQUERIMIENTOS
Página 29
UNIVERSIDAD PRIVADA TELESUP Por ejemplo: Distintos individuos de distintos departamentos pueden desear requisitos conflictivos entre sí, o conflictivos con los objetivos globales del sistema o de la organización. Incluso a veces, detrás de un requisito ambiguo lo que hay, en realidad, es un conflicto no resuelto.
Es
durante el análisis cuando muchos de los conflictos entre requisitos
son
descubiertos.
EL
CONFLICTO
NO
ES
RECHAZABLE y no debe resolverse por decreto, sino mediante un proceso de negociación. Desde este punto de vista, los conflictos son positivos, pues SON FUENTE DE NUEVOS REQUISITOS.
Los
acuerdos
alcanzados
deben
ser
convenientemente anotados, favoreciéndose así la trazabilidad de requisitos a sus orígenes (“el requisito 987 surge como resultado de
los
reunión entre x, y z el día tal del tal...”).
la
Existe, incluso, un subcampo de la IR dedicada a este tipo de temas: la IR orientada a Puntos de Vista o “Viewpoint-Based Requirements Engineering”.
ESPECIFICACIÓN DE REQUISITOS Se fija una descripción detallada y precisa de los requisitos del sistema, de tal forma que sirva de base para un contrato entre el cliente y el desarrollador de software, el objetivo es obtener la especificación de requisitos del sistema, se puede utilizar distintos lenguajes especificar los requisitos.
o Lenguaje natural: o Lenguaje de especificación de requisitos o Lenguaje de descripción de diseño o Notaciones gráficas
EL DOCUMENTO DE REQUISITOS Es el modo habitual de guardar y comunicar requisitos. Es buena práctica utilizar, al menos, dos documentos, a distinto nivel de detalle DRU = Documento de Requisitos de Usuario (en inglés, URD)
INGENIERÍA DE REQUERIMIENTOS
Página 30
UNIVERSIDAD PRIVADA TELESUP ERS = Especificación de Requisitos Software (en inglés, SRS)
OJO: Con “Documento” nos referimos a cualquier medio electrónico de almacenamiento y distribución: Procesador de textos Base de Datos Herramienta de Gestión de Requisitos
La pregunta que surge es ¿en qué se diferencian los “requisitos de usuario” de los “requisitos del software”? A grandes rasgos se puede afirmar que:
El DRU se escribe desde el punto de vista del usuario/cliente/interesado. Normalmente los requisitos de usuario, contenidos en la DRU, no poseen demasiado nivel de detalle. Se incluye la descripción del problema actual (razones por las que el sistema de trabajo actual es insatisfactorio) y las metas que se espera lograr con la construcción del nuevo sistema.
La ERS desarrolla mucho más los contenidos de la DRU. Los requisitos del software contenidos en la ERS son, por tanto, más detallados. Contiene la respuesta a la pregunta ¿Qué características debe poseer un sistema que nos permita alcanzar los objetivos, y evitar los problemas, expuestos en la DRU?
INGENIERÍA DE REQUERIMIENTOS
Página 31
UNIVERSIDAD PRIVADA TELESUP
OJO: La diferencia entre la DRU y la ERS NO es que la DRU emplee lenguaje natural y la ERS emplee modelos o notaciones formales. Tanto la DRU como la ERS pueden utilizar todo tipo de notaciones. La diferencia entre ambos documentos es más de nivel de detalle.
VALIDACIÓN DE REQUISITOS
Objetivo: Descubrir
problemas
en
el
Documento
de
Requisitos antes de comprometer recursos a su implementación. Resultados: se produce una línea-base (baseline)
El documento debe revisarse para: Descubrir omisiones Conflictos Ambigüedades Comprobar la calidad del documento y su grado de adhesión a estándares.
Línea base
En el contexto de la Ingeniería de Requisitos, una línea base es un conjunto de requisitos que han sido formalmente aceptados por todas las personas implicadas en el proyecto. Una vez que se establece una línea base, futuros cambios a tales requisitos sólo podrán realizarse por medio de un proceso formal de gestión y aprobación de cambios. INGENIERÍA DE REQUERIMIENTOS
Página 32
UNIVERSIDAD PRIVADA TELESUP Cada organización, según su experiencia y según el dominio de las aplicaciones que desarrolle, debería desarrollar su lista de comprobación o “checklist” particular.
REVISIONES (REVIEWS)
o
Es la fórmula más empleada para validación
o
Un grupo de personas (incluyendo usuarios) se ocupan de revisar el documento de requisitos.
o
Tres fases: Búsqueda de problemas Reunión Acuerdos.
o
Como guía para identificar problemas habituales, se pueden utilizar listas de comprobación (“checklists”).
o
Hay “checklists” adaptadas a distintos tipos de sistemas.
El 33% de los errores de requisitos en la especificación del sistema A-7E fueron detectados mediante revisión manual. El resto se descubrieron en posteriores fases, con el consiguiente incremento en el coste.
Curiosamente, las revisiones parecen funcionar también con el código ejecutable:
Se descubren más errores inspeccionando el código fuente que ejecutando el programa. ¿Radica aquí el éxito de los desarrollos Open Source?
Cada organización, según su experiencia y según el dominio de las aplicaciones que desarrolle, debería desarrollar su lista de comprobación o “checklist” particular.
INGENIERÍA DE REQUERIMIENTOS
Página 33
UNIVERSIDAD PRIVADA TELESUP
Un ejemplo de cuestiones que deberían figurar en una lista de comprobación podría ser esta:
¿Están
todos
los
requisitos
convenientemente numerados?
¿El mismo servicio es solicitado en distintos requisitos? ¿Existen contradicciones entre ellos?
¿Los requisitos relacionados se encuentran agrupados en el documento?
¿Los
requisitos
son
fácilmente
comprensibles? ¿Por todo tipo de lectores?
En general, una lista de comprobación debería girar alrededor de los 24 atributos de calidad que debería poseer una ERS. Para cada atributo de calidad, se pueden plantear una serie de cuestiones que sirvan para confeccionar la lista de comprobación.
Para Analizar: Para la ingeniería de requisitos, se definen dos procesos, el primero consta de 7 etapas que son: Inicio, obtención, elaboración, negociación, especificación, validación y gestión. En el segundo se consideran 4 etapas: Educción de requisitos, Análisis y negociación de requisitos, Especificación de requisitos y validación de requisitos. Cualquiera de los dos procesos se puede usar, si los comparan es prácticamente lo mismo, con algunas diferencias menores, por ejemplo: La etapa de inicio y obtención, es semejante a la de educción de requisitos, la etapa de elaboración y negociación es semejante a la etapa de Análisis y negociación de requisitos, por último la etapa de validación es semejante a la etapa de validación de requisitos, la etapa de gestión se le recuerda que solamente se utiliza en proyectos grandes con cientos de requisitos, y es la única que no se menciona, por la sencilla razón de encontrarse en todas las demás etapas, y consiste básicamente en gestionar los cambios de los requisitos. INGENIERÍA DE REQUERIMIENTOS
Página 34
UNIVERSIDAD PRIVADA TELESUP
TEMA Clasificaciรณn y Captura de Requisitos
campus.utelesup.com
INGENIERร A DE REQUERIMIENTOS
Pรกgina 35
UNIVERSIDAD PRIVADA TELESUP
Tema 4: Clasificación y Captura de requisitos DEFINICIÓN DE REQUISITOS: Descripción de los servicios que tendrá que proporcionar el sistema y de sus restricciones operativas. Reflejan además las necesidades de los clientes y usuarios de un sistema para que ayude a resolver algún problema (como el control de un dispositivo, hacer un pedido o encontrar determinado información).
Extremos en la definición de Requisitos:
En algunos casos, un
requisito
simplemente
es
En otros casos, es
una
una
descripción
declaración
formal y detallada
abstracta de alto
de una función del
nivel
sistema.
de
un
servicio que debe proporcionar sistema
o
el una
restricción de éste.
Estas diferencias dan como resultado una gran cantidad de problemas cuando se definen los requisitos.
Por
ellos
hay
que
intentar
diferenciarlos.
INGENIERÍA DE REQUERIMIENTOS
Página 36
UNIVERSIDAD PRIVADA TELESUP Diferenciar los requisitos en función del grado de detalle en la descripción de los mismos:
Requisitos de usuario/cliente: Declaraciones en lenguaje natural y en diagramas de los servicios que se espera que el sistema proporcione y de las restricciones bajo las cuales debe operar.
Requisitos de sistema/software Descripción detallada de las funciones, servicios y restricciones del sistema. El documento de requisitos del sistema/software (a veces llamado especificación funcional) debe ser preciso. Debe definir exactamente QUÉ es lo que se va a implementar. Puede ser parte del contrato entre el cliente y los desarrolladores.
CLASIFICACIÓN DE REQUISITOS Requisitos Funcionales Declaraciones de los servicios que debe proporcionar el sistema. En algunos casos, estos requisitos pueden declarar explícitamente lo que el sistema NO debe hacer.
Requisitos No Funcionales Requisitos que no se refieren directamente a las funciones específicas del sistema sino a las propiedades emergentes de éste como la fiabilidad, rendimiento, tiempo de respuesta, capacidad de almacenamiento, etc. Además
también
no
tienen
por
qué
referirse,
exclusivamente, al sistema a desarrollar, sino a técnicas a seguir como estándares de calidad, uso de una herramienta CASE concreta o la descripción del modelo de proceso de desarrollo a seguir. Ejemplo . INGENIERÍA DE REQUERIMIENTOS
Página 37
UNIVERSIDAD PRIVADA TELESUP Requisitos funcionales: El teléfono móvil permitirá crear nuevos contactos y almacenarlos en la agenda (Contactos).
Requisitos no funcionales: La pantalla del teléfono móvil será táctil. Veamos ahora un cuadro de requerimientos funcionales:
REQUISITOS DEL USUARIO
Deben describir los requisitos funcionales y no funcionales de tal forma que sean comprensibles para los usuarios, sin conocimiento técnico detallado.
No se debe utilizar una jerga técnica. Deben redactarse en un lenguaje sencillo, utilizando tablas y formularios sencillos y diagramas intuitivos.
INGENIERÍA DE REQUERIMIENTOS
Página 38
UNIVERSIDAD PRIVADA TELESUP PROBLEMAS QUE SUELEN SURGIR:
Falta de claridad: Es difícil utilizar un lenguaje sencillo de forma precisa y no ambigua sin hacer el documento poco conciso y difícil de leer.
Confusión de requisitos:
No se distinguen claramente los requisitos funcionales de los no funcionales, las metas del sistema y la información para el diseño.
Conjunción de requisitos: A veces se expresan diferentes requisitos de forma conjunta en un único requisito
RECOMENDACIONES PARA MINIMIZAR MALENTENDIDOS
Formato estándar para todos los requisitos.
Utilizar el lenguaje de forma consistente para distinguir entre los
requisitos
obligatorios
de los
Evitar el uso de
deseables.
Los
jerga informática
obligatorios
se
redactan en futuro simple Resaltar el texto para distinguir las
cuestiones
claves
del
deseables
y
los en
condicional.
requisito.
INGENIERÍA DE REQUERIMIENTOS
Página 39
UNIVERSIDAD PRIVADA TELESUP
REQUISITOS DEL SISTEMA
Son versiones extendidas de los requisitos de usuario para los ingenieros software.
Agregan detalle y deben especificar cómo el sistema debe proporcionar los requisitos para satisfacer los requisitos de usuario.
Debe
ser
una
especificación
completa
y
consistente del sistema completo.
Evitar el uso exclusivo del lenguaje natural porque puede ser confuso y dar lugar a malentendidos que se detectan en las últimas fases del ciclo de desarrollo.
IMPORTANTE Las 5 actividades siguientes, no son más que las etapas del proceso requisitos,
de el
ingeniería objetivo
de
de
la
siguiente explicación es detallar mejor cada una de las etapas en base a preguntas clave que se necesitan para captura mejor los requisitos del cliente. Es preciso mencionar que se ha agregado una etapa, gestión, para controlar
los
cambios
en
el
proceso de captura de requisitos.
INGENIERÍA DE REQUERIMIENTOS
Página 40
UNIVERSIDAD PRIVADA TELESUP Ahora se captura los requisitos utilizando 5 actividades según BOOCH, Grady que es otra manera de cómo se puede realizar los procesos de captura de requerimientos a diferencia de PRESSMAN:
EDUCCIÓN DE REQUISITOS ANALISIS Y NEGOCICACIÓN DE REQUISITOS ESPECIFICACIÓN DE REQUISITOS VALIDACIÓN DE REQUISITOS GESTIÓN
1. EDUCCIÓN DE LOS REQUISITOS En el tema anterior en esta etapa se definió como aquella que permite la captura y descubrimiento de los requisitos y identificar a los actores clave del negocio, ahora bien, a continuación se describe el ¿Cómo hacerlo?. Solo para recordar en esta actividad se definen las verdaderas actividades del negocio.
Antes de describir qué pasos deben cumplirse en esta actividad, debemos tener una definición clara del término “Problema”. “Un problema puede ser definido como la diferencia entre las cosas como se perciben y las cosas como se desean”. Aquí vemos nuevamente la importancia que tiene una buena comunicación entre desarrolladores y clientes; de esta comunicación con el cliente depende que entendamos sus necesidades.
INGENIERÍA DE REQUERIMIENTOS
Página 41
UNIVERSIDAD PRIVADA TELESUP
A través de la definición de problema, podemos ver entonces que la actividad de “Análisis del Problema” tiene por objetivo que se comprendan los problemas del negocio, se evalúen las necesidades iniciales de todos los involucrados en el proyecto y que se proponga una solución de alto nivel para resolverlo. Durante el análisis del problema, se realizan una serie de pasos para garantizar un acuerdo entre los involucrados, basados en los problemas reales del negocio.
Estos pasos son los siguientes: Comprender el problema que se está resolviendo: Es importante determinar quién tiene el problema realmente, considerar dicho problema desde una variedad de perspectivas y explorar muchas soluciones desde diferentes puntos de vista. Veamos la siguiente necesidad: “El cliente se queja mucho por la enorme fila que debe formar para realizar una transacción bancaria”.
Perspectiva del cliente = Pérdida de tiempo Perspectiva del banco = Posibles pérdidas de clientes
Posibles soluciones pueden ser, determinar por qué demoran los cajeros, colocar una nueva caja (implica contratación de nuevos cajeros), abrir una nueva sucursal (involucra personal nuevo y estudio de mercado), realizar transacciones por otros medios (teléfono, internet, mediante cajeros automáticos, autobancos, etc).
Como puede verse, múltiples soluciones aplican para el mismo problema, sin embargo, sólo una de ellas será la más factible. Las soluciones iniciales, deben ser definidas tomando en cuenta tanto la perspectiva técnica como la del negocio.
INGENIERÍA DE REQUERIMIENTOS
Página 42
UNIVERSIDAD PRIVADA TELESUP Construir un vocabulario común: Debe confeccionarse un glosario en dónde se definan
todos
los
términos
que
tengan
significados comunes (sinónimos) y que serán utilizados durante el proyecto. Por ejemplo, las palabras
pignoración,
retención,
valor
en
suspenso, custodia, garantía, entre otras, son utilizadas para referirse a la acción de dejar una prenda (puede ser cualquier forma de ahorros) como garantía de una deuda adquirida.
La creación de un glosario es sumamente beneficiosa ya que reduce los términos ambiguos desde el principio, ahorra tiempo, asegura que todos los participantes de una reunión están en la misma página, además de ser reutilizable en otros proyectos.
Identificar a los afectados por el sistema: Identificar a todos los afectados evita que existan sorpresas a medida que avanza el proyecto.
Las necesidades de cada afectado, son discutidas y sometidas a
debate durante la ingeniería de requerimientos, aunque esto no garantiza que vaya a estar disponible toda la información necesaria para especificar un sistema adecuado. Para saber quiénes son las personas, departamentos, organizaciones internas o externas que se verán afectadas por el sistema, debemos realizar algunas preguntas:
¿Quién usará el sistema que se va a construir? ¿Quién usará el sistema que se va a construir? ¿Quién desarrollará el sistema? ¿Quién usará el sistema que se va a construir? ¿Quién probará el sistema?
¿Quién documentará el sistema?
INGENIERÍA DE REQUERIMIENTOS
Página 43
UNIVERSIDAD PRIVADA TELESUP
¿Quién dará soporte al sistema?
¿Quién dará mantenimiento al sistema?
¿Quién mercadeará, venderá, y/o distribuirá el sistema? ¿Quién se beneficiará por el retorno de inversión del sistema?
Como vemos, debe conocerse la opinión de todo aquél que de una u otra forma está involucrado con el sistema, ya sea directa o indirectamente.
Definir los límites y restricciones del sistema: Este punto es importante pues debemos saber lo que se está construyendo, y lo que no se está construyendo, para así entender la estrategia del producto a corto y largo plazo. Debe determinarse cualquier restricción ambiental, presupuestaria, de tiempo, técnica y de factibilidad que limite el sistema que se va a construir.
2.
ANALISIS Y NEGOCIACIÓN DE LOS REQUERIMIENTOS La diversa gama de fuentes de las cuales provienen los requerimientos, hacen necesaria una evaluación de los mismos antes de definir si son adecuados para el cliente. El término “adecuado” significa que ha sido percibido a un nivel aceptable de riesgo tomando en cuenta las factibilidades técnicas y económicas, a la vez que se buscan resultados completos, correctos y sin ambigüedades. . En esta etapa se pretende limitar las expectativas del cliente apropiadamente, tomando como referencia los niveles de abstracción y descomposición de cada problema presentado.
INGENIERÍA DE REQUERIMIENTOS
Página 44
UNIVERSIDAD PRIVADA TELESUP LOS PRINCIPALES PASOS DE ESTA ACTIVIDAD SON: Descubrir problemas potenciales: se identifican aquellos requerimientos ambiguos, incompletos, inconsistentes, etc.
Clasificar los requerimientos:
En este paso se busca identificar la importancia que tiene un requerimiento en términos de implementación. A esta característica se le conoce como prioridad y debe ser usada para establecer la secuencia en que ocurrirán las actividades de diseño y prueba de cada requisito. La prioridad de cada requerimiento dependerá de las necesidades que tenga el negocio.
En base a la prioridad, cada requerimiento puede ser clasificados como mandatorio, deseables o innecesarios. Un requerimiento es mandatorio si afecta una operación crítica del negocio. Si existe algún proceso que se quiera incluir para mejorar los procesos actuales, estamos ante un requerimiento
deseable;
y
si
se
trata
de
un
requerimiento informativo o que puede esperar para fases posteriores, el requerimiento es catalogado como innecesario.
Una vez hecha esta categorización de los requerimientos, puedo tomar como estrategia general el incluir los mandatorios, discutir los deseables y descartar los innecesarios. Antes de decidir la inclusión de un requerimiento, también debe analizarse su costo, complejidad, y una cantidad de otros factores.
Por ejemplo, si un
requerimiento fuera trivial de implementar, puede ser una buena idea incluirlo por más que éste sea sólo deseable.
INGENIERÍA DE REQUERIMIENTOS
Página 45
UNIVERSIDAD PRIVADA TELESUP Evaluar factibilidades y riesgos:
Involucra la evaluación de factibilidades técnicas (¿pueden implementarse los requerimientos con la tecnología
actual?);
factibilidades
operacionales
(¿puede ser el sistema utilizado sin alterar el organigrama actual?); factibilidades económicas (¿ha sido aprobado por los clientes el presupuesto?).
En la actividad de evaluación y negociación, se incrementa la comunicación entre el equipo de desarrollo y los afectados. Para que los requerimientos puedan ser comunicados de manera efectiva, hay una serie de consideraciones que deben tenerse en cuenta; entre las principales tenemos:
Documentar todos los requerimientos a un nivel de detalle apropiado.
Mostrar todos los requerimientos a los involucrados en el sistema.
Analizar el impacto que causen los cambios a requerimientos antes de aceptarlos.
Establecer las relaciones entre requerimientos que indiquen dependencias.
3.
Negociar con flexibilidad para que exista un beneficio mutuo.
Enfocarse en intereses y no en posiciones.
ESPECIFICACIÓN DE REQUISITOS DE SOFTWARE (SRS)
En el tema anterior menciona dos tipos de documentos que se generan, el DRU o documento de requisitos de usuario y el ERS, especificación de requisitos de software, pero el documento final obtenido es el SRS, documento de especificación de requisitos de software.
INGENIERÍA DE REQUERIMIENTOS
Página 46
UNIVERSIDAD PRIVADA TELESUP
La especificaciรณn de requisitos de software es la actividad en la cual se genera el documento, con el mismo nombre, que contiene una descripciรณn completa de las necesidades y funcionalidades
del
sistema
que
serรก
desarrollado;
describe el alcance del sistema y la forma en cรณmo harรก sus funciones, definiendo los requerimientos funcionales y los no funcionales.
En la SRS se definen todos los requerimientos de hardware y software, diagramas, modelos de sistemas y cualquier otra informaciรณn que sirva de soporte y guรญa para fases posteriores. Es importante destacar que la especificaciรณn de requisitos es el resultado final de las actividades de anรกlisis y evaluaciรณn de requerimientos; este documento resultante serรก utilizado como fuente bรกsica
de
comunicaciรณn
entre
los
clientes,
usuarios finales, analistas de sistema, personal de pruebas,
y
todo
aquel
involucrado
en
la
implementaciรณn del sistema.
Los clientes y usuarios utilizan la SRS para comparar si lo que se estรก proponiendo, coincide con las necesidades de la empresa. Los analistas y programadores la utilizan para determinar el producto que debe desarrollarse.
El
personal de pruebas elaborarรก las pruebas funcionales y de sistemas en base a este documento. Para el administrador del proyecto sirve como referencia y control de la evoluciรณn del sistema.
INGENIERร A DE REQUERIMIENTOS
Pรกgina 47
UNIVERSIDAD PRIVADA TELESUP La SRS posee las mismas características de los requerimientos: completa, consistente, verificable, no ambigua, factible, modificable, rastreable, precisa, entre otras. Para que cada característica de la SRS sea considerada, cada uno de los requerimientos debe cumplirlas; por ejemplo, para que una SRS se considere verificable, cada requerimiento definido en ella debe ser verificable; para que una SRS se considere modificable, cada requerimiento debe ser modificable y así sucesivamente.
La estandarización de la SRS es fundamental pues ayudará, entre otras cosas, a facilitar la lectura y escritura de la misma. Será un documento familiar para todos los involucrados, además de asegurar que se cubren todos los tópicos importantes. Existen plantillas creadas para la SRS, sin embargo, cada uno tiene la potestad de crear su propia plantilla.
4. VALIDACIÓN DE REQUISITOS La validación es la actividad de la IR que permite demostrar que los requerimientos definidos en el sistema son los que realmente quiere el cliente; además revisa que no se haya omitido ninguno, que no sean ambiguos, inconsistentes o redundantes.
En este punto es necesario recordar que la SRS debe estar libre de errores, por lo tanto, la validación Garantiza que todos los requerimientos presentes en el documento de especificación sigan los estándares de calidad. .
INGENIERÍA DE REQUERIMIENTOS
Página 48
UNIVERSIDAD PRIVADA TELESUP No debe confundirse la actividad de evaluación de requerimientos con la validación de requerimientos. La evaluación verifica las propiedades de cada requerimiento, mientras que la validación revisa el cumplimiento de las características de la especificación de requisitos.
Durante la actividad de validación pueden hacerse preguntas en base a cada una de las características que se desean revisar. A continuación se presentan varios ejemplos:
¿Están incluidas todas las funciones requeridas por el cliente? (completa)
¿Existen conflictos en los requerimientos? (Consistencia)
¿Tiene alguno de los requerimientos más de una interpretación? (no ambigua) ¿Está cada requerimiento claramente representado? (entendible) ¿Pueden los requerimientos ser implementados con la tecnología y el presupuesto disponible? (factible) ¿Está la SRS escrita en un lenguaje apropiado? (clara) ¿Existe facilidad para hacer cambios en los requerimientos? (modificable) ¿Está claramente definido el origen de cada requisito? (rastreable) ¿Pueden
los requerimientos
ser
sometidos
a
medidas
cuantitativas?
(Verificable)
La validación de requerimientos es importante pues de ella depende que no existan elevados costos de mantenimiento para el software desarrollado.
INGENIERÍA DE REQUERIMIENTOS
Página 49
UNIVERSIDAD PRIVADA TELESUP 5.
GESTIÓN Los requerimientos son una manera de comprender mejor el desarrollo de las necesidades de los usuarios y cómo los objetivos de la organización pueden cambiar, por lo tanto, es
esencial planear posibles cambios a los requerimientos cuando el sistema sea desarrollado y utilizado.
La actividad de evolución es un proceso externo que
ocurre a lo largo del ciclo de vida del proyecto. Los requerimientos cambian por diferentes razones. Las más frecuentes son:
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.
Cambios a los requisitos involucra modificar el tiempo en el que se va a implementar una característica en particular, modificación que a la vez puede tener impacto en otros requerimientos. Por esto, la administración de cambios involucra actividades como establecer políticas, guardar históricos de cada requerimiento, identificar dependencias entre ellos y mantener un control de versiones.
Tener versiones de los requerimientos es tan importante como tener versiones del código, ya que evita tener requerimientos emparchados en un proyecto.
INGENIERÍA DE REQUERIMIENTOS
Página 50
UNIVERSIDAD PRIVADA TELESUP Entre algunos de los beneficios que proporciona el control de versiones Están:
o
Prevenir cambios no autorizados.
o
Guardar revisiones de los documentos de requerimientos.
o
Recuperar versiones previas de los documentos.
o
Administrar una estrategia de “releases”.
o
Prevenir la modificación simultánea a los requisitos.
En vista que las peticiones de cambios provienen de muchas fuentes, las mismas deben ser enrutadas en un solo proceso. Esto se hace con la finalidad de evitar problemas y conseguir estabilidad en los requerimientos.
LECTURAS RECOMENDADAS
LA INGENIERÍA DE REQUISITOS http://es.wikipedia.org/wiki/Ingenier%C3%ADa_de_requisitos
PROCESO DE LA INGENIERÍA DE REQUISITOS http://danielvn7.wordpress.com/2008/03/27/proceso-de-laingenieria-de-requisitos/
CLASIFICACIÓN Y CAPTURA DE REQUISITOS http://www.fdi.ucm.es/profesor/gmendez/docs/is0809/03Requisitos.pdf
INGENIERÍA DE REQUERIMIENTOS
Página 51
UNIVERSIDAD PRIVADA TELESUP
ACTIVIDADES Y EJERCICIOS
1. Capturar y ordenar los requisitos en el proceso de matrícula basado en las 5 actividades según BOOCH. Realiza esta actividad a través de “Booch”.
2. Investigar y enumerar cuáles serían los requerimientos funcionales en el proceso de matrícula. Enumera también los requerimientos no funcionales en el proceso de matrícula. Realiza esta actividad y envíala a través de “Requerimientos”.
INGENIERÍA DE REQUERIMIENTOS
Página 52
UNIVERSIDAD PRIVADA TELESUP
AUTOEVALUACIÓN 1.- ¿Qué es la ingeniería de requisitos? a. Obtener los requisitos del cliente de forma apropiada b. Ingeniería de Computación c. Ingeniería de Sistemas d. Ingeniería de Información e. Obtener los requisitos del cliente
2.- ¿Qué demuestra la evidencia empírica? a. Los requisitos contienen demasiados errores b. Fase de Desarrollo c. Fase de mantenimiento d. Fase de Prueba e. Fase de Entrenamiento
3.- ¿Qué tipo de requisito se refiere a las propiedades emergentes del sistema como la fiabilidad, tiempo de respuesta, etc.? a. Requisito del usuario b. Requisitos del hardware c. Requisitos no funcionales d. Requisitos del cliente e. Requisitos funcionales
4.- De acuerdo a las cinco actividades propuestas por BOOCH ¿En qué actividad se pretende limitar las expectativas del cliente considerando los niveles de abstracción y descomposición? a. b. c. d. e.
Validación Especificación Evolución Educción Análisis y negociación de los requerimientos.
5. Proceso que en base a un conjunto de actividades ayudan al equipo de proyecto a administrar, controlar, rastrear los requisitos y los cambios. a. Validación b. Gestión c. Especificación d. Inicio e. Obtención
INGENIERÍA DE REQUERIMIENTOS
Página 53
UNIVERSIDAD PRIVADA TELESUP
6. No es una técnica de captura de requerimientos a. Entrevista b. Análisis de tareas c. Casos de uso d. Validación e. Brainstorming
7. La técnica de captura de requerimientos Brainstorming trata de: a. Realizar el modelo de negocio de requerimientos b. Generar un gran número de ideas, de los actores clave del negocio. c. Análisis y negociación de requisitos, especificación de requisitos. d. Modelo de clases de negocio e. Negociación de requerimientos del negocio.
8. ¿Existen dos formas de variación en los proyectos cuáles son? a. No existe tal cosa b. Educción de requisitos y Análisis c. Dirigido al mercado y a medida d. Inicio, obtención, Clases de Negocio, a medida e. Inicio, obtención, Clases de Negocio, negociación
9. ¿En función al grado de detalle cuales son los tipos de requisitos? a. No existe tal cosa como grado de detalle b. Requisitos de los requisitos generales c. Requisitos de usuario/cliente d. Requisitos de sistema/software e. Requisitos de usuario/cliente y sistema/software
10. ¿Cuál de los siguientes representa un problema de educción? a. No hay problema, solamente es cuestión de conversar bien con el cliente. b. Los usuarios no saben describir muchas de sus tareas. c. No se puede obtener requisitos, son complicados. d. Ni problema ni solución, hay que comprar un software a medida. e. Inicio, obtención, Clases de Negocio, negociación.
INGENIERÍA DE REQUERIMIENTOS
Página 54
UNIVERSIDAD PRIVADA TELESUP RESUMEN
UNIDAD DE APRENDIZAJE I:
La ingeniería de requisitos radica en conocer cuáles son las necesidades, especificaciones y requerimientos del cliente, por supuesto esto no es una tarea fácil, para ello se utiliza una serie de técnicas para obtener mejor los requisitos. Según investigadores la gran mayoría de proyectos de software fracasan, y tan solo el 15% de ellos, llegan a concluir con éxito. Entonces que son los requisitos, son información acerca del problema a solucionar, también son las propiedades y comportamiento del sistema.
El proceso de la ingeniería de requisitos, representa las fases que se debe seguir para obtener los requerimientos del cliente de manera eficaz. Las etapas del proceso son las siguientes: inicio, análisis y negociación de requisitos, especificación de requisitos, validación de requisitos y gestión. Siendo este ultimo el proceso que permite administrar todos los activos del proyecto de software, como la administración de los recursos involucrados en la ingeniería de requerimientos por ejemplo el tiempo y el costo. Una observación a tener en cuenta es que algunos autores como Booch no consideran a la gestión como proceso fundamental sino como herramienta que permite la buena administración de los recursos.
La etapa de Educción a su vez se divide en técnicas de captura los datos siendo la entrevista y el análisis de tareas las técnicas más utilizado en el momento de obtener requerimientos de los usuarios. Cabe resaltar que la etapa más crítica para el buen desarrollo del sistema final depende de la captura de requerimientos en tal sentido la etapa de educción es la más importante para obtener verdaderamente que necesidades tienen los usuarios. La clasificación de los requerimientos capturados está enfatizada en varios aspectos. Los requisitos de usuario, son declaraciones en lenguaje natural y en diagramas de los servicios que se espera que el sistema proporcione y de las restricciones bajo las cuales debe operar. Utilizan 5 actividades según BOOCH que es otra manera de cómo se puede realizar los procesos de captura de requerimientos a diferencia de PRESSMAN: Educción de Requisitos, Análisis y Negociación de Requisitos, Especificación de Requisitos, Validación de Requisitos, Gestión. Para termina cabe acotar que se debe tener en cuenta que existe diferencia entre usuario y cliente, de quien se debe adquirir los requerimientos para el buen funcionamiento del sistema es del usuario más que de un cliente dado que el usuario es quien va a utilizar nuestro producto final. INGENIERÍA DE REQUERIMIENTOS
Página 55
UNIVERSIDAD PRIVADA TELESUP
UNIDAD DE APRENDIZAJE
REQUERIMIENTOS - RUP
COMPETENCIA: Al finalizar esta unidad usted será capaz de: “Aplicar las técnicas y métodos de la Ingeniería de Requerimientos para la construcción de sistemas de información, expresando sus ideas con coherencia, lógica, orden, claridad, fundamento y buen lenguaje”. INGENIERÍA DE REQUERIMIENTOS
Página 56
UNIVERSIDAD PRIVADA TELESUP
INTRODUCCIÓN
a) Presentación y contextualización El alumno desarrolla una actitud analítica y critica que le permita valorar la etapa de análisis de requerimientos en el ciclo de vida del desarrollo de los sistemas de información.
b) Competencia Aplica las técnicas y métodos de la Ingeniería de Requerimientos para la construcción de sistemas de información, expresando sus ideas con coherencia, lógica, orden, claridad, fundamento y buen lenguaje.
c) Capacidades 1. Desarrolla casos para capturar los requerimientos de los clientes. 2. Explica las técnicas de entrevistas y encuestas para capturar los requerimientos del cliente. 3. Comprende los principios clave sobre el proceso unificado de desarrollo. 4. Modela casos de uso del negocio aplicado a la realidad empresarial.
d) Actitudes Desarrolla una actitud emprendedora mediante la toma de iniciativas, promoción de actividades y toma de decisiones en relación a la actividad asignada. Actúa con responsabilidad personal, al cumplir con los horarios establecidos y el respeto a las normas de convivencia. Cumple con la presentación de los trabajos encomendados de manera individual y en equipo, respetando la iniciativa y aportes de los integrantes. Desarrolla la creatividad, la innovación, la actitud emprendedora y el respeto a la honestidad intelectual.
e) Ideas básicas y contenido esenciales de la Unidad: La Unidad de Aprendizaje 2: Requerimientos - RUP, comprende el desarrollo de los siguientes temas: TEMA 1 TEMA 2 TEMA 3 TEMA 4
: Casos Prácticos para capturar los requisitos. : Métodos de Recolección de Información. : Proceso Unificado de desarrollo. : Modelado del Negocio
INGENIERÍA DE REQUERIMIENTOS
Página 57
UNIVERSIDAD PRIVADA TELESUP
TEMA Casos Prรกcticos para Capturar los Requisitos
INGENIERร A DE REQUERIMIENTOS
Pรกgina 58
UNIVERSIDAD PRIVADA TELESUP
Tema 1: Casos Prácticos para Capturar los Requisitos CASO 1: SISTEMA BIBLIOTECA Se quiere construir un sistema de consulta de libros para una biblioteca. De cada libro la biblioteca almacena: (1) un título, (2) una lista de autores, (3) una referencia bibliográfica que debe ser única, (4) una lista de descriptores y (5) un número de ejemplares disponibles Además se permite realizar reservas, de uno o varios libros, se sabe que se puede solicitar reservas de varios ejemplares. Se registra la información completa del libro, y autor, el autor tiene un nombre una nacionalidad, sexo, país de origen. La gestión del préstamo es un punto central, no se le permitirá el alquiler de un libro a un cliente que tiene ejemplares pendientes por devolver.
POR EJEMPLO:
Título: ¿Programación en Java? Autores: ¿Luis Pérez?, ¿Martín Suárez? Referencia: ¿SIST-34543-WFR? Descriptores:
¿Java?,
¿Introducción
a
la
programación?, ¿Computadores?, ¿Sistemas? Ejemplares disponibles: 20
De la descripción anterior se obtiene los siguientes requerimientos funcionales y no funcionales.
INGENIERÍA DE REQUERIMIENTOS
Página 59
UNIVERSIDAD PRIVADA TELESUP
EL SISTEMA DEBE SOPORTAR SIETE REQUERIMIENTOS FUNCIONALES:
NRO RF01
REQUERIMIENTO FUNCIONAL Agregar un nuevo libro. Obtener la lista de libros que tienen ciertas palabras dadas en el
RF02
título. El usuario teclea una o varias palabras separadas por un blanco y el sistema le presenta por pantalla todos los libros que las incluyen todas en su título. Obtener la lista de libros escritos por un autor. El usuario teclea
RF03
el nombre y apellido de un autor y el sistema le presenta por pantalla todos los libros de los cuales es autor. Obtener la lista de libros que tienen alguno de los descriptores
RF04
dados. El usuario teclea hasta 3 descriptores completos y el sistema le presenta por pantalla todos los libros que incluyen cualquiera de ellos. Pedir prestado un libro de la biblioteca. El usuario lo debe
RF05
seleccionar ya sea por su referencia bibliográfica o a partir de las listas obtenidas en los requerimientos anteriores.
RF06
Devolver un libro prestado. El usuario debe suministrar la referencia bibliográfica del mismo. Indicar el número total de libros disponibles en la biblioteca y el
RF07
número de libros que se encuentran en préstamo en ese momento.
Los Requerimientos Funcionales son los aspectos que tendrá que tener el Software.
INGENIERÍA DE REQUERIMIENTOS
Página 60
UNIVERSIDAD PRIVADA TELESUP
REQUERIMIENTOS NO FUNCIONALES
NRO RNF01
RNF02
REQUERIMIENTO NO FUNCIONAL El sistema debe almacenar los libros en una tabla de hashing, con acceso por la referencia bibliográfica. El sistema debe crear índices por palabras del título, autores y descriptores, utilizando árboles AVL. Sólo se pueden utilizar las estructuras de datos de Cupi2
RNF03
Collections en su forma genérica, sin modificar por ningún motivo su código.
RNF04
RNF05
La actualización de la información del requerimiento 7 se debe hacer utilizando MVC (observable + observador). Todo el diseño debe estar desacoplado utilizando interfaces y fábricas. El
RNF06
sistema
hace
persistir
la
información
utilizando
serialización. El ejercicio se debe entregar con al menos 20 libros registrados.
RNF07
RNF08
El diseño de la interfaz de usuario corre por cuenta de cada grupo. Debe estar implementada con Visual Editor. Cada grupo debe entregar los documentos detallados de análisis y diseño. Aunque
los
requerimientos
no
funcionales del caso sean un poco difíciles de comprender, entiéndase que son las restricciones del sistema.
Al final si necesitamos plasmarlo en un modelo, utilizaremos la notación de casos de uso que será explicada más adelante.
INGENIERÍA DE REQUERIMIENTOS
Página 61
UNIVERSIDAD PRIVADA TELESUP CASO 2: RESERVA DE PELÍCULAS Debe permitir a los usuarios en general hacer consultas y reservaciones de películas, además de poder comprar las entradas al cine de manera virtual, sin tener que desplazarse hasta la taquilla del teatro. Se desea que el sistema de reservas esté disponible desde internet.
AHORA SE DESCRIBEN LOS REQUERIMIENTOS FUNCIONALES: NRO
REQUERIMIENTOS FUNCIONALES
RF01
Consulta de películas disponibles.
RF02
Reserva de películas.
RF03
Pago de boletos para el ingreso.
RF04
Ver horarios de películas.
RF05
Registrar las tarifas.
RF06
Registrar los clientes.
RF07
Registrar las películas.
RF08
Registrar los cines.
REQUERIMIENTOS NO FUNCIONALES NRO RNF01
RNF02
RNF03
RNF04
INGENIERÍA DE REQUERIMIENTOS
REQUERIMIENTO NO FUNCIONAL La programación deberá utilizar el patrón de diseño MVC. Los pagos solo se permiten con tarjetas de crédito. El sistema deberá contar con el uso de un certificado digital. El
sistema
deberá
instalarse
en
una
plataforma cloud computing.
Página 62
UNIVERSIDAD PRIVADA TELESUP
TEMA Métodos de Recolección de Información
INGENIERÍA DE REQUERIMIENTOS
Página 63
UNIVERSIDAD PRIVADA TELESUP
Tema 2: Métodos de Recolección de Información LA ENTREVISTA En el análisis de sistemas hay que distinguir las formas cualitativas y cuantitativas de información. La cualitativa está relacionada con opiniones, políticas y descripciones narrativas de actividades o problemas
y
las
cuantitativas
con
números,
frecuencias o cantidades. A menudo las entrevistas son la mejor fuente de información cualitativa.
Dentro de las técnicas utilizadas para recopilar información, las entrevistas ocupan un lugar preponderante en consideración con el tiempo que ocupan y el objetivo que tienen. Por lo general, son la mayor fuente de información del analista. La entrevista es una forma de conversación, no de interrogación.
Las entrevistas se pueden realizar sobre la base de un cuestionario rígido o de una guía más o menos detallada que las orienta hacia puntos bien definidos. El método de entrevistas para obtener información tiene las siguientes ventajas. Permite a los analistas presentar sus necesidades de forma directa y verificar preguntas
en
las
respuestas
realizadas
recibidas,
fueron
si
las
interpretadas
correctamente.
INGENIERÍA DE REQUERIMIENTOS
Página 64
UNIVERSIDAD PRIVADA TELESUP
Para llevar a efecto una entrevista se deben realizar una serie de pasos y cumplir una serie de reglas para poder asegurar el éxito de la misma.
Preparación Los distintos pasos que se deben realizar son: Ejecución
.
Preparación Se debe coordinar con el usuario la fecha, la hora y el lugar. Se debe garantizar la privacidad, evitar las interrupciones y disponer
de un tiempo
adecuado. Se deben obtener criterios previos acerca de las personas que se van a entrevistar para poder desarrollar una conversación más natural. Se deben preparar cuidadosamente las preguntas a realizar o la guía de la entrevista.
INGENIERÍA DE REQUERIMIENTOS
Página 65
UNIVERSIDAD PRIVADA TELESUP
Ejecución Se debe ser correcto y no preguntar cosas que se pueden obtener por otras vías a menos que se desee comprobar algo. El tacto, la imparcialidad e incluso la vestimenta apropiada ayudan a asegurar una entrevista exitosa. Se debe ser puntual, identificarse y explicar los objetivos de la entrevista. Se debe prestar la máxima atención durante el desarrollo, crear un clima favorable, evitar caer en discusión con los usuarios, no hacer criticas, utilizar una terminología adecuada, no adelantarse a ningún criterio ni opinión de los usuarios y mucho menos sacar conclusiones instantáneas sobre la información recibida. Diferenciar entre los hechos y las opiniones, entre la actividad o función que realiza y el como la realiza, tratando siempre que la información recopilada sea lo mas objetiva posible. Evitar que la entrevista sea larga o se convierta en inoportunas por razones imprevistas, si esto ocurre se debe posponer. Al despedirse se debe mostrar agradecimiento y dejar coordinado otro posible encuentro. Al
final
se
debe
hacer
una
pequeña
recapitulación de la información recopilada para verificar
los
hechos
registrados.
3.
Recapitulación. Se deben revisar las notas para reordenarlas y organizarlas por temas, pasarlas en limpio y comprobar que no existan contradicciones. La recapitulación de las entrevistas se hace en el
modelo
"Registro
de
Acuerdos
y
Observaciones”.
INGENIERÍA DE REQUERIMIENTOS
Página 66
UNIVERSIDAD PRIVADA TELESUP ¿CÓMO LLEVAR A CABO UNA ENTREVISTA EXITOSA? Entrevistar es un arte, así como una habilidad que se da a través de la práctica y el conocimiento del sistema que se está investigando. Aquellos que tienen éxito y son efectivos al utilizar los métodos de entrevista, durante los estudios de sistemas, están de acuerdo con las etapas que los analistas deben seguir. Para asegurar que la entrevista sea útil, el analista debe seguir las siguientes indicaciones: Realice una cita por anticipado con quienes vaya a entrevistar Las entrevistas son exitosas solo si se han planeado y arreglado con cuidado por anticipado. Entrar en la oficina de un alto dirigente sin anunciarse antes sería un error. Avísele a los entrevistados sobre la naturaleza de la entrevista. Planéese mantener una entrevista común por no más de una hora.
Prepararse conociendo de antemano a los individuos que va entrevistar Familiarícese con el tema de la entrevista y prepárese un conjunto apropiado de preguntas que
deben
contestarse
durante
las
conversaciones planeadas.
Durante la Entrevista Comience por presentarse subrayando el tema de la entrevista y estableciendo la naturaleza del proyecto sobre el cual se trabaja. Comience con preguntas generales que establecerán el marco de trabajo con el cual se conducirá el resto de la entrevista. INGENIERÍA DE REQUERIMIENTOS
Página 67
UNIVERSIDAD PRIVADA TELESUP Continúese con los temas y aspectos que surjan de quienes responden. Asegúrese de encontrar por qué quienes responden creen que es tan importante el tema como para comentarlo. Limítense las notas que se escriban para evitar distraer a quienes responden. Cuando todos los temas vistos con los entrevistados se
hayan
discutido,
realícense
otras
preguntas
específicas que se crea deban discutirse. Al final de la entrevista, resúmase la información recabada
durante
la
misma.
Si
se
considera
apropiado, indíquese que se preparará para quienes respondieron un resumen escrito de la entrevista para que puedan examinarlo. Considérese la posibilidad de continuar con las entrevistas después.
EL CUESTIONARIO Los cuestionarios constituyen la única forma posible de poder relacionarse con un gran número de personas para conocer varios aspectos del sistema, sin tener que estar presente. Los cuestionarios como medio para recoger opiniones o hacer encuestas pueden ser de gran utilidad si se usa en forma adecuada, o sea, si se aplican en una situación especifica para la cual fueron diseñados especialmente y además este diseño reúne una serie de requisitos. Entre los principales inconvenientes de los cuestionarios podemos señalar las siguientes:
Muchos usuarios que pueden ofrecer una buena cantidad de información, se resisten o la dan en poca cantidad cuando se trata de suministrarla por escrito.
Los entrevistados pueden objetar muchas preguntas, interpretarlas a su forma o no tomarlas en serio.
Es difícil diseñar cuestionarios que aseguren obtener exactamente toda la información que se desea.
INGENIERÍA DE REQUERIMIENTOS
Página 68
UNIVERSIDAD PRIVADA TELESUP A pesar de los inconvenientes anteriores, estos son recomendables utilizarlos cuando:
Se requiere una pequeña cantidad de información de un gran número de personas en un corto periodo de tiempo.
La información se desea consolidar en tablas de analistas. Se
deseen
respuestas
de
usuarios
que
se
encuentran
dispersas
geográficamente.
HAY DOS FORMAS DE CUESTIONARIOS: ABIERTOS Y CERRADOS.
ABIERTOS Se
utilizan
para
recoger
sentimientos,
opiniones, referencias.
CERRADOS Limitan las respuestas posibles a través de un estilo cuidadoso en la pregunta.
Respuestas de Cuestionario Cerrado: SI/NO ¿Cree que se cometen muchos errores en la
SI
Codificación de los números de cuenta en las facturas?
NO
DE ACUERDO/EN DESACUERDO Se cometen muchos errores al codificar
DE ACUERDO
los números de cuenta en las facturas.
EN DESACUERDO
INGENIERÍA DE REQUERIMIENTOS
Página 69
UNIVERSIDAD PRIVADA TELESUP NÚMERO De cada 100 facturas que se procesan cuántas tienen errores? Anote el número: ___________ RANGO ¿De cada 100 facturas que se procesan cuántas tienen errores?
0-5 6 - 10 11 - 15 16 - 20 21 - 25 26 - 30 31 - 40 41 - 50 Más de 50
SELECCIÓN DE RESPUESTAS LIMITADAS Cuando se presentan errores en la codificación de los números de cuenta en las facturas, ¿cuál es la causa más frecuente? (Anótese el número de la respuesta apropiada). 1.... 2.... 3....
¿CÓMO DESARROLLAR UN CUESTIONARIO? Los buenos cuestionarios se deben diseñar previamente. Un pensamiento cuidadoso, acompañado de una prueba previa, tanto del formato como de las preguntas, son la base de una recopilación de datos significativa a través de cuestionarios. Pautas para ayudarles en la confección de un cuestionario:
INGENIERÍA DE REQUERIMIENTOS
Página 70
UNIVERSIDAD PRIVADA TELESUP Determine qué datos necesitan recopilarse y que personas son las más calificadas para proporcionarlos. Si otros grupos pueden proporcionar datos variantes y mayor visión identifíquelos también.
Seleccione el tipo de cuestionario (abierto o cerrado). Reconozca cuales pueden ser más útiles,
si
contienen
una
sección
de
respuestas cerradas y otras de respuestas abiertas.
Desarrolle un Grupo de preguntas para incluirlas en el cuestionario. Las preguntas extras que son intencionalmente redundantes, pueden ser útiles al asegurar respuestas consistentes por parte de quien responda.
. Examine el cuestionario para encontrarle fallas y defectos como: Interrogantes innecesarias.
Preguntas que puedan ser mal interpretadas debido a su enfoque o forma de escritura.
Preguntas que el sujeto no pueda responder. Preguntas que están escritas de forma que se escogerá la respuesta preferida.
Preguntas que se interpretaran en forma diferente dependiendo del marco de referencia de cada entrevistado.
Preguntas que no proporcionan opciones adecuadas de respuesta. Un ordenamiento no adecuado de las preguntas y respuestas.
Pruébelo previamente en un Grupo pequeño para detectar otros problemas posibles.
INGENIERÍA DE REQUERIMIENTOS
Página 71
UNIVERSIDAD PRIVADA TELESUP Analice la respuesta del Grupo de prueba para asegurar que el análisis de los datos que se busca se puede llevar a cabo con los datos recopilados. Si los datos no revelan algo que el analista no conoce, el cuestionario puede no ser necesario. Realice cambios finales de edición e imprímalo en una forma legible.
Distribuya el cuestionario. Cuando sea posible anote el nombre de cada persona. REVISIÓN DE DOCUMENTOS Toda entidad debe emitir y archivar un conjunto de documentos de información donde aparezcan los indicadores principales de la entidad relacionados con su actividad fundamental. Por lo general las entidades también emiten y archivan un conjunto de informes o modelos de interés para el organismo central o ministerio al cual pertenecen. Además, toda entidad debe tener un Sistema de Contabilidad, un Sistema de Fuerza de Trabajo uno de Abastecimiento, uno de Medios Básicos, etc. Cada uno de los cuales posee toda la información de la entidad sobre esos aspectos específicos.
Muchos o todos los indicadores que Ud. necesita deben estar reflejados en estos documentos. Pero muchas veces en los documentos no se refleja exactamente lo que uno quiere buscar y debe hacer un procesamiento de ellos. Hay que saber obtener la información de los modelos estadísticos. A pesar de que se haga un análisis profundo de los documentos, hay indicadores que la entidad no recopila y son sumamente útiles para el analista; entonces, hay que ir a la investigación o a realizar ciertos experimentos.
INGENIERÍA DE REQUERIMIENTOS
Página 72
UNIVERSIDAD PRIVADA TELESUP
TEMA Proceso Unificado de Desarrollo
INGENIERร A DE REQUERIMIENTOS
Pรกgina 73
UNIVERSIDAD PRIVADA TELESUP
Tema 3: Proceso Unificado de Desarrollo CARACTERÍSTICAS ESENCIALES
Los autores de RUP (Proceso Unificado de Desarrollo) destacan que el proceso de software propuesto por RUP tiene tres características esenciales: está dirigido por los Casos de Uso, está centrado en la arquitectura, y es iterativo e incremental.
PROCESO DIRIGIDO POR CASOS DE USO Según [Kru00], los Casos de Uso son una técnica de captura de requisitos que fuerza a pensar en términos de importancia para el usuario y no sólo en términos de funciones que sería bueno contemplar. Se define un Caso de Uso como un fragmento de funcionalidad del sistema que proporciona al usuario un valor añadido. Los Casos de Uso representan los requisitos funcionales del sistema.
En RUP los Casos de Uso no son sólo una herramienta para especificar los requisitos del sistema. También guían su diseño, implementación y prueba. Los Casos de Uso constituyen un elemento integrador y una guía del trabajo como se muestra en la Figura 1.
Figura 1: Los Casos de Uso integran el trabajo INGENIERÍA DE REQUERIMIENTOS
Página 74
UNIVERSIDAD PRIVADA TELESUP
Los Casos de Uso no sólo inician el proceso de desarrollo sino que proporcionan un hilo conductor, permitiendo
establecer
trazabilidad
entre
los
artefactos que son generados en las diferentes actividades del proceso de desarrollo.
Como se muestra en la Figura 2, basándose en los Casos de Uso se crean los modelos de análisis y diseño, luego la implementación que los lleva a cabo, y se verifica que efectivamente el producto implemente adecuadamente cada Caso de Uso. Todos los modelos deben estar sincronizados con el modelo de Casos de Uso.
Figura 2: Trazabilidad a partir de los Casos de Uso
PROCESO CENTRADO EN LA ARQUITECTURA La arquitectura de un sistema es la organización o estructura de sus partes más relevantes, lo que permite tener una visión común entre todos los involucrados (desarrolladores y usuarios) y una perspectiva clara del sistema completo, necesaria para controlar el desarrollo [Kru00]. La arquitectura involucra los aspectos estáticos y dinámicos más significativos del sistema, está relacionada con la toma de decisiones que indican cómo tiene que ser construido
el sistema y ayuda a determinar en qué orden. Además la
definición de la arquitectura debe tomar en consideración elementos de calidad del sistema, rendimiento, reutilización y capacidad de evolución por lo que debe ser flexible durante todo el proceso de desarrollo.
INGENIERÍA DE REQUERIMIENTOS
Página 75
UNIVERSIDAD PRIVADA TELESUP
La arquitectura se ve influenciada por la plataforma software, sistema operativo, gestor de bases de datos, protocolos, consideraciones de desarrollo como sistemas heredados. Muchas de estas restricciones constituyen requisitos no funcionales del sistema.
En el caso de RUP además de utilizar los Casos de Uso para guiar
el
proceso
se
presta
especial
atención
al
establecimiento temprano de una buena arquitectura que no se vea fuertemente impactada ante cambios posteriores durante la construcción y el mantenimiento. Cada producto tiene tanto una función como una forma. La función corresponde a la funcionalidad reflejada en los Casos de Uso y la forma la proporciona la arquitectura. Existe una interacción entre los Casos de Uso y la arquitectura, los Casos de Uso deben encajar en la arquitectura cuando se llevan a cabo y la arquitectura debe permitir el desarrollo de todos los Casos de Uso requeridos, actualmente y en el futuro. Esto provoca que tanto arquitectura como Casos de Uso deban evolucionar en paralelo durante todo el proceso de desarrollo de software.
En la Figura 3 se ilustra la evolución de la arquitectura durante las fases de RUP. Se tiene una arquitectura más robusta en las fases finales del proyecto. En las fases iniciales lo que se hace es ir consolidando la arquitectura por medio de baselines y se va modificando dependiendo de las necesidades del proyecto.
Inception
Elaboration
Construction
Transition
Architecture
tiempo
Figura 3: Evolución de la arquitectura del sistema
INGENIERÍA DE REQUERIMIENTOS
Página 76
UNIVERSIDAD PRIVADA TELESUP
Es conveniente ver el sistema desde diferentes perspectivas para comprender mejor el diseño por lo que la arquitectura se representa mediante varias vistas que se centran en aspectos concretos del sistema, abstrayéndose de los demás. Para RUP, todas las vistas juntas forman el llamado modelo 4+1 de la arquitectura [Kru95], el cual recibe este nombre porque lo forman las vistas lógica, de implementación, de proceso y de despliegue, más la de Casos de Uso que es la que da cohesión a todas.
Figura 4: Los modelos se completan, la arquitectura no cambia drásticamente
Al final de la fase de elaboración se obtiene una baseline de la arquitectura donde fueron seleccionados una serie de Casos de Uso arquitectónicamente relevantes (aquellos que ayudan a mitigar los riesgos más importantes, aquellos que son los más importantes para el usuario y aquellos que cubran las funcionalidades significativas). Como se observa en la Figura 4, durante la construcción los diversos modelos van desarrollándose hasta completarse (según se muestra con las formas rellenas en la esquina superior derecha).
INGENIERÍA DE REQUERIMIENTOS
Página 77
UNIVERSIDAD PRIVADA TELESUP
La
descripción
de
la
arquitectura
sin
embargo,
no
debería
cambiar
significativamente (abajo a la derecha) debido a que la mayor parte de la arquitectura se decidió durante la elaboración. Se incorporan pocos cambios a la arquitectura (indicados con mayor densidad de puntos en la figura inferior derecha).
PROCESO ITERATIVO E INCREMENTAL Según el equilibrio correcto entre los Casos de Uso y la arquitectura es algo muy parecido al equilibrio de la forma y la función en el desarrollo del producto, lo cual se consigue con el tiempo. Para esto, la estrategia que se propone en RUP es tener un proceso iterativo e incremental en donde el trabajo se divide en partes más pequeñas o mini proyectos. Permitiendo que el equilibrio entre Casos de Uso y arquitectura se vaya logrando durante cada mini proyecto, así durante todo el proceso de desarrollo. Cada mini proyecto se puede ver como una iteración (un recorrido más o menos completo a lo largo de todos los flujos de trabajo fundamentales) del cual se obtiene un incremento que produce un crecimiento en el producto.
Una
iteración
puede realizarse por medio de una cascada como se muestra
en
la
Figura 5. Se pasa por
los
flujos
fundamentales (Requisitos, Análisis, Diseño, Figura 1: Una iteración RUP
Implementación y Pruebas), también existe una
planificación de la iteración, un análisis de la iteración y algunas actividades específicas de la iteración. Al finalizar se realiza una integración de los resultados con lo obtenido de las iteraciones anteriores.
INGENIERÍA DE REQUERIMIENTOS
Página 78
UNIVERSIDAD PRIVADA TELESUP
El proceso iterativo e incremental consta de una secuencia de iteraciones. Cada iteración aborda una parte de la funcionalidad total, pasando por todos los flujos de trabajo relevantes y refinando la arquitectura. Cada iteración se analiza cuando termina. Se puede determinar si han aparecido nuevos requisitos o han cambiado los existentes, afectando a las iteraciones siguientes. Durante la planificación de los detalles de la siguiente iteración, el equipo también examina cómo afectarán los riesgos que aún quedan al trabajo en curso. Toda la retroalimentación de la iteración pasada permite reajustar los objetivos para las siguientes iteraciones. Se continúa con esta dinámica hasta que se haya finalizado por completo con la versión actual del producto.
RUP divide el proceso en cuatro fases, dentro de las cuales se realizan varias iteraciones en número variable según el proyecto y en las que se hace un mayor o menor hincapié en los distintas actividades. En la Figura 6 se muestra cómo varía el esfuerzo asociado a las disciplinas según la fase en la que se encuentre el proyecto RUP.
Figura 6: Esfuerzo en actividades según fase del proyecto INGENIERÍA DE REQUERIMIENTOS
Página 79
UNIVERSIDAD PRIVADA TELESUP
Las primeras iteraciones (en las fases de Inicio y Elaboración) se enfocan hacia la comprensión del problema y la tecnología, la delimitación del ámbito del proyecto, la eliminación de los riesgos críticos, y al establecimiento de una baseline de la arquitectura. Durante la fase de inicio las iteraciones hacen ponen mayor énfasis en actividades modelado del negocio y de requisitos.
En la fase de elaboración, las iteraciones se orientan al desarrollo de la baseline de la arquitectura, abarcan más los flujos de trabajo de requerimientos, modelo de negocios (refinamiento),
análisis,
diseño
y
una
parte
de
implementación orientado a la baseline de la arquitectura.
En la fase de construcción, se lleva a cabo la construcción del producto por medio de una serie de iteraciones. Para cada iteración se selecciona algunos Casos de Uso, se refina su análisis y diseño y se procede a su implementación y pruebas. Se realiza una pequeña cascada para cada ciclo. Se realizan
tantas
iteraciones
hasta
que
se
termine
la
implementación de la nueva versión del producto.
En la fase de transición se pretende garantizar que se tiene un producto preparado para su entrega a la comunidad de usuarios. Como se puede observar en cada fase participan todas las disciplinas, pero que dependiendo de la fase el esfuerzo dedicado a una disciplina varía.
INGENIERÍA DE REQUERIMIENTOS
Página 80
UNIVERSIDAD PRIVADA TELESUP
TEMA Modelado del Negocio
INGENIERร A DE REQUERIMIENTOS
Pรกgina 81
UNIVERSIDAD PRIVADA TELESUP
Tema 4: Modelado del Negocio 1. MODELO DE NEGOCIO El modelado del proceso de negocio es una parte esencial de cualquier desarrollo del software. El proceso le permite al analista capturar los requerimientos y procedimientos con los cuales maneja la empresa. Este modelo proporciona una apreciación global del negocio, dónde se sacaran conclusiones como está funcionando la empresa. En base a esto se propondrán los nuevos sistemas del software que encajará en la estructura orgánica de la empresa y se reflejaran en las actividades diariamente.
El primer paso del modelado del negocio consiste en capturar los procesos de negocio de la organización bajo estudio. La definición del conjunto de procesos del negocio es una tarea crucial, ya que define los límites del proceso de modelado posterior. Nos basamos en el concepto de objetivo estratégico, para identificar de manera adecuada los diferentes procesos de negocio de una organización a partir de la determinación y estructuración de sus objetivos. Para cada objetivo que no ha sido descompuesto en otros, definimos un proceso del negocio cuyo propósito será dar soporte a dicho objetivo, es decir lograrlo o realizarlo. Representamos cada proceso del negocio mediante un caso de uso del negocio.
2. FLUJO DE TRABAJO Evaluar el negocio Describir el negocio actual Describir el negocio : a) Identificar los procesos del negocio b) Refinar las definiciones de los procesos c) Diseñar las Realizaciones de los procesos d) Refinar Roles y Responsabilidades
INGENIERÍA DE REQUERIMIENTOS
Página 82
UNIVERSIDAD PRIVADA TELESUP Explorar la automatización de los procesos Desarrollar un modelo del dominio
2.1 DESCRIPCIÓN DEL FLUJO DE TRABAJO
En la primera iteración hay que evaluar de forma preliminar la organización para decidir el alcance del esfuerzo de modelado. ¿Qué cantidad de modelado necesitamos hacer?
Si no es necesario un modelado en detalles del negocio entonces es suficiente con modelar el dominio.
Si solamente necesitamos modelar el negocio (no vamos a mejorarlo, solo queremos entenderlo) entonces hay que tomar el camino del modelado del negocio pero obviando la descripción del negocio actual.
Si es necesario una reingeniería del negocio entonces si tenemos que describir el negocio actual.
Si es un negocio nuevo hay que tomar el camino del modelado del negocio pero obviando la descripción del negocio actual.
3. ELEMENTOS DE UML PARA EL MODELADO DEL NEGOCIO:
INGENIERÍA DE REQUERIMIENTOS
Página 83
UNIVERSIDAD PRIVADA TELESUP 4. EVALUAR EL NEGOCIO Con el Propósito de: Evaluar el estado de la organización. Clasificar el proyecto y decidir cuál es el escenario de modelado más apropiado. Tomar
decisiones
sobre
como
continuar
trabajando en la iteración actual y perfilar el trabajo de las siguientes. Definir las metas y los objetivos del modelado del negocio en conformidad con los involucrados y el equipo de modelado del negocio.
5. IDENTIFICAR METAS DE NEGOCIO Estrategia de Negocio, define la manera en que la oorganización debe actuar recíprocamente con su ambiente, para cumplir con su ambiente. La organización puede cumplir su propósito una vez que se encuentra en posición competitiva sustentable. Las metas de negocio describe lo que debe lograrse para alcanzar el deseo de la posición competitiva. Estrategia y Meta de negocio se preocupan por lo que debe lograrse y no como se logrará. Las metas de negocio necesitan ser colocadas en una jerarquía, por consiguiente, cada meta de negocio apoya a las metas de nivel superior. Cada Meta de Negocio debe apoyarse directamente por lo menos en un proceso de negocio.
Diagrama visión, objetivos y metas de negocio
INGENIERÍA DE REQUERIMIENTOS
Página 84
UNIVERSIDAD PRIVADA TELESUP 6. IDENTIFICAR LOS PROCESOS DE NEGOCIO Con el Propósito de:
Delimitar el modelo de casos de uso del negocio. Definir prioridades entre los casos de uso del negocio para decidir cuáles van a ser descritos en detalles.
7.
PROCESO DEL NEGOCIO Es la secuencia de acciones necesarias para entregar un producto o servicio, con valor tangible, a un consumidor (cliente).
7.1. CASOS DE USO DEL NEGOCIO Los casos del uso de negocio describen
los
procesos de la empresa. Estos procesos se documentan como una sucesión de acciones que proporcionan un valor notable a un actor de negocio. Es la descripción de la secuencia de Acciones necesarias para entregar un producto o servicio, con valor tangible, a un consumidor (cliente). Desde la perspectiva del cliente o actor del negocio.
INGENIERÍA DE REQUERIMIENTOS
Página 85
UNIVERSIDAD PRIVADA TELESUP El siguiente paso dentro del modelado del negocio es introducirse en cada uno de los casos de uso del negocio identificados, para describirlo en detalle. Inicialmente se rellena una plantilla de descripción, y después, a partir de la información reflejada en dicha plantilla, se construye un conjunto de diagramas que describen completamente el caso de uso del negocio. Nos centraremos en uno de lo s casos de uso del negocio de nuestro ejemplo, Registrar Pedido.
La plantilla de descripción de casos de uso del negocio inspirada en el conjunto de valores etiquetados utilizados para describir un proceso de negocio, contiene los campos objetivo (qué se intenta conseguir), descripción (especificación informal de lo que hace el proceso), prioridad (importancia del proceso, por ejemplo si es fundamental o básico, de administración, o de soporte), riesgos (por ejemplo errores o fallos que pueden ocurrir al ejecutar este proceso), posibilidades (cambios o mejoras futuras del proceso), y por último, tiempo y coste aproximados de ejecución.
El formato que describe los casos de uso es como sigue:
Esta descripción puede ser validada fácilmente por los usuarios.
INGENIERÍA DE REQUERIMIENTOS
Página 86
UNIVERSIDAD PRIVADA TELESUP 7.2. ACTORES DEL NEGOCIO Es un usuario del negocio, que necesita o usa algunos de los casos de uso. Se representa mediante un hombrecillo acompañado de un nombre significativo
Actores Externos
Son los que están fuera del proceso negocio. Es el rol que juega alguien o algo mientras interactúa con el negocio. Ej. Consumidores, proveedores, autoridades, trabajadores de otras partes negocio que no están siendo modeladas.
Actores Internos
Son los que están dentro del proceso de negocio (Workers) Representa un rol o conjunto de roles en el negocio. Un trabajador del negocio interactúa con los otros roles y manipula las entidades del negocio mientras participa en las realizaciones de los casos de uso
del
negocio.
por
ejemplo:
Vendedor,
Administrador.
7.3. DIAGRAMA DE CASOS DE USO DEL NEGOCIO Ahora es necesario estudiar la Descripción de cada Cliente
Registrar Pedido
caso de uso del negocio, y observar el conjunto completo de roles involucrados, tanto externos como
Fabricar Producto
internos a la organización. Los roles del caso del uso del negocio Registrar pedido son Cliente, Comercial,
Gestionar Almacen
Jefe Técnico, y Jefe Producción. Generar Pedido a Proveedor
INGENIERÍA DE REQUERIMIENTOS
Proveedor
Página 87
UNIVERSIDAD PRIVADA TELESUP Lectura Recomendada Modelo de requerimientos http://www.scribd.com/doc/14897162/Evaluacion-de-Requerimientos-para-unSistema-de-Informacion-de-Gestion-de-Recursos-Humanos
Métodos de recolección de información http://www.monografias.com/trabajos18/recoleccion-de-datos/recoleccion-dedatos.shtml
Proceso unificado de desarrollo http://www.mitecnologico.com/Main/ElModeloProcesoUnificado http://www.scribd.com/doc/35010781/Modelo-de-Proceso-Unificado
Diagrama de casos de uso del negocio http://www.scribd.com/doc/13500172/actividad2-diagrama-de-casos-de-uso-delnegocio-y-del-sistema
ACTIVIDADES Y EJERCICIOS
1. En
el
caso
requerimientos
1,
sistema
funcionales
biblioteca, y
dos
mencione
requerimientos
dos no
funcionales adicionales a los descritos en el caso. Realiza esta actividad y envíala a través de “Sistema Biblioteca”.
2. ¿Cuál es la diferencia que existe entre el proceso unificado de desarrollo y el proceso de la ingeniería de requisitos? Responde esta pregunta a través de “Diferencia de Procesos”.
INGENIERÍA DE REQUERIMIENTOS
Página 88
UNIVERSIDAD PRIVADA TELESUP AUTOEVALUACIÓN
1. Según el caso del sistema de biblioteca, que tipo de requerimiento es el siguiente: “Devolver un libro prestado. El usuario debe suministrar la referencia bibliográfica del mismo”. a. Requerimiento del cliente b. Requerimiento funcional c. Requerimiento administrativo d. Requerimiento No Funcional e. Requerimiento del Sistema 2. De acuerdo al caso de la “Reserva de Películas”, ¿cuál de los siguientes enunciados es un requerimiento no funcional? a. Los pagos solo se permiten con tarjetas de crédito. b. El sistema debe almacenar los libros en una tabla de hashing. c. Pago de boletos para el ingreso d. Ver horarios de películas e. Registrar las tarifas 3. ¿Cuál define mejor el concepto de cuestionario? a. Constituyen la única forma posible de poder relacionarse con un gran número de personas b. Son los mismo que las entrevistas c. Los usuarios piensan que no es importante d. No sirve para el software e. Es diferente que las entrevistas
4. ¿Cuál son los principales inconvenientes de los cuestionarios? a. Los usuarios la dan poca cantidad cuando es por escrito. b. No hay inconvenientes. c. Las entrevistas tienen inconvenientes los cuestionarios no. d. No sirve para el software. e. Es diferente que las entrevistas.
5. ¿La entrevista es la mejor fuente de información cualitativa? a. No los cuestionarios son mejores b. Si son la principal fuente de información del analista c. No son la principal fuente de información del analista d. La observación es la mejor e. Los documentos de la empresa son mejores
INGENIERÍA DE REQUERIMIENTOS
Página 89
UNIVERSIDAD PRIVADA TELESUP 6. ¿Qué aspectos de calidad del sistema se deben tomar en cuenta? a. Rendimiento, reutilización y capacidad de evolución b. Rendimiento c. Reutilización d. Evolución e. Capacidad
7. ¿Cuál es la evolución de la arquitectura en el proceso de RUP? a. Incepción, elaboración, construcción, transición b. Incepción c. Elaboración d. Transición y elaboración e. Arquitectura
8. ¿Cuáles son los flujos fundamentales? a. Solo análisis y diseño b. Requisitos, análisis, diseño, implementación y pruebas c. Solo análisis d. Implementación y pruebas e. Las pruebas son relevantes
9. Defina modelo de negocio: a. Permite capturar los procedimientos con los cuales maneja la empresa b. Es saber cuál es la estrategia del cliente c. Los usuarios piensan que no es importante d. Esta probado que el modelo no es relevante e. Es diferente para un sistema, no se usa
10. ¿Qué partes para describen el negocio? a. Identificar los procesos de negocio b. Identificar los procesos de negocio, refinar las definiciones de los procesos, Diseñas las realizaciones de los procesos, refinar roles y responsabilidades. c. Diseñas las realizaciones de los procesos. d. refinar roles y responsabilidades. e. Refinar responsabilidades.
INGENIERÍA DE REQUERIMIENTOS
Página 90
UNIVERSIDAD PRIVADA TELESUP RESUMEN
UNIDAD DE APRENDIZAJE II
Basado en las necesidades del cliente que viene a ser lo que se desea que el sistema tenga, se identifican los requerimientos funcionales y no funcionales. En el caso 1 del sistema de biblioteca a través de la descripción se puede detectar los diversos requerimientos a considerar para llevar a cabo la creación de dicho sistema, tanto funcionales que viene a ser toda función que el sistema debe desempeñar y los no funcionales que vienen a ser el entorno donde el sistema va a funcionar; deben ser considerados para llevar a cabo satisfactoriamente el desarrollo del sistema.
Dentro de los métodos para detectar los requerimientos del cliente tenemos: las entrevistas se pueden realizar sobre la base de un cuestionario rígido o de una guía más o menos detallada que las orienta hacia puntos bien definidos. El método de entrevistas para obtener información tiene las siguientes ventajas: permite a los analistas presentar sus necesidades de forma directa y verificar en las respuestas recibidas, si las preguntas realizadas fueron interpretadas correctamente. Los cuestionarios constituyen la única forma posible de poder relacionarse con un gran número de personas para conocer varios aspectos del sistema, sin tener que estar presente. Los cuestionarios como medio para recoger opiniones o hacer encuestas pueden ser de gran utilidad si se usa en forma adecuada, o sea, si se aplican en una situación específica para la cual fueron diseñados especialmente y además este diseño reúne una serie de requisitos.
El proceso unificado de desarrollo está compuesto por tres características fundamentales, está dirigido por los casos de uso, centrado en la arquitectura y es iterativo e incremental, se refiere que usa modelos para representar el proceso de software. El proceso completo tiene las siguientes etapas: Requisitos, análisis y diseño, implementación y prueba, con estas etapas se debe llegar a conseguir un producto software de calidad y con los requerimientos del cliente.
El modelo del negocio permite tener la idea global del negocio, de cómo está funcionando y es fundamental considerar ello ya que permitirá en base a ello proponer nuevos sistemas que se alinearán a la empresa. Para modelarlo se debe hacer una captura de los procesos del negocio siguiendo la secuencia del flujo de trabajo. Además se debe considerar los elementos del negocio que intervienen como son: los actores, proceso, trabajador, metas; lo cual ayudará a elaborar el modelo de casos de uso del negocio.
INGENIERÍA DE REQUERIMIENTOS
Página 91
UNIVERSIDAD PRIVADA TELESUP
UNIDAD DE APRENDIZAJE
ANÁLISIS DE REQUERIMIENTOS
COMPETENCIA: Al finalizar esta unidad usted será capaz de “Diseñar modelos de análisis para capturar correctamente los requisitos del cliente”.
INGENIERÍA DE REQUERIMIENTOS
”.
Página 92
UNIVERSIDAD PRIVADA TELESUP INTRODUCCIÓN
a) Presentación y contextualización El alumno desarrolla una actitud analítica y crítica que le permita valorar la importancia del análisis de sistema en la gestión y desarrollo de los sistemas de información en el mundo actual, además le permitirá aprender a diseñar modelos conceptuales, modelos de análisis de objetos y diagramas de secuencias.
b) Competencia Diseñar modelos de análisis para capturar correctamente los requisitos del cliente.
c) Capacidades 1. Diseña modelos de casos de uso del sistema aplicado a los requerimientos encontrados en el modelo de casos de uso del negocio. 2. Modela el diagrama de objetos y plasmarlo en un modelo conceptual. 3. Elabora un modelo de análisis de objetos. 4. Entiende, diseña y explica los diagramas de secuencias.
d) Actitudes Desarrolla una actitud emprendedora mediante la toma de iniciativas, promoción de actividades y toma de decisiones en relación a la actividad asignada. Actúa con responsabilidad personal, al cumplir con los horarios establecidos y el respeto a las normas de convivencia. Cumple con la presentación de los trabajos encomendados de manera individual y en equipo, respetando la iniciativa y aportes de los integrantes. Desarrolla la creatividad, la innovación, la actitud emprendedora y el respeto a la honestidad intelectual.
e) Presentación de ideas básicas y contenido esenciales de la Unidad. La Unidad de Aprendizaje 3: Análisis de Requerimientos, comprende el desarrollo de los siguientes temas: TEMA 1: DIAGRAMA DE CASOS DE USO DEL SISTEMA TEMA 2: MODELO CONCEPTUAL TEMA 3: MODELO DE ANÁLISIS DE OBJETOS TEMA 4: DIAGRAMA DE SECUENCIA
INGENIERÍA DE REQUERIMIENTOS
Página 93
UNIVERSIDAD PRIVADA TELESUP
TEMA Diagrama de Casos de Uso del Sistema
campus.utelesup.com
INGENIERร A DE REQUERIMIENTOS
Pรกgina 94
UNIVERSIDAD PRIVADA TELESUP DESARROLLO DE LOS TEMAS
Tema 1: Diagrama de Casos de Uso 1. DIAGRAMA DE CASOS DE USO DEL SISTEMA
El diagrama de casos de uso de sistema representa la forma en cómo un Cliente (Actor) opera con el sistema en desarrollo, además de la forma, tipo y orden en como los elementos interactúan (operaciones o casos de uso). El Modelo de Casos de Uso del sistema define y modela todos los elementos que describen los requerimientos funcionales del sistema. Modela la forma en que el sistema es usado por sus usuarios, clientes, patrocinadores, etc.
Muestra los roles y procesos e información que participan:
Directamente en
Comunicación con el usuario
el sistema.
final y el experto del dominio.
Credibilidad en una etapa Garantizar.
inicial del desarrollo del sistema.
Comprensión mutua de los requerimientos.
o Identifica:
Quién interactuará con el sistema.
Qué deberá hacer el sistema.
Qué interfaz deberá tener el sistema.
INGENIERÍA DE REQUERIMIENTOS
Página 95
UNIVERSIDAD PRIVADA TELESUP o Verifica: o
La captura de todos los requisitos.
o
Que los desarrolladores hayan entendido los requisitos apoyar.
o o
La etapa de pruebas. La planificación del proyecto
2. UN DIAGRAMA DE CASOS DE USO CONSTA DE LOS SIGUIENTES ELEMENTOS: Actor. Casos de Uso. Relaciones de Uso, Herencia y Comunicación.
2.1 Elementos a) Actor:
Una definición previa, es que un Actor es un rol que un usuario juega con respecto al sistema. Es importante destacar el uso de la palabra rol, pues con esto se especifica que un Actor no necesariamente representa a una persona en particular, sino más bien la labor que realiza frente al sistema. Un actor del sistema (actor) representa un rol (humano, software o hardware) externo al sistema con el que se establece intercambio directo de información.
INGENIERÍA DE REQUERIMIENTOS
Página 96
UNIVERSIDAD PRIVADA TELESUP Ejemplo: Vendedor. Jefe de Almacén. Asisten de Producción. Como ejemplo a la definición anterior, tenemos el caso de un sistema de ventas en que el rol de Vendedor con respecto al sistema puede ser realizado por un Vendedor o bien por el Jefe de Local. ¿Dónde encontrar a los actores del sistema? Trabajadores del negocio (bussiness workers). Por cada trabajador del negocio con actividades a automatizar identificar a un actor del sistema. Dar al actor del sistema el mismo nombre del trabajador del negocio.
Otros elementos que ayudan a encontrar a los actores del sistema. Personas que usan el sistema. Personas que interactuarán con el sistema. Personas que proveen información al sistema. Usuarios que requieren ayuda de parte del sistema para poder desarrollar sus actividades o tareas.
Usuarios que se requieren para ejecutar las funciones principales o más obvias del sistema. Usuarios
que
se
requieren
para
desarrollar
funciones secundarias, tales como mantenimiento y administración del sistema. Personas que instalarán el sistema. Sistemas de software externos a la frontera del sistema con los que el sistema requiera interactuar Hardware externo a la frontera del sistema con el que el sistema requiera interactuar.
INGENIERÍA DE REQUERIMIENTOS
Página 97
UNIVERSIDAD PRIVADA TELESUP b) Caso de Uso:
Es una operación/tarea específica que se realiza tras una orden de algún agente externo, sea desde una petición de un actor o bien desde la invocación desde otro caso de uso.
Un caso de uso del sistema identifica:
o
Es un proceso específico del sistema con identidad propia.
o Define
una secuencia de acciones que el sistema realiza para un actor en
particular.
o Define la interacción con el actor correspondiente. o Produce un resultado observable y
esperado para el actor correspondiente.
Los casos de uso requieren tener al menos un conocimiento parcial de los requerimientos del sistema. Un caso de uso es un documento narrativo que describe la secuencia de eventos de un actor (agente externo) que utiliza un sistema para completar un proceso.
Se representa en el diagrama por una elipse, denota un requerimiento solucionado por el sistema. Cada caso de uso es una operación completa desarrollada por los actores y por el sistema en un diálogo. El conjunto de casos de uso representa la totalidad de operaciones
desarrolladas
por
el
sistema.
Va
acompañado de un nombre significativo.
INGENIERÍA DE REQUERIMIENTOS
Página 98
UNIVERSIDAD PRIVADA TELESUP El formato para la descripción de los casos de uso es el siguiente: Caso de uso
: Nombre
Actores
: Lista de actores (agentes externos)
Propósito
: Intención del caso de uso
c) Relaciones: ASOCIACIÓN Es el tipo de relación más básica que indica la invocación desde un actor o caso de uso a otra operación (caso de uso). Dicha relación se denota con una flecha simple. Las asociaciones entre casos de uso pueden ser de tres tipos.
Asociación de inclusión (include).
Asociación de extensión (extended).
Asociación de Generalización (herencia).
o
Asociación de inclusión (include)
Es una relación de dependencia entre dos
casos de uso.
El caso de uso base depende del caso de uso
incluido.
Se establece cuando el caso de uso base necesita incluir obligatoriamente la secuencia de acciones descritas por el caso de uso incluido.
Al caso de uso base solo le interesa el
resultado de la invocación del caso de uso incluido.
INGENIERÍA DE REQUERIMIENTOS
Página 99
UNIVERSIDAD PRIVADA TELESUP ¿Cuándo utilizar la inclusión? Cuando exista un comportamiento común a varios casos de uso (reuso). Las acciones similares en los casos de uso base se extraen al caso de uso incluido.
Cuando existen casos de uso complejos: Se simplifica el caso de uso base extrayendo parte de las acciones al caso de uso incluido.
La flecha se orienta de manera que indique que el caso de uso base es quien necesita incluir al caso de uso incluido.
Se utiliza el estereotipo <<include>> y se coloca encima de la flecha.
.
<<include>>
Caso de Uso base
Caso de Uso incluido
Ejemplo
Venta de productos y compra de insumos en un mercado.
Las acciones para “Realizar movimiento de producto” en su kardex respectivo puede separarse en un caso de uso independiente.
INGENIERÍA DE REQUERIMIENTOS
Página 100
UNIVERSIDAD PRIVADA TELESUP
<<include>>
Cajero
Realizar venta de producto
Realizar movimento de producto
<<include>>
Comprador
Realizar compra de insumos
o
Asociación de extensión (extended)
Es una relación de dependencia entre dos casos de uso.
El caso de uso extendido depende del caso de uso base.
Se establece cuando el caso de uso extendido ocurre excepcionalmente en el caso de uso base.
El caso de uso extendido ocurre solo cuando ocurra el evento respectivo dentro del caso de uso base.
Al caso de uso base solo le interesa el resultado de la invocación del caso de uso extendido.
<<extended>>
Caso de Uso base
INGENIERÍA DE REQUERIMIENTOS
Caso de Uso extendido Página 101
UNIVERSIDAD PRIVADA TELESUP
¿Cuándo utilizar la extensión?
o
Cuando exista un comportamiento común a varios casos de uso (reuso). Las acciones similares en los casos de uso base se extraen al caso de uso extendido.
o
Cuando existen casos de uso complejos: Se simplifica el caso de uso base extrayendo parte de las acciones al caso de uso extendido.
o
La flecha se orienta de manera que indique que el caso de uso extendido constituye la extensión del caso de uso base.
o
Se utiliza el estereotipo <<extended>> y se coloca encima de la flecha.
Ejemplo: o
Venta de productos y compra de insumos en un mercado.
o
Actualizar Tarjeta
Las acciones para “Actualizar <<extended>>
Tarjeta Bonus” puede
Bonus
separarse en un caso de uso independiente. Cajero
Realizar venta
<<include> >
de producto
Realizar movimento de producto
<<include>>
Comprad or
Realizar compra de insumos
INGENIERÍA DE REQUERIMIENTOS
Página 102
UNIVERSIDAD PRIVADA TELESUP
TEMA Modelo Conceptual
campus.utelesup.com
INGENIERร A DE REQUERIMIENTOS
Pรกgina 103
UNIVERSIDAD PRIVADA TELESUP
Tema 02: Modelo Conceptual 1. MODELO CONCEPTUAL Es un caso particular de Diagrama de Clases. Se colocan solamente los conceptos que manejarรก cada caso de uso. Los conceptos se convertirรกn en un futuro en las clases entidad del sistema para manejar los datos. Se incluyen las asociaciones
simples
entre
cada
concepto,
especificando
el
nombre,
navegabilidad y multiplicidad de la asociaciรณn.
2. ENTIDADES DEL NEGOCIO.
INGENIERร A DE REQUERIMIENTOS
Pรกgina 104
UNIVERSIDAD PRIVADA TELESUP OBJETIVOS
Identificar clases conceptuales relacionadas a un dominio del problema.
Identificar las relaciones entre clases.
Identificar las asociaciones, agregaciones y la Herencias entre clases.
Encontrar la multiplicidad entre clases.
Crear un modelo conceptual.
Un diagrama de Modelo Conceptual sirve para visualizar las relaciones entre las clases que involucran el sistema, las cuales pueden ser asociativas,
de
herencia,
de
uso
y
de
contenimiento.
3. ELEMENTOS 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.). En UML, una clase es representada por un rectángulo que posee tres divisiones: Ejemplo: Una Cuenta Corriente que posee como característica: Balance El diseño asociado es:
INGENIERÍA DE REQUERIMIENTOS
Página 105
UNIVERSIDAD PRIVADA TELESUP Atributos y Métodos: Atributos: Los atributos o características de una Clase pueden ser de tres tipos, los que definen el grado de comunicación y visibilidad de ellos con el entorno, estos son:
(+,
public
):
Indica que el atributo será visible tanto dentro como fuera de la clase, es decir, es accesible desde todos lados.
private
(-,):
Indica que el atributo sólo será accesible desde dentro de la clase (sólo sus métodos lo pueden accesar).
protected
(#,
)
Indica que el atributo no será accesible desde fuera de la clase, pero si podrá ser accesado por métodos de la clase además de las subclases que se deriven (ver herencia).
Métodos: Los métodos u operaciones de una clase son la forma en como ésta interactúa con su entorno, éstos pueden tener las características:
Public (+,
):
Indica que el método será visible tanto dentro como fuera de la clase, es decir, es accesible desde todos lados.
INGENIERÍA DE REQUERIMIENTOS
Página 106
UNIVERSIDAD PRIVADA TELESUP Private
(-,):
Indica que el método sólo será accesible desde dentro de la clase (sólo otros métodos de la clase lo pueden accesar).
Protected
(#,
):
Indica que el método no será accesible desde fuera de la clase, pero si podrá ser accesado por métodos de la clase además de métodos de las subclases que se deriven (ver herencia).
Relaciones entre Clases:
Ahora ya definido el concepto de Clase, es necesario
explicar
cómo
se
pueden
interrelacionar dos o más clases (cada uno con características y objetivos diferentes).
Antes es necesario explicar el concepto de cardinalidad de relaciones: En UML, la cardinalidad de las relaciones indica el grado y nivel de dependencia, se anotan en cada extremo de la relación y éstas pueden ser: uno o muchos: 1..* (1..n) 0 o muchos: 0..* (0..n) número fijo: m (m denota el número).
INGENIERÍA DE REQUERIMIENTOS
Página 107
UNIVERSIDAD PRIVADA TELESUP Herencia (Especialización/Generalización): Indica que una subclase hereda los métodos y atributos especificados por una Super Clase, por ende la Subclase además de poseer sus propios métodos y atributos, poseerá las características y atributos visibles de la Super Clase (public y protected),
Ejemplo:
En la figura se especifica que Auto y Camión heredan de Vehículo, es decir, Auto posee las Características de Vehículo (Precio, VelMax, etc) además
posee
Descapotable,
en
algo
particular
cambio
Camión
que
es
también
hereda las características de Vehiculo (Precio, VelMax, etc) pero posee como particularidad propia Acoplado, Tara y Carga.
INGENIERÍA DE REQUERIMIENTOS
Página 108
UNIVERSIDAD PRIVADA TELESUP Agregación:
Para modelar objetos complejos, n bastan los tipos de datos básicos que proveen los lenguajes: enteros, reales y secuencias de caracteres. Cuando se requiere componer objetos que son instancias de clases definidas por el desarrollador de la aplicación, tenemos dos posibilidades: Por Valor:
o
Por Valor:
Es un tipo de relación estática, en donde el tiempo de vida del objeto incluido está condicionado por el tiempo de vida del que lo incluye. Este tipo de relación es comúnmente llamada Composición (el Objeto base se construye a partir del objeto incluido, es decir, es "parte/todo").
o
Por Referencia: :
Es un tipo de relación dinámica, en donde el tiempo de vida del objeto incluido es independiente del que lo incluye. Este tipo de relación es comúnmente llamada Agregación (el objeto base utiliza al incluido para su funcionamiento).
Un Ejemplo es el siguiente:
INGENIERÍA DE REQUERIMIENTOS
Página 109
UNIVERSIDAD PRIVADA TELESUP Asociación: La relación entre clases conocida como Asociación, permite asociar objetos que colaboran entre sí. Cabe destacar que no es una relación fuerte, es decir, el tiempo de vida de un objeto no depende del otro.
Ejemplo:
Un cliente puede tener asociadas muchas Órdenes de Compra, en cambio una orden de compra solo puede tener asociado un cliente.
Ejemplo de un Modelo Conceptual
INGENIERÍA DE REQUERIMIENTOS
Página 110
UNIVERSIDAD PRIVADA TELESUP
TEMA Modelo de Anรกlisis de Objetos
campus.utelesup.com
INGENIERร A DE REQUERIMIENTOS
Pรกgina 111
UNIVERSIDAD PRIVADA TELESUP
Tema 03: Modelo de Análisis de Objetos MODELO DE ANÁLISIS Cuando ya se ha desarrollado y aceptado el modelo de requisitos se comienza el desarrollo del modelo de análisis.
El objetivo del modelo de análisis es comprender y generar una arquitectura de objetos para el sistema en base a lo especificado en el modelo de requisitos. Durante esta etapa no se considera el ambiente de implementación, lo cual incluye al lenguaje de programación, manejador de base de datos, distribución o configuración de hardware, etc.
En otras palabras el análisis pretende modelar el
sistema
bajo
condiciones
ideales,
garantizando que la arquitectura de software resultante
se
suficientemente
robusta
y
extensible para servir de base a la estructura lógica de la aplicación pero sin consideraciones relativas al entorno de implementación que es posible que cambien incluso radicalmente.
Tarde o temprano el sistema tendrá que ser adaptado a las condiciones de implementación deseadas, algo que se hará durante el diseño, cuando todas las consideraciones que han sido descartadas durante el análisis sean consideradas.
Análisis.- Es necesaria una descripción del problema y de los requerimientos. ¿Qué problema vamos a resolver? ¿Qué debe hacer el sistema?
INGENIERÍA DE REQUERIMIENTOS
Página 112
UNIVERSIDAD PRIVADA TELESUP
REALIZACIÓN DE UN CASO DE USO:
o
Describe como un caso de uso es implementado (realizado) por las interacciones entre los objetos (colaboración).
o
En el modelo del análisis los casos de uso son realizados por los objetos instancias de las clases del análisis. En el modelo del diseño los casos de uso son realizados por los objetos instancias de las clases del diseño.
CLASES CON ESTEREOTIPOS El tipo de funcionalidad o “la razón de ser” de un objeto dentro de una arquitectura se le conoce como su estereotipo. Para los sistemas de información la arquitectura del sistema según nuestro modelo de análisis se basa en tres estereotipos básicos de objetos:
o El estereotipo entidad (“entity” en inglés) Para objetos que guarden información sobre el estado interno
del
sistema,
a
corto
correspondiente
al
dominio
comportamiento
naturalmente
del
y
largo
problema.
acoplado
con
plazo, Todo esta
información también se incluye en los objeto entidad. Un ejemplo de un objeto entidad es un registro de usuario con sus datos y comportamiento asociados.
INGENIERÍA DE REQUERIMIENTOS
Página 113
UNIVERSIDAD PRIVADA TELESUP o El estereotipo interface o borde (“boundary” en inglés) Para objetos que implementen la presentación o vista correspondiente a las bordes del sistema hacia el mundo externo, para todo tipo de actores, no sólo usuarios humanos. Un ejemplo de un objeto borde es la funcionalidad de interface de usuario para insertar o modificar información sobre el registro de usuario.
o El estereotipo control (“control” en inglés) Para objetos que implementen el comportamiento o control especificando cuando y como el sistema cambia de estado, correspondiente a los casos de uso.
Los objetos control modelan funcionalidad que no se liga naturalmente con ningún otro tipo de objeto, como el comportamiento que opera en varios objetos entidad a la vez, por ejemplo, hacer alguna computación y luego devolver el resultado a un objeto borde.
Un ejemplo típico de objeto control es analizar el uso del sistema por parte de algún usuario registrado
y
posteriormente.
presentar Este
tal
información
comportamiento
no
le
pertenece a ningún objeto entidad u objeto borde específico.
INGENIERÍA DE REQUERIMIENTOS
Página 114
UNIVERSIDAD PRIVADA TELESUP
DIAGRAMA DE CLASES DE ANÁLISIS
Este diagrama relaciona a los actores de sistema con las clases de análisis Interfaz, control y entidad.
INGENIERÍA DE REQUERIMIENTOS
Página 115
UNIVERSIDAD PRIVADA TELESUP
TEMA Diagrama de Secuencia
INGENIERร A DE REQUERIMIENTOS
Pรกgina 116
UNIVERSIDAD PRIVADA TELESUP
Tema 04: Diagrama de Secuencia DIAGRAMA DE SECUENCIA
Un diagrama de secuencia es una forma de diagrama de interacción que muestra los objetos como líneas de vida a lo largo de la página y con sus interacciones en el tiempo representadas como mensajes dibujados como flechas desde la línea de vida origen hasta la línea de vida destino.
Los diagramas de secuencia son buenos para mostrar qué objetos se comunican con qué otros objetos
y
qué
mensajes
disparan
esas
comunicaciones. Los diagramas de secuencia no están
pensados
para
mostrar
lógicas
de
procedimientos complejos.
LÍNEA DE VIDA Una línea de vida representa un participante individual en un diagrama de secuencia. Una línea de vida usualmente tiene un rectángulo que contiene el nombre del objeto. Si el nombre es self entonces eso indica que la línea de vida representa el clasificador que posee el diagrama de secuencia.
Líneas de Vida:
INGENIERÍA DE REQUERIMIENTOS
Página 117
UNIVERSIDAD PRIVADA TELESUP Algunas veces un diagrama de secuencia tendrá una línea de vida con un símbolo del elemento actor en la parte superior. Este usualmente sería el caso si un diagrama de secuencia es contenido por un caso de uso. Los elementos entidad, control y límite de los diagramas de robustez también pueden contener líneas de vida.
Otras Líneas de Vida:
MENSAJES Los mensajes se muestran como flechas. Los mensajes pueden ser completos, perdidos o encontrados; síncronos o asíncronos: llamadas o señales. En el siguiente diagrama, el primer mensaje es un mensaje síncrono (denotado por una punta de flecha oscura), completo con un mensaje de retorno implícito; el segundo mensaje es asíncrono (denotado por una punta de flecha en línea) y el tercero es un mensaje de retorno asíncrono (denotado por una línea punteada).
INGENIERÍA DE REQUERIMIENTOS
Página 118
UNIVERSIDAD PRIVADA TELESUP
OCURRENCIA DE EJECUCIÓN Un rectángulo fino a lo largo de la línea de vida denota la ocurrencia de ejecución o activación de un foco de control. En el diagrama anterior hay tres ocurrencias de ejecución. El primero es el objeto origen que envía dos mensajes y recibe dos respuestas, el segundo es el objeto
destino que recibe un mensaje
asíncrono y retorna una respuesta, y el tercero es el objeto destino que recibe un mensaje asíncrono y retorna una respuesta.
MENSAJE SELF
Un mensaje self puede representar una llamada recursiva
de
una
operación, o un método llamando a otro método perteneciente
al
mismo
objeto. Este se muestra como cuando crea un foco de control anidado en la ocurrencia de ejecución de la línea de vida.
INGENIERÍA DE REQUERIMIENTOS
Página 119
UNIVERSIDAD PRIVADA TELESUP MENSAJES PERDIDOS Y ENCONTRADOS Los
mensajes
perdidos
son
aquellos que han sido enviados pero que no han llegado al destino esperado, o que han llegado a un destino que no se muestra en el diagrama actual. Los mensajes encontrados
son
aquellos
que
llegan
un
remitente
no
de
conocido, o de un remitente no conocido en el diagrama actual. Ellos se denotan yendo o llegando desde un elemento de punto final.
INICIO Y FINAL DE LÍNEA DE VIDA
Una línea de vida se puede crear o destruir durante la escala de tiempo representada por un diagrama de secuencia. En el último caso, la línea de vida se termina por un símbolo de detención, representado como una cruz. En el primer caso, el símbolo al inicio de la línea de vida se muestra en un nivel más bajo de la página que el símbolo del objeto que causó la creación. El siguiente diagrama muestra un objeto que fue creado y destruido.
INGENIERÍA DE REQUERIMIENTOS
Página 120
UNIVERSIDAD PRIVADA TELESUP LECTURAS RECOMENDADAS Diagrama de casos de uso del sistema http://www.clikear.com/manuales/uml/diagramascasouso.aspx
Modelo conceptual http://www.vico.org/aRecursosPrivats/UML_TRAD/talleres/mapas/UMLTRAD_ 101A/LinkedDocuments/UML_diagClases.pdf
Modelo de análisis de objetos http://www.adrformacion.com/cursos/uml/leccion1/tutorial2.html http://www.chaco.gov.ar/utn/disenodesistemas/apuntes/oo/ApunteUML.pdf
Diagrama secuencia http://www.scribd.com/doc/15493687/DIAGRAMAS-DE-SECUENCIA
ACTIVIDADES Y EJERCICIOS
1. Enumere 5 atributos de la clase alumno, 5 atributos de la clase matricula y 5 atributos de la clases profesor. Realiza esta actividad a través de “Atributos de la clase”.
2. Enumere 5 clases de interfaz, 5 clases de Control y5 clases de Entidad que encuentre en un sistema que conozca. Realiza la actividad y envíala a través de “Clases”.
INGENIERÍA DE REQUERIMIENTOS
Página 121
UNIVERSIDAD PRIVADA TELESUP AUTOEVALUACIÓN 1.- ¿Cuándo se debe utilizar la inclusión? a. b. c. d. e.
Cuando exista un comportamiento común a varios casos de uso Cuando exista un comportamiento diferente Cuando exista un comportamiento diferente en un caso de uso Cuando no exista un comportamiento común a varios casos de uso Cuando el comportamiento es homogéneo
2.- ¿Qué representa el sistema de casos de uso? a. b. c. d. e.
Representa la forma como un actor interactúa con el sistema en desarrollo Representa al sistema y no al actor Representa al actor Define los elementos fundamentales Expresa las actitudes del actor
3.- ¿Qué identifica los casos de uso del sistema? a. Quien interactúa con el sistema. b. Quien interactúa con el sistema, qué deberá hacer el sistema, Qué interfaz deberá tener el sistema. c. Qué deberá hacer el sistema. d. Interfaz deberá tener el sistema, qué deberá hacer el sistema. e. Interfaz deberá tener el sistema, quién interactúa con el sistema.
4.- ¿Qué modelo me permite comprender y generar una arquitectura de objetos para el sistema en base a lo especificado en el modelo de requisitos? a. Modelo de Casos de Uso de Sistema b. Modelo de Negocio c. Modelo de Análisis d. Modelo de Diseño e. Modelo de diseño relacional
5.- ¿Qué artefacto de UML permite a los objetos guardar información sobre el estado interno del sistema? a. b. c. d. e.
Entidad Control Interfaz Clases Clases abstractas
INGENIERÍA DE REQUERIMIENTOS
Página 122
UNIVERSIDAD PRIVADA TELESUP 6.- ¿Qué diagrama relaciona a los actores de sistema con las clases de análisis? a. Diagrama de clases de Análisis b. Diagrama de Casos de Uso c. Diagrama de estados d. Diagrama de actividades e. Diagrama de moléculas del sistema 7.- El modelo conceptual es un caso particular de … a. Un diagrama de clases b. Un diagrama natural c. Un diagrama de casos de uso d. Un diagrama de objeto relación e. Una clase de uso
8.- ¿Cuáles son los elementos de una clase? a. Clase, atributos y operaciones b. Solo las clases c. No es clase ni atributo solo operaciones d. Atributos y operaciones e. Solo atributos, operaciones, y contexto
9.- ¿Qué diagrama de interacción que muestra los objetos como líneas de vida a lo largo de la página y con sus interacciones en el tiempo representadas como mensajes dibujados como flechas desde la línea de vida origen hasta la línea de vida destino? a. Diagrama de Secuencia b. Diagrama de Clases c. Diagrama de Casos de uso d. Diagrama de Estados e. Diagrama de cardos 10.- Son mostrados como flechas y pueden ser complejos, perdidos o encontrados, se refiere a: a. Mensajes b. Diagrama de Clases c. Diagrama de Casos de uso d. Diagrama de Estados e. Ocurrencia de Ejecución
INGENIERÍA DE REQUERIMIENTOS
Página 123
UNIVERSIDAD PRIVADA TELESUP RESUMEN
UNIDAD DE APRENDIZAJE III: El diagrama de casos de uso de sistema representa la forma en cómo un Cliente (Actor) opera con el sistema en desarrollo, además de la forma, tipo y orden en como los elementos interactúan (operaciones o casos de uso). Este consta de los siguientes elementos: Actor, Casos de Uso, Relaciones de Uso, Herencia y Comunicación. El Modelo de Casos de Uso del sistema define y modela todos los elementos que describen los requerimientos funcionales del sistema.Modela la forma en que el sistema es usado por sus usuarios, clientes, patrocinadores, etc.
El Modelo Conceptual es un caso particular de Diagrama de Clases. Se colocan solamente los conceptos que manejará cada caso de uso. Los conceptos se convertirán en un futuro en las clases entidad del sistema para manejar los datos. Se incluyen las asociaciones simples entre cada concepto, especificando el nombre, navegabilidad y multiplicidad de la asociación. Consta de los siguientes elementos: Clase, Atributos y Métodos, Herencia, Agregación, Asociación.
El objetivo del modelo de análisis es comprender y generar una arquitectura de objetos para el sistema en base a lo especificado en el modelo de requisitos pretende modelar el sistema bajo condiciones ideales, garantizando que la arquitectura de software resultante se suficientemente robusta y extensible para servir de base a la estructura lógica de la aplicación pero sin consideraciones relativas al entorno de implementación que es posible que cambien incluso radicalmente.
Un diagrama de secuencia es una forma de diagrama de interacción que muestra los objetos como líneas de vida a lo largo de la página y con sus interacciones en el tiempo representadas como mensajes dibujados como flechas desde la línea de vida origen hasta la línea de vida destino. Los diagramas de secuencia son buenos para mostrar qué objetos se comunican con qué otros objetos y qué mensajes disparan esas comunicaciones. INGENIERÍA DE REQUERIMIENTOS
Página 124
UNIVERSIDAD PRIVADA TELESUP
UNIDAD DE APRENDIZAJE
MODELO DE ANÁLISIS DE REQUERIMIENTOS AVANZADO
COMPETENCIA: Al finalizar esta unidad usted será capaz de: “Diseñar modelos de colaboraciones para entender la interacción entre los objetos del sistema, modelos lógicos de clases relacionándolos con el diseño obtenido en el modelo conceptual, diagramas de componentes y despliegue utilizando los modelos INGENIERÍA DE REQUERIMIENTOS Página 125 obtenidos hasta el momento y los requerimientos del cliente”.
UNIVERSIDAD PRIVADA TELESUP INTRODUCCIÓN
a. Presentación y contextualización El alumno desarrolla una actitud analítica y crítica que le permita valorar los conceptos de diseño de sistemas para las organizaciones en el mundo actual. Elabora diagramas de colaboraciones, modelos lógicos de clases, entiende los principios iníciales del diseño pero aplicado a los requerimientos y elabora los diagramas de componentes y despliegue.
b. Competencias Diseña modelos de colaboraciones para entender la interacción entre los objetos del sistema, modelos lógicos de clases relacionándolos con el diseño obtenido en el modelo conceptual, diagramas de componentes y despliegue utilizando los modelos obtenidos hasta el momento y los requerimientos del cliente.
c. Capacidades 1. Elabora y diseña modelos de colaboraciones para entender la interacción entre los objetos del sistema. 2. Diseña modelos lógicos de clases relacionándolos con el diseño obtenido en el modelo conceptual. 3. Entiende el modelo básico de diseño y lo relaciona con la captura de requisitos. 4. Diseña diagramas de componentes y despliegue utilizando los modelos obtenidos hasta el momento y los requerimientos del cliente.
d. Actitudes Desarrolla una actitud emprendedora mediante la toma de iniciativas, promoción de actividades y toma de decisiones en relación a la actividad asignada. Actúa con responsabilidad personal, al cumplir con los horarios establecidos y el respeto a las normas de convivencia. Cumple con la presentación de los trabajos encomendados de manera individual y en equipo, respetando la iniciativa y aportes de los integrantes. Desarrolla la creatividad, la innovación, la actitud emprendedora y el respeto a la honestidad intelectual.
e. Presentación de ideas básicas y contenido La Unidad de Aprendizaje 4:
Modelo de Análisis de Requerimientos
Avanzado, comprende el desarrollo de los siguientes temas: TEMA 1: DIAGRAMA DE COLABORACIONES TEMA 2: MODELO LÓGICO DE CLASES TEMA 3: MODELO DE DISEÑO APLICADO A LOS REQUERIMIENTOS TEMA 4: DIAGRAMA DE COMPONENTES Y DESPLIEGUE INGENIERÍA DE REQUERIMIENTOS
Página 126
UNIVERSIDAD PRIVADA TELESUP
TEMA Diagrama de Colaboraciones
INGENIERร A DE REQUERIMIENTOS
Pรกgina 127
UNIVERSIDAD PRIVADA TELESUP DESARROLLO DE LOS TEMAS
Tema 1: Diagrama de Colaboraciones 1. DIAGRAMA DE COLABORACIONES
L
os diagramas de colaboración muestran las interacciones que ocurren entre
los objetos que participan en una situación determinada. Esta es más o menos la misma información que la mostrada por los diagramas de secuencia, pero destacando la forma en que las operaciones se producen en el tiempo, mientras que los diagramas de colaboración fijan el interés en las relaciones entre los objetos y su topología.
En los diagramas de colaboración los mensajes enviados de un objeto a otro se representan mediante flechas, mostrando el nombre del mensaje, los parámetros y la secuencia del mensaje. Los diagramas de colaboración están indicados para mostrar una situación o flujo programa específicos y son unos de los mejores tipos de diagramas para demostrar o explicar rápidamente un proceso dentro de la lógica del programa.
Comprender los patrones de interacción significa describir cómo se lleva a cabo o se ejecuta (o se instancia) una realización de caso de uso. Se utilizan los
diagramas
de
colaboración
para
modelar
las
interacciones entre objetos en el análisis.
Un diagrama de colaboración contiene instancias y clases, y muestra cómo interactúan los objetos secuencialmente o en paralelo, numerando los mensajes que se envían unos a otros.
INGENIERÍA DE REQUERIMIENTOS
Página 128
UNIVERSIDAD PRIVADA TELESUP 2. COMPONENTES o Objeto: Se representa con un rectángulo que contiene el nombre y la clase del objeto en un formato nombreObjeto : nombreClase.
o Enlaces: Un enlace es una instancia de una asociación en un diagrama de clases. Se representa como una línea continua que une a dos objetos, acompa nada por un número que indica el orden dentro de la interacción. Pueden darse varios niveles de subíndices para indicar anidamiento de operaciones. Se pueden utilizar estereotipos para indicar si el objeto que recibe el mensaje es un atributo, un parámetro de un mensaje anterior, si es un objeto local o global.
o Flujo de mensajes: Expresa el envío de un mensaje. Se representa mediante una flecha dirigida cerca de un enlace.
o Marcadores de creación y destrucción de objetos: Puede mostrarse en la gráfica qué objetos son creados y destruidos, agregando una restricción con la palabra new o delete respectivamente.
o Objeto compuesto: Es una representación alternativa de un objeto y sus atributos. En esta representación se muestran los objetos contenidos dentro del rectángulo que representa al objeto que los contiene.
Para representar la notación básica veamos el siguiente gráfico
INGENIERÍA DE REQUERIMIENTOS
Página 129
UNIVERSIDAD PRIVADA TELESUP
Para entender que representa cada figura veamos el gráfico
A continuación se observa un ejemplo completo:
Grafico donde se representa el diagrama de colaboración en UML V1.
A diferencia de los Diagramas de Secuencia, los Diagramas de Colaboración muestran las relaciones entre los roles de los objetos. La secuencia de los mensajes y los flujos de ejecución concurrentes deben determinarse explícitamente mediante números de secuencia.
INGENIERÍA DE REQUERIMIENTOS
Página 130
UNIVERSIDAD PRIVADA TELESUP
En cuanto a la representación, un Diagrama de Colaboración muestra a una serie de objetos con los enlaces entre los mismos, y con los mensajes que se intercambian dichos objetos. Los mensajes son flechas que van junto al enlace por el que “circulan”, y con el nombre del mensaje y los parámetros (si los tiene) entre paréntesis. Cada mensaje lleva un número de secuencia que denota cuál es el mensaje que le precede, excepto el mensaje que inicia el diagrama, que no lleva número de secuencia. Se pueden indicar alternativas con condiciones entre corchetes (por ejemplo 3 [condición_de_test] : nombre_de_método() ), tal y como aparece en el ejemplo de la Figura. También se puede mostrar el anidamiento de mensajes con números de secuencia como 3.1, que significa que el mensaje con número de secuencia 3 no acaba de ejecutarse hasta que no se han ejecutado todos los 3.x.
INGENIERÍA DE REQUERIMIENTOS
Página 131
UNIVERSIDAD PRIVADA TELESUP
TEMA Modelo Lรณgico de Clases
INGENIERร A DE REQUERIMIENTOS
Pรกgina 132
UNIVERSIDAD PRIVADA TELESUP
Tema 2: Modelo Lógico de Clases MODELO LÓGICO DE CLASES Es el proceso de construir un modelo de la información usada en la empresa, basado en un modelo
más
específico,
es
decir
es
una
representación relacionada al software que se desarrollará.
Modelo Lógico El modelo lógico queda representado de la siguiente forma:
OBJETIVOS:
o
Verificar la multiplicidad.
o
Agregar atributos a las clases.
o
Crear clases asociativas.
o
Eliminación de las Herencias.
o
Crear un modelo lógico.
INGENIERÍA DE REQUERIMIENTOS
Página 133
UNIVERSIDAD PRIVADA TELESUP Verificar la multiplicidad: La multiplicidad define cuantas instancias de la clase A pueden estar asociadas con una instancia de la clase B.
aloja
Almacen 1
Item *
Agregar atributos a las Clases:
Un atributo es un valor de dato lógico de un objeto.
Los atributos a agregar deben sugerir la necesidad de recordar información.
Crear Clase Asociativa: Modelo Conceptual
Cuando en el modelo Conceptual existe
una
multiplicidad
relación es
de
cuya
muchos
Tiene
Producto 1..*
Factura 1..*
a
Muchos para romper esa relación
Modelo Logico
en el Modelo Lógico se crea una clase intermedia llamada Clase Asociativa. En una asociación de
Tiene
Producto
muchos a muchos entre dos clases
1..*
Factura 1..*
y existe información asociada con la propia asociación. Un atributo
FacturaProducto
está relacionado con la asociación.
Las instancias de la clase asociativa dependen del tiempo de vida de la asociación.
INGENIERÍA DE REQUERIMIENTOS
Página 134
UNIVERSIDAD PRIVADA TELESUP
Eliminación de las Herencias: Para eliminar las herencias en el modelo Lógico se busca un característica especial de las clases hijas y por esa característica se crea una clase en donde la clase Padre apunta a la característica encontrada.
INGENIERÍA DE REQUERIMIENTOS
Página 135
UNIVERSIDAD PRIVADA TELESUP
Para desaparecer una herencia múltiple se tiene que buscar una condición o cdiscriminante por cada nivel de herencia y esta condición o discriminante será una nueva clase en el modelo lógico y la clase padre está apuntando a la clase condición.
INGENIERÍA DE REQUERIMIENTOS
Página 136
UNIVERSIDAD PRIVADA TELESUP
TEMA Modelo de Diseño Aplicado a los Requerimientos
INGENIERÍA DE REQUERIMIENTOS
Página 137
UNIVERSIDAD PRIVADA TELESUP
Tema 3: Modelo de Diseño Aplicado a los Requerimientos
EL DISEÑO: En el Diseño es necesaria una descripción detallada
para desarrollar una
aplicación que cumpla con los requerimientos y restricciones. ¿Cómo el sistema propuesto cumple con los requerimientos? El DOO enfatiza la definición de modelos lógicos de SW que serán finalmente implementados en un lenguaje OO. Estos conceptos también cuentan con atributos y métodos. No olvidar => Diseño - ¿CÓMO?
PROCESO DIRIGIDO POR CASOS DE USO:
Los Casos de Uso son una técnica de captura de requisitos del sistema. Se define un Caso de Uso como un fragmento
de funcionalidad
del
sistema
que
proporciona al usuario un valor añadido. En RUP los Casos de Uso, no son sólo una herramienta para especificar los requisitos del sistema. También guían su diseño, implementación y prueba. Los Casos de Uso constituyen un elemento integrador y una guía del trabajo.
INGENIERÍA DE REQUERIMIENTOS
Página 138
UNIVERSIDAD PRIVADA TELESUP
TRAZABILIDAD A PARTIR DE CASOS DE USO: Los Casos de Uso no sólo inician el proceso de desarrollo sino que proporcionan un hilo conductor, permitiendo establecer trazabilidad entre los artefactos que son generados en las diferentes actividades del proceso de desarrollo. Como se muestra en la figura, basándose en los Casos de Uso se crean los modelos de análisis y diseño, luego la implementación que los lleva a cabo, y se verifica que efectivamente el producto implemente adecuadamente cada Caso de Uso. Todos los modelos deben estar sincronizados con el modelo de Casos de Uso.
ARTEFACTOS: 1) Modelo de diseño 2) Clase del diseño 3) Realización de caso de uso-diseño 4) Subsistema del diseño 5) Interfaz 6) Descripción de la arquitectura (vista del modelo de diseño) 7) Modelo de despliegue 8) Descripción de la arquitectura (vista del modelo de despliegue).
INGENIERÍA DE REQUERIMIENTOS
Página 139
UNIVERSIDAD PRIVADA TELESUP
MODELO DE DISEÑO:
Proporciona una realización física de la realización de caso de uso-análisis para el que es trazado. Una realización de casos de uso-diseño proporciona una traza directa a una realización de caso de uso-análisis del modelo de análisis.
INGENIERÍA DE REQUERIMIENTOS
Página 140
UNIVERSIDAD PRIVADA TELESUP
¿CÓMO ORGANIZAR LA ARQUITECTURA?
Una “Arquitectura de capas”, se define como aquella arquitectura de software que lo organiza en capas, donde cada capa se construye sobre otras más general. Una capa puede ser definida como un conjunto de sistemas o subsistemas con el mismo grado de generalidad.
Las capas superiores son más específicas a la aplicación, las inferiores son más generales.
a. La capa de aplicación, contiene los servicios específicos de la aplicación. La siguiente capa, contiene los componentes específicos del negocio, usados en varias aplicaciones.
b. La
capa
Middleware
contiene
componentes
como:
creadores de la GUI, interfaces a los sistemas, manejadores de datos y los componentes OLE.
c. La capa inferior, contiene los sistemas operativos, las bases de datos, las interfaces con los dispositivos de hardware entre otros.
INGENIERÍA DE REQUERIMIENTOS
Página 141
UNIVERSIDAD PRIVADA TELESUP
TEMA Diagrama de Componentes y Despliegue
INGENIERร A DE REQUERIMIENTOS
Pรกgina 142
UNIVERSIDAD PRIVADA TELESUP
Tema 4: Diagrama de Componentes y Despliegue 1. DIAGRAMA DE COMPONENTES Se utilizan para modelar la vista estática de un sistema. Muestra la organización y las dependencias entre un conjunto de componentes. No es necesario que un diagrama incluya todos los componentes del sistema, normalmente se realizan por partes. Cada diagrama describe un apartado del sistema. En el situaremos librerías, tablas archivos, ejecutables y documentos que formen parte del sistema.
2. COMPONENTES Un componente de software puede definirse como una pieza no trivial del software, un módulo o un subsistema que completa una función clara, tiene límites claros y puede ser integrado en una arquitectura bien definida. Es una unidad de código fuente que se utiliza como bloque de construcción para la estructura física del sistema. Uno de los usos principales es que puede servir para ver que componentes pueden compartirse entre sistemas
o entre
diferentes partes de un sistema.
Aquí tenemos un componente del sistema de Windows. En el diagrama de componentes de Windows debe salir este componente, ya que sin el sistema no funcionaría.
INGENIERÍA DE REQUERIMIENTOS
Página 143
UNIVERSIDAD PRIVADA TELESUP
En esta otra figura tenemos el mismo componente, pero indicamos que dispone de un interface. Al ser una Dll el interface nos da acceso a su contenido. Esto nos hace pensar que la representación anterior es incorrecta, pero no es así solo corresponde a un nivel diferente de detalle.
Como ya hemos indicado antes todo objeto UML puede ser modificado mediante estereotipos, los estándares que define UML son:
Executable
Library
Table
File
Document.
Aunque por suerte no estamos limitados a estas especificaciones. Qué pasa si queremos modelar un proyecto de Internet donde nuestros componentes son ASP, HTML, y Scripts, y queremos marcarlo en el modelo. Pues utilizamos un estereotipo. Existe ya unos definidos WAE (Web Applications Extensión).
Podemos modelar diferentes partes de nuestro sistema, y modelar diferentes entidades que no tiene nada que ver entre ellas.
Ejecutables y bibliotecas.
Tablas.
API
Código fuente.
Hojas HTML.
3. EJECUTABLES Nos facilita la distribución de ejecutables a los clientes. Documenta sus necesidades y dependencias. Si disponemos de un ejecutable que solo se necesita al mismo para funcionar no necesitaremos el diagrama de componentes.
INGENIERÍA DE REQUERIMIENTOS
Página 144
UNIVERSIDAD PRIVADA TELESUP Los pasos a seguir para modelar, a priori no a posteriori, son:
Identificar los componentes, las particiones del sistema, cuales son factibles de ser reutilizadas. Agruparlos por nodos y realizar un diagrama por cada nodo que se quiera modelar.
Identificar cada componente con su estereotipo correspondiente.
Considerar las relaciones entre componentes
4. DIAGRAMAS DE DESPLIEGUE En el diagrama de despliegue se indica la situación física de los componentes lógicos desarrollados. Es decir se sitúa el software en el hardware que lo contiene. Cada Hardware se representa como un nodo.
Un nodo es un objeto físico que representa alguna clase de unidad de cómputo, en la mayoría de los casos se trata de una pieza de hardware.
Una conexión indica una comunicación entre nodos.
Ejemplo 1:
INGENIERÍA DE REQUERIMIENTOS
Página 145
UNIVERSIDAD PRIVADA TELESUP
5. PROCESO Y PROCESADOR Un proceso es la ejecución de un hilo de control. Los objetos son asignados a los procesos. Los procesos son asignados a procesadores.
Ejemplo 2 Nodos y Componentes
Un nodo se representa como un cubo, un nodo es un elemento donde se ejecutan los componentes,
representan
el
despliegue
físico de estos componentes.
Aquí tenemos dos nodos, el cliente y el servidor, cada uno de ellos contiene componentes. El componente del cliente utiliza un interface de uno de los componentes del servidor. Se muestra la relación existente entre los dos Nodos. Esta relación podríamos asociarle un estereotipo para indicar que tipo de conexión disponemos entre el cliente y el servidor, así como modificar su cardinalidad,
para
indicar
que
soportamos
diversos clientes.
INGENIERÍA DE REQUERIMIENTOS
Página 146
UNIVERSIDAD PRIVADA TELESUP
Como los componentes pueden residir en más de un nodo podemos situar el componente de forma independiente, sin que pertenezca a ningún nodo, y relacionarlo con los nodos en los que se sitúa.
LECTURAS RECOMENDADAS
Diagrama de colaboraciones
http://es.wikipedia.org/wiki/Diagrama_de_colaboraci%C3%B3n
Modelo lógico de clases
http://www.sparxsystems.com.ar/downloads/whitepapers/El_Modelo_Logi co.pdf
Modelo de diseño aplicado a los requerimientos
http://sisbib.unmsm.edu.pe/bibvirtualdata/tesis/basic/mendoza_nj/cap5. pdf
Diagrama de componentes y despliegue
http://www.info-ab.uclm.es/asignaturas/42530/pdf/M2tema12.pdf
Curso de UML
http://es.scribd.com/doc/13500210/actividad6-diagrama-de-componentes-ydespliegues
INGENIERÍA DE REQUERIMIENTOS
Página 147
UNIVERSIDAD PRIVADA TELESUP ACTIVIDADES Y EJERCICIOS
1. Enumere 5 Nodos para una red de computadoras para el área académica de un instituto. Realiza esta actividad a través de “Nodos”. 2. Enumere 5 clases para un negocio de su preferencia. Realiza esta actividad a través de “Negocio”. 3. Enumere 3 atributos para la clase alumno, con sus respectivas operaciones. Realiza esta actividad a través de “Clase alumno”.
AUTOEVALUACIÓN
1. ¿Qué diagrama muestra cómo interactúan los objetos secuencialmente o en paralelo y numera los mensajes enviados? a. El diagrama de clases b. El diagrama de casos de uso c. El diagrama de despliegue d. El diagrama de interacción e. El diagrama de colaboración
2. ¿Qué diagrama indica la situación física de los componentes lógicos desarrollados? a. Diagrama de Despliegue b. Diagrama de Componentes c. Diagrama de Casos de uso d. Diagrama de Estados e. Diagrama de estados y casos de uso
INGENIERÍA DE REQUERIMIENTOS
Página 148
UNIVERSIDAD PRIVADA TELESUP 3. ¿Cuáles son todos los componentes de un diagrama de colaboraciones? a. Objeto, enlaces, flujo de mensajes, marcadores de creación y objetos compuesto b. enlaces, flujo de mensajes, marcadores de creación y objetos compuesto c. Objeto, enlaces, flujo de mensajes d. Objeto, enlaces, marcadores de creación y objetos compuesto e. Objeto, enlaces, flujo de mensajes, marcadores de creación y objetos compuesto, flujogramas especiales de la nasa
4. ¿Cuáles son los objetivos de un diagrama lógico de clases? a. Verificar la multiplicidad, agregar atributos a las clases, crear clases asociativas, eliminación de las herencias, crear un modelo lógico b. Agregar atributos a las clases, crear clases asociativas, eliminación de las herencias, crear un modelo lógico c. Verificar la multiplicidad, crear clases asociativas, eliminación de las herencias, crear un modelo lógico d. Verificar la multiplicidad, agregar atributos a las clases, crear clases asociativas e. Verificar la multiplicidad, agregar atributos a las clases, crear clases asociativas, eliminación de las herencias, crear un modelo lógico y clases abstractas
5. ¿Qué tipo de clase se forma cuando se rompe una relación de muchos a muchos? a. Clase asociativa b. Clase padre c. Clase recursiva d. Clase con Restricciones e. Clase rota
6. ¿Cuál de los siguientes conceptos define el diseño? a. Cumple con las restricciones del sistemas solamente b. No cumple con las restricciones del sistema c. Cumple con los requerimientos y restricciones del modelo de requerimientos d. Cumple solo con los requerimientos e. No es importante el diseño
INGENIERÍA DE REQUERIMIENTOS
Página 149
UNIVERSIDAD PRIVADA TELESUP 7. ¿Cuáles son los artefactos del diseño? a. Modelo de diseño, clase del diseño, realización de caso de uso-diseño, subsistema del diseño, interfaz, descripción de la arquitectura, modelo de despliegue, vista del modelo de despliegue b. Modelo de diseño, clase del diseño, realización de caso de uso-diseño, subsistema del diseño, interfaz, descripción de la arquitectura, modelo de despliegue c. Modelo de diseño, clase del diseño, realización de caso de uso-diseño, subsistema del diseño, interfaz, descripción de la arquitectura d. Clase del diseño, realización de caso de uso-diseño, subsistema del diseño, interfaz, descripción de la arquitectura, modelo de despliegue, vista del modelo de despliegue e. Realización de caso de uso-diseño, subsistema del diseño, interfaz, descripción de la arquitectura, modelo de despliegue, vista del modelo de despliegue
8. ¿Cuál de los siguientes enunciados se acerca más a la definición de una capa? a. Subsistemas con el mismo grado de generalidad b. Conjunto de sistemas o subsistemas con el mismo grado de generalidad c. Mismo grado de generalidad en los sistemas d. Conjunto de sistemas o subsistemas e. Conjunto de sistemas expertos
9. ¿Qué artefacto de UML es un objeto físico que representa alguna clase de unidad de cómputo, en la mayoría de los casos se trata de una pieza de hardware? a. Control b. Nodo c. Intefaz d. Clases e. Interfaces y control
10. ¿Se define como una pieza no trivial del software, un módulo o un subsistema que completa una función clara? a. Componentes b. Tabla c. Caso de uso d. Nodo e. Nodo y tablas
INGENIERÍA DE REQUERIMIENTOS
Página 150
UNIVERSIDAD PRIVADA TELESUP RESUMEN
UNIDAD DE APRENDIZAJE Iv:
Los diagramas de colaboración muestran las interacciones que ocurren entre los objetos que participan en una situación determinada. Esta es más o menos la misma información que la mostrada por los diagramas de secuencia, pero destacando la forma en que las operaciones se producen en el tiempo, mientras que los diagramas de colaboración fijan el interés en las relaciones entre los objetos y su topología.
El modelo lógico de clases nos permite verificar la multiplicidad entre clases, agregar atributos a clases, crear clases asociativas, eliminación de herencias entre una clase padre y otra clase hija.
Respecto al modelo de diseño aplicado a los requerimientos cabe recalcar que para realizar el diseño es necesaria una descripción detallada
para desarrollar una
aplicación que cumpla con los requerimientos y restricciones.
En los Diagramas de componentes se utilizan para modelar la vista estática de un sistema. Muestra la organización y las dependencias entre un conjunto de componentes. No es necesario que un diagrama incluya todos los componentes del sistema, normalmente se realizan por partes. Cada diagrama describe un apartado del sistema. Por otro lado, en el diagrama de despliegue se indica la situación física de los componentes lógicos desarrollados. Es decir se sitúa el software en el hardware que lo contiene. Cada Hardware se representa como un nodo. Los desarrolladores de software utilizan herramientas de desarrollo orientada a objetos y usan el modelo lógico de clases para representar una visión global de la aplicación, mientras que el equipo de desarrollo de base de datos diseñan, modelan, construyen y optimizan la base de datos. Las áreas de interfaz y superposición entre estas dos distintas responsabilidades a menudo representan el aspecto más desafiante en el desarrollo de una aplicación de base de datos.
INGENIERÍA DE REQUERIMIENTOS
Página 151
UNIVERSIDAD PRIVADA TELESUP GLOSARIO o
LA CLASE INTERFAZ: Se utiliza para modelar la interacción entre el sistema y actores. Representan a menudo abstracciones de ventanas, formularios, paneles e interfaces de comunicación. Ejemplo: Interfaz de Mantenimiento Factura
o
LA CLASE CONTROL: Representan coordinación, secuencia, transiciones y control de otros objetos y se usa para encapsular el control de un caso de uso concreto. Ejemplo: Control de Garbado de factura
o
LA CLASE ENTIDAD: Modelan información y el comportamiento asociado de algún fenómeno o concepto como persona o un objeto. Ejemplo: Entidad Factura.
o
REALIZACIÓN DE DISEÑO: Proporciona una realización física de la realización de caso de uso-análisis para el que es trazado. Una realización de casos de uso-diseño proporciona una traza directa a una realización de caso de uso-análisis del modelo de análisis.
o
LA CAPA DE APLICACIÓN: Contiene los servicios específicos de la aplicación.
o
LA CAPA MIDDLEWARE: Contiene componentes como: creadores de la GUI, interfaces a los sistemas, manejadores de datos y los componentes OLE.
o
LA CAPA INFERIOR: Contiene los sistemas operativos, las bases de datos, las interfaces con los dispositivos de hardware entre otros.
INGENIERÍA DE REQUERIMIENTOS
Página 152
UNIVERSIDAD PRIVADA TELESUP o
OBJETO: Un
objeto
tiene
estado,
comportamiento,
e
identidad;
la
estructura
y
comportamiento de objetos similares son definidos en su clase común; los términos instancia y objeto son intercambiables.
o
MODELO CONCEPTUAL: Es un caso particular de Diagrama de Clases. Se colocan solamente los conceptos que manejará cada caso de uso. Los conceptos se convertirán en un futuro en las clases entidad del sistema para manejar los datos. Se incluyen las asociaciones simples entre cada concepto, especificando el nombre, navegabilidad y multiplicidad de la asociación.
o
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.).
INGENIERÍA DE REQUERIMIENTOS
Página 153
UNIVERSIDAD PRIVADA TELESUP
FUENTES DE INFORMACIÓN BIBLIOGRÁFICAS: PRESSMAN, Roger. “Ingeniería del Software. Un Enfoque Práctico”. 5ª ed. México: McGraw-Hill Latinoamericana, 2002. ISBN: 8448132149 (005.31/P85/E1) BOOCH, Grady et tal. “El Proceso Unificado de Desarrollo de Software”. 1ª ed. España: Editorial Addison-Wesley. LARMAN, Craig. UML y Patrones – Introducción al Análisis y Diseño Orientado a Objetos. 1ª ed. España: Pearson Educación. SENN, James. “Análisis y Diseño de Sistemas de Información”. México: Mc Graw Hill. ISBN: 9684229917 BRAUDE, J. “Ingeniería de Software: Una Perspectiva Orientada a Objetos” Ra-ma. ISBN: 8478975756. ISBN-13: 9788478975754 SOMMERVILLE, Ian “Ingeniería de Software: Un enfoque practico”, Eddison Wesley, México, 692 p
ELECTRONICAS: Ingeniería de requerimientos http://es.wikipedia.org/wiki/Ingenier%C3%ADa_de_requisitos Proceso de la ingeniería de requisitos http://danielvn7.wordpress.com/2008/03/27/proceso-de-la-ingenieria-derequisitos/ Clasificación y captura de requisitos http://www.fdi.ucm.es/profesor/gmendez/docs/is0809/03-Requisitos.pdf Modelo de requerimientos http://www.scribd.com/doc/14897162/Evaluacion-de-Requerimientos-para-unSistema-de-Informacion-de-Gestion-de-Recursos-Humanos http://www.monografias.com/trabajos6/resof/resof.shtml Métodos de recolección de información http://www.monografias.com/trabajos18/recoleccion-de-datos/recoleccion-dedatos.shtml Proceso unificado de desarrollo http://www.mitecnologico.com/Main/ElModeloProcesoUnificado INGENIERÍA DE REQUERIMIENTOS
Página 154
UNIVERSIDAD PRIVADA TELESUP Modelo de Proceso Unificado http://es.scribd.com/doc/35010781/Modelo-de-Proceso-Unificado Diagrama de casos de uso del negocio http://www.scribd.com/doc/13500172/actividad2-diagrama-de-casos-de-usodel-negocio-y-del-sistema Diagrama de casos de uso del sistema http://www.clikear.com/manuales/uml/diagramascasouso.aspx Modelo conceptual http://www.vico.org/aRecursosPrivats/UML_TRAD/talleres/mapas/UMLTRAD_1 01A/LinkedDocuments/UML_diagClases.pdf Modelo de análisis de objetos http://www.chaco.gov.ar/utn/disenodesistemas/apuntes/oo/ApunteUML.pdf Diagrama secuencia http://es.scribd.com/doc/15493687/DIAGRAMAS-DE-SECUENCIA Diagrama de colaboraciones http://es.wikipedia.org/wiki/Diagrama_de_colaboraci%C3%B3n Modelo lógico de clases http://www.sparxsystems.com.ar/downloads/whitepapers/El_Modelo_Logico.pdf Modelo de diseño aplicado a los requerimientos http://sisbib.unmsm.edu.pe/bibvirtualdata/tesis/basic/mendoza_nj/cap5.pdf Diagrama de componentes y despliegue http://www.info-ab.uclm.es/asignaturas/42530/pdf/M2tema12.pdf Curso de UML-Actividad 6 Diagramas de componentes y despliegue http://es.scribd.com/doc/13500210/actividad6-diagrama-de-componentes-ydespliegues
INGENIERÍA DE REQUERIMIENTOS
Página 155
UNIVERSIDAD PRIVADA TELESUP SOLUCIONARIO
UNIDAD DE APRENDIZAJE 1
UNIDAD DE APRENDIZAJE 2:
1. A
1. B
2. A
2. A
3. C
3. A
4. E
4. A
5. B
5. B
6. D
6. A
7. B
7. A
8. C
8. B
9. E
9. A
10. B
10. B
UNIDAD DE
UNIDAD DE
APRENDIZAJE 3:
APRENDIZAJE 4:
1. A
1. E
2. A
2. A
3. B
3. A
4. C
4. A
5. A
5. A
6. A
6. C
7. A
7. A
8. A
8. B
9. A
9. B
10. A
10. A
INGENIERร A DE REQUERIMIENTOS
Pรกgina 156