Link-up the requirements and testing

RACCIS 4(2), pp. 39-46 (2014)
Revista Antioqueña de las
Ciencias Computacionales y la Ingeniería de Software
ISSN: 2248-7441
www.fundacioniai.org/raccis
[email protected]
Link-up the requirements and testing - How much progress has been made?
Vinculación entre requisitos y pruebas - ¿Qué tanto se ha avanzado?
Marc Luisiana1, Alissa Murthor2
BORLAND. luisianamarc(AT)borland.com1, murthoralissa(AT)borland.com2
INFORMACIÓN DEL ARTÍCULO
Tipo
Revisión
Historia
Recibido: 23-07-2014
Correcciones: 09-09-2014
Aceptado: 15-10-2014
Keywords
Requirements Engineering, software
quality, functional testing, software
errors.
Palabras clave
Ingeniería de Requisitos, calidad del
software,
pruebas
funcionales,
errores del software.
ABSTRACT
In Requirement Engineer are conducted two fundamental process of software engineer: 1)
specification of system expectations, and 2) tests to ensure that they are fulfil. Giving its
importance to product quality and efficient develop is crucial they are aligned. In literature
can be found a wide investigation in both fields, but scarce the works about how link them. In
this work is presented a study with the goal of mapping this situation, and to identify useful
approaches to future research. Over 100 jobs found only 35 were considered relevant to make
them a discussion in the light of the sub-categories of models based on evidence and
traceability.
RESUMEN
En la Ingeniería de Requisitos se llevan a cabo dos procesos fundamentales de la Ingeniería
de Software: 1) la especificación de las expectativas del sistema, y 2) las pruebas para
garantizar que se cumplan. Dada su importancia para la calidad del producto y el desarrollo
eficiente es crucial que estén alineados. En la literatura se puede hallar una amplia
investigación en ambos campos, pero escasean los trabajos acerca de cómo vincularlos. En
este trabajo se presenta un estudio con el objetivo de mapear esta situación, y para identificar
enfoques útiles y necesidades para la investigación futura. De más de 100 trabajos
encontrados sólo 35 se consideraron relevantes para hacerles una discusión a la luz de las
sub-categorías de modelos basados en pruebas y en trazabilidad.
© 2014 IAI. All rights reserved.
1. Introducción
Con la creciente demanda por el mejoramiento de la
calidad del software, la necesidad y la importancia de las
pruebas se ha hecho más evidente en los últimos años. Para
los sistemas de seguridad crítica, como las misiones
espaciales, el diagnóstico médico, y la aviación, las pruebas
son un aspecto crucial para su éxito porque los errores
pueden causar pérdidas irreparables. Por otro lado, la
Ingeniería de Requisitos (RE) representa una visión
complementaria de un sistema y por lo tanto tiene una
relación sinérgica con las pruebas [1]. Por lo tanto, acercar
la RE y las pruebas podría ser de amplio beneficio para
ambas disciplinas y para el mejoramiento de la calidad del
software [2]. También ayudaría a descubrir posibles
errores en las etapas tempranas, lo que a su vez mejoraría
la fiabilidad del producto y los clientes estarían más
satisfechos [3, 4]. Desde la perspectiva de la gestión de
proyectos, la vinculación de los requisitos y las pruebas
permitiría estructurar planes de prueba más precisos, lo
que se reflejaría en el costo del proyecto y en la estimación
del calendario. De esta forma, probablemente el proyecto
se termine dentro de la programación y el presupuesto
planificado [1].
Aunque la industria está cada vez más interesada en lograr
esta vinculación, a menudo en las prácticas de RE no lo
logra y cada vez se amplía la brecha entre ellos. Es
llamativo que en estos esfuerzos la atención se ha centrado
principalmente en los requisitos funcionales más que en
los no-funcionales; en parte porque los primeros juegan un
papel significativo en el éxito de los proyectos, aunque
Grunske [5] establece que a menudo el cumplimiento de
los segundos es más importante para tener un cliente
satisfecho; y Matoussi y Laleau [6] señalan que la
verificación de estos requisitos casi siempre se hace muy
tarde, después de terminar la aplicación. El objetivo en este
trabajo es realizar un mapeo sistemático acerca de lo que
se propone en la literatura para alinear la especificación de
requisitos y las pruebas, con el propósito de presentar una
visión general de la investigación en esta área.
Entre los trabajos encontrados acerca de esta temática se
presta amplia atención a esta trazabilidad, porque puede
ayudar a determinar qué requisito ha sido cubierto por
cuál prueba y cómo los casos de prueba generados cubren
estos requisitos [6]. Rastrear los resultados de las pruebas
a los requisitos también es útil para encontrar la causa de
una prueba fallida. Otra razón importante es que la
trazabilidad mejora la gestión del cambio, ayudando a
descubrir cómo se refleja en un requisito al aplicar los
casos de prueba. También ha llamado la atención la
investigación en áreas como el desarrollo basado en
39
modelos y la arquitectura basada en modelos [7], porque
son técnicas que están logrando la curiosidad de la
industria porque proporcionan derivación automática de
casos de prueba a partir del modelo de comportamiento
del sistema, llamado modelo de prueba.
Esta investigación presenta un mapeo sistemático, que,
como Petersen et al. [8] describen, consiste en una visión
general de los estudios primarios realizados sobre un tema
específico y la categorización de los resultados,
proporcionando un resumen visual. Como tal, un mapa
sistemático ofrece una visión general de un campo
identificando posibles lagunas en la investigación,
mientras que una revisión sistemática de la literatura
proporciona un estudio más detallado de los resultados
identificados [9]. El proceso del mapeo consiste de cinco
fases [8]: 1) definición de las preguntas de investigación,
2) realización de la búsqueda de los estudios primarios, 3)
proyección de artículos para inclusión/exclusión, 4)
clarificación de los resúmenes, y 5) extracción y mapeo de
los datos.
2. Método de investigación
1. Definición de las preguntas de investigación. Para buscar
las investigaciones existentes sobre la alineación de
especificación de requisitos y las pruebas se
formularon las siguientes preguntas de investigación:
P1. ¿Qué estudios se han realizado acerca de la
vinculación de la especificación de requisitos y las
pruebas? El objetivo es conocer: qué temas han sido
investigados y en qué medida; cuáles de estos
estudios se centran en requisitos no-funcionales; y
cuáles son las diferentes perspectivas que abordan
la alineación, por ejemplo, qué enfoques de prueba
se utilizan. Esto ayudaría a identificar necesidades
de investigación complementaria.
P2. ¿Qué tipo de soluciones se representan en estas
investigaciones? La idea es encontrar las soluciones
dadas en las diferentes formas que abordan la
alineación, como método, proceso, marco,
herramienta, etc.
P3. ¿De qué forma se divulga la investigación acerca de
la alineación la especificación y las pruebas? Una
visión general sobre las formas que utilizan los
investigadores para publicar resultados también
podría ayudar con esta investigación.
2. Búsqueda de estudios primarios. Para llevar a cabo la
búsqueda se requería obtener una visión general de las
áreas de especificación de requisitos y de pruebas y de
su alineación. Para lograrlo se reunió un conjunto
inicial de publicaciones conocidas previamente a través
de una búsqueda exploratoria [1, 3-5, 10-15].
Posteriormente se amplió este conjunto utilizando la
referenciación de los trabajos, es decir, mirando cuáles
de los trabajos de la muestra fueron referenciados en o
se refieren a. Se encontraron 24 trabajos que ayudaron
a explorar y elegir palabras clave relevantes para el
mapeo sistemático. Desde las preguntas de
investigación y con base al estudio inicial se derivaron
algunas categorías para la realización de la cadena de
búsqueda: C1, requisitos no-funcionales (NFR); C2,
especificación de NFR; C3, pruebas de NFR; y C4,
vinculación de la especificación y las pruebas de NFR.
Posteriormente se formuló una combinación de las
categorías para llegar a la cadena de búsqueda: (C1 ˄
C2 ˄ C3 ˄ C4).
En la línea de tiempo se decidió cubrir todas las
investigaciones en los últimos 10 años, y se limitó a
documentos escritos en inglés. Las bases de datos
seleccionadas fueron Scopus, Inspec Ingeniería Village,
ISI Web of Knowledge, e IEEE Xplore. Luego se hizo un
refinamiento incremental de la cadena de búsqueda en
cinco pasos. En cada uno se registraron los resultados
para ver si contenían documentos del conjunto inicial;
en el caso que perteneciera a éste se desechaba y se
mejoraba nuevamente la cadena de búsqueda. Un
refinamiento importante fue la eliminación de la
categoría C2 de la cadena, porque muchos artículos en
el conjunto inicial no incluían el término especificación
en su título o resumen. Al encontrar pocos resultados
en NFR se decidió tomar algunas ideas desde la
alineación de requisitos y las pruebas en general. Así
que se añadió otra categoría C5 con el ítem requisito, y
se modificó la cadena de búsqueda a ((C1 ˅ C5) ˄ C3 ˄
C4). Después de la iteración final del refinamiento de la
cadena de búsqueda se alcanzaron 438 resultados.
3. Proyección de artículos para inclusión/exclusión. En esta
fase se definieron los criterios de inclusión y exclusión
a fin de lograr un entendimiento común entre los
miembros del equipo para realizar la proyección. El
proceso de selección se realizó en dos pasos: 1) se
consideraron el título y el resumen de todos los
documentos. Los principales criterios de inclusión
fueron: trabajos que describen la alineación de la
especificación de requisitos funcionales o nofuncionales y las pruebas. Se excluyeron trabajos en
congresos y artículos que no se centraran en el
desarrollo de software. En el proceso, si un
investigador no estaba seguro acerca de la exclusión de
un artículo, se dejaba para el segundo paso. Se
excluyeron 395 documentos en este paso. 2) Se hizo
una lectura completa a los documentos restantes. Se
excluyeron posters, artículos de opinión personal del
autor sobre lo que es bueno o malo [16], y trabajos
cortos (menos de 6 páginas). Los trabajos sólo se
incluyeron si habían sido objeto de revisión por pares.
Si los investigadores no estaban de acuerdo sobre la
inclusión o exclusión de algún trabajo se discutía hasta
llegar a una decisión por consenso. Se excluyeron 8
documentos en este paso. Al final, el número de
trabajos en la muestra se redujo a 35.
4. Clarificación de los resúmenes. En esta fase se desarrolló
el formulario de extracción de datos, en parte basado
en el utilizado por Ivarsson y Gorschek [17]. Para
construir esta forma se buscaron, a través del análisis a
los resúmenes, palabras y conceptos como contexto y
40
dominio, y para lograrlo se leyeron los documentos en
detalle. Utilizando las palabras clave finalmente se
seleccionaron los siguientes atributos: enfoque de la
investigación, tipo de contribución, calidad de los
resultados, dominio, y escala.
5. Extracción y mapeo de datos. A la medida que se
estudiaba el texto completo de los documentos también
se llenó el formulario de extracción de datos para cada
uno, y con el análisis a los mismos se respondió a las
preguntas de investigación.
3. Resultados
3.1 Para responder a P1 se hizo una clasificación de los
documentos y se encontraron las siguientes áreas y
sub-áreas de trabajo:
 Modelos basados en pruebas. Esta área es en la que
