Los requisitos, un factor crítico en el éxito de los proyectos

Transcripción

1 Los requisitos, un factor crítico en el éxito de los proyectos La importancia de los modelos José Luis Fernández Sánchez Profesor titular ETSI Industriales- Universidad Politécnica de Madrid Presentación PMI Madrid, 29 de Julio de 2014

2 Contenido de la presentación 1. Dirección de proyectos e ingeniería de requisitos 2. La importancia de los requisitos 3. Problemas habituales 4. Definiciones y tipos de requisitos 5. Ingeniería de requisitos 6. El esfuerzo de la obtención y especificación de requisitos 7. Los modelos y los requisitos 8. El futuro de los requisitos 29 Julio 2014 José Luis Fernández Sánchez 2

3 Dirección de proyectos e ingeniería de requisitos 1. PMBOK y BABOK

4 1.Comparación Tareas PMBOK Desarrollo del plan de gestión del proyecto Seguimiento y control del proyecto Tareas BABOK Planificar las actividades de análisis del negocio. Planificar la gestión de requisitos Gestionar las prestaciones del análisis del negocio Planificar la gestión del alcance. Obtener requisitos Definir el alcance del proyecto Crear la EDP. Controlar el alcance Validar el alcance Control de calidad Identificar las partes interesadas Planificar la gestión de las comunicaciones Planificar el proceso de gestión de requisitos. Captura de requisitos. Gestionar la trazabilidad de los requisitos. Documentar los requisitos. Definir el alcance de la solución Gestionar el alcance de la solución. Validar la solución Evaluación de las prestaciones de la solución Realizar un análisis de las partes interesadas Planificar la comunicación en el análisis de negocio 29 Julio 2014 José Luis Fernández Sánchez 4

5 2. La importancia de los requisitos Los requisitos son un factor clave en el éxito o fracaso de los proyectos

6 Los requisitos y los proyectos según el PMI PMI s 2014 Pulse of the Profession study said that poor Requirements Management is a major cause of project failure, second only to changing organization priorities. That same Pulse study found that 37 percent of organizations report inaccurate requirements gathering as a primary reason for project failure. 29 Julio 2014 José Luis Fernández Sánchez 6

7 El Informe Standish (I) Razones para el fracaso de los proyectos 1. Requisitos incompletos 2. Falta de participación del usuario 3. Falta de recursos 4. Expectativas no realistas 5. Falta de apoyo de la dirección 6. Cambios en los requisitos 7. Falta de planificación 8. El proyecto se convierte en innecesario 29 Julio 2014 José Luis Fernández Sánchez 7

8 El informe Standish (II) Los 10 factores de éxito en los proyectos: 1. Grado de participación del usuario 2. Apoyo de la dirección 3. Jefe de proyecto con experiencia 4. Objetivos de negocio claros 5. Minimizar el alcance 6. Proceso ágil de ingeniería de requisitos 7. Infraestructura estándar 8. Metodología rigurosa 9. Estimaciones fiables 10. Personal competente 29 Julio 2014 José Luis Fernández Sánchez 8

9 3. Problemas habituales Lo que uno se encuentra en los ámbitos académicos e industria

10 Requisitos tipo novela La aplicación se ejecutará a la máxima capacidad de proceso en todo momento, exceptuando las situaciones de emergencia donde será capaz de ejecutarse al 125% siempre que la situación no exceda una duración de 15 minutos, en cuyo caso se ejecutará al 105%, pero en el caso que sólo se pueda realizar el 95% entonces se activará una excepción de capacidad reducida y se mantendrá la capacidad dentro de un 10% de los valores establecidos por un mínimo intervalo de 30 minutos. 29 Julio 2014 José Luis Fernández Sánchez 10

11 Requisitos orientados a la solución 1 Los peatones indicarán su presencia pulsando un botón en un poste próximo (distancia a determinar) al cruce (orientado a la solución) El sistema permitirá a los peatones mostrar su intención de cruzar la calle (orientado a la función) 1 Dick, J., Ryan, M., Wheatcraft, L.,Zinni,R.,Baksa,K., Fernandez, J.L., Smith G.R. and C. Unger. Guide for Writing Requirements. INCOSE. April Julio 2014 José Luis Fernández Sánchez 11

12 Requisitos no estructurados 29 Julio 2014 José Luis Fernández Sánchez 12

