Moderamiento de Requerimientos de Software (IRE) Guía del Componente Metodológico Aplica el Meta Modelo de Metodologías CEIAR (Conceptos, Entregables, Insumos, Actividades, Roles)

oooooo Contenido 1.0 Conceptos 2.0 Entregables 3.0 Insumos 4.0 Actividades 5.0 Roles Anexos oooooo

oooooo Contenido 1.0 Conceptos 2.0 Entregables 3.0 Insumos 4.0 Actividades 5.0 Roles Anexos oooooo

Algunos problemas a enfrentar Los usuarios no saben con precisión lo que requieren y se les dificulta definir su opinión sobre documentación que represente sus requerimientos. Los usuarios proponen requerimientos tardíos, después de que los costos y calendarios han sido establecidos. Los técnicos no dominan el lenguaje de los usuarios y por ello con frecuencia creen erradamente haber logrado acuerdo con ellos respecto a sus expectativas. Los técnicos tratan de ajustarse a las características de los sistemas vigentes y no a la necesidades de los usuarios.

Definición de Ingeniería de Requerimientos “Es la aplicación disciplinada de principios científicos y técnicas para desarrollar, comunicar y gestionar requerimientos.” La Ingeniería de Requerimientos cumple un papel primordial en el proceso de producción de software, ya que enfoca un área fundamental: la definición de lo que se desea producir. Se fundamenta en enfrentar los factores causantes de Proyectos Fracasados y Cuestionados, a la vez que impulsa los factores determinantes de Proyectos Exitosos.11 Interpretación Representación Negociación

Necesidades, deseos, aspiraciones, expectativas Necesidades, deseos, aspiraciones, expectativas.... Analizar, negociar, priorizar... Los requerimientos por lo general son de una magnitud que supera la capacidad disponible para satisfacerlos. Es necesario precisar cuando el término “Necesidad”, se usa para expresar reales imperativos para afrontar problemas u objetivos. Aveces se confunde “Necesidad” con “Caracteristicas Interesantes” (Nice to have) o necesidades personales y subjetivas.

Un Proceso Iterativo a través de tres Dimensiones Desarrollo y Gestión de Requerimientos Interpretación (I) Representación (R) Negociación (N) Las actividades de la Ingeniería de Requerimientos se dan a través de 3 dimensiones Interrelacionadas entre si y gestionadas a lo largo de todo el proceso interactuando de manera colaborativa con los usuarios.

Niveles por cada Dimensión y el Resultado Óptimo de la Ingeniería de Requerimientos El Resultado Óptimo del Desarrollo y Gestión de Requerimientos se expresa como el punto en que se logra una Interpretación Completa, una Representación Formal y una Negociación que concluya con un Punto de Vista Común.

Dos tipos de Requerimientos Sistema a Construir Mundo Real Requerimientos de Usuario Requerimientos de Producto satisface satisface Resultados deseados para afrontar problemas u objetivos del mundo real Soluciones ingenierizadas usando sistemas actuales o nuevos Arquitectura / Diseño del Sistema … necesitan ser pensados de manera diferente ..... en lo que sigue se dará enfasis a los Requerimientos de Usuario

Contexto para el Desarrollo de Requerimientos según IEEE Desarrollar Requerimientos de Sistemas Técnicos Entorno Clientes Requerimientos No Formales Feedback de Clientes Representación Funcional Restricciones / Influencias Representación Técnica Feedback de Técnicos Este modelo se basa en el Estándar 1233 de la IEEE (1998). Aspectos relevantes: 1. El Desarrollo de Requerimientos implica un proceso iterativo entre Usuarios y Técnicos (Mediante el intercambio de Representaciones y Feedback). 2. Los ciclos iterativos se inician con la emisión de los Requerimientos No Formales por procesar. 3. Existen otros inputs del Entorno (Estrategia, Estructura, Otros Grupos de Interés, Estándares, etc)

