ingeniería de requerimientos adquisición (elicitation)

Ingeniería de RequerimientosAdquisición(Elicitation)

Sandra Victoria Hurtado Gil, 2009


Ingeniería deRequerimientos

Especificación

Validación

Análisis

Adquisición

Desarrollo

Administración Control de Versiones

Seguimiento

Control de Cambios


Temas

•Generalidades•Técnicas de adquisición•Técnicas de modelado


Generalidades

•Es un problema humano▫No tiene una solución técnica definitiva

•Involucra▫Psicología Cognitiva

Entendimiento de las dificultades de las personas para describir sus necesidades

▫Antropología Aproximación metodológica para observar las

actividades humanas, que ayudan al desarrollador a entender cómo el sistema ayuda o dificulta estas actividades


Generalidades

•Involucra▫Sociología

Entendimiento de los cambios políticos y culturales causados por la automatización.

▫Lingüística Importante porque la ingeniería de requerimientos se

basa en la comunicación. Ayuda a definir la forma de usar el lenguaje para evitar ambigüedades.

▫ Filosofía Interpretar y entender los términos, conceptos, puntos

de vista y objetivos de las personas interesadas.


Generalidades

•Es el área con mayor incidencia de malas prácticas y con gran impacto en el proyecto

•Diferencias entre▫Usuarios/Clientes

Términos del dominio del negocio▫Desarrolladores

Términos del software


Generalidades

•Los clientes▫No saben lo que quieren▫No están preparados para definir

adecuadamente lo que quieren▫Tienen muchas influencias externas, que

dificultan saber lo que quieren


Generalidades

•Los ingenieros de software▫Están de acuerdo en que la adquisición de

requerimientos es importante, pero aún así Gastan muy poco tiempo realizándola Se realizan muchos supuestos, se dejan de

lado muchas fuentes de información


Generalidades

•Riesgos de un proceso inadecuado▫Pérdida de tiempo por requerimientos

ambiguos o funcionalidades innecesarias▫Producto no aceptado por el usuario▫No incluir funciones necesarias▫Planificaciones que no se cumplen


Generalidades

•Es fundamental que las personas interesadas conozcan la importancia de los requerimientos▫Implicaciones de costo▫Éxito/Fracaso de proyectos


Temas



Adquisición

•Obtener de los interesados lo que ellos saben (y nosotros no)

•Proceso de comunicación e interacción•Se debe registrar toda la información que

se obtiene


Técnicas de adquisición

•Tradicionales▫Cuestionarios▫Entrevistas▫Análisis de documentación existente

Manuales de procesos, regulaciones, etc.▫Reingeniería (aplicaciones legado)▫Evaluación de productos existentes



•Grupales▫Sesiones intensivas (JAD)▫Tormenta de Ideas▫Muro de las maravillas

•Orientadas a modelos▫Escenarios▫Basados en objetivos



•Prototipos▫Desechables - Evolutivos

•Cognitivas▫Observación▫Análisis de protocolos (Las personas

explican en voz alta mientras trabajan)▫Ordenar tarjetas con conceptos/atributos



•Determinar las técnicas que se utilizarán (no una sola), de acuerdo con las características del proyecto

•Por ejemplo, para aplicaciones muy restringidas no es necesaria tanta interacción con los usuarios



Tipo de aplicación

% Requerimientos aproximadoObtenido de personas

Muy restringida

No restringida

Relativamentebajo

Relativamente alto

Sistema de guía de misiles

Sistema de control de vuelo para aviones

Mejoras al sistema de contabilidad

Sistema de control de la producción

Sistema de contabilidad

Videojuego

Apoyo a decisiones tácticas


Ejercicio

•Adapte los derechos y deberes de los usuarios, propuestos por Karl Wiegers, para usarlos en un posible instructivo del proceso de requerimientos para su empresa


Cuestionarios

•Recolectar información de un gran número de personas

•Centrarse en pocos aspectos del sistemas▫Pocas preguntas, concretas

