capitulo 4. obtención de requerimientos nadie está exento de cometer errores. lo importante es...

Capitulo 4. Obtención de Requerimientos

Nadie está exento de cometer errores. Lo importante es aprender

de ellos. (Karl Popper)

Usa

ndo

UM

L, P

atro

nes

y Ja

vaIn

gen

ierí

a d

e S

oftw

are

Ori

enta

da

a ob

jeto

s

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java

¿Qué es esto?

Pregunta: ¿Cómo cortar el césped?

Lección: Buscar primero la funcionalidad y después definir los objetos

2


¿En dónde estamos?Tres maneras para lidiar con la complejidad:

Abstracción.Descomposición (Técnica: Divide y vencerás).Herencia (Técnica: estratificación).

Dos maneras de tratar con la descomposición:Descomposición: Orientada a objetos y funcional.La descomposición funcional conduce a un código inmanejable.Dependiendo del propósito del sistema, se pueden encontrar

diferentes objetos.¿Cuál es el mejor método?

Empezar por la descripción de la funcionalidad (Modelo de casos de uso ). Luego seguir encontrando objetos (Modelo de objetos).

¿Qué actividades y modelos necesitamos? Esto nos lleva al ciclo de vida del software que utilizamos en clase.

3


Definición del ciclo de vida del Software

Ciclo de vida del Software:Conjunto de actividades y sus relaciones, cada una de las

cuales soporta el desarrollo de sistema software.

Preguntas típicas del ciclo de vida:¿Qué actividades puedo seleccionar para un proyecto

software?¿Qué dependencia hay entre las actividades ? ¿Cómo debo programar las actividades?¿Cuál es el resultado de una actividad ? 4


Ejemplo: Selección de las actividades de ciclo de vida del software para un proyecto específico

Diseño del

Sistema

Diseño de

ObjetosImplementación PruebasObtención de

requerimientos Análisis

Un hacker sólo conoce una actividad:

Implementación

Actividades del ciclo de vida del software

Cada actividad produce uno o mas modelos5


Actividades del ciclo de vida del software

Objetos deldominio de

la aplicación

Subsistemas

clase...clase...clase...

Objetos deldominio

de la solución

CódigoFuente

Casos deprueba

?

Expresado en términos de

Estructurado por

Implementado

porRealizado porVerificado

por

Diseñodel

sistema

Diseñode

objetos

Implemen-tación Pruebas

clase....?

Obtención de requerimientos

Modelo casos de

uso

Análisis de requerimientos

6


Para establecer los requerimientos: Identificar el sistema

El desarrollo de un sistema no sólo se hace tomando una foto de una escena (dominio)

Dos preguntas que son respondidas en el proceso de requerimientos ¿Cómo podemos identificar el propósito de un sistema? Para definir los límites: ¿Qué hay dentro y fuera del sistema?

El proceso de requerimientos consta de dos actividades Obtención de requerimientos:

Definición del sistema en términos entendidos por el cliente (“Descripción del problema”)

Análisis de requerimientos: Especificación técnica del sistema en términos entendidos por el

desarrollador (“Especificación del problema”)7


Definir los límites del sistema es con frecuencia difícil

Qué observa aquí?

8


Productos del proceso de requisitos (Diagrama de actividades)

9

Análisis de Requerimiento

s

Especificacióndel sistema:

Modelo

Modelo de análisis: Modelo

Generación del enunciado del problema

Obtención de Requerimientos

Enunciado del problema


Obtención de Requerimientos

No es una actividad fácilRequiere colaboración de personas con diferentes

conocimientosUsuarios con conocimientos del dominio de aplicación.Desarrolladores con conocimiento del dominio de solución

(de diseño e implementación).Cerrar la brecha entre el usuario y desarrollador :

Escenarios: Ejemplo del uso del sistema en términos de una serie de interacciones entre el usuario y el sistema.

Casos de uso: Abstracción que describe una clase de escenarios.

10


Especificación del sistema vs. Modelo de análisis

Ambos modelos se centran en los requerimientos desde la vista del usuario del sistema.

