Análisis de Impacto Basado en Información de Trazabilidad y Decisiones de Diseño

ANÁLISIS DE IMPACTO BASADO
EN INFORMACIÓN DE
TRAZABILIDAD Y DECISIONES
DE DISEÑO
TESIS DE GRADO EN INGENIERÍA EN

INFORMÁTICA
FACULTAD DE INGENIERÍA
UNIVERSIDAD DE BUENOS AIRES
Tesista: Sr. de la Rosa, Martín Ramiro
Tutor: Lic. Pablo Cosso

Análisis de Impacto basado en información de trazabilidad Tesista: Martín de la Rosa
Universidad de Buenos Aires – Facultad de Ingeniería Tutor: Lic. Pablo Cosso
Página 2
Agradecimientos
El presente trabajo simboliza una etapa importante de mi vida y materializa

todo el esfuerzo realizado para alcanzar la profesión por la que tanta vocación
siento. Todo esto no hubiera sido posible sin la ayuda de las personas que me
rodean y a las cuales no quiero dejar de agradecer.
A mi familia por inculcarme la importancia de tener una profesión y generar

el desafío personal por alcanzarla. A los profesores que me formaron durante
todos estos años de estudio. A Santiago, Luján y Victor, mis compañeros de
estudio, por las revisiones, aportes de ideas y horas de estudio compartidas. Al
Licenciado Pablo Cosso por el esfuerzo dedicado como tutor de la presente tesis.
Y en especial a Mariela, mi amor, por hacerme saber que puedo contar con ella
para lo que sea.
Página 3
Página 4
Resumen
Estimar el impacto provocado por un cambio determinado a un producto de software, es

una tarea preliminar en el proceso de mantenimiento. Es común que el responsable de
dicha tarea, al intentar predecir el impacto sobre el producto, cuente con pocos o ningún
elemento que facilite su trabajo. Sumado a esto, la falta de conexión o “gap” de
conocimiento existente entre las etapas de un proyecto de software, hacen que el diseño y
desarrollo no responda a las especificaciones funcionales. Se presenta, en este
contexto, un modelo de proceso que permite obtener consistencia en la documentación y
artefactos generados durante el proyecto, y ofrecer elementos de valor para facilitar la
estimación de impacto frente a la implementación de requerimientos de cambio. El
proceso se basa en la documentación de trazabilidad implícita y explícita que pueda
existir entre los diferentes artefactos presentes en cada una de las etapas del proyecto. Se
acompaña al proceso con lineamientos para una correcta clasificación de artefactos y
trazas, exponiendo ejemplos de aplicación sobre conocidas metodologías, como ser RUP
e ICONIX. La automatización de la documentación de trazabilidad es un elemento
diferenciador del resto de trabajos investigados. El trabajo incluye el diseño y desarrollo
de una herramienta para asistir a la ejecución de cada actividad del proceso planteado.
Finalmente se presentan detalles de la puesta en práctica del proceso sobre dos casos
prácticos, ofreciendo los resultados y conclusiones de análisis de impacto.
Palabras claves: análisis de impacto, trazabilidad, requerimiento de cambio,

workproduct, proceso, automatización.
Página 5
Abstract
To consider the impact brought by a change to a software product, is a preliminary task in

the maintenance process. It is common that the person in charge of this task, when trying
to predict the impact on the product, counts on few or no element that facilitates its work.
Added to this, the lack of connection or “gap” between the stages of a software project,
causes that the design and development do not respond to the functional specifications. In
this context, this work establishes a process model to obtain consistency in the
documentation and workproducts generated during the project, and to offer valuable
elements to facilitate the impact analysis of change requirements. The process is based on
the documentation of implicit and explicit traceability that can exist between
workproducts that are present in each one of the stages of the project. The process is
accompanied with guidelines for proper classification of workproducts and traces, giving
examples of application over known methodologies such as RUP and ICONIX. The
automation of the traceability documentation is a differentiator element from the rest of
investigated work. This thesis includes the design and development of a tool to attend the
execution of each activity of the raised process. Finally, details of the put into practice of
the process in two case studies are presented, offering the results and conclusions of
impact analysis.
Key words: impact analysis, traceability, change requirement, workproduct, process,

automation.
Página 6
Contenido
1 INTRODUCCIÓN __________________________________________________________ 11
1.1 GUÍA PARA LA LECTURA DE LA TESIS ___________________________________________ 11

1.2 ÁREAS DE DESENVOLVIMIENTO Y CONOCIMIENTO ________________________________ 13
1.3 PROBLEMÁTICA A RESOLVER __________________________________________________ 14
1.4 INVESTIGACIÓN PREVIA AL TRABAJO ___________________________________________ 15
1.5 MOTIVACIÓN DEL TRABAJO ___________________________________________________ 15
1.6 ALCANCE __________________________________________________________________ 16
1.7 HIPÓTESIS DEL TRABAJO _____________________________________________________ 16
1.8 CRITERIOS DE ÉXITO ________________________________________________________ 17
2 MARCO TEÓRICO – ESTADO DEL ARTE ____________________________________ 19
2.1 TERMINOLOGÍA _____________________________________________________________ 19

2.2 TRAZABILIDAD _____________________________________________________________ 20
2.2.1 LA NECESIDAD DE TRAZABILIDAD __________________________________________ 21
2.2.2 PRE-TRAZABILIDAD VS. POST-TRAZABILIDAD ________________________________ 22
2.2.3 DIMENSIONES DE TRAZABILIDAD ___________________________________________ 24
2.2.4 TRAZABILIDAD IMPLÍCITA BASADA EN DECISIONES DE DISEÑO ____________________ 25
2.2.5 FACTORES QUE INFLUYEN EN LA PRÁCTICA DE TRAZABILIDAD DE REQUERIMIENTOS __ 26
2.3 ANÁLISIS DE IMPACTO _______________________________________________________ 29
2.3.1 DEFINICIÓN – TERMINOLOGÍA RELACIONADA _________________________________ 30
2.3.2 ÁREAS DE ANÁLISIS DE IMPACTO___________________________________________ 31
2.3.3 FACTORES QUE INFLUYEN EN LA PRÁCTICA DE ANÁLISIS DE IMPACTO ______________ 32
2.3.4 CLASIFICACIÓN DE WORKPRODUCTS LUEGO DE IMPLEMENTAR UN CAMBIO __________ 33
2.3.5 FRAMEWORK PARA LA COMPARACIÓN DE ENFOQUES DE ANÁLISIS DE IMPACTO ______ 34
2.3.6 PROCESO DE AI _________________________________________________________ 42
2.4 MÉTRICAS _________________________________________________________________ 44
2.4.1 IN-DEGREE / OUT-DEGREE ________________________________________________ 44
2.4.2 RIPPLE ________________________________________________________________ 45
2.5 METODOLOGÍAS - HERRAMIENTAS DE SOPORTE __________________________________ 46
2.5.1 TRAZABILIDAD EN ANÁLISIS_______________________________________________ 46
2.5.2 TRAZABILIDAD EN CÓDIGO ________________________________________________ 47
3 PROCESO AIT - ANÁLISIS DE IMPACTO BASADO EN TRAZABILIDAD ________ 49
3.1 DIAGRAMA DEL PROCESO ____________________________________________________ 50

3.2 ESPECIFICACIÓN DEL PROCESO ________________________________________________ 51
3.2.1 CATÁLOGO DE AGENTES, PRODUCTOS Y ACTIVIDADES _________________________ 51
3.2.2 ACTIVIDAD 1 – CONFIGURACIÓN DE TRAZABILIDAD ____________________________ 53
3.2.3 ACTIVIDAD 2 – DEFINICIÓN DE EXTRACTORES ________________________________ 55
3.2.4 ACTIVIDAD 3 – TRASPASO DE CONOCIMIENTO _________________________________ 57
3.2.5 ACTIVIDAD 4 – IDENTIFICACIÓN ___________________________________________ 59
3.2.6 ACTIVIDAD 5 – REVISIÓN _________________________________________________ 61
3.2.7 ACTIVIDAD 6 – ANÁLISIS DE IMPACTO ______________________________________ 63
3.3 ARQUITECTURA _____________________________________________________________ 65
Página 7
4 AIT – CONFIGURACIÓN DE TRAZABILIDAD ________________________________ 67
4.1 CONFIGURACIÓN DE TRAZABILIDAD ____________________________________________ 68

4.1.1 CLASIFICACIÓN DE WORKPRODUCTS _______________________________________ 68
4.1.2 TRAZABILIDAD HORIZONTAL / VERTICAL ___________________________________ 69
4.1.3 ESPECIFICACIÓN DE LA CONFIGURACIÓN DE TRAZABILIDAD _____________________ 70
4.1.4 CONFIGURACIÓN DE TRAZABILIDAD VERTICAL _______________________________ 71
4.1.5 CONFIGURACIÓN DE TRAZABILIDAD HORIZONTAL ____________________________ 78
5 AIT - EXTRACTORES DE TRAZABILIDAD ___________________________________ 81
5.1 SINCRONIZACIÓN DE TRAZABILIDAD AUTOMATIZADA _____________________________ 82

5.2 ETAPA DE ANÁLISIS – ENTERPRISE ARCHITECT EXTRACTOR ________________________ 83
5.2.1 TRAZABILIDAD ENTRE REQUERIMIENTOS ____________________________________ 84
5.2.2 TRAZABILIDAD ENTRE REQUERIMIENTOS Y CASOS DE USO ______________________ 84
5.2.3 TRAZABILIDAD ENTRE CASOS DE USO Y VISTAS ______________________________ 85
5.3 ETAPA IMPLEMENTACIÓN _____________________________________________________ 85
5.3.1 CAPA DE VISTA Y CONTROL – STRUTS EXTRACTOR ___________________________ 86
5.3.2 CAPA CONTROL, MODELO E INFRAESTRUCTURA - JAVA DEPENDENCY EXTRACTOR __ 87
5.3.3 CAPA MODELO E INFRAESTRUCTURA - DOCLET EXTRACTOR ____________________ 87
5.3.4 CAPA INFRAESTRUCTURA – DAO EXTRACTOR _______________________________ 89
5.3.5 CAPA INFRAESTRUCTURA – DB GENERIC EXTRACTOR _________________________ 90
5.3.6 CAPA INFRAESTRUCTURA – ORACLE EXTRACTOR _____________________________ 91
5.4 RESUMEN __________________________________________________________________ 92
6 AIT - ANÁLISIS DE IMPACTO_______________________________________________ 95
6.1 ANÁLISIS DE IMPACTO ITERATIVO ______________________________________________ 95

6.2 CLASIFICACIÓN DEL ENFOQUE _________________________________________________ 97
6.3 ESPECIFICACIÓN DEL CAMBIO _________________________________________________ 99
6.4 ESPECIFICACIÓN DEL RESULTADO DE AI ________________________________________ 99
6.5 CEITWP VS. TWP ___________________________________________________________ 101
6.6 CIRTWP VS. CEITWP _________________________________________________________ 102
6.7 GRÁFICOS DE IMPACTO ______________________________________________________ 102
6.7.1 DISTRIBUCIÓN DEL CEI SEGÚN DISTANCIA DE IMPACTO _______________________ 103
6.7.2 DISTRIBUCIÓN DEL CEI SEGÚN TIPO DE WORKPRODUCT _______________________ 104
6.7.3 CEITWP VS. TWP ______________________________________________________ 105
6.7.4 CEI ACUMULADO POR DISTANCIA ________________________________________ 105
6.7.5 CEITWP VS. CIRTWP ____________________________________________________ 107
7 AIT - HERRAMIENTA DE SOPORTE ________________________________________ 109
7.1 ARQUITECTURA ____________________________________________________________ 110

7.2 CLASES DE DOMINIO ________________________________________________________ 111
7.3 FUNCIONALIDADES _________________________________________________________ 113
7.3.1 VISUALIZACIÓN DE TRAZABILIDAD________________________________________ 113
7.3.2 DOCUMENTACIÓN DE REQUERIMIENTOS DE CAMBIO __________________________ 117
7.3.3 OBTENCIÓN DE GRÁFICOS Y MÉTRICAS _____________________________________ 118
7.3.4 CONSOLIDACIÓN DE INFORMACIÓN DE TRAZABILIDAD ________________________ 118
7.3.5 CONFIGURACIÓN DE TRAZABILIDAD ______________________________________ 119
Página 8
7.3.6 CONFIGURACIÓN DE EXTRACTORES ________________________________________ 119

7.3.7 ANÁLISIS DE IMPACTO ITERATIVO _________________________________________ 119
8 CASO PRÁCTICO I _______________________________________________________ 121
8.1 PARALELISMO CON EL PROCESO RUP _________________________________________ 121

8.2 CONFIGURACIÓN DE TRAZABILIDAD ___________________________________________ 122
8.3 EXTRACTORES DE TRAZABILIDAD _____________________________________________ 124
8.4 TRASPASO DE CONOCIMIENTO AL EQUIPO DE PROYECTO __________________________ 124
8.5 IDENTIFICACIÓN DE TRAZAS Y WORKPRODUCTS _________________________________ 125
8.6 ANÁLISIS DE IMPACTO ______________________________________________________ 126
8.7 CONCLUSIONES ____________________________________________________________ 165
9 CASO PRÁCTICO II _______________________________________________________ 167
9.1 GENERALIDADES DEL PROYECTO _____________________________________________ 167

9.1 CONFIGURACIÓN DE TRAZABILIDAD ___________________________________________ 168
9.2 EXTRACCIÓN DE TRAZABILIDAD ______________________________________________ 170
9.3 IDENTIFICACIÓN DE TRAZAS Y WORKPRODUCTS_________________________________ 171
9.4 ANÁLISIS DE IMPACTO ______________________________________________________ 172
9.5 CONCLUSIONES ____________________________________________________________ 176
9.5.1 CAMBIOS DEL TIPO 1 ___________________________________________________ 176
9.5.2 CAMBIOS DEL TIPO 2 ___________________________________________________ 178
10 CONCLUSIONES – TRABAJO FUTURO _____________________________________ 181
11 ANEXO __________________________________________________________________ 185
11.1 ANEXO I: DETALLES DEL CASO PRÁCTICO I ____________________________________ 185

11.1.1 GENERALIDADES DEL PROYECTO ________________________________________ 185
11.1.2 OBJETIVO DEL PROYECTO ______________________________________________ 186
11.1.3 MÓDULOS DEL SISTEMA ________________________________________________ 187
11.1.4 REQUERIMIENTOS DEL SISTEMA _________________________________________ 187
11.2 ANEXO II: FRAMEWORK PARA PROYECTOS BASADOS EN UML - HERRAMIENTA:
SHARPTRACE___________________________________________________________________ 189
11.3 ANEXO III: TRAZABILIDAD ENRIQUECIDA - HERRAMIENTA: DOORS _______________ 193
11.4 ANEXO IV: ESTRATEGIAS DE TRAZABILIDAD BASADAS EN CASOS DE USO -
HERRAMIENTA: RATIONAL ROSE Y RATIONAL REQUISITEPRO __________________________ 196
11.4.1 SOLAMENTE CASOS DE USO_____________________________________________ 198
11.4.2 CASOS DE USO INDUCIDOS A PARTIR DE LAS FUNCIONALIDADES ________________ 199
11.4.3 EL MODELO DE CASOS DE USO ES UNA INTERPRETACIÓN DE LA ESPECIFICACIÓN DE
REQUERIMIENTOS DE SOFTWARE __________________________________________ 199
11.4.4 SIN CASOS DE USO ____________________________________________________ 200
11.4.5 EL MODELO DE CASOS DE USO DEFINE LAS FUNCIONALIDADES DEL PRODUCTO _____ 201
11.5 ANEXO V: PROCESO RUP ___________________________________________________ 205
11.5.1 MEJORA ITERATIVA ___________________________________________________ 205
11.5.2 FASES DEL CICLO DE VIDA ______________________________________________ 205
11.5.3 ITERACIONES ________________________________________________________ 206
11.5.4 DISCIPLINAS _________________________________________________________ 206
11.6 ANEXO V: PROCESO ICONIX ________________________________________________ 209
Página 9
11.6.1 VENTAJAS QUE ICONIX APORTA AL PROYECTO ____________________________ 211

11.6.2 TEORÍA DEL PROCESO _________________________________________________ 211
11.6.3 ETAPAS DEL PROCESO ________________________________________________ 212
11.7 ANEXO VI: DOMAIN-DRIVEN DESIGN __________________________________________ 221
11.7.1 SEPARACIÓN DEL DOMINIO ____________________________________________ 224
11.8 ANEXO VII: REQUERIMIENTOS ESTRUCTURADOS – HERRAMIENTA: OPTIMAL TRACE _ 227
12 REFERENCIAS ___________________________________________________________ 229
Página 10
1 Introducción
1.1 Guía para la lectura de la tesis
Para facilitar al lector se presenta a continuación una guía de lo

expuesto en cada uno de los capítulos del presente trabajo.
Introducción: en este primer capítulo se ofrece una descripción de

la problemática y su importancia, el carácter de la misma en base a
investigación previa, la motivación que se tuvo en brindar elementos para
resolverla, las hipótesis a seguir y finalmente los criterios de éxito.
Marco Teórico - Estado del Arte: este capítulo refleja la

información recogida que se utilizó para establecer la situación de los
trabajos de investigación y desarrollo sobre el área particular en la que se
plantea y relaciona la problemática analizada. A partir de citas
bibliográficas se establecen los siguientes puntos:
• La terminología utilizada en el estado del arte.
• Definición de trazabilidad y análisis de impacto, conceptos a ser

manejados durante todo el trabajo como parte de la solución
Página 11
propuesta. Además, se cubren los aspectos principales de cada

metodología.
• Factores que influyen tanto para la práctica de trazabilidad como

de análisis de impacto.
• Métricas halladas para la evaluación de enfoques de análisis de

impacto. Estas serán puestas en práctica en la solución
propuesta.
• Metodologías y herramientas relacionadas con la tesis.
Proceso AIT - Análisis de Impacto basado en trazabilidad: en

este capítulo se presenta la especificación del proceso AIT, siendo el
marco central de la solución propuesta a la problemática planteada. Cada
una de sus actividades será analizada en detalle en capítulos posteriores.
AIT - Configuración de Trazabilidad: se definen los objetivos de la

actividad "Configuración de Trazabilidad" dentro del proceso AIT y sus
conceptos más importantes:
• Clasificación de los workproducts de un sistema.
• Definición de trazabilidad horizontal y vertical en el marco del

proceso AIT.
• Medio para la especificación de la configuración de trazabilidad

de un proyecto.
• Ejemplos de configuraciones de trazabilidad sobre diferentes

metodologías (RUP, ICONIX, Domain-Driven Design,
Requerimientos Estructurados)
AIT - Extractores de Trazabilidad: se explica la importancia de

automatizar la documentación de trazabilidad en un proyecto de software
y se definen a los extractores como elemento diferenciador respecto a
otros enfoques. A modo de ejemplo se presentan implementaciones de
extractores para dar una idea exhaustiva al lector de la puesta en práctica
y alcance de los mismos.
Página 12
AIT - Análisis de Impacto: capítulo focalizado en la actividad de

análisis de impacto, especificando los siguientes puntos:
• La manera de llevarla adelante.
• Templates para la especificación de requerimientos de cambio y

resultados de análisis de impacto.
• Caracterización de cada uno de sus atributos en base a una

publicación investigada y presentada en el capítulo de estado del
arte.
• Métricas y gráficos para la medición y toma de decisiones sobre

los resultados obtenidos.
AIT - Herramienta de Soporte: se presenta a ImpactTrace, una

herramienta diseñada y desarrollada para dar soporte al proceso AIT. Sus
funcionalidades surgieron en base a comparación con otras herramientas
investigadas y a lo que los casos prácticos indicaron como necesario para
llegar a resultados correctos. Se define su arquitectura y diseño, y se
caracteriza cada una de sus funcionalidades en base a la teoría
presentada en capítulos anteriores.
Caso Práctico I y II: estos capítulos ofrecen al lector ejemplos

prácticos de la ejecución del proceso AIT durante dos proyectos de
software. Se realizan y especifican diferentes requerimientos de cambio
con sus respectivos análisis de impacto concluyendo sobre la eficiencia
del enfoque presentado.
1.2 Áreas de desenvolvimiento y conocimiento
Entiendo que la introducción de este trabajo debe incluir una

descripción resumida de mis áreas de desenvolvimiento y conocimiento
con la finalidad de ofrecer al lector un panorama de mis intereses dentro
de la Ingeniería de Software.
Durante la cursada de la carrera de grado de Ingeniería en

Informática y elaboración del presente trabajo, he atravesado por diversas
Página 13
experiencias laborales. En las mismas me desarrollé en actividades

relacionadas al área de “Desarrollo de Software” o comúnmente hoy en
día denominada “Software Factory”, participando en grupos
multidisciplinarios de diversos proyectos con roles de desarrollador y
arquitecto técnico.
En cuanto a tareas de desarrollo, he trabajado tanto sobre

arquitecturas Cliente-Servidor como arquitecturas Web, haciendo uso de
diversos lenguajes de programación como ser: c, c++, c#, .ASP, .Net y
fundamentalmente Java en los últimos cuatro años.
En tareas de diseño o arquitectura, mis tareas principales podrían

resumirse en:
- el análisis y planteo de arquitecturas viables,
- selección de frameworks para la propia construcción,
- elaboración de documentación UML, y
- desarrollo de componentes de base.
1.3 Problemática a resolver
Durante mi desenvolvimiento y experiencia laboral, he detectado dos

falencias que resumen la problemática y causa principal del presente
trabajo.
La primera falencia detectada es la falta de conexión o “gap” de

conocimiento existente entre las etapas de análisis, diseño y
desarrollo de un proyecto de software. Es común encontrar análisis y
especificaciones funcionales de sistemas que no responden a la
arquitectura, diseño y tecnología utilizada, así como también fragmentos
de código que no implementan requerimientos documentados.
La segunda falencia hallada podría resumirse en la falta de

herramientas, conocimiento y metodologías que poseen los
encargados del mantenimiento al momento de estimar el impacto
sobre el proyecto, producto de la implementación de un
Página 14
requerimiento de cambio. Estimar el impacto provocado por un cambio

determinado a un software, es una tarea preliminar en el proceso de
mantenimiento. Es común que el encargado del mantenimiento al intentar
predecir el impacto sobre el software se encuentre con pocos, o en
ocasiones, ningún elemento que facilite su tarea. Por lo general se termina
analizando la dependencia a nivel de código existente entre los diferentes
componentes que integran el mismo. Sumado a esto, la alta rotación de
personal que existe hoy en día en empresas de desarrollo de software
hace que el conocimiento propio de la construcción y diseño se pierda,
haciendo aún más difícil dicha tarea.
Esta última falencia entiendo se debe principalmente a dos causas.

La primera es la falta de documentación, que hace más tedioso entender
cómo se ha realizado y actualizado un sistema, aumentando así la
posibilidad de olvidar detalles de diseño y código. La segunda razón, no
menos importante, es que, al implementar un cambio sobre un módulo se
debe tener en consideración la relación entre ese módulo y el resto del
sistema, ya que muchas veces existen relaciones complejas entre los
componentes de software que integran un sistema.
1.4 Investigación previa al Trabajo
Como resultado de la investigación llevada adelante durante la

preparación del ante-proyecto de este trabajo, se encontraron dos
conceptos importantes que serán utilizados para ofrecer una solución a
las falencias que citamos en la sección previa. Ellos son: trazabilidad y
análisis de impacto. Ambos conceptos serán explicados en la sección
2.1; se aconseja su lectura para lograr entender el alcance e hipótesis
propuestos.
1.5 Motivación del Trabajo
En respuesta a la problemática planteada surge como motivación del

trabajo:
Página 15
- que la documentación y artefactos generados durante las

distintas etapas de un proyecto sean consistentes, y
- ofrecer elementos de valor para facilitar la estimación del impacto

y toma de decisiones frente a la implementación de
requerimientos de cambio.
1.6 Alcance
En este contexto, el propósito de este trabajo es proponer un modelo de

proceso que permita administrar documentación efectiva de trazabilidad entre
artefactos de software, con el fin de posibilitar un efectivo análisis de impacto
y, a su vez, mantener consistentes los modelos de análisis, diseño y
desarrollo. De aquí en adelante me referiré a un modelo como el conjunto de
artefactos y documentación que pueda generarse durante una etapa
específica de un proyecto de software.
Además este trabajo persigue la idea de que la efectividad del proceso

está basada en las herramientas sobre cual se ejecute. Por lo tanto el proceso
planteado será acompañado del diseño y desarrollo de una herramienta que
dé soporte al mismo.
1.7 Hipótesis del trabajo
El trabajo estará guiado por la siguiente hipótesis:
Si se mantiene durante el desenvolvimiento de un proyecto de software

documentación adecuada de información de trazabilidad entre los artefactos
que lo integran, esto permitiría:
a) Un análisis de impacto eficiente, en base al cual es posible

realizar estimaciones más acertadas del impacto producto de la
implementación de un requerimiento de cambio.
b) Mantener consistentes los modelos de análisis, diseño y

desarrollo.
Página 16
1.8 Criterios de Éxito
Los resultados del trabajo serán producto de la experimentación del

proceso planteado en dos casos prácticos seleccionados.
Siendo que el proceso está totalmente basado en la trazabilidad que se

pueda definir entre los artefactos de un proyecto de software, definiremos dos
criterios para verificar el éxito del trabajo:
- Un criterio cuantitativo, ofreciendo resultados de diversos análisis de

impacto sobre requerimientos de cambio que se planteen sobre los
casos prácticos seleccionados. Dichas estimaciones de impacto
serán finalmente contrastadas contra el impacto real. Este criterio
dará respuesta al inciso a) de la hipótesis.
- Un criterio cualitativo, dando a conocer la trazabilidad documentada

entre los modelos para responder al inciso b) de la hipótesis.
Página 17
Página 18
2 Marco teórico – Estado del arte
En este capítulo se reflejará la información investigada y utilizada para

establecer la situación actual de los trabajos encontrados sobre el área
particular de la problemática a resolver.
2.1 Terminología
Durante la presente tesis se hará uso de los siguientes términos:
Trazabilidad de requerimientos: se refiere a la habilidad de poder

describir y seguir la vida de un requerimiento en ambas direcciones, hacia
delante y hacia atrás, es decir, a través de su origen y especificación, hasta
su implementación y uso, así como también durante su constante
refinamiento (Gotel & Finkelstein, 1994).
Análisis de Impacto: es la tarea de estimar que será afectado en el

software y documentación relacionada si un cambio propuesto es realizado.
La información resultante puede ser utilizada para planear los cambios,
agruparlos en tipos, tomar decisiones, y rastrear los efectos de los mismos.
Resumiendo, un efectivo análisis de impacto provee visibilidad de los efectos
Página 19
potenciales que puedan surgir antes de que los cambios sean implementados
(Bohner & Arnold, 1996).
Requerimiento de software: capacidad que necesita el usuario para

alcanzar un objetivo u obligación de cierto componente de software para
cumplir con cierto contrato, estándar, especificación o cualquier otra
formalidad impuesta por alguna documentación (Dean & Don, 1999).
Cambio de requerimiento: en este trabajo se entenderá por cambio a

cualquier modificación a un requerimiento existente o al agregado de un
nuevo requerimiento que pueda o no modificar al resto.
Workproduct: representa cualquier componente / artefacto de software

que requiere ser mantenido o creado nuevamente, cuando los componentes
en cuales él se basa sufren cambios.
Stakeholder: cualquier persona que puede verse afectada debido a la

implementación de un nuevo sistema o aplicación.
2.2 Trazabilidad
La vida de un requerimiento de software puede ser documentada desde

