UNA PROPUESTA METODOLÓGICA PARA MEJORAR LA COMUNICACIÓN EN INGENIERÍA DE REQUISITOS¹

A METHODOLOGICAL PROPOSAL TO IMPROVE COMMUNICATION REQUIREMENTS ENGINEERING

UMA PROPOSTA METODOLÓGICA PARA MELHORAR A COMUNICAÇÃO EM ENGENHARIA DE REQUISITOS

Jenny C. Ramírez-Leal², William J. Giraldo-Orozco³, Raquel Anaya-Hernández⁴

1 Artículo de investigación científica y tecnológica. Apropiación de técnicas de elicitación de conocimiento y de comunicación personalizadas para potenciar el proceso de Ingeniería de Requisitos, Mayo del 2011 a Agosto del 2013, Universidad EAFIT.
2 Ingeniera de Sistemas y Computación. Magíster en Ingeniería. Profesora de planta del Departamento de Pedagogía y Mediaciones Tecnológicas. Universidad del Tolima. Calle 57 4a 53 Torre B Torreon de Piedrapintada Etapa 1, Ibagué, Colombia / Tel.: 3207190167. Correo electrónico: jcramirezle@ut.edu.co.
3 Ingeniería Eléctrica. Doctor en Arquitectura y gestión de la información y del conocimiento en sistemas en red. Profesor de planta del Programa de Ingeniería de Sistemas y Computación. Universidad del Quindío.
4 Ingeniería de Sistemas. Doctorado en Ingeniería de la programación e inteligencia artificial. Profesor de planta de la Universidad EAFIT.

Artículo recibido: 12-V-2016 / Aprobado: 12-XI-2016
Disponible online: 30 de febrero de 2017
Discusión abierta hasta abril de 2018

RESUMEN

La ingeniería de requisitos (IR) involucra el entendimiento de las necesidades de los individuos y sus formas de organización para tener una mayor comprensión de sus principales problemas, metas y alternativas de solución. Esta ingeniería pasa por una serie de etapas y tareas en las que constantemente se requiere colaborar, coordinar y comunicar los distintos stakeholders, entre sí, pero manteniendo distintas perspectivas y puntos de vista lo que plantea grandes retos de comunicación. Este trabajo propone una aproximación metodológica para promover una mejor comunicación entre los stakeholders durante el proceso de IR. Esta aproximación se enmarca en la ingeniería de procesos y las estrategias de comunicación pero desde la óptica de las técnicas de elicitación de conocimiento (TEC) y las técnicas de comunicación (TC). Dada la naturaleza altamente humana de la IR, se mostrará cómo esta propuesta permite potencializar los procesos de comunicación pasando por cuatro etapas, a saber: (1) identificación de las técnicas que aportan a la comunicación; (2) especificación formal de dichas técnicas para comprenderlas en su uso; (3) definición de una aproximación metodológica para la IR; y (4) aplicación de la propuesta en una muestra aleatoria de empresas de desarrollo de software.

PALABRAS CLAVE: Comunicación; elicitación de requisitos; estrategia de comunicación; ingeniería de requisitos; problema de comunicación.

ABSTRACT

Requirements Engineering (RE) involves the knowledge of individuals' situational needs in order to enhance comprehension of leading problems, goals and solution alternatives. This engineering follows a series of stages and tasks which require constant cooperation, coordination and communication among the different stakeholders, while maintaining a variety of perspectives and points of view. Consequently, it poses great communication challenges. This paper proposes a methodological approximation in order to foster better communication among stakeholders during the RE processes. The framework of this approximation is process engineering and communication strategies, yet from the perspective of knowledge elicitation techniques (KET), as well as communication techniques (CT). Given the highly human nature of RE, we will show how this proposal enables the upgrade of communication processes through four stages, namely: (1) identification techniques that contribute to communication, (2) formal specifications of said techniques to understand them in their use, (3) definition of a methodological approximation for RE, (4) application of this proposal on a random sample of a software development companies.

KEY WORDS: Communication; Elicitation of requirements; Communication Strategy; Requirements Engineering; Communication problem.

RESUMO

A engenharia de requisitos (IR) envolve o entendimento das necessidades dos indivíduos e suas formas de organização para ter um maior entendimento de seus principais problemas, metas e alternativas de solução. Esta engenharia passa por uma série de etapas e tarefas nas que constantemente se requer colaborar, coordenar e comunicar os diferentes stakeholders, entre si, mas mantendo diferentes perspectivas e pontos de vista o que propõe grandes desafios de comunicação. Este trabalho propõe uma aproximação metodológica para promover uma melhor comunicação entre os stakeholders durante o processo de IR. Esta aproximação se enquadra na engenharia de processos e as estratégias de comunicação mas desde a óptica das técnicas de elicitação de conhecimento (TEC) e as técnicas de comunicação (TC). Dada a natureza altamente humana da IR, mostrar-se-á como esta proposta permite potencializar os processos de comunicação passando por quatro etapas: (1) identificação das técnicas que contribuem à comunicação; (2) especificação formal das técnicas para compreendâ-las em seu uso; (3) definição de uma aproximação metodológica para a IR; e (4) aplicativo da proposta numa mostra aleatória de empresas de desenvolvimento de software.

PALAVRAS-CHAVE: Comunicação; Elicitação de requisitos; Estratégia de Comunicação; Engenharia de Requisitos; Problema de comunicação.

1. INTRODUCCIÓN

La Ingeniería de Requisitos (IR) es la columna vertebral del ciclo de desarrollo de software, que involucra no solo aspectos técnicos (Goguen, 2009; Diaper, 1989), sino también humanos, donde se generan complejas dinámicas en las relaciones de comunicación entre los stakeholders para elicitar, especificar, negociar y validar los requisitos del sistema que se va a construir (Durán et al., 2003).

Por ello, es de vital importancia mejorar las estrategias de comunicación entre los stakeholders en aras de identificar y validar de manera correcta y oportuna las necesidades reales de los clientes y los usuarios, evitando aplazar la identificación de defectos que surgen de los requisitos en etapas posteriores, los cuales tienen mayor costo de corrección (Boehm, 1984).

