Ingeniería de Requerimientos Análisis

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

Análisis El objetivo del análisis es descubrir problemas, inconsistencias y faltantes en los requerimientos adquiridos. Esto sirve de retroalimentación para las personas interesadas, de manera que se puedan resolver mediante un proceso de negociación

Temas Priorizar Identificar problemas Identificar oportunidades Negociar

Los proyectos de software tienen recursos limitados Priorizar Los proyectos de software tienen recursos limitados Es importante priorizar los requerimientos Ayuda a resolver conflictos Permite planificar las entregas Facilita el uso adecuado de los recursos Balancear beneficios y costos Software Requirements by Karl E. Wiegers, Microsoft Press, 1999

Es un trabajo realizado entre usuarios/clientes y desarrolladores Priorizar Es un trabajo realizado entre usuarios/clientes y desarrolladores Usuarios/clientes definen las funciones con mayores beneficios Desarrolladores definen costos, riegos técnicos, y dificultad de cada función Todos los requerimientos pactados se implementarán, pero algunos no son tan esenciales

Priorizar Escalas Pocos valores Tres valores Puede ser subjetiva Todos deben estar de acuerdo en el significado Tres valores Alta – Media – Baja Esencial – Condicional – Opcional Crítica – Importante - Útil

Priorizar Alta – Esencial Requerimiento de misión crítica El software no es aceptable sin él 2 1 3

Priorizar Media – Condicional Baja – Opcional Operaciones de soporte del sistema Amplía la funcionalidad del software, pero se puede aceptar sin él al comienzo Baja – Opcional Interesante tener esta funcionalidad o cualidad, si los recursos lo permiten Funciones que no son muy valiosas

Priorizar La prioridad de cada requerimiento debe ir en la especificación de los casos de uso o en la especificación de los requerimientos En un caso de uso con varias alternativas, algunas pueden tener mayor prioridad que otras

Las demás características Priorizar Identificar Regulaciones externas Funciones núcleo del negocio y/o diferenciadoras Las demás características Priorizar basados en costos, beneficios y riesgos

Priorizar RUP Priorizar basado en: Beneficios (para el negocio) Crítico, importante, útil Impacto en la arquitectura Ninguno, extiende, modifica Riesgos Tienen más alta prioridad los más críticos, con mayor impacto y riesgo

Priorizar Pasos (1) Hacer una lista con los casos de uso y los requerimientos del sistema que no están en los casos de uso Para cada caso de uso/requerimiento se califican de 0 a 3 los siguientes aspectos: Significativo para la arquitectura Riesgo Naturaleza crítica (beneficio) Craig Larman. UML y Patrones: Una introducción al análisis y diseño orientado a objetos y al proceso unificado, 2003

Priorizar Pasos (2) Se determina el peso que se dará a cada aspecto, en un rango de 1 a 3 Se calcula la prioridad de cada caso de uso/requerimiento, sumando los valores de cada aspecto (multiplicados previamente por su respectivo peso) Los valores más altos corresponden a las mayores prioridades

Priorizar Ejemplo: Pesos: Arq: 1, Riesgo: 2, Beneficio: 3 … Requisito Tipo Arq. Riesgo Beneficio Suma Procesar venta CU 2 3 11 Gestionar devoluciones 1 6 Soporte para varios lenguajes Req. 10 … Pesos: Arq: 1, Riesgo: 2, Beneficio: 3

Priorizar XP Planning Game Priorizar basado en: Importancia para el negocio Esfuerzo (costo) Riesgo

Priorizar XP Los usuarios/clientes definen el valor para el negocio (crítico – significante - útil) Los desarrolladores definen el riesgo (bajo, medio, alto) y estiman el esfuerzo Se negocian las prioridades y se selecciona la historia de usuario que se implementará http://en.wikipedia.org/wiki/Extreme_Programming_Practices#Planning_game

Priorizar Karl Wiegers Priorizar basado en: Valor del requerimiento Beneficio, costo de no tenerlo Costo y riesgo Implementación, elementos técnicos La prioridad está directamente relacionada con el valor e inversamente relacionada con el costo y el riesgo

Priorizar Pasos (1) Listar los requerimientos, características o casos de uso que se desean priorizar Estimar el beneficio relativo (1 muy bajo, 9 el máximo) Basado en los objetivos del negocio Determinado principalmente por los clientes

