Software II

Impact analysis
Anlisis de impacto
Resumen: Los cambios de software son necesarios e inevitables en el desarrollo de
software, pero pueden conducir a un deterioro de software si no se controla
adecuadamente. El anlisis de impacto es la actividad de identificar lo que necesita ser
modificado con el fin de hacer un cambio, o para determinar las consecuencias en el
sistema si se lleva a cabo el cambio. La mayora de las investigaciones sobre el anlisis
de impacto se presentan y debaten en la literatura relacionada con el mantenimiento
del software. En este captulo, nos tomamos un enfoque diferente y discutimos anlisis
de impacto desde la perspectiva de la ingeniera de requisitos. Relacionamos cambio de
software para impacto de anlisis, nociones generales de la historia de anlisis de
impacto y presentar estrategias comunes para la realizacin de anlisis de impacto.
Tambin mencionamos la aplicacin del anlisis de impacto. Por ltimo, se describe lo
que vemos como el futuro de esta fundamental herramienta de gestin del cambio.
Palabras clave: Anlisis de impacto, cambio de software, anlisis de trazabilidad, la
propagacin del cambio, los requisitos no funcionales, las mtricas.
6.1 Introduccin
Es ampliamente reconocido que el cambio es una propiedad ineludible de cualquier
software, por un nmero de razones. Sin embargo, los cambios de software pueden, y lo
harn, si no estn adecuadamente controlados, conducir a un deterioro de software.
Por ejemplo, cuando se analizaron 2.000.000 lneas de cdigo fuente de Mozilla de
cdigo (SLOC Source Lines of Code), haba fuertes indicios de que el software se ha
deteriorado de manera significativa debido al cambio no controlado, haciendo que el
software sea muy difcil de mantener [17].
El deterioro de Software ocurre en muchos casos debido a cambios en el software rara
vez tienen el pequeo impacto que se cree que tienen [40]. En 1983, algunos de los
errores de programacin ms caros del mundo cada uno implicaron el cambio de un
solo dgito en un programa previamente correcto [38], lo que indica que un cambio
aparentemente trivial puede tener un inmenso impacto. Un estudio realizado en los
aos 90 demostr que los profesionales de software que realizan anlisis de impacto y
cambio en la estimacin de un proyecto industrial subestimaron la cantidad de cambio
por un factor de tres [26]. Adems, como los sistemas de software crecen cada vez ms
complejos, los problemas asociados con el cambio de software en consecuencia

aumentan. Por ejemplo, cuando se analiz el cdigo fuente a travs de varias versiones
de un sistema de software de telecomunicaciones de quince aos de edad, de 100 000
000 lneas de cdigo fuente, se observ que el sistema se haba deteriorado debido al
cambio frecuente. Los programadores de estimacin del esfuerzo de cambio llegaron a
la conclusin de que el cdigo era ms difcil de cambiar de lo que debera ser [13].
Anlisis de impacto es una herramienta para el control de cambio, y por lo tanto para
evitar el deterioro. Bohner y Arnold
definen anlisis de impacto como "la actividad de la
identificacin de las posibles consecuencias, incluyendo los efectos secundarios y
efectos en cadena, de un cambio, o la estimacin de lo que necesita ser modificado para
lograr un cambio antes de que se ha hecho" [3]. En consecuencia, la salida de anlisis de
impacto se puede utilizar como una base para estimar el costo asociado con un cambio.
El costo del cambio se puede utilizar para decidir si aplica o no en funcin de su relacin
costo / beneficio.
Anlisis de impacto es una parte importante de la ingeniera de requisitos ya que los
cambios en el software a menudo son iniciados por los cambios en los requisitos. En los
libros de texto de requerimientos de ingeniera, anlisis de impacto es reconocido como
una actividad esencial en la gestin del cambio, pero los detalles sobre cmo realizar a
menudo queda fuera, o limitarse a razonar sobre el impacto del cambio en la
especificacin de requisitos [20, 23, 27, 32 , 35]. Una excepcin es [40], donde Wiegers
ofrece listas de verificacin para ser utilizados por un desarrollador con conocimientos
para evaluar el impacto de la propuesta de cambio.
A pesar de su lugar natural en la investigacin de la ingeniera de requisitos sobre el anlisis de
impacto se encuentra ms comnmente en la literatura relacionada con el mantenimiento del
software. En este captulo, se presenta el anlisis de impacto desde la perspectiva de la
ingeniera de requisitos. En nuestra experiencia, el anlisis de impacto es una parte integral de
todas las fases de desarrollo de software. Durante el desarrollo de requisitos, diseo y cdigo
an no existen, as que los requisitos nuevos y cambiantes afectan slo a los requisitos
existentes. Durante el diseo, el cdigo no existe todava, as que los requisitos nuevos afectan
solamente requisitos existentes y diseo. Por ltimo, durante la ejecucin, los requisitos nuevos
y cambiantes afectan a los requisitos existentes, as como el diseo y el cdigo. Esta es capturad
en la figura 6.1. Tenga en cuenta que en los procesos de desarrollo menos idealistas, la
situacin

mantiene; Requisitos cambiosy afectan a todas las representaciones de sistemas existentes.

El captulo est organizado de la siguiente forma. En el resto de esta seccin, definimos

los conceptos, se habla del cambio de software y nociones generales la historia de
anlisis de impacto. En Sec.6.2, presentamos estrategias comunes para el anlisis de
impacto. Sec. 6.3 discute el anlisis de impacto en el contexto de los requisitos no
funcionales. Exploramos varias mtricas para el anlisis de impacto y damos un ejemplo
de una aplicacin de este tipo de mtricas en Sec. 6.4. En Sec. 6.5, nos fijamos en
soporte de herramientas para el anlisis de impacto y discutir el anlisis del impacto en
las herramientas de gestin de requisitos. Finalmente planteamos el futuro del anlisis
de impacto en la Seccin. 6.6 y proporcionar un resumen del captulo en la Seccin. 6.7.
PAG 3
6.1.1 TRMINOS Y CONCEPTOS
A lo largo de este captulo, utilizaremos varios trminos y conceptos que son relevantes
para el campo de anlisis de impacto. En esta seccin revisaremos brevemente estos
trminos y conceptos y explicaremos cmo cada uno de ellos se relaciona con el anlisis
de impacto y con otros trminos y conceptos.
Objetos del ciclo de vida del Software (SLOs- tambin llamados productos de software o
productos del trabajo) son fundamentales para el anlisis de impacto. un SLO es un
artefacto producido durante un proyecto, tal como un requisito, el componente de la
arquitectura, una clase y as sucesivamente.
Los SLOs estn conectados entre s a travs de una red de relaciones. Las relaciones
pueden ser tanto entre SLOs del mismo tipo, y entre SLOs de diferentes tipos.
Por ejemplo, 2 requerimientos se pueden interconectar para indicar que estn
relacionados entre s. Un requerimiento tambin puede ser conectado a un componente
arquitectnico, por ejemplo, para indicar que el componente es implementado por el
requisito.

El anlisis de impacto se lleva a cabo a menudo mediante el anlisis de la relacin entre

diversas entidades del sistema. Podemos distinguir 2 tipos de anlisis:
Anlisis de la dependencia y el anlisis de trazabilidad [3]
Anlisis de la dependencia de las relaciones entre las entidades
de programa detallado.
Por ejemplo, variables o funciones que se extraen del cdigo fuente. Anlisis de
trazabilidad, por otro lado, es el anlisis de las relaciones que han sido identificados
durante el desarrollo entre todos los tipos de SLOs.
El anlisis de trazabilidad por lo tanto es adecuado para analizar las relaciones entre los
requerimientos, componentes arquitectnicos, documentacin, etc. Los requisitos de
trazabilidad se definen y se discuten en el captulo 5. Es evidente que el anlisis de la
trazabilidad tiene una aplicacin ms amplia dentro de la ingeniera del anlisis de
dependencia de los requisitos; puede ser utilizado en las fases de desarrollo anteriores y
puede identificar un impacto ms diverso en trminos de diferentes tipos de SLO.
Es comn para tratar con conjuntos de anlisis de impacto. Los siguientes conjuntos han
sido definidos por Arnold y Bohner [3]:
El sistema representa el conjunto de todos los SLO en el sistema- todos los otros
conjuntos son subconjuntos de este conjunto.
El conjunto del arranque de impacto (The Starting impact set- SIS) representar el
conjunto de objetos que se cree inicialmente haya cambiado. El SIS
normalmente sirve como entrada para impactar enfoques de anlisis que se
utilizan para encontrar el conjunto impacto estimado.
Conjunto del impacto estimado (The estimated impact set - EIS) siempre incluye
el SIS y por lo tanto puede ser visto como una expansin del SIS. El resultado de
la expansin de la aplicacin, entrega reglas de propagacin del cambio en el
modelo de objeto interno varias veces hasta que todos los objetos que puedan
ser afectadas son descubiertos. Idealmente, el SIS y EIS deben ser los mismos, lo
que significa que el impacto se limita a lo que se pensaba inicialmente poda ser
cambiado.
Conjunto de Impacto Actual (The Actual Impact Set - AIS) por ltimo, contiene
los SLO que han sido afectadas, una vez se ha aplicado el cambio. En el mejor de
los casos, el AIS y EIS son los mismos, lo que significa que la estimacin del
impacto es perfecto.
Adems de los conjuntos de impacto, existen dos formas de informacin que son
necesarias con el fin de determinar el impacto de un cambio:

informacin sobre las dependencias entre objetos

conocimiento sobre cmo los cambios se propagan de un objeto
a travs de dependencias y enlaces de trazabilidad
Las Dependencias entre objetos se capturan a menudo en trminos de referencias entre
ellos (ver cap. 5). El conocimiento sobre cmo el cambio se propaga desde un objeto a
otro se expresa a menudo en trminos de reglas o algoritmos.
PAG 4
Es comn distinguir entre el cambio primario y secundario. El
cambio primario
, tambin
conocido como
impacto directo
, corresponde a la SLO que se identifican mediante el
anlisis de cmo los efectos de un cambio propuesto afectan al sistema. Este anlisis
suele ser difcil de automatizar, ya que se basa principalmente en la experiencia
humana. En consecuencia, poco se puede encontrar en la literatura acerca de cmo
identificar los cambios primarios. Es ms comn encontrar discusiones sobre cmo los
cambios primarios causan cambios secundarios
, tambin conocido como el
impacto
indirecto
.
El impacto indirecto puede tomar dos formas: Los efectos secundarios son
comportamientos no deseados resultantes de las modificaciones necesarias para
implementar el cambio. Los efectos secundarios afectan tanto a la estabilidad y la
funcin del sistema y deben evitarse.
Los efectos de la ondulacin
, por otro lado, son
efectos sobre algunas partes del sistema causado por realizar cambios en otras partes.
Efecto domin no se pueden evitar, ya que son la consecuencia de la estructura y la
aplicacin del sistema. Deben, sin embargo, ser identificados y contabilizados cuando se
implementa el cambio.
Hemos mencionado anteriormente componentes arquitectnicos como ejemplo
de SLO. La arquitectura de software de un sistema es su estructura bsica, que consiste
de componentes interconectados. Hay muchas definiciones de arquitectura de
software, una reciente es "la estructura o estructuras del sistema, que comprenden
elementos de software, las propiedades externamente visibles de esos elementos y las
relaciones entre ellos" [2]. Existen varias otras definiciones (ver [34]), pero la mayora se
hacen eco de la que se da aqu. Arquitectura de software se disea tpicamente al
principio del proyecto, ocultando bajo nivel de diseo e implementacin detalles, y
luego iterativamente refinado a medida que el conocimiento sobre el sistema crece
[10]. Esto hace que los modelos de arquitectura sean interesantes desde un anlisis de
los requisitos de ingeniera e impacto de punto de vista, ya que pueden ser utilizados
para el principio, aunque inicialmente con un grueso anlisis del impacto de los
requisitos de las nuevas necesidades.

6.1.2 Cambio de Software y Anlisis de Impacto

El cambio de software se produce por varias razones, por ejemplo, con el fin de fijar las
fallas, para agregar nuevas caractersticas o para reestructurar el software y adaptarse a
los cambios futuros [28]. Los Cambio de requisitos son una de las motivaciones ms
importantes para el cambio de software. Los requisitos cambian desde el momento en
que se suscit hasta que el sistema se ha vuelto obsoleto. Los cambios en los requisitos
reflejan cmo el sistema debe cambiar para mantenerse til para sus usuarios y seguir
siendo competitivos en el mercado. Al mismo tiempo, estos cambios suponen un gran
riesgo ya que pueden causar deterioro de software. Por lo tanto, los cambios en los
requisitos deben ser capturados, gestionados y controlados cuidadosamente para
asegurar la supervivencia del sistema desde el punto de vista tcnico. Los factores que
pueden infringir cambios en los requisitos, tanto durante el desarrollo inicial, as como
en la evolucin del software son, segn Leffingwell y Widrig [23]:
PAG 5
El problema es que el sistema se supone que resuelve el cambio, por ejemplo
econmico, poltico o por razones tecnolgicas.
Los usuarios cambian sus mentes acerca de que ellos buscan que haga el
sistema, como ellos. Esto puede ocurrir porque los usuarios inicialmente estn
inseguros de lo que buscan, o porque nuevos usuarios entran en juego.
El ambiente en el cual residen los sistemas. Por ejemplo, incrementos en
velocidad y capacidad de los ordenadores pueden afectar las expectativas del
sistema.
El nuevo sistema es desarrollado y entregado a los usuarios principales para
descubrir nuevos requerimientos.
El ltimo factor es real y comn. Cuando el nuevo sistema es entregado, los usuarios se
dan cuenta que ellos queran caractersticas adicionales, que necesitan datos
presentados en otras formas, que hay necesidades emergentes para integrar el sistema
con otros sistemas, y as sucesivamente. As, nuevos requerimientos son generados por
el uso del sistema en si. Conforme con las leyes de evolucin de software, un sistema
debe ser continuamente adaptado, o ser progresivamente menos satisfactorio en su
ambiente.
Problemas surgen si requerimientos y cambios en los requerimientos no son
gestionados correctamente por la organizacin de desarrollo. Por ejemplo, fallas para
realizar preguntas correctas a la gente correcta en el momento correcto durante el
desarrollo de requerimientos lo ms probable es que llevara a un gran nmero de

cambios en los requerimientos en las fases subsiguientes. Adems, fallas para crear un
proceso de cambio prctico puede significar que los cambios no sern manejados
oportunamente, o esos cambios sern implementados sin el control adecuado.
Maciaszek indica: el cambio no es una patada en los dientes, cambios no administrados
lo son. En otras palabras, una organizacin que desarrolla software requiere un
adecuado proceso de gestin con el fin de disminuir los riesgos de constantes cambios
en los requerimientos y su impacto en el sistema. Leffingwell y Widrig discuten cinco
partes necesarias del proceso para administrar los cambios. Estas partes representadas
en la figura siguiente, forman un entorno de trabajo para el proceso de la gestin de
cambios que permiten que el equipo de trabajo gestione los cambios de forma
controlada.

Un plan para el cambio implica reconocer el hecho de que se produzcan cambios, y que
son una parte necesaria del desarrollo del sistema. Esta preparacin es esencial para
que los cambios para sean
recibidos y manejados de manera efectiva.
Requisitos bsicos significan crear una instantnea de la actual serie de requisitos. El
punto de este paso es permitir que los cambios posteriores en los requisitos a ser
comparado con un conjunto estable y conocido de requisitos.
Un solo canal es necesaria para asegurar que ningn cambio se implementa en el
sistema antes de que se haya analizado por una o varias personas, que guardan el
sistema, el proyecto y el presupuesto en mente. En las organizaciones ms grandes, el
nico canal es a menudo un tablero de control de cambios (CCB).
Un sistema de control de cambios permite al CCB (o equivalente) recopilar, seguir y
evaluar el impacto de los cambios. Segn Leffingwell y Widrig, un cambio evaluarse en
trminos de impacto en el costo y funcionalidad, el impacto en los actores externos (Por
ejemplo, clientes) y el potencial para desestabilizar el sistema. Si el ltimo se pasa por
alto, el sistema (como se seal anteriormente) es probable que se deteriore.
Gestionar de forma jerrquica vence una lnea quizs demasiado comn de accin: un
cambio es introducido en el cdigo por un programador ambicioso, que se olvida, o pasa
por alto, el efecto potencial que tiene el cambio sobre casos de prueba, diseo,
arquitectura, requisitos y as sucesivamente. Los cambios deben introducirse de arriba

hacia abajo, comenzando con los requisitos. Si se descomponen requisitos y se vinculan

a otros SLOs, es posible propagar el cambio de una manera controlada.
Este entorno de trabajo para el proceso de cambio deja abierta la determinacin de un
actual proceso de cambio. Libros acerca de los Requisitos de ingeniera proponen la
gestin del cambio procesos con diferentes niveles de detalle y claridad. El proceso
propuesto por Kotonya y Sommerville es, sin embargo, detallado y consistente de los
siguientes pasos:
1. Anlisis de problemas y especificaciones cambio
2. Cambios de anlisis y costos, que a su vez se compone de:
a. Comprobar validez de solicitud de cambio
b. Encontrar requerimientos directamente afectados
c. Encontrar requerimientos dependientes
d. Proponer cambios en los requerimientos
d. Evaluar los costos del cambio
e. Evaluar los costos de la aceptabilidad
3. Cambiar la implementacin
El anlisis de impacto se realiza en pasos 2b, 2c y 2e, mediante la identificacin de los
requerimientos y los componentes del sistema afectados por el cambio propuesto. El
anlisis debe ser expresado en trminos de esfuerzo requerido, tiempo, dinero y los
recursos disponibles. Kotonya y Somerville sugieren el uso de tablas de trazabilidad para
identificar y gestionar las dependencias entre los requerimientos, y entre los
requerimientos y elementos de diseo. Discutimos la trazabilidad como una estrategia
para llevar a cabo el anlisis del impacto en la seccin 6.2.1.1.
6.1.3 Historia y Tendencias
En cierto sentido, el anlisis de impacto se ha realizado durante mucho tiempo, aunque
no necesariamente usando ese trmino y no necesariamente para resolver el problema
de determinar la precisin del efecto de un cambio propuesto. La necesidad de los
profesionales de software para determinar qu cambiar con el fin de implementar los
cambios de requerimientos siempre ha estado presente. Estrategias para realizar el
anlisis de impacto y fueron introducidas y discutidas tempranamente en la literatura.
Por ejemplo, el artculo de Haney de 1972 en una tcnica para analizar la conexin
modular se refiere a menudo como el primer documento sobre el anlisis de impacto. La
tcnica se basa en la idea de que cada par de mdulos de un sistema tiene una
probabilidad de que un cambio en un mdulo en el par requiere un cambio en el otro
mdulo. La tcnica se puede utilizar para modelar el cambio de propagacin entre los
componentes del sistema, incluyendo los requerimientos. El programa de corte en
rebanadas, es una tcnica para centrarse en un problema particular mediante la

