Proceso de Administración del QualDevProcess

Manuel Andrés Muñoz Lara Código: 200111994

Carlos Felipe Romero Toro

Código: 200112281

Asesores: Rubby Casallas, PhD Nicolás López, MsC

Tesis de Grado para optar por el titulo de

Ingeniero de Sistemas y Computación

Departamento de Ingeniería de Sistemas y Computación Facultad de Ingeniería

Universidad de los Andes Mayo de 2006

Contenidos

1. INTRODUCCIÓN .................................................................................................................................. 4 2. OBJETIVOS............................................................................................................................................ 5

2.1. OBJETIVO GENERAL ......................................................................................................................... 5 2.2. OBJETIVOS ESPECÍFICOS................................................................................................................... 5

3. GENERALIDADES DEL PROCESO DE ADMINISTRACIÓN DE PROCESOS (PAP) .............. 5 4. MODELAJE DE PROCESOS USANDO SPEM ................................................................................. 6

4.1. DESCRIPCIÓN GENERAL.................................................................................................................... 6 4.2. ESTRUCTURA DEL PROCESO ............................................................................................................. 6

4.2.1. WorkProduct y WorkProductKind.............................................................................................. 6 4.2.2. WorkDefinition y ActivityParameter .......................................................................................... 7 4.2.3. Activity y Step ............................................................................................................................. 7 4.2.4. ProcessPerformer y ProcessRole ............................................................................................... 7

4.3. COMPONENTES DEL PROCESO........................................................................................................... 7 4.3.1. ProcessComponent ..................................................................................................................... 7 4.3.2. Package ...................................................................................................................................... 7 4.3.3. Discipline.................................................................................................................................... 8

4.4. CICLO DE VIDA DEL PROCESO........................................................................................................... 8 4.4.1. Phase .......................................................................................................................................... 8 4.4.2. Lifycicle ...................................................................................................................................... 8 4.4.3. Iteration ...................................................................................................................................... 8 4.4.4. Precondition and Goal ............................................................................................................... 8 4.4.5. Ejemplo del Ciclo de Vida del Proceso. ..................................................................................... 8

4.5. NOTACIÓN........................................................................................................................................ 9 4.5.1. Iconos propuestos ....................................................................................................................... 9

4.6. DIAGRAMAS DE CLASES ................................................................................................................. 10 4.7. DIAGRAMAS DE PAQUETES............................................................................................................. 11 4.8. DIAGRAMAS DE ACTIVIDAD ........................................................................................................... 12 4.9. DIAGRAMAS DE CASOS DE USO....................................................................................................... 14

5. PROCESO DE ESPECIFICACIÓN FORMAL DE PROCESOS (EFP) ........................................ 15 5.1. ROLES DE ESTE PROCESO................................................................................................................ 15

5.1.1. Líder de Proceso....................................................................................................................... 15 5.1.2. Comité de Diseño de Proceso................................................................................................... 15

5.2. DESCRIPCIONES DE LOS PRODUCTOS DE TRABAJO .......................................................................... 15 5.3. ACTIVIDADES DEL PROCESO........................................................................................................... 16

5.3.1. Formación del Comité de Diseño del Proceso ......................................................................... 16 5.3.2. Documento de Especificación del Proceso............................................................................... 16 5.3.3. Definición de documentos de apoyo a la definición del proceso............................................. 16 5.3.4. Administración de configuraciones con Changeset.................................................................. 17

5.4. EL PROCESO COMO PROYECTO ....................................................................................................... 17 5.5. ÍTEMS DE CONFIGURACIÓN PARA LOS PROCESOS............................................................................ 17

5.5.1. Esquema de identificación........................................................................................................ 17 5.5.2. Manejo de versiones para los ítems.......................................................................................... 18 5.5.3. Manejo de estados para los ítems............................................................................................. 18

5.6. MANEJO DE LÍNEAS DE BASE .......................................................................................................... 18 6. PROCESO DE SOLICITUDES DE CAMBIO DE PROCESOS (SCP) .......................................... 18

6.1. ACTIVIDADES DEL PROCESO........................................................................................................... 19 6.1.1. Solicitudes de Cambio de Proceso............................................................................................ 19 6.1.2. Revisión y Asignación de las Solicitudes de Cambio................................................................ 20

6.1.3. Análisis y Resolución de las Solicitudes de Cambio................................................................. 20 7. CONCLUSIONES ................................................................................................................................ 20 8. REFERENCIAS.................................................................................................................................... 25

1. Introducción

