UNIVERSIDAD DE CONGRESO

Administración de Requerimientos Análisis de Sistemas – 2do año Prof. Gustavo J. Sabio Prof. Gustavo J. Sabio http://www.ucongreso.edu.ar

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

Prof. Gustavo J. Sabio http://www.ucongreso.edu.ar

1

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 Prof. Gustavo J. Sabio http://www.ucongreso.edu.ar

Escencia de la Adm. de Req. problema

Necesidades

características

Requerimientos de Software

El sistema a construir

Procedimientos de Test Diseño Documentos para usuario Prof. Gustavo J. Sabio http://www.ucongreso.edu.ar

2

Contenido Introducción

Ir a …

Buenas Prácticas Introducción al RUP Disciplina Requerimientos Conclusiones

Prof. Gustavo J. Sabio http://www.ucongreso.edu.ar

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

Prof. Gustavo J. Sabio http://www.ucongreso.edu.ar

3

Contenido Introducción Buenas Prácticas Introducción al RUP

Introducción a la AR Modelando Casos de Uso Analizar el Problema

Disciplina Requerimientos

Entender necesidades stakeholders Conclusiones

Definir el Sistema Administrar el alcance Redefinir el sistema Administrar el cambio Prof. Gustavo J. Sabio http://www.ucongreso.edu.ar

Introducción a la Administración de Requerimientos Objetivos:

• Definir conceptos claves de la Disciplina • Entender los beneficios

Prof. Gustavo J. Sabio http://www.ucongreso.edu.ar

4

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)

Prof. Gustavo J. Sabio http://www.ucongreso.edu.ar

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” Prof. Gustavo J. Sabio http://www.ucongreso.edu.ar

5

AR- Niveles de los Requerimientos •Necesidades de los interesados

Qué o Cóm

• Especificaciones de diseño • Procedimientos de prueba • Documentación

Requisitos stakeholders

•Características del sistema

Definidas en Vision.doc

Qué o Cóm

•Especificación de requerimientos de Software (CU)

Qué o Cóm

Modelo CU y Especif compl Prof. Gustavo J. Sabio http://www.ucongreso.edu.ar

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. Prof. Gustavo J. Sabio http://www.ucongreso.edu.ar

6

AR- tipos de req. y trazabilidad

Prof. Gustavo J. Sabio http://www.ucongreso.edu.ar

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 Prof. Gustavo J. Sabio http://www.ucongreso.edu.ar

7

Tipos de requerimientos Clasificación

Tipo

Funcionalidad

Características, capacidades

Usabilidad

Factores humanos, estética, localización geográfica y de recursos, ayudas

Confiabilidad

Frecuencia de fallas, recuperabilidad, disponibilidad, integridad, consistencia

Performance

Velocidad, eficiencia, uso de recursos

Soportabilidad

Prueba, extensibilidad, adaptabilidad, mantenibilidad, compatibilidad

Precisión

Precisión numérica, oportunidad de la información

Restricciones

Del dominio, de la tecnología, operativas, físicas

Seguridad

Accesos, políticas, ubicación de los datos, políticas Prof. Gustavo J. Sabio http://www.ucongreso.edu.ar

Origen de los errores en el software Otros 10% Programación 7% Análisis 56% Diseño 27% Prof. Gustavo J. Sabio http://www.ucongreso.edu.ar

8

Caracterización de los errores Requerimientos Requerimientos correctos incorrectos

Análisis correcto

Análisis incorrecto

Diseño correcto

Diseño incorrecto

Programa correcto

Programa con errores

Catarata de errores de Mizuno

Análisis s/req. incorrectos

Diseño s/análisis Diseño s/análisis incorrecto s/req. incorrectos

Programa no corregible

Programa con errores ocultos

Programa con errores ocultos

Prof. Gustavo J. Sabio http://www.ucongreso.edu.ar

Costo de corrección de errores

Incremento de 100 a 1000 veces

Costo Etapas del ciclo de desarrollo

Prof. Gustavo J. Sabio http://www.ucongreso.edu.ar

9

Incremento del costo de los errores

1 2,5 5 10

Captura de requerimientos Análisis y diseño Codificación Prueba unitaria

25

Prueba de aceptación

100

Mantenimiento

Boehm, 1988 Prof. Gustavo J. Sabio http://www.ucongreso.edu.ar

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 Prof. Gustavo J. Sabio http://www.ucongreso.edu.ar

10

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.

Prof. Gustavo J. Sabio http://www.ucongreso.edu.ar

Éxito del proyecto según su tamaño 60 50

Porcentaje de éxito (%)

hasta $750m $750m a $1.5M $1.5M a $3M $3M a $6M $6M a $10M más de $10M

40 30 20 10 0

Tamaño del proyecto ($) Standish Group, 1999 Prof. Gustavo J. Sabio http://www.ucongreso.edu.ar

11

Contenido Introducción Buenas Prácticas Introducción al RUP

Introducción Modelando Casos de Uso Analizar el Problema

Disciplina Requerimientos

Entender necesidades stakeholders Conclusiones

Definir el Sistema Administrar el alcance Redefinir el sistema Administrar el cambio Prof. Gustavo J. Sabio http://www.ucongreso.edu.ar

¿En qué parte de los Requerimientos estamos?

Prof. Gustavo J. Sabio http://www.ucongreso.edu.ar

12

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 Prof. Gustavo J. Sabio http://www.ucongreso.edu.ar

