MODELOS_DE_TRAZABILIDAD_DE_REQUISITOS_PA.pdf

Citar: Montoya, L; Correa-Henao G. Modelos De Trazabilidad De Requisitos Para El Desarrollo De Software. QUID No. 20, Ene-Jun 2013.
Quid, N°. 22, pp. 29-38, Ene-Jun, 2013, ISSN: 1692-343X, Medellín-Colombia
MODELOS DE TRAZABILIDAD DE REQUISITOS PARA EL DESARROLLO DE SOFTWARE
MODELS OF REQUIREMENTS FOR TRACKING SOFTWARE DEVELOPMENT
Mg. Lina María Montoya Suarez
Universidad Autónoma Latinoamericana,
Facultad de Ingenierías, Carrera 55A N° 49-51.
Medellín, Colombia
linamaria.montoya@unaula.edu.co
PhD. Gabriel Jaime Correa-Henao
Fundación Universitaria Luis Amigó,
Facultad de Ingenierías,
Transversal 51A N° 67B 90.
Medellín, Colombia
gabriel.correahe@amigo.edu.co
Recibido el 13-03-2013. Aprobado el 05-05-2013)
Resumen: este artículo presenta una revisión del estado del arte sobre la trazabilidad, la cual es definida como la
"aptitud para rastrear la historia, la aplicación o la localización de una entidad mediante indicaciones registradas".
Es fundamental hacer el seguimiento a la ingeniería de Requisitos cuando se desea construir un software de calidad,
dado que es una etapa de análisis y estudio detallado. Cuando ocurren cambios en el software, la trazabilidad hace
que sea relativamente más fácil evaluar el impacto que los cambios podrían tener en otras partes del proceso de
desarrollo; esto permite seguir las huellas en los requisitos, según se comprueba en esta investigación.
Palabras clave: trazabilidad, ingeniería de requisitos, consistencia, completitud.
Abstract: this paper shows an overview of state of the art on Traceability which is defined as "the ability to trace the
history, application or location of an entity by means of recorded indications." It is important to point out the
monitoring of Requirements Engineering on the different stages in order to warranty quality software, since it
represents a process of analysis and detailed study. When changes occur in the software, traceability makes it
relatively easy to assess the impact that changes could have on other parts of the development process; this allows
the following of steps in the software requirements, as shown in this research.
Keywords: traceability, requirement engineering, consistency, completeness.
1. INTRODUCCIÓN
El propósito de este trabajo de investigación es
presentar una parte del estado del arte que permita
administrar documentación efectiva de trazabilidad
entre diferentes 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.
Se pretende explorar las estrategias para gestionar y
almacenar la información que facilite realizar
trazabilidad entre modelos, incluyendo el análisis de
información que se puede integrar en los modelos a
los que se refiere.
También se hace referencia al análisis de
información de trazabilidad que se puede almacenar
por separado en otro modelo (Drivalos et al. 2009)
(Aguilar-Calderon, Garrigos, and Mazon 2010).
En esta contribución técnica también se persigue la
idea alrededor de la confianza del proceso en el ciclo
de vida de desarrollo, con el fin de facilitar el
seguimiento de las huellas desde su inicio a su fin.
Por lo tanto, el proceso planteado será acompañado
de información sobre la generalidad de cada uno de
los modelos que existen para generar trazabilidad de
requisitos en un desarrollo de software (Anaya and
Letelier 2002).