Los trabajos de tesis de algunos de los estudiantes que han hecho parte del grupo QualDev se han dedicado a definir procesos para el grupo. Estas definiciones han contribuido a la construcción de un proceso de desarrollo de software completo y que permita, mediante su uso, la producción de software de calidad. El grupo, a lo largo de varios semestres, ha hecho uso de estos procesos y los ha modificado cuando no satisfacen sus necesidades. Estas modificaciones principalmente consisten en eliminar partes de los procesos, o en detallar más algunas tareas específicas o incluso agregar otras definiciones que no se habían contemplado antes.

Esta manera de trabajar, aunque ha sido positiva para el grupo, tiene problemas importantes con respecto al formalismo con el que se han hecho las actividades, y son principalmente los siguientes:

- Las especificaciones de los procesos no tienen un formalismo estándar

- No existe un proceso para hacer las modificaciones a los procesos.

En el presente trabajo nos proponemos definir un proceso de administración de proceso (PAP) que permita solucionar estos inconvenientes y especificar mejor las prácticas que giran en torno a la definición y mejoramiento de los procesos existentes.

Existen varias motivaciones más para realizar una definición del PAP. Por una parte, están algunas practicas de CMMi, por otra parte, están las recomendaciones de la literatura de ingeniería de software al respecto, y por otra la experiencia propia del grupo. En general, podemos decir que estas motivaciones se enmarcan dentro de un conjunto más grande que es el SPI (Software Process Improvement)

El modelo CMMi cuenta con un conjunto de metas genéricas (Generic Goals), que son llamadas así porque aparecen en distintas áreas de proceso. Para satisfacer estas metas, el modelo propone una serie de prácticas que se deben cumplir. El objetivo de estas prácticas es asegurar la institucionalización de los procesos definidos [1](p.19). Estas metas y prácticas están definidas para cada nivel.

El contexto que nos interesa es el del segundo y tercer nivel, y el propósito del PAP es contribuir al avance hacia las metas genéricas de estos niveles. Las metas son las siguientes:

GG2. El proceso es institucionalizado como un proceso administrado [1] (p.38)

GG3. El proceso es institucionalizado como un proceso definido [1](p.47)

Estas metas genéricas tienen a su vez varias prácticas genéricas que deben ser realizadas. En concreto, nos interesa que el PAP pueda satisfacer las siguientes prácticas genéricas para varias áreas de proceso a la vez:

G.P.2.1. Establecer una Política Organizacional.

G.P.2.3. Proveer Recursos.

G.P.2.4. Asignar Responsabilidades.

G.P.2.6. Administrar configuraciones.

G.P.3.1. Establecer un proceso definido.

Nuestro referente principal en la literatura es el proceso TSPi. Humphrey define una etapa dentro de la fase de postmortem que debe estar dedicada explícitamente a la tarea de mejorar el proceso. Esta etapa consiste en realizar propuestas de mejoramiento del proceso (Process Improvement Proposals o PIP) para mejorar los procesos.

Humphrey señala que, una vez se tiene definido un proceso, su mejoramiento es complicado puesto que los cambios que realmente pueden mejorar el proceso son pequeños y se pueden olvidar con facilidad [5](p.186). Por esta razón, es necesario que tanto los procesos, como la manera de hacer mejoras sobre el, sean lo más formales posible.

Por otra parte, el grupo ha experimentado gran cantidad de cambios a lo largo de los últimos semestres (2005-1 y 2005-2), especialmente en el proceso de planeación. A pesar de que las definiciones y las mejoras al proceso se encuentran registradas en distintos documentos, no existe un formato ni un depósito que permita ver claramente en qué aspectos ha cambiado el proceso, y por tanto, no se puede ver qué cambios que se han propuesto a lo largo de estos semestres han entrado efectivamente al proceso que se está utilizando actualmente. Es decir, en este momento es complicado ver qué cambios se introdujeron en el proceso hace tres semestres, y por tanto es complicado evaluara (a) si realmente se hizo en algún momento lo que se dijo que se iba a hacer; (b) si hay razones justificadas para haber dejado de hacer algunas cosas; (c) si lo que se está haciendo actualmente sí responde realmente a los problemas que se han encontrado en el pasado.

2. Objetivos

2.1. Objetivo general Definir un proceso que sirva como apoyo a la formalización, administración y control de versiones de los procesos de software del grupo QualDev.

2.2. Objetivos específicos

• Definir un estándar para realizar la especificación de los procesos usando SPEM.

• Definir un proceso para realizar mejoras al proceso de manera iterativa usando solicitudes de cambio.

