Printer Friendly

Transformacion del conocimiento en el proceso de elicitacion de requisitos no funcionales.

1. Introduccion

Para la construccion de productos de ingenieria del software se cuenta hoy en dia con modelos que han sido definidos a lo largo de los anos, conocidos como ciclos de desarrollo de software, con determinados enfoques, y que han sido aplicados desde diferentes perspectivas como la especificacion, el diseno, la validacion y la evolucion [1]. Estos modelos definen las etapas para realizar el proceso de desarrollo de software; sin embargo, no indican de manera concreta como lograr la adhesion de cada propuesta al interior de la organizacion. Teniendo en cuenta las etapas que definen estas metodologias de desarrollo, se puede observar que la primera etapa siempre propone identificar los objetivos concretos, requisitos y caracteristicas del entorno del negocio; en otras palabras, realizar lo que hoy conocemos como la elicitacion de requisitos (ER). Este proceso de ER se considera como la base para que las etapas siguientes plasmen de manera adecuada y completa la(s) alternativa(s) de solucion [2][3].

Revisando algunas definiciones sobre el proceso de elicitacion de requisitos se tiene que este "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" [4]. Por otro lado, se define que la ER "es la fase principal enfocada en recopilar y analizar los requerimientos y objetivos deseados para el sistema desde diferentes puntos de vista (por ejemplo: clientes, usuarios, restricciones, entorno de operacion del sistema, comercio, marketing y estandares etc. ...)"[2]. Ademas, bajo el estandar IEEE Std 830-1998 [5], el proceso de especificacion de requisitos SRS (Software Requirements Specification) 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. Asi mismo, para [6] la ER se ocupa de los origenes de los requisitos del software y de como el ingeniero del mismo puede recolectarlos.

De acuerdo con estas definiciones, dentro de la elicitacion de requisitos se tienen en cuenta dos elementos principales, los requisitos funcionales y los no funcionales [7]. Chung describe los requisitos no funcionales como caracteristicas de usabilidad, flexibilidad, desempeno, operatividad y seguridad. Para [2] los requisitos funcionales son las acciones que debe realizar el software sin considerar las limitaciones fisicas, mientas que los requisitos no funcionales definiran las propiedades ambientales y las restricciones de implementacion relacionadas con el desempeno del mismo. Por otro lado, en [8] se indica que los requisitos no funcionales limitan el comportamiento y el desarrollo de un producto software, especificando los atributos que el sistema resultante debe tener. Ademas, en [9] se indica 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 etc. El estudio de investigacion realizado por [10] sobre el estado del proceso de elicitacion de requisitos no funcionales permite comprobar que las tecnicas utilizadas para realizar dicho proceso sobre RNF no estan aun claras. De la misma manera, se afirma que "aunque existen tecnicas bien desarrolladas para obtener requisitos funcionales, hay una falta de mecanismo de elicitacion para NFR y no existe un consenso adecuado al respecto de los NFR" [11]. En este sentido, es importante llevar a cabo una investigacion sobre la identificacion, analisis, documentacion e integracion de los requisitos no funcionales en el proceso de elicitacion de requisitos, de tal manera que se pueda lograr un mayor cubrimiento y cohesion de dichos requisitos con el diseno de solucion. Los requisitos no funcionales deben ser considerados como parte del proceso de desarrollo de software [7] y participan de manera determinante en la definicion de las restricciones tanto para el desarrollo como para el proceso de implementacion [11]; ademas, para lograr la calidad del producto de software se deben cumplir las caracteristicas funcionales y las no funcionales, a fin de permitir cubrir de manera completa las expectativas de los interesados [12].

