ingenieria requisitos

Tema 1

Requisitos de Software:

Conceptos, Tipos y Propiedades

Tema 1: Requisitos: Conceptos, Tipos y Propiedades

• El Modelado de Negocios (MN) y la Ingeniería de Requisitos (IR) son dos sub-disciplinas de la Ingeniería de Software (IS)– La primera – MN - está relacionada con el estudio del espacio del

problema en IS

– La segunda –IR- está asociada al problema de los requisitos y al espacio de la solución

• Cuando se aplican al desarrollo de software como procesos, el MN precede a la IR

3

Modelado del

Negocio

Ingeniería de

Requisitos

Tema 1: Requisitos: Conceptos, Tipos y Propiedades

• Una vez modelado el sistema de negocio donde se ubicará la aplicación, el proceso de Ingeniería de Requisitos se encarga de:

– Especificar las características de la aplicación

– Establecer los requisitos funcionales y no-funcionales que la aplicación debe satisfacer

4

¿Qué es un requisito de software?

• Perspectiva del usuario– Un requisito es una condición o capacidad de la aplicación

(o sistema de software) que necesita un usuario para resolver un problema o alcanzar un objetivo

• Perspectiva del desarrollador:– Es una condición o capacidad que debe ser satisfecha o

poseída por la aplicación, a fin de satisfacer un contrato, estándar, especificación u otro documento formalmente impuesto

• En ambos casos, es una representación documentadade una condición o capacidad que debe mostrar la aplicación en desarrollo

5

¿Qué es un requisito de software?

• Los requisitos expresan lo que una aplicación debe hacer para satisfacer necesidades de información de su dominio– Este dominio puede ser:

• Un sistema hardware/software– Dispositivo electrónico

– Celular

– Procesador dedicado, etc.

• Un sistema de negocios– Empresa

– Unidad organizacional

– Proceso de negocio, etc.

6

Sistema de Negocios

Sistema H/S

Aplicación

Requisitos de software

• Los requisitos definen:– Lo que la aplicación debe hacer

• Funciones que debe ejecutar• Datos que debe capturar y almacenar• Información que debe producir

– Las interacciones usuarios-aplicación y aplicación-aplicación• Interfaz gráfica usuario-aplicación (GUI)• Interfaz de la aplicación con otras aplicaciones o sistemas

– Las restricciones bajo las cuales la aplicación debe operar• Plataforma de operación de la aplicación(Hardware/Software)• Tecnología de información que debe usar

– Los atributos de calidad que la aplicación debe satisfacer• Seguridad, facilidad de uso, documentación, utilidad, etc.

7

Requisitos de Software

• Clasificación de los requisitos [Wiegers, 2003]

8

Requisito

Requisito Funcional

Requisito No-Funcional

Requisito del Negocio

Requisito del Usuario

Requisito del Sistema

Requisito de Comportamiento

Restricción Atributo de Calidad

Requisito de Interface

Regla de l Negocio

NO-FUNCIONALES– No están relacionados

directamente con el comportamiento de la aplicación

– Restringen el diseño de la aplicación (la solución)

• Establecen las limitaciones para su desarrollo

– Definen la calidad que la aplicación debe tener

FUNCIONALES– Establecen:

• los objetivos del negocio con respecto a la aplicación

• los servicios que la aplicación debe proporcionarle al negocio

– Determinan la funcionalidad de la aplicación

• Qué funciones debe ejecutar la aplicación

Tipos de requisitos de software

9

NO-FUNCIONALES– Describen:

• las restricciones que se le imponen a la aplicación

• las cualidades o atributos de calidad que la aplicación debe satisfacer

• Las reglas del negocio que la aplicación debe respetar o implementar

• Las interfaces con otros sistemas

FUNCIONALES– Describen lo que la

aplicación deberá hacer, esto es:

• Su comportamiento

• Su interacción con los usuarios y su dominio de aplicación (negocio)

• Sus respuestas a eventos

Diferencias entre los tipos de requisitos

10

Tipos de Requisitos Funcionales

• Requisitos del Negocio

– Se expresan desde la perspectiva de la empresa:

• Describen porque la empresa o el cliente desea desarrollar la aplicación

• Expresan que objetivos, metas o necesidades la empresa espera alcanzar con el uso de la aplicación

11


• Requisitos del Usuario– Se expresan desde la perspectiva del usuario:

• Describen las necesidades que los usuarios tienen y las tareas que los usuarios realizarán con la aplicación

• Expresan lo que el usuario será capaz de hacer con la aplicación

– Se modelan mediante casos de uso

– Ejemplos:• Hojear la mapoteca digital

• Visualizar un mapa

• Comprar un mapa

12


• Requisitos del Sistema– Están asociados a productos que tienen componentes

de hardware y software– Asumen que la aplicación es parte de un sistema

mayor, p.ej.:• Videojuegos, equipos de audio, etc.• Sistemas de información gerencial• Sistemas de control (Ej. Sensores/actuadores)

– Ejemplos de requisitos del sistema:• El sistema de control deberá disparar una alarma cada vez

que el sensor detecte una presión fuera del rango permisible

• La interfaz del celular debe bloquearse cada vez que el usuario presione simultáneamente el botón “Llamar” y la tecla *

13


• Requisitos de Comportamiento – Se expresan desde la perspectiva del desarrollador:

• Son requisitos funcionales propiamente dichos• Describen los servicios que la aplicación presta a todos sus

usuarios directos• Expresan que hace la aplicación bajo ciertos estímulos o

eventos (comportamiento del sistema)

– Ejemplos:• mimapa.com deberá permitir que el cliente efectúe el pago

de su pedido en línea usando tarjetas de crédito o un sistema de pagos en línea (Ej. paypal)

• El sistema debe permitirle al usuario visualizar el mapa seleccionado por el usuario de aquellos contenidos en el catálogo de mapas

14

Tipos de Requisitos NO-Funcionales

• Restricciones:– Expresan las limitaciones que se le imponen al desarrollo

la aplicación– Describen aspectos tales como:

• Plataforma de desarrollo y operación (H/S) • Uso de estándares, prácticas, métodos de desarrollo,

herramientas, etc.• Tiempo máximo de desarrollo • Costo máximo del proyecto

– Ejemplos:• mimapa.com debe ser desarrollada:

– Bajo una plataforma LAMP: Linux, Apache, MySQL y PHP– En un tiempo no mayor a seis meses– Con costo no superior a los Bs.F 300.000

15


• Atributos de calidad

– Son las cualidades o propiedades de calidad que la aplicación debe satisfacer, por ejemplo:

• El rendimiento que la aplicación debe mostrar

• La confiabilidad que debe poseer

• La seguridad que debe proveer

• La utilidad que debe garantizar

– La calidad de una aplicación se mide en función de sus atributos de calidad

16


• Atributos de calidad – Para facilitar su medición durante la verificación,

deben expresarse cuantitativa o cualitativamente• Ejemplo:

– mimapa.com debe tener una confiabilidad igual o mayor al 95%

– Los atributos cualitativos se miden usando escalas cualitativas, tales como la Escala de LIKERT

– 1: muy bajo, 2: bajo, 3:medio, 4: alto, 5: muy alto

• Ejemplo:– mimapa.com debe ser fácil de usar:

» Debe medir un mínimo de 4 puntos en una escala de 5 puntos

17


18

Atributos de Calidad del Software (según norma ISO 9126)

Atributos deCalidad del

Software (ISO9126)

FuncionalidadUtilidad

(Usability)

Confiabilidad

Eficiencia

Portabilidad

Mantenibilidad


• Atributos de Calidad asociados a la Funcionalidad

• Grupo de atributos que permiten calificar si una aplicación maneja adecuadamente las funciones para las cuales fue diseñada

– Adecuación:

• Capacidad de la aplicación para realizar funciones apropiadas a las tareas o procesos del negocio que ejecutan los usuarios

– Interoperabilidad:

• Habilidad de la aplicación para interactuar con otros sistemas o aplicaciones

– Seguridad:

• Habilidad de la aplicación para prevenir el acceso no autorizado (accidental o premeditado) a sus programas y datos

– Conformidad:

• Evalúa si la aplicación se adhiere a estándares y regulaciones establecidas

19


• Atributos de Calidad asociados a la Confiabilidad• Miden la capacidad de la aplicación para mantener un nivel

de rendimiento aceptable bajo condiciones normales y en un tiempo establecido

– Nivel de Madurez:• Mide la frecuencia de fallas ocasionada por errores en el

software

– Tolerancia a fallas:• Habilidad de la aplicación para mantener un nivel específico

de funcionamiento en caso de fallas

– Facilidad de Recuperación:• Habilidad de la aplicación para restablecer su nivel de

operación y recuperar sus datos ante una falla

20


• Atributos de Calidad asociados a la Utilidad• Permiten evaluar el esfuerzo que los usuarios invierten en

utilizar el sistema

– Comprensibilidad:• Capacidad que tiene la aplicación para que sus usuarios

reconozcan la estructura lógica de la aplicación y los conceptos relativos a ella

– Facilidad de Aprendizaje:• Capacidad que tiene la aplicación para que sus usuarios

aprendan a usarlo

– Operatividad:• Capacidad de la aplicación para que sus usuarios la operen y

controlen

21


• Atributos de Calidad asociados a la Eficiencia• Evalúan la relación entre el nivel de funcionamiento de la

aplicación y la cantidad de recursos utilizados

– Uso de recursos:• Mide la cantidad de recursos usados y la duración de su uso

durante la ejecución de sus funciones

– Rendimiento:• Especifican qué tan bien o tan rápido debe la aplicación

ejecutar una función dada en términos de: – Velocidad (tiempo promedio de acceso a datos)

– Volumen de transacciones por minuto

– Capacidad (carga de uso concurrente)

