Gua de Trazabilidad en Proyectos

Document Version No. 1.0 Document Creation: 17/07/2006

Copyright Globant 2006. The information contained in this document is the property of Globant. The contents of the document must not be reproduced or disclosed wholly or in part or used for purposes other than that for which it is supplied without the prior written permission of Globant.

Guia de Trazabilidad en Proyectos

CONTENTS 1. Propsito..........................................................................................1 2. Introduccin......................................................................................1 3. Esquema de Trazabilidad.................................................................2 4. Alternativas de Trazabilidad............................................................5

Globant 2006 All Rights Reserved

Page i of 9

Guia de Trazabilidad en Proyectos

1.

PROPSITO
El propsito de esta gua es asistir a los proyectos en el mantenimiento de la trazabilidad y consistencia de toda la documentacin tcnica. Se describen las ventajas de mantener la trazabilidad y algunos esquemas y mecanismos posibles.

2.

INTRODUCCIN
Todo proyecto debe poder mantener una trazabilidad bidireccional entre los requerimientos del sistema y los distintos componentes que intervienen en todas las etapas del desarrollo (casos de uso, componentes de arquitectura, componentes de diseo, releases, tareas del cronograma, test cases, etc.). Este mecanismo de trazabilidad permite determinar si todos y cada uno de los requerimientos del sistema han sido resueltos adecuadamente dentro de la solucin propuesta. Tambin permite controlar que toda la funcionalidad del sistema actual posee efectivamente un requerimiento inicial que le di origen. De esta manera, el mantenimiento de la trazabilidad durante la vida de un proyecto tiende a garantizar el desarrollo de una solucin compacta, donde no falte ni sobre nada que no est debidamente identificado por el equipo del proyecto. Por otro lado, tambin es una herramienta til a la hora de evaluar el impacto de diferentes pedidos de cambio sobre los requerimientos que van surgiendo en el proyecto. Es decir, ante un cambio en los requerimientos, se busca determinar correctamente como se vern afectados los tiempos y costos del proyecto a partir de la magnitud del impacto en la arquitectura de la solucin, el diseo de los componentes, las tareas asignadas, etc. Otra ventaja a tener en cuenta se produce cuando ingresan nuevas personas al equipo del proyecto. El mantenimiento de la trazabilidad ayuda a lograr una rpida induccin o entendimiento de la solucin que se est construyendo por parte de personas ajenas al proyecto. La trazabilidad se puede mantener tanto vertical como horizontalmente. Por trazabilidad vertical nos referimos por ejemplo a la trazabilidad entre objetos diferentes, por ejemplo requerimientos y casos de uso. Mientras que por trazabilidad horizontal nos referimos a la trazabildad entre objetos de un mismo tipo, por ejemplo la trazabilidad de los requerimientos entre s, o a la trazabilidad de los casos de uso entre s. A nivel vertical, tpicamente se mantiene la trazabilidad entre los siguientes componentes: requerimientos, casos de uso, componentes de arquitectura, componentes de diseo, test cases, tareas del cronograma, releases y pedidos de cambio. La trazabilidad horizontal depende del tipo de componentes, en algunos casos no es necesaria. Las ventajas mencionadas que provee un esquema de trazabilidad pueden resumirse en un aumento en la calidad general del proyecto y el producto. Como desventaja se puede mencionar el overhead necesario para el mantenimiento de esta trazabilidad durante la vida de un proyecto. Como es de esperar, el aumento en la calidad del producto no se consigue sin un costo asociado.

Globant 2006 All Rights Reserved

Page 1 of 9

Guia de Trazabilidad en Proyectos

3.

ESQUEMA DE TRAZABILIDAD
Un tpico esquema de trazabilidad es el que se muestra en el siguiente diagrama:

Tomando a los requerimientos como punto de partida, se van creando y uniendo los dems objetos de manera que siempre se puedan trazear cualquier elemento con un requerimiento original. Mientras esto se respete, el esquema puede ser alterado segn las caractersticas de cada proyecto. Por ejemplo, las tareas del cronograma pueden estar basadas en los casos de uso, los propios requerimientos o inclusive los componentes de diseo. En Globant, toda la trazabilidad se encuentra dividida en los diferentes documentos que se generan durante el desarrollo de un proyecto. De esta forma, se busca que diferentes roles sean los responsables de mantener actualizada una parte de la trazabilidad total. Por ejemplo, el analista funcional ser el responsable de mantener la trazabilidad entre los requerimientos y los casos de uso, el arquitecto ser el responsable de mantener la trazabilidad entre los requerimientos o casos de uso y los componentes de arquitectura, el diseador de testing deber mantener la trazabilidad entre los casos de uso y sus test cases, etc. A continuacin se describe toda la trazabilidad que se mantiene en los proyectos de Globant y quienes son los responsables.

