Análisis de Impacto Basado en Información de Trazabilidad ...materias.fi.uba.ar/7500/delarosa-tesisdegradoingenieriainformatica.pdf · examples of application over known methodologies

ANÁLISIS DE IMPACTO BASADO ANÁLISIS DE IMPACTO BASADO ANÁLISIS DE IMPACTO BASADO ANÁLISIS DE IMPACTO BASADO EN INFORMACIÓN DE EN INFORMACIÓN DE EN INFORMACIÓN DE EN INFORMACIÓN DE

TRAZABILIDAD Y DECISIONES TRAZABILIDAD Y DECISIONES TRAZABILIDAD Y DECISIONES TRAZABILIDAD 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 RequerimientosDocumento 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 ymodificados

Predecidos yno modificados

No predecidos y nomodificados(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.

Análisis de Impacto basado en información de trazabilidadUniversidad de Buenos Aires – Facultad de Ingeniería

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

Tesista: Martín de la Rosa Tutor: Lic. Pablo Cosso

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 ¿Qué objetos y relaciones 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, ninguno, desconocido

Descomposición

¿Qué objetos y relaciones 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, ninguno, desconocido

Carga, modificación, navegación

¿Qué funcionalidades brinda el repositorio para la carga, modificación y navegación

de los elementos almacenados en él?

Carga, modificación, 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

CIIIEvsCEICII == α

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

CEISEvsCEISIS == α




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

CIRH

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#

HCEI

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

CEIM

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#

MCIR

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

Definición de configuración de 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



Definición de configuración de 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

iWPS1

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 WPF1

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 WPTWP1

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 TWPijFS1 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:

TW

P1

TW

P2

TW

P3

TW

P4

TW

P5

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

Caso de U

so

Especificación

Suplem

entaria

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

Caso de U

so

Especificación

Suplem

entaria

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

Requerim

iento

Caso de U

so

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

Requerim

iento

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

Caso de U

so

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.

Caso de U

so

Entidad de D

ominio

Objeto de

Periferia

Objeto de C

ontrol

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

Com

ponentes V

ista

Com

ponentes C

ontrol

Com

ponentes M

odelo

Com

ponentes 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

Requerim

iento E

structurado

Paso

Link

Caso de

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:

Co

mp

on

ente

Vista

Co

mp

on

ente

Co

ntro

l

Co

mp

on

ente

Mo

delo

Co

mp

on

ente

Infraestru

ctura

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:

Co

mp

on

ente

Vista

Co

mp

on

ente

Co

ntro

l

Co

mp

on

ente

Mo

delo

Co

mp

on

ente

Infraestru

ctura

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 perfi l de usuario

Control de promociones activas

Control de carga de artículos y estructuras comerciales

Administración de perfi les, 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_v ariable.jsp

/template/template_condition_v alue.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

PaqueteStored

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

¿Qué objetos y relaciones pueden ser expresados en la

interfaz de usuario del enfoque?

- Cualquier workproduct que haya sido debidamente establecido en la configuración de trazabilidad (ej. requerimientos, decisiones de diseño, clases de modelo, etc.).

Modelo interno de objetos ¿Qué objetos y relaciones 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

¿Qué objetos y relaciones 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.

Carga, modificación, 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

Análisis de Impacto

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:

TW

P1

TW

P2

…

TW

Pn

To

tal

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

[Tip

o W

P i]

…

[Tip

o W

P n

]

To

tal #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

CEITWPvsCEI 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

CE

I

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

Reque

rimie

nto

Casos

de

Uso

Decisi

on D

iseño

Vista

Contro

l

Mod

elo

Infra

estru

ctura


Can

tidad

de

Work

pro

duct

s

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

Requ

erim

iento

Caso

s de

Uso

Decis

ion Di

seño

Vista

Control

Mod

elo

Infra

estru

ctur

a

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

CE

I Acu

mu

lad

o

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.

Análisis de Impacto basado en información de trazabilidadUniversidad de Buenos Aires – Facultad de Ingeniería

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

Tesista: Martín de la Rosa Tutor: Lic. Pablo Cosso

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.

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 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

Modela una dependencia entre dos workproducts. Dicha dependencia modela el impacto que un workproduct origen puede tener sobre un

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

Cas

o d

e U

so 1

Cas

o d

e U

so 2

Cas

o d

e U

so 3

Cas

o d

e U

so 4

Cas

o d

e U

so 5

Cas

o d

e U

so 6

Cas

o d

e U

so 7

Cas

o d

e U

so 8

Requerimiento 1 X X X X X X

Requerimiento 2

Requerimiento 3 X X

Requerimiento 4 X

Requerimiento 5 X

Cada X en un casillero simboliza una traza; en este caso desde un

requerimiento a un caso de uso. Por ejemplo el Requerimiento 3 traza a los

Casos de Uso 2 y 4.

Estas matrices aportan una visión estática y de poca utilidad al momento

de visualizar las trazas. Se habla de una visión estática debido a que no es

posible navegar desde un workproduct a otro de manera de ir observando el

impacto en progreso.

Por lo tanto, el esfuerzo requerido para analizar el impacto originado

sobre un workproduct se torna tan significativo, que finalmente resulta

imposible realizar análisis de impacto durante el ciclo de vida del proyecto.

A modo diferenciador, ImpactTrace ofrece la navegación de grafos de

impacto que permite entre otras cuestiones una visión dinámica e intuitiva de

las trazas.

Las uniones capturadas por los grafos proporcionan una base para la

medición y toma de conocimiento acerca de las relaciones entre workproducts

(Bohner, Change Impact Analysis for Design Evolution, 1996).




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


t




Página 123

Requerim

iento

Caso de U

so

Decisión D

iseñ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


Vista 0


Control 1


Modelo 1


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 / Iteración Nro. Cambio 001 / 1

Propósito del Análisis de Impacto

Identificar todas las interfases relacionadas a la creación y edición de promociones.


Analizados

- Requerimiento

- Vista

Tipos de Trazas utilizadas - Trazas forward

Conjunto de Inicio de Impacto (CII) - R624: Requerimiento Promociones

Resultado Obtenido

Req

uerim

iento

Vista

To

tal

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

Req

uerim

iento

Vista

To

tal

#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


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.



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.


Analizados

- Requerimientos

- Casos de Uso

- Implementación Vista

- Implementación Control

- Implementación Modelo



- R633: Requerimiento Generación Manual de archivos de promociones

Resultado Obtenido

Req

uerim

iento

Caso

de U

so

Vista

Co

ntro

l

Mo

delo

To

tal

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

Req

uerim

iento

Caso

de U

so

Vista

Co

ntro

l

Mo

delo

To

tal

#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


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



Parámetros de Entrada de la iteración Analizar impacto hasta distancia igual a 4 inclusive.


Identificar la interfaz de generación manual de archivos de promociones, el control propio a la misma, y las clases de modelo relacionadas.


Analizados

- Requerimientos

- Casos de Uso






- R633: Requerimiento Generación Manual archivos de promociones

Resultado Obtenido

Req

uerim

iento

Caso

de U

so

Vista

Co

ntro

l

Mo

delo

To

tal





#CEI 1 1 1 2 2 7

#TWP 22 54 151 255 138 620




Página 134

Métricas

Req

uerim

iento

Caso

de U

so

Vista

Co

ntro

l

Mo

delo

To

tal #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


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.




- 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 / Iteración Nro. Cambio 003.a / 1


Identificar interfaces y controles impactados de la administración de perfiles.


Analizados

- Requerimientos



Tipo de trazas utilizadas - Trazas forward


- R619: Requerimiento Administración de perfiles, usuarios y permisos.

Resultado Obtenido

Req

uerim

iento

Vista

Co

ntro

l

To

tal

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

Req

uerim

iento

Vista

Co

ntro

l

To

tal

#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






Página 138


Identificación del Cambio / Iteración Nro. Cambio 003.b / 1


Identificar interfaces y controles impactados en la asociación de sucursales a una promoción.


Analizados

- Requerimientos

- Caso Uso



Tipo de trazas utilizadas - Trazas forward.


Resultado Obtenido

Req

uerim

iento

Caso

Uso

Vista

Co

ntro

l

To

tal

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

Req

uerim

iento

Caso

Uso

Vista

Co

ntro

l

To

tal

#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


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



Parámetros de Entrada 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


Identificar interfaces y controles impactados en la asociación de sucursales a una promoción.


Analizados

- Requerimientos

- Casos de Uso






- R624: Requerimiento Promociones

- R651: Administración – Alta / Baja / Modificación

- CU581: Editar Promoción

- CU601: Asignar Jerarquía / Sucursal a Promoción

Resultado Obtenido

Req

uerim

iento

Caso

de U

so

Vista

Co

ntro

l

To

tal





#CEI 5 2 3 9 19

#TWP 22 54 151 255 482




Página 141

Métricas

Req

uerim

iento

Caso

de U

so

Vista

Co

ntro

l

To

tal

#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






Página 142


Identificación del Cambio / Iteración Nro. Cambio 003.c

Propósito del Análisis de Impacto Identificar clase de modelo referente a un Perfil de Usuario


Analizados

- Requerimientos




- R619: Requerimiento Administración de Perfiles, usuarios y permisos

Resultado Obtenido

Req

uerim

iento

Mo

delo

To

tal

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

Req

uerim

iento

Mo

delo

To

tal

#CEI / #TWP 0.06 0.24 0.212

#CIR / #CEI 1 0.03 0.06

#CII / #CEI 0.03




Página 143

Gráficos






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




- Interfases de reportes de promociones




Página 145




Identificar las interfases relacionadas con reportes de promociones


Analizados

- Requerimientos

- Casos de Uso

- Vista


Conjunto de Inicio de Impacto (CII) - R636: Requerimiento Reportes

Resultado Obtenido

Req

uerim

iento

Caso

de U

so

Vista

To

tal





#CEI 1 4 5 10

#TWP 22 54 151 227

Métricas

Req

uerim

iento

Caso

de U

so

Vista

To

tal

#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






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


Modificar el archivo XML de mapeo de entidad hibernate tanto para la entidad Structure como StructureLevel.




Página 148




Identificar las interfases y casos de uso posiblemente impactados con la finalidad de realizar testing de regresión.


Analizados

- Casos de Uso

- Vista

- Modelo

- Infraestructura

Tipo de trazas utilizadas - Trazas backward


- II568: Implementación Infraestructura StructureHome

- II569: Implementación Infraestructura StructureLevelHome

Resultado Obtenido

Caso

de U

so

Vista

Mo

delo

Infraestru

ctura

To

tal

#CEI 43 76 31 2 152

#TWP 54 151 138 32 375

Métricas

Caso

de U

so

Vista

Mo

delo

Infraestru

ctura

To

tal

#CEI / #TWP 0.796 0.503 0.225 0.063 0.405

#CII / #CEI 0.013

Gráficos




Página 149


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




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.


Identificar las interfases y casos de uso posiblemente impactados con la finalidad de realizar testing de regresión.


Analizados

- Casos de Uso

- Vista

- Modelo

- Infraestructura

Tipo de trazas utilizadas - Trazas backward


- II568: Implementación Infraestructura StructureHome

- II569: Implementación Infraestructura StructureLevelHome

Resultado Obtenido

Caso

de U

so

Vista

Mo

delo

Infraestru

ctura

To

tal

#CEI 15 11 4 2 32

#TWP 54 151 138 32 375

Métricas

Caso

de U

so

Vista

Mo

delo

Infraestru

ctura

To

tal

#CEI / #TWP 0.278 0.073 0.029 0.063 0.085

#CII / #CEI 0.063

Gráficos




Página 151


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)



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