– Tiempo (demanda de tiempo real)

22


• Atributos de Calidad asociados a la Mantenibilidad• Permiten medir el esfuerzo requerido para mantener la

aplicación, bien sea debido a fallas o a mejoras

– Facilidad de Modificación:• Capacidad que tiene la aplicación para que sus mantenedores

puedan:– Modificar aspectos o funciones

– Adaptar la aplicación a un ambiente diferente

– Capacidad de análisis:• Capacidad de la aplicación para diagnosticar deficiencias o

causas de fallas o identificar partes que han de ser modificadas

– Facilidad de prueba:• Capacidad de la aplicación para permitir ser validada, una vez

modificada

23


• Atributos de Calidad asociados a la Portabilidad• Miden la habilidad de la aplicación para ser transferida de

un ambiente (plataforma de operación) a otro

– Facilidad de Instalación:• Habilidad de la aplicación para instalarse en su ambiente de

operación

– Adaptabilidad:• Capacidad de la aplicación para ser adaptada a diferentes

ambientes de operación sin que se requiera modificarla más allá de lo requerido

– Coexistencia:• Capacidad de la aplicación para coexistir con otras

aplicaciones compartiendo recursos comunes

24


• Requisitos de interfaz– Expresan las características de la interacción usuario-

sistema o sistema-sistema– Se dividen en:

• Requisitos de interfaz gráfica (GUI):– Describen las propiedades generales del interfaz gráfica que

permitirá la interacción entre el usuario y la aplicación– Ej.: La interfaz de la aplicación mimapa.com debe ser

implementada usando tecnología web

• Requisitos de interfaces con otros sistemas:– Describen con qué o cómo la aplicación interactuará con otras

aplicaciones de software o sistemas de hardware– Ej.: mimapa.com deberá interactuar con el sistema de pagos en

línea paypal

25


• Reglas del negocio– Expresan regulaciones que la aplicación debe acatar, p.ej.:

• Regulaciones gubernamentales:– Leyes, decretos, providencias, etc.

• Regulaciones de la empresa:– Políticas, normas, procedimientos, estrategias, etc.

• Regulaciones propias de la aplicación:– Estándares y mejores prácticas de desarrollo que deben seguirse

– Algoritmos que deben usarse, etc.

– Ejemplos:• mimapa.com debe elaborarse siguiendo el método de WATCH

adoptado por la empresa VECTOR C.A.

• Un cliente puede descargar gratuitamente las actualizaciones de un mapa adquirido por el/ella durante los 12 meses siguientes a su compra

26

Niveles de requisitos (adaptado de [Wiegers, 2003])

• Los requisitos tienen tres niveles asociados que determinan su origen y los aspectos que ellos tratan

27

Aspectos de la visión y alcance del producto

Aspectos de diseño del producto

Aspectos de uso del producto

Requisitos No-funcionalesRequisitos Funcionales

Niv

el

de

l U

su

ari

oN

ive

l d

el

Pro

du

cto

Niv

el

de

l N

eg

oc

io

Requisitosdel Negocio

Requisitos deUsuarios

Requisitosdel Sistema

Requisitos deComportamiento

Reglas delNegocio

Atributos deCalidad

Requisitos deInterfaces

Restricciones

Propiedades de los requisitos

• La calidad de los requisitos se mide por sus propiedades:– Cada requisito debe expresarse de una manera sencilla,

clara y sin ambigüedades, usando:• Lenguaje natural (Español), • Lenguajes gráficos (Ej. UML) o • Lenguajes formales (Ej. Notación Z)

– Preferiblemente, debe expresarse de manera cuantitativa • Uso de métricas que faciliten la verificación

– Debe identificarse de manera única e inequívoca• Uso de un sistema de numeración para facilitar su búsqueda y

manejo

– Debe ser correcto • Debe estar validado por el cliente

28

Propiedades de los requisitos

• Propiedades (cont.):– Los requisitos deben ser consistentes entre sí

• No debe haber conflictos o incompatibilidad entre requisitos

– Deben ser completos • Deben describir toda la funcionalidad que la aplicación deberá

implementar

– Cada requisito debe ser factible (realista o alcanzable)– Debe describir algo que el cliente o usuario necesita

• Resuelve algún problema del cliente

– Debe ser verificable • Deben medibles y sin ambiguedad

– Se le puede hacer un seguimiento a través de todo el desarrollo del sistema

29

Tema 2

Los problemas de los requisitos y sus soluciones

Tema 2: Problemas de los requisitos y sus soluciones

• Los requisitos son elementos críticos y fundamentales del desarrollo de software– Requisitos incompletos, mal especificados e

inconsistentes conducen al fracaso de un proyecto

• Es importante analizar estos problemas para no caer en el error de desarrollar una aplicación mal fundamentada

• Los objetivos instruccionales de este tema son:– Analizar los problemas que los requisitos presentan

durante el desarrollo de aplicaciones

– Describir las principales soluciones que la Ingeniería de Software ha establecido para resolver estos problemas

31

Los problemas de los requisitos

• De acuerdo a una encuesta realizada por el Standish Group, los principales factores que afectan a los proyectos de desarrollo de software son:

• Requisitos incompletos (13.1%)

• Falta de participación del usuario (12.4%)

• Falta de recursos (10.6%)

• Expectativas poco realistas (9.9%)

• Falta de apoyo gerencial (9.3%)

• Cambios en los requisitos y las especificaciones (8.7%)

• Falta de planificación (8.1%)

• El sistema dejó de ser necesario (7.5%)

32


• Requisitos mal definidos

– No reflejan las necesidades reales de los actores del proyecto

– Son inconsistentes

– Son incompletos

– No son factibles

• El costo de cambiar los requisitos crece a medida que avanza el proyecto

33

Análisis Diseño Implementación Pruebas Operación

Costo

Fase delProyecto


• El usuario o cliente no siempre sabe lo que quiere del sistema

– Al inicio del proyecto, el usuario no sabe que esperar del sistema

– Los requisitos tienden a surgir en la medida que el usuario se familiariza con:

• las tecnología TIC

• el sistema de información

34


• El usuario no tiene tiempo para participar en el proyecto

– Evita participar en el proyecto

– No está consciente de la importancia de su participación

– No ve al sistema como algo que le pertenece

35


• Problemas de comunicación– El cliente o usuario no entiende el lenguaje informático de

los analistas– Los analistas no entienden el lenguaje del dominio de la

aplicación

• Múltiples interpretaciones de los requisitos– El analista entiende y especifica de manera diferente los

requisitos del cliente– El diseñador interpreta de otra manera los requisitos

especificados por el analista

36

Soluciones a los problemas de los requisitos

• Ya hemos identificado los problemas de los requisitos, ahora bien:– ¿qué soluciones existen?

– ¿Cómo podemos enfrentar estos problemas?

• La Ingeniería de Requisitos (IR) es una sub-disciplina de la Ingeniería del Software que se encarga de:– estudiar los problemas asociados a los requisitos y

– proponer soluciones a estos problemas

• La IR establece métodos, modelos, técnicas, herramientas, prácticas, entre otros para resolver los problemas de los requisitos

37


• ¿Cómo resolver los problemas de los requisitos?– Entender la naturaleza del software

• La naturaleza del software promueve cambios frecuentes en los requisitos

– Entender el espacio del problema antes de analizar el espacio de la solución• Modelar el negocio antes de identificar y especificar

requisitos

– Utilizar un proceso de Ingeniería de Requisitos bien definido y probado• Este proceso debe describir como identificar, analizar,

documentar, verificar y gestionar requisitos• Debe ser parte del proceso de desarrollo de software

38


• ¿Cómo resolver los problemas de los requisitos?– Utilizar prácticas reconocidas (mejores prácticas),

p.ej.:• Incorporar al usuario en el desarrollo de la aplicación

(participación activa)

• Modelar los requisitos usando notaciones gráficas estandarizadas

• Gestionar los requisitos

– Emplear personal especializado que entienda los problemas de los requisitos• Analistas de Negocios

• Analistas de Requisitos

39

Espacio del problema vs. espacio de la solución

• Los métodos tradicionales de desarrollo de software subestiman la importancia del problema y su análisis

– Se centran en la solución y sus requisitos

– Por lo que la solución, generalmente, no se alinea al negocio

40


• La separación del espacio del problema y el de la solución es crucial en toda Ingeniería

• La Ingeniería de Sistemas Físicos establece una clara separación entre ambos espacios

41

Formulación

del problema

Diseño

de la solución

Selección de la

mejor solución

Búsqueda

de soluciones

Análisis

del problema

Implementación

de la solución

Espacio delProblema

Espacio de laSolución


– Las necesidades ocurren en el espacio del problema

– Los requisitos tienen lugar en el espacio de la solución

42

Modelado de Negocios

Ingeniería deRequisitos

Espacio de la Solución

Espacio del

ProblemaNecesi-dades

Aspectos(Features)

Requisitos de Software

Procedimientos de PruebasDiseño Doc. del

Usuario

LaSolución(software)

Adaptado de [Rational Requirements Management with Use Cases v5.5, 2000]

El Problema


• Relaciones entre el Modelado de Negocios (MN) y la Ingeniería de Requisitos (IR)– MN se encarga del espacio del problema (el sistema de negocios)

– Mientras que lR se encarga del espacio de la solución (la aplicación)

43

Modelado de Negocios(el problema)

Objetivos Procesos Objetos Reglas Actores Eventos…

Ingeniería de Requisitos(la solución)

Requisitos No FuncionalesRequisitos Funcionales


• El Modelo de las 6P contribuye, también, a resolver el problema de los requisitos

• Este modelo identifica factores críticos de éxito del desarrollo de software

44

Entender la naturaleza del

software

Producto

Utilizar lasmejoresprácticas