3.1

Requerimientos y Casos de Uso

Origen Destino Casos de Uso Donde se mantiene Existe una tabla en el documento SOR, seccin Especificacin de Requerimientos, columna Use Case ID. Existe una tabla en el Analysis Document, seccin Use Case Realisation, columna Number of requirement satisfied. Cualquier relacin entre requerimientos que se quiera destacar se mencionar en el SOR.

Requerimientos

Casos de Uso

Requerimientos

Requerimientos

Requerimientos

Globant 2006 All Rights Reserved

Page 2 of 9

Guia de Trazabilidad en Proyectos

Casos de Uso

Casos de Uso

Se mencionan en los modelos utilizados en el Analysis Document (del tipo included y extended).

El responsable de mantener esta trazabilidad es el Functional Analyst del proyecto al momento de definir inicialmente los Casos de Uso (durante el anlisis funcional del sistema) y luego ante cualquier cambio que impacte los requerimientos y/o casos de uso. La trazabilidad horizontal, tanto entre casos de uso como entre requerimientos debe definirse durante el anlisis funcional del sistema. En este momento se pueden y deben identificar todas las relaciones horizontales entre requerimientos y entre casos de uso.

3.2

Arquitectura
Origen Destino Componentes de Arquitectura Donde se mantiene Ver Documento de Arquitectura. Se resuelve en la tabla "Componentes de Arquitectura", columna "Responsabilidades". Utilizar la funcin search de ser necesario. Ver Documento de Arquitectura.Se resuelve en la tabla "Componentes de Arquitectura", columna "Responsabilidades". Se describe esta relacin en los diferentes modelos utilizados para describir el funcionamiento de la arquitectura y sus componenetes.

Requerimientos/Casos de Uso

Componentes de Arquitectura Componentes de Arquitectura

Requerimientos/Casos de Uso Componentes de Arquitectura

El responsable de mantener esta trazabilidad es el Architect del proyecto al momento de definir la arquitectura inicial. Luego, deber mantener la trazabilidad ante cambios en los requerimientos/casos de uso o ante cambios en los componentes de arquitectura.

3.3

Diseo
Origen Destino Componentes de Diseo Donde se mantiene Ver Documento de Diseo. Se resuelve en la seccin Trazabilidad. Utilizar una tabla o lista. Utilizar la funcin search de ser necesario. Ver Documento de Diseo. Se resuelve en la seccin Trazabilidad. Utilizar una tabla o lista. Se describe esta relacin en los diferentes modelos utilizados para describir el diseo general del sistema y sus componentes.

Requerimientos/Casos de Uso/Componentes de Arquitectura Componentes de Diseo

Requerimientos/Casos de Uso/Componentes de Arquitectura Componentes de Diseo

Componentes de Diseo

El responsable de mantener esta trazabilidad es el Software Designer del proyecto al momento de definir el diseo de servicios en los Design Documents. Luego, deber mantener la trazabilidad ante cambios en los requerimientos/casos de uso/componentes de arquitectura o ante cambio en los componentes de diseo.

3.4

Test Cases
Origen Destino
Globant 2006 All Rights Reserved

Donde se mantiene
Page 3 of 9

Guia de Trazabilidad en Proyectos

Casos de Uso

Test Cases

Ver template de Test Cases, existe una columna Use Case ID donde se identifica la trazabilidad entre Test Cases y Casos de Uso. Utilizar la funcin search. Ver template de Test Cases, existe una columna Use Case ID donde se identifica la trazabilidad entre Test Cases y Casos de Uso.

Test Cases

Casos de Uso

El responsable de mantener esta trazabilidad es el QC Analyst del proyecto al momento de disear los Test Cases. Luego deber mantener la trazabilidad ante cambios en los casos de uso o en los mismos test cases. Extra: Tambin es posible identificar la trazabilidad entre los Casos de Uso o Test Cases y los Bugs encontrados. Ver template de Test Cases, existe una columna Bug # donde se resuelve esta trazabilidad.

3.5

Tareas del Cronograma

