Está en la página 1de 15

HOJA DE PRESENTACIÓN

❖ Nombre: Waldo Ramírez Amonte


❖ Matricula: 100372179
❖ Materia: Ingeniería del Software
❖ Profesor: José M. Amado P
❖ Trabajo: Informe unidad 3
❖ Teléfono: waldomix002@gmail.com
❖ Correo: 8294911332
Índice

1. ………………………Introducción
2. ………………………Enumeración Metas específicas y genéricas de CMMI
3. ……………………… Enumeración Prácticas específicas y genéricas de CMMI
4. ………………………Definición Áreas de proceso de CMMI
5. ………………………Estándar IEEE 1074-2006
6. ………………………Estándar IEEE/EIA 12207
7. ………………………Conclusión
8. ………………………Bibliografía
Introducción

En el presente trabajo de investigación trata sobre, las


Metas, Áreas y estándares que se encuentran en la
sección del modelo CMMI, enumerándolas y definiendo lo
más importante para adquirir conocimientos en su uso,
tanto en lo personal como en las organizaciones por estar
relacionad en la ingeniería de software, empleando
correctamente su sistema en otra organización para no
adquirir fallas y disminuir riesgos a las múltiples
evaluaciones.
ENUMERACIÓN METAS ESPECÍFICAS (SG) Y GENÉRICAS(GG) DE CMMI

Metas específicas (SG)

1. Gestionar Requisitos: Los requisitos son gestionados y las inconsistencias con el


plan de proyecto y los productos de trabajo identificadas.
2. Establecer estimadores: Se establecen una serie de estimadores de parámetros
de proyecto que se mantendrán a lo largo de la vida del proyecto.
3. Desarrollar plan de proyecto: Se establece un plan de proyecto como base para la
gestión del proyecto
4. Obtener compromisos con el plan de proyecto: Los compromisos con el proyecto
son establecidos y mantenidos durante el ciclo de vida del proyecto
5. Monitorizar el proyecto contra su plan: Se monitoriza y compara el progreso y el
desempeño del proyecto real y se compara contra el plan inicial
6. Gestionar acciones correctivas: Las acciones correctivas son gestionadas hasta ser
completadas cuando el proyecto o sus resultados se desvían significativamente
del plan trazado
7. Preparar la gestión de riesgos: Preparación para llevar a cabo la gestión de
riesgos
8. Identificar y analizar riesgos: Los riesgos son identificados y analizados para
determinar su importancia
9. Mitigar riesgos: Los riesgos son abordados y mitigados de forma apropiada para
reducir impactos adversos y lograr alcanzar los objetivos
10.Establecer acuerdos con proveedores: Se establecen y mantienen acuerdos con
proveedores
11.Satisfacer los acuerdos con proveedores: Los acuerdos con proveedores deber ser
satisfechos por ambas partes, el proveedor y quien ejecuta el proyecto
12.Establecer líneas base: Las líneas base de los productos de trabajo son
establecidas.
13.Control de cambios de configuración: Los productos de trabajo bajo gestión de
configuración son seguidos y controlados.
14.Mitigar riesgos: La integridad de las líneas base es establecida y mantenida.
15.Establecer acuerdos con proveedores: Se establecen y mantienen acuerdos con
proveedores
16.Satisfacer los acuerdos con proveedores: Los acuerdos con proveedores deber ser
satisfechos por ambas partes, el proveedor y quien ejecuta el proyecto

Metas Genéricas (GG)

1. Lograr objetivos específicos


2. Institucionalizar un proceso gestionado
3. Institucionalizar un proceso definido

ENUMERACIÓN PRÁCTICAS ESPECÍFICAS (SP) Y GENÉRICAS(GP) DE CMMI

Prácticas específicas (SP)

1. Comprender los requisitos


2. Obtener compromisos para los requisitos
3. Gestionar los cambios de requisitos
a. 4. Mantener una trazabilidad bidireccional o de los
requisitos
5. Asegurar alineamiento entre el trabajo del proyecto y
los requisitos

6. Estimar el alcance del proyecto


7. Establecer una estimación del trabajo y las tareas a
b. realizar
8. Definir las fases del ciclo de vida del proyecto
9. Estimar los costes
10.Establecer el calendario y los costes del proyecto
11.Identificar los riesgos
c. 12.Planificar la gestión de datos
13.Planificar los recursos del proyecto
14.Planificar las habilidades y conocimientos
necesarios
15.Planificar la participación de los involucrados

16.Revisar los planes que puedan afectar al proyecto