su origen, donde es creado debido a la necesidad del cliente, hasta la
implementación de los workproducts que finalmente conforman el producto de
software que lo satisface. Es así que una traza establece una relación entre
dos workproducts (O'Neal, 2003).
El problema de mantener la trazabilidad en un proyecto de desarrollo

puede verse como el problema de mantener las relaciones relevantes entre
los workproducts desarrollados durante el proceso (Wieringa, 1995).
A su vez, estos workproducts pueden variar entre los requerimientos, el

diseño y la implementación.
Página 20
2.2.1 La necesidad de trazabilidad
A continuación se agrupan los beneficios que se pueden obtener a partir

de utilizar información de trazabilidad, según las diferentes necesidades de
los stakeholders involucrados en el desarrollo de software (Ramesh,
Harrington, Rondeau, & Edwards, 1993):
Líder de proyecto: cuando los requerimientos están vinculados con los

workproducts que los satisfacen, entonces:
• Se puede estimar el impacto de un cambio de requerimiento.
• Los conflictos entre requerimientos pueden ser descubiertos con

anterioridad y se pueden evitar demoras en la entrega del
producto.
• Se pueden identificar los requerimientos que no hayan sido

satisfechos por la implementación, y se puede estimar el trabajo
para realizarlos.
Diseñador / Arquitecto: si se registran los diferentes resultados del

diseño, la justificación de dichos resultados, las alternativas consideradas y lo
asumido para la toma de decisiones, junto a enlaces que vinculen los
diferentes requerimientos con el diseño, esto permite:
• Facilitar la verificación de que el diseño satisface los

requerimientos.
• Una visibilidad del impacto sobre el diseño provocado por un

cambio de requerimiento.
• Lograr que un diseñador ajeno al diseño del producto entienda el

porqué de una decisión de diseño.
• Optar por la mejor alternativa de cambio, persiguiendo minimizar

el impacto sobre el diseño actual, reduciendo el esfuerzo final de
implementación.
Página 21
Encargado de Mantenimiento:
• Descubrir dependencias y conflictos entre requerimientos,

logrando estimar el impacto frente a un cambio sobre otros
requerimientos.
• Lograr un mejor entendimiento de todo el sistema, abarcando

todos sus componentes y relaciones de dependencia,
implementando cambios sin degradar el diseño original.
• Estimar el impacto en la implementación debido a un cambio de

requerimientos.
2.2.2 Pre-Trazabilidad vs. Post-Trazabilidad
En el momento de documentar la especificación de requerimientos, la

trazabilidad de los mismos se separa en dos áreas: pre-trazabilidad y post-
trazabilidad. La pre-trazabilizad se basa en la información relacionada con la
generación de un requerimiento, antes de que el mismo sea documentado. En
cambio, la post-trazabilidad relaciona a un requerimiento, una vez
documentado en la especificación, con todos los workproducts que satisfacen
el mismo.
Según la referencia bibliográfica (Gotel & Finkelstein, 1994):
Pre-trazabilidad: se refiere a los aspectos de la vida de un

requerimiento antes de su inclusión en la especificación de requerimientos.
Post-trazabilidad: se refiere a los aspectos de la vida de un

requerimiento que resultan debido a la inclusión del mismo en la
especificación de requerimientos.
La pre-trazabilidad provee un método para documentar la fuente de los

requerimientos, específicamente las necesidades del negocio y decisiones
políticas que llevaron a la creación de los mismos.
Página 22
Especificación de Requerimientos
Stakeholder
Regla de Negocio
Necesidad del
Negocio
Forward to Requirements
Backward from Requirements
La post-trazabilidad, en cambio, ofrece:
• Visibilidad de cómo un requerimiento es satisfecho en el software,

identificando todos los workproducts involucrados.
• Conocer las causas del porque la existencia de un workproduct en

particular, y a que requerimiento responde el mismo.
Especificación de Requerimientos
Documento de
Diseño
Caso de Uso
System
Constraint
Forward from Requirements

Backward to Requirements
Este trabajo hará especial hincapié en la post-trazabilidad como

asistencia fundamental a la actividad de análisis de impacto.
Página 23
2.2.3 Dimensiones de Trazabilidad
Se pueden distinguir diferentes dimensiones de trazabilidad (Bianchi,

Visaggio, & Fasolino, 2000):
La primer dimensión distingue entre trazabilidad horizontal y vertical,

dependiendo de si los ítems relacionados por las trazas pertenecen al mismo
modelo (vertical) o a diferentes (horizontal).
Una segunda dimensión toma en cuenta los tipos de trazas que

relacionan los ítems, pudiendo ser trazas explícitas o implícitas.
Las explícitas se basan en relaciones pre-establecidas de alguna

manera. El usuario es el responsable de señalar las dependencias entre
workproducts, estableciendo las trazas.
Las implícitas son utilizadas cuando no existen trazas explícitas. A

diferencia de las trazas explícitas, las implícitas no requieren de un esfuerzo
para ser documentadas ya que se encuentran en forma intrínseca en el
proyecto.
La técnica “naming trace” describe una manera a través de la cual a

partir de los nombres de entidades se logra trazabilidad entre el diseño y el
código en software orientado a objetos (Fiutem & Antoniol, 1998).
Una traza implícita puede ser derivada en base a conocimiento del

sistema. Surge entonces una tercera dimensión dependiendo de si dicho
conocimiento es estructurado o semántico.
Se habla de conocimiento estructurado cuando las relaciones entre los

workproducts surgen en base a dependencias sintácticas entre los mismos.
Un ejemplo de trazas estructuradas son las herencias y asociaciones entre
clases en programación orientada a objetos.
El conocimiento semántico se basa en el conocimiento del dominio del

sistema y de cómo el mismo fue construido. Básicamente está integrado por
decisiones de diseño tomadas durante el proyecto de construcción del
software. El mismo es más difícil de verificar y obtener. Este tipo de
conocimiento permite definir trazas del tipo cognitivas.
Página 24
En la siguiente tabla, se intenta resumir las diferentes dimensiones de

trazabilidad explicadas:
Dimensión Categorías
D1 Vertical Horizontal
D2 Implícita Explícita
D3 Estructurado Cognitivo
Se le dará suma importancia a lograr automatizar la documentación de

trazabilidad implícita existente en un proyecto.
2.2.4 Trazabilidad implícita basada en decisiones de diseño
Como se mencionó en la sección anterior, las decisiones de diseño

pueden producir conexiones implícitas (trazas cognitivas) entre aquellos
componentes de software, de diseño o código, que no es posible definir trazas
del tipo estructurado.
Se han realizado experimentos cuyos resultados sugieren que si se

registran las decisiones de diseño de manera adecuada, esto permite un
análisis de impacto más eficiente y a una mejora general en la etapa de
mantenimiento de software (Abbattista, Lanubile, Mastelloni, & Visaggio,
1994).
Durante la evolución de un software se toman decisiones de diseño que

con frecuencia no son documentadas. Registrar dichas decisiones es la clave
para reducir la distancia (“gap”) de conocimiento del sistema entre la gente
que lleva a cabo el mantenimiento y la encargada de su desarrollo / diseño. El
concepto de registro de una decisión de diseño puede entenderse como el
conjunto de información que permite el desenvolvimiento de actividades
posteriores a la etapa de desarrollo.
Página 25
Desafortunadamente las decisiones de diseño no son almacenadas o

actualizadas en la documentación final de un sistema. Este tipo de
información es difícil de obtener debido a que por lo general no está
relacionada con el código. Finalmente, la gente encargada del mantenimiento
se ve obligada a realizar exhaustivas inspecciones de código antes de realizar
un cambio, lo que lleva a demoras y por lo tanto a un costo involucrado.
Este trabajo atacará las dificultades y falencias señaladas en la

bibliografía dando especial importancia a la documentación de:
- las decisiones de diseño y,
- la trazabilidad de cada una de ellas con los componentes

de análisis y desarrollo.
2.2.5 Factores que influyen en la práctica de trazabilidad de

requerimientos
Existen diferentes factores que influyen en la actividad de trazabilidad de

requerimientos. Dichos factores son clasificados en organizacionales, técnicos
y ambientales.
(Ramesh B. , 1998), en base a estudios realizados en diferentes

organizaciones distingue claramente dos grupos que llevan a cabo la
actividad de documentar la trazabilidad: un grupo integrado por personas que
simplemente hacen un uso esporádico de la trazabilidad de requerimientos,
generalmente viéndose obligados por cuestiones impuestas por los clientes
(low-end users) y otro en el cual la actividad es parte esencial de los procesos
de Ingeniería de Software para obtener mejoras significativas en la calidad de
los productos (high-end users).
A modo de resumen, a continuación se detallan los conceptos

principales que, según Ramesh, diferencian a los low-end users y high-end
users al momento de practicar la actividad de trazabilidad de requerimientos:
Tipos de trazas: los low-end users no suelen capturar enlaces

cognitivos (cuestiones de diseño por ejemplo), relaciones racionales entre
Página 26
componentes de software o la evolución progresiva de dichos componentes.

En cambio los high-end users emplean esquemas de trazabilidad mucho más
ricos en información, permitiendo un razonamiento acerca del porqué y para
qué de cada traza.
Herramientas de trazabilidad: ambos grupos utilizan herramientas del

tipo CASE para llevar a cabo la actividad. Sin embargo, es común que cada
herramienta se especialice en cierta fase del ciclo de vida de un proyecto (por
ej. DOORS para la Administración de Requerimientos) y que la integración
entre ambas no esté provista comercialmente. Los high-end users se
diferencian en implementar tecnología propia con el fin de reducir el “gap”
entre dichas herramientas.
Contexto organizacional: factores organizaciones producen que, los

low-end users vean a la actividad como una obligación impuesta por los
clientes y sponsors del proyecto para cumplir con cierto estándar. Por otro
lado, los high-end users ven a la trazabilidad como un eslabón fundamental
para alcanzar una mejora en la calidad de sus productos.
Responsables: el mismo equipo de trabajo es el que lleva a cabo la

actividad en organizaciones con high-end users. En cambio, los low-end users
suelen asignar recursos externos al proyecto para la realización de la tarea,
sin prácticas o procesos definidos.
Problemas: los low-end users ven el resultado de la trazabilidad como

documentos para satisfacer al cliente o cumplir cierto estándar. Tienen la
visión de una actividad costosa, sin beneficios tangibles y por lo general en
contra de los objetivos corporativos. Los high-end users toman a la
trazabilidad como un mecanismo para el perfeccionamiento y seguimiento de
todo el proceso de desarrollo.
Objetivos: los high-end users señalan diferentes objetivos a perseguir

mediante la trazabilidad, como ser un mejor entendimiento de todas las
especificaciones de un componente mediante la captura de decisiones de
diseño.
Página 27
Métodos: los métodos utilizados por los low-end users suelen ser
documentos estáticos, como ser matrices de trazabilidad, documentación que
no es actualizada a medida que el desarrollo evoluciona. Los high-end users,
en cambio, poseen metodologías bien definidas para llevar a cabo la
trazabilidad durante todo el ciclo de vida de los proyectos. Logran reconocer
cuándo se pierde trazabilidad vertical, entre un componente en una fase del
ciclo de vida y la siguiente. Reconocen la necesidad de información de
trazabilidad dinámica que refleje el real estado del sistema en cualquier punto
del ciclo de vida del proyecto.
Costo: Mientras los high-end users ven a la trazabilidad como una

inversión que es devuelta a lo largo de todo el ciclo de vida, los low-end users,
lo toman como un overhead al proyecto.
Alcance: las organizaciones poco maduras suelen capturar información

de trazabilidad de manera uniforme para todos los requerimientos. Esto puede
ser llevado a cabo cuando los esquemas de trazabilidad son lo
suficientemente simples como para no representar un costo muy elevado en
cuanto a tiempo se refiera. Los high-end users a menudo reconocen que no
todos los requerimientos son iguales, en términos a su importancia y
significado, con lo cual, mantienen trazabilidad detallada sólo para aquellos
que sean de misión crítica, de manera de mantener los costos bajo control y
obtener beneficios comparables.
Estrategia de implementación: La trazabilidad en organizaciones

maduras suele ser lograda de manera incremental, con un adecuado
entrenamiento y soporte.
Finalidad de la información: los high-end users indican la importancia

de un uso debido de la información de trazabilidad. La misma no debe
utilizarse como elemento para amenazar al personal. Intentar medir la
performance de la actividad en base a la cantidad de información producida
es un enfoque que no debe ser tomado como correcto. Una manera correcta
podría ser contabilizar la cantidad de decisiones de diseño capturadas por un
cierto grupo de personas, una vez que el mismo grupo haya tenido la
Página 28
posibilidad de inspeccionar periódicamente cada uno de las salidas de sus

miembros.
En base a los conceptos tratados por Ramesh, el modelo de proceso

presentado permitirá a las organizaciones ser high-end users de
trazabilidad.
2.3 Análisis de Impacto
A la larga, todo software sufre cambios en su ciclo de vida. Dichos

cambios pueden ser caracterizados por diferentes factores:
• cantidad de líneas de código necesarias para su realización,
• simplicidad o complejidad de implementación,
• importancia o trivialidad según el valor que agreguen al software.
Todos estos factores influyen al esfuerzo necesario para implementar los

cambios.
Realizar cambios al software sin tener una visibilidad de los efectos que
pueden producir, trae como consecuencia:
• pobres o malas estimaciones del esfuerzo necesario,
• atrasos en la liberación de versiones,
• degradación en el diseño del sistema,
• productos poco confiables.
Es real la necesidad de estimar en forma certera el alcance (en tamaño y

complejidad) de los cambios y planear su implementación en forma correcta.
Parecería ser una costumbre en diferentes organizaciones, que los

profesionales responsables de implementar los cambios determinen los
efectos de los mismos, luego de una revisión del código y de la
documentación existente.
El análisis de impacto ofrece un mejor entendimiento de cómo llevar a

cabo la implementación de los cambios, debido a que provee un análisis más
Página 29
detallado de las consecuencias de realizar cambios al software. Las

relaciones entre los componentes de software, incluyendo requerimientos,
diseño, código, material de testing y otra documentación administrativa, son
por lo general implícitas; el análisis de impacto las hace más explícitas.
El principal objetivo del análisis de impacto es identificar los

workproducts del software que serán afectados por cambios propuestos
al mismo.
2.3.1 Definición – Terminología relacionada
En la bibliografía analizada, el Análisis de Impacto (AI) ha sido puesto en

práctica de diferentes maneras. Es más, no se puede encontrar un consenso
frente a la definición de AI.
Una cita bibliográfica (Automated Life Cycle Impact Analysis System,

1986) lo define como “análisis de un impacto para conocer sus partes y/o
elementos”. Mientras que el impacto es definido por “esfuerzo o resultado
debido a un cambio al software”.
(Pfleeger, 1991) define al AI como “la evaluación de diferentes riesgos

asociados con un cambio, incluyendo la estimación de los efectos en los
recursos, esfuerzo y plan de proyecto”.
Este trabajo hará uso de la siguiente definición de Análisis de Impacto:

“El Análisis de Impacto (AI) es la actividad encargada de identificar que
modificar para lograr cierto cambio, e identificar sus consecuencias
potenciales”. En esta definición, se entiende por cambio, a cualquier
modificación o agregado sobre un workproduct que forme parte del software
existente.
Existen otros términos relacionados con AI, que son importantes

conocer. El impacto es una parte del software que ha sido determinada de
ser afectada, y por lo tanto merece cierta inspección posterior a la
implementación del cambio. Un efecto secundario es un “error u otro
comportamiento no deseado que se produce como resultado de una
modificación” (Freedman & Weinberg, 1981). La estabilidad es “la resistencia
Página 30
al potencial efecto-ripple ofrecida por un artefacto de software, cuando este

intenta ser modificado” (Yau & Collofello, 1980).
El efecto-ripple es el “efecto causado por un pequeño cambio a un

sistema que afecta muchas otras partes del mismo” (Stevens, Myers, & L.L.,
1999).
2.3.2 Áreas de Análisis de Impacto
Dentro del análisis de impacto, existen dos áreas principales: análisis

por dependencia (dependency análisis) y análisis por trazabilidad
(traceability análisis). Estas áreas, complementarias entre sí, brindan dos
enfoques con perspectivas diferentes para la realización del análisis de
impacto, cada una con sus potenciales ventajas al momento de identificar el
impacto en el software.
Análisis por dependencia
Basado en relaciones de dependencia entre entidades del programa

(paquetes, clases, métodos, atributos, etc.). Provee una evaluación detallada
de dependencias dentro del código, pero no brinda información acerca de los
workproducts en otros niveles. Por lo tanto, el análisis por dependencia brinda
una perspectiva de análisis de impacto desde el código fuente.
Dentro de este tipo de análisis es posible almacenar tres tipos de

relaciones:
• Dependencias de datos (data dependencies): Existe una

dependencia de datos cuando una sentencia de un programa
provee un valor que es utilizado directa o indirectamente por otra
sentencia del mismo.
• Dependencias de Control (control dependencies): Son

relaciones entre sentencias de código de un programa que
controlan el flujo de ejecución del mismo.
Página 31
• Dependencias de Componentes (component dependencies):

relaciones de dependencia entre componentes de código
(módulos, clases, etc.). Existen diversas técnicas para la
extracción de las mismas: cross-reference, comparadores de
código, etc.
Análisis por trazabilidad
Comprende un análisis de las relaciones de dependencia entre todos los

workproducts que integran el sistema, sin importar a qué nivel pertenezcan,
desde los requerimientos, pasando por el diseño, hasta el código. Brinda una
perspectiva más amplia que el análisis por dependencia, pudiendo relacionar
por ejemplo, workproducts de requerimientos con workproducts del diseño del
software. La desventaja de este análisis es que la dependencia dentro de una
librería / módulo de código es muy poco detallada.
Conclusión
El análisis por dependencia permite un análisis más detallado que el

análisis por trazabilidad, pero se ve limitado a la aplicación en el código
fuente. Típicamente, la falta de información detallada sobre los diferentes
workproducts que integran un sistema limita la eficiencia del análisis por
trazabilidad. Sin embargo, un análisis más exhaustivo de todo el sistema
puede obtenerse si la información de trazabilidad está disponible.
Este trabajo utilizará ambos enfoques de manera de, por un lado lograr
consistencia entre los modelos (análisis por trazabilidad), y por otro,
analizar el impacto dentro del código fuente (análisis por dependencia).
2.3.3 Factores que influyen en la práctica de análisis de impacto
El análisis de impacto, dentro del proceso de cambio al software, resulta

ser una tarea difícil y tediosa de llevar a la práctica. No existen metodologías
estandarizadas y avaladas dentro de la Ingeniería del Software, ni siquiera
suele existir entrenamiento alguno para los ingenieros que la llevan adelante.
Página 32
Depende de la organización y finalmente de sus programadores y analistas, el

enfoque con el que se desarrolle el análisis de impacto.
Otro factor influyente, es la falta de herramientas que permitan una

automatización de la actividad. Por lo general, las herramientas investigadas,
requieren de mucha interacción con el usuario para alcanzar un efectivo
análisis de impacto.
Arnold y Bohnerii señalan que un análisis de impacto automatizado

depende en la capacidad de las herramientas a:
• modelar las relaciones entre los workproducts,
• capturar dichas relaciones en el software y representaciones

asociadas,
• trasladar un cambio específico al software a los workproducts

impactados y sus relaciones.
Por lo tanto, en este trabajo, se dará importancia a estas

características a la hora de crear la herramienta que asista al
análisis de impacto. Se cree que la efectividad de esta actividad, es
consecuencia del soporte que pueda brindar la tecnología.
2.3.4 Clasificación de workproducts luego de implementar un cambio
La mayoría de los métodos de análisis de impacto basados en

trazabilidad, intentan predecir los workproducts que serán afectados debido a
un cambio producido en el producto. Este resultado simboliza al conjunto
estimado de impacto (Ver Sección 2.3.5).
Por lo tanto, los workproducts que no forman parte del conjunto estimado
de impacto, se dicen que no son predecibles de sufrir un cambio. Luego de
implementar el cambio al producto, se puede determinar claramente el
conjunto de workproducts afectados y el conjunto de workproducts no
afectados. Comparando estos resultados con la predicción, se pueden
clasificar a los workproducts en cuatro conjuntos diferentes (Lindvall &
Sandahl, 1998):
Página 33
1. Workproducts modificados y predecidos de ser modificados.
2. Workproducts no modificados y no predecidos de ser modificados.
3. Workproducts modificados y no predecidos de ser modificados.
4. Workproducts no modificados y predecidos de ser modificados.
Tanto en los casos 1) y 2), se puede decir que el análisis de impacto fue
satisfactorio, en cambio, en 3) y en 4) se considera ineficiente.
Todos los
Workproducts
No predecidos y no
modificados
(Correcto)
Predecidos y
no modificados
No predecidos y
modificados
Workproducts
realmente
Modificados (CIR) Workproducts
Predecidos y
predecidos
Modificados
de ser modificados
(Correcto)
(CEI)
2.3.5 Framework para la comparación de enfoques de Análisis de

Impacto
La bibliografía (Arnold & Bohner, 1993) especifica un framework con la

intención de diferenciar diferentes enfoques1 utilizados para el Análisis de
Impacto. Esta framework se basa en tres factores para distinguir los diferentes
enfoques:
1
El término enfoque abarca herramientas, procesos semi-automáticos y procesos manuales.
Página 34
• cómo el enfoque es utilizado para lograr el análisis de impacto (IA

Application)
• cómo el enfoque realiza el análisis de impacto internamente (IA

Parts)
• efectividad del enfoque (IA Effectiveness)
Definiciones utilizadas por los autores del framework
Impacto (impact): es la parte del sistema determinada a ser afectada.
Trazabilidad (traceability): es la habilidad en determinar que partes

están relacionadas con otras en base a relaciones específicas.
Efecto secundario (side effect): es un error o comportamiento no

deseado que ocurre como resultado de una modificación.
Efecto ripple: es el efecto causado al realizar un pequeño cambio al

sistema que termina afectando muchas otras partes del mismo.
Estabilidad (stability): es la resistencia al potencial efecto de ripple,

ofrecida por un sistema al ser modificado.
Aplicación del enfoque (IA Application)
Esta sección del framework examina como el enfoque es utilizado para

llevar adelante el análisis de impacto, es por eso que se basa principalmente
en la distinción de los elementos que hacen a la interfaz usuario-enfoque AI.
Página 35
A continuación se muestra una tabla con los elementos necesarios para

diferenciar enfoques de AI en base a como son aplicados o llevados adelante
por parte del usuario.
IA Application – Elementos diferenciadores
Elemento Explicación Escala
¿Cuáles son los tipos - Componentes de Programa y/o relaciones

de objetos y
- Componentes y/o relaciones de dominio
relaciones extraídos
predefinidas
del dominio del
Modelo de los
sistema? - Componentes y/o relaciones establecidas
artefactos del dominio
por el usuario
- Ninguno
- Desconocido
¿Pueden los - Si, sintaxis y semántica por completo

componentes
- Si, sintaxis con cierta semántica
analizados ser
Descomposición descompuestos y - Si, solo sintaxis
almacenados en la
- No
herramienta / enfoque
de AI? - Desconocido
¿Cómo es el cambio - Si, el cambio se especifica con un análisis

especificado frente al detallado
enfoque de AI?
Especificación de - Si, el cambio se especifica con un simple
cambios análisis
- No, no aplica
- Desconocido
¿Cómo son los - Reporte

resultados del AI
- Exploración (Browsing)
expresados?
Especificación de
- Vista de base de datos
resultados
- Ninguno
- Desconocido
¿Cuánto esfuerzo es - Significante

requerido por el
Interpretación de - Poco
usuario para
resultados interpretar los - Ninguno
resultados del AI?
- Desconocido
¿Qué otras - Explicaciones, métricas, animaciones /

funcionalidades se grafos de impacto, opciones para
encuentran implementar el cambio, acceso a un histórico
Otras funcionalidades
disponibles para el de cambios, estrategias de cambio
usuario? sugeridas, caminos para testear el cambio,
etc.
Página 36
sis de Impacto basado en información de trazabilidad
Análisis Tesista:: Martín de la Rosa
Universidad de Buenos Aires – Facultad de Ingeniería Tutor:: Lic. Pablo Cosso
Partes del enfoque (IA Parts)
Esta parte del framework se preocupa de las partes funcionales

involucradas en el enfoque de AI (que hace el enfoque, como lo hace, y
cuáles son
on las tareas de los agentes / herramientas involucradas).
La figura ilustra los elementos involucrados. Para expresar un cambio

específico, el enfoque de AI posee un modelo propio de objetos y relaciones.
El input, expresado en términos de dicho modelo de
de objetos de interfaz, es
traducido en el modelo de objetos interno al enfoque.
El modelo interno de objetos define los componentes y relaciones (o

dependencias) que el enfoque utiliza. Normalmente suele ser almacenado en
un cierto repositorio (base de datos, CVS, etc.). El repositorio puede poseer
sus propios mecanismos para su carga, exploración, y modificación de los
componentes y relaciones almacenados. A su vez, el repositorio es cargado
descomponiendo los componentes al modelo interno de objetos y relaciones.
El modelo de impacto define reglas que reflejan la semántica acerca de

que afecta que. Define las clases de componentes y relaciones utilizados por
el enfoque, algoritmos y demás fórmulas para determinar cuando un cambio

sobre un artefacto puede alterar a otro.
El componente de trazabilidad / impacto (tracing / impact approach) es el

responsable de implementar el modelo de impacto. Define como los objetos y
dependencias son representados, como las reglas de impacto son
capturadas, especifica los algoritmos de búsqueda de impacto, etc.
Una vez que los resultados de AI son obtenidos del modelo interno de
objetos, deben ser traducidos nuevamente al modelo de objetos de interfaz
entendible por el usuario, con el fin de determinar que partes de los artefactos
originales son impactados.
La siguiente tabla resume los elementos comprendidos en las partes de

un enfoque de AI.
IA Parts – Elementos diferenciadores
¿Qué objetos y relaciones - Strings, objetos de

pueden ser expresados en la programa, objetos
Modelo de objetos de interfaz
interfaz de usuario del predefinidos de documentos,
enfoque? desconocido
- Orientado en documentos,
¿Qué objetos y relaciones basado en objetos, estructura
Modelo interno de objetos
utiliza el enfoque? de grafos, ninguno,
desconocido
¿Cómo son modeladas las

dependencias? ¿Cuándo
- Flujo de datos, control de
estas dependencias son
flujo, matcheo de strings,
Modelo de Impacto tenidas en cuenta? ¿Qué tan
dependencia entre objetos,
bien las dependencias del
ninguno, desconocido
modelo se reflejan con las
del sistema?
¿Qué algoritmos o
procedimientos son - Descomposición, búsquedas
Enfoque de trazas utilizados por el enfoque heurísticas, no explícito,
para calcular el impacto en ninguno, desconocido
base a las trazas?
¿Qué objetos y relaciones

- Entidades de base de datos,
son capturados del sistema y
Descomposición objetos, clases, ninguno,
almacenados internamente
desconocido
en el enfoque?
Página 38
¿Qué repositorio es utilizado - Motor de base de datos

Repositorio para el almacenamiento de relacional, file system,
objetos y relaciones? ninguno, desconocido
¿Qué funcionalidades brinda

el repositorio para la carga, Carga, modificación,
Carga, modificación,
modificación y navegación navegación, todos, ninguno,
navegación
de los elementos desconocido
almacenados en él?
Eficiencia del enfoque (IA Effectiveness)
Esta parte del framework se encarga de conocer que bien el enfoque

implementa el análisis de impacto. Es decir, una vez que se realizó el análisis
de impacto, la pregunta es ¿Qué tan preciso es?
Para responder esta pregunta, se definen ciertos conceptos:
• Universo: conjunto total de artefactos de software (work-

products).
• Sistema: conjunto de artefactos de software que integran el