Procesos para Desarrollo de Sistemas y de Software según el CMMI Infraestructura para Procesos Gestión de Procesos CMMI / SE / SW - Continuos Definición de Procesos Programa de Entrenamiento Gestión Cuantitativa de Procesos Mejora Cuantitativa Proyectos Ingeniería Soporte Planeamiento de Proyectos Control y Seguimiento de Proyectos Gestión de Proveedores Gestión Integrada de Proyectos Equipos Integrados Gestión del Riesgo Gestión Cuantitativa de Proyectos Gestión de Requerimientos Desarrollo de Requerimientos Diseño, Desarrollo e Implementación Integración del Producto Revisiones Pruebas Gestión de la Configuración Aseguramiento de la Calidad Análisis y Métricas Análisis Causal y Solución Toma de Decisiones Estructurada Ambiente Organiza-cional Integrado Gestión Integrada de Proveedores CMMI es el Marco Conceptual más reconocido respecto a Mejores Prácticas en el Desarrollo de Sistemas y de Software, establece dos Áreas de Procesos para la Ingeniería de Requerimientos.

CMMI: Prácticas Específicas (SP) como núcleo de la Ingeniería de Requerimientos PA Gestión de Requerimientos Ingeniería SP 1.1-1 Obtener Entendimiento de los Requerimientos PA Desarrollo de Requerimientos SP 1.2-2 Obtener Compromiso con los Requerimientos SP 1.3-1 Gestionar Cambios de Requerimientos SP 1.4-2 Mantener Rastreabilidad Bidireccional de Requerimientos SP 1.5-1 Identificar inconsistencias entre Requerimientos y Avances SP 1.1-1 Recolectar Necesidades de los Grupos de Interés SP 1.1-2 Generar Requerimientos SP 1.2-1 Desarrollar los Requerimentos de Clientes SP 2.1-1 Establecer Requerimientos de Productos y sus Componentes SP 2.2-1 Asignar Requerimientos a Componentes de Productos SG1 Gestión de Requerimientos SG1 Desarrollar Requerimientos de Clientes SG2 Desarrollar Requerimientos de Productos SG3 Analizar y Validar Requerimientos SP 2.3-1 Identificar Requerimientos de Interfases SP 3.1-1 Establecer Conceptos y Escenarios Operacionales SP 3.2-1 Establecer una Definición de la Funcionalidad Requerida SP 3.3-1 Analizar Requerimientos SP 3.4-3 Analizar Requerimientos para Mantener un Balance SP 3.5-1 Validar Requerimientos SP 3.5-2 Validar Requerimientos con Métodos de Amplio Alcance

Prácticas Específicas (SP) de CMMI y Las 3 Dimensiones (I, R, N) SP 1.1-1 Obtener Entendimiento de los Requerimientos SP 1.2-2 Obtener Compromiso con los Requerimientos SP 1.3-1 Gestionar Cambios de Requerimientos SP 1.4-2 Mantener Rastreabilidad Bidireccional de Requerimientos SP 1.5-1 Identificar inconsistencias entre Requerimientos y Avances SP 1.1-1 Recolectar Necesidades de los Grupos de Interés SP 1.1-2 Interpretar Requerimientos SP 1.2-1 Desarrollar los Requerimentos de Clientes SP 2.1-1 Establecer Requerimientos de Productos y sus Componentes SP 2.2-1 Asignar Requerimientos a Componentes de Productos SP 2.3-1 Identificar Requerimientos de Interfases SP 3.1-1 Establecer Conceptos y Scenarios Operacionales SP 3.2-1 Establecer una Definición de la Funcionalidad Requerida SP 3.3-1 Analizar Requerimientos SP 3.4-3 Analizar Requerimientos para Mantener un Balance SP 3.5-1 Validar Requerimientos SP 3.5-2 Validar Requerimientos con Métodos de Amplio Alcance N R X I SG1 Gestión de Requerimientos SG1 Desarrollar Requerimientos de Clientes SG2 Desarrollar Requerimientos de Productos SG3 Analizar y Validar Requerimientos

Los Casos de Uso como base para la Representación de los Requerimientos CU1 Retirar 1. Cliente del Banco se identifica 2. El Sistema verifica la identidad 3. Cliente del Banco escoge una cuenta y el monto a retirar. 4. El Sistema reduce el saldo de la cuenta 5. El Sistema entrega el dinero 2a. Cliente del Banco no logra identificación válida …. 4a. Cliente del Banco no tiene fondos suficientes .… Retirar Depositar Transferir Cliente del Banco Actor Casos de Uso Los Casos de Uso son uno de los elementos más importantes, sino el más importante del UML (unified Modeling Language). El UML es el estándar de facto a nivel mundial en relación a Análisis y Diseño de Sistemas. Son también un pilar del RUP (Rational Unfied Process)