Prácticas

Gestionar eldesarrollo

como unproyecto

Proyecto

Usar unproceso dedesarrollo efectivo

ProcesoEmplearel mejor personal

Personas

Problema Entender primero el problemaantes de modelar la solución

Mejores prácticas de Ingeniería de Requisitos

• La Ingeniería de Requisitos (IR) propone un conjunto de mejores prácticas que han probado ser efectivas*

• Prácticas asociadas al conocimiento de la IR– Capacitar a los analistas en los temas técnicos de la IR

– Educar a los Representantes de Usuarios y Gerentes en la problemática y soluciones de los requisitos• Concientizar sobre la necesidad de una IR

– Capacitar a los desarrolladores en el dominio de la aplicación (sistema de negocios)

– Crear un glosario de términos del sistema de negocios

* Adaptado de Wiegers (2003)

45


• Prácticas asociadas a la Gestión de Requisitos– Definir un proceso para controlar los cambios de los

requisitos– Establecer un Comité encargado del control de cambios– Llevar a cabo el análisis del impacto que cada cambio en

los requisitos tiene sobre el proyecto– Establecer una línea base de requisitos y llevar control de

las versiones– Mantener históricos de cambios en los requisitos– Hacerle seguimiento a los requisitos

• Llevar las matrices de trazabilidad

– Medir la variabilidad de los requisitos– Usar herramientas para gestionar requisitos

46


• Prácticas asociadas a la Gestión del Proyecto– Seleccionar un ciclo de vida o método de desarrollo

apropiado

– Definir claramente el proceso de Ingeniería de Requisitos

– Basar los planes en los requisitos• Planes iterativos

– Renegociar los acuerdos de requisitos

– Manejar los riesgos de los requisitos

– Aprender de proyectos pasados (lecciones aprendidas)

47


• Prácticas asociadas al Descubrimiento de Requisitos

– Definir la visión y el alcance del producto

– Identificar los tipos de usuarios

– Identificar casos de uso

– Identificar los eventos y respuestas de la aplicación

– Observar a los usuarios realizando sus actividades

– Reutilizar requisitos de otros proyectos similares

48


• Prácticas asociadas al Análisis de Requisitos– Establecer el contexto de la aplicación

• Definir las relaciones entre la aplicación y su dominio o sistema de negocios

– Crear prototipos– Analizar la factibilidad de los requisitos– Establecer las prioridades de los requisitos– Modelar los requisitos

• Crear modelos funcionales, estructural y dinámicos

– Crear un diccionario de datos• Definir los elementos contenidos en los modelos

– Asignar requisitos a los subsistemas de la aplicación• Relacionar los requisitos con la arquitectura de la aplicación

49


• Prácticas asociadas a la Especificación de Requisitos

– Adoptar una plantilla para elaborar el Documento de Requisitos• Usar preferiblemente los estándares y adaptarlo a las necesidades

de su organización

– Identificar las fuentes de los requisitos• ¿Quién propuso este requisito?

– Identificar cada requisito de manera única

– Registrar las reglas del negocio

– Especificar los atributos de calidad• Usar modelos de calidad para seleccionar los requisitos apropiados a

la aplicación

• Especificar las métricas para medir los atributos

50


• Prácticas asociadas a la Validación de Requisitos

– Inspeccionar el Documento de Requisitos (DR)

• Realizar la Revisión Técnica del DR

– Probar los requisitos

• Diseñar las pruebas funcionales basadas en los requisitos

– Definir los criterios de aceptación

• ¿Qué criterios usará el cliente o usuarios para aceptar la aplicación?

51

Tema 3

La Ingeniería de Requisitos:

Productos, Procesos y Actores

Tema 3: IR - Productos, Procesos y Actores

• La Ingeniería de Requisitos (IR) es una sub-disciplina de la Ingeniería de Software – Se encarga del estudio de los requisitos en

sistemas automatizados (H/S)

• La IR produce:– principios, modelos, métodos, mejores prácticas,

técnicas y herramientas automatizadas que contribuyen a mejorar la identificación, análisis, especificación, validación y gestión de los requisitos

53

La Ingeniería de Requisitos

• La IR se ubica, junto al Modelado de Negocios, al comienzo de la cadena de valor del desarrollo de software

Gestión del Proyecto: Alcance, Tiempos, Costos, Recursos y Contratos

Gestión de Riesgos

Gestión de la Configuración

Gestión de la Calidad

Modelado del

Negocio

Ingeniería de

Requisitos

Diseño

Arquitectónico

Programación &

Integración

Pruebas de la

Aplicación

Entrega de la

Aplicación

Diseño

Detallado

54


• La aplicación de la IR al desarrollo de una aplicación conduce a:– Encontrar y definir las necesidades que tienen los

interesados de la aplicación

– Transformar la definición de necesidades en una descripción completa y precisa de requisitos, denominada:• Especificación de requisitos

– Lograr un entendimiento común, entre clientes/usuarios y desarrolladores, de los requisitos que debe satisfacer la aplicación

55


• Los tres elementos fundamentales de la IR:

56

Agreedrequirements

Systemspecification

Systemmodels

Requirementsengineering process

Stakeholderneeds

Organisationalstandards

Domaininformation

Regulations

Existingsystems

information

El proceso:¿cómo

hacerlo?

Los productos:

¿qué se hace?

El grupo: ¿quienes lo hacen?

Los Productos de la Ingeniería de Requisitos

¿Qué productos se elaboran durante el proceso de

Ingeniería de Requisitos?

57


• Principales productos generados por el proceso IR

«programa»

Prototipo de la

Aplicación

«documento»

Documento de Especificación

de Requisitos (DER)

«documento»

Documento de Definición de

Requisitos (DDR)

«documento»

Plan de Gestión de

Requisitos

«modelo»

Modelo Funcional (casos

de uso + descripciones

textuales)

«modelo»

Modelo Dinámico

(diagramas de actividad,

estado y/o secuencias)

«modelo»

Modelo Estructural

(diagramas de

componentes y de clases)

«documento»

Documento de

Requisitos

Producto IR

58


• El Plan de Gestión de Ingeniería de Requisitos– Es un documento de gestión elaborado por el Líder

del Proyecto o el Líder del Grupo de Requisitos– Describe detalladamente las actividades, tiempos,

costos y recursos requeridos en el proyecto para realizar los procesos IR

• El Prototipo de la Aplicación– Es un programa que exhibe la interfaz gráfica de la

aplicación y demuestra su funcionalidad– Es elaborado para verificar:

• Los requisitos de los usuarios • Los requisitos de interfaz gráfica

59


• El Documento de Requisitos (DR) debe describir:– Los requisitos funcionales que debe cumplir la

aplicación• Requisitos del negocio• Requisitos de los usuarios (servicios que ofrece)• Funciones de la aplicación y su comportamiento

– Los requisitos no-funcionales de la aplicación• Reglas de negocio que debe implementar la aplicación• Restricciones bajo las cuales deberá operar la aplicación• Atributos de calidad que deberá cumplir la aplicación• Interfaces con otros sistemas

– El dominio de la aplicación (sistema de negocios) y las relaciones entre ambos

60


• El Documento de Requisitos (DR) – Es un documento manual o electrónico que describe y

comunica los requisitos de la aplicación– Es utilizado por dos tipos de audiencias:

• Clientes, usuarios y gerentes• Desarrolladores de la aplicación

• Es, también, denominado:– Especificación de Requisitos de Software (ERS)– Especificación del Sistema (ES)

• Por lo general, se divide en dos partes:– Documento o Sección de Definición de Requisitos (DDR)– Documento o Sección de Especificación de Requisitos

(DER)

61


• Documento de Definición de Requisitos (DDR)

– Está dirigido a los clientes/usuarios

– Identifica, describe, organiza y relaciona los requisitos desde la perspectiva de los clientes/usuarios

– Cada requisito es debidamente identificado y documentado usando formatos especiales, p.ej.:• Plantilla VOLERE

62

«documento»

Documento de Definición de

Requisitos (DDR)

«documento»

Lista de

Requisitos

Identificados

«modelo»

Matriz Requisitos

.vs. Requisitos

«documento»

Lista de

Requisitos

Seleccionados


• Documento de Especificación de Requisitos (DER)

– Está dirigido a los desarrolladores del sistema

– Describe gráficamente los requisitos contenidos en el DDR usando un lenguaje o notación de modelado, p.ej.:• UML, ER, SADT, Notación Z

63

«documento»Documento de Especificación

de Requisitos (DER)

«modelo»Modelo Funcional (o de

Casos de Uso)

«modelo»Modelo Dinámico (o de

Comportamiento)

«modelo»Modelo Estructural (o de

Clases)

«diag. UML»Diagrama de Casos de Uso

«Document...Descripción

Textual de Caso de Uso

«diag. UML»Diagrama de

Clase


Componentes


Actividad


Estado


Secuencia

1..* 0..*0..* 0..* 0..*0..*

0..11 1

1..*


• Existen varios estándares y modelos (plantillas o patrones) que ayudan a elaborar el Documento de Requisitos

– El estándar IEEE 830-1993

• Propuesto por el Institute of Electrical and Electronics Engineers (IEEE)

• Agrupa los documentos DDR y DER en un sólo documento

• Es, también, un estándar ANSI

– Adaptaciones del estándar IEEE 830-1993• Adaptación de Wiegers(2003)

• Adaptación de Le Vie (2009)

http://www.techwr-l.com/techwhirl/magazine/writing/softwarerequirementspecs.html

64


1. Introducción1. Propósito2. Convenciones utilizadas3. Audiencia y lecturas sugeridas4. Alcance del proyecto5. Referencias

2. Descripción general1. Perspectiva del producto2. Aspectos del producto3. Tipos de usuarios y sus características4. Ambiente operativo5. Restricciones de diseño e

