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


Descargar ppt "Ingeniería de Requerimientos"

Presentaciones similares


Anuncios Google