CMMI (modelos de madurez de capacidades/ Capability Maturity Model Integration)
Es un modelo para la mejora y evaluación de procesos para el desarrollo, mantenimiento y
operación de sistemas de software.
La importancia del uso de un modelo radica principalmente en el hecho de que es
precisamente lo que permite comprender cuáles son los elementos específicos de
una organización, a la vez que ayuda a formular y hablar de qué es lo que se debe
mejorar dentro de la misma y de cómo se pueden lograr dichas mejoras. Dicho esto,
algunas de las ventajas del uso de un modelo que valen la pena mencionar son las
siguientes:
• Proporciona un marco y un lenguaje común, lo que se traduce en la ruptura
de las barreras de la comunicación en el interior de las organizaciones.
• Permite que los usuarios puedan enfocarse específicamente en la mejora, ya
que ayudan a que no pierdan la idea global.
• Aporta años de experiencia.
• Ayudan a mejorar la satisfacción del cliente.
• Permiten producir productos y servicios de alta calidad.
El propósito de un modelo CMMI varía según el enfoque, es decir, si buscamos en
los libros de texto encontraremos que el propósito de este modelo es hacer la
evaluación de la madurez de los procesos de una organización, para así poder
proporcionar una orientación referente a cómo se pueden llevar a cabo las mejoras
de aquellos procesos que darán lugar a mejores productos.
Por otra parte, si hablamos con personas del Software Engineering Institute, lo más
seguro es que nos digan que CMMI es modelo para la administración de riesgos y
que a su vez indica la capacidad que tiene una determinada organización para
administrar esos riesgos. Esta indicación es precisamente el indicio de la
probabilidad con la que una organización puede cumplir con sus promesas o brindar
productos de alta calidad que resulten atractivos para el mercado.
Adicionalmente a estos dos, existe otro enfoque en el cual se dice que el modelo
proporciona un buen indicador sobre el cómo una organización actuará ante
determinadas situaciones de estrés. Una organización que cuente con una gran
madurez, así como con altas capacidades, de seguro afrontará las situaciones
inesperadas y de estrés con calma, lo que sin duda les permitirá reaccionar, hacer
cambios y seguir adelante.
Por el contrario, una organización con poca madurez y bajas capacidades de seguro
tenderá a dejarse llevar por el pánico ante situaciones de estrés, seguirá a ciegas
aquellos procesos obviados, o bien, arruinará todos los procesos y volverá al caos.
GESTION DE REQUISITOS
El propósito de la Gestión de requisitos es gestionar los requisitos de los productos y
componentes del producto del proyecto también para identificar inconsistencias entre esos
requisitos y los planes del proyecto.
Los procesos de gestión de requisitos gestionan todos los requisitos recibidos o generado por el
proyecto, incluidos los requisitos técnicos y no técnicos, así como los requisitos impuestos en
el proyecto de la organización. En particular, si los requisitos se implementan al área de proceso
de desarrollo, sus procesos generarán requisitos de productos y componentes de productos que
también se gestionarán por los procesos de gestión de requisitos. Cuando los requisitos Gestión,
desarrollo de requisitos y solución técnica están implementadas en todas las áreas, sus procesos
asociados pueden ser estrechamente atado y se realiza simultáneamente.
Parte de la gestión de los requisitos es :
• Documentar los requisitos.
• Cambios y justificación y mantener la trazabilidad bidireccional entre requisitos de
origen y todos los productos y requisitos de los componentes del producto
SG1 Administrar requisitos
• Se gestionan los requisitos y las inconsistencias con los planes y el trabajo del
proyecto.
• los productos se identifican
El proyecto mantiene un conjunto de requisitos actual y aprobado sobre la vida del proyecto
haciendo lo siguiente:
• Gestionar todos los cambios a los requisitos.
• Mantener las relaciones entre los requisitos, el proyecto, planes y productos de trabajo
• Identificar inconsistencias entre los requisitos, el proyecto, planes y productos de
trabajo
• Tomar medidas correctivas
Consulte el área de proceso de Monitoreo y control de proyectos para obtener más información.
información sobre cómo tomar medidas correctivas.
PARA INGENIERÍA DE SOFTWARE
Los requisitos pueden ser un subconjunto del producto general requisitos, o pueden constituir
un requisito para el producto completo.
PARA INGENIERÍA DE SISTEMAS
Cada nivel de diseño de componentes del producto (por ejemplo, segmento,subsistema)
recibe los requisitos del nivel superior.
SP 1.1 Obtenga una comprensión de los requisitos
Desarrollar un entendimiento con los proveedores de requisitos en el significado de los
requisitos.
A medida que el proyecto madura y se derivan los requisitos, todas las actividades o las
disciplinas recibirán requisitos. Para evitar que los requisitos se arrastren, se establecen
criterios para designar canales apropiados u oficiales fuentes, de las cuales recibir requisitos.
Las actividades receptoras realizan análisis de los requisitos con el proveedor de requisitos
para asegurar que se llegue a un entendimiento compartido compatible significado de los
requisitos. El resultado de este análisis y diálogo es un conjunto de requisitos acordado.
Productos de trabajo típicos
1. Listas de criterios para distinguir los requisitos apropiados proveedores
2. Criterios de evaluación y aceptación de requisitos.
3. Resultados de análisis contra criterios
4. Un conjunto de requisitos acordado
Subprácticas
1) Establecer criterios para distinguir los requisitos apropiados provistos.
2) Establecer criterios objetivos para la aceptación de los requisitos.
La falta de criterios de aceptación a menudo da como resultado una verificación inadecuada,
retrabajo costoso, o rechazo del cliente.
Los ejemplos de criterios de aceptación incluyen los siguientes:
· Clara y correctamente indicado
· Completo
· Consistentes entre sí
· Identificado de forma única
· Apropiado para implementar
· Verificable (comprobable)
· Trazable
3) Analizar los requisitos para garantizar que los criterios establecidos satisfagan las
necesidades del cliente.
4) Comprender los requisitos provistos para que los participantes del proyecto puedan
comprometerse con ellos.
SP 1.2 Obtener compromiso con los requisitos
Obtener compromiso de los participantes con los requisitos del proyecto.
Mientras que la práctica específica anterior trataba de alcanzar una comprensión con los
proveedores de requisitos, esta práctica específica trata acuerdos y compromisos entre quienes
tienen que llevar a cabo las actividades necesarias para implementar los requisitos. Los
requisitos evolucionan a lo largo del proyecto, especialmente según lo descrito por las prácticas
específicas del área de proceso de Desarrollo de Requisitos y el área de proceso de Solución
técnica. A medida que evolucionan los requisitos, esta práctica específica garantiza que los
participantes del proyecto se comprometan con requisitos actuales aprobados y los cambios
resultantes en el proyecto planes, actividades y productos de trabajo.
Productos de trabajo típicos
• Evaluaciones de impacto de requisitos
• Compromisos documentados con los requisitos y los cambios de los requisitos.
Subprácticas
1. Evaluar el impacto de los requisitos en los compromisos existentes.
El impacto en los participantes del proyecto debe evaluarse cuando los requisitos
cambian o al comienzo de un nuevo requisito.
2. Negociar y registrar compromisos.
Los cambios a los compromisos existentes deben negociarse antes los participantes del proyecto
y comprometerse con el requisito o cambio de requisito.
SP 1.3 Administrar cambios de requisitos
Administre cambios en los requisitos a medida que evolucionan durante el proyecto.
Durante el proyecto, los requisitos cambian por una variedad de razones. Como necesita
cambios y a medida que avanza el trabajo, los requisitos adicionales son derivados y los cambios
pueden tener que hacerse a los existentes requisitos .
Es esencial gestionar estas adiciones y cambios. Eficiente y efectivamente. Para analizar de
manera efectiva el impacto de los cambios, es necesario que se conozca la fuente de cada
requisito y se documenta la justificación de cualquier cambio. El gerente del proyecto Sin
embargo, es posible que desee realizar un seguimiento de las medidas apropiadas de los
requisitos volatilidad para juzgar si son necesarios controles nuevos o revisados.
Productos de trabajo típicos
1) Estado de los requisitos
2) Base de datos de requisitos
3) Base de datos de decisiones sobre requisitos
Subprácticas
1) Capture todos los requisitos y cambios de requisitos que se dan hacia o generado por el
proyecto.
2) Mantener el historial de cambios de requisitos con la justificación de cambios
3) Mantener el historial de cambios ayuda a rastrear la volatilidad de los requisitos.
4) Evaluar el impacto de los cambios de requisitos desde el punto de vista de
partes interesadas relevantes.
5) Ponga los requisitos y cambie los datos a disposición del proyecto.
SP 1.4 Mantener la trazabilidad bidireccional de los requisitos
Mantener la trazabilidad bidireccional entre los requisitos y los planes de proyecto y
productos de trabajo.
La intención de esta práctica específica es mantener la bidireccional trazabilidad de los requisitos
para cada nivel de descomposición del producto. Cuando los requisitos se manejan bien, la
trazabilidad puede ser establecido desde el requisito de origen hasta sus requisitos de nivel
inferior y desde los requisitos de nivel inferior hasta su fuente. Tal la trazabilidad bidireccional
ayuda a determinar que todos los requisitos de origen se han abordado por completo y que
todos los requisitos de nivel inferior se pueden rastrear a una fuente válida. La trazabilidad de
los requisitos también puede cubrir las relaciones con otras entidades como intermedias y
finales productos de trabajo, cambios en la documentación de diseño, planes de prueba y
trabajo de las Tareas. La trazabilidad debe cubrir tanto la horizontal como la vertical. relaciones,
como a través de interfaces. La trazabilidad es particularmente necesario para realizar la
evaluación de impacto de los cambios en los requisitos en los planes del proyecto, actividades y
productos de trabajo.
Productos de trabajo típicos
1. Matriz de trazabilidad de requisitos
2. Sistema de seguimiento de requisitos
Subprácticas
1. Mantener la trazabilidad de los requisitos para garantizar que la fuente de los requisitos
de nivel inferior (derivados) están documentados.
2. Mantener la trazabilidad de los requisitos desde un requisito hasta su derivado
requisitos, así como a su asignación de funciones, objetos, personas, procesos y
productos de trabajo.
3. Mantener la trazabilidad horizontal de una función a otra y a través de interfaces
4. Generar la matriz de trazabilidad de requisitos.
SP 1.5 Identificar inconsistencias entre el trabajo del proyecto y los requisitos
Identificar inconsistencias entre los planes del proyecto y el trabajo.
productos y los requisitos.
Esta práctica específica encuentra las inconsistencias entre requisitos y los planes del proyecto
y productos de trabajo e inicia la acción correctiva para arreglarlos.
Productos de trabajo típicos
1. Documentación de inconsistencias incluyendo fuentes, condiciones, y justificación.
2. Acciones correctivas
Subprácticas
1. Revise los planes, actividades y productos de trabajo del proyecto para coherencia con
los requisitos y los cambios realizados a ellos.
2. Identifique la fuente de la inconsistencia y la justificación.
3. Identificar los cambios que deben realizarse en los planes y el trabajo. productos
resultantes de cambios en la línea de base de requisitos.
4. Iniciar acciones correctivas
GG2 Institutionalize a Managed Process
El proceso se institucionaliza como un proceso gestionado.
• GP 2.1 (CO 1) Establecer una política organizacional
Establecer y mantener una política organizacional para la planificación y
realizando el proceso de gestión de requisitos.
Elaboración:
Esta política establece las expectativas organizacionales para administrar requisitos e
identificación de inconsistencias entre los requisitos y los planes del proyecto y
productos de trabajo.
• GP 2.2 (AB 1) Planifique el proceso
Establecer y mantener el plan para cumplir los requisitos. Proceso de gestión
Elaboración:
Normalmente, este plan para realizar la gestión de requisitos el proceso es parte del
plan del proyecto como se describe en la Planificación del proyecto área de proceso.
• GP 2.3 (AB 2) Proporcionar recursos
Proporcionar recursos adecuados para cumplir los requisitos. proceso de gestión,
desarrollo de productos de trabajo, y proporcionando los servicios del proceso.
Elaboración:
Los ejemplos de recursos proporcionados incluyen las siguientes herramientas:
· Herramientas de seguimiento de requisitos
· Herramientas de trazabilidad
• GP 2.4 (AB 3) Asignar responsabilidad
Asignar responsabilidad y autoridad para realizar el proceso, desarrollando los
productos de trabajo y brindando los servicios de proceso de gestión de requisitos
• GP 2.5 (AB 4) Entrenar personas
Capacitar a las personas que realizan o respaldan los requisitos proceso de gestión
según sea necesario.
Elaboración:
Los ejemplos de temas de capacitación incluyen los siguientes:
· Dominio de la aplicación
· Definición de requisitos, análisis, revisión y gestión.
· Herramientas de gestión de requisitos.
· Gestión de la configuración
· Negociación y resolución de conflictos.
• GP 2.6 (DI 1) Administrar configuraciones
Colocar productos de trabajo designados de la gestión de requisitos. proceso bajo
niveles apropiados de gestión de la configuración.
Elaboración:
· Los ejemplos de productos de trabajo ubicados bajo la administración de la
configuración incluyen lo siguiente:
· Requisitos
· Requerimientos de trazabilidad matriz
• GP 2.7 (DI 2) Identificar e involucrar a las partes interesadas
relevantes
Identificar e involucrar a las partes interesadas relevantes de los requisitos.
proceso de gestión según lo previsto.
Elaboración:
· Seleccione partes interesadas relevantes de clientes, usuarios finales,
desarrolladores, productores, probadores, proveedores, comercializadores,
mantenedores, eliminación personal y otras personas que pueden verse
afectadas o pueden afectar producto así como el proceso.
Los ejemplos de actividades para la participación de los interesados incluyen:
· Resolver problemas sobre la comprensión de los requisitos.
· Evaluar el impacto de los cambios en los requisitos.
· Comunicar la trazabilidad bidireccional.
· Identificar inconsistencias entre planes de proyecto, productos de trabajo y
requisitos.
• GP 2.8 ((DI 3) Monitorear y controlar el proceso
· Monitorear y controlar el proceso de gestión de requisitos.
contra el plan para realizar el proceso y tomar acción correctiva
Elaboración:
Los ejemplos de medidas utilizadas en el monitoreo y control incluyen los
siguientes:
· Volatilidad de los requisitos (porcentaje de requisitos modificados)
• GP 2.9 (VE 1) Evaluar objetivamente la adherencia
Elaboración:
Los ejemplos de actividades revisadas incluyen lo siguiente:
· Requisitos de gestión
· Identificar inconsistencias entre planes de proyecto, productos de trabajo y
requisitos.
Los ejemplos de productos de trabajo revisados incluyen los siguientes:
· Requisitos
· Requerimientos de trazabilidad matriz
• GP 2.10 (VE 2) Estado de revisión con gestión de nivel superior
· Revisar las actividades, el estado y los resultados de los requisitos.
· proceso de gestión con gestión y resolución de nivel superior cuestiones.
Elaboración:
Cambios propuestos a los compromisos que se harán externos a la
organización se revisa con la gerencia de nivel superior para garantizar todos
los compromisos pueden cumplirse.
(El siguiente objetivo no es obligatorio y no se esperan sus prácticas para
una calificación de nivel de madurez 2, pero son necesarios para una
calificación de nivel de madurez 3 y superior).
• GP 3.1 Establecer un proceso definido
Establecer y mantener la descripción de requisitos definidos.
proceso de gestión.
• GP 3.2 Recopilar información de mejora
Recolecte productos de trabajo, medidas, resultados de mediciones y
información de mejora derivada de la planificación y ejecución El
proceso de gestión de requisitos para apoyar el uso futuro y mejora de
los procesos y procesos de la organización bienes.
