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