sistema bajo análisis del enfoque.
• Conjunto de inicio de impacto (CII – CII#): conjunto de

artefactos que son pensados de ser inicialmente modificados por
un cambio.
• Conjunto estimado de impacto (CEI – CEI#): conjunto de

artefactos estimados por el enfoque de AI a ser afectados.
• Conjunto de impacto real (CIR – CIR#): conjunto de artefactos

realmente modificados como resultado de implementar un
cambio. El CIR no es único, ya que un cambio puede ser
implementado de diversas maneras. Igualmente en lo que sigue,
se tomará al CIR en base a un análisis de impacto en particular.
Se asume también que el CIR refleja una implementación correcta
del cambio.
Nota: se hace una distinción entre los artefactos a nivel de interfaz de usuario de la herramienta
de AI (señalados con #), con los artefactos propios del modelo del sistema.
Página 39
Métricas
1) CII# vs. CEI#
Por definición el CEI# siempre contiene al CII#. Sin embargo, el tamaño

del CEI# determina el esfuerzo necesario para chequear todos los objetos
analizados como impactados. Por lo tanto, un CEI# de tamaño considerable
en comparación del CII# no es recomendable para un enfoque de AI.
Por lo tanto la métrica queda definida por:
CII #
CII # vsCEI # = αIE =
CEI #
Resultado Interpretación
αIE = 1 Mejor estimación. Siempre deseado.
K< αIE < 1 Estimación esperada. CEI# es apenas mayor

al CII#.
donde 0 < K < 1
K sugerido 0.7
αIE < K Estimación mala. Salto grande entre CEI# y

CII#. Requiere mayor esfuerzo para chequear
todo el CEI#.
2) CEI# vs. Sistema (SIS#)
En general, no es deseable que el enfoque de AI estime que todo será

impactado, esto es que el CEI# sea igual al Sistema, a no ser que
efectivamente se trate de ese caso. La “distancia” entre el CEI# y el Sistema
es una manera de medir en cierta manera la certeza del enfoque.
La métrica se define como:
CEI #
SIS # vsCEI # = αSE =
SIS #
Página 40
Resultado Interpretación
αSE =1 No útil para un análisis de impacto. Puede

indicar un sistema con efecto de ripple
extremo.
J< αSE <1 Mejor estimación. Se estimó que el cambio

no afecta a todo el sistema.
donde 0 < J < 1
αIE < J Aún mejor. Se estimó que el cambio impacta

solo a una porción reducida del sistema.
3) CEI# vs. CIR#
La relación entre el CEI# y el CIR# también es muy significante. Se

quiere que el CIR# este contenido por el CEI#, y en lo posible ser muy similar
o exacto.
Condición Resultado Interpretación
Lo ideal. Lo estimado como

impactado es igual a lo que
CEI# = CIR#; CIR # realmente se modifica. Si esto
=1
CEI# ⊆ SIS# CEI # ocurre muy frecuentemente,
puede ser una señal de que el AI
no sirva de mucho.
|CEI#| > |CIR#|; CIR# Estimación “segura”. Lo

H< <1 estimado contiene a lo realmente
CIR# ⊂ CEI#; CEI # impactado y además el conjunto
estimado no es mucho mayor al
CEI# ⊆ SIS# donde 0 < H < 1 impactado real.
CIR# Estimación “segura” pero no tan

|CEI#| >> |CIR#|; <H buena. Existe un gran salto entre
CIR# ⊂ CEI#;
CEI # lo impactado realmente y lo
estimado, lo que significa que
CEI# ⊆ SIS# Tomando el H definido hay que chequear bastante al
en la fila anterior CEI para arribar al CIR.
|CIR#| > |CEI#|; CEI # Estimación esperada. El AI es

M< <1 aproximado y se queda corto a lo
CEI# ⊂ CIR#; CIR # que realmente debe ser
CEI# ⊆ SIS# donde 0 < M < 1 modificado.
|CIR#| >> |CEI#|;

CEI # Estimación no muy buena. Gran
<M salto entre lo estimado y lo
CEI# ⊂ CIR#;
CIR # realmente impactado,
Tomando el M definido significando un trabajo extra para
CEI# ⊆ SIS#
en la fila anterior descubrir el CIR.
Página 41
Estimación no muy buena. Se

|CIR# ∩ CEI#|>0; necesita un trabajo extra para
CIR# ≠ CEI#; chequear los objetos del CEI que
|CIR# ∩ CEI#| > 0
no están en el CIR. Ídem para
CEI# ⊆ SIS# descubrir los objetos del CIR que
no están en el CEI.
|CIR# ∩ CEI#|=0; Estimación no muy buena. Una

|CIR# ∩ CEI#| = 0 peor versión del caso presentado
CEI# ⊆ SIS# en la fila anterior.
2.3.6 Proceso de AI
En base a la bibliografía (Bohner & Arnold, An Introduction to Software

Change Impact Analysis, 1996) en esta sección se explica un típico proceso
de Análisis de Impacto.
El usuario solicita una aprobación para la implementación de un cambio

sobre el sistema.
Posteriormente, si se aprueba la implementación del cambio, en base a

la examinación de los requerimientos, documentos de diseño, código, etc. se
identifican los artefactos de software que aparentemente se verán impactados
por el cambio (Conjunto de Inicio de Impacto – CII).
Página 42
Luego, en base a un esquema de relaciones entre los workproducts, se

estiman los workproducts impactados como consecuencia de aplicar el efecto
ripple sobre el conjunto de inicio de impacto. En esta etapa puede que se
identifiquen nuevos workproducts y se agreguen al CII.
El análisis asume que existe una especificación formal de objetos y

relaciones que caracteriza la estructura del impacto del sistema que está
siendo modificado. Esto no es crítico u obligatorio para realizar el análisis de
impacto, pero incrementa su eficiencia y velocidad, más aún si el análisis es
automatizado por alguna herramienta. Si los objetos o relaciones no están
presentes, se pueden utilizar técnicas como ser: inspecciones, walkthroughs,
verificación, validación para lograr el análisis de impacto.
Relación con el Proceso de Administración de Cambios
Bohner y Arnold explican el proceso de Análisis de Impacto bajo el

contexto del proceso de Administración de Cambios del Software.
El Análisis de Impacto ocurre a lo largo de todo el proceso de

Administración de Cambios del Software: a medida que los cambios son
implementados, más impactos son descubiertos, y por lo tanto el conjunto de
workproducts impactados crece. Consecuentemente, a medida que el proceso
progresa, se va conociendo más en detalle el cambio, y por lo tanto el análisis
de impacto se vuelve más concreto y efectivo.
A continuación se enumeran las actividades más importantes referidas al

proceso de cambio del software desde una perspectiva referida al impacto.
Desde esta perspectiva, el análisis de impacto es una tecnología de soporte a
la implementación del cambio.
• Entender el cambio y determinar el impacto: se evalúa la

solicitud de cambio, se clarifica, y se determinan sus posibles
impactos. Esta actividad produce impactos sobre todos los
workproducts del ciclo de vida del proyecto (requerimientos,
diseño, código, casos de prueba). Se descubren efectos de ripple
que alimentan los workproducts impactados.
Página 43
• Especificar y diseñar la implementación del cambio: toma la

solicitud de cambio clarificada y genera especificaciones
detalladas de diseño.
• Implementación del cambio: se implementa el cambio a nivel

código y se actualiza toda la documentación referida a los
workproducts modificados y/o agregados y sus relaciones.
• Testing: las modificaciones son testeadas de manera de validar

que cumplan con los nuevos requerimientos. Además todo el
sistema es sujeto a un testing de regresión para verificar que se
siguen cumpliendo los requerimientos existentes.
2.4 Métricas
En esta sección se detallan ciertas métricas de interés halladas en la

bibliografía.
2.4.1 In-Degree / Out-Degree

XIX
El In-Degree de un determinado workproduct indica la cantidad de
workproducts que dependen del mismo. Puede verse como la cantidad de
trazas que ingresan al workproduct analizado.
Queda definida la siguiente función:
In(n) : Workproduct → ℜ = ∑ T Siendo T = {{b , n} ∈ Traza }
Por otro lado, el Out-Degree indica de cuantos workproducts depende el

workproduct en cuestión. Puede ser visto como la cantidad de trazas salientes
desde el workproduct analizado.
Queda definida la siguiente función:
Out ( n) : Workproduct → ℜ = ∑ T Siendo T = {{ n , b} ∈ Traza }
Página 44
2.4.2 Ripple
XIX
Arnold y Bohner definen al ripple como “el efecto causado al realizar
un pequeño cambio al sistema que termina afectando muchas otras partes del
mismo”.
A modo de cuantificar el ripple que presenta un determinado

workproduct, los autores de la cita tienen en cuenta sus relaciones (trazas) y
las distancias de las mismas.
Así, el ripple para un determinado workproduct puede ser calculado

mediante:

Donde d = distancia,
Idi = Impacto del workproduct para una distancia i
WP1 WP2 WP3 WP4 WP5
WP1 1 1 2 3
WP2 2 1 1 3
WP3 1 3 2 3
WP4 1 2 2 2
WP5 1 2 3 3
En base a la matriz de trazabilidad con indicadores de distancia

presentada, es posible calcular el valor de ripple para los distintos
workproducts. A modo de ejemplo:
Ripplewp1 = 1*2 + 2*1 + 3*1 = 7
Ripplewp2 = 1*2 + 2*1 + 3*1 = 7
Ripplewp3 = 1*1 + 2*1 + 3*2 = 9
Ripplewp4 = 1*1 + 2*3 + 3*0 = 7
Ripplewp5 = 1*1 + 2*1 + 3*2 = 9
Página 45
Se puede concluir que los workproducts WP3 y WP5 presentan mayor

ripple que el resto, indicando posiblemente que frente a una posible decisión
de cambio estos sean menos preferibles de ser modificados que WP1, WP2 y
WP4.
2.5 Metodologías - Herramientas de Soporte
En esta sección se hace referencia a diferentes metodologías,

herramientas y frameworks hallados en la bibliografía. Las mismas se enfocan
en brindar soporte y servir de guía para la documentación de trazabilidad y
hasta la realización de análisis de impacto.
Debido a que no se encontró en la investigación una herramienta que

permita capturar trazas desde un requerimiento hasta componentes de
implementación, se presenta por un lado las herramientas que dan soporte a
la trazabilidad en la etapa de análisis, y por otro a las que asisten a la
documentación de trazas en el código.
Se tomarán en cuenta las características más relevantes de cada una de

las herramientas que se muestren al momento de diseñar la herramienta que
de soporte al enfoque presentado en este trabajo.
2.5.1 Trazabilidad en análisis
Para la documentación de trazabilidad en la etapa de análisis de un

proyecto se encontraron las siguientes metodologías / herramientas, de las
cuales se brinda mayor detalle en los anexos citados del presente trabajo:
• SharpTrace11.2: Framework/Herramienta para la trazabilidad de

requerimientos para proyectos basados en UML.
• DOORS11.3: Permite capturar información de documentos Word y

documentar la semántica de trazas.
• Rational RequisitePro11.4: Herramienta para la documentación de

trazabilidad en proyectos bajo el marco del proceso RUP.
Página 46
11.8
• OptimalTrace : Herramienta que surge de la metodología
Requerimientos Estructurados diseñada por la empresa
Compuware.
2.5.2 Trazabilidad en código
La trazabilidad en el código fuente de un proyecto puede ser vista como

la dependencia existente entre los diferentes componentes que integran el
mismo.
Para el análisis del código fuente y las relaciones implícitas en el mismo

existen herramientas de análisis de dependencia (dependency-analysis tools)
o también denominadas herramientas de referencia cruzada (cross-reference
tools). Estas herramientas permiten extraer dichas relaciones, es decir la
trazabilidad, y generar diferente tipo de información: grafos, reportes de
dependencia, etc.
En esta sección se dará detalle de una herramienta basada en el análisis

de código JAVA llamada Dependency Finder.
Otras herramientas de cross-reference para el análisis de lenguaje Java

que generan como resultado páginas HTML con links para navegar el código
fuente y sus dependencias son: Sorcerer (https://sorcerer.dev.java.net/),
Javasrc (http://sourceforge.net/projects/javasrc/) y Maven JXR
(http://maven.apache.org/jxr/).
Dependency Finder (http://depfind.sourceforge.net)
Se trata de una herramienta que analiza código Java compilado y es

capaz de extraer grafos de dependencia. Esta aplicación puede ser utilizada
de diversas maneras: a través de la lína de comandos, desde una aplicación
Swing, desde una aplicación Web lista para ser instalada en un Servidor Web,
a través de tareas Ant (http://ant.apache.org/), o bien en forma directa
haciendo uso del API de la misma.
En el contexto de esta aplicación existe una dependencia cuando una

clase hace uso de los servicios provistos por otra. Por ejemplo, cuando una
Página 47
clase hereda de otra, o tiene un atributo del tipo de otra clase, o cuando uno
de sus métodos invoca a otro método de otra clase.
A su vez define los conceptos de dependencia entrante y saliente

(inbound/outbound dependencies). Siendo la dependencia A B, se dice que
A tiene una dependencia “saliente” con B, mientras que B tiene una
dependencia “entrante” de A. La dependencia es la misma pero será saliente
o entrante según desde donde se la vea.
Los artefactos de software identificados son: paquetes, clases, y

funcionalidades (constructores, métodos y atributos de una clase).
Con estos elementos define a un grafo de dependencia como un

conjunto de nodos para cada artefacto de software relacionados a través de
dos tipos de relaciones: relaciones de composición y relaciones de
dependencia.
Los paquetes contienen clases, las cuales a su vez contienen

funcionalidades. Estas son las denominadas relaciones de composición.
A su vez, las clases se referencian entre ellas, e igualmente sucede con

las funcionalidades. Estas son relaciones de dependencia.
Así esta herramienta genera grafos de dependencia extrayendo tres

tipos diferentes de dependencia de código:
1) Funcionalidad a Funcionalidad (Feature to Feature)
2) Funcionalidad a Clase (Feature to Class)
3) Clase a Funcionalidad (Class to Feature)
Página 48
3 Proceso AIT - Análisis de Impacto

basado en Trazabilidad
Durante este capítulo se define el proceso que bajo ciertas premisas

permite dar respuesta a la hipótesis de este trabajo.
El proceso establece un marco sobre el cual es posible recolectar

información de trazabilidad adecuada para un posterior efectivo Análisis de
Impacto frente a cambios que se presenten.
El mismo deberá ser implementado en forma paralela al ciclo de vida del

proyecto de software, desde sus etapas tempranas, como así también durante
su desarrollo y mantenimiento.
Como última sección de este capítulo se especifican los componentes de

software de la arquitectura que es necesaria para la implementación del
mismo.
Página 49
3.1 Diagrama del Proceso
Página 50
3.2 Especificación del Proceso
Para la especificación del Proceso, se hace uso de templates extraídos

de la bibliografía (Olson, Reizer, & Over, 1993).
3.2.1 Catálogo de Agentes, Productos y Actividades
Agentes - ¿Quiénes están involucrados en el proceso?
Id Nombre
1 Moderador: Persona encargada de liderar todo el proceso
2 Arquitecto: Líder Técnico del Proyecto
3 Miembro del equipo: Desarrollador, Analista, etc.
Revisor: Persona encargada de revisar la documentación de

4
trazabilidad generada. Puede ser el mismo moderador
Analista de Cambios: Persona encargada de llevar adelante los

5
Análisis de Impacto
Productos - ¿Qué productos se utilizan y producen en el proceso?
Id Nombre
1 Definición de Configuración de Trazabilidad
2 Extractores de Trazabilidad
3 Información de Trazabilidad
4 Registro de Trazabilidad
5 Conjunto Estimado de Impacto
6 Cuantificación del impacto
Página 51
Actividades - ¿Qué actividades se desarrollan?
Id Nombre
1 Configuración de Trazabilidad
2 Definición de Extractores
3 Traspaso de conocimiento
4 Identificación
5 Revisión
6 Análisis de Impacto
Página 52
3.2.2 Actividad 1 – Configuración de Trazabilidad
Propósito - ¿Para qué se desarrolla esta Actividad?
La actividad de Configuración de Trazabilidad es muy importante, ya que

al configurar la trazabilidad se estará especificando la granularidad de la
documentación de trazabilidad que se generará durante el proyecto, y por
consiguiente el esfuerzo requerido para su mantenimiento y actualización.
Desarrollada por - ¿Quiénes son responsables por desarrollar esta

actividad?
Id Nombre
1 Moderador
Criterio de entrada - ¿Cuándo puede comenzar esta actividad?
Estado o Condición Actividad Precedente Y/O
Definición del Alcance del Proceso RUP – Fase Concepción Y

proyecto
Definición de las herramientas Proceso RUP – Fase Concepción

y tecnología a utilizar durante el
proyecto
Entradas - ¿Qué productos utiliza esta actividad?
Esta actividad no utiliza ningún producto.
Página 53
Actividad Padre: Esta actividad no posee actividad padre.
Sub-actividades, procedimiento, método - ¿Cómo se implementa

esta actividad?
Paso Nombre y Descripción
Clasificación de Etapas y Workproducts: Se define a una etapa

como una fase del ciclo de vida del proyecto en cuestión. Durante la
ejecución de la misma se podrán identificar a uno o más tipos de
1
workproducts. Por lo tanto, será importante definir las etapas de
trazabilidad y los tipos de workproducts que se identificarán en cada
una de ellas.
Clasificación de Trazas: Una vez clasificados los tipos de

workproducts, será necesario definir las relaciones que pueden existir
entre ellos a través de trazas.
Se deberán definir tanto las trazas explícitas, como las implícitas,
dejando en claro que tipos de workproducts relacionan cada una de
2
ellas.
En este paso, se especificará la relación existente entre los
workproducts pertenecientes a una etapa, a través de trazas verticales,
y la existente entre workproducts de diferentes etapas mediante de
trazas horizontales.
Criterio de salida - ¿Cuándo está completa esta actividad? ¿Qué

actividad sigue?
Estado o Condición Actividad Siguiente Y/O
Se completó la documentación
Definición de Extractores
de configuración de trazabilidad
Salidas - ¿Qué productos son producidos en esta actividad?
Producto Actividad a la que está destinado
- Definición de Extractores
Definición de configuración de
- Traspaso de conocimiento
trazabilidad
- Revisión
Página 54
3.2.3 Actividad 2 – Definición de Extractores
Una de las premisas de este trabajo es reducir el esfuerzo humano

necesario para la documentación de las trazas existentes en un sistema. Para
eso se definen los extractores. Un extractor no es más ni menos que una
herramienta que permitirá la sincronización de trazas y workproducts en forma
automatizada, requiriendo un esfuerzo humano mínimo. Al hablar de
sincronización nos referimos al proceso por el cual nuestro Modelo de
Trazabilidad y Análisis de Impacto se alimenta de toda la documentación del
proyecto, pudiéndose actualizar trazas y workproducts.
Es importante notar que termina siendo la tecnología (herramientas de

modelado, lenguaje de programación, frameworks, etc.) lo que determina si
existe o no la posibilidad de implementar extractores para cada tipo de
workproduct y traza configurados.

actividad?
Id Nombre
2 Arquitecto
Disponibilidad de documentación de Configuración de

configuración de trazabilidad Trazabilidad
Producto Actividad que lo origina
Definición de configuración de
Configuración de Trazabilidad
trazabilidad
Página 55
Actividad Padre: Configuración de Trazabilidad

esta actividad?
Implementación de Extractores de Workproducts: Es recomendable

1 que para cada tipo de workproduct se implemente un extractor
correspondiente, siempre y cuando la tecnología utilizada lo permita.
Implementación de Extractores de Trazas: De manera de cumplir

con uno de los objetivos de este trabajo, que es el de reducir el
2 esfuerzo humano, se plantea la pauta casi obligatoria de: implementar
un extractor para la documentación de cada traza clasificada en la
actividad anterior.

actividad sigue?
Se implementaron los posibles

extractores de workproducts y Traspaso de conocimiento
trazas
- Traspaso de conocimiento
Extractores de Trazabilidad
- Identificación
Página 56
3.2.4 Actividad 3 – Traspaso de conocimiento
Para lograr una correcta documentación de trazabilidad es obligatorio

que todo el equipo del proyecto se vea involucrado.
Para tal fin y como punto más importante, el proceso debe ser entendido
como una mejora y no como un formalismo de documentación.

actividad?
Id Nombre
1 Moderador
2 Arquitecto
Disponibilidad de documentación de Configuración de Y

configuración de trazabilidad Trazabilidad
Disponibilidad de extractores Definición de Extractores
Definición de configuración de Configuración de Trazabilidad

trazabilidad
Extractores de Trazabilidad Definición de Extractores
Página 57
Actividad Padre: Definición de Extractores
Se deberá establecer para cada rol y miembro del equipo, como y de

que manera identificar y documentar las trazas y workproducts.

esta actividad?
Distribuir y explicar documentación de trazabilidad a cada miembro del

1
equipo de proyecto.
Establecer para cada rol y miembro del equipo, como y de que manera
2
identificar y dejar documentación de trazas y workproducts.

actividad sigue?
Se asignaron los responsables

de la identificación de cada tipo
Identificación
de workproduct, instruyéndolos
en el uso de los extractores.
Definición de responsabilidades Identificación
Página 58
3.2.5 Actividad 4 – Identificación
Esta actividad se refiere a la documentación de trazas y workproducts en

sí. Cada miembro del equipo en base a los lineamientos recibidos en la
actividad anterior, deberá identificar los workproducts y trazas que haya
creado.
Se recomienda que esta tarea sea realizada en forma paralela al

desenvolvimiento del proyecto y no en forma posterior al mismo. Una buena
costumbre es realizar esta identificación con una periodicidad diaria o
semanal.

actividad?
Id Nombre
3 Miembro del equipo
Disponibilidad de extractores Definición de Extractores Y
Creación de workproducts o
Fase Construcción
trazas
Extractores de Trazabilidad Definición de Extractores
Página 59
Actividad Padre: Traspaso de conocimiento al equipo de Proyecto

esta actividad?
1 Identificación de workproducts
2 Identificación de trazas

actividad sigue?
Se identificaron todos los

workproducts y trazas Revisión
respectivos
Información de Trazabilidad Revisión
Página 60
3.2.6 Actividad 5 – Revisión
A modo de inspección y entrenamiento del equipo en la ejecución del

proceso, se establece la necesidad de una revisión de las trazas y
workproducts identificados en la actividad anterior.
Será necesario establecer la periodicidad de esta revisión y el / los

responsables de la misma.

actividad?
Id Nombre
4 Revisor
Nuevos Workproducts y Trazas Identificación de Trazas y

identificadas Workproducts
Información de Trazabilidad Identificación
Definición de Configuración de Configuración de Trazabilidad

Trazabilidad
Página 61
Actividad Padre: Identificación de Trazas y Workproducts

esta actividad?
Validar que los workproducts y trazas identificadas estén de acuerdo a

1
la configuración de trazabilidad
Verificar existencia de requerimientos no trazados hacia ningún

2
workproduct
3 Mantener un registro de aquellos workproducts sin trazas

actividad sigue?
Todos los workproducts y

trazas nuevas han sido No posee
revisados
Registro de trazabilidad Revisión
Página 62
3.2.7 Actividad 6 – Análisis de Impacto
El principal objetivo del análisis de impacto, es identificar los

workproducts del software que serán afectados por cambios propuestos al
mismo.

actividad?
Id Nombre
1 Analista de Cambios
Requerimiento de Cambio -
Información de Trazabilidad Identificación
Página 63
Actividad Padre: Esta actividad no posee actividad padre.

esta actividad?
Identificación de workproducts que aparentemente se verán

1
impactados por el cambio (Conjunto de Inicio de Impacto – CII)
Estimación de los workproducts impactados (Conjunto Estimado de

2
Impacto – CEI) aplicando efecto de ripple sobre el CII
3 Cuantificación del impacto estimado

actividad sigue?
Se alcanza un CEI y se Implementación del Cambio

cuantifica el impacto
Conjunto Estimado de Impacto (CEI) Proceso de Administración del

Cambio
Cuantificación del Impacto Proceso de Administración del

Cambio
Página 64
3.3 Arquitectura
El proceso planteado deberá estar soportado por diferentes

herramientas / componentes de arquitectura que permitan su exitosa
implementación.
En el siguiente diagrama se pueden observar los componentes que

integran dicha arquitectura, y los específicos utilizados en la práctica del
presente trabajo.
• Herramienta Issue Tracking: esta herramienta es utilizada por

los stakeholders del proyecto para especificar requerimientos de
cambio.
• Repositorio de Versionado: es indispensable contar con un

medio para versionar los workproducts del proyecto. Por cada
requerimiento de cambio es aconsejable realizar una nueva
Página 65
versión de manera de contar con información detallada del CIR

resultante.
• Herramienta de Análisis / Diseño: para la especificación del

análisis y diseño, el analista y arquitecto deben utilizar
preferentemente una herramienta ágil y con soporte UML.
• Herramienta Cross Reference: este tipo de herramientas

usualmente ofrecen dos funcionalidades: 1) navegación sobre los
componentes de código de un proyecto y sus relaciones, y 2)
extracción de dependencias de código.
• Explorador CVS: de modo de facilitar la visualización de

comentarios sobre versiones, modificaciones entre una versión y
otra, y demás información inherente al repositorio de versionado
de fuentes, es aconsejable contar con una herramienta que
permita la navegación del mismo de manera fácil e intuitiva. Es
necesario que esta herramienta pueda ser accedida por cualquier
stakeholder y de ser posible mediante un browser http.
• ImpactTrace: herramienta central del proceso sobre la cual se

accederá a toda la información de trazabilidad recolectada para la
estimación de diversos análisis de impacto. Su diseño y
principales funcionalidades serán comentados en una sección
posterior.
• Repositorio de IT: materia prima para el análisis de impacto. En

este repositorio se almacenan todos los workproducts y trazas. El
mismo es accedido a través de la herramienta ImpactTrace.
Página 66
4 AIT – Configuración de
Trazabilidad
Como fue mencionado, la propuesta de Análisis de Impacto está basada

en información de trazabilidad recolectada durante la ejecución del proyecto.
Así, las estimaciones de impacto que puedan obtenerse son consecuencia de
cómo se almacena dicha trazabilidad.
Por lo tanto es importante establecer criterios y conceptos para una

efectiva Configuración de Trazabilidad que permita documentar y mantener de
manera adecuada la trazabilidad por parte del equipo de proyecto.
En este capítulo se brindarán detalles precisos de lo que se entiende por

Configurar la Trazabilidad de un proyecto de Software de manera adecuada
para alcanzar Análisis de Impacto efectivos.
Página 67
4.1 Configuración de Trazabilidad
Según los trabajos investigados, la información de trazabilidad de un

proyecto puede traducirse como la documentación existente de los diversos
workproducts y trazas existentes entre los mismos.
Ahora bien, la información de trazabilidad puede ser documentada de

diversas maneras según el criterio de quien esté llevando adelante la
actividad.
La configuración de trazabilidad de un proyecto será justamente el

elemento que brinde un marco para dicha actividad, básicamente
estableciendo que tipos de workproducts y trazas podrán ser identificados y
documentados.
Así, en esta sección se brindan detalles y criterios de cómo establecer

una Configuración de Trazabilidad que persiga primordialmente el objetivo de
un Análisis de Impacto efectivo y así poder brindar respuesta a la hipótesis
planteada.
4.1.1 Clasificación de Workproducts
Como fue mencionado, los elementos que componen la información de

trazabilidad de un proyecto son por un lado los workproducts que lo integran
y las relaciones entre ellos, es decir las trazas existentes.
En base a que la trazabilidad documentada es la información utilizada

durante el análisis de impacto, se clasifican y agrupan a los workproducts en
base a los siguientes conceptos:
Se define al Sistema como la unión de todos los workproducts

identificados.
n
S = ∑ WPi siendo WPi cada workproduct identificado y n la cantidad
i =1
total de workproducts del Sistema.
Página 68
Si se determina el momento de creación de los workproducts, una Etapa

/ Fase del Sistema marcará una primera diferenciación entre los mismos.
Análisis, diseño, construcción y testing son claros ejemplos de etapas
encontradas comúnmente en proyectos. Cada fase o etapa del sistema se
define como la unión de todos los workproducts identificados en la misma:
n
Fi = ∑ WPj siendo WPj cada workproduct identificado en la fase Fi.
j =1
Una segunda clasificación de workproducts estará dada por su Tipo.

Requerimiento, caso de uso, diagrama de clases, clase, método, tabla son
claros ejemplos de esta clasificación. Se define a un Tipo de Workproduct
como la unión de todos los workproducts clasificados de igual tipo.
n
TWPi = ∑ WPj siendo WPj cada workproduct del tipo TWPi.
j =1
A su vez, una Etapa está conformada por diferentes Tipos de

workproducts, y por lo tanto un Sistema puede ser visto como la unión de sus
etapas, dando lugar a la siguiente definición:
n n n
S = ∑ Fi = ∑∑ TWPij siendo Fi una fase en particular del Sistema y
i =1 i =1 j =1
TWPij un workproduct del Tipo j perteneciente a la Fase i.
Esta clasificación de workproducts según su Etapa de origen y Tipo,

hace que la información de Análisis de Impacto sea más detallada y granular
permitiendo tomar decisiones más acertadas.
4.1.2 Trazabilidad Horizontal / Vertical
Como se definió anteriormente, existe trazabilidad vertical si una traza

asocia a dos ítems de un mismo modelo, y horizontal cuando los ítems
asociados pertenecen a diferentes modelos.
Página 69
Siguiendo la clasificación de workproducts establecida, se denomina

modelo a cada etapa / fase del proyecto. Existe entonces trazabilidad vertical
dentro de una misma etapa y trazabilidad horizontal entre etapas diferentes
del proyecto.
Traza Vertical: relación entre dos workproducts pertenecientes a la

misma etapa del Sistema. Queda definida mediante la siguiente función:
f TV (WPi ) 
→ WPj donde WPi, WPj pertenecen a una misma Etapa.
Traza Horizontal: relación entre dos workproducts pertenecientes a la

misma etapa del Sistema. Queda definida mediante la siguiente función:
f TH (WPi ) 
→WPj donde WPi, WPj pertenecen a diferentes Etapas.
4.1.3 Especificación de la Configuración de Trazabilidad
A fin de especificar la configuración de trazabilidad y brindar una rápida

visualización de la misma, se completa una tabla de doble entrada, de aquí en
adelante denominada “Tabla de Configuración de Trazabilidad”, como la
siguiente:
TWP1
TWP2
TWP3
TWP4
TWP5
TWP1 0..n 1..n 0 1 0..1
TWP2 0..1 0..1 0..n 1..n 0..1
TWP3 1..n 1..n 0..n 0..1 0..1
TWP4 0 0..1 0..1 0..1 0
TWP5 0..1 0..n 0..n 0..n 0..1
Siendo TWP1..TWP5 los diferentes tipos de workproducts identificados,

las trazas posibles entre los mismos están dadas por los valores ingresados
Página 70
en los casilleros que hagan de intersección entre los mismos. Al especificar

una traza se está estableciendo su cardinalidad. Los valores posibles de
cardinalidad y sus significados son los siguientes:
0: TWPi no puede presentar trazas con TWPj.
0..1: TWPi puede presentar una traza con TWPj.
1: TWPi debe presentar una traza con TWPj.
0..n: TWPi puede presentar más de una traza con TWPj.
1..n: TWPi debe presentar como mínimo una traza con TWPj.
Cabe señalar que la tabla debe ser leída comenzando por el tipo de
workproduct que se encuentra a la izquierda. Siguiendo con el ejemplo de
tabla de trazabilidad presentado, algunas posibles asociaciones entre
workproducts son:
• Workproducts del tipo TWP1 pueden presentar más de una traza

con Workproducts del mismo tipo.
• Workproducts del tipo TWP1 deben presentar una traza con algún
workproduct del tipo TWP4
• Workproducts del tipo TWP4 no pueden presentar trazas con

workproducts del tipo TWP1
Concluyendo, esta tabla es el reflejo de la configuración de trazabilidad

establecida en la primer actividad del modelo de proceso planteado.
4.1.4 Configuración de Trazabilidad Vertical
La configuración de trazabilidad vertical que se pueda establecer para

cada etapa de un proyecto dependerá de las metodologías o procesos que se
estén utilizando.
En esta sección se brindan ejemplos prácticos de configuraciones de

trazabilidad vertical para las diferentes metodologías, enfoques y procesos
detallados en los Anexos 11.5 (RUP), 11.6 (ICONIX), 11.7 (Domain-Driven
Design) y 11.8 (Requerimientos Estructurados).
Página 71
RUP
Siendo que este proceso se focaliza en detallar la manera de especificar

necesidades y requerimientos de software, el mismo puede ser tomado como
ejemplo para establecer una configuración de trazabilidad vertical en la Etapa
de Análisis.
Para cada una de sus alternativas de aplicación explicadas en el Anexo

11.4 se detalla una posible configuración de trazabilidad.
4.1.4.1.1 Solo Casos de Uso
Suplementaria
Especificación
Caso de Uso
Caso Uso 0..n 0..n
Especificación
0 0..n
Suplementaria
Es interesante destacar como a través de esta configuración de

trazabilidad se da gran importancia a los Casos de Uso, haciendo que los
mismos sean el punto de partida de documentación de un requerimiento de
usuario. Se logra esto prohibiendo trazas desde Especificaciones
Suplementarias hacia Casos de Uso. Las Especificaciones Suplementarias
sirven como complemento al Caso de Uso, no siendo origen de los mismos.
Además al utilizar cardinalidad 0..n no es obligatorio establecer trazas.
Página 72
4.1.4.1.2 Casos de Uso inducidos a partir de Funcionalidades
Suplementaria
Especificación
Funcionalidad
Caso de Uso
Necesidad
Necesidad 0..n 1..n 0 0
Funcionalidad 0 0..n 1..n 0
Caso Uso 0 0 0..n 0..n
Especificación
0 0 0 0..n
Suplementaria
Esta configuración a diferencia de la anterior obliga a que el punto de

partida sean las Necesidades. Una necesidad debe obligatoriamente trazar
hacia delante (traza forward) con una o más funcionalidades. Sin embargo,
las Necesidades no pueden trazar directamente con Casos de Uso, obligando
así a llegar a los mismos solo a través de Funcionalidades.
Por otro lado, cada Funcionalidad debe trazar con al menos un Caso de
Us, no pudiendo presentar traza alguna con Especificaciones Suplementarias.
4.1.4.1.3 Casos de Uso son interpretados de la SRS (Software

Requirement Specification)
Requerimiento
Funcionalidad
Caso de Uso
Funcionalidad 0..n 1..n 0
Requerimiento 0 0..n 1..n
Caso Uso 0 0 0..n
Página 73
Las funcionalidades son el punto de partida y deben trazar con

requerimientos. A su vez, cada requerimiento de la SRS debe presentar
trazabilidad con al menos un Caso de Uso.
4.1.4.1.4 Sin Casos de Uso
Requerimiento
Funcionalidad
Necesidad
Necesidad 0..n 1..n 0
Funcionalidad 0 0..n 1..n
Requerimiento 0 0 0..n
4.1.4.1.5 El Modelo de Casos de Uso define las funcionalidades del

producto
Caso de Uso
Necesidad
Necesidad 0..n 1..n
Caso de Uso 0 0..n
Proceso ICONIX
ICONIX, como se menciona en el Anexo correspondiente, es un proceso

altamente iterativo. No señala etapas marcadas dentro del proceso, sino que
especifica los pasos necesarios para llevarlo adelante. A su vez, no persigue
la idea de tener que alcanzar un resultado para poder movernos al siguiente
paso.
La característica que diferencia a ICONIX de otros procesos es que

resalta la necesidad de crear Diagramas de Robustez para cada Caso de
Página 74
Uso. Los Diagramas de Robustez permiten reducir el “gap” entre el Análisis y

el Diseño.
En base a este elemento diferenciador, se analiza una posible

configuración de trazabilidad vertical para la Etapa de Análisis de este
proceso, ya que el resto de etapas (diseño, construcción y testing) no aportan
elementos ricos y diferenciadores en cuanto a trazabilidad.
En la definida Etapa de Análisis se encuentran los siguientes elementos:

Casos de Uso, Modelo de Dominio y Diagramas de Robustez. A fin de brindar
mayor granularidad de trazabilidad se identifica como workproduct:
• a cada entidad de dominio perteneciente al Modelo de Dominio y,
• a los elementos propios de un Diagrama de Robustez (Objetos de

Periferia, Objetos de Entidad y Objetos de Control).
En base a la indicación del proceso que dice: los Objetos de Entidad

propios de los Diagramas de Robustez deberán ser Entidades de Dominio
identificadas en el Modelo de Dominio. Con lo cual, en la configuración de
trazabilidad se hace mención a Entidades de Dominio solamente.
Caso de Uso
Entidad de
Objeto de
Objeto de
Periferia
Dominio
Control
Caso de Uso 0..n 0..n 0..n 0..n
Entidad de Dominio 0 0..n 0 0
Objeto de Periferia 0 0 0 0..n
Objeto de Control 0 0..n 0 0..n
La configuración de trazabilidad para la Etapa de Análisis de este

proceso señala a los casos de uso como punto de partida. Cada caso de uso
puede presentar trazas con los diferentes elementos que integran su flujo de
acción: Entidades de Dominio, Objetos de Periferia y Objetos de Control.
Página 75
Siguiendo los lineamientos establecidos por el proceso, al crear los

Diagramas de Robustez se tiene que:
• los Objetos de Periferia solo pueden presentar trazas con los

Objetos de Control,
• los Objetos de Control solo pueden presentar trazas con otros

Objetos de Control y Entidades de Dominio,
• las Entidades de Dominio solo pueden presentar trazas con otras

Entidades de Dominio.
Domain Driven Design
Eric Evans bajo su proceso Domain Driven Design aporta el concepto de

“Modelo de Separación de Capas”, el cual es adoptado para establecer una
posible configuración de trazabilidad vertical en la Etapa de Implementación.
De cada capa planteada por Evans se clasifica un tipo de workproduct

diferente:
• Capa de Presentación: Componentes Vista
• Capa de Aplicación: Componentes Control
• Capa de Dominio / Negocio: Componentes Modelo
• Capa de Infraestructura: Componentes Infraestructura
Con estos elementos es posible definir la siguiente configuración de

trazabilidad vertical en la Etapa de Implementación:
Página 76
Infraestructura
Componentes
Componentes
Componentes
Componentes
Modelo
Control
Vista
Componentes
0..n 0..n 0 0
Vista
Componentes
0 0..n 0..n 0
Control
Componentes
0 0 0..n 0..n
Modelo
Componentes
0 0 0 0..n
Infraestructura
Requerimientos Estructurados
Los tipos de workproducts que pueden clasificarse en la metodología

son:
- Objetivo de negocio (Goal): Objetivo del sistema de alto nivel

expresado en términos del negocio.
- Requerimiento estructurado
- Paso: cada uno de los pasos que integra el flujo de un requerimiento

determinado.
- Link: información adicional de un requerimiento como ser

screenshots o storyboards.
- Caso de Prueba
Así, la metodología a través de su herramienta Optimal Trace permite

capturar la siguiente trazibilidad:
Página 77
Requerimiento
Estructurado
Caso de
Objetivo
Prueba
Paso
Link
Objetivo 0 0..n 0 0 0
Requerimiento
0 0..n 0..n 0..n 0..n
Estructurado
Paso 0 0 0 0 0
Link 0 0 0 0 0
Caso de Prueba 0 0 0 0 0
4.1.5 Configuración de Trazabilidad Horizontal
Siendo uno de los objetivos de este trabajo el de reducir el “gap” de

conocimiento entre el Análisis y Diseño/Desarrollo, se establecen en esta
sección posibles configuraciones de trazabilidad horizontal que permitan ligar
dichos modelos.
Para establecer la configuración de trazabilidad horizontal se hace uso

de los tipos de workproducts identificados en la sección anterior.
Se analizan dos alternativas según que metodología/proceso se esté

utilizando para el Análisis del proyecto:
• Trazabilidad Horizontal en base a RUP
• Trazabilidad Horizontal en base a ICONIX
Se hará uso de la “Tabla de Configuración de Trazabilidad” citada

anteriormente.
Trazabilidad Horizontal en base a RUP
Los tipos de workproducts del proceso RUP que sirven para establecer
trazas horizontales con la Etapa de Implementación son los Requerimientos o
Casos de Uso, según la alternativa de aplicación de RUP utilizada.
Página 78
La configuración de trazabilidad que se propone es la siguiente:
Infraestructura
Componente
Componente
Componente
Componente
Control
Modelo
Vista
Requerimiento 1..n 0 0 0
Caso de Uso 1..n 0 0 0
Mediante esta configuración se establece:
• que todo requerimiento o caso de uso especificado presente al

menos una traza con la Etapa de Implementación,
• que los componentes vista sean los tipos de workproduct de la

Etapa de Implementación que sirvan como nexo con la Etapa de
Análisis mediante las trazas horizontales documentadas,
Trazabilidad Horizontal en base a ICONIX
Los elementos de los diagramas de robustez de este proceso son los

que establecen la trazabilidad horizontal con la Etapa de Implementación.
Se propone la siguiente configuración de trazabilidad:

Infraestructura
Componente
Componente
Componente
Componente
Control
Modelo
Vista
Objeto Periferia 1..n 0 0 0
Objeto Control 0 1..n 0 0
Entidad Dominio 0 0 1..n 0
Página 79
Página 80
5 AIT - Extractores de Trazabilidad
Documentar la trazabilidad durante la vida de un proyecto es una tarea

que requiere un gran esfuerzo por parte de quien la desempeñe. Si a esto a
su vez le sumamos el esfuerzo extra necesario para su actualización a
medida que los workproducts o trazas son modificados, vemos la necesidad y
obligación de destinar un recurso con dedicación full-time a dichas
actividades.
Generalmente la documentación de trazabilidad se realiza de manera

incorrecta, o ni siquiera se tiene en cuenta por cuestiones de costo / beneficio.
Es comúnmente el analista quien debe ir volcando en la herramienta de
análisis los diferentes workproducts y relaciones existentes de manera
explícita haciendo uso de la matriz de trazabilidad o por medio de elementos
UML que permitan vincular diferentes elementos.
El problema principal es que generalmente no existe un medio

automatizado que permita la carga y actualización de trazas y workproducts
desde el proyecto al modelo de análisis de impacto en cuestión.
Página 81
Este factor es uno de los mayores impedimentos a la hora de

implementar el proceso de análisis de impacto en forma efectiva y con una
relación costo-beneficio positiva en una organización de desarrollo de
software.
Por lo tanto se ataca esta problemática reduciendo las horas hombre

requeridas para la creación y actualización de toda la información de
trazabilidad. Para esto se definen extractores automatizados de
trazabilidad que serán utilizados durante la denominada actividad
“Identificación” en el proceso AIT detallado anteriormente.
En este capítulo se define como lograr automatizar la documentación de

trazabilidad a través de la utilización de extractores. Además se brindan
ejemplos de extractores desarrollados para las etapas de Análisis, Diseño e
Implementación.
5.1 Sincronización de Trazabilidad Automatizada
La información de trazabilidad generada durante la actividad de

Identificación del proceso AIT deberá ser almacenada en un repositorio de
trazabilidad con cierta estructura predefinida para su posterior utilización en la
actividad de Análisis de Impacto. Este pasaje de información desde el “mundo
real” al modelo de trazabilidad es denominado con el concepto de
sincronización.
Así, un extractor es el medio por el cual un workproduct o traza es

sincronizado entre el proyecto y la herramienta de forma automatizada. En
referencia a los conceptos brindados por el framework mostrado en la Sección
2.3.5 se puede decir que un extractor permite pasar del modelo de objetos de
interfaz al modelo interno de objetos del enfoque.
Página 82
Se definen dos tipos de extractores: extractores de trazas y

extractores de workproducts. Ambos poseen la misma finalidad:
automatizar la extracción de información de trazabilidad y el almacenamiento
en el repositorio de trazabilidad.
5.2 Etapa de Análisis – Enterprise Architect Extractor
Enterprise Architect (EA) es una herramienta útil para la documentación

del análisis de proyectos mediante notación UML. La misma ha sido utilizada
en el primer caso práctico demostrado en este trabajo. De manera de
automatizar la documentación de trazabilidad presente en el modelo de
Análisis se implementó un extractor capaz de transformar las notaciones UML
utilizadas en la herramienta a información de trazabilidad.
El extractor fue implementado bajo la siguiente arquitectura:
EA se utilizó en modalidad Corporativa de manera de almacenar el

modelo en Base de Datos (EA BD). El extractor EA tiene la funcionalidad de
leer datos de tablas propias de EA (EA BD) y pasarlos al repositorio de
trazabilidad propio de la herramienta de trazabilidad ImpactTrace detallada
más adelante.
En la herramienta Enterprise Architect (EA) es posible documentar

diferentes tipos de artefactos y trazas. En las siguientes secciones se
Página 83
presentan ejemplos de trazabilidad documentados en EA durante el primer

caso práctico.
5.2.1 Trazabilidad entre Requerimientos

cd Formal Requirements
Control de
promoci ones
acti vas
«trace»
Restricci ones Control de carga de artículos y
por perfi l de estructuras comerci al es
«trace»
usuari o
«trace»
Admi nistración de perfi l es,
usuarios y permi sos
Admi ni straci ón de
T emplates
«trace»
T empl ates de Campos edi tables
Promoci ones
«trace»
«trace»
Grupo de T empl ates
5.2.2 Trazabilidad entre Requerimientos y Casos de Uso

cd Traces Req-UseCase
ABM Grupo de
Template
«include»
Administración de
Templates Crear «trace»
«trace» Template
Grupo de Templates
«trace» «include»
Editar Campos editables

«trace»
«trace» Template
Eliminar
Template «trace»
Buscar
Template
Editar Acceso
Campo
Página 84
5.2.3 Trazabilidad entre Casos de Uso y Vistas
cd Traces UseCase-Screen5
Buscar Template
/template/template_filter.j sp
«trace»
«trace»
Eliminar Template
/template/template_condition_promo_v ariable.j sp
/template/template_condition_date.j sp
«trace»
Editar Condicion «trace»

Template
«trace» /template/template_condition_exclude_tab.j sp
«trace»
«include»
/template/template_condition_item_tab.j sp
«trace»
Seleccionar Tipo
Condicion
/template/template_condition_v alue.j sp
5.3 Etapa Implementación
La clasificación de tipos de workproducts de la Etapa de Implementación

puede respetar las capas identificadas por Eric Evans: Vista – Control –
Modelo. Así, en esta sección se brindan ejemplos de implementación de
extractores para cada una de las capas mencionadas.
Primero se cubre un extractor propio para la Capa de Vista y Control

implementado sobre los conceptos del framework Struts.
Página 85
Posteriormente para la Capa de Modelo se especifica un extractor de

trazabilidad implícita basado en dependencia de código y, otro basado en
trazabilidad explícita documentada por los mismos desarrolladores del equipo
de proyecto.
5.3.1 Capa de Vista y Control – Struts Extractor
Este extractor se basa en detalles de implementación del framework

Struts para lograr extraer la información de trazabilidad.
En la siguiente tabla puede observarse la relación entre cada artefacto

extraído y su correspondiente tipo de workproduct generado en el modelo de
trazabilidad.
Artefactos Extraídos Tipo de Workproducts Generados
Java Server Pages

Workproducts Vista
Struts ActionForms
Actions Struts Workproducts Control
Es común que los archivos .jsp sean almacenados a partir de una misma
carpeta. Así este extractor recorre en forma recursiva a partir de un directorio
base, identificando a un workproduct vista con el nombre del archivo
correspondiente por cada archivo .jsp hallado.
Struts basa su configuración en un archivo XML llamado struts-

config.xml. Este extractor se vale del mismo para extraer los ActionForms y
Actions Struts, workproducts de Vista y Control respectivamente. En el
siguiente cuadro se muestra un fragmento de dicha configuración.


<form-beans>
<form-bean name="rewardSelection"
type="ncr.dpc.form.reward.RewardSelection"/>
<form-bean name="rewardGeneralInfo"
type="ncr.dpc.form.reward.RewardGeneralInfo"/>
<form-bean name="rewardLimits" type="ncr.dpc.form.reward.RewardLimits"/>
<form-bean name="promotionForm"
type="ncr.dpc.form.promotion.PromotionForm"/>
…
</form-beans>
Página 86
Asimismo, en el mismo archivo de configuración se encuentran

documentadas las trazas implícitas entre workproducts del tipo Vista y
Control. A modo de ejemplo, se muestra el siguiente fragmento del archivo de
configuración de Struts:
<action-mappings>
<action path="/PagePromotionSearchResult"
type="ncr.dpc.action.promotion.PagePromotionSearchResultAction">
<forward name="success" path="/promotion/SearchPromotionFilter.jsp"/>
</action>
<action name="promotionGeneralTabForm" path="/PopulatePromotionGeneralTabForm"
type="ncr.dpc.action.promotion.PopulatePromotionGeneralTabFormAction" scope="request"
validate="false">
<forward name="success" path="/promotion/CEVPromotionGeneralTab.jsp"/>
</action>
</action-mappings>
Concluyendo, este extractor permite automatizar la documentación de

trazas existentes entre:
• Vista (.jsp) y Vista (ActionForms)
• Vista (.jsp) y Control (Actions Struts)
• Control (Action Struts) y Control (Action Struts)
5.3.2 Capa Control, Modelo e Infraestructura - Java Dependency

Extractor
Siendo JAVA el lenguaje de programación elegido para ambos casos

práctico tratados en este trabajo, se hizo uso de la herramienta Dependency
Finder, explicada en la sección 2.5.2, para construir un extractor capaz de
extraer la trazabilidad implícita en el código con una granularidad a nivel de
método de clase.
5.3.3 Capa Modelo e Infraestructura - Doclet Extractor
Suponiendo el caso en el que a un desarrollador o a un grupo de

desarrolladores se les encarga la tarea de implementar cierta funcionalidad
Página 87
que responde a un caso de uso en particular. Entonces sería útil que los
desarrolladores tuvieran algún medio o herramienta para:
• identificar los métodos y/o clases que implementan dicha

funcionalidad.
• dejar constancia de esta relación, es decir, documentar las trazas

entre el código propio a esta nueva funcionalidad y el caso de uso
correspondiente.
La idea sobre la cual se basa el presente extractor es que la

documentación de trazabilidad se incluya dentro del código mismo mediante
anotaciones especiales (tags doclet).
A modo de ejemplo se presenta el siguiente fragmento de código java:
package test;
/**
*
* @author Martin
* @wp
*/
public class ClassA {
/**
* @wp
* @trace-from name:CU001
*/
public void methodA() {
}
/**
* @wp
* @trace-to name:test.ClassB
*/
public void methodB() {
}
Gracias al tag doclet @wp el extractor al analizar esta clase (ClassA)

puede identificar tres workproducts de modelo:
• ClassA
• ClassA.methodA
Página 88
• ClassA.methodB
Además se definieron dos tags doclets para la documentación de trazas

en el código:
• @trace-to: utilizado para trazas forward
• @trace-from: utilizado para trazas backward
Concluyendo, un desarrollador podrá por ejemplo hacer uso del tag

@trace-from para documentar una traza entre un caso de uso y un método
java. O hacer uso de @trace-to para dejar en claro la dependencia entre dos
métodos propios de la capa de modelo.
5.3.4 Capa Infraestructura – DAO Extractor
Es común que la capa de acceso a datos de una aplicación respete el

patrón de diseño DAO (Data Access Object). El objetivo de dicho patrón es el
de encapsular todos los accesos a la fuente de datos ocultando los detalles
de implementación de la misma.
Por lo general esta capa de acceso a datos es invocada desde clases de

negocio (capa de modelo), o bien desde la capa de control, estableciéndose
cierta trazabilidad.
En particular, para el segundo caso práctico analizado en este trabajo,

las clases DAO son accedidas en forma directa desde la capa de control
(Actions Struts). Cada clase DAO ofrece un servicio de persistencia hacia la
capa de control, los cuales son definidos en un archivo de configuración XML
identificándolos a través de un nombre.
Página 89
…
<service name="contractDao"
description="contract dao operations"
className="com.inetpsa.cis.domain.dao.ContractDaoService">
</service>
<service name="contractSummaryDao"
description="contract Summary dao operations"
className="com.inetpsa.cis.domain.dao.ContractSummaryDaoService"
>
</service>
…
Así, la implementación de un extractor capaz de analizar este archivo

XML, permitió documentar cada Servicio DAO como un Workproduct propio
de la capa de Infraestructura en el segundo caso práctico.
5.3.5 Capa Infraestructura – DB Generic Extractor
Siendo la base de datos uno de los componentes de arquitectura

primordiales de casi todas las aplicaciones desarrolladas hoy en día, es útil
contar con un extractor capaz de obtener información del diseño de la misma.
Así, los workproducts posibles de identificar del diseño de una base de datos
podrían ser:
1) Tabla
2) Campo/Columna de una Tabla
3) Procedimiento Almacenado/Stored Procedure (para

el caso de Bases de Datos que soporten esta
funcionalidad).
Las trazas que se extraen de un Stored Procedure surgen de analizar su

