Administración de Requerimientos

Transcripción

1 UNIVERSIDAD DE CONGRESO Administración de Requerimientos Análisis de Sistemas 2do año Contenido Introducción Buenas Prácticas Introducción al RUP Disciplina Requerimientos Conclusiones 1

2 Dificultades al manejar requerimientos Clientes no siempre conocen lo que quieren Los requerimientos no siempre son obvios Los requerimientos pueden provenir de muchas fuentes Es díficil mantener la relación entre los requerimientos A veces es díficil expresarlos en palabras Los requerimientos cambian El uso de lenguaje técnico limita la expresión de los usuarios Si son muchos requerimientos, se torna inmanejable e incontrolable Escencia de la Adm. de Req. Necesidades problema características Requerimientos de Software El sistema a construir Procedimientos de Test Diseño Documentos para usuario 2

3 Contenido Introducción Ir a Buenas Prácticas Introducción al RUP Disciplina Requerimientos Conclusiones Contenido Introducción Buenas Prácticas Introducción al RUP Disciplina Requerimientos Conclusiones 3

4 Contenido Introducción Buenas Prácticas Introducción al RUP Disciplina Requerimientos Conclusiones Introducción a la AR Modelando Casos de Uso Analizar el Problema Entender necesidades stakeholders Definir el Sistema Administrar el alcance Redefinir el sistema Administrar el cambio Introducción a la Administración de Requerimientos Objetivos: Definir conceptos claves de la Disciplina Entender los beneficios 4

5 Definiciones Requerimiento Describe una condición/ capacidad de cómo el sistema debe comportarse provienen de las necesidades de los usuarios, de un contrato, de estándares o de un documento de especificaciones. (RUP) Característica deseada, propiedad o comportamiento del sistema. (UML) Definiciones Qué es la administración de requerimientos? Es un enfoque sistémico para Encontrar, organizar, documentar, coordinar y mantener los requerimientos. Permite establecer u mantener el acuerdo entre el cliente/usuario y el equipo del proyecto sobre los cambios en los requerimientos. La clave para una administración de requerimientos efectiva, es mantener una clara definición de los requerimientos mediante sus atributos y la trazabilidad 5

6 AR- Niveles de los Requerimientos Necesidades de los interesados Requisitos stakeholders Qué Cómo Especificaciones de diseño Procedimientos de prueba Documentación Características del sistema Definidas en Vision.doc Qué Cómo Especificación de requerimientos de Software (CU) Qué Cómo Modelo CU y Especif compl AR- Niveles de los Requerimientos Explicación del dibujo anterior El requerimiento establece el qué más que el cómo, aunque existen diferentes niveles de qués y de cómos Existen muchos niveles de requerimientos. Dependiendo de la perspectiva generada, una especificación puede ser un requerimiento (qué) o un diseño (cómo). Por ej: la necesidad de un stakeholder es un requerimiento para el analista. Este analista debe producir una lista de características que son requerimientos para el Especificador de casos de uso. Los CU describen que debe hacer el sistema para implementar estas características. El Especificador de CU debe producir unos cuantos casos de uso que son requerimientos para los diseñadores. 6

7 AR- tipos de req. y trazabilidad Cualidades de los requerimientos Verificable Jerarquizable según su importancia Jerarquizable según su estabilidad Modificable Trazable Entendible Correcto Cualidades de un SRS Completo Propuestas por Consistente RUP y IEEE No ambiguo 7

8 Tipos de requerimientos Clasificación Funcionalidad Usabilidad Confiabilidad Performance Soportabilidad Precisión Restricciones Seguridad Tipo Características, capacidades Factores humanos, estética, localización geográfica y de recursos, ayudas Frecuencia de fallas, recuperabilidad, disponibilidad, integridad, consistencia Velocidad, eficiencia, uso de recursos Prueba, extensibilidad, adaptabilidad, mantenibilidad, compatibilidad Precisión numérica, oportunidad de la información Del dominio, de la tecnología, operativas, físicas Accesos, políticas, ubicación de los datos, políticas Origen de los errores en el software Programación 7% Otros 10% Diseño 27% Análisis 56% 8

9 Caracterización de los errores Requerimientos correctos Requerimientos incorrectos Catarata de errores de Mizuno Análisis correcto Análisis incorrecto Análisis s/req. incorrectos Diseño correcto Diseño incorrecto Diseño s/análisis incorrecto Diseño s/análisis s/req. incorrectos Programa correcto Programa con errores Programa no corregible Programa con errores ocultos Programa con errores ocultos Costo de corrección de errores Incremento de 100 a 1000 veces Costo Etapas del ciclo de desarrollo 9

