delarosa-tesisdegradoingenieriainformatica

ANÁLISIS DE IMPACTO BASADOANÁLISIS DE IMPACTO BASADOANÁLISIS DE IMPACTO BASADOANÁLISIS DE IMPACTO BASADO
EN INFORMACIÓN DEEN INFORMACIÓN DEEN INFORMACIÓN DEEN INFORMACIÓN DE
TRAZABILIDAD Y DECISIONESTRAZABILIDAD Y DECISIONESTRAZABILIDAD Y DECISIONESTRAZABILIDAD Y DECISIONES
DE DISEÑODE DISEÑODE DISEÑODE 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
Universidad de Buenos Aires – Facultad de Ingeniería
Tesista: Martín de la Rosa
Página 2

Página 3
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 4

Página 5
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 6
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 7
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 8
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 9
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 10
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 11
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 12
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 13
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 14
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 15
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 16
- 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 17
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 18

Página 19
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 20
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 21
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 22
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 23
Stakeholder
Regla de Negocio
Necesidad del
Negocio
Especificación de Requerimientos
Backward from Requirements
Forward to 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
Backward to Requirements
Forward from Requirements
Este trabajo hará especial hincapié en la post-trazabilidad como
asistencia fundamental a la actividad de análisis de impacto.

Página 24
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 25
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 26
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 27
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 28
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 29
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 30
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 31
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 32
• 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 33
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 34
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.
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.
Predecidos y
Modificados
(Correcto)
Workproducts
predecidos
de ser modificados
(CEI)
Workproducts
realmente
Modificados (CIR)
No predecidos y
modificados
Predecidos y
no modificados
No predecidos y no
modificados
(Correcto)
Todos los
Workproducts

Página 35
• 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 36
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
Modelo de los
artefactos del dominio
¿Cuáles son los tipos
de objetos y
relaciones extraídos
del dominio del
sistema?
- Componentes de Programa y/o relaciones
- Componentes y/o relaciones de dominio
predefinidas
- Componentes y/o relaciones establecidas
por el usuario
- Ninguno
- Desconocido
Descomposición
¿Pueden los
componentes
analizados ser
descompuestos y
almacenados en la
herramienta / enfoque
de AI?
- Si, sintaxis y semántica por completo
- Si, sintaxis con cierta semántica
- Si, solo sintaxis
- No
- Desconocido
Especificación de
cambios
¿Cómo es el cambio
especificado frente al
enfoque de AI?
- Si, el cambio se especifica con un análisis
detallado
- Si, el cambio se especifica con un simple
análisis
- No, no aplica
- Desconocido
Especificación de
resultados
¿Cómo son los
resultados del AI
expresados?
- Reporte
- Exploración (Browsing)
- Vista de base de datos
- Ninguno
- Desconocido
Interpretación de
resultados
¿Cuánto esfuerzo es
requerido por el
usuario para
interpretar los
resultados del AI?
- Significante
- Poco
- Ninguno
- Desconocido
Otras funcionalidades
¿Qué otras
funcionalidades se
encuentran
disponibles para el
usuario?
- Explicaciones, métricas, animaciones /
grafos de impacto, opciones para
implementar el cambio, acceso a un histórico
de cambios, estrategias de cambio
sugeridas, caminos para testear el cambio,
etc.

Partes del enfoque (IA Parts)
Esta parte del framework se preocupa
involucradas en el enfoque de AI (que hace el enfoque, como lo hace, y
cuáles son las tareas de los agentes / herramientas involucradas).
La figura ilustra los elementos involucrados. Para expresar un cambio
específico, el enfoque de AI posee
El input, expresado en términos de dicho modelo d
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
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
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
sis de Impacto basado en información de trazabilidad
Facultad de Ingeniería
Partes del enfoque (IA Parts)
Esta parte del framework se preocupa de las partes funcionales
on las tareas de los agentes / herramientas involucradas).
específico, el enfoque de AI posee un modelo propio de objetos y relaciones.
El input, expresado en términos de dicho modelo de objetos de interfaz, es
traducido en el modelo de objetos interno al enfoque.
un cierto repositorio (base de datos, CVS, etc.). El repositorio puede poseer
descomponiendo los componentes al modelo interno de objetos y
: Martín de la Rosa
: Lic. Pablo Cosso
las partes funcionales
on las tareas de los agentes / herramientas involucradas).
modelo propio de objetos y relaciones.
e objetos de interfaz, es
datos, CVS, etc.). El repositorio puede poseer
descomponiendo los componentes al modelo interno de objetos y relaciones.

Página 38
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
Modelo de objetos de interfaz
¿Qué objetos y relaciones
pueden ser expresados en la
interfaz de usuario del
enfoque?
- Strings, objetos de
programa, objetos
predefinidos de documentos,
desconocido
Modelo interno de objetos
utiliza el enfoque?
- Orientado en documentos,
basado en objetos, estructura
de grafos, ninguno,
desconocido
Modelo de Impacto
¿Cómo son modeladas las
dependencias? ¿Cuándo
estas dependencias son
tenidas en cuenta? ¿Qué tan
bien las dependencias del
modelo se reflejan con las
del sistema?
- Flujo de datos, control de
flujo, matcheo de strings,
dependencia entre objetos,
ninguno, desconocido
Enfoque de trazas
¿Qué algoritmos o
procedimientos son
utilizados por el enfoque
para calcular el impacto en
base a las trazas?
- Descomposición, búsquedas
heurísticas, no explícito,
Descomposición
son capturados del sistema y
almacenados internamente
en el enfoque?
- Entidades de base de datos,
objetos, clases, ninguno,
desconocido

Página 39
Repositorio
¿Qué repositorio es utilizado
para el almacenamiento de
objetos y relaciones?
- Motor de base de datos
relacional, file system,
Carga, modificación,
navegación
¿Qué funcionalidades brinda
el repositorio para la carga,
modificación y navegación
de los elementos
almacenados en él?
navegación, todos, ninguno,
desconocido
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 40
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:
#
#
##
CEI
CII
IEvsCEICII == α
Resultado Interpretación
IEα = 1 Mejor estimación. Siempre deseado.
K < IEα < 1
donde 0 < K < 1
K sugerido 0.7
Estimación esperada. CEI# es apenas mayor
al CII#.
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:
#
#
##
SIS
CEI
SEvsCEISIS == α