código fuente en búsqueda de sentencias de INSERT, SELECT o DELETE
sobre tablas, quedando establecidas las trazas:
Página 90
Para lograr esta extracción se utilizó el API de expresiones Jakarta ORO

(http://jakarta.apache.org/).
Por otro lado las columnas/campos son los elementos que describen a
una tabla, estableciendo así la traza:
Para la extracción tanto de este tipo de trazabilidad como de los

workproducts mismos se utilizó la metadata obtenida haciendo uso de la clase
java.sql.DatabaseMetaData (http://java.sun.com/j2se/1.4.2/docs/api/java/sql/DatabaseMetaData.html).
Es importante destacar que la trazabilidad extraída es implícita y por lo

tanto no requiere del esfuerzo humano para su correspondiente
documentación.
5.3.6 Capa Infraestructura – Oracle Extractor
El motor de base de datos Oracle almacena de manera automática la

trazabilidad entre Paquetes (Packages), Stored Procedures y Tablas en una
tabla de sistema propia (SYS.DEPENDENCY$). Esta información es
mantenida de forma transparente al usuario logrando una actualización
automática frente a cambios en los esquemas.
En base a lo dicho fue posible implementar un extractor que

simplemente consulte la tabla SYS.DEPENDENCY$ y extraiga workproducts
y trazas entre los mismos.
La trazabilidad extraída se puede observar en la siguiente imagen:
Página 91
Función
Stored
Paquete
Procedure
Tabla
Este extractor fue utilizado en el segundo caso práctico presentado en

este trabajo, reduciendo notablemente el esfuerzo para la
documentación y actualización de trazabilidad.
5.4 Resumen
En este capítulo se brindó al lector ejemplos que permitan un mejor

entendimiento de extractores de trazabilidad y diversas implementaciones de
los mismos basadas en herramientas específicas.
A modo de resumen, en la siguiente tabla se detallan los extractores de

trazabilidad ejemplificados. Se puede observar también la información de
trazabilidad en la que cada extractor se enfoca.
Extractor Información de Trazabilidad Extraída
- Workproducts de la Etapa de Análisis (Requerimientos,

Casos de Uso, etc.) y trazas entre los mismos.
EA Extractor
- Trazabilidad entre workproducts de Análisis y workproducts
de Implementación, más específicamente las Vistas.
- Workproducts de la Etapa de Implementación: Capa Vista

(Java Server Pages y ActionForms), Capa Control (Actions
Struts Extractor Struts).
- Trazabilidad entre workproducts de Vista y Control.
- Trazabilidad implícita de la Etapa de Implementación en

base a dependencias de código.
- Workproducts de Modelo e Infraestructura (Clases y
JAVA Dependency Extractor métodos)
- Trazabilidad entre Capa de Control y Modelo.
- Trazabilidad entre Capa de Modelo e Infraestructura.
Página 92
- Trazabilidad explícita entre Etapa de Análisis e

Doclet Extractor Implementación en base a anotaciones documentadas en el
código.
- Trazabilidad implícita en capa de Infraestructura de la

DataBase Generic Extractor Etapa de Implementación: Stored Procedures, Tablas y
Cambos/Columnas de Tablas de una Base de Datos.
- Trazabilidad implícita en capa de Infraestructura de la

Oracle Extractor Etapa de Implementación: Paquetes, Stored Procedures,
Funciones, Tablas. Específico para RDBM Oracle.
Página 93
Página 94
6 AIT - Análisis de Impacto
6.1 Análisis de impacto iterativo
El análisis de impacto, en adelante AI, es la actividad final planteada de

AIT. Al igual que toda metodología de AI tiene como objetivo obtener un CEI
(Conjunto Estimado de Impacto) a partir de un CII (Conjunto de Inicio de
Impacto).
Una de las hipótesis del presente trabajo es la de permitir predicciones

de análisis de impacto más certeras a partir de la implementación de AIT.
Para alcanzar dicho postulado el AI planteado pretende:
1) Que el CEI incluya al CIR: esto significa que lo

realmente impactado por un cambio sea informado
en la estimación.
2) Que el CEI no tenga un tamaño excesivamente

mayor al del CIR.
Página 95
Bajo estos lineamientos y en base a los casos prácticos llevados

adelante se plantea un AI iterativo, donde cada iteración servirá para acotar al
CEI y asemejarlo al CIR.
El usuario de la metodología se podrá valer de la métrica #CEITWP /

#TWP para saber si es necesario realizar una nueva iteración. Será necesario
definir un límite para dicha métrica, indicando que para valores mayores al
mismo se aconseja una nueva iteración.
A su vez, para realizar una nueva iteración de manera de recortar el CEI,

el usuario debe tomar decisiones. Dichas decisiones serán asistidas mediante
los siguientes criterios:
1) Descartar workproducts con ripple elevado.
2) En base al Gráfico CEI Acumulado por distancia 6.7.4,

descartar workproducts del CEI a partir de cierta distancia de
impacto.
3) En base a información adicional de workproducts

(especificaciones funcionales, revisión de código, capturas de
pantalla, etc.) descartar aquellos no influenciados por el
cambio.
Página 96
6.2 Clasificación del enfoque
Haciendo uso del framework planteado en la sección 2.3.5 se clasifica el

enfoque planteado de Análisis de Impacto.
IA Application – Elementos diferenciadores
- Componentes y/o relaciones de análisis

¿Cuáles son los tipos
predefinidas
de objetos y
Modelo de los
relaciones extraídos - Componentes y/o relaciones de diseño
artefactos del dominio
del dominio del predefinidas
sistema?
- Componentes de Programa y/o relaciones
¿Pueden los
componentes
analizados ser
Descomposición descompuestos y - Si, solo sintaxis
almacenados en la
herramienta / enfoque
de AI?
- Si, el cambio se especifica con un simple

¿Cómo es el cambio análisis. Se establece un template para la
Especificación de
especificado frente al especificación del cambio y demás
cambios
enfoque de AI? parámetros de entrada al enfoque de AI. Ver
Sección 6.3
¿Cómo son los

Especificación de - Template para la especificación del
resultados del AI
resultados resultado de AI. Ver Sección 6.4
expresados?
¿Cuánto esfuerzo es
requerido por el
Interpretación de
usuario para - Poco
resultados
interpretar los
resultados del AI?
¿Qué otras
- Configuración de trazabilidad
funcionalidades se
Otras funcionalidades encuentran - Visualización de workproducts sin trazas
disponibles para el
- Sincronización de trazabilidad.
usuario?
Página 97
IA Parts – Elementos diferenciadores
- Cualquier workproduct que

haya sido debidamente
establecido en la
pueden ser expresados en la
Modelo de objetos de interfaz configuración de trazabilidad
interfaz de usuario del
(ej. requerimientos, decisiones
enfoque?
de diseño, clases de modelo,
etc.).
- Orientado a objetos.
Básicamente cada
Modelo interno de objetos workproduct es un objeto y
utiliza el enfoque?
una traza es otro objeto que
relaciona dos workproducts.
¿Cómo son modeladas las

- Una dependencia entre dos
dependencias? ¿Cuándo
workproducts es modelada a
estas dependencias son
través de una traza. Una traza
Modelo de Impacto tenidas en cuenta? ¿Qué tan
es un objeto que compone a
bien las dependencias del
dos workproducts: uno origen
modelo se reflejan con las
y otro destino.
del sistema?
- Ninguno. Las trazas se

¿Qué algoritmos o recorren en forma manual y
procedimientos son se va calculando el impacto
Enfoque de trazas utilizados por el enfoque de manera incremental
para calcular el impacto en partiendo de los workproducts
base a las trazas? origen (conjunto de inicio de
impacto).
¿Qué objetos y relaciones - Todos los que hayan sido

son capturados del sistema y debidamente establecidos en
Descomposición
almacenados internamente la configuración de
en el enfoque? trazabilidad.
¿Qué repositorio es utilizado

- Motor de base de datos
Repositorio para el almacenamiento de
relacional.
objetos y relaciones?
¿Qué funcionalidades brinda

el repositorio para la carga,
Carga, modificación, - Todos (Carga, modificación
modificación y navegación
navegación y navegación).
de los elementos
almacenados en él?
Página 98
6.3 Especificación del cambio
Cada cambio que se desee realizar a un software existente se convertirá

en el parámetro de entrada a la metodología de análisis de impacto que se
esté llevando adelante. Por lo tanto es necesario especificar dichos cambios
según un template prediseñado.
A continuación se presenta el template de especificación de cambio

utilizado en los casos prácticos del presente trabajo. Se describe cada uno de
sus atributos y los encargados de completarlos.
Especificación de Requerimiento de Cambio
Identificación [Título/enumeración del cambio] Analista de Cambios
Enunciado [Descripción del cambio] Analista de Cambios
[Corrección / Agregado o borrado de

Clasificación Analista de Cambios
funcionalidad / Modificación funcional]
Posible [Descripción funcional y/o técnica para

Arquitecto
implementación la implementación del cambio]
6.4 Especificación del Resultado de AI
Con la finalidad de documentar los resultados obtenidos en cada una de

las iteraciones realizadas durante un determinado análisis de impacto, el
arquitecto del proceso AIT deberá completar el siguiente template.
Página 99
Identificación del
[Identificación del cambio / Iteración Nro.]
Cambio / Iteración Nro.
[Completar solo a partir de la segunda iteración. Indicar que criterio se

Parámetros de Entrada
lleva adelante sobre el análisis de impacto para llevar adelante esta
de la Iteración
iteración]
Propósito del Análisis

[¿Qué resultado se espera obtener del análisis de impacto?]
de Impacto
Tipos de
Workproducts [Enumeración de los Tipos de Workproducts utilizados]
analizados
Tipos de Trazas
[Forward / Backward]
utilizados
Conjunto de Inicio de [Enumeración de workproducts que integran el Conjunto de Inicio de

Impacto (CII) Impacto]
Siendo TWPi cada Tipo de Workproduct analizado y en base a las
definiciones dadas en la Sección 2.3.4 se completa la siguiente tabla:
TWPn
TWP1
TWP2
Total
…
Impactados y Predecidos
Resultado Obtenido
No Impactados y No
Predecidos
Impactados y No Predecidos
No Impactados y Predecidos
#CEI #CEITWP1 #CEITWP1 … #CEITWPn #CEI
#TWP #TWP1 #TWP2 … #TWPn #TWP
Página 100
[Tipo WP n]
[Tipo WP i]
Total
…
#CEITWP / #TWP … … … …
#CIRTWP / #CEITWP … … … …
Métricas
#CII / #CEI …
[Completar la tabla con los Tipos de workproducts analizados y el

cálculo de las métricas:
1) #CEITWP / #TWP: Ver Sección
6.5
2) #CIRTWP / #CEITWP
Gráficos [Gráficos de Análisis de Impacto – Ver Sección 6.6]
[Dejar constancia de la aceptación o no de los resultados obtenidos por

Conclusiones de la iteración del análisis de impacto. Aclarar si es necesario realizar una
Iteración nueva iteración de análisis de impacto y en caso afirmativo a partir de
que mejora]
6.5 CEITWP vs. TWP
Como se mencionó en la Sección 2.3.5, la métrica CEI vs. SIS analiza,

frente a un determinado cambio, la relación existente entre un conjunto
estimado de impacto y todo el sistema en cuestión.
Uno de los elementos diferenciadores del enfoque presentado es la

necesidad de definir etapas y tipos de workproducts en la actividad de
Configuración de Trazabilidad.
En base a este concepto, se establece una métrica que permite una

comparación entre el conjunto estimado de impacto y el sistema, diferenciada
por tipo de workproduct, logrando así un análisis con resultados más
detallados.
Un conjunto estimado de impacto podría verse como la unión entre los

conjuntos estimados de impacto de los diferentes tipos de workproducts:
CEI = CEI TWP 1 ∪ CEI TWP 2 ∪ ... ∪ CEI TWPn
Página 101
Entonces, el CEI podría compararse mediante diferentes análisis contra

el sistema, siendo los tipos de workproducts los que definan cada análisis en
particular. Esta comparación queda establecida mediante la siguiente métrica:
CEITWP
CEITWPvs.TWP = Donde TWP es el tipo de workproduct elegido
TWP
para la comparación.
Esta métrica permite tomar decisiones acertadas al momento de realizar

análisis de impacto ya que se basa en información de trazabilidad
granular descomponiendo al sistema en tipos de workproducts.
6.6 CIRTWP vs. CEITWP
Siguiendo los criterios establecidos en la métrica anteriormente tratada

(CEITWP vs. TWP), se define una nueva métrica para comparar el CIR y el CEI
por tipo de workproduct.
Se obtiene la siguiente ecuación:

Donde TWP es el tipo de workproduct

analizado.
Esta métrica permitirá obtener un valor representativo de la eficiencia del

Análisis de Impacto realizado, comparando el CIR y el CEI a nivel de tipo de
workproduct.
6.7 Gráficos de Impacto
En muchas ocasiones, utilizar gráficos (barra, torta, lineales, etc.) para

analizar los resultados obtenidos al aplicar cierta técnica o metodología puede
convertirse en un asistente ideal para la toma de decisiones.
Es por esto que en esta sección se plantean y explican ciertos gráficos

de utilidad para determinar diferentes aspectos acerca de los resultados
arrojados por el Análisis de Impacto que se esté llevando adelante.
Página 102
6.7.1 Distribución del CEI según distancia de impacto
Como ya se menciono, el impacto debido a un cambio se propaga por

los workproducts en forma de ripple, definiendo a la distancia de impacto
como la cantidad de trazas que el efecto de ripple atraviesa a medida que
avanza. Es decir, se inicia con una distancia igual a cero en los workproducts
de origen de impacto o conjunto inicialmente impactado (CII), y a medida que
el impacto se propaga a través de las trazas documentadas la distancia de
impacto se incrementa.
La idea es graficar la distribución del impacto discriminada por tipo de

workproduct (eje Y) según la distancia de impacto (eje X).
En la práctica este gráfico aportó la siguiente información:
1) distancias con mayor y menor impacto,
2) para una distancia en particular la distribución de

impacto según el tipo de workproduct.
A continuación se presenta un ejemplo del gráfico:
Distribución de CEI según Distancia de Impacto
50
45
40
35
30
CEI
25
20
15
10
5
0
0 1 2 3 4 5 6 7 8 9 10 11
Distancia
Requerimiento Caso de Uso Decision Diseño

Implementacion Vista Implementacion Control Implementacion Modelo
Implementacion Infraestructura
Página 103
6.7.2 Distribución del CEI según Tipo de Workproduct
Otro punto interesante a observar de un CEI es el impacto en cada tipo

de workproduct.
Entre las conclusiones que se pueden obtener de este tipo de gráfico se

mencionan:
1) determinar si el impacto se focaliza sobre un tipo

de workproduct en particular,
2) determinar el esfuerzo necesario para validar o

analizar el CEI para un tipo de workproduct
observando el porcentaje de impacto sobre el
total de workproducts de igual tipo.
La idea del gráfico entonces es brindar una comparación entre la

cantidad de workproducts estimados de ser impactados (CEI) y el total de
workproducts existentes por tipo de workproduct establecido en la
configuración de trazabilidad. Para este fin se graficó en el eje Y la cantidad
de workproducts y en el eje X los diferentes tipos de workproduct.
Distribución del CEI según Tipo de Workproduct
300
Cantidad de Workproducts
250
200
150
100
50
0
a
o
o
so
o
ta
tro
eñ
ur
nt
el
U
is
ct
ie
on
od
is
V
im
de
tr u
D
M
C
r
es
ue
os
io
fra
as
eq
is
ec
In
C
R
Tipos de Workproducts
WorkProducts Impactados Total de WorkProducts
Página 104
6.7.3 CEITWP vs. TWP
Habiendo definido la métrica que compara para un determinado tipo de

