REVISTA LATINOAMERICANA DE INGENIERIA DE SOFTWARE

Transcripción

1 REVISTA LATINOAMERICANA DE INGENIERIA DE SOFTWARE FEBRERO 2013 VOLUMEN 1 NUMERO 1 ISSN PUBLICADO POR EL GISI-UNLa EN COOPERACIÓN POR LOS MIEMBROS DE LA RED DE INGENIERÍA DE SOFTWARE DE LATINOAMÉRICA ARTÍCULOS TÉCNICOS Reglas Sintáctico-Semánticas para Relacionar los Objetivos Organizacionales y los Problemas en el Contexto de la Educción Temprana de Requisitos de Software Carlos Mario Zapata, Fabio Alberto Vargas Modelos para Asistir la Gestión de Proyectos de Explotación de Información Pablo Pytel, Paola Britos, Ramón García-Martínez Análisis del Comportamiento de Robots Móviles con RNA. Un Acercamiento desde el Paradigma Reactivo Alejandro Hossian, Gustavo Monte, Verónica Olivera COMUNICACIONES SOBRE INVESTIGACIONES EN PROGRESO Investigación en Progreso: Sistemas Inteligentes en Arquitecturas de Motores para Videojuegos Hernán Merlino, Pablo Pytel, Darío Rodríguez Investigación en Progreso: Espacios Virtuales para Trabajo Colaborativo Darío Rodríguez, Norberto Charczuk, Ramón García-Martínez

2 REVISTA LATINAMERICANA DE INGENIERIA DE SOFTWARE La Revista Latinoamericana de Ingenieria del Software es una publicación tecnica auspiciada por la Red de Ingeniería de Software de Latinoamérica (RedISLA). Busca: [a] difundir artículos técnicos, empíricos y teóricos, que resulten críticos en la actualización y fortalecimiento de la Ingeniería de Software Latinoamericana como disciplina y profesión; [b] dar a conocer de manera amplia y rápida los desarrollos científico-tecnológicos en la disciplina de la región latinoamericana; y [c] contribuir a la promoción de la cooperación institucional entre universidades y empresas de la Industria del Software. La línea editorial, sin ser excluyente, pone énfasis en sistemas no convencionales, entre los que se prevén: sistemas móviles, sistemas, plataformas virtuales de trabajo colaborativo, sistemas de explotación de información (minería de datos), sistemas basados en conocimiento, entre otros; a través del intercambio de información científico y tecnológica, conocimientos, experiencias y soluciones que contribuyan a mejorar la cadena de valor del desarrollo en la industria del software. Comité Editorial PAOLA BRITOS Grupo de Ingeniería de Explotación de Información Laboratorio de Informática Aplicada Universidad Nacional de Río Negro RAMON GARCÍA-MARTINEZ Grupo de Investigación en Sistemas de Información Licenciatura en Sistemas Departamento de Desarrollo Productivo y Tecnológico Universidad Nacional de Lanús ALEJANDRO HOSSIAN Grupo de Investigación de Sistemas Inteligentes en Ingeniería Facultad Regional del Neuquén Universidad Tecnológica Nacional CLAUDIO MENESES VILLEGAS Departamento de Ingeniería de Sistemas y Computación Facultad de Ingeniería y Ciencias Geológicas Universidad Católica del Norte JONÁS MONTILVA C. Facultad de Ingeniería Escuela de Ingeniería de Sistemas Universidad de Los Andes JOSÉ ANTONIO POW-SANG Maestría en Informática Pontifica Universidad Católica del Perú CARLOS MARIO ZAPATA JARAMILLO Departamento de Ciencias de la Computación y de la Decisión Facultad de Minas Universidad Nacional de Colombia BELL MANRIQUE LOSADA Programa de Ingeniería de Sistemas Facultad de Ingeniería Universidad de Medellín MARÍA FLORENCIA POLLO-CATTANEO Grupo de Estudio en Metodologías de Ingeniería de Software Facultad Regional Buenos Aires Universidad Tecnológica Nacional Contacto Dirigir correspondencia electrónica a: Editor de la Revista Latinoamericana de Ïngenieria de Software RAMON GARCIA-MARTINEZ rgarcia@unla.edu.ar alternativo: rgm1960@yahoo.com Página Web de la Revista: Página Web Institucional: Dirigir correspondencia postal a: Editor de la Revista Latinoamericana de Ïngenieria de Software RAMON GARCIA-MARTINEZ Licenciatura en Sistemas. Departamento de Desarrollo Productivo y Tecnológico Universidad Nacional de Lanus Calle 29 de Septiembre No (1826) Remedios de Escalada, Lanús. Provincia de Buenos Aires. ARGENTINA. Normas para Autores Cesión de Derechos de Autor Los autores toman conocimiento y aceptan que al enviar una contribución a la Revista Latinoamericana de Ingenieria del Software, ceden los derechos de autor para su publicación electrónica y difusión via web por la Revista. Los demas derechos quedan en posesión de los Autores. Políticas de revisión, evaluación y formato del envío de manuscritos La Revista Latinoamericana de Ingenieria del Software recibe artículos inéditos, producto del trabajo de investigación y reflexión de investigadores en Ingenieria de Software. Los artículos deben presentarse redactados en el castellano en el formato editorial de la Revista. El incumplimiento del formato editorial en la presentación de un artículo es motivo de retiro del mismo del proceso de evaluación. Dado que es una publicación electrónica no se imponen limites sobre la cantidad de paginas de las contribuciones enviadas. También se pueden enviar comunicaciones cortas que den cuenta de resultados parciales de investigaciones en progreso. Las contribuciones recibidas están sujetas a la evaluación de pares. Los pares que evaluaran cada contribución son seleccionados por el Comité Editorial. El autor que envíe la contribución al contacto de la Revista será considerado como el autor remitente y es con quien la revista manejará toda la correspondencia relativa al proceso de evaluación y posterior comunicación. Del proceso de evaluación, el articulo enviado puede resultar ser: [a] aceptado, en cuyo caso será publicado en el siguiente numero de la revista, [b] aceptado con recomendaciones, en cuyo caso se enviará al autor remitente la lista de recomendaciones a ser atendidas en la nueva versión del articulo y su plazo de envio; ó [c] rechazado, en cuyo caso será devuelto al autor remitente fundando el motivo del rechazo. Temática de los artículos La Revista Latinoamericana de Ingeniería del Software busca artículos empíricos y teóricos que resulten críticos en la actualización y fortalecimiento de la Ingeniería de Software Latinoamericana como disciplina y profesión. La línea editorial pone énfasis en sistemas no convencionales, entre los que se prevén: sistemas móviles, sistemas multimediales vinculados a la televisión digital, plataformas virtuales de trabajo colaborativo, sistemas de explotación de información (minería de datos), sistemas basados en conocimiento, entre otros. Se privilegiarán artículos que contribuyan a mejorar la cadena de valor del desarrollo en la industria del software. Política de Acceso Abierto La Revista Latinoamericana de Ingeniería de Software: Sostiene su compromiso con las políticas de Acceso Abierto a la información científica, al considerar que tanto las publicaciones científicas como las investigaciones financiadas con fondos públicos deben circular en Internet en forma libre, gratuita y sin restricciones. Ratifica el modelo de Acceso Abierto en el que los contenidos de las publicaciones científicas se encuentran disponibles a texto completo libre y gratuito en Internet, sin embargos temporales, y cuyos costos de producción editorial no son transferidos a los autores. No retiene los derechos de reproducción o copia (copyright), por lo que los autores podrán disponer de las versiones finales de publicación, para difundirlas en repositorios institucionales, blogs personales o cualquier otro medio electrónico, con la sola condición de hacer mención a la fuente original de publicación, en este caso Revista Latinoamericana de Ingeniería de Software. Lista de Comprobación de Preparación de Envíos Como parte del proceso de envío, se les requiere a los autores que indiquen que su envío cumpla con todos los siguientes elementos, y que acepten que envíos que no cumplan con estas indicaciones pueden ser devueltos al autor: 1. La contribución respeta el formato editorial de la Revista Latinoamericana de Ingenieria del Software (ver plantilla). 2. Actualidad/Tipo de referencias: El 45% de las referencias debe hacerse a trabajos de publicados en los últimos 5 años, así como a trabajos empíricos, para cualquier tipo de artículo (empírico o teórico). 3. Características artículos empíricos (análisis cuantitativo de datos): Se privilegian artículos empíricos con metodologías experimentales y cuasi experimentales, con pruebas estadísticas robustas y explicitación del cumplimiento de los supuestos de las pruebas estadísticas usadas. 4. Características artículos empíricos (análisis cualitativo de datos): Se privilegian artículos empíricos con estrategias de triangulación teórica-empírica, definición explícita de categorías orientadoras, modelo teórico de análisis, y análisis de datos asistido por computadora. 5. Características artículos de revisión: Para el caso de artículos de revisión, se evaluará que los mismos hayan sido desarrollados bajo el formato de meta análisis, la cantidad de referencias deben superar las 50, y deben explicitarse los criterios de búsqueda, bases consultadas y pertinencia disciplinar del artículo. 6. El artículo (en formato word y pdf) se enviará adjunto a un correo electrónico dirigido al contacto de la Revista en el que deberá constar la siguiente información: dirección postal del autor, dirección de correo electrónico para contacto editorial, número de teléfono y fax, declaración de que el artículo es original, no ha sido previamente publicado ni está siendo evaluado por otra revista o publicación. También se debe informar de la existencia de otras publicaciones similares escritas por el autor y mencionar la versión de la aplicación de los archivos remitidos (versión del editor de texto y del conversor a archivo pdf) para la publicación digital del artículo. 7. Loa Autores aceptan que el no cumplimiento de los puntos anteriores es causal de No Evaluación del articulo enviado. Compromiso de los Autores de Artículos Aceptados La Revista Latinoamericana de Ingeniería del Software busca ser una revista técnica de calidad, en cuyo desarrollo estén involucrados los investigadores y profesionales latinoamericanos de la disciplina. En este contexto, los Autores de artículos aceptados asumen ante la Revista y la Comunidad Latinoamericana de Ingeniería del Software el compromiso de desempeñarse como pares evaluadores de nuevas contribuciones.