30
Esta contribución técnica se estructura de la
siguiente manera: En el capítulo 2 se presenta un
marco te6rico de las definiciones básicas de
trazabilidad, trazabilidad de requisitos y requisitos
entre otros. En el capítulo 3 se analizan los modelos
de trazabilidad presentados por Lindvall, Gotel et al.,
Ramesh et al., Letelier, Egyed y Enterprise Architect
(Montoya 2013), al igual que un diagnostico sobre
los modelos de trazado. Finalmente se presentan las
conclusiones relacionadas con el ejercicio de
búsqueda y análisis.
2. MARCO TEÓRICO
En esta sección se presentan los elementos teóricos
principales de trazabilidad, requisitos, ingeniería de
requisitos, entre otros. Las definiciones presentadas
en esta sección serán de utilidad para la
comprensión de los modelos presentados en los
capítulos subsiguientes.
2.1. Trazabilidad
La trazabilidad o rastreabilidad se define como la
"aptitud para rastrear la historia, la aplicación o la
localización de una entidad mediante indicaciones
registradas" (ISO 1994).
Explica el grado en el cual una relación puede ser
establecida entre dos o más productos del proceso de
desarrollo, especialmente entre productos que tienen
una relación predecesor- sucesor o maestro
subordinado, por ejemplo, el grado en el cual se
corresponden requisitos y el diseño de un sistema
(Oman and Hagemeister 1992).
2.2. Completitud
Se refiere la cuantificación de especificación,
expresando que es completa según el grado que todas
sus partes están presentes y cada parte es totalmente
desarrollada (Boehm 1987) (Boehm 1984).
2.3. Consistencia
Una especificación es consecuente al grado de sus
provisiones siempre y cuando no entren en conflicto
el uno con el otro o con especificaciones gobernantes
y objetivos (Boehm 1984).
2.4. Trazabilidad de Requisitos
Consiste en la habilidad para seguir la vida de un
requisito en ambos sentidos, hacia sus orígenes o
hacia su implementación, a través de las
especificaciones generadas durante el proceso de
desarrollo. Es un factor de calidad (Glinz 2007).
Es la capacidad de describir y seguir el ciclo de vida
de un desarrollo en avance hacia atrás, es decir, desde
sus orígenes, a través del análisis y los requisitos para
su posterior distribución y uso, teniendo presente la
iteración en cualquiera de las fases (Gotel and
Finkelstein 1994).
2.5. Requisitos
El término describe una condici6n o necesidad de un
usuario para resolver un problema o alcanzar un
objetivo (IEEE 2006).
Una condición o capacidad que debe estar presente
en un sistema o componentes de sistema para
satisfacer un contrato, estándar, especificación u otro
documento formal (Moore 1998).
Un requisito es simplemente una declaración
abstracta de alto nivel de un servicio que debe
proporcionar el sistema o una restricción de este
(Somerville 2005).
2.6. Ingeniería de Requisitos
La rama de la "ingeniería de Requisitos" ayuda a los
ingenieros de software a entender mejor el problema
en cuya solución trabajaran. Incluye el conjunto de
tareas que conducen a comprender cual será el
impacto del software sobre el negocio, que es lo que
el cliente quiere y como interactuaran los usuarios
finales con el software (Pressman 2006).
Otras definiciones consideran que la ingeniería de
Requisitos es el proceso de desarrollar una
especificación de software. Las especificaciones
pretender comunicar las necesidades del sistema del
cliente a los desarrolladores del sistema.
(Somerville 2005).
También se aceptan definiciones en la ingeniería de
Requisitos como el conjunto de actividades en las
cuales, utilizando técnicas y herramientas, se analiza
un problema y se concluye con la especificación de
una solución (a veces más de una) (Ortas 1997).
3. MODELOS DE TRAZABILIDAD
Algunos modelos de trazabilidad para el desarrollo
de software son de: Lindvall, Gotel et al., Ramesh et
al., Letelier y Egyed y Enterprise Architect.
De cada uno, se presentará resumidamente indicando
su respectivo modelo, su semántica para realizar el
trazado y los mecanismos utilizados para la
verificación de consistencia y completitud de los
requisitos (Montoya 2013).

