Ingeniería de requerimientos de software: “Análisis”isis... · Requerimientos basados en...

Ingeniería de requerimientos

de software: “Análisis”

Dpto. de Ingeniería de Sistemas y

Computación

Universidad de los Andes

Referencias

El Lenguaje Unificado de Modelado. Grady Booch, James Rumbaugh e Ivar

Jacobson. Addison Wesley, 1999 Capítulos 16 y 17

Object Oriented Software Engineering. Bernd Bruegge y Allen H.Dutoit.

Prentice Hall, 2000. Capítulo 4, pág. 100–106, 118-119

Software Requirements. Karl. E.Wiegers. Microsoft Press, 1999. Capítulo 9,

pág. 153-162. Capítulo 11

Material preparado por Rubby Casallas.

[email protected] 2

Qué es Ingeniería de requerimientos

de software?

Es el proceso de:

Recopilar, descubrir (Elicitation),

Analizar,

Documentar (Especificar) y

Validar (Lograr un acuerdo) Material preparado por Rubby Casallas.

[email protected] 3


[email protected] 4

Anarizar: determinar si los requerimientos son los

indicados, claros, completos, coherentes, se podrán

probar (testable) y resolver los conflictos aparentes.

Técnicas: abstraer, modelar, identificar funcionalidad,

identificar restricciones, características, prototipar,

simular, discutir, …

Modelamiento del mundo del

problema Abstraer de la realidad los conceptos de

interés para el problema

Representarlos en el modelo utilizando un

lenguaje


[email protected] 5

Modelamiento del mundo del

problema Diagrama de clases de UML 2

Modelar los conceptos y las relaciones en

los elementos del mundo del problema.

Propósito:

Ayudar a entender.

Definir un vocabulario.

Ayudar a elaborar preguntas.


[email protected] 6

Ver material diagramas de clases …


[email protected] 7

Requerimientos basados en casos de

uso


[email protected] 8

Los usuarios, cuando utilizan una

aplicación lo hacen con un propósito

en mente.

Siempre esperan obtener algo

concreto de la aplicación como:

• Registrar un nuevo pedido

• Calcular el total vencido

• Ver la colección de canciones

• Enviar un correo …

• …


[email protected] 9


uso Los usuarios se pueden clasificar, desde el

punto de vista de un software, en roles o

grupos de personas que esperan cosas

particulares de la aplicación.

Un Actor representa un rol de un usuario.

Identificar los Actores es el primer paso para

identificar qué se espera de la aplicación.


[email protected] 10


uso

Usos que cada Actor obtiene de la aplicación.

…

…

…

…

…

…

…

…

…

…

…

…

…

Actor

Cualquier cosa con comportamiento, como

una persona (identificada por un rol), sistema

informatizado u organización.

La misma persona física puede interpretar

varios roles como actores distintos

El nombre del actor describe el papel

desempeñado



Identificar Actores

¿Cuáles usuarios el sistema apoya para

desarrollar su trabajo?

¿Cuáles usuarios ejecutan las funciones

principales del sistema?

¿Cuáles usuarios desempeñan funciones

secundarias, como mantenimiento y

administración?

¿El sistema interactúa con hardware externo

o software?

Material preparado por Rubby Casallas




Ejemplo: Actores que utilizan Banner. Cada uno tiene propósitos distintos

• Crear

cursos

• Establecer

horarios de

los cursos

• …

• Agregar

estudiantes a

un curso

• Ver

desempeño

global de un

estudiante

• …

• Registrar

notas de los

estudiantes

• …

• Ver nota de

un curso

• …

Caso de uso

Capturar el comportamiento deseado del

sistema en desarrollo, sin tener que

especificar cómo se implementa este

comportamiento

Los casos de uso proporcionan un medio

para que los desarrolladores, los usuarios

finales del sistema y los expertos del

dominio lleguen a una comprensión

común del sistema



Casos de Uso

Identificar los casos de uso para los actores

Representarlo en un diagrama de casos de

uso

Se utilizan verbos en infinitivo que

representan las acciones del usuario con el

sistema, por lo que siempre debe existir un

tipo de usuario(actor) que lo utilice



Ejemplo Diagrama de Casos de Uso



Especificar un Casos de Uso

Es una descripción de un conjunto de

secuencias de acciones, incluyendo

escenarios o variantes, que ejecuta un

sistema para producir un resultado

observable de valor para un Actor



Escenario 1: Básico (todo sale bien)

Nombre del

escenario

Consultar listado de cursos

Actor Profesor

Flujo de eventos 1. El Profesor ingresa al sistema indicando sus datos.

2. El sistema despliega cada una de las posibilidades del

sistema.

3. El Profesor indica que quiere sacar un listado de un

curso.

4. El sistema solicita ingresar la información del código,

sección y semestre de la materia.

5. El Profesor ingresa 21251, 02, 2018-1.

6. El sistema devuelve la información correspondiente al

curso indican el nombre, carnet, carrera y correo

electrónico de cada uno de los alumnos.



Escenario 2: Hay un problema, no termina