3 Reglas Sintáctico-semánticas para Relacionar los Objetivos Organizacionales y los Problemas en el Contexto de la Educción Temprana de Requisitos de Software Carlos Mario Zapata Jaramillo Facultad de Minas Universidad Nacional de Colombia Medellín, Colombia cmzapata@unal.edu.co Fabio Alberto Vargas Agudelo Facultad de Ingeniería Tecnológico de Antioquia Medellín, Colombia fvargas@tdea.edu.co Resumen Los procesos de ingeniería de software de alta calidad requieren la educción temprana de requisitos funcionales y no funcionales. Este proceso lo llevan a cabo los analistas y los interesados, tratando de solucionar los problemas de información de la organización y contrastándolos con el contexto del negocio, representado en sus objetivos organizacionales. Este proceso se suele realizar de forma manual y, si bien existen algunos trabajos que establecen una relación entre los problemas y los objetivos, se basan en la negación total de unos para obtener los otros. Esto conduce al desarrollo de aplicaciones de software no pertinentes para la organización, que no resuelven sus problemas prioritarios o que no se alinean con sus objetivos organizacionales. Por estas razones, en este artículo se propone una relación entre los problemas a solucionar y los objetivos organizacionales, empleando un conjunto de reglas sintáctico-semánticas que validen dicha relación y que se reflejen en requisitos consistentes y contextualizados con la organización. Estas reglas se validan con un caso de estudio. Palabras clave Objetivos Organizacionales, problemas, educción temprana de requisitos, reglas sintácticas, reglas semánticas. I. INTRODUCCIÓN La ingeniería de software (IS) viene evolucionando en su proceso de automatización, permitiendo a los analistas e interesados mejorar en muchos aspectos los métodos en los cuales participan en procura de lograr desarrollos de software de alta calidad. Cuando se desarrolla una aplicación de software en cualquier plataforma y para cualquier entorno, es de vital importancia reconocer y establecer condiciones que garanticen la pertinencia, calidad, seguridad, eficiencia y rendimiento del aplicativo de software que se implementa [1]. Por tal razón, es importante llevar a cabo las etapas del desarrollo de software (definición, análisis, diseño, desarrollo, pruebas, implementación y mantenimiento), que suministren unas pautas que conlleven al buen desarrollo del aplicativo [2]. La IS está generando propuestas de métodos, artefactos y estrategias metodológicas que buscan darle al desarrollo de software orden, estandarización y calidad. Con esto, se busca que las aplicaciones que se desarrollen se adapten a los diferentes interesados, pasando por personas u organizaciones que las requieran y teniendo en cuenta sus necesidades, expectativas y, muy especialmente, tomando en cuenta los objetivos de la organización, a fin de garantizar su cumplimiento [3]. La IS busca, en su fase de educción temprana de requisitos, un reconocimiento muy profundo de los problemas que se presentan en la organización y de los objetivos que pretenden alcanzar los actores involucrados en los diferentes procesos, a fin de proponer soluciones (aplicaciones de software) y tomar decisiones que se liguen de forma directa con los objetivos organizacionales [4]. De esta manera, se busca la especificación consistente de requisitos funcionales y no funcionales. Rebollar et al. [5] reconocen la importancia de las técnicas de ingeniería de requisitos temprana, conocidas como técnicas de modelado organizacional, ya que es la etapa fundamental para la construcción de software de alta calidad que dé respuesta a las necesidades y expectativas de los interesados y que tenga muy en cuenta los objetivos de la organización, garantizando un software contextualizado y pertinente [6]. Se reconoce que el contexto puede en un momento dado influir en los objetivos de los interesados y, por ende, en la forma de conseguirlos [6]. La captura de requisitos es un proceso manual que lleva a cabo el analista con base en su experiencia e interpretación. En esta etapa, la definición de los problemas a solucionar y su relación con los objetivos de la organización se realizan sin seguir unas pautas previas que garanticen la consistencia y, en muchos casos, esto trae consigo problemas posteriores en el ciclo de vida del desarrollo de software [7]. Existen algunos trabajos que plantean relaciones de consistencia entre objetivos y problemas, pero aún se quedan cortos, pues sólo establecen las relaciones con base en la negación total de los objetivos para obtener los problemas [2]. En este artículo se propone un conjunto de reglas sintácticas y semánticas para establecer el vínculo entre los objetivos y los problemas en el contexto de la educción temprana de requisitos. Para ello, se realiza una revisión y análisis de las metodologías para la educción temprana de requisitos de software que utilizan directamente objetivos y problemas para la especificación de los mismos, con el fin de verificar cómo estructuran sus objetivos y problemas y, además, cómo se relacionan entre ellos, para mejorar la consistencia y evitar futuros problemas en el desarrollo. Se busca determinar cuáles problemas son prioritarios para la Carlos Mario Zapata Jaramillo, Fabio Alberto Vargas Agudelo Reglas Sintáctico-semánticas para Relacionar los Objetivos Organizacionales y los Problemas en el Contexto de la Educción Temprana de Requisitos de Software. Revista Latinoamericana de Ingeniería de Software, 1(1): 1-7, ISSN

4 organización y, a partir de ellos, lograr una especificación consistente de requisitos de software funcionales y no funcionales. El artículo se estructura de la siguiente forma: en la Sección 2 se realiza una revisión y análisis de las metodologías para representar objetivos y problemas en el proceso de educción de requisitos y en el análisis organizacional; en la Sección 3 se define la metodología establecida para proponer las reglas; en la Sección 4 se presenta una propuesta sintáctica-semantica para relacionar los objetivos y los problemas; en la Sección 5 se presenta un caso de estudio basado en un diagrama de objetivos y en un diagrama causa-efecto; finalmente, se presentan las conclusiones y el trabajo futuro II. ANTECEDENTES A. Representación de objetivos y problemas en los procesos de educción temprana de requisitos Los objetivos constituyen los referentes principales para la toma de decisiones a nivel organizacional, ya que son los ejes que rigen cualquier proceso de negocios. Por tal motivo, deben poseer una coherencia en su representación y expresión que garantice a interesados y analistas su interpretación y relación con otros componentes básicos de algún proceso que se inicie en la organización. A nivel de desarrollo de software, es necesario facilitar la representación de los objetivos en los diferentes diagramas y modelos utilizados en los procesos de educción temprana de requisitos. La representación de objetivos y problemas en el proceso de educción de requisitos se realiza con algunas metodologías como KAOS e I*. KAOS (Knowledge Acquisition automated Specification) [8] plantea la representación de un árbol de objetivos, el cual se enfoca en realizar un proceso de análisis formal de los requisitos. El proceso para el trazado del diagrama de objetivos de KAOS requiere que se definan los objetivos secundarios que subrogan los objetivos generales, para luego presentarlos en objetivos más elementales que los subrogan y así sucesivamente hasta llegar a objetivos que se consideren elementales o atómicos o hasta que se alcancen expectativas, requisitos o propiedades del dominio. Con el diagrama de objetivos se busca señalar cuáles de los objetivos subrogados satisfacen actualmente los procesos del área. Se debe notar que la incapacidad de dar satisfacción a los objetivos generales se asocia con la incapacidad de dar satisfacción a los objetivos subrogados. El diagrama de objetivos se realiza no sólo para el área problemática, sino para la organización que la rodea, porque se requiere que la aplicación de software del área se contextualice y se pueda determinar su influencia en la organización, evaluando la viabilidad de cumplimiento de los objetivos subrogados pertenecientes a esa área. El analista construye de manera subjetiva el diagrama, garantizando manualmente la consistencia entre sus elementos. Además, no se plantean estructuras claras para definir objetivos y, en algunos casos, los objetivos planteados dan mayor cuenta de operaciones y no realmente de objetivos. Zapata y Vargas [7] anotan que la estructura y definición de objetivos y requisitos dentro del diagrama de objetivos de KAOS es una tarea del analista, quien lo define de acuerdo con la interpretación y el conocimiento adquirido del área y de la organización, con base en las reuniones con los interesados y en la exploración documental realizada. I* [9] es un lenguaje orientado a objetivos que incluye nodos que representan actores, objetivos, tareas y recursos, además de un conjunto de relaciones entre ellos. Es un enfoque que utiliza la idea de softgoal. La principal particularidad del modelado de negocio sobre otros campos de la ingeniería de requisitos es la importancia de los agentes. Un agente se define como una entidad que existe en la organización, que tiene objetivos y que puede realizar tareas o utilizar recursos para alcanzar dichos objetivos o ayudar a otros agentes a alcanzar sus objetivos. I* tiene una alta dependencia del analista en la elaboración de los diagramas y tampoco existe una estructura sintáctico-semántica que ayude a estructurar adecuadamente los objetivos, para su fácil relación con otros componentes del sistema. Zapata y Lezcano [10] plantean algunos problemas que se presentan en los diagramas de objetivos de KAOS e I*: es difícil automatizar el proceso porque los analistas suelen construir el diagrama de objetivos de forma subjetiva, tomando como base la información que suministran los interesados y se suele presentar una confusión entre los verbos que denotan objetivos y aquellos que expresan operaciones del dominio. Rebollar et al. [5], Bresciani et al. [11] y Ali et al. [12, 13] plantean TROPOS como una metodología para el modelado organizacional, muy utilizada en los procesos de educción temprana de requisitos de software. Esta metodología permite capturar no sólo el qué o el cómo, sino también el porqué del desarrollo del software en la organización. Esta metodología, además, permite realizar una descripción detallada de las dependencias del sistema a desarrollar y logra una adecuada especificación de requisitos funcionales y no funcionales. TROPOS utiliza dos diagramas para la representación del ambiente organizacional, vitales en la educción temprana de requisitos que plantea la metodología: el diagrama de actores, el cual describe los actores, sus objetivos y las dependencias entre ellos, y el diagrama de objetivos, el cual muestra detalladamente la relación entre los objetivos y los actores [5]. Esta metodología continúa presentando los problemas que enuncian Zapata y Lezcano [10]. Ali et al. [6] plantean un modelo de Ingeniería de requisitos orientado hacia objetivos como extensión de TROPOS, donde se especifica que estos son una abstracción útil de las necesidades y expectativas de los interesados y que facilitan su representación. Para Choi et al. [14] los requisitos en lenguaje natural se expresan mediante objetivos y escenarios, utilizando una estructura semántica para representarlos. Los objetivos, en general son oraciones que se representan mediante un verbo, un objeto conceptual o físico, una dirección de origen o destino y la forma o camino en que se van a lograr. Los escenarios se representan mediante una oración que contiene los siguientes componentes: un agente o actor, un verbo, un objeto conceptual o físico, una dirección de origen o destino y una forma o camino. Zapata y Vargas [15] especifican reglas gramaticales para enunciar problemas, objetivos y la relación entre ellos, que se aplican en el proceso de educción de requisitos de software, así como en el análisis organizacional. En las Tablas I, II y III se muestran ejemplos de la aplicación de las reglas. Las abreviaturas empleadas en las tablas, son las siguientes: O=Oración, V=Verbo, Ad=Adjetivo, SN=Sintagma Nominal, Adv=Adverbio, S=Sustantivo, V1=Verbo, V2=Verbo, Ad=Adjetivo, SN1=Sintagma Nominal, SN2=Sintagma Nominal, Adv1=Adverbio, Adv2=Adverbio, C=Conjunción. 2 Carlos Mario Zapata Jaramillo, Fabio Alberto Vargas Agudelo Reglas Sintáctico-semánticas para Relacionar los Objetivos Organizacionales y los Problemas en el Contexto de la Educción Temprana de Requisitos de Software. Revista Latinoamericana de Ingeniería de Software, 1(1): 1-7, ISSN

