05 Visure VI Semana del CMMI

RCM, The Requirements Capability Model,
un marco complementario a modelos de madurez CMMI
11 de Noviembre de 2010 www.visuresolutions.com
Almudena Díez, Consultora – adiez@visuresolutions.com

www.visuresolutions.com Copyright 2008 © Visure Solutions, The Requirements Company - +34 91 806 17 13 - info@visuresolutions.com - 28760 Tres Cantos MADRID 2
The Requirements Capability Model, RCM
Agenda
1. Presentación de la Compañía
2. ¿Por qué preocuparme de los requisitos?
3. Metodología de Mejora para el desarrollo y
gestión de requisitos
4. The Requirements Capability Model (RCM)

Agenda
2. ¿Por qué preocuparme de los requisitos?

¿Quiénes somos?
1. Compañía con capital 100% español especializada en Ingeniería
de Requisitos.
2. Experiencia de más de 10 años en proyectos de Ingeniería de
Requisitos
3. Fabricante y distribuidor de la solución IRQA, líder en Ingeniería de
Requisitos, con más de 200 clientes en 40 países.
4. Alianzas internacionales con las principales consultoras
especializadas en Requisitos, como HOOD Group (Alemania), the
Atlantic Systems Guild (USA) o International Requirements
Engineering Board.
 Acuerdos exclusivos para impartir sus programas formativos
 Acuerdos exclusivos para aplicar sus metodologías registradas en
nuestros clientes
 Formador autorizado IREB.
1. Innovación y evolución continuada.
2. Orientados a solución.
3. Certificación ISO SPICE

Nuestra visión
Ayudar a nuestros clientes a mejorar la calidad de sus
productos y servicios a través de la optimización de sus
procesos de Gestión y Definición de Requisitos

Agenda
2. ¿Por qué preocuparme de los Requisitos?

¿Le son familiares estas situaciones?
1. La visión del proyecto y el alcance nunca son claramente definidos.
2. Los clientes están demasiado ocupados para gastar su tiempo trabajando
con los analistas o desarrolladores sobre los requisitos.
3. Los clientes afirman que todos los requisitos son críticos, y no los priorizan.
4. Los desarrolladores se encuentran con ambigüedades y omisión de
información cuando desarrollan los requisitos, y así comienza la inventiva.
5. Sus clientes firman (aprueban) los requisitos y luego los cambian
continuamente.
6. El alcance del proyecto aumenta a medida que se aceptan cambios en
requisitos, pero el calendario no se modifica en plazos ni en recursos.
7. Los cambios de requisitos se pierden e incluso no se conoce el estado de
las peticiones de cambio.
8. La funcionalidad es solicitada y construida, pero nunca usada.
9. La especificación está satisfecha, pero el cliente no.

Sorpresa!
}Tiempo
Lo que el cliente necesita
Lo que el desarrollador construye
¿Le son familiares estas situaciones?

La realidad de los proyectos software
1. En 2004, el Chaos Report de Standish Group vaticinaba una mejora
continuada en el número de proyectos software que terminaban con éxito.
¿Pero qué ha ocurrido en realidad?
Nota: Standish Group, en su Chaos Report considera como variables de éxito la entrega en tiempo y coste, la calidad de
los sistemas entregados, y el cumplimiento de las necesidades del usuario (alcance)

La realidad de los proyectos software
1. Evolución de los resultados del análisis Chaos Report.
2. En 2006, diferentes analistas ya predecían este comportamiento:
Fuente: TynerBlain.com

Algunos datos interesantes…
Causas de los defectos
Requirements
Errors
(82% )
RequirementsRequirements
ErrorsErrors
(82% )(82% )
Design Errors
(13% )
Design ErrorsDesign Errors
(13% )(13% )
Coding Errors (1% )Coding Errors (1% )Coding Errors (1% )Other Errors (4% )Other Errors (4% )Other Errors (4% )
Requirements
Errors
(82% )
RequirementsRequirements
ErrorsErrors
(82% )(82% )
Design Errors
(13% )
Design ErrorsDesign Errors
(13% )(13% )
Coding Errors (1% )Coding Errors (1% )Coding Errors (1% )Other Errors (4% )Other Errors (4% )Other Errors (4% )Other Errors (4% )Other Errors (4% )Other Errors (4% )
Esfuerzo dedicado a corregir los defectos
Coste relativo de solucionar un defecto
Fuentes: James Martin, Barry Boehm
0 5 10 15 20 25
200
180
160
140
120
100
80
60
40
20
0
%Overcost
% Requirements Management Cost compared to total project cost
0- 5% invested in Req.
Management results in 80-200%
overcost
8-14% invested in Req.
overcost
Project Analyzed
0 5 10 15 20 25
200
180
160
140
120
100
80
60
40
20
0
%Overcost
% Requirements Management Cost compared to total project cost
0- 5% invested in Req.
overcost
8-14% invested in Req.
overcost
Project Analyzed
La importancia de los Requisitos

