PROCESO PARA EL CONTROL DE CAMBIOS [[AUTOR]] VERSIÓN 10

MODELOS DE EVALUACIÓN Y MEJORA DE PROCESOS ANÁLISIS COMPARATIVO
10 PROCESO 31IP2003 INTERPRETACIÓN PREJUDICIAL DE
11 PROCESO 018IP2008 INTERPRETACIÓN PREJUDICIAL DE LOS

11 PROCESO 045IP2013 INTERPRETACIÓN PREJUDICIAL DE LOS
11 PROCESO 76IP2000 SOLICITUD DE INTERPRETACIÓN PREJUDICIAL
11 PROCESO N° 14IP2003 INTERPRETACIÓN PREJUDICIAL DE

<Nombre de la institución>


Proceso para el control de cambios [[Autor]]

Versión 1.0 [[fecha]]

PROCESO PARA EL CONTROL DE CAMBIOS [[AUTOR]] VERSIÓN 10


[[Nombre de la institución]]









Proceso para el control de cambios

[[fecha]]

Versión 1.0




Información del documento

Título

Proceso para el control de cambios

Identificador

Versión

1.0

Archivo

Proceso control de cambios.doc

Autor

Fecha

Estado



Aprobación del documento

Gerente Técnico

<nombre>

<firma>

<fecha>

Responsable de SCM

<nombre>

<firma>

<fecha>

[[cargo/posición]]

<nombre>

<firma>

<fecha>

[[cargo/posición]]

<nombre>

<firma>

<fecha>

[[cargo/posición]]

<nombre>

<firma>

<fecha>



Registro de cambios

Nro. de cambio

Fecha

Tipo(1)

Descripción del cambio

Autor

Nro. de petición































  1. A: Agregar – M: Modificar – E:Eliminar


Tabla de Contenidos

2 Introducción 3

2.1 Propósito 3

2.2 Alcances 3

2.3 Descripción del documento 3

2.4 Glosario de términos 3

2.5 Acrónimos 4

3 Responsables 5

4 Descripción del proceso 6

4.1 Definición 6

4.2 Aplicación 6

4.3 Etapas 6

4.3.1 Proponer cambios 6

4.3.2 Evaluar los cambios propuestos 7

4.3.3 Aprobar y/o rechazar los cambios 8

4.3.4 Implementar los cambios 9

4.4 Participantes 10

4.4.1 Representante de SCM 10

4.4.2 Desarrolladores 10

4.4.3 CCB 11

4.4.4 Unidad de SQA 11

4.4.5 Jefe de proyecto 11

5 Referencias 12

12



2Introducción



2.1Propósito


<Objetivo organizacional asociado al documento, audiencia y responsables de la actualización del documento. >


El presente documento describe los pasos a seguir para el establecimiento del control de cambios en un proyecto de desarrollo de software en la [[institución]], con el propósito de apoyar al responsable de su implementación.


El proceso aquí descrito es actualizado y revisado periódicamente por [[Unidad/área]] <Unidad o área responsable de la actualización y soporte de este proceso. > para garantizar que las experiencias y las lecciones aprendidas sean incorporadas.



2.2Alcances


<Visión general del documento. Incluye sus objetivos y alcance. >


El presente documento describe el proceso de control de cambios, aplicable durante todo el ciclo de vida del software, centrándose en apoyar su establecimiento, ejecución, documentación y monitoreo.


El objetivo global, es controlar y gestionar apropiadamente los cambios que sufren los ítems de configuración (Configuration Item, CI) durante el desarrollo y la mantención.



2.3Descripción del documento


<Breve descripción de los capítulos/secciones del documento. >


Capitulo 1

Introducción: provee una visión general sobre los contenidos y objetivos del documento. Además, entrega las definiciones y acrónimos utilizados en los capítulos posteriores.

Capítulo 2

Responsables: especificación de la unidad/área responsable de la mantención del proceso de control de cambios.

Capitulo 3

Descripción del proceso: entrega una definición del proceso, su campo de aplicación, etapas, y participantes.

Capítulo 4

Referencias bibliográficas

Capítulo 5

Anexos:



2.4Glosario de términos










2.5Acrónimos


<Lista de las abreviaciones utilizadas en el documento. >


Acrónimo

Significado

CC

Change Control, Control de Cambios

CCB

Configuration Control Board, Comité de Control de la Configuración

CI

Configuration Item, Ítem de Configuración

PL

Program Librarian, Bibliotecario

SCM

Software Configuration Management, Gestión de Configuración del Software

SQA

Software Quality Assurance, Aseguramiento de la Calidad del Software


3Responsables


<Designación de una unidad/área responsable de la mantención y soporte del proceso de control de cambios. >