•Combinar preguntas cerradas y abiertas▫Si-No, Selección múltiple, Ordenar o

calificar•La redacción de las preguntas es

importante▫No ambiguas, no orientar a una respuesta


Entrevistas

•Reuniones “cara a cara” entre analistas y personas interesadas

•Es una forma de conversación, no solo de interrogación

•Ideal para recoger opiniones, sugerencias, comentarios, descubrir errores de entendimiento


Entrevistas

•Preparar▫Definir qué información se desea

Depende del tipo de usuario▫Recolectar información de otras fuentes

Conocer el dominio▫Seleccionar a las personas a entrevistar

Priorizar


Entrevistas

•Preparar▫Acordar cita, definir tiempos y enviar

temas a tratar al entrevistado▫Elaborar un guión preliminar

¿Qué hace cada usuario?, ¿Cómo lo hace?, ¿Qué necesita para hacerlo?, Casos excepcionales

Tener en cuenta requerimientos no funcionales, como disponibilidad, fechas/horas con mayor número de transacciones


Entrevistas

•Directivo▫Políticas, Estrategias▫Limitaciones generales

•Ejecutivo▫Objetivos, procedimientos, requerimientos

de información▫Sistemas relacionados▫Otras personas a entrevistar


Entrevistas

•Operativo▫Funciones que realiza actualmente y

sugerencias para mejorar Tipo de entradas Tipo de salidas Consultas / Informes Prioridades de los procedimientos


Entrevistas

• Aspectos▫ Escuchar, escuchar, escuchar.

Incluso si se aleja del tema▫ No suponga que usted tiene la respuesta

lista▫ No suponga que algunas cosas que se dicen

están fuera del alcance. ¡No se conoce el alcance del problema hasta escuchar a todas las personas interesadas!


Entrevistas

• Aspectos▫ La realidad es mucho más extraña de lo que

usted espera▫ Los deseos pueden ocultar necesidades


Entrevistas

•Aspecto clave: ▫Ir más allá de lo operativo▫Entender la razón – contexto – ejemplos –

posibilidades de mejora


Entrevistas

•Evitar▫Usar lenguaje muy técnico▫Influenciar (tendencia a dar información o

resaltar lo que más nos gusta)▫Ejemplo

Preguntar ¿qué le parece que el software tenga tal característica?


Entrevistas

•Debe incluir un seguimiento posterior▫Correo electrónico▫Actas▫Documentos / diagramas▫Reunión corta


Referencia

•Ejemplo de métricas para el proceso de entrevistas▫Libro “Ingeniería de Software: Una

perspectiva orientada a objetos”, de Eric Braude, página 172


Consideraciones

•Buscar los detalles – ser específicos▫Ejemplo: Los reportes de impuestos deben

reflejar el nuevo proceso que se tiene en la empresa al respecto ¿Cuál es el nuevo proceso al cual se hace

referencia? ¿Qué reportes específicamente? ¿Se tiene algún tipo de prueba para

asegurarse de que los resultados son los esperados?


Consideraciones

•El software no siempre es para el momento actual, es para el futuro▫No limitarse a automatizar lo existente

•Preguntar el porqué de las cosas•Proponer sin imponer

▫Es un diálogo donde cada parte aporta▫Señalar posibles mejoras o costos técnicos


Evaluación de productos existentes•Identificar

▫Información que es importante para los procesos (entradas, reportes)

▫Organización de las funciones▫Características importantes o novedosas▫Problemas que se deben evitar


Evaluación de productos existentes•Obtener medidas que pueden servir de

base▫Tiempos de respuesta▫Tiempo promedio para realizar una acción▫Satisfacción del usuario


JAD

•Joint Application Development▫Desarrollo conjunto de aplicaciones▫Proceso de recolección de datos acelerado,

en el cual los usuarios y analistas se reúnen en una única e intensa reunión, que puede durar de uno a cuatro días, con el objetivo de definir los requerimientos de los usuarios


JAD

