Administración de Requisitos

Un área clave de proceso para el nivel 2: Repetible
El propósito de la administración de requisitos es establecer un entendimiento común entre el cliente y
el proyecto de software, acerca de los requisitos del cliente que serán abordados por el proyecto de
software.

La administración de requisitos involucra establecer y mantener un acuerdo con el cliente sobre los
requisitos para el proyecto de software. Este acuerdo es llamado como "los requisitos de sistema
asignados al software". El "cliente" puede ser interpretado como el grupo de ingeniería de sistemas, el
grupo de marketing, otra organización interna, o un cliente externo. El acuerdo cubre requisitos técnicos
y no técnicos (por ejemplo: fechas de entrega). El acuerdo forma la base para estimar, planificar,
ejecutar y seguir las actividades del proyecto de software a través del ciclo de vida del software.

La asignación de los requisitos de sistema al software, hardware, y otras componentes del sistema (por
ejemplo: humanas) puede ser ejecutada por un grupo externo al grupo de ingeniería de software (por
ejemplo: el grupo de ingeniería de sistemas), y además el grupo de ingeniería de software puede no
tener control directo sobre esta asignación. Dentro de las restricciones del proyecto, el grupo de
ingeniería de software toma las acciones necesarias para asegurar que los requisitos de sistema
asignados al software -por los que son responsables de abordar- estén documentados y controlados.

Para lograr este control, el grupo de ingeniería de software revisa los requisitos de sistema asignados al
software tanto los iniciales como los revisados, para resolver problemas antes que sean incorporados
en el proyecto de software. Toda vez que se cambian los requisitos de sistema asignados al software,
se ajustan los planes de software afectados, productos intermedios, y actividades para permanecer
consistentes con los requisitos realizados.

http://pragma.com.ar | CMM N2 - 1

Administración de Requisitos

Nivel 2: Repetible

Metas
Meta 1

Los requisitos del sistema asignados al software son controlados para establecer
una línea base para uso en Administración e ingeniería de software.

Meta 2

Los planes, productos y actividades de software son mantenidos consistentes
con los requisitos de sistema asignados al software.

Compromisos para desarrollar
Compromiso 1

EI proyecto sigue una política organizacional escrita, para la administración
de los requisitos del sistema asignados al software.
Los requisitos del sistema asignados al software, se refiere a los requisitos asignados en esas
practicas
Los requisitos asignados al software son el sub conjunto de los requisitos del sistema que
están para ser implementados por las componentes de software del sistema Los requisitos
asignados son la entrada primaria para el plan de desarrollo de software. El análisis de
requisitos de software elabora y refina los requisitos asignados 10 que produce requisitos de
software que están documentados

Esta política típicamente especifica que:
1.
2.

Los requisitos de software son documentados.
Los requisitos de software son revisados por 105 administradores del
proyecto y otros grupos afectados
q los administradores de software, y
q otros grupos afectados
Ejemplos de grupos afectados incluyen

pruebas de sistema,
ingeniería de software (incluyendo todos los sub-grupos, tales como diseño de software),
ingeniería de sistemas, garantía de calidad de software,
administración de configuraciones de software, y

soporte de documentación.



http://pragma.com.ar | CMM N2 - 2

Nivel 2: Repetible

Administración de Requisitos
Los planes y actividades son cambiados, cada vez que hay un cambio de
requisitos.

Habilidades para desarrollar
Habilidad 1

Para cada proyecto, se establece la responsabilidad de analizar los
requisitos del sistema y asociarlos al hardware, software y otros
componentes del sistema.
EI análisis y la asignación de los requisitos del sistema no son responsabilidades del grupo
de ingeniería de software, pero si son pre-requisitos para su trabajo.

Esta responsabilidad cubre:
1. Administrar y documentar los requisitos del sistema y su asignación a través
de la vida del proyecto.
2. Efectuar cambios a los requisitos del sistema y su asignación.
Habilidad 2

Los requisitos asignados son documentados.
Los requisitos asignados incluyen.
1.

Los requisitos no técnicos que afectan y determinan las actividades del
proyecto de software (ejemplo, acuerdos, condiciones, y términos
contractuales).
Ejemplos de acuerdos, condiciones y términos contractuales incluyen:

productos a ser entregados,

fechas de entrega, y
metas

2.

Requisitos técnicos del software,
Ejemplos de técnicos incluyen:

funciones del usuario final, operador, soporte o integración,

requisitos de desempeño,
restricciones de diseño,
lenguaje de programación, y
requisitos de interfaz



http://pragma.com.ar | CMM N2 - 3

Administración de Requisitos
3.
Habilidad 3

Nivel 2: Repetible

Los criterios de aceptación que serán usados para validar que el producto
entregado satisfaga los requisitos

Se proporcionan los recursos y el financiamiento necesarios para la
administración de los requisitos asignados.
1.

Aquellas personas que tienen experiencia y tienen experiencia en el dominio
de aplicación y en ingeniería de software son asignados para administrar los
requisitos

2.

Herramientas de apoyo a la administración de requisitos como planillas de
calculo, herramientas de administración de configuración, etc.
Ejemplos de herramientas de soporte incluyen:

programas de planilla de calculo,
herramientas para administración de configuraciones,
herramientas para trazabilidad. y

herramientas para administración de las pruebas


Habilidad 4

Los miembros del grupo de ingeniería de software y de otros grupos
relacionados, son entrenados para realizar sus actividades de
administración de requisitos.
Ejemplos de áreas de capacitación son:

Métodos, estándares, y procedimientos usados por el proyecto, y
el dominio de aplicación

Actividades a realizar
Actividad 1

EI grupo de ingeniería de software revisa los requisitos antes de que sean
incorporados al proyecto.
1.

Se identifican requisitos faltantes o incompletos

2.

Los requisitos asignados son revisados para determinar si son:

3.

q

factibles y apropiados para ser implementados en software,

q

clara y apropiadamente establecidos,

q

consistentes un os con otros, y

q

validadles

Cualquier requisito asignado identificado como con problemas potenciales,
es revisado con el grupo responsable por analizar y asignar los requisitos de
sistema, y se hacen los cambios necesarios

http://pragma.com.ar | CMM N2 - 4

Nivel 2: Repetible

Administración de Requisitos
4.

Los compromisos resultantes de la asignación de requisitos son revisados y
negociados con los grupos afectados.
Ejemplos grupos afectos incluyen:







ingeniería de software (incluyendo todos los sub-grupos. tales como diseño de software),
estimación de software,
ingeniería de sistema,
pruebas de sistema,
garantía de calidad de software,
Administración de configuraciones de software,
Administración de subcontratos, y
soporte de documentación

Refiérase a la actividad ó del área clave de proceso de Panificación del Proyecto de
Software para practicas que cubren la negociación de acuerdos.

Actividad 2

EI grupo de ingeniería de software usa los requisitos asignados como la
base para establecer los planes, productos y actividades de software.
Los requisitos asignados:

1.

Son administrados y controlados.
"Administrados y controlados" implica que la versión del producto de trabajo en uso en un
momento dado (pasado o presente) es conocida (es decir "control de versión"), y los cambios
son incorporados de manera controlada (es decir "control de cambios")
Si se desease un mayor grado de formalidad que el implicado por "administrado y
controlado", el producto de trabajo puede ser puesto bajo la disciplina completa de
administración de configuraciones, tal como es descrito en el área clave de proceso
Administración de Configuraciones de Software

Actividad 3

2.

Son la base para desarrollar los planes del proyecto de software.

3.

Son la base para desarrollar los requisitos de software.

Los cambios a los requisitos asignados son revisados e incorporados en el
proyecto de software.
1.

EI impacto en los compromisos existentes es evaluado, y los cambios son
negociados según sea apropiado.
q

Cambios a acuerdos hechos a individuos y grupos externos a la
organización, son revisados con administración superior

http://pragma.com.ar | CMM N2 - 5

q documentados. q evaluados. 2. Cambios en actividades asociadas a los requisitos Numero total de cambios a los requisitos asignados.com. y Total de cambios propuestos. 7 Y 8 del área clave de proceso Supervisión y Control del Proyecto de Software para ver practicas que cubren la negociación de cambios a acuerdos. productos y actividades. cambios aprobados y cambios incorporados a la línea base del sistema http://pragma. q comunicados a los grupos e individuos afectados. Refiérase a las actividades 5. Algunas de estas mediciones son: – – – – Estado de cada uno de los requisitos identificados. para ver practicas que cubren los compromisos hechos externos a la organización q Cambios a acuerdos internos a la organización son negociados con los grupos afectados.Administración de Requisitos Nivel 2: Repetible Refiérase a la actividad 4 del área clave de proceso Planificación del Proyecto de Software y la actividad 3 del área clave de proceso Supervisión y Control del Proyecto de Software. 6. y q seguidos hasta su finalización Medición y Análisis Medición 1 Se hacen mediciones y son usadas para determinar el estado de las actividades de administración de requisitos. q evaluados en riesgo. producto de cambios en los requisitos asignados son: q identificados.ar | CMM N2 .6 . Los cambios que se deben hacer en los planes. q planificados.

tanto como estén disponibles mecanismos adecuados de informe de excepciones. 2. Los requisitos son revisados. esas revisiones y/o auditorias verifican que: 1.com. cuando los requisitos asignados cambian. Se auditan los cambios en los compromisos negociados producto de los cambios en los requisitos.Nivel 2: Repetible Administración de Requisitos Verificación de la Implementación Verificación 1 Las actividades para administrar los requisitos asignados son revisadas periódicamente con la administración superior. EI propósito fundamental de las revisiones de la administración superior es proveer conciencia de y visión de las actividades del proceso de software. Refiérase a la verificación 1 del área clave de proceso Supervisión y Control del Proyecto de Software para practicas cubriendo el contenido típico de revisiones de seguimiento de la administración superior Verificación 2 Las actividades para administrar los requisitos asignados son revisadas con el jefe del proyecto en forma periódica y como respuesta a eventos. productos y actividades. 3. Refiérase a la verificación 2 del área clave de proceso Supervisión y Control del Proyecto de Software para practicas cubriendo el contenido típico de revisiones de seguimiento de la administración del proyecto Verificación 3 EI grupo de garantía de calidad revisa y/o audita las actividades de administración de requisitos e informa los resultados. Se deben revisar apropiadamente los planes. Como mínimo. y los problemas son resueltos antes de que el equipo de ingenieros se comprometa a su realización. EI tiempo entre revisiones debe estar de acuerdo a las necesidades de la organización y pueden ser distanciados. con un adecuado nivel de abstracción y en forma oportuna.ar | CMM N2 . http://pragma.7 .