5 TABLA I. ESTRUCTURAS GRAMATICALES PARA ENUNCIAR PROBLEMAS [15] Caso Descripción Restricciones Ejemplos 1 O V+Ad+S N V {en forma reflexiva impersonal o voz pasiva refleja, por ejemplo: hay, existe, presenta } Ad {debe tener una connotación negativa; se sugieren palabras como bajo, poco, malo, etc.} Se presenta baja producción de materia prima en la fábrica de telares. Existen malas condiciones habitacionales en el conjunto residencial. TABLA II. ESTRUCTURAS GRAMATICALES PARA ENUNCIAR OBJETIVOS [15] Caso Descripción Restricciones Ejemplos 1 O V1+Ad+ SN V1 {Verbo de logro} Ad {Debe tener connotación positiva. Por ejemplo: Alta, buena, Adecuada } Lograr alta producción de materia prima en la fábrica de telares. Lograr buenas condiciones habitacionales en el conjunto residencial. TABLA III. REGLAS DEFINIDAS PARA RELACIÓN ENTRE PROBLEMAS Y OBJETIVOS [15] Caso Descripción Restricciones Ejemplos 1 O V+Ad1+ SN P V1+Ad2+ SN V {Verbo de logro} V1 {en forma reflexiva impersonal o voz pasiva refleja} SN {Se usa el mismo sintagma nominal tanto para el objetivo como para el problema.} Ad1 y Ad2 {Los adjetivos deben poseerconnotaciones contrarias.} Objetivo: Lograr alta producción de materia prima en la fábrica de telares. Problema: Existe baja producción de materia prima en la fábrica de telares. Objetivo: Lograr buenas condiciones habitacionales en el conjunto residencial. Problema: Existen malas condiciones habitacionales en el conjunto residencial. Eriksson y Penker [16] estructuran un modelo objetivo/problema que especifica los objetivos y subobjetivos de la organización e indica los problemas que se deben resolver a fin de alcanzar dichos objetivos. Este modelo se basa en una extensión del diagrama de objetos de UML. Este modelo no especifica estructuras para representar objetivos ni problemas y tampoco plantea estrategias para relacionarlos. Toda la tarea sigue siendo del analista basado en su experiencia y conocimiento. B. Representación de objetivos y problemas en los procesos de educción temprana de requisitos A nivel de análisis organizacional, Ortegón et al. [17] plantean que la metodología de Marco Lógico utiliza un árbol de objetivos y un árbol de problemas, en los cuales se representan los objetivos y las situaciones futuras a la que se desea llegar una vez se resuelvan los problemas plasmados en el árbol. Para la relación entre el árbol de objetivos y el árbol de problemas se tienen en cuenta algunas reglas como: los estados negativos encontrados en los problemas se convierten en estados positivos alcanzados; los problemas se reformulan convirtiéndolos en objetivos y el problema central detectado se convierte también en un objetivo central del proceso. Todo este proceso lo lleva a cabo en forma manual el analista organizacional. En la metodología Kepner-Tregoe [18] se implementa un procedimiento para la solución de problemas que facilita la toma de decisiones al interior de la organización. Para ello, se realiza una serie de etapas que incluyen el análisis de situaciones, el análisis de problemas, el análisis de objetivos de la decisión a tomar y el análisis de problemas potenciales a ocurrir después de la decisión tomada. La metodología exige que los objetivos describan los aspectos que se van a lograr en forma precisa y situarlos en un tiempo y un lugar definido, pero no plantea una estructura precisa para realizar esa descripción. III. ANTECEDENTES A. Fase de Exploración En esta fase se realizó una revisión de literatura y un análisis de las metodologías de educción temprana de requisitos de software que utilizan problemas y objetivos, las formas de representación y la relación que puede existir entre problemas y objetivos a fin de identificar los avances y las falencias que existen en esta temática. Se realizó una exploración de estas mismas metodologías para determinar cómo llevan a cabo el proceso de captura de requisitos, procurando definir cuál es la tarea del analista y cómo él establece los problemas y los objetivos de la organización y su relación para determinar cuáles problemas requieren una solución prioritaria empleando una aplicación de software. También, se analizaron los artículos en los cuales se especifican posibles estructuras sintáctico-semánticas para expresar objetivos y problemas que ayuden al analista de sistemas en la elaboración de los diferentes diagramas, profundizando en la oración y su forma de enunciarla. B. Fase de Definición Teniendo como base las estructuras de objetivos y problemas planteadas en los diferentes diagramas revisados, es decir KAOS [8], I* [9], TROPOS [5, 11, 12 y 13] y el modelo objetivo/problema [16] y además la fase de exploración realizada, se estableció un conjunto de reglas sintácticosemánticas que permitieron la relación automática entre objetivos y problemas en los procesos de educción temprana de requisitos. Como base para la representación se emplearon los denominados esquemas preconceptuales [19] dada su cercanía con el lenguaje natural del interesado y la posibilidad de definir animaciones de la especificación en forma de esquemas preconceptuales ejecutables. La sintaxis básica de los esquemas preconceptuales se muestra en la Figura 1. En los conceptos se colocan los sustantivos o frases nominales del dominio; las notas contienen posibles valores de los conceptos; las relaciones estructurales se asocian con los verbos ser y tener ; las relaciones dinámicas son actividades u operaciones del dominio; los condicionales son expresiones que pueden disparar relaciones dinámicas; las implicaciones son relaciones causa-efecto entre relaciones dinámicas o entre condicionales y relaciones dinámicas; las conexiones sirven para conectar conceptos con relaciones estructurales/dinámicas o viceversa; las conexiones concepto-nota sirven para ligar los conceptos con sus posibles valores. Para hacer ejecutable un esquema preconceptual simplemente hay que colocar los valores correspondientes en los conceptos hoja (aquellos que reciben una relación tiene y de los que no sale ninguna otra relación); Carlos Mario Zapata Jaramillo, Fabio Alberto Vargas Agudelo Reglas Sintáctico-semánticas para Relacionar los Objetivos Organizacionales y los Problemas en el Contexto de la Educción Temprana de Requisitos de Software. Revista Latinoamericana de Ingeniería de Software, 1(1): 1-7, ISSN

6 también, se representan los valores de los conceptos clase (los que no son conceptos hoja) por medio de tablas adicionales. los diferentes valores se asocian con cada uno de los conceptos hoja. VI. CONCLUSIONES Fig. 1. Sintaxis básica de los esquemas preconceptuales. C. Fase de Definición En esta fase se desarrolló un caso de estudio donde se aplicaron estas reglas en la elaboración en la representación de las relaciones entre los objetivos y los problemas durante la etapa de educción temprana de requisitos de software. IV. PROPUESTA La propuesta que se describe en este artículo parte de los problemas encontrados en secciones anteriores, donde en las metodologías correspondientes a los procesos de educción temprana de requisitos de software no se especifican mecanismos que permitan relacionar de forma consistente y automática los objetivos organizacionales con los problemas que se desean solucionar con la aplicación de software, dejando toda la responsabilidad en la experiencia e intuición del analista y, en muchos casos, generando requisitos de software poco consistentes y descontextualizados con la organización. La propuesta incluye en conjunto de reglas sintácticosemánticas que permiten relacionar un problema determinado con uno o varios objetivos organizacionales. Las reglas se construyeron teniendo en cuenta el rol semántico y el rol sintáctico de cada frase que describe un objetivo y un problema. La relación entre un objetivo y un problema se establece con base en unas restricciones, cuya estructura se define mediante una fórmula. El esquema preconceptual que describe este proceso se muestra en la Figura 2. V. CASO DE ESTUDIO Para la ejemplificación del manejo del esquema preconceptual de la Figura 2, se tomó como base un ejemplo que presenta Zapata [20] con una estructura completa de un diagrama de objetivos y un diagrama causa-efecto. La restricción que se define con la fórmula de la Figura 3 se establece de la siguiente manera: si las frases que representan un objetivo y un problema comparten al menos un sustantivo y un verbo, el objetivo y el problema tienen una relación. Para el ejemplo, el problema P10 (no todos los álbumes se pueden acceder) y el objetivo O7 (asegurar que se pueda acceder a los álbumes) comparten el verbo acceder y el sustantivo álbumes, por lo cual el resultado de la relación se fija en verdadero. Nótese en la Figura 3 que las tablas que sirven para apoyar el proceso se ubican en la parte inferior izquierda, en tanto que La educción temprana de requisitos de software, requiere, en su análisis organizacional, la identificación de problemas y objetivos y el establecimiento de una relación entre ellos, a fin de determinar qué problemas afectan el logro de un objetivo de la organización y, por ende, el buen desarrollo de la misma. Las relaciones de consistencia entre objetivos y problemas, pueden conducir a un mejor análisis de las soluciones problemáticas y, consecuentemente, al planteamiento de soluciones adecuadas y la definición consistente de requisitos funcionales y no funcionales alineados con la estrategia organizacional (sus objetivos) y que resuelvan las situaciones negativas (sus problemas). La literatura especializada no plantea métodos automáticos que permitan relacionar objetivos y problemas pues, pese a que algunos utilizan técnicas de representación tanto de objetivos como de problemas (diagrama de objetivos de KAOS, diagrama causa-efecto, árbol de problemas y árbol de objetivos de la metodología de marco lógico), sigue siendo un trabajo que depende del analista, sin que medie ningún proceso de consistencia. Las relaciones sintáctico-semánticas que se propusieron para relacionar los problemas y objetivos facilitan la tarea del analista en los diferentes procesos de educción temprana de requisitos de software, estableciendo de forma automática la consistencia que existe entre objetivos y problemas. La generación de soluciones automatizadas que apoyen a los analistas de sistemas en su proceso de educción temprana de requisitos de software, genera un mayor grado de confiabilidad en las soluciones de software planteadas, ya que éstas se alinearán con el contexto de la organización y serán pertinentes a las necesidades de la misma. Tener en cuenta en la solución los objetivos organizacionales garantiza una especificación más consistente de requisitos de software. Como líneas de trabajo futuro, se encuentran las siguientes: La definición de diferentes restricciones que permitan establecer la relación entre objetivos y problemas, desde el punto de vista sintáctico y semántico. El estudio de otras relaciones entre problemas y objetivos que ya no se liguen con las mismas palabras. En estos casos, se deberían analizar relaciones de sinonimia y proximidad. El análisis de elementos pragmáticos que permitan establecer la relación entre objetivos y problemas. Por ejemplo, para el caso de estudio podría ser intuitivamente claro que el problema no todos los álbumes se pueden acceder ataca directamente el objetivo incrementar los usuarios, pero sus frases no tienen elementos comunes ni estructuras que permitan indicar la relación que puede existir entre el objetivo y el problema. Así, se requieren mecanismos adicionales que contribuyan a definir ese nexo. La construcción de una herramienta de análisis que esté en capacidad de determinar la relación entre los objetivos y problemas y luego trazar los diagramas de manera consistente. 4 Carlos Mario Zapata Jaramillo, Fabio Alberto Vargas Agudelo Reglas Sintáctico-semánticas para Relacionar los Objetivos Organizacionales y los Problemas en el Contexto de la Educción Temprana de Requisitos de Software. Revista Latinoamericana de Ingeniería de Software, 1(1): 1-7, ISSN

7 Fig. 2. Esquema preconceptual que representa la propuesta para relacionar objetivos y problemas. Carlos Mario Zapata Jaramillo, Fabio Alberto Vargas Agudelo Reglas Sintáctico-semánticas para Relacionar los Objetivos Organizacionales y los Problemas en el Contexto de la Educción Temprana de Requisitos de Software. Revista Latinoamericana de Ingeniería de Software, 1(1): 1-7, ISSN

8 Objetivos Identificación Descripción O1 Incrementar los usuarios O2 Fomentar las galerías O3 Fomentar los archivos O4 Fomentar los permisos O5 Asegurar que las galerías tengan álbumes O6 Mantener contenidos actuales e interesantes para los usuarios del sitio O7 Asegurar que se pueda acceder a los álbumes O8 Asegurar que se permita el acceso a los contenidos para cada usuario O9 Asegurar que los álbumes tengan imágenes Problemas Identificación Descripción Palabra P1 Hay pocas galerías Id Descripción Tipo P2 Hay pocos álbumes W1 No Negación P3 Hay pocos permisos para editar álbumes o imágenes W2 Todos Conteo P4 Los álbumes no son suficientes P5 Publicar álbumes es una función demorada W3 los P6 Hay pocos archivos W4 álbumes Objeto P7 La actualización de archivos es difícil de lograr W5 se P8 Los usuarios tienen pocos permisos W6 pueden P9 El acceso tiene muchas restricciones para los nuevos usuarios P10 No todos los álbumes se pueden acceder W7 acceder Logro P11 Los derechos son difíciles de garantizar después de crear un usuari W8 Asegurar Realización P12 Hay pocos usuarios W9 que P13 Los permisos no se definen claramente P14 Los derechos son a veces ambiguos W10 a Frases de problemas Identificación Palabra.Id Rol sintáctico Rol Semántico Orden Frases de objetivos P1 W1 Negación Negación 1 Identificación Palabra.Id Rol sintáctico Rol semántico Orden P1 W2 Adjetivo Conteo 2 O1 W1 Verbo Modo 1 P1 W3 Determinante 3 O1 W2 Determinante 2 P1 W4 Sustantivo Receptor 4 O1 W3 Verbo Modo 3 P1 W5 Verbo Modo 5 O1 W4 Verbo Modo 4 P1 W6 Verbo Lugar 6 O1 W5 Sustantivo Receptor 5 P1 W7 Verbo Modo 7 Fig. 3. Esquema preconceptual correspondiente al caso de estudio para el análisis de la relación entre objetivos y problemas. REFERENCIAS [1] R. Pressman, "Ingeniería del software. Un enfoque práctico", McGraw Hill, México, [2] F. Vargas, "Método para establecer la consistencia de los problemas en el diagrama causa-efecto con el diagrama de objetivos de KAOS", Tesis de maestría (Ingeniería de Sistemas). Universidad Nacional de Colombia, Medellín, [3] M. G. Christel y K. C. Kang, "Issues in requirements elicitation", Technical Report, DTIC Document, Pittsburg, Estados Unidos, Carlos Mario Zapata Jaramillo, Fabio Alberto Vargas Agudelo Reglas Sintáctico-semánticas para Relacionar los Objetivos Organizacionales y los Problemas en el Contexto de la Educción Temprana de Requisitos de Software. Revista Latinoamericana de Ingeniería de Software, 1(1): 1-7, ISSN