Como se mencionó previamente, la [[Unidad/área]] <Por ejemplo, SCM. > es responsable de la actualización y el soporte del proceso de control de cambios. Por lo tanto son de su competencia las siguientes obligaciones:




4Descripción del proceso


4.1Definición


<Definición y descripción global del proceso de control de cambios. Es recomendable adjuntar gráficos representativos del proceso. >



El control de cambios (Change Control, CC) es la columna vertebral del proceso de SCM. En términos generales, es un proceso sistemático para evaluar, coordinar y decidir sobre los cambios propuestos, así como también, para monitorear la implantación e incorporación de aquellas modificaciones aprobadas a los baselines y la documentación asociada. El CC asegura que los cambios sean propuestos, justificados, evaluados, coordinados, aprobados o rechazados, documentados e incorporados a un nuevo baseline.


De acuerdo a esto es necesario contar con un proceso que garantice que solamente los cambios aprobados sean implementados en un baseline. Para ello el CC se compones de cuatro actividades principales: proponer cambios, evaluar los cambios propuestos, aprobar/rechazar los cambios propuestos, e implementar los cambios aprobados.



4.2Aplicación


<Campo de aplicación del proceso. También pueden añadirse observaciones y recomendaciones.>


El proceso de CC es aplicable a todas las etapas del ciclo de vida del software. Sin embargo, tiene sentido sólo a partir del establecimiento formal de la identificación de la configuración.



4.3Etapas


<Descripción de las etapas del proceso de control de cambios. >


A continuación se describen las etapas del proceso de control de cambios en términos de sus objetivos, criterios de entrada/salida y de sus actividades. Además, se enuncian los participantes de cada etapa y sus responsabilidades durante ella.


4.3.1Proponer cambios



Objetivo


El objetivo de esta etapa es identificar los problemas en la configuración, informarlos y dar inicio al proceso de CC.


Participantes


Representante de SCM, y cualquier desarrollador.



Criterios de entrada


  1. Identificación e informe de un problema en la configuración.



Actividades


  1. Identificación de un problema.


El proceso de CC comienza con la detección de un problema en un CI. Inicialmente, el problema debe ser analizado informalmente por uno o más desarrolladores para establecer las causas y determinar posibles acciones correctivas.


Realizado lo anterior, quién detectó el problema debe informarlo mediante una Petición de cambios dirigida al responsable de SCM.


Observación: La detección de problemas, generalmente, ocurre durante las revisiones, auditorías, pruebas o en el transcurso de la operación del producto.


  1. Proponer cambios.


El responsable recibe la petición de cambio, revisando en primera instancia su claridad y la validez del problema. Si determina que es incompleta, la devolverá a su origen. En caso contrario, le asignará un identificador único, con el propósito de monitorearla, y registrará su información en un archivo (manual o electrónico) o base de datos para el monitoreo de las peticiones de cambio.


La petición de cambios debe satisfacer como mínimo las siguientes preguntas:




Criterios de salida


  1. La petición de cambio es aprobada en primera instancia por el responsable de SCM.



4.3.2Evaluar los cambios propuestos



Objetivo


El propósito de esta etapa es hacer una evaluación de los cambios solicitados para verificar la validez de la petición de cambio.


Participantes


Representante de SCM, desarrolladores



Criterios de entrada


  1. La petición de cambio es aprobada en primera instancia por el responsable de SCM.



Actividades


  1. Distribución de la petición de cambio entre un subconjunto de los desarrolladores.


El responsable de SCM al interior del proyecto, debe distribuir la petición de cambio entre un conjunto de desarrolladores para una segunda evaluación.


Estos desarrolladores, preferentemente, deben ser personas con una amplia visión del proyecto, pues ello da mayor objetividad y globalidad a su evaluación.


  1. Los desarrolladores analizan la petición de cambios.


Los desarrolladores deben analizar las modificaciones propuestas en términos de su impacto sobre los requerimientos, la funcionalidad, interfaz, utilidad, costos y planificación del sistema, y también, sobre la confiabilidad, mantenibilidad, transportabilidad y eficiencia del software.


Los productos de este análisis son la descripción de los cambios por realizar para implementar la petición de cambios, los CI’s y la documentación afectada, y los recursos necesarios.


  1. El responsable de SCM establece el paquete de cambios.


Una vez que el responsable de SCM recibe la información del análisis realizado por los desarrolladores, conforma el paquete de cambios. Este contiene a la petición de cambios y los resultados de la evaluación realizada por los desarrolladores durante la presente etapa.



Criterios de salida


  1. Se estableció y completó el paquete de cambios.



4.3.3Aprobar y/o rechazar los cambios


Objetivo


El objetivo de esta etapa es dar una resolución a las peticiones de cambio.


Participantes


CCB, representante de SCM



Criterios de entrada


  1. El paquete de cambios se encuentra disponible.



