Webinar: Gestión de requisitos

1,295 views
1,113 views

Published on

0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,295
On SlideShare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
65
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Webinar: Gestión de requisitos

  1. 1. Javier Sánchez Ramírez Máster Dirección de Sistemas de Información y Comunicaciones MDSIC ( UPM) Empresas: Cibernos Consulting, CH2Mhill, Genasys, evergreenpm 15 años involucrado en desarrollo y gerencia de Proyectos Software. info@evergreenpm.com
  2. 2. Obtener una visión general de qué es la Gestión de Requisitos, suposicionamiento dentro del Análisis de Negocio, la Gestión de Proyectos y laIngeniería del Software.Adquirir conciencia de la importancia e influencia en el éxito de los proyectos.Conocer los principales modelos y las herramientas disponibles para su gestióndesde áreas de negocio a requisitos de solución.
  3. 3. Seminario Ingeniería de Requisitos – 12 Febrero de 2013¿Por qué necesitamos mejorar la gestión de Requisitos?Los Niveles de la gestión de Requisitos NEGOCIO Análisis Empresarial STAKEHOLDERS Gestión de Requisitos de Stakeholders SOLUCIÓN Gestión de Requisitos de SistemaRetos a los que nos enfrentamos en cada nivelPrincipales modelos de gestión en cada nivel
  4. 4. Estadísticas generales de éxito de los proyectos 1 2 3100% Proyectos que se completaron en tiempo y 16%80% presupuesto.60% 53% Proyectos que costaron más del 189% de la estimación.40%20% Proyectos que se cancelaron antes de 31% completarse. 0%
  5. 5. Influencia en el éxito de los proyectos La inefectividad en el tratamiento de requisitos fuela causa raíz principal, siendo los tres factores máscomunes en comprometer un proyecto lossiguientes: 1.  Falta de feedback de usuario: 12,4% 2.  Requisitos y especificaciones incompletas: 13,1% 3.  Cambio de requisitos y especificaciones: 8,7% Requisitos: pobremente organizados, expresados, débilmente relacionados con los interesados, cambiando excesivamente rápido, o innecesarios; con expectativas poco realistas.
  6. 6. Influencia en el éxito de los proyectos Errores en los requisitos: Principal causa de incremento de costes por repetición de trabajos de desarrollo. Entre el 70 y 80% de todos los costes de repetir trabajo son por causas de errores en los requisitos. Fte: Karl Wiegers ‘Business Value of Requirements Managament’ . Jamasoftware.com
  7. 7. Gestión de Requisitos e innovaciónInnovar => CambioCAMBIO = NECESIDAD – RESISTENCIAEficiencia y Eficacia CAMBIO = f(Requisitos)Calidad = f(Requisitos)
  8. 8. Análisis Empresarial Requisitos de Negocio: Definen la naturaleza de NEGOCIO la solución, justifican la inversión y constituyen el punto de partida de un proyecto Análisis Requisitos STAKEHOLDERS Requisitos de Stakeholders: Definen las necesidades de los stakeholder. Análisis RequisitosSOLUCIÓN y TRANSICION Requisitos de Solución: describen las características de una solución, que satisface los requerimientos de negocio y de stakeholder.
  9. 9. Un requisito es:1.  Una condición o capacidad requerida por un stakeholder para resolver un problema o alcanzar un objetivo.2. Una condición o capacidad que debe ser cubierta o estarcontenida en una solución o componente de solución parasatisfacer un contrato, estándar, especificación, o cualquier otrodocumento formal. Dominio Soluciones RequisitosQué debe o no debe ser considerado en el requisito y cuáles son lascaracterísticas necesarias del mismo…?
  10. 10. DEFINICIÓN Declaración que identifica un producto o proceso operacional, funcional, o característica de diseño o restricción, expresada sin ambigüedad, testeable o medible, y necesaria para la aceptación de un producto o proceso (por el cliente o directrices de garantía de calidad interna). Fte: IEEE-STD-1220-1998 (IEEE 1998) - Standard for Application and Management of the Systems Engineering Process
  11. 11. Dinámicos.Medibles (Plan aceptación)Tienen que estar consensuados y priorizados.Jerárquicos y RelacionadosProceso de gestión de requisitos
  12. 12. Los requisitos definen la nueva CAPACIDAD.•  PRODUCTO CORRECTO: time to market no essuficiente, el verdadero reto es time to marketwith the right product•  EFECTIVO EN COSTE:•  MINIMO TIEMPO DE DESPLIEGUE
  13. 13. Los clientes…. NO ¿Saben lo que quieren? SI NO ¿Saben describirlo? SI NO ¿Están describiendo la solución en vez de la necesidad real? SI“Si no puedes describir lo que estás haciendo cómo un proceso, es que no sabes lo que estás haciendo” William Edwards Deming
  14. 14. Entorno…. Entorno Negocio Conflicto de intereses entre stakeholders. La voz del cliente no es única. Elicitación Interesados Entorno / Cultura Condicionantes No FuncionalesNuevo sistema Procesos
  15. 15. Los requisitos son la base de cada proyecto, definiendo lo que los stakeholders necesitan del potencial nuevo sistema (propósito), lo que debe hacer para satisfacer las necesidades de los interesados. Propósito Construcción Inicial Req Del Resultado OK? (Gap) NO Sistema ¿Se entendió el propósito inicial SI del sistema? ¿El propósito es el mismo?“Experienced developers know that managing requirements is a greater challenge than technical execution” Agile Software Requirements (Dean Leffingwell)
  16. 16. Tiempo…. Tiempo: Entorno del negocio, tecnológico y de intereses de los stakeholders cambia con el tiempo durante el plazo de ejecución del proyecto. Recomendación:La aproximación de hacer una definición completa de requisitos, seguidade un largo período antes de que las nuevas capacidades son liberadas,no parece muy apropiado…Fte: “Agile Software Requirements. Lean requirements Practices for Teams, Programs, and the Enterprise” DeanLeffingwell
  17. 17. El triángulo de hierro….Fijo Requisitos Coste Tiempo Q?Estimado Coste Tiempo Requisitos Waterfall / Tradicional Ágil
  18. 18. Selección de proyectos por parte del sponsorFacilitar la estimaciónPermitir priorizar mejorFacilita desarrollar diseñosTestear con efectividadFacilita el seguimientos de estatus de proyectoAcelera el desarrollo
  19. 19. El International Institute of Business Analysis es unaasociación profesional, independiente, sin ánimo de lucro yde carácter mundial, dedicada al análisis de negocio. Lamisión del IIBA® es desarrollar y mantener normas para lapráctica de análisis de negocio y administrar el proceso decertificación de los profesionales del sector. El objetivo esllegar a ser la primera organización mundial dedicada alanálisis de negocio.
  20. 20. Áreas de Conocimiento BABOKPlaneación y monitoreo de Análisis de Negocio Comprende cómo el AN determina qué actividades son necesarias con el fin de completar un esfuerzo de Análisis de Negocio.Elicitación Cómo los AN trabajan con los stakeholders para identificar y entender sus necesidades y preocupaciones y comprenden el medio ambiente en el que trabajan.Administración y Comunicación de Cómo los AN administran conflictos, problemas y cambios con el fin de asegurar que losrequerimientos stakeholders y el equipo mantienen el acuerdo del alcance de la solución.Análisis Empresarial Describe cómo el AN identifica una necesidad de negocio, refina y clarifica la definición de esa necesidad y define un alcance viable.Análisis de Requerimientos Describe cómo el AN prioriza y progresivamente elabora los requerimientos de los stakeholders y de la solución para posibilitar la implementación de la solución por parte del equipo del proyecto.Evaluación y validación de la Solución Describe cómo el AN evalúa las soluciones propuestas para determinar la mejorCompetencias Fundamentales Comportamientos, conocimientos y habilidades para la ejecución efectiva del Análisis de Negocio.
  21. 21. Análisis de negocioDefine una nueva Determina el necesidad de Evaluar el GAP Enfoque de la Define el alcance negocio Solución“Identifica y documenta los requerimientos de negocio y es a menudo elpunto de partida para el inicio de un nuevo proyecto o proyectos”
  22. 22. Define una nueva Determina el necesidad de Evaluar el GAP Enfoque de la Define el alcance negocio Solución• Benchmarking • Análisis de • Benchmarking • Descomposición funcional documentos• Brainstorming • Brainstorming •  Análisis de Interfaces • Análisis DAFO• Análisis de Reg. de Negocio • Análisis de decisiones •  Modelado de alcance• Focus Group • Estimación •  Historias de Usuario• Descomposición Funcional • DAFO •  Declaración de problema o Visión• Análisis Causa-Raiz
  23. 23. • Entrevistas con stakeholders ( o Workshops de requisitos, Focus groups, reuniones de sgto, talleres) • Exploración de escenarios • Estudios de mercado o de cualquier tipoFuentes de requisitos • Sistemas existentes de stakeholders • Problemas y sugerencias de cambio de sistemas existentes • Sistemas análogos • Prototyping, mock-ups, sketching • Cuestionarios
  24. 24. Bases de organización de requisitos Seleccionar el modeloCrear un conjunto de vistas/modelos para la - Escenarios de Usonueva solución de negocio , exhaustiva,completa, consistente y entendida desdetodas las perspectivas de los stakeholders. -  Modelado de procesosSon modelos no técnicos, entendibles porlos stakeholder. -  Historias de Usuario
  25. 25. Relación entre el ciclo de vida de los requisitos y delproyecto.
  26. 26. Nivel ModelosRequisitos de Sistema - Diagramas/descripción de arquitecuras o infraestructura tecnológica: •  Hardware •  Software •  DatosRequisitos de -  Diagramas UMLSusbsistema
  27. 27. Más información en http://www.evergreenpm.com/E-mail: info@evergreenpm.comMuchas Gracias, Javier Sánchez

×