bien (no se obtiene lo que se requería)

Nombre del

escenario

Consultar listado de cursos

Actor Profesor

Flujo de eventos 1. El Profesor ingresa al sistema indicando sus datos.

2. El sistema despliega cada una de las posibilidades del

sistema.

3. El Profesor indica que quiere sacar un listado de un

curso.

4. El sistema solicita ingresar la información del código,

sección y semestre de la materia.

5. El Profesor ingresa 21251, 02, 2018-1.

6. El sistema informa que el curso no es válido




uso Tener claros los siguientes conceptos:

Escenarios

Describen un ejemplo del uso del sistema en términos

de una serie de interacciones entre un actor y el sistema

Instancia del Caso de Uso

Casos de uso

Colección de escenarios con éxito y fallo relacionados,

que describe a los actores utilizando un sistema para

satisfacer un objetivo



Especificación de un caso de uso

El comportamiento de un caso de uso se puede especificar

describiendo un flujo de eventos en forma textual

Además de incluir cómo y cuándo empieza y acaba el caso de uso

Se incluye cuándo interactúa con los actores

Se Indica qué información se intercambia

Se describe el flujo básico

Se describe los flujos alternativos y las excepciones



Ejemplo:

Flujo de eventos principal

1. El sistema pide al cliente un número de

identificación personal

2. El cliente introduce su id.

3. El sistema comprueba entonces la id. Para ver si

es válido

4. Si la identificación es válida el sistema acepta la

entrada



Ejemplo:

Flujo de eventos excepcional

El cliente puede cancelar una transacción en

cualquier momento, reiniciando el caso de uso

No se efectúa ningún cambio en la cuenta del

cliente


Paso 2: El cliente puede borrar su id en cualquier

momento antes de introducirlo



Ejemplo:


Paso 4: Si el cliente introduce un id inválido, el

caso de uso vuelve a empezar

Paso 4: Si el cliente introduce tres veces seguidas

un id inválido, el sistema cancela la transacción

completa, impidiendo que el Cliente utilice el

cajero durante 24 horas



Relaciones entre casos de uso

Inclusión <<include>>

Indica que en el flujo de eventos del caso de uso

base se incluye el comportamiento del otro caso

de uso

Factorizar comportamiento común (NO hacer

descomposición funcional)

SOLAMENTE se hace cuando la parte común es

utilizada por otro caso de uso o cuando es

utilizada por otro actor



Ejemplo <<include>>:




Ejemplo <<include>>:

Verificar Operación

Reintegro Cuenta Corriente

Cliente

Reintegro Cuenta de Crédito

<<include>>

<<include>>





Extensión <<extends>>

Un caso de uso extiende otro caso de uso, si el

caso de uso extendido incluye el comportamiento

del otro bajo ciertas condiciones

Se utiliza para modelar la parte de un caso de uso

que el usuario puede ver como comportamiento

opcional del sistema

Se separa el comportamiento opcional del

obligatorio




Ejemplo <<extends>>:



Extiende el caso de uso

retirar efectivo si, por

ejemplo, el cajero no tiene

papel entonces envía una

notificación de error

Documentación de un Caso de Uso

Identificador: Indispensable/Deseable Prioridad

Nombre Caso de Uso:

Autor:

Fecha

Actores involucrados:

Resumen:

Curso Básico Eventos:

Caminos Alternativos:

Caminos de Excepción:

Puntos de Extensión:

Pre - Condiciones:

Post- Condiciones:

Criterios de Aceptación

Borrador de Interfaz Gráfica




Identificación del caso de uso: Única

Indispensable/Desable: Necesidad del

requerimiento

Prioridad: Alta/Media/Baja definida por el

usuario

Nombre de caso de uso: Iniciar con un verbo

en infinitivo




Autores:

Persona(s) que elabora(ron) el formato

Fecha:

Fecha de elaboración del documento

Descripción/Resumen:

Describe la interacción que ocurre en el caso de uso (contexto)

Curso básico de eventos:

Describe los pasos que los actores y el sistema deben seguir

para completar la meta del caso de uso (No ocurre ningún error)




Caminos alternativos:

camino correcto que ocurre como parte integral

del caso de uso

Caminos de excepción:

Muestran procesamiento no común, en especial

cuando ocurren errores

Puntos de extensión:

Cuando se utiliza la relación de extends. Indica en

que punto exacto se extiende la funcionalidad

bajo ciertas condiciones Material preparado por Rubby Casallas



Precondiciones:

Cosas que han debido ocurrir antes de iniciar la

interacción. Parte del contrato entre el caso de

uso y el mundo de afuera.

Postcondición:

Cuando el caso de uso termina exitosamente se

debe satisfacer.

Criterios de aceptación:

Condiciones para que el cliente acepte el

requerimiento como válido. Material preparado por Rubby Casallas


Ejemplo: La Tienda de Discos



Ingeniería de requerimientos de software: “Análisis”isis... · Requerimientos basados en...

Documents

Transcript of Ingeniería de requerimientos de software: “Análisis”isis... · Requerimientos basados en...