Son numerosos los trabajos de investigación que han propuesto estrategias para mejorar la comunicación en la IR en aras de lograr un mejor entendimiento de los requisitos del sistema que se va a construir; cada uno de estos investigadores tiene sus propias percepciones y proponen diversos modelos desde diferentes enfoques para mejorar los problemas de comunicación. En algunos de estos solo se describen las técnicas a nivel general (Pytel et al., 2012); otros en cambio realizan la recopilación de un conglomerado de técnicas sin especificarlas como lo son Carrizo (2012), Gil (2010). Finalmente, otros autores han trascendido más en este tipo de investigaciones, logrando proponer procesos de formalización de técnicas desde diferentes contextos como Méndez et al. (2010), Jiang et al. (2008); Hossian (2013), Carrizo (2009) y Gómez (2013).

Esta investigación se aborda desde la Ingeniería de software, bajo el contexto la IR, teniendo en cuenta el enfoque de la mejora de la comunicación. Se analiza cada fase de la IR (elicitación - análisis - especificación - validación) para identificar qué técnicas de elicitación de conocimiento (TEC) y de comunicación (TC) pueden complementar o remplazar las técnicas de ingeniería de requisitos tradicionales (TIR).

Para llevar a cabo esta investigación, se analizan los problemas de comunicación que se presentan en el proceso de IR y posteriormente se identifican qué TIR son utilizadas para apoyar el proceso. Adicionalmente, se estudian las TEC utilizadas en Ingeniería de conocimiento que tienen por objetivo elicitar, estructurar y representar formalmente el conocimiento extraído de un dominio específico para la construcción de sistemas expertos o SBC¹ (Palma et al., 2000), también se estudian las TC. Una vez recopiladas estas técnicas, son analizadas para identificar cómo han demostrado resolver problemas mediante el uso de estrategias de comunicación. Finalmente se define un marco metodológico que permita integrar técnicas TEC y TC para el mejoramiento del proceso de comunicación en IR.

Este documento está organizado de la siguiente manera: en la sección 2 se hablará de los trabajos relacionados. En la sección 3 se hablará del contexto de trabajo. En la sección 4 se abordará el marco metodológico de la investigación. En la sección 5 se define el marco conceptual. En la sección 6 se describirá la propuesta metodológica para la ingeniería de requisitos. En la sección 7 se mostrarán los resultados obtenidos y la discusión de los mismos. Finalmente, las conclusiones, trabajos futuros y la bibliografía.

2. TRABAJOS RELACIONADOS

Algunos autores como Intille, Zapata, Potts, Maiden, Leite, France, Laguna, entre otros, han propuesto estrategias para mejorar el proceso de comunicación en la IR, en aras de lograr un mejor entendimiento de los requisitos del sistema que se va a construir; cada uno de estos investigadores tiene sus propias percepciones y proponen diversos modelos desde diferentes enfoques para mejorar los problemas de comunicación. Se pueden mencionar soluciones como:

La incorporación de métodos de Análisis de Comunicaciones (Ruiz et al., 2010), método que plantea una estructura de requisitos basada en 5 niveles que permite una aproximación por refinamientos sucesivos. En el nivel 1 se descompone el problema; en el nivel 2 se identifican los principales objetos de negocio y se modela cada proceso de la organización mediante diagramas de sucesos comunicativos; en el nivel 3 cada suceso comunicativo se describe mediante una plantilla de especificación al mismo tiempo, los objetos de negocio se especifican con más detalle; en el nivel 4 se diseña la interfaz para dar soporte a la comunicación asociada a los sucesos; en el nivel 5 se procede a hacer el diseño lógico y de componentes para la fase de implementación.

Modelo de diálogo (Zapata y Carmona, 2009). Específicamente este modelo trata de generar una estructura de diálogo al proceso de las entrevistas, en aras de mitigar los problemas de limitación de tiempo, redundancia de información, falta de claridad en lo que quiere el cliente, información irrelevante y carencia de herramientas; facilitando de esta forma la interacción oral entre las personas, a través de sistemas informáticos.

Talleres de creatividad a través del sistema RESCUE (Madein y Robertson, 2005). RESCUE se basa en la técnica de brainstorming conocida como CPS (creative problem solving), que está dividida en 3 grupos con 2 fases cada uno: (1) Comprender el problema: encontrar el desorden, encontrar los datos. (2) Generación de ideas: encontrar problemas, encontrar ideas. (3) Plan de acción: encontrar soluciones, aceptar de los hallazgos. En este trabajo los talleres RESCATE se utilizaron de forma exitosa para descubrir necesidades de los interesados del futuro sistema de tráfico aéreo europeo.

Metodología "Image-Based Experience Sampling and Reflection" (Intille et al., 2002). En este estudio se propone esta nueva metodología para dar asistencia a los usuarios en el momento de elicitar sus necesidades. En este proceso, se instala en el ambiente del usuario una cámara fotográfica para capturar imágenes, que después le serán mostradas en el momento de la elicitación para ayudarle a describir sus procesos mediante la generación de sentimientos, esto con el fin de generar un mejor diálogo entre los stakeholders.

Diagramas DTD (Laguna et al., 2001), son usados para elicitar de los expertos del dominio información oral que permiten trabajar con usuarios que no saben expresar qué es lo que realmente necesitan; en este trabajo Laguna plantea que es más fácil que el experto estructure su quehacer diario mediante diagramas DTD (diagramas- documentostareas) donde él muestre las diferentes tareas que realiza y su producción de entregables; que no es posible con los casos de usos, ya que son eficientes pero solo cuando los stakeholders saben perfectamente cómo será el sistema futuro.