implementación6. Documentación del usuario7. Supuestos y dependencias

3. Aspectos de la aplicación1. Aspecto A

1. Descripción y prioridad2. Estímulo/respuesta3. Requisitos funcionales

2. Aspecto B …

4. Requisitos de Interfaces

1. Interfaces de usuarios

2. Interfaces de hardware

3. Interfaces de software

4. Interfaces de comunicación

5. Otros requisitos no-funcionales

1. Requisitos de rendimiento

2. Requisitos de seguridad

3. Atributos de calidad

4. …

6. Otros requisitos

Apéndice A: Glosario

Apéndice B: Modelos de Requisitos

1. Modelo Funcional

2. Modelo Estructural

3. Modelo Dinámico

Estructura del Documento de Requisitos según Wiegers (2003)

65

Modelo de

Negocios

BMM

Modelo de

Eventos

Modelo de

Actores/

Unidades

Modelo de

Objetos de

Negocio

Modelo de

Reglas de

Negocio

Modelo de

Procesos de

Negocio

Modelo de

Objetivos

Documento

de

Requisitos

Vista General

del

Sistema

Requisitos

Funcionales

Requisitos

No

Funcionales

Modelo

Funcional

(Casos de

Uso)

Modelo

Estructural

(Clases)

Modelo

Dinámico

• Relaciones de Dependencia entre el Modelo de Negocios y el Documento de Requisitos

66

Esp

acio

de

l Pro

ble

ma

Espacio

de

la Solu

ción

Los Procesos de la Ingeniería de Requisitos

¿Qué procesos requiere la Ingeniería

de Requisitos?

67

El proceso de la Ingeniería de Requisitos

68

Ingeniería deRequisitos (IR)

«objetivo»

Determinar los

requisitos que la

aplicación debe

satisfacer

«actor»

Líder del Grupo

de Análisis

«actor»

Grupo de Análisis

«actor»

Usuarios«recurso»

Herramientas, técnicas,

patrones, métricas,

prácticas, plantillas para

IR

«Regla»

Métodos, Modelos,

Estándares y

Procedimientos de

Desarrollo de

Software

«modelo»

Modelo del Negocio

«documento»

Plan del Proyecto

«documento»

Plan de Gestión de

Requisitos

«Documento»

Plan del Proyecto

actualizado

«documento»

Documento de Inicio

del Proyecto

Información de

aplicaciones

similares

Necesidades de

los usuarios

«programa»

Prototipo de la

Aplicación

«documento»

Documento de

Requisitos

«documento»

Caso de Negocios

(Visión del Producto)

«persigue»

«ejecuta» «apoya»

«regula»

«controla»

«apoya» «apoya»


• La Ingeniería de Requisitos es un proceso compuesto por:

– Procesos de Desarrollo de Requisitos

• Se encargan de capturar, organizar, filtrar y documentar los requisitos

– Procesos de Gestión de Requisitos

• Planifican y controlan los procesos de desarrollo y controlan los cambios a los requisitos

69

Ingeniería deRequisitos

Descubrimientode Requisitos

Análisis deRequisitos

Especificación deRequisitos

Validación deRequisitos

Gestión deRequisitos

Desarrollo deRequisitos


• El proceso de Descubrimiento de Requisitos (DR)• Denominado, también, Captura de Requisitos

– En qué consiste:• En la búsqueda y recolección de requisitos

– Qué actividades principales requiere:• Establecer los objetivos de la aplicación

– Analizar el Caso de Negocios, Documento de Inicio y Plan del Proyecto

• Analizar el modelo de negocios– Analizar el problema que la aplicación debe resolver

– Identificar a los usuarios

• Recolectar los requisitos que tienen los usuarios– Usar la plantilla VOLERE y/o herramientas de gestión de requisitos

• Organizar los requisitos recolectados

70


• El proceso de Descubrimiento de Requisitos (DR)– Qué técnicas se utilizan para descubrir requisitos:

• Entrevista

• Prototipos

• Reuniones

• Observación directa

• Reutilización de requisitos

• Uso de modelos de negocios

• Ingeniería en Reverso

• Encuestas (cuestionarios)

• Torbellino de ideas

• Análisis de documentos

72


• El proceso de Análisis de Requisitos (AR)

– En que consiste:

• En analizar los requisitos recolectados durante el proceso anterior (DR) a fin de:

– Determinar y resolver posibles conflictos entre estos requisitos

– Refinar los requisitos recolectados y establecer prioridades

– Establecer acuerdos entre usuarios y desarrolladores sobre los requisitos que se pueden implementar

73


• El proceso de Análisis de Requisitos (AR)

– Qué actividades principales requiere:

• Refinar y clasificar los requisitos– Verificar necesidad, consistencia, completitud y factibilidad

• Negociar requisitos con el cliente y/o usuarios– Discutir, priorizar y acordar requisitos

• Modelar los requisitos – Elaborar los modelos funcional, estructural y dinámico de la

aplicación

• Construir un prototipo de la interfaz gráfica

74


• El proceso de Análisis de Requisitos (AR)– Qué técnicas se utilizan para analizar requisitos:

• Análisis de los procesos del negocio• Análisis Orientado a Objetos

– Modelado de funciones mediante Diagramas de Casos de Uso– Modelado de flujos de trabajo a través de Diagramas de Actividad– Modelado estructural de la aplicación usando Diagramas de Clases– Modelado del comportamiento mediante Diagramas de Secuencia

• Análisis Estructurado de Sistemas– Modelado de procesos usando Diagramas de Flujo de Datos (DFD)– Modelado de transiciones empleando Diagramas de Estados– Modelado de entidades por medio de Diagramas Entidad-Interrelación

(ER)

• Prototipos• Técnicas de negociación

75


• El proceso de Especificación de Requisitos (ER)– En que consiste:

• En la documentación de los requisitos

• Está relacionado con la estructura, calidad y verificabilidad del Documento de Requisitos

• Premisa:– “La documentación de requisitos es la precondición fundamental para el

manejo exitoso de requisitos” [Kotonya and Sommerville, 2000]

– Que actividades principales requiere:• Seleccionar el estándar de documentación

• Documentar los requisitos del cliente– Elaborar el Documento de Definición de Requisitos (DDR)

• Documentar los requisitos del desarrollador– Elaborar el Documento de Especificación de Requisitos (DER)

76


• El proceso de Especificación de Requisitos (ER)– Qué técnicas se utilizan para especificar los requisitos:

• Uso de estándares de documentación de requisitos– IEEE P1233/D3– IEEE 830-1998– ISO/IEC 12119-1994– IEEE 1362-1998 (ConOps)

• Indicadores de calidad– Modelos de calidad del software

• Lenguajes y notaciones– Lenguajes de modelado gráfico

» Lenguajes OO: UML» Lenguajes estructurados: DFD, SADT, IDEF» Lenguajes dinámicos: Redes de Petri, Diagramas de Estado

– Lenguajes formales de especificación» Notación Z

77


• El proceso de Validación de Requisitos (VR)– En qué consiste:

• En examinar los productos elaborados durante la Ingeniería de Requisitos para:

– determinar si son válidas y aceptables las descripciones de los requisitos del sistema que se desea construir

– Qué productos de la IR se validan en este proceso:• Lista de requisitos recolectados• Modelos de Requisitos

– Modelos funcional, estructural y dinámico

• Prototipo• Documento de Requisitos

– Documento de Definición de Requisitos (DDR)– Documento de Especificación de Requisitos (DER)

78


• El proceso de Validación de Requisitos (VR)– Los productos de la IR se validan para determinar si

sus requisitos son:• Correctos

– Satisfacen las necesidades reales de los usuarios

• Completos– Incluyen todos los requisitos que los usuarios demandan

• Consistentes – No hay conflictos entre requisitos

• Libres de errores • Cumplen con los estándares establecidos• Precisos

– No hay requisitos ambiguos

79


• El proceso de Validación de Requisitos (VR)– Qué actividades y técnicas se utilizan para validar

requisitos:• Revisar técnicamente los modelos y documentos

– Inspección de modelos– Inspección de documentos

• Validar el Prototipo– Evaluación de prototipos de interfaces gráficas

• Diseñar pruebas funcionales– Definición de criterios de aceptación

» Qué criterios emplearán los usuarios para aceptar la aplicación

– Diseño de casos de pruebas para validar las funciones de la aplicación

80


• El proceso de Gestión de Requisitos (GR)– En que consiste:

• En establecer y mantener, a lo largo de todo el proyecto, un acuerdo con el cliente o usuarios sobre los requisitos de la aplicación

– Qué actividades principales se requieren:• Planificar y controlar las actividades de Ingeniería de

Requisitos• Controlar los cambios a los requisitos acordados

– Definición de la línea base de requisitos– Control de cambios en requisitos

• Manejar las relaciones entre requisitos• Manejar las dependencias entre el Documento de

Requisitos y los otros documentos del desarrollo– Seguimiento o trazabilidad de requisitos

81


• El proceso de Gestión de Requisitos (GR)

– Qué técnicas se utilizan:

• Planificación y control de proyectos

• Control de cambios

• Gestión del almacenamiento de requisitos– Identificación de requisitos

– Uso de bases de datos para requisitos

• Rastreo o trazabilidad de Requisitos

82

Los Actores de la Ingeniería de Requisitos

83

¿Quienes participan en el proceso IR?

El grupo de requisitos

• En la elaboración del Documento de Requisitos participan un conjunto de interesados o actores

– Para garantizar el éxito del proceso IR, este grupo debe estar debidamente organizado y estructurado

– A este conjunto organizado de actores se le denomina Grupo de Requisitos

84

El grupo de requisitos

• Responsabilidades y funciones del Grupo de Requisitos:– Seleccionar un modelo de procesos apropiado para