13 Abuso de la ambigüedad Ejemplos de requisitos ambiguos según K. Wiegers 2 : El sistema funcionará siempre de modo aceptable. El sistema será eficiente. En situación normal el sistema funcionará según El sistema será robusto. El sistema se implementará según el estado del arte. El sistema será fácil de usar. El sistema responderá al evento X suficientemente rápido. El sistema no debería 2 Wiegers, K. and Beatty, J Software Requirements. Microsoft Press, Aug Julio 2014 José Luis Fernández Sánchez 13

14 4. Definiciones y tipos de requisitos Qué es un requisito? Son todos los requisitos iguales?

15 Necesidades, expectativas y requisitos Las necesidades expresan de forma no precisa lo que quiere el cliente (también puede ser llamado requisito en bruto ) Las expectativas representan necesidades no explícitas del cliente Un requisito es una propiedad que debe ser mostrada por un sistema desarrollado o modificado para resolver un problema en particular 29 Julio 2014 José Luis Fernández Sánchez 15

16 Concepto de Requisito según IEEE Std Un requisito bien formulado establece una funcionalidad o capacidad del sistema que puede ser validada, y que debe ser poseída por el sistema para resolver un problema o realizar un objetivo de negocio. Un requisito estará cualificado por condiciones medibles Un requisito puede estar limitado por restricciones de tipo técnico, económico, de proyecto o legales 3 IEEE Computer Society, IEEE Std 1233, Guide for Developing System Requirements Specifications, New York Julio 2014 José Luis Fernández Sánchez 16

17 Ejemplo de Requisito Transportar personas de Madrid a Málaga a una velocidad máxima de 300 km/h por un precio por persona menor de 75 Euros capacidad: transportar personas de Madrid a Málaga condición: velocidad máxima de 300 km/h restricción: precio por persona menor de 75 Euros 29 Julio 2014 José Luis Fernández Sánchez 17

18 Tipos de requisitos Funcionales: Según Thayer 4, los requisitos funcionales describen una función que un sistema, aplicación software o componente debe ser capaz de realizar. Básicamente describen aspectos de conducta mediante transformaciones de entradas en salidas No funcionales o de atributos de calidad: Según Thayer, los requisitos no funcionales no describen qué tiene que hacer el sistema, aplicación software o componente sino cómo tiene que hacerlo. Restricciones: Son requisitos de tipo legal, técnico, económico u otro que limitan el espacio de posibles soluciones. Reglas de negocio: Son requisitos relacionados con la organización o su forma de hacer el negocio. Pueden ser hechos, algoritmos de cómputo, reglas de inferencia u otras. 4. Thayer R. y Dorfman M. (eds.). System and Software Requirements Engineering. IEEE Computer Society Press, Los Alamitos (California) Julio 2014 José Luis Fernández Sánchez 18

19 5. La ingeniería de requisitos Cómo capturarlos, organizarlos y especificarlos

20 Actividades de la ingeniería de requisitos La ingeniería de requisitos conlleva las siguientes actividades 5 : Captura de requisitos Análisis de requisitos Especificación de requisitos Validación de requisitos 5. ISO/IEC/IEEE Systems and software engineering Life cycle processes Requirements Engineering. December Julio 2014 José Luis Fernández Sánchez 20

21 Captura de requisitos Posibles fuentes de requisitos: Objetivos del negocio Dominio de conocimiento Partes interesadas en el proyecto del sistema Entorno operacional del sistema La Empresa o entorno organizativo 29 Julio 2014 José Luis Fernández Sánchez 21

22 Captura de requisitos Técnicas de captura de requisitos: Entrevistas Escenarios Prototipos Reuniones dirigidas Observación 29 Julio 2014 José Luis Fernández Sánchez 22

23 Análisis de requisitos Esta actividad conlleva: Detectar y resolver conflictos entre los requisitos Identificar las fronteras del sistema y como éste interacciona con su entorno (contexto) Desarrollar modelos que ayuden a la comprensión del problema Modelo de contexto Modelos conceptuales Flujos de datos y control Modelos de estados Trazas de eventos Interacciones con los usuarios del sistema otros 29 Julio 2014 José Luis Fernández Sánchez 23

24 Especificación de requisitos Organizar los requisitos Representar los requisitos de diversas formas según la audiencia Elaboración del documento de especificación de requisitos 29 Julio 2014 José Luis Fernández Sánchez 24

25 Organizar los requisitos Existen varios enfoques para organizar los requisitos según el IEEE Std : Por modos de funcionamiento Por tipos de usuarios Por objetos Por aspectos diferenciales Por estímulos Por jerarquía funcional Por enfoques múltiples 6. IEEE Computer Society, IEEE Std , Recommended Practice for Software Requirements Specifications, New York Julio 2014 José Luis Fernández Sánchez 25

