Espanhol (pdf)
Artigo em XML
Referências do artigo
Tradução automática
Enviar este artigo por email
Citado por SciELO 
Citado por Google 
Similares em
SciELO 
Similares em Google 
Permalink
INTRODUCCIÓN
Una de las primeras etapas de las metodologías de desarrollo de software involucra identificar los objetivos concretos, requisitos y características del entorno del negocio; en otras palabras, realizar una elicitación de requisitos (ER). Este proceso de ER se considera como la base para que las etapas siguientes plasmen de manera adecuada y completa las alternativas de solución [1,2]. El proceso de elicitación de requisitos según (i) [3] “es todo sobre aprender y entender las necesidades de los usuarios y de los interesados del proyecto con el objetivo principal de comunicar estas necesidades a los desarrolladores del sistema”, (ii) [1] “es la fase principal enfocada en recopilar y analizar los requerimientos y objetivos deseados para el sistema desde diferentes puntos de vista, y (iii) [4] incluye dentro de sus partes esenciales, información sobre interfaces externas, funciones, requisitos de desempeño, requisitos lógicos de base de datos, restricciones de diseño, atributos del software.
Dentro de la ER, se tienen en cuenta dos elementos principales, los requisitos funcionales y los no funcionales [5]. Para [1] los requisitos funcionales son las acciones que debe realizar el software sin considerar las limitaciones físicas, mientas que los requisitos no funcionales (denominados de aquí en adelante RNF) definirán las propiedades ambientales y las restricciones de implementación relacionadas con el desempeño del producto software. Según [5] los RNF son características tales como usabilidad, flexibilidad, desempeño, operatividad y seguridad. Por otro lado, [6] indican que los RNF limitan el comportamiento y el desarrollo de un producto software especificando los atributos que el sistema resultante debe tener. Además, [7] indican que la funcionalidad es lo que el sistema hace y su no funcionalidad o calidad se refiere a cómo se comporta el sistema frente a atributos observables como desempeño, reusabilidad, confiabilidad, entre otros. Según [8] para lograr la calidad del producto de software se deben cumplir tanto las características funcionales como las no funcionales para permitir cubrir de manera completa las expectativas de los interesados.
Sin embargo, según el estudio sobre el estado del proceso de elicitación de requisitos no funcionales (denominados de aquí en adelante proceso de ERNF), presentado en [9], se concluye que las técnicas utilizadas para realizar este proceso no están aún claras. Además, en [10] se afirma que “aunque existen técnicas bien desarrolladas para obtener requisitos funcionales, hay una falta de mecanismo de elicitación para RNF y no existe un consenso adecuado al respecto de los RNF”. Del mismo modo, en [11] se confirma que los problemas frente a RNF de un sistema representan la complejidad del mismo. Los RNF suelen ser especialmente ignorados debido a que se consideran imposibles de especificar y validar [12]. Por la relevancia descrita anteriormente, es importante la correcta y completa ejecución del proceso ER enfocada en los RNF. En esta misma línea, según [2] para que el equipo de ER sea exitoso requiere un profundo conocimiento del dominio de aplicación, IT y del proceso de elicitación. En este sentido es importante, abordar el tema de identificar, analizar, documentar e integrar los RNF en el proceso ER, de tal manera que se pueda lograr un mayor cubrimiento y cohesión de estos requisitos con el diseño de solución. El objetivo es aportar desde este enfoque a lograr la calidad del producto software.
La manera como se pretende abordar la problemática acerca de la falta de claridad de la elicitación de RNF en las organizaciones desarrolladoras y la falta de participación de los diferentes stakeholders involucrados en este proceso es proponiendo un marco de trabajo para la elicitación de RNF basada en la gestión de conocimiento, el cual se denomina Marco de Trabajo para el ERNF-Merlinn. Este marco de trabajo se ha construido a partir de la integración de conceptos pertenecientes a dos disciplinas específicas: (i) la ER y (ii) la gestión de conocimiento.
La gestión de conocimiento, como disciplina, podría permitir descubrir, analizar y entender la información tácita y explícita que los interesados poseen acerca de los requisitos que se quieren elicitar [13]. Dicho marco se compone de escenarios de aplicabilidad, modelo conceptual, núcleo de transformación de conocimiento, estructura metodológica, dimensiones para la ERNF y un método para la ERNF. El objetivo de este artículo es presentar el marco de trabajo Merlinn, su evaluación mediante la aplicación del mismo en una pequeña empresa desarrolladora de software mediante el método de caso de estudio. Los resultados obtenidos de la evaluación y aplicación de Merlinn muestran que este marco de trabajo puede ser idóneo y adaptable para apoyar la ERNF utilizando la gestión de conocimiento (denominada de aquí en adelante GC).
Además de la presente introducción, en la sección 2 se presenta una vista general del método usado para la construcción y aplicación de Merlinn, y los trabajos relacionados sobre el tema de ERNF. En la sección 3 se describe el marco de trabajo Merlinn y sus componentes. En la sección 4 se presenta la evaluación de Merlinn mediante un caso de estudio real en una pequeña organización desarrolladora de software. Finalmente, en la sección 5 se describen las conclusiones a partir de la experiencia adquirida en la construcción y aplicación del marco de trabajo para la ERNF basada en la GC y se propone el trabajo futuro.
1. ESTRATEGIA DE INVESTIGACIÓN
En esta sección, se presenta la estrategia de investigación para la construcción usada para la construcción y aplicación del marco de trabajo para la ERNF basada en la gestión de conocimiento.
La metodología investigación-acción multi-ciclo con bifurcación presentada por [14] se ha utilizado para la construcción y aplicación de Merlinn. Esta metodología permite gestionar y desarrollar proyectos de investigación en el campo de ingeniería de software a partir de diversos ciclos de investigación que abordan diferentes problemas que se presentan a lo largo del desarrollo del proyecto (figura 1).
Esta estrategia está compuesta de los siguientes ciclos y actividades de investigación:
Ciclo conceptual: análisis conceptual. (i) Identificar el problema: se analizó el estado del proceso de ERNF dentro de la ER y su impacto sobre el proceso de desarrollo de software dentro de las organizaciones. (ii) Estudio de la literatura: se revisaron las características de calidad que se tienen en cuenta dentro del proceso de ERNF y se analiza la literatura existente con respecto a los mecanismos y técnicas utilizadas para realizar el proceso de ER de RNF.
Ciclo metodológico: definición del marco de trabajo. (i) Identificar componentes: Se revisaron y analizaron los componentes que se deben contemplar para el proceso de ER de RNF basado en referentes de la literatura y los componentes de la GC que aportan en la identificación y definición de los componentes del marco de trabajo Merlinn. (ii) Definición de los componentes del marco de trabajo: los componentes identificados se construyeron y relacionaron como elementos constitutivos del marco de trabajo.
Ciclo de evaluación: evaluación del marco de trabajo. Se realizó la evaluación del marco de trabajo propuesto mediante el método estudio de caso [15]. El estudio de caso fue de tipo simple-holístico en una organización software, y sus actividades se describen a continuación: (i) diseño del estudio: se establecieron los objetivos del estudio de caso y se realizó el diseño del mismo; (ii) realización del estudio: se preparó la actividad de recolección de datos y se recogió la evidencia de la intervención de la organización con el marco de trabajo propuesto, y (iii) análisis y conclusiones: se analizaron los resultados obtenidos en el estudio de caso.
2. TRABAJOS RELACIONADOS
A continuación, se presenta un resumen de los aportes más relevantes encontrados partir de un mapeo sistemático realizado (siguiendo la propuesta presentada en [16]) sobre la manera en que se aborda la GC dentro del proceso de ERNF (tabla 1). Cada propuesta se describe en términos de tipo de contribución, el aporte, la forma en que aborda el conocimiento y su fundamento.
Tabla 1 Consolidado de propuestas
| Ref. | TC | Aporte | Forma en que aborda el conocimiento | Fundamentada en |
| [22] | H | Soportar el proceso de ER desde la práctica, incluyendo el proceso de priorización de requisitos | Definición de ontología de RNF a partir de la norma 9126 y combinándola con técnicas de gestión de conocimiento. | Ontología y conocimiento en la norma 9126 |
| [23] | H | Orientación a producto y al proceso de ERNF, para apoyar en el la definición y análisis de los RNF haciendo uso del conocimiento a través de ontologías y web semántica (catálogos) | Reutilización del conocimiento de RNF definidos anteriormente para aumentar las alternativas de requisitos a implementar. | Ontología y Reutilización del conocimiento |
| [24] | PM | Relacionar funcional y no funcionalmente, a través de capas, las variables y contextos tecnológicos con variables y abstracciones clínicas | Las variables son dimensiones de calidad que se relacionan y descomponen de manera jerárquica para lograr un afinamiento de los requisitos de calidad (RNF). | Jerarquía y Capas relacionadas y afinamiento del conocimiento |
| [25] | PM | Asegurar los requisitos de calidad a partir del documento de especificación usando técnicas de text-mining y un diccionario de conceptos | Definición de requisitos de calidad (RNF) basado en la norma 9126. | Documento de especificación y conocimiento en la norma 9126 |
| [26] | PM | Soportar el proceso de ingeniería de requerimientos para colaboración , participación y negociación de los REQ soportándose en el método del prototipado rápido para desarrollos | Niveles de conocimiento, que se combina, disemina e intercambia entre los stakeholders dentro de un contexto (conocimiento implícito del trabajo), el cual debe ser conocido y entendido por los ingenieros de requisitos. | Prototipado e intercambio de conocimiento |
| [27] | E | Clasificación de los enfoques de RNF haciendo un análisis multi-dimensional | Analizar los enfoques del proceso de ERNF desde las dimensiones del contexto, proceso y la aplicación. | Análisis multidimensional de Enfoques existentes |
| [28] | E | Conocer desde la perspectiva de los arquitectos de software, cómo se obtienen los RNF | Cualidades externas e internas del software. ¿Quién decide los RNF, qué tipos de RNF importan a arquitectos, cómo se documentan los RNF y cómo se validan? | Perspectiva de los arquitectos y cualidades del software |
| [29] | H | Soportar la obtención de requisitos tempranos, apoyando en su trazabilidad desde diferentes dominios | Tiene en cuenta el conocimiento de los stakeholders para iniciar el proceso de modelado visual. | Trazabilidad de requisitos tempranos y modelado visual |
| [30] | H | Soportar un enfoque lógico para los RNF basado en el concepto de soft-gold. | Uso de formalización para representar los RNF. | Soft-gold y representación de los requisitos |
| [31] | PM | Identificar los RNF, elicitarlos y analizarlos. Metodología orientada a objetos de UML, bajo el diagrama de casos de uso. | El conocimiento sobre los RNF está dentro del documento de especificación. | Metodología UML y documento de especificación |
| [32] | H | Identificar los RNF para su re utilización. Proponen el framework NDR basado en conocimiento y varias ontologías previamente propuestas en otras investigaciones. | El conocimiento tiene como base unas ontologías a partir de las cuales la herramienta busca las correlaciones y descomposiciones respectivas. | Ontología y reutilización de RNF. |
TC: Tipo de contribución (H: Herramienta, PM: Propuesta metodológica, E: Estudio)
Fuente: elaboración propia
De acuerdo con los resultados obtenidos del mapeo sistemático se puede concluir que no se evidencian trabajos de investigación que integren elementos de GC (tales como flujos de conocimiento, escenarios de transformación de conocimiento, rutas de transformación, entre otros) con el proceso de ERNF. De esta manera, en este artículo se pretende aportar a la ingeniería de requisitos un marco de trabajo para la realización del proceso de ERNF usando la GC desde las etapas tempranas de este proceso con el fin de evitar la generación de problemas en las organizaciones como: (i) la falta de participación activa y dinámica de los usuarios, (ii) la no definición de los RNF, y (iii) la ausencia del conocimiento como activo organizacional. También se desea fortalecer el grado de conciencia en el entorno organizacional para adoptar la perspectiva de GC en sus procesos de ERNF.
3. MARCO DE TRABAJO PARA LA ERNF BASADA EN LA GESTIÓN DE CONOCIMIENTO- MERLINN
El marco de trabajo Merlinn es construido conceptualmente basándose en la disciplina de GC para poder abordar los RNF en un proceso de ERNF. El uso y ERNF se pueden dar en los siguientes escenarios del proceso de desarrollo de software: Los RNF i) son considerados importantes y necesarios para el proceso de desarrollo del producto, ii) no son conocidos o no son aún concretos, iii) no son entendidos por todos los involucrados en el proceso de ER, o iv) no tiene el mismo significado para todos dentro de un contexto específico. Merlinn define un modelo conceptual (figura 2) que permite integrar de manera correlativa el conocimiento sobre los RNF con los stakeholders involucrados dentro del proceso de ER. Los stakeholders hacen referencia a los roles involucrados en el proceso de ERNF para la identificación y validación de este tipo de requisitos, entre los que se incluyen: (i) usuarios finales del sistema de información en diferentes rangos de autoridad y responsabilidad (operativos, y jefes de área), y (ii) usuarios técnicos que definen, configuran, controlan y monitorizan la infraestructura requerida para el sistema de información.
El esquema general de este marco de trabajo consideró propuestas disponibles de las áreas de (i) ER, con el fin de construir un proceso para tal fin de manera que luego de ejecutarlo su resultado final sea la especificación de los RNF del producto software documentados y aprobados por el usuario final, y (ii) Gestión de Conocimiento buscando organizar y comunicar los conocimientos individuales y colectivos sobre RNF involucrados dentro del proceso de ERNF. La columna vertebral del Modelo conceptual de Merlinn es el núcleo de transformación del conocimiento en el proceso de elicitación (núcleo TCER), el cual propone las formas de transformación del conocimiento durante la ERNF y es la base para la construcción de los componentes del método para la ERNF el cual permitirá la instrumentalización final del marco de trabajo Merlinn en las organizaciones. Los componentes de Merlinn son: el núcleo TCER, las dimensiones para la ERNF y el método para la ERNF. A continuación, se describe cada uno de estos componentes.
3.1 Núcleo conceptual TCER
El núcleo conceptual denominado TCER está fundamentado en el modelo SECI [17], y describe la dinámica de transformación del conocimiento frente a los requisitos no funcionales en un proceso de ERNF (no describe un flujo de trabajo de este proceso). Esta dinámica de transformación permite lograr un conocimiento adoptado, reconocido y explícito de los RNF dentro de la organización. La figura 3 describe los diferentes componentes del núcleo combinando notación de SPEM 2.0, SPEM-KF extendido con flujos de conocimiento y gráfica rica adaptada.
La transformación de conocimiento frente a los RNF inicia cuando el elicitador contextualiza a los stakeholders, por medio de la socialización, sobre lo que son, la importancia, los efectos y las posibles maneras de identificar los RNF para el producto software a desarrollar. En este momento, el conocimiento tácito del usuario es menor frente al grado de conocimiento tácito del elicitador con respecto a los RNF; el usuario omite estos aspectos durante el proceso de elicitación, por lo tanto, desconoce los RNF, mientras que el elicitador ya cuenta con determinada formación y experiencia sobre la existencia de ellos y la importancia de especificarlos.
A medida que se realiza esta transferencia de conocimiento, el usuario adquiere nuevo conocimiento entendiendo e interiorizando los conceptos, importancia, propósitos y formas de identificar los RNF. Asimismo, el elicitador obtiene información para ir concretando los RNF determinados por el usuario. Al terminar estas actividades iniciales de elicitación (relacionadas con la socialización), el elicitador expone el conocimiento obtenido en un documento de especificación de RNF (externalización) el cual podrá ser complementado con conocimientos de apoyo dispuestos en otros documentos de ingeniería de requisitos o documentos de RNF de otros proyectos anteriores (combinación).
Otra manera de combinar conocimiento consiste en completar los RNF a través de la elicitación con los usuarios técnicos involucrados en el proceso. Cuando se termina este proceso de identificación y recolección de RNF se comparte la especificación de RNF con los usuarios finales y usuarios técnicos para que ejecuten la validación.
3.2 Dimensiones para la ERNF basada en la gestión de conocimiento
Para gestionar el conocimiento de RNF involucrado en el proceso de ERNF, Merlinn propone tres dimensiones de manera que se logra una integración efectiva y totalmente incluyente entre ellas: i) dimensión de conocimiento, ii) dimensión organizacional y iii) dimensión técnica. A continuación, se hace una breve descripción de cada una de estas dimensiones:
Dimensión de conocimiento (DC): incluye componentes esenciales de la GC para ser usados en los procesos clave de GC propuesto por Merlinn, de manera que a través de la aplicación de estos componentes se logre la implementación del proceso de ERNF desde la perspectiva de la GC. Los componentes de esta dimensión son: (i) nivel de conocimiento (NC), el cual caracteriza los diferentes niveles de conocimiento (principiante, competente, experto y maestro, los cuales han sido adaptados de [18]) que poseen los individuos frente a los RNF en una organización, y (ii) flujo de conocimiento (FC), el cual permite modelar los procesos de transformación del conocimiento desde un estado tácito a explícito o desde un conocimiento menos explícito a uno de mayor explicitud frente a los RNF (los flujos de conocimiento de Merlinn se presentan entre los procesos de socialización, exteriorización, combinación e interiorización, según el modelo SECI [17]).
Dimensión organizacional (DO): incluye componentes que permiten consolidar la información relevante para los procesos de GC en una organización, a partir de los siguientes aspectos: (i) formas y grado de implementación de la GC de los RNF en los proyectos software, el cual permite descubrir si en las organizaciones existe alguna forma de gestión de conocimiento y su grado de aplicación, (ii) formas de comunicación organizacional que permitan apoyar la transferencia del conocimiento de los RNF de manera masiva y ágil entre los involucrados del proyecto, así como de la comunicación que se da entre otros empleados dentro de la organización mediante canales de comunicación adicionales y externos al proyecto, (iii) características de las stakeholders implicados en el proceso de desarrollo del producto software, el cual permite identificar si el proyecto, dentro del contexto de la organización, tiene diferentes tipos de stakeholders, tales como usuarios finales, usuarios de dirección, y usuarios técnicos, y (iv) procesos de negocio involucrados en el dominio de aplicación, el cual permite identificar los procesos de negocio involucrados en el alcance del proyecto y que pertenecen al dominio de la aplicación. En este ítem se logra identificar las interfaces que deben contemplarse dentro del proyecto de desarrollo.
Dimensión técnica (DT): incluye el conjunto de procesos técnicos para realizar la ERNF basada en la GC (figura 4), dentro de un contexto específico de la organización. Estos procesos se basan en el estándar ISO 12207 [19] y han sido adaptados específicamente a la ERNF y, adicionalmente, desde la perspectiva de la GC se identifican los RNF; se elabora la especificación de RNF; se valida la especificación, se negocian y priorizan los RNF, y se publica la especificación.
3.3 Método para la ERNF basado en GC
Los diferentes aspectos descritos en las dimensiones son recolectados y usados a través de la ejecución de un método para la ERNF, que se ha definido en el interior de Merlinn (figura 4), el cual consta de tres tipos de procesos: i) Procesos de gestión organizacional, ii) Procesos clave de la gestión de conocimiento y iii) Procesos técnicos.
Este método inicia con los procesos de diagnóstico empresarial (DE) e identificación de stakeholders (IS) con el propósito de conocer el estado inicial de la organización frente a los mecanismos de GC que tiene implementados, la complejidad del dominio de la aplicación a desarrollar y los tipos de interesados involucrados en el proyecto. Las salidas principales de este grupo de procesos son: tamaño y tipo de la organización, mecanismos de almacenamiento de la información, lista de procesos de negocio involucrados y lista de mecanismos de comunicación utilizados por los stakeholders dentro de la organización.
A partir de esta información, la cual se convierte en entrada para el segundo grupo de procesos (los procesos clave de gestión de conocimiento), se define la estrategia de GC (DEGC) y se planea la estrategia de GC (PEGC) la cual será implementada en la organización de acuerdo con las necesidades específicas del contexto organizacional. Las actividades planeadas pertenecientes a la estrategia de GC definida serán aplicadas (DESGC) durante la ejecución del proceso técnico de ERNF (identificación, elaboración de especificación, validación, negociación y priorización, y publicación de los RNF), logrando transformaciones de conocimiento tácito a explícito, y viceversa, acerca de los RNF acorde con la estrategia. Finalmente, se deberán desarrollar las actividades planeadas de monitorización y control de la estrategia de GC definidas previamente (PEGC) para que se garantice su correcta y completa ejecución de manera que en caso de ser necesario se realicen acciones preventivas o correctivas a las desviaciones. La aplicación de este método posibilita a las organizaciones a planear y ejecutar nuevas iteraciones de gestión de conocimiento frente a los RNF. Para apoyar la ejecución del método, Merlinn sugiere el uso de instrumentos que permiten la captura de la información relevante, desde la perspectiva de GC, para cada proceso específico que lo constituye. Estos instrumentos se muestran en la tabla 2. El marco de trabajo se puede consultar en detalle en [20].
Durante el proceso de desarrollo de la estrategia de gestión de conocimiento (DESGC) se hace uso del núcleo de transformación TCER a través de los diferentes escenarios de transformación que ocurren en la ERNF: i) escenario de instauración del conocimiento (EIC), ii) escenario de configuración del conocimiento (ECC), iii) escenario de afianzamiento del conocimiento (EAC) y iv) escenario de institucionalización del conocimiento (EITC). A continuación, se describe cada uno de estos escenarios.
Luego de que se ejecutan los diferentes escenarios de transformación de conocimiento, Merlinn permite alcanzar el objetivo de implantar y / o aumentar Ia interiorización acerca de los RNF a través de socialización, exteriorización y combinación. Además, el marco propuesto conlleva un proceso de implantación de la GC en las organizaciones como estrategia aplicable al contexto de la ingeniería de software.
El marco de trabajo adiciona, a la propuesta del modelo SECI, caminos nuevos para transformación de conocimiento acordes con las dinámicas organizacionales que pueden darse en los procesos de ERNF: i) Ruta S-E que permite lograr un primer componente explícito del proceso de transformación de conocimiento de RNF; ii) Ruta E-C, la cual es unidireccional, que permite lograr conocimiento explícito de combinación; iii) Ruta E-I-C, la cual es unidireccional que permite una nueva forma de combinación de conocimiento que no está en estado explícito, es decir, que permanecen tácitos en el individuo; iv) Ruta E-I, que soporta la consolidación del conocimiento, la cual ocurre en dos momentos: a) cuando los usuarios finales confirmar lo que saben y entienden por un RNF determinado al momento de la validación de la especificación de estos requisitos, y b) cuando el elicitador presenta el conocimiento que se está exteriorizando a los demás involucrados, puesto que exige una validación, corrección, complemento y confirmación de estos requisitos. Esta ruta es otra alternativa que permite al individuo aumentar el grado de interiorización de RNF a partir de un conocimiento explícito base (figura 5).
Partiendo del supuesto de que: “Mayor necesidad de transformación del conocimiento de tácito a explícito de los RNF, involucra mayor cantidad de flujos de transformación de los procesos de socialización, exteriorización, combinación e interiorización en el proceso de ERNF”, se determinan los escenarios que serán utilizados en la definición de la estrategia de gestión de conocimiento (EGC) que propone Merlinn. Esta estrategia se enfoca en determinar y guiar el desarrollo de las actividades técnicas de ERNF desde la perspectiva de la GC, de manera que se logre un mayor conocimiento explícito de este tipo de requisitos a partir de los diferentes elementos de conocimiento de la organización identificados a través de las diferentes dimensiones.
4. EVALUACIÓN Y ESTUDIO DE CASO DE MERLINN
En esta sección, se detalla la validación preliminar de Merlinn mediante su aplicación en una pequeña empresa desarrolladora de software usando el método de estudio de caso. En la figura 6 se muestran los roles que fueron definidos para el proceso de aplicación de Merlinn, así como las actividades generales que los participantes debían realizar durante el proceso de intervención.
Fuente: elaboración propia
Figura 6 Roles y actividades generales de la aplicación de Merlinn en la empresa
Esta validación preliminar ha seguido la plantilla protocolo para planeación de estudio de caso en términos de antecedentes, diseño, selección del caso y sujetos de investigación, intervención, recolección de datos, análisis y limitaciones.
Antecedentes
El objeto del estudio de caso es el marco de trabajo para la ERNF basada en gestión de conocimiento (Merlinn), y más específicamente su núcleo TCER usado en 3 proyectos diferentes de una organización de desarrollo de software con el fin de evaluar qué ocurre con el conocimiento acerca de los RNF y cómo este conocimiento se va transformando durante el proceso de elicitación. Las preguntas de investigación principales y adicionales que apoyan este mecanismo de validación preliminar se describen en la tabla 7.
Diseño
Tomando en cuenta el enfoque presentado en [15], el tipo de diseño del caso de estudio para este trabajo es simple-embebido, ya que Merlinn ha sido aplicado en el contexto de una empresa con el objetivo de intervenir el proceso de ER en tres proyectos (unidades de análisis diferentes: UA1, UA2 y UA3). El objeto de estudio es Merlinn. Las medidas usadas para indagar sobre las preguntas de investigación son: i) número total de RNF especificados, (ii) número de instrumentos para la GC propuestos por Merlinn usados por las unidades de análisis, y (iii) número de stakeholders involucrados en el proceso de ERNF. Estas métricas fueron tomadas a través de tres mecanismos: (i) aspectos identificados durante la ejecución del proceso de intervención, (ii) resultados de las plantillas e instrumentos que ofrece el marco de trabajo para su aplicación, y (iii) realización de una encuesta final a los equipos involucrados en la evaluación buscando obtener información cuantitativa y cualitativa acerca del proceso de ERNF llevado a cabo en la organización.
Selección del caso y sujetos de investigación
El criterio para la selección del estudio de caso fue una empresa del sector de desarrollo de software donde sus productos sean a la medida (especializados) que permitieran ejecutar un proceso de ERNF con la participación del cliente (usuarios finales del sistema de información) y que estuviera en disposición de utilizar Merlinn. La empresa partícipe del estudio de caso tiene 12 empleados, con 3 años de experiencia de trayectoria empresarial y se dedica al desarrollo de software a la medida y estaba ejecutando en ese momento 6 proyectos de desarrollo.
En cuanto a los sujetos de investigación, el equipo de investigación estuvo compuesto por (i) un asesor del proceso de investigación, experto en ERNF para productos software quien contextualiza acerca del objetivo de la investigación, y guía la ERNF con las diferentes unidades de análisis seleccionadas, (ii) tres equipos técnicos de la empresa (quienes realizan diferentes roles), uno para cada unidad de análisis quienes debían realizar las actividades referentes a la identificación de RNF, negociación y priorización de los RNF y elaboración de la especificación de RNF haciendo uso de los instrumentos propuestos por Merlinn, (iii) grupo de usuarios finales (operarios y jefes de áreas) con quienes los elicitadores realizarían el proceso de ERNF.
Intervención
Durante este proceso fue necesario realizar diferentes actividades para la aplicación de Merlinn en la empresa, entre las más destacadas: (i) contextualización de la propuesta, (ii) capacitación detallada de Merlinn y RNF, (iii) elaboración de especificaciones para los proyectos, y (iv) cierre del proceso. Además, el asesor apoyó la solución de las dudas sobre Merlinn que les surgieron a los diferentes responsables de la ERNF de los proyectos (unidades de análisis) durante su utilización con el fin de que alcanzaran un conocimiento concreto sobre el marco propuesto y sobre RNF que les permitiera, junto con los usuarios finales, identificar los RNF, los cuales quedaron registrados en las especificaciones de cada proyecto. Durante el proceso de intervención en la organización participante del estudio de caso las medidas planeadas para la investigación fueron recolectadas al finalizar el proceso de ERNF.
Recolección de datos
Los datos se recolectaron a través de los mecanismos definidos previamente y se analizan en la siguiente sección. La tabla 8 presenta el número de RNF identificados en el proceso de elicitación de cada proyecto; en las tablas 9 y 10 se detalla la granularidad de dos de los RNF que obtuvieron mayor número de características no funcionales elicitadas durante la intervención (eficiencia de desempeño y usabilidad), y la tabla 11 muestra el consolidado de las respuestas obtenidas a través de la encuesta realizada a las 5 personas de la empresa que participaron en la utilización y aplicación de Merlinn (donde la escala fue de 0 a 5, siendo 0 el menor valor). Además, los 5 encuestados coincidieron en que Merlinn: aporta al proceso de ERNF, está descrito con claridad lo cual facilita su aplicación en la práctica, y será utilizado para futuros proyectos de la empresa.
Tabla 9 Ejemplos detallados de características elicitadas frente a eficiencia de desempeño
| RNF Eficiencia | UA1 | UA2 | UA3 | Totales |
| Tiempo de cargue/consultas de información | 5 | 16 | 21 | |
| Tiempo de obtención de cálculos y/o resultados | 2 | 2 | ||
| Tiempo de almacenamiento en base de datos | 2 | 2 | ||
| Tiempo de ingreso a aplicativo | 1 | 1 | ||
| Tiempo de operación en datos (eliminar, modificar, exportar, crear, registrar) | 9 | 9 | ||
| Totales RNF Eficiencia por unidad de análisis | 5 | 20 | 10 | 35 |
Fuente: elaboración propia
Tabla 10 Ejemplos detallados de características elicitadas frente a usabilidad
| RNF Usabilidad | UA1 | UA2 | UA3 | Totales |
| Plataforma intuitiva y de fácil uso | 8 | 7 | 14 | 29 |
| Ordenamiento de información visual según criterios | 4 | 4 | ||
| Definición de información opcional | 1 | 1 | ||
| Mecanismos de exportación de datos | 1 | 1 | ||
| Mecanismos de filtrado de información | 2 | 2 | ||
| Totales RNF Usabilidad por unidad de análisis | 8 | 15 | 23 | 46 |
Fuente: elaboración propia
Tabla 11 Medidas obtenidas a través de las encuestas
| Calificaciones a las características de Merlinn a través de las encuestas | E1 | E2 | E3 | E4 | E5 | Promedio |
| Flexibilidad | 5 | 4 | 4 | 5 | 4 | 4,4 |
| Capacidad de ajustarse a la dinámica del proyecto | 4 | 4 | 4 | 5 | 4 | 4,2 |
| Conveniencia de uso para el proceso de ERNF | 5 | 5 | 5 | 4 | 5 | 4,8 |
| Suficiencia para el logro de los objetivos (especificar los RNF) | 5 | 5 | 5 | 5 | 4 | 4,8 |
| Utilidad en el proceso de ERNF | 4 | 5 | 5 | 4 | 5 | 4,6 |
Fuente: elaboración propia
Análisis
A continuación, se describen los resultados de la aplicación de Merlinn en el estudio de caso a través de tres aspectos:
En un primer aspecto, acerca de la GC aplicada en el estudio de caso, se evidencia que las unidades de análisis UA1 y UA3 aplicaron el 83% de los instrumentos propuestos por Merlinn, y la unidad de análisis UA2 aplicó el 66% de los instrumentos del marco.
En un segundo aspecto, acerca de la especificación de RNF luego de usar los instrumentos propuestos por el marco de trabajo Merlinn, se evidencia que el total de RNF identificados por las 3 unidades de análisis fue de 132 RNF, de los cuales el 15% fueron elicitados por la UA1, 48% elicitados por la UA2 y un 37% elicitados por la UA3. Los RNF elicitados por las unidades de análisis correspondieron en un 35% a RNF referentes a la usabilidad del sistema de información, un 27% de los RNF elicitados referentes a la eficiencia de desempeño del sistema de información seguidos por RNF referentes a la seguridad del sistema de información con una participación del 20% del total de RNF elicitados (respuesta a la pregunta adicional número 1).
En un tercer aspecto, relacionado con los resultados obtenidos a partir de la encuesta diligenciada por los participantes, se evidencia que Merlinn es un marco de trabajo: (i) con capacidad de adaptabilidad a diferentes dinámicas de proyectos de desarrollo de software, (ii) suficiente para la ERNF, lo cual sugiere que la estructura, actividades propuestas e instrumentos para su aplicación permiten lograr la especificación de RNF de manera efectiva, y (iii) que permite aumentar el conocimiento sobre RNF de los involucrados en el proceso de elicitación y el conocimiento de aspectos ligados con arquitectura e infraestructura de los sistemas de información (respuesta a la pregunta adicional número 1 y número 2).
Basado en que: (i) la utilización de componentes de GC de Merlinn, tales como procesos clave de GC, los flujos de conocimiento, los escenarios y las rutas de transformación de conocimiento, ha permitido la especificación de RNF durante el proceso de elicitación, (ii) los RNF elicitados en los diferentes proyectos, (iii) la adquisición e incremento del conocimiento sobre RNF de los stakeholders involucrados en el proceso de elicitación, (iv) los beneficios descritos por los involucrados durante el proceso de intervención y (v) las experiencias recopiladas durante el estudio de caso, se puede considerar que hay evidencia para considerar que el Marco de trabajo para la ERNF basada en GC - Merlinn es idóneo para la ERNF de un producto software (respondiendo así a la pregunta de investigación principal).
Pese a que la investigación tiene un enfoque de requisitos no funcionales, estos resultados sugieren que podría extenderse el uso de Merlinn al proceso de elicitación de requisitos funcionales dado que, para el caso de la elicitación de este tipo de requisitos, también se requiere la identificación y entendimiento de las necesidades funcionales a partir del conocimiento tácito que tienen los interesados.
Limitaciones del estudio
La generalización de los resultados obtenidos se limitó por el tamaño de la población, por más que este tipo de empresa es común en la industria del software de Iberoamérica.
Los RNF elicitados se limitó por (i) una ejecución no natural del proceso de elicitación por parte de los participantes al sentirse observados por el asesor, (ii) una experiencia restringida frente a participación en proyectos de desarrollo de software, (iii) un desconocimiento de aspectos relacionados con infraestructura tecnológica y gestión de conocimiento, y (iv) un conocimiento parcial acerca de requisitos no funcionales.
CONCLUSIONES Y TRABAJO FUTURO
En este artículo se ha presentado un marco de trabajo denominado Merlinn, el cual hace uso de elementos de gestión de conocimiento, para la ERNF. Este marco de trabajo está compuesto por diferentes componentes que permiten gestionar el conocimiento involucrado en las diferentes etapas técnicas del proceso de ER. Merlinn ha sido evaluado mediante un estudio de caso aplicando Merlinn en un caso real de una empresa desarrolladora de software. Los resultados obtenidos evidencian que Merlinn: (i) apoya la adquisición de conocimiento acerca de RNF para convertirse en activo organizacional, (ii) es útil, adaptable e idóneo para la ERNF. Desde la perspectiva del conocimiento, Merlinn permite: (a) aumentar la participación de los stakeholders y (b) dar mayor claridad a los RNF. La estrategia de aplicar la GC al proceso de ERNF sugiere la posibilidad de que Merlinn pueda ser extendido a otros procesos de la ingeniería.
Como trabajo futuro se pretende fortalecer el proceso de validación de RNF, utilizar a Merlinn como herramienta de apoyo a una metodología para la calidad de los productos software, aplicar Merlinn en organizaciones al nivel nacional que permitan generalizar los resultados y construir una herramienta tecnológica que apoye su aplicación.