31
3.1. Modelo de Lindvall & Sandahl
En las publicaciones "Practical implications of
traceability y Traceability aspects of impact analysis
in object-oriented systems" presentan un modelo que
ofrece diferentes técnicas para realizar el trazado
entre artefactos de software que resultan del proceso
software en tres niveles de abstracción (Lindvall and
Sandahl 1996), (Lindvall and Sandahl 1998):
1. El dominio
2. El análisis
3. El diseño.
Para esto aplica la trazabilidad hacia a delante
(forward) y hacia atrás (backward), vertical y
horizontal, lo cual distingue entre artefactos
permanentes y temporales para jerarquizar el
trazado. Debido a esto, clasifica la trazabilidad en dos
dimensiones (Lindvall and Sandahl 1996). En la
primera, se identifican los vínculos de trazados entre
los diferentes elementos del modelo, por ejemplo: de
objeto a objeto (object-to-object), relación a relación
(Asociación-to-asociación) caso de uso (use-case-
to-use-case), requisitos a casos de uso, etc. (Lindvall
and Sandahl 1998).
En la segunda fase, se determina como se realiza el
trazado: por vínculos explícitos (o relaciones de los
modelos de desarrollo), por referencia, por nombre o
por la experiencia del desarrollador y el
conocimiento que tenga del dominio y del sistema
para distinguir otros ítems que estarían relacionados
(Tabares et al. 2007).
Además la trazabilidad se puede representar como
grafos dirigidos utilizando nodos y arcos. Cada
componente, cada requisito o parte de código puede
ser representado como un nodo y cada vinculo o
dependencia entre ellos es denotado por un arco
(Lindvall and Sandahl 1996) .Dadas las relaciones
que existen entre los diferentes artefactos el
resultado de estos grafos se asemeja a una red
complejo a en la que se pueden visualizar los diferentes
caminos o trazas requeridas para llegar a otros
nodos y son estas trazas las que indican la
dependencia, o no, entre ellos (Anaya and Letelier
2002).
Fig. 1. Gráfico de la Trazabilidad (Lindvall and Sandahl 1998).
En la figura 1 representa el modelo, en el cual los
nodos son productos en los diferentes niveles del
ciclo de vida de desarrollo. Los arcos indican el
trazado entre ellos.
Generar trazabilidad hace posible el seguimiento por
parte del desarrollador de la forma en como esta
diseñada y estructurada una aplicación, es así como
se genera confianza a la hora de realizar cambios que
puedan alterar el comportamiento de la aplicación,
ya que el analista tiene la posibilidad de saber que
partes del producto se verán afectadas por los
cambios que se realicen.
3.2. Modelo de Gotel, Mader, Philippow
En Gotel et al "An analysis of the requirements
traceability problem y Enabling automated
traceability maintenance by recognizing
development activities applied to models", proponen
una división de la trazabilidad que implica un
seguimiento hacia delante y hacia atrás en el ciclo de
vida de desarrollo de un producto. (Mader, Gotel,
and Philippow 2008), (Mader, Gotel, and Philippow
2009). Estas divisiones son llamadas así: Pre-RS
traceability y Post-RS Traceability, la primera se

32
refiere a los aspectos de la vida útil de un requisito
antes de ser incluido en la especificación de los
requisitos, y el segundo implica aquellos requisitos
que se presentan como resultado de la inclusión en la
especificación de los mismos (Mader, Gotel, and
Philippow 2008).
Además presenta un estudio de requisitos acerca de
las causal más destacadas del problema de la
trazabilidad (Tabares et al. 2007). El conocimiento y
la profundización que puede hacer en la práctica a
Partir del conocimiento de diferentes tipos de
trazabilidad (pre trazabilidad y pos trazabilidad)
(Mader, Gotel, and Philippow 2009).
Hace posible extender formas convencionales de
trazabilidad de requisitos basada en artefactos.
En su propuesta presentan dos tipos de requisitos:
1. Basados en artefactos
2. Basados en el persona
3. Participante
Fig. 2. Dos tipos básicos de los requisitos de trazabilidad (Mader et al. 2008)
Los artefactos y el personal participante crean una
"estructura de contribución" para realizar la práctica
de la trazabilidad, que consiste en hacer trazabilidad
de requisitos basada en las contribuciones que hacen
los participantes a los artefactos producidos en el
proceso de ingeniería de requisitos (Mader, Gotel,
and Philippow 2009).
En la semántica asociada a dicha estructura es
posible encontrar dos vínculos de trazado entre los
artefactos de un modelo de desarrollo: adopta para
indicar las relaciones basadas en artefactos que son
típicamente mantenidas para la trazabilidad de
requisitos; referencia para indicar las relaciones ba-
sadas en artefactos que proporcionan información
más allá del contexto básico (Tabares et al. 2007).
Se definen también para los participantes tres roles
de responsabilidad con respecto a un artefacto:
1. Autor (responsable original).
2. Principal (responsable corriente).
3. Documentador.
Esto ayudará posteriormente a verificar la
colaboración entre los participantes y sus roles en el
trazado.
3.3. Modelo de Ramesh-Jarke.
En "Towards reference models for requirements
traceability y Factors Influencing Requirements
Traceability Practice", estos autores muestran un
estudio donde el problema de la trazabilidad depende
de los diferentes contextos acerca de la adopci6n, use
de los requisitos y usuarios (Ramesh and Jarke 2001).
A partir de él se crea el metamodelo de trazabilidad y
se diferencian dos tipos de usuarios de trazabilidad
de "bajo perfil (low-end)" y de "alto perfil (high-
end)".
El metamodelo representa los tres aspectos más
importantes para la práctica de la trazabilidad
(Tabares et al. 2007):