Metodología de uso de metáforas (Potts, 2001) para comprender mejor los requisitos de los clientes; esto debido a cuestiones lingüísticas cognitivas que demuestran que la metáfora es un fenómeno generalizado en la comprensión y la comunicación de las abstracciones de todo tipo. En esta investigación se explican dos tipos de metáforas fundamentales que se repiten a lo largo de la ingeniería de requisitos: (1) la reificación de las abstracciones mentales como sustancias materiales y contenedores; (2) la especialización de las abstracciones como ubicaciones, trayectorias, relaciones espaciales, y antropomorfismos.

Estos trabajos, entre otros, han mejorado el proceso de comunicación en diferentes aspectos como la mitigación de los problemas de limitación de tiempo, la eliminación de redundancia de información, el aumento de claridad en lo que quiere el cliente, la disminución de información irrelevante y el suministro de herramientas de apoyo. A diferencia de estas propuestas, esta investigación propone un método sistémico para incorporar TEC y TC al proceso de IR para mejorar la comunicación; dicho método es flexible y podrá ser aplicado en otros contextos para incorporar cualquier otro tipo de técnicas de adquisición de conocimiento.

3. CONTEXTO

En esta sección se presenta el modelo conceptual expuesto en la Figura 1, el cual expresa los conceptos claves de este trabajo mediante el uso de entidades. Cada concepto está representando un conjunto de información identificada previamente dentro del contexto de la IR y es necesario precisarlos para su claro entendimiento.

Figura 1

En el modelo ontológico de la Figura 1 se representa que el proceso de IR tiene 4 actividades, que a su vez están conformadas por tareas. Las tareas presentan problemáticas de comunicación (ver Tabla 1) y son apoyadas a través de técnicas de IR que pueden llegar a ser complementadas o remplazadas por otras provenientes del contexto de las técnicas de elicitación de requisitos y las de comunicación con cierto nivel de importancia. Estas nuevas técnicas poseen ciertas estrategias de comunicación (ver Tabla 2) que pueden ayudar en alguna medida a mejorar los problemas de comunicación presentados en las tareas.

Tabla 1

Tabla 2

• Proceso de Ingeniería de Requisitos: es el proceso de desarrollar una especificación de software. Las especificaciones pretenden comunicar las necesidades del sistema del cliente a los desarrolladores del sistema (Sommerville y Sawyer, 2005).
• Actividad de IR: representa las cuatro etapas en las cuales se realiza el proceso de Ingeniería de Requisitos y son: elicitación, análisis, especificación y validación.
• Tarea de Ingeniería de Requisitos: es el grano más fino del proceso de IR. La granularidad del proceso se divide en actividades y para cada actividad se realizan tareas (SWEBOK, 2001).
• Técnica de ingeniería de requisitos: es una técnica de utilizada tradicionalmente en cualquier actividad del proceso de IR (Sommerville y Ranson, 2005).
• Técnica: se entiende por una técnica, un contenedor de métodos que tiene: tareas, roles y artefactos que van a ser implementadas como un patrón de capacidad.
• Problema de comunicación: se entiende por problema de comunicación en IR, cuando la transferencia de conocimiento tácito entre los stakeholders no se da de forma satisfactoria debido a factores como: mal uso del lenguaje, deficiencias del entorno (ruido, incomodidad, tiempo, la motivación y el espacio físico) (Durán y Bernández, 2003). El consolidado de problemas de comunicación abordados en esta investigación, a los cuales se les pretende dar solución, se describen en la Tabla 1.
• Estrategia de comunicación: son factores externos o elementos del contexto de la comunicación, en el que se da la aplicación de la técnica, que actúan como agentes (drivers) para mejorar la comunicación. Pueden ser: una circunstancia, un elemento, el contexto o algo que promueve la comunicación. Las estrategias de comunicación trabajadas en esta investigación se describen en la Tabla 2.
• Nivel de importancia: denota el impacto de un concepto de Ingeniería de Requisitos frente a otro. En esta investigación se abordan 5 niveles de importancia los cuales se observan en el modelo conceptual de la Figura 1, y son: el nivel de importancia que tiene una técnica IR para realizar una tarea IR. El nivel de afectación de los problemas de comunicación en una tarea IR. El nivel de mejora de los problemas de comunicación usando estrategias de comunicación. El nivel de presencia de una estrategia de comunicación en una o más TEC o TC. Finalmente, el nivel de complemento de una TEC o TC para una TIR. Se establece una escala de 3 valores de importancia: (1) para denotar nivel de importancia alto, (2) nivel de importancia medio y (3) nivel de importancia bajo.
• Otras técnicas: son técnicas de adquisición de conocimiento proveniente desde otros contextos diferentes a la Ingeniería del Software. Para el caso particular, los contextos abordados en esta investigación son la gestión del conocimiento y la comunicación.

4. MARCO METODOLÓGICO

Para llevar a cabo esta investigación, se llevaron a cabo 4 etapas que se describen a continuación:

1. Identificación inicial de técnicas que aportaran a la comunicación: esta etapa tiene como propósito identificar las técnicas TEC y TC que se incorporarán en la propuesta resultante; para tal fin, inicialmente se identifican los problemas habituales de la IR con el propósito de identificar las técnicas que aportan significativamente a su solución. Posteriormente, se define en detalle en qué consiste cada técnica, comprendiéndola.
2. Especificación formal de las técnicas TEC y TC: una vez encontrada toda la información referente a cada técnica, se procede a definir el esquema de granularidad de las técnicas, con el propósito de lograr un esquema formal de especificación que permita entender el modo de uso de cada una de estas.
3. Definición de la propuesta metodológica para la disciplina IR: se incorpora a la IR una propuesta de incorporación de TEC y TC, que permite entender a los ingenieros de requisitos, o analistas, cómo realizar IR con nuevas técnicas que le faciliten la obtención de resultados más efectivos al momento de identificar las necesidades del producto software a realizar.
4. Aplicación de la propuesta en empresas de desarrollo de software: una vez desarrollada la propuesta para IR, se procede a aplicarla en 5 empresas de desarrollo de software de la ciudad, con el propósito de comprobar su validez para potencializar la comunicación entre los stakeholders. Lo anterior, con la finalidad de que los Ingenieros de Requisitos logren entender mejor el dominio de negocio y las necesidades derivadas de este, para identificar con mayor exactitud los requisitos del producto a construir.