recuperacin de rebanadas ejecutables que contienen slo el cdigo del que una
variable especfica depende, fue introducido ya en 1979 por Weiser. Rebanar, que se
explica en la Seccin. 6.2.1.2, puede ser utilizado para determinar las dependencias en
el cdigo y se puede utilizar para minimizar los efectos secundarios. Rebanar tambin se
puede utilizar para determinar las dependencias entre las secciones en los documentos,
incluyendo los requerimientos, los cuales se describen a continuacin. Requisitos de
trazabilidad definidos en la norma ANSI / IEEE Standard 830-1984 en 1984. Trazabilidad
describe cmo los SLOs estn relacionados entre s y pueden ser utilizados para
determinar cmo cambio en un tipo de artefacto causa el cambio en otro tipo de
artefacto. La nocin del efecto domin fue introducido por Yau y Collofello en 1980 [41].
Sus modelos se pueden utilizar para determinar cmo cambia un rea del cdigo fuente
propagado y causa cambios en otras reas.
El anlisis de impacto se basa en las tcnicas y estrategias que se remontan mucho
tiempo atrs. Sin embargo es posible identificar una tendencia en la investigacin de
anlisis de impacto durante los aos Los primeros anlisis de impacto de trabajo se
centr en el anlisis de cdigo fuente, incluyendo el programa de rebanadas y sus
repercusiones para el cdigo. La maduracin de la ingeniera de software entre
organizaciones de software ha llevado a la necesidad de comprender cmo los cambios
afectan a otra SLO que el cdigo fuente.
Por ejemplo, Turver y Munro sealan que el cdigo fuente no es el nico producto que
tiene que ser cambiado con el fin de desarrollar una nueva versin del software
producto. En un documento impulsado por el enfoque de desarrollo, muchos
documentos son tambin afectados por los requisitos nuevos y modificados. El manual
de usuario es un ejemplo de un documento que tiene que ser actualizado cuando las
nuevas funcionalidades de usuario sean previstos. Turver y Munro se centran en el
problema del efecto domin en la documentacin utilizando una tcnica de rebanadas
temtico. Ellos dicen que este tipo de anlisis no ha sido ampliamente discutido antes.
El mismo enfoque se puede aplicar al documento de requerimientos con el fin de
determinar cmo un nuevo o modificado requisito impacta la especificacin de
requisitos.
En 1996, Arnold y Bohner publicaron una coleccin de artculos de investigacin llamada
Anlisis de Impacto del Cambio del Software. El propsito de la coleccin era presentar
hoy en da, algo disperso, el material que estaba disponible en el momento acerca del
anlisis del impacto. La lectura de la coleccin hoy, casi diez aos despus, se hace
evidente que todava es muy relevante. Documentos publicados despus de 1996
parecen funcionar con las mismas ideas y tcnicas. No nos referimos a depreciar el
trabajo que se ha hecho, pero indica que el campo no est en un estado de flujo. Ms
bien, el foco permanece en la adaptacin de tcnicas y estrategias existentes a nuevos

conceptos y en nuevos contextos. El anlisis del impacto en el nivel de arquitectura es

un ejemplo de esto.
Cuando se acercaba el ao 2000, el problema Y2K hizo evidente que se necesitan vastos
esfuerzos de anlisis de impacto con el fin de identificar el software y partes de software
que tuvo que ser cambiado para sobrevivir al cambio de siglo. Esto sirvi como una
revelacin para muchas organizaciones, en las que el proceso de software antes no
tena un anlisis de impacto explcitamente incluido.
PAG 8
Hoy en da, los sistemas de software son mucho ms complejos de lo que eran hace 25
aos, y se ha vuelto muy difcil de comprender las implicaciones combinadas de los
requisitos y su relacin con la arquitectura, el diseo y el cdigo fuente. Por lo tanto,
surge la necesidad de desarrollar estrategias de anlisis de impacto que emplean los
requisitos y sus relaciones con otros SLOs.
Sin embargo, las redes de dependencia para grandes sistemas de software pueden ser
tan complejas que es necesario visualizarlos en formas novedosas. Bohner y Gracanin
presentan una investigacin que combina el anlisis de impacto y visualizacin en 3D
con el fin de mostrar la informacin de dependencia en un formato ms rico que es
posible con la visualizacin 2D [5]. Bohner tambin hace hincapi en la necesidad de
ampliar el anlisis del impacto de middleware, software COTS y aplicaciones web.
El uso de este tipo de software es cada vez ms comn, reduciendo la complejidad de
distancia de dependencias de datos y de control interno de las dependencias de
interoperabilidad. Las estrategias de anlisis de impacto actuales no son muy adecuadas
para este tipo de dependencias [4].
6.2 Estrategias para el Anlisis de Impacto
Hay varias estrategias para la realizacin de anlisis de impacto, algunos de los cuales
son ms afn al proceso de ingeniera de requisitos que otros. Las estrategias comunes
son:
Analizando la trazabilidad o dependencia de informacin
La utilizacin de tcnicas de corte.
Consultar las especificaciones de diseo y otra documentacin
Entrevistar a los desarrolladores con conocimientos
Dividimos estas estrategias de anlisis de impacto en dos categoras: automatizables y
manual. Con estrategias automatizables, nos referimos a los que son de alguna
algortmica con sentido en su naturaleza. Estos tienen la capacidad de proporcionar
estimacin del impacto con granularidad muy fina en forma automatizada, pero

requieren por otro lado la presencia de una infraestructura detallada y resultar a veces
cometer demasiados falsos positivos [30].
Con estrategias manuales, nos referimos a los que se realiza mejor por los seres
humanos (a diferencia de las herramientas). Estos requieren menos infraestructura,
pero pueden ser ms grueso en su estimacin del impacto que los automatizables.
Reconocemos que las dos categoras no son completamente ortogonales, pero, hacen
una distincin importante; las estrategias manuales son potencialmente ms fciles de
adoptar y trabajar, ya que requieren de entrada menos estructurada y no es necesario
desarrollar nuevas formas de SLOs.
Un estudio anterior indica que el anlisis de impacto de los desarrolladores a
menudo resulta en predicciones optimistas [26], lo que significa que el conjunto
previsto de cambios representa la menor cantidad posible de trabajo. Por lo tanto, el
trabajo no puede ser ms fcil, slo es ms difcil. El estudio tambin identific la
necesidad de predicciones conservadoras y establecimiento una prediccin "peor nivel".
La cantidad real de trabajo se encuentra entre el optimismo y el nivel conservador. Una
mejor meta sera disminuir la variacin del proceso de anlisis de impacto a medida que
se estabiliza y se hace ms madura.
PAG 9-11
El costo asociado con la produccin de una prediccin conservadora depende de su
esperada exactitud. Desde entonces las predicciones conservadoras identifican una gran
parte de tales sistemas, los desarrolladores a menudo no pueden creer que son
realistas. El beneficio de tener una prediccin conservadora es la capacidad de
determinar una prediccin ms probable en algn lugar entre el optimismo y la
prediccin conservadora. Un impacto ideal en el enfoque de anlisis sera siempre
proporcionar un ptimo y conservador clculo. Mediante la recopilacin y anlisis de
datos empricos de las predicciones, as como los cambios reales, que se pueden
establecer en donde se encuentra el lapso a la respuesta correcta.
6.2.1 Estrategias automatizables
Las estrategias de anlisis de impacto automatizables a menudo emplean mtodos
algortmicos en orden para identificar el cambio de propagacin y el impacto indirecto.
Por ejemplo, la relacin grfica de requisitos y otros SLO pueden utilizarse con
algoritmos de grafos para identificar el impacto de un cambio propuesto que tendra en
el sistema. El requisito previo para las estrategias automatizables es una especificacin
estructurada del sistema. Por estructurado, nos referimos a que la especificacin es
consistente y completa, e incluye alguna informacin semntica (por ejemplo, el tipo de

relacin). Una vez en el lugar, tal especificacin puede ser utilizada por las herramientas
para llevar a cabo el impacto de anlisis automtico. Los requerimientos de
dependencia y modelos de objetos son ejemplos de especificaciones estructuradas.
Las estrategias presentadas aqu, la trazabilidad y el anlisis de la dependencia y de
corte, normalmente se utilizan para evaluar el impacto estimado a establecer mediante
la identificacin secundaria de cambios que resulten necesarios debido a los cambios
principales en el sistema. Ellos no estn muy adecuados para la identificacin de
impacto directo.
6.2.1.1 Trazabilidad /Anlisis de Dependencia
Anlisis de trazabilidad y anlisis de la dependencia implica el examen de las
relaciones entre las entidades en el software. Se diferencian en su alcance y nivel de
detalle; la trazabilidad de anlisis es el de las relaciones entre todos los tipos de SLO,
mientras que la dependencia es el anlisis de bajo nivel extrada del cdigo fuente [3].
Los requisitos de trazabilidad se discute ms en el Cap. 5.
Mediante la extraccin de las dependencias de cdigo fuente, es posible obtener
llamadas a grficos, estructuras de control, grficos de datos y as sucesivamente. Dado
que el cdigo fuente es la representacin exacta del sistema, cualquier anlisis basado
en que se puede predecir con mucha precisin el impacto de un cambio. El anlisis de
dependencia es tambin la estrategia ms madura para el anlisis de impacto
disponible[3]. El inconveniente de la utilizacin de cdigo fuente es que es no est
disponible hasta el final del proyecto, hace que el anlisis de dependencia estreche en
su campo de aplicacin. Cuando existen requisitos de trazabilidad hacia abajo de la
fuente, puede sin embargo, ser muy eficaz utilizar dependencias de cdigo fuente con el
fin de determinar el impacto de los cambios en los requerimientos. Un inconveniente es
que los sistemas muy grandes tienen cantidades masivas de dependencias de cdigo
fuente, que hacen que la dependencia Web sea difcil tanto para uso y como para
obtener una visin general[5].
El anlisis de Trazabilidad tambin requiere la presencia de vnculos de relacin entre la
SLO que se analizan. Tpicamente, estas relaciones son capturadas y especificadas
progresivamente durante el desarrollo (conocido como
trazabilidad pregrabada
). El
xito de trazabilidad anlisis depende en gran medida de la integridad y la coherencia de
las relaciones identificadas. Sin embargo, si la informacin de trazabilidad se registra
correctamente desde el principio del desarrollo, el anlisis puede ser muy poderoso.
Un enfoque comn para el registro de enlaces de trazabilidad es utilizar una matriz de
trazabilidad (Vase, por ejemplo, [20], [23] y [40]). Una matriz de trazabilidad es una