¿Cuál es el Retorno de la Inversión (ROI)?
1. Según datos del Software Engineering Institute, SEI, el 40% del
tiempo de un proyecto se dedica al retrabajo:
 Alrededor de un 80% del retrabajo está asociado a problemas en los
Requisitos. ¡Esto supone que el 30% del coste y esfuerzo de un proyecto
se dedica a corregir defectos en los Requisitos!
1. Según Gartner, un tercio del dinero invertido en mejoras en la
codificación no proporciona ningún valor a las organizaciones.
¿Por qué no invertirlo en mejorar los procesos de Requisitos?
UN PROYECTO TÍPICO…
Número de líneas de código 50.000
Número de desarrolladores 6
Otros miembros del equipo (Jefe de Proyecto, analistas, pruebas,…) 4
Duración estimada (meses) 12
Coste medio por mes de los recursos 30.000€
Total coste del proyecto 360.000€
Total coste del retrabajo (40%) 144.000€
Total coste retrabajo asociado a requisitos (80%) 115.200€ 30%

Agenda
3. Metodología de Mejora para el desarrollo
y gestión de requisitos

Metodología de Mejora
Process
Asset
Library
Modelos
Madurez
Requirements
Capability
Model
Evaluaciones Visure
University
Technical
Asset
Library
Contexto
Actual y legislativo

Fase 1 – Diagnóstico Inicial
1. OBJETIVOS
 Analizar los procesos actuales y en definición
 Detectar fortalezas y debilidades
 Establecer grado de alineamiento con estándares
1. ACTIVIDADES
 Preparación y orientación de la evaluación
 Revisión de documentación de procesos
 Revisión de documentación de proyectos
 Revisión de implantación mediante entrevistas
 Elaboración y presentación de los informes de resultados

Estándares utilizados
1. CMMI for Development v 1.2
 Principalmente las áreas de proceso REQM Y RD.
 Pero analizando los interfaces con otras áreas de
proceso como TS, PI, VER, VAL, RSKM, CM, PP y PMC.
 Evalúa el uso de prácticas específicas y genéricas,
así como el cumplimiento de objetivos.
2. Requirements Capability Model (RCM)
 Definido por Visure en colaboración con líderes del sector de
automoción y defensa.
 Específico de Ingeniería de Requisitos.
 Evalúa las prácticas, actividades, necesidades de capacitación y
herramientas de apoyo existentes.
 Cubre aspectos como reutilización, gestión del cambio, trazabilidad,
grado de implantación, …

Estándares utilizados
3. IREB: estándar para la certificación de analistas
en Ingeniería de Requisitos.
4. SPICE (ISO 15504)
 Principalmente las áreas de proceso de:
• Definición de requisitos de stakeholders
• Análisis de los requisitos del sistema
• Análisis de requisitos del software
 Pero analizando los interfaces con otras áreas de proceso de soporte
 Evalúa:
• Parte genérica: Uso de atributos de proceso (AP) y los componentes de los atributos de
proceso (CAP)
• Parte específica (outcomes)
• Cumplimiento de objetivos

Agenda

RCMRCMRCMRCMRCM
Proceso
CMMI, Spice, ISO, ad-hoc
Personas
Formación
Nivel 1
Nivel 3
Nivel 2
Nivel 4
Nivel 5
Tecnología
Herramientas

¿Por qué emplear RCM?
¿Por qué emplear The Requeriments Capability Model (RCM)?
 Es un Modelo de Buenas Prácticas basado en experiencias exitosas del
mercado.
 Evalúa la idoneidad de la Capacidad del Proceso de Requisitos en tres
aspectos:
• Los PROCESOS
• Las PERSONAS
• La TECNOLOGÍA
 Es compatible y complementario con otros estándares y modelos de
referencia, p. e. CMMI, SPICE, ITIL, COBIT, etc.

Objetivos de RCM
• Los principales objetivos de un diagnóstico inicial empleando
RCM son:
 Identificar la adherencia de los Procesos de Ingeniería de Requisitos
con los estándares reconocidos por el mercado:
• CMMI for Development v1.2
• SPICE (ISO 15504)
• IREB
 Profundizar en el detalle, de cara a la identificación de diferentes
características del Proceso de Definición y Gestión de Requisitos,
como son:
• Estructuración de los requisitos
• Idoneidad de la trazabilidad
• Alcance de la gestión de cambios
• Reutilización de requisitos
• Etc.