26 6. El esfuerzo de la captura y especificación de los requisitos Según datos de la industria norteamericana

27 El esfuerzo de la captura y especificación de los requisitos Proyecto de puntos función Porcentaje del esfuerzo total Duración de la captura y especificación Informática de gestión 3,7 4,44 meses Software de sistema 9,0 13,2 meses Productos comerciales 7,0 22,7 meses Software militar 10,0 17,5 meses Proyectos con outsourcing 9,0 21,9 meses 29 Julio 2014 José Luis Fernández Sánchez 27

28 7. Los modelos visuales y los requisitos Dos formas complementarias de resolver el problema

29 Los modelos y los requisitos Los requisitos por su orientación a ser leídos por personas, y sus implicaciones contractuales y legales son esencialmente textuales Al ser textuales adolecen de carencias que conllevan a la ambigüedad y su mala organización Los modelos visuales, en notaciones estándar como SysML, UML u otras suplen estas carencias y complementan a los requisitos textuales Los modelos visuales permiten derivar requisitos a partir de ellos o refinar requisitos textuales para su mejor comprensión y análisis 29 Julio 2014 José Luis Fernández Sánchez 29

30 Ejemplo intencionalmente incompleto de aplicación de los modelos a requisito tipo novela La aplicación se ejecutará a la máxima capacidad de proceso en todo momento, exceptuando las situaciones de emergencia donde será capaz de ejecutarse al 125% siempre que la situación no exceda una duración de 15 minutos, en cuyo caso se ejecutará al 105%, pero en el caso que sólo se pueda realizar el 95% entonces se activará una excepción de capacidad reducida y se mantendrá la capacidad dentro de un 10% de los valores establecidos por un mínimo intervalo de 30 minutos. 29 Julio 2014 José Luis Fernández Sánchez 30

31 Diagrama de estados. Modos. Modo Normal Situacion normal [duración >30 min and Capacidad>95%] [Capacidad< 95%] Situación de emergencia Modo Emergencia [Capacidad< 95%] Modo de Capacidad Reducida 29 Julio 2014 José Luis Fernández Sánchez 31

32 Requisitos (I) RF 10. La aplicación soportará 3 modos de funcionamiento: Modo normal, Modo de Emergencia y Modo de Capacidad Reducida RF 20. La aplicación monitorizará su capacidad Modo Normal RNF.CAPAC. 10. La aplicación se ejecutará a la máxima capacidad de proceso (TBD) en todo momento RF 100. Si se detecta que la capacidad de proceso es menor del 95% de la máxima capacidad de proceso (TBD) se cambiará al modo de capacidad reducida 29 Julio 2014 José Luis Fernández Sánchez 32

33 Modo de Emergencia Requisitos (II) RNF.CAPAC.20. En modo de emergencia la aplicación será capaz de ejecutarse al 125% de su capacidad (TBD),siempre que la situación no exceda una duración de 15 minutos RNF.CAPAC.30. Cuando la duración del modo de emergencia exceda 15 minutos la aplicación se ejecutara con un 105% de su capacidad (TBD) Modo de Capacidad Reducida RNF.CAPAC.40. En este modo de funcionamiento se mantendrá la capacidad dentro de un 10% de los valores establecidos (TBD) por un mínimo intervalo de 30 minutos 29 Julio 2014 José Luis Fernández Sánchez 33

34 Para concluir 8. El futuro de los requisitos

35 8. El futuro de los requisitos 7 (I) Los requisitos son cada vez más importantes y más demandados en los proyectos Importancia de la mejores prácticas en su captura y especificación Los requisitos no son sólo texto sino videos, planos y modelos Se entiende que la ingeniería de requisitos es un trabajo complejo Los requisitos son un activo de la organización 7. Grant, T. High-Value Requirements are Changing App Development and Delivery. Forrester Research. December Julio 2014 José Luis Fernández Sánchez 35

36 8. El futuro de los requisitos (II) Existe una evolución de la ingeniería de requisitos donde cobra mayor relevancia su justificación a efectos de gestión del portafolio Una aproximación orientada a la persona (casos de uso, relatos o storyboards ) dará lugar a requisitos de mayor valor. Uso de los medios sociales es decir foros, blogs y otros La certificación profesional 8 como analista del negocio es una vía a considerar 8. PMI Professional in Business Analysis (PMI-PBA) Handbook. Project Management Institute, March 11, Julio 2014 José Luis Fernández Sánchez 36