Presentación

Nombre y Apellidos:
Josias Matos Batista

Matricula:
FN7105

Tema:
Informe unidad III

Maestro:
Noemi Cuevas Sánchez

Materia:
Ingeniería de Software I

Fecha:
24/03/2022
 Índice
Enumerar las metas específicas y genéricas de CMMI...............................................1
Metas específicas...................................................................................................1
Metas genéricas......................................................................................................1
Metas genéricas y sus procesos............................................................................1
Enumerar las prácticas específicas y genéricas de CMMI..........................................2
Prácticas específicas..............................................................................................2
Prácticas específicas..............................................................................................2
Prácticas genéricas................................................................................................3
Defina todas las áreas de proceso de CMMI................................................................3
Áreas de proceso en CMMI....................................................................................3
Análisis causal y resolución (CAR).........................................................................3
Gestión de configuración (CM)...............................................................................3
Análisis de decisiones y resolución (DAR).............................................................4
Gestión integrada del proyecto + IPPD (IPM + IPPD)............................................4
Medición y análisis (MA).........................................................................................4
Innovación y despliegue en la organización (OID).................................................4
Definición de procesos de la organización + IPPD (OPD + IPPD)........................4
Enfoque en procesos de la organización (OPF)....................................................4
Rendimiento del proceso de la organización (OPP)..............................................5
Formación organizativa (OT)..................................................................................5
Integración de producto (PI)...................................................................................5
Monitorización y control del proyecto (PMC)..........................................................5
Planificación de proyecto (PP)................................................................................5
Aseguramiento de la calidad de proceso y de producto (PPQA)...........................5
Gestión cuantitativa de proyecto (QPM).................................................................6
Desarrollo de requerimientos (RD).........................................................................6
Gestión de requerimientos (REQM).......................................................................6
Gestión de riesgos (RSKM)....................................................................................6
Gestión de acuerdos con proveedores (SAM).......................................................6
Solución técnica (TS)..............................................................................................7
Validación (VAL).....................................................................................................7
Verificación (VER)...................................................................................................7
Hablar del estándar IEEE 1074-2006..............................................................................7
Hablar del estándar IEEE/EIA 12207..............................................................................8
Historia....................................................................................................................9
Versiones IEEE.......................................................................................................9
Procesos, no etapas.............................................................................................10
 Enumerar las metas específicas y genéricas de CMMI

Metas específicas

Una meta específica describe las características únicas que deben estar presentes
para satisfacer el área de proceso. Una meta específica es un componente requerido
del modelo que se utiliza en las evaluaciones para ayudar a determinar si se satisface
un área de proceso. Por ejemplo, una meta específica del área de proceso Gestión de
configuración es “Se establece y se mantiene la integridad de las líneas base”.
Solamente es un componente requerido del modelo la declaración de meta específica.
El título de una meta específica (precedido por el número del objetivo) y todas la/ O tas
asociadas a la meta se consideran componentes informativos del modelo.

 SG 1 Determinar las causas de los defectos.

 SG 2 Abordar las Causas de los defectos.
 SG 3 Establecer líneas.
 SG 4 Seguimiento y Control de Cambios.
 SG 5 Establecer integridad.

Metas genéricas

Las metas genéricas se denominan “genéricas” porque la misma declaración de la

meta se aplica a múltiples áreas de proceso. Una meta genérica describe las
características que deben estar presentes para institucionalizar los procesos que
implementan un área de proceso. Una meta genérica es un componente requerido del
modelo y se utilize en las evaluaciones para determinar si se satisface un área de
proceso.
Un ejemplo de una meta genérica es “El proceso se institucionaliza como un proceso
definido”. Solamente es un componente requerido del modelo la declaración de meta
genérica. El título de una meta genérica precedido por el número del objetivo) y todas
las notas asociadas a la meta se consideran componentes informativos del modelo.

Metas genéricas y sus procesos

 GG1: lograr objetivos específicos.

 GG 2: institucionalizar un proceso gestionado.
 GG 3: institucionalizar un proceso definido.
 GG 3: institucionalizar un proceso definido.

1|Page
  GG 4: institucionalizar un proceso administrado cuantitativamente.
 GG 5: institucionalizar un proceso en fase de optimización.

Enumerar las prácticas específicas y genéricas de CMMI

Prácticas específicas

Una práctica específica es la descripción de una actividad que se considera importante