3. Generalidades del Proceso de Administración de Procesos (PAP)

El proceso QualDev está formado por varios procesos. Se tienen especificaciones para procesos como desarrollo, planeación y soporte. El PAP que define este trabajo tiene como fin ofrecer dos subprocesos para resolver los problemas mencionados en la introducción. El primero, la especificación formal de los procesos (EFP), y el segundo, el manejo de solicitudes de cambios de los procesos definidos (SCP).

Como formalismo para realizar estas especificaciones usamos SPEM (Software Process Especification Metamodel).

Los siguientes capítulos están organizados de la siguiente forma:

Capítulo 4 - Modelaje de Procesos Usando SPEM: Da las definiciones y algunos ejemplos del meta-modelo SPEM que son útiles para las definiciones de los demás procesos.

Capítulo 5 - Proceso de Especificación Formal de Procesos (EFP)

Capítulo 6 - Proceso de Solicitudes de Cambio de Procesos (SCP)

4. Modelaje de Procesos Usando SPEM

SPEM –Software Process Engineering Metamodel -es la especificación proveída por OMG para tratar de lograr la estandarización de procesos de desarrollo de software. Toda la sección cuatro se basa en el documento de definición de SPEM de la OMG [3]

4.1. Descripción general Este meta-modelo es utilizado para describir procesos de desarrollo de software y sus componentes, manejando un esquema basado en objetos y estructurado como un profile de UML 1.4.

Un proceso de desarrollo de software en SPEM es la interacción entre entidades abstractas llamadas process roles que ejecutan activities, que a su vez ejecutan operaciones concretas sobre elementos tangibles llamados work products. Los process roles interactúan entre sí intercambiando work products e iniciando la ejecución de actividades. El objetivo de un proceso es que mediante las relaciones que se presentan entre los roles y las actividades, y el orden en que estas actividades son desarrolladas o ejecutadas, se alcancen los objetivos planteados para el proceso. [4]

Los elementos que componen a SPEM pueden ser divididos en tres grupos debido a su funcionalidad y a cómo definen los elementos del proceso. Estos grupos son: estructura del proceso, componentes del proceso y ciclo de vida del proceso.

Una aplicación de SPEM que hace un ejemplo detallado se puede encontrar en [5].

4.2. Estructura del proceso

4.2.1. WorkProduct y WorkProductKind Un workProduct se conoce como cualquier artefacto que es producido durante la ejecución de un proceso, puede ser un documento, un diagrama, una clase, etc. De acuerdo a la necesidad de agrupar los workProducts, se posee la entidad obligatoria de workProductKind, la cual los organiza de acuerdo a las necesidades del proceso modelado. Un ejemplo de workProductKind puede ser Documento, Diagrama UML, o Clase.

Un workProduct puede estar relacionado con otros workProducts utilizando la agregación de UML, que representa que ese workProduct esta constituido como un conjunto de los demás. También puede estar relacionado con un responsibleRole quien es el encargado de representar el rol que es responsable de producir dicho workProduct. Otra de las relaciones que lo caracteriza es impacts, la cual sirve para indicar que la modificación de un workProduct podría invalidar a otro workProduct. La dependencia precedes da relaciones de comienzo-fin, y fin-fin.

4.2.2. WorkDefinition y ActivityParameter WorkDefinition representa el trabajo que es realizado en un proceso, y está relacionando a los workProducts que necesita como entrada o como salida a través de la clase activityParameter.

4.2.3. Activity y Step WorkDefinition tiene dos subclases, la principal de esas es activity la cual es utilizada para describir las tareas que son ejecutadas en un proceso por un rol –processRole– especifico. Para las actividades también es necesario definir las entradas y las salidas –workProduct- de la misma manera que son definidas para workDefiniton. De igual manera, un processRole es dueño de una activity o puede ser simplemente un asistente a la actividad. De manera similar con los workProducts, activity tiene la dependencia precedes la cual provee relaciones de comienzo-fin y fin-fin.

La otra de las subclases es Step, que representa los elementos que componen una actividad, por eso hereda de ActionState para que sea posible representar el flujo de Steps dentro de una activity.

4.2.4. ProcessPerformer y ProcessRole ProcessPerformer define el rol que va a ser responsable de ejecutar unos workDefinitions dentro de un proceso. ProcessRole es una subclase de processPerformer. El processRole puede tener responsabilidades específicas sobre workProducts y sobre activities.

4.3. Componentes del proceso Estas entidades funcionan como contenedores. Dividen los componentes del proceso para que puedan ser colocadas bajo un manejo de versiones y de configuraciones.

