Notas de la Unidad 7

Transcripción

Unidad 7
Ingeniería de Requisitos y
Análisis OO
M.C. Martín Olguín
Conceptos

Requisitos del Software

Es la descripción de los servicios y restricciones
de un sistema de software, es decir, lo que el
software debe hacer y bajo qué circunstancias
debe hacerlo.
M.C. Martín Olguín (C) 2004
…Conceptos

Ingeniería de Requisitos del Software


Es el proceso de descubrir, analizar, documentar
y verificar los requisitos del software.
Captura de Requisitos


Es el proceso de descubrir, normalmente en
circunstancias difíciles, lo que se debe construir.
Es tan difícil hacerlo, que es una práctica común
comenzar a escribir código (lo fácil) antes de
formalizar el qué debe hacer este código.
…Conceptos

Stakeholders

Este término se utiliza para referirse a cualquier persona
que tiene influencia directa o indirecta sobre los requisitos
del sistema. Entre los stakeholders se encuentran los
usuarios finales que interactúan con el sistema y todos
aquellos en la organización se que verán afectados por
dicho sistema.
Los stakeholders también son los
ingenieros que desarrollan o dan mantenimiento a otros
sistemas relacionados, los administradores del negocio,
los expertos en el dominio del sistema, los representantes
de los trabajadores, etc.
El Proceso y su contexto
La Visión del Proyecto




El proceso de ingeniería de requisitos inicia
con una visión del proyecto.
El documento de Visión debe capturar los
requisitos y restricciones de diseño de alto
nivel para dar una idea del sistema a
desarrollar.
Será la guía de todo el proyecto.
Sirve como base para un contrato de
desarrollo.
Formatos de Visión de
Proyecto


RUP
Process Impact
Actividades principales

La ingeniería de requisitos incluye dos
actividades principales: la obtención de
requisitos, que da como resultado una
especificación del sistema que el cliente
comprende, y el análisis, que da como
resultado un modelo de análisis que los
desarrolladores pueden interpretar sin
ambigüedad. [BRUEGGE, 2002]
Contexto de las Actividades
Principales
Obtención de
Requisitos
Especificación del
sistema (SRS)
Análisis
Modelo de análisis
Actividades del Proceso de Obtención
y Análisis de Requisitos
1.
2.
3.
4.
5.
6.
7.
Comprensión del dominio
Recolección de requisitos
Clasificación
Resolución de conflictos
Priorización
Verificación de requisitos
Especificación de requisitos
Comprensión del Dominio


Los ingenieros de requisitos deben
desarrollar su propia comprensión del
dominio de la aplicación.
Por ejemplo, si se requiere un sistema para
supermercados, deben averiguar cómo
operan éstos.
Recolección de requerimientos


Es el proceso de interactuar con los
stakeholders del sistema para descubrir sus
requisitos.
En esta actividad se profundiza la
comprensión del dominio.
Clasificación


Esta actividad considera la recolección no
estructurada de requisitos y los organiza en
grupos coherentes.
En esta etapa se empiezan a definir los
casos de uso.
Resolución de conflictos



De forma inevitable, cuando existen muchos
stakeholders involucrados, los
requerimientos entrarán en conflicto.
Esta actividad se refiere a encontrar y
resolver los conflictos.
Es probable que se determine hacer primero
actividades de ingeniería de sistemas.
Priorización


En cualquier conjunto de requisitos, algunos
de ellos serán más importantes que otros.
Esta etapa comprende la interacción con los
stakeholders para descubrir los requisitos
más importantes.
Verificación de requisitos

Los requisitos se verifican para descubrir si
están completos, son consistentes y acordes
con lo que realmente quieren los
stakeholders del sistema.
Actividades de la Ingeniería de
Requisitos
Tipos de Requisitos


Requisitos funcionales: Describen las interacciones
entre el sistema y su ambiente, en forma
independiente a su implementación. El ambiente
incluye al usuario y cualquier otro sistema externo
con el cual interactúe el sistema.
Requisitos no funcionales: Describen atributos sólo
del sistema o del ambiente del sistema que no
están relacionados directamente con los requisitos
funcionales. Los requisitos no funcionales incluyen
restricciones cuantitativas, como el tiempo de
respuesta o precisión, tipo de plataforma (lenguajes
de programación y/o sistemas operativos, etc.)
Técnicas para la obtención de
requisitos






Tormenta de ideas
Storyboarding
Role playing
CRC cards
Entrevistas
Observación directa
Características de una buena
SRS