9 [4] C. M. Zapata y F. Arango, "Alineación entre metas organizacionales y elicitación de requisitos del software", Revista Dyna, vol. 143, pp [5] A. M. Rebollar, H. E. Esquivel, y L. A. G. Moreno, "una guía rápida de la metodología tropos", Revista Gerencia Tecnológica Informática, vol 7, nro. 19, 2008, pp [6] R. Ali, F. Dalpiaz, y P. Giorgini, "A goal-based framework for contextual requirements modeling and analysis", Requirements Engineering, vol. 15, nro. 4, 2010, pp [7] C. Zapata y F. Vargas, "Una revisión de la literatura en consistencia entre problemas y objetivos en Ingeniería de Software y Gerencia Organizacional", Revista Escuela de Ingeniería de Antioquia, vol. 11, 2009, pp [8] A. Dardenne, A. Van Lamsweerde, y S. Fickas, "Goal-directed requirements acquisition", Science of computer programming, vol. 20, nro. 1, 1993, pp [9] E. Yu, "Modelling strategic relationships for process reengineering", Social Modeling for Requirements Engineering, vol. 11, [10] C. M. Zapata y L. A. Lezcano, "caracterización de los verbos usados en el diagrama de objetivos", Revista Dyna, vol. 76, nro. 158, 2009, pp [11] P. Bresciani, A. Perini, P. Giorgini, F. Giunchiglia, y J. Mylopoulos, "Tropos: An agent-oriented software development methodology", Revista Autonomous Agents and Multi-Agent Systems, vol. 8, nro. 3, 2004, pp. [12] R. Ali, F. Dalpiaz, y P. Giorgini, "Location-based software modeling and analysis: Tropos-based approach", Journal Lecture Notes in Computer Science, Vol 5231, 2008, pp [13] R. Ali, F. Dalpiaz, y P. Giorgini, "Location-based variability for mobile information systems", Technical Report in Advanced Information Systems Engineering, 2008, pp [14] S. Choi, S. Park, y V. Sugumaran, "A rule-based approach for estimating software development cost using function point and goal and scenario based requirements", Revista Expert Systems with Applications, vol. 39, nro. 1, 2012, pp [15] C. Zapata y F. Vargas, "Innovation in project design and assessment: establishing linguistic relationships among goals and problems", Revista Lámpsakos, vol. 3, No. 6, 2011, pp [16] H. E. Eriksson y M. Penker, "Business modeling with UML: Business patterns at work". Mexico, [17] E. Ortegón, J. Pacheco y A. Prieto, "Metodología del marco lógico para la planificación, el seguimiento y la evaluación de proyectos y programas". Publicación de las Naciones Unidas, Santiago de Chile [18] Ch. Kepner y B. Tregoe, "The New Rational Manager: An Updated Edition for a New World". Princeton Research Press, Princeton [19] C. M. Zapata, A. Gelbukh y F. Arango, "Pre-conceptual schema: a conceptual-graph-like knowledge representation for requirements elicitation", Lecture Notes in Computer Science, vol. 4293, 2006, pp [20] Requirements elicitation", Lecture Notes in Computer Science, vol. 4293, 2006, pp Carlos Mario Zapata Jaramillo. recibió su título de Ingeniero Civil en 1991, una Especialización en Gerencia de Sistemas Informáticos en 1999, una Maestría en Ingeniería de Sistemas en 2002 y un Doctorado en Ingeniería con énfasis en Sistemas en Todos los títulos los recibió en la Universidad Nacional de Colombia. Es Profesor Asociado del Departamento de Ciencias de la Computación y de la Decisión de la Universidad Nacional de Colombia, sede Medellín. Sus áreas de interés son: ingeniería de software, ingeniería de requisitos, lingüística computacional y estrategias didácticas para la enseñanza de la ingeniería. Fabio Alberto Vargas Agudelo. Es Ingeniero de Sistemas por la Universidad Cooperativa de Colombia 1999, Especialista en Ingeniería de Software por la Universidad Nacional de Colombia 2003, y M.S. en Ingeniería de Sistemas por la Universidad Nacional de Colombia Es Profesor de tiempo completo categoría auxiliar y Líder del grupo de Investigación en Ingeniería de Software GIISTA en el Tecnológico de Antioquia (Institución Universitaria). Sus áreas de interés son: ingeniería de requisitos, pruebas de software y desarrollo de software. Actualmente es Candidato de Doctorado en Ingeniería de Sistemas por la Universidad Nacional de Colombia. Carlos Mario Zapata Jaramillo, Fabio Alberto Vargas Agudelo Reglas Sintáctico-semánticas para Relacionar los Objetivos Organizacionales y los Problemas en el Contexto de la Educción Temprana de Requisitos de Software. Revista Latinoamericana de Ingeniería de Software, 1(1): 1-7, ISSN

10 Modelos para Asistir la Gestión de Proyectos de Explotación de Información Pablo Pytel Grupos Investigación en Sistemas de Información. DDPyT. Universidad Nacional de Lanús & GEMIS UTN- FRBA. Argentina. Paola Britos Grupo de Investigación en Explotación de Información. Laboratorio de Informática Aplicada. Universidad Nacional de Río Negro. Argentina. Ramón García-Martínez Grupo Investigación en Sistemas de Información. Departamento Desarrollo Productivo y Tecnológico. Universidad Nacional de Lanús. Argentina. rgarcia@unla.edu.ar Resumen Los proyectos de Explotación de Información son un tipo especial de proyecto de Ingeniería en Software. En lugar de requerir desarrollar un software específico, herramientas disponibles son utilizadas que ya incluyen las técnicas y algoritmos necesarios. Pero de todas formas posee problemas similares al existir cuestiones de gestión que todavía deben ser mejorados. Entre estas cuestiones se destaca la necesidad de un análisis de viabilidad que permita identificar los riesgos en forma temprana y un método de estimación de esfuerzo que asista la planificación de actividades y recursos que son necesarios para desarrollar el proyecto. En este contexto, este trabajo tiene como objetivo proponer y estudiar dos modelos para ser utilizados en Pequeñas y Medianas Empresas al comienzo de un proyecto de Explotación de Información y de esta forma buscar reducir los problemas que se pueden presentar. Términos Clave Estimación, Viabilidad, PyMES, Explotación de Información. I. INTRODUCCIÓN La Explotación de Información consiste en la extracción de conocimiento no-trivial que reside de manera implícita en los datos disponibles en distintas fuentes de información [1]. Dicho conocimiento es previamente desconocido y puede resultar útil para algún proceso [2]. Una vez identificado el problema de Inteligencia de Negocio es posible definir el Proceso de Explotación de Información. Ese proceso se encuentra formado por varias técnicas de Minería de Datos que se ejecutan para lograr, a partir de un conjunto de información con un grado de valor para la organización, otro conjunto de información con un grado de valor mayor que el inicial [3]. Si bien existen metodologías que acompañan el desarrollo de proyectos de explotación de información que se consideran probadas y tienen un buen nivel de madurez entre las cuales se destacan CRISP-DM [4], P3TQ [5] y SEMMA [6], estas metodologías dejan de lado aspectos a nivel operativo de los proyectos y de empresa [7]. En estas metodologías se observa la falta de procesos y herramientas que permitan soportar de las actividades de gestión al inicio del mismo. Estas actividades son de gran importancia para reducir la probabilidad de fracasos en estos proyectos. En este contexto, este trabajo tiene como objetivo proponer y estudiar dos modelos para ser utilizados en Pequeñas y Medianas Empresas (PyMEs) al comienzo de un proyecto de Explotación de Información y de esta forma buscar reducir los problemas que se pueden presentar. El primer modelo propuesto permite realizar la Evaluación de la Viabilidad del proyecto para así determinar así los posibles puntos fuertes y débiles. Por otro lado, el segundo modelo permite realizar la Estimación de los Recursos y Tiempo que serán requeridos para realizar el proyecto en forma satisfactoria. Este trabajo incluye la siguiente estructura: primero se realiza una reseña de sobre los motivos por los que los proyectos pueden fracasar (sección II). Luego se identifican las principales características de estos proyectos para así proponer ambos modelos (sección III). Una vez que ambos modelos son propuestos, se presentan los resultados de su estudio con una prueba de concepto (sección IV) y una validación de casos (sección V). Finalmente, se indican las conclusiones obtenidas (sección VI). II. FRACASOS DE PROYECTOS La mayoría de los proyectos de Ingeniería en Software pueden ser considerados (al menos) fracasos parciales debido a que pocos proyectos cumplen con sus presupuestos de costo, planificación, criterios de calidad o especificaciones de requerimientos [8]. Para los proyectos cancelados o cuestionados, el proyecto promedio estuvo un 189% sobre el presupuesto, 222% retrasado en su planificación, y contenía sólo el 61% de las características originalmente solicitadas. En 2005 se consideraba que entre el 5 y 15% de los proyectos fueron abandonados antes o un poco después de la entrega por considerar totalmente inadecuados [9]. Según [10], entre los principales motivos que generan el fracaso de los proyectos se encuentra una pobre planificación, recursos insuficientes y falta de identificación de los riesgos. Los proyectos de Explotación de Información son un tipo especial de proyecto de Ingeniería en Software. En lugar de requerir desarrollar un software específico, herramientas disponibles son utilizadas que ya incluyen las técnicas y algoritmos necesarios [3]. Como resultado las características de los proyectos de Explotación de Información son diferentes a los de la Ingeniería en Software Tradicional y de la Ingeniería del Conocimiento. Pero de todas formas posee problemas similares. Estudios realizados sobre sobre proyectos de Explotación de Información han detectado que la mayoría de los proyectos finaliza en fracaso por lo que no son terminados con éxito [11; 12]. En el año 2000 se ha había determinado que el 85% de los proyectos no alcanzan sus metas [13], mientras que en el 2005 el porcentaje de fracaso bajo a aproximadamente el 60% [14]. Por lo tanto se puede decir que la comunidad ha estado trabajando en el camino correcto pero 8 Pytel, P., Britos, P., García-Martínez, R Modelos para Asistir la Gestión de Proyectos de Explotación de Información. Revista Latinoamericana de Ingeniería de Software, 1(1): 8-17, ISSN