matriz donde cada fila y cada columna, corresponde a una SLO particular, por ejemplo
un requisito.
La relacin entre los dos SLO se expresa poniendo una marca donde la fila de la primera
SLO y la columna de la segunda SLO se cruzan. Tambin es posible aadir informacin
semntica a la relacin entre SLO. Por ejemplo, la relacin entre un requisito y un
componente arquitectnico puede ser ampliado para incluir informacin sobre si los
implementos de componentes el requisito totalmente, o slo parcialmente.

Fig. 6.3 Tres puntos de vista de las relaciones entre SLO

Ramesh y Jarke informan que las prcticas de requisitos actuales no abarcan totalmente
el uso de la informacin semntica, para aumentar la utilidad de las relaciones entre las
SLO [31]. Una relacin que indica que dos SLO afectan entre s, pero no la forma, estar
abierto a la interpretacin de todos los interesados
. Segn Ramesh y Jarke, diferentes
actores interpretan relaciones en diferentes formas sin informacin semntica . Por
ejemplo, un usuario puede leer una relacin como " implementado" mientras que un
desarrollador puede leer la misma relacin como " puts - restricciones -on"
Para ilustrar an ms la necesidad de la semntica en enlaces de trazabilidad, hemos
creado un ejemplo con seis SLO interconectados. La figura 6.3 muestra el SLO en una
conectividad grfico (izquierda), donde una flecha significa que la fuente de SLO afecta
el destino SLO. Por ejemplo, SLO 2 afecta, o tiene un impacto en, SLO1 y SLO 4.
El grfico de conectividad corresponde exactamente a una matriz de trazabilidad, se
muestra a continuacin en la figura. Una flecha en la matriz de trazabilidad indica que la
fila SLO afecta a la columna SLO. Tanto el grfico de conectividad como la matriz de
trazabilidad muestran el impacto directo o cambio principal si es necesario, mientras
que el impacto indirecto o cambio secundario es necesario, slo puede ser deducido por
la que atraviesa los enlaces de trazabilidad. Para sistemas con muchos SLO, la cantidad
de impacto indirecto se convierte rpidamente en un inmenso grfico de conectividad o

una matriz de trazabilidad difcil de deducir. Para visualizar mejor el impacto indirecto,
la matriz de trazabilidad se puede convertir en una matriz de alcanzabilidad, utilizando
un algoritmo 1 de cierre transitivo. La accesibilidad de la matriz para nuestro ejemplo es
tambin en la Fig. 6.3, mostrando que todos SLO finalmente tienen impacto en cada
otro SLO. En consecuencia, la matriz de accesibilidad para este ejemplo es de uso
limitado para la evaluacin de impacto indirecto. Bohner seala que este problema es
comn en contextos de software, a menos que se tome alguna accin para limitar el
rango de impacto indirecto [4].

Una forma de limitar el rango de impacto indirecto es agregar distancias a la matriz de

accesibilidad . Al hacerlo, es posible no tener en cuenta impactos indirectos con
distancias por encima de un umbral predefinido. Se trata de una simple adicin a la
creacin normal de la matriz de accesibilidad, pero no tiene en cuenta el hecho de que
los diferentes tipos de relaciones de trazabilidad pueden afectar el rango diferente de
impacto indirecto .
Otra solucin es dotar a la matriz de trazabilidad con la semntica de trazabilidad y
ajustar el algoritmo de cierre transitivo para tomar en cuenta esa informacin. Para los
algoritmos debe considerar dos SLO alcanzables entre s, slo si la trazabilidad de
relaciones que forman el camino entre ellos son de tales tipos que se espera para
propagar el cambio.
El anlisis de trazabilidad es til en la ingeniera de requisitos, que vemos como una
actividad realizada a lo largo de todo el ciclo de vida del software. Inicialmente, la
trazabilidad de enlaces slo se pueden formar entre los requisitos, pero como el diseo
e implementacin crecen, los enlaces se pueden crear desde los requisitos hasta otra
SLO tambin.
6.2.1.2 Tcnicas de cortado
Se corta los intentos de comprender las dependencias utilizando partes independientes
del programa [16]. El programa se corta en un pedazo descompuesto, que contiene el
lugar del cambio, y el resto del programa, una parte del complemento. Se corta sobre la
base de datos y las dependencias de control del programa. Los cambios realizados en la
descomposicin cortada son alrededor de la variable en que el corte se basa, no estn
garantizadas para afectar al corte del complemento. El corte limita las posibilidades de
propagacin de cambio y hace que lo particionado sea acotado. La tcnica es, por
ejemplo, utilizado por Turver y Munro [37] en la cual, el corte de los documentos, con el
fin de dar cuenta de un efecto domin como una parte de anlisis de impacto.

Shahmehri et al. [33] aplicar la tcnica de depuracin y la prueba. Lenguajes POO como
C ++ son apoyados a travs de la labor del Consejo et al. Y sus tcnicas de corte en
lonchas para C ++ [36]. Las herramientas de seccionado se basan a menudo en tcnicas
de presentacin basados
en caracteres, que pueden hacer que sea ms difcil de analizar
dependencias, pero la presentacin visual de las secciones se puede aplicar para
impactar el anlisis como se muestra por Gallagher [15].
El corte arquitectnico fue presentado por Zhao [42], y es similar al programa corte en
que identifica una rebanada de la arquitectura que est sujeto a la propuesta cambio, y
uno que no lo es. A diferencia del programa convencional de corte, la arquitectura
slicing opera sobre la arquitectura de software de un sistema. Como tal, se pueden
emplear en el desarrollo temprano, antes se escriba el cdigo. La tcnica utiliza un
grfico de flujos de informacin con el fin de rastrear los componentes que pueden
verse afectados por el componente que se est cambiado. Adems, aquellos
componentes que puedan afectar a la componente que se cambiaron, tambin se
identifican. Esto significa que debe haber una especificacin de la arquitectura que
expone toda la informacin los flujos que contiene.
Las tcnicas de cortado pueden ser tiles en la ingeniera de requisitos para aislar el
impacto de algunos requisitos a cambiar por parte especfica del sistema. A fin de
proporcionar un punto de partida para el mtodo de los cortes, el impacto directo del
cambio debe ser primero a evaluar.
L
a clausura transitiva de un grafo es un grfico en el que se aade un borde entre los
nodos A y B si es posible llegar a B de A en el grfico original.
1

PAG 12 -14
Estrategias manuales:
Las estrategias de anlisis manuales de impacto no dependen tan fuertemente de
especificaciones estructurales como lo hacen sus contrapartes automatizables. En
consecuencia, existe el riesgo de que son menos precisos en sus predicciones de
impacto. Por el contrario, pueden ser mas fciles de introducir un proceso de gestin de
cambio y son en nuestra experiencia comnmente empleado en la industria sin tener en
cuenta su precisin.
Las estrategias presentadas aqu, utilizando diseo de documentacin y entrevistas, se
utilizan principalmente para la evaluacin del impacto inicial establecida mediante la
identificacin de impacto directo. La identificacin del impacto secundario es posible,