Propósito del Análisis de Impacto Identificar el impacto sobre workproducts de Etapa Implementación.


Analizados

- Casos de Uso

- Vista

- Control

- Modelo

- Infraestructura


Conjunto de Inicio de Impacto (CII) - CU609: Agregar / Excluir elementos a Promoción

Resultado Obtenido

Caso

de U

so

Vista

Co

ntro

l

Mo

delo

Infraestru

ctura

To

tal





#CEI 1 2 7 37 18 65

#TWP 22 151 255 138 32 598

Métricas

Caso

de U

so

Vista

Co

ntro

l

Mo

delo

Infraestru

ctura

To

tal

#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


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




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.


Identificar el impacto sobre workproducts de Etapa Implementación.


Analizados

- Casos de Uso

- Vista

- Control

- Modelo

- Infraestructura


Conjunto de Inicio de Impacto (CII) - CU609: Agregar / Excluir elementos a Promoción

Resultado Obtenido

Caso

de U

so

Vista

Co

ntro

l

Mo

delo

Infraestru

ctura

To

tal





#CEI 1 2 1 2 1 7

#TWP 22 151 255 138 32 598

Métricas

Caso

de U

so

Vista

Co

ntro

l

Mo

delo

Infraestru

ctura

To

tal

#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






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”)