11 hay cuestiones de gestión que todavía deben ser mejorados. Entre estas cuestiones se destaca la necesidad de un análisis de viabilidad que permita identificar los riesgos en forma temprana y un método de estimación de esfuerzo que asista la planificación de actividades y recursos que son necesarios para desarrollar el proyecto. III. MODELOS PROPUESTOS En esta sección los dos modelos son propuestos para ser utilizados al comienzo de un proyecto de explotación de información. El primer modelo busca evaluar la viabilidad del proyecto (descripto en la subsección A) mientras que el segundo permite estimar los recursos y tiempo requerido (en meses/hombre) para desarrollar el proyecto (subsección B). Tanto la definición como su posterior validación (realizada en el capítulo V) han utilizado información de proyectos reales de explotación de información que fueron recolectados por investigadores del Grupo de Investigación en Sistemas de Información del Departamento de Desarrollo Productivo y Tecnológico de la Universidad Nacional de Lanús (GISI- DDPyT-UNLa), investigadores del Grupo de Estudio en Metodologías de Ingeniería de Software de la Facultad Regional Buenos Aires de la Universidad Tecnológica Nacional (GEMIS-FRBA-UTN), e investigadores del Grupo de Investigación en Explotación de Información en el Laboratorio de Informática Aplicada de la Universidad Nacional de Río Negro (GIEdI-UNRN). Debe notarse que todos estos proyectos fueron realizados utilizando la metodología CRISP-DM [4], por lo que el método propuesto se considera confiable para proyectos de explotación de información a ser desarrollados con dicha metodología. A. Modelo para la Evaluación de la Viabilidad Un modelo permite identificar, definir e integrar distintos elementos de una realidad para ayudar su análisis. Para poder proponer el Modelo de Viabilidad, primero es necesario identificar las principales características que un Proyecto de Explotación de Información debe cumplir para ser considerado viable. El ingeniero encargado del proyecto deberá responder a dichas condiciones de acuerdo a las características del proyecto para así evaluar su viabilidad. Estas características han sido clasificadas en tres grupos: o Plausibilidad que indica si es posible realizar el proyecto, o o Adecuación que determinar si la explotación de información es la mejor solución para el problema planteado, y Éxito que determinar si los resultados pueden y serán utilizados o no por la organización. Sin embargo, como normalmente no es sencillo contestar las condiciones con respuestas del tipo sí / no (o dando una valoración numérica), el modelo propuesto deberá poder manejar un rango de valores lingüísticos en forma similar al criterio empleado por el test de viabilidad para proyectos de INCO indicado en [15; 16] que se encuentra basado en sistemas expertos difusos [17]. A partir de estos valores y aplicando un conjunto de pasos, se podrá obtener la valoración por dimensión y global de la viabilidad del proyecto. A continuación se describen los cinco pasos que se deben aplicar: Paso 1: Determinar el valor correspondiente para cada una de las características del proyecto. Para caracterizar un proyecto de explotación de información y evaluar luego su viabilidad se utilizan las características definidas en la tabla I las cuales fueron identificadas a partir de la investigación documental realizada en [18-25]. El ingeniero deberá responder las preguntas indicadas a partir del resultado de las entrevistas realizadas en la organización, asociadas a cada característica. Para ello, los valores lingüísticos permitidos son nada, poco, regular, mucho y todo. Donde cuanto más verdadera parezca una característica, mayor valor se le debe asignar y cuanto más falsa parezca, menor valor. TABLA I. CARACTERÍSTICAS EVALUADAS POR EL MODELO DE VIABILIDAD Categoría ID Pregunta asociada a la Característica Peso Umbral Datos Problema de Negocio Proyecto Equipo de Trabajo P1 En qué medida los repositorios disponibles poseen datos actuales? 8 poco P2 Qué tan representativos son los datos de los repositorios disponibles para resolver el 9 poco problema de negocio? A1 En qué medida los repositorios se encuentran disponibles en formato digital? 4 poco A2 Qué cantidad de atributos y registros tienen los datos disponibles? 7 poco A3 Cuánta confianza se posee en la credibilidad de los datos disponibles? 8 poco Cuánto facilita la tecnología de los E1 repositorios disponibles las tareas de 6 nada manipulación de los datos? P3 Cuánto se entiende del problema de negocio? 7 poco En qué medida el problema de negocio no A4 puede ser resuelto aplicando técnicas 10 poco estadísticas tradicionales? A5 Qué tan estable es el problema de negocio durante el desarrollo del proyecto? 9 poco E2 Cuánto apoyan los interesados (stakeholders) al proyecto? 8 nada En qué medida la planificación del E3 proyecto permite considerar la realización de buenas prácticas ingenieriles con el 7 nada tiempo adecuado? Qué nivel de conocimientos posee el P4 equipo de trabajo sobre explotación de 6 poco información? E4 Qué nivel de experiencia posee el equipo de trabajo en proyectos similares? 6 nada Para cada característica de la tabla I se definen los siguientes atributos: Categoría que se utiliza únicamente para poder agrupar las características de acuerdo a qué o quién se refiere. ID que indica el código para identificar unívocamente a la característica y a la dimensión a la que pertenece. Pregunta asociada a la Característica que describe la condición a evaluar del proyecto. Peso que indica la importancia relativa a cada característica en la globalidad del modelo. Nótese que la suma de todos los pesos no es igual a 100 pero esto es soportado por las fórmulas utilizadas en el modelo. Umbral que indica el valor que la característica debe igualar o superar. En caso de que no supere el umbral, se puede considerar que el proyecto no es viable y no es necesario continuar con los siguientes pasos. Paso 2: Convertir los valores en intervalos difusos. Una vez que los valores lingüísticos han sido definidos para cada característica de la tabla 1, se deben traducir en Pytel, P., Britos, P., García-Martínez, R Modelos para Asistir la Gestión de Proyectos de Explotación de Información. Revista Latinoamericana de Ingeniería de Software, 1(1): 8-17, ISSN

12 intervalos difusos. Para cada valor lingüístico se define un intervalo expresado por cuatro valores numéricos (entre cero y diez) que representan los puntos de ruptura (o puntos angulares) de su función de pertenencia correspondiente. Estos intervalos, junto con la representación gráfica de la función de pertenencia, se indican en la figura 1. Paso 3: Calcular la valoración de cada dimensión. Para calcular la valoración de cada dimensión del proyecto, los intervalos difusos (obtenidos en el paso anterior) son ponderados considerando su peso correspondiente (definido en la tabla 1). El intervalo que representa la valoración de cada dimensión ( I d ) se calcula con la fórmula (1): Valor = nada Valor = poco Intervalo Difuso= (0,0; 0,0; 1,2; 2,2) n d n d P di ( P di C di ) 1 = i= i= 1 Id (1) 2 nd 2 nd Pd i P di i= Cd 1 i i= 1 Donde: I d : representa el intervalo difuso calculado para la dimensión d (usando como nomenclatura P para plausibilidad, A para adecuación y E para criterio de éxito). P di : representa el peso de la característica i perteneciente a la dimensión d. C di : representa el intervalo difuso asignado a la característica i perteneciente a la dimensión d. n d : representa la cantidad de características asociada a la dimensión d. Está fórmula está formada por la combinación de la media armónica y la media aritmética del conjunto de intervalos. De esta forma se busca reducir la influencia de valores bajos en el cálculo de la dimensión. Ya que el resultado de la fórmula anterior es otro intervalo difuso, para convertir dicho intervalo en un único valor numérico ( V d ) se utiliza la media aritmética de los valores del intervalo como se indica en la fórmula (2): 4 I d i V = i = 1 d 4 (2) Donde: V d : representa el valor numérico calculado para la dimensión d. I di : representa el valor de la posición i del intervalo difuso calculado para la dimensión d. Paso 4: Calcular la valoración global de la viabilidad del proyecto. Finalmente, los valores numéricos calculados en el paso anterior para cada dimensión ( V d ) son combinados a través de una media aritmética ponderada (la cual es indicada en la fórmula 3) y así se consigue el valor de la viabilidad global del proyecto ( EV ). 8 VP + 8 VA + 6 V EV = E 22 (3) Donde: EV: representa el valor global de la viabilidad del proyecto. V P : representa el valor para la dimensión plausibilidad. V A : representa el valor para la dimensión adecuación. V E : representa el valor para la dimensión criterio de éxito. Valor = regular Valor = mucho Valor = todo Intervalo Difuso= (1,2; 2,2; 3,4; 4,4) Intervalo Difuso= (3,4; 4,4; 5,6; 6,6) Intervalo Difuso= (5,6; 6,6; 7,8; 8,8) Intervalo Difuso= (7,8; 8,8; 10,0; 10,0) Fig. 1. Representación de la Función de Pertenencia y asignación de Intervalo Difuso para los Valores Lingüísticos. Paso 5: Interpretar los resultados obtenidos. Una vez que los valores correspondientes a cada dimensión y al proyecto global son calculados (pasos 3 y 4 respectivamente), deben ser analizados. Por un lado, para interpretar los resultados de la viabilidad de cada dimensión, se recomienda graficar la función de pertenencia del intervalo difuso (I d ). Se considera que la 10 Pytel, P., Britos, P., García-Martínez, R Modelos para Asistir la Gestión de Proyectos de Explotación de Información. Revista Latinoamericana de Ingeniería de Software, 1(1): 8-17, ISSN

13 viabilidad de la dimensión está aceptada si supera al intervalo del valor regular (esto es análogo a considerar que el valor de la dimensión V d es mayor a 5). Por otro lado, para la viabilidad del proyecto se utiliza el siguiente criterio: si las tres dimensiones son aceptadas (es decir el valor de cada dimensión es mayor a 5) y la valoración global de la viabilidad proyecto (EV) es mayor a 5 entonces el proyecto es viable. En caso contrario, el proyecto no es viable. En ambos casos, el ingeniero también podrá observar los puntos débiles del proyecto que debe reforzar (en caso de proyecto no viable) y/o monitorear durante el desarrollo del proyecto. B. Modelo para la Estimación de Esfuerzo Para realizar tanto una planificación como un presupuesto correcto para el proyecto se necesita una buena estimación al comienzo del mismo. De esta manera se destaca la necesidad de contar con métodos de estimación de esfuerzo confiables para proyectos de Explotación de Información. Dada las diferencias que existen entre un proyecto tradicional de construcción de software, los métodos usuales de estimación no son aplicables ya que los parámetros a ser utilizados son de naturalezas diferentes. No obstante en [26] se ha definido el modelo de estimación DMCoMo teniendo en cuenta las características particulares de los proyectos de Explotación de Información, un estudio detallado de DMCoMo ha demostrado que sólo es válido para proyectos grandes [27]. Al trabajar con proyectos medianos y pequeños DMCoMo tiende a sobreestimar el esfuerzo por lo que cual no es útil. Teniendo en cuenta lo anterior, el modelo propuesto para la estimación considera las características de proyectos medianos y pequeños [28; 29] y las características de las Pequeñas y Medianas Empresas en Latinoamérica [30; 31] se ha propuesto un modelo que utiliza ocho factores de costos. En esta propuesta se han definido pocos factores de costo, ya que como se demuestra en [33], al momento de crear un nuevo método de estimación es preferible ignorar muchos de los datos no significativos para evitar que el modelo sea demasiado complejo y por lo tanto poco práctico. De esta manera se busca eliminar las variables tanto irrelevantes como dependientes, y además reducir la varianza y el ruido. Los factores de costo han sido seleccionados teniendo en cuanta las tareas más críticas de la metodología CRISP-DM [4]: en [33] se indica que actualmente la construcción de los modelos de minería de datos y buscar los patrones es bastante simple, pero el 90% de los esfuerzos del proyecto están incluidos en el preprocesamiento de los datos (es decir la fase de Preparación de los Datos de CRISP-DM). A partir de nuestra experiencia, las otras tareas críticas se relacionan con la fase de Comprensión del Negocio (entre las que se destacan el entendimiento del negocio y la identificación de los goles del proyecto). Los factores de costos propuestos se encuentran agrupados en tres grupos dependiendo de su naturaleza como se indica a continuación: Factores de costo relacionados al proyecto: Tipo de objetivo de explotación de información (OBTY) Este factor de costo analiza el objetivo del proyecto de Explotación de Información considerando el tipo de proceso a ser aplicado para obtenerlo de acuerdo a la definición realizada en [3] de acuerdo a los datos disponibles y las metas del proyecto. Los posibles valores de este factor de costo se indican en la tabla II. Valor TABLA II. VALORES DEL FACTOR DE COSTO OBTY Descripción Se desea conocer los atributos que caracterizan el comportamiento o la descripción de una clase ya conocida. Se desea dividir los datos disponibles en grupos sin poseer una clasificación conocida previamente. Se desea conocer los atributos que caracterizan a grupos sin poseer una clasificación conocida previamente. Se desea conocer los atributos que poseen mayor frecuencia de incidencia sobre un comportamiento o la identificación de una clase conocida. Se desea conocer los atributos que poseen mayor frecuencia de incidencia sobre la identificación de una clase desconocida previamente. Grado de apoyo de los miembros de la organización (LECO) El grado de apoyo y participación de los miembros de la organización se analiza viendo si la alta gerencia (normalmente los dueños de la PyME), la gerencia media (supervisores y/o jefes de área) y/o el resto del personal están dispuestos a ayudar al equipo de trabajo para comprender el negocio y los datos. Se sobreentiende que si un proyecto de explotación de información fue contratado, por lo menos la alta gerencia va a apoyar el mismo. Los posibles valores de este factor de costo se indican en la tabla III. Valor TABLA III. VALORES DEL FACTOR DE COSTO LECO Descripción Tanto los directivos como el personal poseen buena disposición para colaborar en el proyecto. Sólo los directivos poseen buena disposición para colaborar en el proyecto mientras que el personal es indiferente al proyecto. Sólo la alta gerencia posee buena disposición para colaborar en el proyecto mientras que la gerencia media y el personal es indiferente. Sólo la alta gerencia posee buena disposición para colaborar en el proyecto pero la gerencia media no desea colaborar. Factores de costo relacionados a los datos disponibles: Cantidad y tipo de los repositorios de datos disponibles (AREP) Se analizan los repositorios de datos disponibles (es decir sistemas gestores de bases de datos, planillas de cálculos, documentos entre otros). En este caso interesa saber tanto la cantidad de repositorios disponibles (públicos o privados de la organización) como la tecnología en que se encuentran implementadas. No interesa conocer la cantidad de tablas que posee cada repositorio dado que se entiende que la integración de los datos dentro de un repositorio es relativamente sencilla (sobre todo al utilizar sistemas gestores de bases de datos por poder ser realizada con un comando query). Sin embargo, dependiendo de la tecnología, la complejidad de las tareas de integración de los datos puede ser mayor o menor. Los criterios recomendados para ser utilizados se describen a continuación: - Si todos los repositorios están implementados con la misma tecnología, entonces se consideran como compatibles para la integración. - Si todos los repositorios permiten exportar los datos en un formato común, entonces pueden ser considerados Pytel, P., Britos, P., García-Martínez, R Modelos para Asistir la Gestión de Proyectos de Explotación de Información. Revista Latinoamericana de Ingeniería de Software, 1(1): 8-17, ISSN

