Consultoria CMMI REQM 071023 2 Slides

Administración de Requerimientos
Administración de
Requerimientos
REQM
Octubre de 2007
® Capability Maturity Model Integration esta registrada en la oficina
de U.S. Patent and Trademark por la Universidad de Carnegie
Mellon.
La distribución de este material está limitada por el SIECenter de

México a los asistentes a este curso.
© SIE Center México, Documento de Carácter Confidencial 1
Misión del SIE Center

Contribuir al desarrollo de la industria,

incrementando su competitividad a través de
la difusión, la mejora continua y el
conocimiento en tecnologías de información.

SIE Center- Áreas
Capacitación
Consultoría Evaluaciones
Investigación
Propósito del Curso

Entender el concepto de
Administración de
Requerimientos desde
la perspectiva del
modelo CMMI, así
como los factores a
considerar para lograr
una exitosa
implementación.

Objetivos del Curso – 1
• Identificar dos tipos de

requerimientos: orientado al
cliente y descripción técnica
del problema.
• Identificar técnicas para lograr
entender ambos requerimientos
• Facilitar el compromiso a los
requerimientos
• Manejar atributos de los requerimientos
• Entender el concepto y uso del rastreo
de requerimientos
Objetivos del Curso – 2

• Conocer los tipos de rastreo y sus

representaciones gráficas
• Entender el contexto de los procesos
de REQM en el ciclo de vida
• Entender los objetivos y prácticas
específicas de REQM
• Manejar el control de cambios de requerimientos:
análisis de impacto, aprobación y desarrollo
• Entender la interdependencia entre REQM,
desarrollo de requerimientos (RD) y solución
técnica (TS).
• Entender la naturaleza recursiva de RD, TS y
REQM.

Audiencia del Curso
• Líderes de proyecto
• Analistas
• Área de comercialización
Logística
• Inicio de la sesión: 09:00 am

• Fin de la sesión: 04:00 pm
• Descansos para café
– Mañana: 11:30 am
– Tarde: 01:30 pm

Facilidades
• Salidas de Emergencia
• Baños
• Teléfonos
Técnicas Didácticas
• Presentaciones
• Discusiones
• Trabajo en equipo
• Dinámicas

Reglas Base
• Puntualidad
• Participar
• Preguntar
• Trabajo en equipo
• Mantener los teléfonos
celulares en modo silencioso
(vibración)
• Criticar ideas, nunca a las
personas
Introducción de Participantes
• Nombre
• Puesto
• Experiencia en Administración
de Requerimientos
– Definir el alcance del sistema
– Validar el entendimiento del
problema
– Técnicas de compromiso
– Administración de cambios
– Rastreo del requerimiento
• Expectativas del Curso

Presentación del Instructor
Vilma Escarria Rodríguez

vescarria@esicenter.itesm.mx
• Estudios y Certificaciones
– Ingeniería en Sistemas Computacionales
– Maestría en Ciencias Computacionales
– Diplomados en Administración de Proyectos
– Diversos cursos en modelos CMM y CMMI, UML y
lenguajes
• Experiencia
– Asistente de Investigación
– Profesora de Cátedra
– Líder de Proyecto
– Coordinadora de Desarrollo
– Solution Consultant Manager
– Consultora
• Pasatiempos
– Lectura
– Música
REQM vs. Desarrollo Requerimientos

• Administrar los Requerimientos (REQM)

– Asegurar que los requerimientos son consistentes
con los productos de trabajo desarrollados a lo largo
del ciclo de vida
• Desarrollo de Requerimientos (RD)
– Generar una lista de servicios a ser desarrollados
(cliente)
– Generar una lista de requerimientos de producto
(técnicos)
– Analizar los requerimientos
– Validar ambas listas de requerimientos

Dinámica (10 min.)
• ¿Qué es un requerimiento para tu