pero es mejor manejado por estrategias automatizables. Sealar que las estrategias
manuales como estn descritas se pueden utilizar para capturar enlaces de trazabilidad
entre SLOs para ser utilizado en el anlisis de trazabilidad.
6.2.2.1 Diseo de documentacin:
El diseo de documentacin viene de muchas formas diferentes, por ejemplo, como
bocetos de arquitectura, maquetas de arquitectura basadas en vistas, diagramas UML
orientados a objetos, descripciones textuales de componentes de sw y as
sucesivamente. La calidad de la documentacin de diseo depende del propsito para el
cual fue escrito, la frecuencia con la que se actualiza y la informacin que contiene. Es
muy comn en la industria de que la documentacin de diseo esta escrito al principio
de un proyecto solo para convertirse en un articulo de estanteria, o que la
documentacin se escribe despus del proyecto solo por el motivo de escribirlo. Para
realizar anlisis de impacto y determinar cmo un requisito nuevo o modificado afecta
el sistema basado en la documentacin de diseo requiere la documentacin para estar
al da y en consonancia con cualquier implementacin realizadas hasta la fecha. Adems
de un requisito previo para el uso de SLOs diseos encontrados en la documentacin. El
xito y la precisin de esta actividad depende de una serie de factores:
Conocimiento y habilidades de las personas que realizan el anlisis:
las personas con
poca penetracin en el sistema lo ms probable es que tenga problemas identificando el
impacto de requerimientos modificados en el sistema.
La disponibilidad de la documentacin: La documentacin que est "escondida" en los
ordenadores personales o almacenados en carpetas annimas puede pasar por alto en
el anlisis.
Cantidad de informacin transmitida en la documentacin
: bocetos de diseo simples
son comunes, pero no logran expresar la semntica de las conexiones entre clases o
componentes arquitectnicos. Eligiendo esquemas de denominacin o anotacin
incompatible hace que la tarea de anlisis sea arduo.
Documentacin clara y consistente: Documentacin Ambigua es abierta a la
interpretacin, es decir, por ejemplo, que el impacto de un cambio propuesto es, junto
con una gran incertidumbre, simplemente porque otra interpretacin habra cedido
diferente impacto.
si anteriormente se han tenido en cuenta los factores, anlisis de impacto de un cambio
puede llevarse a cabo mediante la identificacin de los SLOs diseos que implementan o
de cualquier otra manera depender de los requisitos afectados por el cambio. Otras
medidas que se pueden tomar para aliviar el esfuerzo de anlisis de impacto son:

Mantener un diseo razonable: Una justificacin de diseo es la documentacin que

describe por qu se toman las decisiones de la manera que son. Bratthall ha realizado
un experimento sobre el efecto de una lgica de diseo cuando se realiza el anlisis de
impacto. Los resultados del experimento sugieren que una razn de diseo en algunos
casos puede acortar el tiempo requerido para el anlisis de impacto, y aumentar la
calidad del anlisis.
Estimar el impacto de los requisitos tan pronto como se desarrollan los requisitos: el
impacto estimado es necesariamente grueso para empezar, pero se puede mejorar de
forma incremental como el conocimiento acerca del sistema aumenta.
Por supuesto, la documentacin del diseo estructurado tambin se puede utilizar con
anlisis de trazabilidad para identificar el impacto indirecto. Por ejemplo, Briand
propone un mtodo para realizar anlisis de impacto en los modelos UML, donde
utilizan un algoritmo de cierre transitivo de encontrar impactos indirectos en los
modelos. Ellos sealan, sin embargo, el criterio esencial que los modelos UML se
actualizan como el sistema experimenta cambios.
6.2.2.2. Entrevistas:

Entrevistando a desarrolladores conocedores es probablemente la manera ms comn

de adquirir informacin sobre probables efectos de requerimientos nuevos o
modificados acorde al estudio de anlisis de impacto [25]. El estudio encuentra lo que
perciben los desarrolladores como altamente costo-efectivo para preguntar a una
persona conocedora en lugar de buscar en documentos u otras formas de fuentes de
informacin. Amplia comunicacin entre desarrolladores es tambin mencionada por
desarrolladores como un factor de xito para desarrollo de proyectos de software.
Anlisis de cdigo fuente es la segunda manera ms comn de adquirir informacin
sobre el probable impacto de requerimiento nuevo o modificado.
Mientras todos los desarrolladores dijeron que entrevistaron otros desarrolladores y
cdigos fuentes consultados, cerca de la mitad de los desarrolladores respondieron que
ellos tambin consultaron informacin, como modelos de caso de uso y modelos de
objetos, almacenados en la herramienta CASE en uso. Cuando se le pregunt por qu no
se utiliz informacin de modelos de objetos ms ampliamente, los desarrolladores
respondieron que la informacin en modelos de objeto no contiene suficiente detalle
para el anlisis de impacto. Adems, ellos no creen que la informacin en el modelo fue
up-to-date
. Cdigo fuente, en cambio, es siempre
up-to-date.

Entre algunos desarrolladores, especialmente nuevos, la actitud hacia el uso de modelos

de objetos es la base para determinar cambio como un efecto de requerimientos
nuevos o modificados fue menos que positiva. Modelos de objetos (y la herramienta
CASE particular que es usada) fueron, sin embargo, mencionados como una buena
herramienta para documentar anlisis de impacto y para responder preguntas sobre la
relacin entre requerimientos y diseo de objetos usando el apoyo de enlaces de
trazabilidad.
6.3 Requerimientos No-Funcionales
Los requerimientos son divididos frecuentemente en
requerimientos
funcionales
y
no-funcionales. Requerimientos no-funcionales, o requerimientos de calidad, son los
requerimientos los cuales no se preocupan especficamente de la funcionalidad del
sistema [20].
Requerimientos no-funcionales son frecuentemente ms difciles de tratar que los
funcionales, porque su impacto es generalmente no localizado en una parte del sistema,
pero atraviesa todo el sistema.
Un requerimiento no-funcional que, por ejemplo, se relaciona con y pide alta seguridad,
frecuentemente requerimientos funcionales se soporta en la arquitectura de software,
como tambin a restringir al acceso a los datos, manejo de archivos, vistas de bases de
datos, funcionalidades disponibles, etc. Cambios en los requerimientos funcionales
tambin pueden afectar los requerimientos no-funcionales. Por ejemplo, si un cambio
involucra remplazar un protocolo de transferencia de datos por uno que utiliza ms
datos, el rendimiento total del sistema puede descender. Un acercamiento para lidiar
con requerimientos no-funcionales es convertirlos en uno o ms requerimientos
funcionales [6]. Por ejemplo, un requerimiento indica que no se debe permitir a
personas no autorizadas acceso a los datos se puede dividir en las necesidades ms
tangibles un usuario debe loguearse en el sistema usando una contrasea y la
identidad de los usuarios debe ser verificada a travs del subsistema login al acceder a
los datos. No todos los requerimientos no-funcionales pueden convertirse de esta
forma, sin embargo, an significa que los cambios en ellos todava tienen impacto en
todo el sistema. Desafortunadamente, la mayora de las tcnicas de anlisis de impacto
se ocupan exclusivamente de los cambios que pueden ser identificados inicialmente a
un componente, clase especfica o similar.
Lam y Shankararam insisten en la distincin entre el anlisis del impacto funcional y el
anlisis del impacto de la calidad, por ejemplo, anlisis de impacto para requerimientos
funcionales y requerimientos de calidad, respectivamente [21]. Ellos sugieren el uso de
Despliegue de la Funcin de Calidad (DFC en ingls Quality Function Deployment QFD)
para lidiar con cambios en ambos requerimientos funcional y no- funcional. En DFC, se

construye una matriz que conecta las necesidades del cliente con caractersticas de
diseo. Un cambio a un requisito se puede asignar a disear funciones a travs de la
matriz DFC.
Cleland-Huang et al. et al. realizar anlisis de impacto en funcin de rendimiento medio
de trazabilidad basado en eventos [9]. En otras palabras, requerimientos estn
interconectados como editores de eventos suscribiendo modelos de rendimiento. Cada
vez que se propone un cambio en un requisito, los modelos de rendimiento pertinentes
son re-calculados. El anlisis del impacto resultante es posteriormente comparado con
restricciones en la especificacin de requerimientos. Si varios requerimientos estn
relacionados con el mismo modelo de desempeo, deben ser todos verificados contra el
anlisis de impacto.
PAG 15 - 16

El impacto de los requisitos no funcionales se trata comnmente con software de

evaluacin de arquitectura. Bosch ha creado un mtodo de diseo de arquitectura de
software con un fuerte enfoque en los requerimientos no funcionales [6]. En el mtodo,
un inicialmente la arquitectura funcional se transforma progresivamente hasta que sea
capaz de reunir todos los requisitos no funcionales planteados en el sistema. Partes del
mtodo se prestan bien para que impactan anlisis, puesto que tratan con el reto de la
evaluacin donde el impacto a menudo en todo el sistema que los requisitos no
funcionales tienen. Para la mayor parte operativa de atributos no funcionales (por
ejemplo, el rendimiento y la fiabilidad), un perfil consta de escenarios de uso, la
descripcin de los usos habituales del sistema-a-ser es creado. Los escenarios dentro del
perfil se le asignan pesos relativos, de conformidad con su frecuencia o ocurrencia
probable. En la evaluacin basada en escenarios, un anlisis del impacto se realiza
mediante la evaluacin del impacto arquitectnico de cada escenario en el perfil. Para