Página 41
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
donde 0 < J < 1
Mejor estimación. Se estimó que el cambio
no afecta a todo el sistema.
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
CEI# = CIR#;
CEI# ⊆ SIS#
1
#
#
=
CEI
CIR
Lo ideal. Lo estimado como
impactado es igual a lo que
realmente se modifica. Si esto
ocurre muy frecuentemente,
puede ser una señal de que el AI
no sirva de mucho.
|CEI#| > |CIR#|;
CIR# ⊂ CEI#;
CEI# ⊆ SIS#
1
#
#
<<
CEI
CIR
H
donde 0 < H < 1
Estimación “segura”. Lo
estimado contiene a lo realmente
impactado y además el conjunto
estimado no es mucho mayor al
impactado real.
|CEI#| >> |CIR#|;
CIR# ⊂ CEI#;
CEI# ⊆ SIS#
H
CEI
CIR
<
#
#
Tomando el H definido
en la fila anterior
Estimación “segura” pero no tan
buena. Existe un gran salto entre
lo impactado realmente y lo
estimado, lo que significa que
hay que chequear bastante al
CEI para arribar al CIR.
|CIR#| > |CEI#|;
CEI# ⊂ CIR#;
CEI# ⊆ SIS#
1
#
#
<<
CIR
CEI
M
donde 0 < M < 1
Estimación esperada. El AI es
aproximado y se queda corto a lo
que realmente debe ser
modificado.
|CIR#| >> |CEI#|;
CEI# ⊂ CIR#;
CEI# ⊆ SIS#
M
CIR
CEI
<
#
#
Tomando el M definido
en la fila anterior
Estimación no muy buena. Gran
salto entre lo estimado y lo
realmente impactado,
significando un trabajo extra para
descubrir el CIR.

