CMM7

Parte dos: Las Prácticas Clave del CMM para
Software
Capítulo 7: Las Áreas Claves del Proceso para el Nivel 2:
Repetible.
Los procesos de administración básicos del proyecto se establecen para seguir los
costos, el cronograma y la funcionalidad. Existe la disciplina necesaria de proceso como
para poder repetir éxitos anteriores en proyectos con aplicaciones similares.
Las áreas claves del proceso para el Nivel 2 son:
7.1
7.2
7.3
7.4
7.5
7.6
Administración de los Requerimientos
Planeamiento del Proyecto de Software
Seguimiento y Vista General del Proyecto de Software
Administración de un Subcontrato de Software
Garantía de la Calidad del Software
Administración de la Configuración del Software
7.1 Administración de los Requerimientos
Un área clave del proceso para el Nivel 2: Repetible.
El propósito de la Administración de los Requerimientos es establecer un entendimiento
común entre el cliente y el proyecto de software acerca de los requerimientos que
considerará el proyecto de software.
La Administración de los requerimientos implica el establecimiento y
mantenimiento de un acuerdo con el cliente sobre los requerimientos para el proyecto de
software. Este acuerdo se conoce como los “requerimientos del sistema asignados al
software”. El “cliente” puede interpretarse como el grupo de ingeniería de sistemas, el
grupo de mercadeo, otra organización interna, o un cliente externo. El acuerdo cubre
tanto los requerimientos técnicos como los que no son técnicos (por ejemplo, fechas de
entrega). El acuerdo forma la base para estimar, planear, realizar, y seguir las
actividades del proyecto de software durante el ciclo de vida del software.
La asignación de los requerimientos del sistema al software, al hardware, y a
otros componentes del sistema (por ejemplo, humanos) puede ser realizada por un grupo
externo al grupo de ingeniería del software (por ejemplo, el grupo de ingeniería del
sistema), y el grupo de ingeniería del software puede no tener un control directo sobre
esta asignación. Dentro de las limitaciones del proyecto, el grupo de ingeniería del
software toma los pasos apropiados para asegurar que los requerimientos del sistema
asignados al software, del que es responsable, se documenten y controlen.
Para lograr este control, el grupo de ingeniería del software revisa los
requerimientos iniciales y los revisados del sistema asignados al software para resolver
temas antes de ser incorporados al proyecto de software. Cada vez que los
requerimientos del sistema asignados al software cambien, los planes del software, los
productos de trabajo, y las actividades afectados se ajustan para que sigan siendo
consistentes con los requerimientos actualizados.
Objetivos
Objetivo 1
Se controlan los requerimientos del sistema asignados al software
para establecer una línea base para la ingeniería del software y para
el uso de la administración.
Objetivo 2
Los planes, productos y actividades de software se mantienen
consistentes con los requerimientos del sistema asignados al software.
Compromiso para el Desempeño
Compromiso 1
El proyecto sigue una política organizacional escrita para
administrar los requerimientos del sistema asignados al
software.
En estas prácticas llamamos “requerimientos asignados” a los
requerimientos del sistema asignados al software.
Los requerimientos asignados son el subconjunto de los
requerimientos del sistema que deben implementarse en los
componentes del software del sistema. Los requerimientos
asignados son una entrada primaria para el plan de desarrollo del
software. El análisis de los requerimientos del software elabora y
redefine los requerimientos asignados y resulta en requerimientos
de software que están documentados.
Esta política típicamente especifica que:
1. Los requerimientos asignados se documenten.
2. Los requerimientos asignados son revisados por:


Los administradores del software, y
Otros grupos afectados.
Ejemplos de grupos afectados incluyen:
Prueba del sistema,
Ingeniería del software (incluyendo todos los subgrupos,
como ser diseño del software),
Ingeniería del sistema,
Garantía de la calidad del software,
Administración de la configuración del software, y
Soporte de la documentación.
3. Los planes, productos de trabajo, y actividades del software se
cambian para que sean consistentes con los cambios a los
requerimientos asignados.
Capacidad para Desempeñarse
Capacidad 1 Para cada proyecto, se establece la responsabilidad para analizar los
requerimientos del sistema y asignarlos al hardware, al software y a
otros componentes del sistema.
El análisis y la asignación de los requerimientos del sistema no es
responsabilidad del grupo de ingeniería del software pero es un requisito
previo para su trabajo.
Esta responsabilidad cubre:
1. La administración y documentación de los requerimientos del sistema
y su asignación durante todo el ciclo de vida del proyecto.
2. Hacer efectivos los cambios a los requerimientos del sistema y su
asignación.
Capacidad 2 Se documentan los requerimientos asignados.
Los requerimientos asignados incluyen:
1. Los requerimientos no técnicos (o sea, los arreglos, condiciones, y/o
términos contractuales) que afectan y determinan las actividades del
proyecto de software.
Ejemplos de acuerdos, condiciones y términos contractuales incluyen:
Productos a entregar,
Fechas de entrega, y
Hechos importantes.
2. Los requerimientos técnicos para el software.
Ejemplos de requerimientos técnicos incluyen:
Funciones de usuario final, operador, soporte, o integración;
Requerimientos de performance;
Limitaciones de diseño;
Lenguaje de programación; y
Requerimientos de interfaz.
3. Los criterios de aceptación que se usarán para validar que los
productos del software satisfagan los requerimientos asignados.
Capacidad 3 Se proporcionan la financiación y los recursos adecuados para
administrar los requerimientos asignados.
1. Se asignan los individuos que tienen experiencia y son expertos en el
dominio de la aplicación y en la ingeniería del software para
administrar los requerimientos asignados.
2. Se ponen a disposición para su uso las herramientas para soportar las
actividades para administrar los requerimientos.
Ejemplos de herramientas de soporte incluyen:
Programas de hoja extendida (spreadsheet),
Herramientas para la administración de la configuración,
Herramientas para el seguimiento, y
Herramientas para la administración del texto.
Capacidad 4 Los integrantes del grupo de ingeniería de software y otros grupos
relacionados con el software se entrenan para realizar sus
actividades.
Ejemplos de entrenamiento incluyen:
Los métodos, estándares y procedimientos usados por el proyecto, y
El dominio de la aplicación.
Actividades Realizadas
Actividad 1
El grupo de ingeniería del software revisa los requerimientos
asignados antes de que se incorporen al proyecto de software.
1. Se identifican los requerimientos incompletos y los asignados
erróneamente.
2. Se revisan los requerimientos asignados para determinar si:




Son factibles y apropiados para implementar en el software,
Están enunciados de una manera clara y adecuada,
Son consistentes entre ellos, y
Se pueden probar.
3. Los requerimientos asignados que se identifican como que pueden
tener futuros problemas se revisan con el grupo responsable de
analizar y asignar los requerimientos del sistema, y se hacen los
cambios necesarios.
4. Se negocian los compromisos que resultan a partir de los
requerimientos asignados con los grupos afectados.
Ejemplos de grupos afectados incluyen:
Ingeniería del software (incluyendo todos los subgrupos, como ser
diseño del software),
Estimación del software,
Ingeniería de sistemas,
Prueba de sistemas,
Garantía de la calidad del software,
Administración de la configuración del software.
Administración del contrato, y
Soporte de documentación.
Referirse a la Actividad 6 del área clave de proceso Planeamiento del
Proyecto de Software para ver prácticas que cubren la negociación de
compromisos.
Actividad 2
El grupo de ingeniería del software usa los requerimientos asignados
como la base para los planes, productos de trabajo y actividades del
software.
Los requerimientos asignados:
1. Se administran y controlan.
“Se administran y controlan” implica que la versión del producto de
trabajo en uso en un momento dado (pasado o presente) es conocida (o
sea, control de versión), y los cambios se incorporan de una manera
controlada (o sea, control de cambios).
Si se desea un mayor grado de formalidad que lo que implica “se
administran y controlan”, el producto de trabajo puede ubicarse bajo la
disciplina completa de la administración de la configuración, como se
describe en el área clave de proceso Administración de la Configuración
del Software.
2. Son la base para el plan de desarrollo del software.
3. Son la base para desarrollar los requerimientos del software.
Actividad 3
Se revisan los cambios hechos a los requerimientos asignados y se
incorporan al proyecto de software.
1. Se evalúa el impacto de los compromisos existentes, y se negocian
los cambios según sea apropiado.

Los cambios de los compromisos hechos a individuos y grupos
externos a la organización se revisan con la administración senior.
Referirse a la Actividad 4 del área clave de proceso Planeamiento del
Proyecto de Software y a la Actividad 3 del área clave de proceso
Seguimiento y Vista General del Proyecto de Software para prácticas
que cubran los compromisos externos a la organización.

Los cambios a los compromisos dentro de la organización se
negocian con los grupos afectados.
Referirse a las Actividades 5, 6, 7 y 8 del área clave de proceso
Seguimiento y Vista General del Proyecto de Software para prácticas
que cubran la negociación de cambios a los compromisos.
2. Los cambios que se deben hacer a los planes, productos de trabajo y
actividades como resultado de los cambios a los requerimientos
asignados se:







Identifican,
Evalúan,
Evalúan para riesgos,
Documentan,
Planean,
Comunican a los grupos e individuos afectados, y
Siguen hasta que se completen.
Mediciones y Análisis
Medición 1
Se hacen y se usan mediciones para determinar el estado de las
actividades para administrar los requerimientos asignados.
Ejemplos de mediciones incluyen:
El estado de cada uno de los requerimientos asignados
Actividad de cambios para los requerimientos asignados, y
Cantidad acumulada de cambios a los requerimientos asignados,
incluyendo la cantidad total de cambios propuestos, abiertos,
aprobados e incorporados a la línea base del sistema.
Verificación de la Implementación
Verificación 1
Las actividades para administrar los requerimientos
asignados se revisan con la administración senior de manera
periódica.
El propósito primario de las revisiones periódicas por parte de la
administración senior es proporcionar consciencia y
conocimiento de las actividades del proceso de software a un
nivel de abstracción apropiado y con prontitud. El tiempo entre
revisiones debe satisfacer las necesidades de la organización y
puede ser largo, siempre y cuando haya mecanismos adecuados
para informar excepciones.
Referirse al área clave de proceso Seguimiento y Vista General
del Proyecto de Software para prácticas que cubran el contenido
típico de las revisiones generales de la administración senior.
Verificación 2
Las actividades para administrar los requerimientos
asignados se revisan con el administrador del proyecto tanto
de manera periódica como dependiendo de los eventos.
Referirse a la Verificación 2 del área clave de proceso
Seguimiento y Vista General del Proyecto de Software para
prácticas que cubran el contenido típico de las revisiones
generales de la administración del proyecto.
Verificación 3
El grupo de garantía de la calidad del software revisa y/o
audita las actividades y los productos de trabajo para
administrar los requerimientos asignados e informa los
resultados.
Referirse al área clave de proceso Garantía de la Calidad del
Software.
Como mínimo, estas revisiones y/o auditorías verifican que:
1. Se revisen los requerimientos asignados y se resuelvan los
problemas antes de que el grupo de ingeniería del software se
dedique a ellos.
2. Se revisen los planes, productos de trabajo y actividades del
software de una manera adecuada cuando los requerimientos
asignados cambian.
3. Se negocien los cambios en los compromisos que resulten de
los cambios a los requerimientos asignados con los grupos
afectados.
7.2 Planeamiento del Proyecto de Software
Un área clave del proceso para el Nivel 2: Repetible.
El propósito del Planeamiento del Proyecto de Software es establecer planes razonables
para llevar a cabo la ingeniería del software y para administrar el proyecto de software.
El Planeamiento del Proyecto de Software implica el desarrollo de estimaciones
para el trabajo a realizar, estableciendo los compromisos necesarios, y definiendo el
plan para realizar el trabajo.
El planeamiento del software comienza con un enunciado del trabajo a realizar y
otras limitaciones y objetivos que definen y limitan el proyecto de software (los
establecidos por las prácticas del área clave de proceso Administración de los
Requerimientos). El proceso de planeamiento del software incluye pasos para estimar el
tamaño de los productos del trabajo de software y de los recursos necesarios, para
producir un cronograma, para identificar y evaluar los riesgos del software, y para
negociar compromisos. Puede ser necesario hacer iteraciones con estos pasos para
establecer el plan para el proyecto de software (o sea, el plan de desarrollo del software).
Este plan proporciona las bases para realizar y administrar las actividades del
proyecto de software y estudia los compromisos con el cliente del proyecto de software
de acuerdo a los recursos, limitaciones y capacidades del proyecto de software.
Objetivos
Objetivo 1
Las estimaciones del software se documentan para su uso en el
planeamiento y seguimiento del proyecto de software.
Objetivo 2
Se planean y documentan las actividades y compromisos del proyecto
de software.
Objetivo 3
Los individuos y los grupos afectados acuerdan los compromisos
relacionados con el proyecto de software.
Compromiso para el Desempeño
Compromiso 1
Se designa un administrador del proyecto de software como
responsable de negociar los compromisos y de desarrollar el
plan de desarrollo del proyecto de software.
Compromiso 2
El proyecto sigue una política organizacional escrita para
planear el proyecto de software.
Esta política típicamente especifica que:
1. Los requerimientos del sistema asignados al software se usan
como la base para planear el proyecto de software.
Referirse a la Actividad 2 del área clave de proceso
Administración de los Requerimientos.
2. 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.
3. La posibilidad de que otros grupos de ingeniería se involucren
en las actividades de software se negocia con estos grupos y se
documenta.
Ejemplos de otros grupos de ingeniería incluyen:
Ingeniería de sistemas,
Ingeniería de hardware, y
Prueba de sistemas.
4. Los grupos afectados revisan el proyecto de software:




Estimaciones del tamaño del software,
Estimaciones del costo y el esfuerzo,
Plazos, y
Otros compromisos.
Ejemplos de grupos afectados incluyen:
Ingeniería del software (incluyendo todos los subgrupos,
como ser diseño de software),
Estimación del software,
Ingeniería de sistemas,
Prueba de sistemas,
Garantía de la calidad del software,
Administración de la configuración del software,
Administración del contrato, y
Soporte de la documentación.
5. La administración senior revisa todos los compromisos del
proyecto de software hechos hacia individuos y grupos
externos a la organización.
6. Se administra y controla el plan de desarrollo del proyecto de
software.
El término “plan de desarrollo del software” se usa en todas estas
prácticas para referirnos al plan general para administrar el
proyecto de software. El uso de la terminología “desarrollo” no
implica que haya que excluir los proyectos de mantenimiento y
soporte del software, y debe interpretarse adecuadamente en el
contexto del proyecto individual.
“Se administra y controla” implica que la versión del producto de
trabajo en uso en un momento dado (pasado o presente) es
conocida (o sea, control de versión), y que los cambios se
incorporan de una manera controlada (o sea, control de cambios).
Si se desea un mayor grado de control que lo que significa
“administrado y controlado”, el producto de trabajo puede
manejarse con la disciplina de la administración de la
configuración, según se describe en el área clave de proceso
Administración de la Configuración del Software.
Capacidad para Desempeñarse
Capacidad 1 Existe una enunciación aprobada y documentada de trabajo para el
proyecto de software.
1. la enunciación del trabajo cubre:



el alcance del trabajo,
los objetivos técnicos,
la identificación de los clientes y los usuarios finales,
Los usuarios a los que nos referimos en estas prácticas son los clientes
designados usuarios finales o los representantes de los usuarios finales.




Los estándares impuestos,
Las responsabilidades asignadas,
Los objetivos y las limitaciones en cuanto a costos y plazos,
Las dependencias entre el proyecto de software y otras
organizaciones,
Ejemplos de organizaciones incluyen:
El cliente,
Los subcontratistas, y
Los socios de “joint venture” (empresas conjuntas).


Los objetivos y las limitaciones de recursos, y
Otros objetivos y limitaciones para el
mantenimiento.
desarrollo
y/o
2. La enunciación del trabajo es revisada por:




El administrador del proyecto,
El administrador del software del proyecto
Los otros administradores de software, y
Otros grupos afectados.
3. La enunciación del trabajo se administra y controla.
Capacidad 2 Se asignan las responsabilidades para desarrollar el plan de
desarrollo del software
1. El administrador del proyecto de software, directamente o por
delegación, coordina el planeamiento del software del proyecto.
2. Se dividen las responsabilidades para los productos de trabajo y se
asignan a los administradores del software de manera que se puedan
rastrear y justificar.
Ejemplos de productos de trabajo de software incluyen:
Productos de trabajo para entregar al cliente externo o usuarios
finales, según sea apropiado;
Productos de trabajo para que usen otros grupos de ingeniería; y
Productos de trabajo importantes para uso interno del grupo de
ingeniería del software.
Capacidad 3 Se proporcionan fondos y recursos adecuados para planear el
proyecto de software.
1. Cuando es posible, los individuos con experiencia, que son expertos
en el dominio de aplicación del proyecto de software que se está
planeando, están disponibles para desarrollar el plan de desarrollo del
software.
2. Hay herramientas para soportar las actividades de planeamiento del
proyecto de software.
Ejemplos de herramientas de soporte incluyen:
Programas de hoja extendida (spreadsheet),
Modelos de estimación, y
Planeamiento del proyecto y cronogramas.
Capacidad 4 Los administradores del software, los ingenieros de software y otros
individuos involucrados con el planeamiento del proyecto de
software se entrenan en los procedimientos de planeamiento y
estimación del software aplicables a sus áreas de responsabilidad.
Actividades Realizadas
Actividad 1
El grupo de ingeniería de software participa del equipo de
proposiciones del proyecto.
1. El grupo de ingeniería del software está involucrado en:



Preparación y entrega de la propuesta,
Discusión y entrega de clarificaciones, y
Negociaciones de cambios a compromisos que afecten el proceso
de software.
2. El grupo de ingenieros del software revisa los compromisos
propuestos del proyecto.
Ejemplos de compromisos del proyecto incluyen:
Los objetivos técnicos del proyecto,
La solución técnica de software y del sistema,
El presupuesto, los plazos y los recursos del software, y
Los procedimientos y estándares del software.
Actividad 2
El planeamiento del proyecto de software se inicia en las etapas
tempranas y de manera paralela al planeamiento del proyecto
general.
Actividad 3
El grupo de ingeniería del software participa con otros grupos
afectados en el planeamiento del proyecto general durante todo el
ciclo de vida del proyecto.
1. El grupo de ingeniería del software revisa los planes a nivel del
proyecto.
Actividad 4
Los administradores senior revisan los compromisos del proyecto de
software hechos con individuos y grupos externos a la organización
de acuerdo a un procedimiento documentado.
Actividad 5
Se identifica o define un ciclo de vida del software con etapas
definidas de antemano y de tamaño manejable.
Ejemplos de ciclos de vida del software incluyen:
Cascada,
Cascada con superposiciones,
Espiral,
Construcción en serie, y
Cascada con superposiciones / prototipo único.
Actividad 6
El plan de desarrollo del proyecto de software se desarrolla de
acuerdo a un procedimiento documentado.
Este procedimiento típicamente especifica que:
1. El plan de desarrollo del software se basa y está de acuerdo con:




Los estándares del cliente, según sea apropiado,
Los estándares del proyecto,
La enunciación aprobada del trabajo, y
Los requerimientos asignados.
2. Los planes para grupos relacionados con el software y otros grupos de
ingeniería involucrados en las actividades del grupo de ingeniería del
software se negocian con esos grupos, los esfuerzos de soporte se
presupuestan, y se documentan los acuerdos.
Ejemplos de grupos relacionados con el software incluyen:
Garantía de la calidad del software,
Administración de la configuración del software,
Soporte de documentación.
Ejemplos de otros grupos de ingeniería incluyen:
Ingeniería de sistemas,
Ingeniería del hardware, y
Prueba del sistema.
3. Se negocian los planes para los grupos de ingeniería de software
involucrados en las actividades de otros grupos de software y otros
grupos de ingeniería relacionados con estos grupos, se presupuestan
los esfuerzos de soporte, y se documentan los acuerdos.
4. El plan de desarrollo del software es revisado por:




El administrador del proyecto,
El administrador de software del proyecto,
Los otros administradores de software, y
Otros grupos afectados.
5. El plan de desarrollo del software se administra y controla.
Actividad 7
Se documenta el plan para el proyecto de software.
En las prácticas claves, este plan o conjunto de planes se conoce como el
plan de desarrollo del software.
Referirse a la Actividad 1 del área clave de proceso Seguimiento y Vista
General del Proyecto de Software para prácticas relacionadas con el uso
del proyecto del plan de desarrollo del software.
El plan de desarrollo del software cubre:
1. Los objetivos, el alcance y el propósito del proyecto de software.
2. La selección del ciclo de vida del software
3. La identificación de los procedimientos, métodos y estándares
seleccionados para desarrollar y/o mantener el software.
Ejemplos de estándares y procedimientos de software incluyen:
Planeamiento del desarrollo del software,
Administración de la configuración del software,
Garantía de la calidad del software,
Diseño del software,
Rastreo y resolución de problemas, y
Mediciones del software.
4. La identificación de los productos de trabajo de software a
desarrollar.
5. Las estimaciones del tamaño de los productos de trabajo del software
y cualquier cambio a los productos de trabajo del software.
6. Las estimaciones de los costos y esfuerzos del proyecto de software.
7. El uso estimado de recursos críticos de computadora.
8. Los plazos del proyecto de software, incluyendo la identificación de
los puntos más importantes y revisiones.
9. La identificación y evaluación de los riesgos del proyecto de
software.
10. Los planes para las facilidades de la ingeniería del software del
proyecto y las herramientas de soporte.
Actividad 8
Se identifican los productos de trabajo del software que se necesitan
para establecer y mantener el control del proyecto de software.
Referirse a la Actividad 4 del área clave de proceso Administración de la
Configuración del Software.
Actividad 9
Se derivan las estimaciones para el tamaño de los productos de
trabajo del software (o cambios al tamaño de los productos de
trabajo del software) de acuerdo a un procedimiento documentado.
Este procedimiento típicamente especifica que:
1. Las estimaciones de tamaño se hacen para todas las actividades y
productos de trabajo del software más importantes.
Ejemplos de mediciones del tamaño del software incluyen:
Puntos de función,
Puntos de características,
Líneas de código,
Cantidad de requerimientos, y
Cantidad de páginas.
Ejemplos de tipos de productos de trabajo y actividades para los que se
hacen estimaciones de tamaño incluyen:
Software operacional y software de soporte,
Productos de trabajo que se pueden entregar y que no se pueden
entregar,
Productos de trabajo de software y que no son de software (por
ejemplo, documentos), y
Actividades para desarrollar, verificar y validar productos de
trabajo.
2. Los productos de software se descomponen con la granularidad
necesaria para satisfacer los objetivos de estimación.
3. Se usan los datos históricos que haya disponibles.
4. Se documentan las suposiciones de las estimaciones del tamaño.
5. Las estimaciones de tamaño se documentan, revisan y acuerdan.
Ejemplos de grupos e individuos que revisan y acuerdan el tamaño de las
estimaciones incluyen:
El administrador del proyecto,
El administrador del software del proyecto, y
Los otros administradores de software.
Actividad 10 Se derivan las estimaciones para los costos y esfuerzos del proyecto
de software de acuerdo a un procedimiento documentado.
Este procedimiento típicamente especifica que:
1. Las estimaciones para los costos y el esfuerzo del proyecto de
software están relacionadas con las estimaciones de tamaño de los
productos de trabajo de software (o del tamaño de los cambios).
2. Cuando están disponibles, se usan los datos de productividad
(históricos y/o actuales) para hacer las estimaciones; las fuentes y la
racional para estos datos se documentan.