4.3.1. ProcessComponent Un processComponent es un fragmento de un proceso, pero que internamente es consistente, además al ser utilizado junto con otros processComponents puede estructurar procesos completos. Una de las características que definen un processComponent, es que no debe tener dependencias o asociaciones a elementos que se encuentran fuera de este componente. Un proceso -process- esta definido de la misma manera que un processComponent, pero con la diferencia que se debe sustentar solo, es decir, que en su definición no esta dispuesto que interactué con otros processComponents.

4.3.2. Package

Un package, al igual que en UML, es un contenedor que puede importar o ser dueño de elementos que definen el proceso. También puede ser utilizado para categorizar elementos creando packages para cada categoría y los elementos del paquete son relacionados con la dependencia categorizes para representar su pertenencia. Una de las dependencia que lo caracteriza es import la cual denota que el contenido de un package será agregado a otro package.

4.3.3. Discipline Una Discipline es una categorización especial de Package, ya que divide las actividades y todos los elementos asociados a ellas de acuerdo a un “tema” común.

4.4. Ciclo de vida del proceso Gracias a estas entidades es posible guiar el proceso, precisando la manera en que las actividades serán ejecutadas. Son utilizadas para asistir con la planeación, ejecución, y monitoreo del proceso.

Para esta sección se utilizará un mismo ejemplo para estas entidades, ya que hay que denotar una jerarquía que es más sencilla de ver si se comparan entre si.

4.4.1. Phase Una phase es una operación que representa el trabajo realizado en el proceso. Es una especialización de workDefinition, la cual tiene criterios de entrada, preconditions, y criterios de salida, milestones. Las phases se definen también con restricciones de secuenciación, ya que al ejecutar los procesos se le asignan fechas a los milestones y generalmente no hay superposición de actividades.

4.4.2. Lifycicle La manera como se definen una secuencia de phases para alcanzar un objetivo especifico.

4.4.3. Iteration Una iteration es un workDefinition compuesto que representa un conjunto de actividades que se focalizan su ejecución, ya que busca cumplir con un milestone para dar lugar a un producto.

4.4.4. Precondition and Goal A cada WorkDefinition se le pueden asociar restricciones (expresiones booleanas) que tienen que ser cumplidas para que pueda ser ejecutado o terminado. Estas dos restricciones se conocen como Preconditions y Goals, las cuales son definidas en strings.

4.4.5. Ejemplo del Ciclo de Vida del Proceso.

La cual correspondería con la siguiente jerarquía de elementos del ciclo de vida:

− Lifecycle

o Phase

Iteration

• Activity

o Step

Lo importante a tener en cuenta, es que todas estas entidades son especializaciones de workDefinition.

Entre más abajo en la jerarquía, los entregables son más pequeños y el tiempo para ejecutarlos también es menor.

4.5. Notación

En esta sección se tratara la notación que la OMG ha propuesto, tanto para las instancias de algunas de las entidades definidas por SPEM, como para la funcionalidad que se les da a los diferentes diagramas que provee UML.

4.5.1. Iconos propuestos Los siguientes iconos fueron propuestos por la OMG para las diferentes entidades1.

Estereotipo

Notación E.A.

WorkProduct

WorkDefinition

Guiadence

Activity

ProcessPerformer

ProcessRole

ProcessPackage

1 Documento ptc/2002-05-08

Phase

Process

Document

UML Model

Tabla 1 - Iconos propuestos por la OMG

4.6. Diagramas de clases

Los diagramas de clases permiten la representación de varios aspectos del proceso, entre ellos están la herencia, dependencias, asociaciones simples, relaciones entre processPerformers o processRole con workProduct,y dependencias o descomposiciones de workproducts. Pero no es posible utilizar todas las entidades que ofrece UML, ya que SPEM ofrece restricciones de uso sobre las interfaces, templates, diamantes blancos, y asociaciones múltiples (n-arias).

Ilustración 1 - Diagrama de clases usando los iconos SPEM

4.7. Diagramas de paquetes

Los diagramas de paquetes representan process, processComponents, processPackages, y Disciplines.

Ilustración 2 - Diagrama de Paquetes usando los iconos SPEM

4.8. Diagramas de actividad

Permiten la representación de la secuencia de actividades con sus workProducts de entrada y de salida, y también permiten la representación de estados de flujo de los objetos. La utilización de swimlanes para denotar responsabilidades también es una característica de este diagrama.

Ilustración 3 - Diagrama de actividad usando iconos SPEM