Priorizar Pasos (2) Estimar el costo de no tener la función (1 bajo, 9 alto) Valor = Suma del beneficio y el costo Se puede dar un peso a cada uno Estimar el costo de implementar la función (1 bajo, 9 alto) Complejidad, Interfaz de usuario, … Determinado por los desarrolladores

Priorizar Pasos (3) Estimar el riesgo asociado (1 bajo, 9 alto) Falta de experiencia, tecnología nueva, … Calcular la prioridad, así: Prioridad = % Valor / (% Costo + % Riesgo) Se puede dar pesos al costo y al riesgo El porcentaje es con respecto al total de todas las funciones evaluadas

Priorizar Pasos (4) Ordenar de forma descendente Los primeros elementos, por tener un balance favorable en costo/beneficio, son candidatos a tener alta prioridad

Priorizar Ejemplo Req. Bene-ficio Costo no tener Valor % Costo Riesgo Priori-dad R1 5 3 13 8.4 2 4.8 1 1.3 R2 9 7 25 16.2 11.9 9.1 0.9 … T: 154 42 33 Pesos: Beneficio: 2, Costo no tener: 1, Costo: 1, Riesgo: 0.5

Priorizar Tablas: Son una herramienta de gran ayuda, que incluye elementos numéricos en una valoración que generalmente es subjetiva Los resultados obtenidos deben ser revisados, pues sirven de guía pero no son absolutos

Otros aspectos que se pueden considerar Priorizar Otros aspectos que se pueden considerar Volatilidad de los requerimientos Competidores Recursos …

Ejercicio Elabore una plantilla para calcular las prioridades de los requerimientos

Priorizar Otras técnicas Voto acumulativo (100-Dollar Test) Distribuir 100 unidades (pesos, horas) entre los requerimientos Puntuación (Ranking) Dar un puntaje de 1 a N (para N requerimientos), donde 1 es el menos importante Diez primeros (Top Ten) http://books.google.com/books?id=pUG1IaikDhMC&printsec=frontcover&source=gbs_v2_summary_r&cad=0#v=onepage&q&f=false (AURUM, Aybüke y WOHLIN, Claes. Engineering and Managing Software Requirements. Springer, 2005)

Temas Priorizar Identificar problemas Identificar oportunidades Negociar

Identificar problemas Determinar Los requerimientos son factibles Técnicamente Económicamente Operacionalmente No hay contradicciones/inconsistencias

Identificar problemas Algunas técnicas Lista de preguntas Revisar casos de uso Matriz de requerimientos Matriz CRUD

Identificar problemas Ejemplo Lista de preguntas ¿Los requerimientos son consistentes con los objetivos propuestos? ¿Hay requerimientos “cosméticos”, es decir, que no son realmente necesarios? ¿Se requiere tecnología con la que no se cuenta actualmente? ¿Algún requerimiento se puede dividir en otros requerimientos? G. Kotonya and I. Sommerville. Requirements Elicitation and Analysis,1998

Identificar problemas Revisar casos de uso (1) El diagrama de casos de uso presenta claramente el comportamiento del sistema No hay cadenas de relaciones “include” y/o “extends” Hay pocas dependencias entre casos de uso Todas las relaciones entre los casos de uso están justificadas

Identificar problemas Revisar casos de uso (2) Se han identificado todos los casos de uso No hay casos de uso innecesarios Si el modelo es muy grande o las responsabilidades están distribuidas, se han utilizado paquetes Los paquetes hacen el modelo más fácil de entender

Identificar problemas Matriz de requerimientos Filas y columnas con los requerimientos Cero (0) si son independientes Uno (1) si presentan algún conflicto Dos (2) si tienen elementos comunes, es decir, se solapan

Identificar problemas Ejemplo - Matriz de requerimientos R1 R2 R3 R4 R5 R6 ­ 2 1  

Identificar problemas Matriz CRUD Permite encontrar requerimientos faltantes Filas  Casos de uso Columnas  Entidades - Conceptos Celdas: C: Crear R: Leer - Consultar U: Actualizar D: Borrar

Identificar problemas Ejemplo – Matriz CRUD Entidades Casos de uso Orden Químico Solicitante Proveedor Ingresar orden C R Cambiar orden U,D   Gestionar inventario de químicos C,U,D Reporte de órdenes Editar solicitantes C,U,R