[IEEE Std 830-1998]
1. Correcta
2. No ambigua
3. Completa
4. Consistente
5. Calificada de acuerdo a la importancia y/o
estabilidad
6. Verificable
7. Modificable
8. Rastreable
IEEE Std 830-1998

Correcta


Una SRS es correcta, sí y solo sí, cada requisito
especificado es un requisito que el software debe
cumplir.
No ambigua

Una SRS no es ambigua sí y solo sí cada
requisito especificado tiene sólo una
interpretación.
...IEEE Std 830-1998

Completa

Una SRS es completa, sí y solo sí, incluye los
siguientes elementos:



Todos los requisitos significativos
Definición de las respuestas del software a todos los
tipos posibles de clases de datos de entrada en todos
los tipos posibles de clases de situaciones.
Etiquetas y referencias completas a todas las figuras,
tablas y diagramas en la SRS así como la definición
de todos los términos y unidades de medida.
...IEEE Std 830-1998

Consistente


Uns SRS es consistente, sí y solo sí, no se
contradice a sí misma, es decir, si ningún
subconjunto de requisitos ahí descritos se
contradicen o entran en conflicto.
Jerarquizada de acuerdo a la importancia y/o
estabilidad

Si cada requisito tiene un identificador que
indique la importancia o estabilidad del requisito.
...IEEE Std 830-1998

Verificable

Una SRS es verificable, sí y solo sí, cada
requisito especificado es verificable. Un requisito
es verificable sí y solo sí existe un proceso finito
de costo-efectivo con el cual una persona o una
máquina puede verificar que el producto de
software cumple con el requisito. En general
cualquier requisito ambiguo no es verificable.
...IEEE Std 830-1998

Modificable

Una SRS es modificable, sí y solo sí, su estructura y
estilo son tales que, cualquier cambio a los
requisitos pueden ser hechos fácil, completa y
consistentemente sin perder la estructura y el estilo.



La modificabilidad generalmente requiere que una SRS:
a) Tenga una organización coherente y fácil de usar con una
tabla de contenido, un índice y referencias cruzadas
explícitas.
b) No sea redundante (esto es, el mismo requisito no debe
aparecer en más de una parte en la SRS).
c) Expresa cada requisito de manera separada, en vez de
hacerlo mezclado con otros requisitos.
...IEEE Std 830-1998
Rastreable
Una SRS es rastreable si el origen de cada
uno de sus requisitos es clara y si facilita la
referencia de cada requisito en el desarrollo
futuro o mejora de la documentación.



Tipos de rastreabilidad:


Hacia enfrente
Hacia atrás
Formatos para SRS


RUP
Process Impact
Modelo de Casos de Uso



Una forma de construir la SRS es basada en
casos de uso.
Cada caso de uso puede agrupar a uno o
varios requisitos.
Cada caso de uso se debe documentar.
Documentación de Caso de
Uso
X. Flujo de Eventos para el Caso de Uso
<nombre>
X.1 Precondiciones
X.2 Flujo principal
X.3 Subflujos
X.4 Flujos alternos
X.5 Postcondiciones
Formatos para documentación
de Casos de Uso


RUP
Process Impact
Modelo de Análisis


Una vez especificados los requisitos y
definidos los casos de uso, se procede a la
construcción del modelo de análisis.
Los modelos de análisis OO contienen:




Realizaciones de casos de uso.
Clases de análisis con sus responsabilidades,
atributos y relaciones.
Paquetes.
La vista de la arquitectura.
Realización de casos de uso
Colaboración
Consultar Kardex
ConsultarKardex
Realización del caso de uso
Colaboración


Es una descripción de una colección de
objetos que interactúan para implementar
algún comportamiento dentro de un contexto.
Una colaboración tiene aspectos
estructurales y aspectos de comportamiento.


El aspecto estructural es una vista estática.
El aspecto de comportamiento es el conjunto de
mensajes intercambiados por los objetos.
Escenarios



Son utilizados para describir una
colaboración.
Un escenario es una instancia de un caso de
uso.
Constituye un camino a través del flujo de
eventos del caso de uso.
Escenarios y Casos de Uso


Un caso de uso está compuesto de varios
escenarios.
Escenarios primarios:


Escenarios secundarios:


El flujo normal del caso de uso.
La lógica si-entonces del caso de uso.
Las fases tempranas del análisis se
concentran en los escenarios primarios.
Interacción



