Printer Friendly

Elicitacion de requisitos no funcionales basada en la gestion de conocimiento: el marco de trabajo Merlinn/Non-Functional Requirements Tendering Based on Knowledge Management: the Merlinn Framework/Elicitacao de requisitos nao funcionais baseada na gestao de conhecimento: o referencial de trabalho Merlinn.

INTRODUCCION

Una de las primeras etapas de las metodologias de desarrollo de software involucra identificar los objetivos concretos, requisitos y caracteristicas del entorno del negocio; en otras palabras, realizar una elicitacion 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 solucion [1, 2]. El proceso de elicitacion de requisitos segun (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, informacion sobre interfaces externas, funciones, requisitos de desempeno, requisitos logicos de base de datos, restricciones de diseno, 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 fisicas, mientas que los requisitos no funcionales (denominados de aqui en adelante RNF) definiran las propiedades ambientales y las restricciones de implementacion relacionadas con el desempeno del producto software. Segun [5] los RNF son caracteristicas tales como usabilidad, flexibilidad, desempeno, 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. Ademas, [7] indican que la funcionalidad es lo que el sistema hace y su no funcionalidad o calidad se refiere a como se comporta el sistema frente a atributos observables como desempeno, reusabilidad, confiabilidad, entre otros. Segun [8] para lograr la calidad del producto de software se deben cumplir tanto las caracteristicas funcionales como las no funcionales para permitir cubrir de manera completa las expectativas de los interesados.

Sin embargo, segun el estudio sobre el estado del proceso de elicitacion de requisitos no funcionales (denominados de aqui en adelante proceso de ERNF), presentado en [9], se concluye que las tecnicas utilizadas para realizar este proceso no estan aun claras. Ademas, en [10] se afirma que "aunque existen tecnicas bien desarrolladas para obtener requisitos funcionales, hay una falta de mecanismo de elicitacion 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 ejecucion del proceso ER enfocada en los RNF. En esta misma linea, segun [2] para que el equipo de ER sea exitoso requiere un profundo conocimiento del dominio de aplicacion, IT y del proceso de elicitacion. 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 cohesion de estos requisitos con el diseno de solucion. El objetivo es aportar desde este enfoque a lograr la calidad del producto software.

La manera como se pretende abordar la problematica acerca de la falta de claridad de la elicitacion de RNF en las organizaciones desarrolladoras y la falta de participacion de los diferentes stakeholders involucrados en este proceso es proponiendo un marco de trabajo para la elicitacion de RNF basada en la gestion de conocimiento, el cual se denomina Marco de Trabajo para el ERNF-Merlinn. Este marco de trabajo se ha construido a partir de la integracion de conceptos pertenecientes a dos disciplinas especificas: (i) la ER y (ii) la gestion de conocimiento.

La gestion de conocimiento, como disciplina, podria permitir descubrir, analizar y entender la informacion tacita y explicita que los interesados poseen acerca de los requisitos que se quieren elicitar [13]. Dicho marco se compone de escenarios de aplicabilidad, modelo conceptual, nucleo de transformacion de conocimiento, estructura metodologica, dimensiones para la ERNF y un metodo para la ERNF. El objetivo de este articulo es presentar el marco de trabajo Merlinn, su evaluacion mediante la aplicacion del mismo en una pequena empresa desarrolladora de software mediante el metodo de caso de estudio. Los resultados obtenidos de la evaluacion y aplicacion de Merlinn muestran que este marco de trabajo puede ser idoneo y adaptable para apoyar la ERNF utilizando la gestion de conocimiento (denominada de aqui en adelante GC).

Ademas de la presente introduccion, en la seccion 2 se presenta una vista general del metodo usado para la construccion y aplicacion de Merlinn, y los trabajos relacionados sobre el tema de ERNF. En la seccion 3 se describe el marco de trabajo Merlinn y sus componentes. En la seccion 4 se presenta la evaluacion de Merlinn mediante un caso de estudio real en una pequena organizacion desarrolladora de software. Finalmente, en la seccion 5 se describen las conclusiones a partir de la experiencia adquirida en la construccion y aplicacion del marco de trabajo para la ERNF basada en la GC y se propone el trabajo futuro.

1. ESTRATEGIA DE INVESTIGACION

En esta seccion, se presenta la estrategia de investigacion para la construccion usada para la construccion y aplicacion del marco de trabajo para la ERNF basada en la gestion de conocimiento.

La metodologia investigacion-accion multi-ciclo con bifurcacion presentada por [14] se ha utilizado para la construccion y aplicacion de Merlinn. Esta metodologia permite gestionar y desarrollar proyectos de investigacion en el campo de ingenieria de software a partir de diversos ciclos de investigacion que abordan diferentes problemas que se presentan a lo largo del desarrollo del proyecto (figura 1).

Esta estrategia esta compuesta de los siguientes ciclos y actividades de investigacion:

* Ciclo conceptual: analisis conceptual. (i) Identificar el problema: se analizo 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 caracteristicas de calidad que se tienen en cuenta dentro del proceso de ERNF y se analiza la literatura existente con respecto a los mecanismos y tecnicas utilizadas para realizar el proceso de ER de RNF.

* Ciclo metodologico: definicion 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 identificacion y definicion de los componentes del marco de trabajo Merlinn. (ii) Definicion de los componentes del marco de trabajo: los componentes identificados se construyeron y relacionaron como elementos constitutivos del marco de trabajo.

* Ciclo de evaluacion: evaluacion del marco de trabajo. Se realizo la evaluacion del marco de trabajo propuesto mediante el metodo estudio de caso [15]. El estudio de caso fue de tipo simple-holistico en una organizacion software, y sus actividades se describen a continuacion: (i) diseno del estudio: se establecieron los objetivos del estudio de caso y se realizo el diseno del mismo; (ii) realizacion del estudio: se preparo la actividad de recoleccion de datos y se recogio la evidencia de la intervencion de la organizacion con el marco de trabajo propuesto, y (iii) analisis y conclusiones: se analizaron los resultados obtenidos en el estudio de caso.

2. TRABAJOS RELACIONADOS

A continuacion, se presenta un resumen de los aportes mas relevantes encontrados a partir de un mapeo sistematico 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 terminos de tipo de contribucion, el aporte, la forma en que aborda el conocimiento y su fundamento.

De acuerdo con los resultados obtenidos del mapeo sistematico se puede concluir que no se evidencian trabajos de investigacion que integren elementos de GC (tales como flujos de conocimiento, escenarios de transformacion de conocimiento, rutas de transformacion, entre otros) con el proceso de ERNF. De esta manera, en este articulo se pretende aportar a la ingenieria de requisitos un marco de trabajo para la realizacion del proceso de ERNF usando la GC desde las etapas tempranas de este proceso con el fin de evitar la generacion de problemas en las organizaciones como: (i) la falta de participacion activa y dinamica de los usuarios, (ii) la no definicion de los RNF, y (iii) la ausencia del conocimiento como activo organizacional. Tambien 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 GESTION DE CONOCIMIEN-TO-MERLINN

El marco de trabajo Merlinn es construido conceptualmente basandose 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 aun 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 especifico. 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 identificacion y validacion de este tipo de requisitos, entre los que se incluyen: (i) usuarios finales del sistema de informacion en diferentes rangos de autoridad y responsabilidad (operativos, y jefes de area), y (ii) usuarios tecnicos que definen, configuran, controlan y monitorizan la infraestructura requerida para el sistema de informacion.

El esquema general de este marco de trabajo considero propuestas disponibles de las areas de (i) ER, con el fin de construir un proceso para tal fin de manera que luego de ejecutarlo su resultado final sea la especificacion de los RNF del producto software documentados y aprobados por el usuario final, y (ii) Gestion 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 nucleo de transformacion del conocimiento en el proceso de elicitacion (nucleo TCER), el cual propone las formas de transformacion del conocimiento durante la ERNF y es la base para la construccion de los componentes del metodo para la ERNF el cual permitira la instrumentalizacion final del marco de trabajo Merlinn en las organizaciones. Los componentes de Merlinn son: el nucleo TCER, las dimensiones para la ERNF y el metodo para la ERNF. A continuacion, se describe cada uno de estos componentes.

3.1 Nucleo conceptual TCER

El nucleo conceptual denominado TCER esta fundamentado en el modelo SECI [17], y describe la dinamica de transformacion del conocimiento frente a los requisitos no funcionales en un proceso de ERNF (no describe un flujo de trabajo de este proceso). Esta dinamica de transformacion permite lograr un conocimiento adoptado, reconocido y explicito de los RNF dentro de la organizacion. La figura 3 describe los diferentes componentes del nucleo combinando notacion de SPEM 2.0, SPEM-KF extendido con flujos de conocimiento y grafica rica adaptada.

La transformacion de conocimiento frente a los RNF inicia cuando el elicitador contextualiza a los stakeholders, por medio de la socializacion, 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 tacito del usuario es menor frente al grado de conocimiento tacito del elicitador con respecto a los RNF; el usuario omite estos aspectos durante el proceso de elicitacion, por lo tanto, desconoce los RNF, mientras que el elicitador ya cuenta con determinada formacion 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, propositos y formas de identificar los RNF. Asimismo, el elicitador obtiene informacion para ir concretando los RNF determinados por el usuario. Al terminar estas actividades iniciales de elicitacion (relacionadas con la socializacion), el elicitador expone el conocimiento obtenido en un documento de especificacion de RNF (externalizacion) el cual podra ser complementado con conocimientos de apoyo dispuestos en otros documentos de ingenieria de requisitos o documentos de RNF de otros proyectos anteriores (combinacion).

Otra manera de combinar conocimiento consiste en completar los RNF a traves de la elicitacion con los usuarios tecnicos involucrados en el proceso. Cuando se termina este proceso de identificacion y recoleccion de RNF se comparte la especificacion de RNF con los usuarios finales y usuarios tecnicos para que ejecuten la validacion.

3.2 Dimensiones para la ERNF basada en la gestion de conocimiento

Para gestionar el conocimiento de RNF involucrado en el proceso de ERNF, Merlinn propone tres dimensiones de manera que se logra una integracion efectiva y totalmente incluyente entre ellas: i) dimension de conocimiento, ii) dimension organizacional y iii) dimension tecnica. A continuacion, se hace una breve descripcion de cada una de estas dimensiones:

* Dimension 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 traves de la aplicacion de estos componentes se logre la implementacion del proceso de ERNF desde la perspectiva de la GC. Los componentes de esta dimension 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 organizacion, y (ii) flujo de conocimiento (FC), el cual permite modelar los procesos de transformacion del conocimiento desde un estado tacito a explicito o desde un conocimiento menos explicito a uno de mayor explicitud frente a los RNF (los flujos de conocimiento de Merlinn se presentan entre los procesos de socializacion, exteriorizacion, combinacion e interiorizacion, segun el modelo SECI [17]).

* Dimension organizacional (DO): incluye componentes que permiten consolidar la informacion relevante para los procesos de GC en una organizacion, a partir de los siguientes aspectos: (i) formas y grado de implementacion de la GC de los RNF en los proyectos software, el cual permite descubrir si en las organizaciones existe alguna forma de gestion de conocimiento y su grado de aplicacion, (ii) formas de comunicacion organizacional que permitan apoyar la transferencia del conocimiento de los RNF de manera masiva y agil entre los involucrados del proyecto, asi como de la comunicacion que se da entre otros empleados dentro de la organizacion mediante canales de comunicacion adicionales y externos al proyecto, (iii) caracteristicas de las stakeholders implicados en el proceso de desarrollo del producto software, el cual permite identificar si el proyecto, dentro del contexto de la organizacion, tiene diferentes tipos de stakeholders, tales como usuarios finales, usuarios de direccion, y usuarios tecnicos, y (iv) procesos de negocio involucrados en el dominio de aplicacion, el cual permite identificar los procesos de negocio involucrados en el alcance del proyecto y que pertenecen al dominio de la aplicacion. En este item se logra identificar las interfaces que deben contemplarse dentro del proyecto de desarrollo.