5. MARCO CONCEPTUAL

La metodología propuesta en esta investigación tiene dos enfoques: el primero, relacionado con el cómo, abordado desde la ingeniería de procesos, con el fin de complementar y/o remplazar las técnicas de la ingeniería de requisitos. El segundo, abordado desde la hipótesis de esta investigación (ver Figura 1); identificando las estrategias de comunicación asociadas al contexto de las técnicas TEC y TC que de alguna forma puedan extrapolarse para enfrentar los problemas de comunicación identificados en la IR.

Las estrategias de comunicación son seleccionadas a partir de los trabajos recopilados en el estado del arte. Para ello, se utilizan dos tipos de extracción: la extracción directa, es decir, estudiando directamente la incidencia de estas estrategias de comunicación en los problemas encontrados. Segundo, la extracción indirecta por medio del estudio de cómo estas estrategias de comunicación están siendo resueltas por las TC y las TEC (ver Figura 2).

5.1. Enfoque desde la ingeniería de procesos

Este enfoque proviene de la Ingeniería de Procesos y se necesita para formalizar las técnicas con el fin de identificar el aporte de las técnicas TEC y TC en el proceso de comunicación de la IR (a través de las TIR). Para hacer esto se identifica cuando un contenido de método (término utilizado en SPEM para referirse a un empaquetamiento de una especificación de proceso) enriquece a otro contenido (siendo ambos del mismo tipo); por lo tanto, si el contenido fuente es una técnica, la contribución se hará estrictamente sobre otra técnica (no sobre un paso o una tarea- términos de SPEM); de tal forma, las TIR podrán complementarse con otras técnicas, para este caso las TEC y las TC.

Por lo anterior y sabiendo que las técnicas en general son extrapolables, dado que tienen su origen en un contexto particular, estas pueden ser aplicadas en otro contexto. Esto les permite que puedan ser mejoradas para que luego sean aplicadas en su entorno origen dando solución a un problema que antes no solucionaba (ver Figura 3).

Figura 3

5.2. Enfoque desde la hipótesis de la investigación

Siguiendo este enfoque se identifican los problemas de comunicación durante el proceso de IR y las estrategias de comunicación que pueden solucionar dichos problemas para que posteriormente se apliquen los instrumentos en empresas de desarrollo, a personas expertas en IR con el objetivo de identificar las relaciones "Apoyada por", "Incide en la ejecución" y "Es mejorado/resuelto".

Finalmente se propone una matriz de decisión que establece las siguientes relaciones: "Está presente" que tiene como propósito definir el nivel de importancia que existe entre las estrategias de comunicación y otras técnicas desde los contextos TEC y TC. La relación "Complementa o remplaza" que tiene como propósito definir el nivel de importancia que existe entre otras técnicas y las TIR.

Lo anterior con el fin de que los analistas e ingenieros de requisitos puedan tener pautas para seleccionar las técnicas TEC o TC que pueden utilizar durante las diferentes tareas IR y de este modo mejorar la comunicación en el proceso IR.

6. PROPUESTA METODOLÓGICA PARA INGENIERÍA DE REQUISITOS

En esta sección se presenta brevemente la propuesta metodológica para mejorar el proceso de comunicación en IR a partir de las técnicas TEC y TC. La metodología está compuesta por 11 etapas, las cuales muestran cómo incorporar técnicas TEC o TC al proceso IR para complementar o remplazar las TIR. A continuación se describe cada etapa.

Etapa 1. Definición del modelo de descomposición de trabajo: en esta etapa se establecen los 4 niveles de granularidad para definir cada técnica (TIR - TEC - TC), uno para establecer el momento de ocurrencia (planeación / ejecución / análisis de resultados), otro para describir la técnica y encapsularla, y los otros 2 para manejar dos niveles de granularidad interno (labor / sub-labor); todo con el objetivo de establecer patrones y conductas similares dentro de las técnicas, que permitan reconocer si una tarea presente en 2 técnicas con diferente nombre, en realidad corresponde a la misma (ver Figura 4).

Figura 4

Etapa 2. Identificación de TIR: en esta etapa se identifican las TIR que podrán ser complementadas o remplazadas mediante las TEC y TC. Las TIR son extraídas de dos formas, la primera usando las disciplinas Bussines Model y Requirements del marco de trabajo RUP, y la segunda haciendo uso de la literatura, identificando cuáles son las utilizadas, razón por la cual se le asigna el nombre de tradicionales.

Etapa 3: Formalización de TIR: en esta etapa cada TIR se define haciendo uso de los 4 niveles de granularidad establecidos en la etapa 1.

Etapa 4: Clasificación de TIR por actividades IR: en esta etapa el consolidado de TIR recolectado en la etapa 2 es clasificado según las 4 actividades de la ingeniería de requisitos (elicitación - análisis - especificación - validación) donde cada técnica sea utilizada.

Etapa 5 Identificación de TEC y TC: en esta etapa, se identifican las TEC y las TC que pudieran ser incorporadas al proceso de IR para mejorar la comunicación.

Etapa 6 Formalización de TEC y TC: permite el consolidado de TEC/TC, el cual se define haciendo uso de los 4 niveles de granularidad establecidos en la etapa 1.

Etapa 7 Elaboración de catálogo: ya formalizadas las TIR, TEC y TC se procede a incluirlas en el marco de trabajo de SPEM, para realizar un marco de navegación sobre las mismas.

Etapa 8 Identificación de problemas de comunicación: realiza una revisión para identificar los problemas de comunicación que más se presentan en el proceso de Ingeniería de Requisitos, los cuales se pretenden mejorar o resolver.