se encuentra mayor producción en la muestra, y los
requisitos informales son la base para el desarrollo
del modelo de comportamiento del sistema. Este
modelo se utiliza para generar casos de prueba
automáticamente. Uno de los problemas es que las
pruebas generadas no se pueden ejecutar
directamente en la implementación bajo prueba,
porque están en el mismo nivel de abstracción que
el modelo. Arnold, Corriveau y Wei abordan este
problema [18] y proponen una solución, además,
sostienen que su enfoque basado en escenarios
soporta la trazabilidad entre los casos de prueba
generados y los ejecutados. Este enfoque es
compatible con requisitos funcionales y nofuncionales.
Otras propuestas son la de Goel, Sengupta y
Roychoudhury [19], quienes proponen un enfoque
orientado a modelos en el que se combinan las
fortalezas de los estilos de modelado basados en
escenarios y los basados en el estado. Footprinter es
una herramienta que hace posible rastrear desde
los requisitos hasta las pruebas y viceversa en un
enfoque de ingeniería de ida y vuelta. El marco
propuesto por Tasi et al [20] para pruebas basadas
en escenarios se compone de scripts de prueba y
casos de prueba, generados automáticamente, con
base a un escenario de especificación para el
componente principal de prueba. Algunas
investigaciones desarrollan procesos basados en
modelo orientados a las pruebas, es el caso de
Pfaller et al [21] quienes utilizan diferentes niveles
de abstracción en el proceso de desarrollo para
derivar casos de prueba y vincularlos con las
correspondientes necesidades de los usuarios;
Boulanger y Dao [22] proponen un enfoque en el
que la RE se realiza en diferentes fases del modelo
en V, con el fin de facilitar la validación y la
trazabilidad de requisitos; Lobo y Arther [23]
desarrollan un proyecto que tiene como objetivo
reducir la brecha entre la RE y el proceso de V&V, lo
que logran aplicándolo en un modelo de dos fases:
1) se lleva a cabo justo después de la elicitación de
requisitos para cada función específica del sistema,
y 2) se verifica y valida la calidad de los vínculos
entre las series de requisitos.
Otros estudios parten de pruebas basadas en el
modelo de sistemas orientados al servicio, como el
de Felderer et al [7], quienes están convencidos de
que la herramienta que proponen podría apoyar la
trazabilidad entre todo tipo de modelos y sistemas;
el marco propuesto por Tasi et al [20] también tiene
como objetivo las pruebas de servicios web. Hay
otros enfoques, como el de Marelly Harel y Kugler
[24], que extienden secuencias de cartas con
instancias y variables simbólicas con el fin de
enlazar los requisitos y las pruebas; Zou y Pavlovski
[12] proponen casos de control para complementar
los casos de uso mediante el modelado de requisitos
no-funcionales que no pueden ser abordados de
otra manera. Se pueden aplicar durante el ciclo de
vida de desarrollo de software y también para
verificar si el sistema implementado cumple con los
requisitos no-funcionales especificados.
 Desarrollo orientado a objetivos. En el modelado