•Principios▫Hacer partícipes a los usuarios▫Dinámica de grupo▫Uso de ayudas audiovisuales▫Proceso organizado y documentado


JAD


JAD

•Preparación▫Obtener información preliminar para

delimitar los aspectos a tratar en la reunión▫Definir grupos de trabajo ▫Elaborar una agenda▫Elaborar un documento (o documentos) con

la información recolectada hasta el momento


JAD

•Reunión - Orden sugerido▫Recordar reglas, objetivos▫Definir visión, contexto▫Mini – tutorial de las herramientas a usar

Casos de uso, CRC, storyboards, etc.▫Trabajo en subgrupos▫Preguntas, acuerdos


JAD


JAD

•Durante 1 a 4 días los equipos crean una especificación del sistema▫Flujo de trabajo▫Datos▫Reportes▫Pantallas

•Se documentan las decisiones tomadas (y se dejan en lugares visibles)


JAD•Consideraciones

▫Lugar alejado del trabajo▫Ambiente de respeto y confianza


JAD

•Después▫Se elabora un documento final▫Se distribuye entre los participantes para

su revisión▫Reunión de 1 a 2 horas para la revisión

final del documento


Tormenta de ideas

•No tiene estructura definida•Preguntas y respuestas libres•Ayuda a obtener información general,

llegar a consensos sobre objetivos del sistema e identificar algunos conflictos

•Surgen temas no previstos


Tormenta de ideas

•Ambiente libre de críticas y juicios•Grupos de 4 a 10 personas•No hay un líder•Los participantes se comprometen a

generar ideas sin discutir sus méritos•Se escriben la ideas y se colocan en

lugares visibles


Tormenta de ideas

•Posteriormente▫Se revisan y organizan las ideas

Clarificar Unir ideas comunes

▫Se descartan ideas que no son factibles▫Se priorizan las ideas▫Se documenta


Muro de las maravillas

• Pasos1. Listar ítems, individualmente

Definir previamente las áreas de trabajo mediante preguntas claves

Permitir un espacio breve de discusión Cada persona anota posibles respuestas a

las preguntas clave. Cada respuesta es un ítem



• Pasos2. Formar subgrupos de participantes para

seleccionar los ítems más importantes Se define el tiempo de trabajo Cada ítem se anota en una tarjeta

De 3 a 5 palabras Letra grande

De 7 a 9 ítems por grupo



• Pasos3. Pegar las tarjetas en la pared (sin

ningún orden en particular) Algunos grupos pueden aclarar el

significado de sus tarjetas



• Pasos4. Agrupar las tarjetas relacionadas

Se pueden crear/eliminar tarjetas Se da un nombre significativo a cada

grupo de tarjetas

Abc Def Hij TarjetasSin grupo



• Pasos5. Analizar

Extender el contenido de cada grupo Preguntar a las personas por los ítems que

definieron inicialmente Realizar verificaciones finales


Escenarios

•Ejemplo concreto de uso del sistema•Representa una situación posible de

interacción con el sistema•Un caso de uso agrupa varios escenarios• Tipos

▫Actuales▫Futuros


Escenarios

•Ejemplo▫Roberto y Alicia, que van en su patrulla,

observan que sale humo de una bodega. ▫Alicia activa la función “Reportar emergencia”

en su PDA. Ingresa la dirección y un nivel de emergencia. Solicita un carro de bomberos y espera respuesta.

▫Juan, el despachador, recibe una alerta en su estación de trabajo. Revisa el reporte enviado y da un acuse de recibo. Asigna un carro de bomberos y envía el tiempo estimado de llegada.

▫Alicia recibe el acuse de recibo.


Escenarios

•Ejemplo▫Juan, quien comenzó a trabajar esta semana,

recibe una llamada telefónica del Sr. Jones. El Sr. Jones le dice que realizó un pedido hace tres meses y aún no ha recibido la mercancía. Con la cédula del Sr. Jones, Juan consulta el estado del pedido y observa que fue despachado la semana pasada. Juan le informa al Sr. Jones que debe recibir la mercancía esta semana. También aprovecha para actualizar el número de teléfono del Sr. Jones, pues está errado.