Niveles de RCM
• El Modelo RCM establece diferentes niveles de Capacidad:
 En el nivel 0 los requisitos están recogidos en documentos y no están
estructurados más allá de la organización en capítulos del propio
documento.
 En el nivel 1 comienza la implantación del proceso de Ingeniería de
Requisitos en una organización.
 En el nivel 2 existe un proceso de Gestión y Definición de Requisitos
establecido.
 En el nivel 3 se mantienen trazas a nivel de pruebas de aceptación y
gestión del proyecto.
 En el nivel 4 se mantienen trazas a nivel de elementos de diseño.
 En el nivel 5 es consistente la gestión de cambios, la reutilización de
requisitos y la implantación corporativa del proceso de Ingeniería de
Requisitos.

El Modelo RCM
NIVELES DE CAPACIDAD
Nivel 5
Modelizado
Se realizan modelos de negocio: clases conceptuales, casos de uso
de negocio, diagramas de secuencia, etc.
Se realizan modelos del funcionamiento del sistema a desarrollar:
casos de uso, escenarios, prototipos, etc.
Nivel 4
Trazado
Los requisitos se trazan con los elementos de diseño.
Nivel 3
Trazado inicial
Se asegura que los requisitos son verificables.
Se trazan los requisitos con las pruebas de aceptación y verificación.
Se trazan los requisitos con las etapas del proyecto.
Nivel 2
Proceso Definido
Se establecen los niveles de requisitos a tratar (requisitos de usuario,
de sistema, de subsistema, etc.), y los tipos de requisitos
(funcionales, no funcionales.)
Se definen las relaciones de trazabilidad entre requisitos.
Se establece el proceso de gestión de los requisitos de los distintos
niveles (ciclo de vida, responsables de cada estado, etc.)
Nivel 1
Estructurado
Los requisitos están identificados con códigos únicos, redactados de
forma adecuada y caracterizados con atributos básicos (origen y
prioridad)
Nivel 0
No Estructurado
Los requisitos están recogidos en documentos y no están
estructurados.

Niveles de RCM
Nivel 0- No estructurado
Nivel 1- Estructurado
Nivel 2- Proceso definido
Nivel 3- Trazado inicial
Nivel 4- Trazado
Gestióndelcambioyreutilización
Nivel 5- Modelizado

Niveles de capacidad RCM
• Niveles de 1 a 3:
 Comienza la implantación del proceso de Ingeniería de Requisitos en
una organización.
 Los requisitos están estructurados en una jerarquía (requisitos padre e
hijos).
 Se identifican incipientes prácticas para la gestión de cambios, la
reutilización de requisitos y la implantación corporativa del proceso
de Ingeniería de Requisitos.
 Se identifican métricas.
• Niveles 4 y 5:
 Existe trazabilidad completa y gestión de cambios a todos los niveles.
 La reutilización de requisitos existe y es consistente.
 Se dispone de métricas consistentes.

• Cada uno de los niveles de capacidad está conformado
por diversas prácticas, que se agrupan en 4 categorías:
 Prácticas relacionadas con la Ingeniería de Requisitos (IR)
 Prácticas relacionadas con el Control de Cambios (GC)
 Prácticas para garantizar la Implantación Corporativa (IC)
 Prácticas de Reutilización (RU)

NIVEL
Ingeniería de Requisitos
y Gestión de Cambios
Implantación
Corporativa y
Reutilización
Funcionalidades
Herramienta (IRQA)
Formación
necesaria
Nivel 1
Codificación de
requisitos
Patrón de escritura
Jerarquía
Origen de requisitos
Prioridad de requisitos
Líneas base
Impacto de cambio en
requisitos
Negociación de cambios
Conceptos de negocio
Reglas de
codificación
Plantillas de
redacción de
requisitos
Valores de prioridad
Métricas de
redacción de
requisitos
Reutilización de
patrones
Reutilización de
conceptos de
negocio
Captura de requisitos y
servicios
Codificación automática
Atributos
Jerarquía de requisitos
Gestión de vistas y filtros
Versiones de requisitos y
servicios
Líneas base
Plantillas de proyecto
IRQA Quality Analyzer
Module
Formación básica
en IR:
- Redacción de
requisitos
- Codificación
- Priorización
- Trazabilidad al
origen
- Conceptos de
negocio