ejecutar la IR– Adaptar el modelo de procesos IR a las características del

proyecto y de la empresa– Planificar el proceso de requisitos– Elaborar el Documento de Requisitos siguiendo el proceso– Mantener actualizado el Documento de Requisitos – Hacerle seguimiento a los requisitos (mantener la

trazabilidad)– Proporcionar soporte técnico al grupo de desarrollo del

sistema en relación a los requisitos

85

Tema 4: Modelado Funcional de Requisitos

• La Identificación de Requisitos describe cada requisito separadamente– Sin embargo, para comunicar, analizar y validar los

requisitos de una aplicación es más conveniente modelarlos gráficamente

• Por esta razón, durante el Análisis de Requisitos se elaboran tres modelos de requisitos diferentes:– Modelo Funcional

• Representa los requisitos funcionales de la aplicación

– Modelo Estructural• Representa la estructura de la aplicación

– Modelo Dinámico • Representa el comportamiento de la aplicación

86

Tema 4: Modelado Funcional de Requisitos

• Los modelos de requisitos son elaborados usando el lenguaje UML

– UML provee las notaciones necesarias para modelar :

• Los requisitos funcionales

• La estructura y comportamiento de la aplicación

• Los requisitos funcionales se modelan usando los Diagramas de Casos de Uso del lenguaje UML

87

Modelado Funcional de Requisitos

• El Modelado Funcional es un proceso mediante el cual se representa gráficamente la funcionalidad de una aplicación

• La funcionalidad es el conjunto de funciones o servicios que una aplicación provee a sus usuarios– Determina que operaciones pueden los usuarios

realizar con el sistema– La funcionalidad dice que hace el sistema, pero no

dice como lo hace

• El producto principal del Modelado Funcional de requisitos es un Modelo de Casos de Uso

88

Modelado Funcional de Requisitos

• Componentes de un Modelo de Casos de Uso

– Un Modelo de Casos de Uso consta de uno o más Diagramas de Casos de Uso y un conjunto de descripciones textual

• Una descripción textual está asociada a un caso de uso

89

Retirar efectivo

Validar tarjeta

Transferir entrecuentas

Consultar saldo

Usuario ATM

Cambiar clave

Diagramas de Casos de Uso

• Los Diagramas de Casos de Uso especifican requisitos funcionales

– Cada requisito funcional es representado por un caso de uso

– Cada caso de uso es documentado mediante una Descripción Textual

90

Caso de uso: Validar tarjetaActor: UsuarioFlujo de eventos:1.- El usuario introduce la tarjeta2.- El sistema valida la tarjeta3.- El sistema presenta el menú

de opciones

Descripción Textual

Diagrama de Casos de Uso

uc CasoUsoPrincipal

Servicio de Transporte Aéreo

Gestionar

Vuelos

Gestionar

reservaciones

Consultar

productos y

servicios

Administrar

recursos

UsuarioNoRegistrado

Administrador

Aerolinea

Registrar

usuarios

Pasajero


• Los diagramas de casos de uso modelan:

– Los actores de un sistema

– Los casos de uso

– Las relaciones entre actores

– Las relaciones entre casos de uso

– Las relaciones de comunicación entre actores y casos de uso

– Los límites del sistema

– El refinamiento o descomposición de los casos de uso

91


• Forma general de un diagrama de casos de uso

92

relación de extensión

<<extiende>>

relación de inclusión

<<incluye>>

asociación

Caso de uso

especializado

relación de generalización

límite del sistema

Caso de uso

Actor

Caso de uso

extendido

Caso de uso incluido

relación de extensión

<<extiende>>

relación de inclusión

<<incluye>>

asociación

Caso de uso

especializado

relación de generalización

límite del sistema

Caso de uso

Actor

Caso de uso

extendido

Caso de uso incluido


• Actor

– Símbolo usado para representar el rol que objetos externos, de una misma clase, juegan cuando interactúan con el sistema

• Un objeto externo puede ser una persona interesada (stakeholder), un dispositivo u otro sistema

• No se refieren a un individuo particular, sino a una clase de individuos que tienen un rol común

– Representan a entes externos al sistema

– Un actor intercambia señales y datos con el sistema

– Un actor es un clasificador y no una ocurrencia

93

Icono creado por el modelador

Clasificador con estereotipo

«actor»

rol

rol

Representación icónica

Rol

Icono creado por el modelador

Clasificador con estereotipo

«actor»

rol

rol


Rol


Rol


• Relaciones entre Actores– Se pueden

establecer relaciones de generalización entre los actores

– Un rol general puede ser heredado por uno o más roles específicos

94

uc Actores

PasajeroPilotoAerolinea

PasajeroFrecuente

(PF)

UsuarioNoRegistrado

Administrador


• Relaciones entre Actores y Casos de Uso

– Los actores se relacionan con los casos de uso mediante asociaciones

– Un asociación modela la comunicación bidireccional entre un actor y un caso de uso• Envío de señales

– Ej. activación del caso de uso

• Envío de datos e información

95

ActorCaso de Uso

ActorCaso de Uso


• Relaciones entre casos de uso

– Los casos de usos se asocian entre sí usando tres tipos de relaciones:

• Relaciones de extensión

• Relaciones de inclusión

• Relaciones de generalización

96

Caso Uso 1

Caso Uso 2

Caso Uso 3

Caso Uso 4

«incluye»

«extiende»

Caso Uso 1

Caso Uso 2

Caso Uso 3

Caso Uso 4

«incluye»

«extiende»


• Relación de extensión

– Modelan relaciones en las cuales un caso de uso base incluye el comportamiento de un caso de uso extendido en uno o más puntos de su flujo de eventos

• Estos puntos se denominan puntos de extensión

• Tienen asociado una condición que determina cuando el caso de uso extendido es invocado por el caso de uso base

– El caso de uso extendido se activa cuando la condición se cumple

97


• Relación de extensión

– Usadas para modelar separadamente el comportamiento excepcional del caso de uso base

– Este tipo de relación es unidireccional y va desde el caso de uso extendido al caso de uso base usando el estereotipo <<extend>> o << extiende>>

98

uc CasosURelaciónExtensión

Realizar reservación Reservar múltiples

destinos

Condición: {modo="multiples destinos"}

Punto de extensión: Verificar modo

Caso de uso base Caso de uso

extendido

«extiende»


• Relación de inclusión

– Modelan relaciones en las cuales uno o más casos de uso incluyen (usan) el comportamiento de un caso de uso común

– Son usados para compartir comportamiento común entre varios casos de uso

– Este tipo de relación es unidireccional y va desde el caso de uso base al caso de uso incluido usando el estereotipo <<include>> o <<incluye>>

99

uc CasosUsoRelaciónInclusión

Usar

reservaciónRegistrar el

vuelo«incluye»


• Relación de generalización en casos de uso

– Modela las relaciones en las cuales el comportamiento de un caso de uso general (padre) es heredado por uno o más casos de uso especializados (hijos)

100

uc CasosUsoRelaciónGeneralización

Actualizar

reservación

Realizar

reservación

Modificar

reservación

Eliminar

reservación

Caso de uso

General

Casos de uso

específicos


• Reglas de estilo para elaborar Diagramas de Casos de Uso

– Cada actor y caso de uso debe tener un nombre único

– Los actores deben tener nombres y/o íconos representativos• Los nombres deben indicar roles

– El nombre de un caso de uso debe indicar acción y debe ser claro y conciso• Forma general: Verbo + predicado

• Ejemplos: – Actualizar itinerarios

– Realizar reservación

– Gestionar vuelos

101


• Reglas de estilo para Diagramas de Casos de Uso– Los casos de uso de un diagrama deben estar todos a

un mismo nivel de abstracción

– Evite el cruce de líneas

– Evite tener demasiados casos de uso en un mismo diagrama• Use la regla del 7 2:

– El número apropiado de casos de uso por diagrama está en el rango de 5 a 9

– Evite el uso complejo de relaciones de extensión e inclusión• No más de tres niveles de relaciones consecutivas

102


• Ejemplos de Diagramas de Casos de Uso: Servicio de Transporte Aéreo

103

uc CasoUsoPrincipal

Servicio de Transporte Aéreo

Gestionar

Vuelos

Gestionar

reservaciones

Consultar

productos y

servicios

Administrar

recursos

UsuarioNoRegistrado

Administrador

Aerolinea

Registrar

usuarios

Pasajero

uc Actores

PasajeroPilotoAerolinea

PasajeroFrecuente

(PF)

UsuarioNoRegistrado

Administrador


104

uc CasoUsoGestionarVuelos

Actualizar

Aerolineas

Actualizar

Aviones

Actualizar

itinerarios

Actualizar

Pilotos

Actualizar

Aeropuertos

Aerolinea

uc GestionarReservaciones

Realizar

reservación

Modificar

reservación

Eliminar

reservación

Usar

reservación

Consultar

promociones

Actualizar

reservación

Registrar el

vuelo

Consultar

promociones de

PF

Aerolinea

Pasajero

PasajeroFrecuente

(PF)

Consultar

itinerarios

Reservar múltiples

destinos

«extend»

«incluye»

«extiende»

Descripción textual de casos de uso

• La simplicidad de los diagramas de casos de uso tienen un costo asociado: – Baja expresividad:

• Las acciones que ocurren entre un actor y el caso de uso no se pueden capturar con los símbolos de los casos de uso

– Cada caso de uso tiene asociado un flujo de eventos que indica el orden en que sus acciones se ejecutan

– Ejemplo:1. El sistema presenta la forma “Registro de Cliente”

2. El usuario ingresa los datos de la forma y pulsa “enter”

3. El sistema valida el nombre de la empresa y el RIF

4. El sistema crea un nuevo registro de cliente en la base de datos