* Dimension tecnica (DT): incluye el conjunto de procesos tecnicos para realizar la ERNF basada en la GC (figura 4), dentro de un contexto especifico de la organizacion. Estos procesos se basan en el estandar ISO 12207 [19] y han sido adaptados especificamente a la ERNF y, adicionalmente, desde la perspectiva de la GC se identifican los RNF; se elabora la especificacion de RNF; se valida la especificacion, se negocian y priorizan los RNF, y se publica la especificacion.

3.3 Metodo para la ERNF basado en GC

Los diferentes aspectos descritos en las dimensiones son recolectados y usados a traves de la ejecucion de un metodo 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 gestion organizacional, ii) Procesos clave de la gestion de conocimiento y iii) Procesos tecnicos.

Este metodo inicia con los procesos de diagnostico empresarial (DE) e identificacion de stakeholders (IS) con el proposito de conocer el estado inicial de la organizacion frente a los mecanismos de GC que tiene implementados, la complejidad del dominio de la aplicacion a desarrollar y los tipos de interesados involucrados en el proyecto. Las salidas principales de este grupo de procesos son: tamano y tipo de la organizacion, mecanismos de almacenamiento de la informacion, lista de procesos de negocio involucrados y lista de mecanismos de comunicacion utilizados por los stakeholders dentro de la organizacion.

A partir de esta informacion, la cual se convierte en entrada para el segundo grupo de procesos (los procesos clave de gestion de conocimiento), se define la estrategia de GC (DEGC) y se planea la estrategia de GC (PEGC) la cual sera implementada en la organizacion de acuerdo con las necesidades especificas del contexto organizacional. Las actividades planeadas pertenecientes a la estrategia de GC definida seran aplicadas (DESGC) durante la ejecucion del proceso tecnico de ERNF (identificacion, elaboracion de especificacion, validacion, negociacion y priorizacion, y publicacion de los RNF), logrando transformaciones de conocimiento tacito a explicito, y viceversa, acerca de los RNF acorde con la estrategia. Finalmente, se deberan desarrollar las actividades planeadas de monitorizacion y control de la estrategia de GC definidas previamente (PEGC) para que se garantice su correcta y completa ejecucion de manera que en caso de ser necesario se realicen acciones preventivas o correctivas a las desviaciones. La aplicacion de este metodo posibilita a las organizaciones a planear y ejecutar nuevas iteraciones de gestion de conocimiento frente a los RNF. Para apoyar la ejecucion del metodo, Merlinn sugiere el uso de instrumentos que permiten la captura de la informacion relevante, desde la perspectiva de GC, para cada proceso especifico 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 gestion de conocimiento (DESGC) se hace uso del nucleo de transformacion TCER a traves de los diferentes escenarios de transformacion que ocurren en la ERNF: i) escenario de instauracion del conocimiento (EIC), ii) escenario de configuracion del conocimiento (ECC), iii) escenario de afianzamiento del conoci miento (EAC) y iv) escenario de institucionalizacion del conocimiento (EITC). A continuacion, se describe cada uno de estos escenarios.

Descripcion del escenario: El elicitador inicia el proceso de identificacion del estado de conocimiento de los stakeholders frente a los RNF, activando de esta manera el flujo de socializacion del marco de trabajo. Este proceso genera una dinamica de comunicacion que conlleva al entendimiento mutuo acerca de los RNF iniciales. El stakeholder expresara el entendimiento que vaya adquiriendo para luego combinarlo con otro conocimiento previo (tacito o explicito).

El marco de trabajo adiciona, a la propuesta del modelo SECI, caminos nuevos para transformacion de conocimiento acordes con las dinamicas organizacionales que pueden darse en los procesos de ERNF: i) Ruta S-E que permite lograr un primer componente explicito del proceso de transformacion de conocimiento de RNF; ii) Ruta E-C, la cual es unidireccional, que permite lograr conocimiento explicito de combinacion; iii) Ruta E-I-C, la cual es unidireccional que permite una nueva forma de combinacion de conocimiento que no esta en estado explicito, es decir, que permanecen tacitos en el individuo; iv) Ruta E-I, que soporta la consolidacion 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 validacion de la especificacion de estos requisitos, y b) cuando el elicitador presenta el conocimiento que se esta exteriorizando a los demas involucrados, puesto que exige una validacion, correccion, complemento y confirmacion de estos requisitos. Esta ruta es otra alternativa que permite al individuo aumentar el grado de interiorizacion de RNF a partir de un conocimiento explicito base (figura 5).

Partiendo del supuesto de que: "Mayor necesidad de transformacion del conocimiento de tacito a explicito de los RNF, involucra mayor cantidad de flujos de transformacion de los procesos de socializacion, exteriorizacion, combinacion e interiorizacion en el proceso de ERNF", se determinan los escenarios que seran utilizados en la definicion de la estrategia de gestion de conocimiento (EGC) que propone Merlinn. Esta estrategia se enfoca en determinar y guiar el desarrollo de las actividades tecnicas de ERNF desde la perspectiva de la GC, de manera que se logre un mayor conocimiento explicito de este tipo de requisitos a partir de los diferentes elementos de conocimiento de la organizacion identificados a traves de las diferentes dimensiones.

4. EVALUACION Y ESTUDIO DE CASO DE MERLINN

En esta seccion, se detalla la validacion preliminar de Merlinn mediante su aplicacion en una pequena empresa desarrolladora de software usando el metodo de estudio de caso. En la figura 6 se muestran los roles que fueron definidos para el proceso de aplicacion de Merlinn, asi como las actividades generales que los participantes debian realizar durante el proceso de intervencion.