empresa?
• ¿Cuántos tipos de requerimientos
tienen?
• ¿Qué características debe tener
un requerimiento válido en la
empresa?
Definición – 1
Requerimiento:
Necesidad del usuario o una característica,
función, estado o atributo de un sistema que
puede ser percibida externamente.
Especificación de requerimientos:
Documento que describe todos los atributos
requeridos por un sistema que pueden ser
apreciados externamente. Describe que va
hacer el sistema externamente sin describir
como lo va hacer internamente.
Definición – 2
Ingeniería de Requerimientos de
Software:
Es la ciencia y disciplina concerniente al
análisis y documentación de requerimientos
de software a través de un proceso iterativo
de definición, análisis, estudios de balance,
elaboración de prototipos y simulación.
[Dorfman y Thayer]
Importancia Requerimientos – 1
• El proyecto no se puede terminar porque no se

terminan los cambios
• El producto debe satisfacer las necesidades del
cliente
• La solución no funciona si el problema no es
entendido
• Los productos se deben hacer una sola vez
• La generación de productos basados en un
pobre entendimiento del problema y cotizados
con base en ese entendimiento conllevan a
pérdidas en el negocio

Importancia Requerimientos – 2
En casi todo proyecto de software que

fracasa por no coincidir con la
funcionalidad ó con los costos
planeados, los requerimientos
inadecuados han jugado un papel
preponderante.
[M. Alford y J. Lawson]
Ingeniería de
Requerimientos
Obtención de Necesidades
Análisis
Especificación
Validación
Administración
Ingeniería de Requerimientos
Entendimiento
Entendimiento
Problema
Problema
(Elicitation)
(Elicitation) Análisis
Análisis
de
de Prototipos
Factibilidad Prototipos
Factibilidad
Análisis
Análisis
ConOps del
del
ConOps Problema
Problema Especificación
Especificación
Documento
Documentode de del
del
Factibilidad Problema
Problema
Factibilidad
Modelos
Modelos Validación
Validación
SRS
SRS
Administración
Administraciónde
deRequerimientos
Requerimientos
Canal de Comunicación
• Definir proveedor válido de

requerimientos
• Definir un responsable en el
caso de múltiples
proveedores
• Definir quien debe aceptar
los requerimientos por el
lado de la empresa de
desarrollo

Dinámica (15 min.)
1. Define los criterios para determinar

proveedores de requerimientos
2. Determina un criterio para definir
un responsable único de mandar
requerimientos cuando existen
múltiples proveedores
3. Determina si el proveedor es el
mismo para pedir requerimientos o
solicitar cambios a requerimientos
Entendimiento del Problema (Elicitation)

Para lograr un correcto entendimiento del problema se

pueden utilizar estas herramientas:
• Entrevistas
• Cuestionarios
• Observación
• Maestro – Alumno
• Prototipos
• Descripción Operacional
– Concepto de Operaciones
– Casos de uso

Entrevista
Objetivo
Enterarse de opiniones y sentimientos acerca del sistema, la
organización y las metas personales.
Ventajas
– Permite conocer en un ambiente controlado a los posibles
usuarios
Desventajas
Las personas no siempre están dispuestas a ser entrevistadas:
– Temen hacer un mal papel o perder poder si revelan lo que
saben
– No se sienten en confianza con el analista (especialmente si es
de otro departamento o ajeno a la empresa)
– Se saltan pasos “básicos” al describir los procesos
Cuestionario
Tipos
Obtener detalles sobre la implementación de actividades.
Ventajas
Se recomienda:
– Cuando la gente se encuentra dispersa
– Cuando hay mucha gente involucrada en el sistema de software
– Para conocer y sensibilizar a los interesados antes de proceder
a las entrevistas.
Desventajas
– El lenguaje utilizado debe ser muy preciso, por lo que se debe
hacer un análisis previo del dominio del problema (círculo
vicioso)
– Se necesita bastante práctica en la elaboración de un buen
cuestionario

Observación
Utilizado para profundizar en lo que realmente se está haciendo,

viendo de primera mano la relación del usuario con la
organización y su medio ambiente físico.
Ventajas
– Revelan detalles que difícilmente se habrían descubierto con
otros métodos.
Desventajas
– A algunos usuarios no les gusta ser observados
– El tiempo necesario para lograr una buena observación es largo
– Es difícil permanecer en calidad de observador
Otras Técnicas
• Maestro – Alumno
Trabajar junto al personal que realiza las tareas para
aprender acerca de la tarea y como se cumple.
• Etnografía
Técnica de observación para entender requerimientos
sociales y organizacionales
• Prototipos
Representación limitada del diseño de un producto que
permite comprender la problemática y clarificar los
requerimientos.