33
1. Las fuentes
2. Los participantes (stakeholder)
3. Los objetos para ser trazados.
La semántica asociada a los vínculos de trazado
(trace_to, has_role_in, etc.) está dada por: Object
traces to Object, Stakeholder has role in Object,
Stakeholder manages Source y Source documents
Object. (Ramesh and Jarke 2001), como se muestra
en la Figura 3.
Fig. 3. Semántica asociada a los vínculos de
trazado (Ramesh 1998)
3.4. Modelo de Letelier, Anaya.
En "SmarTTrace: Una herramienta para trazabilidad
de requisitos en proyectos basados en UML" y en
"Entregando especificaciones textuales y elementos
de modelado UML en un marco de trabajo para
trazabilidad de requisitos", afirman que la
trazabilidad de requisitos es un proceso clave para la
exitosa gestión de los requisitos de un sistema de
información. A pesar de ello, no existe un consenso
acerca de los tipos de especificaciones y enlaces entre
estos que deben usarse en un proceso de trazabilidad
(Letelier 2002). Además, a pesar de la existencia de
herramientas específicas para la gesti6n de
requisitos, estas no proceden mecanismos adecuados
para la configuración de la trazabilidad de acuerdo
con las necesidades específicas del proyecto
(Tabares et al. 2007).
El autor presenta un modelo de SmarTTrace, que es
una herramienta que aprovecha los mecanismos de
extensión proporcionados por la CASE Rational
Rose para incorporar a esta las tareas de
configuración, especificación y explotación de
trazabilidad en un proceso de desarrollo.
Para ilustrar la funcionalidad de SmarTTrace como
se muestra en la Figura 4, respecto a dichas tareas se
ha propuesto un pequeño ejemplo basado en el
proceso Rational Unified Process (Anaya and
Letelier 2002).
Fig. 4. SmarTTrace una herramienta para la
trazabilidad de requisitos (Anaya and Letelier 2002a)
3.5. Modelo de Egyed
En "A scenario-driven approach to trace dependency
analysis y Resolving uncertainties during trace
analysis", explica que el objetivo del modelo para la
trazabilidad de requisitos es producir información de
trazabilidad generada entre los sistemas de software
y sus modelos. Está basado en la observación de
escenarios de prueba que son ejecutados durante la
prueba de un sistema de software (Egyed 2003).
A partir de dicha observación se establecen vínculos
de trazado entre los elementos de modelos (clase y
flujos de datos) y su correspondiente c6digo fuente
(el sistema) (Egyed 2004).
El modelo está orientado a manejar tipos de trazado
entre escenarios y el sistema; elementos de los
modelos y el sistema; escenarios y elementos de los
modelos; elementos de los modelos y elementos
similares; entre los mismos elementos de los
modelos; entre conjuntos de elementos del modelo,
posibles inconsistencias y completitud (Egyed
2003).
Además, provee tres dependencias de traza:
hipotetizada, generada y observada, como se muestra
en la Figura 5 (Tabares et al. 2007).