Origen Destino Tareas del Cronograma Donde se mantiene Se utiliza la columna Origen del cronograma, mediante un search se puede soportar esta trazabilidad. En su defecto, existe una tabla en el documento SOR, seccin Especificacin de Requerimientos, columna WBS. Tambin existe una tabla en el Analysis Document, seccin Use Case Realisation, columna ID Task. Si esta trazabilidad se identifica correctamente en el cronograma, no es necesario completar las tablas en los documentos.

Requerimientos/Cases de Uso/Componenetes

Tareas del Cronograma

Requerimientos/Cases de Uso/Componenetes

Se utiliza la columna Origen del cronograma.

El responsable de mantener esta trazabilidad es el Project Manager del proyecto durante el desarrollo del proyecto. Esta trazabilidad podr identificarse gradualmente a medida que se vayan definiendo las tareas que involucran especficamente a los distintos requerimientos/casos de uso/componentes. Ante cambios en las tareas, requerimientos, etc., el Project Manager deber mantener la trazabilidad.

3.6

Cdigo
Origen Destino Cdigo/Release Requerimientos/Casos de Uso Donde se mantiene Se puede identificar a travs del cronograma y la bitcora de releases del proyecto. Se puede identificar a travs del cronograma y la bitcora de releases del proyecto. Sino se puede identificar en las respectivas Release Notes.

Requerimientos/Casos de Uso Cdigo/Release

El responsable de mantener esta trazabilidad es el Configuration Manager del proyecto o Team Member encargado de elaborar las Release Notes. Esto ocurre al momento de generar las
Globant 2006 All Rights Reserved

Page 4 of 9

Guia de Trazabilidad en Proyectos

Release Notes, cuando se detalla exactamente la funcionalidad que se incluye en el Build/Release.

3.7

Pedidos de Cambio
Origen Destino Producto/Documento afectado Pedido de Cambio Donde se mantiene Se resuelve dentro de la herramienta de issue tracking, donde se especifica el alcance de los cambios. Se puede verificar en el log de CVS/SVN. Sino se puede consultar en la herramienta de issue tracking.

Pedido de Cambio

Producto/Documento afectado

El responsable de mantener esta trazabilidad es el Team Member del proyecto que haya ingresado la solicitud o se vea afectado en la resolucin de la misma. Esto ocurre cuando se ingresa el pedido de cambio en la herramienta, en este momento se debe detallar que producto se ve afectado directamente. Luego de un anlisis de impacto, se pueden detallar otros productos afectados. Finalmente, al momento de cierre del pedido de cambio, se puede detallar en que versiones se resolvieron los ajustes. El equipo de proyecto debe indicar brevemente el o los cambios que se realicen sobre los productos utilizando el commit log del SVN (o similar para otras herramientas de versionado).

4.

ALTERNATIVAS DE TRAZABILIDAD
Existen otros mtodos/alternativas posibles para mantener la trazabilidad dentro de un proyecto de desarrollo de software. Idealmente, lo mejor es aprovechar las ventajas de algunas herramientas de modelado como el Enterprise Architect (EA) donde es posible definir dentro del proyecto los requerimientos, casos de uso, componentes de arquitectura & diseo, test cases, etc. Luego, a medida que se van definiendo nuevos objetos, se puede ir indicando grficamente la trazabilidad existente con los dems objetos del modelo (vertical y horizontal). Esta herramienta, adems de permitir definir y consultar grficamente todas las relaciones que existen entre los objetos modelados, posee la opcin de mostrar/imprimir una Matriz de Trazabilidad o Relationship Matrix actualizada. De no contar con una herramienta como el EA, tambin es posible elaborar directamente una matriz de trazabilidad nica para todo el proyecto. La misma se puede definir en excel o word y existen varios ejemplos en Internet. Tpicamante consisten en un conjunto de tablas donde los objetos origen se define en las filas y los objetos destino en las columnas. Luego, marcando las celdas correctas, se identifica que objetos estn relacionados entre s. Se pueden utilizar distintas solapas para identificar la trazabilidad entre diferentes objetos. Otra posibilidad incluye la generacin de una base de datos nica donde registrar todos los objetos que son traceados entre s. Esta opcin facilita las busquedas a travs de queries pero, al igual que la matriz en excel o word, implica que todos los roles del proyecto debern ingresar a esta base de datos para mantener la trazabilidad ah. Esta opcin tiene el costo agregado de tener que desarrollar la aplicacin.

Globant 2006 All Rights Reserved

Page 5 of 9