Actividades


  1. El representante de SCM, al interior del proyecto, distribuye entre los miembros del CCB el paquete de cambios.


El CCB es el responsable de tomar la decisión final sobre la petición de cambios. Por ello el representante de SCM debe entregar a sus miembros el paquete de cambio con la debida anticipación a la reunión de evaluación.


  1. El CCB se reúne para resolver la aprobación o rechazo de la petición de cambio.


Básicamente, el CCB se reúne para decidir, sobre la base de la información contenida n el paquete de cambios, la aprobación o rechazo de la petición. Su respuesta puede ser la aprobación, rechazo o una solicitud de mayor información y/o de un análisis adicional.


Si se autoriza la petición, ésta es enviada al CMO para dar curso a las acciones respectivas. De ser denegada, es devuelta a su origen junto a las razones expuestas por el CCB. Y en la última circunstancia, se envía el paquete de cambios al grupo de desarrolladores, que estuvo a cargo de su análisis, junto a las consultas del CCB.



Criterios de salida


  1. El CCB a aprobado o rechazado la petición.


En el caso de aprobación se pasa a la siguiente etapa. En el caso contrario el proceso se cierra.


4.3.4Implementar los cambios



Objetivo


El propósito de esta etapa es verificar la implementación de las acciones correctivas aprobadas pro el CCB.


Participantes


Representante de SCM, desarrolladores, bibliotecario, grupo de SQA.


Criterios de entrada


  1. La petición de cambio fue aprobada por el CCB.



Actividades


  1. Notificación del cambio.


Una vez que el cambio ha sido autorizado, se pone en marcha su implantación mediante una notificación de cambio que detalla los cambios por realizar, las restricciones y los criterios para su posterior revisión y auditoría. Esto debe ser llevado a cabo por el responsable de SCM.


Una copia de la notificación es enviada al bibliotecario y otra a los desarrolladores a los cuales se les asignó la tare de implementar las acciones correctivas definidas en la petición de cambio.


  1. Autorización de acceso a los CI de las baselines establecidas.


Al despacharse la notificación, se autoriza el acceso a los CIs contenidos en la biblioteca del software a los desarrolladores responsables de realizar los cambios aprobados. Los cambios son hechos sobre una copia del CI.


Es responsabilidad del bibliotecario habilitar correctamente dicho acceso.


  1. Revisión y aprobación de los cambios realizados.


Cuando los cambios hayan sido completados, debe llevarse a cabo una revisión sobre el nuevo CI. Esta revisión y el monitoreo de la adecuada implementación de los cambios es responsabilidad de SQA.


Cuando las actividades de SQA sobre los CIs afectados hayan concluido, se originará una nueva versión de los CIs y estos volverán a la biblioteca. Por último, la nueva versión será incluida en la baseline correspondiente y distribuida en la organización.



Criterios de salida


  1. Los cambios han sido completados y aprobados.

  2. Una nueva versión de los CIs afectados a ha sido incorporada a la biblioteca del software



4.4Participantes


<Definición de los roles y responsabilidades de los participantes del proceso de control de cambios. >


4.4.1Representante de SCM


La unidad de SCM debe nombrar a uno de sus miembros como el responsable del proceso de control de cambios para cada proyecto. Este representante de SCM al interior del proyecto deberá responsabilizarse de:



4.4.2Desarrolladores


El término desarrollador es utilizado para referenciar a cualquier miembro de un proyecto. En relación con el proceso de control de cambio, cada desarrollador debe:



4.4.3CCB


El comité de control de la configuración (Configuration Control Board, CCB) tiene bajo su responsabilidad la revisión de las peticiones de cambio a los componentes del software y la aprobación de éstas.


4.4.4Unidad de SQA


Dentro de las actividades de SQA se encuentra el monitoreo de las actividades de SCM, por ello un representante de SQA tiene que:



4.4.5Jefe de proyecto


A pesar de no ser miembro activo del proceso de control de cambio, el jefe de proyecto debe facilitar sus actividades, difundirlas entre los desarrolladores y, de ser necesario, debe participar como miembro del CCB.

5Referencias


<Lista bibliográfica utilizada para la definición del proceso de control de cambios. Es recomendable ser lo más específico posible para evitar confusiones posteriores. >

12

PROCESO PARA EL CONTROL DE CAMBIOS [[AUTOR]] VERSIÓN 10


11 PROCESO Nº 073IP2011 INTERPRETACIÓN PREJUDICIAL
12 PROCESO 6IP93 INTERPRETACIÓN PREJUDICIAL DE LOS
12 PROCESO Nº 48IP99 INTERPRETACIÓN PREJUDICIAL DE


Tags: cambios [[autor]], los cambios, proceso, control, cambios, [[autor]], versión