- 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




Identificar Workproducts Vista y Control referidos a la edición detallada de una promoción.


Analizados

- Requerimientos

- Caso de Uso





Resultado Obtenido

Req

uerim

iento

Caso

de U

so

Vista

Co

ntro

l

To

tal





#CEI 5 27 44 60 136

#TWP 22 54 151 255 482

Métricas

Req

uerim

iento

Caso

de U

so

Vista

Co

ntro

l

To

tal

#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


Valor de #CEI / #TWP de Caso de Uso no aceptable. Se propone una siguiente iteración refinando este CEI.




Página 160




Se refina el CEI de Requerimiento y Casos de Uso realizando un análisis detallado de los mismos.


Identificar Workproducts Vista y Control referidos a la edición detallada de una promoción.


Analizados

- Requerimientos

- Caso de Uso





Resultado Obtenido

Req

uerim

iento

Caso

de U

so

Vista

Co

ntro

l

To

tal





#CEI 2 2 2 4 10

#TWP 22 54 151 255 482

Métricas

Req

uerim

iento

Caso

de U

so

Vista

Co

ntro

l

To

tal

#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






Página 162




Identificar workproducts de Modelo respecto a la generación de archivos de promociones


Analizados

- Requerimiento

- Caso de Uso

- Modelo



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