Analizar el Problema Lograr el acuerdo en la definición definición del problema Capturar un Vocabulario común Identificar las causas (problema (problema tras el problema) 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 Prof. Gustavo J. Sabio http://www.ucongreso.edu.ar

13

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

• ¿Cuál es el problema? – Entender la perspectiva de los clientes Requisitos – Documentos del cliente Stakeholders – Intentar el acuerdo (no solo con el cliente, también dentro del propio equipo de desarrollo) Prof. Gustavo J. Sabio http://www.ucongreso.edu.ar

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

Se debe trabajar sobre la percepción

Pro blem a

Se debe trabajar sobre la brecha

... y lo deseado” Gause & Weinberg Prof. Gustavo J. Sabio http://www.ucongreso.edu.ar

14

Definición del problema Visión

Para el problema:

(describir el problema)

que afecta a:

(lista de interesados afectados)

y cuyo impacto es:

(describir cuál es el impacto del problema)

Una solución adecuada debería proveer:

(lista de los principales beneficios de negocio claves) Prof. Gustavo J. Sabio http://www.ucongreso.edu.ar

Analizar el Problema Lograr el acuerdo en la definición definición del problema Capturar un Vocabulario común Identificar las causas (problema (problema tras el problema) 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 Prof. Gustavo J. Sabio http://www.ucongreso.edu.ar

15

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 Glosario

Evaluar sus resultados

Prof. Gustavo J. Sabio http://www.ucongreso.edu.ar

Analizar el Problema Lograr el acuerdo en la definición definición del problema Capturar un Vocabulario común Identificar las causas (problema (problema tras el problema) 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 Prof. Gustavo J. Sabio http://www.ucongreso.edu.ar

16

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é? Entender el problema

Encontrar Stakeholders

Visión

Potenciales actores modelo de CU

Visión Prof. Gustavo J. Sabio http://www.ucongreso.edu.ar

Identificar las causas

Herramientas a aplicar:

•Espina de pescado •Pareto

Prof. Gustavo J. Sabio http://www.ucongreso.edu.ar

17

Analizar el Problema Lograr el acuerdo en la definición definición del problema Capturar un Vocabulario común Identificar las causas (problema (problema tras el problema) 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 Prof. Gustavo J. Sabio http://www.ucongreso.edu.ar

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

Prof. Gustavo J. Sabio http://www.ucongreso.edu.ar

18

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

Prof. Gustavo J. Sabio http://www.ucongreso.edu.ar

3. Definir Requerimientos de Negocio 4. Identificar la/s solución/es correcta/s • Modelo de CU de Negocio

Prof. Gustavo J. Sabio http://www.ucongreso.edu.ar

19

Analizar el Problema Lograr el acuerdo en la definición definición del problema Capturar un Vocabulario común Identificar las causas (problema (problema tras el problema) 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 Prof. Gustavo J. Sabio http://www.ucongreso.edu.ar

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?

Visión

Elaborar los perfiles de los potenciales (o actuales) actores 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 Prof. Gustavo J. Sabio http://www.ucongreso.edu.ar

20

Analizar el Problema Lograr el acuerdo en la definición definición del problema Capturar un Vocabulario común Identificar las causas (problema (problema tras el problema) 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 Prof. Gustavo J. Sabio http://www.ucongreso.edu.ar

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 Prof. Gustavo J. Sabio http://www.ucongreso.edu.ar

21

Definir los límites del sistema

Prof. Gustavo J. Sabio http://www.ucongreso.edu.ar

Analizar el Problema Lograr el acuerdo en la definición definición del problema Capturar un Vocabulario común Identificar las causas (problema (problema tras el problema) 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 Prof. Gustavo J. Sabio http://www.ucongreso.edu.ar

22

Identificar Restricciones del sistema

Visión

política económica

Desarrollo

factibilidad

Técnica sistema

Reglas de Negocio Prof. Gustavo J. Sabio http://www.ucongreso.edu.ar

Contenido Introducción Buenas Prácticas Introducción al RUP

Introducción Modelando Casos de Uso CONCLUSIONES Analizar el Problema

Disciplina Requerimientos

Entender necesidades stakeholders Conclusiones

Definir el Sistema Administrar el alcance Redefinir el sistema Administrar el cambio Prof. Gustavo J. Sabio http://www.ucongreso.edu.ar

23

Foco en la Vision Deseos Stakeholders Requisitos Stakeholders Necesidades Stakeholders

+ Características

Vision

SRS Requerimientos De Software

Modelo CU

Especif. Especif. Complem. Complem. Prof. Gustavo J. Sabio http://www.ucongreso.edu.ar

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 Prof. Gustavo J. Sabio http://www.ucongreso.edu.ar

24

Estructura del documento Visión Visión 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11.

Historia de cambios Tabla de contenidos Introducción Aprobaciones Audiencia Propósito Alcance Antecedentes Oportunidad de negocios Definición del problema Objetivos del proyecto

12. Descripción de participantes 13. Lista de necesidades 14. Descripción del producto 15. Restricciones y supuestos 16. Requisitos de calidad 17. Prioridades 18. Productos a entregar 19. Otros requerimientos 20. Estimación económoca y temporal 21. Análisis de riesgos preliminar

Prof. Gustavo J. Sabio http://www.ucongreso.edu.ar

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 Prof. Gustavo J. Sabio http://www.ucongreso.edu.ar

25

Analizar el Problema Lograr el acuerdo en la definición del problema

Herram brainstorming

Capturar un Vocabulario común

Identificar las causas

Artefacto

Glosario

Brainstorming Espina de pescado Pareto

Visión

Definir los requerimientos de negocio

Identificar la solución correcta (s)

Entrevistas Workshop Brainstorming

Modelo Negocio Visión

Workshop Brainstorming

Modelo CU Visión

Identificar los stakeholders

Definir límites del sistema propuesto Identificar restricciones del sistema/proyecto

Workshop Brainstorming

Visión Prof. Gustavo J. Sabio http://www.ucongreso.edu.ar

26