d. 17.Poner de acuerdo el trabajo y los recursos
compartidos
18. Obtener compromiso de acuerdo para el plan de
proyecto

19.Monitorizar los parámetros del proyecto o trabajo


20.Monitorizar los compromisos
21. Monitorizar riesgos
e. 22.Monitorizar gestión datos
23.Monitorizar la participación de los involucrados
24.Llevar a cabo revisiones del progreso
25. Llevar a cabo revisiones de hitos

26.Analizar problemas
f. 27.Llevar a cabo medidas correctivas
28.Gestionar las medidas correctivas

29.Determinar las categoría y fuentes de riesgo


g. 30.Definir parámetros de riesgo
31. Establecer una estrategia de gestión de riesgo

h. 32.Identificar riesgos
33.Evaluar, categorizar y priorizar riesgos

34.Desarrollar un plan de mitigación de riesgos


i.
35.Implementar el plan de mitigación de riesgo
36.Establecer el tipo de adquisición
j. 37.Seleccionar los proveedores
38. Establecer acuerdos con proveedores

39.Ejecutar el acuerdo con proveedores


k. 40.Aceptar el producto adquirido
41.Asegurar la transacción de productos

42.Identificar los elementos de configuración


l. 43.Establecer y mantener un sistema de gestión de
configuración
44.Crear o liberar las líneas base

45.Seguir las peticiones de cambio para los elementos


m. de configuración
46.Controlar los cambios a los elementos de
configuración

47.Establecer y mantener los registros que describen


los elementos de configuración
n.
48.Realizar auditorías de configuración para mantener
la integridad de las líneas base de configuración

49.Establecer el tipo de adquisición


o. 50.Seleccionar los proveedores
51.Establecer acuerdos con proveedores

52.Ejecutar el acuerdo con proveedores


p. 53. Aceptar el producto adquirido
54. Asegurar la transacción de productos
Prácticas genéricas (GP)

a. 1. Llevar a cabo practicas específicas

2. Establecer una política Organizativa


3. Planificar el proceso
4. Facilitar recursos
5. Asignar responsabilidades
b. 6. Dar formación
7. Controlar los productos de trabajo
8. Identificar e involucrar a todos los afectados
9. Monitorizar y controlar el proceso
10.Evaluar la adhesión objetivamente
11.Revisar el estado con niveles de gestión superior

c. 12.Establecer un proceso definido


13.Recopilar experiencias del proceso relacionadas

ÁREAS DE PROCESO DE CMMI

En los tres modelos CMMI (CMMI-DEV, CMMI-ACQ y CMMI-SVC) existen un total de


16 áreas de procesos centrales o Core procesos áreas comunes:

Causal Analysis and Resolution (CAR) Tiene como propósito identificar las causas de los
resultados seleccionados y tomar acción para mejorar la realización del proceso.
Configuration Management (CM) Tiene como propósito establecer y mantener la
integridad de los productos de trabajo utilizando la identificación de la configuración,
el control de configuración, el registro del estado de configuración y las auditorías de
configuración.
Decision Analysis and Resolution (DAR) Tiene como propósito analizar las posibles
decisiones utilizando un proceso de evaluación formal que evalúa alternativas
idénticas contra los criterios establecidos. Una evaluación formal de procesos reduce
la subjetividad de las decisiones y conduce a una mayor probabilidad de seleccionar
la solución más apropiada para el mayor número de involucrados en el proyecto.

Integrated Project Management (IPM) El propósito de IPM es establecer y gestionar el


proyecto y la involucración de todos los participantes relevantes dentro de un
proceso integrado y venido ajustado al conjunto de procesos estándares de la
organización.