orientado a objetivos el ingeniero puede darse
cuenta fácilmente de las necesidades de las partes
interesadas y de sus interdependencias, utilizando
conceptos mucho menos dependientes de la
tecnología de implementación y mucho más
cercanos al dominio del problema [25]. Los
objetivos, que pueden estar en varios niveles de
abstracción, definen las necesidades de las partes
interesadas. Cuando son estados que los actores
pueden alcanzar se conocen como difíciles, y son
fáciles cuando son metas que nunca se pueden
alcanzar plenamente. Los requisitos funcionales se
muestran como objetivos difíciles y los nofuncionales, como la eficiencia y la fiabilidad,
representan objetivos fáciles, lo que significa que se
espera cumplirlos dentro de unos
límites
aceptables pero no absolutamente [25]. Este tipo de
desarrollo mejora la productividad así como la
calidad del modelo. Nan et al [25] proponen un
marco para el rastreo de aspectos de los requisito
para la implementación y las pruebas. También
proporcionan soporte de lenguaje para transformar
los modelos en programas orientados a aspectos.
Los casos de prueba se pueden derivar de estos
modelos para ayudar en el proceso de verificación.
Las metodologías de la Ingeniería de Software
orientada a aspectos se basan en el paradigma de
agentes, y ayudan a desarrollar sistemas
distribuidos complejos [26]. También abordan
parcialmente el vínculo entre los requisitos y las
pruebas, lo que se logra mediante la verificación
formal basada en la especificación y las técnicas de
prueba orientadas a objetos. Duy, Perini y Tonella
[26] introducen un marco de pruebas para estas
metodologías llamado TROPOS, el cual proporciona
una manera sistemática de derivar los casos de
prueba a partir del análisis objetivo. Este enfoque se
41
denomina prueba orientado a objetivos. En cuanto
al desarrollo orientado a aspectos, Nan et al [25] lo
presentan como una solución
para la
transformación del modelo objetivo a la
implementación. Describen cómo se introducen los
aspectos desde el modelo y presentan un marco en
el que los aspectos pueden mantener la trazabilidad
desde el nivel de los requisitos tempranos hasta la
implementación y la prueba.
 Trazabilidad. Abbors, Truscan y Lilius [27]