Etapa 9 Identificación de estrategias de comunicación: A partir de los trabajos recopilados en el estado del arte y las experiencias obtenidas en estas investigaciones, se procede a identificar las estrategias de comunicación que pueden ayudar a mitigar los problemas de comunicación generados durante el proceso de Ingeniería de Requisitos.

Etapa 10 Diseño y Aplicación del instrumento: se aplica el instrumento en empresas de desarrollo a personas expertas en IR, para obtener 3 tablas que midan el nivel de importancia que existe entre distintos conceptos de ingeniería de requisitos.

La primera tabla tiene que ver con la relación "Apoyada por", y tiene como objeto definir el nivel de importancia que existe entre las tareas IR y las técnicas de ingeniería de requisitos. Las preguntas asociadas a esta tabla son las siguientes:

Pregunta 1: ¿Cuál es la frecuencia de ejecución de las tareas genéricas del proceso de IR?

Pregunta 2: ¿Cuál(es) es(son) la(s) técnica(s) de IR que usted aplica para la ejecución de la tareas, cuya frecuencia de ejecución es Alta o Media?

La segunda tabla tiene que ver con la relación "Incide en la ejecución" y tiene como propósito definir el nivel de importancia que existe entre los problemas de comunicación y las tareas IR. Las preguntas asociadas a esta tabla son las siguientes:

Pregunta 3: ¿Cuáles son los problemas de comunicación que más se presentan en su compañía?

Pregunta 4: ¿Cuáles son las tareas de IR que se ven principalmente afectadas por dichos problemas?

La tercera tabla tiene que ver con la relación "Es mejorado/resuelto", y tiene como propósito definir el nivel de importancia que existe entre los problemas de comunicación y las estrategias de comunicación. La pregunta asociadas a esta tabla es la siguiente:

Pregunta 5: Determine, para los problemas que se presentan con mayor frecuencia (identificados en la tabla anterior como A y B), cuál (les) es (son) la(s) estrategia(s) de comunicación que podrían contribuir a la solución de dichos problemas.

Etapa 11 Elaboración de matriz de decisión: en esta etapa se realiza el análisis de los resultados obtenidos en la etapa 10, en la cual se establecerá la relación "Está presente", que tiene como fin definir el nivel de importancia que existe entre las estrategias de comunicación y otras técnicas desde los contextos TEC y TC y la relación "Complementa o remplaza", que tiene como propósito definir el nivel de importancia que existe entre otras técnicas y las TIR.

Estableciendo estas relaciones, el analista o el ingeniero de requisitos, podrá definir qué técnicas TEC o TC podrá utilizar según las necesidades que tenga para el proceso de Ingeniería de Requisitos.

A manera de síntesis, la Figura 5 muestra la definición de las 11 etapas definidas para lograr la incorporación de técnicas al proceso IR.

Figura 5

7. RESULTADOS Y DISCUSIÓN

Una vez elaborada la propuesta metodológica para incorporar técnicas TEC y TC se procede a definir 5 empresas de desarrollo de software de la ciudad de Armenia, con la finalidad de aplicar el experimento que pudiera validar la propuesta. Para la selección de la muestra, se utilizó un muestreo aleatorio de 5 empresas de desarrollo de software que cumplieran a cabalidad ciertas características que favorecerían la aplicación de la propuesta metodológica; estas características se describen a continuación:

• Desarrollo de productos de desarrollo de software a la medida: se hizo necesario tener a disposición el desarrollo de un producto concreto en el cual un cliente tiene a cargo la especificación de las necesidades a incorporar; esto posibilitó comprobar si las técnicas TEC/TC indicadas por la propuesta metodológica potencializan los procesos de comunicación entre los stakehoders.
• Empresas pequeñas: para realizar el experimento se necesita tener fácil acceso al personal de la empresa.
• Existencia del rol ingeniero de requisitos o analista: la propuesta exige, en las diferentes técnicas que incorpora, el liderazgo de un ingeniero de requisitos, para llevar el control y definición de artefactos durante la disciplina de ingeniería de requisitos.
• Experiencia en desarrollo de productos software: las empresas seleccionadas deben tener más de 1 año de experiencia, a fin de corroborar la validación de los resultados obtenidos; esto se hace realizando un escenario comparativo entre las experiencias adquiridas en proyectos anteriores y la nueva experiencia.
• Aplicación de técnicas de ingeniería de requisitos durante la disciplina: es necesario contar con personas con experiencia en la aplicación de TIR para el desarrollo de un producto software, esto con el propósito de tener un marco de referencia comparativo con las técnicas propuestas, respecto a la veracidad de los resultados obtenidos.
• Empresas que estuvieran iniciando la fase de ingeniería de requisitos: evidentemente la propuesta está diseñada para la disciplina IR, por lo cual se necesitan proyectos en donde esta etapa no se haya realizado.
• Disponibilidad del cliente durante la aplicación del experimento: con el fin de aplicar la propuesta metodológica y posteriormente evaluar la veracidad de los resultados obtenidos, se hizo necesario contar con clientes que tengan tiempo e interés en participar en el experimento, ya que de estos depende en gran medida, en primera instancia, la aplicación de las técnicas TEC/TC, y en segunda instancia la validación de los resultados obtenidos.
• Empresas con desarrollos pequeños: en aras de realizar un experimento concreto a corto plazo, se hizo necesario seleccionar proyectos pequeños de desarrollo a la medida, cuya ejecución no tardara más de 4 meses. Esto permite dar cobertura total de los requisitos durante la ejecución del experimento.
• Dominios de negocio desconocidos: el hecho de que el equipo de desarrollo del proyecto desconociera el dominio de negocio pone a prueba a las técnicas TEC/TC, y demuestra su potencialidad al facilitar el proceso de comunicación entre los stakeholders, haciendo el experimento más idóneo.

No se hacen necesarias más empresas, ya que prevalece ejecutar la propuesta metodológica en una muestra aleatoria, donde se tuviera a disposición los stakeholders para de esta forma lograr comprobar la validez de la propuesta y su potencialidad para comprender las necesidades de los clientes.