La especificación de sistema: usa lenguaje natural (derivado del enunciado del problema).

El modelo de análisis utiliza la notación formal o semiformal (por ejemplo, un lenguaje gráfico como UML).

El punto de partida es el enunciado del problema.

11


Enunciado del problemaEl enunciado del problema es desarrollado por el cliente

como una descripción del problema que abordará el sistema.

Un buen enunciado del problema describe:Situación actual.La funcionalidad del nuevo sistema que debe apoyar.El entorno en el cual se desarrollará el sistema.Resultados esperados por el cliente.Fechas de entrega.Un conjunto de criterios de aceptación.

12


Elementos del enunciado del problema Situación actual: el problema a resolver Descripción de uno o más escenarios Requerimientos:

Funcionales o no funcionalesRestricciones (“seudorrequerimientos”)

Agenda del proyectoHitos importantes que involucran la interacción con el cliente,

incluyendo la fecha límite para la entrega del sistema Objetivo del ambiente

El entorno en el que el sistema de entrega tiene que realizar un conjunto específico de pruebas del sistema

Criterio de aceptación del clienteCriterios para las pruebas del sistema

13


Situación actual: El problema a resolver Hay un problema en la situación actual

Ejemplos: El tiempo de respuesta al jugar cartas es demasiado lento.

¿Qué ha cambiado? ¿Por qué se puede resolver el problema ahora?Ha habido un cambio en el dominio de aplicación o en el dominio de la

solución.Cambio en el dominio de aplicación

Una nueva función (proceso de negocio) se introduce en el negocio. Ejemplo: Podemos jugar juegos altamente interactivos con gente remota.

Cambio en el dominio de la solución Ha aparecido una nueva solución tecnológica. Ejemplo: Internet permite la creación de comunidades virtuales.

14


Caso ARENA: El problemaInternet ha hecho posible las comunidades virtuales

Grupos de personas que comparten intereses comunes, pero que nunca se han conocido en persona. Estas comunidades virtuales pueden ser de corta duración (como: personas en una sala de chat o un juego multijugador) o de larga duración (como: suscriptores a una lista de correo).

Muchos juegos multijugador ahora incluyen soporte para comunidades virtuales. Los Jugadores pueden recibir noticias sobre actualizaciones del juego,

nuevos niveles de juegos, anunciar y organizar partidos, y comparar puntajes.

15


Caso ARENA: El problemaActualmente cada compañía de juegos desarrolla ese apoyo

a la comunidad en cada juego individual. Cada compañía usa diferentes infraestructuras y conceptos, y ofrece

diferentes niveles de soporte. Esta inconsistencia y redundancia conduce a los siguientes

problemas:Curva de aprendizaje alta para unirse a una nueva comunidad de

jugadores. Las compañías de juegos deben desarrollar el soporte desde el inicio.Los anunciantes necesitan colocarse en contacto con cada comunidad

individual por separado.

16


Caso ARENA: Los objetivosProporcionar una infraestructura genérica para el

funcionamiento de una ARENA para:Soporte a las comunidades virtuales de juego.Registro de nuevos juegos. Registro de nuevos jugadores.Organizar torneos.Hacer un seguimiento de los puntajes de los jugadores.

Proporcionar un marco de referencia para los organizadores del evento para: Personalizar el número y secuencia de partidos y la acumulación

de puntos de valoración de expertos.

17


Caso ARENA: Los objetivosProporcionar un marco de referencia para los

desarrolladores de juegos para: El desarrollo de nuevos juegos o para la adaptación de los juegos

existentes en el marco de referencia de ARENA.Proporcionar una infraestructura para los anunciantes.

18


Tipos de requerimientosRequerimientos Funcionales:

Describen las interacciones entre el sistema y su entorno, independiente de la implementación Un operador de ARENA debe ser capaz de definir un nuevo juego.

Requerimientos no funcionales: Describen aspectos del sistema visibles para el usuario, que

no están directamente relacionados con el comportamiento funcional del sistema. El tiempo de respuesta debe ser inferior a 1 segundo. El servidor de ARENA debe estar disponible las 24 horas del día.

