1
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)
Contenido
2.0 Entregables
1.0 Conceptos
4.0 Actividades
3.0 Insumos
5.0 Roles
Anexos
2
Contenido
2.0 Entregables
1.0 Conceptos
4.0 Actividades
3.0 Insumos
5.0 Roles
Anexos
3
● 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 yno a la necesidades de los usuarios.
Algunos problemas a enfrentar
4
● “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
Definición de Ingeniería de Requerimientos
5
Interpretación
Representación
Negociación
Necesidades, deseos, aspiraciones, expectativas.... Analizar, negociar, priorizar...
6
● 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
7
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.
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
8
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.
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
9
Requerimientos de Usuario
Requerimientos de Usuario
Requerimientos de Producto
Requerimientos de Producto
Arquitectura / Diseño del Sistema
Arquitectura / Diseño del Sistema
Mundo Real
Sistema a Construir
satisface
satisface
Resultados deseados para afrontar
problemas u objetivos del mundo real
Soluciones ingenierizadas usando
sistemas actuales o nuevos
… necesitan ser pensados de manera diferente..... en lo que sigue se dará enfasis a los Requerimientos de Usuario
… 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
10
Desarrollar Requerimientos
de Sistemas
TécnicosEntorno
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)
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
11
Infraestructurapara Procesos
Gestión deProcesos
CMMI / SE / SW - Continuos
Definición de Procesos
Programa de Entrenamiento
Gestión Cuantitativa de Procesos
Mejora Cuantitativade Procesos
Gestión deProyectos
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 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.
12
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
CMMI: Prácticas Específicas (SP) como núcleo de la Ingeniería de Requerimientos
Prácticas Específicas (SP) de CMMI y Las 3 Dimensiones (I, R, N)
13
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
NR
X
I
X
XXX
X
X
XX
X
XXX
X
X
X
XX
XX
XXX
XXX
XXX
XXX
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
14
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)
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)
CU1 Retirar
1. Cliente del Banco se identifica2. El Sistema verifica la identidad3. Cliente del Banco escoge una cuenta y el monto a retirar.4. El Sistema reduce el saldo de la cuenta5. El Sistema entrega el dinero
2a. Cliente del Banco no logra identificación válida …. …. ….4a. Cliente del Banco no tiene fondos suficientes …. .…
CU1 Retirar
1. Cliente del Banco se identifica2. El Sistema verifica la identidad3. Cliente del Banco escoge una cuenta y el monto a retirar.4. El Sistema reduce el saldo de la cuenta5. 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
TransferirCliente del Banco
Actor
Casos de Uso
SOA: Los Requerimientos como Servicios Tecnológicos para las Actividades
15
1.0 Modelamiento del Negocio
2.0 Modelamiento de Requerimientos
3.0 Modelamiento de la Tecnología
● 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á
¿Porqué son tan útiles los CU?
16
Contenido
2.0 Entregables
1.0 Conceptos
4.0 Actividades
3.0 Insumos
5.0 Roles
Anexos
17
Plantilla: Especificación general de un Caso de Uso – Modelo Original
18
IRE - E – Especificación General de un CdU – Modelo Original - Plantilla.xls”. IRE - E – Especificación General de un CdU – Modelo Original - Plantilla.xls”.
Plantilla: Especificación general de un Caso de Uso – Modelo Intermedio
19
IRE - E – Especificación General de un CdU – Modelo intermedio - Plantilla.xls”. IRE - E – Especificación General de un CdU – Modelo intermedio - Plantilla.xls”.
Plantilla: Especificación general de un Caso de Uso – Modelo Requerido
20
IRE - E – Especificación General de un CdU – Modelo Requerido - Plantilla.xls”. IRE - E – Especificación General de un CdU – Modelo Requerido - Plantilla.xls”.
Plantilla: Diagramas Star Net
21
Plantilla: Prototipos de Vistas
22
Plantilla: Matriz de Alineamiento y Priorización (Funcionalidad vs. Estrategia)
23
IRE – E – (POR RECONSTRUIR).xls”. IRE – E – (POR RECONSTRUIR).xls”.
Contenido
2.0 Entregables
1.0 Conceptos
4.0 Actividades
3.0 Insumos
5.0 Roles
Anexos
24
Contenido
2.0 Entregables
1.0 Conceptos
4.0 Actividades
3.0 Insumos
5.0 Roles
Anexos
25
Ingeniería de Requerimientos - Diagrama de Actividades
26
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
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
27
Modelar Requerimientos de Usuario
SistemasUsuarios
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 EspecficacionesID - Modelamiento de
Requerimientos por validar
Contenido
28
2.0 Entregables
1.0 Conceptos
4.0 Actividades
3.0 Insumos
5.0 Roles
Anexos
Roles - Genéricos para Proyectos de Cambio
29
ADC - R - Funciones … xls ADC - R - Funciones … xls ADC - C - Guía ... pptADC - C - Guía ... ppt
Roles: Los específicos para este Componente Metodológico
30
IRE- R - Funciones… xls”. IRE- R - Funciones… xls”. ADC - C – Guía ... pptADC - C – Guía ... ppt
Contenido
2.0 Entregables
1.0 Conceptos
4.0 Actividades
3.0 Insumos
5.0 Roles
Anexos
31
Rastreabilidad (Traceability) hacia adelante y en retroceso
32
Moviéndose hacia adelante para evaluar el impacto de un cambio
Todo lo que se programa debe corresponder a algún Requerimiento.
Todo Requerimiento oficial debe ser cubierto por alguna funcionalidad del sistema.
Moviéndose hacia atrás para identificar el origen de un componente
Requerimentos de Usuario
Requerimentos de Usuario
Código de Programación
Código de Programación
Requerimientos del Producto
Requerimientos del Producto
Interpretación de los Requerimientos
33