workproduct la cantidad estimada de ser impactada frente al total de los
mismos surge el siguiente gráfico.
CEItwp vs. Tipo de Workproduct
0,80
0,70 0,72
0,60
0,50 0,50
0,43
0,40 0,41
0,30 0,3 0,3 0,3 0,3 0,3 0,3 0,3

0,23 0,23 0,22
0,20
0,10
0,00
ño
a
o
so
ur
nt
ta
tro
el
e
U
ct
ie
is
is
on
od
rim
de
ru
V
D
M
C
st
on
ue
ae
so
si
eq
fr
a
ci
In
C
R
e
D
CEI/WP Etapa Valor Referencia
Siendo que la métrica graficada permite conocer la efectividad del

análisis de impacto dependiendo del tipo de workproduct, este gráfico permite
visualizar y conocer de manera rápida los puntos más aceptables y los menos
del mismo. Para este ejemplo, se puede observar que para workproducts de
infraestructura el enfoque no fue muy acertado, existiendo seguramente un
gran efecto de ripple que hizo que la mayoría de workproducts se vean
impactados (0,72). Por el contrario, para workproducts de control, la métrica
arroja un valor de 0,23, por debajo del valor de referencia, sugiriendo un CEI
muy aceptable.
6.7.4 CEI Acumulado por distancia
A medida que la distancia se incrementa, es decir cuando nos alejamos

del conjunto de inicio de impacto (CII) como resultado del efecto ripple, la
cantidad de workproducts incluidos en el conjunto estimado de impacto (CEI)
o bien se mantiene constante o crece en su magnitud.
Ahora bien, si dicho crecimiento se produce en forma abrupta al

incrementar la distancia en una unidad, significa que el efecto ripple es tal que
Página 105
el impacto obtenido va a cubrir gran parte del sistema, situación que como ya
se mencionó no es para nada deseable en un análisis de impacto.
Por el contrario, si el CEI presenta un crecimiento leve desde la menor

distancia hasta la máxima, se puede afirmar con mayor seguridad de estar
frente a un CEI con mayor veracidad.
Concluyendo, este gráfico permite identificar los puntos en donde se

presentan dichos crecimientos abruptos. Una vez identificados, se podrán
tomar decisiones para recortar el CEI hasta la distancia en donde se produce
el pico de crecimiento, quedándonos con la porción más útil.
CEI Acumulado por distancia
70
60
50
CEI Acumulado
40
30
20
10
0
0 1 2 3 4 5 6 7 8 9 10 11
Distancia
Requerimiento Casos de Uso Decision Diseño Vista

Control Modelo Infraestructura
A modo de ejemplo, en base al gráfico presentado, se puede concluir

que:
1) el CEI de workproducts de modelo es útil hasta una

distancia no mayor a 5 teniendo quizás que
Página 106
descartar al resto del conjunto para llegar a datos

más precisos,
2) los requerimientos presentan un efecto ripple casi

nulo pudiendo significar una gran veracidad en su
estimación de impacto.
6.7.5 CEITWP vs. CIRTWP
En base a la métrica que compara el CIR contra el CEI por tipo de

workproduct (Sección 6.6), surge el siguiente gráfico:
1,6
1,4
1,2
1
CEI=CIR
0,8 CEI>>CIR
0,6 CEI<<CIR
CIR/CEI
0,4
0,2
0
TWP1 TWP2 TWP3 TWP4 TWP5 TWP6 TWP7
Este gráfico permite conocer la eficiencia de un análisis de impacto al

comparar que tanto se asemeja el CEI al CIR. Al definir las constantes H y M,
definidas en la Sección 2.3.5, quedan definidos los siguientes rangos de
valores:
i. [0, M] CEI >> CIR: Estimación “segura”. Pero gran

esfuerzo para chequear el CEI.
ii. (M, 1) CEI > CIR: Estimación “segura”. Además CEI no

tan mayor al CIR.
iii. 1 CEI = CIR: Situación ideal.
Página 107
iv. (1, H) CEI < CIR: Estimación esperada. El AI es

aproximado y se queda corto a lo que realmente debe ser
modificado.
v. [H,∞] CEI << CIR: Estimación no muy buena. Gran salto

entre lo estimado y lo realmente impactado, significando un
trabajo extra para descubrir el CIR.
A partir de este gráfico es fácil conocer la eficiencia de un análisis de

impacto en cada tipo de workproduct analizado. Se busca que las
estimaciones se encuentren en los rangos 2, 3 o 4 y nunca en los extremos 1
o 5.
Página 108
7 AIT - Herramienta de Soporte
En este capítulo se presenta a ImpactTrace, una herramienta que sirve

de soporte al proceso AIT.
El desarrollo de esta herramienta surgió en base a perseguir los

siguientes objetivos:
1) concentrar la documentación de trazabilidad en un

solo lugar facilitando su acceso a cualquier
stakeholder involucrado en un proyecto de software,
2) minimizar el esfuerzo requerido para realizar las

tareas propias del proceso AIT en relación al
beneficio obtenido,
3) maximizar la eficiencia con que dicho proceso es

llevado adelante,
4) permitir obtener de manera ágil y rápida diferentes

resultados de análisis de impacto.
Este capítulo está organizado de la siguiente manera:
Página 109
1) Sección 8.1 describe la arquitectura de la

herramienta, dando detalles de la tecnología y
frameworks utilizados para su construcción.
2) Sección 8.2 detalla cada clase involucrada en el

dominio de la solución. Se presenta el
correspondiente diagrama de clases.
3) Sección 8.3 ejemplifica cada funcionalidad ofrecida

por la herramienta.
7.1 Arquitectura
ImpactTrace es una herramienta construida sobre plataforma Web en

lenguaje Java.
La persistencia de las clases de dominio se implementó utilizando el

framework Hibernate (www.hibernate.org/), logrando independizar en gran
medida a la aplicación del motor de base de datos sobre la cual quiera
implantarse.
El patrón de diseño MVC fue implementado mediante el framework

Struts (http://struts.apache.org/).
Otros de los frameworks utilizados para este desarrollo fueron:
1) Prefuse (http://prefuse.org): toolkit para la

visualización de información de manera dinámica e
interactiva. Fue utilizado para la generación de
grafos de impacto.
2) JFreeChart (http://www.jfree.org/jfreechart/): librería

Java para la generación de gráficos estadísticos de
varios tipos. Utilizado para graficar resultados de
análisis de impacto.
Página 110
sis de Impacto basado en información de trazabilidad
Análisis Tesista:: Martín de la Rosa
Universidad de Buenos Aires – Facultad de Ingeniería Tutor:: Lic. Pablo Cosso
7.2 Clases de Dominio
Clase Descripción
Modela un workproduct.
Atributos:
- traces: colección de trazas hacia delante.
Workproduct
- backwardTraces: colección de trazas hacia atrás.
- phase: fase/etapa a la que pertenece.
- type: identifica su tipo.
Modela una dependencia entre dos workproducts. Dicha dependencia

modela el impacto que un workproduct origen puede tener sobre un
workproduct destino.
Atributos
Trace
- sourceWP: workproduct origen de la traza.
- targetWP: workproduct destino de la traza.
- extractedBy: agregación con el extractor que dio origen a esta traza.
Modela un tipo de workproduct en particular.

Atributos:
WPType
- extractors: colección de extractores capaces dar origen a este tipo de
workproducts.
Clase abstracta que modela un tipo de extractor. Los tipos de

extractores podrán ser de trazas o workproducts. Instancias de esta
clase servirán al momento de definir los extractores de un proyecto.
ExtractorType Atributos:
- implementationClass: clase concreta que implementa un extractor de
workproducts o un extractor de trazas. Esta clase será instanciada en
tiempo de ejecución para la correspondiente extracción.
Modela un tipo de extractor de workproducts. El usuario al definir

extractores de workproducts de un proyecto estará creando instancias
WPExtractorType
de esta clase y señalando la implementación concreta del extractor a
través del atributo implementationClass.
Modela un tipo de extractor de trazas. El usuario al definir extractores

de trazas de un proyecto estará creando instancias de esta clase y
TraceExtractorType
señalando la implementación concreta del extractor a través del atributo
implementationClass.
Interfaz que deberá ser implementada para proveer a la plataforma de

un nuevo extractor de workproducts.
WPExtractor Métodos:
- Vector<Workproduct> getWorkProducts(): devuelve un vector de
workproducts extraídos.
Interfaz que deberá ser implementada para proveer a la plataforma de

un nuevo extractor de trazas.
TraceExtractor
Métodos:
- Vector<Trace> getTraces(): devuelve un vector de trazas extraídas.
Modela los diferentes tipos de fases/etapas que pueden encontrarse en

un proyecto de software. Al momento de configurar la trazabilidad, el
PhaseType
usuario indicará para cada tipo de fase los tipos de workproducts con
los que cuenta.
Modela una fase en particular de un proyecto.

Phase Atributos:
- workproducts: colección de workproducts propios de esta fase.
Modela un proyecto. Es el punto de partida para la configuración de

trazabilidad.
Atributos:
Project
- users: stakeholders asociados al proyecto con sus respectivos roles
dentro del mismo.
- phases: fases/etapas propias del proyecto.
Modela un stakeholder de un proyecto. Cada usuario podrá estar

User
asociado a uno o mas proyectos con un respectivo rol.
Página 112
7.3 Funcionalidades
ImpactTrace fue diseñado y desarrollado con la idea de llevar a la

práctica todos los detalles de las actividades del proceso AIT. En esta sección
se cubren las siguientes funcionalidades, que hacen de la herramienta un
elemento de soporte fundamental para AIT:
1) Visualización de trazabilidad
2) Documentación de requerimientos de cambio
3) Obtención de gráficos y métricas
4) Consolidación de información de trazabilidad
5) Configuración de Trazabilidad
6) Configuración de Extractores
7) Análisis de impacto iterativo
7.3.1 Visualización de trazabilidad
Ciertas herramientas del mercado ofrecen funcionalidades para

documentar las trazas de un sistema (Sección 2.5). A la hora de brindar al
usuario capacidades para la visualización de las mismas, es común
encontrarse con matrices de trazabilidad de doble entrada. Por lo general, el
usuario selecciona un workproduct en particular y posteriormente la
herramienta genera la matriz de trazabilidad con el resto de workproducts
dependientes.
En la siguiente figura se visualiza un ejemplo de matriz de trazabilidad

entre requerimientos y casos de uso:
Página 113
Caso de Uso 1
Caso de Uso 2
Caso de Uso 3
Caso de Uso 4
Caso de Uso 5
Caso de Uso 6
Caso de Uso 7
Caso de Uso 8
Requerimiento 1 X X X X X X
Requerimiento 2
Requerimiento 3 X X
Requerimiento 4 X
Requerimiento 5 X
Cada X en un casillero simboliza una traza; en este caso desde un

requerimiento a un caso de uso. Por ejemplo el Requerimiento 3 traza a los
Casos de Uso 2 y 4.
Estas matrices aportan una visión estática y de poca utilidad al momento

de visualizar las trazas. Se habla de una visión estática debido a que no es
posible navegar desde un workproduct a otro de manera de ir observando el
impacto en progreso.
Por lo tanto, el esfuerzo requerido para analizar el impacto originado

sobre un workproduct se torna tan significativo, que finalmente resulta
imposible realizar análisis de impacto durante el ciclo de vida del proyecto.
A modo diferenciador, ImpactTrace ofrece la navegación de grafos de

impacto que permite entre otras cuestiones una visión dinámica e intuitiva de
las trazas.
Las uniones capturadas por los grafos proporcionan una base para la
medición y toma de conocimiento acerca de las relaciones entre workproducts
(Bohner, Change Impact Analysis for Design Evolution, 1996).
Página 114
Así, el proceso de análisis de impacto debe estar soportado

por una herramienta que permita la navegación de grafos de
impacto.
A continuación se enumeran las diferentes características que se

siguieron para la construcción de esta funcionalidad de navegación. Estas
premisas fueron pensadas con la idea de facilitar la visualización de trazas y
navegación a través de las mismas; y como consecuencia mejorar el proceso
de análisis de impacto.
Elementos del grafo
Un grafo está integrado por dos tipos de elementos: nodos y aristas. Los
nodos serán los responsables de representar a los workproducts del modelo y
las aristas a las trazas existentes entre los mismos.
Es importante destacar el uso de aristas direccionales que nos permitan

denotar el impacto de un workproduct sobre otro debido al efecto de ripple. Es
decir, cada arista relacionará dos workproducts, siendo uno el que origina el
impacto (workproduct origen), y otro el que es impactado (workproduct
destino).
Visualización en base al perfil / rol del usuario
Los workproducts pertenecientes a diferentes etapas (análisis, diseño,

implementación) deberán ser identificados en el grafo con facilidad. Esto nos
permitirá que el usuario que analice el impacto, se concentre específicamente
en el área de su interés. Por ejemplo, para alguien que se desempeñe con el
rol de Analista de un equipo de trabajo, lo más seguro es que solo le interese
Página 115
visualizar la etapa de análisis, dejando de lado el resto de workproducts.

Mientras que un arquitecto o desarrollador, se verá más involucrado en ver
como un cambio puede impactar el diseño o implementación del sistema.
Distancia de visualización
Para evitar que el grafo se transforme en una “tela de araña” de nodos y

relaciones que haga imposible la identificación de workproducts impactados
se tendrá en cuenta la distancia de visualización.
La distancia de visualización estará definida por la cantidad de trazas

que se deben atravesar para poder llegar desde un workproduct a otro.
En la figura se muestran las distancias referidas a partir del workproduct

WP1.
La herramienta permite, mientras se visualiza el grafo de impacto,

establecer dinámicamente la distancia de impacto que se desea tener en
cuenta.
Selección de workproducts inicialmente impactados
Los grafos son creados a partir del conjunto de workproducts

inicialmente impactados seleccionados por el usuario. Se cree que un grafo
que muestre todas las trazas del sistema carece de valor alguno, debido a
que puede resultar en una tela de araña de nodos y relaciones que dificulte la
identificación de workproducts.
Página 116
Dinámica del grafo
El proceso de identificación de workproducts impactados es calculado a

través del efecto ripple a partir de los workproducts inicialmente impactados.
El resultado obtenido al aplicar el efecto ripple puede ser modificado de

manera interactiva por el usuario, permitiendo agregar o quitar workproducts
al conjunto de impacto. De esta manera, el grafo desarrollado es dinámico y
permite la interacción del usuario.
7.3.2 Documentación de Requerimientos de Cambio
Los requerimientos de cambio, en adelante RC, deben quedar

asentados y correctamente documentados, no solo para servir de input al
análisis de impacto, sino también para futuras revisiones.
AIT establece un template para la especificación de los RC (Sección

6.3). Mediante dicho template ImpactTrace permite al usuario documentar
todos los atributos de un RC. Para un RC en particular, además de su
información, permite la carga de diferentes Análisis de Impacto llevados a
cabo, sus respectivos resultados (métricas, gráficos, workproducts incluidos
en el CEI) y el CIR resultante.
La documentación de un RC en ImpactTrace termina siendo la

composición de:
1) Atributos de especificación de AIT.
2) Uno o más análisis de impacto con sus respectivos

conjuntos estimados de impacto (CEI).
3) Conjunto de Impacto Real (CIR).
En base al lineamiento dado “para cada cambio se debe realizar una

revisión en el repositorio” (Sección 3.3), sería interesante incluir en una futura
versión de ImpactTrace la posibilidad de extraer de manera automática el CIR
desde el repositorio de versiones, no requiriendo esfuerzo humano y
eliminando toda posibilidad de error en su carga.
Página 117
7.3.3 Obtención de gráficos y métricas
ImpactTrace permite obtener en forma instantánea los gráficos

explicados en la Sección 6.6:
1) #CEITWP / #TWP
2) #CEI según distancia
3) #CEI según tipo de workproduct
4) #CEI acumulado por distancia
5) #CIR / #CEI
Como se explicó anteriormente, cada uno de estos gráficos aportan

datos al usuario para la toma de decisiones entre iteraciones de Análisis de
Impacto.
ImpactTrace permite además obtener los valores de las métricas: ripple,

in-degree y out-degree2.4.
7.3.4 Consolidación de información de trazabilidad
La eficiencia del análisis de impacto estará dada en gran medida por la

información de trazabilidad utilizada por el usuario al momento de tomar
decisiones. Dicha información además de estar actualizada y ser precisa,
debe poder ser consultada en forma ágil. Es inadmisible que un usuario al
momento de seleccionar el conjunto de inicio de impacto (CII) para un
determinado requerimiento de cambio tenga que abrir la IDE para consultar el
código de una clase, o bien acceder a la herramienta UML para conocer la
especificación de un Caso de Uso.
AIT a través de ImpactTrace establece que toda la información se

encuentre consolidada en un solo lugar, facilitando el acceso a todos los
agentes.
Así, ImpactTrace permite el almacenamiento de atributos “custom” para

los workproducts. Dichos atributos pueden incluir:
Página 118
1) Cualquier información textual (ej. especificaciones

de caso de uso)
2) Links a cualquier URL (ej. capturas de pantalla,

herramientas de Cross-Reference para la visualización
de código, etc.)
7.3.5 Configuración de Trazabilidad
ImpactTrace permite la configuración de trazabilidad mediante:
1) Configuración de múltiples proyectos y los usuarios

que intervienen en cada uno.
2) Configuración de etapas.
3) Configuración de tipos de workproducts por etapa.
7.3.6 Configuración de Extractores
Una vez desarrollado un nuevo extractor de trazabilidad (implementando

la interfaz TraceExtractor o WPExtractor), ImpactTrace permite agregarlo a la
configuración de un proyecto. Para esto el usuario debe indicar:
1) La clase que lo implementa.
2) Tipos de Workproducts / Trazas que extrae.
3) Posibilidad de atributos “custom”.
Los atributos “custom” permiten indicar parámetros de configuración a

cada extractor. Por ejemplo a un extractor de trazabilidad de componentes de
infraestructura de base de datos es necesario indicarle la URL de conexión, el
usuario y clave para el acceso a la misma.
7.3.7 Análisis de impacto iterativo
La herramienta implementa todas las características del análisis de

impacto iterativo descripto en la Sección 6.1, permitiendo al usuario:
1) Seleccionar el conjunto de inicio de impacto (CII).
Página 119
2) Seleccionar los tipos de workproducts sobre los cuales se

aplicará el análisis.
3) Seleccionar el tipo de trazabilidad (forward/backward) a

utilizar.
4) Realizar las iteraciones necesarias para llegar al conjunto

estimado de impacto (CEI) final, permitiendo descartar
workproducts del análisis, visualizar métricas, gráficos, etc.
Página 120
8 Caso Práctico I
En este capítulo se muestran los resultados obtenidos de implementar el

proceso AIT sobre un proyecto de software determinado. Se analizarán los
puntos favorables de utilizar este enfoque, las conclusiones a las que se
arribó y las dificultades encontradas.
Aconsejamos la lectura del Anexo 11.1 para conocer los detalles del
proyecto, de manera de lograr entender con mayor facilidad los detalles y
ejemplos presentados en esta sección acerca de como se implemento el
modelo de trazabilidad sobre el que se basó el Análisis de Impacto.
8.1 Paralelismo con el Proceso RUP
Como se mencionó anteriormente, AIT debe ser ejecutado

paralelamente al propio proceso del proyecto, siendo RUP el utilizado en este
caso práctico.
Página 121
En la siguiente figura se detalla el paralelismo entre ambos procesos,

pudiendo observar en qué fase de RUP se desarrolló cada una de las
actividades del proceso AIT.
Proceso AIT implementado sobre RUP

Fase Actividad Proceso AIT
Concepción
Configuración de
Trazabilidad Definición de
Extractores Traspaso de
Elaboración Conocimiento
Construcción Identificación Revisión
Transición
Análisis de
Impacto
Producción
t
El proceso RUP puede ser extendido con una fase denominada

Producción. El objetivo de esta fase es mantener el sistema funcionando y en
estado productivo luego de ser implantados (Ambler, Nalbone, & Vizdos,
2007). Será durante esta fase cuando surgen los requerimientos de cambio
que requieren de la actividad de Análisis de Impacto del proceso AIT.
A continuación presentamos, por medio de la tabla detallada en la

Sección 4.1.3, la configuración de trazabilidad utilizada en este proyecto.
Página 122
Decisión Diseño
Requerimiento
Infraestructura
Caso de Uso
Modelo
Control
Vista
Requerimiento 0..n 1..n 0 0 0 0 0
Caso de Uso 0 0..n 0..n 1..n 0 0 0
Decisión Diseño 0 0 0..n 0..n 0..n 0..n 0..n
Vista 0 0 0 0..n 0..n 0 0
Control 0 0 0 0 0..n 0..n 0
Modelo 0 0 0 0 0 0..n 0..n
Infraestructura 0 0 0 0 0 0 0..n
A fin de detallar con mayor claridad cada tipo de workproduct identificado

en la configuración establecida, en la siguiente tabla se especifica para cada
uno de ellos su modo de implementación.
Tipo Workproduct Implementación
Requerimiento Requerimiento Enterprise Architect
Caso de Uso Caso de Uso Enterprise Architect
Decisión de Diseño Decisión Diseño ImpactTrace
Java Server Pages

Vista
Struts Action Forms
Struts Action Classes

Control
Struts Action Methods
JAVA Classes
Modelo
JAVA Methods
JAVA Classes
Infraestructura
JAVA Methods
Página 123
8.3 Extractores de Trazabilidad
Para este caso práctico se han implementado y utilizado la mayoría de

extractores de trazabilidad presentados en el Capítulo 5. Se aconseja su
lectura para un mayor detalle.
8.4 Traspaso de conocimiento al equipo de proyecto
Una vez configurada la trazabilidad y extractores propios al proyecto,

resta definir las responsabilidades de cada miembro / rol del equipo para
poder llevar adelante el proceso.
Como se menciona en el Anexo 11.1, el equipo de proyecto fué

integrado por tres personas: un analista, un arquitecto y un desarrollador.
La siguiente tabla detalla los roles responsables de la identificación de

los workproducts y trazas configurados.
Rol Workproducts Trazas
Requerimiento – Requerimiento
Requerimiento Requerimiento – Caso de Uso
Analista
Caso de Uso Caso de Uso – Caso de Uso
Caso de Uso – Vista
Caso de Uso – Decisión de Diseño

Decisión de Diseño – Decisión de Diseño
Decisión de Diseño – Vista
Arquitecto Decisión de Diseño
Decisión de Diseño – Control
Decisión de Diseño – Modelo
Decisión de Diseño – Infraestructura
Vista – Vista
Vista – Control
Implementación Vista
Control – Control
Implementación Control
Desarrollador Control – Modelo
Implementación Modelo
Modelo – Modelo
Implementación Infraestructura
Modelo – Infraestructura
Infraestructura - Infraestructura
Página 124
8.5 Identificación de trazas y workproducts
En esta sección se presentan los datos de trazabilidad recolectados

durante el desarrollo del proyecto.
Tipos de Workproducts identificados y cantidades respectivas
Tipo de Workproduct Cantidad identificada
Requerimiento 22
Caso de Uso 54
Decisión de Diseño 2
Implementación Vista 151
Implementación Control 255
Implementación Modelo 138
Implementación Infraestructura 32
TOTAL WORKPRODUCTS 654
Trazas identificadas y cantidades respectivas
Id Traza Workproduct Workproduct Cantidad

Origen Destino identificada
1 Requerimiento Requerimiento 14
2 Requerimiento Caso de Uso 27
3 Caso de Uso Caso de Uso 43
4 Decisión de Decisión de 0
Diseño Diseño
5 Vista Vista 30
6 Vista Control 322
7 Control Control 189
8 Control Modelo 661
9 Modelo Modelo 116
Página 125
10 Modelo Infraestructura 35
11 Infraestructura Infraestructura 1
12 Caso de Uso Decisión de 2

Diseño
13 Caso de Uso Vista 53
14 Decisión de Vista 0
Diseño
15 Decisión de Control 1
Diseño
16 Decisión de Modelo 1
Diseño
17 Decisión de Infraestructura 1
Diseño
18 Vista Modelo 12
TOTAL TRAZAS 1508
Es importante resaltar la existencia de 12 (doce) trazas existentes entre

workproducts vista y workproducts modelo. Las trazas entre estos dos tipos
de workproducts no fueron clasificadas como posibles en el paso de
configuración de trazabilidad del proceso. Se considera como un error de
diseño / desarrollo que se pasó por alto al momento de las inspecciones.
Ahora bien, a fines prácticos y demostrativos se tomarán en cuenta dichas
trazas para evitar tener que realizar un refactoring de lo implementado.
En esta sección se propone a modo demostrativo ciertos cambios que se

plantearon al proyecto analizando el impacto de cada uno de ellos en base a
los lineamientos establecidos por AIT.
Página 126
Cambio No. 1
Identificación Cambio 001
Agregar a la creación/edición de promociones textos de

ayuda (tooltips). Se desea poder incluir en una promoción,
por cada campo editable, un texto de ayuda asociado al
Enunciado
campo, de manera que cuando el usuario se posicione con
el mouse en dicho campo, aparezca el texto de ayuda
asociado.
Clasificación Agregado de funcionalidad
Se editará cada workproduct de interfaz (.jsp), y para cada

Posible implementación del
control editable se agregará el tooltip mediante código
cambio
HTML.
Página 127
Identificación del
Cambio 001 / 1
Propósito del Análisis Identificar todas las interfases relacionadas a la creación y edición
de Impacto de promociones.
Tipos de - Requerimiento
Workproducts
Analizados - Vista
Tipos de Trazas
- Trazas forward
utilizadas
Conjunto de Inicio de
- R624: Requerimiento Promociones
Impacto (CII)
Requerimiento
Vista
Total
Impactados y Predecidos 2 22 24
Resultado Obtenido No Impactados y No Predecidos 17 107 124
Impactados y No Predecidos 0 0 0
No Impactados y Predecidos 3 22 25
#CEI 5 44 49
#TWP 22 151 173

Requerimiento
Vista
Total
Métricas
#CEI / #TWP 0.227 0.291 0.283
#CIR / #CEI 0.4 0.5 0.49
#CII / #CEI 0.002
Página 128
Gráficos
Conclusiones de Los valores de #CEI / #TWP son todos aceptables. No se requiere de otra
Iteración iteración.
Página 129
Cambio No. 2
Generación de archivos de promociones por sucursal.

Actualmente la generación de archivos de promociones se
Enunciado realiza para todas las sucursales a la vez. Se desea la
posibilidad de que en la generación manual pueda
seleccionarse para una o varias sucursales.
Este cambio afectará:

- interfaz de generación manual de archivos de
promociones agregándose un combo-box para la
Posible implementación del selección de la sucursal que se quiere,
cambio - control asociado a la interfaz de manera de controlar
la selección de la sucursal, y
- clases de modelo afectadas a la generación de
archivos de promociones.
Página 130
Identificación del
Cambio / Iteración Cambio 002 / 1
Nro.
Propósito del Identificar la interfaz de generación manual de archivo de

Análisis de promociones, el control propio a la misma, y las clases de modelo
Impacto relacionadas.
- Requerimientos
- Casos de Uso
Tipos de
Workproducts - Implementación Vista
Analizados
- Implementación Control
- Implementación Modelo
Tipos de Trazas
- Trazas forward
utilizadas
Conjunto de Inicio - R633: Requerimiento Generación Manual de archivos de

de Impacto (CII) promociones
Requerimiento
Caso de Uso
Control
Modelo
Vista
Total
Impactados y Predecidos 1 1 1 1 1 5
No Impactados y No
Resultado Predecidos
21 53 150 253 90 567
Obtenido
Impactados y No
0 0 0 0 0 0
Predecidos
No Impactados y
0 0 0 1 47 48
Predecidos
#CEI 1 1 1 2 48 53
#TWP 22 54 151 255 138 620

Requerimiento
Caso de Uso
Control
Modelo
Vista
Total
Métricas
#CEI / #TWP 0.045 0.019 0.007 0.008 0.348 0.085
#CIR / #CEI 1 1 1 0.5 0.02 0.094
#CII / #CEI 0.019
Página 131
Gráficos
Valores de #CEI / #TWP aceptables excepto para los workproducts del

tipo Modelo (0.348). Observando el gráfico CEI Acumulado Según
Conclusiones de
Distancia se nota un ripple marcado a partir de distancia 4.
Iteración
Proponemos una nueva iteración quedándonos con datos de impacto
hasta una distancia 4 inclusive.
Página 132
Identificación del
Cambio 002 / 2
Analizar impacto hasta distancia igual a 4 inclusive.
de la iteración
Identificar la interfaz de generación manual de archivos de

promociones, el control propio a la misma, y las clases de modelo
de Impacto
relacionadas.
- Requerimientos
- Casos de Uso
Tipos de
Analizados
Tipos de Trazas
- Trazas forward
utilizadas
Conjunto de Inicio de - R633: Requerimiento Generación Manual archivos de

Impacto (CII) promociones
Requerimiento
Caso de Uso
Control
Modelo
Vista
Total
Impactados y
1 1 1 1 1 5
Predecidos
No Impactados y No
Resultado Obtenido Predecidos
21 53 150 253 136 613
Impactados y No
0 0 0 0 0 0
Predecidos
No Impactados y
0 0 0 1 1 2
Predecidos
#CEI 1 1 1 2 2 7
#TWP 22 54 151 255 138 620
Página 133
Requerimiento
Caso de Uso
Control
Modelo
Vista
Total
Métricas
#CEI / #TWP 0.045 0.019 0.007 0.008 0.014 0.011
#CIR / #CEI 1 1 1 0.5 0.5 0.094
#CII / #CEI 0.143
Gráficos
Conclusiones de Valores de #CEI / #TWP aceptables. No se requiere de una

Iteración siguiente iteración.
Página 134
Cambio No. 3
Asignación de sucursales y grupos de sucursales a Perfiles

de Usuario. Así, un usuario solo podrá crear promociones
para las sucursales asociadas a su perfil.
Consideraciones:
- La asignación de sucursales y grupos de sucursales a
Enunciado perfiles se hará desde la interfaz de Perfiles y no al
revés.
- Los reportes no serán modificados, de tal forma que
cualquier usuario podrá ver las promociones para
todas las sucursales, más allá de las asignadas a su
perfil.
Este cambio afectará:

- Interfaz y controles propios de la interfaz de
administración de perfiles.
Posible implementación del
cambio - Interfaz y controles propios de la interfaz donde se
asocia una promoción a una sucursal.
- Clase de Modelo de Perfil de Usuario agregándole
una asociación a las sucursales.
Página 135
Identificación del
Cambio 003.a / 1
Propósito del Análisis Identificar interfaces y controles impactados de la administración

de Impacto de perfiles.
- Requerimientos
Tipos de
Analizados
Tipo de trazas
- Trazas forward
utilizadas
Conjunto de Inicio de - R619: Requerimiento Administración de perfiles, usuarios