7.1. Diseño de experimento

Se caracteriza cada empresa de desarrollo de software seleccionada a partir de 7 criterios descritos en la Tabla 3, esto con el fin de lograr identificar con qué técnicas TEC y TC se debe validar la propuesta metodológica. Para tal fin, para cada empresa de desarrollo se diseña un experimento consistente en seis actividades: (1) Identificación de proyecto de desarrollo. (2) Diligenciamiento de ficha de planeación TEC/TC. (3) Establecimiento de plan de ejecución. (4) Definición de resultados. (5) Realización de panel grupal de retroalimentación. (6) Análisis de resultados. Ha de aclararse, que no se realiza la divulgación de los resultados obtenidos, ya que las empresas manifiestan la necesidad de confidencialidad de dicha información que consideran sensible ante la competencia.

Tabla 3

1. Identificación de proyecto de desarrollo. Selección de un proyecto a partir de todos los proyectos de desarrollo que tiene a cargo la empresa de desarrollo. Este proyecto tiene las siguientes características: alcance definido, ejecución de la disciplina de ingeniería de requisitos y disponibilidad de clientes.
2. Diligenciamiento de ficha de planeación TEC/ TC. Cada empresa identifica en la ficha de planeación TEC/TC (Ver Tabla 4) los problemas de comunicación particulares que han tenido en la disciplina de Ingeniería de Requisitos en proyectos anteriores. Una vez identificados los problemas de cada empresa, se selecciona las TEC/TC que se requieren aplicar para mitigar el problema; lo anterior teniendo en cuenta la caracterización de las estrategias comunicacionales que implementa cada técnica (ver Tabla 5).

Tabla 4

Tabla 5

3. Establecimiento de plan de ejecución. En esta actividad se definen las sesiones para aplicar la propuesta metodológica en la empresa de desarrollo (ver Tabla 6). Cada encuentro debe incluir: las actividades a realizar, la duración, el responsable, las observaciones encontradas y la aprobación de los stakeholders con el fin de lograr comprometerlos a participar activamente durante el proceso.

Tabla 6

4. Definición de resultados. Describe en detalle los resultados alcanzados en cada una de las sesiones y los artefactos obtenidos desde el enfoque de las técnica: flor de loto, mapa conceptual, descripción de incidente, storyboard, entre otros o desde el enfoque de la disciplina: diagrama de casos de uso, historias de usuario, documento de especificación de requisitos, documento de especificación de casos de uso, entre otros (ver Tabla 7). Lo anterior, con el fin de tener evidencias de los artefactos que serán evaluados posteriormente con el ingeniero de requisitos y/o los clientes. Cuando la evaluación de los clientes corresponde a varios, se hace necesario realizar una ponderación de la evaluación individual de cada uno de estos.

Tabla 7

5. Realización de panel grupal de retroalimentación. Con todos los stakeholders por proyecto, se aborda los tópicos alrededor de: la pertinencia de la propuesta metodológica, el tiempo de aplicación y las observaciones encontradas durante cada una de las sesiones. Para obtener resultados más concretos, durante el desarrollo del panel un moderador dirige a los stakeholders preguntas concretas, a las cuales estos deben responder mediante la siguiente escala cualitativa: Alta(A), Media (M) o Baja (B) según la experiencia vivida durante cada una de las sesiones. Posteriormente se abre un segmento de 10 minutos al finalizar el panel para que los stakeholders expongan los comentarios que consideren pertinentes, obteniendo en consolidado por tópico los resultados expuestos en la Tabla 8.

Tabla 8

6. Análisis de resultados. Se procede a analizar las calificaciones asignadas en las casillas: validación de cliente y validación del ingeniero de requisitos responsable de la plantilla de resultados (ver Tabla 8), la cual permite validar la exactitud de los artefactos obtenidos durante la aplicación del experimento, todo con la intención de identificar idóneamente las necesidades del producto software al construir. Cada uno de los enfoques de calificación está orientado desde diferente perspectiva; por un lado los ingenieros de requisitos líderes evaluaban si los artefactos les parecían pertinentes para la disciplina IR; por otra parte los clientes, siendo los más idóneos, evaluaban si los requisitos identificados eran lo que ellos realmente necesitaban. Estos resultados se muestran en la Tabla 9.

Tabla 9

En los resultados de la validación de los artefactos obtenidos, una vez aplicadas las técnicas, se evidencia que los clientes se muestran más satisfechos a nivel general que los ingenieros de requisitos; quizás esto se deba a que estos últimos tienen más brechas culturales referentes a los métodos tradicionales.

Es satisfactorio encontrar que entre el 95% y 97% de los clientes de todas las empresas dieron una puntuación alta a la aproximación y calidad de los requisitos obtenidos al finalizar el experimento, y ninguno de ellos calificó los resultados obtenidos en un nivel bajo, lo que permite identificar que la propuesta metodológica logra potencializar los procesos de comunicación entre los stakeholders para lograr la adquisición de requisitos de calidad.

Lo anterior demuestra que la propuesta logra ser más efectiva que las metodologías tradicionales para aplicar la ingeniería de requisitos, ya que permite no solo el uso de nuevas técnicas sino que además guía de forma descriptiva cómo aplicarlas y cuándo hacerlo en términos de estrategias comunicacionales. Adicionalmente, evidencia que los stakeholders se compenetran más en el proceso usando estas técnicas, sintiéndose más satisfechos con los resultados obtenidos.

8. CONCLUSIONES Y TRABAJOS FUTUROS

La realización de este trabajo arroja como resultado una nueva aproximación metodológica para incorporar técnicas de adquisición de conocimiento al proceso de Ingeniería de Requisitos y de esta manera mejorar la comunicación que se da entre los stakeholders. Aunque, en este trabajo solo son estudiadas técnicas de adquisición de conocimiento desde los contextos de gestión de conocimiento y comunicación, en esta metodología también es posible incorporar técnicas desde otros contextos, siempre y cuando estas favorezcan la comunicación.