NIVEL
Implantación
Corporativa y
Reutilización
Funcionalidades
Herramienta (IRQA)
Formación
necesaria
Nivel 2
Identificación de niveles
de requisitos
Ciclo de vida
Clasificación de
requisitos
Trazabilidad entre
niveles
Relaciones entre
requisitos
Análisis de impacto de
cambios
Definición de
niveles de
requisitos y reglas
de trazabilidad
Tipificación de
requisitos
Métricas de
consistencia
Reutilización de
requisitos
Diagramas de bloques
Atributos
Flujos de trabajo
Relaciones entre
requisitos por motivo libre
Matriz de trazabilidad
Análisis de consistencia
Reutilización de
componentes
Formación en IR:
- Trazabilidad
- Ciclo de vida de
requisitos

NIVEL
Implantación
Corporativa y
Reutilización
Funcionalidades
Herramienta (IRQA)
Formación
necesaria
Nivel 3
Definición de niveles de
pruebas de aceptación y
verificación
Trazabilidad de
requisitos a pruebas
Asignación de
requisitos a etapas del
proyecto
cambios
Definición de
niveles de pruebas
y reglas de
trazabilidad con
requisitos
Definición de reglas
de asignación a
etapas del proyecto
Métricas de
consistencia
Métodos de
estimación de
esfuerzo
Reutilización de
requisitos y pruebas
Diagramas de bloques
Atributos
Captura de pruebas
Matriz de trazabilidad
Integración con TD/QC
Integración con MS
Project
Análisis de consistencia
Estimación de esfuerzo
Reutilización de
componentes
Formación en IR:
- Requisitos y
pruebas
- Requisitos y
gestión de
proyecto

NIVEL
Ingeniería de
Requisitos y Gestión
de Cambios
Implantación
Corporativa y
Reutilización
Funcionalidades
Herramienta (IRQA)
Formación
necesaria
Nivel 4
Identificación de
elementos de diseño
Trazabilidad entre
requisitos y
elementos de diseño
Análisis de impacto
de cambios
Definición de
técnicas de diseño y
reglas de
trazabilidad
Métricas de
consistencia
Reutilización de
requisitos y
elementos de
diseño
Integración con
herramientas UML
Formación en IR:
- Trazabilidad

NIVEL
Implantación
Corporativa y
Reutilización
Funcionalidades Herramienta
(IRQA)
Formación
necesaria
Nivel 5
Modelos de negocio
Trazabilidad entre
requisitos y modelos de
negocio
Modelos de interacción
del sistema con el
exterior
Modelos de
comportamiento del
sistema
cambios
Reglas de
trazabilidad entre
requisitos y
elementos de
modelización
Reutilización de
modelos de negocio
Relaciones entre requisitos y
conceptos de negocio
Diagramas de casos de uso y
de contexto
Actores/Entidades Externas
Servicios
Diagramas de estados
Diagramas de secuencia
DFDs
Escenarios
Analizador Automático
Plantillas de proyecto
Formación en
IR:
-Técnicas de
modelización
de requisitos

Evaluación RCM
1. El modelo RCM posee un método de evaluación basado en el
análisis de:
 La documentación de los Procesos de Gestión y Definición de
Requisitos.
 La documentación de los Proyectos en el marco de los Requisitos.
 Adicionalmente a la revisión de esta documentación, se realizan
diferentes entrevistas con el personal involucrado, de forma que todos
los puntos de vista son tenidos en cuenta.
1. Toda esta información es tratada de forma objetiva para obtener
así una ponderación de la adherencia de los procesos de la
organización frente a las prácticas del modelo, a nivel de
cumplimiento con el Modelo RCM y también para cada nivel de
RCM en sus diferentes categorías.

Resultados RCM
Cumplimiento RCM
0%
10%
20%
30%
40%
50%
60%
70%
80%
90%
100%
NIVEL 1 NIVEL 2 NIVEL 3 NIVEL 4 NIVEL 5
R
Y
G
Nivel 1
0%
10%
20%
30%
40%
50%
60%
70%
80%
90%
100%
PRÁCTICAS IR PRÁCTICAS GC PRÁCTICAS IC PRÁCTICAS RU
R
Y
G
G: No se identifican debilidades en la ejecución de las prácticas
Y: Se identifican algunas debilidades en la ejecución de las prácticas
R: No se ejecutan las prácticas
• Se obtiene una valoración cualitativa y cuantitativa de la
cobertura frente al modelo RCM, identificando:
 Puntos Fuertes
 Oportunidades de Mejora
 Métricas del cumplimiento de cada nivel y práctica

34
¿PREGUNTAS?
¡Muchas gracias!
adiez@visuresolutions.com

05 Visure VI Semana del CMMI

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (18)

Similar to 05 Visure VI Semana del CMMI

Similar to 05 Visure VI Semana del CMMI (20)

More from Pepe

More from Pepe (20)

Recently uploaded

Recently uploaded (20)

05 Visure VI Semana del CMMI

Editor's Notes