Al iterar estos pasos puede ser necesario crear el plan para el proyecto de software (es decir.com. El proceso de Planificación del Proyecto de Software incluye pasos para estimar el tamaño de los productos y recursos requeridos.8 . http://pragma. producir la programación. establecer los acuerdos necesarios.Planificación del Proyecto de Software Un área clave de proceso para el nivel 2: Repetible El propósito de la Planificación del Proyecto de Software es establecer planes razonables para realizar las tareas de ingeniería de software y administración del proyecto de software. La Planificación del Proyecto de Software involucra desarrollar estimaciones para el trabajo a ejecutar. y definir el plan para desarrollar el trabajo. identificar y evaluar los riesgos de software y negociar compromisos. el plan de desarrollo de software).ar | CMM N2 . restricciones. y capacidades del proyecto de software. La planificación de software comienza con una orden de trabajo a ser ejecutada y otras restricciones y metas que definen y acotan el proyecto de software (aquellas establecidas por las practicas del área clave de proceso de Administración de Requisitos). Este plan proporciona las bases para ejecutar y administrar las actividades del proyecto y considera los acuerdos con el cliente del proyecto de software de acuerdo a los recursos.

3.Planificación del Proyecto de Software Nivel 2: Repetible Metas Meta 1 Las estimaciones de software son documentadas para ser usadas en la planificación y seguimiento del proyecto de software. Meta 3 Los grupos y personas involucradas aprueban sus compromisos relacionados al proyecto de software.ar | CMM N2 . Esta política típicamente especifica que: 1. Meta 2 Las actividades y los compromisos del proyecto de software son planificados y documentados. Los compromisos del proyecto de software se negocian entre: q el administrador del proyecto. Compromisos para desarrollar Compromiso 1 Se designa un administrador del proyecto de software para ser responsable por la negociación de compromisos y ejecutar el plan de desarrollo del proyecto de software.com. y – pruebas de sistema – http://pragma. q el administrador del proyecto de software. Ejemplos de otros grupos de ingeniería incluyen: – ingeniería de sistemas ingeniería de hardware.9 . Los requisitos de sistema asignados al software deben ser usados como las bases para la planificación del proyecto de software Refiérase a la actividad 2 del área clave de proceso Administración de Requisitos 2. y q los otros administradores de software La participación de otros grupos de ingeniería en las actividades de desarrollo de software debe ser negociada con fichas grupos y luego documentada. Compromiso 2 EI proyecto sigue una política organizacional de planificación del proyecto de software.

EI uso de la terminología "desarrollo" no pretende excluir los proyectos de mantenimiento o soporte de s oftware. EI plan de desarrollo de software del proyecto es administrado y controlado EI termino "plan de desarrollo de software" es usado a través de esas practicas para referirse al plan global para administrar el proyecto de software.10 . estimación de software. tal como es descrito en el área clave de proceso Administración de Configuraciones de Software http://pragma. "Administrado y controlado" implica que la versión del producto de trabajo en uso en un momento dado (pasado o presente) es conocida (es decir "control de versión). 6. y q otros acuerdos. y soporte de documentación 5. tales como diseñó de software).ar | CMM N2 . Los grupos involucrados revisan del proyecto de software: q las estimaciones de tamaño del software.Nivel 2: Repetible Planificación del Proyecto de Software 4. administración de contrato. administración de configuraciones de software. Ejemplos de grupos afectados incluyen: – – – – – – – – ingeniería de software (incluyendo todos los sub-grupos. garantía de calidad de software.com. el producto de trabajo puede ser puesto bajo la disciplina completa de administración de configuraciones. q las estimaciones de esfuerzo y costo. pruebas de sistema. La administración superior revisa todos los compromisos hechos con individuos o grupos externos a la organización. y debe ser apropiadamente interpretada en el contexto de cada proyecto. ingeniería de sistema. q la programación. y los cambios son incorporados de manera controlada (es decir "control de cambios") Si se desease un mayor grado de formalidad que el implicado por "Administrado y controlado".

Ejemplos de otras organizaciones incluyen: – el cliente.Planificación del Proyecto de Software Nivel 2: Repetible Habilidades para desarrollar Habilidad 1 Existe un documento aprobado de orden de trabajo para el proyecto de software.11 . q Los grupos afectados EI documento de orden de trabajo es administrado y controlado. q Responsabilidades asignadas. 1. 1. q Dependencias entre el proyecto de software y otras organizaciones.ar | CMM N2 . Se asignan responsabilidades para desarrollar el plan de proyecto. restricciones de costos y programación. Ejemplos de productos de trabajo de software incluyen: – Producto de trabajo para entrega a un cliente externo o usuario final. q Metas. Las responsabilidades por los productos de trabajo y las actividades de software son divididas y asignadas a los administradores del software de manera justificable y seguible. EI documento de orden de trabajo es revisado por: q EI administrador del proyecto global. q Identificación de clientes y usuarios finales. 2. y q Otras restricciones y metas para el desarrollo y/o mantenimiento. q Estándares impuestos. coordina la planificación del proyecto. Los usuarios finales a que se refieren estas practicas son los usuarios finales o representantes de usuarios finales designados por el cliente. – http://pragma. EI administrador del proyecto de software. – subcontratistas. – 2. 3. y socios. y – Producto de trabajo principales para uso interno del grupo de ingeniería de software. directamente o por delegación. EI documento de orden de trabajo cubre: q Alcance del trabajo q Metas técnicas y objetivos. según corresponda Producto de trabajo para uso de otros grupos de ingeniería. Habilidad 2 q Restricciones de recursos y metas. q EI administrador del proyecto de software.com.

1. Actividades a realizar Actividad 1 EI grupo de ingeniería de software participa en el equipo que realiza la propuesta del proyecto. 2. Se dejan disponibles herramientas de apoyo a la planificación de proyectos Ejemplos herramientas de soporte incluyen: – – – Habilidad 4 programas de planilla de calculo.12 . personas con experiencia.ar | CMM N2 . 1. son entrenadas en los procedimientos de estimación y planificación aplicables a su área de responsabilidad. y los estándares y procedimientos de software – – Actividad 2 La planificación del proyecto de software es iniciada en las primeras etapas. son asignados para el desarrollo del plan del proyecto. son la planificación global del proyecto. que tengan conocimiento experto en el dominio de aplicación del proyecto de software bajo planificación. http://pragma. y programas de planificación y programación Los administradores. y q negociaciones de cambios de acuerdos que afectan al proyecto de software El grupo de ingeniería de software revisa los acuerdos propuestos de proyecto Ejemplos de acuerdos de proyecto incluyen: – los objetivos y metas técnicas del proyecto. Actividad 3 EI grupo de ingenieros de software participa con otros grupos involucrados en la planificación global del proyecto. ingenieros de software y otras personas involucradas en la planificación del proyecto de software.Nivel 2: Repetible Habilidad 3 Planificación del Proyecto de Software Se destinan los recursos y fondos adecuados para realizar la planificación del proyecto. a lo largo de la vida del proyecto. 1. q discusiones de clarificación.com. – el sistema y la solución técnica de software. 2. el presupuesto del software. programación y recursos. Cuando es factible. EI grupo de ingeniería de software revisa los planes de nivel de proyecto. El grupo de ingeniería de software es involucrado en: q preparación y entrega de la propuesta. modelos de estimación. y en paralelo.

Ejemplos de grupos relacionados con el software incluyen: – – – Garantía de calidad de software. – cascada traslapada. ingeniería de hardware. los esfuerzos de soporte son presupuestados.13 . Ejemplos de otros grupos de ingeniería incluyen: – ingeniería de sistemas. Los planes para grupos relacionados con el software y otros grupos de ingeniería involucrados en las actividades de! grupo de ingeniería de software son negociados con esos grupos. El plan de desarrollo de software esta basado en: q Estándares del cliente. http://pragma. y los acuerdos documentados.com. construcción serial. q EI documento de orden de trabajo (aprobado) y q los requisitos de software.ar | CMM N2 . y los acuerdos documentados. 2. los esfuerzos de soporte son presupuestados. q Estándares del proyecto. – 3. Los planes para la participación de! grupo de ingeniería de software en actividades de otros grupos relacionados con el software y otros grupos de ingeniería son negociados con esos grupos. 1. y cascada simple prototipo / traslapada – – – Actividad 6 EI plan del proyecto de software es realizado de acuerdo a un procedimiento documentado. Ejemplos de ciclos de vida de software incluyen: – cascada. administración de configuraciones de software. espiral. y soporte de documentación.Planificación del Proyecto de Software Nivel 2: Repetible Actividad 4 Los compromisos adquiridos por personas o grupos externos a la organización son revisados con la administración superior de acuerdo a un procedimiento documentado. y – pruebas de sistema. Actividad 5 Se identifica o define un ciclo de vida de software con etapas predefinidas de un tamaño manejable.

com. EI plan de desarrollo de software del proyecto cubre: q El propósito. diseño de software. incluyendo identificación de hitos y revisiones. administración de configuraciones de software. q Identificación y evaluación de los riesgos de software del proyecto. Ejemplos de estándares y procedimientos incluyen: – – – – – – planificación del proyecto de software. q el administrador del proyecto de software. q Uso estimado de recursos críticos q Cronogramas del proyecto. q Estimación del esfuerzo y costo del proyecto. Actividad 7 EI plan de desarrollo de software es revisado por: q el administrador del proyecto. Refiérase a la actividad 1 de las áreas claves de proceso Supervisión y Control del Proyecto de Software para practicas concernientes al uso del plan de desarrollo de software del proyecto. métodos y estándares de desarrollo y/o mantenimiento de software seleccionados. http://pragma. seguimiento y resolución de problemas. y q otros grupos involucrados. q Planificación del uso de las facilidades de ingeniería de software y herramientas de apoyo.14 . ámbito. En las practicas claves. q Estimaciones de tamaño de los productos de trabajo y cualquier cambio a los productos de trabajo de software. q Identificación de los productos de trabajo a ser desarrollados. este plan o colección de planes es mencionada como el plan de desarrollo de software.Nivel 2: Repetible Planificación del Proyecto de Software 4. y mediciones de software. 5. metas y objetivos del proyecto de software.ar | CMM N2 . El plan del proyecto de software es documentado. q Selección de un ciclo de vida de software q Identificación de los procedimientos. q otros administradores de software. garantía de calidad de software.

ar | CMM N2 . el administrador del proyecto de software.15 . revisadas y luego acordadas. y – los otros administradores de software – http://pragma. Las estimaciones de tamaño son documentadas.Planificación del Proyecto de Software Actividad 8 Nivel 2: Repetible Se identifican aquellos productos de software sobre los cuales es necesario establecer y mantener un control dentro del proyecto de software. puntos de características. y actividades para desarrollar.). Ejemplos de grupos e individuos que revisan y acuerdan las estimaciones de tamaño incluyen: – el administrador del proyecto. Ejemplos de tipos de productos de trabajo y actividades para los cuales se hacen estimaciones incluyen: – – – – software operacional y de soporte. 3. Actividad 9 Las estimaciones del tamaño de los productos de software (o de los cambios en ellas) se realizan de acuerdo a un procedimiento documentado. Refiérase a la actividad 4 del área clave de proceso Administración de configuraciones de software. 5. líneas de código. 2. Los supuestos de las estimaciones de tamaño son documentados. verificar y validar los productos de trabajo. productos de trabajo de software y "no-software" (por ejemplo documento. Se realizan estimaciones de tamaño sobre los principales productos de trabajo de software.com. Este procedimiento típicamente especifica que: 1. Se usan datos históricos cuando se dispone de ellos. productos de trabajo entregables y no entregables. numero de requisitos. y numero de paginas. Ejemplos de estimaciones de tamaño de software incluyen: – – – – – Puntos de función. Los productos de trabajo de software son descompuestos hasta la granularidad requerida para cumplir con los objetivos de estimación. 4.

q Se preparan estimaciones de las distribuciones del esfuerzo. y costos de uso de computadores. gastos generales. Se identifican los recursos computacionales críticos.16 . las fuentes de información y la lógica para esos datos son documentadas. y capacidad del canal de comunicaciones – http://pragma. Se utilizan datos de productividad (históricos y/o reales) para las estimaciones cuando están disponibles. Este procedimiento típicamente establece que: 1. Este procedimiento típicamente especifica que: 1. q Los datos de productividad y costos son de proyectos de la organización cuando sea posible. q Los datos de productividad y costos toman en cuenta el esfuerzo y los costos significativos incluidos en hacer los productos de trabajo de software Ejemplos de costos significativos incluidos en hacer los productos de trabajo de software incluyen: – – – – 3. Las estimaciones de esfuerzos y costos del proyecto están relacionadas alas estimaciones de tamaño de los productos de trabajo de software (o el tamaño de los cambios) 2. gastos de viajes. en el ambiente operacional. Las estimaciones de esfuerzo. Ejemplos de recursos computacionales críticos incluyen: – capacidad de memoria del computador. personal y costos se basan en la experiencia pasada. personal. – usa del procesador del computador.ar | CMM N2 . y costos. Las estimaciones de los recursos computacionales críticos son realizadas de acuerdo a un procedimiento documentado. q Se derivan las fases en el tiempo de las actividades.Nivel 2: Repetible Actividad 10 Planificación del Proyecto de Software Las estimaciones de esfuerzo y costos se derivan de acuerdo a un procedimiento documentado. Actividad 11 gastos de esfuerzo directo. o en cualquier combinación de ellos. q Debieran usarse proyectos similares cuando sea posible. Los recursos computacionales críticos pueden ser en el ambiente del servidor.com. en el ambiente de pruebas e integración.

y planes alternativos de adquisición de recursos computacionales http://pragma. q la carga de procesamiento operacional. Establece claramente los hitos. revisada y acordada. y q las estimaciones de esfuerzo y costos 2. 4. 3. Los riesgos son analizados y priorizados de acuerdo a su impacto potencial en el proyecto. Se identifican contingencias para los riesgos. equipos de trabajo alternativos.Planificación del Proyecto de Software Nivel 2: Repetible 2. y otras restricciones. La programación de software esta relacionada a: q las estimaciones de tamaño del software. La programación de software se acomoda alas fechas impuestas de hitos. Actividad 13 Los riesgos asociados al costo. Ejemplos de contingencias incluyen: – – – holguras en las fechas. La programación del proyecto es documentada. recursos.com. evaluados y documentados. programación y aspectos técnicos del proyecto son identificados. dependencias criticas de actividades y otras restricciones. fechas de dependencias criticas. Las estimaciones de recursos computacionales críticos son documentadas.17 .ar | CMM N2 . revisadas y acordadas Actividad 12 La programación del proyecto de software se obtiene de acuerdo a un procedimiento documentado. La programación de software se basa en la experiencia pasada q Se usan proyectos similares cuando es posible 3. 2. 5. Los supuestos hechos al derivar la programación son documentados. 1. La estimación de recursos críticos esta relacionada a las estimaciones de: q el tamaño de los productos de trabajo de software. y q el trafico de las comunicaciones. Este procedimiento especifica típicamente que: 1. 6.

18 . Los datos de planificación de software son administrados y controlados. http://pragma.com.Nivel 2: Repetible Actividad 14 Planificación del Proyecto de Software Se preparan planes para las facilidades de ingeniería de software y herramientas de soporte del proyecto. Ejemplos de estas mediciones son: – Cumplimientos de los hitos del proyecto en relación con la planificación. software del medio ambiente del computador destino. Medición y Análisis Medición 1 Se hacen mediciones y son usadas para determinar el estado de las actividades de planificación de proyectos de software. Se asignan responsabilidades y se negocian los acuerdos para procurar desarrollar esas facilidades y herramientas de soporte. Ejemplos de facilidades de desarrollo de software y herramientas de soporte incluyen: – computadores y periféricos para desarrollo de software. – Trabajo realizado. – periféricos computadores para prueba de software. esfuerzo gastado y fondos utilizados en relación con la planificación Verificación de la Implementación Verificación 1 Las actividades contenidas en la planificación son revisadas en conjunto con la administración superior periódicamente. 2. 1. 1.ar | CMM N2 . 3. EI propósito principal de las revisiones periódicas de la administración superior es proveer el conocimiento y visión sobre las actividades del proceso de software a un nivel de abstracción apropiado y oportuno en el tiempo EI tiempo entre revisiones debe cumplir con las necesidades de la organización y puede ser tan largo como mecanismos para reporte de excepciones estén disponibles. y otro software de soporte – – Actividad 15 2. Se registran los datos de planificación de software. Los planes son revisados por todo todos los grupos afectados. Las estimaciones de requerimientos de capacidad para esas facilidades y herramientas de soporte están basadas en las estimaciones de tamaño de los productos de trabajo de software y otras características. La información registrada incluye las estimaciones y la información asociada necesaria para reconstruir las estimaciones y evaluar su razonabilidad.

EI grupo de garantía de calidad del software revisa y audita las actividades y productos de trabajo de la planificación de proyectos de software e informa los resultados. 6. las actividades de preparación del plan de desarrollo de software. http://pragma. Se revisan aspectos técnicos. EI estado real del proyecto y los resultados obtenidos se revisan contra los documentos de definición de trabajo y de requisitos asignados 3. costos. se revisan y se supervisan hasta cerrarlos 5.Planificación del Proyecto de Software Verificación 2 Verificación 3 Nivel 2: Repetible 1. e prepara un informe resumen de cada reunión y es distribuido a los individuos y grupos afectados. Refiérase al área clave de proceso de Garantía de Calidad de Software. Se abordan los riesgos del proyecto. 3. Los grupos afectados están representados 2. Se asignan ítems de acción. el contenido del plan de desarrollo de software. 1. Los riesgos del proyecto son revisados. Como mínimo la auditoria revisa: 1.. Las dependencias entre los distintos grupos son abordadas 4.com. y si siguen hasta cerrarlos 7. los estándares usados para preparar el plan de desarrollo de software. Se abordan conflictos y problemas no solubles en niveles mas bajos 3. personal y el cumplimiento de la programación. se revisan. 2. 5. Los conflictos y problemas no solubles en los niveles inferiores son abordados. tanto periódicamente como en respuesta a eventos. 4.ar | CMM N2 . 4. Se prepara un informe resumen de cada reunión y se distribuye a los grupos e individuos afectados Las actividades para la planificación de proyectos de software son revisadas con el administrador del proyecto. 2. Se asignan ítems de acción.19 . las actividades de estimación y planificación de software. 5. las actividades de revisión y toma de compromisos de proyecto.

Las actividades de software son monitoreadas por la administración. y ajustar el plan de acuerdo a los logros y resultados reales.ar | CMM N2 . Cuando se ha determinado que los planes del proyecto de software no están siendo cumplidos. Estas acciones pueden incluir revisar el plan de desarrollo software para reflejar los resultados reales y planificar el trabajo restante o tomar acciones para mejorar el desempeño.Seguimiento y Control del Proyecto de Software Un área clave de proceso para el nivel 2: Repetible EI propósito del Seguimiento y Control del Proyecto de Software es proporcionar una adecuada visión del avance real del proyecto de forma que los administradores puedan tomar acciones efectivas cuando el rendimiento del proyecto de software se desvía significativamente del plan de software. comunicar su estado.com. Se usa un plan documentado para el proyecto de software (es decir.20 . y programación real del software con el plan cuando se completan productos de trabajo de software y en hitos selectos. se toman acciones correctivas. El progreso es determinado principalmente comparando el tamaño. EI Seguimiento y Control del Proyecto de Software involucra seguir y revisar los logros y resultados en contraste alas estimaciones. el plan de desarrollo de software. esfuerzo. como se describió en el área clave de proceso Planificación del Proyecto de Software) como la base para seguir las actividades de software. costo. y revisar los planes. http://pragma. compromisos y planes documentados.

ar | CMM N2 .21 . Los cambios a los compromisos de software son hechos con el involucramiento y el acuerdo de los grupos afectados Ejemplos de grupos afectados incluyen: – ingeniería de software (incluyendo todos los sub-grupos. Compromiso 2 El proyecto sigue una política organizacional escrita para la administración de proyectos de software. tales como diseño de software).com. Se usa y mantiene un plan de desarrollo documentado como base para el seguimiento del proyecto. Meta 3 Los cambios en los compromisos adquiridos son acordados entre los grupos y personas afectadas. pruebas de software garantía de calidad de software. Meta 2 Se toman y administran acciones correctivas cuando los resultados y el rendimiento obtenidos se desvían significativamente del plan. Esta política típicamente indica que: 1. 4. administración de contrato. ingeniería de software. y – apoyo de documentación – – 5. ya sea ajustando el plan o el desempeño. 2. Compromisos para desarrollar Compromiso 1 Se designa a un administrador del proyecto de software como responsable por las actividades y resultados del proyecto. El administrador de! proyecto se mantiene informado del estado y los problemas de! proyecto. La administración superior revisa todos los cambios y nuevos compromisos adquiridos por el proyecto con individuos o grupos externos a la organización. administración de configuración de software. 3. Se toman acciones correctivas cuando el plan del proyecto no esta siendo logrado. – – estimación de software.Seguimiento y Control del Proyecto de Software Nivel 2: Repetible Metas Meta 1 El rendimiento y los resultados obtenidos son seguidos y contrastados con el plan del proyecto. http://pragma.

Habilidad 2 El administrador del proyecto de software asigna en forma explicita responsabilidades sobre las actividades y productos a desarrollar. costos. EI presupuesto para estas actividades de software Se proveen los recursos y fondos necesarios para el seguimiento del proyecto. y programación de software.com. 1. 4.Nivel 2: Repetible Seguimiento y Control del Proyecto de Software Habilidades para desarrollar Habilidad 1 Se documenta y aprueba un plan de desarrollo de software para el proyecto. La programación asociada a estas actividades de software. Se proporcionan herramientas que apoyen la labor de seguimiento del proyecto Ejemplos de herramientas de soporte incluyen: – – Habilidad 4 Planillas de calculo.22 . EI esfuerzo y costo para estas actividades de software. 3. 2. seguimiento y control del tamaño. y administración de personal Los administradores de primera línea reciben orientación en los aspectos técnicos del proyecto. Ejemplos de orientación incluyen: – Estándares de ingeniería de software y procedimientos aplicables al proyecto – EI dominio de aplicación del proyecto http://pragma.ar | CMM N2 . Ejemplos de entrenamiento incluyen: – – – Habilidad 5 Administración de proyectos técnicos. Los productos de software a ser desarrollados o los servicios a ser proporcionados. programas de planificación y programación de actividades Los administradores de proyectos son entrenados para administrar los aspectos técnicos y de personal de los proyectos. Se asignan responsabilidades especificas de seguimiento a los administradores y lideres de tarea. esfuerzo. La asignación de responsabilidades cubre: Habilidad 3 1. 2. Refiérase alas actividades 6 y 7 del área clave de proceso de Planificación de proyectos de software para practicas que cubren el plan de desarrollo de software.

según sea apropiado. EI presupuesto para estas actividades de software El plan de desarrollo de software del proyecto se revisa de acuerdo a un procedimiento documentado. q los administradores de software. EI plan de desarrollo de software es administrado y controlado. para incorporar refinamientos y cambios al plan. restricciones de diseño. y los cambios son incorporados de forma controlada (es decir.Seguimiento y Control del Proyecto de Software Nivel 2: Repetible Actividades a realizar Actividad 1 Se usa un plan de desarrollo documentado para seguir las actividades y comunicar el estado de ellas. Este procedimiento. Fácilmente disponible para: q EI grupo de ingeniería de software (incluyendo todos los sub-grupos tales como diseño de software). q la administración superior. 4. EI plan es actualizado para incorporar los cambios en los compromisos. o los nuevos compromisos. costos. y la programación necesitan ser reflejadas en todos los cambios al plan. típicamente. La programación asociada a estas actividades de software. 4. el producto de trabajo puede ser puesto bajo la disciplina completa de administración de configuración. Las interdependencias entre requisitos de sistema asignados al software.23 . particularmente cuando se completan hitos 2. recurso. Si se desea un mayor grado de control que el implicado por "administrado y controlado". EI plan de desarrollo es revisado. Actualizado a medida que el trabajo avanza para reflejar logros. control de cambios). y q otros grupos afectados 3. 3. especifica que: 1. Refiérase a la actividad 6 del orea clave de proceso de Planificación de proyectos de software para prácticas que cubren las actividades para producir el plan de desarrollo de software. Refiérase a la actividad 7 del área clave de proceso de Planificación de proyectos de software para practicas que cubren el contenido del plan de desarrollo de software Este plan de desarrollo es: Actividad 2 1. como es descrita en el área clave de proceso de Administración de Configuración de Software http://pragma. q los administradores del proyecto. El plan de desarrollo de software es examinado en cada revisión. 2.com. control de versiones).ar | CMM N2 . "Administrado y controlado" implica que la versión del producto de trabajo en uso en un momento dado (pasado o presente) es conocida (es decir.

EI esfuerzo y la provisión de personal son comparadas alas estimaciones documentadas en el plan de desarrollo de software. Los cambios la provisión de personal y en otros costos que afecten los compromisos de software son negociados con los grupos afectados y son documentados. EI tamaño real del código (generado. son negociados con los grupos afectados y son documentados Se siguen el esfuerzo y los costos del proyecto y se toman acciones correctivas si es necesario. Se siguen los tamaños de los principales productos de software (o el tamaño de los cambios) 2. 1.com. Actividad 6 1. Actividad 4 Los cambios aprobados a compromisos que afectan al proyecto son comunicados a los miembros del grupo de ingeniería de software y otros grupos relacionados. EI tamaño total proyectado de todos los productos de software (estimados combinados con reales) es refinado.24 . Los gastos reales de esfuerzo y costos.ar | CMM N2 . Los cambios en las estimaciones de tamaño que afectan compromisos de software. Refiérase a la actividad 9 del área clave de proceso de Planificación de proyectos de software para practicas que cubren las actividades para derivar las estimaciones de tamaño. Las unidades reales de documentación entregada son comparadas con las estimaciones documentadas en el plan de desarrollo de software. 3. 5. Los costos de software son seguidos y comparados alas estimaciones documentadas en el plan de desarrollo de software. http://pragma. y – apoyo de documentación – Actividad 5 Se sigue el tamaño del producto de software (o el tamaño de los cambios) y se toman acciones correctivas si es necesario. en el tiempo y en relación con los productos desarrollados son comparados con las estimaciones documentadas en el plan de desarrollo de software para identificar potenciales desviaciones de 10 presupuestado. Ejemplos de otros grupos relacionados con software incluyen: – garantía de calidad de software. Refiérase a la actividad 10 del área clave de proceso de Planificación de proyectos de software para practicas que cubren las actividades para derivar las estimaciones de costo. monitoreado y ajustado regularmente. 4. 4.Nivel 2: Repetible Seguimiento y Control del Proyecto de Software Actividad 3 Los cambios a compromisos o nuevos compromisos del proyecto de software. 3. deben ser revisados con la administración superior de acuerdo a un procedimiento documentado. 2. probado y entregado) es comparado con las estimaciones documentadas en el plan de desarrollo de software. administración de configuración de software. hechos a grupos o personas externas a la organización.

Actividad 9 Actividad 10 1. Se siguen los riesgos asociados con costos. EI cumplimiento de las actividades y de los hitos de la programación es comparado con el plan de desarrollo de software 2. Los cambios en estimaciones de recursos críticos de computador que afecten los compromisos de software son negociados entre las partes afectadas.com. Los reportes de problemas son seguidos hasta su cierre. Miembros del grupo de ingeniería de software informan el estado técnico al administrador de primera línea en forma regular. recursos. 1. Refiérase a la actividad 12 del área clave de proceso de Planificación" de proyectos de software para prac ticas que cubre" las actividades para derivar las estimaciones de la programación. Los problemas identificados en cualquiera de los productos de software son informados y documentados. Refiérase a la actividad 11 del área clave de proceso de Planificación de proyectos de software para practicas que cubren las actividades para derivar las estimaciones de recurso de computadores. Se siguen las actividades técnicas de ingeniería de software del proyecto y se toman acciones correctivas si es necesario. hitos y otros compromisos. Actividad 8 1. Se evalúan los efectos del atraso o adelanto en el cumplimiento de las actividades. Se signe la programaci6n de software del proyecto y se toman acciones correctivas si es necesario. Las revisiones y modificaciones a la programación que afecten los compromisos de software son negociadas con los grupos afectados y son documentados. 2. en relación con el impacto sobre actividades e hitos futuros 3. http://pragma. 2. Refiérase a la actividad 13 del área clave de proceso de Planificación de proyectos de software para practicas que cubren la identificación de los riesgos.Seguimiento y Control del Proyecto de Software Actividad 7 Nivel 2: Repetible Se siguen los recursos críticos de computador y se toman acciones correctivas si es necesario.25 . 3. EI uso real y proyectado de recursos computacionales para cada componente principal es comparado con las estimaciones documentadas en el plan de desarrollo de software. 4. Los contenidos del software liberado para construcciones sucesivas son comparados con los planes documentados en el plan de desarrollo de software.ar | CMM N2 . programación y aspectos técnicos del proyecto y se toman acciones correctivas si es necesario.

Actividad 12 1. Se registran datos de medición reales y de replanificación para el proyecto de software. 2. según corresponda. Las prioridades de los riesgos y las contingencias de los riesgos son ajustadas a medida de que se dispone de información adicional. Resultan en la identificación y documentación de los problemas mas significativos. Refiérase a la actividad 15 del área clave de proceso de Planificación de proyectos de software para practicas que cubre" el registro de datos de proyecto. Los datos de replanificación son administrados y controlados 3. los administradores de primera línea. Los administradores de primera línea y sus lideres de tarea de software. Usan materiales que son revisados y aprobados por los administradores de software responsables. 2. EI grupo de ingeniería de software conduce revisiones internas periódicas para seguir el avance técnico. Esas revisiones son conducidas entre: Actividad 13 1. 3. La información registrada incluye las estimaciones y la información necesaria para reconstruir las estimaciones y verificar su razonabilidad. Resulta en un refinamiento del plan de desarrollo de software si es necesario http://pragma. y problemas contra el plan de desarrollo de software. y datos de mediciones reales son archivados para ser utilizados en proyectos en ejecución y futuros. datos de replanificacion. Abordan los compromisos. Las áreas de alto riesgo son revisadas con el administrador del proyecto en forma regular. EI administrador del proyecto de software. Se planifican para ocurrir en puntos significativos de la programación del proyecto. tales como comienzo y fin de etapas. 6. Los reportes de problemas son seguidos hasta su cierre.Nivel 2: Repetible Actividad 11 Seguimiento y Control del Proyecto de Software 5. y otros administradores de software. Esas revisiones: 1. usuarios finales y los grupos involucrados dentro de la organización.com. planes. 4. planes y el estado de las actividades de software 5.ar | CMM N2 . 4. los ítems de acción y las decisiones. Los usuarios finales referidos en estas practicas son usuarios finales designados por el cliente o representantes de los usuarios finales. Se abordan los riesgos del proyecto de software 7. Se realizan revisiones formales para abordar los logros y resultados del proyecto de software en algunos hitos escogidos de acuerdo a un procedimiento documentado. desempeño. Los datos de planificación de software. 2.26 . 6. Participan los clientes.

costos. Los grupos afectados están representados. El principal propósito de las revisiones periódicas por la administración superior es generar conciencia de.com. recursos críticos de computador y programación Verificación de la Implementación Verificación 1 Las actividades de seguimiento y control son revisadas con la administración superior en forma periódica.27 . Se abordan las dependencias entre grupos. Se asignan ítems de acción. estimaciones de costos de software. se revisan y se siguen hasta su termino 7. y Actividad de cambio en el plan de desarrollo de software. 3. 4. 1. las cuales incluyen cambios en el tamaño estimado de los productos de software. Se abordan los riesgos del proyecto de software. Se asignan ítems de acción. personal y programación. 5. se revisan y son seguidas hasta su termino 5. como estén disponibles mecanismos adecuados de reporte de excepciones. 2. Se prepara un informe resumen de estado de cada reunión el cual es distribuido a los grupos afectados. Las actividades de seguimiento y control son revisadas con el administrador del proyecto en forma periódica y ante eventos que lo requieran. 4. Se re evalúan los riesgos del proyecto. Se abordan los conflictos y problemas que no solubles en los niveles inferiores.Seguimiento y Control del Proyecto de Software Nivel 2: Repetible Medición y Análisis Medición 1 Se realizan mediciones y son usadas para determinar el estado de las actividades de Supervisión y Control del Proyecto.ar | CMM N2 . Verificación 2 1. El desempeño técnico. Se revisa el rendimiento técnico. Se abordan los conflictos y problemas no solubles en los niveles inferiores. Se prepara un informe resumen de cada reunión y se distribuye a los grupos afectados. y visión acerca de las actividades del proceso de software a un nivel de abstracción adecuado y de manera oportuna el tiempo entre revisiones debe cumplir con las necesidades de la organización y puede ser tan largo. 6. 2. Ejemplos de mediciones incluyen: – – Esfuerzo y otros recursos gastados en actividades de Supervisión y Control del Proyecto. la asignación de recursos y la programación se revisan en comparación con el plan del proyecto de software 3. http://pragma. los costos.

programación. EI contenido del plan de desarrollo de software revisado. Refiérase al área clave de proceso Garantía de Calidad de Software Como mínimo. 5. Las actividades para conducir las revisiones técnicas y de la administración planificadas http://pragma.28 .com. 4. Las actividades para revisión y repaso de compromisos. restricciones técnicas. 2.ar | CMM N2 . Las actividades de revisión del plan de desarrollo 3. de funcionalidad y de rendimiento.Nivel 2: Repetible Verificación 3 Seguimiento y Control del Proyecto de Software EI grupo garantía de calidad de software revisa y/o audita las actividades y productos de trabajo de Supervisión y Control de Proyectos de Software e informa los resultados. de diseño. Las actividades de seguimiento de los costos. las auditorias o revisiones verifican: 1. riesgos.

se crea un acuerdo documentado cubriendo tanto los requerimientos técnicos como no técnicos (por ejemplo: fechas de entrega) y se usa como base para administrar el subcontrato. y el seguimiento y revisión del desempeño y resultados del subcontratista. http://pragma. Los estándares que son para ser seguidos por el subcontratista son compatibles con los estándares del contratante. seguimiento. y control para el trabajo subcontratado son ejecutadas por el subcontratista. hardware y posiblemente otras componentes de sistema. as! como también la administración de una componente de software de un subcontrato que incluye software.29 . El contratante asegura que esas actividades de planificación. Los subcontratistas pueden ser seleccionados sobre la base de alianzas comerciales estratégicas. El subcontratista es seleccionado sobre la base de su habilidad para desarrollar el trabajo. o bien por razones técnicas. El contratante trabaja con el subcontratista para administrar las interfaces de productos y procesos. Involucra la selección del subcontratista.Administración de Subcontratos Un área clave de proceso para el nivel 2: Repetible El propósito de la Administración de Subcontratos es seleccionar subcontratistas de software calificados y administrarlos efectivamente.com. El trabajo a ser realizado por el subcontratista y los planes para el trabajo son documentados. Al subcontratar. establecer compromisos con el subcontratista. seguimiento y control son ejecutadas apropiadamente y que los productos de software entregados por el subcontratista satisfacen sus criterios de aceptación. Las actividades de planificación de software. Las practicas de esta área clave de proceso abordan el proceso tradicional de adquisición asociado con subcontratar una porción definida del trabajo con otra organización.ar | CMM N2 . Esas practicas cubren la administración de un subcontrato de software (solamente).

especifica: Compromiso 2 1. 3. tales como adquisiciones. EI administrador del subcontrato es conocedor y experimentado en ingeniería de software o tiene personas asignadas que tienen este conocimiento y experiencia.Nivel 2: Repetible Administración de Subcontratos Metas Meta 1 EI contratante selecciona subcontratistas de software calificados. de los resultados reales y del desempeño en relación a sus compromisos. Se usan estándares y procedimientos documentados para la selección y la administración de los subcontratistas de software. finanzas. típicamente. 2. y legal establecen y monitorean los términos y condiciones del subcontrato http://pragma. Compromisos para desarrollar Compromiso 1 El proyecto sigue una política organizacional escrita para la administración del subcontrato de software Esta política. Este administrador debe: 1. Los acuerdos contractuales son la base para administrar el subcontrato. 2.com. Meta 3 EI contratante y el subcontratista de software mantienen una comunicación continua. Meta 4 EI contratante hace un seguimiento al subcontratista de software.30 . Los cambios en el subcontrato son hechos con la participación y acuerdo del contratante y el subcontratista. EI grupo de ingeniería de sistemas del proyecto y el grupo de ingeniería de software definen la cobertura técnica del trabajo a ser subcontratado Los grupos funcionales de negocio. Meta 2 EI contratante y el subcontratista acuerdan compromisos recíprocos. Ser responsable de coordinar el alcance técnico del trabajo a ser subcontratado y los términos y condiciones del subcontrato con las partes afectadas. Se designa un administrador de subcontratos para hacerse responsable de establecer y administrar el subcontrato de software.ar | CMM N2 .

31 .com.Administración de Subcontratos 3. Nivel 2: Repetible EI administrador del subcontrato es responsable por: q seleccionar al subcontratista de software. Son asignadas responsabilidades especificas a los administradores del software y otros individuos por administrar el subcontrato. planillas de calculo y programas de administración y programación de proyectos Los administradores del software y otros individuos que están involucrados en el establecimiento y administración de los subcontratos están entrenados para realizar esas actividades. Se hacen disponibles herramientas para apoyar la administración del subcontrato. 2. estándares en uso. 1. – Evaluación la capacidad del proceso de software de un postor del subcontrato. y procedimientos en uso http://pragma. Selección de un subcontratista. Evaluación de las estimaciones y planes de un postor del subcontrato. Ejemplos de capacitación incluyen: – Preparación y panificación para la administración del subcontrato. q administrar el subcontrato y q organizar el apoyo post-contrato de los productos subcontratados Habilidades para desarrollar Habilidades 1 Se proveen recursos y financiamiento adecuados para seleccionar al subcontratista y administrar el subcontrato. Metodologías en uso. Herramientas de software en uso. Ejemplos de orientación incluyen: – – – – – Tecnologías de software en aplicación.ar | CMM N2 . y Administración de un subcontrato – – – Habilidades 3 Los administradores del software y otros individuos que están involucrados en la administración del subcontrato reciben orientación en los aspectos técnicos del subcontrato. Ejemplos de herramientas de apoyo incluyen: – – – Habilidades 2 modelos de estimación.

q repasada. Las actividades y productos de software a ser subcontratados son seleccionados de acuerdo a características técnicas y no técnicas del proyecto q Las funciones o subsistemas a ser subcontratados son seleccionados para calzar con las habilidades y capacidades de potenciales subcontratistas q La especificación de los productos y actividades de software a ser subcontratadas es determinada basándose en un análisis sistemático y una partición adecuada de los requerimientos de sistema y de software La especificación del trabajo a ser subcontratado y los estándares y procedimientos a ser seguidos se derivan de: q La orden de trabajo. q administra y controla un informe del trabajo a subcontratar. Los administradores de software responsables.ar | CMM N2 . 3. 2. Ejemplos de individuos que revisan y acuerdan la orden de trabajo del subcontratista incluyen: – – – – – – EI administrador del proyecto. http://pragma. y EI administrador de! Subcontrato q revisada cuando es necesario. EI administrador del proyecto de software. q los requisitos de software. q los estándares de software y procedimientos Una orden de trabajo es: q preparada. q el plan de desarrollo del software.Nivel 2: Repetible Administración de Subcontratos Actividades a realizar Actividad 1 EI trabajo a ser subcontratado es definido y planificado de acuerdo a un procedimiento documentado. EI administrador de configuración de software. Este procedimiento típicamente especifica que: 1. q acordada. y q administrada y controlada. EI administrador de garantía de calidad de software. q los requisitos de sistema asignados al software.32 .com.

Software. 2. Experiencia previa en aplicaciones similares. 6. y Capacitación http://pragma. y los cambios son incorporados de forma controlada (es decir. control de versiones). Se prepara un plan para seleccionar un subcontratista. Actividad 2 EI subcontratista es seleccionado. si están disponibles.Nivel 2: Repetible Administración de Subcontratos 4. Ejemplos de recursos incluyen: – – – – Medios. Registros de desempeño en trabajos similares. 7. Una administración efectiva de algunos subcontratos puede requerir frecuentes interacciones cara a cara. "Administrado y controlado" implica que la versión del producto de trabajo en uso en un momento dado (pasado o presente) es conocida (es decir.33 . Propuestas enviadas para el subcontrato planificado. 4.com. Recursos disponibles. de acuerdo a un procedimiento documentado.ar | CMM N2 . La ubicación geográfica de los postulantes al subcontrato. el producto de trabajo puede ser puesto bajo la disciplina completa de administración de configuración. en base a una evaluación de la capacidad del postulante al subcontrato de realizar el trabajo. control de cambios) Si se desea un mayor grado de control que el implicado por "administrado y controlado". concurrentemente con el informe del trabajo. incluyendo experiencia en software del equipo administrador de software del subcontratista. Un ejemplo de un método para evaluar capacidades de subcontratistas es el "Software Capability Evaluación" del SEI 5. Hardware. Este procedimiento cubre la evaluación de: 1. como es descrita en el área clave de proceso de Administración de Configuración de Software Refiérase a la habilidad 1 del área clave de proceso de Planificación de proyectos de software para practicas que cubren el contenido típico de una orden de trabajo. Las capacidades de administración e ingeniería de software. EI personal disponible para realizar el trabajo. 3.

1. Los procedimientos y criterios de aceptación para ser usados en la evaluación del producto subcontratado antes de la aceptación por el contratante. Los requisitos para los productos a ser desarrollados. 3. La orden de trabajo. Refiérase a la actividad 7 del área clave de proceso de Planificación de Proyectos de Software para practicas que cubren el contenido típico de "n plan de desarrollo de software. EI acuerdo contractual documenta: 1. Un plan documentado de desarrollo del software subcontratado es revisado y aprobado por el contratante. 4. 5. el plan de desarrollo para el subcontratista. 8. los términos y condiciones del subcontrato y otros acuerdos son resueltos de acuerdo a un procedimiento documentado. 1. tanto del contratante como del subcontratista ítems http://pragma.com.34 . Este procedimiento típicamente especifica que están involucrados todos los grupos afectados. Las condiciones bajo las cuales se someterán a revisiones los productos 7. Documentación del diseño. Ambiente de simulación. Los términos y condiciones 2. La lista de dependencias entre el subcontratista y el contratante. Actividad 6 Los cambios a la orden de trabajo. Este plan de desarrollo de software cubre (directamente o por referencia) los ítems apropiados del plan de desarrollo de software del contratante En algunos casos. Actividad 5 Un plan de desarrollo de software documentado y aprobado es usado para el seguimiento de las actividades de software y comunicar su estado. Refiérase a la habilidad 1 del área clave de proceso de Planificación de Proyectos de Software para practicas que cubren el contenido típico de una orden de trabajo. y por tanto no se necesita un plan de desarrollo de software del subcontratista aparte. el plan de desarrollo de software del contratante.ar | CMM N2 . y – EI plan de pruebas de aceptación – – – Actividad 4 6. Los productos subcontratados que serán entregados al contratante Ejemplo de productos incluyen: – Código fuente. Plan de desarrollo de software. puede incluir.Administración de Subcontratos Actividad 3 Nivel 2: Repetible EI acuerdo contractual entre el contratante y los subcontratistas es usado como base para administrar el subcontrato. Los procedimientos y criterios de evaluación a ser usados por el contratante para monitorear y evaluar el desempeño del subcontratista.

Se abordan las dependencias criticas y compromisos entre el grupo de ingeniería de software del subcontratista y otros grupos del subcontratista. Estas revisiones: 1. contra el plan de desarrollo del software del subcontratista. Se asignan.apropiados del plan de desarrollo de software del contratante. Administración de Subcontratos Nivel 2: Repetible Actividad 7 La administración del contratante conduce revisiones de estado / coordinación con la administración del subcontratista. según corresponda. 2. http://pragma. 5. Se le entrega al subcontratista la visión de las necesidades y deseos del cliente del producto y de los usuarios finales si corresponde. Los usuarios finales referidos en esas practicas son usuarios finales designados por el cliente. 1.ar | CMM N2 . 3.35 . Verifican que los aspectos técnicos se están resolviendo de forma oportuna. 4. Se revisan los recursos computacionales designados como críticos para el proyecto. Se abordan los riesgos de proyecto que involucran el trabajo del subcontratista 8. 7. 2. Se revisan. Se abordan las dependencias y acuerdos críticos entre el contratante y el subcontratista. la contribución del subcontratista alas estimaciones actuales es seguida y comparada con las estimaciones para cada componente de software documentadas en el plan de desarrollo de software del subcontratista. o representantes de los usuarios finales. están de acuerdo con los requisitos del contratante 4. el desempeño técnico. q Actividad 8 Se revisan los compromisos del subcontratista con el contratante y viceversa 6. costos. con el subcontratista de software. Verifican que los acuerdos se están cumpliendo. por parte del subcontratista. Verifican que la interpretación e implementación de los requisitos técnicos. Se abordan no conformidades con el subcontrato. en forma periódica. personal y programación. Proveen al subcontratista de visibilidad de las necesidades y deseos del cliente y los usuarios finales. revisan y siguen ítems de acción hasta cerrarlos Se realizan intercambios y revisiones técnicas. 3. 9.com. Monitorean las actividades técnicas del subcontratista. 5. Se abordan conflictos y problemas no resolubles internamente por el subcontratista.

2. procedimientos y estándares para garantía de calidad del subcontratista. Se revisan los estándares. son revisados periódicamente para asegurar que ellos son adecuados para monitorear el desempeño del subcontratista. Actividad 11 EI grupo de administración de la configuración del contratante monitorea las actividades de administración de la configuración del subcontratista. Las revisiones son pre-planificadas y documentadas en la orden de trabajo.Administración de Subcontratos Actividad 9 Nivel 2: Repetible Se conducen revisiones formales para abordar los resultados y logros de la ingeniería de software del subcontratista. en hitos selectos y bajo un procedimiento documentado. 4. Se abordan los riesgos de! software 5. planes para y estado de las actividades de software. 3. 2. Este procedimiento típicamente especifica que: Actividad 10 1. recursos.com. El contratante y el subcontratista coordinan sus actividades en materias relacionadas a la administración de la configuración para asegurar que los productos del subcontratista pueden ser rápidamente integrados o incorporados en el ambiente del proyecto del contratante. según corresponda. planes. recursos y procedimientos de la administración de configuración del subcontratista para asegurar que son adecuados. q El grupo de garantía de calidad de software del contratante audita los registros de garantía de calidad de software del subcontratista. Se conducen revisiones regulares del subcontratista para asegurar que se están siguiendo los procedimientos y estándares aprobados. 3. en hitos selectos y bajo un procedimiento documentado. 2. El plan de desarrollo del software del subcontratista se refina. los ítems de acción y las decisiones. Este procedimiento típicamente especifica que: 1. Este procedimiento típicamente especifica que: 1. Las revisiones abordan los acuerdos para. http://pragma. según corresponda.ar | CMM N2 . Los planes. estándares y procedimientos de garantía de calidad de software. de acuerdo a un procedimiento documentado. Se conducen revisiones formales para abordar los resultados y logros de la ingeniería de software del subcontratista. q El grupo de garantía de calidad de software del contratante chequea las actividades y productos de ingeniería de software del subcontratista.36 . Los registros de las actividades garantía de calidad del subcontratista son auditados periódicamente para evaluar cuan bien se están siguiendo los planes. Se identifica y documentan los problemas significativos.

ar | CMM N2 . El contratante y el subcontratista coordinan sus actividades en materias relacionadas a la administración de la configuración para asegurar que los productos del subcontratista pueden ser rápidamente integrados o incorporados en el ambiente del proyecto del contratante. 2. Medición y Análisis Medición 1 Se realizan mediciones y son usadas para determinar el estado de las actividades de administración del subcontrato de software. periódicamente. Se planifican acciones para cada producto de software que no pasa sus pruebas de aceptación Se evalúa. como opuesto alas revisiones periódicas técnicas y de coordinación que ocurren a través del proyecto La documentación de esas evaluaciones también actúa como una entrada para actividades futuras de selección de subcontratistas. Están definidos. Los resultados de las pruebas de aceptación son documentados 3.Administración de Subcontratos Nivel 2: Repetible 3. de acuerdo a un procedimiento documentado. Un mecanismo tal como las revisiones de premio por cuota de desempeño proveen este tipo de retroalimentación. el desempeño del subcontratista de software y la evaluación es revisada con el subcontratista. – Tiempos de entrega reales para productos subcontratados en comparación con el plan Tiempos de entrega del contratante al subcontratista en comparación con el plan – http://pragma.37 .com. Actividad 12 EI contratante conduce pruebas de aceptación como parte de la entrega de los productos de software del subcontratista. La librería de líneas base de software del subcontratista es revisada periódicamente para evaluar que tan bien son seguidos los procedimientos para la administración de configuración del software y que tan efectivos son ellos en administrar la línea base de software. Este procedimiento típicamente especifica que: Actividad 13 1. 4. Ejemplo de mediciones: – Costos de las actividades para la administración del subcontrato en comparación con el plan. revisados y aprobados los criterios de aceptación para cada producto. las necesidades del contratante). La evaluación del desempeño del subcontratista provee una oportunidad para el subcontratista de obtener retroalimentación en ellas sobre si esta o no satisfaciendo las necesidades de sus clientes (es decir.

con la administración superior.Nivel 2: Repetible Administración de Subcontratos Verificación de la Implementación Verificación 1 Las actividades para la administración del subcontrato de software son revisadas. Refiérase a la verificación 2 del área clave de proceso de Seguimiento y Control de Proyectos para practicas cubriendo el típico contenido de las revisiones de seguimiento de la administración superior. Las actividades para la coordinación de las actividades de administración de la configuración del contratante y el subcontratista. La revisión de la conducción de 10 planificado con el subcontratista. 3. Refiérase al área clave de proceso de Garantía de Calidad de Software. Las actividades para seleccionar al subcontratista. 4.38 . EI proceso de aceptación de los productos de software del subcontratista http://pragma. y reporta los resultados.com. Las actividades para administrar el subcontrato. 2. 6. Verificación 3 EI grupo de garantía de calidad del software. revisa y/o audita las actividades y los productos del trabajo para administrar los subcontratos del software.ar | CMM N2 . en forma periódica y en reacción a eventos. en forma periódica. 5. Esta revisión y/o auditoria verifica: 1. La conducción de revisiones que establecen el termino de aspectos claves del proyecto para el subcontratista. Refiérase a la verificación 1 del área clave de proceso de Seguimiento y Control de Proyectos para practicas cubriendo el típico contenido de las revisiones de seguimiento de la administración superior Verificación 2 Las actividades para la administración del subcontrato de software son revisadas con el administrador del proyecto.

estándares y procedimientos. Garantía de Calidad de Software involucra revisar y auditar los productos y actividades de software a fin de asegurar que ellos cumplan con los estándares y procedimientos aplicables. el grupo de garantía de calidad de software ayuda a asegurar que ellos se ajustan alas necesidades del proyecto y verifica que ellos serán usables para efectuar revisiones y auditorias a través del ciclo de vida del software. estándares y procedimientos establecidos.com.ar | CMM N2 . El grupo de Garantía de Calidad de Software trabaja con el proyecto de software durante sus etapas tempranas para definir los planes. http://pragma. Al participar en establecer los planes.39 .Garantía de Calidad de Software Un área clave de proceso para el nivel 2: Repetible El propósito de Garantía de Calidad de Software es dar ala administración una visibilidad adecuada del proceso que esta siendo usado y los productos que están siendo construidos. estándares y procedimientos que agregaran valor al proyecto de software y satisfarán las restricciones del proyecto y las políticas de la organización. El grupo de garantía de calidad de software revisa las actividades del proyecto y audita los productos de trabajo de software a través del ciclo de vida y provee a la administración de visibilidad sobre la adherencia del proyecto de software a sus planes. proveyendo al proyecto de software y otros administradores apropiados de los resultados de esas revisiones y auditorias.

40 . Meta 4 Problemas de no conformidad que no puedan ser resueltos dentro del proyecto son abordados por la administración superior. y q Otros grupos relacionados con el software Ejemplo de otros grupos relacionados con el software incluyen: – – Administración del configuración de software. Compromisos para desarrollar Compromiso 1 EI proyecto sigue una política organizacional escrita para implementar Garantía de Calidad de Software (GCS). http://pragma. – Proteger a los individuos que ejecutan el rol de GCS de una evaluación de desempeño por la administración del proyecto software que ellos están revisando.ar | CMM N2 . Meta 2 Verificar objetivamente si los productos y actividades satisfacen los requisitos y estándares aplicables. tales como GCS. típicamente. Esta política. Meta 3 Los grupos y personas afectadas son informadas sobre las actividades de garantía de calidad y de los resultados obtenidos.com. Las organizaciones deben determinar la estructura organizacional que soportara las actividades que requieren independencia. 2. – Proveer a los individuos el ejecutar el rol GCS con la libertad organizacional de ser "los ojos Y los oídos" de la administración superior dentro del proyecto de software. especifica: 1. y – Proveer a la administración superior la confianza que se esta reportando información objetiva acerca de los procesos y los productos del proyecto de software. EI grupo de Garantía de Calidad de Software tiene un canal de reporte directo a la administración superior que es independiente de: q EI administrador del proyecto. en el contexto de sus metas estratégicas de negocia y el ambiente de negocios. y Apoyo de documentación. q El grupo de ingeniería de software del proyecto.Nivel 2: Repetible Garantía de Calidad de Software Metas Meta 1 Las actividades de garantía de calidad de software son planificadas. La administración superior revisa periódicamente las actividades y resultados de garantía de calidad. La función de Garantía de Calidad de Software está implantada en todos los proyectos de software. La independencia debiera: 3.

y Herramientas de auditoria Los miembros del grupo de garantía de calidad de software están entrenados para realizar las tareas asociadas a esta actividad. Un administrador superior. 2. estándares y procedimientos para el proyecto de software. Un grupo puede variar desde un individuo asignado a jornada parcial. Programas de planilla de calculo. Se asigna específicamente un administrador responsable por las actividades de Garantía de Calidad de Software. Las consideraciones sobre cuando implementare un grupo incluyen las actividades y tareas asignadas. Uso efectivo de los métodos y herramientas de garantía de calidad. varios individuos asignados a jornada parcial de diferentes departamentos. – – – – – – Involucramiento del grupo de GCS en las actividades del proyecto. y Comunicación interpersonal http://pragma.ar | CMM N2 . responsabilidades y autoridad de GCS. Programas de bases de datos. están concentrados en actividades de proyecto. hasta varios individuos dedicados a jornada c ompleta. Métodos. Dominio de aplicación del proyecto de sof tware. el tamaño del proyecto. Un grupo es la colección de departamentos administradores e individuos que tienen responsabilidad por un grupo de tareas o actividades. Métodos.41 . que esta concentrado en actividades horizontales de la organización Habilidad 2 Se proveen los recursos y fondos necesarios para la realización de las actividades de Garantía de Calidad de Software. – Roles y responsabilidades del grupo de ingeniería de software y otros grupos relacionados. Ejemplos de capacitación incluyen: – Practicas y habilidades de ingeniería de software. tales como el grupo de garantía de calidad de software. 1. y otros.com. Se dispone de herramientas de apoyo a Garantía de Calidad de Software: Ejemplos de herramientas de apoyo incluyen: – – – – Habilidad 3 Estaciones de trabajo.Garantía de Calidad de Software Nivel 2: Repetible Habilidades para desarrollar Habilidad 1 Existe un grupo de Garantía de Calidad de Software que es responsable de coordinar e implementar las actividades de Garantía de Calidad de Software para el proyecto. como el grupo de ingeniería de procesos de software. la estructura y la cultura de la organización. Algunos grupos. Todos los administradores en la cadena de reporte a la administración superior son conocedores del rol. procedimientos y objetivos de garantía de calidad. q 3. quien es conocedor del rol de GCS y tiene la autoridad de tomar acciones de control. es designado para recibir y actuar sobre los ítems de software no conformes.

El administrador de software. “Administrado y controlado" implica que la versión del producto de trabajo en uso en un momento dado (pasado o presente) es conocida (es decir. y EI grupo de ingeniería de software (incluyendo todos los sub-grupos. 2.Nivel 2: Repetible Habilidad 4 Garantía de Calidad de Software Los miembros del proyecto reciben orientación en los roles. Requisitos de recursos para el grupo de GCS. el producto de trabajo puede ser puesto bajo la disciplina completa de administración de configuración. El plan de Garantía de Calidad de Software es desarrollado en las primeras etapas y en paralelo con la planificación global del proyecto. El plan cubre: 1.ar | CMM N2 . Otras administradores de software. tales como diseño de software y también los lideres de tarea) El plan de Garantía de Calidad de Software es administrado y controlado. Evaluaciones a ser realizadas por el grupo de garantía de calidad http://pragma. y los cambios son incorporados de forma controlada (es decir.com. El plan de Garantía de Calidad de Software es revisado por los grupos e individuos afectados. Responsabilidades y autoridad del grupo de GCS. Programación y financiamiento para las actividades del grupo de GCS del proyecto. EI administrador superior a quien el grupo de GCS reporta problemas de no conformidad. Ejemplos de grupos e individuos afectados incluyen: – – – – – – 3. Actividades a realizar Actividad 1 Se prepara un plan de garantía de calidad para el proyecto de acuerdo a un procedimiento documentado.42 . como es descrita en el área clave de proceso de Administración de Configuración de Software Actividad 2 Las actividades del grupo de GCS se realizan de acuerdo con el plan de GCS. autoridad y valor del grupo de GCS. control de cambios) Si se desea un mayor grado de control que el implicado por "administrado y controlado". EI administrador de software. control de versiones). Un representante de GCS del cliente. Este procedimiento típicamente especifica que: 1. estándares y procedimientos del proyecto 5. 2. responsabilidades. La participación del grupo de GCS en la definición del plan de desarrollo de software. 3. 4.

q Tópicos que debería incluir el plan de desarrollo. Actividades de desarrollo y verificación de productos (por ejemplo ejecución de los casos de prueba). Documentación que se requiere que el grupo de GCS produzca. estándares y procedimientos del proyecto. Procedimientos para documentar y seguir hasta el cierre los problemas de no conformidad Estos procedimientos pueden ser incluidos como parte del plan o vía referencia a otros documentos donde están contenidos. 11. Productos de software y no software (por ejemplo documentos). estándares impuestos por la orden de trabajo). (por ejemplo. y q Otras áreas asignadas por el proyecto EI grupo de GCS verifica que los planes. estándares y procedimientos del proyecto. y Las actividades seguidas para crear el producto – – – 6.ar | CMM N2 .com. 7. q Estándares que son apropiados para uso del proyecto.43 . con respecto a: q Cumplimiento de la política organizacional. 1. 2. Auditorias y revisiones a ser conducidas por el grupo de GCS. EI grupo de GCS provee consultoría y revisión de los planes. 10. Estándares y procedimientos del proyecto a ser usados como base de las auditorias y revisiones del grupo de GCS 8. 9.Garantía de Calidad de Software Nivel 2: Repetible Ejemplos de productos y actividades a ser evaluados incluyen: – Software operacional y de soporte. Procedimientos para documentar y seguir hasta el cierre los problemas de no conformidad Actividad 3 EI grupo de GCS participa en la preparación y revisión del plan de desarrollo de software. Método y frecuencia para proveer retroalimentación al grupo de ingeniería de software y otros grupos relacionados con el software sobre las actividades de GCS. – Productos entregables y no entregables. estándares y procedimientos estén en su lugar y sean utilizables para revisar y auditar el proyecto de software. http://pragma. q Cumplimiento de requisitos y estándares impuestos del exterior.

Refiérase a la característica común Verificando la Implementación en las otras áreas clave de proceso para practicas cubriendo las revisiones y auditorias especificas ejecutadas por el grupo de GCS 3. administradores de software o administradores de proyecto adecuados cuando sea posible. Actividad 7 Las desviaciones identificadas en los productos y actividades son documentadas y manejadas de acuerdo a un procedimiento documentado. y seguidas hasta su conclusión 4. administradores de software o administradores de proyecto se documentan y se presentan al administrador superior designado para recibir ítems no conformes. Los ítems no con formes presentados a la administración superior. Las desviaciones son identificadas. El grupo de GCS revisa productos designados de software para verificar conformidad. Las desviaciones del plan de desarrollo de software. Las correcciones son verificadas. los estándares y procedimientos designados del proyecto no solubles con los lideres de tarea. son revisados periódicamente hasta su solución.44 . Los productos de software entregables son evaluados antes de ser entregados al cliente. Los productos de software son evaluados de acuerdo a los estándares.Nivel 2: Repetible Actividad 4 Actividad 5 Garantía de Calidad de Software El grupo de GCS revisa las actividades de ingeniería de software para verificar conformidad. 1. 2. 3. 2. documentadas y seguidas hasta su conclusión 4. según corresponda. La documentación de los ítems no conformes es administrada y controlada. Las desviaciones del plan son identificadas.com. Las actividades son evaluadas contra el plan de desarrollo y los estándares y procedimientos designados. los estándares y procedimientos designados del proyecto son documentadas y resueltas con los lideres de tarea. EI grupo de GCS conduce revisiones periódicas de sus actividades y hallazgos con el personal de GCS del cliente. Este procedimiento establece típicamente que: Actividad 8 1. procedimientos y requisitos contractuales designados 3. 1. Las correcciones son verificadas Actividad 6 EI grupo de GCS informa periódicamente los resultados de sus actividades al grupo de ingeniería de software. 2.ar | CMM N2 . 4. Las desviaciones del plan de desarrollo de software. http://pragma. documentadas.

Refiérase a la verificación 1 del área clave de proceso de Seguimiento y Control de Proyectos para practicas cubriendo el típico contenido de las revisiones de seguimiento de la administración superior. como estén disponibles mecanismos adecuados de reporte de excepciones.com. EI tiempo entre revisiones debe cumplir con las necesidades de la organización y puede ser tan largo. Numero de auditorias de productos y revisiones de actividades comparadas con el plan Verificación de la Implementación Verificación 1 Las actividades de GCS se revisan con la administración superior en forma periódica. y visión acerca de las actividades del proceso de software a un nivel de abstracción adecuado y de manera oportuna. esfuerzo y financiamiento gastado en las actividades de GCS comparadas con el plan.45 .Garantía de Calidad de Software Nivel 2: Repetible Medición y Análisis Medición 1 Se realizan mediciones y son usadas para determinar el estado de las actividades de GCS. http://pragma. Verificación 2 Las actividades de GCS se revisan con el administrador del proyecto en forma periódica y ante eventos que lo requieran. Trabajo terminada. Refiérase a la verificación 2 del área clave de proceso de Seguimiento y Control de Proyectos para practicas cubriendo el típico contenido de las revisiones de seguimiento de la administración superior. Verificación 3 Expertos independientes revisan periódicamente las actividades del grupo de Garantía de Calidad de Software.ar | CMM N2 . Ejemplo de mediciones incluyen: – – – Cumplimiento de las hitas de GCS (en comparación a la establecido en el plan). EI principal propósito de las revisiones periódicas por la administración superior es generar conciencia de.

46 . el documento de requerimientos de software y el código) Y los ítem identificados con. (por ejemplo. Las practicas que identifican itemes/unidades de configuración especificas están contenidas en las áreas clave de proceso que describen el desarrollo y manutención de cada item/unidad de configuración. Los cambios alas líneas bases y la liberación de productos de software construidos desde la librería de líneas base son controlados sistemáticamente vía las funciones de control de cambios y auditoria de configuración de la administración de configuración de software.Administración de Configuración de Software Un área clave de proceso para el nivel 2: Repetible El propósito de la administración de configuración de software es establecer y mantener la integridad de los productos de software del proyecto a través del ciclo de vida del proyecto de software. controlando sistemáticamente los cambios a la configuración. Los productos de trabajo puestos bajo administración de configuración de software incluyen los productos que son entregados al cliente (por ejemplo. La administración de configuración de software involucra identificar la configuración del software (es decir. http://pragma. una selección de productos de trabajo de software y sus descripciones) en puntos dados del tiempo. Se establece una librería de líneas base de software conteniendo las líneas base de software a medida que ellas son desarrolladas. Esta área clave de proceso cubre las practicas para ejecutar la función de administración de configuración de software. el compilador). o requeridos para crear esos productos de software.com.ar | CMM N2 . y manteniendo la integridad y trazabilidad de la configuración a través del ciclo de vida del software.

http://pragma. lodo el software puede ser considerado como uno ítem de configuración simple. 5. indica que: 1. Los proyectos establecen o tienen acceso a un repositorio para almacenar las unidades de configuración y los registros de ACS asociados. Los ítem que configuración son típicamente descompuestos en componentes de configuración. Las herramientas y procedimientos para accesar este repositorio son referidos como el "sistema de librería de administración de configuración" en esas practicas. controlan y mantienen disponibles productos de trabajo de software selectos. y las componentes dc configuración san típicamente descompuestos en unidades En un sistema de hardware / software. ACS es implementada a través de todo el ciclo de vida del proyecto 3.47 . Esta política. Compromisos para desarrollar Compromiso 1 EI proyecto sigue una política organizacional escrita para la implementación de administración de configuración de software (ACS). compiladores) 4. algunos productos internos seleccionados y algunas herramientas de apoyo designadas usadas en el proyecto(ejemplo.ar | CMM N2 .Administración de configuración de Software Nivel 2: Repetible Metas Meta 1 Las actividades de administración de configuración son planificadas. Las Líneas base de software y las actividades de ACS son auditadas peri6dicamente. Los productos de trabajo que son puestos bajo administración de configuración y son tratados como una entidad simple son referidos como ítem de configuración. típicamente. En esas prácticas el termino ítems/unidades de configuración es usado para referirse a los elementos bajo administración de configuración. Meta 3 Los cambios a los productos de trabajo de software identificados son controlados. Los contenidos de este repositorio son referidos como "Librería de líneas base de software" en esas prácticas. o el software puede ser descompuesto en múltiples ítems de configuración. ACS es implementada para productos entregables externamente. Meta 2 Se identifican. La responsabilidad por ACS en cada proyecto es explícitamente asignada 2.com. Meta 4 Los grupos e individuos afectados son informados del estado y contenido de las líneas base de software.

Las consideraciones sobre cuando implementare un grupo incluyen las actividades y tareas asignadas.ar | CMM N2 . Un grupo puede variar desde un individuo asignado a jornada parcial. el tamaño del proyecto.com. Autoriza el establecimiento de líneas base para el software y la identificaci6n de itemes/unidades de configuración. la estructura y la cultura de la organización Algunos grupos. La creación y administración de la librería de lineas base de software del proyecto. hasta varios individuos delicados a jornada completa. Ejemplos de grupos afectados incluyen: – – – – – – – Habilidad 2 Garantía de calidad de hardware. Ingeniería de manufactura. Representa los intereses del administrador del proyecto y de todos los grupos que pueden ser afectados por cambios en las Líneas base del software. Existe un grupo que es responsable de coordinar e implementar ACS para el proyecto.48 . Administración de configuración de software Administración del contrato. Ingeniería de sistemas. Un grupo es la colección de departamentos. tales como el grupo de garantía de calidad de software. estándares y procedimientos de ACS. y apoyo de documentación 3. un comité de control de configuraci6n de software-CCCS) EI CCCS: 1. Ingeniería de software (incluyendo todos los sub-grupos. y otros. como el grupo de ingeniería de procesos de software. Ingeniería de hardware. Garantía de calidad de Software. 2. que esta concentrado en actividades horizontales de la organización Este grupo coordina e implementa: 1. varios individuos asignados a jornada parcial de Administración de diferentes departamentos. tales como diseño de software). Autoriza la creación de productos desde la librería de líneas base del software. 2. Administración de configuración de hardware. http://pragma. El desarrollo. administradores e individuos que tienen responsabilidad por un grupo de tareas o actividades. 4. Revisa y autoriza cambios en las líneas base del software. manutención y distribución de los planes. Pruebas de sistema.Nivel 2: Repetible Administración de configuración de Software Habilidades para desarrollar Habilidad 1 Existe o se establece un comité que tiene la autoridad para administrar las líneas base de software del proyecto (es decir. están concentrados en actividades de proyecto.

Ejemplos de otros grupos relacionados con el software incluyen: – Garantía de calidad de software. La producción y distribución de informes de ACS Se proporcionan los recursos y fondos necesarios para realizar las actividades de ACS. estándares y procedimientos de ACS. y – Herramientas de administración de configuración Habilidad 4 Los miembros del grupo de ACS están entrenados en los objetivos. La creación de productos des de la librería de lineas base de software 7.ar | CMM N2 .com.Administración de configuración de Software 3. estándares y procedimientos de ACS a ser seguidos por las actividades de ACS dentro del grupo de ingeniería de software y otros grupos relacionados con el software.49 . – Programas de bases de datos. Se hacen disponibles herramientas para apoyar las actividades de ACS. Se designa un administrador con responsabilidad especifica por ACS. Ejemplos de capacitación incluyen: – – Habilidad 5 Métodos. mantener o usar un proceso de software Habilidad 3 4. La actualización de las líneas base de software 6. y – Apoyo de documentación Ejemplos de capacitación incluyen: – Métodos. procedimientos y métodos para ejecutar sus actividades de ACS. responsabilidades y autoridad del grupo de administración de configuración http://pragma. Ejemplos de herramientas de soporte incluyen: – Estaciones de trabajo. El registro de acciones de ACS 8. 1. Nivel 2: Repetible La identificación del conjunto de productos de trabajo que serán sometidos a ACS Un producto de trabajo es cualquier artefacto derivado de definir. La administración del acceso a la librería de lineas base de software 5. 2. y Herramientas de ACS Los miembros del grupo de ingeniería de software y otros grupos relacionados con el software están entrenados para ejecutar sus actividades de ACS. y – El rol.

Este procedimiento típicamente especifica que: 1. Si se desea un mayor grado de control que el implicado por "administrado y controlado". Este plan es desarrollado en las etapas tempranas del proyecto y en paralelo con la planificación global de éste.com. Las actividades de ACS a ser realizadas. EI plan de administración de configuración es administrado Y controlado. la programación de actividades. "Administrado y controlado" implica qué la versión del producto de trabajo en uso en su momento dado (pasado o presente) es conocida (es decir. como es descrita en el área clave de proceso de Administración de Configuración de Software.50 . Los requisitos de ACS y las actividades a ser realizadas por el grupo de ingeniería de software y por otros grupos relacionados Se establece un sistema de librería de administración de configuración como un repositorio de las lineas base de software. Diferencias en los niveles de control requeridos para sistemas de software solamente vs. control de versiones). herramientas y medios computacionales) 2. Proporciona almacenamiento y recuperación de las unidades de configuración 3. control de cambios). el control es mas ajustado a medida que el producto va madurando). EI plan cubre: Actividad 3 1. es usado como la base para realizar las actividades de ACS. Actividad 2 Un plan de ACS documentado Y aprobado. las responsabilidades asignadas y los recursos requeridos (incluyendo personal. sistemas que incluyen tanto hardware como software 2. Apoya múltiples niveles de control de ACS. Ejemplos de situaciones llevando múltiples niveles de control incluyen: – – Diferencias en el nivel de contra! necesario en diferentes tiempos en el ciclo de vida (por ejemplo.Nivel 2: Repetible Administración de configuración de Software Actividades a realizar Actividad 1 Para cada proyecto se prepara un plan de ACS de acuerdo a un procedimiento documentado. y los cambios son incorporados de forma controlada (es decir. 3. el producto de trabajo puede ser puesto bajo la disciplina completa de administración de configuración. 2. Permite compartir y transferir las unidades de configuración entre los grupos afectados y dentro de los niveles de control de la librería http://pragma. EI plan de administración de configuración es revisado por todos los grupos afectados.ar | CMM N2 . Esta librería: 1.

4. Se especifica el punto en su desarrollo en que cada item/unidad es puesta bajo administración de configuración. 9. Permite el almacenamiento y recuperación de versiones de archivo de los itemes/unidades de configuración.com. Ejemplos de productos de trabajo de software que pueden ser identificados como itemes/unidades de configuración incluyen: – – – – – Procedimientos de prueba de software. Los ítems/unidades de configuraci6n son seleccionadas de acuerdo a un criterio documentado. 1. estándares o procedimientos) Requerimientos de software. realización y recuperación de los registros de administración de configuración. Construcciones del sistema de software para las actividades de prueba. 3. Ayuda en el uso de estándares de producto para los itemes/unidades de configuración.ar | CMM N2 . Se asigna identificadores únicos a los itemes/unidades de configuración. y Recuperación de errores de la librería Se identifican los productos de software a ser puestos bajo administración de configuración. Unidades de código de software. Permite el almacenamiento. Ayuda a asegurar una correcta creación de los productos desde la librería de lineas base del software.Administración de configuración de Software Nivel 2: Repetible 4. planes. Se especifican las lineas base a fa que pertenece cada item/unidad de configuración. Compiladores. 6. revisados. 2. Las solicitudes de cambios requeridos y los reportes de problemas para todos los itemes/unidades de configuración son iniciados. Proporciona la manutención de la estructura y contenidos de la librería. Apoya la producción de informes de administración de configuración. Se especifican las características de cada item/unidad de configuración. registrados.51 . 5. Se asignan responsables por cada item/unidad de configuración. Ejemplos de funciones de manutención de la librería incluyen: – – Actividad 4 Respaldo/restauración de archivos de la libraría. 8. 5. 6. Construcciones del sistema de software para entrega al cliente o usuarios finales. http://pragma. aprobados y seguidos de acuerdo a un procedimiento documentado. Diseño de software. y – Otras herramientas de soporte – – – Actividad 5 Documentación relacionada con el proceso (par ejemplo. 7.

tanto para uso interno y externo.Nivel 2: Repetible Actividad 6 Administración de configuración de Software Los cambios en las lineas base son controlados de acuerdo a un procedimiento documentado. son construidos solo a partir de los itemes/unidades de configuración en la librería de lineas base de software. Actualizar la librería de lineas base de software. http://pragma. Las unidades de configuración son registradas a la entrada y la salida de forma que se mantenga la conformidad e integridad de la librería de lineas base de software. 3. Los productos construidos desde las lineas base de software.52 . Se realizan revisiones y/o pruebas de regresión para asegurar que los cambios no produzcan efectos inesperados en la línea base. Este procedimiento típicamente especifica que: Actividad 8 1. El CCCS autoriza la creación de productos desde la librería de lineas base de software.com. Ejemplos de pasos de registro de entrada / salida incluyen: – – – – – Actividad 7 Verificar que las revisiones están autorizadas. Este procedimiento típicamente especifica que: 1. 2. y Archivar la línea base de software reemplazada Los productos son creados desde la librería de lineas base y su liberaci6n es controlada de acuerdo a un procedimiento documentado. 2. Crear un log de cambios. Las acciones de administración de configuración son almacenadas con el detalle suficiente para que el contenido y estado de cada item/unidad de configuración sea conocido y para que las versiones previas puedan sean recuperadas.ar | CMM N2 . EI estado de las unidades de configuración es almacenado de acuerdo a un procedimiento documentado. Se mantiene la historia y el estado actual de cada item/unidad de configuración. Este procedimiento típicamente especifica que: 1. Mantener una copia de los cambios. 2. Solo los itemes/unidades de configuración aprobadas por el CCCS son incorporados en la línea base del software.

5.ar | CMM N2 . Se sigan las acciones a tomar a partir de las auditorias hasta su cierre Medición y Análisis Medición 1 Se realizan mediciones y son usadas para determinar el estado de las actividades de ACS. Se informe los resultados de las auditorias a los administradores del proyecto. "esfuerzo gastado. Se verifique la completitud y correctitud del contenido de las librerías de administración de configuración. 2. – Resumen y estado de las solicitudes de cambios. 6.53 . Historia de revisiones de los Itemes/unidades de configuración – – – – – Actividad 10 Estado de la línea base de software. Resumen y estado de los reportes de los problemas (incluyendo reparaciones).Administración de configuración de Software Actividad 9 Nivel 2: Repetible Se desarrollan informes estándares que documentan las actividades de ACS y los contenidos de las lineas base. Se evalué la integridad de las lineas base de software. Existe una adecuada preparación para las auditorias. 4. 3. Este procedimiento típicamente especifica que: 1. Se revise la estructura y medios del sistema de librería de administración de configuración. y se hacen disponibles a los grupos e individuos afectados.com. y Trabaja terminado. y Resultados de las auditorias de lineas base realizadas Se conducen auditorias de las lineas base del software de acuerdo a un procedimiento documentado. Ejemplos de informes incluyen: – Minutas de reuniones del CCCS. Ejemplos de mediciones incluyen: – – – Numero de solicitudes de cambios procesadas por unidad de tiempo Cumplimiento de los hitos de las actividades de ACS en comparación al plan. Se verifique la aplicación de los estándares y procedimientos de ACS aplicables. y costa de las actividades de ACS http://pragma. Resumen de los cambios hechos alas lineas base de software. 7.

El principal propósito de las revisiones periódicas por lo administración superior es generar conciencia de.Nivel 2: Repetible Administración de configuración de Software Verificación de la Implementación Verificación 1 Se revisan las actividades de ACS con la administración superior en forma periódica. las revisiones y/o auditorias verifican: 1.ar | CMM N2 . Conformidad con los estándares y procedimientos de: q EI grupo de ACS. y q Otros grupos relacionados con el software La ocurrencia de auditorias periódicas de las lineas base de software http://pragma.54 . Refiérase al área clave de procesos de Garantía de Calidad de Software Como mínimo. q EI CCCS q EI grupo de ingeniería de software. Verificación 3 El grupo de Administración de la Configuración audita en forma periódica las líneas base del software para verificar que están conformes a la documentación que las define. Refiérase a la verificación 2 del área clave de proceso de Seguimiento y Control de Proyectos para practicas cubriendo el típico contenido de las revisiones de seguimiento de la administración superior. 2. Refiérase a la verificación 1 del área clave de proceso de Seguimiento y Control de Proyectos para practicas cubriendo el típico contenido de las revisiones de seguimiento de la administración superior Verificación 2 Se revisan las actividades de ACS con el administrador del proyecto en forma periódica y ante eventos que lo requieran. Verificación 4 El grupo de Garantía de Cali dad de Software revisa y/o audita las actividades y productos de trabajo de ACS e informa los resultados. y visión acerca de las actividades del proceso de software a un nivel de abstracción adecuado y de manera oportuna EI tiempo entre revisiones debe cumplir con las necesidades de la organización y puede ser tan largo. como estén disponibles mecanismos adecuados de reporte de excepciones.com.