Impacto (CII) y permisos.
Requerimiento
Control
Vista
Total
Impactados y Predecidos 1 1 3 5
Resultado Obtenido No Impactados y No Predecidos 21 150 250 421
Impactados y No Predecidos 0 0 0 0
No Impactados y Predecidos 0 0 2 2
#CEI 1 1 5 7
#TWP 22 151 255 428

Requerimiento
Control
Vista
Total
Métricas
#CEI / #TWP 0.046 0.007 0.02 0.016
#CIR / #CEI 1 1 0.6 0.714
#CII / #CEI 0.143
Página 136
Gráficos

Página 137
Identificación del
Cambio 003.b / 1
Propósito del Análisis Identificar interfaces y controles impactados en la asociación de

de Impacto sucursales a una promoción.
- Requerimientos
Tipos de - Caso Uso
Workproducts
Analizados - Implementación Vista
Tipo de trazas
- Trazas forward.
utilizadas
Impacto (CII)
Requerimiento
Caso Uso
Control
Vista
Total
Impactados y Predecidos 2 2 1 3 8
Resultado Obtenido No Impactados y No

17 27 107 193 344
Predecidos
Impactados y No Predecidos 0 0 0 0 0
No Impactados y Predecidos 3 25 43 59 130
#CEI 5 27 44 62 138
#TWP 22 54 151 255 482

Requerimiento
Caso Uso
Control
Vista
Total
Métricas
#CEI / #TWP 0.227 0.5 0.291 0.243 0.286
#CIR / #CEI 0.4 0.007 0.023 0.05 0.05
#CII / #CEI 0.007
Página 138
Gráficos
Valor de #CEI / #TWP de Caso de Uso no aceptable. Se requiere

Conclusiones de
una nueva iteración seleccionando con mayor granularidad el CII
Iteración
en base a un análisis de los casos de uso impactados.
Página 139
Identificación del
Cambio 003.b / 2
Parámetros de Entrada Aumentar granularidad de CII descartando del CEI de Caso de Uso de
de iteración iteración 1 los workproducts que se creen no impactados
Propósito del Análisis Identificar interfaces y controles impactados en la asociación de

de Impacto sucursales a una promoción.
- Requerimientos
- Casos de Uso
Tipos de
Analizados
Tipos de Trazas
- Trazas forward
utilizadas
Conjunto de Inicio de - R651: Administración – Alta / Baja / Modificación

Impacto (CII) - CU581: Editar Promoción
- CU601: Asignar Jerarquía / Sucursal a Promoción
Requerimiento
Caso de Uso
Control
Vista
Total

17 52 147 246 462
Predecidos
#CEI 5 2 3 9 19
#TWP 22 54 151 255 482
Página 140
Requerimiento
Caso de Uso
Control
Vista
Total
Métricas
#CEI / #TWP 0.227 0.037 0.02 0.035 0.039
#CIR / #CEI 0.4 1 0.333 0.333 0.421
#CII / #CEI 0.444
Gráficos
Conclusiones de Valores de #CEI / #TWP aceptables. No se requiere de una siguiente

Página 141
Identificación del
Cambio 003.c

Identificar clase de modelo referente a un Perfil de Usuario
de Impacto
Tipos de - Requerimientos
Workproducts
Analizados - Implementación Modelo
Tipo de trazas
- Trazas forward.
utilizadas
Conjunto de Inicio de - R619: Requerimiento Administración de Perfiles, usuarios

Impacto (CII) y permisos
Requerimiento
Modelo
Total
Impactados y Predecidos 1 1 2
Resultado Obtenido No Impactados y No Predecidos 0 0 0
Impactados y No Predecidos 0 0 0
No Impactados y Predecidos 0 32 32
#CEI 1 33 34
#TWP 22 138 160

Requerimiento
Modelo
Total
Métricas
#CEI / #TWP 0.06 0.24 0.212
#CIR / #CEI 1 0.03 0.06
#CII / #CEI 0.03
Página 142
Gráficos

Página 143
Cambio No. 4
Agregar hipervínculos en reportes de promociones. Para

agilizar las consultas, los reportes que listen promociones,
deberían mostrarlas como hipervínculos para acceder a ellas
Enunciado en modo consulta.
Consideraciones:
- No afecta la impresión de reportes
Posible implementación del Este cambio afectará:

cambio - Interfases de reportes de promociones
Página 144
Identificación del
Cambio 004 / 1
Propósito del Análisis Identificar las interfases relacionadas con reportes de

de Impacto promociones
- Requerimientos
Tipos de
Workproducts - Casos de Uso
Analizados
- Vista
Tipo de trazas
- Trazas forward.
utilizadas
- R636: Requerimiento Reportes
Impacto (CII)
Requerimiento
Caso de Uso
Vista
Total
#CEI 1 4 5 10
#TWP 22 54 151 227

Requerimiento
Caso de Uso
Vista
Total
Métricas
#CEI / #TWP 0.045 0.074 0.033 0.044
#CIR / #CEI 1 0.25 0.2 0.3
#CII / #CEI 0.1
Página 145
Gráficos

Página 146
Cambio No. 5
La tabla STRUCTURES posee como clave única el campo

CODE. La clave única debería estar formada por los campos
Enunciado LEVEL_CODE + CODE, ya que en el caso de estructuras
comerciales no jerárquicas, se puede utilizar el mismo
código en dos niveles diferentes.
Clasificación Modificación
Posible implementación del Modificar el archivo XML de mapeo de entidad hibernate

cambio tanto para la entidad Structure como StructureLevel.
Página 147
Identificación del
Cambio 005 / 1
Propósito del Análisis Identificar las interfases y casos de uso posiblemente impactados
de Impacto con la finalidad de realizar testing de regresión.
- Casos de Uso
Tipos de - Vista
Workproducts
Analizados - Modelo
- Infraestructura
Tipo de trazas
- Trazas backward
utilizadas
Conjunto de Inicio de - II568: Implementación Infraestructura StructureHome

Impacto (CII) - II569: Implementación Infraestructura StructureLevelHome
Infraestructura
Caso de Uso
Modelo
Vista
Total
Resultado Obtenido
#CEI 43 76 31 2 152
#TWP 54 151 138 32 375

Infraestructura
Caso de Uso
Modelo
Vista
Total
Métricas
#CEI / #TWP 0.796 0.503 0.225 0.063 0.405
#CII / #CEI 0.013
Gráficos
Página 148
Valores de #CEI / #TWP para nada aceptables. Se observa un gran

Conclusiones de
ripple. Se propone una siguiente iteración partiendo de un análisis
Iteración
del CEI de Modelo.
Página 149
Identificación del
Cambio 005 / 2
Se analiza el CEI de Modelo obtenido en iteración 1 cortando el ripple

hasta una distancia 2 inclusive ya que se observa que el resto de
de la Iteración
workproducts no formarían parte del CIR.
Propósito del Análisis Identificar las interfases y casos de uso posiblemente impactados con
de Impacto la finalidad de realizar testing de regresión.
- Casos de Uso
Tipos de - Vista
Workproducts
Analizados - Modelo
- Infraestructura
Tipo de trazas
- Trazas backward
utilizadas
Conjunto de Inicio de - II568: Implementación Infraestructura StructureHome

Impacto (CII) - II569: Implementación Infraestructura StructureLevelHome
Infraestructura
Caso de Uso
Modelo
Vista
Total
Resultado Obtenido
#CEI 15 11 4 2 32
#TWP 54 151 138 32 375

Infraestructura
Caso de Uso
Modelo
Vista
Total
Métricas
#CEI / #TWP 0.278 0.073 0.029 0.063 0.085
#CII / #CEI 0.063
Gráficos
Página 150
Conclusiones de Valores de #CEI / #TWP aceptables. No se requiere una siguiente

Página 151
Cambio No. 6
Posibilidad de realizar búsquedas sobre grillas de elementos

Enunciado seleccionados (items, departments, manufacturers,
mixmatches)
Agregar a la pantalla de asignación de elementos a

Posible implementación del promociones un radio button para seleccionar si la búsqueda
cambio se realiza sobre elementos seleccionados o no
seleccionados.
Página 152
Identificación del
Cambio 006 / 1

Identificar el impacto sobre workproducts de Etapa Implementación.
de Impacto
- Casos de Uso
- Vista
Tipos de
Workproducts - Control
Analizados
- Modelo
- Infraestructura
Tipo de trazas
- Trazas forward
utilizadas
- CU609: Agregar / Excluir elementos a Promoción
Impacto (CII)
Infraestructura
Caso de Uso
Control
Modelo
Vista
Total

0 0 0 0 0 0
Predecidos
Impactados y No Predecidos 0 0 0 0 0 0
No Impactados y Predecidos 0 0 6 36 17 59
#CEI 1 2 7 37 18 65
#TWP 22 151 255 138 32 598

Infraestructura
Caso de Uso
Control
Modelo
Vista
Total
Métricas
#CEI / #TWP 0.045 0.013 0.027 0.268 0.562 0.109
#CIR / #CEI 1 1 0.143 0.027 0.056 0.092
#CII / #CEI 0.015
Página 153
Gráficos
Valor de #CEI / #TWP de Infraestructura no aceptable. Se propone

Conclusiones de
una siguiente iteración partiendo de un análisis del CEI de Control y
Iteración
Modelo.
Página 154
Identificación del
Cambio 006 / 2
El CEI de Control se reduce a solo el workproduct responsable de

Parámetros de Entrada la búsqueda de elementos (ncr.dpc.action.SearchElement).
de la Iteración Del CEI de Modelo se descarta el workproduct
ncr.dpc.domain.Application por presentar alto ripple.
Propósito del Análisis Identificar el impacto sobre workproducts de Etapa

de Impacto Implementación.
- Casos de Uso
- Vista
Tipos de
Workproducts - Control
Analizados
- Modelo
- Infraestructura
Tipo de trazas
- Trazas forward
utilizadas
- CU609: Agregar / Excluir elementos a Promoción
Impacto (CII)
Infraestructura
Caso de Uso
Control
Modelo
Vista
Total

0 0 0 0 0 0
Predecidos
Impactados y No Predecidos 0 0 0 0 0 0
No Impactados y Predecidos 0 0 0 1 0 1
#CEI 1 2 1 2 1 7
#TWP 22 151 255 138 32 598

Infraestructura
Caso de Uso
Control
Modelo
Vista
Total
Métricas
#CEI / #TWP 0.045 0.013 0.004 0.014 0.031 0.012
#CIR / #CEI 1 1 1 0.5 1 0.857
#CII / #CEI 0.143
Página 155
Gráficos

Página 156
Cambio No. 7
Añadir dos flags adicionales a nivel de promoción (“Aplicar

Enunciado sobre productos iguales” – “Aplicar sobre precio de lista
menos descuentos anteriores”)
- Modificación de la interfaz gráfica de edición

detallada de una promoción, de manera de permitir
Posible implementación del la edición de los valores de dichos flags.
cambio
- Adaptación de la generación de los archivos de
promociones para contemplar dichos flags.
Página 157
Identificación del
Cambio 007.a / 1
Propósito del Análisis Identificar Workproducts Vista y Control referidos a la edición

de Impacto detallada de una promoción.
- Requerimientos
Tipos de - Caso de Uso
Workproducts
Tipo de trazas
- Trazas forward
utilizadas
Impacto (CII)
Requerimiento
Caso de Uso
Control
Vista
Total
Resultado Obtenido No Impactados y No Predecidos 0 0 0 0 0
#CEI 5 27 44 60 136
#TWP 22 54 151 255 482

Requerimiento
Caso de Uso
Control
Vista
Total
Métricas
#CEI / #TWP 0.227 0.5 0.291 0.235 0.282
#CIR / #CEI 0.4 0.037 0.023 0.033 0.044
#CII / #CEI 0.007
Página 158
Gráficos
Conclusiones de Valor de #CEI / #TWP de Caso de Uso no aceptable. Se propone

Iteración una siguiente iteración refinando este CEI.
Página 159
Identificación del
Cambio 007.a / 2
Parámetros de Entrada Se refina el CEI de Requerimiento y Casos de Uso realizando un

de la Iteración análisis detallado de los mismos.
Propósito del Análisis Identificar Workproducts Vista y Control referidos a la edición

de Impacto detallada de una promoción.
- Requerimientos
Tipos de - Caso de Uso
Workproducts
Tipo de trazas
- Trazas forward
utilizadas
Impacto (CII) Requerimiento
Caso de Uso
Control
Vista
Total
Resultado Obtenido No Impactados y No Predecidos 0 0 0 0 0
#CEI 2 2 2 4 10
#TWP 22 54 151 255 482

Requerimiento
Caso de Uso
Control
Vista
Total
Métricas
#CEI / #TWP 0.091 0.037 0.013 0.016 0.021
#CIR / #CEI 1 0.5 0.5 0.5 0.6
#CII / #CEI 0.1
Página 160
Gráficos

Página 161
Identificación del
Cambio 007.b / 1
Propósito del Análisis Identificar workproducts de Modelo respecto a la generación de

de Impacto archivos de promociones
- Requerimiento
Tipos de
Workproducts - Caso de Uso
Analizados
- Modelo
Tipo de trazas
- Trazas forward
utilizadas
- R632: Requerimiento Generación automática de archivos

Conjunto de Inicio de de promociones
Impacto (CII) - R633: Requerimiento Generación manual de archivos de
promociones
Requerimiento
Caso de Uso
Modelo
Total
#CEI 2 2 51 55
#TWP 22 54 138 214

Requerimiento
Caso de Uso
Modelo
Total
Métricas
#CEI / #TWP 0.091 0.037 0.37 0.257
#CIR / #CEI 1 1 0.02 0.091
#CII / #CEI 0.036
Página 162
Gráficos
Conclusiones de Valor de #CEI / #TWP de Modelo no aceptable. Se propone una

Iteración siguiente iteración refinando el CEI de Modelo.
Página 163
Identificación del
Cambio 007.b / 2
Observando el gráfico de Impacto Acumulado Según Distancia

obtenido en Iteración 1, se ve un ripple marcado a partir de la
distancia 2 en adelante. Se refina entonces la distancia 2
de la Iteración
descartando el workproduct ncr.dpc.domain.Application que
presenta alto ripple.
Propósito del Análisis Identificar workproducts de Modelo respecto a la generación de

de Impacto archivos de promociones
- R632: Requerimiento Generación automática de archivos

Conjunto de Inicio de de promociones
Impacto (CII) - R633: Requerimiento Generación manual de archivos de
promociones
- Requerimiento
Tipos de
Workproducts - Caso de Uso
Analizados
- Modelo
Tipo de trazas
- Trazas forward
utilizadas
Requerimiento
Caso de Uso
Modelo
Total

0 0 0 0
Predecidos
#CEI 2 2 31 35
#TWP 22 54 138 214

Requerimiento
Caso de Uso
Modelo
Total
Métricas
#CEI / #TWP 0.091 0.037 0.225 0.164
#CIR / #CEI 1 1 0.032 0.143
#CII / #CEI 0.057
Página 164
Gráficos

8.7 Conclusiones
Sumado a los ejemplos de análisis de impacto presentados, el siguiente

gráfico muestra la distribución de la métrica #CIR/#CEI para cada uno de los
Página 165
cambios analizados. Esto permite tomar conocimiento de la eficiencia de los

resultados obtenidos.
Al observar el gráfico se puede concluir:
- Realizar nuevas iteraciones sobre un análisis de impacto mejoró en todos los

casos la estimación. Esto quiere decir que se obtuvo un #CEI más cercano al
#CIR reduciendo el posterior esfuerzo.
- Solo en un caso se obtuvo un #CIR/#CEI > 1, es decir, existieron

workproducts impactados que no fueron predecidos por AIT. Esta situación
ocurrió por no tener disponible información de trazabilidad para un
workproduct en particular.
- Más de un 40% de lo realmente impactado fue estimado para un 75% de los

casos analizados (#CIR/#CEI > 0,4).
Página 166
9 Caso Práctico II
Este segundo caso práctico demuestra la utilidad de mantener

información de trazabilidad entre workproducts de infraestructura.
A pesar de no estar de acuerdo con el diseño de muchas aplicaciones,

es muy común que la lógica de negocio resida en procedimientos
almacenados (stored procedures).
Por lo tanto, mantener trazabilidad granular entre dichos componentes

nos servirá para dar respuesta a preguntas como por ejemplo: ¿Qué
módulos/casos de uso utilizan un determinado stored procedure? ¿Qué se
impacta o sobre que debo realizar testing de regresión si se modifica
determinada tabla / stored procedure?
9.1 Generalidades del Proyecto
Al igual que el primer caso práctico, éste también se trata de un

desarrollo Web. Para el mismo se utilizó la siguiente tecnología:
- J2SE 5.0
Página 167
- Framework MVC: Struts
- Framework ORM: Apache OJB
- Base de Datos: Oracle
Para la finalidad de este trabajo se analiza el módulo de consultas del

proyecto. El mismo cuenta con una serie de consultas que permiten a un
usuario la obtención y visualización de información en base a filtros
específicos.
En la siguiente tabla se muestran los tipos de workproducts identificados

en el proyecto discriminados por etapa:
Tipo de
Etapa Implementación Descripción
Workproduct
Cada requerimiento
Especificación del sistema podrá
Consulta Análisis
Word verse como una
consulta.
Pantalla/Subpantalla
de una consulta en
particular. Contiene
Java Server los filtros de
Vista Implementación
Pages (JSP) búsqueda
específicos y la
visualización de
información.
Componentes de
Control Implementación Action Struts control en respuesta
a eventos del usuario
Página 168
Servicio DAO para

Patrón de
ServicioDAO Implementación acceso a base de
Diseño DAO
datos
Agrupamiento de
Paquete de
Paquete Implementación Stored Procedures
Oracle
de Oracle
Procedimiento Procedimiento para

Stored
Implementación Almacenado de resolver cierta lógica
Procedure
Oracle de datos
Tabla para el
Tabla Implementación Tabla de Oracle almacenamiento de
información
A continuación se presenta, por medio de la tabla detallada en la

Sección 4.1.3, la configuración de trazabilidad utilizada en este proyecto.
StoredProcedure
ServicioDAO
Consulta
Paquete
Control
Tabla
Vista
Consulta 0..n 1..n 0 0 0 0 0
Vista 0 0..n 1..n 0 0 0 0
Control 0 0 0..n 0..n 0 0 0
ServicioDAO 0 0 0 0 0..n 0..n 0
Paquete 0 0 0 0 0..n 0 0
StoredProcedure 0 0 0 0 0 0..n 0..n
Tabla 0 0 0 0 0 0 0
Página 169
9.2 Extracción de trazabilidad
En la siguiente tabla se pueden observar los diferentes extractores de

trazabilidad utilizados. Se recomienda la lectura de la Sección 5 para mayor
detalle de cada extractor.
Extractor Información de trazabilidad Tipo de

extraída trazabilidad
No disponible. Se Workproduct: Consultas Explícita

cargó manualmente la
información.
StrutsPresentationExtr Workproduct: Vista Implícita

actor
Struts Control Workproduct: Control Implícita

Extractor
Trazas: Vista-Control
DAOExtractor Workproduct: ServicioDAO Implícita
DependencyExtractor Trazas: Control-ServicioDAO Implícita
DocletExtractor Trazas: ServicioDAO- Explícita

StoredProcedure, ServicioDAO-
Paquete
OracleExtractor Workproducts: Paquetes, Implícita

StoredProcedures, Tablas
Trazas: Paquete-Tabla,
StoredProcedure-Tabla
Página 170
9.3 Identificación de Trazas y Workproducts
Tipos de Workproducts identificados y cantidades respectivas
Tipo de Workproduct Cantidad identificada
Consulta 21
Vista 98
Control 152
ServicioDAO 42
Paquete/StoredProcedure/Tabla 2318
TOTAL WORKPRODUCTS 2631
Trazas identificadas y cantidades respectivas
Id Traza Workproduct Workproduct Destino Cantidad

Origen identificada
1 Consulta Consulta 6
2 Consulta Vista 21
3 Vista Vista 0
4 Vista Control 128
5 Control Control 164
6 Control ServicioDAO 73
7 ServicioDAO Paquete/Stored 54
Procedure/Tabla
8 Paquete/Stored StoredProcedure/Tabla 13606

Procedure
TOTAL TRAZAS 14052
Página 171
En esta sección se proponen a modo demostrativo ciertos cambios que

se plantearon al proyecto analizando el impacto de cada uno de ellos.
Cambio No. 1
Modificación de estructura de la tabla MODELO. Se aumenta

Enunciado
el ancho de la columna de descripción de modelos de autos.
Posible implementación del No Aplica.

cambio
Identificación del
Cambio 001 / 1

Identificar todas las consultas relacionadas con la tabla MODELO.
de Impacto
- Tabla
- Stored Procedure
Tipos de
Workproducts - ServicioDAO
Analizados
- Vista
- Consulta
Tipos de Trazas
- Trazas backward
utilizadas
- II26724: Tabla MODELO
Impacto (CII)
Infraestructura
Requerimiento
Modelo
Total
Métricas
#CEI / #TWP 0.24 0.238 0.52 0.24
Página 172
Gráficos
Los valores de #CEITWP / #TWP son aceptables excepto para el tipo de workproduct
Conclusiones de Requerimiento (Consultas) = 0.52. Por otro lado el #CEI / TWP total es aceptable =
Iteración 0.24. Debido a que este AI es para obtener un CEI de Requerimientos sobre el cual
aplicar testing de regresión no se cree necesario realizar una nueva iteración.
Página 173
Cambio No. 2
Modificación de los parámetros de entrada del Stored

Procedure
CIS_PAGOS_PKG.BORRAR_TEMP_CTOS_PAGOS. Se
Enunciado
agregará un parámetro en el cual deberán indicarse los
conceptos de pago seleccionados por el usuario
concatenados por pipes.
Posible implementación del Modificar ServicioDAO y componentes de control para

cambio invocar al stored procedure con el nuevo parámetro.
Identificación del
Cambio 002

Identificar ServicioDAO y componentes de control a modificar.
de Impacto
- Package
Tipos de
Workproducts - ServicioDAO
Analizados
- Control
Tipos de Trazas
- Trazas backward
utilizadas
- II26724: Package CIS_PAGOS_PKG (Nota: no se contaba

con información del workproduct Stored Procedure:
Impacto (CII)
BORRAR_TEMP_CTOS_PAGOS)
Página 174
ServicioDAO
Package
Control
Total
#CEI 1 2 5 8
#TWP 2318 42 152 2512
ServicioDAO
Package
Control
Total
Métricas
#CEI / #TWP 0.0004 0.048 0.033 0.003
#CIR / #CEI 1 0,5 0.2 0,375
#CII / #CEI 0.000398
Gráficos
Página 175
Conclusiones de Los valores de #CEI / #TWP son todos aceptables. No se requiere de otra
9.5 Conclusiones
Se analizó el impacto para otros cambios similares a los dos ejemplos

planteados y se obtuvieron las siguientes conclusiones.
9.5.1 Cambios del Tipo 1
Uno de los objetivos de este análisis de impacto fue identificar sobre que
requerimientos aplicar testing de regresión frente a cambios en componentes
de infraestructura. Así, se logró que el testing de regresión se enfoque solo a
la porción del sistema referida al CEI, reduciendo el esfuerzo necesario.
Por lo tanto es bueno que el tamaño (cantidad de workproducts) del CEI

de requerimientos obtenido no se acerque al total de workproducts de
requerimientos.
Página 176
En el siguiente gráfico se presenta la distribución de la métrica #CEITWP /

#TWP.
Para diferentes rangos de K = #CEITWP / #TWP se observa:
- Solo 6 workproducts de infraestructura presentan un KREQ >= 0,5. Es decir,

solo si se modificasen alguno de dichos workproducts habría que realizar
testing de regresión a más de un 50% de las consultas del sistema.
- Habría que realizar testing de regresión entre un 30% y 50% de las consultas,
si el CII estuviera integrado por alguno de los 99 workproducts.
- Habría que realizar testing de regresión menor a un 30% para un CII con
cualquiera del resto de los 2213 workproducts de infraestructura.
En conclusión, para la mayoría de cambios de este tipo, el esfuerzo de

realizar testing de regresión es menor o igual a un 30% del total requerido si
no se contara con una metodología de análisis de impacto.
De igual manera, si ponemos atención sobre las vistas (pantallas) a ser

impactadas, solo 6 workproducts de infraestructura provocarían un #CEIVISTA /
#VISTA >= 0,2.
Esto indica que el ripple de la trazabilidad backward utilizado para el

análisis de cambios del tipo 1 es bajo para la mayor cantidad de casos.
Página 177
La distribución anterior nos muestra que la mayoría de estimaciones de

impacto están por debajo de 0,2. Solo para un caso se tiene cierto ripple
provocando que entre un 40% y 45% del total de workproducts analizados
sean estimados de ser impactados.
9.5.2 Cambios del Tipo 2
Se analizaron diez cambios similares a los del tipo 2. Lo interesante para

este tipo de cambio fue comparar el #CEI resultante contra el #CIR para
concluir acerca de la eficiencia de los análisis.
A continuación se gráfica la métrica #CIR/#CEI para cada uno de los

análisis llevados a cabo:
Se concluye:
Página 178
- Para ningún cambio la métrica dio valores mayores a 1, indicando que todo lo
impactado siempre fue estimado. Las estimaciones fueron “seguras”, es decir
no se requirió esfuerzo extra para descubrir workproducts impactados.
- Para 7 cambios la estimación se acerco a lo realmente impactado

(1>#CIR/#CEI>0,6).
- En 3 casos existió un salto entre el #CEI y el #CIR. Esto fue debido al ripple
de trazabilidad presente para los #CII en cuestión.
Página 179
Página 180
10 Conclusiones – Trabajo Futuro
En el contexto de la problemática planteada en el capítulo de

introducción, el presente trabajo propuso al proceso AIT (Análisis de Impacto
basado en Trazabilidad) como el modelo que permite administrar la
información de trazabilidad de un proyecto de software. Este proceso hace
hincapié en documentar la trazabilidad entre los componentes que integran el
proyecto para luego permitir realizar efectivos análisis de impacto.
Como conclusión al presente trabajo se alcanzaron los siguientes

resultados:
• A través de la actividad denominada "Configuración de

Trazabilidad" se permite definir y especificar sobre cuales
componentes de un proyecto de software documentar la
trazabilidad, y de qué manera.
• Ejemplificar posibles configuraciones de trazabilidad para las

metodologías y arquitecturas más utilizadas en la actualidad.
• Automatizar la documentación de trazabilidad mediante la

implementación de extractores de trazabilidad implícita y explícita.
Página 181
• Definir los roles y responsabilidades para cada participante del

proyecto de software de manera que el proceso sea llevado
adelante de forma efectiva.
• Ejemplificar la implementación de extractores de trazabilidad

sobre frameworks y herramientas conocidos.
• Demostración de la efectividad del enfoque en base a la puesta

en práctica del proceso AIT sobre dos casos prácticos, ofreciendo
datos reales de análisis de impacto y comparaciones contra el
impacto real.
• Reducir el esfuerzo necesario para el testing de regresión de los

sistemas en base a una correcta identificación del impacto
generado por un cambio.
• Plantear un análisis de impacto iterativo, mejorando en cada

iteración los resultados obtenidos en base a la utilización de
gráficos y métricas establecidas.
• Establecer vínculos entre las etapas de análisis, diseño y

desarrollo mediante la definición de etapas y tipos de
workproducts para reducir el gap de conocimiento entre las
mismas.
• Investigación de metodologías y herramientas de trazabilidad

existentes en el mercado detectando falencias o diferencias con el
enfoque planteado.
• Desarrollo de una herramienta para dar soporte a todas las

actividades del proceso AIT, desde la documentación de
trazabilidad hasta la realización de análisis de impacto.
Asimismo, a continuación se enumeran una serie de tareas que resultan

de interés estudiar y sientan las pautas para próximos trabajos:
Página 182
- Análisis de métricas de impacto existentes y definición de una que aplique al

proceso AIT.
- “La relación entre la métrica de impacto y el esfuerzo requerido para

desarrollar software permite estimar el esfuerzo requerido para implementar
un cambio” (Lee, 1998). Se toma la frase citada como otro de los objetivos a
trabajar en el futuro para estudiar las posibles relaciones entre resultados de
análisis de impacto y esfuerzo necesario para la implementación de cambios.
- Automatizar la identificación de los workproducts incluidos en el Conjunto de

Inicio de Impacto del análisis de impacto de un requerimiento de cambio. En
el presente trabajo el usuario del proceso AIT es quien debe establecer que
workproducts son inicialmente impactados por un requerimiento de cambio.
Un error en la definición del CII provocaría que el resultante CEI no concuerde
finalmente con el CIR resultante al implementar el cambio.
Página 183
Página 184
11 Anexo
11.1 Anexo I: Detalles del Caso Práctico I
11.1.1 Generalidades del Proyecto
Se trató de un proyecto desarrollado a lo largo de un período de seis

meses. Cabe señalar que el proyecto no sufrió desvíos de su estimación
inicial, tanto en tiempo como en funcionalidad cubierta por el alcance del
mismo.
El equipo de proyecto fue integrado por tres personas, distribuyéndose

los roles de la siguiente manera:
1) Analista / Project Leader: persona involucrada en la

administración del proyecto y análisis del mismo.
2) Arquitecto: persona responsable del diseño y

arquitectura, y desarrollo de componentes con
mayor riesgo tecnológico.
Página 185
3) Desarrollador Senior: persona con perfil de

desarrollador senior, involucrada pura y
exclusivamente en tareas de desarrollo.
El Sistema fue desarrollado íntegramente en lenguaje JAVA, con la

capacidad de ser implantado en cualquier Application Server compatible
con los estándares J2EE. Entre los frameworks utilizados se encuentran:
para la implementación de patrón MVC (Model – View – Controller) se
utilizó Struts y, para la persistencia de clases, Hibernate.
Como herramienta de soporte para el Análisis se utilizó Enterprise

Architect. En la misma se documentaron los requerimientos, casos de
uso e interfases del sistema.
11.1.2 Objetivo del Proyecto
El sistema brinda a personas especializadas en marketing y con

conocimiento de las diferentes necesidades de los clientes de
supermercados, la capacidad de crear una amplia gama de promociones
de productos. Dichas promociones abarcan ofertas patrocinadas por los
fabricantes y sponsors de los diferentes productos. A través de la
implementación del sistema, se obtuvo un aumento en las ventas y
satisfacción por parte de los clientes al ser acreedores de importantes
beneficios en la compra de dichas promociones.
El sistema provee una interfaz gráfica a partir de la cual será posible

crear, modificar y eliminar promociones. Como resultado se generan
archivos que posteriormente se procesan en tiempo real al momento de
la compra en los puntos de venta (POS) para otorgar los beneficios a los
clientes.
La aplicación posee funcionalidad para asignar y distribuir promociones

a diferentes sucursales, especificar restricciones según el perfil del
usuario y, poder efectuar altas, bajas y modificaciones sobre los distintos
parámetros que maneja el sistema.
Página 186
11.1.3 Módulos del sistema
1) Promociones: Este modulo contiene la funcionalidad necesaria