5. El sistema notifica al usuario el número de registro

105


• El flujo de eventos establece los detalles de la comunicación entre el caso de uso y sus actores

• Los flujos de eventos se describen separadamente usando Descripciones Textuales de Casos de Uso – Flujo de eventos principal (flujo feliz)

– Flujos de eventos alternativos

106

Flu

jo p

rincip

al


• Plantilla para descripción de casos de uso

107

Caso de uso: <nombre del caso de uso>

Actores participantes: <lista de actores que participan>

Condiciones de entrada: <precondiciones>

Flujo de eventos principal:

<evento 1> (los eventos son del tipo: “El actor hace esto” o “El sistema hace aquello”)

<evento 2>

…

<evento n>

Flujos alternativos:

<flujo alternativo asociado al flujo de eventos normal i>

Condiciones de salida: <postcondiciones>

Requisitos especiales: <requisitos no-funcionales asociados al caso de uso>

Notas: <notas adicionales o aclaratorias>


108

Caso de uso: Realizar Reservación

Actores participantes: Pasajero

Condiciones de entrada: El pasajero es un usuario registrado

Flujo de eventos principal:

1. El usuario selecciona la opción "Realizar reservación"

2. El sistema muestra un formulario con los criterios de búsqueda de vuelos

3. El usuario ingresa los criterios (modo, origen, destino, periodo y pasajeros) y pulsa la tecla "buscar vuelos"

4. El sistema busca todos los vuelos que cumplen con los criterios

5. El sistema muestra los vuelos (aerolínea, monto, tasa, impuestos)

6. El usuario selecciona el vuelo y pulsa la tecla "reservar"

7. El sistema muestra un formulario de ingreso de datos de los pasajeros

8. El usuario ingresa los datos de los pasajeros y pulsa la tecla "guardar"

9. El sistema agrega la reservación al vuelo de la aerolínea

10. El sistema emite un comprobante de la reservación

Condiciones de salida:

El pasajero obtiene la reservación mediante un comprobante de confirmación


109

Flujo de eventos alternativos:

3.1 El usuario ingresa los criterios de búsqueda incompletos

3.1.1 El sistema muestra un mensaje de advertencia

3.2 El usuario ingresa el modo: “múltiples destinos”

3.2.1 El sistema muestra un formulario para seleccionar múltiples destinos

3.2.2 El usuario selecciona los destinos y pulsa la tecla "continuar"

3.2.3 El sistema guarda los destinos y regresa al formulario de criterios del vuelo

4. El sistema no encuentra disponibilidad de vuelos

4.1 El sistema muestra un mensaje indicando que no existe disponibilidad de vuelos para los criterios seleccionados

6. El usuario no selecciona ningún vuelo

6.1 El usuario pulsa la tecla "Regresar"

6.2 El sistema regresa a la página anterior

8. El usuario ingresa los datos de los pasajeros incompletos

8.1 El sistema muestra un mensaje de datos de pasajeros incompletos

Requisitos especiales:

El sistema debe mostrar los resultados de vuelos en un tiempo no mayor a 10 segundos


• Reglas para la descripción textual de casos de uso (1)– Narre el flujo de eventos usando voz activa, en tiempo

presente y desde la perspectiva del actor• Evite el uso de voz pasiva:

– “La clave es introducida por el usuario”

• Prefiera el uso de la voz activa:– “El usuario introduce la clave”– “El sistema valida la clave”

– Exprese cada paso del flujo usando la forma “llamada y respuesta”:• El texto debe reflejar el hecho de que el actor ejecuta algo y el

sistema responde a la solicitud del actor– “El [actor] hace [esto]” y “El sistema hace [aquello]”

110


• Reglas para la descripción textual de casos de uso (2)– El caso de uso que se describe debe expresar un solo

requisito funcional• Pero, pueden haber uno o más requisitos no-funcionales asociados

al requisito funcional descrito

– Establezca el contexto inicial del actor• Especifique la ubicación del actor en el contexto de la interfaz de

usuario del sistema– Ej. El Cliente introduce su clave de identificación en la ventana de

identificación al inicio del sistema

– Asegúrese que el caso de uso produzca un resultado visible y de valor para el cliente

– Establezca todos los posibles flujos alternativos al flujo principal (flujo feliz)

111

Tema 5: Modelado Estructural de Requisitos

• Toda aplicación tiene una estructura asociada

• La aplicaciones orientadas a objetos (OO) representan mediante objetos de software a los objetos del dominio de la aplicación (sistema de negocios)– Cada objeto relevante del sistema de negocios es

representado en la aplicación por un objeto de software

• Los objetivos instruccionales de este tema son:– Familiarizarse con el proceso de modelado estructural de

requisitos

– Adquirir habilidades en el modelado de la estructura de una aplicación usando Diagramas de Clases en UML

112

Modelado Estructural de Requisitos

• Una actividad importante del Análisis de Requisitos es la elaboración del Modelo Estructural de la aplicación

• Un Modelo Estructural es una representación gráfica de la estructura que debe tener la aplicación– En aplicaciones OO, esta estructura se expresa en

términos de clases de objetos y relaciones entre estas clases

– Cada clase de objetos representa a un conjunto de objetos del dominio de la aplicación que tienen todos las mismas propiedades Mapa

representa

113

UML: Diagramas de Clases

• Los Diagramas de Clases permiten representar diferentes aspectos de la estructura de un sistema o aplicación

• En Ingeniería de Requisitos se usan para:– Facilitar la identificación y modelado de los

requisitos estructurales de una aplicación, es decir• Las clases del negocio

– Esto es, clases que representan a los objetos del negocio

• Las relaciones entre estas clases

114


• Los diagramas de clases se pueden elaborar mediante el análisis de los diagramas de casos de uso

– Cada sustantivo del nombre de un caso de uso representa un tipo o clase de negocio

115

Comprar un mapa Mapa


• Un Diagrama de Clase en UML consta de:

– Una o más clases de objetos

– Una o más relaciones entre clases

116

Operaciones

(Métodos)

Diagrama de

Clases

Agregación DependenciaComposiciónAsociaciónGeneralizaciónAtributos

RelaciónClases de Objeto

**

**


• Una CLASE representauna colección de entidades u objetos quetienen un conjuntocomún de propiedades

• Es un constructo quedefine la estructura(atributos) y el comportamiento(operaciones) de un conjunto de objetosdenominados instancias

117

Avión

+id

+nombre

+marca

+modelo

+capacidadMax

+estado

+...

+cambiarEstado()

+actualizarDatos()

+obtenerDatos()

+obtenerEstado()

+...()

Nombre dela clase

Atributos(estructura)

Métodos u Operaciones(comportamiento)


• Una clase describe los atributos de sus instancias • Los atributos son las propiedades comunes que

las instancias de una clase tienen• Formato de un atributo:

• visibilidad / nombre: tipo [multiplicidad] = valor de defecto {propiedad}