Página 42
|CIR# ∩CEI#|>0;
CIR# ≠ CEI#;
CEI# ⊆ SIS#
|CIR# ∩CEI#| > 0
Estimación no muy buena. Se
necesita un trabajo extra para
chequear los objetos del CEI que
no están en el CIR. Ídem para
descubrir los objetos del CIR que
no están en el CEI.
|CIR# ∩CEI#|=0;
CEI# ⊆ SIS#
|CIR# ∩CEI#| = 0
Estimación no muy buena. Una
peor versión del caso presentado
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 43
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 44
• 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
El In-Degree XIX
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:
∑=ℜ→ TtWorkproducnIn :)( Siendo }},{{ TrazanbT ∈=
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:
∑=ℜ→ TtWorkproducnOut :)( Siendo }},{{ TrazabnT ∈=

Página 45
2.4.2 Ripple
Arnold y Bohner XIX
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 46
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 47
• OptimalTrace 11.8
: 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 48
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 49
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 50
3.1 Diagrama del Proceso

Página 51
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.
4
Revisor: Persona encargada de revisar la documentación de
trazabilidad generada. Puede ser el mismo moderador
5
Analista de Cambios: Persona encargada de llevar adelante los
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 52
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 53
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
proyecto
Proceso RUP – Fase Concepción Y
Definición de las herramientas
y tecnología a utilizar durante el
proyecto
Proceso RUP – Fase Concepción
Entradas - ¿Qué productos utiliza esta actividad?
Esta actividad no utiliza ningún producto.

Página 54
Actividad Padre: Esta actividad no posee actividad padre.
Sub-actividades, procedimiento, método - ¿Cómo se implementa
esta actividad?
Paso Nombre y Descripción
1
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
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.
2
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
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
de configuración de trazabilidad
Definición de Extractores
Salidas - ¿Qué productos son producidos en esta actividad?
Producto Actividad a la que está destinado
Definición de configuración de
trazabilidad
- Definición de Extractores
- Traspaso de conocimiento
- Revisión

Página 55
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 trazabilidad
Configuración de
Trazabilidad
Producto Actividad que lo origina
trazabilidad
Configuración de Trazabilidad

Página 56
Actividad Padre: Configuración de Trazabilidad
esta actividad?
1
Implementación de Extractores de Workproducts: Es recomendable
que para cada tipo de workproduct se implemente un extractor
correspondiente, siempre y cuando la tecnología utilizada lo permita.
2
Implementación de Extractores de Trazas: De manera de cumplir
con uno de los objetivos de este trabajo, que es el de reducir el
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
trazas
Traspaso de conocimiento
Extractores de Trazabilidad
- Traspaso de conocimiento
- Identificación

Página 57
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
Trazabilidad
Y
Disponibilidad de extractores Definición de Extractores
trazabilidad
Extractores de Trazabilidad Definición de Extractores

Página 58
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?
1
Distribuir y explicar documentación de trazabilidad a cada miembro del
equipo de proyecto.
2
Establecer para cada rol y miembro del equipo, como y de que manera
identificar y dejar documentación de trazas y workproducts.
actividad sigue?
Se asignaron los responsables
de la identificación de cada tipo
de workproduct, instruyéndolos
en el uso de los extractores.
Identificación
Definición de responsabilidades Identificación

Página 59
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
trazas
Fase Construcción
Extractores de Trazabilidad Definición de Extractores

Página 60
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
respectivos
Revisión
Información de Trazabilidad Revisión

Página 61
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
identificadas
Identificación de Trazas y
Workproducts
Información de Trazabilidad Identificación
Definición de Configuración de
Trazabilidad

Página 62
Actividad Padre: Identificación de Trazas y Workproducts
esta actividad?
1
Validar que los workproducts y trazas identificadas estén de acuerdo a
la configuración de trazabilidad
2
Verificar existencia de requerimientos no trazados hacia ningún
workproduct
3 Mantener un registro de aquellos workproducts sin trazas
actividad sigue?
Todos los workproducts y
trazas nuevas han sido
revisados
No posee
Registro de trazabilidad Revisión

Página 63
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 64
Actividad Padre: Esta actividad no posee actividad padre.
esta actividad?
1
Identificación de workproducts que aparentemente se verán
impactados por el cambio (Conjunto de Inicio de Impacto – CII)
2
Estimación de los workproducts impactados (Conjunto Estimado de
Impacto – CEI) aplicando efecto de ripple sobre el CII
3 Cuantificación del impacto estimado
actividad sigue?
Se alcanza un CEI y se
cuantifica el impacto
Implementación del Cambio
Conjunto Estimado de Impacto (CEI) Proceso de Administración del
Cambio
Cuantificación del Impacto Proceso de Administración del
Cambio

Página 65
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 66
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 67
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 68
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
i
iWPS
1
siendo WPi cada workproduct identificado y n la cantidad
total de workproducts del Sistema.

Página 69
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
j
ji WPF
1
siendo WPj cada workproduct identificado en la fase Fi.
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
j
ji WPTWP
1
siendo WPj cada workproduct del tipo TWPi.
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
i
n
i
n
j
i TWPijFS
1 1 1
siendo Fi una fase en particular del Sistema y
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 70
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:
jiTV WPWPf →)( 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:
jiTH WPWPf →)( 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 71
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 72
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
CasodeUso
Especificación
Suplementaria
Caso Uso 0..n 0..n
Especificación
Suplementaria
0 0..n
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 73
4.1.4.1.2 Casos de Uso inducidos a partir de Funcionalidades
Necesidad
Funcionalidad
CasodeUso
Especificación
Suplementaria
Necesidad 0..n 1..n 0 0
Funcionalidad 0 0..n 1..n 0
Caso Uso 0 0 0..n 0..n
Especificación
Suplementaria
0 0 0 0..n
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)
Funcionalidad
Requerimiento
CasodeUso
Funcionalidad 0..n 1..n 0
Requerimiento 0 0..n 1..n
Caso Uso 0 0 0..n

Página 74
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
Necesidad
Funcionalidad
Requerimiento
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
Necesidad
CasodeUso
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 75
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.
CasodeUso
Entidadde
Dominio
Objetode
Periferia
Objetode
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 76
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 77
Componentes
Vista
Componentes
Control
Componentes
Modelo
Componentes
Infraestructura
Componentes
Vista
0..n 0..n 0 0
Componentes
Control
0 0..n 0..n 0
Componentes
Modelo
0 0 0..n 0..n
Componentes
Infraestructura
0 0 0 0..n
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 78
Objetivo
Requerimiento
Estructurado
Paso
Link
Casode
Prueba
Objetivo 0 0..n 0 0 0
Requerimiento
Estructurado
0 0..n 0..n 0..n 0..n
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 79
La configuración de trazabilidad que se propone es la siguiente:
Componente
Vista
Componente
Control
Componente
Modelo
Componente
Infraestructura
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:
Componente
Vista
Componente
Control
Componente
Modelo
Componente
Infraestructura
Objeto Periferia 1..n 0 0 0
Objeto Control 0 1..n 0 0
Entidad Dominio 0 0 1..n 0

Página 80

Página 81
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 82
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 83
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 84
presentan ejemplos de trazabilidad documentados en EA durante el primer
caso práctico.
5.2.1 Trazabilidad entre Requerimientos
5.2.2 Trazabilidad entre Requerimientos y Casos de Uso
cd Formal Requirements
Restricciones
por perfil de
usuario
Control de
promociones
activas
Control de carga de artículos y
estructuras comerciales
Administración de perfiles,
usuarios y permisos
Templates de
Promociones
Administración de
Templates
Campos editables
Grupo de Templates
«trace»
«trace»
«trace»
«trace»
«trace»
«trace»
cd Traces Req-UseCase
Administración de
Templates Crear
Template
Editar
Template
Eliminar
Template
Buscar
Template
Campos editables
Editar Acceso
Campo
Grupo de Templates
ABM Grupo de
Template
«trace»
«trace»
«trace»
«trace»
«include»
«trace»
«trace»
«include»

Página 85
5.2.3 Trazabilidad entre Casos de Uso y Vistas
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.
cd Traces UseCase-Screen5
Eliminar Template
Buscar Template
/template/template_filter.jsp
Editar Condicion
Template
/template/template_condition_date.jsp
/template/template_condition_exclude_tab.jsp
/template/template_condition_item_tab.jsp
/template/template_condition_promo_variable.jsp
/template/template_condition_value.jsp
Seleccionar Tipo
Condicion
«trace»
«trace»
«trace»
«trace»
«trace»
«trace»
«trace»
«include»

Página 86
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
Struts ActionForms
Workproducts Vista
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 87
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 88
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 89
• 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 90
…
<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 91
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 92
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
EA Extractor
- Workproducts de la Etapa de Análisis (Requerimientos,
Casos de Uso, etc.) y trazas entre los mismos.
- Trazabilidad entre workproducts de Análisis y workproducts
de Implementación, más específicamente las Vistas.
Struts Extractor
- Workproducts de la Etapa de Implementación: Capa Vista
(Java Server Pages y ActionForms), Capa Control (Actions
Struts).
- Trazabilidad entre workproducts de Vista y Control.
JAVA Dependency Extractor
- Trazabilidad implícita de la Etapa de Implementación en
base a dependencias de código.
- Workproducts de Modelo e Infraestructura (Clases y
métodos)
- Trazabilidad entre Capa de Control y Modelo.
- Trazabilidad entre Capa de Modelo e Infraestructura.
Tabla
Paquete
Stored
Procedure
Función

Página 93
Doclet Extractor
- Trazabilidad explícita entre Etapa de Análisis e
Implementación en base a anotaciones documentadas en el
código.
DataBase Generic Extractor
- Trazabilidad implícita en capa de Infraestructura de la
Etapa de Implementación: Stored Procedures, Tablas y
Cambos/Columnas de Tablas de una Base de Datos.
Oracle Extractor
- Trazabilidad implícita en capa de Infraestructura de la
Etapa de Implementación: Paquetes, Stored Procedures,
Funciones, Tablas. Específico para RDBM Oracle.

Página 94

Página 95
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 96
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 97
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
Modelo de los
artefactos del dominio
¿Cuáles son los tipos
de objetos y
relaciones extraídos
del dominio del
sistema?
- Componentes y/o relaciones de análisis
predefinidas
- Componentes y/o relaciones de diseño
predefinidas
- Componentes de Programa y/o relaciones
Descomposición
¿Pueden los
componentes
analizados ser
descompuestos y
almacenados en la
herramienta / enfoque
de AI?
- Si, solo sintaxis
Especificación de
cambios
¿Cómo es el cambio
especificado frente al
enfoque de AI?
- Si, el cambio se especifica con un simple
análisis. Se establece un template para la
especificación del cambio y demás
parámetros de entrada al enfoque de AI. Ver
Sección 6.3
Especificación de
resultados
¿Cómo son los
resultados del AI
expresados?
- Template para la especificación del
resultado de AI. Ver Sección 6.4
Interpretación de
resultados
¿Cuánto esfuerzo es
requerido por el
usuario para
interpretar los
resultados del AI?
- Poco
Otras funcionalidades
¿Qué otras
funcionalidades se
encuentran
disponibles para el
usuario?
- Configuración de trazabilidad
- Visualización de workproducts sin trazas
- Sincronización de trazabilidad.

Página 98
IA Parts – Elementos diferenciadores
Modelo de objetos de interfaz
pueden ser expresados en la
interfaz de usuario del
enfoque?
- Cualquier workproduct que
haya sido debidamente
establecido en la
(ej. requerimientos, decisiones
de diseño, clases de modelo,
etc.).
Modelo interno de objetos
utiliza el enfoque?
- Orientado a objetos.
Básicamente cada
workproduct es un objeto y
una traza es otro objeto que
relaciona dos workproducts.
Modelo de Impacto
¿Cómo son modeladas las
dependencias? ¿Cuándo
estas dependencias son
tenidas en cuenta? ¿Qué tan
bien las dependencias del
modelo se reflejan con las
del sistema?
- Una dependencia entre dos
workproducts es modelada a
través de una traza. Una traza
es un objeto que compone a
dos workproducts: uno origen
y otro destino.
Enfoque de trazas
¿Qué algoritmos o
procedimientos son
utilizados por el enfoque
para calcular el impacto en
base a las trazas?
- Ninguno. Las trazas se
recorren en forma manual y
se va calculando el impacto
de manera incremental
partiendo de los workproducts
origen (conjunto de inicio de
impacto).
Descomposición
son capturados del sistema y
almacenados internamente
en el enfoque?
- Todos los que hayan sido
debidamente establecidos en
la configuración de
trazabilidad.
Repositorio
¿Qué repositorio es utilizado
para el almacenamiento de
objetos y relaciones?
- Motor de base de datos
relacional.
navegación
¿Qué funcionalidades brinda
el repositorio para la carga,
modificación y navegación
de los elementos
almacenados en él?
- Todos (Carga, modificación
y navegación).

Página 99
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
Clasificación
[Corrección / Agregado o borrado de
funcionalidad / Modificación funcional]
Analista de Cambios
Posible
implementación
[Descripción funcional y/o técnica para
la implementación del cambio]
Arquitecto
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 100
Identificación del
Cambio / Iteración Nro.
[Identificación del cambio / Iteración Nro.]
Parámetros de Entrada
de la Iteración
[Completar solo a partir de la segunda iteración. Indicar que criterio se
lleva adelante sobre el análisis de impacto para llevar adelante esta
iteración]
Propósito del Análisis
de Impacto
[¿Qué resultado se espera obtener del análisis de impacto?]
Tipos de
Workproducts
analizados
[Enumeración de los Tipos de Workproducts utilizados]
Tipos de Trazas
utilizados
[Forward / Backward]
Conjunto de Inicio de
Impacto (CII)
[Enumeración de workproducts que integran el Conjunto de Inicio de
Impacto]
Resultado Obtenido
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:
TWP1
TWP2
…
TWPn
Total
Impactados y Predecidos
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 101
Métricas
[TipoWPi]
…
[TipoWPn]
Total
#CEITWP / #TWP … … … …
#CIRTWP / #CEITWP … … … …
#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]
Conclusiones de
Iteración
[Dejar constancia de la aceptación o no de los resultados obtenidos por
la iteración del análisis de impacto. Aclarar si es necesario realizar una
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:
TWPnTWPTWP CEICEICEICEI ∪∪∪= ...21

Página 102
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:
TWP
CEI
TWPvsCEI TWP
TWP =. Donde TWP es el tipo de workproduct elegido
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 103
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
0
5
10
15
20
25
30
35
40
45
50
0 1 2 3 4 5 6 7 8 9 10 11
Distancia
CEI
Requerimiento Caso de Uso Decision Diseño
Implementacion Vista Implementacion Control Implementacion Modelo
Implementacion Infraestructura

Página 104
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
0
50
100
150
200
250
300
R
equerim
iento
C
asos
de
U
so
D
ecision
D
iseño
V
ista
C
ontrol
M
odelo
Infraestructura
Tipos de Workproducts
CantidaddeWorkproducts
WorkProducts Impactados Total de WorkProducts

Página 105
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.
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
CEItwp vs. Tipo de Workproduct
0,23
0,41
0,50
0,23 0,22
0,43
0,72
0,3 0,3 0,3 0,3 0,3 0,3 0,3
0,00
0,10
0,20
0,30
0,40
0,50
0,60
0,70
0,80
R
equerim
iento
C
a
sos
de
U
so
D
e
cision
D
ise
ño
V
ista
C
ontrol
M
odelo
Infraestructura
CEI/WP Etapa Valor Referencia

Página 106
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.
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
CEI Acumulado por distancia
0
10
20
30
40
50
60
70
0 1 2 3 4 5 6 7 8 9 10 11
Distancia
CEIAcumulado
Requerimiento Casos de Uso Decision Diseño Vista
Control Modelo Infraestructura

Página 107
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:
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.
0
0,2
0,4
0,6
0,8
1
1,2
1,4
1,6
TWP1 TWP2 TWP3 TWP4 TWP5 TWP6 TWP7
CEI=CIR
CEI>>CIR
CEI<<CIR
CIR/CEI

Página 108
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 109
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 110
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.

7.2 Clases de Dominio
Clase
Workproduct
Modela un workproduct.
Atributos:
- traces: colección de trazas hacia delante.
- backwardTraces: colección de trazas hacia atrás.
- phase: fase/etapa a la que pertenece.
- type: identifica
Trace
Modela una dependencia entre dos workproducts. Dicha dependencia
modela el impacto que un workproduct origen puede tener sobre un
workproduct destino.
Atributos
- sourceWP: workproduct origen de la traza.
- targetWP: workproduct destino de
- extractedBy: agregación con el extractor que dio origen a esta traza.
WPType
Modela un tipo de workproduct en particular.
Atributos:
- extractors: colección de extractores capaces dar origen a este tipo de
workproducts.
sis de Impacto basado en información de trazabilidad
Facultad de Ingeniería
Clases de Dominio
Descripción
Modela un workproduct.
Atributos:
traces: colección de trazas hacia delante.
backwardTraces: colección de trazas hacia atrás.
phase: fase/etapa a la que pertenece.
type: identifica su tipo.
workproduct destino.
Atributos
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:
extractors: colección de extractores capaces dar origen a este tipo de
workproducts.
: Martín de la Rosa
: Lic. Pablo Cosso
extractedBy: agregación con el extractor que dio origen a esta traza.
extractors: colección de extractores capaces dar origen a este tipo de

Página 112
ExtractorType
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.
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.
WPExtractorType
Modela un tipo de extractor de workproducts. El usuario al definir
extractores de workproducts de un proyecto estará creando instancias
de esta clase y señalando la implementación concreta del extractor a
través del atributo implementationClass.
TraceExtractorType
Modela un tipo de extractor de trazas. El usuario al definir extractores
de trazas de un proyecto estará creando instancias de esta clase y
señalando la implementación concreta del extractor a través del atributo
implementationClass.
WPExtractor
Interfaz que deberá ser implementada para proveer a la plataforma de
un nuevo extractor de workproducts.
Métodos:
- Vector<Workproduct> getWorkProducts(): devuelve un vector de
workproducts extraídos.
TraceExtractor
Interfaz que deberá ser implementada para proveer a la plataforma de
un nuevo extractor de trazas.
Métodos:
- Vector<Trace> getTraces(): devuelve un vector de trazas extraídas.
PhaseType
Modela los diferentes tipos de fases/etapas que pueden encontrarse en
un proyecto de software. Al momento de configurar la trazabilidad, el
usuario indicará para cada tipo de fase los tipos de workproducts con
los que cuenta.
Phase
Modela una fase en particular de un proyecto.
Atributos:
- workproducts: colección de workproducts propios de esta fase.
Project
Modela un proyecto. Es el punto de partida para la configuración de
trazabilidad.
Atributos:
- users: stakeholders asociados al proyecto con sus respectivos roles
dentro del mismo.
- phases: fases/etapas propias del proyecto.
User
Modela un stakeholder de un proyecto. Cada usuario podrá estar
asociado a uno o mas proyectos con un respectivo rol.

Página 113
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 114
CasodeUso1
CasodeUso2
CasodeUso3
CasodeUso4
CasodeUso5
CasodeUso6
CasodeUso7
CasodeUso8
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 115
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 116
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 117
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 118
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 119
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 120
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 121
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 122
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.
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.
Traspaso de
Conocimiento
Identificación Revisión
Proceso AIT implementado sobre RUP
Fase Actividad Proceso AIT
Concepción
Elaboración
Construcción
Transición
Producción
Configuración de
Trazabilidad Definición de
Extractores
Análisis de
Impacto
t

Página 123
Requerimiento
CasodeUso
DecisiónDiseño
Vista
Control
Modelo
Infraestructura
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
Vista
Java Server Pages
Struts Action Forms
Control
Struts Action Classes
Struts Action Methods
Modelo
JAVA Classes
JAVA Methods
Infraestructura
JAVA Classes
JAVA Methods

Página 124
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
Analista
Requerimiento
Caso de Uso
Requerimiento – Requerimiento
Requerimiento – Caso de Uso
Caso de Uso – Caso de Uso
Caso de Uso – Vista
Arquitecto Decisión de Diseño
Caso de Uso – Decisión de Diseño
Decisión de Diseño – Decisión de Diseño
Decisión de Diseño – Vista
Decisión de Diseño – Control
Decisión de Diseño – Modelo
Decisión de Diseño – Infraestructura
Desarrollador
Implementación Vista
Implementación Control
Implementación Modelo
Implementación Infraestructura
Vista – Vista
Vista – Control
Control – Control
Control – Modelo
Modelo – Modelo
Modelo – Infraestructura
Infraestructura - Infraestructura

Página 125
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
Origen
Workproduct
Destino
Cantidad
identificada
1 Requerimiento Requerimiento 14
2 Requerimiento Caso de Uso 27
3 Caso de Uso Caso de Uso 43
4 Decisión de
Diseño
Decisión de
Diseño
0
5 Vista Vista 30
6 Vista Control 322
7 Control Control 189
8 Control Modelo 661
9 Modelo Modelo 116

Página 126
10 Modelo Infraestructura 35
11 Infraestructura Infraestructura 1
12 Caso de Uso Decisión de
Diseño
2
13 Caso de Uso Vista 53
14 Decisión de
Diseño
Vista 0
15 Decisión de
Diseño
Control 1
16 Decisión de
Diseño
Modelo 1
17 Decisión de
Diseño
Infraestructura 1
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 127
Cambio No. 1
Identificación Cambio 001
Enunciado
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
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
Posible implementación del
cambio
Se editará cada workproduct de interfaz (.jsp), y para cada
control editable se agregará el tooltip mediante código
HTML.

Página 128
Identificación del
Cambio 001 / 1
de Impacto
Identificar todas las interfases relacionadas a la creación y edición
de promociones.
Tipos de
Workproducts
Analizados
- Requerimiento
- Vista
Tipos de Trazas
utilizadas
- Trazas forward
Impacto (CII)
- R624: Requerimiento Promociones
Resultado Obtenido
Requerimiento
Vista
Total
Impactados y Predecidos 2 22 24
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
Métricas
Requerimiento
Vista
Total
#CEI / #TWP 0.227 0.291 0.283
#CIR / #CEI 0.4 0.5 0.49
#CII / #CEI 0.002

Página 129
Gráficos
Conclusiones de
Iteración
Los valores de #CEI / #TWP son todos aceptables. No se requiere de otra
iteración.

Página 130
Cambio No. 2
Enunciado
Generación de archivos de promociones por sucursal.
Actualmente la generación de archivos de promociones se
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.
cambio
Este cambio afectará:
- interfaz de generación manual de archivos de
promociones agregándose un combo-box para la
selección de la sucursal que se quiere,
- 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 131
Identificación del
Cambio / Iteración
Nro.
Cambio 002 / 1
Propósito del
Análisis de
Impacto
Identificar la interfaz de generación manual de archivo de
promociones, el control propio a la misma, y las clases de modelo
relacionadas.
Tipos de
Workproducts
Analizados
- Requerimientos
- Casos de Uso
- Implementación Vista
- Implementación Control
- Implementación Modelo
Tipos de Trazas
utilizadas
- Trazas forward
Conjunto de Inicio
de Impacto (CII)
- R633: Requerimiento Generación Manual de archivos de
promociones
Resultado
Obtenido
Requerimiento
CasodeUso
Vista
Control
Modelo
Total
Impactados y Predecidos 1 1 1 1 1 5
No Impactados y No
Predecidos
21 53 150 253 90 567
Impactados y No
Predecidos
0 0 0 0 0 0
No Impactados y
Predecidos
0 0 0 1 47 48
#CEI 1 1 1 2 48 53
#TWP 22 54 151 255 138 620
Métricas
Requerimiento
CasodeUso
Vista
Control
Modelo
Total
#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 132
Gráficos
Conclusiones de
Iteración
Valores de #CEI / #TWP aceptables excepto para los workproducts del
tipo Modelo (0.348). Observando el gráfico CEI Acumulado Según
Distancia se nota un ripple marcado a partir de distancia 4.
Proponemos una nueva iteración quedándonos con datos de impacto
hasta una distancia 4 inclusive.

Página 133
Identificación del
Cambio 002 / 2
de la iteración
Analizar impacto hasta distancia igual a 4 inclusive.
de Impacto
Identificar la interfaz de generación manual de archivos de
promociones, el control propio a la misma, y las clases de modelo
relacionadas.
Tipos de
Workproducts
Analizados
- Requerimientos
- Casos de Uso
Tipos de Trazas
utilizadas
- Trazas forward
Impacto (CII)
- R633: Requerimiento Generación Manual archivos de
promociones
Resultado Obtenido
Requerimiento
CasodeUso
Vista
Control
Modelo
Total
Impactados y
Predecidos
1 1 1 1 1 5
No Impactados y No
Predecidos
21 53 150 253 136 613
Impactados y No
Predecidos
0 0 0 0 0 0
No Impactados y
Predecidos
0 0 0 1 1 2
#CEI 1 1 1 2 2 7
#TWP 22 54 151 255 138 620

Página 134
Métricas
Requerimiento
CasodeUso
Vista
Control
Modelo
Total
#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
Iteración
Valores de #CEI / #TWP aceptables. No se requiere de una
siguiente iteración.

Página 135
Cambio No. 3
Enunciado
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
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.
cambio
- Interfaz y controles propios de la interfaz de
administración de perfiles.
- 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 136
Identificación del
Cambio 003.a / 1
de Impacto
Identificar interfaces y controles impactados de la administración
de perfiles.
Tipos de
Workproducts
Analizados
- Requerimientos
Tipo de trazas
utilizadas
- Trazas forward
Impacto (CII)
- R619: Requerimiento Administración de perfiles, usuarios
y permisos.
Resultado Obtenido
Requerimiento
Vista
Control
Total
Impactados y Predecidos 1 1 3 5
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
Métricas
Requerimiento
Vista
Control
Total
#CEI / #TWP 0.046 0.007 0.02 0.016
#CIR / #CEI 1 1 0.6 0.714
#CII / #CEI 0.143

Página 137
Gráficos
Conclusiones de
Iteración

Página 138
Identificación del
Cambio 003.b / 1
de Impacto
Identificar interfaces y controles impactados en la asociación de
sucursales a una promoción.
Tipos de
Workproducts
Analizados
- Requerimientos
- Caso Uso
Tipo de trazas
utilizadas
- Trazas forward.
Impacto (CII)
Resultado Obtenido
Requerimiento
CasoUso
Vista
Control
Total
Impactados y Predecidos 2 2 1 3 8
No Impactados y No
Predecidos
17 27 107 193 344
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
Métricas
Requerimiento
CasoUso
Vista
Control
Total
#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 139
Gráficos
Conclusiones de
Iteración
Valor de #CEI / #TWP de Caso de Uso no aceptable. Se requiere
una nueva iteración seleccionando con mayor granularidad el CII
en base a un análisis de los casos de uso impactados.

Página 140
Identificación del
Cambio 003.b / 2
de iteración
Aumentar granularidad de CII descartando del CEI de Caso de Uso de
iteración 1 los workproducts que se creen no impactados
de Impacto
Identificar interfaces y controles impactados en la asociación de
sucursales a una promoción.
Tipos de
Workproducts
Analizados
- Requerimientos
- Casos de Uso
Tipos de Trazas
utilizadas
- Trazas forward
Impacto (CII)
- R651: Administración – Alta / Baja / Modificación
- CU581: Editar Promoción
- CU601: Asignar Jerarquía / Sucursal a Promoción
Resultado Obtenido
Requerimiento
CasodeUso
Vista
Control
Total
No Impactados y No
Predecidos
17 52 147 246 462
#CEI 5 2 3 9 19
#TWP 22 54 151 255 482

Página 141
Métricas
Requerimiento
CasodeUso
Vista
Control
Total
#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
Iteración
Valores de #CEI / #TWP aceptables. No se requiere de una siguiente
iteración.

Página 142
Identificación del
Cambio 003.c
de Impacto
Identificar clase de modelo referente a un Perfil de Usuario
Tipos de
Workproducts
Analizados
- Requerimientos
Tipo de trazas
utilizadas
- Trazas forward.
Impacto (CII)
- R619: Requerimiento Administración de Perfiles, usuarios
y permisos
Resultado Obtenido
Requerimiento
Modelo
Total
Impactados y Predecidos 1 1 2
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
Métricas
Requerimiento
Modelo
Total
#CEI / #TWP 0.06 0.24 0.212
#CIR / #CEI 1 0.03 0.06
#CII / #CEI 0.03

Página 143
Gráficos
Conclusiones de
Iteración

Página 144
Cambio No. 4
Enunciado
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
en modo consulta.
Consideraciones:
- No afecta la impresión de reportes
cambio
- Interfases de reportes de promociones

Página 145
Identificación del
Cambio 004 / 1
de Impacto
Identificar las interfases relacionadas con reportes de
promociones
Tipos de
Workproducts
Analizados
- Requerimientos
- Casos de Uso
- Vista
Tipo de trazas
utilizadas
- Trazas forward.
Impacto (CII)
- R636: Requerimiento Reportes
Resultado Obtenido
Requerimiento
CasodeUso
Vista
Total
#CEI 1 4 5 10
#TWP 22 54 151 227
Métricas
Requerimiento
CasodeUso
Vista
Total
#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 146
Gráficos
Conclusiones de
Iteración

Página 147
Cambio No. 5
Enunciado
La tabla STRUCTURES posee como clave única el campo
CODE. La clave única debería estar formada por los campos
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
cambio
Modificar el archivo XML de mapeo de entidad hibernate
tanto para la entidad Structure como StructureLevel.

Página 148
Identificación del
Cambio 005 / 1
de Impacto
Identificar las interfases y casos de uso posiblemente impactados
con la finalidad de realizar testing de regresión.
Tipos de
Workproducts
Analizados
- Casos de Uso
- Vista
- Modelo
- Infraestructura
Tipo de trazas
utilizadas
- Trazas backward
Impacto (CII)
- II568: Implementación Infraestructura StructureHome
- II569: Implementación Infraestructura StructureLevelHome
Resultado Obtenido
CasodeUso
Vista
Modelo
Infraestructura
Total
#CEI 43 76 31 2 152
#TWP 54 151 138 32 375
Métricas
CasodeUso
Vista
Modelo
Infraestructura
Total
#CEI / #TWP 0.796 0.503 0.225 0.063 0.405
#CII / #CEI 0.013
Gráficos

Página 149
Conclusiones de
Iteración
Valores de #CEI / #TWP para nada aceptables. Se observa un gran
ripple. Se propone una siguiente iteración partiendo de un análisis
del CEI de Modelo.

Página 150
Identificación del
Cambio 005 / 2
de la Iteración
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
workproducts no formarían parte del CIR.
de Impacto
Identificar las interfases y casos de uso posiblemente impactados con
la finalidad de realizar testing de regresión.
Tipos de
Workproducts
Analizados
- Casos de Uso
- Vista
- Modelo
- Infraestructura
Tipo de trazas
utilizadas
- Trazas backward
Impacto (CII)
- II568: Implementación Infraestructura StructureHome
- II569: Implementación Infraestructura StructureLevelHome
Resultado Obtenido
CasodeUso
Vista
Modelo
Infraestructura
Total
#CEI 15 11 4 2 32
#TWP 54 151 138 32 375
Métricas
CasodeUso
Vista
Modelo
Infraestructura
Total
#CEI / #TWP 0.278 0.073 0.029 0.063 0.085
#CII / #CEI 0.063
Gráficos

Página 151
Conclusiones de
Iteración
Valores de #CEI / #TWP aceptables. No se requiere una siguiente
iteración.

Página 152
Cambio No. 6
Enunciado
Posibilidad de realizar búsquedas sobre grillas de elementos
seleccionados (items, departments, manufacturers,
mixmatches)
cambio
Agregar a la pantalla de asignación de elementos a
promociones un radio button para seleccionar si la búsqueda
se realiza sobre elementos seleccionados o no
seleccionados.

Página 153
Identificación del
Cambio 006 / 1
de Impacto
Identificar el impacto sobre workproducts de Etapa Implementación.
Tipos de
Workproducts
Analizados
- Casos de Uso
- Vista
- Control
- Modelo
- Infraestructura
Tipo de trazas
utilizadas
- Trazas forward
Impacto (CII)
- CU609: Agregar / Excluir elementos a Promoción
Resultado Obtenido
CasodeUso
Vista
Control
Modelo
Infraestructura
Total
No Impactados y No
Predecidos
0 0 0 0 0 0
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
Métricas
CasodeUso
Vista
Control
Modelo
Infraestructura
Total
#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 154
Gráficos
Conclusiones de
Iteración
Valor de #CEI / #TWP de Infraestructura no aceptable. Se propone
una siguiente iteración partiendo de un análisis del CEI de Control y
Modelo.

Página 155
Identificación del
Cambio 006 / 2
de la Iteración
El CEI de Control se reduce a solo el workproduct responsable de
la búsqueda de elementos (ncr.dpc.action.SearchElement).
Del CEI de Modelo se descarta el workproduct
ncr.dpc.domain.Application por presentar alto ripple.
de Impacto
Identificar el impacto sobre workproducts de Etapa
Implementación.
Tipos de
Workproducts
Analizados
- Casos de Uso
- Vista
- Control
- Modelo
- Infraestructura
Tipo de trazas
utilizadas
- Trazas forward
Impacto (CII)
- CU609: Agregar / Excluir elementos a Promoción
Resultado Obtenido
CasodeUso
Vista
Control
Modelo
Infraestructura
Total
No Impactados y No
Predecidos
0 0 0 0 0 0
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
Métricas
CasodeUso
Vista
Control
Modelo
Infraestructura
Total
#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 156
Gráficos
Conclusiones de
Iteración
iteración.

Página 157
Cambio No. 7
Enunciado
Añadir dos flags adicionales a nivel de promoción (“Aplicar
sobre productos iguales” – “Aplicar sobre precio de lista
menos descuentos anteriores”)
cambio
- Modificación de la interfaz gráfica de edición
detallada de una promoción, de manera de permitir
la edición de los valores de dichos flags.
- Adaptación de la generación de los archivos de
promociones para contemplar dichos flags.

Página 158
Identificación del
Cambio 007.a / 1
de Impacto
Identificar Workproducts Vista y Control referidos a la edición
detallada de una promoción.
Tipos de
Workproducts
Analizados
- Requerimientos
- Caso de Uso
Tipo de trazas
utilizadas
- Trazas forward
Impacto (CII)
Resultado Obtenido
Requerimiento
CasodeUso
Vista
Control
Total
No Impactados y No Predecidos 0 0 0 0 0
#CEI 5 27 44 60 136
#TWP 22 54 151 255 482
Métricas
Requerimiento
CasodeUso
Vista
Control
Total
#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 159
Gráficos
Conclusiones de
Iteración
Valor de #CEI / #TWP de Caso de Uso no aceptable. Se propone
una siguiente iteración refinando este CEI.

Página 160
Identificación del
Cambio 007.a / 2
de la Iteración
Se refina el CEI de Requerimiento y Casos de Uso realizando un
análisis detallado de los mismos.
de Impacto
Identificar Workproducts Vista y Control referidos a la edición
detallada de una promoción.
Tipos de
Workproducts
Analizados
- Requerimientos
- Caso de Uso
Tipo de trazas
utilizadas
- Trazas forward
Impacto (CII)
Resultado Obtenido
Requerimiento
CasodeUso
Vista
Control
Total
No Impactados y No Predecidos 0 0 0 0 0
#CEI 2 2 2 4 10
#TWP 22 54 151 255 482
Métricas
Requerimiento
CasodeUso
Vista
Control
Total
#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 161
Gráficos
Conclusiones de
Iteración
iteración.

Página 162
Identificación del
Cambio 007.b / 1
de Impacto
Identificar workproducts de Modelo respecto a la generación de
archivos de promociones
Tipos de
Workproducts
Analizados
- Requerimiento
- Caso de Uso
- Modelo
Tipo de trazas
utilizadas
- Trazas forward
Impacto (CII)
- R632: Requerimiento Generación automática de archivos
de promociones
- R633: Requerimiento Generación manual de archivos de
promociones
Resultado Obtenido
Requerimiento
CasodeUso
Modelo
Total
#CEI 2 2 51 55
#TWP 22 54 138 214
Métricas
Requerimiento
CasodeUso
Modelo
Total
#CEI / #TWP 0.091 0.037 0.37 0.257
#CIR / #CEI 1 1 0.02 0.091
#CII / #CEI 0.036

Página 163
Gráficos
Conclusiones de
Iteración
Valor de #CEI / #TWP de Modelo no aceptable. Se propone una
siguiente iteración refinando el CEI de Modelo.

Página 164
Identificación del
Cambio 007.b / 2
de la Iteración
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
descartando el workproduct ncr.dpc.domain.Application que
presenta alto ripple.
de Impacto
Identificar workproducts de Modelo respecto a la generación de
archivos de promociones
Impacto (CII)
- R632: Requerimiento Generación automática de archivos
de promociones
- R633: Requerimiento Generación manual de archivos de
promociones
Tipos de
Workproducts
Analizados
- Requerimiento
- Caso de Uso
- Modelo
Tipo de trazas
utilizadas
- Trazas forward
Resultado Obtenido
Requerimiento
CasodeUso
Modelo
Total
No Impactados y No
Predecidos
0 0 0 0
#CEI 2 2 31 35
#TWP 22 54 138 214
Métricas
Requerimiento
CasodeUso
Modelo
Total
#CEI / #TWP 0.091 0.037 0.225 0.164
#CIR / #CEI 1 1 0.032 0.143
#CII / #CEI 0.057

Página 165
Gráficos
Conclusiones de
Iteración
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 166
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 167
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 168
- 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
Workproduct
Etapa Implementación Descripción
Consulta Análisis
Especificación
Word
Cada requerimiento
del sistema podrá
verse como una
consulta.
Vista Implementación
Java Server
Pages (JSP)
Pantalla/Subpantalla
de una consulta en
particular. Contiene
los filtros de
búsqueda
específicos y la
visualización de
información.
Control Implementación Action Struts
Componentes de
control en respuesta
a eventos del usuario

Página 169
ServicioDAO Implementación
Patrón de
Diseño DAO
Servicio DAO para
acceso a base de
datos
Paquete Implementación
Paquete de
Oracle
Agrupamiento de
Stored Procedures
de Oracle
Stored
Procedure
Implementación
Procedimiento
Almacenado de
Oracle
Procedimiento para
resolver cierta lógica
de datos
Tabla Implementación Tabla de Oracle
Tabla para el
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.
Consulta
Vista
Control
ServicioDAO
Paquete
StoredProcedure
Tabla
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 170
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
extraída
Tipo de
trazabilidad
No disponible. Se
cargó manualmente la
información.
Workproduct: Consultas Explícita
StrutsPresentationExtr
actor
Workproduct: Vista Implícita
Struts Control
Extractor
Workproduct: Control
Trazas: Vista-Control
Implícita
DAOExtractor Workproduct: ServicioDAO Implícita
DependencyExtractor Trazas: Control-ServicioDAO Implícita
DocletExtractor Trazas: ServicioDAO-
StoredProcedure, ServicioDAO-
Paquete
Explícita
OracleExtractor Workproducts: Paquetes,
StoredProcedures, Tablas
Trazas: Paquete-Tabla,
StoredProcedure-Tabla
Implícita

Página 171
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
Origen
Workproduct Destino Cantidad
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
Procedure/Tabla
54
8 Paquete/Stored
Procedure
StoredProcedure/Tabla 13606
TOTAL TRAZAS 14052

Página 172
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
Enunciado
Modificación de estructura de la tabla MODELO. Se aumenta
el ancho de la columna de descripción de modelos de autos.
cambio
No Aplica.
Identificación del
Cambio 001 / 1
de Impacto
Identificar todas las consultas relacionadas con la tabla MODELO.
Tipos de
Workproducts
Analizados
- Tabla
- Stored Procedure
- ServicioDAO
- Vista
- Consulta
Tipos de Trazas
utilizadas
- Trazas backward
Impacto (CII)
- II26724: Tabla MODELO
Métricas
Infraestructura
Modelo
Requerimiento
Total
#CEI / #TWP 0.24 0.238 0.52 0.24

Página 173
Gráficos
Conclusiones de
Iteración
Los valores de #CEITWP / #TWP son aceptables excepto para el tipo de workproduct
Requerimiento (Consultas) = 0.52. Por otro lado el #CEI / TWP total es aceptable =
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 174
Cambio No. 2
Enunciado
Modificación de los parámetros de entrada del Stored
Procedure
CIS_PAGOS_PKG.BORRAR_TEMP_CTOS_PAGOS. Se
agregará un parámetro en el cual deberán indicarse los
conceptos de pago seleccionados por el usuario
concatenados por pipes.
cambio
Modificar ServicioDAO y componentes de control para
invocar al stored procedure con el nuevo parámetro.
Identificación del
Cambio 002
de Impacto
Identificar ServicioDAO y componentes de control a modificar.
Tipos de
Workproducts
Analizados
- Package
- ServicioDAO
- Control
Tipos de Trazas
utilizadas
- Trazas backward
Impacto (CII)
- II26724: Package CIS_PAGOS_PKG (Nota: no se contaba
con información del workproduct Stored Procedure:
BORRAR_TEMP_CTOS_PAGOS)

Página 175
Resultado Obtenido
Package
ServicioDAO
Control
Total
#CEI 1 2 5 8
#TWP 2318 42 152 2512
Métricas
Package
ServicioDAO
Control
Total
#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 176
Conclusiones de
Iteración
Los valores de #CEI / #TWP son todos aceptables. No se requiere de otra
iteración.
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 177
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 178
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 179
- 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 180

Página 181
10Conclusiones – 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 182
• 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 183
- 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 184

Página 185
11Anexo
11.1Anexo 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 186
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 187
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 188
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 189
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 190
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 191
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 192
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 193
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 194
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 195
Plug-in para Microsoft® Word que permite la exportación de información a la plataforma
DOORS.

Página 196
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.

La figura, muestra los diferentes artefactos de software involucrados en
la especificación de requerimientos en RUP.

Página 198
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
requerimientos
Alguna gente opina que no se puede
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 199
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
expresados en una manera fácil de entender
No aceptada en todas las organizaciones
El análisis de impacto debido a cambios en
los requerimientos es facilitado por esta
estrategia de trazabilidad. El impacto de una
funcionalidad no implementada es fácilmente
entendido
Alguna gente opina que es difícil alcanzar un
contrato que está basado fundamentalmente
en casos de uso. Si bien, existen
organizaciones que lo han logrado.
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 200
Las funcionalidades son trazadas hacia especificaciones formales de
requerimientos de software, y estas son a su vez, trazadas con los casos de
uso.
detallada
No bien entendido por la gente. Se suele
verse confundida frente a dos enfoques, el
tradicional SRS y el modelo de casos de uso
Los requerimientos de software son
expresados en forma entendible
Presta a confusión al momento de completar
la especificación de requerimientos, ya que es
necesario mantener los dos modelos
los requerimientos es facilitado por esta
estrategia de trazabilidad. El impacto de una
funcionalidad, requerimiento o caso de uso no
implementado es fácilmente entendido
Documentación relativamente extensa de
mantener
El modelo de casos de uso es relacionado
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
Implica un gran costo
Ú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
contratos legales
Dificultad para el entendimiento de los
requerimientos presentados de esta manera
Recomendado por varios procesos
estándares
los requerimientos es difícil de llevar a cabo

Página 201
detallada
Los requerimientos individuales no tienen un
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
relacionados con las necesidades del cliente,
permitiendo verificar que tan apropiado es el
modelo de casos de uso
Al inicio del proyecto, los casos de uso
aparentan definir las funcionalidades del
sistema, pero los dos conceptos tienden a
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 202
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 203
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 204
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 205
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 206
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 207
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 208
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 209
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 210
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 211
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 212
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 213
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 214
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 215
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 216
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 217
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 218
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 219
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 220
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 221
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 222
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 223
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 224
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 225
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 226
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 227
11.8Anexo 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 228
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 229
12Referencias
- 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 230
- 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 231

Página 232

delarosa-tesisdegradoingenieriainformatica

Más contenido relacionado

La actualidad más candente

Similar a delarosa-tesisdegradoingenieriainformatica

delarosa-tesisdegradoingenieriainformatica