- R633: Requerimiento Generación manual de archivos de promociones

Resultado Obtenido

Req

uerim

iento

Caso

de U

so

Mo

delo

To

tal





#CEI 2 2 51 55

#TWP 22 54 138 214

Métricas

Req

uerim

iento

Caso

de U

so

Mo

delo

To

tal

#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


Valor de #CEI / #TWP de Modelo no aceptable. Se propone una siguiente iteración refinando el CEI de Modelo.




Página 164




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.


Identificar workproducts de Modelo respecto a la generación de archivos de promociones


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

- R633: Requerimiento Generación manual de archivos de promociones


Analizados

- Requerimiento

- Caso de Uso

- Modelo


Resultado Obtenido

Req

uerim

iento

Caso

de U

so

Mo

delo

To

tal





#CEI 2 2 31 35

#TWP 22 54 138 214

Métricas

Req

uerim

iento

Caso

de U

so

Mo

delo

To

tal

#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



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.

Co

nsu

lta

Vista

Co

ntro

l

Servicio

DA

O

Paq

uete

Sto

redP

roced

ure

Tab

la

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.



No Aplica.


Identificación del Cambio / Iteración Nro.

Cambio 001 / 1

Propósito del Análisis de Impacto Identificar todas las consultas relacionadas con la tabla MODELO.


Analizados

- Tabla

- Stored Procedure

- ServicioDAO

- Vista

- Consulta

Tipos de Trazas utilizadas - Trazas backward

Conjunto de Inicio de Impacto (CII) - II26724: Tabla MODELO

Métricas

Infraestru

ctura

Mo

delo

Req

uerim

iento

To

tal

#CEI / #TWP 0.24 0.238 0.52 0.24




Página 173

Gráficos


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.



Modificar ServicioDAO y componentes de control para invocar al stored procedure con el nuevo parámetro.


Identificación del Cambio / Iteración Nro.

Cambio 002

Propósito del Análisis de Impacto Identificar ServicioDAO y componentes de control a modificar.


Analizados

- Package

- ServicioDAO

- Control

Tipos de Trazas utilizadas

- Trazas backward


- 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

Packag

e

Servicio

DA

O

Co

ntro

l

To

tal





#CEI 1 2 5 8

#TWP 2318 42 152 2512

Métricas

Packag

e

Servicio

DA

O

Co

ntro

l

To

tal

#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


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

10 Conclusiones – Trabajo Futuro

En el contexto de la problemática planteada en el capítulo de

introducción, el presente trabajo propuso al proceso AIT (Análisis de Impacto

basado en Trazabilidad) como el modelo que permite administrar la

información de trazabilidad de un proyecto de software. Este proceso hace

hincapié en documentar la trazabilidad entre los componentes que integran el

proyecto para luego permitir realizar efectivos análisis de impacto.

Como conclusión al presente trabajo se alcanzaron los siguientes

resultados:

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

Trazabilidad" se permite definir y especificar sobre cuales

componentes de un proyecto de software documentar la

trazabilidad, y de qué manera.

• Ejemplificar posibles configuraciones de trazabilidad para las

metodologías y arquitecturas más utilizadas en la actualidad.

• Automatizar la documentación de trazabilidad mediante la

implementación de extractores de trazabilidad implícita y explícita.




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

11 Anexo

11.1 Anexo I: Detalles del Caso Práctico I

11.1.1 Generalidades del Proyecto

Se trató de un proyecto desarrollado a lo largo de un período de seis

meses. Cabe señalar que el proyecto no sufrió desvíos de su estimación

inicial, tanto en tiempo como en funcionalidad cubierta por el alcance del

mismo.