para buscar, crear, eliminar o modificar templates de promociones y
promociones.
2) Administración: Este modulo contiene los ABMs de sucursales,

grupos de sucursales, artículos, departamentos, estructuras
comerciales, medios de pago, categoría de clientes, etc.
3) Seguridad: Este módulo contempla ABM de usuarios, ABM de

perfiles y configuración de parámetros del sistema como ser
cantidad máxima de promociones activas.
4) Monitor de promociones por sucursal: Provee la funcionalidad

necesaria para ver el estado de actualización de las POS de cada
sucursal.
5) Auditoria de Accesos y Operaciones en BD: Este modulo se

encarga de registrar altas, bajas y modificaciones en las tablas del
sistema.
6) Reportes.
7) Generación de Archivos: Provee la funcionalidad para la

generación de los archivos binarios de promociones a ser
procesados por las POS.
11.1.4 Requerimientos del Sistema
A continuación se enumeran los requerimientos del Sistema. Los

mismos fueron extraídos de un documento presentado por el cliente.
Página 187
No. Descripción
1 Restricciones por perfil de usuario
1.1 Control de promociones activas
1.2 Control de carga de artículos y estructuras comerciales
1.3 Administración de perfiles, usuarios y permisos
2 Templates de Promociones
2.1 Administración de Templates
2.2 Campos editables
2.3 Grupo de Templates
3 Promociones
3.1 Listado de Promociones vigentes
3.2 Estado de Promociones
3.3 Importación
4 Jerarquías de sucursales
4.1 Asignación de sucursales a promociones
4.2 Administración de Jerarquías de Sucursales
5 Distribución de promociones en sucursales
5.1 Generación automática de archivos de promociones
5.2 Generación manual de archivos de promociones
6 Control centralizado de envío de promociones a las POS
7 Auditoría
8 Reportes
Página 188
11.2 Anexo II: Framework para proyectos basados en UML

- Herramienta: SharpTrace
La administración de requerimientos y específicamente la trazabilidad de

los mismos, suele ser una actividad costosa. El nivel de detalle y tipo de
información recolectada en estas actividades debe ser configurada en base a
las necesidades específicas del proyecto, con el fin de obtener una relación
ganancia-costo positiva.
(Letelier, 2002) se basa en UML (Unified Modeling Language) como el

medio para establecer un framework común para la especificación de
requerimientos, diseño, y test, que permita una eficiente trazabilidad de
requerimientos.
Dicho modelo tiene las siguientes características:
1) Entidades que cubre: TraceableSpecifications y Stakeholders.
2) Los Stakeholders son los responsables de crear y modificar

especificaciones.
3) Una “especificación trazable” (TraceableSpecification) significa una

especificación de un componente de software con un cierto nivel de
granularidad, pudiendo ser un documento, un diagrama, un texto
especificando un requerimiento no funcional, un caso de uso, una
clase, etc. La granularidad de dicha especificación se encuentra
dada por relaciones del tipo partOf (parte de). Como tipos de
especificaciones, el modelo las separa en especificaciones
racionales (RationaleSpecificacion), de requerimientos
(RequirementSpecification), de casos de prueba (TestSpecification)
y otras especificaciones UML (OtherUML_Specification).
4) Los tipos de trazas (links) que utiliza el modelo son:
a. traceTo: [pre-traceability y post-traceability] es la traza mas

general, utilizada para establecer relaciones entre cualquier
TraceableSpecification.
Página 189
b. modifies: [pre-traceability y post-traceability] establece una

relación entre una entidad Stakeholder que modifica a una
entidad TraceableSpecification.
c. responsibleOf: [pre-traceability y post-traceability] señala al

Stakeholder responsable de la definición y mantenimiento de
una TraceableSpecification.
d. validatedBy: [post-traceability] relaciona una especificación

de requerimiento (RequirementSpecification) con una
especificación de caso de prueba (TestSpecification) que la
valide.
e. verifiedBy: [post-traceability] determina que caso de prueba

(TestSpecification) verifica cierta especificación UML.
f. assignedTo: [post-traceability] indica que componentes del

modelo UML implementan cierto requerimiento, como ser por
ejemplo, las clases que llevan a cabo el comportamiento de
un caso de uso.
5) Establece para cada tipo de entidad y relación, un elemento que le

corresponda del modelo UML. Hace uso de todas las herramientas
de especificación de UML, sumando las extensiones steoreotypes,
tagged values, y constraints para lograr documentos que puedan
ser trazables a lo largo del proyecto.
Todos estos conceptos pueden visualizarse para un mejor entendimiento

en la siguiente figura:
Página 190
Además Letelier define las siguientes principales actividades, dentro de

lo que se considera trazabilidad de requerimientos:
1) Configuración de trazabilidad de acuerdo a las necesidades del

proyecto: comprende seleccionar los tipos de componentes de
software (workproducts) a tener en cuenta, definir sus relaciones de
agregación en caso de existir, establecer los tipos de relaciones
(links o trazas) entre sí, y definir criterios para derivar la trazabilidad
en forma implícita.
2) Especificación y explotación de la información de trazabilidad

durante las etapas de desarrollo y mantenimiento de un
software.
Señala la importancia de establecer atributos y sus posibles valores para

cada tipo de workproduct, que permitan mayor trazabilidad (ej. RUP establece
como atributos para una funcionalidad (software-feature): estado (propuesta,
aprobada, incorporada), beneficio de ser incorporada (crítico, importante, útil),
riesgo y estabilidad (bajo, medio, alto).
Bajo el contexto de este framework surge la herramienta SharpTrace

(Anaya & Letelier, 2002). La misma es un add-in de Rational Rose que
extiende dicha herramienta. Permite a Rational Rose integrar especificaciones
Página 191
UML y no UML, proporcionando un marco común de interpretación para la

información de trazabilidad. SharpTrace permite seleccionar los tipos de
componentes y links con los cuales se trabajará, proporcionando el
subproceso de configuración de trazabilidad.
Página 192
11.3 Anexo III: Trazabilidad Enriquecida - Herramienta:

DOORS
(Dick, 1995) en su publicación destaca la importancia de asociar una

semántica a los links que establecen las relaciones entre los componentes de
software. Con esto, el autor se refiere a que las relaciones deben tener un
significado más profundo que el simple hecho de “cierto componente se verá
impactado frente a un cambio en otro componente”.
Señala que la trazabilidad por medio de matrices, brinda información

poco detallada. Por ejemplo, si un requerimiento de usuario se ve relacionado
con varias funcionalidades a implementar, entonces, ¿qué significan dichas
relaciones? Que todas las funcionalidades son necesarias para cumplir con el
requerimiento, o que solo alguna de ellas es necesaria.
De manera de obtener una mejor trazabilidad, el modelo señala como

necesidad:
1) que las trazas estén acompañadas de algún comentario que

explique la razón de su existencia,
2) un agrupamiento de trazas, permite describir de mejor manera la

relación en las que se encuentran involucradas
3) tipificar los grupos de trazas permite realizar nuevos análisis de

trazabilidad. Un grupo de relaciones puede por ejemplo ser
mutuamente conflictivo, o brindar una respuesta en conjunto.
En este modelo se basa la herramienta DOORS. Telelogic®, empresa

que desarrolla el producto DOORS, fundamenta las ventajas de la utilización
de su producto, en base a las nuevas capacidades que perciben los diferentes
roles de un equipo de proyecto. A fines prácticos de este trabajo,
resaltaremos los dos roles que creemos mas relevantes en cuanto al uso de
la herramienta:
Página 193
1) Ingeniero de Software:
a. Facilidad para la creación de relaciones entre las necesidades

del usuario y componentes que integran el software: la
herramienta permite generar links entre el código y una
especificación textual, como ser el caso de una necesidad o
requerimiento. Dichos links pueden ser utilizados
posteriormente para un análisis de impacto.
b. Agrupar toda la información en un solo lugar: la herramienta es

capaz de extraer información de diferentes lugares, como ser
herramientas de testing o UML, y lograr vincular esa
información.
2) Analista de Requerimientos:
a. Extracción de los puntos clave de los documentos del cliente:

es posible almacenar documentos originales del cliente,
extraer de los mismos los puntos clave, almacenarlos de
manera uniforme para todo el proyecto, y dejar relación entre
los mismos. Por ejemplo, de un documento, se pueden extraer
requerimientos del cliente, y almacenarlos usando los mismos
atributos para todos ellos (id, nombre, descripción, etc.). A su
vez, es posible a partir de un requerimiento, regresar al
documento que lo originó.
Página 194
Plug-in para Microsoft® Word que permite la exportación de información a la plataforma

DOORS.
Página 195
11.4 Anexo IV: Estrategias de trazabilidad basadas en

Casos de Uso - Herramienta: Rational Rose y Rational
RequisitePro
En esta sección se explican diferentes estrategias de trazabilidad,

utilizadas por organizaciones que optan por técnicas de modelado de casos
de uso como parte de su metodología de Administración de Requerimientos.
Todas las estrategias tratadas, se encuentran bajo el marco de RUP (Rational
Unified Process) y fueron extraídas de la bibliografía (Spence & Probasco,
2000).
Una de las decisiones más importantes a tomar al momento de

establecer el proceso de trazabilidad, es el nivel de trazabilidad que
requerimos y la cantidad de trazabilidad explícita requerida para alcanzar este
objetivo. El agregado de trazas explícitas a nuestros artefactos de desarrollo
puede tener un costo significante en el proyecto.
Es necesario entonces, definir la estrategia de trazabilidad que será

utilizada para un determinado proyecto, logrando una relación costo-beneficio
positiva.
La estrategia de trazabilidad seleccionada definirá el nivel de trazabilidad

explícita que agregaremos a nuestro proceso de desarrollo.
Página 196
La figura, muestra los diferentes artefactos de software involucrados en

la especificación de requerimientos en RUP.
Se puede observar como la tradicional SRS2 es solo un camino

alternativo de especificar requerimientos de Software. Es importante notar que
tanto el enfoque de casos de uso, como el tradicional SRS, pueden proveer
una especificación de requerimientos de software que defina en forma
completa el comportamiento externo del sistema a ser construido. No significa
que los dos enfoques no puedan coexistir en un mismo proyecto, en más,
muchas veces es necesario para brindar diferentes visiones según los
stakeholders con los que se trate.
Las estrategias de trazabilidad planteadas en el paper son:
11.4.1 Solamente Casos de Uso
Los requerimientos del sistema son almacenados por completo en casos

de uso y especificaciones suplementarias, no existen especificaciones de
necesidades o funcionalidades. Debe existir un alto grado de confianza entre
el cliente y los desarrolladores, debido a la falta de análisis de necesidades y
funcionalidades.
Ventajas Desventajas
Documentación mínima No existe relación alguna hacia las

necesidades del cliente. No se intenta realizar
un análisis de problema antes de la definición
de la solución.
Esfuerzo mínimo en administración de Alguna gente opina que no se puede

requerimientos establecer un claro contrato a partir de un
modelo de casos de uso.
Los casos de uso son fáciles de entender Dificultad para saber cuando el caso de uso
modela una solución que permita la
resolución de las necesidades del cliente,
debido a una falta de análisis de las mismas.
Buen soporte para la administración del

alcance, análisis de impacto y desarrollo
incremental.
2
SRS (Software Requirement Specificafion): colección de artefactos que describen en forma completa el
comportamiento externo del sistema. Crea un modelo conceptual del sistema a ser construido. Toma como input
el documento de visión en donde se sientan objetivos y necesidades de los usuarios.
Página 198
11.4.2 Casos de uso inducidos a partir de las funcionalidades
Esta es la estrategia recomendada por RUP por defecto. Las

necesidades y funcionalidades, especificadas en el documento de visión, son
trazadas a los casos de uso. Si no se reflejan en los casos de uso, entonces
se trazan hacia las especificaciones suplementarias. El modelo de casos de
uso y especificaciones suplementarias, son complementados con las
necesidades y funcionalidades, para formar la especificación de
requerimientos.
Los requerimientos de software son No aceptada en todas las organizaciones

expresados en una manera fácil de entender
El análisis de impacto debido a cambios en Alguna gente opina que es difícil alcanzar un
los requerimientos es facilitado por esta contrato que está basado fundamentalmente
estrategia de trazabilidad. El impacto de una en casos de uso. Si bien, existen
funcionalidad no implementada es fácilmente organizaciones que lo han logrado.
entendido
Permite trazabilidad formal, de bajo nivel y

detallada. Tener ambas perspectivas, la de
casos de uso y funcionalidades del sistema,
facilita la captura de requerimientos
Minimiza el esfuerzo requerido en la

administración de requerimientos
El modelo de casos de uso es relacionado

hacia atrás con las necesidades de los
stakeholders, a través de las funcionalidades
Documentación relativamente corta, permite

escalabilidad
11.4.3 El modelo de casos de uso es una interpretación de la

especificación de requerimientos de software
Esta estrategia por lo general es utilizada cuando la SRS, es una

metodología que está afianzada en la organización y los casos de uso son
utilizados para posibilitar el desarrollo conducido por casos de uso (use case
driven development).
Página 199
Las funcionalidades son trazadas hacia especificaciones formales de

requerimientos de software, y estas son a su vez, trazadas con los casos de
uso.
Permite trazabilidad formal, de bajo nivel y No bien entendido por la gente. Se suele
detallada verse confundida frente a dos enfoques, el
tradicional SRS y el modelo de casos de uso
Los requerimientos de software son Presta a confusión al momento de completar

expresados en forma entendible la especificación de requerimientos, ya que es
necesario mantener los dos modelos
El análisis de impacto debido a cambios en Documentación relativamente extensa de

los requerimientos es facilitado por esta mantener
estrategia de trazabilidad. El impacto de una
funcionalidad, requerimiento o caso de uso no
implementado es fácilmente entendido
El modelo de casos de uso es relacionado Implica un gran costo

con las necesidades de los stakeholders a
través de los requerimientos de software y las
funcionalidades. Permite a los stakeholders
entender la razón del modelo de casos de uso
Útil para las organizaciones que están dando

sus primeros pasos con casos de uso. El
mundo externo continúa viendo el tradicional
SRS, que permite utilizar contratos y
procedimientos estándares
11.4.4 Sin casos de uso
En este enfoque no existe el modelo de casos de uso. Las necesidades

de los stakeholders dan lugar a las funcionalidades, y estas a los
requerimientos de software, que son formalmente especificados en SRS.
Bien entendido Dificultad para la captura de requerimientos
Se cree que es un buen enfoque para Dificultad para el entendimiento de los

contratos legales requerimientos presentados de esta manera
Recomendado por varios procesos El análisis de impacto debido a cambios en

estándares los requerimientos es difícil de llevar a cabo
Página 200
Permite trazabilidad formal, de bajo nivel y Los requerimientos individuales no tienen un

detallada contexto
La falta de un contexto impide dar prioridad a

los requerimientos, dificultando la
administración del alcance y entregas
incrementales del producto
Altos costos de mantenimiento. La falta de

trazabilidad implícita lleva a tener que
mantener gran cantidad de trazas explícitas
11.4.5 El modelo de casos de uso define las funcionalidades del

producto
En este caso, el modelado de casos de uso es utilizado como la técnica

principal para la captura de requerimientos, siendo los casos de uso la fuente
principal de las funcionalidades del producto. Esta opción es solo viable para
pequeños desarrollos, con ciclos de vida cortos y sin escalabilidad. Es una
variación al enfoque “Solo Casos de Uso”. Es recomendado utilizar el enfoque
“Casos de uso inducidos a partir de las funcionalidades”, en el caso de que se
opte por relaciones de trazabilidad entre los casos de uso y las necesidades
de los stakeholders.
En este enfoque los casos de uso son Al inicio del proyecto, los casos de uso
relacionados con las necesidades del cliente, aparentan definir las funcionalidades del
permitiendo verificar que tan apropiado es el sistema, pero los dos conceptos tienden a
modelo de casos de uso separarse a medida que el proyecto madura
Los casos de uso no son funcionalidades,

provocando que lo que aparenta ser un
ahorro en tiempo, resultará en un problema
de mantenimiento
El paper (Use Case Management with Rational Rose and Rational

RequisitePro, 2001) menciona como poder lograr una Administración
Integrada de Casos de Uso haciendo uso de las herramientas Rational Rose
y Rational RequisitePro y siguiendo alguna de las técnicas mencionadas.
Página 201
Estas herramientas principalmente se enfocan en documentar las trazas entre

requerimientos y casos de uso y fundamentan su importancia en:
• Al proveer al usuario una visión de lo que el sistema debería hacer,

los casos de uso se transforman en requerimientos.
• Estableciendo una dependencia tangible entre los casos de uso y

las necesidades, es más fácil responder a cambios sobre
requerimientos del negocio.
• Priorizando la importancia de implementar un caso de uso sobre

otro, ayuda a saber por dónde empezar.
• Administrar casos de uso junto a requerimientos es la clave para

entender el estado del proyecto y permitir realizar entregables del
sistema requerido en forma y tiempo.
¿Como es llevada a la práctica la “Administración Integrada de

Casos de Uso” a través de estas dos herramientas?
Rational Rose es la herramienta para el modelado UML, mientras que

Rational RequisitePro permite la documentación de casos de uso y
requerimientos en documentos Word. A su vez RequisitePro se implementa
sobre una base de datos de manera de almacenar todas las relaciones y
atributos.
Rational permite la asociación de un modelo de Rose con uno de

RequisitePro, de manera de poder ligar el modelo a descripciones de
requerimientos y casos de uso.
Una de las funcionalidades más interesantes a destacar es como se

puede ligar un caso de uso a un requerimiento a medida que se está
escribiendo la especificación del mismo en un documento Word. En la
siguiente figura se puede visualizar como un usuario crea una traza desde el
caso de uso que está editando a un nuevo requerimiento, con un simple click-
derecho del mouse.
Página 202
Además, de existir una posterior modificación de dicha relación, la traza

será actualizada de manera transparente para el usuario.
Otra funcionalidad importante, es la capacidad de generar diferentes

tipos de vistas que permitan por ejemplo ver casos de uso con cierta
dificultad, a quien están asignados, etc.
Para la visualización de trazas, Rational ofrece una tabla de doble

entrada denominada “matriz de trazabilidad”. En la siguiente figura se puede
apreciar un ejemplo:
Página 203
En resumen, la técnica “Administración Integrada de Casos de Uso”,

extiende a los casos de uso con información de requerimientos.
Como beneficio principal de la herramienta podemos citar la capacidad

que brinda al usuario de realizar modificaciones en tiempo real acerca de los
atributos de los casos de uso, y trazas entre casos de uso y requerimientos.
La principal desventaja de este enfoque es que solo se ocupa de

resolver la problemática de trazabilidad en la etapa de análisis, dejando de
lado el “gap” existente entre análisis, diseño y posterior implementación de
código.
Página 204
11.5 Anexo V: Proceso RUP
En base a las bibliografías (Leffingwell & Widrig, 2003) y (Kroll &

Kruchten, 2003), en esta sección se explican resumidamente los aspectos
más relevantes del proceso RUP (Rational Unified Process).
11.5.1 Mejora Iterativa
El enfoque iterativo combina las mejores características de los modelos

en cascada y espiral.
Este enfoque también incorpora los nuevos aportes de la ingeniería del

software.
En este modelo las fases del ciclo de vida se encuentran desacopladas

con respecto a las actividades lógicas que ocurren en cada fase, permitiendo
volver a validar las actividades, como por ejemplo requerimientos, diseño e
implementación, en varias iteraciones a lo largo del proyecto.
Al igual que en el modelo en espiral, cada iteración está diseñada de

modo que se puedan analizar y mitigar aquellos riesgos que se encuentren
presentes en ese momento.
11.5.2 Fases del ciclo de vida
El modelo presenta cuatro fases: concepción, elaboración, construcción

y transición. Estas fases se corresponden a los estados naturales del
proyecto.
En la fase de concepción el equipo concentra la atención en entender el

negocio y alcance del proyecto y posibilidades de implementación. Se realiza
un análisis del problema, una visión de la solución. Se estiman en forma
Página 205
preliminar calendarios y costos. Se analizan los posibles riesgos que puedan

surgir en el proyecto y se identifican los principales casos de uso.
En la fase de elaboración se refinan los requerimientos completando los

casos de uso, se establece la arquitectura y, quizá, se desarrolla un prototipo
para mostrar.
En la fase de construcción se centra el foco en la implementación. La

mayoría del código se construye en esta fase. La arquitectura y diseño se
suponen ya terminadas.
En la fase de transición se implementa el producto en el cliente y se

entrena a los usuarios. Como consecuencia de esto suelen surgir nuevos
requisitos a ser analizados.
11.5.3 Iteraciones
Dentro de cada fase existen múltiples iteraciones. Una iteración es una

secuencia de actividades con un plan establecido y criterios de evaluación. Lo
que se obtiene es un “entregable” de algún tipo. Cada iteración se construye
sobre la base de la iteración anterior, por lo que el proyecto se desarrolla en
un estilo iterativo e incremental.
Las iteraciones se seleccionan de acuerdo algún criterio. Por ejemplo,

las primeras iteraciones deberían diseñarse para evaluar la viabilidad de la
arquitectura elegida contra alguno de los casos de uso más riesgosos.
11.5.4 Disciplinas
Las actividades asociadas con el desarrollo del software se organizan

en un conjunto de disciplinas. Cada disciplina define los pasos a seguir para
Página 206
obtener un producto viable. Si bien la cantidad y tipo de disciplinas pueden

variar, existen al menos seis disciplinas.
Durante cada iteración, el equipo ocupa el tiempo apropiado para cada

disciplina, entonces una iteración puede verse como un pequeño modelo en
cascada con las actividades necesarias. Cada modelo en cascada se ajusta a
las necesidades específicas de cada iteración.
En la figura se muestra la cantidad relativa de esfuerzo que se invierte

en las disciplinas. Por ejemplo, en la fase de elaboración, la mayoría del
tiempo de concentra en refinar requerimientos y definir la arquitectura que
soportará la funcionalidad del sistema. Las actividades pueden ser
secuenciales o ejecutarse en forma concurrente, de acuerdo a las
necesidades del proyecto.
Consideraciones
El modelo iterativo permite una mejor adaptabilidad a los cambios en los

requerimientos. El modelo reconoce que los requerimientos cambian, es por
esto que se refinan y se validan a lo largo de todo el ciclo.
Página 207
También permite una mejor administración del alcance ya que en cada

iteración se pueden analizar desvíos y hacer correcciones. Además, al haber
múltiples iteraciones siempre puede existir la posibilidad de obtener un
ejecutable, aunque no contenga todas las funcionalidades.
Página 208
11.6 Anexo V: Proceso ICONIX
En esta sección brindaremos un resumen de los puntos que

consideramos más importantes del proceso de desarrollo ICONIX (Rosenberg
& Scott, 2001). Merece una sección separada, debido a que creemos que
este proceso aporta conceptos que son útiles de seguir y que pueden servir
como base para la implementación de un modelo de trazabilidad eficiente en
una organización de desarrollo de software.
Es común, en las organizaciones de desarrollo de software, la

percepción de nunca existir el tiempo necesario para el modelado, análisis y
diseño de los sistemas a construir. En la mayoría de los casos, está presente
la presión de “saltar” al código lo antes posible, debido a que el progreso en el
software muchas veces es medido a partir de la cantidad de código existente
hasta cierto momento.
Los autores del proceso, lo encuentran ubicado entre dos procesos; por
un lado el proceso RUP (Rational Unified Process), criticado en cierta medida
por ser muy extenso, y procesos del tipo XP (eXtreme programming),
definidos como “ligeros”. El proceso ICONIX se puede definir como un
proceso de desarrollo inducido a partir de los casos de uso (use-case driven),
como ser el proceso RUP, pero sin todo el overhead del mismo. A su vez, es
relativamente reducido y ajustado como procesos XP, pero no descarta en
ningún momento la necesidad del análisis y el diseño.
Página 209
La figura demuestra la selección de componentes UML que realiza

ICONIX con el fin de brindar un enfoque ágil, minimalista y eficiente,
reduciendo el overhead necesario para la producción de todos los
documentos que acompañan al proceso RUP. ICONIX, en contraste con RUP,
es un proceso “liviano” y altamente iterativo, focalizado en alcanzar el código
lo más rápido posible.
Otro objetivo que persigue ICONIX es, reducir la “distancia” (gap) entre
el análisis del sistema y la implementación del mismo, es decir, entre la
especificación de requerimientos a través de casos de uso, y el código
responsable del comportamiento necesario para el cumplimiento de los
mismos.
Creemos, que es vital para alcanzar un correcto modelo de trazabilidad,

intentar transferir todo el conocimiento del modelo de análisis, al modelo de
diseño, y a su vez, que ambos modelos estén altamente relacionados, hasta
el punto que, uno se vea necesitado del otro. Es decir, los modelos deben ser
complementarios, y no por el contrario, uno ser el reemplazo de otro.
Hacemos especial énfasis en este último punto, debido a que es común
Página 210
encontrarse en la práctica, modelos de análisis, con ideas imposibles de

transferir al modelo de diseño, y viceversa.
11.6.1 Ventajas que ICONIX aporta al proyecto
El proceso ICONIX es una guía que describe como llegar desde un caso
de uso hasta el código que lo implementa. Es así que, le conciernen los
aspectos del modelo de análisis y del modelo de diseño que se puedan
alcanzar en la producción de software.
Rousenberg (Rosenberg, Collins-Cope, & Stephens, Agile Development

with ICONIX Process: People, Process, and Pragmatism, 2005) señala que la
misión de ICONIX resulta ser: “Remover la ambigüedad de los
requerimientos, y posteriormente realizar un diseño claro”.
Existe una buena razón para seleccionar este enfoque. Casos de uso
escritos en forma inconsistente, brindan ambigüedad al momento de
resolverlos. Si esta ambigüedad, no es esclarecida, entonces se traslada a
todo el conjunto de casos de uso, diseño y lo peor de todo, al código. Esto a
su vez, provoca todo tipo de costos, principalmente por defectos en el
software o desvíos en lo que el cliente esperaba del mismo. Es por esto, que
es importante remover todo tipo de ambigüedad lo antes posible, es decir, en
la etapa de especificación de requerimientos.
11.6.2 Teoría del Proceso
El proceso ICONIX trata de extraer el diseño del software a partir de los

requerimientos funcionales de una manera guiada, de un paso a la vez. En
otras palabras, se refiere a escribir el manual de usuario primero (o al menos
un par de párrafos por vez, en forma de casos de uso); validando que se
contemplen los diferentes escenarios y que la descripción del comportamiento
dado a cada caso de uso es realmente el esperado por los usuarios;
asegurándonos que hemos definido el conjunto de objetos (en realidad,
clases) que pueden colaborar para implementar el comportamiento requerido;
y chequeando que dichas clases tienen los atributos y operaciones correctas.
Página 211
Cuando trabajamos en las diferentes etapas del proceso, lo que

realmente estamos haciendo es llevando los requerimientos funcionales a una
forma mas completa, precisa, sin ambigüedades. A partir de los
requerimientos sin ambigüedades, se desprende un diseño lo suficientemente
ligado para asegurarnos que estamos construyendo el sistema correcto
(entendemos el comportamiento deseado) y lo estamos construyendo de la
manera correcta (definimos clases con los métodos y atributos correctos para
llevar adelante el comportamiento). En resumen, para quitar la ambigüedad a
los requerimientos se trata de construir el sistema correcto, y construirlo de la
manera correcta.
En el proceso ICONIX, cada artefacto UML utilizado, tiene un objetivo

principal:
1) Casos de Uso: describir los requerimientos

funcionales.
2) Modelo del Dominio: describir los objetos reales

del problema y sus relaciones.
3) Diagramas de Robustez: quitar ambigüedad a los

requerimientos funcionales y ligarlos a los objetos
del modelo.
4) Diagramas de Secuencia: Alocar comportamiento

(asignar métodos a las clases).
11.6.3 Etapas del Proceso
El proceso asume en primera instancia, que los requerimientos serán

especificados en base a casos de uso. En segundo lugar, y como punto de
partida entiende que, se han identificado los diferentes escenarios y
principales casos de usos del sistema a construir.
Siguiendo estas premisas, el proceso intenta definir, como llegar desde

un caso de uso, al código que lo implementa, intentando definir un modo que
permita reducir el gap entre análisis – diseño – código.
Página 212
Para tal fin, el proceso ICONIX puede verse como la secuencia de los
siguientes pasos (en negrita se detallan los diferentes artefactos producidos
en cada etapa).
1) Paso 1: Identificar los objetos del dominio del problema (Modelo del
Dominio).
2) Paso 2: Definir los requerimientos funcionales (Casos de Uso).
3) Paso 3: Análisis de robustez (Diagramas de Robustez).
4) Paso 4: Situar la funcionalidad requerida en los objetos del dominio

(Diagramas de Secuencia).
5) Paso 5: Finalizar el modelo estático (Diagrama de Clases).
6) Paso 6: Implementación del código (Código Fuente).
7) Paso 7: Realizar testing del sistema.
No debe entenderse bajo ningún aspecto que, los pasos mencionados

deban realizarse uno tras otro. En más, el proceso ICONIX es altamente
iterativo, y requiere una constante revisión y actualización del trabajo
previamente realizado. A diferencia de muchos enfoques, ICONIX no plantea
la obligación de tener que obtener un resultado para poder avanzar al
siguiente paso del proceso, lo que aporta a su “agilidad”.
Página 213
A medida que explicaremos los pasos mencionados en las secciones

siguientes, se notará la existencia de cuatro hitos marcados en el proceso,
que servirán para medir y demostrar el trabajo que ya ha sido realizado en
cierto punto. Dichos hitos son:
1) Hito 1: Revisión de Requerimientos
2) Hito 2: Revisión del Diseño Preliminar
3) Hito 3: Revisión del Diseño Detallado / Crítico
4) Hito 4: Entrega
Paso 1: Identificar los objetos del dominio del problema
Partiendo de las premisas previamente señaladas, y de un prototipo de

interfaces del sistema, el primer artefacto es el modelo del dominio. El
modelo del dominio, no es nada mas, ni nada menos, la manera de establecer
el lenguaje unívoco que menciona Eric Evans11.7, que sirva de glosario para el
equipo de trabajo durante el proyecto. En términos de UML, el modelo del
dominio, es básicamente un diagrama de clases, sin caer en el detalle de
atributos y métodos de cada clase. Puede ser visto como un resumen
abstracto del diagrama de clases. En más, el proceso señala la importancia
Página 214
de construir este modelo como un primer acercamiento al modelo de clases,

haciendo especial enfoque en el problema del dominio a resolver. Cuando
creamos un modelo del dominio, estamos creando una representación de los
objetos y acciones involucradas en el negocio y necesarias para los
problemas que el proyecto intenta resolver. El modelo de dominio inicial que
se cree para cualquier proyecto nunca será perfecto. A medida que se avanza
en el proceso, se irá refinando y aportando detalles al modelo final de clases.
Es importante dedicar cierto tiempo para obtener un modelo del dominio