14 como compatibles para la integración al realizar la integración con estos datos exportados. - Por otro lado, si existen repositorios que no están en forma digital (es decir impreso en papel) se considera que la tecnología será no compatible pero el método de estimación no puede predecir el tiempo requerido para realizar la digitalización de esta información ya que esto puede variar de acuerdo a muchos factores externos (como son la longitud, diversidad, formato entre otros). La tabla con los posibles valores de este factor de costo se indica en la tabla IV. TABLA IV. VALORES DEL FACTOR DE COSTO AREP Valor Descripción 1 Sólo 1 repositorio disponible. Entre 2 y 4 repositorios con tecnología compatible para la 2 integración. Entre 2 y 4 repositorios con tecnología no compatible para la 3 integración. 4 Más de 5 repositorios con tecnología compatible para la integración. Más de 5 repositorios con tecnología no compatible para la 5 integración. Cantidad de tuplas disponibles en la tabla principal (QTUM) Este factor de costo considera la cantidad total de tuplas (registros) disponibles en la tabla principal utilizada para aplicar los algoritmos de minería de datos. Los posibles valores de este factor de costo se indican en la tabla V. TABLA V. VALORES DEL FACTOR DE COSTO QTUM Valor Descripción 1 Hasta 100 tuplas en la tabla principal. 2 Entre 101 y tuplas en la tabla principal. 3 Entre y tuplas en la tabla principal. 4 Entre y tuplas en la tabla principal. 5 Entre y tuplas en la tabla principal. 6 Más de tuplas en la tabla principal. Cantidad de tuplas disponibles en tablas auxiliares (QTUA) Esta variable considera la cantidad aproximada de tuplas (registros) disponibles en las tablas auxiliares (si existieran) que son utilizadas para agregar información a la tabla principal (como es la tabla que define las características del producto a partir de su identificador en la tabla de ventas). Estas tablas auxiliares normalmente suelen tener menos registros que la tabla principal. Los posibles valores de este factor de costo se indican en la tabla VI. TABLA VI. VALORES DEL FACTOR DE COSTO QTUA Valor Descripción 1 No se utilizan tablas auxiliares. 2 Hasta tuplas en las tablas auxiliares. 3 Entre y tuplas en las tablas auxiliares. 4 Más de tuplas en las tablas auxiliares. Nivel de conocimiento sobre los datos (KLDS) Considera el nivel de documentación existente sobre los repositorios de datos. Es decir, se analiza si existe un documento donde se indique la tecnología en que están implementados, los campos que componen sus tablas y la forma en que los datos son creados, modificados, y/o eliminados. En caso de que esta información no se encuentre disponible, será necesario realizar reuniones con los expertos (normalmente los encargados de la administración y mantenimiento de los repositorios). Los posibles valores de este factor de costo se indican en la tabla VII. TABLA VII. VALORES DEL FACTOR DE COSTO KLDS Valor Descripción 1 Todas las tablas y repositorios están correctamente documentados. Más del 50% de las tablas y repositorios están correctamente 2 documentados y existen expertos en los datos disponibles para explicarlos. Menos del 50% de las tablas y repositorios están correctamente 3 documentados pero existen expertos en los datos disponibles para explicarlos. Las tablas y repositorios no están documentadas pero existen 4 expertos en los datos disponibles para explicarlos. Las tablas y repositorios no están documentados y existen expertos 5 en los datos pero no están disponibles para explicarlos. Las tablas y repositorios no están documentados y no existen 6 expertos en los datos para explicarlos. Factores de costo relacionados a los recursos disponibles: Nivel de conocimiento y experiencia del equipo de trabajo (KEXT) Analiza la capacidad del equipo de trabajo que se ocupará de llevar adelante el proyecto. El equipo de trabajo contratado para realizar el proyecto debe tener un mínimo conocimiento y experiencia en el desarrollo de proyectos de explotación de información. No obstante pueden poseer o no experiencia en proyectos similares en el mismo tipo de negocio y los datos a ser utilizados. Por lo tanto se debe evaluar el conocimiento y experiencia previa en proyectos anteriores similares al que se está llevando a cabo con respecto al tipo de negocio, los da-tos a ser utilizados y los objetivos que se esperan lograr. Los posibles valores de este factor de costo se indican en la tabla VIII. Valor TABLA VIII. VALORES DEL FACTOR DE COSTO KEXT Descripción El equipo ha trabajado en tipos de organizaciones y con datos similares para obtener los mismos objetivos. El equipo ha trabajado en tipos de organizaciones similares pero con datos diferentes para obtener los mismos objetivos. El equipo ha trabajado en otros tipos de organizaciones y con datos similares para obtener los mismos objetivos. El equipo ha trabajado en otros tipos de organizaciones y con datos diferentes para obtener los mismos objetivos. El equipo ha trabajado en tipos de organizaciones diferentes, con datos diferentes y otros objetivos. Funcionalidad de las herramientas disponibles (TOOL) Finamente, este factor de costo evalúa las características de las herramientas disponibles para realizar el proyecto. Para ello se analiza tanto las funcionalidades de preparación de los datos como los algoritmos de minería de datos que posee implementadas. Sus posibles valores de este factor de costo se indican en la tabla IX. Una vez que los factores de costo fueron definidos, se han utilizado para caracterizar 34 proyectos reales de explotación de información recolectados los cuales se encuentran disponibles en [34]. Estos proyectos provistos por colegas investigadores (como se ha indicado anteriormente) incluyen el esfuerzo real que fue requerido para realizar el proyecto en forma completa. 12 Pytel, P., Britos, P., García-Martínez, R Modelos para Asistir la Gestión de Proyectos de Explotación de Información. Revista Latinoamericana de Ingeniería de Software, 1(1): 8-17, ISSN

15 TABLA IX. VALORES DEL FACTOR DE COSTO TOOL TABLA X. RESULTADOS DEL MODELO DE VIABILIDAD Valor Descripción La herramienta posee funciones tanto para el formateo e integración de los datos (permitiendo importar más de una tabla de datos) como para aplicar las técnicas de minería de datos. La herramienta posee funciones tanto para el formateo como para aplicar las técnicas de minería de datos, y permite importar más de una tabla de datos en forma independiente. La herramienta posee funciones tanto para el formateo como para aplicar las técnicas de minería de datos, pero sólo permite importar una tabla de datos. La herramienta posee funciones sólo para aplicar las técnicas de minería de datos, y permite importar más de una tabla de datos. La herramienta posee funciones sólo para aplicar las técnicas de minería de datos y sólo permite importar una tabla de datos. Dimensión Plausibilidad Intervalo Valor Dimensión ( I d ) Valor de la Dimensión ( V d ) (6,05; 7,12; 8,39; 8,82) 7,60 Una vez que los factores de costo fueron definidos, se han utilizado para caracterizar 34 proyectos reales de explotación de información recolectados los cuales se encuentran disponibles en [34]. Estos proyectos provistos por colegas investigadores (como se ha indicado anteriormente) incluyen el esfuerzo real que fue requerido para realizar el proyecto en forma completa. Un método de regresión lineal multivariante [35] fue aplicado sobre estos datos para obtener una ecuación lineal de la forma utilizada por los métodos de la familia COCOMO [36]. Como resultado del proceso de regresión se obtiene la fórmula (4) que se indica a continuación. Adecuación (4,65; 5,68; 6,91; 7,84) 6,27 (3,44; 4,62; 5,93; 6,99) 5,25 Donde: PEM= 0,80 OBTY+ 1,10 LECO -1,20 AREP- 0,30 QTUM - 0,70 QTUA+1,80 KLDS - 0,90 KEXT+1,86 TOOL -3,30 (4) PEM es el esfuerzo estimado por el método de estimación para PyMEs (en meses/hombre) OBTY, LECO, AREP, QTUM, QTUA, KLDS, KEXT y TOOL son los valores correspondientes de los factores de costo definidos en las tablas II a IX respectivamente. IV. PRUEBA DE CONCEPTO A modo de ejemplo en esta sección se presenta una prueba de concepto de los modelos propuestos. Para ello se utilizan los datos de un proyecto de explotación de información real finalizado con éxito (y por lo tanto fue viable) que fue desarrollado por 3 personas en 4 meses (es decir que tuvo un esfuerzo de 12 meses/hombre o un año/hombre). Este proyecto tenía el objetivo de detectar las evidencias de causalidad entre la satisfacción general de los clientes de una organización proveedora de Internet mediante la detección de evidencias de causalidad entre satisfacción general, servicio contratado y baja de clientes. Para ello se utilizó la información de una encuesta realizada por la organización a sus clientes. Para realizar la prueba de concepto, primero se aplicaron los cinco pasos propuestos en el Modelo para Evaluar la Viabilidad (en la sección III-A). Todos los cálculos necesarios fueron realizados mediante una planilla creada ad-hoc [37] que implementa las fórmulas definidas anteriormente y sus resultados se muestran en la tabla X. Como se puede ver, dado que los valores de cada dimensión y de la viabilidad global del proyecto son superiores al valor mínimo requerido, se considera que el proyecto es viable para ser realizado (lo cual es correcto). Éxito Valor global de la viabilidad del proyecto ( EV ) 6,47 Sin embargo, el proyecto posee algunos puntos débiles. Puede notarse que a pesar de que la valoración de Plausibilidad y Adecuación es holgada (valores cercanos a mucho ), para el Éxito del proyecto es muy cercana al valor mínimo requerido (es decir al intervalo correspondiente al valor regular ). Esto significa que se debe prestar mayor atención las características asociadas al éxito para asegurar que el proyecto se desarrolle sin problemas. De esta forma estos puntos débiles se convierten en riesgos para ser monitoreados y controlados durante el desarrollo del proyecto. Por otro lado, ya que el proyecto se considera viable se utiliza el Modelo de Estimación de Esfuerzo (sección III-B) en este proyecto para comparar el esfuerzo real del proyecto con el calculado por el modelo. Para ello se definen los valores de cada factor de costo y luego se aplica la fórmula correspondiente para obtener el esfuerzo. En la tabla XI, se detallan los valores de los factores de costo utilizados para la prueba de concepto. Como resultado de aplicar la fórmula del modelo se obtiene un esfuerzo estimado de 12,18 meses/hombre. Al compararlo con el esfuerzo real que fue requerido por el proyecto de 12 meses/hombre se puede ver que el error del modelo es menor a 6 días/hombre (es decir 0,18 meses/hombre) con respecto al real. Esto significa que para este ejemplo el modelo fue muy preciso. Pytel, P., Britos, P., García-Martínez, R Modelos para Asistir la Gestión de Proyectos de Explotación de Información. Revista Latinoamericana de Ingeniería de Software, 1(1): 8-17, ISSN