Esta validacion preliminar ha seguido la plantilla protocolo para planeacion de casos de estudio descritos en [21], de tal manera que a continuacion, se describe el estudio de caso en terminos de antecedentes, diseno, seleccion del caso y sujetos de investigacion, intervencion, recoleccion de datos, analisis y limitaciones.

Antecedentes

El objeto del estudio de caso es el marco de trabajo para la ERNF basada en gestion de conocimiento (Merlinn), y mas especificamente su nucleo TCER usado en 3 proyectos diferentes de una organizacion de desarrollo de software con el fin de evaluar que ocurre con el conocimiento acerca de los RNF y como este conocimiento se va transformando durante el proceso de elicitacion. Las preguntas de investigacion principales y adicionales que apoyan este mecanismo de validacion preliminar se describen en la tabla 7.

Diseno

Tomando en cuenta el enfoque presentado en [15], el tipo de diseno 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 analisis diferentes: UA1, UA2 y UA3). El objeto de estudio es Merlinn. Las medidas usadas para indagar sobre las preguntas de investigacion son: i) numero total de RNF especificados, (ii) numero de instrumentos para la GC propuestos por Merlinn usados por las unidades de analisis, y (iii) numero de stakeholders involucrados en el proceso de ERNF. Estas metricas fueron tomadas a traves de tres mecanismos: (i) aspectos identificados durante la ejecucion del proceso de intervencion, (ii) resultados de las plantillas e instrumentos que ofrece el marco de trabajo para su aplicacion, y (iii) realizacion de una encuesta final a los equipos involucrados en la evaluacion buscando obtener informacion cuantitativa y cualitativa acerca del proceso de ERNF llevado a cabo en la organizacion.

Seleccion del caso y sujetos de investigacion

El criterio para la seleccion 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 participacion del cliente (usuarios finales del sistema de informacion) y que estuviera en disposicion de utilizar Merlinn. La empresa participe del estudio de caso tiene 12 empleados, con 3 anos 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 investigacion, el equipo de investigacion estuvo compuesto por (i) un asesor del proceso de investigacion, experto en ERNF para productos software quien contextualiza acerca del objetivo de la investigacion, y guia la ERNF con las diferentes unidades de analisis seleccionadas, (ii) tres equipos tecnicos de la empresa (quienes realizan diferentes roles), uno para cada unidad de analisis quienes debian realizar las actividades referentes a la identificacion de RNF, negociacion y priorizacion de los RNF y elaboracion de la especificacion de RNF haciendo uso de los instrumentos propuestos por Merlinn, (iii) grupo de usuarios finales (operarios y jefes de areas) con quienes los elicitadores realizarian el proceso de ERNF.

Intervencion

Durante este proceso fue necesario realizar diferentes actividades para la aplicacion de Merlinn en la empresa, entre las mas destacadas: (i) contextualizacion de la propuesta, (ii) capacitacion detallada de Merlinn y RNF, (iii) elaboracion de especificaciones para los proyectos, y (iv) cierre del proceso. Ademas, el asesor apoyo la solucion de las dudas sobre Merlinn que les surgieron a los diferentes responsables de la ERNF de los proyectos (unidades de analisis) durante su utilizacion 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 intervencion en la organizacion participante del estudio de caso las medidas planeadas para la investigacion fueron recolectadas al finalizar el proceso de ERNF.

Recoleccion de datos

Los datos se recolectaron a traves de los mecanismos definidos previamente y se analizan en la siguiente seccion. La tabla 8 presenta el numero de RNF identificados en el proceso de elicitacion de cada proyecto; en las tablas 9 y 10 se detalla la granularidad de dos de los RNF que obtuvieron mayor numero de caracteristicas no funcionales elicitadas durante la intervencion (eficiencia de desempeno y usabilidad), y la tabla 11 muestra el consolidado de las respuestas obtenidas a traves de la encuesta realizada a las 5 personas de la empresa que participaron en la utilizacion y aplicacion de Merlinn (donde la escala fue de 0 a 5, siendo 0 el menor valor). Ademas, los 5 encuestados coincidieron en que Merlinn: aporta al proceso de ERNF, esta descrito con claridad lo cual facilita su aplicacion en la practica, y sera utilizado para futuros proyectos de la empresa.

Analisis

A continuacion, se describen los resultados de la aplicacion de Merlinn en el estudio de caso a traves de tres aspectos:

* En un primer aspecto, acerca de la GC aplicada en el estudio de caso, se evidencia que las unidades de analisis UA1 y UA3 aplicaron el 83% de los instrumentos propuestos por Merlinn, y la unidad de analisis UA2 aplico el 66% de los instrumentos del marco.