Restricciones (“Seudorrequerimientos"):Son impuestas por el cliente o el entorno en el cual opera el

sistema El lenguaje de implementación debe ser Java. ARENA debe permitir interactuar dinámicamente a los juegos

existentes con los proporcionados por otros desarrolladores de juegos.

19


¿Qué no debe ir en los requerimientos?

La estructura del sistema, la tecnología de implementación.

La metodología de desarrollo. El ambiente de desarrollo. El Lenguaje de implementación. Reutilización.

Lo ideal es que ninguno de los anteriores estén limitados por lo que diga el cliente .

20


Validación de RequerimientosLa validación de requerimientos es un paso crítico en el proceso de desarrollo, generalmente después de la ingeniería de requerimientos o el análisis de requerimientos. También en la entrega (la prueba de aceptación cliente). Criterios de validación de requerimientos:Corrección:

Los requerimientos representan la visión del cliente. Suficiencia:

Son descritos todos los escenarios posibles en los cuales el sistema puede ser utilizado, incluyendo el comportamiento excepcional por el usuario o el sistema. 21


Validación de Requerimientos

Consistencia: Hay requerimientos funcionales o no funcionales que se contradicen

entre sí.Realismo:

Los requerimientos pueden ser implementados y entregadosTrazabilidad:

Cada función del sistema puede ser rastreada a un correspondiente conjunto de requerimientos funcionales

Problema con la validación de requerimientos: Los requerimientos pueden cambiar muy rápido durante la obtención de requerimientos. 22


Validación de RequerimientosHerramientas de soporte para la administración

de requerimientos:Almacenamiento de requerimientos en un repositorio

compartido.Proporcionar acceso multiusuario.Creación automática de un documento de

especificación del sistema desde el repositorio.Permitir el control de cambios.Proporcionar la trazabilidad a lo largo del ciclo de vida

del proyecto.23


Tipos de obtención de requerimientosIngeniería Greenfield

El desarrollo comienza desde cero, no existe ningún sistema previo, los requerimientos son extraídos de los usuarios finales y el cliente.

Se activa por las necesidades del usuarioEjemplo: Desarrollar un juego desde cero: Asteroides.

ReingenieríaRediseño y/o reimplementación de un sistema

existente utilizando nueva tecnología.Desencadenada por el habilitador de tecnología.

Ejemplo: Reingeniería de un juego.24


Tipos de obtención de requerimientosIngeniería de interfaces

Proporcionar los servicios de un sistema existente en un nuevo entorno.

Desencadenado por el habilitador de tecnología o nuevas necesidades del mercado.Ejemplo: Nueva Interfaz para un juego existente (Bumpers)

25


Escenarios“Es una descripción narrativa de lo que la gente hace y

experimenta cuando trata de utilizar sistemas y aplicaciones de computadora” [M. Carrol, Diseño basado en escenarios , Wiley, 1995]

Es una descripción concreta, centrada e informal de UNA SOLA característica del sistema desde el punto de vista de los actores.

Los escenarios pueden tener usos diferentes durante el ciclo de vida del softwareObtención de requerimientos: Escenario tal como es, Escenario

visionario.Prueba de aceptación del cliente: Escenario de evaluación.Desarrollo del sistema: Escenario de entrenamiento.

26


Tipos de escenarios Escenario tal como es:

Usado en la descripción de una situación actual. Generalmente usado en proyectos de reingeniería. El usuario describe el sistema.

Escenario visionario:Usado para describir un sistema futuro. Generalmente es usado en

Ingeniería Greenfield y en reingeniería de proyectos.No puede ser realizada a menudo por el usuario o el desarrollador

solo.

Escenario de evaluación:Las tareas del usuario por las cuales se va a evaluar el sistema.

Escenario de entrenamiento: Instrucciones paso a paso que guían al usuario novato a través de un

sistema desarrollado.27


¿Cómo identificar escenarios? No espere que el cliente sea claro si el sistema no existe

(Ingeniería Greenfield). No espere que la información esté, incluso si el sistema

existe. Abordar desde un enfoque dialéctico (ingeniería

evolutiva, incremental).Usted ayuda al cliente a formular los requerimientos.El cliente le ayuda a comprender los requerimientos. Los requerimientos evolucionan mientras que los

escenarios están siendo desarrollados.28


Heurísticos para identificar escenariosPreguntas orientadoras:

¿Cuáles son las principales tareas que el sistema necesita para funcionar?

¿Qué datos del actor creará, almacenará, modificará, eliminará o adicionará al sistema?

¿Qué cambios externos se necesita que conozca el sistema?

¿Qué cambios o eventos necesita el actor que le informe el sistema?

Observación de tareas si el sistema ya existe (Ingeniería de interfaz o reingeniería de procesos) Pida hablar con el usuario final, no sólo con el cliente. Espere resistencia y trate de superarla. 29


Ejemplo: Sistema de manejo de accidentes¿Qué hay que hacer para denunciar un incidente de un “gato

en un árbol"? ¿Qué hay que hacer si una persona reporta una “bodega en

llamas”?¿Quién está involucrado en el reporte de un incidente?¿Qué hace el sistema si no hay carros de policía disponibles?,

¿Si el carro del policía tiene un accidente en el camino hacia el incidente de “gato en un árbol" ?

¿Qué necesito hacer si el “gato en un árbol" se convierte en una “abuela que ha caído de una escalera"?

¿Puede el sistema soportar un reporte de incidente simultáneo “bodega en llamas?” 30


Ejemplo de escenario: Bodega en llamas Roberto, conduciendo por la calle principal en su patrulla, observa

que sale humo saliendo de una bodega. Su compañera, Alicia reporta la emergencia desde el carro.

Alicia introduce la dirección del edificio, una breve descripción de su ubicación (es decir, esquina noroeste) y un nivel de emergencia. Además de un carro de bomberos, solicita varias ambulancias en la escena dado que la zona parece estar algo atareada. Ella confirma su entrada y espera una respuesta.

Juan, el distribuidor, es alertado de la emergencia mediante un sonido en su estación de trabajo. Revisa la información presentada por Alicia y da el acuse de recibo del reporte. Él asigna un carro de bomberos y dos ambulancia para el sitio del incidente y envía una hora estimada de llegada (ETA) a Alicia.

Alicia recibe el acuse de recibo y la ETA. 31


Observaciones acerca del escenario “Bodega en llamas”Escenario Concreto

Describe una única instancia para informar de un incidente de fuego.

No menciona todas las posibles situaciones en las que puede un incendio ser reportado.

Actores participantesRoberto, Alicia y Juan

32


Siguiente paso: …formulados los escenariosEncontrar todos los escenario que especifiquen todas las

instancias posibles de cómo reportar un incendio para definir casos de uso

Describir cada caso de uso con mayor detalle Actores participantesDescriba las condiciones de entrada Describa el flujo de eventos Describa las condiciones de salida Describa las excepcionesDescriba los requerimientos especiales (Restricciones,

Requerimientos no funcionales). 33


ReportarEmergencia

Casos de usoUn caso de uso es un flujo de eventos dentro del sistema que incluye

una interacción con los actores.Este es iniciado por un actor.Cada caso de uso tiene un nombre.Cada caso de uso tiene una condición final .Notación Gráfica: Son óvalos que contienen el nombre del caso de uso.

Modelo de casos de uso: Es el conjunto de todos los casos de uso que especifican la funcionalidad completa del sistema. 34


Ejemplo: Caso de uso para el manejo de incidentes

ReportarEmergencia

OficialCampoDespachador

AbrirIncidente

AsingarRecursos

35

<<inicia>>


Heurística: ¿Cómo encuentro los casos de uso?

Seleccione una franja vertical del sistema (un escenario).Discútalo en detalle con el usuario para comprender su

estilo preferido de interacción. Seleccione un segmento horizontal (muchos escenarios)

para definir el alcance del sistema. Discutir el alcance con el usuario.

Utilizar prototipos ilustrativos (maquetas) como apoyo visual

Averigüe sobre que lo que el usuario hace Observación de tareas (Correcto) Cuestionarios (INCORRECTO) 36


Ejemplo de caso de usoNombre caso de uso: ReportarEmergenciaActores participantes:

Oficial de campo (Roberto y Alicia, en el escenario).Despachador (Juan, en el escenario).

Excepciones:El OficialCampo es notificado de inmediato si se pierde la

conexión entre su terminal y la central.El Despachador es notificado inmediatamente si la conexión

entre cualquier OficialCampo registrado y la central se pierde.Flujo de eventos: (ver la siguiente diapositiva)Requerimientos especiales:

El acuse de recibo del reporte del OficialCampo debe darse en menos de 30 segundos. La respuesta llega a más tardar 30 segundos después de que ha sido enviada por el despachador. 37


Ejemplo de caso de usoEl OficialCampo activa la función de “ReportarEmergencia"

desde su terminal. FRIEND responde presentando un formulario al oficial. El OficialCampo diligencia el formulario, seleccionando el nivel de emergencia, tipo, ubicación y una breve descripción de la situación. El OficialCampo también puede describir las posibles respuestas a la situación de emergencia. Una vez completado el formulario, el OficialCampo envía el formulario, en ese momento, el Despachador es notificado.

38


Ejemplo de caso de usoEl Despachador revisa la información presentada y crea un

incidente en la base de datos llamando al caso de uso de AbrirIncidente. El Despachador selecciona una respuesta y da el acuse recibo al reporte de emergencia.

El OficialCampo recibe el acuse de recibo y la respuesta seleccionada.

39


Otro caso de uso: Asignar un recurso

Actores: Supervisor de campo: Este es el oficial en el sitio de

emergencia.Asignador de recursos: El asignador de recursos es

responsable por el compromiso y la liberación de los recursos administrados por el sistema FRIEND.

Despachador: El despachador entra, actualiza y elimina los incidentes de emergencia, las acciones y las solicitudes en el sistema. El despachador también cierra incidentes de emergencia..

Oficial de campo: Reporta accidentes desde el campo.40


Nombre del caso: AsignarRecursosActores participantes:

OficialDeCampo (Roberto y Alicia en el Escenario)Despachador (Juan en el escenario)Asignador de RecursosSupervisor de Campo

Condiciones de entradaEl asignador de recursos ha seleccionado un recurso

disponible.El recurso no está asignado actualmente

41



Flujo de eventosEl asignador de recursos selecciona un incidente de

emergencia. El recurso es asignado al incidente de emergencia.

Condiciones de salidaEl caso de uso termina cuando el recurso es asignado.El recurso seleccionado ya no está disponible para cualquier

otro incidente de emergencia o solicitudes de recursos.Requerimientos especiales

El Supervisor de Campo es responsable de la administración de los recursos. 42



Pasos a seguir cuando se formulan casos de uso

Primer paso: nombre del caso de usoNombre de caso de uso : ReportarEmergencia

Segundo paso: Identificar actores Generalice los nombres concretos (“Roberto”) a los

actores participantes (“OficialDeCampo”)Actores Participantes:

OficialCampo (Roberto y Alicia en el escenario) Despachador (Juan en el escenario)

Tercer paso: Concéntrese en el flujo de eventos Use lenguaje natural e informal.

43


Relaciones entre casos de uso Un modelo de caso de uso se compone de: los casos

de uso y sus relaciones (asociaciones entre casos de uso).

Tipos de relaciones importantes de casos de uso: incluye, extiende, Generalización

IncluyeUn caso de uso utiliza a otro (descomposición

funcional). Extiende

Un caso de uso se extiende a otro caso de uso. Generalización

Un caso de uso tiene diferentes especializaciones. 44


<<incluye>>: Descomposición FuncionalProblema:

La función del planteamiento del problema original es demasiado compleja para ser resuelta inmediatamente

Solución: Describir la función como la agregación de un conjunto de funciones

simples. El caso de uso asociado se descompone en casos de uso más pequeños

ManejarIncidente

CrearIncidente MantenerIncidente CerrarIncidente

<<incluye>>

45

<<incluye>><<incluye>>


<<incluye>>: Reutilizar funcionalidades existentes Problema:

Ya existen funciones. ¿Cómo podemos reutilizarlas? Solución:

La asociación de inclusión desde un caso de uso A a un caso de uso B indica que una instancia del caso uso A realiza todo el comportamiento descrito en el caso de uso B (“A delega a B")

Ejemplo: El caso de uso "VerPlano" describe el comportamiento que puede

ser utilizado por el caso de uso "AbrirIncidente" ("VerPlano" es factorizado)

VerPlanoAbrirIncidente

AsignarRecursos

<<incluye>>

<<incluye>>

Caso de uso base Caso de uso

proveedor

Nota: El caso base no puede existir por sí solo. Este siempre es llamado con el caso de uso proveedor

46


Relación <<extiende>> entre casos de uso Problema:

La funcionalidad en el enunciado del problema original necesita ser ampliada.

Solución: Una relación extiende desde un caso de uso A a un caso de uso

B, indica que el caso de uso B es una extensión del caso de uso A.

Ejemplo: El caso de uso "ReportarEmergencia" es completo por sí mismo,

pero puede ser extendido por el caso de uso “Ayuda" en un escenario específico en el cual el usuario necesita ayuda.

ReportarEmergencia

OficialDeCampoAyuda

<<extiende>>

Nota: El caso de uso base puede ser ejecutado sin la extensión del caso de uso en las asociaciones extiende

47


Asociación de generalización de casos de uso

Problema: Usted tiene un comportamiento común entre casos de uso y quiere

que esto sea un hecho. Solución:

La Asociación de generalización entre factores de casos de uso común comportamiento. Los casos de uso de niño heredan el comportamiento y significado del padre caso de uso y agregar o reemplazar algún comportamiento.

Ejemplo: Consideremos el caso de uso "ValidarUsuario", responsable de verificar

la identidad del usuario. El cliente puede requerir dos ejecuciones: “ValidarContraseña" y “ValidarHuellaDigital”

ValidarUsuario

ValidarContraseña

ValidarHuellaDigital

Caso de usopadre

Caso de uso hijo

48


De casos de uso a objetosNivel Superior del Caso de uso

Nivel 2 - Casos de uso

Operaciones

Ay B son llamadosobjetos

participantes

Nivel 2

Nivel 1

Nivel2

Nivel3 Nivel3

Nivel4 Nivel4

Nivel3

A B49



Los casos de uso se pueden usar para mas de un objeto

Operaciones

Objetos Participantes

Nivel 2

Nivel 1

Nivel2

Nivel3 Nivel3

Nivel4 Nivel4

Nivel3

A B

50


Nivel Superior del Caso de uso



Cómo especificar un caso de uso (Resumen)

Nombre del caso de usoActores

Descripción de los actores involucrados en el caso de usoCondiciones de entrada

“Este caso de uso inicia cuando…”Flujo de eventos

Formulario libre, lenguaje natural e informalCondición de salida

“El caso de uso finaliza cuando…”Excepciones

Describa que pasa cuando las cosas van malRequermientos especiales

Requerimientos no funcionales, restricciones

51


ResumenEl proceso de requerimientos consta de: obtención de

requerimientos y análisis de requerimientos.La actividad de obtención de requerimientos es diferente

para: Ingeniería de Greenfield, reingeniería de procesos, ingeniería de

interfaces

Escenarios:Excelente manera de establecer comunicación con el cliente.Diferentes tipos de escenarios : Escenario tal como es, visionario,

evaluación y pruebas.Casos de uso: Abstracción de escenarios.

52


ResumenLa descomposición funcional pura no es conveniente:

Lleva a un código interminable

La identificación pura de objetos no es conveniente:Podría conducir a definir objetos, atributos y/o métodos incorrectos.

La clave de un análisis exitoso es:Empezar con los casos de uso y después encontrar los objetos. Si alguien pregunta “¿Qué es esto?”, no contestar de inmediato,

observar el usuario final o volver a la pregunta "¿para qué se utiliza?”.

53

capitulo 4. obtención de requerimientos nadie está exento de cometer errores. lo importante es...

Documents