4.9. Diagramas de casos de uso

Los diagramas de uso son útiles para representar relaciones entre processRoles y las definiciones de trabajo –workDefinitions-.

Para los roles que ayudan en la ejecución de una actividad se utiliza la relación <<assist>>, para los responsables se utiliza <<perform>>.

Ilustración 4 - Diagrama de casos de uso utilizando iconos SPEM

5. Proceso de Especificación Formal de Procesos (EFP)

5.1. Roles de este proceso En esta sección se establecerán los roles que intervienen en este proceso.

5.1.1. Líder de Proceso Este es un rol sugerido para responsabilizarse de llevar satisfactoriamente a término el proceso de especificación formal de procesos. La persona encargada de este rol, deberá tener conocimiento de los procesos ya especificados, de esta manera no se harán definiciones de procesos que existan o se descartara que las necesidades del nuevo proceso puedan ser satisfechas con alguna definición existente. Esta persona también debe tener conocimiento de SPEM, ya que los documentos de especificación formal del proceso se harán utilizando este meta-modelo.

5.1.2. Comité de Diseño de Proceso Este comité se reunirá cuando sea necesario especificar un nuevo proceso o cuando sea necesario hacer un cambio significativo en uno existente. Sugerimos que los integrantes de este comité sean el líder de proceso, y los líderes del proceso que se quiera crear o modificar, por ejemplo, si los cambios se quieren hacer sobre el proceso de planeación, los líderes de planeación de los grupos harán parte del comité.

5.2. Descripciones de los productos de trabajo Cada proceso tiene descripciones propias de esos productos de trabajo, como plantillas y formatos, y otra serie de documentos de especificación de proceso. Estos documentos corresponden, por lo general, a uno de los siguientes tipos:

Documentos de definición (DEF): Estos documentos son los que describen en términos generales el proceso. Pueden ser documentos de texto, o en nuestro caso, diagramas de SPEM.

Plantillas (PLANT): Muchos de los proceso están soportados en plantillas.

Listas de Chequeo (LSTCHK): Procesos como diseño e implementación tienen listas de chequeo para verificar que los demás productos de trabajo cumplan las exigencias de calidad.

Herramientas de Soporte (HERRA): Cuando hay herramientas que soportan un proceso, y que son desarrolladas internamente (como las herramientas de planeación) estas también deben estar bajo administración de configuraciones.

Tutoriales (TUT): Para usar las herramientas de soporte, o para hacer alguna tarea en especial en un proceso pueden existir tutoriales que también deben ser administrables.

En SPEM, estos tipos pueden ser vistos como workProductKinds. Estos documentos van a quedar incluidos en la administración de configuraciones. Entre paréntesis aparece un identificador que permitirá hacer referencia a ellos de acuerdo al esquema de identificación.

Entre los documentos de definición debe estar el diagrama de actividades SPEM obligatoriamente. Este documento garantiza la unidad en el proceso, pues en el se referencia cómo interactúan los demás productos de trabajo.

5.3. Actividades del proceso A continuación se realiza la especificación de las tareas de este proceso.

5.3.1. Formación del Comité de Diseño del Proceso La formación del comité de diseño del proceso es una de las actividades más importantes de este proceso, ya que estas personas son las encargadas de hacer la definición del proceso y la creación de todos los productos de trabajo necesarios para que la especificación sea clara y completa. Se aconseja que sean las personas más relevantes al nuevo proceso, como son los líderes del proceso a definir, o en su defecto las personas más experimentadas del grupo.

El líder de proceso debe hacer parte de este comité, ya que este rol es el más experimentado en la especificación de SPEM, y la descripción formal del nuevo proceso se hace utilizando este meta-modelo.

5.3.2. Documento de Especificación del Proceso Una de las primeras actividades que debe realizar el comité, es un documento donde se consigne todo lo concerniente al proceso. Este documento no es una especificación formal del proceso, pero si un borrador donde se consignaran las ideas principales del nuevo proceso.

5.3.3. Definición de documentos de apoyo a la definición del proceso Esta no es una sola fase, sino son realmente seis fases donde se define un tipo diferente de documento. La responsabilidad de concebir estos documentos recaerá en los miembros del comité de diseño de proceso.

Las seis fases están divididas de acuerdo al producto de trabajo que se realicen.

• Documento de definición del Proceso

• EFP_PLANT_HERRA

• Listas de chequeo

• Plantillas

• Definición SPEM

• Tutoriales

5.3.4. Administración de configuraciones con Changeset2

