ingenierÍa de requerimientos notas del curso ingeniería de software i dra. maria del pilar gÓmez...

INGENIERÍA DE REQUERIMIENTOS

NOTAS DEL CURSOIngeniería de Software I

DRA. MARIA DEL PILAR GÓMEZ GIL

Versión : 01-Oct-12

(C) P. Gómez-Gil, INAOEP 2009

INGENIERÍA DE REQUERIMIENTOS* Entender los requerimientos de una solución basada en

software es una de las tareas mas difíciles para un(a) Ing. de software.

Como otras actividades de Ing. de Sw, ésta debe adaptarse a las necesidades del proceso, proyecto, producto y gente que hace el software.

La Ing. de Requerimientos provee de un mecanismo apropiado para entender que quiere el consumidor, analizar sus necesidades, valorar la factibilidad de construcción, negociar una solución razonable, especificar de manera no ambigua una solución, validar la especificación y administrar los requerimientos conforme se transforman.

*Referencia: capítulo 7 libro de texto (Pressman 2005)


Tareas de la Ing. de Requerimientos

Iniciación (Inception) Obtención (Elicitation) Elaboración Negociación Especificación Validación (Validation) Administración

Algunas de estas funciones pueden ocurrir en paralelo y ajustarse a las necesidades del proyecto


Iniciación

Como se empieza un proyecto? Algunas veces inicia por conversaciones informales, otras de manera mas formal; normalmente como resultado de una necesidad importante

En esta parte, los ingenieros de software realizan preguntas “libres de contexto” (generales), para establecer un entendimiento básico del problema, determinar las personas que quieren una solución, la naturaleza de la solución, y la efectividad de las colaboraciones y comunicaciones preeliminares que se generan entre el consumidor y el desarrollador


Obtención de Requerimientos

Se refiere a definir formalmente los requerimientos de la solución. Es difícil porque como ya se ha visto:Hay problemas de definición de alcancesHay problemas de entendimiento entre los

involucradosHay problemas de volatilidad (los

requerimientos cambian con el tiempo)


Elaboración

Esta actividad expande y refina la información obtenida en la tarea de iniciación

Se enfoca en realizar modelos técnicos refinados de las funciones del software, características y limitantes.

Es básicamente una función de modelado. Se conduce a través de la definición de escenarios del usuario que describen la interacción del usuario final con el sistema

Se define el dominio del problema desde varios puntos de vista: información, funciones y comportamiento


Negociación

Los usuarios y consumidores normalmente piden mas de lo que se puede hacer con los recursos con que se cuenta.

Casi siempre diferentes involucrados (stakeholders) piden cosas diferentes, por lo que hay que conciliar intereses a través de negociaciones.

Hay varias maneras para negociar, y depende de la cultura de la organización y tamaño del proyecto


Especificación

Especificación significa diferentes cosas para diferentes personas en el área de Ing. de software.

Este es el producto de trabajo final de la ingeniería de requerimientos.

Sirve como base para actividades subsecuentes. Describe la función y desempeño de un sistema y las

restricción que tiene. Hay muchas técnicas para escribir especificaciones:

diagramas, narraciones en prosa, modelos matemáticos, dibujos, etc.


Validación

El producto generado por la ingeniería de requerimientos debe ser evaluado en términos de congruencia y calidad. Se debe asegurar que la especificación concuerda con las expectativas del usuario y que no es ambigua.

Deben detectarse y corregirse errores, omisiones e inconsistencias con respecto a los estándares establecidos en el proyecto.

El mecanismo común de validación es la revisión técnica formal.


Administración de requerimientos Actividades que ayudan al equipo de trabajo a identificar, controlar

y seguir los requerimientos y cambios que ocurren en ellos a través de todo el proceso de desarrollo.

La administración empieza con la identificación de cada requerimiento. Posteriormente se generan tablas que permitirán darles seguimiento. Algunas de éstas son: Tablas de características Tablas de fuentes Tablas de dependencias Tablas de subsistemas Tablas de interfaces


Descripción detallada de las Tareas de la Ing. de Requerimientos

Iniciación (Inception) Obtención (Obtención (ElicitationElicitation)) ElaboraciónElaboración NegociaciónNegociación EspecificaciónEspecificación Validación (Validación (ValidationValidation)) AdministraciónAdministración


Pasos del proceso de Iniciación.

1. Identificación de involucrados (Stakeholders).

2. Reconocimiento de diferentes puntos de vista.

3. Desarrollo de un ambiente colaborativo. Implica identificar puntos en común, áreas de conflicto e inconsistencias.

4. Aplicación de preguntas iniciales.


Algunas preguntas Iniciales típicas Primeras

¿Quién está detrás de la requisición de este trabajo? ¿Quién usará la solución ? ¿ Cual es el beneficio económico de una solución exitosa? ¿ Hay otras fuentes para obtener la solución buscada que se

necesitarán? Siguientes:

¿ Qué sería una “buena salida” para generar una solución eficiente?

¿ Que problemas aparecerán con esta solución? ¿ Podría describirme el medio ambiente en que la solución

funcionará? ¿ Qué aspectos de desempeño o limitaciones afectan la