obtener un rendimiento, el impacto puede ser expresado como la ejecucin del tiempo,
por ejemplo. Con base en el impacto y los pesos relativos de los escenarios, es posible
calcular valores globales (por ejemplo, el rendimiento y la ejecucin tiempo) para el
atributo de calidad que se est evaluando. Estos valores se pueden comparar con los
requisitos no funcionales correspondientes al atributo de calidad, con el fin de ver si se
cumplen o no. Adems, sirven como limitaciones sobre el alcance a la que los requisitos
no funcionales pueden cambiar antes de que una reorganizacin arquitectnica es
necesario. Adems, en caso de un cambio de requisito funcional, es posible para
incorporar el cambio en una arquitectura especulativa, vuelva a calcular el impacto de
los escenarios en el perfil de escenario, y ver si los requisitos no funcionales Todava se
cumplen o no.
6.4 Impacto Anlisis de mtricas
Las mtricas son tiles en anlisis de impacto por varias razones. Ellos pueden ser, por
ejemplo, ser utilizado para medir y cuantificar el cambio causado por un requisito nuevo
o cambiado en el punto de la actividad de anlisis de impacto. Las mtricas tambin se
pueden utilizar para evaluar la propio proceso de anlisis de impacto una vez que se han
aplicado los cambios. Esto es ilustrado en la Fig. 6.4, en la que se representan dos
puntos de medida; uno despus de los requisitos fase ha terminado y el diseo est a
punto de comenzar, y uno cuando la prueba tiene se ha completado. El uso de estos
puntos de medida, se puede capturar el impacto previsto (el primer punto) y
compararlo con el impacto real (el segundo punto).
Este tipo de la medicin es crucial para poder hacer un anlisis y aprender de las
experiencias con el fin de mejorar continuamente la capacidad de anlisis de impacto.
La figura simplifica e ilustra un ciclo de aprendizaje basado en un modelo de cascada
similares. Como se seal anteriormente,
el anlisis de impacto se puede utilizar
durante todo el ciclo de vida
con el fin de analizar las nuevas necesidades y los puntos
de medida se pueden aplicar en consecuencia: siempre que sea una prediccin que se
ha realizado y siempre que una implementacin se ha completado.

6.4.1 Las mtricas para cuantificar Impacto del Cambio

Las mtrica para cuantificar el impacto del cambio se basan en el SLO que se prev para
cambiar como efecto de requisitos nuevos o modificados. Adems, los indicadores de la
gravedad del cambio se pueden utilizar. Tales medidas del impacto previsto puede ser
utilizado para estimar el costo de un cambio propuesto o un nuevo requisito. Cuanto
ms requisitos y dems SLO se vean afectados, ms extendidos son y cuanto ms
complejo sea el cambio propuesto, ser ms caro el nuevo o modificado requisito.

Los requisitos que son costosos en este sentido, pero ofrecen poco valor pueden, por
ejemplo, ser filtrados en beneficio de los requisitos que proporcionan ms valor, pero a
un costo menor.
El cambio de impacto se puede medir en base al conjunto de requisitos que se vean
afectados por el cambio. Por ejemplo, el nmero de requisitos afectado por un cambio
puede contarse con base en este conjunto. La complejidad de los requisitos afectados a
menudo determina la gravedad del cambio es y se puede medir de varias maneras:
Ejemplos son del tamao de cada requisito en trminos de puntos de funcin y las
dependencias de cada requisito en otros requisitos. Por otra SLO, las mtricas son
similares. Para la arquitectura y el diseo, medidas de impacto incluyen el nmero de
componentes afectados, el nmero de clases afectadas o mdulos, y el nmero de
mtodos afectados o funciones. Por cdigo fuente, los artculos de bajo nivel como
lneas afectadas de cdigo pueden ser medidos y el nivel de complejidad de los
componentes, clases, y mtodos se pueden medir utilizando mtricas estndares tales
como ciclomtica complejidad y las mtricas orientadas a objetos regulares. Para
determinar qu tan grave o costoso que un cambio es, es til para definir el impacto
factor.
Lindvall define los factores de impacto de la Tabla 6.1 para medir el impacto de un
cambio sugerido [25].
El factor de impacto se basa en hallazgos empricos en los que se
determin que los cambios en diferentes tipos de SLO se pueden utilizar como un
indicador de la magnitud del cambio.
Cuanto mayor sea el factor de impacto, ms
grave es la cambiar. Por ejemplo, los cambios que no afectan a ningn otro tipo de SLO
pero el diseo modelo de objetos son relativamente limitado en su alcance. Los cambios
que afectan al uso de los casos modelo son en lugar probable que requiera cambios que
estn relacionados con los fundamentos de la el sistema y son por lo tanto ms grandes
en su alcance. Adems, los cambios en el uso de los casos modelo lo ms probable es
que tambin implican cambios de todos los dems SLO que hacen este tipo de cambio
an ms grave.
PAG 17-18
tabla 6.1 factores de impacto.
factor de
impacto

impacto

descripcion

m1

cambio del
modelo de

estos cambios de inmobiliaria

consideran una descripcin fsica del
sistema que puede generar un cambio

objetos de
diseo .

en la arquitectura de software sobre el

tamao del cambio en el modelo.

m2

cambio de
modelo de
anlisis de
objetos.

estos
cambios
consideran
la
descripcin ideal o lgico del sistema .
un pequeo cambio aqu puede
generar un cambio en la arquitectura
del software ms grande que el
cambio en el modelo .

m3

cambiar el
modelo de
objetos de
dominio.

estos
cambios
consideran
el
vocabulario necesario en el sistema.
Un pequeo cambio aqu puede
generar gran cambio en la arquitectura
de software .

m4

cambiar el
modelo de casos
de uso .

estos cambios requieren adiciones y

supresiones en el modelo de casos de
uso . pequeos cambios aqu pueden
requerir gran cambio en la
arquitectura de software .

fig 6.5 rbol de mtricas de anlisis de impacto.

6.4.2 mtricas para la evaluacin de los anlisis de impacto

Bohner y arnold proponen una serie de indicadores con su introduccin del conjunto
impacto. estas mtricas son las relaciones entre las cardinalidades de los conjuntos de
impacto , y pueden ser vistos como indicadores de la eficacia del enfoque de anlisis de
impacto empleado :
1. #SIS / #EIS , Es decir, el nmero de SLOs pensado inicialmente para ser afectado
por el nmero de SLOs estimados a ser afectados (cambio primario y cambio
secundario ) . Una relacin de cerca de 1 es lo deseado , ya que indica que el
impacto se limita a la SLOs en SIS . Una proporcin mucho menor que 1 indica
que muchos SLOs son objeto de impacto indirecto , lo que significa que va a
llevar mucho tiempo para comprobarlos.
2. #EIS / #system , Es decir, el nmero de SLOs estimados a ser afectados por el
nmero de SLOs en el sistema. la relacin deseada es mucho menor que 1 , ya
que indica que los cambios se restringen a una pequea parte del sistema . Una
relacin cercana a 1 indicara o bien un enfoque de anlisis de impacto
defectuoso o un sistema con repercusiones extremas.
3. #EIS / #AIS , Es decir, el nmero de SLOs estimados a ser afectados por el
nmero de SLOs realmente afectada . la relacin deseada es 1 , ya que indica
que el impacto se estima perfectamente . En realidad , es probable que la
relacin sea menor que 1 , lo que indica que el enfoque no pudo estimar todos

los impactos . dos casos especiales son si AIS y estudio de impacto ambiental
slo se solapan en parte o no se superponen en absoluto, lo que tambin
indicara un fallo del mtodo de anlisis de impacto.

Fasolino y viaggio tambin definen mtricas basadas en las cardinalidades de los