La administración de configuraciones se realiza sobre ítems de configuración, los ítems de configuración son los productos básicos de trabajo que van a ser sometidos a la administración. Cada ítem de configuración puede tener versiones, siendo cada versión un archivo específico. Cada versión, además, tiene un estado asociado que permite ver la evolución de un ítem. Una línea de base (baseline), además, es un conjunto de ítems de configuración.

Changeset sirve como herramienta de soporte para realizar administración de configuraciones, e inicialmente fue diseñado para realizar esta tarea principalmente sobre productos de trabajo de software. Sin embargo, en las siguientes secciones mostramos cómo es posible usar la misma herramienta y los mismos conceptos para hacer administración de configuraciones sobre el proceso. En las siguientes secciones nos encargamos de definir cuál sería el procedimiento a seguir para poder hacer esta administración del proceso usando los mismos conceptos y a Changeset como herramienta de soporte.

5.4. El proceso como proyecto Es necesario definir cada proceso como un proyecto dentro de Changeset. Esto con el fin de diferenciarlo de los otros proyectos cuya administración de configuraciones sea soportada por la herramienta, y de esta forma, poder manejar ítems de configuración del proceso independientemente de los demás ítems.

5.5. Ítems de configuración para los procesos La práctica genérica 2.6 hace énfasis en que hay que mantener la integridad de los productos de trabajo del proceso y también sus descripciones. Ejemplos de productos de trabajo son: reportes semanales, actas de reuniones, documentos de requerimientos, documentos de riesgos, etc.

5.5.1. Esquema de identificación Cada proceso puede tener diversos documentos de especificación de varios tipos. Por ejemplo, puede tener tres plantillas y dos tutoriales. Para poder identificar y hacer disponibles estos documentos a los responsables de ejecutar el proceso, es necesario usar un esquema (Scheme en Changeset) que permita identificar claramente el documento de acuerdo al proceso, a su tipo, y a un identificador propio. El esquema, entonces, sería el siguiente:

• Proceso: El ítem corresponde a un proceso en particular, por ejemplo, el proceso de planeación, o el proceso de pruebas. Este campo es el identificador de ese proceso.

2 Esta sección no pretende ser exhaustiva en la explicación de la administración de configuraciones ni el manejo que se hace de ella con la herramienta Changeset. Para esto vease: http://qualdev.uniandes.edu.co

• Tipo de documento: Alguno de los tipos definidos en la sección anterior

• Identificador: Identificador del documento.

Una lista de chequeo de implementación, que pertenezca al proceso de pruebas puede tener el siguiente identificador: TEST_CHKLST_IMP1

5.5.2. Manejo de versiones para los ítems Cada versión de cada ítem de configuración tiene también un identificador que permite ubicarla dentro de un árbol de versiones. Estos identificadores tienen por lo general la siguiente estructura: a.b.c donde a, b y c son números. Una versión derivada de otra debe tener un identificador más grande que su versión predecesora, por ejemplo: 1.2.1 puede ser una versión derivada de 1.2, y esta a su vez de 1.0.

El estándar de la industria para manejar estos números es que el primer número indique la versión mayor, el segundo la menor, y el último la actualización o la revisión. Por ejemplo, cada vez que se haga un cambio estructural importante en un proceso debería haber un cambio en el primer número. El segundo número debería cambiar cuando se introduzcan modificaciones a lo que ya existe, y el último cuando se hagan actualizaciones menores, como correcciones ortográficas o estilísticas a los documentos.

5.5.3. Manejo de estados para los ítems Los ítems de configuración de proceso pueden estar básicamente en dos estados. Cuando un ítem está siendo revisado, debe estar en ‘diseño’. Cuando el ítem está siendo usado como parte de un proceso estable debe estar en ‘implantación’.

5.6. Manejo de líneas de base Cada proceso se especifica con un conjunto de documentos de definición, que son ítems de configuración en Changeset. En este sentido, una versión de un proceso completo (por ejemplo, el proceso de planeación, de pruebas, etc.) puede entenderse como una línea de base (baseline). Las líneas de base son conjuntos de versiones de ítems de configuración. Una versión de un proceso debería incluir las últimas versiones aprobadas de los distintos tipos de ítems. Debe incluir todas las plantillas, los tutoriales, y por supuesto, la definición SPEM que permite ver claramente la dinámica del proceso.

Manejar los distintos procesos como líneas de base tiene como ventaja que soluciona el problema de disponibilidad. Al obtener una línea de base, el integrante obtiene todo lo que necesita para ejecutar un proceso. Esto contribuye a facilitar la evaluación de la adherencia del grupo a los procesos.