solución?


Algunas preguntas típicas (2)

Siguientes:¿ Es Usted la persona correcta a

preguntarle? ¿Son sus respuestas “oficiales”?¿ Considera mis preguntas relevantes al

problema que Usted tiene?¿ Le estoy preguntando demasiado?¿ Puede alguien mas darme información

adicional ?


Características de un(a) buen(a) Ing. de Requerimientos

Habilidad para captar conceptos abstractos sintetizándolos y

reorganizándolos en divisiones lógicas. Habilidad para obtener hechos importantes de situaciones

confusas. Habilidad para entender el medio ambiente. Habilidad para comunicarse bien en forma verbal y escrita. Habilidad para "ver el bosque a través de las hojas".


Generación de las Necesidades del Cliente

Herramientas para obtener información de las necesidades del Cliente: Cuestionarios Entrevistas Estudio de campo

Revisión de documentos en la base de datos de conocimiento de la organización

Autoaprendizaje


Cuestionarios Los cuestionarios son útiles especialmente cuando hay una gran

cantidad de usuarios finales.

El diseño de un cuestionario requiere de tiempo y dedicación, ya que un cuestionario deficiente produce frustración y pérdida de interés en el usuario.

El cuestionario debe ser fácil de procesar

En caso de que el cuestionario no se aplique a todos los usuarios, se debe seleccionar correctamente al grupo que realice el cuestionario.


Entrevistas

La entrevista es una herramienta muy útil para obtener información.

Se puede llevar a cabo en cualquier nivel dentro de la organización, desde el presidente hasta el obrero en la línea de ensamble.

La entrevista debe prepararse adecuadamente.


Consejos para Realizar una Entrevista

1) Preparación de la entrevista:

a) Buscar el apoyo del gerente de departamento o jefe donde se llevará a cabo la entrevista.

b) Preparar la entrevista para un tiempo determinado, y dárselo a conocer al entrevistado.

c) Identificar de antemano la posición del entrevistado en la organización, sus responsabilidades y actividades.

d) Acordar de antemano la hora y el lugar de la entrevista. Evitar las interrupciones.

e) Preparar el contenido de la entrevista: temas, preguntas etc.


Consejos Para Realizar Una Entrevista (continuación)

2) Conduciendo la entrevista: a) Presentarse al entrevistado y presentar al proyecto en el que se trabaja.b) Asegurarse de se entendieron correctamente las responsabilidades del

entrevistado. Realizar preguntas de la forma: "tengo entendido que... ".c) Estudiar el método de decisión del entrevistado.d) Evitar palabras técnicas o rebuscadas.e) Darse una idea del "sentimiento" del entrevistado con respecto al sistema.f) Escuchar al entrevistado.g) Preguntar al entrevistado sobre algunas ideas propias que pudieron

olvidarse.h) Al final de la entrevista resumir las conclusiones y escribir una bitácora.i) No tomar demasiadas notas.j) Grabar la entrevista la mayoría de las veces resulta anti-productivo.


- Respuestas falsas por temor a admitir ignorancia

- El usuario tiende a decir lo que el entrevistador quiere oír

- Boicoteo de información

- Actitud cerrada hacia cambios

- Pesimismo total

- Desvío del objetivo fundamental hacia otros problemas de la

organización

Algunos Problemas Durante las Entrevistas


Tareas de la Ing. de Requerimientos

Iniciación (Iniciación (InceptionInception))

Obtención (Elicitation) ElaboraciónElaboración NegociaciónNegociación EspecificaciónEspecificación Validación (Validación (ValidationValidation)) AdministraciónAdministración


Continuando con el análisis...

Según [Larman 99] las principales actividades asociadas al análisis son:Definir los casos de usoDefinir el modelo conceptualDefinir los diagramas de colaboraciónDefinir diagramas de diseño de clases


Obtención de Requerimientos

Incluye juntas colaborativas de definición, despliegue de funciones y descripción de escenarios

Los productos que genera son: Una declaración de necesidades y factibilidades Una declaración delimitada del alcance del sistema o producto Una lista de consumidores, usuarios y otros involucrados

(stakeholders) que participaron en la definición del documento Una descripción del medio ambiente técnico del sistema Una lista de requerimientos, de preferencia organizados por

función, y las restricciones de dominio que los afectan Un conjunto de escenarios de uso que dan idea del uso del

producto en diferentes condiciones operativas Prototipos desarrollados


Desarrollo de casos de uso

Un caso de uso describe el comportamiento del sistema en condiciones diferentes, así como la respuesta del sistema a las requisiciones de uno o mas stakeholders

El primer paso es definir por escrito los “actores” que estarán involucrados en el sistema. Los actores son personas o dispositivos que usan el producto dentro de un contexto o función. Representan los roles de las personas o dispositivos

De manera formal un actor es cualquier cosa que se comunica con el sistema o producto y que es externa a éste. Cada actor puede tener uno o mas objetivos cuando usa el sistema.

Se pueden identificar actores primarios, aquellos que interactúan directamente con el sistema, y secundarios, aquellos que de alguna manera dan soporte al sistema, a fin de que lo primarios puedan realizar su trabajo