34
Fig. 5. Elemento de Modelo orientado ha trazado
entre escenarios y el sistema (Egyed 2001)
3.6. Enterprise Architect
La trazabilidad es un medio de captura y
dependencia de las relaciones de los requisitos para
la aplicación de un modelo de desarrollo de
Software, por medio de vínculos de realización, Por
ejemplo un proceso de negocio requerirá algunas
funcionalidades del sistema (casos de uso), para
implementar las funciones de proceso. Esto permite
capturar esta información mediante enlaces
realización(Architect 2010).
Cuando se usa diagramas de análisis asociados a los
procesos, casos de uso, clases, etc. Se puede capturar
las relaciones por medio de la realización.
La siguiente Figura 6 indica que el caso de uso
ingresar aplicación al dar inicio de sesión a los
requisitos formales y Sitio Web a su vez es
implementado por la lógica de negocios, los
componentes de páginas ASP y acceso al sitio Web
de la página.
Una vez que estas relaciones se hacen, se pueden
consultar mediante la aplicación y la dependencia,
los detalles están disponibles en el menú contextual
del Navegador de proyectos, como se muestra en la
Figura 7.
Los informes de la dependencia son similares, pero la
captura de la punta opuesta de la relación, es decir, lo
que los elementos del modelo dependen de un
elemento para la realización. Cuando se relacionan
los requisitos con los casos de uso se puede acceder a
las matrices de trazabilidad.
Fig. 6. Inicio de sesión requisitos formales (Architect 2012)
3.7. CLASIFICACION DE MODELOS
En la revisión de estado del arte de la secci6n
anterior, se presentan los modelos de trazabilidad
desde los autores, lo que permite a los ingenieros de
Software generar y taller estructuras y formas para
elaborar y generar en la práctica en un determinado
proyecto, la trazabilidad con sus respectivas
actividades fundamentales y necesarias para el ciclo
de vida.
Toda trazabilidad permite aproximaciones de
alguna u otra forma con los tres elementos básicos
para la práctica de la trazabilidad: los artefactos, los
participantes y las fuentes.
Es importante resaltar y observar los modelos más
representativos de trazado, que permiten orientar y
conocer la forma y estructura de llevar a cabo el
proceso de trazado, según se muestra en la Tabla 1.

35
Modelo
Características de Verificación de Consistencias y Completitud
Consistencia Completitud Mecanismo
Lindvall, (1996, 1998)
Niveles de abstracción:
 El dominio
 El análisis
 El diseño
Niveles de abstracción:
 El dominio
 El análisis
 El diseño
1. Trazabilidad hacia a
delante (forward) y hacia
atrás (backward), vertical y
horizontal.
2. Determina como se realiza
el trazado: por vínculos
explícitos, por referencia,
por nombr e o por la
e x p e r i e n c i a del
desarrollador.
Gotel et al, (1994,2008)
Pre-RS traceability y Post-RS
Traceability
Pre-RS traceability y Post-RS
Traceability
En su propuesta presentan dos
tipos de requisitos:
 Basados en artefactos
 Basados en el personal parti-