para alcanzar la meta específica asociada. Las prácticas específicas describen las
actividades que se espera que produzcan la consecución de las metas específicas de
un área de proceso. Una práctica específica es un componente esperado del modelo.
Un ejemplo de una práctica específica del área de proceso de Monitorización y control
de proyecto es Monitorizar los compromises contraídos frente a los identificados en el
plan del proyecto”. Solamente es un componente esperado del modelo la declaración
de la práctica específica. El título de la práctica específica (precedido por el número de
la práctica) y todas las notas asociadas con la práctica específica se consideran
componentes informativos del modelo.

Prácticas específicas

 SG 1 Determinar las causas de los defectos

o SP 1.1 Seleccionar Defecto Datos para el Análisis
o SP 1.2 analizar las causas
 SG 2 Abordar las Causas de los defectos
o SP 2.1 aplicar las propuestas de acción
o SP 2.2 Evaluar el efecto de los cambios
o SP 2.3 Datos de registro
 SG 1 Establecer líneas
o SP 1.1 Identificación de los elementos de configuración
o SP 1.2 Establecer un Sistema de Gestión de la configuración
o SP 1.3 Crear o liberación líneas
 SG 2 Seguimiento y Control de Cambios
o SP 2.1 Seguimiento de las peticiones de cambio
o SP 2.2 Control Elementos de configuración
 SG 3 Establecer integridad
o SP 3.1 Establecer registros de gestión de configuración
o SP 3.2 realizar auditorías de configuración

2|Page
Prácticas genéricas

Las prácticas genéricas se denominan “genéricas” porque la misma práctica se aplica a

múltiples áreas de proceso. Una práctica genérica es la descripción de una actividad
que se considera importante para el logro de la meta genérica asociada. Una práctica
genérica es un componente esperado del modelo.
Por ejemplo, una práctica genérica de la meta genérica “El proceso se institucionaliza
como un proceso gestionado” es “Proporcionar recursos adecuados para llevar a cabo
el proceso, para desarrollar los productos de trabajo y para proporcionar los servicios
del proceso”.

Defina todas las áreas de proceso de CMMI

Áreas de proceso en CMMI

Un área de proceso es un conjunto de prácticas relacionadas que cuando son

implementadas colectivamente, satisfacen un conjunto objetivos considerados
importantes para mejorar esa área de proceso. Las áreas de proceso del modelo CMMI
son 22.
Cada una de ellas es implementada para alcanzar el nivel de madurez correspondiente
y se agrupan de acuerdo a cuatro categorías: Administración de Procesos,
Administración de Proyectos, Ingeniería y Soporte. Este agrupamiento es realizado
para mostrar cómo se relaciona cada área de proceso dentro de una categoría. Sin
embargo, áreas de procesos de distintas categorías pueden encontrarse relacionadas,
pero dado que en este documento se desarrollarán sólo áreas de procesos de una
misma categoría (Ingeniería) estas relaciones se desprecian.
Las 22 áreas de proceso se presentan aquí por orden alfabético de sus acrónimos en
inglés.

Análisis causal y resolución (CAR)

Tiene como propósito identificar las causas de los resultados seleccionados y tomar
acción para mejorar la realización del proceso.

Gestión de configuración (CM)

Es una disciplina de ingeniería reconocida que proporciona procesos y tecnologías

para identificar y controlar los elementos en el sistema para asegurar la integridad y la
calidad del producto durante su desarrollo.

3|Page
Análisis de decisiones y resolución (DAR)

Tiene como propósito analizar las posibles decisiones utilizando un proceso de

evaluación formal que evalúa alternativas identificadas contra los criterios establecidos.

Gestión integrada del proyecto + IPPD (IPM + IPPD)

Tiene como propósito establecer y gestionar el proyecto y la participación de los

interesados de acuerdo con un proceso integrado y definido que se adapta a partir del
conjunto de procesos estándar de la organización.

Medición y análisis (MA)

Tiene como propósito desarrollar y apoyar la capacidad de medición utilizada para

poder dar soporte a las necesidades de información de la gerencia.

Innovación y despliegue en la organización (OID)

El área de proceso de Organizational Innovation and Deployment (OID) corresponde al

nivel 5 en la representación por etapas y está ubicada dentro de la categoría de
proceso de Gestión de procesos para la representación continua. Tiene como propósito
seleccionar y desplegar mejoras incrementales e innovadoras que mejoren de forma
medible los procesos y las tecnologías de la organización. Estas mejoras apoyan los
objetivos de calidad y de desempeño del proceso de la organización derivados de los
objetivos estratégicos de la organización.

Definición de procesos de la organización + IPPD (OPD + IPPD)

El área de proceso de Organizational Process Definition (OPD) corresponde al nivel 3