10 Incremento del costo de los errores 1 2, Captura de requerimientos Análisis y diseño Codificación Prueba unitaria Prueba de aceptación Mantenimiento Boehm, 1988 Toma de requerimientos: Involucrar a todo el equipo es conveniente incluir a todo el equipo en los requerimientos? Desarrolladores, testers y documentadores El equipo logra un mayor entendimientos de los requerimientos y el por qué ellos son importantes para el cliente Se logran más recomendaciones para estandarizar el proceso de desarrollo. Una recomendación hecha por todos provoca un fuerte involucramiento. - CMM y Constructabilidad - 10

11 Factores de éxito del proyecto En 1998 el Standish Group relevó 365 compañías y 8000 proyectos y presentó los resultados en su informe de 1999 Mejora en el éxito de los proyectos: 16% en 1994 vs. 26% en 1998 además de reducción de costos y tiempos Causas: participación de usuarios, soporte ejecutivo, claro establecimiento de los objetivos del negocio, administración de proyectos, entregables permanentes, requerimientos firmes, menor tamaño y duración del proyecto, etc. Éxito del proyecto según su tamaño 60 Porcentaje de éxito (%) hasta $750m $750m a $1.5M $1.5M a $3M $3M a $6M $6M a $10M más de $10M Tamaño del proyecto ($) Standish Group,

12 Contenido Introducción Buenas Prácticas Introducción al RUP Disciplina Requerimientos Conclusiones Introducción Modelando Casos de Uso Analizar el Problema Entender necesidades stakeholders Definir el Sistema Administrar el alcance Redefinir el sistema Administrar el cambio En qué parte de los Requerimientos estamos? 12