Cuando es posible, los datos de productividad y costo son de los
proyectos de la organización.
Los datos de productividad y costo tienen en cuenta el esfuerzo y
los costos significantes que entran al hacer los productos de
trabajo de software.
Ejemplos de costos significantes que entran al hacer los productos de
trabajo de software incluyen:
Gastos de personal directos,
Gastos generales,
Expensas de viaje, y
Costos del uso de computadoras.
3. Las estimaciones de costo, personal y esfuerzo se basan en la
experiencia pasada.



Cuando sea posible deben usarse proyectos similares.
Se deriva la duración de las actividades.
Se preparan distribuciones de las estimaciones del esfuerzo, del
personal y del costo a lo largo del ciclo de vida del software.
4. Las estimaciones y las suposiciones hechas al derivar las
estimaciones se documentan, revisan y acuerdan.
Actividad 11 Se derivan las estimaciones para los recursos de computadora
críticos del proyecto de acuerdo a un procedimiento documentado.
Los recursos críticos de computadora pueden encontrarse en el entorno
del host, en el de la integración y prueba, en el del target, o en cualquier
combinación de éstos.
Este procedimiento típicamente especifica que:
1. Se identifican los recursos críticos de computadora para el proyecto.
Ejemplos de recursos críticos de computadora incluyen:
Capacidad de memoria de la computadora,
Uso del procesador de la computadora, y
Capacidad del canal de comunicaciones.
2. Las estimaciones para los recursos críticos de computadora se
relacionan con las estimaciones de:



El tamaño de los productos de trabajo de software,
La carga de procesamiento operacional, y
El tránsito de las comunicaciones.
3. Las estimaciones de los recursos críticos de la computadora se
documentan, revisan y acuerdan.
Actividad 12 El cronograma del software del proyecto se deriva de acuerdo a un
procedimiento documentado.
Este procedimiento típicamente especifica que:
1. El cronograma del software se relaciona con:


La estimación del tamaño de los productos de trabajo de software
(o el tamaño de los cambios), y
Los esfuerzos y costos del software.
2. El cronograma del software se basa en experiencias pasadas.

Cuando es posible se usan proyectos similares.
3. El cronograma del software se acomoda a las fechas más importantes
impuestas, a las fechas de dependencia críticas y a otras limitaciones.
4. Las actividades del cronograma del software son de una duración
apropiada y los puntos más importantes están separados en el tiempo
de manera adecuada para soportar la precisión en la medición del
progreso.
5. Las suposiciones hechas al derivar el cronograma se documentan.
6. El cronograma del software se documenta, revisa y acuerda.
Actividad 13 Los riesgos del software asociados con el costo, los recursos, el
cronograma y los aspectos técnicos del proyecto se identifican,
evalúan y documentan.
1. Los riesgos se analizan y se ordenan por prioridad basándose en su
impacto potencial en el proyecto.
2. Se identifican contingencias para los riesgos.
Ejemplos de contingencias incluyen:
Buffers del cronograma,
Planes de personal alternativos, y
Planes alternativos para equipamiento de computación adicional.
Actividad 14 Se preparan los planes para las facilidades de ingeniería del software
del proyecto y herramientas de soporte.
1. Las estimaciones de los requerimientos de capacidad para estas
facilidades y herramientas de soporte se basan en las estimaciones de
tamaño de los productos de trabajo de software y en otras
características.
Ejemplos de facilidades de desarrollo de software y herramientas de
soporte:
Computadoras de desarrollo de software y periféricos,
Computadoras de prueba de software y periféricos,
Software de entorno de la computadora objetivo, y
Otro software de soporte.
2. Se asignan responsabilidades y se negocian los compromisos para
procurar o desarrollar estas facilidades y herramientas de soporte.
3. Todos los grupos afectados revisan los planes.
Actividad 15 Se registran los datos del planeamiento del software.
1. La información registrada incluye las estimaciones y la información
asociada necesaria para reconstruir las estimaciones y evaluar su
razonabilidad.
2. Se administran y controlan los datos de planeamiento del software.
Mediciones y Análisis
Medición 1
Se hacen y se usan mediciones para determinar el estado de las
actividades del planeamiento del software.
Ejemplos de mediciones incluyen:
El completado de los puntos más importantes para las actividades
de planeamiento del proyecto del software comparado con el plan;
y
El trabajo completado, el esfuerzo expandido y los fondos gastados
en las actividades de planeamiento del proyecto de software
comparado con el plan.
Verificación de la Implementación
Verificación 1 Las actividades para el planeamiento del proyecto de software se
revisan con la administración senior de manera periódica.
El propósito primario de las revisiones periódicas por parte de la
administración senior es hacer notar las actividades del proceso de
software, y proporcionar conocimientos sobre ellas, con un nivel
apropiado de abstracción y a tiempo. El tiempo transcurrido ente las
revisiones debe satisfacer las necesidades de la organización y puede ser
largo, siempre y cuando haya mecanismos adecuados para informar
excepciones.
1. Se revisa el desempeño técnico, de costos, del personal y del
cronograma.
2. Se tratan conflictos y temas que no se han podido resolver en niveles
inferiores.
3. Se tratan los riesgos del proyecto de software.
4. Se asignan, revisan, siguen y cierran las acciones individuales.
5. Se prepara un informe sumario de cada reunión y se entrega a los
individuos y grupos afectados.
Verificación 2 Se revisan las actividades para el planeamiento del proyecto de
software con el administrador del proyecto tanto de manera
periódica como dependiente de los eventos.
1. Se representan los grupos afectados.
2. Se revisan el estado y los resultados actuales de las actividades de
planeamiento del proyecto de software comparándolos con la
enunciación del proyecto de software y los requerimientos asignados.
3. Se consideran las dependencias entre grupos.
4. Se consideran los conflictos y temas que no se pudieron resolver en
niveles inferiores.
5. Se revisan los riesgos del proyecto de software.
6. Se asignan, revisan, siguen y cierran las acciones individuales.
7. Se prepara un informe sumario de cada reunión y se entrega a los
individuos y grupos afectados.
Verificación 3 El grupo de garantía de la calidad del software revisa y/o audita las
actividades y los productos de trabajo para el planeamiento del
proyecto de software e informa los resultados.
Referirse al área clave de proceso Garantía de la Calidad del Software.
Como mínimo, las revisiones y/o auditorías verifican:
1.
2.
3.
4.
Las actividades para la estimación y planeamiento del software.
Las estimaciones para revisar y hacer los compromisos del proyecto.
Las actividades para preparar el plan de desarrollo del software.
Los estándares usados para preparar el plan de desarrollo del
software.
5. El contenido del plan de desarrollo del software.
7.3 Seguimiento y Vista General del Proyecto de Software
Un área clave del proceso para el Nivel 2: Repetible.
El propósito del Seguimiento y Vista General del Proyecto de Software es proporcionar
una visibilidad adecuada del progreso real de manera que la administración pueda tomar
medidas efectivas cuando el desempeño del proyecto de software se desvía de manera
importante de los planes del software.
El Seguimiento y Vista General del Proyecto de Software implica el seguimiento
y revisión de los logros y resultados del software en comparación con las estimaciones,
los compromisos y planes documentados, y el ajuste de estos planes basándose en los
logros y resultados reales.
Como base para las actividades de seguimiento de las actividades de software se
usa un plan documentado para el proyecto de software (o sea, el plan de desarrollo del
software, según se describe en el área clave de proceso Planeamiento del Proyecto de
Software), así como para comunicar el estado y para revisar los planes. La
administración monitorea las actividades del software. El progreso se determina
principalmente comparando el tamaño real del software, el costo y el cronograma con el
plan cuando se completan algunos productos de software seleccionados y en puntos
clave seleccionados. Cuando se determina que no se están satisfaciendo los planes del
proyecto de software, se toman acciones correctivas. Estas acciones pueden incluir la
revisión del plan de desarrollo del software para reflejar los logros reales y un
re-planeamiento del trabajo restante o tomar acciones para mejorar la performance.
Objetivos
Objetivo 1
Los resultados y el desempeño reales se comparan con los del plan
del software.
Objetivo 2
Cuando los resultados reales se desvían significativamente de los
planes del software se toman acciones correctivas y se administran
hasta su cierre.
Objetivo 3
Los grupos e individuos afectados acuerdan los cambios a los
compromisos del software.
Compromiso para el Desempeño
Compromiso 1
se designa un administrador del proyecto de software que sea
responsable para las actividades y resultados del software del
proyecto.
Compromiso 2
El proyecto sigue una política organizacional escrita para
administrar el proyecto de software.
Esta política típicamente especifica que:
1. Se usa y mantiene un plan de desarrollo de software
documentado como la base para el seguimiento del proyecto
de software.
2. El administrador del proyecto se mantiene informado del
estado y de los temas del proyecto de software.
3. Se toman acciones correctivas cuando el plan de software no
se está logrando, ya sea ajustando la performance o ajustando
los planes.
4. Los cambios a los compromisos del software se hacen con la
participación y el acuerdo de los grupos afectados.
Ejemplos de grupos afectados incluyen:
Ingeniería del software (incluyendo todos los subgrupos,
como ser diseño del software),
Estimaciones del software,
Ingeniería de sistemas,
Prueba del sistema,
Garantía de la calidad del software,
Administración de la configuración del software,
Administración del contrato, y
Soporte de documentación.
5. La administración senior revisa todos los cambios a los
compromisos y los nuevos compromisos del proyecto de
software hechos con individuos y grupos externos a la
organización.
Capacidad para Desempeñarse
Capacidad 1 Se documenta y aprueba un plan de desarrollo de software para el
proyecto de software.
Referirse a las Actividades 6 y 7 del área clave Planeamiento del
Proyecto de Software para prácticas que cubran el plan de
desarrollo del software.
Capacidad 2 El administrador de software del proyecto explícitamente asigna
responsabilidades para las actividades y los productos de trabajo de
software.
Las responsabilidades asignadas cubren:
1. Los productos de trabajo de software a desarrollar o los servicios a
proporcionar.
2. El esfuerzo y el costo para estas actividades de software.
3. El cronograma para estas actividades de software.
4. El presupuesto para estas actividades de software.
Capacidad 3 Se proporcionan recursos y fondos adecuados para seguir el
proyecto de software.
1. Se asignan responsabilidades específicas de seguimiento del proyecto
de software a los administradores del software y los líderes de las
tareas de software.
2. Se ponen a disposición de quien las necesite las herramientas
necesarias para soportar el seguimiento de software.
Ejemplos de herramientas de soporte incluyen:
Programas de hoja extendida (spreadsheet) y
Programas de planeamiento y cronograma del proyecto.
Capacidad 4 Los administradores del software se entrenan para administrar
aspectos técnicos y de personal del proyecto de software.
Ejemplos de entrenamiento incluyen:
Administración de proyectos técnicos;
Seguimiento y vista general del tamaño, esfuerzo, costo y plazos del
software; y
Administración del personal.
Capacidad 5 Los administradores de primera línea reciben orientación en los
aspectos técnicos del proyecto de software.
Ejemplos de orientación incluyen:
Los estándares y procedimientos de la ingeniería del proyecto de
software y
El dominio de aplicación del proyecto.
Actividades Realizadas
Actividad 1
Se usa un plan documentado de desarrollo de software para seguir
las actividades del software y para comunicar el estado.
Referirse a la Actividad 7 del área clave de proceso Planeamiento del
Proyecto de Software para prácticas que cubran el contenido del plan de
desarrollo del software.
Este plan de desarrollo de software:
1. Se actualiza a medida que el trabajo progresa para reflejar los logros,
en particular cuando se completa algún punto clave.
2. Está disponible para:





Actividad 2
El grupo de ingeniería de software (incluyendo todos los
subgrupos, como ser diseño del software),
Los administradores del software,
El administrador del proyecto,
La administración senior, y
Otros grupos afectados.
El plan de desarrollo del software del proyecto se revisa de acuerdo a
un procedimiento documentado.
Referirse a la Actividad 6 del área clave de proceso Planeamiento del
Proyecto de Software para prácticas que cubran las actividades para
producir el plan de desarrollo del software.
Este procedimiento especifica que:
1. Se revisa el plan de desarrollo, según sea apropiado, para incorporar
refinamientos al plan y para incorporar cambios a los planes,
particularmente cuando los planes cambian significativamente.
En todos los cambios del plan deben reflejarse las interdependencias
entre los requerimientos asignados, las limitaciones del diseño, los
recursos, los costos y los plazos.
2. El plan de desarrollo del software se actualiza para incorporar todos
los nuevos compromisos del proyecto de software y los cambios a los
compromisos.
3. En cada revisión se revisa el plan de desarrollo del software.
4. El plan de desarrollo del software se administra y controla.
“Se administra y controla” implica que la versión del producto de trabajo
que se encuentra en uso en un momento dado (pasado o presente) es
conocida (o sea, control de versión) y que los cambios se incorporan de
una manera controlada (o sea, control de cambios).
Si se desea un mayor grado de control que el que implica
“administrado y controlado”, el producto de trabajo puede ubicarse bajo
la disciplina total de la administración de la configuración, según se
describe en el área clave de proceso Administración de la Configuración
del Software.
Actividad 3
Los compromisos del proyecto de software y los cambios a los
compromisos hechos con individuos y grupos externos a la
organización se revisan con la administración senior de acuerdo a un
procedimiento documentado.
Actividad 4
Los cambios a los compromisos aprobados que afectan al proyecto
de software se comunican a los miembros del grupo de ingeniería del
software y a otros grupos relacionados con el software.
Ejemplos de otros grupos relacionados con el software incluyen:
Garantía de la calidad del software,
Administración de la configuración del software, y
Soporte de documentación.
Actividad 5
Los tamaños de los productos de software (o los tamaños de los
cambios a los productos de software) se siguen, y se toman acciones
correctivas cuando sea necesario.
Referirse a la Actividad 9 del área clave de proceso Planeamiento del
Proceso de Software para prácticas que cubran la derivación del tamaño
de las estimaciones.
1. Se siguen los tamaños de los productos de trabajo de software más
importantes (o los tamaños de los cambios).
2. El tamaño real del código (generado, completamente probado, y
entregado) se compara con las estimaciones documentadas en el plan
de desarrollo del software.
3. Las unidades reales de documentación entregada se comparan con las
estimaciones documentadas en el plan de desarrollo del software.
4. El tamaño general proyectado de los productos de trabajo del
software (estimaciones combinadas con los reales) se redefine,
monitorean y ajustan regularmente.
5. Los cambios en las estimaciones de tamaño de los productos de
trabajo de software que afectan los compromisos del software se
negocian con los grupos afectados y se documentan.
Actividad 6
Se siguen el esfuerzo y los costos del software del proyecto, y se
toman acciones correctivas cuando sea necesario.
Referirse a la Actividad 10 del área clave de proceso Planeamiento del
Proyecto de Software para prácticas que cubran la derivación de las
estimaciones del costo.
1. Se comparan los gastos reales de esfuerzo y costo en el tiempo y
proporcionalmente al trabajo realizado con las estimaciones
documentadas en el plan de desarrollo del software para identificar
excesos e incumplimientos potenciales.
2. Se siguen los costos del software y se comparan con las estimaciones
documentadas en el plan de desarrollo del software.
3. Se comparan el esfuerzo y el personal con las estimaciones
documentadas en el plan de desarrollo del software.
4. Los cambios de personal y otros costos del software que afecten los
compromisos del software se negocian con los grupos afectados y se
documentan.
Actividad 7
Se siguen los recursos críticos de computadora del proyecto, y se
toman acciones correctivas cuando sea necesario.
Referirse a la Actividad 11 del área clave de proceso Planeamiento del
Proyecto de Software para prácticas que cubran la derivación de
estimaciones de recursos de computadoras.
1. Se siguen y se comparan con las estimaciones los usos real y
proyectado de los recursos críticos de computadora para cada
componente importante del software según se documenta en el plan
de desarrollo del software.
2. Los cambios en las estimaciones de recursos de computadora críticos
que afectan los compromisos del software se negocian con los grupos
afectados y se documentan.
Actividad 8
Se sigue el cronograma del software del proyecto, y se toman
acciones correctivas según sea necesario.
Referirse a la Actividad 12 del área clave de proceso Planeamiento del
Proyecto de Software para prácticas que cubran la derivación del
cronograma.
1. Se compara el completado real de las actividades del software, puntos
importantes y otros compromisos con el plan de desarrollo del
software.
2. Se evalúan los efectos de los completados antes y después de plazo
para impactos sobre actividades futuras y puntos importantes.
3. Las revisiones del cronograma del software que afectan los
compromisos del software se negocian con los grupos afectados y se
documentan.
Actividad 9
Se siguen las actividades técnicas de la ingeniería del software, y se
toman acciones correctivas según sea necesario.
1. Los miembros del grupo de ingeniería del software informan el
estado técnico a su administrador de primera línea regularmente.
2. Se comparan los contenidos de edición del software para
construcciones sucesivas con los planes documentados en el plan de
desarrollo del software.
3. Se informan y documentan los problemas identificados en cualquiera
de los productos de trabajo de software.
4. Los informes de problemas se siguen hasta su cierre.
Actividad 10 Se siguen los riesgos de software asociados con el costo, los recursos,
los plazos y los aspectos técnicos del proyecto.
Referirse a la Actividad 13 del área clave de proceso Planeamiento del
Proyecto de Software para prácticas que cubran la identificación de
riesgos.
1. Las prioridades de los riesgos y de las contingencias para los riesgos
se ajustan a medida que la información adicional se vuelve
disponible.
2. Las áreas de alto riesgo se revisan con el administrador del proyecto
de manera regular.
Actividad 11 Se registran los datos de mediciones reales y los datos de
replaneamiento para el proyecto de software.
Referirse a la Actividad 15 del área clave de proceso Planeamiento del
Proyecto de Software para prácticas que cubran el registro de datos del
proyecto.
1. La información registrada incluye las estimaciones e información
asociada necesarias para reconstruir las estimaciones y verificar su
razonabilidad.
2. Los datos de replaneamiento del software se administran y controlan.
3. Los datos de planeamiento del software, los datos de replaneamiento,
y los datos de mediciones reales se archivan para ser usados por el
proyecto actual y por proyectos futuros.
Actividad 12 El grupo de ingeniería del software conduce revisiones periódicas
internas para seguir el progreso técnico, los planes, la performance y
otros temas y compararlos con el plan de desarrollo del software.
Estas revisiones se conducen entre:
1. Los administradores de primera línea del software y sus líderes de
tareas de software.
2. El administrador de software del proyecto, los administradores de
primera línea del software y otros administradores de software, según
sea apropiado.
Actividad 13 Se conducen revisiones formales para estudiar los logros y resultados
del proyecto de software en puntos clave seleccionados de acuerdo a
un procedimiento documentado.
Estas revisiones:
1. Están planeadas para que ocurran en puntos importantes del
cronograma del proyecto de software, como ser en el inicio o el final
de etapas seleccionadas.
2. Se conducen con el cliente, el usuario final y los grupos afectados
dentro de la organización, según sea apropiado.
Los usuarios finales que se nombran en estas prácticas son los clientes
designados como usuarios finales o representantes de usuarios finales.
3. Usan materiales que son revisados y aprobados por los
administradores de software responsables.
4. Estudian los compromisos, planes, y estado de las actividades del
software.
5. Resultan en la identificación y documentación de temas importantes,
unidades de acción y decisiones.
6. Estudian los riesgos del proyecto de software.
7. Resultan en el refinamiento del plan de desarrollo del software, según
sea necesario.
Mediciones y Análisis
Medición 1
Se hacen y se usan mediciones para determinar el estado de las
actividades de seguimiento y vista general del software.
Ejemplos de mediciones incluyen:
Esfuerzo y otros recursos usados para realizar las actividades de
seguimiento y vista general; y
Actividad de cambio para el plan de desarrollo del software, que
incluye cambios a las estimaciones de tamaño de los productos de
trabajo del software, estimaciones del costo del software,
estimaciones de recursos críticos de computadoras y plazos.
Verificación de la Implementación
Verificación 1 Las actividades para el seguimiento y vista general del proyecto de
software son revisadas por la administración senior de manera
periódica.
El propósito primario de las revisiones periódicas por parte de la
administración senior es crear conciencia y conocimiento sobre las
actividades del proceso de software en un nivel apropiado de
abstracción y de una manera rápida. El tiempo entre revisiones debe
satisfacer las necesidades de la organización y puede ser largo,
siempre y cuando haya mecanismos adecuados para informar
excepciones.
1. Se revisa la performance técnica, de los costos, del personal y del
cronograma.
2. Se tratan los conflictos y los temas que no se pudieron resolver en
niveles inferiores.
3. Se tratan los riesgos del proyecto de software.
4. Se tratan, revisan, y siguen hasta su finalización temas relacionados
con la acción.
5. Se presenta y distribuye a los grupos afectados un informe de estado
de cada reunión.
Verificación 2 Las actividades para el seguimiento y la vista general del proyecto de
software se revisan con el administrador del proyecto tanto de
manera periódica como dependiente de los eventos.
1. Se representan los grupos afectados.
2. Se revisa la performance técnica, de costos, del personal y de los
plazos en comparación con el plan de desarrollo.
3. Se revisa el uso de los recursos críticos de computadora; se informan
las estimaciones actuales y el uso real de estos recursos críticos en
comparación con las estimaciones originales.
4. Se tratan las dependencias entre grupos.
5. Se tratan los conflictos y temas que no se pudieron resolver en niveles
inferiores.
6. Se tratan los riesgos del proyecto de software.
7. Se asignan, revisan y siguen hasta su finalización temas relacionados
con la acción.
8. Se prepara y distribuye a los grupos afectados un informe resumen de
cada reunión.
Verificación 3 El grupo de garantía de la calidad del software revisa y/o audita las
actividades y productos de trabajo para el seguimiento y vista
general del proyecto de software e informa los resultados.
Referirse al área clave de proceso Garantía de la Calidad del
Software.
Como mínimo, las revisiones y/o auditorías verifican:
1.
2.
3.
4.
Las actividades para rever y revisar los compromisos.
Las actividades para revisar el plan de desarrollo del software.
El contenido del plan de desarrollo de software revisado.
Las actividades para seguir las limitaciones de diseño, costo,
cronograma, riesgos y técnicas, y la funcionalidad y la performance.
5. Las actividades para conducir las revisiones técnicas y de
administración planeadas.
7.4 Administración de los Subcontratos de Software
Un área clave del proceso para el Nivel 2: Repetible.
El propósito de la Administración de los Subcontratos de Software es seleccionar
subcontratistas de software calificados y administrarlos de manera efectiva.
La Administración de los Subcontratos de Software implica seleccionar un
subcontratista de software, establecer compromisos con el subcontratista, y seguir y
revisar los resultados y la performance del subcontratista. Estas prácticas cubren la
administración de un (solo) subcontratista de software, así como la administración del
componente de software de un subcontrato que incluye software, hardware y
posiblemente otros componentes de sistemas.
El subcontratista se selecciona sobre la base de su habilidad de realizar el
trabajo. Muchos factores contribuyen a la decisión de subcontratar una porción del
trabajo principal del contratista. Los subcontratistas pueden seleccionarse basándose en
alianzas estratégicas de negocios, así como consideraciones técnicas. Las prácticas de
esta área clave de proceso tratan los procesos de adquisición tradicionales asociados con
la subcontratación de una porción definida del trabajo a otra organización.
Al subcontratar se establece un acuerdo documentado que cubre los
requerimientos técnicos y no técnicos (por ejemplo, fechas de entrega) y se usa como la
base para administrar el subcontrato. Se documentan el trabajo a ser realizado por el
subcontratista y los planes para el trabajo. Los estándares a seguir por el subcontratista
son compatibles con los estándares del contratista primario.
Las actividades de planeamiento, seguimiento y vista general del software para el
trabajo subcontratado son realizadas por el subcontratista. El contratista primario se
asegura que estas actividades sean realizadas de manera adecuada y que los productos
de software que entrega el subcontratista satisfagan sus criterios de aceptación. El
contratista primario trabaja con el subcontratista para administrar interfaces de
procesos y productos.
Objetivos
Objetivo 1
El contratista primario selecciona subcontratistas de software
calificados.
Objetivo 2
El contratista primario y el subcontratista de software acuerdan sus
compromisos mutuos.
Objetivo 3
El contratista primario y el subcontratista de software mantienen
comunicaciones continuas.
Objetivo 4
El contratista primario sigue los resultados reales y la performance
del subcontratista y los compara con los compromisos.
Compromiso para el Desempeño
Compromiso 1
El proyecto sigue una política organizacional escrita para
administrar el subcontrato de software.
Esta política típicamente especifica que:
1. Se usan estándares y procedimientos documentados para
seleccionar subcontratistas de software y administrar
subcontratos de software.
2. Los acuerdos contractuales forman la base para administrar el
subcontrato.
3. Los cambios al subcontrato se hacen con la participación y el
acuerdo tanto del contratista primario como del subcontratista.
Compromiso 2
Se designa un administrador del subcontrato para que sea el
responsable de establecer y mantener el subcontrato de
software.
1. El administrador del subcontrato tiene conocimiento y
experiencia en ingeniería de software o tiene asignados
individuos que tienen ese conocimiento y experiencia.
2. El administrador del subcontrato es responsable de coordinar
el alcance técnico del trabajo a subcontratar y los términos y
condiciones del subcontrato con las partes afectadas.
El grupo de ingeniería de sistemas del proyecto y el grupo
de ingeniería de software definen el alcance técnico del
trabajo a subcontratar.
Los grupos de función de negocios apropiados, como ser
compras, finanzas y legales, establecen y monitorean los
términos y condiciones del subcontrato.
3. El administrador del subcontrato es responsable de:



Seleccionar el subcontratista de software,
Administrar el subcontrato de software, y
Arreglar el soporte posterior al subcontrato de los
productos subcontratados.
Capacidad para Desempeñarse
Capacidad 1 Se proporcionan recursos y fondos adecuados para seleccionar el
subcontratista de software y administrar el subcontrato.
1. Se asignan responsabilidades específicas a los administradores de
software y otros individuos para administrar el subcontrato.
2. Se ponen a disposición las herramientas necesarias para soportar la
administración del subcontrato.
Ejemplos de herramientas de soporte incluyen:
Modelos de estimación,
Programas de hoja extendida (spreadsheet), y
Programas de scheduling y de administración del proyecto.
Capacidad 2 Los administradores de software y otros individuos que están
involucrados en establecer y administrar el subcontrato de software
se entrenan para realizar estas actividades.
Ejemplos de entrenamiento incluyen:
Preparación y planeamiento para el subcontrato de software,
Evaluación de la capacidad de proceso de software de los que se
presentan para ganar el subcontrato,
Evaluación de los planes y estimaciones de software de los que se
presentan para ganar el subcontrato,
Selección de un subcontratista, y
Administración del subcontrato.
Capacidad 3 Los administradores de software y otros individuos que están
involucrados en la administración del subcontrato de software
reciben una reorientación en los aspectos técnicos del subcontrato.
Ejemplos de orientación incluyen:
Dominio de aplicación,
Tecnologías de software que se están aplicando,
Herramientas de software que se están usando,
Metodologías que se están usando,
Estándares que se están usando, y
Procedimientos que se están usando.
Actividades Realizadas
Actividad 1
Se define y planea el trabajo a subcontratar de acuerdo a un
procedimiento documentado.
Este procedimiento típicamente especifica que:
1. Los productos y las actividades de software a subcontratar se
seleccionan sobre la base de una evaluación balanceada tanto de
características técnicas como no técnicas del proyecto.


Las funciones o subsistemas a subcontratar se seleccionan de
acuerdo a las capacidades de los subcontratistas potenciales.
La especificación de los productos y actividades de software a
subcontratar se determina basándose en un análisis sistemático y
un particionamiento adecuado de los requerimientos de software y
los del sistema.
2. La especificación del trabajo a subcontratar y los estándares y
procedimientos a seguir se derivan de:





El enunciado del trabajo,
Los requerimientos del sistema asignados al software,
Los requerimientos del software,
El plan de desarrollo del software, y
Los procedimientos y estándares del software.
3. Un enunciado de un subcontrato de trabajo se:



Prepara,
Revisa,
Acuerda,
Ejemplos de individuos que revisan y acuerdan la enunciación de trabajo
del subcontrato incluyen:
El administrador del proyecto,
El administrador de software del proyecto,
Los administradores de software responsables,
El administrador de la administración de la configuración del
software,
El administrador de la garantía de la calidad del software, y
El administrador del subcontrato.


Revisa cuando es necesario, y
Se administra y controla.
“Se administra y controla” implica que la versión del producto de trabajo
en uso en un momento dado (pasado o presente) es conocida (o sea,
control de versión), y que los cambios se incorporan de una manera
controlada (o sea, control de cambios).
Si se desea un mayor grado de control que el que implica
“administrado y controlado”, el producto de trabajo puede ubicarse bajo
la disciplina total de la administración de la configuración, según se
describe en el área clave de proceso Administración de la Configuración
del Software.
Referirse a la Capacidad 1 del área de proceso clave Planeamiento del
Proyecto de Software para prácticas que cubran los contenidos típicos de
la enunciación del trabajo.
4. Se prepara un plan para seleccionar un subcontratista al mismo
tiempo que la enunciación de trabajo del subcontrato y se revisa,
según sea apropiado.
Actividad 2
Se selecciona el subcontratista de software sobre la base de una
evaluación de la capacidad para realizar el trabajo de los que se han
presentado a la licitación del subcontrato, de acuerdo a un
procedimiento documentado.
Este procedimiento cubre la evaluación de:
1. Propuestas presentadas para el subcontrato planeado.
2. Registros del desempeño anterior en trabajos similares, si existe.
3. Las ubicaciones geográficas de los que se presentaron a la licitación
del subcontrato con relación al subcontratista primario.
La administración efectiva de algunos subcontratos puede requerir
interacciones frecuentes cara a cara.
4. Capacidades de administración del software y de la ingeniería del
software.
Un ejemplo de un método para evaluar las capacidades de los
subcontratistas es el método de Evaluación de la Capacidad del Software
SEI.
5. Personal disponible para realizar el trabajo.
6. Experiencia en aplicaciones similares, incluyendo experticia en el
software en el equipo de administración del software del
subcontratista.
7. Recursos disponibles.
Ejemplos de recursos:
Facilidades,
Hardware,
Software, y
Entrenamiento.
Actividad 3
El acuerdo contractual entre el contratista primario y el
subcontratista de software se usa como la base para administrar el
subcontrato.
El acuerdo contractual documenta:
1. Los términos y condiciones.
2. La enunciación del trabajo.
Referirse a la Capacidad 1 del área clave de proceso Planeamiento del
Proceso de Software para prácticas que cubran los contenidos típicos de
una enunciación de trabajo.
3. Los requerimientos para los productos a desarrollar.
4. La lista de dependencias entre el subcontratista y el contratista
primario.
5. Los productos subcontratados a ser entregados al contratista primario.
Ejemplos de productos incluyen:
Código fuente,
Plan de desarrollo del software,
Entorno de simulación,
Documentación de diseño, y
Plan de prueba de aceptación.
6. Las condiciones bajo las cuales se deben presentar las revisiones a los
productos.
7. Los procedimientos de aceptación y los criterios de aceptación a usar
al evaluar los productos subcontratados antes de ser aceptados por el
contratista primario.
8. Los procedimientos y criterios de evaluación que usará el contratista
primario para monitorear y evaluar el desempeño del subcontratista.
Actividad 4
El contratista primario revisa y aprueba un plan documentado de
desarrollo de software del subcontratista.
1. Este plan de desarrollo de software cubre (en forma directa o por
referencia) los puntos adecuados del plan de desarrollo de software
del contratista primario.
En algunos casos el plan de desarrollo de software del contratista
primario puede incluir el plan de desarrollo de software para el
subcontratista, en cuyo caso no se necesita un plan separado de
desarrollo de software del subcontratista.
Actividad 5
Se usa un plan documentado de desarrollo de software del
subcontratista que haya sido aprobado para seguir las actividades
del software y comunicar el estado.
Actividad 6
Los cambios a la enunciación del trabajo del subcontratista de
software, a los términos y condiciones del subcontrato y a otros
compromisos se resuelven de acuerdo a un procedimiento
documentado.
1. Este procedimiento típicamente especifica que participan todos los
grupos afectados tanto del contratista primario como del
subcontratista.
Actividad 7
La administración del contratista primario conduce revisiones
periódicas de estado / coordinación con la administración del
subcontratista de software.
1. El subcontratista recibe información en cuanto a las necesidades y
deseos de los clientes del producto y usuarios finales, según sea
necesario.
Los usuarios finales a los que se nombra en estas prácticas son los
clientes designados usuarios finales o los representantes de los usuarios
finales.
2. Se revisa la performance técnica, de costos, de personal y de
cronograma del subcontratista en comparación con el plan de
desarrollo de software del subcontratista.
3. Se revisan los recursos de computadora designados como críticos
para el proyecto; se sigue la contribución del subcontratista a las
estimaciones actuales y se comparan con las estimaciones para cada
componente de software según se documenta en el plan de desarrollo
de software del subcontratista.
4. Se tratan las dependencias y compromisos críticos entre el grupo de
ingeniería de software del subcontratista y otros grupos del
subcontratista.
5. Se tratan los compromisos y dependencias críticas entre el contratista
primario y el subcontratista.