Con la ejecución de esta metodología en las empresas de desarrollo de software se pretende guiar de forma más acertada la adquisición y transferencia de las necesidades de los clientes en el proceso de Ingeniería de requisitos, favoreciendo el intercambio de experiencias en un ambiente propicio, donde todas las personas involucradas se sientan seguras y libres de expresar sus ideas, haciendo uso de estrategias de comunicación que minimicen los problemas de comunicación que puedan presentarse.

Es importante tener en cuenta que una técnica TEC/TC puede implementar varias estrategias y que una estrategia puede aportar a la solución de varios problemas. De tal forma se encuentra que el 50% de los problemas de comunicación son solucionados con al menos 3 estrategias de comunicación, lo que indica que existen varias alternativas para mitigar los problemas de comunicación, ya que varias técnicas TEC y/o TC presentan estas estrategias de comunicación.

Esta investigación consiguió un consolidado de 24 técnicas de elicitación de conocimiento y de comunicación, con información referente a: descripción, recursos, artefactos, roles, objetivos, labores y sub-labores. Gracias a esta recopilación, se creó un catálogo público de técnicas de fácil consulta y aporte a la comunidad en general, que facilita la comprensión y comunicación entre los stakeholders que participan del proceso, suministrado a los ingenieros de requisitos de cada empresa una guía para apoyar la toma de decisiones frente a las TEC y/o TC.

Finalmente, la utilización de TEC y TC supuso una novedad considerable para los expertos durante el proceso de validación de la propuesta. La experiencia puede considerarse positiva, ya que posiblemente los expertos no hayan aprendido en qué consiste cada técnica, pero sí la importancia de las habilidades comunicacionales en este proceso y la existencia de técnicas útiles para propiciar estas habilidades. No obstante, queda la duda si el equilibrio alcanzado es suficiente para que en la práctica estos expertos puedan seleccionar de forma asertiva la técnica a aplicar en un proyecto.

_____________________________
NOTAS
1 Sistemas Basados en Conocimientos.

REFERENCIAS

Boehm, B. W. (1984). Verifying and validating software requirements and design specifications. Revista IEEE software, 1(1), enero-febrero, pp. 75-88. [Online] Disponible en: http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.365.8494. [Consultado 15 de junio de 2013]         [ Links ].

Cohene, T.; Easterbrook, S. (2005). Contextual risk analysis for interview design. En: Requirements Engineering, 2005. Proceedings. 13th IEEE International Conference IEEE. Washington, USA, 95-104 Aug. 2005 - Disponible en: http://ieeexplore.ieee.org/xpl/login.jsp?tp=$arnumber=1531031$url=http%3A%2F%2Fieeexplore.ieee.org%2Fxpls%2Fabs_all.jsp%3Farnumber%3D1531031. [Consultado 22 de junio de 2013]         [ Links ].

Coughlan, J.; Macredie, R. (2014). Effective Communication in Requirements Elicitation: A Comparison of Methodologies. Revista Requirements Engineering, 7 (2), pp. 47-60. [Online] Disponible en: http://link.springer.com/article/10.1007%2Fs007660200004 [Consultado 2 de junio de 2015]         [ Links ].

Diaper, D. (1989). Knowledge elicitation: principle, techniques and applications. Revista Engineering Applications of Artificial Intelligence 3(3), pp. 25-36 [Online] Disponible en: http://dl.acm.org/citation.cfm?id=SERIES10268.94297 [Consultado 18 de mayo de 2013]         [ Links ].

Drake, J.; Xie, W.; Tsai W.; Zualkernan, I. (1997). Approach and Case Study of Requirement Analysis Where End Users Take an Active Role. En: ICSE '93 Proceedings of the 15th international conference on Software Engineering. CA, USA pp. 177-186 May 1993. - Disponible en: http://dl.acm.org/citation.cfm?id=257608. [Consultado 16 de agosto 2013]         [ Links ].

Durán, A.; Bernández, B. (2003). Un Entorno Metodológico de Ingeniería de Requisitos para sistemas de información, tesis (Doctorado en Informática), España, universidad de Sevilla, 388 pp. [Online] Disponible en: https://www.lsi.us.es/docs/doctorado/tesis/AmadorDuran.pdf. [Consultado 26 de Agosto 2013]         [ Links ].

Farias, I.; Dos Santos, A.; Marczak, S. (2012). A Systematic Tertiary Study of Communication in Distributed Software Development Projects. En: IEEE Seventh International Conference on Global Software Engineering. Porto Alegre: Brazil 182-194 agosto 2012. [Online] Disponible en: http://www.computer.org/csdl/proceedings/icgse/2012/4787/00/4787a182-abs.html. [Consultado 4 de mayo 2013]         [ Links ].

France, R. B.; Horton, T. B. (1995). Applying Domain Analysis and Modeling: An Industrial Experience. En: SSR '95 Proceedings of the 1995 Symposium on Software reusability. York: USA 206-214 agosto 1995. [Online] Disponible en: http://dl.acm.org/citation.cfm?id=211846$dl=ACM$coll=DL$CFID=599445504$CFTOKEN=21879437. [Consultado 14 de mayo 2013]         [ Links ].

Goguen, J.A. (2009). Requirements Engineering as the Reconciliation of Social and Technical Issues. Computer Science and engineering. Revista Requirements engineering, 3(1) pp. 165-199 [Online] Disponible en: https://www.researchgate.net/publication/2263328_Requirements_Engineering_as_the_Reconciliation_of_Technical_and_Social_Issues [Consultado 18 de Mayo de 2013]         [ Links ].

Hoffmann, H.F.; Lehner, F. (2001). Requirements Engineering as a Success Factor in Software Projects. Revista IEEE Software, 18(4) pp. 58-66. [Online] Disponible en: http://ieeexplore.ieee.org/xpl/login.jsp?tp=$arnumber=936219$url=http%3A%2F%2Fieeexplore.ieee.org%2Fxpls%2Fabs_all.jsp%3Farnumber%3D936219. [Consultado 25 de julio de 2013]         [ Links ].