en la representación por etapas y está ubicada dentro de la categoría de proceso de
Gestión de procesos para la representación continua. Tiene como propósito establecer
y mantener un conjunto útil de activos de proceso de la organización y de estándares
del entorno de trabajo.

Enfoque en procesos de la organización (OPF)

El área de proceso de Organizational Process Focus (OPF) corresponde al nivel 3 en la

representación por etapas y está ubicada dentro de la categoría de proceso de Gestión
de procesos para la representación continua. Tiene como propósito planificar,
implementar y desplegar las mejoras de procesos de la organización, basadas en el

4|Page
entendimiento de las fortalezas y debilidades actuales de los procesos y de los activos
de proceso de la organización.

Rendimiento del proceso de la organización (OPP)

Tiene como propósito establecer y mantener una comprensión cuantitativa del

rendimiento del conjunto de procesos estándar de la organización en apoyo de los
objetivos de calidad y de rendimiento de procesos, y proporcionar datos, líneas base y
modelos de rendimiento de los procesos para gestionar cuantitativamente los proyectos
de la organización.

Formación organizativa (OT)

Tiene como propósito desarrollar las habilidades y el conocimiento de las personas

para que puedan realizar sus roles eficaz y eficientemente.

Integración de producto (PI)

Tiene como propósito ensamblar el producto a partir de sus componentes, asegurar

que el producto, una vez integrado, funciona correctamente (ej. posee la funcionalidad
requerida y los atributos de calidad), y entregar el producto.

Monitorización y control del proyecto (PMC)

Tiene como propósito proporcionar una comprensión del progreso del proyecto para
que se puedan tomar las acciones correctivas apropiadas, cuando el rendimiento del
proyecto se desvíe significativamente del plan. Las prácticas definidas en esta área de
proceso, en conjunto con las de PP, permiten llevar a cabo una adecuada gestión del
proyecto que es la base del proceso gestionado. Ambas áreas de proceso están
estrechamente ligadas en el sentido que PP establece y actualiza los planes de
proyecto que son gestionados y controlados en PMC.

Planificación de proyecto (PP)

El área de proceso de Project Planning (PP) corresponde al nivel 2 en la

representación por etapas y está ubicada dentro de la categoría de proceso de Gestión
de proyectos para la representación continua. Tiene como propósito establecer y
mantener planes que definan las actividades del proyecto.

Aseguramiento de la calidad de proceso y de producto (PPQA)

El área de proceso de Process and Product Quality Assurance (PPQA) corresponde al

nivel 2 en la representación por etapas y está ubicada dentro de la categoría de

5|Page
proceso de Soporte para la representación continua. Tiene como propósito
proporcionar al personal y a la gerencia una visión objetiva de los procesos y de los
productos de trabajo asociados.

Gestión cuantitativa de proyecto (QPM)

El área de proceso de Quantitative Project Management (QPM) corresponde al nivel 4

en la representación por etapas y está ubicada dentro de la categoría de proceso de
Gestión de proyectos para la representación continua. Tiene como propósito gestionar
cuantitativamente el proyecto para alcanzar los objetivos establecidos de calidad y de
rendimiento del proceso del proyecto.

Desarrollo de requerimientos (RD)

El área de proceso de Requirements Development (RD) corresponde al nivel 3 en la

representación por etapas y está ubicada dentro de la categoría de proceso de
Ingeniería para la representación continua. Tiene como propósito producir y analizar los
requisitos del cliente, del producto y de los componentes del producto.

Gestión de requerimientos (REQM)

El área de proceso de Requirements Management (REQM) corresponde al nivel 2 en la

representación por etapas y está ubicada dentro de la categoría de proceso de Gestión
de proyectos para la representación continua. Tiene como propósito gestionar los
requisitos de los productos y de los componentes del producto del proyecto, e
identificar inconsistencias entre esos requisitos y los planes y productos de trabajo del
proyecto.

Gestión de riesgos (RSKM)

El área de proceso de Risk Management (RSKM) corresponde al nivel 3 en la

representación por etapas y está ubicada dentro de la categoría de proceso de Gestión
de proyectos para la representación continua. Tiene como propósito identificar los
problemas potenciales antes de que ocurran para que las actividades de gestión de
riesgos puedan ser planificadas y utilizadas según sea necesario a lo largo de la vida
del producto o del proyecto para mitigar los impactos adversos para alcanzar los
objetivos.

6|Page
Gestión de acuerdos con proveedores (SAM)

El área de proceso de Supplier Agreement Management (SAM) corresponde al nivel 2