– La visibilidad puede ser pública (+), protegida(#), privada (-) o sólo para el paquete (~)

– Las propiedades pueden ser: {readOnly}, {sequence}, {ordered}– / indica que el atributo es derivado o calculado a partir de otros

• Ejemplos:– + capacidadMax: Integer = 45– + estado: String = “activo”– - / edad: Integer {readOnly}

118


• Una clase describe, también, las operaciones (métodos) que se le pueden aplicar a sus instancias

• Formato de una operación:• visibilidad nombre (lista de parámetros): valor de retorno

{propiedad}– La visibilidad puede ser pública (+), protegida(#), privada (-) o paquete

(~)

– Las propiedades pueden ser: {isQuery}, {sequential}, {concurrent},...

– La lista de parámetros tiene el siguiente formato:

» dirección nombre: tipo [multiplicidad] = valor de defecto

» Dirección indica si el parámetro es de entrada (in), salida (out) o ambos (inout)

• Ejemplos:– +obtenerEstado():String

– +actualizarDatos( in marca: String, in modelo: String)

– #cambiarCapacidad( in nueva: Integer) {sequential}

119


• Entre las clases se establecen RELACIONES de varios tipos:– Generalización y herencia

– Asociación

– Agregación

– Composición

– Dependencia

120

A B

A B+rol2+rol1

A B

A B

A B


• Generalización y herencia• Establece una relación del tipo ”es_un” entre dos o

más clases

• Una o más clases específicas, denominadas subclases, heredan la estructura y comportamiento de una clase genérica

• Las subclases tienen (heredan) los mismos atributos y operaciones que tiene su superclase

121

subclases

superclase

Persona

Profesor

Estudiante


• Asociación

– Establece una relación funcional y bidireccional entre dos o más clases

– Cada instancia de una clase se asocia a cero, uno o más instancias de la otra clase asociada

122

CursoEstudiante inscribe +es_cursado+cursa

0..*0..*

nombre de la asociación

multiplicidad

rol


• Agregación

– Establece una relación “todo-partes” en la cual una clase (el todo) está conformada por otra u otras clases (las partes)

– La existencia de las instancias de las partes no depende de la existencia de las instancias de la clase agregada

123

Equipo de Trabajo

Estudianteparte

todo


• Composición

– Establece una relación “es_parte_de” entre dos clases

– Es un tipo particular de agregación en la cual la existencia de las instancias de las partes depende de la existencia de la instancia compuesta

124

Curso

Objetivo Contenido Actividad

1..* 1..* 0..*

Clase compuesta

Clases componentes


• Dependencia

– Establece una relación entre una clase dependiente y otra independiente

– No establece un tipo específico de dependencia

• Simplemente se indica que hay una dependencia entre dos clases

125

Curso Institución

Clase independienteClase dependiente


• Casos especiales

126

Clase de Asociación

Clase Abstracta

Paciente

+id+nombre+...

Médico

+id+nombre+especialidad#consultorio+...

Cita

+fecha+hora

0..*0..*

Equipo<<abstract>>

+id+nombre+marca+modelo+serial

+obtenerSerial()+...()

PDA

+memoria+tipoCPU

PC

+memoria+tipoCPU+capDD

Teléfono

+protocoloCOM


• Casos especiales

127

Asociación Recursiva

Actividad

+id+nombre+descripción+duración

+estructurada_por

0..*

1

Departamento

Persona Proyecto

Asociación Ternaria


• Usos de los Diagramas de Clases

– En la especificación de requisitos, se usan para representar:

• Los objetos de negocio del dominio de aplicación y

• Las relaciones entre estos objetos

– Ejemplo 1: Modelo de Objetos de Negocio en un Sistema de Reservaciones Aéreas

128

Reservación

Cliente Vuelo Aerolínea+reservado_por+reserva

0..*0..*

+coordina+coordinado_por

11..*

Avión

asignación

1

1

129

Reservación

+fecha+hora+localizador+estado

Cliente

+id+cédula+nombre+teléfono+e-mail+...

Vuelo

+id+número+origen+destino+cupoDisponible+estado+...

Aerolínea

+id+nombre+e-mail+estadoActual+...

+reservado_por+reserva

0..*0..*

+coordina+coordinado_por

11..*

Avión

+id+nombre+marca+modelo+capacidadMax+estado+...

asignación

1

1

clase de negocio

clase de asociación

asociación

atributo

roles

multipicidad

Sistema de Reservaciones Aéreas


• Ejemplo 2: Sistema de ordenes de compra– Identificación de objetos de negocios:

• Cliente

• Producto o ítem

• Orden de compra– Encabezado

– Líneas de pedido (ítems solicitados)

• Pago– Pago en efectivo

– Pago a crédito

– Pago con cheque

– Identificación de relaciones

• Un Cliente coloca una o más Ordenes de Compra

• Una Orden de Compra está compuesta por un Encabezado y una o más líneas de pedido

• Una Orden de Compra es pagada en efectivo, cheque o a crédito

130

UML: Diagramas de clases

131

Resumen del Tema 5

• Qué es el Modelado Estructural de Requisitos

• Porqué es importante modelar la estructura de la aplicación durante la IR

• Cómo se elabora un Diagrama de Clases

• Qué diferencias existen entre:

– Clases y objetos

– Atributos y métodos

– Generalización y especialización

– Composición y agregación

– Clase de asociación y asociación recursiva

132

Ejercicios Prácticos del Tema 5

• Objetivo de la actividad:– Elaborar el Modelo Estructural de los requisitos de su

aplicación

• Duración:– 15 minutos presenciales + 1-2 horas a distancia

• Pasos a seguir:Usando el Modelo Funcional de Requisitos elaborado en durante el Tema 4:1. Identifique las clases del negocio que debe manejar su

aplicación2. Identifique las relaciones entre estas clases3. Identifique los principales atributos de cada clase4. Elabore y valide el Modelo Estructural de su aplicación

133

Tema 6

Modelado Dinámico

Diagramas de Actividad y Estado

Tema 6: Modelado Dinámico de Requisitos

• Toda aplicación tiene una dinámica asociada– Esta dinámica está determinada por el comportamiento

de la aplicación ante eventos– Los eventos hacen que la aplicación responda o reaccione– Estos eventos pueden ocurrir debido a:

– La interacción del usuario con la aplicación– Una transición de estado en un objeto de la aplicación– Una falla de la aplicación

• Los objetivos instruccionales de este tema son:– Familiarizarse con el modelado dinámico de una

aplicación– Adquirir habilidades en el uso de diagramas de actividad y

diagramas de estado del UML

135

Modelado Dinámico de Requisitos

• Para modelar la dinámica o el comportamiento de una aplicación existe un conjunto amplio de técnicas:– UML:

• Diagramas de actividad• Diagramas de Interacción

– Diagramas de secuencia– Diagramas de comunicación

• Diagramas de estado

– Otros:• Diagramas de flujo• Redes de Petri• Notación de Modelado de Procesos de Negocios BPMN

136

Modelado Dinámico de Requisitos

• Los diagramas de actividad del UML son útiles para :– modelar los flujos de trabajo en los que interviene la

aplicación– Representar la interacción de la aplicación con los procesos

del sistema de negocios

• Los diagramas de estado del UML son útiles para modelar:– los eventos que ocasionan cambios en el estado de los

objetos de una aplicación– las transiciones de estado que pueden tener los objetos de

cierta clase en una aplicación

• Los diagramas BPMN son una alternativa a los diagramas de actividad– Permiten modelar flujos de trabajo de una aplicación

137

UML: Diagramas de Actividad

• Los diagramas de actividad son usados para modelar flujos de trabajo (workflow) de una aplicación

– Expresan que acciones se requieren y en que orden

– Qué hacen estas acciones y/o que producen

– Quien es responsable de ejecutarlas (partición de actividades)

Recibo

de la ordenCierre

de la orden

Factura

Llenarorden

Enviarorden

Enviarfactura

Hacerpago

Aceptarpago

[ordenaceptada]

[ordenrechazada]

Orden derequerimiento

138

DiseñarEstructura del

Producto

DiseñarForma delProducto

EspecificarComponentes

«información»Características del Producto

«información»Estructura

del Producto

«información»Forma

del Producto

«información»Modelo

del Producto


• Los diagramas de actividad capturan las acciones de un proceso del negocio y sus resultados

– Enfatizan la secuencia de actividades (acciones)

– Modelan dos tipos de flujos de un proceso del negocio:

• el flujo de control y/o

• el flujo de objetos

Modelo de flujo de control

Modelo de flujo de objetos

DiseñarEstructura del

Producto


EspecificarComponentes

139


• Concepto de “acción” o “tarea” en un diagrama de actividad

– Una acción (o tarea) es la unidad fundamental de especificación de comportamiento

– Una acción es atómica

• No puede ser descompuesta en otras acciones

– Una acción toma uno o más objetos de entrada (tokens) y las transforma en uno o más objetos de salida (tokens)

tokens

acción


«información»Estructura

del Producto

«información»Forma

del Producto

140


• Un diagrama de actividad es un grafo dirigido que está compuesto de:– Un conjunto de nodos de cuatro tipos:

• Nodos de actividad que representan acciones – Transforman objetos que entran en objetos que salen

• Nodos de control usados para controlar flujos

• Nodos de objetos que representan objetos de datos

• Nodos de señal que modelan eventos que activan la ejecución de acciones

– Un conjunto de ejes• Cada eje conecta a dos nodos

• A través de los ejes circulan objetos denominados tokens

141


• Formato de un diagrama de actividad

Pre y postcondiciones

Ejes de actividadNodos de actividad

Parámetro de la actividad

Nombre de la actividad

Nodos de parámetros

…

…

…

Nombre de la actividad o proceso <<precondición>> restricciónNombre del parámetro: Tipo <<poscondición>> restricción

142


• Ejemplo 1: “Procesar Ordenes de Compra”

Orden decompra

Nota dedespacho

Revisar ordende compra

Rechazar orden

Actualizar inventario

Elaborarnota de despacho

Verificar existenciade producto

A

A

[Ordencompleta]

[Orden incompleta]

No

Si

Procesar Orden de Compra <<precondición>> Orden válida<<postcondición>> Orden atendida

Nombre de la actividad o proceso Nodo Objeto parámetrode salida

Pre y postcondiciones

Nodo objeto parámetrode entrada

Join

Fork

Nodo de mezcla

Nodo de decisiónConector

Nodo fin de

actividad

Acción

Nodoinicio deactividad

143

Nodos de parámetros

Anotación deflujo continuo

Anotaciones deexcepción

Materiales de producción

Computadores Ensamblados

Tableros de circuitos impresos

Computadoresaceptados

ComputadoresrechazadosProducir tableros

de circuitosimpresos

Ensamblarcomputadores

Probar computadores

{flujo}


• Ejemplo 2: Flujo de objetos de la actividad “Producir computadores”

144


• Nodos de señales

– Permiten modelar eventos o señales que activan la ejecución de acciones

nodos de señal de envío

nodo de señal de aceptación

(Ventas)Crear orden

(almacén)Facturar orden

Entregarorden

Notificar alCliente

Cancelarorden

Solicitudde cancelación

de orden

145


• Los diagramas de actividad modelan flujos de trabajo mediante:

• Secuencias de acciones (secuenciación)

• Secuencias de acciones paralelas (paralelismo)

• Secuencias de acciones alternativas (decisión)

• Sincronización de acciones paralelas (concurrencia)

Cancelarservicio

Cancelartransacción

Notificarinactividad

Notificarrechazo

Rechazar

Aprobarservicio

Sometera aprobación

Aprobarautomáticam

Cronometrarinactividad

[cantidad<200]

[cantidad>=200]

[decisión=rechazar]

[decisión=aceptar]

146


• Partición de actividades y carriles (swimlanes)

– Permiten agrupar las acciones de acuerdo a los actores o unidades organizacionales responsables de su ejecución

– Útiles para establecer relaciones entre la aplicación y sus usuarios

a) Partición usando la notación “swimlane”

No

mb

re d

ep

arti

ció

n

ParticiónNombre-4

Par

tici

ón

No

mb

re-1

Par

tici

ón

No

mb

re-2

c) Partición usando la notación“swimlane” jerárquica y multidimensional

Nombre de dimensión

No

mb

re d

e d

imen

sió

n

ParticiónNombre-3

b) Partición usando la notación “swimlane” jerárquica

No

mb

re d

e d

imen

sió

n

No

mb

re d

e p

arti

ció

n

No

mb

re d

esu

bp

arti

ció

n

No

mb

re d

esu

bp

arti

ció

n

147


• Ejemplo 1: Partición de actividadesC