16 TABLA XI. RESULTADOS DEL MODELO DE ESTIMACIÓN Categoría ID Descripción Valor OBTY Se desea conocer la incidencia de los atributos sobre el motivo de baja del 5 Proyecto servicio. Se posee buena disposición del personal y LECO la dirección para colaborar en el proyecto. 1 Datos Disponibles Recursos Disponibles AREP Sólo 1 repositorio disponible. 1 QTUM Aprox tuplas en la tabla principal. 3 QTUA Aprox tuplas en tablas auxiliares 3 Las tablas y repositorios no están KLDS documentados y no existen expertos. 6 KEXT TOOL Se ha trabajado en tipos de organizaciones similares pero con datos diferentes para mismos objetivos. La herramienta posee funciones para el formateo y para aplicar las técnicas de minería de datos, pero sólo importa una tabla. Esfuerzo Estimado por el Modelo = 12,18 meses/hombre V. VALIDACIÓN DE LOS MODELOS PROPUESTOS En esta sección se presentan los resultados de la validación realizada sobre los modelos propuestos en la sección III. Para realizar esta validación se han utilizado datos de 25 proyectos reales, cuyos datos proyectos se encuentran disponibles en [38]. En ese reporte se incluye también todos los cálculos 2 3 auxiliares utilizados por el Modelo de Viabilidad. Un resumen de estos datos se muestra en la tabla XII. Como se puede ver veintidós de los proyectos (P1 a P22 inclusive) han finalizado con éxito y los tres restantes (P23, P24 y P25) fueron cancelados. Para la validación de los modelos primero se realiza el análisis de gráficos Boxplot y luego en aplicar la prueba de rangos con signo de Wilcoxon [39]. Esta prueba no paramétrica se utiliza para comprobar que no hay diferencia entre los datos reales y los calculados por cada modelo. A. Validación del Modelo para la Evaluación de la Viabilidad Como se puede ver en la tabla XII, se les ha pedido a los investigadores que indiquen una valoración de las cuatro dimensiones consideradas por el modelo (plausibilidad, adecuación y éxito) utilizando una escala de 1 a 10 (donde 10 es el mayor valor). Con estos valores se calcula su promedio para obtener la Valoración de la Viabilidad del proyecto. Esta valoración se utiliza junto con los resultados de aplicar el procedimiento propuesto para validar el modelo propuesto. Para realizar las pruebas se toma cada dimensión (plausibilidad, adecuación, éxito y viabilidad global) en forma independiente. Primero se compara el comportamiento del modelo con la valoración de los investigadores en gráficos boxplot (figura 2). En estos gráficos se muestran los valores mínimos y máximo, el rango del desvío estándar y el valor medio para cada uno. # Valoración indicada por los Investigadores Plausibilidad Adecuación Éxito TABLA XII. DATOS REALES DE CADA PROYECTO Y LOS CALCULADOS POR LOS MODELOS Viabilidad Global Valores calculados por el Modelo de Viabilidad Esfuerzo Real * Plausibilidad Adecuación Éxito Viabilidad Global Esfuerzo calculado por el Modelo de Estimación * P ,33 2,41 7,20 6,11 5,25 6,27 2,58 P ,00 7,00 6,87 5,07 5,25 5,77 6,00 P ,33 1,64 5,90 5,67 5,31 5,65 1,48 P ,33 3,65 5,12 6,95 4,12 5,51 1,68 P ,00 9,35 5,12 7,82 6,81 6,56 9,80 P ,33 11,63 5,45 5,61 5,25 5,45 5,10 P ,00 6,73 5,45 5,56 5,42 5,48 3,78 P ,67 5,40 6,45 5,80 5,18 5,87 4,88 P ,33 8,38 7,20 5,61 5,57 6,18 8,70 P ,67 1,56 5,85 5,34 5,57 5,59 1,08 P ,33 9,70 6,22 6,56 5,42 6,14 9,60 P ,33 5,24 7,67 7,35 6,45 7,22 5,80 P ,00 5,00 5,93 5,09 7,05 5,93 4,58 P ,67 8,97 6,20 6,59 5,69 6,20 9,18 P ,00 2,81 8,72 6,89 7,66 7,77 3,48 P ,00 11,80 6,45 6,43 5,64 6,22 12,00 P ,33 2,79 6,14 5,83 5,42 5,83 2,28 P ,33 3,88 6,00 5,31 5,42 5,59 3,58 P ,33 5,70 7,01 6,89 5,58 6,58 6,30 P ,00 8,54 8,24 6,75 5,52 6,96 9,18 P ,33 10,61 8,05 6,45 5,25 6,70 11,50 P ,33 6,88 6,45 5,81 6,54 6,24 6,40 P ,33-4,66 5,34 3,25 4,52 - P ,33-4,66 3,46 4,21 4,10 - P ,33-4,63 2,81 3,01 3,52 - * : en meses/hombre y sólo indicado para proyectos que han finalizado con éxito. 14 Pytel, P., Britos, P., García-Martínez, R Modelos para Asistir la Gestión de Proyectos de Explotación de Información. Revista Latinoamericana de Ingeniería de Software, 1(1): 8-17, ISSN

17 Plausibilidad Adecuación Éxito Viabilidad Global Fig. 2. Gráficos boxplot para el Modelo de Viabilidad Como se puede ver el comportamiento para las cuatro dimensiones es muy similar por ser tanto los valores medio como el rango del desvío estándar muy similares (la mayor diferencia es de 0,3 para la plausibilidad). Sin embargo, el modelo propuesto tiende a ser más conservador por no tener valores tan extremos sobre todo para el mínimo. Dado que las diferencias de los pares de datos tienen una distribución que es aproximadamente simétrica se puede aplicar el análisis de la prueba de rangos con signo de Wilcoxon. En esta prueba se aplican la siguiente hipótesis nula ( H 0 ) y alternativa ( H 1 ): H 0 : Los valores indicados por los investigadores y calculados por el modelo son tales que la mediana de la población de las diferencias es igual a cero (es decir, no hay diferencias significativas entre lo indicado por los investigadores y lo definido por el modelo). H 1 : La mediana de la población de diferencias no es igual a cero (es decir, que existen diferencias significativas entre lo indicado por los investigadores y lo definido por el modelo). Los resultados de aplicar la prueba de Wilcoxon se muestran en la tabla XIII. Como en todos los casos se obtuvo 25 pares o proyectos con diferencias distinta de cero (n=25) y el nivel de significancia seleccionado es de 0,01 entonces la hipótesis nula ( H 0 ) será rechazada si la menor suma de rangos ( W ) es menor o igual a 68 (valor crítico obtenido de la tabla estadística). En caso contrario, no se rechaza y se considera como válida. En el caso de la Plausibilidad se toma 97 como la menor suma de rangos ( W ) por ser la suma de rangos positiva ( W + ) la menor. Dado que este valor es mayor que el valor crítico (68), no se rechaza la hipótesis nula y se puede decir que no hay diferencia entre el valor calculado por el modelo para la plausibilidad y el asignado por los investigadores. Para la Adecuación, como W - es la menor, se toma W = 98. Dado que este valor es mayor que 68, no se rechaza la hipótesis nula (H 0 ). Con el Éxito sucede algo similar: W = W - = 150 > 68, entonces no se rechaza H 0. Finalmente la Viabilidad Global tampoco rechaza H 0 ( W = W - = 144 > 68 ). TABLA XIII. RESULTADOS DE APLICAR LA PRUEBA DE WILCOXON AL MODELO DE VIABILIDAD Dimensión Suma de Rangos + ( W + ) Suma de Rangos ( W + ) Cantidad de pares distintos de cero Plausibilidad Adecuación Éxito Viabilidad Global Por lo tanto, con un se puede decir con un nivel de significancia del 0,01 que no hay diferencia entre el valor calculado por el modelo para todas las dimensiones y el asignado en la valoración realizada por los investigadores. B. Validación del Modelo para la Estimación de Esfuerzo Para analizar el comportamiento del modelo de estimación orientado para PyMEs propuesto se utiliza sólo la información de los primeros 22 proyectos indicados en la tabla XII (P1 a P22 inclusive) por haber finalizado exitosamente y ser conocido su esfuerzo real. Con estos proyectos se ha calculado los esfuerzos por el modelo propuesto con la fórmula PEM definida en la sección III-B. Pytel, P., Britos, P., García-Martínez, R Modelos para Asistir la Gestión de Proyectos de Explotación de Información. Revista Latinoamericana de Ingeniería de Software, 1(1): 8-17, ISSN

18 Para comparar con mayor claridad el esfuerzo real con el calculado se genera un gráfico boxplot (figura 3). Se puede observar que se produce un error promedio de aproximadamente 0,49 meses/hombre con un desvío estándar para el error de aproximadamente ± 1,62 meses/hombre. Se nota que el modelo propuesto tiende a generar estimaciones un poco inferiores a las reales (el promedio del esfuerzo real es de 6,35 meses/hombre y la del modelo es de 5,86 meses/hombre) pero en la mayoría de los casos (19 proyectos de los 22 analizados) el error es menor al 35% del esfuerzo real. Fig. 3. Gráfico boxplot para el Modelo de Estimación Dado que las diferencias de los pares de datos tienen una distribución que es aproximadamente simétrica también se puede aplicar el análisis de la prueba de rangos con signo de Wilcoxon. En esta nueva prueba se aplican la siguiente hipótesis nula y alternativa: H 0 : El esfuerzo real y el calculado por el modelo son tales que la mediana de la población de las diferencias es igual a cero (es decir, no hay diferencias significativas entre lo requerido realmente y lo definido por el modelo). H 1 : La mediana de la población de diferencias no es igual a cero (es decir, que existen diferencias significativas entre el esfuerzo real requerido y lo definido por el modelo). Los resultados de aplicar la prueba de Wilcoxon se muestran a continuación: Suma de Rangos + ( W + ) = 108 Suma de Rangos ( W - ) = 145 Como en todos los casos se obtuvo 22 pares con diferencias distinta de cero (n=22) y el nivel de significancia seleccionado es de 0,01 entonces el valor crítico obtenido de la tabla estadística es 49. Dado que la mínimo menor suma de rangos (W) es igual a 108 ( W + ) y es mayor a 49, no se rechaza la hipótesis nula ( H 0 ) y se puede afirmar que no hay diferencias significativas entre el esfuerzo real y el calculado por el modelo propuesto. VI. CONCLUSIÓN Se ha observado en los Proyectos de Explotación de Información la ausencia de modelos que permitan identificar sus riesgos al inicio del mismo y estimar el esfuerzo requerido cuando se desarrollan en PyMEs. Esto genera que de la gran cantidad de proyectos desarrollados, no todos finalizan con éxito, terminando la mayoría en fracasos. Por lo tanto, en este trabajo incluye dos propuestas: o Primero se define un Modelo que permita la Evaluación de la Viabilidad para Proyectos de Explotación de Información usando la información disponible al comienzo del mismo. Mediante un procedimiento que consta de cinco pasos es posible caracterizar un proyecto y calcular la viabilidad de acuerdo a tres dimensiones: plausibilidad, adecuación y éxito. Esta evaluación además permite identificar los puntos débiles del proyecto. A pesar de que el proyecto sea viable, estos puntos débiles deben ser monitoreados durante el desarrollo del proyecto como riesgos. Es responsabilidad del ingeniero mantener o subir su valor para evitar así el fracaso del proyecto. o Además se propone un Modelo que permite Estimar el Esfuerzo que se necesita para realizar el proyecto en su totalidad. Debe notarse que este modelo se encuentra orientado a las particularidades de los proyectos de corto alcance que son usualmente requeridos por las Pequeñas y Medianas Empresas. Para ello, se vuelve a caracterizar el proyecto esta vez mediante la asignación de valores a un conjunto de factores de costos que luego se utilizan para calcular el esfuerzo mediante una fórmula similar a las utilizadas por los métodos de la familia COCOMO. Para ambos modelos se realiza una validación mediante su aplicación en proyectos reales y su comparación. Como resultado se determina que ambos modelos producen resultados muy precisos. En ambos casos el comportamiento general de los modelos tiende a ser similar al de los proyectos reales. AGRADECIMIENTOS Este trabajo de investigación ha si parcialmente financiado por los proyectos 33A167 y 33B102 de la Universidad Nacional de Lanús, por los proyectos 40B133 y 40B065 de la Universidad Nacional de Río Negro, y el proyecto EIUTIBA11211 de la Universidad Tecnológica Nacional Facultad Regional Buenos Aires. Además los autores desean agradecer a los investigadores que han provisto la información de proyectos reales utilizados. REFERENCIAS [1] Schiefer, J., Jeng, J., Kapoor, S., & Chowdhary, P. Process Information Factory: A Data Management Approach for Enhancing Business Process Intelligence. Proceedings 2004 IEEE International Conference on E-Commerce Technology. pp [2] Stefanovic, N., Majstorovic. V., & Stefanovic, D. Supply Chain Business Intelligence Model. Proceedings 13th International Conference on Life Cycle Engineering pp [3] García-Martínez, R., Britos, P., Pesado, P., Bertone, R., Pollo- Cattaneo, F., Rodríguez, D., Pytel, P., & Vanrell. J. Towards an Information Mining Engineering. En Software Engineering, Methods, Modeling and Teaching. Sello Editorial Universidad de Medellín pp ISBN [4] Chapman, P., Clinton, J., Keber, R., et al.. CRISP-DM 1.0 Step by step BI guide. Edited by SPSS crispdm [5] Pyle, D. Business Modeling and Business intelligence. Morgan Kaufmann [6] SAS Enterprise Miner: SEMMA semmasas [7] Vanrell, J., Bertone, R., & García-Martínez, R. Modelo de Proceso de Operación para Proyectos de Explotación de 16 Pytel, P., Britos, P., García-Martínez, R Modelos para Asistir la Gestión de Proyectos de Explotación de Información. Revista Latinoamericana de Ingeniería de Software, 1(1): 8-17, ISSN