cipante.
Los artefactos y el personal
p a r t i c i p a n t e c r e a n u n a
"estructura de contribución".
Ramesh et al, (1998,2001)
Metamodelo para dos tipos de
usuarios trazabilidad de "bajo
perfil (low-end)" y de "alto perfil
(high-end)". El metamodelo
representan:
1. Las fu entes
2. Los p a r t i c i p a n t e s
(stakeholder)
Los objetos para ser trazados
Metamodelo para dos tipos de
usuarios trazabilidad de "bajo
perfil (low-end)" y de "alto perfil
(high-end)". El metamodelo
representan:
1. Las fu entes
2. Los p a r t i c i p a n t e s
(stakeholder)
Los objetos para ser trazados
La semántica asociada a los
vínculos de trazado (trace_to,
has_rolein, etc.) está dada por:
Object traces_to Object,
Stakeholder has_rolein Object,
Stakeholder manages Source y
Source documents Object
Letelier, Anaya (2002)
Metamodelo basado en UML Metamodelo basado en UML
Para la práctica de la trazabilidad
definen entidades y vínculos de
trazado. Traceable Specification
permite cubrir las cuatro perspectivas
de información de
trazabilidad:
Requisitos (Requirement
Specification), fundamentos
(Rationale Specification), asignación
de requisitos a artefactos de los
modelos de desarrollo
(OtherUML_ Specification) y pruebas
(TestSpecification).
Egged
(2003, 2004, 2005, 2006)
Definici6n de las trazabilidad
hipotéticas excesivas.
Genera reglas de Consistencia
estáticas y determinísticas.
Definición de las trazabilidad
hipotéticas excesivas.
Genera reglas de Consistencia
estáticas y determinísticas.
1. Si un elemento del modelo es
exactamente alguna huella de
trazado (en el código), entonces
S e r e c o n o c e q u e
traza a dicha huella de trazado y
no a otra.
2. El alcance de una regla de
consistencia está completo al
contener subcondiciones
AND/OR que influencian como
y si los elementos de modelo
son accedidos.
Enterprise Architect
Relación de los requisitos con
los casos de uso (matrices).
Relación de los requisitos con
los casos de uso (matrices).
Generar informes de la
dependencia con base en la
captura contenida en relación, es
decir, lo que los elementos del
m o d e l o d e p e n d e n d e u n
elemento para la realización

36
4. CONCLUSIONES
Es fundamental identificar las diferentes
características, elementos y comportamientos que
requiere un modelo de trazabilidad para así poder
garantizar y generar las transversalidad en diferentes
niveles de abstracción.
Hay que tener presente la estructura y el
comportamiento de los modelos de trazado para
poder definir un mecanismo y lograr la verificación
de la consistencia y la completitud.
La trazabilidad de requisitos facilita en un proyecto
de Software, patrones dinámicos con el propósito de
generar criterios de calidad, basados en diagramas de
UML, en especial los Casos de Usos.
Es importante realizar la práctica de la trazabilidad
en un proyecto de desarrollo de software, partir
pensando en los factores que influyen el trazado
como la complejidad, el nivel de especificación de
los requisitos, el levantamiento y análisis de
requisitos, el lenguaje de modelado utilizado, las
pruebas y validación, los niveles de abstracción,
lenguaje de representación utilizado en los modelos,
la codificación, la gestión de cambios, entre otros.
5. REFERENCIAS
Aguilar-Calderon, Jose Alfonso, Irene Garrigos, and Jose
Norberto Mazon. 2010. "Modelo de Requisitos Y Modelo
de Dominio, Trazabilidad Mediante Modelos de
Weaving."
Anaya, Víctor, and Patricio Letelier. 2002a. "SmartTrace:
Una Herramienta Para Trazabilidad de Requisitos En
Proyectos Basados En UML." Pp. 210-24 in WER.
Anaya, Víctor, and Patricio Letelier. 2002b. "Trazabilidad
de Requisitos Adaptada a Las Necesidades Del Proyecto:
Un Caso de Estudio Usando Alterativamente RUPYXP."
Architect, Enterprise. 2010. "Sparx Systems."
Architect, Enterprise. 2012. "Disponible Online:
http://www.sparxsystem.com." Consultada el 25.
Boehm, Barry W. 1984. "Verifying and Validating
Software Requirements and Design Specifications." in
IEEE software.
Boehm, Barry W. 1987. "Improving Software
Productivity." in Computer.
Drivalos, Nikolaos, Dimitrios S. Kolovos, Richard F.
Paige, and Kiran J. Fernandes. 2009. "Engineering a DSL
for Software Traceability." Pp. 151-67 in Software
Language Engineering. Springer.
Egyed, Alexander. 2001. "A Scenario-Driven Approach to
Traceability." Pp. 123-32 in Proceedings of the 23rd
international conference on software engineering.
Egyed, Alexander. 2003. "A Scenario-Driven Approach to
Trace Dependency Analysis." Software Engineering,
IEEE Transactions on 29(2):116-32.
Egyed, Alexander. 2004. "Resolving Uncertainties during
Trace Analysis." Pp. 3-12 in ACM SIGSOFT Software
Engineering Notes, vol. 29.
Glinz, Martin. 2007. "On Non-Functional Requirements."
Pp. 21-26 in Requirements Engineering Conference,
2007. RE'07. 15th IEEE International.
Gotel, Orlena C. Z., and Anthony C. W. Finkelstein. 1994.
"An Analysis of the Requirements Traceability Problem."
Pp. 94-101 in Requirements Engineering, 1994.,
Proceedings of the First International Conference on.
IEEE. 2006. "610.12-1990 - The IEEE Standards
A s s o c i a t i o n
http://standards.ieee.org/findstds/standard/610.12.
ISO for Standardization, International Organization. 1994.
ISO 8402: 1994: Quality Management and Quality
Assurance-Vocabulary. International Organization for
Standardization.
Letelier, Patricio. 2002. "A Framework for Requirements
Traceability in UML-Based Projects." Pp. 30-41 in
Proceedings of the 1st International Workshop on
Traceability in Emerging Forms of Software Engineering.
Lindvall, Mikael, and Kristian Sandahl. 1996. "Practical
Implications of Traceability." Softw., Pract. Exper.
26(10):1161-80.
Lindvall, Mikael, and Kristian Sandahl. 1998.
"Traceability Aspects of Impact Analysis in Object-
Oriented Systems." Journal of Software Maintenance:
Research and Practice 10(1):37-57.
Mader, P., Orlena Gotel, and Ilka Philippow. 2008.
"Enabling Automated Traceability Maintenance by
Recognizing Development Activities Applied to Models."
Pp. 49-58 in Proceedings of the 2008 23rd IEEE/ACM
International Conference on Automated Software
Engineering.
Mader, P., Orlena Gotel, and Ilka Philippow. 2009. "Semi-
Automated Traceability Maintenance: An Architectural
Overview of trace MAINTAINER." Pp. 425-26 in
Software Engineering-Companion Volumen, 2009. IC SE-
Companion 2009. 31st International Conference on.
Mader, Patrick, Orlena Gotel, and Ilka Philippow. 2009.
"Enabling Automated Traceability Maintenance through
the Upkeep of Traceability Relations." Pp. 174-89 in
Model Driven Architecture-Foundations and Applications.

