Practicas CMM L2 (Espanol)

Administracin de Requisitos
Un rea clave de proceso para el nivel 2: Repetible

El propsito de la administracin de requisitos es establecer un entendimiento comn entre el cliente y
el proyecto de software, acerca de los requisitos del cliente que sern abordados por el proyecto de
software.
La administracin 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 ingeniera de sistemas, el
grupo de marketing, otra organizacin interna, o un cliente externo. El acuerdo cubre requisitos tcnicos
y no tcnicos (por ejemplo: fechas de entrega). El acuerdo forma la base para estimar, planificar,
ejecutar y seguir las actividades del proyecto de software a travs del ciclo de vida del software.
La asignacin 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 ingeniera de software (por
ejemplo: el grupo de ingeniera de sistemas), y adems el grupo de ingeniera de software puede no
tener control directo sobre esta asignacin. Dentro de las restricciones del proyecto, el grupo de
ingeniera de software toma las acciones necesarias para asegurar que los requisitos de sistema
asignados al software -por los que son responsables de abordar- estn documentados y controlados.
Para lograr este control, el grupo de ingeniera 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
Nivel 2: Repetible
Metas
Meta 1
Los requisitos del sistema asignados al software son controlados para establecer
una lnea base para uso en Administracin e ingeniera 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 poltica organizacional escrita, para la administracin

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
estn 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 anlisis de
requisitos de software elabora y refina los requisitos asignados 10 que produce requisitos de
software que estn documentados
Esta poltica tpicamente 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,
ingeniera de software (incluyendo todos los sub-grupos, tales como diseo de software),
ingeniera de sistemas, garanta de calidad de software,
administracin de configuraciones de software, y
soporte de documentacin.
Nivel 2: Repetible
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 anlisis y la asignacin de los requisitos del sistema no son responsabilidades del grupo
de ingeniera de software, pero si son pre-requisitos para su trabajo.
Esta responsabilidad cubre:

1. Administrar y documentar los requisitos del sistema y su asignacin a travs
de la vida del proyecto.
2. Efectuar cambios a los requisitos del sistema y su asignacin.
Habilidad 2
Los requisitos asignados son documentados.

Los requisitos asignados incluyen.
1.
Los requisitos no tcnicos que afectan y determinan las actividades del

proyecto de software (ejemplo, acuerdos, condiciones, y trminos
contractuales).
Ejemplos de acuerdos, condiciones y trminos contractuales incluyen:
productos a ser entregados,
fechas de entrega, y
metas
2.
Requisitos tcnicos del software,

Ejemplos de tcnicos incluyen:
funciones del usuario final, operador, soporte o integracin,
requisitos de desempeo,
restricciones de diseo,
lenguaje de programacin, y
requisitos de interfaz
3.
Habilidad 3
Nivel 2: Repetible
Los criterios de aceptacin que sern usados para validar que el producto
entregado satisfaga los requisitos
Se proporcionan los recursos y el financiamiento necesarios para la

administracin de los requisitos asignados.
1.
Aquellas personas que tienen experiencia y tienen experiencia en el dominio

de aplicacin y en ingeniera de software son asignados para administrar los
requisitos
2.
Herramientas de apoyo a la administracin de requisitos como planillas de

calculo, herramientas de administracin de configuracin, etc.
Ejemplos de herramientas de soporte incluyen:
programas de planilla de calculo,

herramientas para administracin de configuraciones,
herramientas para trazabilidad. y
herramientas para administracin de las pruebas
Habilidad 4
Los miembros del grupo de ingeniera de software y de otros grupos

relacionados, son entrenados para realizar sus actividades de
administracin de requisitos.
Ejemplos de reas de capacitacin son:
Mtodos, estndares, y procedimientos usados por el proyecto, y

el dominio de aplicacin
Actividades a realizar
Actividad 1
EI grupo de ingeniera 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.
factibles y apropiados para ser implementados en software,
clara y apropiadamente establecidos,
consistentes un os con otros, y
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
Nivel 2: Repetible
4.
Los compromisos resultantes de la asignacin de requisitos son revisados y

negociados con los grupos afectados.
Ejemplos grupos afectos incluyen:
ingeniera de software (incluyendo todos los sub-grupos. tales como diseo de software),
estimacin de software,
ingeniera de sistema,
pruebas de sistema,
garanta de calidad de software,
Administracin de configuraciones de software,
Administracin de subcontratos, y
soporte de documentacin
Refirase a la actividad del rea clave de proceso de Panificacin del Proyecto de

Software para practicas que cubren la negociacin de acuerdos.
Actividad 2
EI grupo de ingeniera 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 versin del producto de trabajo en uso en un
momento dado (pasado o presente) es conocida (es decir "control de versin"), 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
administracin de configuraciones, tal como es descrito en el rea clave de proceso
Administracin 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 segn sea apropiado.
q
Cambios a acuerdos hechos a individuos y grupos externos a la

organizacin, son revisados con administracin superior
Nivel 2: Repetible
Refirase a la actividad 4 del rea clave de proceso Planificacin del Proyecto de Software y
la actividad 3 del rea clave de proceso Supervisin y Control del Proyecto de Software, para
ver practicas que cubren los compromisos hechos externos a la organizacin
Cambios a acuerdos internos a la organizacin son negociados con

los grupos afectados.
Refirase a las actividades 5, 6, 7 Y 8 del rea clave de proceso Supervisin y Control del
Proyecto de Software para ver practicas que cubren la negociacin de cambios a acuerdos.
2.
Los cambios que se deben hacer en los planes, productos y actividades,

producto de cambios en los requisitos asignados son:
q
identificados,
evaluados,
evaluados en riesgo,
documentados,
planificados,
comunicados a los grupos e individuos afectados, y
seguidos hasta su finalizacin
Medicin y Anlisis
Medicin 1
Se hacen mediciones y son usadas para determinar el estado de las

actividades de administracin de requisitos.
Algunas de estas mediciones son:
Estado de cada uno de los requisitos identificados.

Cambios en actividades asociadas a los requisitos
Numero total de cambios a los requisitos asignados, y
Total de cambios propuestos, cambios aprobados y cambios incorporados a la lnea base
del sistema
Nivel 2: Repetible
Verificacin de la Implementacin
Verificacin 1
Las actividades para administrar los requisitos asignados son revisadas

peridicamente con la administracin superior.
EI propsito fundamental de las revisiones de la administracin superior es proveer
conciencia de y visin de las actividades del proceso de software, con un adecuado nivel de
abstraccin y en forma oportuna. EI tiempo entre revisiones debe estar de acuerdo a las
necesidades de la organizacin y pueden ser distanciados, tanto como estn disponibles
mecanismos adecuados de informe de excepciones.
Refirase a la verificacin 1 del rea clave de proceso Supervisin y Control del Proyecto de
Software para practicas cubriendo el contenido tpico de revisiones de seguimiento de la
administracin superior
Verificacin 2
Las actividades para administrar los requisitos asignados son revisadas

con el jefe del proyecto en forma peridica y como respuesta a eventos.
Refirase a la verificacin 2 del rea clave de proceso Supervisin y Control del Proyecto de
Software para practicas cubriendo el contenido tpico de revisiones de seguimiento de la
administracin del proyecto
Verificacin 3
EI grupo de garanta de calidad revisa y/o audita las actividades de

administracin de requisitos e informa los resultados.
Como mnimo, esas revisiones y/o auditorias verifican que:
1.
Los requisitos son revisados, y los problemas son resueltos antes de que el
equipo de ingenieros se comprometa a su realizacin.
2.
Se deben revisar apropiadamente los planes, productos y actividades,

cuando los requisitos asignados cambian.
3.
Se auditan los cambios en los compromisos negociados producto de los

cambios en los requisitos.
Planificacin del Proyecto de Software

El propsito de la Planificacin del Proyecto de Software es establecer planes razonables para realizar
las tareas de ingeniera de software y administracin del proyecto de software.
La Planificacin del Proyecto de Software involucra desarrollar estimaciones para el trabajo a ejecutar,
establecer los acuerdos necesarios, y definir el plan para desarrollar el trabajo.
La planificacin 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 Administracin de
Requisitos). El proceso de Planificacin del Proyecto de Software incluye pasos para estimar el tamao
de los productos y recursos requeridos, producir la programacin, identificar y evaluar los riesgos de
software y negociar compromisos. Al iterar estos pasos puede ser necesario crear el plan para el
proyecto de software (es decir, el plan de desarrollo de software).
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, restricciones, y
capacidades del proyecto de software.
Nivel 2: Repetible
Metas
Meta 1
Las estimaciones de software son documentadas para ser usadas en la

planificacin y seguimiento del proyecto de software.
Meta 2
Las actividades y los compromisos del proyecto de software son planificados y

documentados.
Meta 3
Los grupos y personas involucradas aprueban sus compromisos relacionados al


Compromiso 1
Se designa un administrador del proyecto de software para ser responsable

por la negociacin de compromisos y ejecutar el plan de desarrollo del
Compromiso 2
EI proyecto sigue una poltica organizacional de planificacin del proyecto

de software.
Esta poltica tpicamente especifica que:
1.
Los requisitos de sistema asignados al software deben ser usados como las
bases para la planificacin del proyecto de software
Refirase a la actividad 2 del rea clave de proceso Administracin de Requisitos
2.
3.
Los compromisos del proyecto de software se negocian entre:

q
el administrador del proyecto,
el administrador del proyecto de software, y
los otros administradores de software
La participacin de otros grupos de ingeniera en las actividades de

desarrollo de software debe ser negociada con fichas grupos y luego
documentada.
Ejemplos de otros grupos de ingeniera incluyen:
ingeniera de sistemas
ingeniera de hardware, y
pruebas de sistema
Nivel 2: Repetible

4.
Los grupos involucrados revisan del proyecto de software:

q las estimaciones de tamao del software,
q las estimaciones de esfuerzo y costo,
q la programacin, y
q otros acuerdos.
Ejemplos de grupos afectados incluyen:
ingeniera de software (incluyendo todos los sub-grupos, tales como dise de software),
ingeniera de sistema,
pruebas de sistema,
administracin de configuraciones de software,
administracin de contrato, y
soporte de documentacin
5.
La administracin superior revisa todos los compromisos hechos con

individuos o grupos externos a la organizacin.
6.
EI plan de desarrollo de software del proyecto es administrado y controlado

EI termino "plan de desarrollo de software" es usado a travs de esas practicas para referirse
al plan global para administrar el proyecto de software. EI uso de la terminologa "desarrollo"
no pretende excluir los proyectos de mantenimiento o soporte de s oftware, y debe ser
apropiadamente interpretada en el contexto de cada proyecto.
"Administrado y controlado" implica que la versin del producto de trabajo en uso en un