Desarrollo de casos de uso (2)

Una vez que se han identificado los actores, lo siguiente es desarrollar el caso de uso. Jacobson sugiere hacer las siguientes preguntas: Quienes son los actores primarios y secundarios? Cuales son las “metas” de los actores? Que precondiciones deben existir antes de que la “historia”

empiece? Que tareas principales son realizadas por el actor? Que excepciones se pueden considerar con respecto a la

descripción de la “historia”?

Continúa...


Desarrollo de casos de uso (2)

Que variaciones en las interacciones del actor son posibles?

Qué sistemas de información adquirirá, producirá o cambiará el actor?

El actor tendrá que informar al sistema acerca de cambios en el medio ambiente externo?

Que información desea el usuario del sistema? Desea el actor ser informado acera de cambios

inesperados?


Símbolos usados en los Diagrama de Casos de Uso de UML*

Caso de Uso


Ejemplo de un Diagrama de Casos de Uso1

1. Sistema de control de registro para maquinas tragamonedas. Alvarez, V. et al.Otoño 04


Escenarios

Cada ovalo en el diagrama de casos de uso debe ser descrito detalladamente, a través de un escenario.


Información principal a Incluir en la descripción de un escenario Nombre del caso de uso Actor principal Objetivo Pre-condiciones Iniciador del caso de uso Descripción del Escenario Excepciones Prioridades Disponibilidad Frecuencia de Uso Canales de comunicación con actores Canales con actores secundarios Puntos aún no resueltos


Descripción

escenarios

[Computer, 02]


Otra P

lantilla para describir escenarios

[Larman,99]


Ejemplo de caso de uso del proyecto “Casa Segura” Involucrados:

Dueño de la casa Administrador de la configuración (probablemente la

misma persona que el dueño) Sensores Subsistema de monitoreo

Escogiendo como “actor” al dueño de la casa…


Sistema Casa Segura


Interacciones de “dueño de la casa” con el sistema Introduce un “password” para permitir otras

interacciones Pregunta sobre el status de una zona de

seguridad Pregunta sobre el status de un sensor Oprime el botón “pánico” en caso de una

emergencia Activa o desactiva el sistema de seguridad


Ejemplo de caso de uso del proyecto “Casa Segura”

[Pressman 2004]


Diagrama de actividades

Representa el flujo de interacción con respecto a un escenario específico

Los rectángulos indican funciones, las flechas indican flujo, los diamantes indican ramas de decisión y las líneas horizontales indican que ocurren actividades en paralelo.


Diagrama de actividades para Licitación de Requerimientos

[Pressman 2004]


Diagramas tipo Swimlane (carriles) Son una variación de los de actividades.

Permiten representar el flujo de actividades y al mismo tiempo indicar que actor(a) o clase tiene la responsabilidad de la acción descrita por el rectángulo. Se divide con líneas verticales el diagrama, una columna por cada actor (como los canales de nado en una piscina).


Diagrama tipo carriles

Fig. 8.8 [Pressman 04]


Unified Modeling Language (UML)1

UML es:Un lenguaje que permite especificar,

visualizar y construir artefactos de softwareUn lenguaje destinado a los sistemas que

utilizan conceptos orientados a objetosNotación estándar para construir modelos

orientados a objetosSolo una notación. No es un método o

proceso de desarrollo


Historia de UML En el 2009 yase liberó la versión 2.2

Diagramas de UML 2.0

Tres tipos, 13 diagramas:1. Diagramas de estructura estática. Incluyen Diagramas

de Clase, Diagramas de Objetos, Diagramas de Componente, Diagramas de Estructura Compuesta, Diagramas de Paquete y Diagramas de Entrega (Deployment)

2. Diagramas de Comportamiento. Incluyen Diagramas de Caso de Uso, Diagramas de Actividades y Diagramas de Estado de Máquina

3. Diagramas de Interacción. Incluyen Diagramas de Secuencia, Diagramas de Comunicación, Diagramas de Sincronización (timing) y Diagramas Generales de Interacción (Interaction Overview Diagram)



Consultar

Object Management Group: UML Resource Page:

http://www.uml.org/

Consultar

Object Management Group: UML Resource Page:

http://www.uml.org/

ANEXO.EJEMPLO DE CASOS DE USO: SISTEMA PRISCUS


Diagrama de flujo de datos de Priscus

[Perea-Centeno 2012]

Bibliografía Anexo

Perea Centeno Liliana. “Interfaz web para el reconocimiento de texto manuscrito y antiguo a través del proyecto Priscus”. Tesis de Licenciatura. Instituto de Estudios Superiores A.C, Benemérita Universidad Autónoma de Puebla. 2012

Cuevas-Farfán E, Gómez-Gil P. “PRISCUS: Reconocedor Óptico de caracteres manuscritos y antiguos.” Memorias técnicas del 9º Encuentro de Investigación. Instituto Nacional de Astrofísica, Óptica y Electrónica. Tonantzintla, Puebla. 6 y 7 de Noviembre 2008.

ingenierÍa de requerimientos notas del curso ingeniería de software i dra. maria del pilar gÓmez...

Documents