37
Montoya Suarez, Lina María. 2013. Levantamiento de Un
Estado Del Arte Para La Trazabilidad de Requisito En El
Desarrollo de Software.
Moore, James W. 1998. Software Engineering Standards.
Wiley Online Library.
Oman, Paul, and Jack Hagemeister. 1992. "Metrics for
Assessing a Software System's Maintainability." Pp.
337-44 in Software Maintenance, 1992. Proceerdings.,
Conference on.
Pressman, Roger S. 2006. Engenharia de Software.
McGraw Hill Brasil.
Ramesh, Balasubramaniam. 1998. "Factors Influencing
Requirements Traceability Practice." Communications of
the ACM 41(12):37-44.
Ramesh, Balasubramaniam, and Matthias Jarke. 2001.
"Toward Reference Models for Requirements
Traceability." Software Engineering, IEEE Transactions
on 27(1):58-93.
Sommerville, Ian. 2005. "Integrated Requirements
Engineering: A Tutorial." Software, IEEE 22(1):16-23.
Tabares, Marta Silvia, Andres Felipe Barrera, Juan David
Arroyave, and Juan Diego Pineda. 2007. "Un método para
la trazabilidad de requisitos en el proceso unificado de
desarrollo." revista EIA (8).

MODELOS_DE_TRAZABILIDAD_DE_REQUISITOS_PA.pdf

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Similar a MODELOS_DE_TRAZABILIDAD_DE_REQUISITOS_PA.pdf

Similar a MODELOS_DE_TRAZABILIDAD_DE_REQUISITOS_PA.pdf (20)

Más de Rebeca Ortega

Más de Rebeca Ortega (16)

MODELOS_DE_TRAZABILIDAD_DE_REQUISITOS_PA.pdf