presentan un enfoque para la trazabilidad de los
requisitos, a través de un proceso de modelo basado
en pruebas, y herramientas que se utilizan para cada
fase. Algunas investigaciones previas orientan las
pruebas basadas en requisitos a facilitar la
trazabilidad entre ellos y las pruebas. Mendez, Perez
y Mendoza [28] presentan un proceso de prueba
basado en requisitos y definen una guía sobre cómo
mantener la trazabilidad en el proceso desde los
requisitos tempranos hasta los casos de prueba.
Quinn et al [29] proponen un método mediante el
cual los requisitos de un componente software se
pueden especificar fácilmente en un documento de
referencia, con el fin de facilitar la trazabilidad entre
los requisitos y las pruebas. Algunas investigaciones
abordan cuestiones de trazabilidad utilizando
escenarios, como Naslavsky et al [30] quienes
consideran que diferentes tipos de escenarios son
útiles para trazar los requisitos a las pruebas a
través del ciclo de vida del desarrollo, y que cada
uno se puede utilizar como escenario de prueba;
Goel y Roychoudhury [31] estudian las cuestiones
de generación de pruebas y trazabilidad en tres
diferentes sistemas basados en escenarios
modelando lenguajes. Otras investigaciones
construyen meta-modelos para facilitar la
trazabilidad. En este sentido, y con el fin de
establecer la relación entre los componentes
software que incluyen los requisitos, los casos de
prueba de diseño, y el código, Ibrahim et al [32]
construyeron un meta-modelo con soporte de
trazabilidad top-down y bottom-up; y Dubois,
Peraldi y Lakhal [33] proponen una meta-modelo
con el objetivo de mantener el enlace de
trazabilidad de los requisitos en tres fases: la
elicitación, el diseño, y la V&V.
 Enfoques formales. Post et al [2] se centran en la
traducción de requisitos a un lenguaje formal
basado en escenarios, que a su vez podría estar
vinculado con la verificación de software. Ramo et al
[34] utilizan un sub-conjunto de diagramas UML 2.0
y lenguaje OCL para formalizar el comportamiento
esperado del sistema. El modelo es utilizado para
generar automáticamente scripts de prueba
ejecutables. Kelleher y Simonss [35] proponen un
nuevo enfoque de modelado de requisitos en el que
los casos de uso son reemplazados por clases de
casos de uso en UML 2.0. Estas clases son plantillas
formales que describen reglas con instancias sobre
los requisitos modelados. Esta sustitución, junto con
la utilización de enlaces de trazabilidad explícitos,
facilita la reducción de la brecha entre los requisitos
y las pruebas. Sabetta et al [36] discuten que a veces
puede ser necesario transformar los modelos UML
en diferentes modelos de análisis que puedan ser
utilizados para verificar, formalmente, algún tipo de
requisito no-funcional [37]. Algunos de estos
modelos son redes Petri, redes de colas, lógica
formal, etc. Para este propósito, su enfoque de
abstracción puede transformar modelos UML en
diferentes tipos de modelos de análisis con
diferentes formalismos. Hassan et al [38] se centran
en los requisitos de seguridad. Proponen el primer
enfoque de seguridad de software orientado a
objetivos, con el propósito de producir de forma
sistemática software con alto nivel de seguridad. El
modelo soporta la derivación automática de las
especificaciones en lenguaje B y un conjunto de
casos de prueba de aceptación desde el modelo de
requisitos, para garantizar una mejor alineación de
la seguridad de ellos y las pruebas. Hussain y
Eschbach [39] presentan un enfoque de análisis de
seguridad basado en modelos, que genera
automáticamente modelos formales del sistema y
produce un árbol de fallos que puede ser utilizado
para generar casos de prueba. Por lo tanto, los casos
de prueba pueden ser ligados directamente a los
requisitos de seguridad para asegurar la
trazabilidad entre las actividades de prueba y los
requisitos de seguridad.
 Enfoques centrados en el código. Mugridge [40]
presenta una propuesta de desarrollo de pruebas
orientado a historias como una forma
complementaria que se puede aplicar al desarrollo
de sistemas. Las pruebas de historias, que son
ejemplos ejecutables y orientados a negocios, son
escritas por los clientes como una alternativa para
detallar el documento de requisitos. Como
documentos ejecutables reducen significativamente
la necesidad de derivar pruebas independientes,
porque les ayudan a los desarrolladores a verificar
continuamente su compatibilidad con el sistema.
Bâillon y Mongardé [41] describen el desarrollo
orientado a comportamiento como un nuevo
paradigma con el fin de abordar los problemas de
trazabilidad. Introducen la herramienta XReq como
soporte para Ada y otros lenguajes de tipo estático.
 Buenas prácticas para la alineación. Uusitalo et al [3]