Dualidad del Rol del Analista
Comprensibilidad Formalidad
Diseño y
Codificación
Usuarios Analista Analista
Obtención y Búsqueda de
Necesidades (Elicitation) Administración de Requerimientos
• Entrevistas
• Cuestionarios
• Observación
• Maestro-alumno
• Prototipos
• Descripción operacional
– Concepto de Operaciones
– Casos de Uso

Concepto de
Operaciones
• Documentación de las necesidades
del cliente
• Descripción operacional del
sistema (casos de uso)
Concepto de Operaciones (ConOps)

Describe los resultados del análisis conceptual

– Sistema o situación actual
– Necesidades desarrollo/modificación
– Modos de operación sistema propuesto
– Clases de usuarios y sus características
– Características operacionales (prioridades)
– Escenarios operacionales
– Limitaciones de la aproximación (enfoque)
– Análisis de impacto

Documento ConOps
Documento orientado al usuario que le permite describir

los conceptos de un sistema:
– Ayuda a los usuarios a expresar sus distintos puntos
de vista y expectativas
– Provee una descripción de las necesidades y deseos
del usuario
– Ayuda en general al usuario en su trabajo
Proveer un puente entre las necesidades del usuario

y los requerimientos técnicos (desarrolladores)
Casos de Uso (CU)

• Es un modelo de lo que un sistema debe hacer y de

la interacción con entidades externas
• Elementos principales:
– Actor: elemento externo interactuando con el sistema
– Caso de Uso: servicios proveídos por los actores
– Escenario: secuencia de eventos que captura como el servicio
es llevado a cabo.
Un servicio puede requerir múltiples funciones

e interactuar con múltiples actores

CU: Propósito
Propósito
• Definir el alcance del sistema

– Identificar las interacciones del sistema con
entidades externas
– Identificar los servicios proveídos por el
sistema
• Validar el entendimiento del desarrollador
sobre el sistema
Diagrama de Casos de Uso

Hacer Llamada Local Callee

Caller
Hacer Llamada Larga Dist.

Proveedor Larga Distancia
Cliente Cobrar Cliente Administrador Cobros

¿ Qué es un Actor?
¿Qué
• Los actores no son parte del sistema

• Los actores representan los roles que
puede tomar un usuario
• Un actor puede representar un humano,
dispositivo o sistema
• Un actor puede cambiar activamente
información con el sistema
• Un actor puede proporcionar información
• Un actor puede ser receptor pasivo de
información
Actor
Aceptación de y
Compromiso con los
Requerimientos
Criterios de aceptación
Compromiso interno y externo

Criterios de Aceptación – 1
• Características que debe tener un requerimiento

para ser aceptado en el proyecto
– Completo
– Consistente
– Verificable (se puede asociar una prueba)
– Claro (no ambigüo)
– Técnicamente factible
• Criterio de aceptación del producto por el cliente
• Correcto: si todo requerimiento escrito

representa algo requerido por el sistema a
ser construido.
• No ambigüo: si todo requerimiento escrito
tiene una sola interpretación
– Evita frecuencias, administra operador lógico
• Completo: si la definición de las respuestas
del sistema de todas las posibles clases de
entradas de datos en todas las posibles
clases de situaciones son incluidas

• Verificable: un requerimiento escrito es

verificable si existe algún proceso finito y
costeable con el cual una persona o
máquina pueda confirmar que el software a
ser construido cumpla con el requerimiento.
Ejemplos de requerimientos que no son
verificables son:
– The product shall have an easy-to-use interface.
– The program shall not enter an infinite loop.
– Avoid words such as “usually”, “generally,” or “often”
• Consistente: si ningún requerimiento escrito