El equipo de proyecto fue integrado por tres personas, distribuyéndose

los roles de la siguiente manera:

1) Analista / Project Leader: persona involucrada en la

administración del proyecto y análisis del mismo.

2) Arquitecto: persona responsable del diseño y

arquitectura, y desarrollo de componentes con

mayor riesgo tecnológico.




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


Permite trazabilidad formal, de bajo nivel y 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

El análisis de impacto debido a cambios en 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

El análisis de impacto debido a cambios en los requerimientos es difícil de llevar a cabo




Página 201

Permite trazabilidad formal, de bajo nivel y 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.8 Anexo VII: Requerimientos Estructurados – Herramienta: Optimal Trace

La empresa Compuware hace hincapié en una metodología que ellos

mismos denominaron “Requerimientos Estructurados”. Esta empresa entiende

que una administración inadecuada de requerimientos provoca el 70% de los

fracasos de proyectos.

La causa principal que señalan es parte de la problemática analizada en

este trabajo: el gap entre lo que el equipo de negocio necesita y lo que la

gente de IT entiende y finalmente entrega.

Lo que proponen es una manera de documentar los requerimientos. Se

denominan estructurados puesto que ofrecen un flujo paso por paso de lo que

los stakeholders necesitan y esperan del sistema.

Los requerimientos estructurados permiten trazabilidad completa a lo

largo de todo el ciclo de vida debido a que terminan siendo la parte central del

proceso de planeamiento del proyecto, conectando el plan de proyecto con

los objetivos de negocio. A partir del proceso se desprenden especificaciones

de diseño (modelos UML), diseño de interfaces de usuario (screenshots y

storyboards), plan de testing (compuesto por casos de prueba), y módulos de

código (Java, C++, etc.).

¿Qué es exactamente un requerimiento estructurado?

Un requerimiento estructurado describe un objetivo del sistema en

cuestión. Son generados con un alto grado de involucramiento del usuario

que conoce el negocio. Debido a que reflejan de manera clara el

comportamiento del sistema en un flujo entendible, es fácil para los usuarios

entender y verificar el proceso y asegurar que nada está siendo omitido.

Además permiten a los arquitectos entender los objetivos del sistema desde el

punto de vista del cliente. Definen el alcance e interfaz del sistema, facilitando

ver que está dentro y que afuera, acelerando la decisión de compra del cliente

y reduciendo discusiones.




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

12 Referencias

- Abbattista, F., Lanubile, F., Mastelloni, G., & Visaggio, G. (1994). An Experiment on the Effect of Design Recording on Impact Analysis. International Conference on

Software Maintenance (págs. 253-259). Bari, Italia: IEEE Computer Society. - Ambler, S. W., Nalbone, J., & Vizdos, M. J. (2007). The Enterprise Unified Process:

Extending the Rational Unified Process. Prentice Hall. - Anaya, V., & Letelier, P. (2002). Trazabilidad de Requisitos Adaptada a las

Necesidades del Proyecto: Un Caso de Estudio Usando Alternativamente RUP y XP. Valencia, España: Departamento de Sistemas Informáticos y Computación - Universidad Politécnica de Valencia.

- Arnold, R., & Bohner, S. (1993). Impact analysis-Towards a framework for comparison. CSM-93, Proceedings., Conference, (págs. 292-301).

- (1986). Automated Life Cycle Impact Analysis System. Roma, Italia. - Bianchi, A., Visaggio, G., & Fasolino, A. R. (2000). An Exploratory Case Study of the

Maintenance Effectiveness of Traceability Models. 8th International Workshop on

Program Comprehension (pág. 149). Napoli, Italia: IEEE Computer Society. - Bohner, S. (1996). Change Impact Analysis for Design Evolution. En S. Bohner, & R.

Arnold, Software Change Impact Analysis (pág. 75). IEEE Computer Society Press. - Bohner, S., & Arnold, R. (1996). An Introduction to Software Change Impact

Analysis. En S. Bohner, & R. Arnold, Software Change Impact Analysis. IEEE Computer Society Press.

- Bohner, S., & Arnold, R. (1996). Software Change Impact Analysis. IEEE Computer Society Press.

- Dean, L., & Don, W. (1999). Managing Software Requirements - A Unified Approach. Addison Wesley.

- Dick, J. (1995). Rich Traceability. Quality Systems and Software Ltd.




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

Documents

Análisis de Impacto Basado en Información de Trazabilidad ...materias.fi.uba.ar/7500/delarosa-tesisdegradoingenieriainformatica.pdf · examples of application over known methodologies