lien

te

<<ex

tern

a>>

<<at

rib

uto

>> d

pto

Ejec

uto

r : D

epar

tam

ento

Dp

to. d

e O

rden

esD

pto

. d

e C

on

tab

ilid

ad

Recibirorden

Cerrarorden

Factura

Llenarorden

Enviarorden

Enviarfactura

Hacerpago

Aceptarpago

[ordenaceptada]

148


• Ejemplo 2: Partición de actividades usando carriles multidimensionales

Mérida Caracas

<<cl

ase>

>D

pto

. de

Co

nta

bili

dad

<<

clas

e>>

Dp

to. d

e V

enta

s

Recibirorden

Cerrarorden

Factura

Solicitar despacho

Despacharorden

Enviarfactura

Recibirpago

Confirmarpago

[ordenaceptada]

149


• Ejemplo 3: Otra manera de particionaractividades es mediante la anotación

– Cada acción tiene una anotación específica que indica el actor o unidad organizacional responsable de ejecutarla

(Dpto.Orden)

Recibirorden

(Dpto. Orden)

Cerrarorden

Factura

(Dpto. Orden)

Llenar orden

(Dpto. Orden)

Enviar orden

(Contabilidad)

Enviar factura

<<externa>>

(Cliente)Hacer pago

(Contabilidad)

Enviar pago

[ordenaceptada]

anotación

150


• Los Diagramas de Actividad modelan:

– el flujo de trabajo de un proceso del negocio y

– las relaciones entre los usuarios y la aplicación

• Ejemplo 1: Sistema de Facturación en líneaRecibirorden

Cierrede orden

Solicitar Despachode orden

Despacharorden

Enviarfactura

Hacerpago

Aceptarpago

[ordenaceptada]

Clie

nte

<<e

xte

rno

>>

Dep

to. d

e V

en

tas

Sist

. de

Fact

ura

ció

n

Factura

<<u

nid

ad o

rgan

izac

ion

al>>

Ge

ren

cia

de

Ve

nta

s

151


• Ejemplo 2: Sistema de ordenes de compra

Verificar

datos cliente

Verificar

inventario

Rechazar

orden

Procesar

orden

Empacar

productos

Ingresar

orden

Enviar

pedido

válido

inválido

cantidad > 0cantidad <= 0

<<producto>>

Pedido

<<información>>

Notificación

Cliente Sistema Ordenes de Compra Sistema Inventario Almacén

152

Diagramas de actividad

• Ejemplo 3: Un cajero automático

153

[Borland, 2002]


• Ejemplo 4: Descomposición funcional en diagramas de actividad

Descomposiciónde la actividad

Usarparte

RequerirID parte

Buscarparte

Proveerparte requerida

[else]

[encontrada]

[no encontrada]

[proveída]

Ingenieríade Diseño

Ingenieríade Estándares

Ejecutarflujo detrabajo

[flujo][flujo]

Investigarposibilidades

de producción

[acepta]

[rechaza]

Proveerinformación

adicionalMod. parte

Búsquedaexperta

de la parte

Asignaringeniero

Revisarrequerimiento

Especificarflujo detrabajo

Mod. parte

Planificarflujo detrabajo

Mod. parte

Clarificarrequerimientos

Revisarplan

[cancelar]

[replanificar][OK]

[flujo][flujo]

[no encontrada]

[encontrada]

Proveer parte requerida Ingenieríade Diseño

Ingenieríade Estándares

154

UML: Diagramas de Estado

• Las aplicaciones de software combinan tres procesos computacionales:– Comportamiento funcional (ejecución de funciones)– Manipulación de datos – Cambios de estado

• Una aplicación en ejecución, generalmente, se encuentra en un determinado estado – P.ej., en espera, procesando, cerrada, etc.

• Este estado es modificado cuando ocurre un cierto evento o condición predeterminada– La ocurrencia del evento o la presencia de la condición

ocasiona una transición o cambio de estado en la aplicación

155


• Los diagramas de estado son ideales para modelar las transiciones de estado que ocurren a nivel de:– Toda la aplicación, p.ej.:

• Cambios de estado de una aplicación interactiva o una de tiempo real

– Una aplicación interactiva pasa del estado inactivo al estado activo cuando el usuario selecciona cualquier opción de su interfaz

– Objetos de la aplicación, p.ej.:• Cambios en el estado de un objeto de negocio en una

aplicación empresarial– En la aplicación mimapa.com, los objetos de la clase Carro de

Compras puede cambiar del estado “vacio” al estado “agregando”

156


• Máquinas de Estado Finito

– Tanto una aplicación como un objeto de ella pueden ser vistos como máquinas de estado

– Una máquina de estado es un modelo que especifica las secuencias de estados que un objeto puede recorrer durante su existenciaEstado 1

Inicial

Estado 2

Estado 3

Final

evento A

evento C[condición D]

evento B

157


• Máquinas de Estado Finito

– Una máquina de estado tiene tres tipos de elementos:

• Estados representados por rectángulos

• Transiciones o cambios de estado representados por flechas entre estados

• Eventos o condiciones que causan las transiciones entre estados

Estado 1

Inicial

Estado 2

Estado 3

Final

evento A

evento C[condición D]

evento B

158


• Estados– Un estado es una condición en la cual un objeto

de una determinada clase puede estar en cierto momento de su existencia

– El estado de un objeto es determinado por los valores de sus atributos y enlaces a otros objetos

– Durante su estadía en un estado, el objeto puede ejecutar operaciones al momento de:• Entrada al estado (entry)

• Permanencia en el estado (do)

• Salida del estado (exit)

<nombre del estado>

entry/<operación>

do/<operación>

exit/<operación>

159


• Transiciones (cambios de estado)

– Una transición es un cambio de estado que ocurre en un objeto o sistema

• El objeto (o sistema) pasa de un estado actual a otro estado

• La transición se representa mediante un arco

Estado actual

Estado destino

transición

160


• Eventos– Una transición ocurre debido a un evento que la

dispara• Un evento es algo que acontece en el sistema o en su

entorno y que ocasiona una transición• Formato del evento:

<nombreDelEvento> [<condición>] / <acción>Donde:<condición>: Expresión booleana. Debe ser verdadera para que

ocurra la transición. Si la expresión es falsa, no hay transición

<acción>: Operación que se ejecuta sobre el objeto en el momento en que ocurre la transición

• Ejemplo:Cuenta

suspendidaCuenta activada

pago realizado [saldo < 0]

pago realizado [saldo >=0]/eliminarSuspension

161


• Ejemplo 1: Un Sistema de Seguridad

Sistema activado

+ entry / encender sensores

Sistema desactivado

+ entry / apagar alarma+ entry / apagar sensores

Alarma encendida

+ entry / encender alarma

Inicial

botónencendido

clave correcta

clave incorrecta[t > 30 seg]

movimiento detectado

clave correcta[t <= 30 seg]

clave incorrecta

clave correcta[t > 30 seg]

162


• Ejemplo 2: Diagrama de Estado de los objetos de la clase Reservación del Sistema de Reservaciones

163

Resumen del Tema 6

• Qué es el Modelado Dinámico de requisitos

• Qué es el comportamiento de una aplicación

• Qué aspectos dinámicos de una aplicación se modelan durante la IR

• Cómo representar un flujo de trabajo usando diagramas de actividades

• Cómo modelar los cambios de estado de un objeto del negocio

164

Tema 6: Actividades Prácticas

• Objetivo de la actividad:

– Elaborar el Modelo Dinámico de los requisitos de su aplicación

• Duración:

– 30 minutos presenciales + 2-3 horas a distancia

• Pasos a seguir:

1. Usando el modelo de negocios elaborado durante la Sesión 2.1:

1. Seleccione un proceso de negocio que sea apoyado por la aplicación que usted está especificando

2. Elabore un Diagrama de Actividad que muestre el flujo de trabajo que requiere el proceso y su relación con la aplicación

2. Usando el Modelo Estructural elaborado durante el Tema 5:

1. Seleccione una clase que tenga cambios de estado interesante

2. Elabore el diagrama de estado para la clase seleccionada

165

Conclusiones

• Un mal manejo de los requisitos de una aplicación puede ocasionar el fracaso del proyecto

• La Ingeniería de Requisitos (IR) busca resolver los problemas asociados a los requisitos

• La IR agrupa y organiza los procesos de:– Identificación, análisis, especificación, validación y gestión

de requisitos

• La IR está estrechamente relacionada con el Modelado de Negocios (MN)– El MN estudia el problema; mientras que la IR se encarga

de especificar la solución, inmediatamente antes de diseñarla

166

Referencias Bibliográficas

• Le Vie, D. (2009). Writing Software Requirement Specifications. [on-line] http://www.techwr-l.com/techwhirl/magazine/writing/softwarerequirementspecs.html

• Wiegers, K. E. (2003). Software Requirements. Microsoft Press. Redmond, Washington.

• Scott, K. (2004). Fast Track UML 2.0. Spriger-Verlag, New York.

• Eriksson, Penker, M, Lyons, B. and Fado, D. (2004). UML 2 Toolkit. WileyPublishing. Indiana.

• Montilva, J., Barrios, J. y Rivero, M. (2008). Gray Watch: Método de Desarrollo de Software para Aplicaciones Empresariales. Versión preliminar. Monografía disponible en www.methodius.org.ve

167




http://www.methodius.org.ve/

Módulo 2

Fin de la Sesión 2.2

Derechos Reservados. Prohibida la reproducción total o parcial de este documento, por cualquier medio manual o electrónico, sin la autorización

escrita de sus autores.

© Jonás A. Montilva [email protected]

http://e-praxis.biosoftca.com

mailto:[email protected]

http://e-praxis.biosoftca.com/



ingenieria requisitos

Documents