Measurement and Analysis (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. Los directores tienen siempre la necesidad de contar con
herramientas de medición que les permitan tomar decisiones en función del estado
actual.
Organizational Process Definition (OPD) El propósito de OPD es establecer y mantener
un conjunto de ventajas del proceso organizacional y estándares de ambiente de
trabajo.
Organizational Process Focus (OPF) Tiene como propósito planificar, implementar y
desplegar las mejoras de procesos de la organización, basadas en el entendimiento
de las fortalezas y debilidades actuales de los procesos y de los activos de proceso de
la organización.
Organizational Performance Management (OPM) El propósito de OPM es gestionar de
manera proactiva el desempeño de la organización para alcanzar los objetivos de
negocio. OPM analiza iterativamente información agregada de diversas fuentes con
el fin de encontrar diferencias significativas entre el rendimiento observado y los
objetivos de negocio.
Organizational Process Performance (OPP) Tiene como propósito establecer y mantener
una comprensión cuantitativa del rendimiento de los procesos seleccionados del
conjunto de procesos estándar de la organización en apoyo al logro 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
Organizational Training (OT) El propósito de OT es el de desarrollar habilidades y
conocimiento en el personal de manera que puedan llevar a cabo sus tareas de
forma más eficaz y eficiente.
Project Monitoring and Control (PMC) El propósito de la monitorización y control es
dotar un conocimiento acerca del progreso del proyecto de tal forma que se puedan
tomar acciones correctivas en caso de que el proyecto se desvíe significativamente
del plan inicial.
Project Planning (PP) El propósito de PP es “establecer y mantener planes que definan
las actividades del proyecto”. Incluye el desarrollo del plan de proyecto, identificar e
involucrar a todos los afectados relevantes por el proyecto (stakeholders), obtener
compromiso para llevar a cabo dicho plan, y mantener el plan actualizado cuando
este se vea modificado por cambios en los requisitos.
Process and Product Quality Assurance (PPQA) El propósito del Aseguramiento de la
Calidad de Proceso y Producto es proporcionar a los diferentes equipos y a la
gerencia una visión objetiva de los procesos y productos asociados.
Quantitative Project Management (QPM) Tiene como propósito gestionar
cuantitativamente el proyecto para alcanzar los objetivos establecidos de calidad y
de rendimiento del proceso del proyecto.
Requirements Management (REQM) El propósito de la gestión de requisitos es
identificar, asignar y hacer seguimiento de los requisitos necesarios para satisfacer
los objetivos del proyecto.
Risk Management (RSKM) El objetivo de la gestión de requisitos es identificar
problemas potenciales antes de que lleguen a producirse de forma que se puedan
planear acciones y actividades que minimicen o palien estos riesgos.

En CMMI-DEV existen además 5 áreas de procesos específicas:

Product Integration (PI) El propósito de PI es armar el producto a partir de los


componentes del producto, asegurar que el producto armado se comporta
adecuadamente y entregar el producto.
Requirements Development (RD) El propósito de RD es obtener, analizar y establecer
requisitos de cliente, producto o de componentes de producto.
Technical Solution (TS) El propósito de TS es seleccionar, diseñar e implementar
soluciones a los requisitos.
Validation (VAL) El propósito de la VAL es demostrar que el producto o los
componentes del producto cumplen con las intenciones de uso cuando se sitúan en
su entorno de uso.
Verification (VER) El propósito de VER es asegurar que el proyecto o producto cumple
con sus especificaciones.
En CMMI-SVC además de la citada área de procesos compartida con
CMMI-DEV existen otras 6 áreas de procesos específicas más otra
adicional:

Capacity and Availability Management (CAM) El propósito es garantizar el rendimiento


eficaz del sistema de servicio y garantizar que los recursos se proporcionen y utilicen
de manera eficaz para respaldar los requisitos del servicio .
Incident Resolution and Prevention (IRP) El propósito es garantizar la resolución
oportuna y eficaz de los incidentes de servicio y la prevención de incidentes de
servicio según corresponda
Service Continuity (SCON) El propósito es establecer y mantener planes para asegurar
la continuidad de los servicios durante y después de cualquier interrupción
significativa de las operaciones normales.
Service Delivery (SD) El propósito es brindar servicios de acuerdo con los acuerdos de
servicio.
Service System Development (SSD) El propósito es analizar, diseñar, desarrollar,
integrar, verificar y validar sistemas de servicio, incluidos los componentes del
sistema de servicio, para satisfacer los acuerdos de servicio existentes o anticipados.
Service System Transition (SST) El propósito es implementar componentes del sistema
de servicio nuevos o significativamente modificados mientras se gestiona su efecto
en la prestación de servicios en curso.
Strategic Service Management (STSM) El propósito es establecer y mantener servicios
estándar de acuerdo con las necesidades y planes estratégicos.

Por último, en CMMI-ACQ existen 6 áreas específicas:

Acquisition Requirements Development (ARD) El propósito es obtener, desarrollar y


analizar los requisitos contractuales y de los clientes.
Solicitation and Supplier Agreement Development (SSAD) El propósito es preparar un
paquete de solicitud, seleccionar uno o más proveedores para entregar el producto o
servicio y establecer y mantener el acuerdo con el proveedor.
Agreement Management (AM) El propósito es garantizar que el proveedor y el
adquirente se desempeñen de acuerdo con los términos del acuerdo con el
proveedor.
Acquisition Technical Management (ATM) El propósito es evaluar la solución técnica del
proveedor y gestionar las interfaces seleccionadas de esa solución.
Acquisition Verification (AVER) El propósito garantizar que los productos de trabajo
seleccionados cumplan con los requisitos especificados.
Acquisition Validation (AVAL) El propósito es demostrar que un producto o servicio
adquirido cumple con su uso previsto cuando se coloca en su entorno previsto.

ESTÁNDAR IEEE 1074-2006


El estándar IEEE 1074-2006, es la última versión del estándar definido por The
Institute of Electrical and Electronics Engineers IEEE, el cual está orientado a permitir
establecer un proceso para la administración y mantenimiento de proyectos de
desarrollo de software. El estándar le permite al usuario, luego de escoger el Modelo
del Ciclo de Vida del Proyecto de Software, el cual va a aplicar en su proyecto y que
debe estar de acuerdo a la misión, visión, metas y recursos de la organización,
establecer una serie de actividades que se deben realizar durante la ejecución del
desarrollo, el resultado de escoger el modelo y determinar las actividades a realizar
dentro del Ciclo de Vida es el Proceso del Ciclo de Vida del Proyecto de Software.
De igual forma el estándar claramente indica que no pretende definir un Ciclo de
Vida del Proyecto de Software (SPLC), ni tampoco definir un modelo SPLCM
especifico, básicamente está orientado a servir de guía en la lista de actividades que
se deben contemplar. Sin embargo, si se puede utilizar para desarrollar un proceso
organizacional que soporte el desarrollo y mantenimiento de proyectos de software.
El estándar define actividades que están orientadas a cada una de las etapas del ciclo
de vida de los proyectos de software incluyendo desde su concepción, desarrollo
hasta su retiro o el momento en el que se da de baja al software. La 33 forma en la
que está concebido el estándar le da mucha flexibilidad en su aplicación, ya que las
actividades cubren una amplia gama de condiciones y el usuario determina cuales de
ellas debe incluir en cada una de las etapas del Ciclo de Vida del Proyecto de
Software (SPLC).

En 1995, se realizó la primera revisión de la versión original que se realizó en 1991,


durante esta revisión solamente se corrigieron algunos pequeños errores
encontrados.

• En 1997 se dieron los siguientes cambios:

1. Las actividades se reordenaron dentro de grupos lógicos los cuales son


llamados grupos de actividades.
2. El termino Grupo de Actividades entro a reemplazar el termino Proceso
3. Se incluyo la actividad denominada Administración del Riesgo
4. Luego de determinar que el software puede ser adquirido en el extranjero,
fue necesario incluir el Grupo de Actividades Importación de Software. 7

• La última revisión se realizó en el 2006 y se incluyeron los siguientes cambios:

1. El foco del estándar se centró en un proceso particular de un proyecto


determinado.
2. Se incluyeron actividades para la Administración de versiones
3. Por el amplio crecimiento de las necesidades de la seguridad del
software se definieron dos actividades nuevas: Determinar Objetivos de
Seguridad y Confirmar la Acreditación de la Seguridad.

ESTÁNDAR IEEE/EIA 12207

Está formado por algunas variantes La primera describe los procesos del que
la adopten, deberán especificar de manera los ciclos de vida del software con
sus actividades y detallando cómo implementar la norma para usar tareas,

la segunda describe la forma de manera adecuada. administrando los datos


obtenidos a lo largo de los procesos del ciclo de vida del software y la normas
que incluye un anexo denominado Proceso a tercero que contiene las
consideraciones de Adaptación, que permite a los interesados implementarlo
al estándar, que es una guía para usarla.

Este estándar Establece un marco común para el software a través de su ciclo


de vida, desde la concepción hasta el retiro del mismo, de tal manera que
Enfoca los procesos del software desde el punto de vista técnico del sistema y
desde el punto de vista comercial de la empresa. Otro detalle se considera
ampliamente como base para el comercio mundial de software.
Conclusión

Para concluir con lo investigado se comprende la


base en la que se dan a conocer el modelo de
Madurez de Capacidad Integrado (CMMI) polo que
cada Área tienen un propósito propio en la que
detalla su labor con fundamento, aunque en los
estándares muestra datos relacionados dando un
marco de información dada su fecha en la que se
crea y cambios que se dio.
Bibliografía

• http://www.javier8a.com/itc/bd1/ld-
Ingenieria.de.software.enfoque.practico.7ed.Pressman.PDF

• https://biblioteca.utb.edu.co/notas/tesis/0040360.pdf

• https://www.amazon.com/Guidebook-IEEE-EIA-12207-
Information/dp/0971989508

También podría gustarte