6. Proceso de Solicitudes de Cambio de Procesos (SCP)

Una vez se tiene inicializado un proceso como un proyecto sobre Changeset, es decir, una vez se tiene un proceso formalizado bajo una definición en SPEM y se tienen en la

herramienta los ítems de configuración, se puede dar inicio eventualmente al proceso para modificarlo.

6.1. Actividades del proceso Cada integrante de grupo podrá obtener la línea de base aprobada (o algún ítem en particular que le interese), para poder usarlo.

6.1.1. Solicitudes de Cambio de Proceso A medida que avanza el trabajo, el integrante de grupo puede sentirse inconforme con la especificación del proceso, y puede tener ideas para mejorarla. Para este fin, debe realizar una solicitud de cambio de proceso.

El integrante debe identificar de la manera más clara posible cuál es el inconveniente que encuentra en el proceso. Puede decir, por ejemplo, que una lista de chequeo es insuficiente pues le falta incluir algo que se debe revisar, o que alguna plantilla es incompleta por que falta algún campo. Los inconvenientes pueden ser más generales, pues pueden faltar etapas, o artefactos importantes. El integrante también debería mencionar de qué forma cree que es posible mejorar el inconveniente que encuentra, es decir, debe decir en términos generales cuál sería la solución. Por ejemplo, podría necesitarse una nueva herramienta, o una fase de inspecciones, etc. La plantilla para esta solicitud está basada en el formato PIP (Process Improvement Proposal) de TSP [5] es el siguiente:

Qualdev – Propuesta de Mejoramiento de Proceso Identificador de la forma: SCP_TEMP_PMP Nombre: ________________________________ Ciclo: __________________ Rol: ___________________________________ Proyecto: _______________ Documento(s) de definición de proceso involucrados: _______________ ___________________________________________________________________ Descripción del problema: ___________________________________________________________________ ___________________________________________________________________ ___________________________________________________________________ ___________________________________________________________________ Solución propuesta: ___________________________________________________________________ ___________________________________________________________________ ___________________________________________________________________ ___________________________________________________________________

La solicitud de cambio de proceso es, por tanto, una solicitud de cambio en Changeset que tiene como archivo la plantilla.

Los integrantes de grupo deberían tener siempre a la mano una plantilla SCP_TEMP_PMP cuando estén trabajando en cualquier proyecto. Esto con el fin de poder generar solicitudes rápidamente a medida que encuentran defectos en los documentos de descripción.

6.1.2. Revisión y Asignación de las Solicitudes de Cambio El líder de proceso será el encargado de revisar las solicitudes de cambio de proceso, evaluar su pertinencia y asignar un responsable para que las resuelva. En caso de que la actualización sea un cambio menor, la solicitud podría ser responsabilidad de un integrante de grupo cualquiera. En caso de que la solicitud merezca un cambio mayor, debe considerarse que sea resuelta por el comité de proceso. En Changeset, cada vez que se asigna una solicitud de cambio, quien la asigna puede escribir una pequeña descripción. En ella pueden ir comentarios que no incluya el formato de la propuesta de mejoramiento, pero sobre todo, debe ir obligatoriamente el identificador que tendría la nueva versión del ítem que posteriormente debe crear el responsable de resolver la solicitud.

6.1.3. Análisis y Resolución de las Solicitudes de Cambio La persona que esté resolviendo la solicitud debe estudiar la plantilla SCP_TEMP_PMP e intentar resolver el inconveniente. Una vez está resuelta la solicitud, el integrante de grupo debe cerrarla y crear una nueva versión del ítem. El identificador de la nueva versión es dado por el líder de proceso en la descripción de la asignación de la solicitud.

El líder de proceso debe revisar que efectivamente se haya satisfecho la solicitud. En caso de que no, el líder de proceso debe generar una nueva solicitud. Si la solicitud ha sido resuelta satisfactoriamente, el líder de proceso debe evaluar la necesidad de crear una nueva línea de base con la última versión.

7. Conclusiones

Intentamos definir el proceso SCP de manera que se reduzca la carga operativa a los integrantes de grupo. Para esto, tuvimos que aumentar la carga de trabajo en el proceso EFP. En principio, hay que hacer un esfuerzo para inicializar la infraestructura en Changeset que soporta los procesos, pues hay que aprender a diseñar procesos usando SPEM y hay que comprender los conceptos de la administración de configuraciones.

