practicas cmm l2 (espanol)

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

Administración de Requisitos

Un área clave de proceso para el nivel 2: Repetible El propósito de la administración de requisitos es establecer un entendimiento común entre el cliente y

el proyecto de software, acerca de los requisitos del cliente que serán abordados por el proyecto de

software.

La administración de requisitos involucra establecer y mantener un acuerdo con el cliente sobre los

requisitos para el proyecto de software. Este acuerdo es llamado como "los requisitos de sistema

asignados al software". El "cliente" puede ser interpretado como el grupo de ingeniería de sistemas, el

grupo de marketing, otra organización interna, o un cliente externo. El acuerdo cubre requisitos técnicos

y no técnicos (por ejemplo: fechas de entrega). El acuerdo forma la base para estimar, planificar,

ejecutar y seguir las actividades del proyecto de software a través del ciclo de vida del software.

La asignación de los requisitos de sistema al software, hardware, y otras componentes del sistema (por

ejemplo: humanas) puede ser ejecutada por un grupo externo al grupo de ingeniería de software (por

ejemplo: el grupo de ingeniería de sistemas), y además el grupo de ingeniería de software puede no

tener control directo sobre esta asignación. Dentro de las restricciones del proyecto, el grupo de

ingeniería de software toma las acciones necesarias para asegurar que los requisitos de sistema

asignados al software -por los que son responsables de abordar- estén documentados y controlados.

Para lograr este control, el grupo de ingeniería de software revisa los requisitos de sistema asignados al

software tanto los iniciales como los revisados, para resolver problemas antes que sean incorporados

en el proyecto de software. Toda vez que se cambian los requisitos de sistema asignados al software,

se ajustan los planes de software afectados, productos intermedios, y actividades para permanecer

consistentes con los requisitos realizados.


Administración de Requisitos Nivel 2: Repetible

Metas Meta 1 Los requisitos del sistema asignados al software son controlados para establecer

una línea base para uso en Administración e ingeniería de software. Meta 2 Los planes, productos y actividades de software son mantenidos consistentes

con los requisitos de sistema asignados al software.

Compromisos para desarrollar Compromiso 1 EI proyecto sigue una política organizacional escrita, para la administración

de los requisitos del sistema asignados al software.

Los requisitos del sistema asignados al software, se refiere a los requisitos asignados en esas practicas

Los requisitos asignados al software son el sub conjunto de los requisitos del sistema que están para ser implementados por las componentes de software del sistema Los requisitos asignados son la entrada primaria para el plan de desarrollo de software. El análisis de requisitos de software elabora y refina los requisitos asignados 10 que produce requisitos de software que están documentados

Esta política típicamente especifica que:

1. Los requisitos de software son documentados. 2. Los requisitos de software son revisados por 105 administradores del

proyecto y otros grupos afectados

q los administradores de software, y q otros grupos afectados

Ejemplos de grupos afectados incluyen

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

– soporte de documentación.


Nivel 2: Repetible Administración de Requisitos

Los planes y actividades son cambiados, cada vez que hay un cambio de

requisitos.

Habilidades para desarrollar Habilidad 1 Para cada proyecto, se establece la responsabilidad de analizar los

requisitos del sistema y asociarlos al hardware, software y otros componentes del sistema.

EI análisis y la asignación de los requisitos del sistema no son responsabilidades del grupo de ingeniería de software, pero si son pre-requisitos para su trabajo.

Esta responsabilidad cubre:

1. Administrar y documentar los requisitos del sistema y su asignación a través de la vida del proyecto.

2. Efectuar cambios a los requisitos del sistema y su asignación.

Habilidad 2 Los requisitos asignados son documentados.

Los requisitos asignados incluyen.

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

Ejemplos de acuerdos, condiciones y términos contractuales incluyen:

– productos a ser entregados,

– fechas de entrega, y – metas

2. Requisitos técnicos del software,

Ejemplos de técnicos incluyen:

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

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



3. Los criterios de aceptación que serán usados para validar que el producto

entregado satisfaga los requisitos

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

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

2. Herramientas de apoyo a la administración de requisitos como planillas de calculo, herramientas de administración de configuración, etc.

Ejemplos de herramientas de soporte incluyen:

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

– herramientas para administración de las pruebas

Habilidad 4 Los miembros del grupo de ingeniería de software y de otros grupos relacionados, son entrenados para realizar sus actividades de administración de requisitos.

Ejemplos de áreas de capacitación son:

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

Actividades a realizar Actividad 1 EI grupo de ingeniería de software revisa los requisitos antes de que sean

incorporados al proyecto.

1. Se identifican requisitos faltantes o incompletos

2. Los requisitos asignados son revisados para determinar si son:

q factibles y apropiados para ser implementados en software,

q clara y apropiadamente establecidos,

q consistentes un os con otros, y

q validadles

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



4. Los compromisos resultantes de la asignación de requisitos son revisados y

negociados con los grupos afectados.

Ejemplos grupos afectos incluyen:

– ingeniería de software (incluyendo todos los sub-grupos. tales como diseño de software), – estimación de software,

– ingeniería de sistema, – pruebas de sistema, – garantía de calidad de software, – Administración de configuraciones de software,

– Administración de subcontratos, y – soporte de documentación

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

Actividad 2 EI grupo de ingeniería de software usa los requisitos asignados como la

base para establecer los planes, productos y actividades de software.

Los requisitos asignados: 1. Son administrados y controlados. "Administrados y controlados" implica que la versión del producto de trabajo en uso en un

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

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

3. Son la base para desarrollar los requisitos de software. Actividad 3 Los cambios a los requisitos asignados son revisados e incorporados en el

proyecto de software.

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

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



Refiérase a la actividad 4 del área clave de proceso Planificación del Proyecto de Software y

la actividad 3 del área clave de proceso Supervisión y Control del Proyecto de Software, para ver practicas que cubren los compromisos hechos externos a la organización

q Cambios a acuerdos internos a la organización son negociados con los grupos afectados.

Refiérase a las actividades 5, 6, 7 Y 8 del área clave de proceso Supervisión y Control del Proyecto de Software para ver practicas que cubren la negociación de cambios a acuerdos.

2. Los cambios que se deben hacer en los planes, productos y actividades, producto de cambios en los requisitos asignados son:

q identificados,

q evaluados,

q evaluados en riesgo,

q documentados,

q planificados,

q comunicados a los grupos e individuos afectados, y

q seguidos hasta su finalización

Medición y Análisis Medición 1 Se hacen mediciones y son usadas para determinar el estado de las

actividades de administración de requisitos. Algunas de estas mediciones son:

– Estado de cada uno de los requisitos identificados. – Cambios en actividades asociadas a los requisitos – Numero total de cambios a los requisitos asignados, y – Total de cambios propuestos, cambios aprobados y cambios incorporados a la línea base

del sistema



Verificación de la Implementación Verificación 1 Las actividades para administrar los requisitos asignados son revisadas

periódicamente con la administración superior. EI propósito fundamental de las revisiones de la administración superior es proveer

conciencia de y visión de las actividades del proceso de software, con un adecuado nivel de abstracción y en forma oportuna. EI tiempo entre revisiones debe estar de acuerdo a las necesidades de la organización y pueden ser distanciados, tanto como estén disponibles mecanismos adecuados de informe de excepciones.

Refiérase a la verificación 1 del área clave de proceso Supervisión y Control del Proyecto de Software para practicas cubriendo el contenido típico de revisiones de seguimiento de la administración superior

Verificación 2 Las actividades para administrar los requisitos asignados son revisadas

con el jefe del proyecto en forma periódica y como respuesta a eventos. Refiérase a la verificación 2 del área clave de proceso Supervisión y Control del Proyecto de

Software para practicas cubriendo el contenido típico de revisiones de seguimiento de la administración del proyecto

Verificación 3 EI grupo de garantía de calidad revisa y/o audita las actividades de

administración de requisitos e informa los resultados.

Como mínimo, esas revisiones y/o auditorias verifican que:

1. Los requisitos son revisados, y los problemas son resueltos antes de que el equipo de ingenieros se comprometa a su realización.

2. Se deben revisar apropiadamente los planes, productos y actividades, cuando los requisitos asignados cambian.

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


Planificación del Proyecto de Software

Un área clave de proceso para el nivel 2: Repetible El propósito de la Planificación del Proyecto de Software es establecer planes razonables para realizar

las tareas de ingeniería de software y administración del proyecto de software.

La Planificación del Proyecto de Software involucra desarrollar estimaciones para el trabajo a ejecutar,

establecer los acuerdos necesarios, y definir el plan para desarrollar el trabajo.

La planificación de software comienza con una orden de trabajo a ser ejecutada y otras restricciones y

metas que definen y acotan el proyecto de software (aquellas establecidas por las practicas del área

clave de proceso de Administración de

Requisitos). El proceso de Planificación del Proyecto de Software incluye pasos para estimar el tamaño

de los productos y recursos requeridos, producir la programación, identificar y evaluar los riesgos de

software y negociar compromisos. Al iterar estos pasos puede ser necesario crear el plan para el

proyecto de software (es decir, el plan de desarrollo de software).

Este plan proporciona las bases para ejecutar y administrar las actividades del proyecto y considera los

acuerdos con el cliente del proyecto de software de acuerdo a los recursos, restricciones, y

capacidades del proyecto de software.


Planificación del Proyecto de Software Nivel 2: Repetible

Metas Meta 1 Las estimaciones de software son documentadas para ser usadas en la

planificación y seguimiento del proyecto de software. Meta 2 Las actividades y los compromisos del proyecto de software son planificados y

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

proyecto de software.

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

por la negociación de compromisos y ejecutar el plan de desarrollo del proyecto de software.

Compromiso 2 EI proyecto sigue una política organizacional de planificación del proyecto

de software. Esta política típicamente especifica que:

1. Los requisitos de sistema asignados al software deben ser usados como las

bases para la planificación del proyecto de software Refiérase a la actividad 2 del área clave de proceso Administración de Requisitos

2. Los compromisos del proyecto de software se negocian entre:

q el administrador del proyecto,

q el administrador del proyecto de software, y

q los otros administradores de software

3. La participación de otros grupos de ingeniería en las actividades de desarrollo de software debe ser negociada con fichas grupos y luego documentada.

Ejemplos de otros grupos de ingeniería incluyen:

– ingeniería de sistemas – ingeniería de hardware, y

– pruebas de sistema


Nivel 2: Repetible Planificación del Proyecto de Software

4. Los grupos involucrados revisan del proyecto de software:

q las estimaciones de tamaño del software,

q las estimaciones de esfuerzo y costo,

q la programación, y

q otros acuerdos. Ejemplos de grupos afectados incluyen:

– ingeniería de software (incluyendo todos los sub-grupos, tales como diseñó de software), – estimación de software,

– ingeniería de sistema, – pruebas de sistema, – garantía de calidad de software, – administración de configuraciones de software,

– administración de contrato, y – soporte de documentación

5. La administración superior revisa todos los compromisos hechos con

individuos o grupos externos a la organización.

6. EI plan de desarrollo de software del proyecto es administrado y controlado EI termino "plan de desarrollo de software" es usado a través de esas practicas para referirse

al plan global para administrar el proyecto de software. EI uso de la terminología "desarrollo" no pretende excluir los proyectos de mantenimiento o soporte de s oftware, y debe ser apropiadamente interpretada en el contexto de cada proyecto.

"Administrado y controlado" implica que la versión del producto de trabajo en uso en un momento dado (pasado o presente) es conocida (es decir "control de versión), y los cambios son incorporados de manera controlada (es decir "control de cambios")

Si se desease un mayor grado de formalidad que el implicado por "Administrado y controlado", el producto de trabajo puede ser puesto bajo la disciplina completa de administración de configuraciones, tal como es descrito en el área clave de proceso Administración de Configuraciones de Software



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

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

q Alcance del trabajo

q Metas técnicas y objetivos,

q Identificación de clientes y usuarios finales,

Los usuarios finales a que se refieren estas practicas son los usuarios finales o representantes de usuarios finales designados por el cliente.

q Estándares impuestos,

q Responsabilidades asignadas,

q Metas, restricciones de costos y programación,

q Dependencias entre el proyecto de software y otras organizaciones, Ejemplos de otras organizaciones incluyen:

– el cliente,

– subcontratistas, y – socios.

q Restricciones de recursos y metas, y

q Otras restricciones y metas para el desarrollo y/o mantenimiento.

2. EI documento de orden de trabajo es revisado por:

q EI administrador del proyecto global,

q EI administrador del proyecto de software,

q Los grupos afectados

3. EI documento de orden de trabajo es administrado y controlado.

Habilidad 2 Se asignan responsabilidades para desarrollar el plan de proyecto. 1. EI administrador del proyecto de software, directamente o por delegación,

coordina la planificación del proyecto.

2. Las responsabilidades por los productos de trabajo y las actividades de software son divididas y asignadas a los administradores del software de manera justificable y seguible.

Ejemplos de productos de trabajo de software incluyen:

– Producto de trabajo para entrega a un cliente externo o usuario final, según corresponda – Producto de trabajo para uso de otros grupos de ingeniería; y

– Producto de trabajo principales para uso interno del grupo de ingeniería de software.



Habilidad 3 Se destinan los recursos y fondos adecuados para realizar la planificación

del proyecto. 1. Cuando es factible, personas con experiencia, que tengan conocimiento

experto en el dominio de aplicación del proyecto de software bajo planificación, son asignados para el desarrollo del plan del proyecto.

2. Se dejan disponibles herramientas de apoyo a la planificación de proyectos Ejemplos herramientas de soporte incluyen:

– programas de planilla de calculo, – modelos de estimación, y – programas de planificación y programación

Habilidad 4 Los administradores, ingenieros de software y otras personas involucradas en la planificación del proyecto de software, son entrenadas en los procedimientos de estimación y planificación aplicables a su área de responsabilidad.

Actividades a realizar Actividad 1 EI grupo de ingeniería de software participa en el equipo que realiza la

propuesta del proyecto. 1. El grupo de ingeniería de software es involucrado en:

q preparación y entrega de la propuesta,

q discusiones de clarificación, y

q negociaciones de cambios de acuerdos que afectan al proyecto de software

2. El grupo de ingeniería de software revisa los acuerdos propuestos de proyecto

Ejemplos de acuerdos de proyecto incluyen:

– los objetivos y metas técnicas del proyecto;

– el sistema y la solución técnica de software; – el presupuesto del software, programación y recursos; y – los estándares y procedimientos de software

Actividad 2 La planificación del proyecto de software es iniciada en las primeras etapas, y en paralelo, son la planificación global del proyecto.

Actividad 3 EI grupo de ingenieros de software participa con otros grupos involucrados en la planificación global del proyecto, a lo largo de la vida del proyecto.

1. EI grupo de ingeniería de software revisa los planes de nivel de proyecto.



Actividad 4 Los compromisos adquiridos por personas o grupos externos a la

organización son revisados con la administración superior de acuerdo a un procedimiento documentado.

Actividad 5 Se identifica o define un ciclo de vida de software con etapas predefinidas de un tamaño manejable.

Ejemplos de ciclos de vida de software incluyen:

– cascada,

– cascada traslapada. – espiral. – construcción serial. y – cascada simple prototipo / traslapada

Actividad 6 EI plan del proyecto de software es realizado de acuerdo a un

procedimiento documentado. 1. El plan de desarrollo de software esta basado en:

q Estándares del cliente,

q Estándares del proyecto,

q EI documento de orden de trabajo (aprobado) y

q los requisitos de software.

2. Los planes para grupos relacionados con el software y otros grupos de ingeniería involucrados en las actividades de! grupo de ingeniería de software son negociados con esos grupos, los esfuerzos de soporte son presupuestados, y los acuerdos documentados.

Ejemplos de grupos relacionados con el software incluyen:

– Garantía de calidad de software, – administración de configuraciones de software, y – soporte de documentación.

Ejemplos de otros grupos de ingeniería incluyen:

– ingeniería de sistemas, – ingeniería de hardware, y

– pruebas de sistema.

3. Los planes para la participación de! grupo de ingeniería de software en

actividades de otros grupos relacionados con el software y otros grupos de ingeniería son negociados con esos grupos, los esfuerzos de soporte son presupuestados, y los acuerdos documentados.



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

q el administrador del proyecto,

q el administrador del proyecto de software,

q otros administradores de software, y

q otros grupos involucrados.

Actividad 7 El plan del proyecto de software es documentado. En las practicas claves, este plan o colección de planes es mencionada como el plan de

desarrollo de software.

Refiérase a la actividad 1 de las áreas claves de proceso Supervisión y Control del Proyecto de Software para practicas concernientes al uso del plan de desarrollo de software del proyecto.

5. EI plan de desarrollo de software del proyecto cubre:

q El propósito, ámbito, metas y objetivos del proyecto de software.

q Selección de un ciclo de vida de software

q Identificación de los procedimientos, métodos y estándares de desarrollo y/o mantenimiento de software seleccionados.

Ejemplos de estándares y procedimientos incluyen:

– planificación del proyecto de software, – administración de configuraciones de software,

– garantía de calidad de software, – diseño de software, – seguimiento y resolución de problemas, y – mediciones de software.

q Identificación de los productos de trabajo a ser desarrollados.

q Estimaciones de tamaño de los productos de trabajo y cualquier cambio a los productos de trabajo de software.

q Estimación del esfuerzo y costo del proyecto.

q Uso estimado de recursos críticos

q Cronogramas del proyecto, incluyendo identificación de hitos y revisiones.

q Identificación y evaluación de los riesgos de software del proyecto.

q Planificación del uso de las facilidades de ingeniería de software y herramientas de apoyo.



Actividad 8 Se identifican aquellos productos de software sobre los cuales es necesario establecer y mantener un control dentro del proyecto de software.

Refiérase a la actividad 4 del área clave de proceso Administración de configuraciones de

software.

Actividad 9 Las estimaciones del tamaño de los productos de software (o de los cambios en ellas) se realizan de acuerdo a un procedimiento documentado.

Este procedimiento típicamente especifica que:

1. Se realizan estimaciones de tamaño sobre los principales productos de trabajo de software.

Ejemplos de estimaciones de tamaño de software incluyen:

– Puntos de función, – puntos de características, – líneas de código,

– numero de requisitos, y – numero de paginas.

Ejemplos de tipos de productos de trabajo y actividades para los cuales se hacen estimaciones incluyen:

– software operacional y de soporte, – productos de trabajo entregables y no entregables, – productos de trabajo de software y "no-software" (por ejemplo documento,), y – actividades para desarrollar, verificar y validar los productos de trabajo.

2. Los productos de trabajo de software son descompuestos hasta la granularidad requerida para cumplir con los objetivos de estimación.

3. Se usan datos históricos cuando se dispone de ellos.

4. Los supuestos de las estimaciones de tamaño son documentados.

5. Las estimaciones de tamaño son documentadas, revisadas y luego acordadas.

Ejemplos de grupos e individuos que revisan y acuerdan las estimaciones de tamaño

incluyen:

– el administrador del proyecto, – el administrador del proyecto de software, y

– los otros administradores de software



Actividad 10 Las estimaciones de esfuerzo y costos se derivan de acuerdo a un procedimiento documentado.

Este procedimiento típicamente establece que:

1. Las estimaciones de esfuerzos y costos del proyecto están relacionadas alas estimaciones de tamaño de los productos de trabajo de software (o el tamaño de los cambios)

2. Se utilizan datos de productividad (históricos y/o reales) para las estimaciones cuando están disponibles; las fuentes de información y la lógica para esos datos son documentadas.

q Los datos de productividad y costos son de proyectos de la organización cuando sea posible.

q Los datos de productividad y costos toman en cuenta el esfuerzo y los costos significativos incluidos en hacer los productos de trabajo de software

Ejemplos de costos significativos incluidos en hacer los productos de trabajo de software

incluyen:

– gastos de esfuerzo directo, – gastos generales, – gastos de viajes, y – costos de uso de computadores.

3. Las estimaciones de esfuerzo, personal y costos se basan en la experiencia

pasada.

q Debieran usarse proyectos similares cuando sea posible.

q Se derivan las fases en el tiempo de las actividades.

q Se preparan estimaciones de las distribuciones del esfuerzo, personal, y costos.

Actividad 11 Las estimaciones de los recursos computacionales críticos son realizadas de acuerdo a un procedimiento documentado.

Los recursos computacionales críticos pueden ser en el ambiente del servidor. en el ambiente

de pruebas e integración, en el ambiente operacional, o en cualquier combinación de ellos.


1. Se identifican los recursos computacionales críticos. Ejemplos de recursos computacionales críticos incluyen:

– capacidad de memoria del computador,

– usa del procesador del computador, y – capacidad del canal de comunicaciones



2. La estimación de recursos críticos esta relacionada a las estimaciones de:

q el tamaño de los productos de trabajo de software,

q la carga de procesamiento operacional, y

q el trafico de las comunicaciones.

3. Las estimaciones de recursos computacionales críticos son documentadas, revisadas y acordadas

Actividad 12 La programación del proyecto de software se obtiene de acuerdo a un procedimiento documentado.

Este procedimiento especifica típicamente que:

1. La programación de software esta relacionada a:

q las estimaciones de tamaño del software, y

q las estimaciones de esfuerzo y costos

2. La programación de software se basa en la experiencia pasada

q Se usan proyectos similares cuando es posible

3. La programación de software se acomoda alas fechas impuestas de hitos, fechas de dependencias criticas, y otras restricciones.

4. Establece claramente los hitos, dependencias criticas de actividades y otras restricciones.

5. Los supuestos hechos al derivar la programación son documentados.

6. La programación del proyecto es documentada, revisada y acordada.

Actividad 13 Los riesgos asociados al costo, recursos, programación y aspectos técnicos del proyecto son identificados, evaluados y documentados.

1. Los riesgos son analizados y priorizados de acuerdo a su impacto potencial en el proyecto.

2. Se identifican contingencias para los riesgos.

Ejemplos de contingencias incluyen:

– holguras en las fechas, – equipos de trabajo alternativos, y – planes alternativos de adquisición de recursos computacionales



Actividad 14 Se preparan planes para las facilidades de ingeniería de software y herramientas de soporte del proyecto.

1. Las estimaciones de requerimientos de capacidad para esas facilidades y herramientas de soporte están basadas en las estimaciones de tamaño de los productos de trabajo de software y otras características.

Ejemplos de facilidades de desarrollo de software y herramientas de soporte incluyen:

– computadores y periféricos para desarrollo de software,

– periféricos computadores para prueba de software, – software del medio ambiente del computador destino, y – otro software de soporte

2. Se asignan responsabilidades y se negocian los acuerdos para procurar

desarrollar esas facilidades y herramientas de soporte.

3. Los planes son revisados por todo todos los grupos afectados.

Actividad 15 Se registran los datos de planificación de software.

1. La información registrada incluye las estimaciones y la información asociada necesaria para reconstruir las estimaciones y evaluar su razonabilidad.

2. Los datos de planificación de software son administrados y controlados.

Medición y Análisis

Medición 1 Se hacen mediciones y son usadas para determinar el estado de las actividades de planificación de proyectos de software.

Ejemplos de estas mediciones son:

– Cumplimientos de los hitos del proyecto en relación con la planificación,

– Trabajo realizado, esfuerzo gastado y fondos utilizados en relación con la planificación

Verificación de la Implementación

Verificación 1 Las actividades contenidas en la planificación son revisadas en conjunto con la administración superior periódicamente.

EI propósito principal de las revisiones periódicas de la administración superior es proveer el conocimiento y visión sobre las actividades del proceso de software a un nivel de abstracción apropiado y oportuno en el tiempo EI tiempo entre revisiones debe cumplir con las necesidades de la organización y puede ser tan largo como mecanismos para reporte de excepciones estén disponibles.



1. Se revisan aspectos técnicos, costos, personal y el cumplimiento de la programación.

2. Se abordan conflictos y problemas no solubles en niveles mas bajos

3. Se abordan los riesgos del proyecto.

4. Se asignan ítems de acción, se revisan y se supervisan hasta cerrarlos

5. Se prepara un informe resumen de cada reunión y se distribuye a los grupos e individuos afectados

Verificación 2 Las actividades para la planificación de proyectos de software son revisadas con el administrador del proyecto, tanto periódicamente como en respuesta a eventos.

1. Los grupos afectados están representados

2. EI estado real del proyecto y los resultados obtenidos se revisan contra los documentos de definición de trabajo y de requisitos asignados

3. Las dependencias entre los distintos grupos son abordadas

4. Los conflictos y problemas no solubles en los niveles inferiores son abordados.

5. Los riesgos del proyecto son revisados.

6. Se asignan ítems de acción, se revisan, y si siguen hasta cerrarlos

7. e prepara un informe resumen de cada reunión y es distribuido a los individuos y grupos afectados.

Verificación 3 EI grupo de garantía de calidad del software revisa y audita las actividades y productos de trabajo de la planificación de proyectos de software e informa los resultados.

Refiérase al área clave de proceso de Garantía de Calidad de Software.

Como mínimo la auditoria revisa:

1. las actividades de estimación y planificación de software,

2. las actividades de revisión y toma de compromisos de proyecto,

3. las actividades de preparación del plan de desarrollo de software,

4. los estándares usados para preparar el plan de desarrollo de software,.

5. el contenido del plan de desarrollo de software.


Seguimiento y Control del Proyecto de Software

Un área clave de proceso para el nivel 2: Repetible EI propósito del Seguimiento y Control del Proyecto de Software es proporcionar una adecuada visión

del avance real del proyecto de forma que los administradores puedan tomar acciones efectivas cuando

el rendimiento del proyecto de software se desvía significativamente del plan de software.

EI Seguimiento y Control del Proyecto de Software involucra seguir y revisar los logros y resultados en

contraste alas estimaciones, compromisos y planes documentados, y ajustar el plan de acuerdo a los

logros y resultados reales.

Se usa un plan documentado para el proyecto de software (es decir, el plan de desarrollo de software,

como se describió en el área clave de proceso Planificación del Proyecto de Software) como la base

para seguir las actividades de software, comunicar su estado, y revisar los planes. Las actividades de

software son monitoreadas por la administración. El progreso es determinado principalmente

comparando el tamaño, esfuerzo, costo, y programación real del software con el plan cuando se

completan productos de trabajo de software y en hitos selectos. Cuando se ha determinado que los

planes del proyecto de software no están siendo cumplidos, se toman acciones correctivas. Estas

acciones pueden incluir revisar el plan de desarrollo software para reflejar los resultados reales y

planificar el trabajo restante o tomar acciones para mejorar el desempeño.


Seguimiento y Control del Proyecto de Software Nivel 2: Repetible

Metas Meta 1 El rendimiento y los resultados obtenidos son seguidos y contrastados

con el plan del proyecto. Meta 2 Se toman y administran acciones correctivas cuando los resultados y el

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

grupos y personas afectadas.

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

por las actividades y resultados del proyecto. Compromiso 2 El proyecto sigue una política organizacional escrita para la administración

de proyectos de software. Esta política típicamente indica que:

1. Se usa y mantiene un plan de desarrollo documentado como base para el

seguimiento del proyecto.

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

3. Se toman acciones correctivas cuando el plan del proyecto no esta siendo logrado, ya sea ajustando el plan o el desempeño.

4. Los cambios a los compromisos de software son hechos con el involucramiento y el acuerdo de los grupos afectados

Ejemplos de grupos afectados incluyen:

– ingeniería de software (incluyendo todos los sub-grupos, tales como diseño de software),

– estimación de software, – ingeniería de software, pruebas de software – garantía de calidad de software, administración de configuración de software, – administración de contrato, y

– apoyo de documentación 5. La administración superior revisa todos los cambios y nuevos compromisos

adquiridos por el proyecto con individuos o grupos externos a la organización.


Nivel 2: Repetible Seguimiento y Control del Proyecto de Software

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

proyecto. Refiérase alas actividades 6 y 7 del área clave de proceso de Planificación de proyectos de

software para practicas que cubren el plan de desarrollo de software.

Habilidad 2 El administrador del proyecto de software asigna en forma explicita

responsabilidades sobre las actividades y productos a desarrollar. La asignación de responsabilidades cubre:

1. Los productos de software a ser desarrollados o los servicios a ser

proporcionados.

2. EI esfuerzo y costo para estas actividades de software.

3. La programación asociada a estas actividades de software.

4. EI presupuesto para estas actividades de software Habilidad 3 Se proveen los recursos y fondos necesarios para el seguimiento del

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

administradores y lideres de tarea.

2. Se proporcionan herramientas que apoyen la labor de seguimiento del proyecto

Ejemplos de herramientas de soporte incluyen:

– Planillas de calculo, – programas de planificación y programación de actividades

Habilidad 4 Los administradores de proyectos son entrenados para administrar los

aspectos técnicos y de personal de los proyectos.

Ejemplos de entrenamiento incluyen:

– Administración de proyectos técnicos, – seguimiento y control del tamaño, esfuerzo, costos, y programación de software, y – administración de personal

Habilidad 5 Los administradores de primera línea reciben orientación en los aspectos

técnicos del proyecto. Ejemplos de orientación incluyen:

– Estándares de ingeniería de software y procedimientos aplicables al proyecto

– EI dominio de aplicación del proyecto



Actividades a realizar Actividad 1 Se usa un plan de desarrollo documentado para seguir las actividades y

comunicar el estado de ellas. Refiérase a la actividad 7 del área clave de proceso de Planificación de proyectos de

software para practicas que cubren el contenido del plan de desarrollo de software Este plan de desarrollo es:

1. Actualizado a medida que el trabajo avanza para reflejar logros,

particularmente cuando se completan hitos

2. Fácilmente disponible para:

q EI grupo de ingeniería de software (incluyendo todos los sub-grupos tales como diseño de software),

q los administradores de software,

q los administradores del proyecto,

q la administración superior, y

q otros grupos afectados

3. La programación asociada a estas actividades de software.

4. EI presupuesto para estas actividades de software Actividad 2 El plan de desarrollo de software del proyecto se revisa de acuerdo a un

procedimiento documentado.

Refiérase a la actividad 6 del orea clave de proceso de Planificación de proyectos de software para prácticas que cubren las actividades para producir el plan de desarrollo de software.

Este procedimiento, típicamente, especifica que:

1. EI plan de desarrollo es revisado, según sea apropiado, para incorporar

refinamientos y cambios al plan.

Las interdependencias entre requisitos de sistema asignados al software, restricciones de diseño, recurso, costos, y la programación necesitan ser reflejadas en todos los cambios al plan.

2. EI plan es actualizado para incorporar los cambios en los compromisos, o los

nuevos compromisos.

3. El plan de desarrollo de software es examinado en cada revisión.

4. EI plan de desarrollo de software es administrado y controlado. "Administrado y controlado" implica que la versión del producto de trabajo en uso en un

momento dado (pasado o presente) es conocida (es decir, control de versiones), y los cambios son incorporados de forma controlada (es decir, control de cambios). Si se desea un mayor grado de control que el implicado por "administrado y controlado", el producto de trabajo puede ser puesto bajo la disciplina completa de administración de configuración, como es descrita en el área clave de proceso de Administración de Configuración de Software



Actividad 3 Los cambios a compromisos o nuevos compromisos del proyecto de

software, hechos a grupos o personas externas a la organización, deben ser revisados con la administración superior de acuerdo a un procedimiento documentado.

Actividad 4 Los cambios aprobados a compromisos que afectan al proyecto son

comunicados a los miembros del grupo de ingeniería de software y otros grupos relacionados.

Ejemplos de otros grupos relacionados con software incluyen:

– garantía de calidad de software, – administración de configuración de software, y

– apoyo de documentación

Actividad 5 Se sigue el tamaño del producto de software (o el tamaño de los cambios) y

se toman acciones correctivas si es necesario. Refiérase a la actividad 9 del área clave de proceso de Planificación de proyectos de

software para practicas que cubren las actividades para derivar las estimaciones de tamaño. 1. Se siguen los tamaños de los principales productos de software (o el tamaño

de los cambios)

2. EI tamaño real del código (generado, probado y entregado) es comparado con las estimaciones documentadas en el plan de desarrollo de software.

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

4. EI tamaño total proyectado de todos los productos de software (estimados combinados con reales) es refinado. monitoreado y ajustado regularmente.

5. Los cambios en las estimaciones de tamaño que afectan compromisos de software, son negociados con los grupos afectados y son documentados

Actividad 6 Se siguen el esfuerzo y los costos del proyecto y se toman acciones

correctivas si es necesario. Refiérase a la actividad 10 del área clave de proceso de Planificación de proyectos de

software para practicas que cubren las actividades para derivar las estimaciones de costo. 1. Los gastos reales de esfuerzo y costos, en el tiempo y en relación con los

productos desarrollados son comparados con las estimaciones documentadas en el plan de desarrollo de software para identificar potenciales desviaciones de 10 presupuestado,

2. Los costos de software son seguidos y comparados alas estimaciones documentadas en el plan de desarrollo de software,

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

4. Los cambios la provisión de personal y en otros costos que afecten los compromisos de software son negociados con los grupos afectados y son documentados.



Actividad 7 Se siguen los recursos críticos de computador y se toman acciones

correctivas si es necesario. Refiérase a la actividad 11 del área clave de proceso de Planificación de proyectos de

software para practicas que cubren las actividades para derivar las estimaciones de recurso de computadores.

1. EI uso real y proyectado de recursos computacionales para cada

componente principal es comparado con las estimaciones documentadas en el plan de desarrollo de software.

2. Los cambios en estimaciones de recursos críticos de computador que afecten los compromisos de software son negociados entre las partes afectadas.

Actividad 8 Se signe la programaci6n de software del proyecto y se toman acciones

correctivas si es necesario. Refiérase a la actividad 12 del área clave de proceso de Planificación" de proyectos de

software para prac ticas que cubre" las actividades para derivar las estimaciones de la programación.

1. EI cumplimiento de las actividades y de los hitos de la programación es

comparado con el plan de desarrollo de software

2. Se evalúan los efectos del atraso o adelanto en el cumplimiento de las actividades, hitos y otros compromisos, en relación con el impacto sobre actividades e hitos futuros

3. Las revisiones y modificaciones a la programación que afecten los compromisos de software son negociadas con los grupos afectados y son documentados.

Actividad 9 Se siguen las actividades técnicas de ingeniería de software del proyecto y

se toman acciones correctivas si es necesario. 1. Miembros del grupo de ingeniería de software informan el estado técnico al

administrador de primera línea en forma regular.

2. Los contenidos del software liberado para construcciones sucesivas son comparados con los planes documentados en el plan de desarrollo de software.

3. Los problemas identificados en cualquiera de los productos de software son informados y documentados.

4. Los reportes de problemas son seguidos hasta su cierre. Actividad 10 Se siguen los riesgos asociados con costos, recursos, programación y

aspectos técnicos del proyecto y se toman acciones correctivas si es necesario.

Refiérase a la actividad 13 del área clave de proceso de Planificación de proyectos de

software para practicas que cubren la identificación de los riesgos.



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

ajustadas a medida de que se dispone de información adicional.

6. Las áreas de alto riesgo son revisadas con el administrador del proyecto en forma regular.

Actividad 11 Se registran datos de medición reales y de replanificación para el proyecto

de software. Refiérase a la actividad 15 del área clave de proceso de Planificación de proyectos de

software para practicas que cubre" el registro de datos de proyecto. 1. La información registrada incluye las estimaciones y la información necesaria

para reconstruir las estimaciones y verificar su razonabilidad.

2. Los datos de replanificación son administrados y controlados

3. Los datos de planificación de software, datos de replanificacion, y datos de mediciones reales son archivados para ser utilizados en proyectos en ejecución y futuros.

4. Los reportes de problemas son seguidos hasta su cierre. Actividad 12 EI grupo de ingeniería de software conduce revisiones internas periódicas

para seguir el avance técnico, planes, desempeño, y problemas contra el plan de desarrollo de software.

Esas revisiones son conducidas entre:

1. Los administradores de primera línea y sus lideres de tarea de software.

2. EI administrador del proyecto de software, los administradores de primera línea, y otros administradores de software, según corresponda.

Actividad 13 Se realizan revisiones formales para abordar los logros y resultados del proyecto de software en algunos hitos escogidos de acuerdo a un procedimiento documentado.

Esas revisiones: 1. Se planifican para ocurrir en puntos significativos de la programación del

proyecto, tales como comienzo y fin de etapas.

2. Participan los clientes, usuarios finales y los grupos involucrados dentro de la organización.

Los usuarios finales referidos en estas practicas son usuarios finales designados por el

cliente o representantes de los usuarios finales.

3. Usan materiales que son revisados y aprobados por los administradores de software responsables.

4. Abordan los compromisos, planes y el estado de las actividades de software

5. Resultan en la identificación y documentación de los problemas mas significativos, los ítems de acción y las decisiones.

6. Se abordan los riesgos del proyecto de software

7. Resulta en un refinamiento del plan de desarrollo de software si es necesario



Medición y Análisis Medición 1 Se realizan mediciones y son usadas para determinar el estado de las

actividades de Supervisión y Control del Proyecto. Ejemplos de mediciones incluyen:

– Esfuerzo y otros recursos gastados en actividades de Supervisión y Control del Proyecto, y – Actividad de cambio en el plan de desarrollo de software. las cuales incluyen cambios en el

tamaño estimado de los productos de software, estimaciones de costos de software. recursos críticos de computador y programación

Verificación de la Implementación Verificación 1 Las actividades de seguimiento y control son revisadas con la

administración superior en forma periódica. El principal propósito de las revisiones periódicas por la administración superior es generar

conciencia de, y visión acerca de las actividades del proceso de software a un nivel de abstracción adecuado y de manera oportuna el tiempo entre revisiones debe cumplir con las necesidades de la organización y puede ser tan largo, como estén disponibles mecanismos adecuados de reporte de excepciones.

1. Se revisa el rendimiento técnico, costos, personal y programación,

2. Se abordan los conflictos y problemas que no solubles en los niveles inferiores,

3. Se abordan los riesgos del proyecto de software,

4. Se asignan ítems de acción, se revisan y son seguidas hasta su termino

5. Se prepara un informe resumen de estado de cada reunión el cual es distribuido a los grupos afectados,

Verificación 2 Las actividades de seguimiento y control son revisadas con el administrador del proyecto en forma periódica y ante eventos que lo requieran.

1. Los grupos afectados están representados,

2. El desempeño técnico, los costos, la asignación de recursos y la programación se revisan en comparación con el plan del proyecto de software

3. Se abordan las dependencias entre grupos,

4. Se abordan los conflictos y problemas no solubles en los niveles inferiores,

5. Se re evalúan los riesgos del proyecto,

6. Se asignan ítems de acción, se revisan y se siguen hasta su termino

7. Se prepara un informe resumen de cada reunión y se distribuye a los grupos afectados.



Verificación 3 EI grupo garantía de calidad de software revisa y/o audita las actividades y

productos de trabajo de Supervisión y Control de Proyectos de Software e informa los resultados.

Refiérase al área clave de proceso Garantía de Calidad de Software

Como mínimo, las auditorias o revisiones verifican:

1. Las actividades para revisión y repaso de compromisos.

2. Las actividades de revisión del plan de desarrollo

3. EI contenido del plan de desarrollo de software revisado.

4. Las actividades de seguimiento de los costos, programación, riesgos, restricciones técnicas, de diseño, de funcionalidad y de rendimiento.

5. Las actividades para conducir las revisiones técnicas y de la administración planificadas


Administración de Subcontratos

Un área clave de proceso para el nivel 2: Repetible El propósito de la Administración de Subcontratos es seleccionar subcontratistas de software

calificados y administrarlos efectivamente.

Involucra la selección del subcontratista, establecer compromisos con el subcontratista, y el

seguimiento y revisión del desempeño y resultados del subcontratista. Esas practicas cubren la

administración de un subcontrato de software (solamente), as! como también la administración de una

componente de software de un subcontrato que incluye software, hardware y posiblemente otras

componentes de sistema.

El subcontratista es seleccionado sobre la base de su habilidad para desarrollar el trabajo. Los

subcontratistas pueden ser seleccionados sobre la base de alianzas comerciales estratégicas, o bien

por razones técnicas. Las practicas de esta área clave de proceso abordan el proceso tradicional de

adquisición asociado con subcontratar una porción definida del trabajo con otra organización.

Al subcontratar, se crea un acuerdo documentado cubriendo tanto los requerimientos técnicos como no

técnicos (por ejemplo: fechas de entrega) y se usa como base para administrar el subcontrato. El

trabajo a ser realizado por el subcontratista y los planes para el trabajo son documentados. Los

estándares que son para ser seguidos por el subcontratista son compatibles con los estándares del

contratante.

Las actividades de planificación de software, seguimiento, y control para el trabajo subcontratado son

ejecutadas por el subcontratista. El contratante asegura que esas actividades de planificación,

seguimiento y control son ejecutadas apropiadamente

y que los productos de software entregados por el subcontratista satisfacen sus criterios de aceptación.

El contratante trabaja con el subcontratista para administrar las interfaces de productos y procesos.


Nivel 2: Repetible Administración de Subcontratos

Metas Meta 1 EI contratante selecciona subcontratistas de software calificados. Meta 2 EI contratante y el subcontratista acuerdan compromisos recíprocos. Meta 3 EI contratante y el subcontratista de software mantienen una comunicación

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

resultados reales y del desempeño en relación a sus compromisos.

Compromisos para desarrollar Compromiso 1 El proyecto sigue una política organizacional escrita para la administración

del subcontrato de software

Esta política, típicamente, especifica:

1. Se usan estándares y procedimientos documentados para la selección y la administración de los subcontratistas de software.

2. Los acuerdos contractuales son la base para administrar el subcontrato.

3. Los cambios en el subcontrato son hechos con la participación y acuerdo del contratante y el subcontratista.

Compromiso 2 Se designa un administrador de subcontratos para hacerse responsable de

establecer y administrar el subcontrato de software.

Este administrador debe:

1. EI administrador del subcontrato es conocedor y experimentado en ingeniería de software o tiene personas asignadas que tienen este conocimiento y experiencia.

2. Ser responsable de coordinar el alcance técnico del trabajo a ser subcontratado y los términos y condiciones del subcontrato con las partes afectadas.

EI grupo de ingeniería de sistemas del proyecto y el grupo de ingeniería de software definen

la cobertura técnica del trabajo a ser subcontratado

Los grupos funcionales de negocio, tales como adquisiciones, finanzas, y legal establecen y monitorean los términos y condiciones del subcontrato


Administración de Subcontratos Nivel 2: Repetible

3. EI administrador del subcontrato es responsable por:

q seleccionar al subcontratista de software,

q administrar el subcontrato y

q organizar el apoyo post-contrato de los productos subcontratados

Habilidades para desarrollar Habilidades 1 Se proveen recursos y financiamiento adecuados para seleccionar al

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

software y otros individuos por administrar el subcontrato.

2. Se hacen disponibles herramientas para apoyar la administración del subcontrato.

Ejemplos de herramientas de apoyo incluyen:

– modelos de estimación, – planillas de calculo y – programas de administración y programación de proyectos

Habilidades 2 Los administradores del software y otros individuos que están

involucrados en el establecimiento y administración de los subcontratos están entrenados para realizar esas actividades.

Ejemplos de capacitación incluyen:

– Preparación y panificación para la administración del subcontrato,

– Evaluación la capacidad del proceso de software de un postor del subcontrato, – Evaluación de las estimaciones y planes de un postor del subcontrato, – Selección de un subcontratista, y – Administración de un subcontrato

Habilidades 3 Los administradores del software y otros individuos que están

involucrados en la administración del subcontrato reciben orientación en los aspectos técnicos del subcontrato.

Ejemplos de orientación incluyen:

– Tecnologías de software en aplicación, – Herramientas de software en uso, – Metodologías en uso,

– estándares en uso, y – procedimientos en uso



Actividades a realizar Actividad 1 EI trabajo a ser subcontratado es definido y planificado de acuerdo a un

procedimiento documentado. Este procedimiento típicamente especifica que:

1. Las actividades y productos de software a ser subcontratados son seleccionados de acuerdo a características técnicas y no técnicas del proyecto

q Las funciones o subsistemas a ser subcontratados son seleccionados para calzar con las habilidades y capacidades de potenciales subcontratistas

q La especificación de los productos y actividades de software a ser subcontratadas es determinada basándose en un análisis sistemático y una partición adecuada de los requerimientos de sistema y de software

2. La especificación del trabajo a ser subcontratado y los estándares y procedimientos a ser seguidos se derivan de:

q La orden de trabajo,

q los requisitos de sistema asignados al software,

q los requisitos de software,

q el plan de desarrollo del software,

q los estándares de software y procedimientos

3. Una orden de trabajo es:

q preparada,

q repasada,

q acordada, Ejemplos de individuos que revisan y acuerdan la orden de trabajo del subcontratista

incluyen:

– EI administrador del proyecto, – EI administrador del proyecto de software, – Los administradores de software responsables,

– EI administrador de configuración de software, – EI administrador de garantía de calidad de software, y – EI administrador de! Subcontrato

q revisada cuando es necesario, y

q administrada y controlada.

q administra y controla un informe del trabajo a subcontratar.



4. Se prepara un plan para seleccionar un subcontratista, concurrentemente con el informe del trabajo.

"Administrado y controlado" implica que la versión del producto de trabajo en uso en un

momento dado (pasado o presente) es conocida (es decir, control de versiones), y los cambios son incorporados de forma controlada (es decir, control de cambios)

Si se desea un mayor grado de control que el implicado por "administrado y controlado", el producto de trabajo puede ser puesto bajo la disciplina completa de administración de configuración, como es descrita en el área clave de proceso de Administración de Configuración de Software

Refiérase a la habilidad 1 del área clave de proceso de Planificación de proyectos de

software para practicas que cubren el contenido típico de una orden de trabajo.

Actividad 2 EI subcontratista es seleccionado, en base a una evaluación de la

capacidad del postulante al subcontrato de realizar el trabajo, de acuerdo a un procedimiento documentado.

Este procedimiento cubre la evaluación de:

1. Propuestas enviadas para el subcontrato planificado.

2. Registros de desempeño en trabajos similares, si están disponibles.

3. La ubicación geográfica de los postulantes al subcontrato. Una administración efectiva de algunos subcontratos puede requerir frecuentes interacciones

cara a cara.

4. Las capacidades de administración e ingeniería de software. Un ejemplo de un método para evaluar capacidades de subcontratistas es el "Software

Capability Evaluación" del SEI

5. EI personal disponible para realizar el trabajo.

6. Experiencia previa en aplicaciones similares, incluyendo experiencia en software del equipo administrador de software del subcontratista.

7. Recursos disponibles. Ejemplos de recursos incluyen:

– Medios, – Hardware,

– Software, y – Capacitación



Actividad 3 EI acuerdo contractual entre el contratante y los subcontratistas es usado

como base para administrar el subcontrato. EI acuerdo contractual documenta:

1. Los términos y condiciones

2. La orden de trabajo. Refiérase a la habilidad 1 del área clave de proceso de Planificación de Proyectos de

Software para practicas que cubren el contenido típico de una orden de trabajo.

3. Los requisitos para los productos a ser desarrollados.

4. La lista de dependencias entre el subcontratista y el contratante.

5. Los productos subcontratados que serán entregados al contratante Ejemplo de productos incluyen:

– Código fuente, – Plan de desarrollo de software, – Ambiente de simulación, – Documentación del diseño, y

– EI plan de pruebas de aceptación

6. Las condiciones bajo las cuales se someterán a revisiones los productos

7. Los procedimientos y criterios de aceptación para ser usados en la evaluación del producto subcontratado antes de la aceptación por el contratante.

8. Los procedimientos y criterios de evaluación a ser usados por el contratante para monitorear y evaluar el desempeño del subcontratista.

Actividad 4 Un plan documentado de desarrollo del software subcontratado es revisado y aprobado por el contratante.

1. Este plan de desarrollo de software cubre (directamente o por referencia) los

ítems apropiados del plan de desarrollo de software del contratante

En algunos casos, el plan de desarrollo de software del contratante, puede incluir, el plan de desarrollo para el subcontratista, y por tanto no se necesita un plan de desarrollo de software del subcontratista aparte.

Refiérase a la actividad 7 del área clave de proceso de Planificación de Proyectos de

Software para practicas que cubren el contenido típico de "n plan de desarrollo de software.

Actividad 5 Un plan de desarrollo de software documentado y aprobado es usado para el seguimiento de las actividades de software y comunicar su estado.

Actividad 6 Los cambios a la orden de trabajo, los términos y condiciones del subcontrato y otros acuerdos son resueltos de acuerdo a un procedimiento documentado.

1. Este procedimiento típicamente especifica que están involucrados todos los

grupos afectados, tanto del contratante como del subcontratista ítems


apropiados del plan de desarrollo de software del contratante. Nivel 2: Repetible Administración de Subcontratos

Actividad 7 La administración del contratante conduce revisiones de estado /

coordinación con la administración del subcontratista.

1. Se le entrega al subcontratista la visión de las necesidades y deseos del cliente del producto y de los usuarios finales si corresponde.

Los usuarios finales referidos en esas practicas son usuarios finales designados por el

cliente, o representantes de los usuarios finales.

2. Se revisan, contra el plan de desarrollo del software del subcontratista, el desempeño técnico, costos, personal y programación.

3. Se revisan los recursos computacionales designados como críticos para el proyecto; la contribución del subcontratista alas estimaciones actuales es seguida y comparada con las estimaciones para cada componente de software documentadas en el plan de desarrollo de software del subcontratista.

4. Se abordan las dependencias criticas y compromisos entre el grupo de ingeniería de software del subcontratista y otros grupos del subcontratista.

5. Se abordan las dependencias y acuerdos críticos entre el contratante y el subcontratista.

q Se revisan los compromisos del subcontratista con el contratante y viceversa

6. Se abordan no conformidades con el subcontrato.

7. Se abordan los riesgos de proyecto que involucran el trabajo del subcontratista

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

9. Se asignan, revisan y siguen ítems de acción hasta cerrarlos Actividad 8 Se realizan intercambios y revisiones técnicas, en forma periódica, con el

subcontratista de software.

Estas revisiones:

1. Proveen al subcontratista de visibilidad de las necesidades y deseos del cliente y los usuarios finales, según corresponda.

2. Monitorean las actividades técnicas del subcontratista.

3. Verifican que la interpretación e implementación de los requisitos técnicos, por parte del subcontratista, están de acuerdo con los requisitos del contratante

4. Verifican que los acuerdos se están cumpliendo.

5. Verifican que los aspectos técnicos se están resolviendo de forma oportuna.



Actividad 9 Se conducen revisiones formales para abordar los resultados y logros de la

ingeniería de software del subcontratista, en hitos selectos y bajo un procedimiento documentado.


1. Las revisiones son pre-planificadas y documentadas en la orden de trabajo.

2. Las revisiones abordan los acuerdos para, planes para y estado de las actividades de software.

3. Se identifica y documentan los problemas significativos, los ítems de acción y las decisiones.

4. Se abordan los riesgos de! software

5. El plan de desarrollo del software del subcontratista se refina, según corresponda.

Actividad 10 Se conducen revisiones formales para abordar los resultados y logros de la

ingeniería de software del subcontratista, en hitos selectos y bajo un procedimiento documentado.


1. Los planes, recursos, procedimientos y estándares para garantía de calidad del subcontratista, son revisados periódicamente para asegurar que ellos son adecuados para monitorear el desempeño del subcontratista.

2. Se conducen revisiones regulares del subcontratista para asegurar que se están siguiendo los procedimientos y estándares aprobados.

q El grupo de garantía de calidad de software del contratante chequea las actividades y productos de ingeniería de software del subcontratista,

q El grupo de garantía de calidad de software del contratante audita los registros de garantía de calidad de software del subcontratista, según corresponda.

3. Los registros de las actividades garantía de calidad del subcontratista son auditados periódicamente para evaluar cuan bien se están siguiendo los planes, estándares y procedimientos de garantía de calidad de software.

Actividad 11 EI grupo de administración de la configuración del contratante monitorea

las actividades de administración de la configuración del subcontratista, de acuerdo a un procedimiento documentado.


1. Se revisan los estándares, planes, recursos y procedimientos de la administración de configuración del subcontratista para asegurar que son adecuados.

2. El contratante y el subcontratista coordinan sus actividades en materias relacionadas a la administración de la configuración para asegurar que los productos del subcontratista pueden ser rápidamente integrados o incorporados en el ambiente del proyecto del contratante.



3. La librería de líneas base de software del subcontratista es revisada periódicamente para evaluar que tan bien son seguidos los procedimientos para la administración de configuración del software y que tan efectivos son ellos en administrar la línea base de software.

4. El contratante y el subcontratista coordinan sus actividades en materias relacionadas a la administración de la configuración para asegurar que los productos del subcontratista pueden ser rápidamente integrados o incorporados en el ambiente del proyecto del contratante.

Actividad 12 EI contratante conduce pruebas de aceptación como parte de la entrega de

los productos de software del subcontratista, de acuerdo a un procedimiento documentado.


1. Están definidos, revisados y aprobados los criterios de aceptación para cada producto.

2. Los resultados de las pruebas de aceptación son documentados

3. Se planifican acciones para cada producto de software que no pasa sus pruebas de aceptación

Actividad 13 Se evalúa, periódicamente, el desempeño del subcontratista de software y

la evaluación es revisada con el subcontratista. La evaluación del desempeño del subcontratista provee una oportunidad para el

subcontratista de obtener retroalimentación en ellas sobre si esta o no satisfaciendo las necesidades de sus clientes (es decir, las necesidades del contratante). Un mecanismo tal como las revisiones de premio por cuota de desempeño proveen este tipo de retroalimentación, como opuesto alas revisiones periódicas técnicas y de coordinación que ocurren a través del proyecto La documentación de esas evaluaciones también actúa como una entrada para actividades futuras de selección de subcontratistas.


actividades de administración del subcontrato de software. Ejemplo de mediciones:

– Costos de las actividades para la administración del subcontrato en comparación con el plan.

– Tiempos de entrega reales para productos subcontratados en comparación con el plan – Tiempos de entrega del contratante al subcontratista en comparación con el plan



Verificación de la Implementación Verificación 1 Las actividades para la administración del subcontrato de software son

revisadas, con la administración superior, en forma periódica. Refiérase a la verificación 1 del área clave de proceso de Seguimiento y Control de

Proyectos para practicas cubriendo el típico contenido de las revisiones de seguimiento de la administración superior

Verificación 2 Las actividades para la administración del subcontrato de software son

revisadas con el administrador del proyecto, en forma periódica y en reacción a eventos.

Refiérase a la verificación 2 del área clave de proceso de Seguimiento y Control de Proyectos para practicas cubriendo el típico contenido de las revisiones de seguimiento de la administración superior.

Verificación 3 EI grupo de garantía de calidad del software, revisa y/o audita las

actividades y los productos del trabajo para administrar los subcontratos del software, y reporta los resultados.

Refiérase al área clave de proceso de Garantía de Calidad de Software.

Esta revisión y/o auditoria verifica:

1. Las actividades para seleccionar al subcontratista.

2. Las actividades para administrar el subcontrato.

3. Las actividades para la coordinación de las actividades de administración de la configuración del contratante y el subcontratista.

4. La revisión de la conducción de 10 planificado con el subcontratista.

5. La conducción de revisiones que establecen el termino de aspectos claves del proyecto para el subcontratista.

6. EI proceso de aceptación de los productos de software del subcontratista


Garantía de Calidad de Software

Un área clave de proceso para el nivel 2: Repetible El propósito de Garantía de Calidad de Software es dar ala administración una visibilidad adecuada del

proceso que esta siendo usado y los productos que están siendo construidos.

Garantía de Calidad de Software involucra revisar y auditar los productos y actividades de software a fin

de asegurar que ellos cumplan con los estándares y procedimientos aplicables, proveyendo al proyecto

de software y otros administradores apropiados de los resultados de esas revisiones y auditorias.

El grupo de Garantía de Calidad de Software trabaja con el proyecto de software durante sus etapas

tempranas para definir los planes, estándares y procedimientos que agregaran valor al proyecto de

software y satisfarán las restricciones del proyecto y las políticas de la organización.

Al participar en establecer los planes, estándares y procedimientos, el grupo de garantía de calidad de

software ayuda a asegurar que ellos se ajustan alas necesidades del proyecto y verifica que ellos serán

usables para efectuar revisiones y auditorias a través del ciclo de vida del software. El grupo de

garantía de calidad de software revisa las actividades del proyecto y audita los productos de trabajo de

software a través del ciclo de vida y provee a la administración de visibilidad sobre la adherencia del

proyecto de software a sus planes, estándares y procedimientos establecidos.


Nivel 2: Repetible Garantía de Calidad de Software

Metas Meta 1 Las actividades de garantía de calidad de software son planificadas. Meta 2 Verificar objetivamente si los productos y actividades satisfacen los

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

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

proyecto son abordados por la administración superior.

Compromisos para desarrollar Compromiso 1 EI proyecto sigue una política organizacional escrita para implementar

Garantía de Calidad de Software (GCS).

Esta política, típicamente, especifica:

1. La función de Garantía de Calidad de Software está implantada en todos los proyectos de software.

2. EI grupo de Garantía de Calidad de Software tiene un canal de reporte directo a la administración superior que es independiente de:

q EI administrador del proyecto,

q El grupo de ingeniería de software del proyecto, y

q Otros grupos relacionados con el software Ejemplo de otros grupos relacionados con el software incluyen:

– Administración del configuración de software, y – Apoyo de documentación.

Las organizaciones deben determinar la estructura organizacional que soportara las actividades que requieren independencia, tales como GCS, en el contexto de sus metas estratégicas de negocia y el ambiente de negocios.

La independencia debiera:

– Proveer a los individuos el ejecutar el rol GCS con la libertad organizacional de ser "los ojos Y los oídos" de la administración superior dentro del proyecto de software.

– Proteger a los individuos que ejecutan el rol de GCS de una evaluación de desempeño por la administración del proyecto software que ellos están revisando, y

– Proveer a la administración superior la confianza que se esta reportando información objetiva acerca de los procesos y los productos del proyecto de software.

3. La administración superior revisa periódicamente las actividades y resultados

de garantía de calidad.


Garantía de Calidad de Software Nivel 2: Repetible

Habilidades para desarrollar Habilidad 1 Existe un grupo de Garantía de Calidad de Software que es responsable de

coordinar e implementar las actividades de Garantía de Calidad de Software para el proyecto.

Un grupo es la colección de departamentos administradores e individuos que tienen

responsabilidad por un grupo de tareas o actividades. Un grupo puede variar desde un individuo asignado a jornada parcial, varios individuos asignados a jornada parcial de diferentes departamentos, hasta varios individuos dedicados a jornada c ompleta. Las consideraciones sobre cuando implementare un grupo incluyen las actividades y tareas asignadas, el tamaño del proyecto, la estructura y la cultura de la organización. Algunos grupos, tales como el grupo de garantía de calidad de software, están concentrados en actividades de proyecto, y otros, como el grupo de ingeniería de procesos de software, que esta concentrado en actividades horizontales de la organización

Habilidad 2 Se proveen los recursos y fondos necesarios para la realización de las

actividades de Garantía de Calidad de Software.

1. Se asigna específicamente un administrador responsable por las actividades de Garantía de Calidad de Software.

2. Un administrador superior, quien es conocedor del rol de GCS y tiene la autoridad de tomar acciones de control, es designado para recibir y actuar sobre los ítems de software no conformes.

q Todos los administradores en la cadena de reporte a la administración superior son conocedores del rol, responsabilidades y autoridad de GCS.

3. Se dispone de herramientas de apoyo a Garantía de Calidad de Software: Ejemplos de herramientas de apoyo incluyen:

– Estaciones de trabajo, – Programas de bases de datos, – Programas de planilla de calculo, y – Herramientas de auditoria

Habilidad 3 Los miembros del grupo de garantía de calidad de software están

entrenados para realizar las tareas asociadas a esta actividad. Ejemplos de capacitación incluyen:

– Practicas y habilidades de ingeniería de software,

– Roles y responsabilidades del grupo de ingeniería de software y otros grupos relacionados, – Métodos, estándares y procedimientos para el proyecto de software, – Dominio de aplicación del proyecto de sof tware, – Métodos, procedimientos y objetivos de garantía de calidad,

– Involucramiento del grupo de GCS en las actividades del proyecto, – Uso efectivo de los métodos y herramientas de garantía de calidad, y – Comunicación interpersonal



Habilidad 4 Los miembros del proyecto reciben orientación en los roles,

responsabilidades, autoridad y valor del grupo de GCS.

Actividades a realizar Actividad 1 Se prepara un plan de garantía de calidad para el proyecto de acuerdo a un



1. El plan de Garantía de Calidad de Software es desarrollado en las primeras etapas y en paralelo con la planificación global del proyecto.

2. El plan de Garantía de Calidad de Software es revisado por los grupos e individuos afectados.

Ejemplos de grupos e individuos afectados incluyen:

– El administrador de software, – Otras administradores de software,

– EI administrador de software, – Un representante de GCS del cliente, – EI administrador superior a quien el grupo de GCS reporta problemas de no conformidad, y

– EI grupo de ingeniería de software (incluyendo todos los sub-grupos, tales como diseño de software y también los lideres de tarea)

3. El plan de Garantía de Calidad de Software es administrado y controlado.

“Administrado y controlado" implica que la versión del producto de trabajo en uso en un momento dado (pasado o presente) es conocida (es decir, control de versiones), y los cambios son incorporados de forma controlada (es decir, control de cambios)

Si se desea un mayor grado de control que el implicado por "administrado y controlado", el

producto de trabajo puede ser puesto bajo la disciplina completa de administración de configuración, como es descrita en el área clave de proceso de Administración de Configuración de Software

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

GCS.

El plan cubre:

1. Responsabilidades y autoridad del grupo de GCS,

2. Requisitos de recursos para el grupo de GCS,

3. Programación y financiamiento para las actividades del grupo de GCS del proyecto.

4. La participación del grupo de GCS en la definición del plan de desarrollo de software, estándares y procedimientos del proyecto

5. Evaluaciones a ser realizadas por el grupo de garantía de calidad



Ejemplos de productos y actividades a ser evaluados incluyen:

– Software operacional y de soporte,

– Productos entregables y no entregables, – Productos de software y no software (por ejemplo documentos), – Actividades de desarrollo y verificación de productos (por ejemplo ejecución de los casos

de prueba), y – Las actividades seguidas para crear el producto

6. Auditorias y revisiones a ser conducidas por el grupo de GCS.

7. Estándares y procedimientos del proyecto a ser usados como base de las auditorias y revisiones del grupo de GCS

8. Procedimientos para documentar y seguir hasta el cierre los problemas de no conformidad

Estos procedimientos pueden ser incluidos como parte del plan o vía referencia a otros documentos donde están contenidos.

9. Documentación que se requiere que el grupo de GCS produzca.

10. Método y frecuencia para proveer retroalimentación al grupo de ingeniería de software y otros grupos relacionados con el software sobre las actividades de GCS.

11. Procedimientos para documentar y seguir hasta el cierre los problemas de no conformidad

Actividad 3 EI grupo de GCS participa en la preparación y revisión del plan de

desarrollo de software, estándares y procedimientos del proyecto.

1. EI grupo de GCS provee consultoría y revisión de los planes, estándares y procedimientos del proyecto, con respecto a:

q Cumplimiento de la política organizacional,

q Cumplimiento de requisitos y estándares impuestos del exterior. (por ejemplo, estándares impuestos por la orden de trabajo),

q Estándares que son apropiados para uso del proyecto,

q Tópicos que debería incluir el plan de desarrollo, y

q Otras áreas asignadas por el proyecto

2. EI grupo de GCS verifica que los planes, estándares y procedimientos estén en su lugar y sean utilizables para revisar y auditar el proyecto de software.



Actividad 4 El grupo de GCS revisa las actividades de ingeniería de software para

verificar conformidad.

1. Las actividades son evaluadas contra el plan de desarrollo y los estándares y procedimientos designados.

2. Refiérase a la característica común Verificando la Implementación en las otras áreas clave de proceso para practicas cubriendo las revisiones y auditorias especificas ejecutadas por el grupo de GCS

3. Las desviaciones son identificadas, documentadas, y seguidas hasta su conclusión

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

conformidad.

1. Los productos de software entregables son evaluados antes de ser entregados al cliente.

2. Los productos de software son evaluados de acuerdo a los estándares, procedimientos y requisitos contractuales designados

3. Las desviaciones del plan son identificadas, documentadas y seguidas hasta su conclusión

4. Las correcciones son verificadas Actividad 6 EI grupo de GCS informa periódicamente los resultados de sus actividades

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

documentadas y manejadas de acuerdo a un procedimiento documentado.

Este procedimiento establece típicamente que:

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

2. Las desviaciones del plan de desarrollo de software, los estándares y procedimientos designados del proyecto no solubles con los lideres de tarea, administradores de software o administradores de proyecto se documentan y se presentan al administrador superior designado para recibir ítems no conformes.

3. Los ítems no con formes presentados a la administración superior, son revisados periódicamente hasta su solución.

4. La documentación de los ítems no conformes es administrada y controlada. Actividad 8 EI grupo de GCS conduce revisiones periódicas de sus actividades y

hallazgos con el personal de GCS del cliente, según corresponda.




actividades de GCS. Ejemplo de mediciones incluyen:

– Cumplimiento de las hitas de GCS (en comparación a la establecido en el plan); – Trabajo terminada, esfuerzo y financiamiento gastado en las actividades de GCS

comparadas con el plan, – Numero de auditorias de productos y revisiones de actividades comparadas con el plan

Verificación de la Implementación Verificación 1 Las actividades de GCS se revisan con la administración superior en forma

periódica.

EI principal propósito de las revisiones periódicas por la administración superior es generar conciencia de, y visión acerca de las actividades del proceso de software a un nivel de abstracción adecuado y de manera oportuna. EI tiempo entre revisiones debe cumplir con las necesidades de la organización y puede ser tan largo, como estén disponibles mecanismos adecuados de reporte de excepciones.

Refiérase a la verificación 1 del área clave de proceso de Seguimiento y Control de

Proyectos para practicas cubriendo el típico contenido de las revisiones de seguimiento de la administración superior.

Verificación 2 Las actividades de GCS se revisan con el administrador del proyecto en

forma periódica y ante eventos que lo requieran.

Refiérase a la verificación 2 del área clave de proceso de Seguimiento y Control de Proyectos para practicas cubriendo el típico contenido de las revisiones de seguimiento de la administración superior.

Verificación 3 Expertos independientes revisan periódicamente las actividades del grupo

de Garantía de Calidad de Software.


Administración de Configuración de Software

Un área clave de proceso para el nivel 2: Repetible El propósito de la administración de configuración de software es establecer y mantener la integridad de

los productos de software del proyecto a través del ciclo

de vida del proyecto de software.

La administración de configuración de software involucra identificar la configuración del software (es

decir, una selección de productos de trabajo de software y sus descripciones) en puntos dados del

tiempo, controlando sistemáticamente los cambios a la configuración, y manteniendo la integridad y

trazabilidad de la configuración a través del ciclo de vida del software. Los productos de trabajo puestos

bajo administración de configuración de software incluyen los productos que son entregados al cliente

(por ejemplo, el documento de requerimientos de software y el código) Y los ítem identificados con, o

requeridos para crear esos productos de software. (por ejemplo, el compilador).

Se establece una librería de líneas base de software conteniendo las líneas base de software a medida

que ellas son desarrolladas. Los cambios alas líneas bases y la liberación de productos de software

construidos desde la librería de líneas base son controlados sistemáticamente vía las funciones de

control de cambios y auditoria de configuración de la administración de configuración de software.

Esta área clave de proceso cubre las practicas para ejecutar la función de administración de

configuración de software. Las practicas que identifican itemes/unidades de configuración especificas

están contenidas en las áreas clave de proceso que describen el desarrollo y manutención de cada

item/unidad de configuración.


Administración de configuración de Software Nivel 2: Repetible

Metas Meta 1 Las actividades de administración de configuración son planificadas. Meta 2 Se identifican, controlan y mantienen disponibles productos de trabajo de

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

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

de las líneas base de software.

Compromisos para desarrollar Compromiso 1 EI proyecto sigue una política organizacional escrita para la

implementación de administración de configuración de software (ACS).

Esta política, típicamente, indica que:

1. La responsabilidad por ACS en cada proyecto es explícitamente asignada

2. ACS es implementada a través de todo el ciclo de vida del proyecto

3. ACS es implementada para productos entregables externamente. algunos productos internos seleccionados y algunas herramientas de apoyo designadas usadas en el proyecto(ejemplo. compiladores)

4. Los proyectos establecen o tienen acceso a un repositorio para almacenar las unidades de configuración y los registros de ACS asociados,

Los contenidos de este repositorio son referidos como "Librería de líneas base de software" en esas prácticas. Las herramientas y procedimientos para accesar este repositorio son referidos como el "sistema de librería de administración de configuración" en esas practicas.

Los productos de trabajo que son puestos bajo administración de configuración y son tratados como una entidad simple son referidos como ítem de configuración. Los ítem que configuración son típicamente descompuestos en componentes de configuración, y las componentes dc configuración san típicamente descompuestos en unidades En un sistema de hardware / software, lodo el software puede ser considerado como uno ítem de configuración simple, o el software puede ser descompuesto en múltiples ítems de configuración. En esas prácticas el termino ítems/unidades de configuración es usado para referirse a los elementos bajo administración de configuración.

5. Las Líneas base de software y las actividades de ACS son auditadas

peri6dicamente.


Nivel 2: Repetible Administración de configuración de Software

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

líneas base de software del proyecto (es decir, un comité de control de configuraci6n de software-CCCS)

EI CCCS:

1. Autoriza el establecimiento de líneas base para el software y la identificaci6n de itemes/unidades de configuración.

2. Representa los intereses del administrador del proyecto y de todos los grupos que pueden ser afectados por cambios en las Líneas base del software.

Ejemplos de grupos afectados incluyen:

– Garantía de calidad de hardware, – Administración de configuración de hardware, Ingeniería de hardware, – Ingeniería de manufactura,

– Ingeniería de software (incluyendo todos los sub-grupos, tales como diseño de software),

– Ingeniería de sistemas, Pruebas de sistema,

– Garantía de calidad de Software, Administración de configuración de software

– Administración del contrato, y apoyo de documentación 3. Revisa y autoriza cambios en las líneas base del software.

4. Autoriza la creación de productos desde la librería de líneas base del software.

Habilidad 2 Existe un grupo que es responsable de coordinar e implementar ACS para

el proyecto. Un grupo es la colección de departamentos, administradores e individuos que tienen

responsabilidad por un grupo de tareas o actividades. Un grupo puede variar desde un individuo asignado a jornada parcial, varios individuos asignados a jornada parcial de Administración de diferentes departamentos, hasta varios individuos delicados a jornada completa. Las consideraciones sobre cuando implementare un grupo incluyen las actividades y tareas asignadas, el tamaño del proyecto, la estructura y la cultura de la organización Algunos grupos, tales como el grupo de garantía de calidad de software, están concentrados en actividades de proyecto, y otros, como el grupo de ingeniería de procesos de software, que esta concentrado en actividades horizontales de la organización

Este grupo coordina e implementa:

1. La creación y administración de la librería de lineas base de software del proyecto,

2. El desarrollo, manutención y distribución de los planes, estándares y procedimientos de ACS,



3. La identificación del conjunto de productos de trabajo que serán sometidos a

ACS

Un producto de trabajo es cualquier artefacto derivado de definir, mantener o usar un proceso de software

4. La administración del acceso a la librería de lineas base de software

5. La actualización de las líneas base de software

6. La creación de productos des de la librería de lineas base de software

7. El registro de acciones de ACS

8. La producción y distribución de informes de ACS Habilidad 3 Se proporcionan los recursos y fondos necesarios para realizar las

actividades de ACS,

1. Se designa un administrador con responsabilidad especifica por ACS.

2. Se hacen disponibles herramientas para apoyar las actividades de ACS.

Ejemplos de herramientas de soporte incluyen: – Estaciones de trabajo, – Programas de bases de datos, y – Herramientas de administración de configuración

Habilidad 4 Los miembros del grupo de ACS están entrenados en los objetivos,

procedimientos y métodos para ejecutar sus actividades de ACS. Ejemplos de capacitación incluyen:

– Métodos, estándares y procedimientos de ACS, y – Herramientas de ACS

Habilidad 5 Los miembros del grupo de ingeniería de software y otros grupos

relacionados con el software están entrenados para ejecutar sus actividades de ACS.

Ejemplos de otros grupos relacionados con el software incluyen:

– Garantía de calidad de software, y – Apoyo de documentación

Ejemplos de capacitación incluyen:

– Métodos, estándares y procedimientos de ACS a ser seguidos por las actividades de ACS dentro del grupo de ingeniería de software y otros grupos relacionados con el software, y

– El rol, responsabilidades y autoridad del grupo de administración de configuración



Actividades a realizar Actividad 1 Para cada proyecto se prepara un plan de ACS de acuerdo a un



1. Este plan es desarrollado en las etapas tempranas del proyecto y en paralelo con la planificación global de éste.

2. EI plan de administración de configuración es revisado por todos los grupos afectados.

3. EI plan de administración de configuración es administrado Y controlado. "Administrado y controlado" implica qué la versión del producto de trabajo en uso en su

momento dado (pasado o presente) es conocida (es decir, control de versiones), y los cambios son incorporados de forma controlada (es decir, control de cambios). Si se desea un mayor grado de control que el implicado por "administrado y controlado", el producto de trabajo puede ser puesto bajo la disciplina completa de administración de configuración, como es descrita en el área clave de proceso de Administración de Configuración de Software.

Actividad 2 Un plan de ACS documentado Y aprobado, es usado como la base para

realizar las actividades de ACS.

EI plan cubre:

1. Las actividades de ACS a ser realizadas, la programación de actividades, las responsabilidades asignadas y los recursos requeridos (incluyendo personal, herramientas y medios computacionales)

2. Los requisitos de ACS y las actividades a ser realizadas por el grupo de ingeniería de software y por otros grupos relacionados

Actividad 3 Se establece un sistema de librería de administración de configuración

como un repositorio de las lineas base de software.

Esta librería:

1. Apoya múltiples niveles de control de ACS, Ejemplos de situaciones llevando múltiples niveles de control incluyen:

– Diferencias en el nivel de contra! necesario en diferentes tiempos en el ciclo de vida (por ejemplo, el control es mas ajustado a medida que el producto va madurando),

– Diferencias en los niveles de control requeridos para sistemas de software solamente vs. sistemas que incluyen tanto hardware como software

2. Proporciona almacenamiento y recuperación de las unidades de

configuración

3. Permite compartir y transferir las unidades de configuración entre los grupos afectados y dentro de los niveles de control de la librería



4. Ayuda en el uso de estándares de producto para los itemes/unidades de configuración.

5. Permite el almacenamiento y recuperación de versiones de archivo de los itemes/unidades de configuración.

6. Ayuda a asegurar una correcta creación de los productos desde la librería de lineas base del software.

7. Permite el almacenamiento, realización y recuperación de los registros de administración de configuración.

8. Apoya la producción de informes de administración de configuración.

9. Proporciona la manutención de la estructura y contenidos de la librería. Ejemplos de funciones de manutención de la librería incluyen:

– Respaldo/restauración de archivos de la libraría, y – Recuperación de errores de la librería

Actividad 4 Se identifican los productos de software a ser puestos bajo administración

de configuración. 1. Los ítems/unidades de configuraci6n son seleccionadas de acuerdo a un

criterio documentado. Ejemplos de productos de trabajo de software que pueden ser identificados como

itemes/unidades de configuración incluyen:

– Documentación relacionada con el proceso (par ejemplo. planes. estándares o procedimientos)

– Requerimientos de software. – Diseño de software, – Unidades de código de software,

– Procedimientos de prueba de software, – Construcciones del sistema de software para las actividades de prueba, – Construcciones del sistema de software para entrega al cliente o usuarios finales, – Compiladores, y

– Otras herramientas de soporte 2. Se asigna identificadores únicos a los itemes/unidades de configuración.

3. Se especifican las características de cada item/unidad de configuración.

4. Se especifican las lineas base a fa que pertenece cada item/unidad de configuración.

5. Se especifica el punto en su desarrollo en que cada item/unidad es puesta bajo administración de configuración.

6. Se asignan responsables por cada item/unidad de configuración. Actividad 5 Las solicitudes de cambios requeridos y los reportes de problemas para

todos los itemes/unidades de configuración son iniciados, registrados, revisados, aprobados y seguidos de acuerdo a un procedimiento documentado.



Actividad 6 Los cambios en las lineas base son controlados de acuerdo a un



1. Se realizan revisiones y/o pruebas de regresión para asegurar que los cambios no produzcan efectos inesperados en la línea base.

2. Solo los itemes/unidades de configuración aprobadas por el CCCS son incorporados en la línea base del software.

3. Las unidades de configuración son registradas a la entrada y la salida de forma que se mantenga la conformidad e integridad de la librería de lineas base de software.

Ejemplos de pasos de registro de entrada / salida incluyen:

– Verificar que las revisiones están autorizadas, – Crear un log de cambios,

– Mantener una copia de los cambios, – Actualizar la librería de lineas base de software, – y Archivar la línea base de software reemplazada

Actividad 7 Los productos son creados desde la librería de lineas base y su liberaci6n

es controlada de acuerdo a un procedimiento documentado.


1. El CCCS autoriza la creación de productos desde la librería de lineas base de software.

2. Los productos construidos desde las lineas base de software, tanto para uso interno y externo, son construidos solo a partir de los itemes/unidades de configuración en la librería de lineas base de software.

Actividad 8 EI estado de las unidades de configuración es almacenado de acuerdo a un



1. Las acciones de administración de configuración son almacenadas con el detalle suficiente para que el contenido y estado de cada item/unidad de configuración sea conocido y para que las versiones previas puedan sean recuperadas.

2. Se mantiene la historia y el estado actual de cada item/unidad de configuración.



Actividad 9 Se desarrollan informes estándares que documentan las actividades de

ACS y los contenidos de las lineas base, y se hacen disponibles a los grupos e individuos afectados.

Ejemplos de informes incluyen:

– Minutas de reuniones del CCCS,

– Resumen y estado de las solicitudes de cambios, – Resumen y estado de los reportes de los problemas (incluyendo reparaciones), – Resumen de los cambios hechos alas lineas base de software, – Historia de revisiones de los Itemes/unidades de configuración

– Estado de la línea base de software, y – Resultados de las auditorias de lineas base realizadas

Actividad 10 Se conducen auditorias de las lineas base del software de acuerdo a un



1. Existe una adecuada preparación para las auditorias.

2. Se evalué la integridad de las lineas base de software.

3. Se revise la estructura y medios del sistema de librería de administración de configuración.

4. Se verifique la completitud y correctitud del contenido de las librerías de administración de configuración.

5. Se verifique la aplicación de los estándares y procedimientos de ACS aplicables.

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

7. Se sigan las acciones a tomar a partir de las auditorias hasta su cierre


actividades de ACS.

Ejemplos de mediciones incluyen:

– Numero de solicitudes de cambios procesadas por unidad de tiempo – Cumplimiento de los hitos de las actividades de ACS en comparación al plan, y – Trabaja terminado, "esfuerzo gastado, y costa de las actividades de ACS



Verificación de la Implementación Verificación 1 Se revisan las actividades de ACS con la administración superior en forma

periódica. El principal propósito de las revisiones periódicas por lo administración superior es generar

conciencia de, y visión acerca de las actividades del proceso de software a un nivel de abstracción adecuado y de manera oportuna EI tiempo entre revisiones debe cumplir con las necesidades de la organización y puede ser tan largo, como estén disponibles mecanismos adecuados de reporte de excepciones.

Refiérase a la verificación 1 del área clave de proceso de Seguimiento y Control de

Proyectos para practicas cubriendo el típico contenido de las revisiones de seguimiento de la administración superior

Verificación 2 Se revisan las actividades de ACS con el administrador del proyecto en

forma periódica y ante eventos que lo requieran. Refiérase a la verificación 2 del área clave de proceso de Seguimiento y Control de

Proyectos para practicas cubriendo el típico contenido de las revisiones de seguimiento de la administración superior.

Verificación 3 El grupo de Administración de la Configuración audita en forma periódica

las líneas base del software para verificar que están conformes a la documentación que las define.

Verificación 4 El grupo de Garantía de Cali dad de Software revisa y/o audita las

actividades y productos de trabajo de ACS e informa los resultados. Refiérase al área clave de procesos de Garantía de Calidad de Software

Como mínimo, las revisiones y/o auditorias verifican:

1. Conformidad con los estándares y procedimientos de:

q EI grupo de ACS,

q EI CCCS

q EI grupo de ingeniería de software, y

q Otros grupos relacionados con el software

2. La ocurrencia de auditorias periódicas de las lineas base de software

practicas cmm l2 (espanol)

Documents