Identificar problemas Entidades que no tengan alguna de las acciones ¿Falta un caso de uso? ¿Algún caso de uso está incompleto? ¿El objeto no es necesario? ¿Falta determinar alguna regla del negocio?

Ejercicio Elabore la matriz CRUD para los casos de uso y entidades en el ejemplo Determine posibles requerimientos faltantes

Temas Priorizar Identificar problemas Identificar oportunidades Negociar

Identificar oportunidades Refinar los requerimientos ¿Cómo va a ser el resultado? ¿Cómo va a ser la entrada? Requerimiento Restricciones de datos Restricciones de tiempo de ejecución

Identificar oportunidades Requerimientos explícitos Se declaran y establecen Requerimientos implícitos Se asume que se deben cumplir Requerimientos innovadores Van más allá de las expectativas del cliente

Identificar oportunidades Mejorar “usabilidad” (facilidad de uso) del sistema Ayudas o guías para el usuario No son triviales, impactan positivamente Promedio de uso de cada acción Acciones más frecuentes tienen mayor prioridad y facilidad de acceso

Temas Priorizar Identificar problemas Identificar oportunidades Negociar

Negociar Consiste en llegar a un acuerdo en los requerimientos, con las personas interesadas en el proyecto Se realiza Cuando hay conflictos Diferentes objetivos y perspectivas de las personas interesadas

Se deben identificar los conflictos Negociar Se deben identificar los conflictos Elementos en conflicto Autores, Fuentes Participarán en la negociación Descripción del conflicto Posibles alternativas Importancia / Urgencia

Negociar Plantilla propuesta Conflicto <id> - <nombre> Descripción Requerimientos relacionados Alternativas Consecuencias Posibles soluciones Comentarios Amador Durán Toro y Beatriz Bernárdez Jiménez. Metodología para la Elicitación de Requisitos de Sistemas Software, 2001

Se deben evitar los conflictos emocionales Negociar Se deben evitar los conflictos emocionales Contar con un buen facilitar Además de los conflictos y las alternativas, se deben hace explícitas las argumentaciones Apoyan la solución seleccionada Klaus Pohl. Requirements Engineering: An Overview, 1996

Negociar Pasos (1) Definir el problema Definir los interesados Identificar los objetivos de cada interesado Analizar los objetivos Inconsistencias Riesgos Supuestos

Negociar Pasos (2) Determinar los criterios/reglas para evaluar las alternativas Negociación, basada en: Realizar propuestas y definir qué aspectos se está dispuesto a cambiar Buscar alternativas para los puntos en conflicto Establecer beneficios y compromisos de cada una de las partes

Se pueden usar herramientas que ayuden en el proceso Negociar Se pueden usar herramientas que ayuden en el proceso Plantillas para identificar conflictos Tormentas de ideas y votaciones Espacios de trabajo compartidos – herramientas colaborativa – Wikis Herramientas automáticas

Herramientas automáticas Negociar Herramientas automáticas NSS (Negotiation Support Systems) Aspire Negoisst Easy Win-Win SmartSettle

Negociar Modelo Win-Win Elementos: Condiciones ganadoras (Condiciones Win) Objetivos y definiciones de los interesados con respecto al sistema Acuerdo Una condición ganadora que no presenta conflictos Problema Se crea cuando hay un conflicto entre condiciones ganadoras Opciones Soluciones sugeridas

Negociar Modelo Win-Win: involucra Condición Win resuelven Problemas Opciones Acuerdos cubre adopta resuelven involucra Barry Boehm y Alexander Egyed. Software Requirements Negotiation: Some Lessons Learned, 1998

Negociar Pasos (1) Establecer una forma de clasificar los elementos, para Entender el dominio del negocio Buscar elementos rápidamente En tarjetas se anotan las condiciones ganadoras Se clasifican y se dejan visibles (pegar en una pared)

Negociar Pasos (2) Se identifican conflictos Se anotan en tarjetas Se anotan en otras tarjetas las opciones Se discuten los argumentos para seleccionar una de las opciones anotadas Los acuerdos (condiciones ganadoras sin conflictos o las opciones seleccionadas) Se pegan en otra pared

Plantilla Priorización Enlaces Modelo Win-Win http://sunset.usc.edu/publications/TECHRPTS/1998/usccse98-512/usccse98-512.pdf http://www.mindtools.com/CommSkll/NegotiationSkills.htm Plantilla Priorización http://www.processimpact.com/goodies.shtml