Descargar la presentación
La descarga está en progreso. Por favor, espere
1
Ingeniería de Requerimientos
Análisis
2
Ingeniería de Requerimientos Especificación Validación Análisis Adquisición Desarrollo Administración Control de Versiones Seguimiento Control de Cambios
3
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
4
Temas Priorizar Identificar problemas Identificar oportunidades Negociar
5
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
6
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
7
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
8
Priorizar Alta – Esencial Requerimiento de misión crítica
El software no es aceptable sin él 2 1 3
9
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
10
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
11
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
12
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
13
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
14
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
15
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
16
Priorizar XP Planning Game Priorizar basado en:
Importancia para el negocio Esfuerzo (costo) Riesgo
17
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á
18
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
19
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
20
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
21
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
22
Priorizar Pasos (4) Ordenar de forma descendente
Los primeros elementos, por tener un balance favorable en costo/beneficio, son candidatos a tener alta prioridad
23
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
24
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
25
Otros aspectos que se pueden considerar
Priorizar Otros aspectos que se pueden considerar Volatilidad de los requerimientos Competidores Recursos …
26
Ejercicio Elabore una plantilla para calcular las prioridades de los requerimientos
27
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) (AURUM, Aybüke y WOHLIN, Claes. Engineering and Managing Software Requirements. Springer, 2005)
28
Temas Priorizar Identificar problemas Identificar oportunidades Negociar
29
Identificar problemas
Determinar Los requerimientos son factibles Técnicamente Económicamente Operacionalmente No hay contradicciones/inconsistencias
30
Identificar problemas
Algunas técnicas Lista de preguntas Revisar casos de uso Matriz de requerimientos Matriz CRUD
31
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
32
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
33
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
34
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
35
Identificar problemas
Ejemplo - Matriz de requerimientos R1 R2 R3 R4 R5 R6 2 1
36
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
37
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
38
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?
39
Ejercicio Elabore la matriz CRUD para los casos de uso y entidades en el ejemplo Determine posibles requerimientos faltantes
40
Temas Priorizar Identificar problemas Identificar oportunidades Negociar
41
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
42
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
43
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
44
Temas Priorizar Identificar problemas Identificar oportunidades Negociar
45
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
46
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
47
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
48
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
49
Negociar Pasos (1) Definir el problema Definir los interesados
Identificar los objetivos de cada interesado Analizar los objetivos Inconsistencias Riesgos Supuestos
50
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
51
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
52
Herramientas automáticas
Negociar Herramientas automáticas NSS (Negotiation Support Systems) Aspire Negoisst Easy Win-Win SmartSettle
53
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
54
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
55
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)
56
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
57
Plantilla Priorización
Enlaces Modelo Win-Win Plantilla Priorización
Presentaciones similares
© 2024 SlidePlayer.es Inc.
All rights reserved.