Holz, Harald. (2000). Process Based Knowledge Management Support of Software Engineering, tesis (Doctorado en ciencias), Alemania, Universität Kaiserslautern, 53 pp. [Online] Disponible en: file:///D:/Users/Usuario/Downloads/00b0c8600cf245659 d00f391%20(1).pdf. [Consultado 4 de septiembre 2013]         [ Links ].

Intille, S.; Kukla, C.; Ma, X. (2002l). Eliciting user preferences using image-based experience sampling and reflection. En: CHI'02 Extended Abstracts on Human Factors in Computing Systems. New york: USA, 738-739. Abril 2002. [Online] Disponible en: http://dl.acm.org/citation.cfm?id=506573. [Consultado 20 de mayo 2013]         [ Links ].

Laguna, M. A.; Marqués, J. M.; Gracía, F. J. (2001). A user requirements elicitation tool. Revista ACM SIGSOFT Software Engineering Notes, 26(2), pp. 35-37. [Online] Diponible en: https://files.ifi.uzh.ch/rerg/amadeus/teaching/courses/re_seminar_fs11/RE_Tools_for_End_Users_final_version.pdf. [Consultado 5 de julio de 2013]         [ Links ].

Land, P. W.; Aurum, A.; Handzic, M. (2001). Capturing implicit software engineering knowledge. En: Software Engineering Conference, 2001. Proceedings. 2001 Sidney: Australian, 108-114 agosto 2001. [Online] Disponible en: http://ieeexplore.ieee.org/xpl/login.jsp?tp=$arnumber=948504$url=http%3A%2F%2Fieeexplore.ieee.org%2Fxpls%2Fabs_all.jsp%3Farnumber%3D948504. [Consultado 6 de abril 2013]         [ Links ].

Macaulay, L. (1996). Requirements for requirements engineering techniques. En: Requirements Engineering, Proceedings of the Second International Conference. Colorado; Estados Unidos, 157-164 abril 1996. [Online] Disponible en: http://ieeexplore.ieee.org/xpl/login.jsp?tp=$arnumber=491440$url=http%3A%2F%2Fieeexplore.ieee.org%2Fxpls%2Fabs_all.jsp%3Farnumber%3D491440. [Consultado 15 de septiembre 2013]         [ Links ].

Maiden, N.; Robertson, S. (2005). Integrating creativity into requirements processes: Experiences with an air traffic management system. En: Requirements Engineering, Proceedings. 13th IEEE International Conference, Washington: USA, 95-104 105-114 agosto 2005. [Online] Disponible en: http://ceit.aut.ac.ir/islab/courses/RE-old/RE%20891127/RE/homework/question/Integrating%20Creativity%20into%20Requirement%20Process.pdf. [Consultado 22 de junio de 2013]         [ Links ].

Miura, N.; Kaiya, H.; Saeki, M. (1995). Building the structure of specification documents from utterances of requirements elicitation meetings. En: Software Engineering Conference Proceedings. Asia Pacific. 64-73 diciembre 1995. [Online] Disponible en: https://pdfs.semanticscholar.org/9fb2/8c79e217542b1816f506d66396401ebd03ca.pdf. [Consultado 22 de Junio de 2013]         [ Links ].

Nuseibeh, B.; Easterbrook, S. (2000). Requirements engineering: a roadmap. En: Proceedings of the Conference on the Future of Software Engineering. Limerick: Ireland, 35-46, junio 2000. [Online] Disponible en: http://www.cs.toronto.edu/~sme/papers/2000/ICSE2000.pdf. [Consultado 11 de julio 2013]         [ Links ].

Potts, C. (2001). Metaphors of Intent. En: IEEE International Symposium on Requirements Engineering. Toronto: Estados Unidos, 31-38, agosto 2001. [Online] Disponible en: http://ieeexplore.ieee.org/xpl/login.jsp?tp=$arnumber=948541$url=http%3A%2F%2Fieeexplore.ieee.org%2Fxpls%2Fabs_all.jsp%3Farnumber%3D948541 [Consultado 1 de agosto 2013]         [ Links ].

Ruiz, M.; España, S.; González, A.; Pastor, O. (2010). Análisis de Comunicaciones como un enfoque de requisitos para el desarrollo dirigido por modelos. En: The VII Taller sobre Desarrollo de Software Dirigido por Modelos (DSDM 2010). Valencia: España, 70-77, septiembre 2010. [Online] Disponible en: http://www.pros.upv.es/ca/Publications/Ruiz_DSDM(2010).pdf. [Consultado 25 de mayo 2013]         [ Links ].

Sommerville, I.; Ransom, J. (2005). An empirical study of industrial requirements engineering process assessment and improvement. En: Journal ACM Transactions on Software Engineering and Methodology (TOSEM) 14(1), New York: USA, 85-117, enero 2005. [Online] Disponible en: http://dl.acm.org/citation.cfm?id=1044837. [Consultado 25 de mayo 2013]         [ Links ].

Sommerville, l.; Sawyer, P. (2005). Ingeniería del Software un enfóque práctico, septima edicion. México DF: McGraw Hill, 2005, pp. 691.         [ Links ]

SWEBOK. (2001). Software Engineering Body of Knowledge, tercera edition. New York, 2001, pp. 103.         [ Links ]

Zapata, C.M.; Carmona, N. (2010). Un modelo de diálogo para la educción de requisitos de software. Revista Dyna, 77(164), pp. 209-219. [Online] Disponible en: http://www.redalyc.org/articulo.oa?id=49620414021 [Consultado 25 de julio de 2014]         [ Links ].

Zayas, P. (2010). La comunicación interpersonal, tesis (Doctorado en Ciencias Psicológicas,), La Habana, Universidad de la Habana, 122 pp. [Online] Disponible en: http://biblioteca.utec.edu.sv/siab/virtual/elibros_internet/55772.pdf. [Consultado 16 de agosto 2013]         [ Links ].