* En un segundo aspecto, acerca de la especificacion 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 analisis 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 analisis correspondieron en un 35% a RNF referentes a la usabilidad del sistema de informacion, un 27% de los RNF elicitados referentes a la eficiencia de desempeno del sistema de informacion seguidos por RNF referentes a la seguridad del sistema de informacion con una participacion del 20% del total de RNF elicitados (respuesta a la pregunta adicional numero 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 dinamicas de proyectos de desarrollo de software, (ii) suficiente para la ERNF, lo cual sugiere que la estructura, actividades propuestas e instrumentos para su aplicacion permiten lograr la especificacion de RNF de manera efectiva, y (iii) que permite aumentar el conocimiento sobre RNF de los involucrados en el proceso de elicitacion y el conocimiento de aspectos ligados con arquitectura e infraestructura de los sistemas de informacion (respuesta a la pregunta adicional numero 1 y numero 2).

Basado en que: (i) la utilizacion de componentes de GC de Merlinn, tales como procesos clave de GC, los flujos de conocimiento, los escenarios y las rutas de transformacion de conocimiento, ha permitido la especificacion de RNF durante el proceso de elicitacion, (ii) los RNF elicitados en los diferentes proyectos, (iii) la adquisicion e incremento del conocimiento sobre RNF de los stakeholders involucrados en el proceso de elicitacion, (iv) los beneficios descritos por los involucrados durante el proceso de intervencion 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 idoneo para la ERNF de un producto software (respondiendo asi a la pregunta de investigacion principal).

Pese a que la investigacion tiene un enfoque de requisitos no funcionales, estos resultados sugieren que podria extenderse el uso de Merlinn al proceso de elicitacion de requisitos funcionales dado que, para el caso de la elicitacion de este tipo de requisitos, tambien se requiere la identificacion y entendimiento de las necesidades funcionales a partir del conocimiento tacito que tienen los interesados.

Limitaciones del estudio

* La generalizacion de los resultados obtenidos se limito por el tamano de la poblacion, por mas que este tipo de empresa es comun en la industria del software de Iberoamerica.

* Los RNF elicitados se limito por (i) una ejecucion no natural del proceso de elicitacion por parte de los participantes al sentirse observados por el asesor, (ii) una experiencia restringida frente a participacion en proyectos de desarrollo de software, (iii) un desconocimiento de aspectos relacionados con infraestructura tecnologica y gestion de conocimiento, y (iv) un conocimiento parcial acerca de requisitos no funcionales.

CONCLUSIONES Y TRABAJO FUTURO

En este articulo se ha presentado un marco de trabajo denominado Merlinn, el cual hace uso de elementos de gestion de conocimiento, para la ERNF. Este marco de trabajo esta compuesto por diferentes componentes que permiten gestionar el conocimiento involucrado en las diferentes etapas tecnicas 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 adquisicion de conocimiento acerca de RNF para convertirse en activo organizacional, (ii) es util, adaptable e idoneo para la ERNF. Desde la perspectiva del conocimiento, Merlinn permite: (a) aumentar la participacion 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 ingenieria.

Como trabajo futuro se pretende fortalecer el proceso de validacion de RNF, utilizar a Merlinn como herramienta de apoyo a una metodologia para la calidad de los productos software, aplicar Merlinn en organizaciones al nivel nacional que permitan generalizar los resultados y construir una herramienta tecnologica que apoye su aplicacion.

AGRADECIMIENTOS

Este trabajo ha sido financiado por el proyecto VRI-4354 registrado en la Vicerrectoria de Investigaciones de la Universidad del Cauca. Los autores agradecen a la Universidad del Cauca, donde ellos trabajan como profesores OTC y titular, respectivamente.

REFERENCIAS

[1] D. Pandey, U. Suman, and A. K. Ramani, "An Effective Requirement Engineering Process Model for Software Development and Requirements Management," pp. 287-291, 2010.

[2] H. F. Hofmann and F. Lehner, "Requirements engineering as a success factor in software projects," IEEE software, vol. 18, p. 58, 2001.

[3] D. Zowghi and C. Coulin, "Requirements elicitation: A survey of techniques, approaches, and tools," in Engineering and managing software requirements, ed: Springer, 2005, pp. 19-46.

[4] I. C. S. S. E. S. Committee and I.-S. S. Board, "IEEE Recommended Practice for Software Requirements Specifications," 1998.

[5] L. Chung and J. C. S. do Prado Leite, "On non-functional requirements in software engineering," in Conceptual modeling: Foundations and applications, ed: Springer, 2009, pp. 363-379.

[6] A. Casamayor, D. Godoy, and M. Campo, "Identification of non-functional requirements in textual specifications: A semi-supervised learning approach," Information and Software Technology, vol. 52, pp. 436-445, 2010.

[7] X. Franch and P. Botella, "Putting non-functional requirements into software architecture," in Proceedings of the 9th international Workshop on Software Specification and Design, 1998, p. 60.

[8] L. M. Cysneiros and E. Yu, "Non-functional requirements elicitation," in Perspectives on software requirements, ed: Springer, 2004, pp. 115-138.

[9] E. Serna-Montoya, "Estado actual de la investigacion en requisitos no funcionales," Ingenieria y Universidad, vol. 16, pp. 225-246, 2012.

[10] M. Mijanur Rahman and S. Ripon, "Elicitation and Modeling Non-Functional Requirements--A POS Case Study," International Journal of Future Computer and Communication, pp. 485-489, 2013.

[11] H. Hu, Q. Ma, T. Zhang, Y. Tan, H. Xiang, C. Fu, and Y. Feng, "Semantic modelling and automated reasoning of non-functional requirement conficts in the context of softgoal interdependencies," IET Software, vol. 9, pp. 145-156, 2015.

[12] W. Hu, J. C. Carver, V. K. Anu, G. S. Walia, and G. Bradshaw, "Detection of requirement errors and faults via a human error taxonomy: a feasibility study," in Proceedings of the 10th ACM/IEEE International Symposium on Empirical Software Engineering and Measurement, 2016, p. 30.

[13] E. Serna, O. Bachiller, and A. Serna, "Knowledge meaning and management in requirements engineering," International Journal of Information Management, vol. 37, pp. 155-161, 2017.

[14] F. J. Pino, M. Piattini, and G. Horta Travassos, "Managing and developing distributed research projects in software engineering by means of action-research," Revista Facultad de Ingenieria Universidad de Antioquia, pp. 61-74, 2013.

[15] R. K. Yin, "Case study research: Design and methods, Newbury Park," Cal.: SAGE Publications, 1994.

[16] K. Petersen, R. Feldt, S. Mujtaba, and M. Mattsson, "Systematic mapping studies in software engineering," in 12th international conference on evaluation and assessment in software engineering, 2008.

[17] I. Nonaka, R. Toyama, and N. Konno, "SECI, Ba and leadership: a unified model of dynamic knowledge creation," Long range planning, vol. 33, pp. 5-34, 2000.

[18 ] K . Dalkir and J. Liebowitz , Knowledge management in theory and practice: MIT press, 2011.

[19] SEI, "Improving Processes in Small Settings (IPSS) A White Paper," Software Engineering Institute, Pittsburgh, PA, 2017.

[20] S. L. Buitron, B. L. Flores-Rios, and F. J. Pino, "Elicitacion de requisitos no funcionales basada en la gestion de conocimiento de los stakeholders," Ingeniare. Revista chilena de ingenieria, vol. 26, pp. 142-156, 2018.

[21] P. Brereton, B. Kitchenham, D. Budgen, and Z. Li, "Using a protocol template for case study planning," in Proceedings of the 12th International Conference on Evaluation and Assessment in Software Engineering. University of Bari, Italy, 2008.

[22] T. H. Al Balushi, P. R. F. Sampaio, and P. Loucopoulos, "Eliciting and prioritizing quality requirements supported by ontologies: a case study using the ElicitO framework and tool," Expert Systems, vol. 30, pp. 129-151, 2013.

[23] A. L. de Araujo, L. M. Cysneiros, and V. M. B. Werneck, "NDR-Tool: Uma Ferramenta de Apoio ao Reuso de Conhecimento em Requisitos Nao Funcionais."

[24] N. Larburu, R. G. Bults, and H. J. Hermens, "Making medical treatments resilient to technological disruptions in telemedicine systems," in IEEE-EMBS International Conference on Biomedical and Health Informatics (BHI), 2014, pp. 285-288.

[25] Y. Terawaki, "Supporting of requirements elicitation for ensuring services of information systems used for education," in Symposium on Human Interface, 2011, pp. 58-65.

[26] L. Teixeira, V. Saavedra, C. Ferreira, J. Simoes, and B. S. Santos, "Requirements Engineering Using Mockups and Prototyping Tools: Developing a Healthcare Web-Application," in International Conference on Human Interface and the Management of Information, 2014, pp. 652-663.

[27] P. Loucopoulos, J. Sun, L. Zhao, and F. Heidari, "A systematic classification and analysis of NFRs," 2013.

[28] D. Ameller, C. Ayala, J. Cabot, and X. Franch, "How do software architects consider non-functional requirements: An exploratory study," in 2012 20th IEEE International Requirements Engineering Conference (RE), 2012, pp. 41-50.

[29] J. Helming, M. Koegel, F. Schneider, M. Haeger, C. Kaminski, B. Bruegge, and B. Berenbach, "Towards a unified requirements modeling language," in Requirements Engineering Visualization (REV), 2010 Fifth International Workshop on, 2010, pp. 53-57.

[30] B. Wei, Z. Jin, and L. Liu, "A Formalism for Extending the NFR Framework to Support the Composition of the Goal Trees," pp. 23-32, 2010.

[31] X. Song, Z. Duan, and C. Tian, "Non-functional requirements elicitation and incorporation into class diagrams," in International Conference on Intelligent Information Processing, 2010, pp. 72-81.

[32] R. Veleda and L. M. Cysneiros, "An Initial Approach to Reuse Non-Functional Requirements Knowledge," in iStar, 2015, pp. 25-30.

Sandra Lorena Buitron Ruiz (**)

Brenda Leticia Flores Rios (***)

Francisco Jose Pino Correa (****)

(*) Investigacion terminada. Origen: proyecto VRI-4354 Marco de trabajo para la elicitacion de requisitos no funcionales basada en la gestion de conocimientoTiempo de ejecucion: 2 anos Ente financiador: vicerrectoria de Investigaciones de la Universidad del Cauca.

(**) Grupo IDIS, Universidad del Cauca, Colombia. sandrabr@unicauca.edu.co

(***) Universidad Autonoma de Baja California, Mexico. brenda.fores@uabc.edu.mx

(****) Grupo IDIS, Universidad del Cauca, Colombia. fjpino@unicauca.edu.co

Recibido: 18/05/2017 * Aceptado: 27/07/2017

DOI: 10.22395/rium.v17n32a8
Tabla 1. Consolidado de propuestas

Ref.  TC  Aporte

          Soportar el proceso de ER desde la
[22]  H   practica, incluyendo el proceso de
          priorizacion de requisitos

          Orientacion a producto y al proceso
          de ERNF, para apoyar en el la
[23]  H   definicion y analisis de los RNF
          haciendo uso del conocimiento a
          traves de ontologias y web semantica
          (catalogos)
          Relacionar funcional y no funcionalmente,
          a traves de capas, las
[24]  PM  variables y contextos tecnologicos
          con variables y abstracciones
          clinicas
          Asegurar los requisitos de calidad
          a partir del documento de
[25]  PM  especificacion usando tecnicas de
          text-mining y un diccionario de
          conceptos
          Soportar el proceso de ingenieria
          de requerimientos para colaboracion,
          participacion y negociacion
[26]  PM  de los REQ soportandose en el
          metodo del prototipado rapido
          para desarrollos

          Clasificacion de los enfoques
[27]  E   de RNF haciendo un analisis
          multi-dimensional

          Conocer desde la perspectiva de
          los arquitectos de software, como
[28]  E   se obtienen los RNF


          Soportar la obtencion de requisitos
[29]  H   tempranos, apoyando en su trazabilidad
          desde diferentes dominios
          Soportar un enfoque logico para
[30]  H   los RNF basado en el concepto de
          soft-gold.
          Identificar los RNF, elicitarlos y
      PM  analizarlos. Metodologia orientada
[31]      a objetos de UML, bajo el diagrama
          de casos de uso.
          Identificar los RNF para su re utilizacion.
          Proponen el framework
[32]  H   NDR basado en conocimiento y
          varias ontologias previamente propuestas
          en otras investigaciones.
          respectivas.

Ref.  Forma en que aborda
      el conocimiento
      Definicion de ontologia de RNF a
[22]  partir de la norma 9126 y combinandola
      con tecnicas de gestion de
      conocimiento.
      Reutilizacion del conocimiento de
      RNF definidos anteriormente para
[23]  aumentar las alternativas de requisitos
      a implementar.


      Las variables son dimensiones de
      calidad que se relacionan y
[24]  descomponen
      de manera jerarquica para lograr
      un afinamiento de los requisitos de
      calidad (RNF).
      Definicion de requisitos de calidad
[25]  (RNF) basado en la norma 9126.



      Niveles de conocimiento, que se
      combina, disemina e intercambia
[26]  entre los stakeholders dentro de un
      contexto (conocimiento implicito del
      trabajo), el cual debe ser conocido
      y entendido por los ingenieros de
      requisitos.
[27]  Analizar los enfoques del proceso
      de ERNF desde las dimensiones del
      contexto, proceso y la aplicacion.

      Cualidades externas e internas del
[28]  software. ?Quien decide los
      RNF, que tipos de RNF importan
      a arquitectos, como se documentan
      los RNF y como se validan?
[29]  Tiene en cuenta el conocimiento
      de los stakeholders para iniciar el
      proceso de modelado visual.
[30]  Uso de formalizacion para
      representar los RNF.

      El conocimiento sobre los RNF
[31]  esta dentro del documento de
      especificacion.

      El conocimiento tiene como base
[32]  unas ontologias a partir de las
      cuales la herramienta busca las
      correlaciones y descomposiciones

Ref.  Fundamentada en

      Ontologia y
[22]  conocimiento en la
      norma 9126

      Ontologia y
      Reutilizacion del
[23]  conocimiento



      Jerarquia y Capas
      relacionadas y
[24]  afinamiento del
      conocimiento


      Documento de
[25]  especificacion y
      conocimiento en la
      norma 9126

      Prototipado e
      intercambio de
[26]  conocimiento




[27]  Analisis multi-dimensional
      de
      enfoques
      existentes
      Perspectiva de
[28]  los arquitectos
      y cualidades del
      software

[29]  Trazabilidad de requisitos
      tempranos
      y modelado visual
[30]  Soft-gold y
      representacion de
      los requisitos
      Metodologia UML
[31]  y documento de
      especificacion

      Ontologia y
[32]  reutilizacion de
      RNF.

TC: Tipo de contribucion (H: Herramienta, PM: Propuesta metodologica,
E: Estudio)
Fuente: elaboracion propia

Tabla 2. Procesos e instrumentos del metodo para le ERNF

                    Procesos e instrumentos del metodo para la ERNF
Proceso de   Proceso de      Proceso de     Proceso de     Proceso de
Diagnostico  identificacion  definicion de  planeacion de  desarrollo de
Empresarial  de stakehol-    la estrategia  la estrategia  la estrategia
(DE)         ders (IS)       de gestion de  de gestion de  de gestion de
                             conocimiento   conocimiento   conocimiento
                             (DEGC)         (p egc)        (desegc)
Formato FM-DE-IS             Formato        Formato        Formato
                             FM-DEGC        FM-PEGC        FM-DESEGC

                  Procesos e instrumentos del metodo para la ERNF
Proceso de        Proceso de monitorizacion
Diagnostico       y control
Empresarial       de la estrategia
(DE)              de gestion
                  de conocimiento
                  (mycegc)
Formato FM-DE-IS  Formato
                  FM-MyCEGC

                               Propositos de los instrumentos de apoyo
Conocer el grado de com-       Establecer la es-  Definir las
plejidad del dominio de la     trategia de cono-  actividades
aplicacion, frente a aspectos  cimiento que sera  de ERNF
que involucra la GC en la      implementada en    basadas en GC
organizacion y determinar      la organizacion    acorde al tipo
el grupo de stakeholders       a par tir de las   de estrategia
adecuado y sus atributos de    salid as de los    definido en
tipo conocimiento para llevar  procesos DE e IS   proceso DEGC.
a cabo el proc eso de ERNF.   previos.

                               Propositos de los instrumentos de apoyo
Conocer el grado de com-       Apoyar la       Controlar y
plejidad del dominio de la     ejecucion       monitorear
aplicacion, frente a aspectos  del proceso     el avance de
que involucra la GC en la      de ERNF,        la estrategia
organizacion y determinar      capturando      planeada para
el grupo de stakeholders       informacion     el proceso de
adecuado y sus atributos de    sobre los RNF   ERNF.
tipo conocimiento para llevar  identificados.
a cabo el proc eso de ERNF.

Fuente: elaboracion propia

Tabla 3. Caracterizacion del escenario EIC

                      Escenario de instauracion del conocimiento (EIC)
Flujos TC involucrados           Actores

Socializacion, interiorizacion,  Elicitador, usuarios
exteriorizacion, combinacion     finales y de direccion

                      Escenario de instauracion del conocimiento (EIC)
Flujos TC involucrados           Etapa tecnica de ERNF  Rutas TC

Socializacion, interiorizacion,  Identificacion de RNF  SE
exteriorizacion, combinacion                            EI

Descripcion del escenario: El elicitador inicia el proceso de
identificacion del estado de conocimiento de los stakeholders frente
a los RNF, activando de esta manera el flujo de socializacion del
marco de trabajo. Este proceso genera una dinamica de comunicacion
que conlleva al entendimiento mutuo acerca de los RNF iniciales. El
stakeholder expresara el entendimiento que vaya adquiriendo para luego
combinarlo con otro conocimiento previo (tacito o explicito).
Fuente: elaboracion propia

Tabla 4. Caracterizacion del escenario ECC

                    Escenario de configuracion del conocimiento (ECC)
   Flujos TC involucrados         Actores

Interiorizacion, exterioriza-  Elicitador, otros proyectos,
cion, combinacion              usuarios tecnicos

                    Escenario de configuracion del conocimiento (ECC)
   Flujos TC involucrados       Etapa tecnica de ERNF    Rutas TC

Interiorizacion, exterioriza-  Elaboracion de especif-     EC
cion, combinacion              cacion de RNF

Descripcion del escenario: A partir del escenario inicial (EIC), el
elicitador debe plasmar los RNF definidos en un documento
(conocimiento explicito) denominado especificacion de RNF. En este
escenario un conocimiento que estaba explicito para otros proyectos de
desarrollo de software puede ser utilizado para complementar y/o
aclarar los RNF del proyecto en curso, realizando un proceso de
combinacion de conocimiento, ademas, el elicitador complementa los RNF
con informacion de usuarios expertos. En este escenario se puede
requerir realizar tareas de priorizacion y negociacion de requisitos
no funcionales con los interesados involucrados.
Fuente: elaboracion propia

Tabla 5. Caracterizacion del escenario EAC

                       Escenario de afianzamiento del conocimiento (EAC)
Flujos TC involucrados                  Actores


Interiorizacion, exteriorizacion  Usuarios finales, direccion
combinacion                       usuarios tecnicos, elicitador

                       Escenario de afianzamiento del conocimiento (EAC)
Flujos TC involucrados             Etapa tecnica de      Rutas TC
                                        ERNF

Interiorizacion, exteriorizacion  Validacion de especi-     EIC
combinacion                       ficacion de RNF

Descripcion del escenario: En este escenario de afianzamiento el
usuario final realiza un proceso de validacion de los RNF de la
especificacion entregada por el elicitador, de manera que el RNF sea
confirmado y, ademas, este completo, no ambiguo y consistente. En este
escenario el conocimiento se exterioriza nuevamente para garantizar el
entendimiento de los RNF elicitado.
Fuente: elaboracion propia

Tabla 6. Caracterizacion del escenario EITC

               Escenario de institucionalizacion del conocimiento (EITC)
Flujos TC involucrados             Actores


Socializacion, exteriorizacion  Usuario, elicitador

               Escenario de institucionalizacion del conocimiento (EITC)
Flujos TC involucrados             Etapa tecnica de ERNF       Rutas
                                                               TC

Socializacion, exteriorizacion  Publicacion de especificacion  SE
                                de RNF

Descripcion del escenario: Luego de acordar los RNF del producto
mediante el proceso de validacion, se publica la informacion a traves
de herramientas tecnologicas disponibles entregando de esta manera la
especificacion de RNF al siguiente proceso del ciclo de desarrollo de
software. El conocimiento queda disponible para nuevos proyectos o
nuevos interesados en la organizacion.
Fuente: elaboracion propia

Tabla 7. Preguntas de investigacion del estudio de caso

Tipo                                    Pregunta

Principal    ?El marco de trabajo Merlinn es idoneo (adecuado y
             apropiado) para algo para la
             ERNF de un producto de software?
Adicional 1  ?Los procesos y componentes de gestion de conocimiento
             (GC) que propone Merlinn
             son utiles para la ERNF?
Adicional 2  ?Merlinn permite a los stakeholders adquirir conocimiento
             acerca de los RNF?

Fuente: elaboracion propia

Tabla 8. Medidas obtenidas a traves del uso de los artefactos
Medidas obtenidas a traves del uso de los artefactos de Merlinn

Metricas                                   UA1  UA2  UA3  Promedio

Numero de RNF identificados                20   63   49    44
Numero de artefactos usados en el proceso   5    4    5     4.6
Numero de stakeholders involucrados en el
proceso de ERNF                             4    1   28    11

Fuente: elaboracion propia

Tabla 9. Ejemplos detallados de caracteristicas elicitadas frente a
eficiencia de desempeno

RNF Eficiencia                                  UA1  UA2  UA3  Totales

Tiempo de cargue/consultas de informacion       5    16          21
Tiempo de obtencion de calculos y/o resultados        2           2
Tiempo de almacenamiento en base de datos             2           2
Tiempo de ingreso a aplicativo                             1      1
Tiempo de operacion en datos (eliminar,
modificar, exportar, crear,                                9      9
registrar)
Totales RNF Eficiencia por unidad de analisis   5    20   10     35

Fuente: elaboracion propia

Tabla 10. Ejemplos detallados de caracteristicas elicitadas frente a
usabilidad

RNF Usabilidad                                 UA1  UA2  UA3  Totales

Plataforma intuitiva y de facil uso            8     7   14     29
Ordenamiento de informacion visual
segun criterios                                      4           4
Definicion de informacion opcional                   1           1
Mecanismos de exportacion de datos                   1           1
Mecanismos de filtrado de informacion                2           2
Totales RNF Usabilidad por unidad de analisis  8    15   23     46

Fuente: elaboracion propia

Tabla 11. Medidas obtenidas a traves de las encuestas

Calificaciones a las caracteristicas
de Merlinn a traves de                             E1  E2  E3  E4  E5
            las encuestas

Flexibilidad                                        5   4   4   5   4
Capacidad de ajustarse a la dinamica del proyecto   4   4   4   5   4
Conveniencia de uso para el proceso de ERNF         5   5   5   4   5
Suficiencia para el logro de los objetivos
(especificar los                                    5   5   5   5   4
RNF)
Utilidad en el proceso de ERNF                      4   5   5   4   5

Calificaciones a las caracteristicas
de Merlinn a traves de                             Promedio
            las encuestas

Flexibilidad                                          4,4
Capacidad de ajustarse a la dinamica del proyecto     4,2
Conveniencia de uso para el proceso de ERNF           4,8
Suficiencia para el logro de los objetivos
(especificar los                                      4,8
RNF)
Utilidad en el proceso de ERNF                        4,6

Fuente: elaboracion propia
COPYRIGHT 2018 Universidad de Medellin
No portion of this article can be reproduced without the express written permission from the copyright holder.
Copyright 2018 Gale, Cengage Learning. All rights reserved.

Article Details
Printer friendly Cite/link Email Feedback
Author:Ruiz, Sandra Lorena Buitron; Rios, Brenda Leticia Flores; Correa, Francisco Jose Pino
Publication:Revista Ingenierias
Date:Jan 1, 2018
Words:8541
Previous Article:A Representation Proposal of Practices for Teaching and Learning Software Engineering Using a Semat Kernel Extension/Propuesta de representacion de...
Next Article:Analisis de calidad de potencia en un sistema industrial a partir de mediciones multipunto/Power Quality Analysis in an Industrial System from...
Topics:

Terms of use | Privacy policy | Copyright © 2020 Farlex, Inc. | Feedback | For webmasters