presentan un conjunto de buenas prácticas que se
pueden aplicar para crear un vínculo más fuerte
entre la Ingeniería de Requisitos y las pruebas.
Algunas involucran a los probadores durante la
planificación del proyecto y la revisión de
requisitos, lo que podría conducir a una mayor
calidad y a mejorar la capacidad de prueba.
Kukkanen et al [1] proponen un enfoque sistemático
para mejorar los procesos de los requisitos y las
pruebas además del objetivo de vincularlos.
Describen lecciones aprendidas y mejores prácticas
determinadas a partir de la aplicación de nuevos
42
procesos en un estudio de caso industrial.
Sabaliauskaite et al [42] llevaron a cabo una
encuesta en una gran empresa de software en
Suecia, con el objetivo de investigar los obstáculos y
prácticas experimentados en la adecuación de los
requisitos y las pruebas.
y la seguridad están incluidos en los requisitos de
modelado. El marco de Duy, Perini y Tonella [26]
está orientado a objetivos en los que los requisitos
no-funcionales se especifican como objetivos fáciles.
Para descubrir aspectos desde los modelos objetivo
los objetivos deben ser elicitados y categorizados
como difíciles y fáciles. En el método propuesto por
Mendez, Perez y Mendoza [28] se especifican los
casos de prueba basados en casos de uso que
permiten la trazabilidad entre las pruebas y los
requisitos funcionales y no-funcionales. En este
enfoque la tabla de casos de prueba especificados se
puede utilizar para definir los procedimientos
asociados a los requisitos no-funcionales. El metamodelo presentado por Dubois, Peraldi y Lakhal
[33] permite una trazabilidad completa de ambos
tipos de requisitos a través del proceso de
desarrollo de software. En su investigación, Sabetta
et al [36] transforman modelos UML a diferentes
tipos de modelos de análisis, como redes Petri,
redes de colas, lógica formal, etc. Cada uno podría
ser utilizado en la verificación formal de diferentes
requisitos no-funcionales. Hassan et al [38] se
centran en la alineación de los requisitos de
seguridad y las pruebas a través del apoyo de la
derivación automática de especificaciones en
lenguaje B y un conjunto de casos de prueba de
aceptación desde el modelo de requisitos. En otra
investigación, Mugridge [40] establece que tanto el
desarrollo orientado a prueba de historias como el
desarrollo orientado a pruebas dependen de
avanzadas técnicas de pruebas automatizadas,
incluidas las pruebas de los requisitos nofuncionales.
 Casos de prueba. Nebut et al [43] se concentran en
una guía para la generación automática de casos de
prueba en sistemas embebidos que se basa en
conceptos orientados a objetos. Los requisitos del
sistema se describen a través de casos de uso,
contratos, y escenarios. Si se necesita cualquier otra
información sobre los requisitos es proporcionada
por diferentes artefactos UML, como los diagramas
de secuencia. Whalen et al [44] mencionan varios
problemas en la medición de la adecuación de las
pruebas funcionales usando artefactos ejecutables.
También presentan métricas de cobertura basadas
en los requisitos formales de alto nivel. Conrad, Fey
y Sadeghipour [45] presentaron una estrategia de
generación de casos de prueba que se utiliza en una
empresa de automóviles. Siegl, Hielscher y German
[46] también están interesados en la industria
automotriz y propusieron un método para la
generación automática de casos de prueba, y otro
para la derivación de casos de prueba desde los
requisitos. Riebisch y Hubner [47] se concentran en
el primer paso de la generación de casos de prueba.
Su método utiliza una descripción en lenguaje
natural que transforma en una expresión con
sintaxis y semántica definida formalmente.
 Enfoques con soporte para requisitos no-funcionales.
