319397032 ingenieria de requerimientos

Page 1

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


Turn static files into dynamic content formats.

Create a flipbook
Issuu converts static files into: digital portfolios, online yearbooks, online catalogs, digital photo albums and more. Sign up and create your flipbook.