Con respecto a las prácticas genéricas de CMMi, podemos decir que los procesos que definimos, de ser implantados, contribuirían a satisfacerlas de la siguiente manera:

G.P.2.1. Establecer una Política Organizacional: Habría una política organizacional que establecería la formalización y la evolución de los procesos.

G.P.2.3. Proveer Recursos: Los recursos para los procesos estarían disponibles en la herramienta Changeset

G.P.2.4. Asignar Responsabilidades: La formalización en SPEM indicaría claramente quién es responsable de cada tarea en el proceso y de cada producto de trabajo.

G.P.2.6. Administrar configuraciones: Se usaría Changeset para administrar las configuraciones de los procesos:

G.P.3.1. Establecer un proceso definido: Cada proceso seguiría el mismo estándar de definición.

Como trabajo futuro es necesario comenzar a formalizar los procesos existentes.

Glosario SPEM [2] Activity: Un WorkDefinition describiendo lo que ejecuta un ProcessRole. Las actividades son el elemento principal de trabajo. Component: (ver Process Component) Dependency : Una dependencia es una relación especifica al proceso, entre elementos del modelo. Discipline: Una Discipline es un package organizado desde la perspectiva de una de las disciplinas de la ingeniería de software: Configuración, Administración, Análisis y Diseño, etc, Element: (ver Model Element) Guidance: Es un Model Element asociado con los más grandes elementos que definen el proceso, que contienen descripciones adicionales como técnicas, guías y profiles UML, procedimientos, estándares, templates, ejemplos de work products, definiciones, etc. Iteration: Una iteración es una gran work definition que representa un conjunto de actividades enfocándose en una porción del desarrollo del sistema que resulta en un lanzamiento (interno o externo) del producto de software. Model Element: Un elemento que describe un aspecto del proceso de ingeniería de software. Process Role: Un model element que describe los roles, responsabilidades y competencias de un individuo que ejecuta las Activities dentro de un Process, y es responsable de ciertos work products. Phase: Una work definition de alto nivel demarcada por un milestone. Process: Un Process es una completa descripción de un proceso de ingeniera de software, en términos de Process Performers, Process Roles, Work Definitions, Work Products, y Guidance asociados. Process Component : Es una agrupación coherente de model elements del proceso organizados desde un punto ventajoso como una discipline, por ejemplo, pruebas, o la producción de un work product especifico, por ejemplo, el manejo de requerimientos. Process Performer: Un Process Performer es un Model Element que describe el dueño de una Work Definitions. Es utilizado para Work Definitions que no pueden ser asociadas con un Process Roles, como los Life Cycle o una Phase. Step: Un model element fino usado para descomponer actividades. Las actividades son conjuntos parcialmente organizados de Steps. Work Definition: Un Model Element de un proceso que describe la ejecución, operaciones realizadas, y las transformaciones ejecutadas sobre los Work Products por los roles. Activity, Iteration, Phase, and Lifecycle son tipos de work definition. Work Product: Un Work Product es la descripción de un pedazo de información o una entidad física producida o utilizada por las actividades de procesos de ingeniería de software. Ejemplos de work products incluyen modelos, planes, código, ejecutables, documentos, etc.

Ilustración 5 - QualdevProcess

Ilustración 6 - Administración de Procesos

Ilustración 7 - Especificación de un Proceso

Ilustración 8 - Proceso de Solicitudes de Cambio de Procesos

8. Referencias

[1] CMMISM for Systems Engineering/Software Engineering/Integrated Product and Process Development/Supplier Sourcing, Version 1.1, Continuous Representation, consultado el 1 de Mayo de 2006. Tomado de:

http://www.sei.cmu.edu/pub/documents/02.reports/pdf/02tr011.pdf

[2] Object Management Group. Software Process Engineering Metamodel Specification. Version 1.1, formal/05-01-06, consultado el 31 de Agosto de 2005. Tomado de: http://www.OMG.org/docs/formal/05-01-06.pdf

[3] ADELFE: Using SPEM Notation to Unify Agent Engineering Processes and Methodology. IRIT/2003-10-R. Gleizes M., Millan T., Picard G. Tomado de: http://www.irit.fr/ADELFE/DOCS/RapportIrit2003-10-R.pdf. consultado el 5 de Septiembre de 2005

[4] Modelaje de Procesos de Desarrollo de Software. Manuel Andrés Muñoz Lara. Tomado de: http://chie.uniandes.edu.co/~changeset/wiki/doku.php?id=development:research:spem

[5] Humphrey, Watts. Introduction to the Team Software Process. Addison Wesley Professional. 2000.