A partir de estos hallazgos, en este articulo se presenta: (i) una propuesta de como se transforma el conocimiento durante el proceso de elicitacion de requisitos no funcionales, y (ii) un conjunto de beneficios que las organizaciones pueden identificar al realizar la elicitacion de requisitos no funcionales. El objetivo de este trabajo es determinar como los requisitos no funcionales pueden ser incluidos de manera efectiva en el proceso de elicitacion de requisitos bajo el enfoque de Gestion de Conocimiento. El articulo, ademas de esta introduccion, se organiza de la siguiente manera: en la seccion 2 se presentan los antecedentes de la tematica, en la seccion 3 se describe la propuesta de investigacion y finalmente se exponen las conclusiones del trabajo realizado hasta el momento.

2. Antecedentes

En reportes como el que presenta Standish Groups's International se indican, entre otras, las tres razones principales que llevan al fracaso de los proyectos de desarrollo de software: en primer lugar, con un 15.9 %, la falta de participacion de los usuarios; el segundo lugar lo ocupa la falta de soporte a la gestion ejecutiva del proyecto, con un 13.9 %; y en tercer lugar la definicion clara de los requisitos, con un 13% [13]. Adicionalmente, [14] en su estudio confirman que frente al objetivo de lograr la calidad en las organizaciones, un 37.5 % de las no conformidades corresponde a requisitos no funcionales; entre otros resultados, se identifica que 5.88 % de las no conformidades hacen parte del proceso de definicion de los requisitos de los stakeholders y un 12,94 % de las no conformidades se encuentran en el proceso de analisis de los requisitos del sistema. Por la relevancia descrita anteriormente, toma importancia la correcta y completa ejecucion del proceso de elicitacion de requisitos (ER) y, con mayor precision, la ER enfocada en los RNF. En esta misma linea, para que el equipo de ER sea exitoso, se requiere, segun [3], un profundo conocimiento del dominio de aplicacion, IT y del proceso de elicitacion; en otras palabras, una correcta combinacion de conocimiento, recursos y procesos. La Gestion del Conocimiento es una disciplina importante que mediante un proceso sistematico permite crear y usar el conocimiento [15]; siendo el conocimiento una mezcla de experiencia, valores, informacion y "saber hacer", que sirve como marco para la incorporacion de nuevas experiencias e informacion, y el cual resulta util para la accion [16]. En esta linea, y debido a que la participacion del usuario es un factor que contribuye en el exito del proceso de elicitacion de requisitos [17], el presente trabajo pretende abordar la administracion del conocimiento de las necesidades del usuario y el conocimiento (tecnico, del negocio, etc.) de los elicitadores frente a la pregunta: ?como apoyar la recoleccion de requisitos no funcionales en el proceso de elicitacion de requisitos dentro de las organizaciones siguiendo un enfoque de Gestion del Conocimiento?

El aporte de este trabajo es la integracion de procesos de creacion y transformacion del conocimiento con el proceso de elicitacion de requisitos no funcionales, desde sus etapas mas tempranas, de manera que se logra involucrar a los usuarios finales en actividades que permiten la obtencion de los requisitos no funcionales y, de la misma manera, apoyar en dar mayor claridad y visibilidad a estas caracteristicas de calidad del software dentro de los procesos de elicitacion de requisitos que se lleven a cabo en las organizaciones.

3. Propuesta

Para abordar este problema y dar respuesta a la pregunta de investigacion, se propone la creacion de un marco de trabajo que permita incluir de manera efectiva los requisitos no funcionales en el proceso de elicitacion de requisitos bajo el enfoque de Gestion de Conocimiento. En la creacion de este marco es importante utilizar una estrategia de investigacion adecuada que permita abordar de una manera rigurosa y cientifica el problema, ademas de entender la transformacion del conocimiento durante el proceso de ER no funcionales. En este sentido, a continuacion de se presenta la estrategia de investigacion que se utilizara para desarrollar la propuesta, luego el modelo SECI, posteriormente una descripcion de como se transforma el conocimiento durante la ejecucion del proceso de elicitacion de requisitos no funcionales y, por ultimo, algunos beneficios de incluir los requisitos no funcionales en el proceso de elicitacion