momento dado (pasado o presente) es conocida (es decir "control de versin), 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
administracin de configuraciones, tal como es descrito en el rea clave de proceso
Administracin de Configuraciones de Software
Nivel 2: Repetible

Habilidad 1
Existe un documento aprobado de orden de trabajo para el proyecto de

software.
1.
EI documento de orden de trabajo cubre:

q
Alcance del trabajo
Metas tcnicas y objetivos,
Identificacin de clientes y usuarios finales,

Los usuarios finales a que se refieren estas practicas son los usuarios finales o
representantes de usuarios finales designados por el cliente.
Estndares impuestos,
Responsabilidades asignadas,
Metas, restricciones de costos y programacin,
Dependencias entre el proyecto de software y otras organizaciones,

Ejemplos de otras organizaciones incluyen:
el cliente,
subcontratistas, y
socios.
2.
3.
Habilidad 2
Restricciones de recursos y metas, y
Otras restricciones y metas para el desarrollo y/o mantenimiento.
EI documento de orden de trabajo es revisado por:

q
EI administrador del proyecto global,
EI administrador del proyecto de software,
Los grupos afectados
EI documento de orden de trabajo es administrado y controlado.
Se asignan responsabilidades para desarrollar el plan de proyecto.

1.
EI administrador del proyecto de software, directamente o por delegacin,

coordina la planificacin del proyecto.
2.
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.
Ejemplos de productos de trabajo de software incluyen:
Producto de trabajo para entrega a un cliente externo o usuario final, segn corresponda
Producto de trabajo para uso de otros grupos de ingeniera; y
Producto de trabajo principales para uso interno del grupo de ingeniera de software.
Nivel 2: Repetible
Habilidad 3

Se destinan los recursos y fondos adecuados para realizar la planificacin
del proyecto.
1.
Cuando es factible, personas con experiencia, que tengan conocimiento

experto en el dominio de aplicacin del proyecto de software bajo
planificacin, son asignados para el desarrollo del plan del proyecto.
2.
Se dejan disponibles herramientas de apoyo a la planificacin de proyectos

Ejemplos herramientas de soporte incluyen:
Habilidad 4
programas de planilla de calculo,

modelos de estimacin, y
programas de planificacin y programacin
Los administradores, ingenieros de software y otras personas involucradas

en la planificacin del proyecto de software, son entrenadas en los
procedimientos de estimacin y planificacin aplicables a su rea de
responsabilidad.
Actividad 1
EI grupo de ingeniera de software participa en el equipo que realiza la

propuesta del proyecto.
1.
2.
El grupo de ingeniera de software es involucrado en:

q
preparacin y entrega de la propuesta,
discusiones de clarificacin, y
negociaciones de cambios de acuerdos que afectan al proyecto de

software
El grupo de ingeniera de software revisa los acuerdos propuestos de

proyecto
Ejemplos de acuerdos de proyecto incluyen:
los objetivos y metas tcnicas del proyecto;
el sistema y la solucin tcnica de software;

el presupuesto del software, programacin y recursos; y
los estndares y procedimientos de software
Actividad 2
La planificacin del proyecto de software es iniciada en las primeras

etapas, y en paralelo, son la planificacin global del proyecto.
Actividad 3
EI grupo de ingenieros de software participa con otros grupos involucrados

en la planificacin global del proyecto, a lo largo de la vida del proyecto.
1.
EI grupo de ingeniera de software revisa los planes de nivel de proyecto.
Nivel 2: Repetible
Actividad 4
Los compromisos adquiridos por personas o grupos externos a la

organizacin son revisados con la administracin superior de acuerdo a un
procedimiento documentado.
Actividad 5
Se identifica o define un ciclo de vida de software con etapas predefinidas

de un tamao manejable.
Ejemplos de ciclos de vida de software incluyen:
cascada,
cascada traslapada.
espiral.
construccin serial. y
cascada simple prototipo / traslapada
Actividad 6
EI plan del proyecto de software es realizado de acuerdo a un

1.
2.
El plan de desarrollo de software esta basado en:

q
Estndares del cliente,
Estndares del proyecto,
EI documento de orden de trabajo (aprobado) y
los requisitos de software.
Los planes para grupos relacionados con el software y otros grupos de

ingeniera involucrados en las actividades de! grupo de ingeniera de
software son negociados con esos grupos, los esfuerzos de soporte son
presupuestados, y los acuerdos documentados.
Ejemplos de grupos relacionados con el software incluyen:
Garanta de calidad de software,

administracin de configuraciones de software, y
soporte de documentacin.
Ejemplos de otros grupos de ingeniera incluyen:
ingeniera de sistemas,
ingeniera de hardware, y
pruebas de sistema.
3.
Los planes para la participacin de! grupo de ingeniera de software en

actividades de otros grupos relacionados con el software y otros grupos de
ingeniera son negociados con esos grupos, los esfuerzos de soporte son
presupuestados, y los acuerdos documentados.
Nivel 2: Repetible

4.
Actividad 7
EI plan de desarrollo de software es revisado por:

q
el administrador del proyecto de software,
otros administradores de software, y
otros grupos involucrados.
El plan del proyecto de software es documentado.

En las practicas claves, este plan o coleccin de planes es mencionada como el plan de
desarrollo de software.
Refirase a la actividad 1 de las reas claves de proceso Supervisin y Control del Proyecto
de Software para practicas concernientes al uso del plan de desarrollo de software del
proyecto.
5.
EI plan de desarrollo de software del proyecto cubre:

q
El propsito, mbito, metas y objetivos del proyecto de software.
Seleccin de un ciclo de vida de software
Identificacin de los procedimientos, mtodos y estndares de desarrollo

y/o mantenimiento de software seleccionados.
Ejemplos de estndares y procedimientos incluyen:
planificacin del proyecto de software,

administracin de configuraciones de software,
diseo de software,
seguimiento y resolucin de problemas, y
mediciones de software.
Identificacin de los productos de trabajo a ser desarrollados.
Estimaciones de tamao de los productos de trabajo y cualquier cambio

a los productos de trabajo de software.
Estimacin del esfuerzo y costo del proyecto.
Uso estimado de recursos crticos
Cronogramas del proyecto, incluyendo identificacin de hitos y

revisiones.
Identificacin y evaluacin de los riesgos de software del proyecto.
Planificacin del uso de las facilidades de ingeniera de software y

herramientas de apoyo.
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.
Refirase a la actividad 4 del rea clave de proceso Administracin de configuraciones de
software.
Actividad 9
Las estimaciones del tamao de los productos de software (o de los

cambios en ellas) se realizan de acuerdo a un procedimiento documentado.
Este procedimiento tpicamente especifica que:
1.
Se realizan estimaciones de tamao sobre los principales productos de

trabajo de software.
Ejemplos de estimaciones de tamao de software incluyen:
Puntos de funcin,
puntos de caractersticas,
lneas de cdigo,
numero de requisitos, y
numero de paginas.
Ejemplos de tipos de productos de trabajo y actividades para los cuales se hacen

estimaciones incluyen:
software operacional y de soporte,

productos de trabajo entregables y no entregables,
productos de trabajo de software y "no-software" (por ejemplo documento,), y
actividades para desarrollar, verificar y validar los productos de trabajo.
2.
Los productos de trabajo de software son descompuestos hasta la

granularidad requerida para cumplir con los objetivos de estimacin.
3.
Se usan datos histricos cuando se dispone de ellos.
4.
Los supuestos de las estimaciones de tamao son documentados.
5.
Las estimaciones de tamao son documentadas, revisadas y luego

acordadas.
Ejemplos de grupos e individuos que revisan y acuerdan las estimaciones de tamao
incluyen:

el administrador del proyecto de software, y
los otros administradores de software
Nivel 2: Repetible
Actividad 10
Las estimaciones de esfuerzo y costos se derivan de acuerdo a un

Este procedimiento tpicamente establece que:
1.
Las estimaciones de esfuerzos y costos del proyecto estn relacionadas alas

estimaciones de tamao de los productos de trabajo de software (o el
tamao de los cambios)
2.
Se utilizan datos de productividad (histricos y/o reales) para las

estimaciones cuando estn disponibles; las fuentes de informacin y la lgica
para esos datos son documentadas.
q
Los datos de productividad y costos son de proyectos de la organizacin

cuando sea posible.
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.
Actividad 11
gastos de esfuerzo directo,

gastos generales,
gastos de viajes, y
costos de uso de computadores.
Las estimaciones de esfuerzo, personal y costos se basan en la experiencia

pasada.
q
Debieran usarse proyectos similares cuando sea posible.
Se derivan las fases en el tiempo de las actividades.
Se preparan estimaciones de las distribuciones del esfuerzo, personal, y

costos.
Las estimaciones de los recursos computacionales crticos son realizadas

de acuerdo a un procedimiento documentado.
Los recursos computacionales crticos pueden ser en el ambiente del servidor. en el ambiente
de pruebas e integracin, en el ambiente operacional, o en cualquier combinacin de ellos.

1. Se identifican los recursos computacionales crticos.
Ejemplos de recursos computacionales crticos incluyen:
capacidad de memoria del computador,
usa del procesador del computador, y

capacidad del canal de comunicaciones
Nivel 2: Repetible
2. La estimacin de recursos crticos esta relacionada a las estimaciones de:

q
el tamao de los productos de trabajo de software,
la carga de procesamiento operacional, y
el trafico de las comunicaciones.
3. Las estimaciones de recursos computacionales crticos son documentadas,

revisadas y acordadas
Actividad 12
La programacin del proyecto de software se obtiene de acuerdo a un

Este procedimiento especifica tpicamente que:
1. La programacin de software esta relacionada a:
q
las estimaciones de tamao del software, y
las estimaciones de esfuerzo y costos
2. La programacin de software se basa en la experiencia pasada

q
Se usan proyectos similares cuando es posible
3. La programacin de software se acomoda alas fechas impuestas de hitos,

fechas de dependencias criticas, y otras restricciones.
4. Establece claramente los hitos, dependencias criticas de actividades y otras
restricciones.
5. Los supuestos hechos al derivar la programacin son documentados.
6. La programacin del proyecto es documentada, revisada y acordada.
Actividad 13
Los riesgos asociados al costo, recursos, programacin y aspectos

tcnicos del proyecto son identificados, evaluados y documentados.
1. Los riesgos son analizados y priorizados de acuerdo a su impacto potencial
en el proyecto.
2. Se identifican contingencias para los riesgos.
Ejemplos de contingencias incluyen:
holguras en las fechas,

equipos de trabajo alternativos, y
planes alternativos de adquisicin de recursos computacionales
Nivel 2: Repetible
Actividad 14
Se preparan planes para las facilidades de ingeniera de software y

herramientas de soporte del proyecto.
1.
Las estimaciones de requerimientos de capacidad para esas facilidades y

herramientas de soporte estn basadas en las estimaciones de tamao de
los productos de trabajo de software y otras caractersticas.
Ejemplos de facilidades de desarrollo de software y herramientas de soporte incluyen:
computadores y perifricos para desarrollo de software,
perifricos computadores para prueba de software,

software del medio ambiente del computador destino, y
otro software de soporte
Actividad 15
2.
Se asignan responsabilidades y se negocian los acuerdos para procurar

desarrollar esas facilidades y herramientas de soporte.
3.
Los planes son revisados por todo todos los grupos afectados.
Se registran los datos de planificacin de software.

1.
La informacin registrada incluye las estimaciones y la informacin asociada

necesaria para reconstruir las estimaciones y evaluar su razonabilidad.
2.
Los datos de planificacin de software son administrados y controlados.
Medicin y Anlisis
Medicin 1
Se hacen mediciones y son usadas para determinar el estado de las

actividades de planificacin de proyectos de software.
Ejemplos de estas mediciones son:
Cumplimientos de los hitos del proyecto en relacin con la planificacin,
Trabajo realizado, esfuerzo gastado y fondos utilizados en relacin con la planificacin
Verificacin 1
Las actividades contenidas en la planificacin son revisadas en conjunto

con la administracin superior peridicamente.
EI propsito principal de las revisiones peridicas de la administracin superior es proveer el
conocimiento y visin sobre las actividades del proceso de software a un nivel de abstraccin
apropiado y oportuno en el tiempo EI tiempo entre revisiones debe cumplir con las
necesidades de la organizacin y puede ser tan largo como mecanismos para reporte de
excepciones estn disponibles.
Verificacin 2
Verificacin 3
Nivel 2: Repetible
1.
Se revisan aspectos tcnicos, costos, personal y el cumplimiento de la

programacin.
2.
Se abordan conflictos y problemas no solubles en niveles mas bajos
3.
Se abordan los riesgos del proyecto.
4.
Se asignan tems de accin, se revisan y se supervisan hasta cerrarlos
5.
Se prepara un informe resumen de cada reunin y se distribuye a los grupos

e individuos afectados
Las actividades para la planificacin de proyectos de software son

revisadas con el administrador del proyecto, tanto peridicamente como en
respuesta a eventos.
1.
Los grupos afectados estn representados
2.
EI estado real del proyecto y los resultados obtenidos se revisan contra los
documentos de definicin de trabajo y de requisitos asignados
3.
Las dependencias entre los distintos grupos son abordadas
4.
Los conflictos y problemas no solubles en los niveles inferiores son

abordados.
5.
Los riesgos del proyecto son revisados.
6.
Se asignan tems de accin, se revisan, y si siguen hasta cerrarlos
7.
e prepara un informe resumen de cada reunin y es distribuido a los

individuos y grupos afectados.
EI grupo de garanta de calidad del software revisa y audita las actividades

y productos de trabajo de la planificacin de proyectos de software e
informa los resultados.
Refirase al rea clave de proceso de Garanta de Calidad de Software.
Como mnimo la auditoria revisa:

1.
las actividades de estimacin y planificacin de software,
2.
las actividades de revisin y toma de compromisos de proyecto,
3.
las actividades de preparacin del plan de desarrollo de software,
4.
los estndares usados para preparar el plan de desarrollo de software,.
5.
el contenido del plan de desarrollo de software.
Seguimiento y Control del Proyecto de

Software
EI propsito del Seguimiento y Control del Proyecto de Software es proporcionar una adecuada visin
del avance real del proyecto de forma que los administradores puedan tomar acciones efectivas cuando
el rendimiento del proyecto de software se desva significativamente del plan de software.
EI Seguimiento y Control del Proyecto de Software involucra seguir y revisar los logros y resultados en
contraste alas estimaciones, compromisos y planes documentados, y ajustar el plan de acuerdo a los
logros y resultados reales.
Se usa un plan documentado para el proyecto de software (es decir, el plan de desarrollo de software,
como se describi en el rea clave de proceso Planificacin del Proyecto de Software) como la base
para seguir las actividades de software, comunicar su estado, y revisar los planes. Las actividades de
software son monitoreadas por la administracin. El progreso es determinado principalmente
comparando el tamao, esfuerzo, costo, y programacin real del software con el plan cuando se
completan productos de trabajo de software y en hitos selectos. Cuando se ha determinado que los
planes del proyecto de software no estn siendo cumplidos, se toman acciones correctivas. 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 desempeo.
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.
Meta 2
Se toman y administran acciones correctivas cuando los resultados y el

rendimiento obtenidos se desvan significativamente del plan.
Meta 3
Los cambios en los compromisos adquiridos son acordados entre los

grupos y personas afectadas.

Compromiso 1
Se designa a un administrador del proyecto de software como responsable

por las actividades y resultados del proyecto.
Compromiso 2
El proyecto sigue una poltica organizacional escrita para la administracin

de proyectos de software.
Esta poltica tpicamente indica que:
1.
Se usa y mantiene un plan de desarrollo documentado como base para el

seguimiento del proyecto.
2.
El administrador de! proyecto se mantiene informado del estado y los

problemas de! proyecto.
3.
Se toman acciones correctivas cuando el plan del proyecto no esta siendo

logrado, ya sea ajustando el plan o el desempeo.
4.
Los cambios a los compromisos de software son hechos con el

involucramiento y el acuerdo de los grupos afectados
ingeniera de software (incluyendo todos los sub-grupos, tales como diseo de software),
ingeniera de software, pruebas de software
garanta de calidad de software, administracin de configuracin de software,
administracin de contrato, y
apoyo de documentacin
5.
La administracin superior revisa todos los cambios y nuevos compromisos

adquiridos por el proyecto con individuos o grupos externos a la
organizacin.
Nivel 2: Repetible

Habilidad 1
Se documenta y aprueba un plan de desarrollo de software para el

proyecto.
Refirase alas actividades 6 y 7 del rea clave de proceso de Planificacin de proyectos de
software para practicas que cubren el plan de desarrollo de software.
Habilidad 2
El administrador del proyecto de software asigna en forma explicita

responsabilidades sobre las actividades y productos a desarrollar.
La asignacin de responsabilidades cubre:
Habilidad 3
1.
Los productos de software a ser desarrollados o los servicios a ser

proporcionados.
2.
EI esfuerzo y costo para estas actividades de software.
3.
La programacin asociada a estas actividades de software.
4.
EI presupuesto para estas actividades de software
Se proveen los recursos y fondos necesarios para el seguimiento del

proyecto.
1.
Se asignan responsabilidades especificas de seguimiento a los

administradores y lideres de tarea.
2.
Se proporcionan herramientas que apoyen la labor de seguimiento del

proyecto
Habilidad 4
Planillas de calculo,
programas de planificacin y programacin de actividades
Los administradores de proyectos son entrenados para administrar los

aspectos tcnicos y de personal de los proyectos.
Ejemplos de entrenamiento incluyen:
Habilidad 5
Administracin de proyectos tcnicos,

seguimiento y control del tamao, esfuerzo, costos, y programacin de software, y
administracin de personal
Los administradores de primera lnea reciben orientacin en los aspectos

tcnicos del proyecto.
Ejemplos de orientacin incluyen:
Estndares de ingeniera de software y procedimientos aplicables al proyecto
EI dominio de aplicacin del proyecto
Nivel 2: Repetible
Actividad 1
Se usa un plan de desarrollo documentado para seguir las actividades y

comunicar el estado de ellas.
Refirase a la actividad 7 del rea clave de proceso de Planificacin de proyectos de
software para practicas que cubren el contenido del plan de desarrollo de software
Este plan de desarrollo es:
Actividad 2
1.
Actualizado a medida que el trabajo avanza para reflejar logros,

particularmente cuando se completan hitos
2.
Fcilmente disponible para:

q
EI grupo de ingeniera de software (incluyendo todos los sub-grupos

tales como diseo de software),
los administradores de software,
los administradores del proyecto,
la administracin superior, y
otros grupos afectados
3.
La programacin asociada a estas actividades de software.
4.
EI presupuesto para estas actividades de software
El plan de desarrollo de software del proyecto se revisa de acuerdo a un

Refirase a la actividad 6 del orea clave de proceso de Planificacin de proyectos de
software para prcticas que cubren las actividades para producir el plan de desarrollo de
software.
Este procedimiento, tpicamente, especifica que:

1.
EI plan de desarrollo es revisado, segn sea apropiado, para incorporar

refinamientos y cambios al plan.
Las interdependencias entre requisitos de sistema asignados al software, restricciones de
diseo, recurso, costos, y la programacin necesitan ser reflejadas en todos los cambios al
plan.
2.
EI plan es actualizado para incorporar los cambios en los compromisos, o los

nuevos compromisos.
3.
El plan de desarrollo de software es examinado en cada revisin.
4.
EI plan de desarrollo de software es administrado y controlado.

momento dado (pasado o presente) es conocida (es decir, control de versiones), y los
cambios son incorporados de forma controlada (es decir, control de cambios). Si se desea un
mayor grado de control que el implicado por "administrado y controlado", el producto de
trabajo puede ser puesto bajo la disciplina completa de administracin de configuracin,
como es descrita en el rea clave de proceso de Administracin de Configuracin de
Software
Nivel 2: Repetible
Actividad 3
Los cambios a compromisos o nuevos compromisos del proyecto de

software, hechos a grupos o personas externas a la organizacin, deben
ser revisados con la administracin superior de acuerdo a un
Actividad 4
Los cambios aprobados a compromisos que afectan al proyecto son

comunicados a los miembros del grupo de ingeniera de software y otros
grupos relacionados.
Ejemplos de otros grupos relacionados con software incluyen:

administracin de configuracin de software, y
apoyo de documentacin
Actividad 5
Se sigue el tamao del producto de software (o el tamao de los cambios) y

se toman acciones correctivas si es necesario.
software para practicas que cubren las actividades para derivar las estimaciones de tamao.
Actividad 6
1.
Se siguen los tamaos de los principales productos de software (o el tamao

de los cambios)
2.
EI tamao real del cdigo (generado, probado y entregado) es comparado

con las estimaciones documentadas en el plan de desarrollo de software.
3.
Las unidades reales de documentacin entregada son comparadas con las

estimaciones documentadas en el plan de desarrollo de software.
4.
EI tamao total proyectado de todos los productos de software (estimados

combinados con reales) es refinado. monitoreado y ajustado regularmente.
5.
Los cambios en las estimaciones de tamao que afectan compromisos de

software, 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.
software para practicas que cubren las actividades para derivar las estimaciones de costo.
1.
Los gastos reales de esfuerzo y costos, en el tiempo y en relacin con los

productos desarrollados son comparados con las estimaciones
documentadas en el plan de desarrollo de software para identificar
potenciales desviaciones de 10 presupuestado,
2.
Los costos de software son seguidos y comparados alas estimaciones

documentadas en el plan de desarrollo de software,
3.
EI esfuerzo y la provisin de personal son comparadas alas estimaciones

documentadas en el plan de desarrollo de software,
4.
Los cambios la provisin de personal y en otros costos que afecten los

compromisos de software son negociados con los grupos afectados y son
documentados.

Actividad 7
Nivel 2: Repetible
Se siguen los recursos crticos de computador y se toman acciones

software para practicas que cubren las actividades para derivar las estimaciones de recurso
de computadores.
Actividad 8
1.
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.
2.
Los cambios en estimaciones de recursos crticos de computador que

afecten los compromisos de software son negociados entre las partes
afectadas.
Se signe la programaci6n de software del proyecto y se toman acciones

Refirase a la actividad 12 del rea clave de proceso de Planificacin" de proyectos de
software para prac ticas que cubre" las actividades para derivar las estimaciones de la
programacin.
Actividad 9
Actividad 10
1.
EI cumplimiento de las actividades y de los hitos de la programacin es

comparado con el plan de desarrollo de software
2.
Se evalan los efectos del atraso o adelanto en el cumplimiento de las

actividades, hitos y otros compromisos, en relacin con el impacto sobre
actividades e hitos futuros
3.
Las revisiones y modificaciones a la programacin que afecten los

compromisos de software son negociadas con los grupos afectados y son
documentados.
Se siguen las actividades tcnicas de ingeniera de software del proyecto y

se toman acciones correctivas si es necesario.
1.
Miembros del grupo de ingeniera de software informan el estado tcnico al

administrador de primera lnea en forma regular.
2.
Los contenidos del software liberado para construcciones sucesivas son

comparados con los planes documentados en el plan de desarrollo de
software.
3.
Los problemas identificados en cualquiera de los productos de software son

informados y documentados.
4.
Los reportes de problemas son seguidos hasta su cierre.
Se siguen los riesgos asociados con costos, recursos, programacin y

aspectos tcnicos del proyecto y se toman acciones correctivas si es
necesario.
software para practicas que cubren la identificacin de los riesgos.
Nivel 2: Repetible
Actividad 11

5.
Las prioridades de los riesgos y las contingencias de los riesgos son

ajustadas a medida de que se dispone de informacin adicional.
6.
Las reas de alto riesgo son revisadas con el administrador del proyecto en
forma regular.
Se registran datos de medicin reales y de replanificacin para el proyecto

de software.
software para practicas que cubre" el registro de datos de proyecto.
Actividad 12
1.
La informacin registrada incluye las estimaciones y la informacin necesaria

para reconstruir las estimaciones y verificar su razonabilidad.
2.
Los datos de replanificacin son administrados y controlados
3.
Los datos de planificacin de software, datos de replanificacion, y datos de

mediciones reales son archivados para ser utilizados en proyectos en
ejecucin y futuros.
4.
Los reportes de problemas son seguidos hasta su cierre.
EI grupo de ingeniera de software conduce revisiones internas peridicas

para seguir el avance tcnico, planes, desempeo, y problemas contra el
plan de desarrollo de software.
Esas revisiones son conducidas entre:
Actividad 13
1.
Los administradores de primera lnea y sus lideres de tarea de software.
2.
EI administrador del proyecto de software, los administradores de primera

lnea, y otros administradores de software, segn corresponda.
Se realizan revisiones formales para abordar los logros y resultados del

proyecto de software en algunos hitos escogidos de acuerdo a un
Esas revisiones:
1.
Se planifican para ocurrir en puntos significativos de la programacin del

proyecto, tales como comienzo y fin de etapas.
2.
Participan los clientes, usuarios finales y los grupos involucrados dentro de la

organizacin.
Los usuarios finales referidos en estas practicas son usuarios finales designados por el
cliente o representantes de los usuarios finales.
3.
Usan materiales que son revisados y aprobados por los administradores de

software responsables.
4.
Abordan los compromisos, planes y el estado de las actividades de software
5.
Resultan en la identificacin y documentacin de los problemas mas

significativos, los tems de accin y las decisiones.
6.
Se abordan los riesgos del proyecto de software
7.
Resulta en un refinamiento del plan de desarrollo de software si es necesario
Nivel 2: Repetible
Medicin y Anlisis
Medicin 1
Se realizan mediciones y son usadas para determinar el estado de las

actividades de Supervisin y Control del Proyecto.
Ejemplos de mediciones incluyen:
Esfuerzo y otros recursos gastados en actividades de Supervisin y Control del Proyecto, y

Actividad de cambio en el plan de desarrollo de software. las cuales incluyen cambios en el
tamao estimado de los productos de software, estimaciones de costos de software.
recursos crticos de computador y programacin
Verificacin 1
Las actividades de seguimiento y control son revisadas con la

administracin superior en forma peridica.
El principal propsito de las revisiones peridicas por la administracin superior es generar
conciencia de, y visin acerca de las actividades del proceso de software a un nivel de
abstraccin adecuado y de manera oportuna el tiempo entre revisiones debe cumplir con las
necesidades de la organizacin y puede ser tan largo, como estn disponibles mecanismos
adecuados de reporte de excepciones.
Verificacin 2
1.
Se revisa el rendimiento tcnico, costos, personal y programacin,
2.
Se abordan los conflictos y problemas que no solubles en los niveles

inferiores,
3.
Se abordan los riesgos del proyecto de software,
4.
Se asignan tems de accin, se revisan y son seguidas hasta su termino
5.
Se prepara un informe resumen de estado de cada reunin el cual es

distribuido a los grupos afectados,
Las actividades de seguimiento y control son revisadas con el

administrador del proyecto en forma peridica y ante eventos que lo
requieran.
1.
Los grupos afectados estn representados,
2.
El desempeo tcnico, los costos, la asignacin de recursos y la

programacin se revisan en comparacin con el plan del proyecto de
software
3.
Se abordan las dependencias entre grupos,
4.
Se abordan los conflictos y problemas no solubles en los niveles inferiores,
5.
Se re evalan los riesgos del proyecto,
6.
Se asignan tems de accin, se revisan y se siguen hasta su termino
7.
Se prepara un informe resumen de cada reunin y se distribuye a los grupos

afectados.
Nivel 2: Repetible
Verificacin 3
EI grupo garanta de calidad de software revisa y/o audita las actividades y

productos de trabajo de Supervisin y Control de Proyectos de Software e
informa los resultados.
Refirase al rea clave de proceso Garanta de Calidad de Software
Como mnimo, las auditorias o revisiones verifican:

1.
Las actividades para revisin y repaso de compromisos.
2.
Las actividades de revisin del plan de desarrollo
3.
EI contenido del plan de desarrollo de software revisado.
4.
Las actividades de seguimiento de los costos, programacin, riesgos,

restricciones tcnicas, de diseo, de funcionalidad y de rendimiento.
5.
Las actividades para conducir las revisiones tcnicas y de la administracin

planificadas
Administracin de Subcontratos
El propsito de la Administracin de Subcontratos es seleccionar subcontratistas de software
calificados y administrarlos efectivamente.
Involucra la seleccin del subcontratista, establecer compromisos con el subcontratista, y el

seguimiento y revisin del desempeo y resultados del subcontratista. Esas practicas cubren la
administracin de un subcontrato de software (solamente), as! como tambin la administracin de una
componente de software de un subcontrato que incluye software, hardware y posiblemente otras
componentes de sistema.
El subcontratista es seleccionado sobre la base de su habilidad para desarrollar el trabajo. Los

subcontratistas pueden ser seleccionados sobre la base de alianzas comerciales estratgicas, o bien
por razones tcnicas. Las practicas de esta rea clave de proceso abordan el proceso tradicional de
adquisicin asociado con subcontratar una porcin definida del trabajo con otra organizacin.
Al subcontratar, se crea un acuerdo documentado cubriendo tanto los requerimientos tcnicos como no
tcnicos (por ejemplo: fechas de entrega) y se usa como base para administrar el subcontrato. El
trabajo a ser realizado por el subcontratista y los planes para el trabajo son documentados. Los
estndares que son para ser seguidos por el subcontratista son compatibles con los estndares del
contratante.
Las actividades de planificacin de software, seguimiento, y control para el trabajo subcontratado son
ejecutadas por el subcontratista. El contratante asegura que esas actividades de planificacin,
seguimiento y control son ejecutadas apropiadamente
y que los productos de software entregados por el subcontratista satisfacen sus criterios de aceptacin.
El contratante trabaja con el subcontratista para administrar las interfaces de productos y procesos.
Nivel 2: Repetible
Metas
Meta 1
EI contratante selecciona subcontratistas de software calificados.
Meta 2
EI contratante y el subcontratista acuerdan compromisos recprocos.
Meta 3
EI contratante y el subcontratista de software mantienen una comunicacin

continua.
Meta 4
EI contratante hace un seguimiento al subcontratista de software, de los

resultados reales y del desempeo en relacin a sus compromisos.

Compromiso 1
El proyecto sigue una poltica organizacional escrita para la administracin

del subcontrato de software
Esta poltica, tpicamente, especifica:
Compromiso 2
1.
Se usan estndares y procedimientos documentados para la seleccin y la

administracin de los subcontratistas de software.
2.
Los acuerdos contractuales son la base para administrar el subcontrato.
3.
Los cambios en el subcontrato son hechos con la participacin y acuerdo del

contratante y el subcontratista.
Se designa un administrador de subcontratos para hacerse responsable de

establecer y administrar el subcontrato de software.
Este administrador debe:
1.
EI administrador del subcontrato es conocedor y experimentado en

ingeniera de software o tiene personas asignadas que tienen este
conocimiento y experiencia.
2.
Ser responsable de coordinar el alcance tcnico del trabajo a ser

subcontratado y los trminos y condiciones del subcontrato con las partes
afectadas.
EI grupo de ingeniera de sistemas del proyecto y el grupo de ingeniera de software definen
la cobertura tcnica del trabajo a ser subcontratado
Los grupos funcionales de negocio, tales como adquisiciones, finanzas, y legal establecen y
monitorean los trminos y condiciones del subcontrato
3.
Nivel 2: Repetible
EI administrador del subcontrato es responsable por:

q
seleccionar al subcontratista de software,
administrar el subcontrato y
organizar el apoyo post-contrato de los productos subcontratados

Habilidades 1
Se proveen recursos y financiamiento adecuados para seleccionar al

subcontratista y administrar el subcontrato.
1.
Son asignadas responsabilidades especificas a los administradores del

software y otros individuos por administrar el subcontrato.
2.
Se hacen disponibles herramientas para apoyar la administracin del

subcontrato.
Ejemplos de herramientas de apoyo incluyen:
Habilidades 2
modelos de estimacin,
planillas de calculo y
programas de administracin y programacin de proyectos
Los administradores del software y otros individuos que estn

involucrados en el establecimiento y administracin de los subcontratos
estn entrenados para realizar esas actividades.
Ejemplos de capacitacin incluyen:
Preparacin y panificacin para la administracin del subcontrato,
Evaluacin la capacidad del proceso de software de un postor del subcontrato,

Evaluacin de las estimaciones y planes de un postor del subcontrato,
Seleccin de un subcontratista, y
Administracin de un subcontrato
Habilidades 3
Los administradores del software y otros individuos que estn

involucrados en la administracin del subcontrato reciben orientacin en
los aspectos tcnicos del subcontrato.
Ejemplos de orientacin incluyen:
Tecnologas de software en aplicacin,

Herramientas de software en uso,
Metodologas en uso,
estndares en uso, y
procedimientos en uso
Nivel 2: Repetible
Actividad 1
EI trabajo a ser subcontratado es definido y planificado de acuerdo a un

1.
2.
3.
Las actividades y productos de software a ser subcontratados son

seleccionados de acuerdo a caractersticas tcnicas y no tcnicas del
proyecto
q
Las funciones o subsistemas a ser subcontratados son seleccionados

para calzar con las habilidades y capacidades de potenciales
subcontratistas
La especificacin de los productos y actividades de software a ser

subcontratadas es determinada basndose en un anlisis sistemtico y
una particin adecuada de los requerimientos de sistema y de software
La especificacin del trabajo a ser subcontratado y los estndares y

procedimientos a ser seguidos se derivan de:
q
La orden de trabajo,
los requisitos de sistema asignados al software,
los requisitos de software,
el plan de desarrollo del software,
los estndares de software y procedimientos
Una orden de trabajo es:

q
preparada,
repasada,
acordada,
Ejemplos de individuos que revisan y acuerdan la orden de trabajo del subcontratista
incluyen:
EI administrador del proyecto,

EI administrador del proyecto de software,
Los administradores de software responsables,
EI administrador de configuracin de software,
EI administrador de garanta de calidad de software, y
EI administrador de! Subcontrato
revisada cuando es necesario, y
administrada y controlada.
administra y controla un informe del trabajo a subcontratar.
Nivel 2: Repetible
4.
Se prepara un plan para seleccionar un subcontratista, concurrentemente

con el informe del trabajo.
cambios son incorporados de forma controlada (es decir, control de cambios)
Si se desea un mayor grado de control que el implicado por "administrado y controlado", el
producto de trabajo puede ser puesto bajo la disciplina completa de administracin de
configuracin, como es descrita en el rea clave de proceso de Administracin de
Configuracin de Software
Refirase a la habilidad 1 del rea clave de proceso de Planificacin de proyectos de

software para practicas que cubren el contenido tpico de una orden de trabajo.
Actividad 2
EI subcontratista es seleccionado, en base a una evaluacin de la

capacidad del postulante al subcontrato de realizar el trabajo, de acuerdo a
un procedimiento documentado.
Este procedimiento cubre la evaluacin de:
1.
Propuestas enviadas para el subcontrato planificado.
2.
Registros de desempeo en trabajos similares, si estn disponibles.
3.
La ubicacin geogrfica de los postulantes al subcontrato.

Una administracin efectiva de algunos subcontratos puede requerir frecuentes interacciones
cara a cara.
4.
Las capacidades de administracin e ingeniera de software.

Un ejemplo de un mtodo para evaluar capacidades de subcontratistas es el "Software
Capability Evaluacin" del SEI
5.
EI personal disponible para realizar el trabajo.
6.
Experiencia previa en aplicaciones similares, incluyendo experiencia en

software del equipo administrador de software del subcontratista.
7.
Recursos disponibles.
Ejemplos de recursos incluyen:
Medios,
Hardware,
Software, y
Capacitacin
Actividad 3
Nivel 2: Repetible
EI acuerdo contractual entre el contratante y los subcontratistas es usado

como base para administrar el subcontrato.
EI acuerdo contractual documenta:
1.
Los trminos y condiciones
2.
La orden de trabajo.
Refirase a la habilidad 1 del rea clave de proceso de Planificacin de Proyectos de
Software para practicas que cubren el contenido tpico de una orden de trabajo.
3.
Los requisitos para los productos a ser desarrollados.
4.
La lista de dependencias entre el subcontratista y el contratante.
5.
Los productos subcontratados que sern entregados al contratante

Ejemplo de productos incluyen:
Cdigo fuente,
Plan de desarrollo de software,
Ambiente de simulacin,
Documentacin del diseo, y
EI plan de pruebas de aceptacin
Actividad 4
6.
Las condiciones bajo las cuales se sometern a revisiones los productos
7.
Los procedimientos y criterios de aceptacin para ser usados en la

evaluacin del producto subcontratado antes de la aceptacin por el
contratante.
8.
Los procedimientos y criterios de evaluacin a ser usados por el contratante

para monitorear y evaluar el desempeo del subcontratista.
Un plan documentado de desarrollo del software subcontratado es revisado

y aprobado por el contratante.
1. 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, el plan de desarrollo de software del contratante, puede incluir, el plan de
desarrollo para el subcontratista, y por tanto no se necesita un plan de desarrollo de software
del subcontratista aparte.
Refirase a la actividad 7 del rea clave de proceso de Planificacin de Proyectos de
Software para practicas que cubren el contenido tpico de "n plan de desarrollo de software.
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.
Actividad 6
Los cambios a la orden de trabajo, los trminos y condiciones del

subcontrato y otros acuerdos son resueltos de acuerdo a un procedimiento
documentado.
1.
Este procedimiento tpicamente especifica que estn involucrados todos los

grupos afectados, tanto del contratante como del subcontratista tems
apropiados del plan de desarrollo de software del contratante.

Nivel 2: Repetible
Actividad 7
La administracin del contratante conduce revisiones de estado /

coordinacin con la administracin del subcontratista.
1.
Se le entrega al subcontratista la visin 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, o representantes de los usuarios finales.
2.
Se revisan, contra el plan de desarrollo del software del subcontratista, el

desempeo tcnico, costos, personal y programacin.
3.
Se revisan los recursos computacionales designados como crticos para el

proyecto; la contribucin 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.
4.
Se abordan las dependencias criticas y compromisos entre el grupo de

ingeniera de software del subcontratista y otros grupos del subcontratista.
5.
Se abordan las dependencias y acuerdos crticos entre el contratante y el

subcontratista.
q
Actividad 8
Se revisan los compromisos del subcontratista con el contratante y

viceversa
6.
Se abordan no conformidades con el subcontrato.
7.
Se abordan los riesgos de proyecto que involucran el trabajo del

subcontratista
8.
Se abordan conflictos y problemas no resolubles internamente por el

subcontratista.
9.
Se asignan, revisan y siguen tems de accin hasta cerrarlos
Se realizan intercambios y revisiones tcnicas, en forma peridica, con el

subcontratista de software.
Estas revisiones:
1.
Proveen al subcontratista de visibilidad de las necesidades y deseos del

cliente y los usuarios finales, segn corresponda.
2.
Monitorean las actividades tcnicas del subcontratista.
3.
Verifican que la interpretacin e implementacin de los requisitos tcnicos,

por parte del subcontratista, estn de acuerdo con los requisitos del
contratante
4.
Verifican que los acuerdos se estn cumpliendo.
5.
Verifican que los aspectos tcnicos se estn resolviendo de forma oportuna.
Actividad 9
Nivel 2: Repetible
Se conducen revisiones formales para abordar los resultados y logros de la

ingeniera de software del subcontratista, en hitos selectos y bajo un
Actividad 10
1.
Las revisiones son pre-planificadas y documentadas en la orden de trabajo.
2.
Las revisiones abordan los acuerdos para, planes para y estado de las
actividades de software.
3.
Se identifica y documentan los problemas significativos, los tems de accin y

las decisiones.
4.
Se abordan los riesgos de! software
5.
El plan de desarrollo del software del subcontratista se refina, segn

corresponda.
Se conducen revisiones formales para abordar los resultados y logros de la

ingeniera de software del subcontratista, en hitos selectos y bajo un
1. Los planes, recursos, procedimientos y estndares para garanta de calidad
del subcontratista, son revisados peridicamente para asegurar que ellos son
adecuados para monitorear el desempeo del subcontratista.
2. Se conducen revisiones regulares del subcontratista para asegurar que se
estn siguiendo los procedimientos y estndares aprobados.
q
El grupo de garanta de calidad de software del contratante chequea las

actividades y productos de ingeniera de software del subcontratista,
El grupo de garanta de calidad de software del contratante audita los

registros de garanta de calidad de software del subcontratista, segn
corresponda.
3. Los registros de las actividades garanta de calidad del subcontratista son

auditados peridicamente para evaluar cuan bien se estn siguiendo los
planes, estndares y procedimientos de garanta de calidad de software.
Actividad 11
EI grupo de administracin de la configuracin del contratante monitorea

las actividades de administracin de la configuracin del subcontratista, de
acuerdo a un procedimiento documentado.
1. Se revisan los estndares, planes, recursos y procedimientos de la
administracin de configuracin del subcontratista para asegurar que son
adecuados.
2. El contratante y el subcontratista coordinan sus actividades en materias
relacionadas a la administracin de la configuracin para asegurar que los
productos del subcontratista pueden ser rpidamente integrados o
incorporados en el ambiente del proyecto del contratante.
Nivel 2: Repetible
3. La librera de lneas base de software del subcontratista es revisada

peridicamente para evaluar que tan bien son seguidos los procedimientos
para la administracin de configuracin del software y que tan efectivos son
ellos en administrar la lnea base de software.
4. El contratante y el subcontratista coordinan sus actividades en materias
relacionadas a la administracin de la configuracin para asegurar que los
productos del subcontratista pueden ser rpidamente integrados o
incorporados en el ambiente del proyecto del contratante.
Actividad 12
EI contratante conduce pruebas de aceptacin como parte de la entrega de

los productos de software del subcontratista, de acuerdo a un
Actividad 13
1.
Estn definidos, revisados y aprobados los criterios de aceptacin para cada

producto.
2.
Los resultados de las pruebas de aceptacin son documentados
3.
Se planifican acciones para cada producto de software que no pasa sus

pruebas de aceptacin
Se evala, peridicamente, el desempeo del subcontratista de software y

la evaluacin es revisada con el subcontratista.
La evaluacin del desempeo del subcontratista provee una oportunidad para el
subcontratista de obtener retroalimentacin en ellas sobre si esta o no satisfaciendo las
necesidades de sus clientes (es decir, las necesidades del contratante). Un mecanismo tal
como las revisiones de premio por cuota de desempeo proveen este tipo de
retroalimentacin, como opuesto alas revisiones peridicas tcnicas y de coordinacin que
ocurren a travs del proyecto La documentacin de esas evaluaciones tambin acta como
una entrada para actividades futuras de seleccin de subcontratistas.
Medicin y Anlisis
Medicin 1

actividades de administracin del subcontrato de software.
Ejemplo de mediciones:
Costos de las actividades para la administracin del subcontrato en comparacin con el

plan.
Tiempos de entrega reales para productos subcontratados en comparacin con el plan

Tiempos de entrega del contratante al subcontratista en comparacin con el plan
Nivel 2: Repetible
Verificacin 1
Las actividades para la administracin del subcontrato de software son

revisadas, con la administracin superior, en forma peridica.
Refirase a la verificacin 1 del rea clave de proceso de Seguimiento y Control de
Proyectos para practicas cubriendo el tpico contenido de las revisiones de seguimiento de la
Verificacin 2
Las actividades para la administracin del subcontrato de software son

revisadas con el administrador del proyecto, en forma peridica y en
reaccin a eventos.
administracin superior.
Verificacin 3
EI grupo de garanta de calidad del software, revisa y/o audita las

actividades y los productos del trabajo para administrar los subcontratos
del software, y reporta los resultados.
Refirase al rea clave de proceso de Garanta de Calidad de Software.
Esta revisin y/o auditoria verifica:

1.
Las actividades para seleccionar al subcontratista.
2.
Las actividades para administrar el subcontrato.
3.
Las actividades para la coordinacin de las actividades de administracin de

la configuracin del contratante y el subcontratista.
4.
La revisin de la conduccin de 10 planificado con el subcontratista.
5.
La conduccin de revisiones que establecen el termino de aspectos claves

del proyecto para el subcontratista.
6.
EI proceso de aceptacin de los productos de software del subcontratista
Garanta de Calidad de Software

El propsito de Garanta de Calidad de Software es dar ala administracin una visibilidad adecuada del
proceso que esta siendo usado y los productos que estn siendo construidos.
Garanta de Calidad de Software involucra revisar y auditar los productos y actividades de software a fin
de asegurar que ellos cumplan con los estndares y procedimientos aplicables, proveyendo al proyecto
de software y otros administradores apropiados de los resultados de esas revisiones y auditorias.
El grupo de Garanta de Calidad de Software trabaja con el proyecto de software durante sus etapas
tempranas para definir los planes, estndares y procedimientos que agregaran valor al proyecto de
software y satisfarn las restricciones del proyecto y las polticas de la organizacin.
Al participar en establecer los planes, estndares y procedimientos, el grupo de garanta de calidad de

software ayuda a asegurar que ellos se ajustan alas necesidades del proyecto y verifica que ellos sern
usables para efectuar revisiones y auditorias a travs del ciclo de vida del software. El grupo de
garanta de calidad de software revisa las actividades del proyecto y audita los productos de trabajo de
software a travs del ciclo de vida y provee a la administracin de visibilidad sobre la adherencia del
proyecto de software a sus planes, estndares y procedimientos establecidos.
Nivel 2: Repetible
Metas
Meta 1
Las actividades de garanta de calidad de software son planificadas.
Meta 2
Verificar objetivamente si los productos y actividades satisfacen los

requisitos y estndares aplicables.
Meta 3
Los grupos y personas afectadas son informadas sobre las actividades de

garanta de calidad y de los resultados obtenidos.
Meta 4
Problemas de no conformidad que no puedan ser resueltos dentro del

proyecto son abordados por la administracin superior.

Compromiso 1
EI proyecto sigue una poltica organizacional escrita para implementar

Garanta de Calidad de Software (GCS).
Esta poltica, tpicamente, especifica:
1.
La funcin de Garanta de Calidad de Software est implantada en todos los

proyectos de software.
2.
EI grupo de Garanta de Calidad de Software tiene un canal de reporte

directo a la administracin superior que es independiente de:
q
EI administrador del proyecto,
El grupo de ingeniera de software del proyecto, y
Otros grupos relacionados con el software

Ejemplo de otros grupos relacionados con el software incluyen:
Administracin del configuracin de software, y

Apoyo de documentacin.
Las organizaciones deben determinar la estructura organizacional que soportara las

actividades
que requieren independencia, tales como GCS, en el contexto de sus metas estratgicas de
negocia y el ambiente de negocios.
La independencia debiera:
3.
Proveer a los individuos el ejecutar el rol GCS con la libertad organizacional de ser "los
ojos Y los odos" de la administracin superior dentro del proyecto de software.
Proteger a los individuos que ejecutan el rol de GCS de una evaluacin de desempeo por
la administracin del proyecto software que ellos estn revisando, y
Proveer a la administracin superior la confianza que se esta reportando informacin

objetiva acerca de los procesos y los productos del proyecto de software.
La administracin superior revisa peridicamente las actividades y resultados

de garanta de calidad.
Nivel 2: Repetible

Habilidad 1
Existe un grupo de Garanta de Calidad de Software que es responsable de

coordinar e implementar las actividades de Garanta de Calidad de Software
para el proyecto.
Un grupo es la coleccin de departamentos administradores e individuos que tienen
responsabilidad por un grupo de tareas o actividades. Un grupo puede variar desde un
individuo asignado a jornada parcial, varios individuos asignados a jornada parcial de
diferentes departamentos, hasta varios individuos dedicados a jornada c ompleta. Las
consideraciones sobre cuando implementare un grupo incluyen las actividades y tareas
asignadas, el tamao del proyecto, la estructura y la cultura de la organizacin. Algunos
grupos, tales como el grupo de garanta de calidad de software, estn concentrados en
actividades de proyecto, y otros, como el grupo de ingeniera de procesos de software, que
esta concentrado en actividades horizontales de la organizacin
Habilidad 2
Se proveen los recursos y fondos necesarios para la realizacin de las

actividades de Garanta de Calidad de Software.
1.
Se asigna especficamente un administrador responsable por las actividades

de Garanta de Calidad de Software.
2.
Un administrador superior, 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.
q
3.
Todos los administradores en la cadena de reporte a la administracin

superior son conocedores del rol, responsabilidades y autoridad de
GCS.
Se dispone de herramientas de apoyo a Garanta de Calidad de Software:

Ejemplos de herramientas de apoyo incluyen:
Habilidad 3
Estaciones de trabajo,
Programas de bases de datos,
Programas de planilla de calculo, y
Herramientas de auditoria
Los miembros del grupo de garanta de calidad de software estn

entrenados para realizar las tareas asociadas a esta actividad.
Practicas y habilidades de ingeniera de software,
Roles y responsabilidades del grupo de ingeniera de software y otros grupos relacionados,

Mtodos, estndares y procedimientos para el proyecto de software,
Dominio de aplicacin del proyecto de sof tware,
Mtodos, procedimientos y objetivos de garanta de calidad,
Involucramiento del grupo de GCS en las actividades del proyecto,

Uso efectivo de los mtodos y herramientas de garanta de calidad, y
Comunicacin interpersonal
Nivel 2: Repetible
Habilidad 4

Los miembros del proyecto reciben orientacin en los roles,
responsabilidades, autoridad y valor del grupo de GCS.
Actividad 1
Se prepara un plan de garanta de calidad para el proyecto de acuerdo a un

1.
El plan de Garanta de Calidad de Software es desarrollado en las primeras

etapas y en paralelo con la planificacin global del proyecto.
2.
El plan de Garanta de Calidad de Software es revisado por los grupos e

individuos afectados.
Ejemplos de grupos e individuos afectados incluyen:
3.
El administrador de software,
Otras administradores de software,
EI administrador de software,
Un representante de GCS del cliente,
EI administrador superior a quien el grupo de GCS reporta problemas de no conformidad, y
EI grupo de ingeniera de software (incluyendo todos los sub-grupos, tales como diseo de
software y tambin los lideres de tarea)
El plan de Garanta de Calidad de Software es administrado y controlado.

Administrado y controlado" implica que la versin del producto de trabajo en uso en un
cambios son incorporados de forma controlada (es decir, control de cambios)

Configuracin de Software
Actividad 2
Las actividades del grupo de GCS se realizan de acuerdo con el plan de

GCS.
El plan cubre:
1.
Responsabilidades y autoridad del grupo de GCS,
2.
Requisitos de recursos para el grupo de GCS,
3.
Programacin y financiamiento para las actividades del grupo de GCS del

proyecto.
4.
La participacin del grupo de GCS en la definicin del plan de desarrollo de

software, estndares y procedimientos del proyecto
5.
Evaluaciones a ser realizadas por el grupo de garanta de calidad
Nivel 2: Repetible
Ejemplos de productos y actividades a ser evaluados incluyen:
Software operacional y de soporte,
Productos entregables y no entregables,

Productos de software y no software (por ejemplo documentos),
Actividades de desarrollo y verificacin de productos (por ejemplo ejecucin de los casos
de prueba), y
Las actividades seguidas para crear el producto
6.
Auditorias y revisiones a ser conducidas por el grupo de GCS.
7.
Estndares y procedimientos del proyecto a ser usados como base de las

auditorias y revisiones del grupo de GCS
8.
Procedimientos para documentar y seguir hasta el cierre los problemas de no

conformidad
Estos procedimientos pueden ser incluidos como parte del plan o va referencia a otros
documentos donde estn contenidos.
9.
Documentacin que se requiere que el grupo de GCS produzca.
10. Mtodo y frecuencia para proveer retroalimentacin al grupo de ingeniera de

software y otros grupos relacionados con el software sobre las actividades de
GCS.
11. Procedimientos para documentar y seguir hasta el cierre los problemas de no
conformidad
Actividad 3
EI grupo de GCS participa en la preparacin y revisin del plan de

desarrollo de software, estndares y procedimientos del proyecto.
1.
2.
EI grupo de GCS provee consultora y revisin de los planes, estndares y

procedimientos del proyecto, con respecto a:
q
Cumplimiento de la poltica organizacional,
Cumplimiento de requisitos y estndares impuestos del exterior. (por

ejemplo, estndares impuestos por la orden de trabajo),
Estndares que son apropiados para uso del proyecto,
Tpicos que debera incluir el plan de desarrollo, y
Otras reas asignadas por el proyecto
EI grupo de GCS verifica que los planes, estndares y procedimientos estn

en su lugar y sean utilizables para revisar y auditar el proyecto de software.
Nivel 2: Repetible
Actividad 4
Actividad 5

El grupo de GCS revisa las actividades de ingeniera de software para
verificar conformidad.
1.
Las actividades son evaluadas contra el plan de desarrollo y los estndares y

procedimientos designados.
2.
Refirase a la caracterstica comn Verificando la Implementacin en las

otras reas clave de proceso para practicas cubriendo las revisiones y
auditorias especificas ejecutadas por el grupo de GCS
3.
Las desviaciones son identificadas, documentadas, y seguidas hasta su

conclusin
4.
Las correcciones son verificadas.
El grupo de GCS revisa productos designados de software para verificar

conformidad.
1.
Los productos de software entregables son evaluados antes de ser

entregados al cliente.
2.
Los productos de software son evaluados de acuerdo a los estndares,

procedimientos y requisitos contractuales designados
3.
Las desviaciones del plan son identificadas, documentadas y seguidas hasta

su conclusin
4.
Las correcciones son verificadas
Actividad 6
EI grupo de GCS informa peridicamente los resultados de sus actividades

al grupo de ingeniera de software.
Actividad 7
Las desviaciones identificadas en los productos y actividades son

documentadas y manejadas de acuerdo a un procedimiento documentado.
Este procedimiento establece tpicamente que:
Actividad 8
1.
Las desviaciones del plan de desarrollo de software, los estndares y

procedimientos designados del proyecto son documentadas y resueltas con
los lideres de tarea, administradores de software o administradores de
proyecto adecuados cuando sea posible.
2.
Las desviaciones del plan de desarrollo de software, los estndares y

procedimientos designados del proyecto no solubles con los lideres de tarea,
administradores de software o administradores de proyecto se documentan y
se presentan al administrador superior designado para recibir tems no
conformes.
3.
Los tems no con formes presentados a la administracin superior, son

revisados peridicamente hasta su solucin.
4.
La documentacin de los tems no conformes es administrada y controlada.
EI grupo de GCS conduce revisiones peridicas de sus actividades y

hallazgos con el personal de GCS del cliente, segn corresponda.
Nivel 2: Repetible
Medicin y Anlisis
Medicin 1

actividades de GCS.
Ejemplo de mediciones incluyen:
Cumplimiento de las hitas de GCS (en comparacin a la establecido en el plan);

Trabajo terminada, esfuerzo y financiamiento gastado en las actividades de GCS
comparadas con el plan,
Numero de auditorias de productos y revisiones de actividades comparadas con el plan
Verificacin 1
Las actividades de GCS se revisan con la administracin superior en forma

peridica.
EI principal propsito de las revisiones peridicas por la administracin superior es generar
abstraccin adecuado y de manera oportuna. EI tiempo entre revisiones debe cumplir con las

Verificacin 2
Las actividades de GCS se revisan con el administrador del proyecto en

forma peridica y ante eventos que lo requieran.
Verificacin 3
Expertos independientes revisan peridicamente las actividades del grupo

de Garanta de Calidad de Software.
Administracin de Configuracin de
Software
El propsito de la administracin de configuracin de software es establecer y mantener la integridad de
los productos de software del proyecto a travs del ciclo
de vida del proyecto de software.
La administracin de configuracin de software involucra identificar la configuracin del software (es

decir, una seleccin de productos de trabajo de software y sus descripciones) en puntos dados del
tiempo, controlando sistemticamente los cambios a la configuracin, y manteniendo la integridad y
trazabilidad de la configuracin a travs del ciclo de vida del software. Los productos de trabajo puestos
bajo administracin de configuracin de software incluyen los productos que son entregados al cliente
(por ejemplo, el documento de requerimientos de software y el cdigo) Y los tem identificados con, o
requeridos para crear esos productos de software. (por ejemplo, el compilador).
Se establece una librera de lneas base de software conteniendo las lneas base de software a medida
que ellas son desarrolladas. Los cambios alas lneas bases y la liberacin de productos de software
construidos desde la librera de lneas base son controlados sistemticamente va las funciones de
control de cambios y auditoria de configuracin de la administracin de configuracin de software.
Esta rea clave de proceso cubre las practicas para ejecutar la funcin de administracin de
configuracin de software. Las practicas que identifican itemes/unidades de configuracin especificas
estn contenidas en las reas clave de proceso que describen el desarrollo y manutencin de cada
item/unidad de configuracin.
Administracin de configuracin de Software
Nivel 2: Repetible
Metas
Meta 1
Las actividades de administracin de configuracin son planificadas.
Meta 2
Se identifican, controlan y mantienen disponibles productos de trabajo de

software selectos.
Meta 3
Los cambios a los productos de trabajo de software identificados son

controlados.
Meta 4
Los grupos e individuos afectados son informados del estado y contenido

de las lneas base de software.

Compromiso 1
EI proyecto sigue una poltica organizacional escrita para la

implementacin de administracin de configuracin de software (ACS).
Esta poltica, tpicamente, indica que:
1.
La responsabilidad por ACS en cada proyecto es explcitamente asignada
2.
ACS es implementada a travs de todo el ciclo de vida del proyecto
3.
ACS es implementada para productos entregables externamente. algunos

productos internos seleccionados y algunas herramientas de apoyo
designadas usadas en el proyecto(ejemplo. compiladores)
4.
Los proyectos establecen o tienen acceso a un repositorio para almacenar

las unidades de configuracin y los registros de ACS asociados,
Los contenidos de este repositorio son referidos como "Librera de lneas base de software"
en esas prcticas.
Las herramientas y procedimientos para accesar este repositorio son referidos como el
"sistema de librera de administracin de configuracin" en esas practicas.
Los productos de trabajo que son puestos bajo administracin de configuracin y son
tratados como una entidad simple son referidos como tem de configuracin.
Los tem que configuracin son tpicamente descompuestos en componentes de
configuracin, y las componentes dc configuracin san tpicamente descompuestos en
unidades En un sistema de hardware / software, lodo el software puede ser considerado
como uno tem de configuracin simple, o el software puede ser descompuesto en mltiples
tems de configuracin. En esas prcticas el termino tems/unidades de configuracin es
usado para referirse a los elementos bajo administracin de configuracin.
5.
Las Lneas base de software y las actividades de ACS son auditadas

peri6dicamente.
Nivel 2: Repetible

Habilidad 1
Existe o se establece un comit que tiene la autoridad para administrar las

lneas base de software del proyecto (es decir, un comit de control de
configuraci6n de software-CCCS)
EI CCCS:
1.
Autoriza el establecimiento de lneas base para el software y la identificaci6n

de itemes/unidades de configuracin.
2.
Representa los intereses del administrador del proyecto y de todos los

grupos que pueden ser afectados por cambios en las Lneas base del
software.
Habilidad 2
Garanta de calidad de hardware,

Administracin de configuracin de hardware, Ingeniera de hardware,
Ingeniera de manufactura,
Ingeniera de software (incluyendo todos los sub-grupos, tales como
diseo de software),
Ingeniera de sistemas, Pruebas de sistema,
Garanta de calidad de Software, Administracin de configuracin de
software
Administracin del contrato, y apoyo de documentacin
3.
Revisa y autoriza cambios en las lneas base del software.
4.
Autoriza la creacin de productos desde la librera de lneas base del

software.
Existe un grupo que es responsable de coordinar e implementar ACS para

el proyecto.
Un grupo es la coleccin de departamentos, administradores e individuos que tienen
responsabilidad por un grupo de tareas o actividades. Un grupo puede variar desde un
individuo asignado a jornada parcial, varios individuos asignados a jornada parcial de
Administracin de diferentes departamentos, hasta varios individuos delicados a jornada
completa. Las consideraciones sobre cuando implementare un grupo incluyen las actividades
y tareas asignadas, el tamao del proyecto, la estructura y la cultura de la organizacin
Algunos grupos, tales como el grupo de garanta de calidad de software, estn concentrados
en actividades de proyecto, y otros, como el grupo de ingeniera de procesos de software,
que esta concentrado en actividades horizontales de la organizacin
Este grupo coordina e implementa:

1.
La creacin y administracin de la librera de lineas base de software del

proyecto,
2.
El desarrollo, manutencin y distribucin de los planes, estndares y

procedimientos de ACS,

3.
Nivel 2: Repetible
La identificacin del conjunto de productos de trabajo que sern sometidos a

ACS
Un producto de trabajo es cualquier artefacto derivado de definir, mantener o usar un proceso
de software
Habilidad 3
4.
La administracin del acceso a la librera de lineas base de software
5.
La actualizacin de las lneas base de software
6.
La creacin de productos des de la librera de lineas base de software
7.
El registro de acciones de ACS
8.
La produccin y distribucin de informes de ACS
Se proporcionan los recursos y fondos necesarios para realizar las

actividades de ACS,
1.
Se designa un administrador con responsabilidad especifica por ACS.
2.
Se hacen disponibles herramientas para apoyar las actividades de ACS.

Estaciones de trabajo,
Programas de bases de datos, y
Herramientas de administracin de configuracin
Habilidad 4
Los miembros del grupo de ACS estn entrenados en los objetivos,

procedimientos y mtodos para ejecutar sus actividades de ACS.
Habilidad 5
Mtodos, estndares y procedimientos de ACS, y

Herramientas de ACS
Los miembros del grupo de ingeniera de software y otros grupos

relacionados con el software estn entrenados para ejecutar sus
actividades de ACS.
Ejemplos de otros grupos relacionados con el software incluyen:
Garanta de calidad de software, y
Apoyo de documentacin
Mtodos, estndares y procedimientos de ACS a ser seguidos por las actividades de ACS
dentro del grupo de ingeniera de software y otros grupos relacionados con el software, y
El rol, responsabilidades y autoridad del grupo de administracin de configuracin
Nivel 2: Repetible
Actividad 1
Para cada proyecto se prepara un plan de ACS de acuerdo a un

1.
Este plan es desarrollado en las etapas tempranas del proyecto y en paralelo

con la planificacin global de ste.
2.
EI plan de administracin de configuracin es revisado por todos los grupos

afectados.
3.
EI plan de administracin de configuracin es administrado Y controlado.

"Administrado y controlado" implica qu la versin del producto de trabajo en uso en su
cambios son incorporados de forma controlada (es decir, control de cambios).
Configuracin de Software.
Actividad 2
Un plan de ACS documentado Y aprobado, es usado como la base para

realizar las actividades de ACS.
EI plan cubre:
Actividad 3
1.
Las actividades de ACS a ser realizadas, la programacin de actividades, las

responsabilidades asignadas y los recursos requeridos (incluyendo personal,
herramientas y medios computacionales)
2.
Los requisitos de ACS y las actividades a ser realizadas por el grupo de

ingeniera de software y por otros grupos relacionados
Se establece un sistema de librera de administracin de configuracin

como un repositorio de las lineas base de software.
Esta librera:
1.
Apoya mltiples niveles de control de ACS,

Ejemplos de situaciones llevando mltiples niveles de control incluyen:
Diferencias en el nivel de contra! necesario en diferentes tiempos en el ciclo de vida (por

ejemplo, el control es mas ajustado a medida que el producto va madurando),
Diferencias en los niveles de control requeridos para sistemas de software solamente vs.
sistemas que incluyen tanto hardware como software
2.
Proporciona almacenamiento y recuperacin de las unidades de

configuracin
3.
Permite compartir y transferir las unidades de configuracin entre los grupos

afectados y dentro de los niveles de control de la librera
Nivel 2: Repetible
4.
Ayuda en el uso de estndares de producto para los itemes/unidades de

configuracin.
5.
Permite el almacenamiento y recuperacin de versiones de archivo de los

itemes/unidades de configuracin.
6.
Ayuda a asegurar una correcta creacin de los productos desde la librera de

lineas base del software.
7.
Permite el almacenamiento, realizacin y recuperacin de los registros de

administracin de configuracin.
8.
Apoya la produccin de informes de administracin de configuracin.
9.
Proporciona la manutencin de la estructura y contenidos de la librera.

Ejemplos de funciones de manutencin de la librera incluyen:
Actividad 4
Respaldo/restauracin de archivos de la librara, y

Recuperacin de errores de la librera
Se identifican los productos de software a ser puestos bajo administracin

de configuracin.
1.
Los tems/unidades de configuraci6n son seleccionadas de acuerdo a un

criterio documentado.
Ejemplos de productos de trabajo de software que pueden ser identificados como
itemes/unidades de configuracin incluyen:
Procedimientos de prueba de software,

Construcciones del sistema de software para las actividades de prueba,
Construcciones del sistema de software para entrega al cliente o usuarios finales,
Compiladores, y
Otras herramientas de soporte
Actividad 5
Documentacin relacionada con el proceso (par ejemplo. planes. estndares o

procedimientos)
Requerimientos de software.
Diseo de software,
Unidades de cdigo de software,
2.
Se asigna identificadores nicos a los itemes/unidades de configuracin.
3.
Se especifican las caractersticas de cada item/unidad de configuracin.
4.
Se especifican las lineas base a fa que pertenece cada item/unidad de

configuracin.
5.
Se especifica el punto en su desarrollo en que cada item/unidad es puesta

bajo administracin de configuracin.
6.
Se asignan responsables por cada item/unidad de configuracin.
Las solicitudes de cambios requeridos y los reportes de problemas para

todos los itemes/unidades de configuracin son iniciados, registrados,
revisados, aprobados y seguidos de acuerdo a un procedimiento
documentado.
Nivel 2: Repetible
Actividad 6

Los cambios en las lineas base son controlados de acuerdo a un
1.
Se realizan revisiones y/o pruebas de regresin para asegurar que los

cambios no produzcan efectos inesperados en la lnea base.
2.
Solo los itemes/unidades de configuracin aprobadas por el CCCS son

incorporados en la lnea base del software.
3.
Las unidades de configuracin son registradas a la entrada y la salida de

forma que se mantenga la conformidad e integridad de la librera de lineas
base de software.
Ejemplos de pasos de registro de entrada / salida incluyen:
Actividad 7
Verificar que las revisiones estn autorizadas,

Crear un log de cambios,
Mantener una copia de los cambios,
Actualizar la librera de lineas base de software,
y Archivar la lnea base de software reemplazada
Los productos son creados desde la librera de lineas base y su liberaci6n

es controlada de acuerdo a un procedimiento documentado.
Actividad 8
1.
El CCCS autoriza la creacin de productos desde la librera de lineas base

de software.
2.
Los productos construidos desde las lineas base de software, tanto para uso
interno y externo, son construidos solo a partir de los itemes/unidades de
configuracin en la librera de lineas base de software.
EI estado de las unidades de configuracin es almacenado de acuerdo a un

1.
Las acciones de administracin de configuracin son almacenadas con el

detalle suficiente para que el contenido y estado de cada item/unidad de
configuracin sea conocido y para que las versiones previas puedan sean
recuperadas.
2.
Se mantiene la historia y el estado actual de cada item/unidad de

configuracin.

Actividad 9
Nivel 2: Repetible
Se desarrollan informes estndares que documentan las actividades de

ACS y los contenidos de las lineas base, y se hacen disponibles a los
grupos e individuos afectados.
Ejemplos de informes incluyen:
Minutas de reuniones del CCCS,
Resumen y estado de las solicitudes de cambios,

Resumen y estado de los reportes de los problemas (incluyendo reparaciones),
Resumen de los cambios hechos alas lineas base de software,
Historia de revisiones de los Itemes/unidades de configuracin
Actividad 10
Estado de la lnea base de software, y

Resultados de las auditorias de lineas base realizadas
Se conducen auditorias de las lineas base del software de acuerdo a un

1.
Existe una adecuada preparacin para las auditorias.
2.
Se evalu la integridad de las lineas base de software.
3.
Se revise la estructura y medios del sistema de librera de administracin de

configuracin.
4.
Se verifique la completitud y correctitud del contenido de las libreras de

administracin de configuracin.
5.
Se verifique la aplicacin de los estndares y procedimientos de ACS

aplicables.
6.
Se informe los resultados de las auditorias a los administradores del

proyecto.
7.
Se sigan las acciones a tomar a partir de las auditorias hasta su cierre
Medicin y Anlisis
Medicin 1

actividades de ACS.
Ejemplos de mediciones incluyen:
Numero de solicitudes de cambios procesadas por unidad de tiempo

Cumplimiento de los hitos de las actividades de ACS en comparacin al plan, y
Trabaja terminado, "esfuerzo gastado, y costa de las actividades de ACS
Nivel 2: Repetible
Verificacin 1
Se revisan las actividades de ACS con la administracin superior en forma

peridica.
El principal propsito de las revisiones peridicas por lo administracin superior es generar
abstraccin adecuado y de manera oportuna EI tiempo entre revisiones debe cumplir con las
Verificacin 2
Se revisan las actividades de ACS con el administrador del proyecto en

forma peridica y ante eventos que lo requieran.
Verificacin 3
El grupo de Administracin de la Configuracin audita en forma peridica

las lneas base del software para verificar que estn conformes a la
documentacin que las define.
Verificacin 4
El grupo de Garanta de Cali dad de Software revisa y/o audita las

actividades y productos de trabajo de ACS e informa los resultados.
Refirase al rea clave de procesos de Garanta de Calidad de Software
Como mnimo, las revisiones y/o auditorias verifican:

1.
2.
Conformidad con los estndares y procedimientos de:

q
EI grupo de ACS,
EI CCCS
EI grupo de ingeniera de software, y
Otros grupos relacionados con el software
La ocurrencia de auditorias peridicas de las lineas base de software

Practicas CMM L2 (Espanol)

Diunggah oleh

Informasi Dokumen

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Practicas CMM L2 (Espanol)

Diunggah oleh

Hak Cipta:

Format Tersedia

Administracin de Requisitos

Un rea clave de proceso para el nivel 2: Repetible

Los planes, productos y actividades de software son mantenidos consistentes

Compromisos para desarrollar

EI proyecto sigue una poltica organizacional escrita, para la administracin

Esta poltica tpicamente especifica que:

Los requisitos de software son documentados.

Habilidades para desarrollar

Para cada proyecto, se establece la responsabilidad de analizar los

Esta responsabilidad cubre:

Los requisitos asignados son documentados.

Los requisitos no tcnicos que afectan y determinan las actividades del

productos a ser entregados,

Requisitos tcnicos del software,

funciones del usuario final, operador, soporte o integracin,

Se proporcionan los recursos y el financiamiento necesarios para la

Aquellas personas que tienen experiencia y tienen experiencia en el dominio

Herramientas de apoyo a la administracin de requisitos como planillas de

programas de planilla de calculo,

herramientas para administracin de las pruebas

Los miembros del grupo de ingeniera de software y de otros grupos

Mtodos, estndares, y procedimientos usados por el proyecto, y

EI grupo de ingeniera de software revisa los requisitos antes de que sean

Se identifican requisitos faltantes o incompletos

Los requisitos asignados son revisados para determinar si son:

factibles y apropiados para ser implementados en software,

clara y apropiadamente establecidos,

consistentes un os con otros, y

Cualquier requisito asignado identificado como con problemas potenciales,

Los compromisos resultantes de la asignacin de requisitos son revisados y

Refirase a la actividad del rea clave de proceso de Panificacin del Proyecto de

EI grupo de ingeniera de software usa los requisitos asignados como la

Son administrados y controlados.

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

Son la base para desarrollar los requisitos de software.

Los cambios a los requisitos asignados son revisados e incorporados en el

EI impacto en los compromisos existentes es evaluado, y los cambios son

Cambios a acuerdos hechos a individuos y grupos externos a la

Cambios a acuerdos internos a la organizacin son negociados con

Los cambios que se deben hacer en los planes, productos y actividades,

comunicados a los grupos e individuos afectados, y

seguidos hasta su finalizacin

Se hacen mediciones y son usadas para determinar el estado de las

Estado de cada uno de los requisitos identificados.

Las actividades para administrar los requisitos asignados son revisadas

Las actividades para administrar los requisitos asignados son revisadas

EI grupo de garanta de calidad revisa y/o audita las actividades de

Se deben revisar apropiadamente los planes, productos y actividades,

Se auditan los cambios en los compromisos negociados producto de los

Planificacin del Proyecto de Software

Planificacin del Proyecto de Software

Las estimaciones de software son documentadas para ser usadas en la

Las actividades y los compromisos del proyecto de software son planificados y

Los grupos y personas involucradas aprueban sus compromisos relacionados al

Compromisos para desarrollar

Se designa un administrador del proyecto de software para ser responsable

EI proyecto sigue una poltica organizacional de planificacin del proyecto

Los compromisos del proyecto de software se negocian entre:

el administrador del proyecto,

el administrador del proyecto de software, y

los otros administradores de software

La participacin de otros grupos de ingeniera en las actividades de

Planificacin del Proyecto de Software

Los grupos involucrados revisan del proyecto de software: