740 likes | 925 Vues
Ingeniería de Requerimientos. Adquisición (Elicitation). Adquisición. Desarrollo. Análisis. Especificación. Validación. Control de Cambios. Administración. Control de Versiones. Seguimiento. Ingeniería de Requerimientos. Temas. Generalidades Técnicas de adquisición
E N D
Ingeniería de Requerimientos Adquisición (Elicitation)
Adquisición Desarrollo Análisis Especificación Validación Control de Cambios Administración Control de Versiones Seguimiento Ingeniería de Requerimientos
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 • Generalidades • Técnicas de adquisición • Técnicas de modelado
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
Técnicas de adquisición • Grupales • Sesiones intensivas (JAD) • Tormenta de Ideas • Muro de las maravillas • Orientadas a modelos • Escenarios • Basados en objetivos
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
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
No restringida Apoyo a decisiones tácticas Videojuego Sistema de contabilidad Tipo de aplicación Sistema de control de la producción Mejoras al sistema de contabilidad Sistema de control de vuelo para aviones Muy restringida Sistema de guía de misiles Relativamente alto Relativamente bajo % Requerimientos aproximado Obtenido de personas Técnicas de adquisición
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 • JointApplicationDevelopment • 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 • 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 • 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 • 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
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
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