Escenarios

•Pueden acompañarse de “Storyboards”▫Esquemas o borradores de las pantallas o

las situaciones▫Cada pantalla tiene una descripción de las

acciones que se realizan▫Muy usado para multimedia

•Ejemplo


Escenarios

Dirección:

Nivel Emergencia: Alto

Descripción:

Cra 20 Con Calle 18

Incendio. Enviar bomberos

…

Alicia activa la función “Reportar emergencia” en su PDA

Ingresa la dirección y un nivel de emergencia. Solicita un carro de bomberos y espera respuesta

Reportar Emergencia


Observación

•El proceso actual puede diferir del establecido formalmente

•Las personas a veces encuentran difícil explicar lo que hacen porque es algo natural para ellos

•Se observa a las personas para luego representar la forma de hacer el trabajo


Observación

•Guías▫Invierta tiempo conociendo a las personas y

estableciendo una relación de confianza ▫Suponga que la gente es buena haciendo su

trabajo▫Busque alternativas para hacer las cosas▫Lleve notas detalladas


Temas



•Modelar permite:▫Mostrar los detalles esenciales de un

problema complejo y filtrar los no esenciales

▫Visualizar el sistema ha ser desarrollado desde diferentes perspectivas

▫Mejorar la comunicación, al representar la información claramente para diferentes personas


Técnicas de modelado

•Algunas técnicas (I)▫Diagramas de flujo de datos▫Diagramas UML

Casos de uso Actividades Estados


Técnicas de modelado

•Algunas técnicas (II)▫Prototipos▫Diagramas de Entrada/Salida▫Árboles de decisión▫Tablas de decisión


Diagramas de flujo de datos

•Elementos▫Proceso o Función:

▫Entidad Externa:

▫Flujo:

▫Almacenes de datos:



•Diagramas de contexto▫Entidades externas▫Sistema como un gran proceso

•Diagramas de nivel uno



•Ejemplo diagrama de contexto

Agenda de compromisos

Secretaria PersonaSolicitud Compromisos pendientes

Listado compromisos pendientes Datos nuevo

compromiso

Confirmación


Diagrama de Estados

•Permite▫Modelar comportamiento discreto▫Posibles estados de una clase (objeto) o del

sistema Cambios de una pantalla a otra


Diagrama de Estados

•Principales elementos

▫Estado

▫Estado inicial

▫Estado final

▫Transición


Diagrama de Estados

•Ejemplo – un proyecto:

EnDefinición

aprobar

EnDesarrollo

avancesterminar

Cerrado


Diagrama de Estados

•Estado:

Nombre

Actividades Internas


Diagrama de Estados

•Actividades internas:▫On Entry▫On Exit▫Do▫Otras (personalizadas)


Diagrama de Estados

•Ejemplo – pantallas:

Menú CoordinadorPrograma

Salir

Gestionar Evaluación

do/CrearEvaluacióndo/ModificarEvaluacióndo/EliminarEvaluacióndo/ConsultarEvaluación

Opción Gestión Evaluaciones

Salir Activar Evaluaciones

entry/Validar que existan evaluacionesdo/Activar o desactivar evaluaciones

Opción Activar Evaluaciones Salir


Ejercicio

•Elaborar el diagrama de estados que muestre las diferentes pantallas del sistema de ejemplo


Enlaces

•Método de desarrollo basado en el usuario:▫http://www.usabilitynet.org/trump/methods/

index.htm•Diagramas de estado:

▫http://sparxsystems.com.au/resources/uml2_tutorial/uml2_statediagram.html

http://www.usabilitynet.org/trump/methods/index.htm

http://www.usabilitynet.org/trump/methods/index.htm

http://sparxsystems.com.au/resources/uml2_tutorial/uml2_statediagram.html

http://sparxsystems.com.au/resources/uml2_tutorial/uml2_statediagram.html

ingeniería de requerimientos adquisición (elicitation)

Documents