en la representación por etapas y está ubicada dentro de la categoría de proceso de
Gestión de proyectos para la representación continua. Tiene como propósito gestionar
la adquisición de productos y servicios del proveedor.

Solución técnica (TS)

El área de proceso de Technical Solution (TS) corresponde al nivel 3 en la

representación por etapas y está ubicada dentro de la categoría de proceso de
Ingeniería para la representación continua. Tiene como propósito diseñar, desarrollar e
implementar soluciones para los requerimientos. Las soluciones, los diseños y las
implementaciones engloban productos, componentes de producto y procesos del ciclo
de vida asociados al producto, de manera individual o en combinación, según sea
apropiado.

Validación (VAL)

El área de proceso de Validation (VAL) corresponde al nivel 3 en la representación por

etapas y está ubicada dentro de la categoría de proceso de Ingeniería para la
representación continua. Tiene como propósito demostrar que un producto o
componente de producto se ajusta a su uso previsto cuando se sitúa en su entorno
previsto.

Verificación (VER)

El área de proceso de Verification (VER) corresponde al nivel 3 en la representación

por etapas y está ubicada dentro de la categoría de proceso de Ingeniería para la
representación continua. Tiene como propósito asegurar que los productos de trabajo
seleccionados cumplen sus requerimientos especificados.

Hablar del estándar IEEE 1074-2006

El estándar IEEE 1074 proporciona el conjunto

de actividades que constituyen los procesos
que son obligatorios para el desarrollo y
mantenimiento de software. Se encuentra
organizado en 17 procesos, que comprenden

7|Page
un total de 65 actividades. Los procesos se dividen en cuatro secciones lógicas o
grupos de procesos.
El primer grupo está compuesto por el Proceso de Modelo del Ciclo de Vida del
Software que proporciona actividades que se necesitan para identificar los modelos de
ciclo de vida software candidatos y para seleccionar aquel modelo que se vaya a
utilizar en el proyecto.
El segundo grupo está conformado por el Proceso de Gestión del Proyecto, que
propone un conjunto de procesos de iniciación, supervisión y control del proyecto a lo
largo de ciclo de vida del software.
El tercer grupo está compuesto por los procesos Orientados al Desarrollo, los Procesos
de Pre-Desarrollo, los Procesos de Desarrollo y los Procesos de PostDesarrollo del
software.
El último grupo está compuesto por los Procesos Integrales, son aquellos procesos que
se necesitan para completar con éxito las actividades de un proyecto.
El proceso de implantación está tratado en el proceso de instalación del grupo de
procesos post-desarrollo perteneciente al grupo de Procesos orientados al Desarrollo.
Este proceso implica el transporte y la instalación de un sistema software desde el
entorno de desarrollo al entorno de destino.
Las actividades del proceso de instalación propuestas en el estándar son: la
distribución del software, la instalación del software, la carga de la base de datos (si el
proyecto lo requiere), la aceptación del software en el entorno de operación, la
realización de las actualizaciones y finalmente la instalación del software probado.
Los Procesos Integrales que articulan con el proceso de implantación son los procesos
de verificación y validación, de gestión de configuración, de desarrollo de la
documentación y de formación.
Los Procesos de Gestión del Proyecto relacionados al proceso de implantación son: el
proceso de iniciación del proyecto, el proceso de supervisión y control del proyecto y el
proceso de gestión de la calidad.

Hablar del estándar IEEE/EIA 12207

ISO / IEC / IEEE 12207 Ingeniería de software y sistemas: los procesos del ciclo de
vida del software es un estándar internacional para los procesos del ciclo de vida del
software. Introducido por primera vez en 1995, tiene como objetivo ser un estándar

8|Page
primario que define todos los procesos necesarios para desarrollar y mantener
sistemas de software incluidos los resultados y / o actividades de cada proceso.

Historia