conjuntos de impacto. atan las mtricas a las propiedades y caractersticas del enfoque
de anlisis de impacto , de acuerdo con el rbol en la figura 6.5.
Suficiencia es la capacidad del enfoque de anlisis de impacto para estimar el impacto
conjunto . se mide por medio de la inclusin de mtricas binarias , que est
estrictamente definido a 1 si todos los SLOs en AIS tambin estn en estudio de impacto
ambiental y 0 en caso contrario . La eficacia es la capacidad del enfoque para
proporcionar resultados beneficiosos. que se refina en la sensibilidad ondulacin ( la
capacidad de identificar un efecto domin ) , la nitidez (la capacidad de no sobreestimar
el impacto ) y la adhesin (la capacidad para estimar el impacto correcto) .
sensibilidad de ondulacion, se mide mediante amplificacin , que se define como ( #EIS #SIS ) / # SIS , es decir, la relacin entre el nmero de SLOs indirectamente afectadas y el
nmero de impactado directamente SLOs . esta relacin no debe ser preferiblemente
mucho ms grande que 1 , lo que indicara mucho ms impacto indirecto que de
impacto directo . nitidez se mide por changerate , que se define como #EIS / #system .
esta es la misma mtrica como la segunda de Arnold y bohner`s mtricas presentado
anteriormente . la adherencia se mide por S- ratio, que se define como #AIS / #EIS . S relacin es la inversa de la tercera parte de arnold un mtricas bohner`s presentados
previamente .
lam y shankararaman proponer mtricas que no se liberan a los conjuntos de impacto ,
estos indicadores son ms vagamente definidos y en consecuencia existe falta de los
valores recomendados :
desviacin de la calidad , es decir, la diferencia en algn atributo de calidad ( por
ejemplo, el rendimiento ) antes y despus de que se han aplicado los cambios, o
entre los valores reales y simulados . Una diferencia mayor de lo esperado podra
indicar que el enfoque de anlisis de impacto no identific todos los impactos.
recuento de defectos , es decir, el nmero de defectos que surgen despus de
que se han aplicado los cambios. Un gran nmero de defectos podra indicar que
algn impacto fue pasado por alto por el enfoque de anlisis de impacto.

 recuento de dependencia, es decir, el nmero de requisitos que dependen de un

requisito particular . requisitos con recuento alto de dependencia deben ser
examinados cuidadosamente al ser sometidos a cambios.
Lindvall define y utiliza mtricas en un estudio de la empresa de telecomunicaciones
sueca Ericsson AB con el fin de responder a una serie de preguntas relacionadas con el
resultado ( prediccin) de anlisis de impacto como el realizado en un proyecto de
software comercial y realizado por los desarrolladores del proyecto como parte del
proyecto de trabajo regular.
PAG 19
se bas en el anlisis del impacto realizado la fase de requisitos, como la figura. 6.4
indica, y el anlisis de impacto impulsada requisitos trmino fue acuado para captar
este hecho. Los resultados del anlisis de impacto fue utilizado por el proyecto Ericsson
para estimar costos de implementacin y para seleccionar los requisitos de aplicacin
basado en el costo estimado frente beneficio percibido. El estudio primero mir al
conjunto de los requisitos recogidos predicho y el impacto real respondiendo a las
siguientes preguntas: "Qu tan bueno fue la prediccin del cambio causado por el
nuevo y cambi los requisitos en trminos de predecir el Nombre de C ++ clases para ser
cambiado" y "Qu tan bueno fue esta prediccin en trminos de predecir qu clases
que cambiar?" La ltima pregunta se divide en las dos preguntas secundarias: "se
cambiaron las clases predijeron?" y "Dnde cambiaron las clases previstas?"
Hubo un total de 136 clases de C ++ en el sistema de software. 30 de ellos se prev que
ser cambiado. El anlisis de los cambios de cdigo fuente mostr que 94 clases se han
cambiado realmente. As, slo 31,0% (30/94) de el nmero de clases modificados se
prev que ser cambiado.
Con el fin de analizar los datos adicionales, las clases se dividieron en los dos grupos de
grupo predictivo y de grupo real. Adems, cada grupo se dividi en dos subgrupos: Sin
modificaciones y cambiadas. Las clases 136 se distribuyeron entre estos cuatro grupos,
como se muestra en la Tabla 6.2.
Celda A representa las 42 clases que no se prev que cambiar y que tambin se mantuvo
sin cambios. La prediccin fue correcta ya que estas clases se prev que mantendr sin
cambios, que tambin result ser cierto. La prediccin era implcita como estas clases se
identificaron indirectamente -ellos result como un efecto secundario como
complemento clases de predecir cambiado.

Celda B representa las clases cero que se prev que cambie, pero en realidad
permanecieron sin cambios. Un gran nmero aqu indicara una gran desviacin de la
prediccin.
Celda C representa las 64 clases que no se prev que cambie, pero result ser cambiado
despus de todo. Al igual que con las clulas B, un gran nmero en esta celda indica una
gran desviacin de la prediccin.
Celda D, por ltimo, representa las 30 clases que se prev que ser cambiado y que eran,
de hecho, cambi. Esto es una prediccin correcta. Un gran nmero en esta celda indica
una buena prediccin.
Hay varias maneras de analizar la bondad de la prediccin. Una manera es calcular el
porcentaje de predicciones correctas, que era (42 + 30) / 136 =
PAG 20
52,9%. Por lo tanto, la prediccin era correcta en aproximadamente la mitad de los
casos. Otra forma es utilizar el valor kappa de Cohen, que mide el acuerdo entre dos
grupos que van desde -1,0 hasta 1,0. La cifra de -1.0 significa incumplimiento total entre
los dos grupos, 1.0 significa el cumplimiento total y el 0,0 significa que el resultado no es
mejor que el puro azar [11]. El valor kappa en este caso es 0,22, lo que indica una
prediccin razonable. Nos referimos a [26] para ms detalles sobre los clculos kappa
para el ejemplo. Una tercera forma de evaluar la prediccin es comparar el nmero de
clases previstas para ser cambiado con el nmero de clases ha cambiado realmente. El
nmero de clases prev que ser cambiado en este caso result ser subestimada en gran
medida por un factor de 3. Por lo tanto, se identific slo alrededor de un tercio del
conjunto de clases modificados. Es, sin embargo, vale la pena notar que todas las clases
que se prev que se pueden cambiar en realidad cambiado.
El estudio analiz a continuacin el impacto previsto y real de cada requerimiento,
respondiendo a preguntas similares para cada requisito. Se organizaron los requisitos y
las clases que fueron afectados por estos requisitos de la siguiente manera: Para cada
requisito, el conjunto de clases predijo que ser cambiado, clases del conjunto de clases
modificados y la interseccin de los dos conjuntos, es decir, que fueron ambos
predijeron y cambiado. Adems, los conjuntos de clases que se predijeron pero no
cambiaron y se identifica el conjunto de clases que se han cambiado pero no predijo.
El anlisis mostr que en casi todos los casos, hubo una subestimacin en trminos de
nmero de clases. En resumen, el anlisis mostr que el nmero de clases cambiado
dividido por el nmero de clases predichos oscil de 1,0 a 7,0.
Por lo tanto, hasta 7 veces ms clases de lo previsto se cambiaron en realidad.
Estimacin de costos en la seleccin requisitos menudo se basa en la prediccin como lo
fue en el caso de Ericsson, lo que significa que los requisitos predijeron para causar el
cambio en slo unas pocas entidades se consideran menos costoso, mientras que los

requisitos predijeron para causar el cambio en muchas entidades se consideran ms

caro. Esto hace que el orden de rango de seleccin requisitos igual a una lista de
requisitos ordenados por el nmero de elementos previstos. Al comparar el orden
relativo basado en el nmero de clases predichos con el orden relativo basado en el
nmero de clases realmente cambiado, era posible juzgar la bondad de la prediccin a
partir de otro punto de vista. En resumen, el anlisis del nivel de requisitos mostr que
la mayora de los requisitos se subestimada. Tambin qued claro que es relativamente
comn que algunas clases predichos por un requisito no se cambian a causa de este
requisito en particular, sino a causa de algn otro requisito. Esto es probablemente
debido a que los desarrolladores no estaban obligados a aplicar los requisitos
modificados tal y como se ha especificado en la propuesta de aplicacin del resultado de
anlisis de impacto. el anlisis de la orden de requisitos basados en el nmero de clases
predichas mostr que la orden no se mantuvo completamente intacta; algunos de los
requisitos que se prev que sea pequeo demostr tener un impacto en el cambio
grande, y viceversa.
Con el fin de tratar de entender el proceso de anlisis de impacto basadas en requisitos
y la forma de mejorarlo, se llev a cabo un anlisis de las diversas caractersticas de las
clases modificadas y no modificadas. Una de esas caractersticas era de tamao, y las
preguntas fueron: "Fueron largas las clases cambiadas" "Eran grandes las clases
predecidas?" y "Eran largas las clases predecidas comparadas con las clases
cambiadas?"
PAG 21
El anlisis indic que clases grandes cambiaron, mientras que las pequeas
permanecieron sin cambios. El anlisis tambin indic que las clases grandes estaban
previstas a cambiar, lo que lleva a la conclusin que el tamao de una clase podra ser
uno de los ingredientes usados por los desarrolladores, tal vez inconscientemente,
durante la bsqueda de candidatos para un requerimiento nuevo o modificado.
6.5 Soporte de herramientas
La complejidad del proceso de gestin del cambio hace que sea necesario usar alguna
especie de herramienta de soporte. Una herramienta de gestin de cambio puede ser
usada para gestionar requerimientos y otros SLOs, gestionar solicitudes de cambio,
enlazar las solicitudes de cambio a los requerimientos y otros SLOs, y monitorear el
progreso de anlisis de impacto. Una simple base de datos o herramienta de hoja de
clculo podra ser usada como un soporte bsico de gestin del cambio, pero seguira
requiriendo una considerable cantidad de trabajo manual, que eventualmente podra

llevar a inconsistencias en los datos de gestin del cambio. Si el soporte de herramientas

no es una parte integral del proceso de gestin del cambio, siempre hay un riesgo de
que no ser usada apropiadamente. Un sistema de gestin de cambio que no es usada
en toda su extensin, no puede proveer soporte apropiado al proceso.
Un problema con varias herramientas de gestin de cambio es que ellas estn
restringidas a trabajar con el cambio y el anlisis del impacto a nivel de requerimientos.
Idealmente, una herramienta de gestin de cambio dara soporte al anlisis de impacto
en requerimientos, diseo, cdigo fuente, casos de prueba, etc. Sin embargo, eso
requerira la integracin de herramientas de gestin de requerimientos, herramientas
de diseo y entornos de desarrollo en una sola herramienta o un conjunto de ellas. En
un catlogo de requerimientos para herramientas de gestin de requerimientos,
Hoffmann enumeran ambas trazabilidad e integracin de herramientas como
requerimientos de alta prioridad, y funciones de anlisis como requerimientos de
mediana prioridad, confirmando la importancia de estas caractersticas.
En un estudio de las caractersticas de 29 herramientas de gestin de requerimientos
dando soporte a trazabilidad, slo pudimos encontrar 9 herramientas para las cuales era
declarado explcitamente en sus sitios web que ellos entregaban soporte a la
trazabilidad entre requerimientos y otros SLOs, tales como elementos de diseo, casos
de prueba y cdigo. Dependiendo de la verbosidad y la calidad de la informacin
disponible, esto puede no ser una cifra exacta. Sin embargo, esto indica que en muchos
casos es necesario usar varias herramientas diferentes para gestionar trazabilidad y
realizar anlisis de impacto, lo que puede ser problemtico dependiendo del grado de
integracin de las herramientas.
Hay herramientas que extraen informacin de dependencia de representaciones de
sistema existentes, por ejemplo cdigo fuente y modelos de objeto, pero la tarea de
tales herramientas, no obstante, es difcil y a menudo requieren de trabajo manual.
Representaciones de ms alto nivel, pueden ser muy gruesas, y el cdigo fuente podra
tener dependencias ocultas, por ejemplo debido al enlace. Egyed, por ejemplo, propone
un enfoque para la extraccin de dependencias principalmente del cdigo fuente. De
entrada a este enfoque se tiene un conjunto de escenarios de prueba y algunos rastros
hipotticos que enlazan SLOs a los escenarios. Luego calcula las huellas de los
escenarios, por ejemplo las lneas de cdigo fuente que cubren; y basados en las huellas
y los rastros hipotticos genera los rastros restantes.
PAG 22
El enfoque tambin puede ser usado cuando no existe cdigo fuente, por ejemplo
simulando el sistema o de la hiptesis en torno a las huellas de los escenarios.

Herramientas que lidian con cdigo fuente son mayormente usadas en el contexto de
mantenimiento de software, y son obviamente de uso limitado dentro del proyecto de
desarrollo. Natt och Dag han estudiado el anlisis de similitud automtica como un
medio para encontrar requerimientos duplicados en el desarrollo impulsado por el
mercado. Adems del campo original de aplicacin, ellos sugieren que su tcnica puede
ser usada para identificar relaciones de dependencia entre requerimientos, por ejemplo
que dos requerimientos tienen una relacin de o, o que varios requerimientos tratan
de funcionalidades similares. Cmo tratar con lenguaje natural de requerimientos es
ms explorado en el captulo 10. Herramientas que ayudan en la realizacin de anlisis
de impacto pueden ser sinnimos con los mtodos subyacentes. Mtodos que se basan
en el anlisis de trazabilidad son muy adecuados para la inclusin en herramientas que
tratan de predecir el impacto indirecto. Por ejemplo, Fasolino y Visaggio presentan
ANALYST, una herramienta que evala el impacto en modelos basados en
dependencia. Lee, presenta otra herramienta, ChAT, la cual calcula el efecto domin
causado por un cambio al sistema. Muchas de tales herramientas son comnmente
herramientas a prueba de conceptos, construidas para mostrar o dar soporte a un
algoritmo o metodologa particular. Lo que est faltando es la integracin de
herramientas de gestin del cambio en la corriente principal.
6.6 Futuro del Anlisis de Impacto:
La mayora de las estrategias de anlisis de impacto funcionan bajo el supuesto de que
los cambios slo afectan a la funcionalidad. Esto provoca que los cambios de impacto a
los requerimientos no funcionales sean mucho ms difciles de evaluar. Muchas veces
los cambios realizados pueden afectar indirectamente a los requerimientos no
funcionales, y all es donde justamente radica su dificultad de evaluacin. Ya existen
trabajos que abordan este tema (ver 9 y 21), pero aun as se necesita un estudio con
mayor nfasis, especficamente en el anlisis de impacto de los requisitos no
funcionales.
Como ya hemos sealado, un anlisis de impacto apunta, sobre todo al contexto de
mantenimiento de software. Hemos argumentado que el anlisis de impacto es una
actividad esencial tambin en contextos ingeniera de requerimientos, pues, un anlisis
de impacto con estrategias estndar, se puede aplicar a la mayora de los casos (por
ejemplo, enfoques de trazabilidad que se ejercen habitualmente para los requisitos).
Todava hay, sin embargo, la necesidad de realizar ms investigaciones centradas en los
aspectos de ingeniera de requisitos y anlisis de impacto, por ejemplo, la forma en que
se relacionan los requisitos con otros requisitos SLOs y cmo el cambio se propaga en
este contexto. La mayora de las estrategias automatizadas para el anlisis de impacto,

asumen modelos completos e informacin completa de su trazabilidad. Es muy comn

que en la industria se puedan encontrar modelos que no se actualizan y que su
informacin de trazabilidad es slo parcial (o incompleta), es por ello que hay una gran
necesidad de obtener ms estrategias slidas de anlisis del impacto que puedan
trabajar con informacin parcial. Egyed ha propuesto uno de estos enfoques (12). Las
herramientas existentes para el anlisis de impacto son a menudo las herramientas de
prueba de concepto, o slo funcionan con escasos problemas de anlisis de impacto,
tales como la extraccin de las dependencias de las representaciones del sistema.
Algunos de los requisitos principales se gestionan utilizando herramientas que
incorporan la evaluacin de impacto que, no slo se realiza sobre los requisitos, sino
tambin sobre el diseo, cdigo y prueba, pero lejos de todas estas cosas. El anlisis
de impacto, a gran escala, debe ser una parte integral de la herramienta de gestin de
requisitos para que de esta forma, el cambio sea tratado adecuadamente. El anlisis de
impacto debe adaptarse a los distintos tipos de sistemas actuales tales como
aplicaciones web y software COTS. Por ejemplo; las aplicaciones web, que a menudo
consisten en componentes independientes que se conectan a un repositorio central,
como las conexiones que se poseen en una base de datos. Con este ejemplo es posible
observar que; hay pocas dependencias de control entre los componentes, y en cambio
las Webs estn ricas de dependencias de datos hacia y dentro del depsito central.
El hecho de que dichos repositorios se pueden compartir entre varios sistemas
distintos, introduce dependencias de interoperabilidad, que las estrategias de anlisis
de impacto (especialmente diseados para estas tecnologas) deben abordar, con el fin
de ser efectivas.

6.7 Resumen:
Anlisis de impacto es una parte importante de la ingeniera de requisitos ya que,
justamente, los cambios en el software, a menudo son iniciados por cambios en los
requisitos. Como el proceso de desarrollo se hace paso a paso, es posible que en
modelos como el de la cascada aparezcan nuevos requisitos, o requisitos que requieren
modificacin, como ya hemos mencionado, esto puede suceder en cualquier momento
del proceso de desarrollo, es por ello que el anlisis de impacto se convierte en una
parte integral de todas las fases de desarrollo de software. El anlisis de impacto es una
herramienta que se ha utilizado desde hace mucho tiempo, obteniendo buenos
resultados, aunque no necesariamente el uso de ese esta, resolver completamente la
problemtica ya que el problema no se resuelve slo con determinar con precisin el
efecto de un cambio propuesto. La necesidad de los profesionales de software, de
determinar qu se debe cambiar, con el fin de implementar los cambios de requisitos,

siempre ha estado presente. Los mtodos y estrategias clsicos para llevar a cabo el
anlisis de impacto son; la dependencia de anlisis, anlisis de trazabilidad y de corte. El
Trabajo de anlisis de impacto temprano se centr en la aplicacin de estos mtodos
y estrategias al cdigo fuente, con el fin de llevar a cabo el corte del programa y
determinar un efecto domin de cambios en el cdigo. Con el tiempo la ingeniera de
software a madurado, permitiendo que organizaciones dedicadas a este rubro tambin
lo hagan, mejorando sus procesos de produccin de software, sin embargo, ha dado
lugar a una necesidad de comprender cmo las solicitudes de cambio afectan a otros
SLOs, a su cdigo fuente, sus los requisitos y a sus mismos mtodos y estrategias
aplicadas. Los mtodos y estrategias tpicos actuales, se basan en el anlisis de la
trazabilidad o dependencia de la informacin, utilizando tcnicas de corte, consultas a
las especificaciones de diseo y dems documentacin, y adems entrevistar a los
desarrolladores con conocimientos. El entrevistar a los desarrolladores con
conocimientos, es probablemente la forma ms comn de adquirir informacin sobre
los efectos probables de requisitos nuevos o modificados. Las mtricas son tiles e
importantes en el anlisis de impacto por varias razones. Las mtricas pueden, por
ejemplo, ser utilizadas para medir y cuantificar el cambio causado por un requisito
nuevo o modificado en la actividad de anlisis de impacto. Las mtricas tambin se
pueden utilizar para evaluar el proceso de anlisis de impacto en s, una vez que se han
aplicado los cambios. En la determinacin de la gravedad de un cambio o que tan
costoso es, todos estos puntos son tiles para determinar el factor de impacto, ya que
indican la probabilidad de un cambio a un cierto tipo de SLO.
Para resumir
: El anlisis de impacto es una actividad crucial para apoyar la ingeniera de
requisitos. El formulario de resultados de anlisis de impacto se alimenta de muchas
actividades como la estimacin de los requerimientos de costo y priorizacin de las
necesidades del software. Estas actividades se alimentan directamente de la
planificacin de proyectos, es por ello que el anlisis del impacto se convierte en una
actividad central, en el xito del proyecto.