Se revisan los compromisos del subcontratista con el contratista
primario y los compromisos del contratista primario con el
subcontratista.
6. Se trata el incumplimiento del subcontrato.
7. Se tratan los riesgos del proyecto que involucran el trabajo del
subcontratista.
8. Se tratan los conflictos y temas que el subcontratista no puede
resolver internamente.
9. Se asignan temas de acción, se revisan y se siguen hasta su cierre.
Actividad 8
Se sostienen revisiones periódicas internas e intercambios con el
subcontratista de software.
Estas revisiones:
1. Proporcionan información al subcontratista acerca de las necesidades
y deseos de los clientes y los usuarios finales, según sea apropiado.
2. Monitorean las actividades técnicas del subcontratista.
3. Verifican que la interpretación e implementación de los
requerimientos técnicos por parte del subcontratista esté de acuerdo
con los requerimientos del contratista primario.
4. Verifican que se estén cumpliendo los compromisos.
5. Verifican que los temas técnicos se resuelvan con prontitud.
Actividad 9
Se conducen revisiones formales para tratar los logros y resultados
de la ingeniería de software del subcontratista en puntos clave
seleccionados, de acuerdo a un procedimiento documentado.
Este procedimiento típicamente especifica que:
1. Las revisiones se planean y documentan en la enunciación del trabajo.
2. Las revisiones tratan los compromisos, los planes y el estado de las
actividades de software por parte del subcontratista.
3. Se identifican y documentan temas importantes, temas de acción y
decisiones.
4. Se tratan los riesgos del software.
5. Se redefine el plan de desarrollo de software del subcontratista, según
sea apropiado.
Actividad 10 El grupo de garantía de la calidad del software del contratista
primario monitorea las actividades del subcontratista para
garantizar la calidad del software, de acuerdo a un procedimiento
documentado.
Este procedimiento típicamente especifica que:
1. Los planes, recursos, procedimientos y estándares del subcontratista
se revisan periódicamente para asegurar que son adecuados para
monitorear la performance del subcontratista.
2. Se conducen revisiones regulares del subcontratista para asegurar que
se están siguiendo los procedimientos y estándares aprobados.


El grupo de garantía de la calidad del software del contratista
primario verifica las actividades de ingeniería de software y los
productos del subcontratista.
El grupo de garantía de la calidad del software del contratista
primario audita los registros de garantía de la calidad del software
del subcontratista, según sea apropiado.
3. Los registros del subcontratista de sus actividades para garantizar la
calidad del software se auditan de manera periódica para evaluar cuán
bien se están siguiendo los planes, estándares y procedimientos de
garantía de la calidad del software.
Actividad 11 El grupo de administración de la configuración del software del
contratista primario monitorea las actividades del subcontratista
para la administración de la configuración del software, de acuerdo
a un procedimiento documentado.
Este procedimiento típicamente especifica que:
1. Se revisan los planes, recursos, procedimientos y estándares del
subcontratista para la administración de la configuración del software
para asegurarse que sean adecuados.
2. El contratista primario y el subcontratista coordinan sus actividades
en temas relacionados con la administración de la configuración del
software para asegurar que los productos del subcontratista pueden
integrarse o incorporarse con prontitud al entorno del proyecto del
contratista primario.
3. La biblioteca (library) base del software del subcontratista se audita
de manera periódica para evaluar cuán bien se están siguiendo los
estándares y procedimientos para la administración de la
configuración del software y cuán efectivos son para administrar la
línea base del software.
Actividad 12 El contratista primario conduce pruebas de aceptación como parte
de la entrega de los productos de software del subcontratista de
acuerdo a un procedimiento documentado.
Este procedimiento típicamente especifica que:
1. El contratista primario y el subcontratista definen, revisan y aprueban
los procedimientos y criterios de aceptación para cada producto antes
de la prueba.
2. Se documentan los resultados de las pruebas de aceptación.
3. Se establece un plan de acción para cualquier producto de software
que no pase su prueba de aceptación.
Actividad 13 La performance del subcontratista de software se evalúa de manera
periódica, y la evaluación se revisa con el subcontratista.
La evaluación de la performance del subcontratista proporciona una
oportunidad para que el subcontratista sepa si está satisfaciendo las
necesidades del cliente o no (o sea, del contratista primario). Un
mecanismo de revisiones de cuota de recompensa por la performance
proporciona este tipo de "feedback", en oposición a las revisiones
periódicas técnicas y de coordinación que pueden ocurrir todo a lo largo
del proyecto. La documentación de estas evaluaciones también actúa
como entrada para actividades futuras de selección de subcontratistas.
Mediciones y Análisis
Medición 1
Las mediciones se hacen y se usan para determinar el estado de las
actividades para administrar el subcontrato de software.
Ejemplos de mediciones incluyen:
Costos de las actividades para administrar el subcontrato en
comparación con el plan,
Fechas reales de entrega para productos subcontratados en
comparación con el plan, y
Fechas reales de entregas del contratista primario al subcontratista en
comparación con el plan.
Verificación de la Implementación
Verificación 1 Las actividades para administrar el subcontrato de software se
revisan con la administración senior de manera periódica.
El propósito primario de las revisiones periódicas por parte de la
administración senior es proporcionar consciencia y conocimiento sobre
las actividades del proceso de software en un nivel apropiado de
abstracción y con prontitud. El tiempo transcurrido entre las revisiones
debe satisfacer las necesidades de la organización y puede ser largo,
siempre y cuando haya mecanismos adecuados para el informe de
excepciones.
Referirse a la Verificación 1 del área clave de proceso Seguimiento y
Vista General del Proyecto de Software para prácticas que cubran el
contenido típico de las revisiones generales de la administración senior.
Verificación 2 Las actividades para administrar el subcontrato de software se
revisan con el administrador del proyecto tanto de manera periódica
como dependiente de los eventos.
Referirse a la Verificación 2 del área clave de proceso Seguimiento y
Vista General del Proyecto de Software para prácticas que cubran el
contenido típico de las revisiones generales de la administración del
proyecto.
Verificación 3 El grupo de garantía de la calidad del software revisa y/o audita las
actividades y los productos de trabajo para administrar el
subcontrato de software e informa los resultados.
Referirse al área clave de proceso Garantía de la Calidad del Software.
Como mínimo, las revisiones y/o auditorías verifican:
1. Las actividades para seleccionar el subcontratista.
2. Las actividades para administrar el subcontrato de software.
3. Las actividades para coordinar las actividades de administración de la
configuración del contratista primario y del subcontratista.
4. La conducción de revisiones planeadas con el subcontratista.
5. La conducción de revisiones que establecen el completado de los
puntos clave o las etapas de proyecto para el subcontrato.
6. El proceso de aceptación para los productos de software del
subcontratista.
7.5 Garantía de la Calidad del Software
Un área clave del proceso para el Nivel 2: Repetible.
El propósito de la Garantía de la Calidad del Software es proporcionar administración
con una visibilidad apropiada del proceso que se está usando en el proyecto de software
y de los productos que se están construyendo.
La Garantía de la Calidad del Software implica hacer revisiones y auditorías a las
actividades y los productos de software para verificar que satisfacen los estándares y
procedimientos aplicables así como proporcionar los resultados de estas revisiones y
auditorías al proyecto de software y a otros administradores apropiados.
El grupo de garantía de la calidad del software trabaja con el proyecto de
software durante las etapas tempranas para establecer planes, estándares y
procedimientos que aumentarán el valor del proyecto de software y satisfarán las
limitaciones del proyecto y las políticas de la organización. Al participar en el
establecimiento de planes, estándares y procedimientos el grupo de garantía de la
calidad del software ayuda a asegurar que se ajusten a las necesidades del proyecto y
verifica que puedan usarse para llevar a cabo revisiones y auditorías durante todo el
ciclo de vida del software. El grupo de garantía de la calidad del software revisa las
actividades del proyecto y audita los productos de trabajo del software durante todo el
ciclo de vida y proporciona una administración con visibilidad en cuanto a si el proyecto
de software se adhiere a los planes, estándares y procedimientos establecidos.
Los temas de cumplimiento se tratan primero dentro del proyecto de software y
se resuelven allí de ser posible. Para temas que no se pueden resolver dentro del
proyecto de software, el grupo de garantía de la calidad del software eleva el tema a un
nivel apropiado de la administración para su resolución.
Esta área clave de proceso cubre las prácticas para el grupo que lleva a cabo la
función de garantizar la calidad del software. Las prácticas que identifican las
actividades específicas y los productos de trabajo que el grupo de garantía de la calidad
del software revisa y/o audita están generalmente contenidos en el rasgo común
Verificación de la Implementación de las otras áreas clave del proceso.
Objetivos
Objetivo 1
Se planean las actividades para garantizar la calidad del software.
Objetivo 2
Se verifica de manera objetiva la adherencia de las actividades y los
productos de software a los estándares, procedimientos y
requerimientos aplicables.
Objetivo 3
Los individuos y grupos afectados son informados de las actividades
y resultados de la garantía de la calidad del software.
Objetivo 4
Los temas de incumplimiento que no pueden resolverse dentro del
proyecto de software son tratados por la administración senior.
Compromiso para el Desempeño
Compromiso 1
El proyecto sigue una política organizacional escrita para
implementar la garantía de la calidad del software (SQA).
Esta política especifica que:
1. La función SQA está en todos los proyectos de software.
2. El grupo SQA tiene un canal para presentar informes a la
administración senior que es independiente de:



El administrador del proyecto,
El grupo de ingeniería de software del proyecto, y
Los otros grupos relacionados con el software.
Ejemplos de otros grupos relacionados con el software incluyen:
Administración de la configuración del software, y
Soporte de documentación.
Las organizaciones deben determinar la estructura organizacional
que soportarán las actividades que requieren independencia,
como el SQA, en el contexto de sus objetivos estratégicos de
negocios y de su entorno de negocios.
La independencia debe:
Proporcionar a los individuos que se desempeñan en el rol de
SQA la libertad organizacional para ser los "ojos y orejas" de
la administración senior en el proyecto de software;
Proteger a los individuos que se desempeñan en el rol de
SQA de una apreciación del desempeño por parte de la
administración del proyecto de software que están revisando;
y
Proporcionar a la administración senior la seguridad de que se
está presentando información objetiva sobre el proceso y los
productos de proyecto de software.
3. La administración senior revisa periódicamente las actividades
y resultados del SQA.
Capacidad para Desempeñarse
Capacidad 1 Existe un grupo responsable de coordinar e implementar el SQA
para el proyecto (o sea, el grupo SQA)
Un grupo es el conjunto de departamentos, administradores e individuos
que tienen la responsabilidad de un conjunto de tareas o actividades. Un
grupo puede variar desde un único individuo asignado “part-time”,
pasando por varios individuos con dedicación parcial asignados de
diferentes departamentos, hasta varios individuos dedicados “full-time”.
Las consideraciones al implementar un grupo incluyen tareas o
actividades asignadas, el tamaño del proyecto, la estructura de la
organización y la cultura de la organización. Algunos grupos, como el
grupo de garantía de la calidad del software, se enfocan en actividades
del proyecto, y otros, como el grupo de proceso de la ingeniería del
software, se enfocan en actividades que abarcan toda la organización.
Capacidad 2 Se proporcionan recursos y financiación adecuados para llevar a
cabo las actividades del SQA.
1. Se asignan responsabilidades específicas a un administrador para las
actividades del SQA del proyecto.
2. Se designa un administrador senior, que tiene conocimientos sobre el
rol del SQA y tiene la autoridad para tomar medidas generales
apropiadas, para recibir y actuar sobre temas de incumplimiento del
software.
Todos los administradores en la cadena de informes al
administrador senior tienen conocimientos sobre el rol, las
responsabilidades y la autoridad del SQA.
3. Hay herramientas disponibles para soportar las actividades del SQA.