3.1 Estrategia de investigacion

La estrategia de investigacion utilizada en este trabajo es la investigacion-accion multiciclo con bifurcacion [18], a partir de la cual se desarrollaran los siguientes ciclos: conceptual, metodologico, de evaluacion y de documentacion. En el ciclo conceptual se identifica de manera concreta el problema dentro del contexto del proceso de desarrollo de software y se revisa la literatura buscando tanto caracteristicas de calidad, mecanismos y tecnicas para realizar el proceso de elicitacion de RNF, asi como conceptos relacionados con la Gestion de Conocimiento. En el ciclo metodologico se identifican y definen los componentes del marco de trabajo frente al proceso de elicitacion de requisitos no funcionales y de la Gestion del Conocimiento, de manera que se logra una estructura especifica de la alternativa de solucion al problema de investigacion. En los ultimos dos ciclos de la estrategia, evaluacion y documentacion, se cubre el diseno del caso de estudio, su ejecucion y analisis de resultados, asi como la culminacion de la documentacion obtenida durante todo el proceso de investigacion, finalizando con la divulgacion de los resultados obtenidos.

3.2 Gestion del conocimiento y elicitacion de requisitos no funcionales

La gestion del conocimiento es un proceso de responsabilidad de la alta gerencia, la cual debe propiciar ambientes que atraigan y sostengan la creacion, uso y accesibilidad del nuevo conocimiento, con el fin de ahorrar tiempo, mejorar la productividad, propiciar la innovacion y apoyar a la gestion de los procesos [19]. El proceso de creacion de conocimiento en las organizaciones se da a traves de la interaccion entre conocimiento explicito y tacito [20]. El modelo SECI es propuesto por [20] para la creacion de conocimiento, el cual define cuatro formas para realizar "conversion de conocimiento": socializacion, externalizacion, combinacion e internalizacion, como lo muestra la Figura 1.

[FIGURA 1 OMITIR]

La Gestion de Conocimiento permitira aportar al proceso de consecucion, analisis y definicion de los requisitos no funcionales, de manera que considere el conocimiento que esta en los recursos (cliente, elicitador, activos de conocimiento) durante la ejecucion del proceso de elicitacion. De esta manera estaremos acercandonos, con mayor precision, a lograr la calidad del producto software. Segun el Software Engineering Institute (SEI), para lograr la calidad en los productos de software se deben combinar las siguientes tres dimensiones organizacionales: las personas, los metodos y procedimientos, y las herramientas, siendo los procesos utilizados por la organizacion los que permiten evolucionar e incorporar los conocimientos de como hacer mejor las cosas [21]

3.3 Transformacion del conocimiento en el proceso de elicitacion de requisitos no funcionales

La Figura 2 nos muestra una descripcion sobre como se da la transformacion del conocimiento durante el proceso d e elicitacion de RNF. Al iniciar el proceso es el elicitador quien debe contextualizar al usuario sobre lo que son, la importancia y las posibles maneras de identificar los RNF para el producto software a desarrollar (socializacion). En este momento, el conocimiento tacito del usuario es menor frente al grado de conocimiento tacito del elicitador en relacion con los RNF. El usuario omite estos aspectos durante el proceso de elicitacion [3] [12]; por lo tanto, desconoce los RNF, mientras que el elicitador ya cuenta con determinada formacion y experiencia sobre la existencia de los RNF y la importancia de determinarlos.

[FIGURA 2 OMITIR]

