Ingeniería de requerimientos de software: “Análisis”isis... · Requerimientos basados en...
Transcript of 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.
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.
Material preparado por Rubby Casallas.
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
Material preparado por Rubby Casallas.
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.
Material preparado por Rubby Casallas.
Requerimientos basados en casos de
uso
Material preparado por Rubby Casallas.
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 …
• …
Material preparado por Rubby Casallas.
Requerimientos basados en casos de
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.
Material preparado por Rubby Casallas.
Requerimientos basados en casos de
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
Material preparado por Rubby Casallas.
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
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
Material preparado por Rubby Casallas.
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
Material preparado por Rubby Casallas.
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
Material preparado por Rubby Casallas
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.
Material preparado por Rubby Casallas
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
Material preparado por Rubby Casallas
Requerimientos basados en casos de
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
Material preparado por Rubby Casallas.
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
Material preparado por Rubby Casallas
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
Material preparado por Rubby Casallas
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
Flujo de eventos excepcional
Paso 2: El cliente puede borrar su id en cualquier
momento antes de introducirlo
Material preparado por Rubby Casallas
Ejemplo:
Flujo de eventos excepcional
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
Material preparado por Rubby Casallas
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
Material preparado por Rubby Casallas
Ejemplo <<include>>:
Relaciones entre casos de uso
Material preparado por Rubby Casallas
Ejemplo <<include>>:
Verificar Operación
Reintegro Cuenta Corriente
Cliente
Reintegro Cuenta de Crédito
<<include>>
<<include>>
Relaciones entre casos de uso
Material preparado por Rubby Casallas
Relaciones entre casos de uso
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
Material preparado por Rubby Casallas
Relaciones entre casos de uso
Ejemplo <<extends>>:
Material preparado por Rubby Casallas
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
Material preparado por Rubby Casallas
Documentación de un Caso de Uso
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
Material preparado por Rubby Casallas
Documentación de un Caso de Uso
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)
Material preparado por Rubby Casallas
Documentación de un Caso de Uso
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
Documentación de un Caso de Uso
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