correcto, es decir, que represente la realidad. A su vez, este paso no debe
significar la paralización del proyecto. A medida que se avanza en las
actividades de análisis y diseño, volveremos al modelo del dominio para
actualizarlo, agregando nuevos objetos y correcciones. El modelo del dominio
evoluciona a medida que crece nuestro entendimiento del problema del
dominio.
A su vez, este paso puede ser separado en los siguientes dos:
1) Identificar los objetos del mundo real del dominio, así como también
relaciones de generalización y agregación entre dichos objetos.
2) Comenzar a dibujar un diagrama de clases de alto nivel.
Si es posible, realizar un prototipado rápido del sistema a construir, o

recolectar cualquier tipo de información relevante del sistema “legacy” que se
tome como base.
Paso 2: Definir los requerimientos funcionales
Los requerimientos funcionales (los que brinden el comportamiento

esperado del sistema) en el proceso ICONIX son definidos en los casos de
uso.
Debido a tratarse a un proceso inducido a partir de casos de uso, se

intenta marcar una diferencia con el resto de enfoques. Los casos de uso no
serán descripciones textuales, abstractas, confusas, sin detalle para poder
conseguir en base a los mismos un diseño detallado; sino que por el contrario,
Página 215
el proceso mantiene la idea de que el diseño del sistema, deberá surgir a

partir de los casos de uso. Es importante notar que este objetivo del proceso,
juega a favor de la trazabilidad que se intenta perseguir en este trabajo.
El proceso indica que una vez que tenemos el texto necesario para la
especificación de un caso de uso, es hora de refinarlo teniendo en cuenta que
las oraciones sean claras y discretas. Para esta finalidad, se plantea que las
oraciones sigan el patrón sustantivo-verbo-sustantivo. Los sustantivos podrán
ser cualquier entidad identificada en el modelo del dominio u actor del
sistema. A su vez, durante la realización de este modelo, es importante
actualizar e ir sumando conceptos al modelo del dominio, a medida que se
descubren nuevos objetos y se expande el conocimiento de las entidades
previamente identificadas.
Según los autores, el formato a seguir para una especificación de caso

de uso, debe contemplar el curso básico de acción y los alternativos, dejando
de lado toda otra información que pueda distraernos del enfoque. Las
preguntas que guiarán la construcción de un caso de uso serán: ¿Qué
sucede? ¿Y luego que sucede? ¿Qué otra cosa puede suceder?
Se puede estar conformes con el modelo de casos de uso alcanzado

cuando:
1) Los casos de uso construidos responden a todos los requerimientos

y/o funcionalidades del sistema a construir.
2) Las descripciones de los cursos básicos son claras y concisas,

acompañadas de cursos de acción alternativos apropiados, para
cada caso de uso.
Este paso, puede ser subdividido en las siguientes actividades:
1) Identificar los casos de uso utilizando diagramas de caso de uso.
2) Organizar los casos de uso en grupos.
3) Ligar los requerimientos funcionales a casos de uso y a objetos del

dominio.
4) Especificar los casos de uso (curso básico y alternativos).
Página 216
Al finalizar este paso, el proceso marca el Hito 1: Revisión de

Requerimientos
Paso 3: Análisis de Robustez
La mayoría de enfoques hacen uso de casos de uso y diagramas de

secuencia, pero no resuelven el problema de reducir el “gap” entre los
primeros, generalmente con poca claridad, y los segundos de gran detalle a
nivel de código y específicos. Para atravesar este salto, entre el qué y el
cómo, está el aspecto central del proceso ICONIX, los diagramas de
robustez. El diagrama de robustez se ubica entre los requerimientos y el
diseño detallado, ayudando a llegar desde un caso de uso a un diagrama de
secuencia. Muestra los objetos que participan en un determinado escenario y
como dichos objetos interactúan entre sí.
Los diagramas de robustez son el resultado de un análisis de robustez.

Dicho análisis involucra el trabajo de recorrer la especificación de un caso de
uso y tomar un vistazo preliminar de cómo podría ser el diseño para
implementarlo, haciendo uso de los objetos que hemos descubierto hasta el
momento en el modelo del dominio.
En los diagramas de robustez participan los siguientes tipos de objetos:
1) Objetos de Periferia (Boundary Objects): utilizados por los

actores para comunicarse con el sistema.
2) Objetos de Entidad (Entity Objects): usualmente objetos

pertenecientes al modelo del dominio.
3) Objetos de Control (Control Objects): usualmente denominados

“controladores”, ya que no son objetos reales. Sirven de unión entre
los objetos periféricos y los de entidad.
Página 217
El análisis de robustez para un caso de uso se realiza recorriendo la

especificación textual del mismo, oración por oración, y dibujando el/los
actor/es, los objetos de periferia, control y entidad apropiados, y las relaciones
entre ellos. Se debe poder completar el curso básico y todos los cursos
alternativos del caso de uso en cuestión.
Para la realización de los diagramas, se deben contemplar cuatro reglas

básicas:
1) Los actores solo pueden hablar con objetos de periferia.
2) Objetos de periferia solo pueden hablar con objetos de control y

actores.
3) Objetos de entidad solo pueden hablar con objetos de control.
4) Objetos de control pueden hablar con objetos de periferia, objetos

de entidad, pero no actores.
Tanto los objetos de entidad como los de periferia responden a los

sustantivos de la especificación de los casos de uso, mientras que los verbos
se corresponden con los objetos de control. Por lo tanto los sustantivos no
pueden comunicarse con otros sustantivos, pero los verbos pueden hablar
tanto con sustantivos como con verbos.
El análisis de robustez, además de aportar como resultado la creación

del diagrama correspondiente, trae como consecuencia:
1) Un chequeo de que la especificación del caso de uso sea válida, es

decir, que no se haya especificado algo imposible de llevar a la
implementación.
2) Surgimiento de nuevos objetos, que quizás se hayan escapado

durante la realización del modelo del dominio, incorporándose al
mismo. Además nos aseguramos que todos los objetos de control y
periferia necesarios para llevar a cabo el curso del caso de uso,
estén debidamente identificados para el posterior diagrama de
secuencia.
El análisis de robustez puede ser dividido en los siguientes pasos:
Página 218
1) Dibujar los diagramas de robustez. Para cada caso de uso:
2) Identificar los objetos del dominio responsables de cumplir un

escenario en particular.
3) Actualizar el modelo del dominio, a medida que se descubren

nuevos objetos y atributos.
4) Actualizar (quitar ambigüedad) la especificación del caso de uso, de

manera que concuerde con el diagrama de robustez.
5) Terminar de actualizar el diagrama de clases de manera que refleje

la finalización de la fase de análisis del proyecto.
Al finalizar este paso, el proceso marca el Hito 2: Revisión del Diseño

Preliminar.
Paso 4: Situar la funcionalidad en los objetos del dominio
Al finalizar los diagramas de robustez y realizar una revisión preliminar

del diseño, es hora de realizar el diseño detallado. El diseño detallado se basa
en situar las funciones del software que hemos identificado en el conjunto de
objetos que hemos descubierto. ICONIX toma a los diagramas de secuencia
como elemento central del diseño detallado, o al menos de la parte dinámica
del modelo de objetos.
En la parte superior de un diagrama de secuencia se encuentran los

objetos que participan en un escenario dado. Lo primero que debemos hacer
antes de comenzar un diagrama de secuencia es, identificar los objetos que
participarán en el mismo. Como ayuda a esta tarea, se puede pensar en las
funcionalidades que debemos situar para el escenario en cuestión. Por lo
tanto, mientras realicemos el diagrama, estaremos pensando en el mapeo
entre, las funciones que brindarán el comportamiento deseado, y los objetos
involucrados.
Esta etapa del proceso, puede ser subdividida en los siguientes pasos
para cada caso de uso:
Página 219
1) Identificar los mensajes que necesitan ser enviados entre los

objetos y los métodos asociados a los mismos que serán invocados.
2) Dibujar el diagrama de secuencia de manera de situar la

especificación del caso de uso a la izquierda y los detalles de
diseño a la derecha.
3) Continuar actualizando el / los diagramas de clases con los

atributos y operaciones a medida que son identificados.
El proceso señala la necesidad de crear un diagrama de secuencia para

cada caso de uso, en el que se muestre tanto el curso básico como los cursos
alternativos del mismo. A nuestro parecer llevar esto a la práctica se torna
casi imposible por el costo en esfuerzo requerido. Nuestra opinión es que se
deben realizar diagramas de secuencia solo para aquellos casos de uso en
los que intervengan entidades importantes, y su curso responda a una
necesidad de negocio importante. Resumiendo, creemos que un diagrama de
secuencia por ejemplo de un ABM no aporta valor a la documentación.
Paso 5: Finalizar el modelo estático
Como el título lo menciona, el artefacto de diseño fundamental de este

paso es el modelo estático, que está integrado por uno o mas diagramas de
clases.
Este paso puede ser visto como las siguientes actividades:
1) Agregar información de diseño detallada (aplicar patrones de diseño

al modelo)
2) Verificar con el equipo de trabajo que el diseño satisface los

requerimientos que han sido identificados.
El modelo estático es la vista más detallada del modelo del dominio,

conteniendo detalles de implementación y decisiones de diseño. Además
contiene los diagramas de clases a un nivel detallado y concordante con los
diagramas de secuencia.
Página 220
Al finalizar este paso, el proceso marca el Hito 3: Revisión detallada /

crítica del diseño.
Paso 6: Implementación del código
Este paso, es cuando los programadores toman el diseño y comienzan a

codificar a partir del mismo. ICONIX asume que los programadores deben
participar activamente en todos los pasos de diseño.
Asumiendo un enfoque ágil, el diseño no va a estar 100% correcto, por

lo que en caso de tomarse nuevas decisiones de diseño, o modificar
cuestiones del modelo, los mismos deben verse reflejados en los artefactos
previamente citados.
Se pueden identificar dos actividades en este paso:
1) Generación de código.
2) Realización de testing unitario y de integración.
Paso 6: Testing del Sistema
En esta etapa, un grupo integrado por personas ajenas al desarrollo

(idealmente un equipo de QA) realiza el testing de aceptación, tomando a los
casos de uso como “cajas negras” y aplicándoles los casos de prueba.
Al finalizar este paso, el proceso marca el Hito 4: Entrega.
11.7 Anexo VI: Domain-Driven Design
En cierta medida, la trazabilidad estará guiada por la habilidad con que

se logre modelar el dominio del negocio. Un enfoque en el cual se basa la
presente tesis es el de “Diseño dirigido a partir del dominio”, o más
comúnmente denominado en la Ingeniería del Software como “Domain-Driven
Design” propuesto en la bibliografía (Evans, 2003).
“Domain-Driven Design descarta la separación entre el modelo de

análisis y el modelo de diseño, buscando un único modelo que sirva para
Página 221
ambos propósitos. Dejando de lado temas puramente técnicos, cada

elemento en el diseño, juega un rol conceptual en el modelo”.
El proceso tradicional de desarrollo de software indica que en primer

lugar un analista, en base a un relevamiento de las necesidades de los
stakeholders, especifique que debería solucionar el sistema a través de los
requerimientos de software. Posteriormente una etapa de diseño, especifica
como dichos requerimientos son llevados a cabo. Esta separación de roles,
hace por lo general, que se manejen conceptos y lenguajes diferentes. Es
muy común observar en las organizaciones, con una marcada separación
entre analistas y diseñadores / arquitectos, la tendencia a que el segundo
grupo termine finalmente produciendo un modelo de implementación
totalmente diferente al planteado por el primer grupo. En la mayoría de los
casos es debido a que el modelo de análisis no es “técnicamente
implementable”. Sin embargo, el mayor problema radica que al coexistir dos
modelos que manejan conceptos diferentes, las relaciones entre ambos no
pueden ser documentadas, quitando toda posibilidad de trazabilidad.
“Siempre existen diversas maneras de abstraer el dominio, y a su vez

varios diseños capaces de resolver un problema. Esto es lo que hace
importante en mantener una conexión entre el modelo y el diseño en la
práctica. Cuando un modelo puede llevarse a la implementación, entonces
debemos seleccionar otro.”
Lograr la conexión mencionada por Evans, no debe significar un análisis

pobre debido a consideraciones técnicas, ni tampoco, un diseño que solo
refleje ideas del dominio sin estar fuertemente basado en los principios de
diseño mayormente aceptados (patrones de diseño).
Evans resalta tres características esenciales que debe tener un buen

modelo:
1) El modelo y el corazón del diseño deben ser un reflejo mutuo. Es la

relación íntima entre el modelo y la implementación lo que hace del
modelo un elemento relevante, asegurando que el análisis que
sobre él se realice será aplicado al producto final, un sistema que
Página 222
funcione. Esta conexión entre el modelo y la implementación ayuda

al mantenimiento y continuo desarrollo, ya que el código puede ser
interpretado en base a un entendimiento del modelo.
2) El modelo es la columna vertebral que integra el lenguaje a ser

utilizado por todos los miembros del equipo. La conexión entre el
modelo y la implementación, permite a los desarrolladores hablar
del sistema utilizando este lenguaje. Pueden comunicarse con los
expertos del dominio sin traducción alguna. Y debido a que el
lenguaje está basado en el modelo, nuestra propia lingüística
permitirá refinar al modelo mismo.
3) El modelo es la manera en que el equipo de proyecto estructura el

conocimiento del dominio y distingue los elementos de mayor
interés. Captura la manera en que pensamos acerca del dominio, a
medida que seleccionamos términos, desglosamos conceptos, y los
relacionamos entre ellos. La conexión entre el modelo y la
implementación permite ganar experiencia en versiones tempranas
del software, permitiendo un feed-back para aplicar al proceso.
Esta metodología requiere ciertos requisitos para poder llevarse a cabo,

que son de interés detallar:
1) El desarrollo debe ser un proceso iterativo.
2) Debe existir una relación continua y cercana entre los que

construyen el sistema (diseñadores / arquitectos) y los expertos del
dominio, es decir, entre los que conocen el dominio y los que saben
cómo construirlo.
3) Hacer uso de un lenguaje unívoco, tanto en el análisis como en el

diseño. Evans lo define como “UBIQUITOUS LANGUAGE”.
4) Existencia de herramientas y lenguajes que soporten un buen

modelo de la realidad. Los lenguajes Orientados a Objetos, son los
elegidos, brindando asociaciones entre objetos, jerarquía de clases,
comportamiento a través de mensajes, etc.
Página 223
5) Integración entre los roles del grupo de trabajo. Una marcada

separación de la responsabilidad de cada uno de ellos (analista,
diseñador / arquitecto, desarrollador). “Si la gente que escribe el
código no se siente responsable por el modelo, o no entienden
como hacer que el modelo funcione en una aplicación, entonces el
modelo no tiene nada que hacer con el software que se produzca”.
6) Separación del dominio – se explica detalladamente a continuación.
11.7.1 Separación del Dominio
Si bien esta sección se refiere a conceptos que se deben perseguir para

alcanzar un correcto diseño de un sistema, merece la atención debido que el
modelo de trazabilidad planteado en este trabajo, presupone su utilización.
En todo diseño OO, siempre es necesario desacoplar los objetos de

dominio de toda otra funcionalidad que el sistema ofrezca, evitando:
1) confundir conceptos del dominio con otros conceptos relacionados

con la tecnología del software,
2) perder el dominio de vista entre la gran “masa” del sistema.
Es común, frente a diseños imposibles de mantener, encontrarse

características tales como:
1) Código de presentación, acceso a base de datos, y otro código de

soporte, escrito dentro de las clases de negocio.
2) Lógica del negocio embebida dentro de componentes de la

presentación o scripts de la base de datos.
Cuando las reglas de negocio que conforman el dominio, se encuentran

mezcladas entre código con diferentes funcionalidades, se vuelve
extremadamente difícil de entender y razonar. Así, por ejemplo, cambios
superficiales a la interfaz de presentación, pueden producir cambios en la
lógica de negocio, produciendo efectos no deseados. El testing se volvería
una tarea exhaustiva, debido a que la lógica a testear estaría “desparramada”
por todo el código, y a su vez siendo impactada por cualquier factor de
Página 224
cambio. Cambiar una regla de negocio, significaría un seguimiento meticuloso

del código de presentación, código de base de datos, u otros elementos que
integren al sistema.
Evans propone como resolución a esta problemática, un modelo de

capas, en donde “el principio esencial es que cada elemento de una capa
(layer) depende solo en elementos de la misma, o de elementos de una capa
inferior. La comunicación hacia arriba debe dirigirse a través de algún
mecanismo indirecto”.
Cada capa del modelo propuesto por Evans, se especializa en un

aspecto particular del sistema. Se persigue alcanzar una gran cohesión3 en el
diseño de estos aspectos, permitiendo diseños más fáciles de entender, y un
bajo acoplamiento4 entre las capas del modelo.
Las capas que integran el modelo son:
3
Cohesión: Grado de relación (similitud) que existe entre los elementos de un mismo módulo.
4
Acoplamiento: Grado de relación (dependencia) que existe entre diferentes módulos.
Página 225
1) Capa de Presentación: responsable de mostrar información al

usuario e interpretar las solicitudes del mismo. El usuario u actor
externo puede ser en algunas ocasiones otro sistema en vez de una
persona.
2) Capa de Aplicación / Control: define la interacción necesaria entre

diferentes objetos del dominio para llevar a cabo los requerimientos
de software. Esta capa trata de mantenerse delgada. No contiene
reglas de negocio o conocimiento del dominio, solo coordina tareas
y delega trabajo a la capa inferior. No mantiene un estado reflejando
la situación del negocio, pero existe la posibilidad de que mantenga
estados que informen al usuario el avance de una tarea.
3) Capa del Dominio / Negocio: responsable de representar los

conceptos, información acerca de la situación, y reglas del mismo
negocio. Los detalles técnicos de almacenar el estado del negocio
son delegados a la capa de infraestructura. Esta capa es el corazón
del software del negocio.
4) Capa de Infraestructura: provee capacidades técnicas para el

soporte de las capas superiores: envío de mensajería, persistencia
del dominio, etc.
“Concentrar todo el código relacionado al modelo del dominio en una

sola capa y separarlo de la interfaz de usuario, código de control e
infraestructura. Los objetos del dominio, al estar libres de la responsabilidad
de mostrarse a sí mismos, guardarse, administrar las tareas, y demás,
pueden enfocarse en expresar el modelo del dominio. Esto permite una
evolución rica y clara del modelo, que permita capturar el conocimiento
esencial del negocio y ponerlo a funcionar.”
(Fowler, 1997) “Separando la capa del dominio de las capas de

infraestructura y presentación permite un diseño mucho más claro de cada
capa. Capas separadas son menos costosas de mantener, debido a que
tienden a evolucionar con diferente velocidad y responden a necesidades
diferentes.”
Página 226
11.8 Anexo VII: Requerimientos Estructurados –

Herramienta: Optimal Trace
La empresa Compuware hace hincapié en una metodología que ellos

mismos denominaron “Requerimientos Estructurados”. Esta empresa entiende
que una administración inadecuada de requerimientos provoca el 70% de los
fracasos de proyectos.
La causa principal que señalan es parte de la problemática analizada en

este trabajo: el gap entre lo que el equipo de negocio necesita y lo que la
gente de IT entiende y finalmente entrega.
Lo que proponen es una manera de documentar los requerimientos. Se

denominan estructurados puesto que ofrecen un flujo paso por paso de lo que
los stakeholders necesitan y esperan del sistema.
Los requerimientos estructurados permiten trazabilidad completa a lo

largo de todo el ciclo de vida debido a que terminan siendo la parte central del
proceso de planeamiento del proyecto, conectando el plan de proyecto con
los objetivos de negocio. A partir del proceso se desprenden especificaciones
de diseño (modelos UML), diseño de interfaces de usuario (screenshots y
storyboards), plan de testing (compuesto por casos de prueba), y módulos de
código (Java, C++, etc.).
¿Qué es exactamente un requerimiento estructurado?
Un requerimiento estructurado describe un objetivo del sistema en

cuestión. Son generados con un alto grado de involucramiento del usuario
que conoce el negocio. Debido a que reflejan de manera clara el
comportamiento del sistema en un flujo entendible, es fácil para los usuarios
entender y verificar el proceso y asegurar que nada está siendo omitido.
Además permiten a los arquitectos entender los objetivos del sistema desde el
punto de vista del cliente. Definen el alcance e interfaz del sistema, facilitando
ver que está dentro y que afuera, acelerando la decisión de compra del cliente
y reduciendo discusiones.
Página 227
Optimal Trace
Compuware basándose en la metodología de requerimientos

estructurados, desarrolló una herramienta llamada Optimal Trace. La misma
permite llevar adelante todo el proceso de captura y especificación de
requerimientos. A su vez, permite establecer “links” a screenshots,
storyboards o cualquier información útil para dar más información a los
requerimientos especificados.
Página 228
12 Referencias
- Abbattista, F., Lanubile, F., Mastelloni, G., & Visaggio, G. (1994). An Experiment on
the Effect of Design Recording on Impact Analysis. International Conference on
Software Maintenance (págs. 253-259). Bari, Italia: IEEE Computer Society.
- Ambler, S. W., Nalbone, J., & Vizdos, M. J. (2007). The Enterprise Unified Process:
Extending the Rational Unified Process. Prentice Hall.
- Anaya, V., & Letelier, P. (2002). Trazabilidad de Requisitos Adaptada a las
Necesidades del Proyecto: Un Caso de Estudio Usando Alternativamente RUP y XP.
Valencia, España: Departamento de Sistemas Informáticos y Computación -
Universidad Politécnica de Valencia.
- Arnold, R., & Bohner, S. (1993). Impact analysis-Towards a framework for
comparison. CSM-93, Proceedings., Conference, (págs. 292-301).
- (1986). Automated Life Cycle Impact Analysis System. Roma, Italia.
- Bianchi, A., Visaggio, G., & Fasolino, A. R. (2000). An Exploratory Case Study of the
Maintenance Effectiveness of Traceability Models. 8th International Workshop on
Program Comprehension (pág. 149). Napoli, Italia: IEEE Computer Society.
- Bohner, S. (1996). Change Impact Analysis for Design Evolution. En S. Bohner, & R.
Arnold, Software Change Impact Analysis (pág. 75). IEEE Computer Society Press.
- Bohner, S., & Arnold, R. (1996). An Introduction to Software Change Impact
Analysis. En S. Bohner, & R. Arnold, Software Change Impact Analysis. IEEE
Computer Society Press.
- Bohner, S., & Arnold, R. (1996). Software Change Impact Analysis. IEEE Computer
Society Press.
- Dean, L., & Don, W. (1999). Managing Software Requirements - A Unified Approach.
Addison Wesley.
- Dick, J. (1995). Rich Traceability. Quality Systems and Software Ltd.
Página 229
- Evans, E. (2003). Domain-Driven Design: Tacking Complexity In the Heart of

Software. Addison Wesley Longman Publishing Co., Inc.
- Fiutem, R., & Antoniol, G. (1998). Identifying Design-Code Inconsistencies in
Object-Oriented Software: a Case Study. International Conference on Software
Maintenance (págs. 94-102). Los Alamitos, California, USA: IEEE Computer Society.
- Fowler, M. (1997). Analysis Patterns: Reusable Object Models. Addison Wesley.
- Freedman, & Weinberg. (1981). A Checklist for Potential Side Effect of a
Maintenance Change. En G. Parikh, Techniques of program and system maintenance.
QED Information Sciences, Inc.
- Gotel, O. C., & Finkelstein, A. C. (1994). An Analysis of the Requirements
Traceability Problem. Proc. Int'l Conf. Requirements Eng. (págs. 94-101). Los
Alamitos, California, USA: IEEE CS Press.
- Kroll, P., & Kruchten, P. (2003). The Rational Unified Process Made Easy: A
Practitioner's Guide to the RUP. Addison Wesley.
- Lee, M. L. (1998). Change Impact Analysis of Object Oriented Software. George
Mason University.
- Leffingwell, D., & Widrig, D. (2003). Managing Software Requirements: A Use Case
Approach. Addison Wesley.
- Letelier, P. (2002). A Framework for Requirements Traceability in UML-based
Projects. 17th IEEE International Conference on Automated Software Engineering.
U.K.
- Lindvall, M., & Sandahl, K. (1998). Traceability aspects of impact analysis in object-
oriented systems. Journal of Software Maintenance: Research and Practice , 37-57.
- Olson, T., Reizer, N., & Over, J. (1993). A Software Process Framework for the SEI
Capability Maturity Model. Pittsburgh, Pennsylvania: Software Engineering Institute.
- O'Neal, J. S. (2003). Analyzing the impact of changing software requirements: a
traceability based methodology. Louisana State, USA.
- Pfleeger, S. L. (1991). Software Engineering: The Production of Quality Software,
2nd ed. New York, USA: Macmillan Publishing Co., Inc.
- Ramesh, B. (Diciembre de 1998). Factors influencing requirements traceability
practice. Communications of the ACM , págs. 37-44.
- Ramesh, B., Harrington, G., Rondeau, K., & Edwards, M. (1993). A model of
requirements traceability to support system development. Maryland, USA.
- Rosenberg, D., & Scott, K. (2001). Applying Use Case Driven Object Modeling with
UML: An Annotated e-Commerce Example. Addison Wesley.
- Rosenberg, D., Collins-Cope, M., & Stephens, M. (2005). Agile Development with
ICONIX Process: People, Process, and Pragmatism. Apress.
- Spence, I., & Probasco, L. (2000). Traceability Strategies for Managing Requirements
with Use Cases. Rational Software.
- Stevens, W., Myers, G., & L.L., C. (1999). Structured design. IBM Systems Journal ,
231.
- (2001). Use Case Management with Rational Rose and Rational RequisitePro.
Rational Software Corporation.
- Wieringa, R. (1995). An Introduction to Requirements Traceability. Amsterdam,
Holanda.
- Yau, S., & Collofello, J. (1980). Some Stability Measures for Software Maintenance.
IEEE Transactions on Software Engineering , 545-552.
Página 230
Página 231
Página 232
Juegos, Revistas, Cursos, Software, Sistemas Operativos, Antivirus y
más … Gratis para el Conocimiento...!
www.detodoprogramas.com
Visítanos y compruébalo
Material para los amantes de la Programación Java,

C/C++/C#,Visual.Net, SQL, Python, Javascript, Oracle, Algoritmos,
CSS, Desarrollo Web, Joomla, jquery, Ajax y Mucho Mas…
www.detodoprogramacion.com
Visitanos
Libros Universitarios, Contabilidad, Matemáticas, obras literarias,

Administración, ingeniería y mas…

Análisis de Impacto Basado en Información de Trazabilidad y Decisiones de Diseño

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Análisis de Impacto Basado en Información de Trazabilidad y Decisiones de Diseño

Cargado por

Copyright:

Formatos disponibles

ANÁLISIS DE IMPACTO BASADO

TESIS DE GRADO EN INGENIERÍA EN

Tesista: Sr. de la Rosa, Martín Ramiro

Tutor: Lic. Pablo Cosso

El presente trabajo simboliza una etapa importante de mi vida y materializa

A mi familia por inculcarme la importancia de tener una profesión y generar

Estimar el impacto provocado por un cambio determinado a un producto de software, es

Palabras claves: análisis de impacto, trazabilidad, requerimiento de cambio,

To consider the impact brought by a change to a software product, is a preliminary task in

Key words: impact analysis, traceability, change requirement, workproduct, process,

1.1 GUÍA PARA LA LECTURA DE LA TESIS ___________________________________________ 11

2 MARCO TEÓRICO – ESTADO DEL ARTE ____________________________________ 19

2.1 TERMINOLOGÍA _____________________________________________________________ 19

3 PROCESO AIT - ANÁLISIS DE IMPACTO BASADO EN TRAZABILIDAD ________ 49

3.1 DIAGRAMA DEL PROCESO ____________________________________________________ 50

4 AIT – CONFIGURACIÓN DE TRAZABILIDAD ________________________________ 67

4.1 CONFIGURACIÓN DE TRAZABILIDAD ____________________________________________ 68

5 AIT - EXTRACTORES DE TRAZABILIDAD ___________________________________ 81

5.1 SINCRONIZACIÓN DE TRAZABILIDAD AUTOMATIZADA _____________________________ 82

6 AIT - ANÁLISIS DE IMPACTO_______________________________________________ 95

6.1 ANÁLISIS DE IMPACTO ITERATIVO ______________________________________________ 95

7 AIT - HERRAMIENTA DE SOPORTE ________________________________________ 109

7.1 ARQUITECTURA ____________________________________________________________ 110

7.3.6 CONFIGURACIÓN DE EXTRACTORES ________________________________________ 119

8 CASO PRÁCTICO I _______________________________________________________ 121

8.1 PARALELISMO CON EL PROCESO RUP _________________________________________ 121

9 CASO PRÁCTICO II _______________________________________________________ 167

9.1 GENERALIDADES DEL PROYECTO _____________________________________________ 167

10 CONCLUSIONES – TRABAJO FUTURO _____________________________________ 181

11 ANEXO __________________________________________________________________ 185

11.1 ANEXO I: DETALLES DEL CASO PRÁCTICO I ____________________________________ 185

11.6.1 VENTAJAS QUE ICONIX APORTA AL PROYECTO ____________________________ 211

12 REFERENCIAS ___________________________________________________________ 229

1.1 Guía para la lectura de la tesis

Para facilitar al lector se presenta a continuación una guía de lo

Introducción: en este primer capítulo se ofrece una descripción de

Marco Teórico - Estado del Arte: este capítulo refleja la

• La terminología utilizada en el estado del arte.

• Definición de trazabilidad y análisis de impacto, conceptos a ser

propuesta. Además, se cubren los aspectos principales de cada

• Factores que influyen tanto para la práctica de trazabilidad como

• Métricas halladas para la evaluación de enfoques de análisis de

• Metodologías y herramientas relacionadas con la tesis.

Proceso AIT - Análisis de Impacto basado en trazabilidad: en

AIT - Configuración de Trazabilidad: se definen los objetivos de la

• Clasificación de los workproducts de un sistema.

• Definición de trazabilidad horizontal y vertical en el marco del

• Medio para la especificación de la configuración de trazabilidad

• Ejemplos de configuraciones de trazabilidad sobre diferentes

AIT - Extractores de Trazabilidad: se explica la importancia de

AIT - Análisis de Impacto: capítulo focalizado en la actividad de

• La manera de llevarla adelante.

• Templates para la especificación de requerimientos de cambio y

• Caracterización de cada uno de sus atributos en base a una

• Métricas y gráficos para la medición y toma de decisiones sobre

AIT - Herramienta de Soporte: se presenta a ImpactTrace, una

Caso Práctico I y II: estos capítulos ofrecen al lector ejemplos

1.2 Áreas de desenvolvimiento y conocimiento

Entiendo que la introducción de este trabajo debe incluir una

Durante la cursada de la carrera de grado de Ingeniería en

experiencias laborales. En las mismas me desarrollé en actividades

En cuanto a tareas de desarrollo, he trabajado tanto sobre

En tareas de diseño o arquitectura, mis tareas principales podrían