A medida que se realiza esta transferencia de conocimiento, el usuario adquiere nueva informacion, de modo que empieza a entender e interiorizar los conceptos, la importancia, los propositos y las formas de identificar los RNF (internalizacion en el usuario). En esta dinamica de retroalimentacion, el elicitador podra utilizar la informacion obtenida para ir concretando los RNF determinados por el usuario (internalizacion en el elicitador). Al terminar estas actividades iniciales de elicitacion, el elicitador podra elaborar un primer documento de especificacion de los RNF del producto (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 (combinacion). Cuando se tiene este documento, se comparte con el usuario para buscar su validacion y aprobacion, a fin de que pueda ser considerado como documento final del proceso de elicitacion de requisitos NF.

3.4 Beneficios de la propuesta para las organizaciones

Esta propuesta podria apoyar a las organizaciones en la consecucion de beneficios que, desde la propia experiencia, se han identificado a traves del trabajo llevado a cabo durante 15 anos en el campo de administracion de procesos en diferentes empresas de la industria de software nacional; entre los cuales estan:

* Mayor concientizacion de los usuarios frente a la importancia y relevancia de estos aspectos no funcionales en el momento de la recoleccion y posterior aprobacion de la especificacion del sistema.

* Al lograr una mayor conciencia de estos aspectos se ira fortaleciendo el proceso de elicitacion en las organizaciones, de manera que se empiece a incluir lo no funcional como factor necesario para lograr la calidad.

* Los usuarios y demas interesados alcanzaran un mayor grado de confianza con respecto a la informacion critica para el negocio que genere el sistema, debido a que podran verificar estos resultados a traves de los elementos no funcionales que sean identificados e incluidos en el momento de la elicitacion.

* Disminucion de los eventos reportados al grupo de soporte de las organizaciones, como consecuencia de la capacidad del producto para indicar al usuario final sobre el motivo de los errores y la ruta para solucionarlos.

* Se podra generar un plan de pruebas mucho mas robusto, que permita a las organizaciones evidenciar el comportamiento del sistema en un escenario de pruebas, generando mayor tranquilidad en los usuarios con respecto a su comportamiento en terminos de tiempos de respuesta y de los componentes de arquitectura (base de datos, canales de comunicacion, servidores, equipos cliente etc.). Esto es, obtener informacion cuantitativa y cualitativa oportunamente sobre el desempeno del producto, permitiendo la toma decisiones con respecto a la futura arquitectura que se utilizara en el entorno productivo.

* Todos los aspectos no funcionales que se logren recolectar durante la elicitacion permitiran un mayor volumen de informacion relevante para el posterior diseno de la arquitectura del producto. Estos aspectos podran ser tenidos en cuenta al momento de tomar decisiones referentes al dimensionamiento de las necesidades de hardware (conocido como sizing) por las organizaciones y su departamento de tecnologia.

* Esta informacion no funcional podria llevar a los administradores del sistema a definir un plan de monitoreo del sistema bajo el entorno productivo, de manera que se logre disminuir la atencion de emergencias y correctivos frente a la disponibilidad del servicio que presta el producto software; esto es, se podra brindar un servicio de soporte tecnologico de tipo preventivo a la organizacion.

* Cada uno de estos aspectos no funcionales que se incluyan en el plan de monitoreo, y que, por lo tanto, ameriten ser medidos y controlados, podrian apoyar en la definicion de los indicadores del servicio de soporte del departamento de tecnologia, toda vez que estas mediciones sobre el producto software se convierten en bases estadisticas para cumplir con la responsabilidad de seguimiento y mantenimiento a los sistemas de informacion como activos tecnologicos de las organizaciones.

* Esta inevitable relacion entre el proceso de elicitacion de requisitos no funcionales y el proceso de diseno de la arquitectura del producto, podrian beneficiar en la convergencia y cohesion de esfuerzos de los integrantes del departamento de tecnologia de las organizaciones, de modo que se mejore la calidad del servicio como area de apoyo dentro de la organizacion.

* Las interacciones y participacion de diferentes niveles y tipos de conocimiento (funcional, tecnico y de negocio) durante el proceso de elicitacion de requisitos no funcionales, permite a los ingenieros involucrados en este proceso fortalecer continuamente su conocimiento integral del negocio, asi como afianzar su conocimiento tecnico, ejecutando procesos de ingenieria mucho mas maduros en pro de los objetivos y metas organizacionales.

* La definicion clara de los aspectos no funcionales referentes al producto de software, permitira un analisis, diagnostico y atencion mas rapidos y precisos ante los eventos de emergencia reportados por los usuarios, logrando un mejor tiempo de respuesta del servicio del departamento de tecnologia; esto, debido a que la elicitacion de requisitos no funcionales permite al final obtener la correlacion de estos aspectos no funcionales con la funcionalidad del producto, haciendo las veces de mapa de ruta para la atencion de eventos.

* El conocimiento de quienes participan de manera activa en procesos de elicitacion de requisitos no funcionales, tanto usuarios como ingenieros de software, podran obtener mayor habilidad frente al proceso, lo que creara un habito organizacional de inclusion de los requisitos no funcionales en sus proyectos de desarrollo de software.

4. Conclusiones

La literatura encontrada hasta el momento permite confirmar la importancia de realizar mayores esfuerzos en el tema de elicitacion de requisitos no funcionales. En esta literatura se evidencia que las caracteristicas de calidad del software requieren ser visualizadas de forma mas clara ante las organizaciones que realizan proyectos de desarrollo de software; por otro lado, la Gestion del Conocimiento ofrece aspectos que pueden ser usados para incluir los requisitos no funcionales en el proceso de elicitacion de requisitos, ya que abarca todas las fuentes posibles de conocimiento dentro de las organizaciones, tales como los procesos, los interesados y la tecnologia existente. Es asi como este escenario de investigacion posibilita la generacion de una propuesta sobre el como realizar la elicitacion de requisitos no funcionales desde la perspectiva de Gestion de Conocimiento.

Estos esfuerzos podran ser realizados por las organizaciones a medida que se brinden mecanismos practicos que faciliten su apropiacion dentro de sus procesos de desarrollo de software. La Gestion de Conocimiento es un enfoque que surge como alternativa aplicable para la mejora de procesos relacionados con el conocimiento de los usuarios finales (stakeholders), dentro del contexto de la elicitacion de requisitos. En este orden de ideas, en este trabajo se ha presentado un modelo de como se transforma el conocimiento durante la elicitacion de requisitos no funcionales (y algunos beneficios de considerar este tipo de requisitos). Como trabajo futuro se abordara la definicion de un marco de trabajo que permita incluir de manera efectiva los requisitos no funcionales en el proceso de elicitacion y este basado en el modelo definido.

Agradecimientos

Este trabajo ha sido financiado por el proyecto "Marco de trabajo para la elicitacion de requisitos no funcionales basado en la gestion del conocimiento" (Vicerrectoria de Investigaciones de Unicauca--VRI ID 4354). Los autores agradecen a: (i) Brenda L. Flores Rios por su valiosos aporte y sugerencias; y (ii) la Universidad del Cauca, donde Sandra Buitron cursa la Maestria en Computacion y Francisco J. Pino trabaja como profesor titular

Referencias

[1] Mohammed, N., Munassar, A. & Govardhan, A. (2010). A Comparison Between Five Models Of Software Engineering. IJCSI International Journal of Computer Science Issues 7, 5, 94-101.

[2] Pandey, D., Suman, U. & Ramani, K. (Oct., 2010). An Effective Requirement Engineering Process Model for Software Development and Requirements Management. 2010 Int. Conf. Adv. Recent Technol. Commun. Comput. 287-291.

[3] Hofmann, H. F. & Motors, G. (Aug., 2001). Requirements Engineering as a Success Factor in Software Projects.

[4] Zowghi, D. & Coulin, C. (2005). Requirements Elicitation: A Survey of Techniques, Approaches, and Tools. Eng. Manag. Softw. Requir. 19-46.

[5] Engineering, S. & Committee, S. (1998). IEEE Recommended Practice for Software Requirements Specifications.

[6] IEEE Computer. (2014). Guide to the Software Engineering Body of Knowledge Version 3.0 (SWEBOK Guide V3.0).

[7] Chung, L., Cesar, J. & Leite, P. (2009). On Non-Functional Requirements in Software. pp. 363-379.

[8] Casamayor, A., Godoy, D. & Campo, M. (Apr., 2010). Identification of non-functional requirements in textual specifications: A semi-supervised learning approach. Inf. Softw. Technol., 52, 4, 436-445.

[9] Franch, X. & Botella, P. (1998). Putting Non-Functional Requirements into, 1158.

[10] Serna-Montoya, E. (2011). Estado actual de la investigacion en requisitos no funcionales 1, 2126, 225-246.

[11] Mijanur Rahman, M. & Ripon, S. (2013). Elicitation and Modeling Non-Functional Requirements --A POS Case Study. Int. J. Futur. Comput. Commun. 2, 5, 485-489.

[12] Cysneiros, L. M. & Yu, E. (2004). Chapter # Non-functional requirements.

[13] Standish Group's International. (2002). The standish group report [C]. 1-8.

[14] Garzas, J., Pino, F. J., Piattini, M. & Manuel, C. (2013). A maturity model for the Spanish software industry based on ISO standards.

[15] Nonaka, I. & Teece, D. J. (1998). Managing Industrial Knowledge.

[16] Davenport, B. T. H., Prusak, L. & Webber, A. (2011). Working Knowledge: How Organizations Manage What They Know. 1-15.

[17] Adhavji, N. A. H. M., El Emam, K. & Madhavji, N. H. (March, 1995). A Field Study of Requirements Engineering Practices in Information Systems Development A Field Study of Requirements Engineering Practices in Information Systems Development.

[18] Pino, F. J., Piattini, M. & Travassos, G. H. (2013). Managing and developing distributed research projects in software engineering by means of Gestion y desarrollo de proyectos de investigacion distribuidos en ingenieria del software por medio de investigacion-accion. pp. 61-74.

[19] Milena, C. & Raza, H. (2014). Tecnica para el analisis de requisitos de software basada en la gestion del conocimiento, para la empresa de desarrollo de software Kruger.

[20] Nonaka, I., Toyama, R. & Konno, N. (2000). SECI, Ba and Leadership: a Uni [R] edModel of Dynamic Knowledge Creation, vol. 33, 5-34.

[21] Chrissis, M. B. & Torralba, J. (2009). CMMI [R] Guia para la integracion de procesos y la mejora de productos.

Sandra L. Buitron (1)

Francisco J. Pino (2)

(1) Grupo IDIS, Facultad de Ingenieria Electronica y Telecomunicaciones, Universidad del Cauca. Calle 2 No. 21 DN--100. Popayan, Colombia. Correspondencia: Tel.: 57+8366330. Correo electronico: sandrabr@unicauca.edu.co.

(2) Grupo IDIS, Facultad de Ingenieria Electronica y Telecomunicaciones, Profesor Titular de la Universidad del Cauca, Calle 5 No. 4-70. Correspondencia: Tel: +5728209800 Ext. 2117. Correo electronico: fjpino@unicauca.edu.co

Fecha de recepcion: 16/04/2015--Fecha de aceptacion: 30/06/2015.
COPYRIGHT 2015 Universidad Autonoma de Occidente
No portion of this article can be reproduced without the express written permission from the copyright holder.
Copyright 2015 Gale, Cengage Learning. All rights reserved.

Article Details
Printer friendly Cite/link Email Feedback
Author:Buitron, Sandra L.; Pino, Francisco J.
Publication:Revista El Hombre y la Maquina
Date:Jan 1, 2015
Words:3972
Previous Article:Laser de rayos X generados por atomos hadronicos.
Next Article:Linea de Base Energetica en la implementacion de la norma ISO 50001. Estudios de casos.
Topics:

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