Ejemplos de herramientas de soporte incluyen:
Workstations,
Programas de bases de datos,
Programas de hoja extendida (spreadsheet), y
Herramientas de auditoría.
Capacidad 3 Los integrantes del grupo SQA se entrenan para llevar a cabo sus
actividades.
Ejemplos de entrenamiento incluyen:
Capacidades y prácticas en ingeniería de software,
Roles y responsabilidades del grupo de ingeniería de software y de
otros grupos relacionados con el software,
Estándares, procedimientos y métodos para el proyecto de software,
Dominio de aplicación del proyecto de software,
Objetivos, procedimientos y métodos del SQA,
Participación del grupo SQA en las actividades del software,
Uso efectivo de los métodos y herramientas del SQA, y
Comunicaciones interpersonales.
Capacidad 4 Los integrantes del proyecto de software reciben orientación en
cuanto al rol, las responsabilidades, la autoridad y el valor del grupo
SQA.
Actividades Realizadas
Actividad 1
Se prepara un plan SQA para el proyecto de software de acuerdo a
un procedimiento documentado.
Este procedimiento típicamente especifica que:
1. El plan SQA se desarrolla en las etapas tempranas y de manera
paralela al planeamiento del proyecto general.
2. Los grupos e individuos afectados revisan el plan SQA.
Ejemplos de grupos e individuos afectados incluyen:
El administrador del proyecto de software;
Otros administradores de software;
El administrador del proyecto;
Representante del SQA cliente;
El administrador senior al que el SQA presenta sus informes sobre
temas de incumplimiento; y
El grupo de ingeniería del software (incluyendo todos los subgrupos,
como ser diseño del software y líderes de tareas de software).
3. El plan SQA se administra y controla.
“Se administra y controla” implica que la versión del producto de trabajo
en uso en un momento dado (pasado o presente) es conocida (o sea,
control de versión) y que los cambios se incorporan de una manera
controlada (o sea, control de cambios).
Si se desea un mayor grado de control que el que implica
“administrado y controlado”, el producto de trabajo puede colocarse bajo
la disciplina completa de la administración de la configuración, según se
describe en el área clave de proceso Administración de la Configuración
de Software.
Actividad 2
Las actividades del grupo SQA se realizan de acuerdo con el plan del
SQA.
El plan cubre:
1. Responsabilidades y autoridad del grupo SQA.
2. Requerimientos de recursos para el grupo SQA (incluyendo personal,
herramientas y facilidades).
3. Cronograma y financiación de las actividades del grupo SQA del
proyecto.
4. La participación del grupo SQA para establecer el plan de desarrollo
del software, los estándares y los procedimientos para el proyecto.
5. Evaluaciones a ser llevadas a cabo por el grupo SQA.
Ejemplos de productos y actividades a evaluar incluyen:
Software operacional y software de apoyo,
Productos que se pueden entregar y productos que no se pueden
entregar,
Productos de software y productos que no son de software (por
ejemplo, documentos),
Actividades de desarrollo de productos y de verificación de
productos (por ejemplo, ejecutar casos de prueba), y
Las actividades seguidas al crear el producto.
6. Las auditorías y revisiones a ser realizadas por el grupo SQA.
7. Los procedimientos y estándares del proyecto a ser usados como la
base para las revisiones y auditorías del grupo SQA.
8. Los procedimientos para documentar y rastrear temas de
incumplimiento hasta su cierre.
Estos procedimientos pueden incluirse como parte del plan o pueden
incluirse como referencia a otros documentos en donde están contenidos.
9. La documentación que el SQA debe producir.
10. El método y la frecuencia con que se proporciona “feedback” al
grupo de ingeniería de software y a otros grupos relacionados con el
software sobre las actividades del SQA.
Actividad 3
El grupo SQA participa en la preparación y revisión del plan de
desarrollo del software del proyecto, estándares y procedimientos.
1. El grupo SQA proporciona consultas y revisiones de los planes,
estándares y procedimientos con respecto a:





El cumplimiento de la política organizacional,
El cumplimiento de estándares y requerimientos impuestos
externamente (por ejemplo, estándares requeridos por la
enunciación del trabajo),
Estándares que son apropiados para el uso por parte del proyecto,
Tópicos que deben tratarse en el plan de desarrollo del software, y
Otras áreas según hayan sido asignadas por el proyecto.
2. El grupo SQA verifica que los planes, estándares y procedimientos
estén ordenados y que puedan usarse para revisar y auditar el
proyecto de software.
Actividad 4
El grupo SQA revisa las actividades de ingeniería de software para
verificar el cumplimiento.
1. Las actividades se evalúan en comparación con el plan de desarrollo
del software y los procedimientos y estándares de software
designados.
Referirse al rasgo común Verificación de la Implementación en las otras
áreas claves de proceso para prácticas que cubran las revisiones y
auditorías específicas realizadas por el grupo SQA.
2. Las desviaciones se identifican, documentan, y siguen hasta su cierre.
3. Se verifican las correcciones.
Actividad 5
El grupo SQA audita productos de trabajo de software designados
para verificar el cumplimiento.
1. Los productos de software que se pueden entregar se evalúan antes de
ser entregados al cliente.
2. Los productos de trabajo de software se evalúan comparándolos con
los procedimientos, estándares y requerimientos contractuales
designados del software.
3. Las desviaciones se identifican, documentan y siguen hasta su cierre.
4. Se verifican las correcciones.
Actividad 6
El grupo SQA informa periódicamente los resultados de sus
actividades al grupo de ingeniería del software.
Actividad 7
Las desviaciones identificadas en las actividades del software y en los
productos de trabajo del software se documentan y manejan de
acuerdo a un procedimiento documentado.
Este procedimiento típicamente especifica que:
1. Las desviaciones del plan de desarrollo del software y de los
procedimientos y estándares designados del proyecto se documentan
y resuelven con los líderes de tareas, administradores de software que
sean apropiados o con el administrador del proyecto cuando sea
posible.
2. Las desviaciones del plan de desarrollo del software y de los
procedimientos y estándares designados del proyecto que no se
pueden resolver con los líderes de tareas, ni con los administradores
de software ni con el administrador del proyecto se documentan y
presentan al administrador senior que se ha designado para recibir
temas de incumplimiento.
3. Los temas de incumplimiento presentados al administrador senior se
revisan periódicamente hasta ser resueltos.
4. La documentación de los temas de incumplimiento se administra y
controla.
Actividad 8
El grupo SQA conduce revisiones periódicas de sus actividades y
hallazgos con el personal del SQA del cliente, según sea apropiado.
Mediciones y Análisis
Medición 1
Las mediciones se hacen y se usan para determinar el estado del
costo y del cronograma de las actividades del SQA.
Ejemplos de mediciones incluyen:
Completado de puntos clave para las actividades del SQA en
comparación con el plan;
Trabajo completado, esfuerzo expandido y fondos gastados en las
actividades del SQA en comparación con el plan; y
Cantidad de auditorías de productos y revisiones de actividades en
comparación con el plan.
Verificación de la Implementación
Verificación 1 Las actividades del SQA se revisan con la administración senior con
base periódica.
El propósito primario de las revisiones periódicas por parte de la
administración senior es proporcionar consciencia y conocimiento sobre
las actividades del proceso de software en un nivel apropiado de
abstracción y con prontitud. El tiempo transcurrido entre las revisiones
debe satisfacer las necesidades de la organización y puede ser largo,
siempre y cuando haya mecanismos adecuados para informes de
excepción.
Referirse a la Verificación 1 del área clave de proceso Seguimiento y
Vista General del Proyecto de Software para prácticas que cubran el
contenido típico de las revisiones generales de la administración senior.
Verificación 2 Las actividades del SQA se revisan con el administrador del proyecto
de manera periódica y dependiendo de los eventos.
Referirse a la Verificación 2 del área clave de proceso Seguimiento y
Vista General del Proyecto de Software para prácticas que cubran el
contenido típico de las revisiones generales de la administración del
proyecto.
Verificación 3 Expertos independientes del grupo SQA revisan periódicamente las
actividades de los productos de trabajo de software del grupo SQA
del proyecto.
7.6 Administración de la Configuración del Software
Un área clave del proceso para el Nivel 2: Repetible.
El propósito de la Administración de la Configuración del Software es establecer y
mantener la integridad de los productos del proyecto de software a lo largo del ciclo de
vida del software del proyecto.
La Administración de la Configuración del Software implica identificar la
configuración del software (o sea, productos de trabajo de software seleccionados y sus
descripciones) en momentos dados, controlando sistemáticamente los cambios a la
configuración y manteniendo la integridad y la posibilidad de rastrear la configuración a
lo largo del ciclo de vida del software. Los productos de trabajo de software ubicados
bajo la administración de la configuración del software incluyen los productos de
software que se entregan al cliente (por ejemplo, el documento de los requerimientos del
software y el código) y las cosas que se identifique con el software o que sean necesarias
para crear estos productos de software (por ejemplo, el compilador).
Se establece una biblioteca (library) base que contiene las bases del software
según se van desarrollando. Los cambios a las bases, así como la edición de productos
de software construidos a partir de la biblioteca base del software, se controlan
sistemáticamente por medio de las funciones de auditoría de la configuración y del
control de cambios que tiene la administración de la configuración del software.
Esta área clave de proceso cubre las prácticas para realizar la función de
administración de la configuración del software. Las prácticas que identifican
unidades/ítems de configuración específicos están contenidas en las áreas claves de
proceso que describen el desarrollo y el mantenimiento de cada unidad/ítem de
configuración.
Objetivos
Objetivo 1
Se planean las actividades de administración de la configuración del
software.
Objetivo 2
Se identifican, controlan y hacen disponibles productos de trabajo de
software seleccionados.
Objetivo 3
Se controlan los cambios a productos de trabajo de software
identificados.
Objetivo 4
Los grupos e individuos afectados reciben información sobre el
estado y el contenido de las bases del software.
Compromiso para el Desempeño
Compromiso 1
El proyecto sigue una política organizacional escrita para
implementar la administración de la configuración del
software (SCM).
Esta política típicamente especifica que:
1. La responsabilidad para la SCM de cada proyecto se asigna
explícitamente.
2. La SCM se implementa durante todo el ciclo de vida del
proyecto.
3. La SCM se implementa para productos de software que se van
a entregar externamente, para productos de trabajo de software
internos designados, y para herramientas de soporte
designadas usadas dentro del proyecto (por ejemplo,
compiladores).
4. Los proyectos establecen o tienen acceso a un repositorio para
almacenar temas/unidades de configuración y los registros
SCM asociados.
Los contenidos de este repositorio se conocen como “biblioteca
base del software” en estas prácticas.
Las herramientas y procedimientos para acceder a este
repositorio se conocen como “sistema de biblioteca de
administración de la configuración” en estas prácticas.
Los productos de trabajo que están ubicados bajo la
administración de la configuración se tratan como una entidad
simple se conocen como ítems de configuración.
Los ítems de configuración típicamente se descomponen en
componentes de configuración, y los componentes de
configuración típicamente se descomponen en unidades. En un
sistema de hardware/software, todo el software puede
considerarse como un solo ítem de configuración, o puede ser
descompuesto en varios ítems de configuración. En estas
prácticas el término “ítems/unidades de configuración” se usa
para referirse a los elementos bajo la administración de la
configuración.
5. Las bases del software y las actividades de SCM se auditan
periódicamente.
Capacidad para Desempeñarse
Capacidad 1 Existe o se establece un panel que tiene la autoridad para
administrar las bases del software del proyecto (o sea, un panel de
control de la configuración del software – SCCB)
El SCCB:
1. Autoriza el establecimiento de las bases del software y la
identificación de los ítems/unidades de configuración.
2. Representa los intereses del administrador del proyecto y de todos los
grupos que pueden verse afectados por cambios en las bases del
software.
Ejemplos de grupos afectados incluyen:
Garantía de la calidad del hardware,
Administración de la configuración del hardware,
Ingeniería del hardware,
Ingeniería de fábrica,
Ingeniería del software (incluyendo todos los subgrupos, como ser
diseño del software),
Ingeniería de sistemas,
Prueba de sistemas,
Garantía de la calidad del software,
Administración de la configuración del software,
Administración del contrato, y
Soporte de documentación.
3. Revisa y autoriza cambios a las bases del software.
4. Autoriza la creación de productos a partir de la biblioteca base del
software.
Capacidad 2 Existe un grupo que es responsable de coordinar e implementar la
SCM para el proyecto (o sea, el grupo SCM).
Un grupo es el conjunto de departamentos, administradores e individuos
que tienen la responsabilidad de un conjunto de tareas o actividades. Un
grupo puede variar desde un único individuo con dedicación parcial,
pasando por varios individuos asignados de diferentes departamentos,
hasta varios individuos con dedicación “full-time”. Las consideraciones
al implementar un grupo incluyen las tareas o actividades asignadas, el
tamaño del proyecto, la estructura organizacional, y la cultura
organizacional. Algunos grupos, como el grupo de garantía de la calidad
del software, se enfocan en las actividades del proyecto, y otros, como el
grupo de proceso de ingeniería del software, se enfocan en actividades
que abarcan toda la organización.
El grupo SCM coordina o implementa:
1. La creación y administración de la biblioteca base de software del
proyecto.
2. El desarrollo, mantenimiento y distribución de los planes, estándares
y procedimientos de la SCM.
3. La identificación de un conjunto de productos de trabajo a ubicar bajo
el accionar de la SCM.
Un producto de trabajo es cualquier artefacto que surja de definir,
mantener o usar un proceso de software.
4.
5.
6.
7.
8.
La administración del acceso a la biblioteca base del software.
Las actualizaciones a las bases del software.
La creación de productos a partir de la biblioteca base del software.
El registro de las acciones de la SCM.
La producción y distribución de informes de la SCM.
Capacidad 3 Se proporcionan recursos y financiación adecuados para llevar a
cabo las actividades de la SCM.
1. Se asignan responsabilidades específicas para la SCM a un
administrador o manager.
2. Se ponen a disposición herramientas para soportar las actividades de
la SCM.
Ejemplos de herramientas de soporte incluyen:
Worksatations,
Programas de bases de datos, y
Herramientas de administración de la configuración.
Capacidad 4 Los integrantes del grupo SCM se entrenan en los objetivos,
procedimientos y métodos para realizar sus tareas en el marco de la
SCM.
Ejemplos de entrenamiento incluyen:
Estándares, procedimientos y métodos de la SCM, y
Herramientas de la SCM.
Capacidad 5 Los integrantes del grupo de ingeniería del software y otros grupos
relacionados con el software se entrenan para realizar sus
actividades SCM.
Ejemplos de otros grupos relacionados con el software incluyen:
Garantía de la calidad del software, y
Soporte de documentación.
Ejemplos de entrenamiento incluyen:
Los estándares, procedimientos y métodos a seguir para las
actividades de la SCM llevadas a cabo dentro del grupo de ingeniería
del software y en otros grupos relacionados con el software; y
El rol, las responsabilidades y la autoridad del grupo SCM.
Actividades Realizadas
Actividad 1
Se prepara un plan SCM para cada proyecto de software de acuerdo
a un procedimiento documentado.
Este procedimiento típicamente especifica que:
1. El plan SCM se desarrolla en las etapas tempranas y de manera
paralela al planeamiento general del proyecto.
2. El plan SCM es revisado por los grupos afectados.
3. El plan SCM se administra y controla.
“Se administra y controla” implica que la versión del producto de trabajo
en uso en un momento dado (pasado o presente) es conocida (o sea,
control de versión) y que los cambios se incorporan de una manera
controlada (o sea, control de cambios).
Si se desea un mayor grado de control que el que implica
“administrado y controlado”, el producto de trabajo puede colocarse bajo
la disciplina completa de la administración de la configuración, según se
describe en el área clave de proceso Administración de la Configuración
de Software.
Actividad 2
Se usa un plan de SCM aprobado y documentado como la base para
llevar a cabo las actividades da la SCM.
El plan cubre:
1. Las actividades de la SCM a realizar, el cronograma de actividades,
las responsabilidades asignadas, y los recursos requeridos (incluyendo
personal, herramientas y facilidades de computadoras)
2. Los requerimientos y actividades de la SCM a ser realizadas por el
grupo de ingeniería del software y por otros grupos relacionados con
el software.
Actividad 3
Se establece un sistema de biblioteca de administración de la
configuración como repositorio para las bases del software.
El sistema de biblioteca:
1. Soporta varios niveles de control de la SCM.
Ejemplos de situaciones que conducen a diversos niveles de control
incluyen:
Diferencias en los niveles de control necesarios en diferentes etapas
del ciclo de vida (por ejemplo, un control más estricto a medida que
el producto madura),
Diferencias en los niveles de control necesarios para los sistemas
sólo de software contra los sistemas que incluyen software y
hardware.
2. Hace posible el almacenamiento y la recuperación de ítems/unidades.
3. Hace que se puedan compartir y transferir los ítems/unidades de
configuración entre los grupos afectados y entre niveles de control
dentro de la biblioteca.
4. Ayuda en el uso de estándares de productos para ítems/unidades de
configuración.
5. Hace posible el almacenamiento y la recuperación de versiones de
archivos de ítems/unidades de configuración.
6. Ayuda a asegurar la creación correcta de productos a partir de la
biblioteca base.
7. Hace posible el almacenamiento, la actualización y la recuperación de
registros SCM.
8. Soporta la producción de informes de la SCM.
9. Hace posible el mantenimiento de la estructura de la biblioteca y sus
contenidos.
Ejemplos de funciones de mantenimiento de la biblioteca incluyen:
Hacer backup / recuperar los archivos de la biblioteca, y
Recuperar de los errores de la biblioteca.
Actividad 4
Se identifican los productos de trabajo de software a ubicar bajo la
administración de la configuración.
1. Se seleccionan los ítems/unidades de configuración basándose en
criterios documentados.
Ejemplos de productos de trabajo de software que pueden identificarse
como ítems/unidades de configuración incluyen:
Documentación relacionada con el proceso (por ejemplo, planes,
estándares o procedimientos),
Requerimientos de software,
Diseño de software,
Unidades de código de software,
Procedimientos de prueba de software,
Construcción de un sistema de software para la actividad de prueba
del software,
Construcción de un sistema de software para la entrega al cliente o a
los usuarios finales,
Compiladores, y
Otras herramientas de soporte.
2. Se asignan identificadores únicos a los ítems/unidades de
configuración.
3. Se especifican las características de cada ítem/unidad de
configuración.
4. Se especifican las bases de software a las que pertenece cada
ítem/unidad de configuración.
5. Se especifica el punto de desarrollo en el que se ubica cada
ítem/unidad de configuración en la administración de la
configuración.
6. Se identifica la persona responsable para cada ítem/unidad de
configuración (o sea, el dueño, desde el punto de vista de la
administración de la configuración)
Actividad 5
Se inician, registran, revisan, aprueban y siguen las solicitudes de
cambios y los informes de problemas para todos los ítems/unidades
de configuración de acuerdo a un procedimiento documentado.
Actividad 6
Se controlan los cambios a las bases de acuerdo a un procedimiento
documentado.
Este procedimiento típicamente especifica que:
1. Se realizan revisiones y/o pruebas de regresión para asegurar que los
cambios no han causado efectos no buscados en la base.
2. Sólo los ítems/unidades de configuración que han sido aprobados por
el SCCB se ingresan a la biblioteca base del software.
3. Los ítems/unidades de configuración se ingresan y retiran de una
manera que mantenga la corrección e integridad de la biblioteca base
del software.
Ejemplos de pasos de ingreso/retiro incluyen:
Verificar que las revisiones estén autorizadas,
Crear un log. de cambios,
Mantener una copia de los cambios,
Actualizar la biblioteca base del software, y
Archivar la base de software reemplazada.
Actividad 7
Se crean productos a partir de la biblioteca base del software y se
controla su edición, de acuerdo a un procedimiento documentado.
Este procedimiento típicamente especifica que:
1. El SCCB autoriza la creación de productos a partir de la biblioteca
base del software.
2. Los productos a partir de la biblioteca base del software, tanto para
uso interno como externo, se construyen sólo a partir de
ítems/unidades de configuración en la biblioteca base de software.
Actividad 8
Se registra el estado de los ítems/unidades de configuración de
acuerdo a un procedimiento documentado.
Este procedimiento típicamente especifica que:
1. Las acciones de administración de la configuración se registran con
detalle suficiente de manera que el contenido y el estado de cada
ítem/unidad de configuración son conocidos y se pueden recuperar
versiones anteriores.
2. Se mantiene el estado actual y la historia (o sea, cambios y otras
acciones) de cada ítem/unidad de configuración.
Actividad 9
Se desarrollan informes estándar que documentan las actividades de
la SCM y los contenidos de la base del software, y se ponen a
disposición de los grupos e individuos afectados.
Ejemplos de informes incluyen:
Actas de reuniones del SCCB,
Estado y resumen de las solicitudes de cambios,
Estado y resumen de los informes de problemas (incluyendo
reparaciones),
Resumen de los cambios hechos a las bases del software,
Historia de revisiones de los ítems/unidades de configuración
Estado de la base del software, y
Resultados de las auditorías de la base del software.
Actividad 10 Se conducen auditorías de la base del software de acuerdo a un
procedimiento documentado.
Este procedimiento típicamente especifica que:
1. Hay una preparación adecuada para la auditoría.
2. Se evalúa la integridad de las bases del software.
3. Se revisan la estructura y las facilidades del sistema de biblioteca de
administración de la configuración.
4. Se verifica que los contenidos de la biblioteca base del software estén
completos y sean correctos.
5. Se verifica que se cumplan los estándares y procedimientos aplicables
de la SCM.
6. Se informan los resultados de la auditoría al administrador de
software del proyecto.
7. Se siguen los temas de acción que surjan de la auditoría hasta su
cierre.
Mediciones y Análisis
Medición 1
Se hacen y usan mediciones para determinar el estado de las
actividades de la SCM.
Ejemplos de mediciones incluyen:
Cantidad de solicitudes de cambios procesadas por unidad de
tiempo;
Completado de puntos importantes para las actividades de la SCM en
comparación con el plan; y
Trabajo completado, esfuerzo realizado y fondos usados en las
actividades de la SCM.
Verificación de la Implementación
Verificación 1 Las actividades de la SCM se revisan periódicamente con la
administración senior.
El propósito primario de las revisiones periódicas por parte de la
administración senior es proporcionar consciencia y conocimiento sobre
las actividades del proceso de software en un nivel apropiado de
abstracción y con prontitud. El tiempo transcurrido entre las revisiones
debe satisfacer las necesidades de la organización y puede ser largo,
siempre y cuando haya mecanismos adecuados para informar
excepciones.
Referirse a la Verificación 1 del área clave de proceso Seguimiento y
Vista General del Proyecto de Software para prácticas que cubran los
contenidos típicos de las revisiones generales de la administración
senior.
Verificación 2 Las actividades SCM se revisan con el administrador del proyecto de
manera periódica y dependiendo de los eventos.
Referirse a la Verificación 2 del área clave de proceso Seguimiento y
Vista General del Proyecto de Software para prácticas que cubran los
contenidos típicos de las revisiones generales de la administración del
proyecto.
Verificación 3 El grupo SCM audita periódicamente las bases del software para
verificar que estén de acuerdo con la documentación que las define.
Verificación 4 El grupo de garantía de la calidad del software revisa y/o audita las
actividades y los productos de trabajo para la SCM e informa los
resultados.
Referirse al área clave de proceso Garantía de la Calidad del Software.
Como mínimo, las revisiones y/o auditorías verifican:
1. Que los siguientes grupos cumplan los estándares y procedimientos
de la SCM:




El grupo SCM,
El SCCB,
El grupo de ingeniería del software, y
Otros grupos relacionados con el software.
2. La ocurrencia de auditorías periódicas de las bases del software.