SOA: Los Requerimientos como Servicios Tecnológicos para las Actividades 1.0 Modelamiento del Negocio 2.0 Modelamiento de Requerimientos 3.0 Modelamiento de la Tecnología

¿Porqué son tan útiles los CU? Son intuitivos. Fortaleza su forma conversacional. El usuario puede entenderlos como “una explicación su procedimientos y la manera como el sistema apoyará en cada punto clave”. Se centran en el valor para el usuario. Las pantallas, reportes y archivos se diseñan luego teniendo más claridad en el “por qué” o el “para qué”. No debería desarrollarse funcionalidad sin un uso pre establecido. Facilitan el lograr acuerdos. Usuarios y técnicos comparten un lenguaje común. El eje siempre es lo que el usuario hace y como el sistema lo servirá

oooooo Contenido 1.0 Conceptos 2.0 Entregables 3.0 Insumos 4.0 Actividades 5.0 Roles Anexos oooooo

Plantilla: Especificación general de un Caso de Uso – Modelo Original IRE - E – Especificación General de un CdU – Modelo Original - Plantilla.xls”.

Plantilla: Especificación general de un Caso de Uso – Modelo Intermedio IRE - E – Especificación General de un CdU – Modelo intermedio - Plantilla.xls”.

Plantilla: Especificación general de un Caso de Uso – Modelo Requerido IRE - E – Especificación General de un CdU – Modelo Requerido - Plantilla.xls”.

Plantilla: Diagramas Star Net

Plantilla: Prototipos de Vistas

IRE – E – (POR RECONSTRUIR).xls”. Plantilla: Matriz de Alineamiento y Priorización (Funcionalidad vs. Estrategia) IRE – E – (POR RECONSTRUIR).xls”.

oooooo Contenido 1.0 Conceptos 2.0 Entregables 3.0 Insumos 4.0 Actividades 5.0 Roles Anexos oooooo

oooooo Contenido 1.0 Conceptos 2.0 Entregables 3.0 Insumos 4.0 Actividades 5.0 Roles Anexos oooooo

Ingeniería de Requerimientos - Diagrama de Actividades Modelar Requerimientos Desarrollar Requerimientos Modelar Requerimientos de Producto Gestionar Requerimientos Modelar Requerimientos de Usuario Falta cubrir Alcance Se cubrió Alcance Faltan precisionesv No faltan precisiones Faltan precisiones Recolectar Negociar Documentar Validar Formulación del Proyecto ID - Modelamiento del Negocio ID - Modelamiento de Requerimientos

Modelar Requerimientos de Usuario - Ciclo de Coordinación Sistemas Usuarios Recolectar Negociar Documentar Validar Prever Costos y Restricciones Revisar y confirmar cumplimiento de Intencionalidad (Problemas/Objetivos) Casos de Uso y Servicios Candidatos Priorizar y Justificar según Beneficios / Costos Casos de Uso y Servicios Acordados ID - Modelamiento de Requerimientos Investigar reglas del Negocio Atender Entrevistas y Generar Servicios Candidatos Apoyar en Generación de Servicios ID - Modelamiento del Negocio Identificar Actores y otras fuentes Analizar y Definir Contrapropuestas Describir Interacción Actores / Sistemas Prototipear Pantallas para implementar Servicios en cada Caso de Uso Complementar e Integrar Especficaciones ID - Modelamiento de Requerimientos por validar

oooooo Contenido 1.0 Conceptos 2.0 Entregables 3.0 Insumos 4.0 Actividades 5.0 Roles Anexos oooooo

Roles - Genéricos para Proyectos de Cambio ADC - R - Funciones … xls ADC - C - Guía ... ppt

Roles: Los específicos para este Componente Metodológico IRE- R - Funciones… xls”. ADC - C – Guía ... ppt

oooooo Contenido 1.0 Conceptos 2.0 Entregables 3.0 Insumos 4.0 Actividades 5.0 Roles Anexos oooooo

Rastreabilidad (Traceability) hacia adelante y en retroceso Moviéndose hacia adelante para evaluar el impacto de un cambio Requerimentos de Usuario Código de Programación Requerimientos del Producto Moviéndose hacia atrás para identificar el origen de un componente Todo lo que se programa debe corresponder a algún Requerimiento. Todo Requerimiento oficial debe ser cubierto por alguna funcionalidad del sistema.

Interpretación de los Requerimientos