19 Información. Anales del XVI Congreso Argentino de Ciencias de la Computación, ISBN [8] May, L.J. Major causes of software project failures, CrossTalk: The Journal of Defense Software Engineering, 11(6), pp [9] Charette, R.N. Why software fails, Spectrum, IEEE, 42(9), pp [10] The Standish Group: Chaos Report group. com/ [11] Edelstein, H.A. & Edelstein, H.C., Building, Using, and Managing the Data Warehouse, Data Warehousing Institute, Prentice-Hall PTR, EnglewoodCliffs (NJ) [12] Strand, M. The Business Value of Data Warehouses - Opportunities, Pitfalls and Future Directions. Ph.D. Thesis, Department of Computer Science, University of Skovde [13] Fayyad, U.M. Tutorial report. Summer school of DM. Monash University (Australia) [14] Gondar, J.E. Metodología del Data Mining. Number Data Mining Institute S.L [15] García-Martínez, R. & Britos, P. Ingeniería de Sistemas Expertos. Editorial Nueva Librería ISBN [16] Gómez, A., Juristo, N., Montes, C. & Pazos, J. Ingeniería del Conocimiento, Ed. Ramón Areces S.A. (Madrid) [17] Jang, J.S.R. Fuzzy inference systems, Upper Saddle River, NJ: Prentice-Hall [18] Sim, J. Critical success factors in data mining projects. Ph.D. Thesis, University of North Texas [19] Nemati, H.R. & Barko, C.D. Key factors for achieving organizational data-mining success. Industrial Management & Data Systems, 103(4), pp doi: / [20] Davenport, T.H. Make Better Decisions, Harvard Business Review, (November), pp [21] Bolea, U., Jakličb, J. Papac, G. & Žabkard, J. Critical Success Factors of Data Mining in Organizations, Ljubljana [22] Nadali, A., Kakhky, E.N. & Nosratabadi, H.E. Evaluating the success level of data mining projects based on CRISP-DM methodology by a Fuzzy expert system, Electronics Computer Technology (ICECT), 3rd International Conference on Kanyakumari, IEEE Vol. 6, pp doi: /icectech [23] Nie, G., Zhang, L., Liu, Y. Zheng, X. & Shi, Y. Decision analysis of data mining project based on Bayesian risk, Expert Systems with Applications, 36(3), pp [24] Pipino, L.L., Lee, Y.W. & Wang, R.Y. Data quality assessment, Communications of the ACM, 45(4), pp [25] Lavravc, N., Motoda, H., Fawcett, T., Holte, R. Langley, P. & Adriaans, P. Introduction: Lessons learned from data mining applications and collaborative problem solving, Machine learning, vol. 57, n.º 1, pp [26] Marbán, O., Menasalvas, E., & Fernández-Baizán, C. A cost model to estimate the effort of data mining projects (DMCoMo). Information Systems, 33(1), [27] Pytel, P., Tomasello, M., Rodríguez, D., Pollo Cattaneo, F., Britos, P., García Martínez, R. Estudio del Modelo Paramétrico DMCoMo de Estimación de Proyectos de Explotación de Información. Proceedings XVII Congreso Argentino de Ciencias de la Computación. Pág ISBN [28] International Organization for Standardization. ISO/IEC DTR Software Engineering - Lifecycle Profiles for Very Small Entities (VSEs) - Part 1: Overview. International Organization for Standardization (ISO), Switzerland [29] Laporte, C., Alexandre, S. & Renault, A. Developing International Standards for VSEs. Computer, 41(3): [30] Organization for Economic Cooperation and Development. OECD SME and Entrepreneurship Outlook OECD Publishing [31] Álvarez, M. & Durán, J. Manual de la Micro, Pequeña y Mediana Empresa. Una contribución a la mejora de los sistemas de información y el desarrollo de las políticas públicas. San Salvador: CEPAL - Naciones Unidas [32] Chen, Z., Menzies, T., Port, D., et al. Finding the right data for software cost modeling. Software, IEEE, vol.22, no.6, pp , Nov.-Dec [33] Domingos, P., Elkan, C., Gehrke, J., et al. 10 challenging problems in data mining research. International Journal of Information Technology & Decision Making, 5(4): [34] Pytel, P. Datos Recopilados para Estimación de Proyectos de Explotación de Información en PYMEs, Reporte Técnico GISI- TD RT , GISI/papers/GISI-TD TR DatosProyectos.pdf [35] Weisberg, S. Applied Linear Regression. John Wiley & Sons, New York [36] Boehm, B., Abts, C., Brown, A., Chulani, S., Clark, B., Horowitz, E., Madachy, R., Reifer, D., Steece, B. Software Cost Estimation with COCOMO II. Prentice-Hall [37] Pytel, P. Implementación del Modelo de Viabilidad Propuesto [38] Pytel, P. Datos Recopilados para Validación del Modelo de Viabilidad de Proyectos de Explotación de Información, Reporte Técnico GISI-TD RT , Datos-Proyectos-para-Viabilidad.pdf [39] Wilcoxon, F. Individual Comparisons by Ranking Methods, Biometrics 1, pp Pablo Pytel. Es Ingeniero en Sistemas de Información por la UTN, Magister en Ingeniería de Software por la Universidad Politécnica de Madrid. Es Docente Instructor en la Licenciatura en Sistemas y codirector del proyecto UNLa 33B102 de la UNLa. Sus intereses en investigación son modelos de viabilidad y estimación de proyectos de explotación de información; y aplicaciones de IA a IS. Paola Britos. Es Licenciada en Sistemas de Información por la UNLu, Magister en Ingeniería del Conocimiento por la Universidad Politécnica de Madrid y Doctora en Ciencias Infromáticas por la Universidad Nacional de La Plata. Es Profesora Asociada Regular del Área de Ingenieria de Software en la Licenciatura en Sistemas de Infromación y directora de los proyectos 40B133 y 40B065 de la UNRN. Sus intereses en investigación son modelos de proceso para proyectos de explotación de información. Ramón García Martínez. Es Analista de Computación por la UNLP, es Licenciado en Sistemas de Información por la UNLu, es Master en Ingeniería Informática y Doctor en Informática por la Universidad Politécnica de Madrid. Es Profesor Titular Regular del Area de Ingeniería de Software en la Licenciatura en Sistemas y Director de los proyectos 33A166 y 33A167 la UNLa. Su áreas de interés en investigación son Aprendizaje Automático, Sistemas Inteligentes, Explotación de Datos basada en Sistemas Inteligentes, Ingeniería del Conocimiento y las correspondientes aplicaciones en Ingeniería, Economía, Salud y Agroindustria. Pytel, P., Britos, P., García-Martínez, R Modelos para Asistir la Gestión de Proyectos de Explotación de Información. Revista Latinoamericana de Ingeniería de Software, 1(1): 8-17, ISSN

20 Análisis del Comportamiento de Robots Móviles con RNA. Un Acercamiento desde el Paradigma Reactivo Alejandro Hossian, Gustavo Monte, Verónica Olivera Facultad Regional del Neuquén Universidad Tecnológica Nacional Plaza Huincul, Neuquén, Argentina Resumen. Por medio de la navegación es posible guiar el curso de un robot móvil a través de un entorno con presencia de obstáculos. Se conocen diferentes esquemas para llevar a cabo esta tarea, pero todos ellos tienen el objetivo común de dirigir el vehículo hacia su destino de la manera más segura y eficiente posible. La capacidad de reacción que pueda poseer el robot cuando se encuentra ante situaciones inesperadas, debe constituir su cualidad más distintiva para desenvolverse eficazmente en el entorno donde este deba operar, lo cual indica el grado de autonomía que este posee. La navegación robótica es aplicable a múltiples disciplinas y entornos industriales; y en este sentido, la aplicación de la Inteligencia Artificial a través de las diferentes tecnologías inteligentes que la componen (redes neuronales, algoritmos genéticos y aprendizaje automático entre otras) cobra un gran protagonismo dentro del campo de la Robótica Cognitiva para su desarrollo. El objetivo principal del presente trabajo se focaliza en el análisis y presentación de resultados de investigación en técnicas de navegación robótica, que se han obtenidos en base a experimentos llevados a cabo mediante la aplicación de la tecnología de las redes neuronales artificiales, las cuales concentran las mejores características del paradigma reactivo en lo que se refiere a la navegación autónoma de robots. En el presente artículo se evalúa la efectividad y el desempeño de este paradigma mediante la aplicación de una red neuronal de arquitectura sencilla, obteniendo conclusiones en lo que respecta a la conducta deseada del robot y comparándola con la que manifiesta en su desempeño. Los parámetros que se analizan para esta evaluación están relacionados con la evitación de obstáculos, velocidad de respuesta, optimización de las trayectorias que adopta y el logro de los objetivos. Palabras Clave: Navegación Robótica, Redes Neuronales Artificiales, Paradigma Reactivo, Robótica Autónoma. I. INTRODUCCIÓN La robótica autónoma constituye un área muy particular en el vasto campo de la robótica. En esta línea, puede afirmarse que para que un robot sea autónomo es necesario que el mismo sea capaz de reaccionar ante situaciones que no han sido consideradas en la programación de su control y sin ningún tipo de supervisión proveniente del exterior. Aún así, y considerando que su control está definido por un programa determinado, el vehículo debe tener la capacidad suficiente para realizar las tareas que le fueron encomendadas sin que sea necesario que su programa de control defina en forma explícita todas las acciones posibles que este debería realizar ante la totalidad de situaciones posibles que pueden tener lugar en su entorno [1]. Lo hasta aquí expuesto, pone de manifiesto que el robot autónomo debe ser no totalmente preprogramado. A partir de este enfoque, si se considera a un robot operando en un proceso de ensamblado o pintura y se le cambia alguna condición específica de operación, tal como puede ser el desplazamiento de la pieza a ensamblar, el robot ya no estará en condiciones de llevar a cabo estas tareas conforme a las condiciones de diseño. Es decir, dichos robots no tienen la capacidad de desarrollar su actividad ante situaciones que no fueron tenidas en cuenta en su programa de control. En un principio, las investigaciones de robótica llevadas a cabo consideraba que los entornos en donde operaban los robots eran de tipo estructurado, entendiéndose por tal a aquellos que se los puede definir en forma precisa en lo que se refiere a su configuración (qué objetos existen, forma de los mismos, posición en la que se encuentran, etc), ya sea porque el ambiente permanece inalterable en el tiempo, o bien porque los cambios que puedan darse en el mismo son predecibles y, en consecuencia, pueden ser formalizados en términos computacionales. Entonces, se puede afirmar que el enfoque tradicional en robótica asume un perfecto conocimiento del entorno de operación del robot y de las consecuencias que conlleva cada acción que éste realiza, de modo que le permita al diseñador fijar políticas preactivas y de contingencia a los efectos de poder prever resultados no deseados. Este acercamiento al problema resultó ser de suma utilidad en aquellos ambientes donde las llamadas células de trabajo se mantenían fijas en sus posiciones mientras el robot desarrollaba sus tareas. En la medida en que estos ambientes comenzaron a manifestar la necesidad de efectuar cambios para optimizar su producción, es que dicha aproximación pasa a caracterizarse por su rigidez y falta de flexibilidad, no siendo aplicable al caso de robots que deban operar en ambientes dinámicos, es decir, que son cambiantes en el tiempo y no totalmente conocidos, puesto que es muy difícil de prever los numerosos cambios que demandan estos entornos, o en caso de que se puedan prever, el volumen de información a procesar en este sentido sería demasiado grande. Por tal motivo, si se pretende disponer de un sistema de robot que sea capaz de operar en entornos no estructurados, el mismo no 18 Hossian, A., Monte, G., Olivera, V Análisis del Comportamiento de Robots Móviles con RNA. Un Acercamiento desde el Paradigma Reactivo Revista Latinoamericana de Ingeniería de Software, 1(1): 18-24, ISSN