Es el conjunto de mensajes dentro de una
colaboración.
Es decir, una interacción define el aspecto de
comportamiento de una colaboración.
El UML provee dos tipos de diagramas para
documentar las interacciones:


Diagrama de Secuencia
Diagrama de Colaboración
Realización de casos de uso
Flujo Básico
1. El sistema solicita
usuario y password
2. El maestro
introduce la
información
3. El sistema la valida
4. El sistema otorga
acceso
Escenario: Flujo Básico
profesor : Maestro
cont rolA cceso
pantallaLogin
captura datos
valida
busca
despliega
FormaAcceso
crea
Menu
crea
TablaUsuarios
ControlAcceso
consulta
consulta
Validador
usuarios:Tabla
despliega
Flujos Alternos
3. 1 Si el usuario o
password es
incorrecto, el sistema
despliega mensaje de
error.
3.2 Si es el tercer
intento bloquea la
cuenta del usuario
validador
menuPrincipal
Clases de Análisis





Una clase de análisis representa una abstracción de
una o varias clases y/o subsistemas del diseño del
sistema.
Se centra en el tratamiento de los requisistos
funcionales.
Raramente define u ofrece una interfaz en términos
de operaciones y sus firmas.
Define atributos de alto nivel.
Las relaciones que se definen para estas clases son
más conceptuales que las de las clases del diseño.
Clases Estereotipadas
Interfaz
Control
Entidad
Clases Interfaz



Se utilizan para modelar la interacción entre
el sistema y sus actores.
Esta interacción regularmente implica recibir
(y presentar) información y peticiones de (y
hacia) los usuarios y los sistemas externos.
Representan abstracciones de ventanas,
formularios, paneles, interfaces de
comunicación, de impresoras, sensores, etc.
Clases Entidad



Se utilizan para modelar información que
posee una vida larga y que comúnmente es
persistente.
Modelan la información y el comportamiento
asociado de algún fenómeno o concepto,
como una persona, objeto del mundo real, o
un suceso del mundo real.
Suelen mostrar una estructura de datos
lógica y contribuyen a comprender de qué
información depende el sistema.
Clases de Control




Representan coordinación, secuencia,
transacciones y control de otros objetos.
Se usan para encapsular el control de un
caso de uso en concreto.
También se usan para representar lógica de
negocios que no puede asociarse a una
clase entidad.
Modelan los aspectos dinámicos del sistema.
Clases Estereotipadas
3:
2: captura datos
1: despliega
profesor : Maestro
pantallaLogin : FormaAcceso
controlAcceso :
ControlAcceso
7:
4: valida
menuPrincipal : Menu
validador : Validador
6:
usuarios :
TablaUsuarios
8: despliega
5: busca
Identificación de Clases



No existe una receta de cocina para
encontrar las clases en el dominio de un
problema.
Un buen comienzo para encontrar las clases
del sistema en desarrollo es buscando las
clases límite, entidad y control.
Ya que el proceso de análisis y diseño es
iterativo, la lista de clases se modificará
conforme avance el tiempo.
Buenas clases



Una buena clase captura una y sólo una
abstracción, deberá tener un sólo tema
principal.
Las clases deberán ser nombradas utilizando
el vocabulario del dominio.
El nombre deberá ser el sustantivo singular
que mejor caracterice la abstracción.
Documentación de Clases



Conforme las clases se van creando, deben
ser documentadas.
La documentación deberá enunciar el
propósito de la clase y no la estructura de la
clase.
Si se tiene dificultad para nombrar o
documentar una clase, puede ser un
indicador de que no es una buena
abstracción.
Formatos para Documentar
Clases

Formato del RUP
Organización en Paquetes



Los artefactos que se van generando
requieren ser organizados, esto se hace
mediante paquetes.
Los paquetes deben ser altamente cohesivos
y débilmente acoplados.
Deben crearse basándose en requisitos
funcionales y en el dominio del problema.
Ejemplo de paquetes
Compras
Ventas
Inventario
Vista de la Arquitectura

Muestra los artefactos significativos para la
arquitectura:




Descomposición del modelo de análisis en
paquetes y sus dependencias.
Clases fundamentales del análisis
Realizaciones de casos de uso que describen la
funcionalidad importante.
Formato del RUP

Notas de la Unidad 7

Transcripción

Documentos relacionados

Comunicado de prensa SCEM/CS/178 RINDEN HOMENAJE AL

himno cebe don josé de san martín