13 Analizar el Problema Qué es? Es el proceso de entender los problemas reales, las necesidades de los usuarios y de proponer soluciones para ellas. Cuáles son los objetivos? Intentar un mejor entendimiento antes de comenzar con el desarrollo Identificar las causas (raíz de los problemas) Ayudar a formular los requerimientos de negocio Ayudar a encontrar la solución correcta Analizar el Problema Lograr el acuerdo en la definición del problema Capturar un Vocabulario común Identificar las causas (problema( tras el problema) Definir los requerimientos de negocio Identificar la solución correcta (s) Identificar los stakeholders Definir límites del sistema propuesto Identificar restricciones del sistema/proyecto 13

14 Lograr el acuerdo en la definición del sistema Para comenzar analizar cualquier problema se debe estar seguro, de que todos los involucrados coinciden en cuál es el problema que intentan solucionar con el sistema Cuál es el problema? Entender la perspectiva de los clientes Documentos del cliente Requisitos Stakeholders Intentar el acuerdo (no solo con el cliente, también dentro del propio equipo de desarrollo) Desarrollar Glosario Definir el problema que se debe resolver Definición de problema Un problema es la diferencia entre... Se debe trabajar sobre lo deseado...lo percibido... Problema Se debe trabajar sobre la percepción Se debe trabajar sobre la brecha... y lo deseado Gause & Weinberg 14

15 Definición del problema Visión Para el problema: que afecta a: y cuyo impacto es: Una solución adecuada debería proveer: (describir el problema) (lista de interesados afectados) (describir cuál es el impacto del problema) (lista de los principales beneficios de negocio claves) Analizar el Problema Lograr el acuerdo en la definición del problema Capturar un Vocabulario común Identificar las causas (problema( tras el problema) Definir los requerimientos de negocio Identificar la solución correcta (s) Identificar los stakeholders Definir límites del sistema propuesto Identificar restricciones del sistema/proyecto 15

16 Capturar un vocabulario común Para qué sirve el Glosario? Para definir un vocabulario común que puede ser usado en toda descripción textual del sistema, especialmente en la descripción de los casos de uso. Definir los términos usados en el proyecto Prevenir desentendimientos Pasos que propone la actividad: Desarrollar la Vision Encontrar términos comunes Evaluar sus resultados Glosario Analizar el Problema Lograr el acuerdo en la definición del problema Capturar un Vocabulario común Identificar las causas (problema( tras el problema) Definir los requerimientos de negocio Identificar la solución correcta (s) Identificar los stakeholders Definir límites del sistema propuesto Identificar restricciones del sistema/proyecto 16

17 Identificar las causas del problema Cuál es el problema, realmente? Buscar el problema tras el problema No aceptar la primer definición de un problema. Continuar preguntando: por qué? Visión Entender el problema Encontrar Stakeholders Potenciales actores Visión modelo de CU Identificar las causas Herramientas a aplicar: Espina de pescado Pareto 17

18 Analizar el Problema Lograr el acuerdo en la definición del problema Capturar un Vocabulario común Identificar las causas (problema( tras el problema) Definir los requerimientos de negocio Identificar la solución correcta (s) Identificar los stakeholders Definir límites del sistema propuesto Identificar restricciones del sistema/proyecto 3. Definir Requerimientos de Negocio 4. Identificar la/s solución/es correcta/s Formular los requerimientos de negocio Los requerimientos de negocio deberían partir de las causas identificadas Se debe especificar la situación actual Se debe especificar la situación de negocios deseada 18

19 3. Definir Requerimientos de Negocio 4. Identificar la/s solución/es correcta/s Identificar soluciones de negocio Analizar los requerimientos de negocio Identificar un conjunto de soluciones técnicas / no-técnicas / ambas Escoger la (s) mejor que cumpla con los requerimientos de negocio Iniciar un proyecto para implementar la solución 3. Definir Requerimientos de Negocio 4. Identificar la/s solución/es correcta/s Modelo de CU de Negocio 19

20 Analizar el Problema Lograr el acuerdo en la definición del problema Capturar un Vocabulario común Identificar las causas (problema( tras el problema) Definir los requerimientos de negocio Identificar la solución correcta (s) Identificar los stakeholders Definir límites del sistema propuesto Identificar restricciones del sistema/proyecto Identificar los stakeholders Quiénes son los usuarios del sistema? Quién es el cliente para el sistema? A quiénes afectará el rendimiento del sistema? Quién evaluará y aprobará el sistema cuándo este se entregue y se implemente? Hay cualquier otro usuario, interno o externo del sistema, cuyas necesidades deban contemplarse? Quién mantendrá el nuevo sistema? Hay alguien más? De acuerdo, hay alguien más? Elaborar los perfiles de los potenciales (o actuales) actores Visión Documentar en la VISION lo que se tenga sobre los usuarios y su entorno Un Stakeholder es cualquiera que esté afectado (materialmente) por la llegada del sistema 20

21 Analizar el Problema Lograr el acuerdo en la definición del problema Capturar un Vocabulario común Identificar las causas (problema( tras el problema) Definir los requerimientos de negocio Identificar la solución correcta (s) Identificar los stakeholders Definir límites del sistema propuesto Identificar restricciones del sistema/proyecto Definir los límites del sistema El límite del sistema define la frontera entre la solución y el mundo real que rodea la solución En otros términos, el límite del sistema se describe como una burbuja en donde se contiene la solución del sistema. Los actores están fuera del sistema a desarrollar Visión Es muy eficaz usar actores para definir y describir los límites del sistema. Encontrar actores ycu 21

22 Definir los límites del sistema Analizar el Problema Lograr el acuerdo en la definición del problema Capturar un Vocabulario común Identificar las causas (problema( tras el problema) Definir los requerimientos de negocio Identificar la solución correcta (s) Identificar los stakeholders Definir límites del sistema propuesto Identificar restricciones del sistema/proyecto 22

23 Identificar Restricciones del sistema Visión política Desarrollo económica Técnica sistema factibilidad Reglas de Negocio Contenido Introducción Introducción Buenas Prácticas Introducción al RUP Disciplina Requerimientos Conclusiones Modelando Casos de Uso Analizar CONCLUSIONES el Problema Entender necesidades stakeholders Definir el Sistema Administrar el alcance Redefinir el sistema Administrar el cambio 23

24 Foco en la Vision Deseos Stakeholders Necesidades Stakeholders + Características SRS Requisitos Stakeholders Vision Requerimientos De Software Modelo CU Especif. Complem. Artefacto: Vision Para qué sirve el documento Vision? Visión Permite la comunicación entre los administradores, vendedores y el equipo completo del proyecto Le brinda al cliente el primer feedback Capta el entendimiento general del producto Establece alcance y prioridad de las características a un nivel macro Para que todas las partes entiendan para qué están trabajando Describe el qué y el porqué del producto o aplicación Se focaliza en: las necesidades de los usuarios, metas, objetivos y características del producto 24

25 Estructura del documento Visión Visión 1. Historia de cambios 12. Descripción de participantes 2. Tabla de contenidos 13. Lista de necesidades 3. Introducción 14. Descripción del producto 4. Aprobaciones 15. Restricciones y supuestos 5. Audiencia 16. Requisitos de calidad 6. Propósito 17. Prioridades 7. Alcance 18. Productos a entregar 8. Antecedentes 19. Otros requerimientos 9. Oportunidad de negocios 20. Estimación económoca y temporal 10. Definición del problema 21. Análisis de riesgos preliminar 11. Objetivos del proyecto Estructura del documento Visión Visión 1. Introducción 2. Descripción de los stakeholders 3. Generalidades del Producto 4. Características del Producto 5. Entregables 6. Restricciones 7. Requisitos de Calidad 8. Prioridades 9. Otros requerimientos del producto 10. Anexo Atributos de las características 25

26 Analizar el Problema Herram Artefacto Lograr el acuerdo en la definición del problema brainstorming Capturar un Vocabulario común Identificar las causas Definir los requerimientos de negocio Identificar la solución correcta (s) Brainstorming Espina de pescado Pareto Entrevistas Workshop Brainstorming Glosario Modelo Negocio Visión Visión Identificar los stakeholders Definir límites del sistema propuesto Workshop Brainstorming Modelo CU Visión Identificar restricciones del sistema/proyecto Workshop Brainstorming Visión 26