La descarga está en progreso. Por favor, espere

La descarga está en progreso. Por favor, espere

Ingeniería de Requerimientos

Presentaciones similares


Presentación del tema: "Ingeniería de Requerimientos"— Transcripción de la presentación:

1 Ingeniería de Requerimientos
Adquisición (Elicitation)

2

3 Ingeniería de Requerimientos Especificación Validación Análisis Adquisición Desarrollo Administración Control de Versiones Seguimiento Control de Cambios

4 Temas Generalidades Técnicas de adquisición Técnicas de modelado

5 Generalidades Es un problema humano Involucra
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 Bashar Nuseibeh y Steve Easterbrook. Requirements Engineering: A Roadmap, 2000

6 Generalidades Involucra Sociología Lingüística Filosofí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.

7 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

8 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

9 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

10 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

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

12 Temas Generalidades Técnicas de adquisición Técnicas de modelado

13 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 Martina Marré. Notas curso Ingeniería del Software I, 2002.

14 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 Bashar Nuseibeh y Steve Easterbrook. Requirements Engineering: A Roadmap, 2000

15 Técnicas de adquisición
Grupales Sesiones intensivas (JAD) Tormenta de Ideas Muro de las maravillas Orientadas a modelos Escenarios Basados en objetivos

16 Técnicas de adquisición
Prototipos Desechables - Evolutivos Cognitivas Observación Análisis de protocolos (Las personas explican en voz alta mientras trabajan) Ordenar tarjetas con conceptos/atributos

17 Técnicas de adquisición
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

18 Técnicas de adquisición
Tipo de aplicación % Requerimientos aproximado Obtenido de personas Muy restringida No restringida Relativamente bajo 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 Braude, Eric. Ingeniería de Software: Una perspectiva OO, 2003

19 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 Karl. E Wiegers. Software Requirements, Second Edition, 2003.

20 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

21 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

22 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

23 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

24 Entrevistas Directivo Ejecutivo Políticas, Estrategias
Limitaciones generales Ejecutivo Objetivos, procedimientos, requerimientos de información Sistemas relacionados Otras personas a entrevistar

25 Entrevistas Operativo
Funciones que realiza actualmente y sugerencias para mejorar Tipo de entradas Tipo de salidas Consultas / Informes Prioridades de los procedimientos

26 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! Ian Alexander, 2005

27 Entrevistas Aspectos La realidad es mucho más extraña de lo que usted espera Los deseos pueden ocultar necesidades Ian Alexander, 2005

28 Entrevistas Aspecto clave: Ir más allá de lo operativo
Entender la razón – contexto – ejemplos – posibilidades de mejora

29 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?

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

31 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

32 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?

33 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

34 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

35 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

36 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

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

38 JAD

39 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

40 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 Scott Burkett. JAD: Facilitation Workshop Basics, 2006

41 JAD María de los Ángeles Sumano López.
Áncora: Metodología para el Análisis de Requerimientos de Software conducente al Reuso, 2001

42 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)

43 JAD Consideraciones Lugar alejado del trabajo
Ambiente de respeto y confianza

44 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

45 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

46 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

47 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

48 Muro de las maravillas Pasos 1. 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 Ellen Gottesdiener. Specifying Requirements With a Wall of Wonder, 2001

49 Muro de las maravillas Pasos
2. 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

50 Muro de las maravillas Pasos
3. Pegar las tarjetas en la pared (sin ningún orden en particular) Algunos grupos pueden aclarar el significado de sus tarjetas

51 Muro de las maravillas Pasos 4. Agrupar las tarjetas relacionadas
Se pueden crear/eliminar tarjetas Se da un nombre significativo a cada grupo de tarjetas Abc Def Hij Tarjetas Sin grupo

52 Muro de las maravillas Pasos 5. Analizar
Extender el contenido de cada grupo Preguntar a las personas por los ítems que definieron inicialmente Realizar verificaciones finales

53 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

54 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.

55 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. Tomado de:

56 Escenarios Pueden acompañarse de “Storyboards” Ejemplo
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

57 Escenarios … Reportar Emergencia Dirección: Nivel Emergencia: Alto
Descripción: Cra 20 Con Calle 18 Incendio. Enviar bomberos Ingresa la dirección y un nivel de emergencia. Solicita un carro de bomberos y espera respuesta Alicia activa la función “Reportar emergencia” en su PDA

58 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 G. Kotonya and I. Sommerville, 1998

59 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

60 Temas Generalidades Técnicas de adquisición Técnicas de modelado

61 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

62 Técnicas de modelado Algunas técnicas (I) Diagramas de flujo de datos
Diagramas UML Casos de uso Actividades Estados

63 Técnicas de modelado Algunas técnicas (II) Prototipos
Diagramas de Entrada/Salida Árboles de decisión Tablas de decisión

64 Diagramas de flujo de datos
Elementos Proceso o Función: Entidad Externa: Flujo: Almacenes de datos:

65 Diagramas de flujo de datos
Diagramas de contexto Entidades externas Sistema como un gran proceso Diagramas de nivel uno

66 Diagramas de flujo de datos
Ejemplo diagrama de contexto Agenda de compromisos Secretaria Persona Solicitud Compromisos pendientes Listado compromisos pendientes Datos nuevo compromiso Confirmación

67 Diagrama de Estados Permite Modelar comportamiento discreto
Posibles estados de una clase (objeto) o del sistema Cambios de una pantalla a otra

68 Diagrama de Estados Principales elementos Estado Estado inicial
Estado final Transición

69 Diagrama de Estados Ejemplo – un proyecto: aprobar terminar avances En
Definición aprobar terminar Cerrado En Desarrollo avances

70 Diagrama de Estados Estado: Nombre Actividades Internas

71 Diagrama de Estados Actividades internas: On Entry On Exit Do
Otras (personalizadas)

72 Diagrama de Estados Ejemplo – pantallas:
nálisis y Diseño Orientado a Objetos con UML y el Proceso Unificado - Stephen Schach

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

74 Enlaces Método de desarrollo basado en el usuario:
ex.htm Diagramas de estado: orial/uml2_statediagram.html


Descargar ppt "Ingeniería de Requerimientos"

Presentaciones similares


Anuncios Google