El marco de validación de Arnold, Corriveau y Wei
[18] soporta el modelado y la validación automática
de requisitos funcionales y no-funcionales. El
enfoque basado en la notación de requisitos es uno
de los pocos que aborda el modelado y la validación
de ambos tipos [48]. La propuesta der Felderer et al
[7] es adecuada para probar los contratos a nivel de
servicio que se consideran como propiedades nofuncionales. En este caso, el estudio del rendimiento
3.2 Para la pregunta P2 se construyó una base de datos en
la que se detallan los tipos de investigación y los tipos
de contribución encontrados. La Tabla 1 muestra un
mapa de la cantidad de trabajos, la focalización de la
investigación, y la alineación de la especificación de
requisitos y las pruebas. Cabe señalar que un trabajo
puede proporcionar múltiples contribuciones, por
ejemplo, ser una herramienta y un método.
Tabla 1. Mapa de los resultados
Tipo de investigación
Propuestas de
solución
8
6
1
12
3
1
Investigación
evaluativa
1
1
1
2
2
Enfoque de
investigación
Formal
Trazabilidad
Centrado en código
Centrado en modelos
Casos de prueba
Buenas prácticas
Tipo de contribución
Método
Proceso
Herramienta
6
3
2
5
1
1
2
2
3
2
5
1
3.3 Para la pregunta P3 se encontró que la mayoría de
investigaciones se divulga en conferencias y talleres
(80%). Esto llama la atención porque al parecer los
investigadores prefieren presentar sus resultados
ante una comunidad que los retroalimenta
inmediatamente, y no esperar al proceso de
publicación en alguna revista.
2
1
Guía
Marco
1
1
1
Métrica
3
1
6
1
2
Modelo
2
1
4. Discusión
Existen varios desafíos en el uso de los modelos orientados
a pruebas para alinear los requisitos y las pruebas a los que
los investigadores han tratado de hacerles frente. Uno es
estructurar casos de prueba ejecutables, ya que las
pruebas no están al mismo nivel de detalle que el código de
implementación [18, 48], y otro es diseñar casos de prueba
43
exitosos, es decir, que cubran los requisitos y que tengan
altas probabilidades de descubrir errores potenciales [21].
La trazabilidad de requisitos en el proceso de estos
modelos es otro tema importante, y es el foco de varias
investigaciones como [7, 21, 31] que se focalizan
principalmente en la trazabilidad de los requisitos
funcionales, mientras que para los no-funcionales queda
abierta a nuevas investigaciones [27]. Algunas se orientan
al uso de los modelos en sistemas orientados a servicios [7,
20], o al uso de la notación de escenarios para la
especificación de los modelos del sistema [18, 20, 31, 48].
El enfoque en temas de trazabilidad también es concebible
ya que ayuda a determinar el grado de cobertura de los
casos de prueba a los requisitos y mejora la gestión del
cambio, que es de vital importancia para la industria. Como
Abbors, Truscan y Lilius mencionan [27], la trazabilidad
reduce el tiempo necesario para la depuración de la
especificación o la implementación del sistema, ofreciendo
evaluaciones rápidas.
Los enfoques formales también son de interés para la
investigación, y se utilizan para traducir requisitos
informales a modelos formales para generar pruebas
formales, y para rastrear entre los requisitos informales y
la pruebas [31]. La aplicación de métodos formales para
alinear los requisitos y las pruebas tiene algunas ventajas
y desventajas. En este enfoque los requisitos se formulan
en una representación precisa, comprobable, y correcta,
que es inequívoca y coherente [37]. Esto hace de los
métodos formales una de las mejores opciones para la
elaboración de modelos y pruebas para los sistemas
complejos y de seguridad crítica. Por otra parte, el uso de
métodos formales es difícil para los profesionales [37]. Las
personas con experiencia en este campo son difíciles de
conseguir y costoso de emplear, y su aplicación,
especialmente para sistemas complejos, es difícil debido a
su alto costo y escalabilidad limitada. Algunos
investigadores han iniciado el proceso de romper estas
dificultades, como el profesor Serna en Colombia [49-52],
pero hay espacio para más investigaciones que puedan
potencializar las ventajas de los métodos formales y
hacerlos más fáciles de aprender y aplicar, y para buscar la
alineación de los requisito y las pruebas.
En cuanto al tipo de investigación, en todas las áreas el
enfoque es proponer alguna solución. Esto significa que los
desafíos en cada una se conocen bien, pero las soluciones
propuestas son muy pequeñas y se quedan sólo en mostrar
el uso actual y en evaluar lo que se publica. Sólo la mitad de
los trabajos han evaluado sus ideas en estudios de casos
industriales, pero la validez de la discusión es pobre,
porque se mencionan las amenazas sin una discusión
detallada. Además, la mayoría de las búsquedas no son lo
suficientemente maduras para ser publicadas en revistas,
por lo que el 80% de las investigaciones en esta revisión
se publicaron en conferencias y talleres. Con todo y que la
alineación de los requisitos y las pruebas parece ser una
área bastante inmadura, todavía se tiene la necesidad de
un mayor trabajo práctico.
El tipo de contribución es principalmente métodos (31%),
herramientas (24%), y marcos (14%). Se necesita
presentar nuevas metodologías o mejorar las existentes
para establecer un fuerte vínculo entre los requisitos y las
pruebas. Con el fin de que sean prácticos en la industria se
deben construir herramientas y marcos de soporte. Esto se
espera lograr muy pronto, porque los resultados muestran
que el interés de los investigadores por hacerlo se ha
incrementado en los años recientes. Otro punto
importante es que la mayoría de los esfuerzos por alinear
los requisitos y las pruebas han sido en requisitos
funcionales, y se descuida ampliamente a los nofuncionales desconociendo la importancia de éstos en los
sistemas complejos actuales.
5. Conclusiones
Este trabajo presenta un mapeo sistemático acerca de la
alineación de la especificación de requisitos funcionales o
no-funcionales y las pruebas. Se identificaron 35 trabajos
que aportan para responder a las preguntas de
investigación: 1) ¿Qué estudios se han realizado acerca de
la vinculación de la especificación y la prueba de
requisitos? 2) ¿Qué tipo de soluciones se representan en
estas investigaciones? Y 3) ¿De qué forma se divulga la
investigación acerca de la alineación de la especificación y
las pruebas?
Para responder a 1 se trabaja en enfoques centrados en el
modelo, en el código, en la trazabilidad, métodos formales,
en casos de prueba, en problemas, y en un conjunto de
buenas prácticas. El enfoque principal es en modelos
basados en pruebas y en trazabilidad. En respuesta a 2, el
tipo de contribución es en su mayoría métodos (26%) y
herramientas (24%), seguidos de marcos (14%). En
respuesta a 3, la mayor parte de la investigación se ha
publicado en conferencias y talleres (80%), y muy poco en
capítulos de libro y revistas científicas.
Aunque la industria está cada vez más interesada en
establecer un fuerte vínculo entre los requisitos y las
pruebas, aún existe una brecha significativa en estas áreas.
Esto muestra un alto potencial para trabajo futuro en el
establecimiento de métodos y procesos con herramientas
de soporte. Los enfoques actuales han prestado poca
atención a los requisitos no-funcionales, aunque juegan un
papel fundamental en la consecución de sistemas software
de calidad. Como tal, esta área tiene un alto potencial para
futuras investigaciones.
Referencias
[1]
[2]
[3]
[4]
Kukkanen, J. et al (2009). Applying a systematic approach
to link requirements and testing: A case study. Proceedings
Asia-Pacific Software Engineering Conference (APSEC), pp.
482-488. December 1-3, Penang, Malaysia.
Post, H. et al (2009). Linking functional requirements and
software verification. Proceedings 17thIEEE International
Requirements Engineering Conference (RE), pp. 295-302.
August 31-September 4, Atlanta, USA.
Uusitalo, E. et al (2008). Linking requirements and testing
in practice. Proceedings 16th IEEE International
Requirements Engineering Conference, pp. 265-70.
September 8-12, Catalunya, Spain.
Serna M.E. (2014). Model to Develop and Manage
Requirements Engineering –MoDeMaRE–. In press.
44
[5]
[6]
[7]
[8]
[9]
[10]
[11]
[12]
[13]
[14]
[15]
[16]
[17]
[18]
[19]
[20]
[21]
Grunske, L. (2008). Specification Patterns for probabilistic
quality properties. Proceedings 30th International
Conference on Software Engineering (ICSE 2008), pp. 3140. May 10-18, Leipzig, Germany.
Matoussi, A. & Laleau, R. (2008). A Survey of non-functional
requirements in software development process. Technical
report TR-LACL-2008-7. Laboratory of Algorithms,
Complexity and Logic (LACL), University of Paris, France.
Felderer, M. et al (2010). A tool-based methodology for
system testing of service-oriented systems. Proceedings
Second International Conference on Advances in System
Testing and Validation Lifecycle (VALID), pp. 108-13.
August 22-27, Nice, France.
Petersen, K. et al (2008). Systematic mapping studies in
software engineering. Proceedings 12th International
Conference on Evaluation and Assessment in Software
Engineering (EASE), pp. 68-77. June 26-27, Bari, Italy.
Serna, M.E. (2014). Methodology for perform reliable
literature reviews. In press.
Chung, L. & Prado, J. (2009). On Non-functional
requirements in Software Engineering. In Alexander, T. et al
(Eds.), Proceedings Conceptual Modeling: Foundations and
Applications, pp. 363-379. Springer-Verlag.
Agnes, M.; Frati, P. & Albinet, A. (2010). Requirement
traceability in safety critical systems. Proceedings of the 1st
Workshop on Critical Automotive applications: Robustness
and Safety, pp. 11-14. April 28-30, Valencia, Spain.
Zou, J. & Pavlovski, C. (2008). Control cases during the
software development life-cycle. Proceedings IEEE
Congress on Services Part 1 (SERVICES-1), pp. 337-344. July
6-11, Honolulu, USA.
Metsa, J.; Katara, M. & Mikkonen, T. (2007). Testing nonfunctional requirements with aspects: An industrial case
study. Seventh International Conference on Quality
Software (QSIC'07), pp. 5-14. October 11-12, Portland, USA.
Romano, B. et al (2009). Software testing for webapplications non-functional requirements. Proceedings of
the 2009 Sixth International Conference on Information
Technology: New Generations, pp. 1674-1675. April 27-29,
Las Vegas, USA.
Glinz, M. (2007). On non-functional requirements.
Proceedings 15th IEEE International Requirements
Engineering Conference (RE'07), pp. 21-26. October 15-19,
Delhi, India.
Wieringa, R. et al (2005). Requirements engineering paper
classification and evaluation criteria: A proposal and a
discussion. Requirements Engineering Journal 11(1), pp.
102-107.
Ivarsson, M. & Gorschek, T. (2009). Technology transfer
decision support in requirements engineering research: A
systematic review of REj. Requirements Engineering
Journal 14 (3), pp. 155-175.
Arnold, D.; Corriveau, J. & Wei, S. (2010). Modeling and
validating requirements using executable contracts and
scenarios. Proceedings 8th ACIS International Conference
on Software Engineering Research, Management and
Applications (SERA), pp. 311-20. May 24-26, Montreal,
Canada.
Goel, A.; Sengupta, B. & Roychoudhury, A. (2009).
Footprinter: Round-trip engineering via scenario and state
based models. Proceedings 31st International Conference
on Software Engineering, pp. 419-420. May 16-24,
Vancouver, Canada.
Tsai, W. et al (2003). Scenario-based web services testing
with distributed agents. IEICE Transactions on Information
and Systems 86(10), pp. 2130-2144.
Pfaller, C. et al (2006). On the integration of design and test:
A model-based approach for embedded systems.
Proceedings of the 2006 international workshop on
[22]
[23]
[24]
[25]
[26]
[27]
[28]
[29]
[30]
[31]
[32]
[33]
[34]
[35]
Automation of software test (AST), pp. 15-21. May 20-28,
Shanghai, China.
Boulanger, J. & Dao, V. (2008). Requirements engineering in
a model-based methodology for embedded automotive
software. Proceedings IEEE International Conference on
Research, Innovation and Vision for the Future, pp. 263268. July 13-17, Ho Chi Minh City, Vietnam.
Lobo, L. & Arthur, J. (2005). Local and global analysis:
Complementary activities for increasing the effectiveness of
requirements verification and validation. Proceedings of
the 43rd Annual ACM Southeast Conference, pp. 256-261.
March 18-20, Kennesaw, USA.
Marelly, R.; Harel, D. & Kugler, H. (2002). Multiple instances
and symbolic variables in executable sequence charts.
Proceedings 17th International Conference on ObjectOriented Programming, Systems, Languages and
Applications (OOPSLA), pp. 83-100. November 4-8, Seattle,
USA.
Nan, N. et al (2009). Aspects across software life cycle: a
goal-driven approach. Lecture Notes in Computer Science
5560, pp. 83-110.
Duy, N.; Perini, A. & Tonella, P. (2008). A goal-oriented
software testing methodology. Lecture Notes in Computer
Science 4951, pp. 58-72.
Abbors, F.; Truscan, D. & Lilius, J. (2009). Tracing
requirements in a model-based testing approach.
Proceedings First International Conference on Advances in
System Testing and Validation Lifecycle (VALID), pp. 123-8.
September 20-25, Porto, Portugal.
Mendez, E.; Perez, M. & Mendoza, L. (2008). Improving
software test strategy with a method to specify test cases.
Proceedings 10th International Conference on Enterprise
Information Systems, pp. 159-64. June 12-16, Barcelona,
Spain.
Quinn, C. et al (2006). Specification of software component
requirements using the trace function method. Proceedings
International Conference on Software Engineering
Advances, pp. 50-50. October 29 - November 3, Papeete,
Tahiti.
Naslavsky, L. et al (2005). Using scenarios to support
traceability. Proceedings 3rd international workshop on
Traceability in emerging forms of software engineering, pp.
25-30. November 8, Long Beach, USA.
Goel, A. & Roychoudhury, A. (2006). Synthesis and
traceability of scenario-based executable models.
Proceedings 2nd International Symposium on Leveraging
Applications of Formal Methods, Verification and
Validation, pp. 347-54. November 15-19, Paphos, Cyprus.
Ibrahim, S. et al (2006). A software traceability validation
for change impact analysis of object oriented software.
Proceedings of the International Conference on Software
Engineering Research and Practice, pp. 453-459. June 2629, Las Vegas, USA.
Dubois, H.; Peraldi, M. & Lakhal, F. (2010). A model for
requirements traceability in a heterogeneous model-based
design process - Application to automotive embedded
systems. Proceedings 15th IEEE International Conference
on Engineering of Complex Computer Systems, pp. 233-242.
March 22-26, Oxford, UK.
Bouquet, F. et al (2007). A subset of precise UML for modelbased testing. Proceedings 3rd international workshop on
Advances in model-based testing, pp. 95-104. July 9-12,
London, England.
Kelleher, J. & Simonsson, M. (2006). Utilizing use case
classes for requirement and traceability modeling.
Proceedings 17th IASTED International Conference on
Modelling and Simulation, pp. 617-25. Anaheim, CA, USA,
2006.
45
[36] Sabetta, A. et al (2005). Abstraction-raising transformation
for generating analysis models. Lecture Notes in Computer
Science 3844, pp. 217-26.
[37] Mustelier, D. & Viera, Y. (2013). Variables that define the
complexity of the software functional requirements. Revista
Antioqueña de las Ciencias Computacionales y la Ingeniería
de Software (RACCIS), 3(2), pp. 38-42.
[38] Hassan, R. et al (2010). Formal analysis and design for
engineering security automated derivation of formal
software security specifications from goal-oriented security
requirements. IET Software 4(2), pp. 149-160.
[39] Hussain, T. & Eschbach, R. (2010). Automated fault tree
generation and risk-based testing of networked automation
systems. Proceedings 15th IEEE Conference on Emerging
Technologies and Factory Automation, pp. 1-8. September
13-16, Bilbao, Spain.
[40] Mugridge, R. (2008). Managing agile project requirements
with storytest-driven development. IEEE Software 25(1),
pp. 68-75.
[41] Bâillon, C. & Mongardé, S. (2010). Executable requirements
in a safety-critical context with Ada. Ada User Journal 31(2),
pp. 131-135.
[42] Sabaliauskaite, G. et al (2010). Challenges in aligning
Requirements Engineering and verification in a large-scale
industrial context. Lecture Notes in Computer Science 6182,
pp. 128-42.
[43] Nebut, C. et al (2006). Automatic test generation: A use case
driven approach. IEEE Transactions on Software
Engineering 32(3), pp. 140-55.
[44] Whalen, M. et al (2006). Coverage metrics for requirementsbased testing. Proceedings of the international symposium
[45]
[46]
[47]
[48]
[49]
[50]
[51]
[52]
on Software testing and analysis, pp. 25-35. July 17-20,
Portland, USA.
Conrad, M.; Fey, I. & Sadeghipour, S. (2005). Systematic
model-based testing of embedded automotive software.
Electronic Notes in Theoretical Computer Science 111, pp.
13-26.
Siegl, S.; Hielscher, K. & German, R. (2010). Model based
requirements analysis and testing of automotive systems
with timed usage models. Proceedings 18th IEEE
International Requirements Engineering Conference, pp.
345-350. September 29 – October 1, Sydney, Australia.
Riebisch, M. & Hubner, M. (2005). Traceability-driven
model refinement for test case generation. Proceedings
12th IEEE International Conference and Workshops on the
Engineering of Computer-Based Systems, pp. 113-120.
April 4-7, Greenbelt, USA.
Arnold, D.; Corriveau, J. & Wei, S. (2010). Scenario-based
validation: Beyond the user requirements notation.
Proceedings Software Engineering Conference, pp. 75-84.
April 6-9, Oakland, USA.
Serna, M.E. (2010). Formal methods and Software
Engineering. Revista Virtual Universidad Católica del Norte
30, pp. 158-184.
Serna, M.E. (2013). Logic in Computer Science. Revista
Educación en Ingeniería 8(15), pp. 62-68.
Serna, M.E. & Polo, J.A. (2014). Logic and abstraction in
engineering education: A necessary relationship. Revista
Ingeniería Investigación y Tecnología XV(2), pp. 299-310.
Serna, M.E. & Zapata, A.L.F. (2014). Approach to logic and
abstraction in the engineering training. Revista
Internacional de Educacion y Aprendizaje 2(1), pp. 35-47.
46