ISO / IEC / IEEE 12207: 2017 es la versión más reciente, publicada en noviembre de
2017. La IEEE Computer Society se unió directamente a la Organización Internacional
de Normalización (ISO) en el proceso de edición de esta versión. Un cambio
significativo es que adopta un modelo de proceso idéntico al modelo de proceso ISO /
IEC / IEEE 15288: 2015 (hay un cambio de nombre, el proceso 15288 "Definición de
requisitos del sistema" se renombra al proceso "Definición de requisitos del sistema /
software"). Esta armonización de las dos normas dio lugar a la eliminación de procesos
separados de desarrollo y reutilización de software, lo que redujo el número total de
12207 procesos de 43 a los 30 procesos definidos en 15288. También provocó
cambios en las actividades de los procesos de gestión y aseguramiento de la calidad y
resultados. Además, se actualizó la definición de " auditoría " y las actividades de
auditoría relacionadas. El Anexo I de ISO / IEC / IEEE 12207: 2017 proporciona un
mapeo de procesos entre la versión 2017 y la versión anterior, incluidas las
alineaciones de procesos primarios entre las dos versiones; esto está destinado a
permitir la trazabilidad y facilitar la transición para los usuarios de la versión anterior.

Versiones IEEE

Antes de que la IEEE Computer Society se uniera formalmente al proceso de edición

(convirtiéndose en una de las principales partes interesadas) para la versión de 2017,
IEEE mantuvo sus propias versiones de ISO / IEC 12207, inicialmente con
modificaciones realizadas conjuntamente con Electronic Industries Alliance (EIA) Con la
actualización de 2008 llegó una "estrategia compartida de ISO / IEC JTC 1 / SC 7 y el
IEEE para armonizar sus respectivas colecciones de normas", lo que resultó en normas
idénticas, pero con nombres ligeramente diferentes. Esas versiones de IEEE incluyen:

 IEEE Std. 12207-2008: "integra ISO / IEC 12207: 1995 con sus dos enmiendas y
se coordinó con la revisión paralela de ISO / IEC 15288: 2002 (procesos del ciclo
de vida del sistema) para alinear la estructura, los términos y los procesos
organizativos y de proyecto correspondientes"; reemplazado por ISO / IEC /
IEEE 12207: 2017

9|Page
  IEEE / EIA 12207.2-1997: "proporciona una guía de consideración de
implementación para las cláusulas normativas de IEEE / EIA 12207.0";
reemplazado / hecho obsoleto por IEEE Std. 12207-2008, que luego fue
reemplazada por ISO / IEC / IEEE 12207: 2017
 IEEE / EIA 12207.1-1997: "proporciona una guía para registrar los datos del ciclo
de vida que resultan de los procesos del ciclo de vida de IEEE / EIA 12207.0";
reemplazado por ISO / IEC / IEEE 15289: 2011, que luego fue reemplazado por
ISO / IEC / IEEE 15289: 2017
 IEEE / EIA 12207.0-1996: "consta de las aclaraciones, adiciones y cambios [a
ISO / IEC 12207: 1995 para la implementación de la industria] aceptados por el
Instituto de Ingenieros Eléctricos y Electrónicos (IEEE) y la Alianza de Industrias
Electrónicas (EIA) como formulado por un proyecto conjunto de las dos
organizaciones "; reemplazado por IEEE Std. 12207-2008, que luego fue
reemplazada por ISO / IEC / IEEE 12207: 2017.

Procesos, no etapas

El estándar establece un conjunto de procesos para administrar el ciclo de vida del

software. El estándar "no prescribe un modelo de ciclo de vida de software, una
metodología de desarrollo, un método, un enfoque de modelado o una técnica
específicos ". En cambio, el estándar (así como ISO / IEC / IEEE 15288) distingue entre
una "etapa" y un "proceso" de la siguiente manera:

 etapa: "período dentro del ciclo de vida de una entidad que se relaciona con el
estado de su descripción o realización". Una etapa es típicamente un período de
tiempo y termina con una "puerta de decisión primaria".
 proceso: "conjunto de actividades interrelacionadas o interactuantes que
transforma las entradas en salidas". El mismo proceso a menudo se repite en
diferentes etapas.
Las etapas (también conocidas como fases) no son lo mismo que los procesos, y este
estándar solo define procesos específicos, no define ninguna etapa en particular. En
cambio, el estándar reconoce que los ciclos de vida del software varían y pueden
dividirse en etapas (también llamadas fases) que representan los principales períodos
del ciclo de vida y dan lugar a puertas de decisión primarias. Ningún conjunto de etapas
en particular es normativo, pero menciona dos ejemplos:

 Se podrían usar las etapas del ciclo de vida del sistema de ISO / IEC TS 24748-
1 (concepto, desarrollo, producción, utilización, soporte y retiro).
 También señala que un conjunto común de etapas para el software es la
exploración, el desarrollo, el mantenimiento y la retirada de conceptos.

10 | P a g e
Los procesos del ciclo de vida que define el estándar no están alineados con ninguna
etapa específica del ciclo de vida del software. De hecho, los procesos del ciclo de vida
que implican la planificación, el desempeño y la evaluación "deben considerarse para
su uso en todas las etapas". En la práctica, los procesos ocurren siempre que se
necesitan dentro de cualquier etapa.

11 | P a g e