está en conflicto con otro previamente
documentado.
– Conflicto de comportamiento: especificar un estímulo
diferente para inducir una respuesta o diferentes
respuestas al mismo estímulo.
– Conflicto de términos: términos usados en diferentes
contextos que significan la misma cosa.
– Conflicto en características: demanda que el producto
exhiba características contradictorias
– Inconsistencia en los tiempos: demanda que el
producto responda con tiempos de respuesta
contradictorios.
Análisis de Factibilidad
• Posibilidad de realización del software con el

hardware y software existentes.
• Estimación del costo contra los beneficios
que el software brindará a la empresa.
• Se realiza después de que se establecieron
las necesidades del sistema.
• Permite tomar la decisión de si es factible
realizar el sistema propuesto
Dinámica (15 min.)

1. ¿Cómo determinas si un requerimiento

es técnicamente factible, que técnicas o
herramientas empleas?
2. ¿Cómo determinas si un requerimiento
esta completo?
3. ¿Cuántos tipos de elementos técnicos
manejas y cuales son sus características
(catálogos, reportes, agentes, robots,
busquedas, pantallas captura, vistas,
archivos, protocolos?

Compromiso a los Requerimientos
• Los requerimientos definen el alcance del sistema

• El equipo de desarrollo debe comprometerse a
desarrollar el sistema descrito por los
requerimientos
• La empresa de desarrollo se compromete con el
cliente a desarrollar el sistema descrito con los
requerimientos
• El equipo de desarrollo debe hacer un análisis de
impacto de los requerimientos antes de
comprometerse a ellos
Técnicas de Análisis de Impacto

• Análisis de factibilidad
• Prototipos técnicos
• Matriz de requerimiento (cambios)
• Simulación

Control de Cambios - Atributos
• Registro del cambio

• Razón de cambio
• Evaluar impacto
– Requerimientos afectados (nuevos, modificados, cancelados)
– Impacto en productos de trabajo
– Esfuerzo/calendario/Costo
• Decisión del cambio
– Registrar decisión y razón de la misma
• Actualizar historial
• Comunicar, planear y proceder al cambio conforme a la
decisión
Dinámica (20 min.)

Define la plantilla para solicitud de

cambios
Tips:
Recomendamos por lo menos tres
secciones: Descripción del cambio;
Análisis; Evaluación/Resultado

Rastreo de
Requerimientos
Rastreo Adelante (Fordward)
Rastreo Atrás (Backward)
Representaciones
Asignación Requerimientos
Requerimientos Derivados
Rastreo de Requerimientos – 1
Capacidad de describir y seguir el

desarrollo de los requerimientos a
través del ciclo del vida del proyecto, en
cualquiera de las siguientes
direcciones:
– Forward
– Backward

Rastreo de Requerimientos – 2
• Forward: Habilidad de rastrear un

requerimiento a través de su especificación y
desarrollo.
• Backward: Habilidad de identificar el o los
requerimientos que originaron un producto de
trabajo.
Rastreo (Traceability)
Lista de Fases /
requerimientos Productos de
Forward Trabajo
1. Backward 1.
2. 2.
3. 3.
4. 4.
… …
n n

Rastreo Bidireccional
F F F
Aná
Análisis B Diseñ
Diseño B Código B Pruebas
F: Forward
B: Backward
Rastreo Vertical – 1
• Identifica el origen y continúa el desarrollo

del requerimiento a través de las diferentes
actividades y productos en el proyecto.

Rastreo Vertical – 2
Aná
Análisis
Modelo de Cascada
Rastreo Vertical *
Diseñ
Diseño
Código
Pruebas
* Entre diferentes fases
Rastreo Horizontal
• Identifica las relaciones entre los

requerimientos para evitar problemas
potenciales antes de la integración del
producto.

Rastreo Requerimientos Relacionados
1.-
2.-
3.-
4.-
Rastreo Previo Definición Requerimientos

Casos de
Uso
Entrevista
ConOps SRS
Observació
Observación
Prototipos

Requerimiento Derivado
Un Requerimiento Derivado es un
requerimiento que no fue pedido explícitamente
por el cliente, pero es necesario para el
sistema.
Aná
Análisis Diseñ
Diseño
RD
RD
RD: Requerimiento Derivado
Asignación (Allocation)
Se refiere a la descomposición de un
requerimiento de alto nivel, en requerimientos
de bajo nivel y su asignación en actividades y
productos de trabajo.
1. Requerimiento padre
1.1 Requerimiento hijo 1

Rastreo Requerimientos Derivados
RD 5.-
5.1 -
5.2 -
Requerimiento que no fue

solicitado explícitamente
por el cliente pero que es
necesario para el sistema
Verificación
Ver Ver Ver
F F F
Aná
Análisis B Diseñ
Diseño B Código B Pruebas

Rastreo Bidireccional en CMMI
Requerimientos F
F Productos F: Forward
Requerimientos Producto
B de Trabajo B: Backward
Derivados Final
Relevantes
B
F B
Ejemplos de Productos de Trabajo
Documentos de Diseñ
Diseño
Actividades Casos de Prueba
en el Plan Código
Matriz de Rastreabilidad - 1
ID Requerimi Fuen- SRS Planea- Dise- Códi Caso Resul- Cam- Comen-
ento te ción ño go de tado de bios tarios
Prue- Pruebas
ba
Req1
Req2
Req3

Dinámica (20 min.)
¿Bosqueja una matriz de rastreo de

requerimientos?
- Identifica los productos de trabajo
- Determina cobertura en ciclo de
vida
- Determina relaciones a ser
consideradas:
Derivados; entre requerimientos;
entre requerimientos y productos.
Dinámica (10 min.)

1. ¿Cuándo se debe hacer el

rastreo?
2. ¿Cuándo debes revisar que se

esta llevando a cabo el rastreo?

Herramientas para el
Rastreo de
Requerimientos
Caliber
Requisite Pro
Enterprise Architect
Caliber Analist, Borland – 1

• Repositorio Centralizado para todos los

proyectos
• Múltiples métodos de visualización de rastreo
• Cubre las áreas de RD y REQM al ayudar a
definir requerimientos y dar seguimiento y
registro de cambios e inconsistencias.

http://www.borland.com/media/en/edm/caliber_analyst_product_demo/main.html


Rational RequisitePro – 1
• Integración con Word para la autoría de

requerimientos.
• Rastreo a alto y bajo nivel.
• Análisis de cambios grafico y notificación de
cambios por correo electrónico a los agentes
involucrados.
• Creación de línea base en XML; permite la
comparación de líneas base entre proyectos.
• Acceso via web.
• Integración con las demás herramientas de Rational


Enterprise Architect – 1
• Soporta diagramas UML

• Generación de documentación y reportes
en formatos personalizados
• Frameworks de distintos lenguajes de
desarrollo como java y .Net
• Dependiendo de la edición soporta MDA

Identificar
Inconsistencias

Identificar Inconsistencias – 1
Revisar inconsistencias entre los

planes, productos de trabajo y los
requerimientos, identificando causa
y razón de las mismas así como las
acciones correctivas necesarias
Identificar Inconsistencias – 2
Requerimientos
F
Productos
B de Trabajo
Requerimientos
Relevantes
Derivados
F: Forward
B: Backward
F B
Ejemplos de Productos de Trabajo
Documentos de Diseñ
Diseño
Casos de Prueba
Actividades Código
en el Plan

Identificar Causa de Inconsistencia
• El trabajo realizado o planeado no incluye

todo lo solicitado
• El trabajo realizado o planeado incluye más
de lo solicitado (gold plating)
• Los cambios hacen inconsistente algún
producto ya liberado
Acciones Correctivas
• Determinar las acciones correctivas necesarias para

resolver las inconsistencias
• Asignar un responsable a cada acción correctiva
• Incluirla en la lista de actividades a monitorear
(actividades del proyecto, agenda para la junta de
estatus, etc.)
• Analizar los resultados de las acciones correctivas
– ¿Se terminó?
– ¿Resolvió el problema?
• Se requiere otra acción correctiva

Dinámica (10 min.)
¿Cuándo realizarías revisiones

por consistencia?
Revisiones por Consistencia (Cuándo)

• Al liberar un producto de trabajo

– Revisiones internas
– Peer Reviews
• Al terminar un cambio

REQM desde la
perspectiva CMMI
Relación entre las Áreas de
Ingeniería
SG 1 Administrar
Requerimientos
Propósito REQM
Manejar los requerimientos de los

productos y componentes del
producto del proyecto
Identificar inconsistencias entre esos
requerimientos y los planes del
proyecto y los productos de trabajo.

REQM Incluye …
• Manejar todos los requerimientos recibidos o

generados por el proyecto, incluyendo técnicos, no
técnicos y aquellos agregados por la organización
• Lograr acuerdos con los clientes con respecto al
significado e intención de los requerimientos
• Lograr compromiso con los requerimientos de los
participantes del proyecto
• Administrar los cambios a requerimientos (internos y
externos) durante el proyecto
• Identificar inconsistencias entre los requerimientos,
los planes de proyecto, y los productos de trabajo
Cuando no hay REQM

• El cliente y el desarrollador tienen

diferentes entendimientos sobre el
conjunto de requerimientos
• El equipo trabaja en proyectos que
técnicamente no cree factibles
• No hay un registro de los cambios y sus
justificaciones
• No se pude garantizar que el código
incluye los requerimientos originales y sus
cambios aprobados
Contexto de REQM – 1
SG1 Administrar Requerimientos

SP 1.1 Obtener Entendimiento Requerimientos
SP 1.2 Obtener Compromiso Requerimientos
SP 1.3 Administrar Cambios Requerimientos
SP 1.4 Mantener Rastreo Bidireccional de
Requerimientos
SP 1.5 Identificar Inconsistencias entre trabajo
del proyecto y los Requerimientos
Contexto de REQM – 2
Obtener Identificar
Inconsistencias
Entendimiento Requerimientos entre los
de los Productos y los
Requerimientos Requerimientos
Obtener
Administrar los Mantener una
Compromiso
Cambios de los Rastreabilidad
con los
Requerimientos Bidireccional
Requerimientos
Rastreabilidad
© SEI, Carnegie Mellon University

Contexto de REQM en CMMI – 1
• RD desarrolla requerimientos de cliente y de

producto validados apoyándose en un
proceso de análisis
• REQM administra las listas de
requerimientos y provee visibilidad del
desarrollo de los requerimientos durante el
ciclo de vida
• REQM, RD y TS se aplican recursivamente
Contexto de REQM en CMMI – 2

Requerimientos
REQM
Requerimientos de
producto y componentes
Alternativas
de solución Componentes
del producto
Producto
RD TS PI Cliente
Requeri-
mientos
Reportes de verificación y validación de
los componentes y productos de trabajo
VER VAL
Necesidades del cliente y usuarios
© SEI, Carnegie Mellon University

SG1: Administrar Requerimientos
Los requerimientos son administrados y las

inconsistencias con los planes de trabajo y
productos de trabajo son identificadas.
SP1.1 Obtener Entendimiento

Requerimientos – 1
Desarrollar un entendimiento con los

proveedores de requerimientos sobre su
significado.

Subprácticas:
– Establecer criterios para distinguir los proveedores
adecuados de requerimientos.
– Establecer criterios objetivos para la evaluación y
aceptación de requerimientos.
– Analizar los requerimientos para asegurar que se
cumple con los criterios establecidos.
– Alcanzar un entendimiento de los requerimientos
con sus proveedores, de tal forma que los
participantes del proyecto se puedan comprometer
con ellos.

Productos de Trabajo:
– Lista de criterios para distinguir los
proveedores apropiados de requerimientos.
– Criterios para la evaluación y aceptación de
los requerimientos.

Entendimiento de los Requerimientos
Llegar a un
Establecer Analizar los
Entendimiento
Criterios para Establecer Criterios Requerimientos
Identificar para la Aceptación conforme a los con los
de Requerimientos Proveedores de
Proveedores de Criterios Requerimientos
Requerimientos
Concepto de
Operaciones
Criterios para Criterios para
Proveedores de Aceptación de Análisis Aceptación
Requerimientos Requerimientos Contrato
SP1.2: Lograr Compromiso con los

Lograr compromiso con los requerimientos por

parte de los participantes del proyecto.

Subprácticas:
– Evaluar el impacto de los requerimientos en
los compromisos existentes.
– Negociar y registrar compromisos.

– Evaluaciones de impacto de los
requerimientos.
– Compromisos documentados con los
requerimientos y cambios en los
requerimientos.

Compromiso con los Requerimientos
SP1.3: Administrar Cambios en

Administrar los cambios a los requerimientos

conforme se desarrollan durante el proyecto.

Subprácticas:
– Documentar todos los requerimientos y cambios a los
requerimientos que sean dados o generados por el
proyecto.
– Mantener un historial de cambio de requerimientos
con su razonamiento para los cambios.
– Evaluar el impacto de los cambios de requerimientos
desde el punto de vista de los agentes relevantes.
– Hacer que los datos de requerimientos y sus cambios
estén disponibles para el proyecto.
Control de Cambios

– Estatus de requerimientos.
– Base de datos de requerimientos.
– Base de datos de decisiones sobre
Requerimientos.
SP1.4: Mantener Rastreo Bidireccional de

los Requerimientos – 1
Mantener rastreo bidireccional entre los

requerimientos y los productos de trabajo.

Subprácticas:
– Mantener rastreo de requerimientos para asegurar
que la fuente de menor nivel (derivada) es
documentada.
– Mantener rastreo de requerimientos desde el
requerimiento hasta su requerimiento derivado y
ubicación en funciones, interfaces, objetos, personas,
procesos y productos de trabajo.
– Generar la matriz de rastreo de requerimientos.

– Matriz de rastreo de requerimientos.
– Sistema de rastreo de requerimientos.

Rastreabilidad
SP 1.5 Identificar Inconsistencias entre

Trabajo del proyecto y Requerimientos – 1
Identificar las inconsistencias entre los planes

de proyecto, los productos de trabajo y los
requerimientos.

Subprácticas:
– Revisar los planes del proyecto, actividades y
productos de trabajo en busca de inconsistencias con
los requerimientos y los cambios hechos a ellos.
– Identificar la fuente de la inconsistencia y su
razonamiento.
– Identificar cambios que necesitan ser realizados a los
planes y productos de trabajo resultantes de cambios
a los requerimientos de la línea base.
– Iniciar acciones correctivas.

Productos de Trabajo
– Documentación de inconsistencias incluyendo
fuentes, condiciones y razonamiento.
– Acciones correctivas.

Identificar Inconsistencias
Prácticas Genéricas
CMMI v 1.2 - REQM

GG 2 Institucionaliza Proceso Administrado
GP 2.1 Establecer una Política Organizacional

GP 2.2 Planear el Proceso
GP 2.3 Proveer Recursos
GP 2.4 Asignar Responsabilidades
GP 2.5 Capacitar al Personal
GP 2.6 Administrar la Configuración
GP 2.7 Identificar e Involucrar a los Agentes
Relevantes
GP 2.8 Monitorear y Controlar el Proceso
GP 2.9 Evaluar Adherencia en forma Objetiva
GP 2.10 Revisar Estatus con Alta Gerencia
GG 3 Institucionaliza Proceso Definido

GP 3.1 Establecer un Proceso Definido

GP 3.2 Recolectar Información para la Mejora

Pre-procesos
Control de cambios
Revisión por consistencia
REQM: Arquitectura de Procesos


REQM: Arquitectura de Procesos
! " #
!
Proceso Análisis
(Entendimiento y Compromiso)
…
Proceso de Control de Cambios

%& ' $
(' !
$
+ ) !
,
('
! $
%
,
(' !
% ) ! ! $
.
!
(' $
! !
) !
$ -
(
!
* + +
!
(' ('
+ ('
( ) !

Resumen
Factores de éxito
Resumen
Factores de Éxito
• Identifica proveedor valido para

requerimientos y peticiones de cambio
• Valida requerimientos con base a criterios de
aceptación
• Identifica e involucra a los agentes que
afectan o son afectados por el nuevo sistema
durante la aceptación de los requerimientos
• Automatiza el registro y rastreo de
requerimientos

Resumen de REQM
• Valida tu entendimiento de los requerimientos con

tus clientes
• Compromete a la gente que participa en el proyecto
con los requerimientos
• Realiza un análisis de impacto antes de aceptar las
peticiones de cambio
• Registra el rastreo de requerimientos a Productos
de Trabajo (PT) predeterminados
• Aplica acciones correctivas cuando se identifiquen
inconsistencias entre PT y requerimientos
¿Comentarios,
Preguntas?

Ing. Vilma C. Escarria Rodríguez

vescarria@esicenter.itesm.mx
http://esicenter.itesm.mx
Muchas Gracias!

Consultoria CMMI REQM 071023 2 Slides

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Consultoria CMMI REQM 071023 2 Slides

Încărcat de

Drepturi de autor:

Formate disponibile

Administración de Requerimientos

La distribución de este material está limitada por el SIECenter de

© SIE Center México, Documento de Carácter Confidencial 1

Misión del SIE Center

Contribuir al desarrollo de la industria,

© SIE Center México, Documento de Carácter Confidencial 2

Propósito del Curso

© SIE Center México, Documento de Carácter Confidencial 4

• Identificar dos tipos de

© SIE Center México, Documento de Carácter Confidencial 5

Objetivos del Curso – 2

• Conocer los tipos de rastreo y sus

© SIE Center México, Documento de Carácter Confidencial 6

© SIE Center México, Documento de Carácter Confidencial 7

• Inicio de la sesión: 09:00 am

© SIE Center México, Documento de Carácter Confidencial 8

© SIE Center México, Documento de Carácter Confidencial 9

© SIE Center México, Documento de Carácter Confidencial 10

© SIE Center México, Documento de Carácter Confidencial 11

© SIE Center México, Documento de Carácter Confidencial 12

Vilma Escarria Rodríguez

REQM vs. Desarrollo Requerimientos

• Administrar los Requerimientos (REQM)

© SIE Center México, Documento de Carácter Confidencial 14

• ¿Qué es un requerimiento para tu

© SIE Center México, Documento de Carácter Confidencial 15

© SIE Center México, Documento de Carácter Confidencial 17

• El proyecto no se puede terminar porque no se

© SIE Center México, Documento de Carácter Confidencial 18

En casi todo proyecto de software que

[M. Alford y J. Lawson]

© SIE Center México, Documento de Carácter Confidencial 19

© SIE Center México, Documento de Carácter Confidencial 21

• Definir proveedor válido de

© SIE Center México, Documento de Carácter Confidencial 22

1. Define los criterios para determinar

© SIE Center México, Documento de Carácter Confidencial 23

Entendimiento del Problema (Elicitation)

Para lograr un correcto entendimiento del problema se

© SIE Center México, Documento de Carácter Confidencial 24

© SIE Center México, Documento de Carácter Confidencial 25

© SIE Center México, Documento de Carácter Confidencial 26

Utilizado para profundizar en lo que realmente se está haciendo,

© SIE Center México, Documento de Carácter Confidencial 27

© SIE Center México, Documento de Carácter Confidencial 28

Usuarios Analista Analista

© SIE Center México, Documento de Carácter Confidencial 29

© SIE Center México, Documento de Carácter Confidencial 30

© SIE Center México, Documento de Carácter Confidencial 31

Concepto de Operaciones (ConOps)

Describe los resultados del análisis conceptual

© SIE Center México, Documento de Carácter Confidencial 32

Documento orientado al usuario que le permite describir

Proveer un puente entre las necesidades del usuario

© SIE Center México, Documento de Carácter Confidencial 33

Casos de Uso (CU)

• Es un modelo de lo que un sistema debe hacer y de

Un servicio puede requerir múltiples funciones

© SIE Center México, Documento de Carácter Confidencial 34

• Definir el alcance del sistema

© SIE Center México, Documento de Carácter Confidencial 35

Diagrama de Casos de Uso

Hacer Llamada Local Callee

Hacer Llamada Larga Dist.