relais v1-n1-revista

REVISTA LATINOAMERICANA DE INGENIERIA DE SOFTWARE FEBRERO 2013 VOLUMEN 1 NUMERO 1 ISSN 2314-2642

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

01-07

Modelos para Asistir la Gestión de Proyectos de Explotación de Información Pablo Pytel, Paola Britos, Ramón García-Martínez

08-17

Análisis del Comportamiento de Robots Móviles con RNA. Un Acercamiento desde el Paradigma Reactivo Alejandro Hossian, Gustavo Monte, Verónica Olivera

18-24

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

25-27

Investigación en Progreso: Espacios Virtuales para Trabajo Colaborativo Darío Rodríguez, Norberto Charczuk, Ramón García-Martínez

28-33

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 e-mail: [email protected]

e-mail alternativo: [email protected] Página Web de la Revista: http://www.unla.edu.ar/sistemas/redisla/ReLAIS/index.htm

Página Web Institucional: http://www.unla.edu.ar

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 3901. (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.

Carlos Mario Zapata Jaramillo, Fabio Alberto Vargas Agudelo. 2013. 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 2314-2642

1

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

[email protected]

Fabio Alberto Vargas Agudelo Facultad de Ingeniería

Tecnológico de Antioquia Medellín, Colombia [email protected]

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. 2013. 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 2314-2642

2

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.


3

TABLA I. ESTRUCTURAS GRAMATICALES PARA ENUNCIAR PROBLEMAS [15]

Caso Descripción Restricciones Ejemplos

1 O→V+Ad+SN

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áctico-semá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);



4

también, se representan los valores de los conceptos clase (los que no son conceptos hoja) por medio de tablas adicionales.

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áctico-semá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

los diferentes valores se asocian con cada uno de los conceptos hoja.

VI. CONCLUSIONES

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.


5

Fig. 2. Esquema preconceptual que representa la propuesta para relacionar objetivos y problemas.



6

Identificación DescripciónO1 Incrementar los usuariosO2 Fomentar las galeríasO3 Fomentar los archivosO4 Fomentar los permisosO5 Asegurar que las galerías tengan álbumesO6 Mantener contenidos actuales e interesantes para los usuarios del sitioO7 Asegurar que se pueda acceder a los álbumesO8 Asegurar que se permita el acceso a los contenidos para cada usuarioO9 Asegurar que los álbumes tengan imágenes

Objetivos

Identificación DescripciónP1 Hay pocas galeríasP2 Hay pocos álbumesP3 Hay pocos permisos para editar álbumes o imágenesP4 Los álbumes no son suficientesP5 Publicar álbumes es una función demoradaP6 Hay pocos archivosP7 La actualización de archivos es difícil de lograrP8 Los usuarios tienen pocos permisosP9 El acceso tiene muchas restricciones para los nuevos usuariosP10 No todos los álbumes se pueden accederP11 Los derechos son difíciles de garantizar después de crear un usuariP12 Hay pocos usuariosP13 Los permisos no se definen claramenteP14 Los derechos son a veces ambiguos

Problemas

Identificación Palabra.Id Rol sintáctico Rol Semántico OrdenP1 W1 Negación Negación 1P1 W2 Adjetivo Conteo 2P1 W3 Determinante 3P1 W4 Sustantivo Receptor 4P1 W5 Verbo Modo 5P1 W6 Verbo Lugar 6P1 W7 Verbo Modo 7

Frases de problemas

Id Descripción TipoW1 No NegaciónW2 Todos ConteoW3 losW4 álbumes ObjetoW5 seW6 puedenW7 acceder LogroW8 Asegurar RealizaciónW9 queW10 a

Palabra

Identificación Palabra.Id Rol sintáctico Rol semántico OrdenO1 W1 Verbo Modo 1O1 W2 Determinante 2O1 W3 Verbo Modo 3O1 W4 Verbo Modo 4O1 W5 Sustantivo Receptor 5

Frases de objetivos

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, 2002. [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, 2010.

[3] M. G. Christel y K. C. Kang, "Issues in requirements elicitation", Technical Report, DTIC Document, Pittsburg, Estados Unidos, 1992.


7

[4] C. M. Zapata y F. Arango, "Alineación entre metas organizacionales y elicitación de requisitos del software", Revista Dyna, vol. 143, 2004. pp. 101-110.

[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. 67-77.

[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. 439-458.

[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. 117-129.

[8] A. Dardenne, A. Van Lamsweerde, y S. Fickas, "Goal-directed requirements acquisition", Science of computer programming, vol. 20, nro. 1, 1993, pp. 3-50.

[9] E. Yu, "Modelling strategic relationships for process reengineering", Social Modeling for Requirements Engineering, vol. 11, 2011.

[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. 219-228.

[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 169-182.

[13] R. Ali, F. Dalpiaz, y P. Giorgini, "Location-based variability for mobile information systems", Technical Report in Advanced Information Systems Engineering, 2008, pp. 575-578.

[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. 406-418.

[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. 46-55.

[16] H. E. Eriksson y M. Penker, "Business modeling with UML: Business patterns at work". Mexico, 1999.

[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. 2005.

[18] Ch. Kepner y B. Tregoe, "The New Rational Manager: An Updated Edition for a New World". Princeton Research Press, Princeton. 1997.

[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. 17-27.

[20] Requirements elicitation", Lecture Notes in Computer Science, vol. 4293, 2006, pp. 17-27.

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 2007. 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 2010. 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.

Pytel, P., Britos, P., García-Martínez, R.. 2013. 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 2314-2642

8

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. [email protected]

Paola Britos Grupo de Investigación en Explotación

de Información. Laboratorio de Informática Aplicada. Universidad Nacional de Río Negro. Argentina.

[email protected]

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. [email protected]

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


9

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 Adecuación que determinar si la explotación de

información es la mejor solución para el problema planteado, y

o É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

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 problema de negocio?

9 poco

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

Datos

E1 ¿Cuánto facilita la tecnología de los repositorios disponibles las tareas de manipulación de los datos?

6 nada

P3 ¿Cuánto se entiende del problema de negocio? 7 poco

A4 ¿En qué medida el problema de negocio no puede ser resuelto aplicando técnicas estadísticas tradicionales?

10 poco Problema de Negocio

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

Proyecto E3

¿En qué medida la planificación del proyecto permite considerar la realización de buenas prácticas ingenieriles con el tiempo adecuado?

7 nada

P4 ¿Qué nivel de conocimientos posee el equipo de trabajo sobre explotación de información?

6 poco Equipo de Trabajo

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


10

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 ( Id ) se calcula con la fórmula (1):

⎟⎟⎟⎟⎟⎟⎟

⎠

⎞

⎜⎜⎜⎜⎜⎜⎜

⎝

⎛

=

=

⋅

⋅+

⎟⎟⎟⎟⎟⎟⎟

⎠

⎞

⎜⎜⎜⎜⎜⎜⎜

⎝

⎛

=⎟⎟

⎠

⎞

⎜⎜

⎝

⎛=⋅=

∑

∑

∑

∑dn

iidP

dn

iidCidP

dn

i idCidP

dn

iidP

dI

1

)1

(

21

1

121 (1)

Donde: Id: 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).

Pdi: representa el peso de la característica i perteneciente a la dimensión d.

Cdi: representa el intervalo difuso asignado a la característica i perteneciente a la dimensión d.

nd: 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 ( Vd ) se utiliza la media aritmética de los valores del intervalo como se indica en la fórmula (2):

4

4

1∑== i

idI

dV (2)Donde:

Vd: representa el valor numérico calculado para la dimensión d. Idi: 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 ( Vd ) 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 ).

22688 EVAVPV

EV⋅+⋅+⋅

= (3)Donde:

EV: representa el valor global de la viabilidad del proyecto. VP: representa el valor para la dimensión plausibilidad. VA: representa el valor para la dimensión adecuación. VE: representa el valor para la dimensión criterio de éxito.

Valor = ‘nada’

Intervalo Difuso= (0,0; 0,0; 1,2; 2,2)

Valor = ‘poco’


Valor = ‘regular’


Valor = ‘mucho’


Valor = ‘todo’


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 (Id). Se considera que la


11

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 Vd 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 pre-procesamiento 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.

TABLA II. VALORES DEL FACTOR DE COSTO OBTY

Valor Descripción

1 Se desea conocer los atributos que caracterizan el comportamiento o la descripción de una clase ya conocida.

2 Se desea dividir los datos disponibles en grupos sin poseer una clasificación conocida previamente.

3 Se desea conocer los atributos que caracterizan a grupos sin poseer una clasificación conocida previamente.

4 Se desea conocer los atributos que poseen mayor frecuencia de incidencia sobre un comportamiento o la identificación de una clase conocida.

5 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.

TABLA III. VALORES DEL FACTOR DE COSTO LECO

Valor Descripción

1 Tanto los directivos como el personal poseen buena disposición para colaborar en el proyecto.

2 Sólo los directivos poseen buena disposición para colaborar en el proyecto mientras que el personal es indiferente al proyecto.

3 Sólo la alta gerencia posee buena disposición para colaborar en el proyecto mientras que la gerencia media y el personal es indiferente.

4 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


12

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.

2 Entre 2 y 4 repositorios con tecnología compatible para la integración.

3 Entre 2 y 4 repositorios con tecnología no compatible para la integración.

4 Más de 5 repositorios con tecnología compatible para la integración.

5 Más de 5 repositorios con tecnología no compatible para la 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 1.000 tuplas en la tabla principal.

3 Entre 1.001 y 20.000 tuplas en la tabla principal.

4 Entre 20.001 y 80.000 tuplas en la tabla principal.

5 Entre 80.001 y 5.000.000 tuplas en la tabla principal.

6 Más de 5.000.000 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 1.000 tuplas en las tablas auxiliares.

3 Entre 1.001 y 50.000 tuplas en las tablas auxiliares.

4 Más de 50.000 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.

2 Más del 50% de las tablas y repositorios están correctamente documentados y existen expertos en los datos disponibles para explicarlos.

3 Menos del 50% de las tablas y repositorios están correctamente documentados pero existen expertos en los datos disponibles para explicarlos.

4 Las tablas y repositorios no están documentadas pero existen expertos en los datos disponibles para explicarlos.

5 Las tablas y repositorios no están documentados y existen expertos en los datos pero no están disponibles para explicarlos.

6 Las tablas y repositorios no están documentados y no existen 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.

TABLA VIII. VALORES DEL FACTOR DE COSTO KEXT

Valor Descripción

1 El equipo ha trabajado en tipos de organizaciones y con datos similares para obtener los mismos objetivos.

2 El equipo ha trabajado en tipos de organizaciones similares pero con datos diferentes para obtener los mismos objetivos.

3 El equipo ha trabajado en otros tipos de organizaciones y con datos similares para obtener los mismos objetivos.

4 El equipo ha trabajado en otros tipos de organizaciones y con datos diferentes para obtener los mismos objetivos.

5 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.


13

TABLA IX. VALORES DEL FACTOR DE COSTO TOOL

Valor Descripción

1 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.

2 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.

3 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.

4 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.

5 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.

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.

3,30 - TOOL1,86 +KEXT0,90 - KLDS 1,80 +QTUA 0,70 - QTUM0,30 -AREP1,20 -

LECO1,10 OBTY 0,80 = PEM

⋅⋅⋅⋅⋅⋅⋅+⋅

(4)

Donde: 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).

TABLA X. RESULTADOS DEL MODELO DE VIABILIDAD

Dimensión Intervalo Valor Dimensión ( Id )

Valor de la Dimensión

( Vd ) (6,05; 7,12; 8,39; 8,82) 7,60

Plausibilidad

(4,65; 5,68; 6,91; 7,84) 6,27

Adecuación

(3,44; 4,62; 5,93; 6,99) 5,25

É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.


14

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 servicio.

5 Proyecto

LECO Se posee buena disposición del personal y la dirección para colaborar en el proyecto. 1

AREP Sólo 1 repositorio disponible. 1

QTUM Aprox. 15.000 tuplas en la tabla principal. 3

QTUA Aprox. 10.000 tuplas en tablas auxiliares 3 Datos

Disponibles

KLDS Las tablas y repositorios no están documentados y no existen expertos. 6

KEXT Se ha trabajado en tipos de organizaciones similares pero con datos diferentes para mismos objetivos.

2

Recursos Disponibles

TOOL La herramienta posee funciones para el formateo y para aplicar las técnicas de minería de datos, pero sólo importa una tabla.

3

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

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.

TABLA XII. DATOS REALES DE CADA PROYECTO Y LOS CALCULADOS POR LOS MODELOS

Valoración indicada por los Investigadores Valores calculados por el Modelo de Viabilidad

# Plausibilidad Adecuación Éxito Viabilidad

Global

Esfuerzo Real*

Plausibilidad Adecuación Éxito Viabilidad Global

Esfuerzo calculado por el Modelo de Estimación*

P1 8 7 4 6,33 2,41 7,20 6,11 5,25 6,27 2,58 P2 7 6 5 6,00 7,00 6,87 5,07 5,25 5,77 6,00 P3 8 5 6 6,33 1,64 5,90 5,67 5,31 5,65 1,48 P4 6 6 4 5,33 3,65 5,12 6,95 4,12 5,51 1,68 P5 6 8 7 7,00 9,35 5,12 7,82 6,81 6,56 9,80 P6 6 5 5 5,33 11,63 5,45 5,61 5,25 5,45 5,10 P7 5 5 5 5,00 6,73 5,45 5,56 5,42 5,48 3,78 P8 6 5 6 5,67 5,40 6,45 5,80 5,18 5,87 4,88 P9 7 6 6 6,33 8,38 7,20 5,61 5,57 6,18 8,70 P10 6 5 6 5,67 1,56 5,85 5,34 5,57 5,59 1,08 P11 8 5 6 6,33 9,70 6,22 6,56 5,42 6,14 9,60 P12 7 8 7 7,33 5,24 7,67 7,35 6,45 7,22 5,80 P13 7 5 6 6,00 5,00 5,93 5,09 7,05 5,93 4,58 P14 7 7 6 6,67 8,97 6,20 6,59 5,69 6,20 9,18 P15 9 7 8 8,00 2,81 8,72 6,89 7,66 7,77 3,48 P16 7 6 5 6,00 11,80 6,45 6,43 5,64 6,22 12,00 P17 6 5 5 5,33 2,79 6,14 5,83 5,42 5,83 2,28 P18 5 5 6 5,33 3,88 6,00 5,31 5,42 5,59 3,58 P19 8 7 7 7,33 5,70 7,01 6,89 5,58 6,58 6,30 P20 9 7 5 7,00 8,54 8,24 6,75 5,52 6,96 9,18 P21 8 6 5 6,33 10,61 8,05 6,45 5,25 6,70 11,50 P22 7 6 6 6,33 6,88 6,45 5,81 6,54 6,24 6,40 P23 3 4 3 3,33 - 4,66 5,34 3,25 4,52 - P24 5 3 2 3,33 - 4,66 3,46 4,21 4,10 - P25 4 2 1 2,33 - 4,63 2,81 3,01 3,52 -

*: en meses/hombre y sólo indicado para proyectos que han finalizado con éxito.


15

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 ( H0 ) y alternativa ( H1 ):

H0: 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).

H1: 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 ( H0 ) 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 (H0). Con el Éxito sucede algo similar: W = W- = 150 > 68, entonces no se rechaza H0. Finalmente la Viabilidad Global tampoco rechaza H0 ( 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 97 228 25 Adecuación 227 98 25

Éxito 175 150 25 Viabilidad Global 181 144 25

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.


16

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:

H0: 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).

H1: 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 ( H0 ) 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. 162-169. 2004.

[2] Stefanovic, N., Majstorovic. V., & Stefanovic, D. “Supply Chain Business Intelligence Model”. Proceedings 13th International Conference on Life Cycle Engineering. 2006. pp. 613-618.

[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. 2011. pp. 83-99. ISBN 978-958-8692-32-6.

[4] Chapman, P., Clinton, J., Keber, R., et al.. “CRISP-DM 1.0 Step by step BI guide”. Edited by SPSS. 2000. http://tinyurl.com/ crispDM

[5] Pyle, D. Business “Modeling and Business intelligence”. Morgan Kaufmann. 2003.

[6] SAS Enterprise Miner: “SEMMA”. 2008. http://tinyurl.com/ semmaSAS

[7] Vanrell, J., Bertone, R., & García-Martínez, R. “Modelo de Proceso de Operación para Proyectos de Explotación de


17

Información”. Anales del XVI Congreso Argentino de Ciencias de la Computación, 674-682. ISBN 978-950-9474-49-9. 2010.

[8] May, L.J. “Major causes of software project failures”, CrossTalk: The Journal of Defense Software Engineering, 11(6), pp. 9-12. 1998.

[9] Charette, R.N. “Why software fails”, Spectrum, IEEE, 42(9), pp. 42-49. 2005.

[10] The Standish Group: “Chaos Report 2010”. http://blog.standish group. com/

[11] Edelstein, H.A. & Edelstein, H.C., “Building, Using, and Managing the Data Warehouse”, Data Warehousing Institute, Prentice-Hall PTR, EnglewoodCliffs (NJ). 1997.

[12] Strand, M. “The Business Value of Data Warehouses - Opportunities, Pitfalls and Future Directions”. Ph.D. Thesis, Department of Computer Science, University of Skovde. 2000.

[13] Fayyad, U.M. “Tutorial report”. Summer school of DM. Monash University (Australia). 2000.

[14] Gondar, J.E. “Metodología del Data Mining”. Number 84-96272-21-4. Data Mining Institute S.L.. 2005.

[15] García-Martínez, R. & Britos, P. “Ingeniería de Sistemas Expertos”. Editorial Nueva Librería. 2004. ISBN 987-1104-15-4.

[16] Gómez, A., Juristo, N., Montes, C. & Pazos, J. “Ingeniería del Conocimiento”, Ed. Ramón Areces S.A. (Madrid). 1997.

[17] Jang, J.S.R. “Fuzzy inference systems”, Upper Saddle River, NJ: Prentice-Hall. 1997.

[18] Sim, J. “Critical success factors in data mining projects”. Ph.D. Thesis, University of North Texas. 2003.

[19] Nemati, H.R. & Barko, C.D. “Key factors for achieving organizational data-mining success”. Industrial Management & Data Systems, 103(4), pp. 282-292. 2003. doi:10.1108/02635570310470692.

[20] Davenport, T.H. “Make Better Decisions”, Harvard Business Review, (November), pp. 117-123. 2009.

[21] Bolea, U., Jakličb, J. Papac, G. & Žabkard, J. “Critical Success Factors of Data Mining in Organizations”, Ljubljana. 2011.

[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. 161-165. 2011. doi:10.1109/ICECTECH.2011.5942073.

[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. 4589-4594. 2009.

[24] Pipino, L.L., Lee, Y.W. & Wang, R.Y. “Data quality assessment”, Communications of the ACM, 45(4), pp. 211-218. 2002.

[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. 13-34. 2004.

[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), 133–150. 2008.

[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. 979–988. 2011. ISBN 978–950–34–0756–1.

[28] International Organization for Standardization. “ISO/IEC DTR 29110-1 Software Engineering - Lifecycle Profiles for Very Small Entities (VSEs) - Part 1: Overview. International Organization for Standardization (ISO)”, Switzerland. 2011.

[29] Laporte, C., Alexandre, S. & Renault, A. “Developing International Standards for VSEs”. Computer, 41(3): 98. 2008.

[30] Organization for Economic Cooperation and Development. “OECD SME and Entrepreneurship Outlook 2005”. OECD Publishing. 2005.

[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. 2009.

[32] Chen, Z., Menzies, T., Port, D., et al. “Finding the right data for software cost modeling”. Software, IEEE, vol.22, no.6, pp. 38- 46, Nov.-Dec. 2005.

[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): 597. 2006.

[34] Pytel, P. “Datos Recopilados para Estimación de Proyectos de Explotación de Información en PYMEs”, Reporte Técnico GISI-TD-2011-01-RT-2012-01, http://www.unla.edu.ar/sistemas/gisi/ GISI/papers/GISI-TD-2011-01-TR-2012--DatosProyectos.pdf

[35] Weisberg, S. “Applied Linear Regression”. John Wiley & Sons, New York. 1985.

[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. 2000.

[37] Pytel, P. Implementación del Modelo de Viabilidad Propuesto. 2012. http://tinyurl.com/ViabPruConcepto

[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-2011-01-RT-2012-02, http://www .unla.edu.ar/sistemas/gisi/GISI/papers/GISI-TD-2011-01-TR-20 12-02-20Datos-Proyectos-para-Viabilidad.pdf

[39] Wilcoxon, F. “Individual Comparisons by Ranking Methods”, Biometrics 1, pp. 80-83. 1945.

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.

Hossian, A., Monte, G., Olivera, V.. 2013. 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 2314-2642

18

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

[email protected], [email protected]

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


19

puede estar totalmente preprogramado y debe poseer una arquitectura cognitiva que le permita establecer las correspondientes relaciones entre lo que el robot percibe del entorno, sean las entradas a los sensores, y sus acciones sobre el mismo, las salidas de los actuadores o motores. Este hecho hace que el robot pueda generar de manera autónoma su mapa sensor – actuador y que tenga la capacidad de adaptarse a los cambios que ocurren en el ambiente de operación.

El presente trabajo centra su atención en la generación de este mapa en función de las características del ambiente de operación del robot, y que la información que éste brinda a través de dicho mapa se procese aplicando la tecnología de las Redes Neuronales Artificiales (RNA).

II. MARCO TEÓRICO Si se busca un sistema robot con la capacidad de desarrollar

su actividad en un entorno de características dinámicas y no conocidas en forma absoluta quien lo diseña, este debe contar con algún tipo de arquitectura cognitiva para su control que le permita establecer vinculaciones entre su sistema sensorial y las acciones que toma sobre el mundo en el cual está operando; esto le permitirá generar en forma autónoma el llamado “mapa sensor – actuador”. En este sentido, es también importante que el sistema robot aprenda de sus errores y optimice su desempeño, motivo por el cual también estará capacitado para adaptarse a variaciones que tienen lugar en su ambiente operativo.

Durante los últimos años, las investigaciones de robótica muestran que dos son los enfoques que han servido de guía: el enfoque “basado en conocimiento”, que tiene su origen en la inteligencia artificial simbólica, y más recientemente, el enfoque “basado en comportamientos”, que se inspira en la naturaleza y toma distancia de algunas de las líneas tradicionales. A continuación se presentan algunas consideraciones acerca de los enfoques mencionados.

A. Enfoque basado en conocimiento A fin de alcanzar la autonomía en los robots, se ha

utilizado la inteligencia artificial simbólica y la piedra basal en la cual se sustenta, se focaliza en el hecho de que la inteligencia es intrínsicamente un fenómeno computacional, y en consecuencia, es posible estudiarla y aplicarla en diferentes sistemas, so pretexto de que los mismos se encuentren fuera de su entorno de actuación.

Este enfoque, también recibe el nombre de “deliberativo”, está fundamentado en una visión introspectiva acerca de cómo piensan y actúan los seres humanos; dicho de otra forma, en relación con los “estados de ánimo” o de “conciencia”. Un ejemplo de esto sería: “una persona que ve una puerta y decide pasar a través de ella”.

Sintetizando, las características más salientes que presentan las arquitecturas de control enmarcadas dentro de este enfoque son las siguientes:

• Hacen uso de técnicas de razonamiento para decidir las acciones que el robot ha de seguir en base a un modelo del entorno; el procesamiento de la información se lleva a cabo en forma secuencial, de modo tal que el robot opera sobre el ambiente de navegación de acuerdo a las modificaciones que se producen en el modelo interno que este posee del ambiente.

• Conforme lo señalado anteriormente, las técnicas de razonamiento, implican estructuras de razonamiento en alto nivel que le permiten al robot hacer frente a requerimientos de navegación de alta complejidad.

• Estas arquitecturas parten de una descomposición de los procesos que el robot debe llevar a cabo en tareas independientes que luego se unifican; estas tareas son las siguientes: interpretación de la información relevada de los sensores, modelado del ambiente en el que el sistema de robot debe desempeñarse, modelo sobre el cuál se planifica un conjunto de acciones a desarrollar por el robot y, por último, estas acciones se realizan mediante un módulo de ejecución que establece los valores correspondientes a cada movimiento.

La figura 1 ilustra las arquitecturas de control del enfoque basado en conocimiento y sus correspondientes tareas.

Concluyendo, este enfoque admite que el robot percibe el mundo, planifica la acción que va a llevar a cabo y la ejecuta; es decir, la información percibida por el robot se representa en un modelo global del ambiente.

Pero también, uno de los principales problemas de este enfoque consiste en que algunos de estos procesos, como la sensorización y la planificación se realizan mediante módulos desarrollados sin considerar los otros módulos presentes en la arquitectura. Esta falta de interacción entre los diferentes módulos que conforman estas arquitecturas, constituyen la razón fundamental de la falta de robustez del enfoque basado en conocimiento. En consecuencia, cuando se acomete el diseño de una arquitectura cognitiva es interesante considerar tres dificultades que se pueden presentar [2]:

• Ocurre que, no es sencillo descomponer el sistema de control en todos los casos.

• Y en muchos casos las interacciones entre los módulos las determina el propio ambiente, y por ende, resultan ser más complejas que unos simples enlaces entre estos módulos.

Las interacciones entre los módulos aumenta de manera exponencial, a medida que crece la complejidad del sistema.

Fig. 1. Arquitectura de control que sigue el enfoque basado en conocimiento

B. Enfoque reactivo En contraposición al enfoque anterior, el enfoque reactivo

se basa en modelos biológicos para explicar el comportamiento observado en distintos organismos vivos. Las arquitecturas que siguen este tipo de comportamiento, a veces llamadas “puramente reactivas”, implementan estrategias de control como una colección de pares “condiciones – acciones”

Modelado del ambiente

Planificación de acciones

Ejecución de las acciones

Interpretación de la información de los sensores

Salidas de actuadores

Entradas de sensores


20

y no llevan a cabo procesos de planificación ya que no operan sobre un modelo interno del ambiente.

La respuesta a estímulos es reflexiva, no regulada por procesos de carácter deliberativos de ningún tipo y los movimientos del robot se guían sólo a partir de la información que se está presente en ese momento en los sensores. Por ende, las acciones del robot se basan en un acoplamiento directo entre sensores y actuadores mediante bucles rápidos de realimentación.

A continuación, se repasan las características más sobresalientes de estas arquitecturas de control enmarcadas dentro de este enfoque:

• La velocidad en el procesamiento de información es mayor que las correspondientes al enfoque basado en conocimiento.

• Aún así, la gran velocidad de respuesta que poseen estas arquitecturas, presentan importantes limitaciones cuando el robot debe abordar tareas que requieren planificación.

• Los modelos de procesamiento de información “masivamente paralelos” son la base de estas arquitecturas, como por ejemplo, las redes neuronales artificiales (RNA).

Para cerrar este enfoque diremos que el robot percibe el mundo y ejecuta la acción que le parezca más adecuada; o sea, la información percibida por el robot no se integra en ningún modelo del ambiente. Es decir, el ambiente de operación es su mejor ambiente.

La figura 2 muestra las arquitecturas de control que siguen el enfoque reactivo puro.

Fig. 2. Arquitectura de control que sigue el enfoque reactivo

C. Enfoque basado en comportamientos1 Una evolución de las reactivas puras son las arquitecturas

que siguen este enfoque, en el sentido de que los comportamientos describen, de algún modo, la forma en que reacciona el sistema robot ante un determinado estado de los sensores; mientras que los actuadores determinan las acciones a seguir por parte del robot de una manera un poco más elaborada que la consulta a una simple tabla de decisión “sensor – actuador”. Asimismo, estas arquitecturas funcionan en base a un conjunto de comportamientos paralelos ejecutándose en forma concurrente y donde cada uno de los distintos módulos de comportamiento se vinculan en forma directa con los sensores y actúan directamente sobre los actuadores [3]. Algunos ejemplos de comportamientos serían: buscar alimentos, cerrar pinzas o evitar obstáculos.

En relación a las dificultades que presentan los dos enfoques anteriores, el diseño aislado de los módulos individuales en el enfoque basado en conocimiento y la falta

1La idea sustancial en este enfoque subyace en el hecho de que la sensorización y la actuación de un sistema robótico están estrechamente vinculadas por medio de comportamientos. Estos comportamientos son controladores realimentados realizados sobre cualquier base de procesado (redes neuronales, sistemas expertos, programación tradicional, etc) y que en un ambiente y robot determinado producen una actuación de éste etiquetada como tal comportamiento (seguir otro robot, seguir una luz o evitar obstáculos).

de planificación en el enfoque reactivo, la comunidad científica perteneciente a este campo comenzó a dedicar mayores esfuerzos para el desarrollo de arquitecturas cognitivas con mayor grado de interacción entre los módulos, es decir que los diferentes módulos se configuran en forma simultánea y coordinada. En tal sentido, a mediados de los años ochenta, comienzan a cobrar relevancia diferentes investigaciones en el campo, tales como las arquitecturas subsumidas [4] y los agentes de competencia [5]. Así, se conforma lo que se denomina “una nueva tendencia en robótica” [6]. Esta tendencia se posiciona entre la planificación de alto nivel de la IA (Inteligencia Artificial) deliberativa y el control de bajo nivel, a la vez que toma inspiración en la naturaleza y pone especial acento en comportamiento y reacción rápida y no en conocimiento y planificación [3].

Para sintezar, las características más relevantes que presentan las arquitecturas de control que se enmarcan dentro de este enfoque son las siguientes [7]:

Dado este enfoque, las funciones de sensorización

y de actuación de un sistema robot están vinculadas directamente mediante comportamientos.

Su desarrollo es más rápido que las arquitecturas pertenecientes al enfoque basado en conocimiento, ya que requiere menos procesado de la información.

Tienen capacidad para tratar situaciones no previstas, ya que depositan mayor confianza en el mundo como fuente de información y de determinación de sus acciones.

Aún con la simplicidad del enfoque reactivo, estas arquitecturas escalan en complejidad buscando incorporar otras habilidades en los robots, tales como memoria, aprendizaje y comunicación.

Dado que no intentan mantener representaciones objetivas del ambiente tienen menos dificultades de representación de los estímulos sensoriales.

La figura 3 ilustra las arquitecturas de control que siguen el

enfoque basado en comportamientos con sus correspondientes tareas [8], [9].

Fig. 3. Arquitectura de control que sigue el enfoque basado en

comportamientos

Entradas de sensores Salidas de actuadores

Entradas de

sensoresSalidas

de actuadores

Identificar cuerpos

Planificar cambios en el ambiente

Elaboración de mapas

Explorar

Evitar obstáculos

Monitorizar cambios


21

D. Enfoque híbrido El enfoque se origina en base a la hibridación de los

enfoques basados en conocimiento y reactivo, dado a las dificultades que ambos enfoques presentaban por separado. Así, la idea central de este enfoque es obtener las características más significativas que ofrecen los enfoques basados en conocimiento y reactivo por separado, a fin de combinarlas y potenciarlas; dichas características se sintetizan en la figura 4.

Fig. 4. Características más significativas de los enfoques basados en

conocimiento y reactivo

Este enfoque reúne las arquitecturas que brindan cierto compromiso entre las orientadas a metas y las reactivas puras. Las mismas se componen de una “capa de comportamiento” cuya misión consiste en el control de bajo nivel o acciones de base tales como avanzar, retroceder, evitar obstáculos, etc; y una “capa de planificación”, encargada de la toma de decisiones de nivel superior o de acciones que requieren mayor elaboración tales como reconocer un objeto o encaminarse hacia un determinado objetivo. Ambas capas se comunican a los efectos de tener la información correspondiente acerca de las acciones a llevar a cabo y de su ejecución [10].

La figura 3 ilustra las características generales de las arquitecturas de control que siguen el enfoque híbrido.

Fig. 5. Arquitectura de control que sigue el enfoque híbrido

Mediante este tipo de arquitecturas se busca optimizar el

desempeño del sistema robot en su entorno de navegación en términos de que el mismo sea capaz de esquivar obstáculos, de desenvolverse con una aceptable velocidad de respuesta, se desplace intentando siempre buscar trayectorias óptimas y que alcance los objetivos que le fueron asignados [8].

De este modo, las arquitecturas híbridas son capaces de liberar todo el potencial de las arquitecturas basadas en comportamiento a partir de la incorporación de los mecanismos deliberativos que se llevan a cabo en la capa de planificación y

de los mecanismos reactivos que se realizan en la capa de comportamiento; permitiendo de esta forma la reconfiguración de los sistemas de control reactivos por medio de su habilidad para razonar sobre los comportamientos básicos [11].

III. EXPERIMENTACIÓN CON REDES NEURONALES ARTIFICIALES

A continuación desarrollaremos un ejemplo práctico de tales conceptos, mediante la simulación de un robot en un entorno determinado, advirtiendo de manera concreta el mecanismo de entrenamiento y los resultados del mismo, en el camino de búsqueda de una trayectoria adecuada y proyectada al desplazamiento del robot desde un origen y hasta un objetivo predeterminado, evitando obstáculos. Dicho en otras palabras, observaremos mediante este ejemplo el proceso que realiza el robot mediante un entorno de simulación con el que éste puede interactuar.

A. Procedimiento para la experimentación Como se observa en la figura 6, el mundo en el que

experimenta este vehículo, consta de una grilla de cien espacios, precisamente identificados mediante un eje cartesiano de posición (x,y), en el que se distribuyen los obstáculos mencionados, presentados con cruces e indicando que por allí el robot no puede avanzar. La línea remarcada en la posición (9,0) describe la llegada u objetivo. A la vez que, en el recuadro de Localización, los indicadores Px y Py, señalan la posición que éste adquiere en su recorrido paso a paso y la orientación con la que se desplaza, a saber: norte, sur, este, oeste. Puede observarse además, que en el diseño del robot se han ilustrado tanto sus sensores y sus motores, en los cuales se actualiza el valor que adquieren durante el proceso de desplazamiento. El objetivo del presente esquema es lograr un seguimiento pormenorizado de la experimentación.

Fig. 6. Entorno de simulación

En consecuencia, se consideran dos tipos de espacios en la grilla: los obstáculos, que no pueden ser ocupados por el robot y que deben ser evitados por el mismo para no colisionar; y los libres, aptos para su desplazamiento. Todo el recuadro que delimita la grilla, también es considerado un obstáculo para el robot.

El robot empleado en este ejemplo consta de cuatro sensores, uno en cada cara, dos sensores internos de posición y posee, además, dos motores, cada uno de los cuales ordena el movimiento de las ruedas laterales.

ENFOQUE BASADO EN

CONOCIMIENTO

ENFOQUE REACTIVO

Comportamiento de tipo reactivo y de rápida

adaptabilidad a los cambios del entorno

Comportamiento de tipo deliberativo y orientado a

metas

Capa de Planificación

Capa de Comportamien

Salidas de actuadores

Entradas de sensores


22

Fig. 7. Esquema Sensor/Motor del Robot

Las coordenadas están dadas por los valores de Px y Py, quienes contienen las coordenadas horizontal y vertical respectivamente, correspondientes a su posición actual en el entorno. Los sensores S1, S2, S3 y S4, son los que deben detectar la proximidad de objetos u obstáculos, adoptando el valor 1 ante la presencia cercana de un objeto (entiéndase por cercano un objeto cuando está a dos casilleros o dos posiciones o menos en relación a la ubicación del sensor, en el entorno que transita el robot); o el valor -1 ante la ausencia cercana de objetos (considerando que un objeto no es cercano cuando está a más de dos casilleros o posiciones respecto del sensor, en el entorno que transita el robot.

De la misma forma, son los motores MA y MB quienes adquieren un par ordenado de valores que producen un efecto determinado, si adoptan el par ordenado (-1, -1), el robot se desplazará una posición hacia atrás, si el par ordenado es (-1, 1) el robot se desplazará una posición hacia la izquierda, si es (1, -1), el desplazamiento será una posición a la derecha y si es (1, 1) el desplazamiento del robot será una posición hacia delante.

Ya hemos presentado el ambiente para el ejemplo de navegación robótica con redes neuronales artificiales. A continuación, observemos el recorrido esperado desde el origen hasta el destino.

Fig. 8. Trayectoria de entrenamiento del Robot

La figura 6, muestra la posición de partida del robot, que

para nuestro caso de estudio es (0,5), y la orientación del mismo, en este caso: Este; indica también, los valores obtenidos para cada sensor y motor, luego de que el cartel enseñe el título “RNA Entrenada!!!”; mientras que la figura 8 muestra, mediante una traza remarcada, la trayectoria del robot que se utilizará para cumplir su objetivo, a través de la búsqueda de patrones de entrenamiento, donde la red neuronal actuará como “cerebro” del robot. El mismo debe llegar a destino, indicado en la posición (9,0).

Para la construcción de un mapa “sensor-motor” para el robot con la trayectoria indicada, se arma una matriz PS (que contiene los datos de los sensores y la posición), y una matriz

T (que contiene la salida asignada al estado sensorial almacenado en la respectiva fila de P).

Haciendo uso de los recursos del entorno propuesto, se entrena una red de tipo Perceptron que consta de seis entradas y dos neuronas de salida.

Con todos estos datos necesarios para la experimentación, mediante los recursos disponibles de los lenguajes de programación, puede crearse un programa que permite tal simulación, en este caso, nuestro programa ha de llamarse “SimulacionEJEMPLObp”.

Para la trayectoria propuesta la figura 8 muestra que el robot puede resolver correctamente el problema de “llegar a destino”.

Consecuentemente, para experimentar este aprendizaje del robot, se analiza la salida de la red en otras posiciones.

A continuación, se simula el comportamiento del robot, iniciando su trayectoria en distintas posiciones. Puede observarse que cuando el robot parte de (0,6) pero con orientación Norte en la figura 9, recorre la grilla hasta llegar el final de ella y regresa por el mismo camino hasta encontrar la trayectoria aprendida para llegar al objetivo.

Fig. 9. Trayectoria de Entrenamiento resuelta correctamente por la RNA para

un punto de partida (0,6), con orientación Norte Si ahora orientamos el robot al Este o al Oeste, los

resultados obtenidos son los observados en las figuras 10 y 11; concluyendo así que no es capaz de alcanzar la trayectoria aprendida y colisiona en ambos casos.

Fig. 10. Trayectoria de Entrenamiento no resuelta por la RNA para un punto

de partida (0,6), con orientación Este


23

Fig. 11. Trayectoria de Entrenamiento no resuelta por la RNA para un punto

de partida (0,6), con orientación Oeste

B. Análisis de los resultados obtenidos Una de las primeras inferencias significativas que se puede

hacer en función de los resultados que arrojaron los experimentos realizados, es que el patrón de entrenamiento ha sido suficiente para algunas trayectorias que entrenó el robot, pero en líneas generales, este dicho patrón no resulta ser muy representativo del entorno bidimensional en el cual este se desplaza, habida cuenta de que la mayoría de las salidas que manifiestan sus motores consiste en avanzar y por esa razón es que colisiona partiendo desde otras posiciones y/o otra orientación, tal como se muestra en las figuras 10 y 11. Para atenuar este problema, se considera aumentar el número de patrones de entrenamiento utilizando trayectorias más largas, vigilando siempre la convergencia de la red. Conforme a lo expresado, es de hacer notar que, por ejemplo, cuando se considera una trayectoria de entrenamiento como la de la figura 11, la cual está dotada de mayor complejidad en lo que hace a la mayor cantidad de maniobras que debe realizar el robot en su conducta de navegación, se observa que el mismo no puede aprenderla ante la no convergencia de la red propuesta.

Por otra parte, otro detalle importante a considerar en el desarrollo bajo este paradigma, es la constante búsqueda del robot por hallar su trayectoria de entrenamiento; lo cual constituye una conclusión lógica es en conformidad con las características del paradigma reactivo que representan las redes neuronales, pero cabe señalar que en situaciones reales, esta situación puede conllevar a un desgaste excesivo del sistema robot en su accionar navegador, así como también a un alto consumo de combustible.

En síntesis, se asume que el uso de las Redes Neuronales Artificiales como técnica de navegación de características reactivas proporciona resultados satisfactorios para ciertas trayectorias en la fase de operación, tanto más en la medida que estas trayectorias presenten mayor similitud con las que desarrolló en la fase de entrenamiento; así es que se tendrá por caso, que el robot buscará girar más para el lado que lo hace en la trayectoria de entrenamiento que para el otro. A medida que las trayectorias que se le proponen al robot son tanto más complejas que la que este entrenó, este paradigma exhibe sus limitaciones haciendo que la red no converja y se produzcan situaciones de colisión en el ambiente de navegación. En otros términos, se produce una incorrecta generalización de la red neuronal para las nuevas situaciones que debe afrontar el robot,

las cuales no se encontraban presentes en las trayectorias de entrenamiento.

IV. CONCLUSIONES Las arquitecturas híbridas combinan los métodos de

procesamiento reactivo y de planificación a los efectos de poder consolidar un diseño de arquitectura más robusta, tendiente a optimizar el desempeño del robot en el ámbito de su entorno de operación.

La idea que subyace detrás de este objetivo central, es que dichas mejoras puedan verse reflejadas en términos de evitación de obstáculos, velocidad de respuesta, optimización de las trayectorias y logro de los objetivos.

Por otra parte, el comportamiento global del agente robótico está definido por la continua interacción entre las capas que componen la arquitectura.

En síntesis, las arquitecturas híbridas, a través de la combinación de ambos enfoques (basado en conocimiento y basado en comportamiento), permiten la reconfiguración de los sistemas de control reactivos por medio de su habilidad para razonar sobre los comportamientos fundamentales.

Además, y en virtud de todo lo expuesto cabe considerar las siguientes cuestiones sobre las que este grupo de investigación se encuentra trabajando con el objetivo de mejorar el desempeño del robot en lo que se refiere a sus conductas de navegación.

Trabajar con modelos de redes neuronales de arquitecturas más complejas (agregando capas ocultas) para lograr una máxima generalización de la red y de esta manera, poder implementar trayectorias más representativas del ambiente de navegación del robot, teniendo en cuenta que a medida que aumenta la cantidad y complejidad de la información que usa la red es más difícil que esta converja.

Complementando el concepto expresado en el punto anterior, considerar la aplicación de técnicas de razonamiento de alto nivel de tipo deliberativas (aprendizaje automático y planificación autónoma de tareas entre otras) como complemento de las técnicas reactivas; las cuales, si bien son de menor velocidad de reacción que estas, también le permiten al robot afrontar requerimientos de desempeño más complejos.

REFERENCIAS [1] Santos, J., Duro, R.: Evolución Artificial y Robótica

Autónoma, Ed. Alfaomega – Ra-Ma, México (2005) [2] Harvey, I.: Artificial Evolution and Real Robots, Proceedings of

Internacional Symposium on Artificial Life and Robotics (AROB), Masanori Sugisaka (Ed), Beppu, Japan, pp. 138-141, (1996)

[3] Amalia F. Foka and Panos E. Trahanias. Predictive autonomous robotnavigation. In Proc. of the IEEE/RSJ International Conference on Intelligent Robots and Systems (IROS), pp. 490-495 (2002)

[4] Brooks, R.: Achieving Artificial Intelligence through Building Robots, A.I. Memo 898, MIT, AI Lab (1986)

[5] Maes, P.: A Bottom-up Mechanism for Behavior Selection in an Artificial Creature, Proceedings of the First International Conference on Simulation of Adaptive Behavior (SAB90), The Mit Press, pp. 238-246, (1991)

[6] Sharkey, N.: The New Wave in Robot Learning, Robotics and Autonomous System, Vol. 22, pp. 179-185, (1991)

[7] Jones, J.L. and Flynn, A.M.: Mobile Robots: Inspiration to Implementation, A.K. Peters Ltd., Wellesley, MA, (1993)


24

[8] J. H. Connel, \SSS: A Hybrid Achitecture Applied to Robot Navigation". Conf. on Robotics and Automation (ICRA-92), pp. 2719-2724. Proc. of the 1992

[9] Mataric, M.J.: Behavior-Based System: Main Properties and Implications, Proceedings of IEEE Internacional Conference on Robotics and Automation, Workshop on Architectures for Intelligence Control Systems, Nice, France, pp. 46-54, (1992)

[10] Ronald C. Arkin, \Behavior-Based Robotics", The MIT Press, (2000)

[11] Adrian. E. Scillato, Daniel. L. Colón y Juan. E. Balbuena: Técnicas de Navegación Híbrida para Navegación de Robots Móviles. Ed. Rama de Estudiantes del IEEE. Tesis de grado para obtener el grado de Ingeniero Electrónico. Universidad Nacional del Comahue.

Alejandro Hossian. Ingeniero Civil (Universidad Católica Argentina). Máster en Ingeniería de Software (Universidad Politécnica de Madrid).. Especializado en Sistemas de expertos - Instituto Técnico Buenos Aires (ITBA). Doctor en Ciencias Informáticas, Universidad Nacional de La Plata (2.012). Profesor de la Universidad Tecnológica Nacional - Facultad Regional Neuquén (UTN - FRN). Director del grupo de investigación de robótica y automatización. Sus temas de interés incluyen:

robótica, redes neuronales artificiales e Inteligencia Artificial.

Gustavo Eduardo Monte. Ingeniero Electricista orientación Electrónica Universidad Nacional de Mar del Plata. Master of Science, State University of New York at Stony Brook. Profesor Titular e Investigador de la Universidad Tecnológica Nacional Facultad Regional del Neuquén (UTN - FRN). Sus tópicos de interés incluyen: procesamiento digital de señales, sensores inteligentes y sistemas embebidos. Miembro de la IES Standards Committee de la IEEE.

Verónica Olivera. Estudiante avanzado de Ingeniería Electrónica Universidad Tecnológica Nacional - Facultad Regional Neuquén (UTN - FRN). Participó en la elaboración de artículos sobre automatización y Robótica Cognitiva. Ayudante Ad-Honorem de "Tecnología de redes neuronales" en UTN - FRN. Sus temas de interés incluyen: robótica cognitiva, automatización, señales y sistemas, redes neuronales artificiales e Inteligencia Artificial.

Merlino, H., Pytel, P., Rodríguez, D. 2013. Investigación en Progreso: Sistemas Inteligentes en Arquitecturas de Motores para Videojuegos. Revista Latinoamericana de Ingeniería de Software, 1(1): 25-27, ISSN 2314-2642

25

Investigación en Progreso: Sistemas Inteligentes en Arquitecturas de Motores para Videojuegos

Hernan Merlino, Pablo Pytel, Darío Rodríguez Grupo Investigación en Sistemas de Información

Departamento Desarrollo Productivo y Tecnológico. Universidad Nacional de Lanús. Remedios de Escalada, Buenos Aires, Argentina.

[email protected]

Resumen — La industria de productos lúdicos informatizados (más conocidos como videojuegos) es una de las actividades económicas de mayor crecimiento en los últimos años. Durante el 2006, en los Estados Unidos los ingresos por videojuegos excedieron por primera vez en la historia a los del cine. Sin embargo, a pesar del auge en este mercado, todavía existen más ofertas de empleo que personas preparadas para ocuparlos. Para lograr el desarrollo de un videojuego se requiere de diversos conocimientos, como ser, diseño multimedial, manejo de lenguajes de programación especifica, uso de plataformas de actividades lúdicas, entre otros; sumado a estas actividades es necesario dotar al videojuego con un grado de inteligencia que lo haga no determinista; logrando que los jugadores mantengan durante una mayor cantidad de tiempo el interés por el mismo, pues de no ser así, los jugadores solo lo utilizarían hasta llegar hasta comprender la lógica de funcionamiento y perderian el interés por el videojuego. Es por esto que es de interés para la industria del video juego el desarrollo de motores basados en sistemas inteligentes tomando la experiencia adquirida en otros dominios, como ser, robótica, minería de datos y control de procesos, haciendo las adaptaciones necesarias al dominio en cuestión..

Palabras Clave —Software lúdico, sistemas inteligentes, videojuegos, arquitecturas.

I. JUSTIFICACIÓN E IMPORTANCIA DE LA PROPUESTA El el año 2004, el Estado Nacional promulgó la Ley 25.922

(Ley de Promoción de la Industria del Software - Definición, Ámbito de Aplicación y Alcances) y el año pasado [1] fue prorrogada la citada norma hasta el año 2019. En este contexto, el Fondo Fiduciario de Promoción de la Industria del Software del Ministerio de Ciencia y Tecnología, en su accionar para la consolidación de empresas existentes y contribuir a la generación de nuevas empresas comerciales dentro del sector, ha señalado como una de las áreas estratégicas la de desarrollo de videojuegos [2].

La industria del video juego en la Argentina es un área creciente de la industria de software que exporta el 90% de su producción [3], lo que la señala como un área promisoria de inversiones. La incorporación de tecnología de sistemas inteligentes en los motores de videos juegos hace que tengan un nivel de “jugabilidad” mayor [4] al que se podría obtener si no se utilizara.

La UNLa dispone de docentes-investigadores que acreditan experiencia de más de una década en la aplicación de Sistemas Inteligentes a problemas concretos, lo que la posiciona como

una Institución con capacidades de generar conocimiento que de mayor valor agregado a este sector de la Industria.

II. ESTADO ACTUAL DEL CONOCIMIENTO SOBRE EL TEMA En los últimos años se ha producido un incremento en el

interés de la comunidad científica por el estudio e investigación de los sistemas inteligentes aplicados al desarrollo de videojuegos, esto se debe en parte al auge que ha tenido el desarrollo de videojuegos [5]. Esto ha producido que el desarrollo de arquitectura para la construcción de videojuegos sea uno de los focos de interés para la industria informática, una lista de los diferentes motores categorizados por sus características se puede encontrar en [6]. En este sentido no se puede dejar de lado a un libro que ha sido paradigmático en el estudio de los diferentes aspectos a tener en cuenta en la construcción de arquitecturas de videojuegos como ser Game Engine Architecture [7], aquí se tratan temas de estilos de programación a el arte necesario para la construcción de videojuegos pasando por el diseño del sonido del mismo.

En el área del desarrollo de motores de sistemas inteligentes para videojuegos, es de apreciar la proliferación de bibliografía relacionada a la problemática, como ser [4, 8-13], que abarcan aspectos teóricos y prácticos relacionados con los sistemas inteligentes dando también lineamientos de las características que debería tener un motor de sistemas inteligentes.

Entre las tecnologías de Sistemas Inteligentes aplicables a la industria de videojuegos se pueden citar:

Sistemas Expertos: Se pueden definir los Sistemas Expertos (SE) como una clase de programas que son capaces de [14]: aconsejar, categorizar, analizar, comunicar, consultar, diseñar, diagnosticar, explicar, explorar, formar conceptos, interpretar, justificar, planificar ; son en suma, programas capaces de manejar problemas que normalmente requieren para su resolución la intervención humana especializada. Las siguientes características guían el diseño (aunque no siempre obtenibles) de los sistemas expertos: [a] aplican su experiencia de una manera eficiente para solucionar problemas, pudiendo realizar inferencias a partir de datos incompletos o inciertos, [b] explican y justifican lo que están haciendo, [c] se comunican y adquieren nuevos conocimientos, [d] reestructuran y reorganizan el conocimiento, [e] pueden quebrantar reglas, es decir, interpretan simultáneamente el espíritu y la letra de de las mismas, [f] determinan cuando un


26

problema está en el dominio de su experiencia, conocido como determinación de la relevancia del problema.

Algoritmos TDIDT: Estos algoritmos (TDIDT - Top Down Induction Decisión Trees) pertenecen a los métodos inductivos del Aprendizaje Automático que aprenden a partir de ejemplos preclasificados [15]. A esta familia pertenecen los algoritmos el ID3, C4.5 y C5. Estos algoritmos generan árboles y reglas de decisión a partir de ejemplos preclasificados. Para construir los árboles se utilizan el método de aprendizaje automático basado en la estrategia propuesta por Hunt en [16], que particiona el conjunto de ejemplos en subconjuntos a medida que avanza; trabajar sobre cada subconjunto es más sencillo que trabajar sobre el total de los datos.

Redes Neuronales BP: Son redes formadas por múltiples capas lo que les permite resolver problemas que no son linealmente separables. Pueden ser totalmente o localmente conectadas. En el primer caso cada salida de una neurona de la capa "i" es entrada de todas las neuronas de la capa "i+1", mientras que en el segundo caso, cada neurona de la capa "i" es entrada de una serie de neuronas (región) de la capa "i+1". Utilizan un algoritmo de aprendizaje llamado regla delta generalizada (ó regla de retropropagación del error), que consiste en minimizar el error (comúnmente cuadrático) por medio del método del gradiente descendente en los parámetros de entrenamiento de la red neuronal [17, 18]. Estas redes son conocidas como redes de retropropagación (Redes BP).

Redes Neuronales SOM: Los mapas auto organizados o SOM (Self-Organizing Map), también llamados redes de Kohonen [19] son un tipo de red neuronal no supervisada competitiva, con capacidad para formar mapas bidimensionales de características a partir del principio de formación de mapas topológicos. Se orientan a descubrir la estructura subyacente de los datos ingresados a partir de establecer características comunes entre los vectores de información de entrada a la red. A lo largo del entrenamiento de la red; los vectores de datos son introducidos en cada neurona y se comparan con el vector de peso característico de la misma. La neurona que presenta menor diferencia entre su vector de peso y el vector de datos es la neurona ganadora (o BMU) y ella y sus vecinas verán modificados sus vectores de pesos.

Redes Bayesianas: Las redes bayesianas o probabilísticas se fundamentan en la teoría de la probabilidad y combinan la potencia del teorema de Bayes con la expresividad semántica de los grafos dirigidos; las mismas permiten representar un modelo causal por medio de una representación gráfica de las independencias / dependencias entre las variables que forman parte del dominio de aplicación [20, 21]. Se puede interpretar a una red bayesiana de dos formas: (a) distribución de probabilidad en la que representa la distribución de la probabilidad conjunta de las variables representadas en la red, ó (b) base de reglas en la que cada arco representa un conjunto de reglas que asocian a las variables involucradas y están cuantificadas por las probabilidades respectivas.

Algoritmos Genéticos: Son métodos de optimización, en los que aquella variable o variables que se pretenden optimizar junto con las variables de estudio constituyen un segmento de información [22, 23]. Aquellas configuraciones de las variables de análisis que obtengan mejores valores para la variable de respuesta, corresponderán a segmentos con mayor capacidad reproductiva. A través de la reproducción, los mejores segmentos perduran y su proporción crece de generación en

generación. Se puede además introducir elementos aleatorios para la modificación de las variables (mutaciones). Al cabo de cierto número de iteraciones, la población estará constituida por buenas soluciones al problema de optimización, pues las malas soluciones han ido descartándose, iteración tras iteración.

Este interés suscitado sobre los aspectos específicos de los sistemas inteligentes en los videojuegos ha permitido la creación de un conferencia anual sobre este área de dominio, denominada GameAI Conference [24], en la que se exponen sobre el uso aplicaciones originales de sistemas inteligentes en videojuegos. También se ha desarrollado un sitio de internet dedicado a la problemática antes mencionada AIGameDev [25], en él se tratan y publican artículos de interés para la comunidad como también guías de buenas practicas y foros de discusión. También se han desarrollados librerías especificas para diferentes aspectos de sistemas expertos como ser el manejo de movimientos tales como en Libbehavior [26]. En relación a motores de sistemas inteligentes para videojuegos, los avances han sido muy recientes con lo cual solo es posible referir AISandBox [27] un entorno de trabajo que se encuentra, al momento de presentación de este proyecto, en sus últimas etapas de pruebas.

III. PREGUNTAS PROBLEMA, HIPÓTESIS Y OBJETIVOS GENERALES Y ESPECÍFICOS

A. Pregunta Problema ¿Cuál es la mejor aproximación para la integracion de un

motor basado en tecnologia de sistemas inteligentes dentro de la arquitectura de un videojuego?

B. Hipótesis Hipótesis I: La tecnología de sistemas inteligentes tiene la madurez suficiente para explorar aplicaciones en la industria de videojuegos. Hipótesis II: La actual tecnología utilizada en motores de videojuegos no esta basada en tecnología de sistemas inteligentes.

C. Objetivo General y Objetivos Específicos: El objetivo de este proyecto es sistematizar el cuerpo de

conocimiento existente, y desarrollar el faltante, sobre el uso de tecnología de sistemas inteligentes en motores de videojuegos, con el propósito de establecer las bases que permitan a la industria de videojuegos incorporar el comportamiento no determinista en sus productos. Objetivos específicos vinculado a las Hipótesis: 1.- Sistematizar y desarrollar el conocimiento de sistemas

inteligentes que sea de aplicación en la industria de desarrollo de videojuegos.

2.- Especificar, diseñar y desarrollar un motor de videojuegos de propósito general, basado en tecnologia de sistemas inteligentes.

IV. METODOLOGÍA Para el Objetivo Específico 1 se propone: (i) realizar

investigación documental sobre sistemas inteligentes y su aplicación a la industria de videojuegos; (ii) identificar en la literatura casos de estudio de arquitecturas de motores de videojuegos; (iii) identificar componentes de la arquitectura


27

que sean potenciables con tecnología de sistemas inteligentes, (iv) desarrollar versiones basadas en tecnología de sistemas inteligentes de los componentes identificados, (v) hacer pruebas de performance de los componentes desarrollados.

Para el Objetivo Específico 2 se propone: con base en los componentes de la arquitectura potenciables con tecnología de sistemas inteligentes identificados en el Objetivo Específico 1: (i) desarrollar mediante la metodología de prototipado evolutivo un arquetipo de motor de videojuego basado en las tecnologías de sistemas inteligentes aplicables; y (ii) realizar pruebas de concepto que validen la arquitectura propuesta.

FINANCIAMIENTO Este proyecto de investigación tiene financiamiento por

subsidio UNLa-SCyT-33B112 de la Secretaria de Ciencia y Técnica de la Universidad Nacional de Lanús, Argentina.

REFERENCES [1] CESSI. 2012. http://www.cessi.org.ar/ver-noticias-telam-la-

presidenta-promulgo-la-ley-de-promocion -de-la-industria-del-software-297. Pagina válida al 01/08/2012.

[2] FONSOFT, 2012. Charla sobre subsidios para emprendedores del software. Fondo Fiduciario de Promoción de la Industria del Software (blogspot). http://fonsoft.blogspot.com.ar/. Pagina válida al 01/08/2012.

[3] AEN, 2012. Crece la Industria Nacional de Videojuegos. Argentina en Noticias. http://www.argentina.ar/_es/economia-y-negocios/ C7990-crece-la-industria-nacional-de-videojuegos.php. Pagina valida al 01/08/2012.

[4] Millington, Ian; Funge, John (2009). Artificial Intelligence for Games, Second Edition. ISBN-13: 978-012374731. Publisher: Morgan Kaufmann.

[5] Gonzalez, D. (2011). Diseño de Videojuegos. ISBN-13: 978-8499640785. Publisher: Alfaomega Ra-Ma.

[6] Wikipedia. List of Game Engines. http://en.wikipedia.org/wiki/ List_of_game_engines. Pagina válida al 01/08/2012.

[7] Gregory, J. (2009). Game Engine Architecture. Publisher: A K Peters, Ltd.

[8] Schwab, B. (2004). AI Game Engine Programming. ISBN-13: 978-1584503446. Publisher: Charles River Media.

[9] Fung, John (2004). Artificial Intelligence for Computer Games. ISBN-13: 978-1568812083. Publisher: A K Peters/CRC Press.

[10] Thompson, Guy (2008). AI and Artificial Life for Video Games. ISBN: 978-1584505587. Charles River Media.

[11] Buckland, Mat (2004). Programming Game AI by Example. ISBN-13: 978-1556220784. Publisher: Jones & Bartlett.

[12] Mark, Dave (2009). Behavioral Mathematics for Game AI. ISBN-13: 978-1584506843. Publisher: Course Technology PTR.

[13] González-Calero, Pedro (Editor), Gómez-Martín, Marco (Editor) (2011). Artificial Intelligence for Computer Games. ISBN-13: 978-1441981875. Publisher: Springer.

[14] García Martínez, R. y Britos, P. 2004. Ingeniería de Sistemas Expertos. Editorial Nueva Librería. ISBN 987-1104-15-4.

[15] Quinlan, J. 1986. Induction of decision trees. Machine Learning, 1(1): 81-106.

[16] Hunt, E., Marin, J., Stone, P. 1966. Experiments in Induction. Academic Press.

[17] Freeman, J., Skapura, D. (1991). Neural Networks: Algorithms, Applications, and Programming Techniques. Adison Wesley.

[18] Hilera, J., Martínez, J. (1995). Redes Neuronales Artificiales. Fundamentos, Modelos y Aplicaciones. Editorial RA-MA.

[19] Kohonen, T. 1995. Self-Organizing Maps. Springer Verlag Publishers.

[20] Pearl, J. 1988. Probabilistic Reasoning in Intelligent Systems: Networks of Plausible Inference. Morgan Kaufmann.

[21] Lauría, E., Duchéis, P. 2006. A Bayesian Belief Network for IT Implementation Decision Support. Decision Support Systems, 42: 1573-1588.

[22] Goldberg, D. 1989. Genetic Algorithms in Search, Optimization, and Machine Learning. Adisson Wesley Publishing Company.

[23] [23] Sivanandam, S., Deepa, S. 2008. Introduction to Genetic Algorithms. Springer-Business Media.

[24] GameAI Conference. http://gameaiconf.com/. Pagina valida al 01/08/2012.

[25] AIGameDev. http://aigamedev.com. Página válida al 01/08/2012.

[26] Libbehavior. 2012. librería de código abierto. http://code.google. com/p/ libbehavior/. Página válida al 01/08/2012.

[27] AISandBox Framework de AI para videojuegos. http://aisandbox .com/ ¡. Página válida al 01/08/2012.

Hernán Merlino. Es Licenciado en Sistemas por la Universidad de Belgrano, Especialista en Ingeniería de Sistemas Expertos por el Instituto Tecnológico de Buenos Aires y Magister en Ingeniería de Software por la Universidad Politécnica de Madrid. Es Profesor Asociado de la Licenciatura en Sistemas de la Universidad Nacional de Lanús. Ha sido Director del proyecto UNLa 33B066 y actualmente dirige el proyecto UNLa 33B112. Es Docente Investigador del Programa de Incentivos de

la Secretaria de Políticas Universitarias del Ministerio de Educación. Su área de investigación es patrones de diseño y de desarrollo de software.

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.

Darío Rodríguez. Es Diseñador Multimedial por la Escuela de Arte Multimedial Da Vinci, Licenciado en Comunicación Audiovisual por la Facultad de Ciencias de la Interacción Social de la Universidad del Museo Social Argentino, y Magister en Tecnología Informática Aplicada en Educación en la Facultad de Informática de la Universidad Nacional de La Plata. Es Docente Instructor en la Licenciatura en Sistemas y codirector del

proyecto UNLa 33A166 de la Universidad Nacional de Lanus. Sus intereses en investigación son los modelos colaborativos de construcción de conocimiento.

Rodríguez, D., Charczuk, N., García-Martínez, R. 2013. Investigación en Progreso: Espacios Virtuales para Trabajo Colaborativo. Revista Latinoamericana de Ingeniería de Software, 1(1): 28-33, ISSN 2314-2642

28

Investigación en Progreso: Espacios Virtuales para Trabajo Colaborativo

Darío Rodríguez, Norberto Charczuk, 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. Remedios de Escalada, Buenos Aires, Argentina.

[email protected]

Resumen — Los espacios virtuales de trabajo colaborativo permiten la integración de grupos de trabajo en la que sus miembros no están físicamente contiguos. Hay una amplia literatura vinculada al modelado de las arquitecturas software que soportan este tipo de ambientes. Sin embargo, los formalismos existentes atienden la interacción entre actores y sistema y entre componentes del sistema; descuidando los aspectos de interacción humana. Este proyecto se propone desarrollar, mediante la metodología de prototipado evolutivo, los siguientes elementos: (a) herramientas para el modelado y diseño de espacios virtuales para trabajo colaborativo con énfasis en las interacciones humanas que deben soportar, (b) un arquetipo patrón de arquitectura de espacio virtual dedicados al desarrollo de proyectos grupales, y (c) herramientas de medición de interacción humana en grupos que realicen trabajo colaborativo basado en espacios virtuales.

Palabras Clave — Espacios virtuales, trabajo colaborativo, grupos de trabajo, herramientas para el modelado.

I. JUSTIFICACIÓN E IMPORTANCIA DE LA PROPUESTA El teletrabajo es una forma flexible de organización del

trabajo consistente en el desempeño de la actividad profesional sin la presencia del trabajador durante una parte importante de su horario laboral. Dichas actividades laborales pueden ser desarrolladas a tiempo parcial o completo [1]. La aparición de Internet [2], hace más de dos décadas, ha generado en el campo laboral nuevos paradigmas de teletrabajo [1].

Los ambientes virtuales se usan hace mas de un lustro en Educación Superior. Las Universidades, basadas en el uso masivo de la tecnología de Internet, han incorporado los campus virtuales como un medio a través de los cuales ofrecen (sin necesidad de presencia de los alumnos): cursos de extensión, programas de posgrado de especialización y maestría; estando en la actualidad, comenzado a ofrecer asignaturas de grado.

Era impensable, antes de la aparición de Internet, que equipos de desarrollo de proyectos pudieran realizar sus actividades sin contar con un lugar físico en el que cada uno de sus integrantes desarrollase sus tareas o; se realizaran las reuniones de equipo para consolidar resultados, evaluar la marcha del trabajo o discutir posibles soluciones a problemas emergentes del proyecto.

El concepto de espacio virtual para trabajo colaborativo (EVTC), surge de la fusión de los conceptos de: teletrabajo, equipos de desarrollo y espacios virtuales. Un EVTC se puede definir como un espacio basado en tecnología de Internet que

permite el trabajo colaborativo de grupos en los que sus miembros no se encuentran físicamente contiguos [3].

Algunas de las ventajas, entre otras, que ofrece el trabajo grupal basado en EVTCs son: [a] el soporte informatico de todos los artefactos desarrollados por el equipo de trabajo permite la trazabilidad de los avances y en consecuencia mejorar el control y la gestion del proyecto; [b] los costos vinculados a conexión de internet y servidores requeridos para el trabajo sobre EVTCs son sensiblemente menores a los costos vinculados a infraestructura fisica de espacios para trabajos presenciales; [c] el tiempo dedicado a traslados hasta el lugar de trabajo es ganado por el individuo para ocio o descanso con el consecuente impacto positivo sobre su productividad en las horas de trabajo.

Si bien se ha avanzado en el desarrollo de arquitecturas de software que soportan EVTCs [4], hay poco trabajo realizado para sentar las bases de una ingeniería de este tipo de ambientes virtuales. En particular, no se cuenta con herramientas que contribuyan al análisis y diseño y que estén orientadas a modelar las interacciones entre los sujetos que usan el EVTC, la gestión de tareas grupales y de los artefactos que surgen del trabajo conjunto [5]. La ausencia de estas herramientas conlleva a no poder especificar satisfactoriamente las funcionalidades que el EVTC debe cumplir a efectos de asegurar que el equipo de trabajo disponga de todos los elementos que aseguren su máximo rendimiento.

II. ESTADO ACTUAL DEL CONOCIMIENTO SOBRE EL TEMA Carlsen [6] presenta una teoría del conocimiento en el

marco de su trabajo sobre modelado de flujos de trabajo en el que sostiene que los términos: datos, información y conocimiento, son utilizados en forma ambigua por lo que propone las siguientes definiciones: Conocimiento: Es un conjunto relativamente estable y

suficientemente consistente de conceptos sabidos por un grupo de personas.

Datos: Denotan algún conjunto de representaciones de conocimiento expresadas en un lenguaje.

Información: Es el incremento de los conocimientos producidos por la acción de recibir un mensaje, es decir, es la diferencia entre las concepciones interpretadas a partir de un mensaje recibido y el conocimiento antes de la acción de recepción.

Drucker [7] en sus trabajos sobre la información y sociedad del conocimiento, y sobre la transformación de las


29

organizaciones basadas en la información y la organización de los especialistas científicos; propone la siguiente definición: "La información son datos dotados de relevancia y propósito; convertir datos en información requiere de conocimientos; el conocimiento, es por definición, especializado".

Nonaka [8, 9] define al conocimiento como una “creencia verdadera y justificada”, sosteniendo que la información es un flujo de mensajes, y que el conocimiento “es creado y organizado por el flujo mismo de la información, basándose en el compromiso y las creencias de su poseedor”; de esta manera liga estrechamente la creación del conocimiento a la acción humana.

Carlsen [6] establece que un punto central a las teorías de Drucker y de Nonaka es que el conocimiento dentro de una organización o grupo es creado a través de un continuo dialogo entre el conocimiento tácito y explicito desarrollado por los distintos actores del grupo, contribuyendo esta interacción a la amplificación y desarrollo de nuevo conocimiento.

La distinción entre conocimiento tácito y explícito se encuentra establecida por la ingeniería de conocimiento [10] en la que se define al conocimiento explícito (conocimiento público o conocimiento codificado) como transmisible en lenguaje formal y sistemático, mientras que el conocimiento tácito tiene una cualidad personal que hace que sea difícil de articular, formalizar y comunicar.

Nonaka [11] identifica cuatro patrones de interacción entre el conocimiento implícito y el conocimiento explicito, a los cuales llama modos de conversión de conocimiento como se presenta en la figura 1.

Carlsen [6] sostiene que el modo de internalizar y externalizar la creación de conocimientos en la creación colaborativa de soluciones para problemas, se encuentra estrechamente relacionado con el proceso de "aprender haciendo", por lo tanto, la acción está relacionada con el proceso de internalización.

Nonaka [9] argumenta que las teorías tradicionales sobre el aprendizaje grupal, descuidan el abordaje de la noción de la externalización de lo aprendido y que prestan poca atención a la importancia de la socialización del conocimiento. Propone que las capacidades de aprendizaje son implícitamente mejoradas (o desarrolladas) durante el proceso de creación del modelo de conocimiento, ya que los grupos crean continuamente nuevos conocimientos mediante la reconstrucción de las perspectivas existentes del modelo de conocimiento desarrollado por ellos. Lo que hace única a esta concepción es la visión dinámica del conocimiento, que está en permanente creación, refinamiento y reformulación a partir de la información aportada por los miembros del grupo.

En los grupos de trabajo, el conocimiento explícito está normalmente representado por un prototipo o modelo que puede ser un representativo de un concepto. La innovación surge cuando se produce la interacción entre el conocimiento tácito y el conocimiento explícito. Nonaka [11] establece que la interacción está determinada por los cambios entre los modos de conversión del conocimiento, inducida por varios factores desencadenantes, como se muestra en la Figura 1. En la figura 2, se muestra el modo de socialización de partida con la construcción de un espacio de interacción para facilitar el intercambio de experiencias y modelos mentales.

El enfoque tradicional de la gestión de flujo de trabajo se centra en el flujo de control dentro de la definición de un proceso [12].

Fig. 1. Modos de conversión de conocimiento según Nonaka

Las perspectivas que son relevantes para el modelado de flujo de trabajo y su ejecución son: (a) perspectiva desde el flujo de control o proceso, (b) perspectiva desde los recursos u organización, (c) perspectiva desde los datos o información, (d) perspectiva desde la tarea o función y (e) perspectiva desde la operación o aplicación.

Fig. 2. Cambios entre los modos de conversión del conocimiento según

Nonaka

Garrido [13] propone para el modelado de flujo de trabajo, un marco conceptual basado en un modelo cooperativo representado por cuatro vistas realizadas bajo diferentes niveles de abstracción [14-16]: Vista organizacional: Refiere a la estructura estática y

dinámica del grupo. Los estados representan los diferentes roles que pueden desempeñar los miembros en el grupo y las transiciones reflejan los posibles cambios de rol en virtud del cumplimiento de ciertas restricciones. Estas restricciones pueden ser capacidades (restricciones cognitivas impuestas a un actor para participar bajo un rol determinado) o leyes (restricciones impuestas por la propia organización que identifican las reglas sociales que deben ser preservadas en el grupo).

Vista cognitiva: Representa las tareas que puede llevar a cabo cada miembro del grupo en el escenario colaborativo. Por un lado se define la interfaz del rol, el cual incluye las características más relevantes del conjunto de tareas a realizar, y por otro lado se describen las tareas. En esta vista pueden aparecer elementos de las vistas de


30

información (documentos, datos, recursos) y de interacción (protocolos).

Vista de interacción: Se analiza la forma de comunicación entre participantes y los recursos usados mediante protocolos de interacción de alto nivel.

Vista de información: Refleja la información que es compartida en el escenario o que se utiliza para la comunicación (documentos, eventos, recursos).

Estas vistas son modeladas a partir de una serie de componentes relativos al grupo y complementarios entre sí, y contribuyen a la comprensión dimensión del grupo como entidad organizativa [17]. En la figura 3 se presenta la descripción asociada a cada uno de los elementos que integran cada componente que se presentan a continuación: Estructura: Un aspecto fundamental de todo sistema es

analizar y comprender su composición. Permite analizar la evolución que se produce en la organización (y por tanto en su propia estructura) mediante relaciones con el contexto.

Comportamiento: El grupo se organiza para realizar una finalidad. Este objetivo condiciona la manera de llevar esta labor y la división del trabajo. Permite abordar la realización de actividades por parte del grupo. Las tareas a realizar no se asignan directamente a actores, sino que se delegan a roles, condicionados por las estrategias del grupo. Los procesos cognitivos necesarios para realizar las tareas están distribuidos en la comunidad, y estos procesos se usan para reaccionar ante los nuevos eventos que se producen.

Entorno: Constituye el espacio de trabajo donde se desenvuelven los grupos.

Dinámica: Los grupos involucrados en una organización de tareas están sujetos a una dinámica cambiante en un proceso evolutivo. Los factores que pueden condicionar este cambio son alteraciones del entorno (nuevos objetivos), cambios estructurales (modificación de los miembros del grupo) o formas de llevarlo a cabo (nuevos métodos de interacción, dispositivos, entre otros). Para ello, habrá que identificar los aspectos más relevantes que influyen a un grupo bajo un modelo dinámico.

García Peñalbo y García Carrasco [18] sostienen que un espacio virtual educativo debe ofrecer un conjunto de servicios educativos funcionales a los participantes del proceso formativo. Éstos pueden soportar una interacción síncrona, cuando los participantes están presentes "en línea" al mismo tiempo mientras se lleva a cabo el servicio, o asíncrona, cuando la presencia de todos los participantes no es requerida para desarrollar la actividad. Para García Carrasco y su equipo de colaboradores [19] los servicios provistos por el espacio virtual educativo pueden clasificarse diversos grupos no disjuntos entre tales como: Servicios de comunicación: Facilitan la comunicación entre los

protagonistas del proceso formativo (estudiantes y profesores). En este grupo se incluyen servicios tan populares como el correo electrónico, foros de discusión (síncronos como el IRC, o asíncronos como los grupos de noticias), seminarios virtuales, videoconferencias o publicación de documentos en formato digital.

Servicios de información: Ofrecen información genérica estructurada y dispuesta de forma eficiente para un uso específico. Ejemplo de este servicio son las páginas web.

ELEMENTO DESCRIPCIÓN

Grupo Es la unidad mínima de organización, consistente en una agregación estructurada de actores. Los grupos poseen identidad y comportamiento.

Rol Los grupos se organizan y estructuran en base a roles. Un rol identifica un comportamiento estereotipado dentro del entorno, el cual puede desempeñar un actor

Actor

Un actor es un agente activo (ya sea persona o computacional) con iniciativa en el sistema y capaz de interactuar con el resto de miembros del grupo. La asignación de roles a actores en los grupos pueden variar por diferentes causas. Por tanto denominaremos

participante al actor que en un instante dado desempeña un rol dentro de un grupo

Organización Todas las estructuras de grupos se disponen en torno a organizaciones, que representan ecosistemas con características compartidas.

Estructura

Contexto

El contexto representa la situación de la organización ubicada en una dimensión espacial y temporal. En este sentido, las alteraciones que puede modificar el comportamiento pueden ser originadas por hechos acaecidos en el pasado o ahora, y además, por las características del entorno.

Objetivos La organización se plantea una serie de metas que se deben alcanzar. Estas metas condicionan el comportamiento de todos los integrantes del grupo.

Tarea

La consecución de los objetivos se realiza llevando a cabo una serie de tareas que están encaminadas a cumplir esos objetivos. Las tareas se asignan a roles del grupo y por su complejidad, pueden descomponerse en un conjunto de actividades más simples.

Estrategia

Consiste en la técnica a aplicar para llevar a cabo un determinado objetivo. Se puede cuantificar y calificar el tipo de estrategias, denotando el grado de flexibilidad y repuesta de la organización para acometer el objetivo ante posibles eventualidades.

Actividad Conjunto de pasos a realizar para llevar a cabo una tarea.

Acción Actividades atómicas no descomponibles y que representan acciones físicas o mentales elementales.

Comportamiento

Evento Estímulo del entorno que es percibido y susceptible de causar una reacción por los participantes. Puede ser externo o bien, provocado por la propia comunidad.

Información Constituye la fuente de información en la organización. Puede tener distintos formatos y modos de compartición

Entorno

Artefactos

Son los dispositivos que permiten el acceso a la información y la comunicación con el resto de participantes. En sistemas ubicuos cobran mayor importancia por su integración dentro de la organización.

Ley

Una ley es una restricción impuesta por el sistema a la propia organización. Las leyes vienen impuestas por el propio entorno (como normas) o por organizaciones de orden superior.

Dinámica

Capacidad

Es una habilidad que un actor o grupo puede llegar a lograr dentro del sistema. Esta capacidad puede estar ligada a aspectos cognitivos (aprendizaje), destrezas (ser experto en...) o cualidades (propiedades o atributos).

Fig. 3. Elementos que integran cada componente y la descripción asociada

Grupos de trabajo colaborativo: Ofrecen la posibilidad de que varias personas trabajen juntas utilizando ordenadores y tecnología informática, facilitando el trabajo en equipo y un intercambio eficiente de información. Ejemplos de servicios de este grupo serían entre otros los seminarios virtuales con varios participantes activos, aplicaciones de tiempo real compartidas como escritura o dibujo cooperativos, sistemas de flujos de trabajo (workflows) o agendas comunes.

Servicios de información: Ofrecen información genérica estructurada y dispuesta de forma eficiente para un uso específico. Ejemplo de este servicio son las páginas web.

Grupos de trabajo cooperativo: Ofrecen la posibilidad de que varias personas trabajen juntas utilizando ordenadores y


31

tecnología informática, facilitando el trabajo en equipo y un intercambio eficiente de información. Ejemplos de servicios de este grupo serían entre otros los seminarios virtuales con varios participantes activos, aplicaciones de tiempo real compartidas como escritura o dibujo cooperativos, sistemas de flujos de trabajo (workflows) o agendas comunes.

Servicios de administración: Permiten la gestión administrativa de las diversas entidades que conforman el dominio del problema del ámbito educativo, esto es, profesores, alumnos, cursos, informes estadísticos.

Servicios de entretenimiento: Son servicios, educativos o no, diseñados en su mayor medida para el ocio, como juegos en línea o tablones de noticias.

Servicios y herramientas de autor: mediante las cuales los formadores pueden producir unidades de actividad que, al tiempo que recuperan los modos escritos de oferta de conocimiento, pueden incorporar el modo oral, el icónico, y el audiovisual, dotados de reticularidad, organización topológicas y navegables en función de los intereses particulares del usuario.

Estos servicios quedan establecidos en el espacio virtual educativo dentro de un conjunto de componentes software de carácter pedagógico, junto a un repositorio de información, donde quedarán almacenados los diferentes activos de información que se intercambian en el proceso educativo. La interacción de los participantes en dicho proceso educativo se hace a través de dichos componentes software, en sus versiones cliente y servidor, donde normalmente el cliente manejado es un clásico navegador web, que da acceso al resto de los componentes [19].

El proyecto que se presenta articula una línea de trabajo que el grupo de investigación viene explorando desde el año 2009.

En esta exploración se han formulado consideraciones sobre el uso de espacios virtuales en la formación de investigadores [20], se ha propuesto diseño conceptual de espacios virtuales para ese fin [21]; se han realizado experiencias sobre entrenamiento mediado por espacios virtuales [22]; se han propuesto elementos para el análisis y diseño conceptual de espacios virtuales de trabajo colaborativo [23]; se han realizado pruebas de concepto y la correspondiente fundamentación sobre formación mediada por espacios virtuales [24]; se ha propuesto trabajar sobre la identificación de usos educativos de espacios de encuentro virtual [25] se han validado elementos de análisis y diseño para espacios virtuales centrados en formación [5]; se ha comenzado a trabajar sobre el diseño conceptual de espacios virtuales para el desarrollo de proyectos en materias de carrera de grado [26]; se ha consolidado un modelo colaborativo de formación basado en espacios virtuales y se han propuesto líneas de investigación en Trabajo Colaborativo basado en Espacios Virtuales [27].

III. PREGUNTAS PROBLEMA, HIPÓTESIS Y OBJETIVOS GENERALES Y ESPECÍFICOS

A. Contexto Los espacios virtuales de trabajo colaborativo permiten la

integración de grupos de trabajo en la que sus miembros no están físicamente contiguos. El proyecto articula una línea de trabajo que el grupo de investigación viene desarrollando sobre esta temática desde el año 2009.

B. Pregunta Problema ¿Se puede cubrir la vacancia de disponer de un conjunto

unificado de herramientas para el modelado y diseño de espacios virtuales de trabajo colaborativo?

C. Hipótesis Hipótesis I: Los espacios virtuales de trabajo colaborativo permiten la integración de grupos de trabajo en la que sus miembros están físicamente no contiguos. Hay una amplia literatura vinculada al modelado de las arquitecturas software que soportan este tipo de ambientes. Sin embargo, los formalismos existentes atienden la interacción entre actores y sistema y entre componentes del sistema. Hipótesis II: Apoyados en las nuevas tecnologías de la información y de las comunicaciones, los ambientes virtuales de trabajo colaborativo abren la posibilidad de disponer un espacio donde el encuentro virtual del equipo de trabajo permita mejorar su productividad. Sin embargo, no todas las arquitecturas propuestas para estos espacios satisfacen las funcionalidades de: gestión de tareas grupales, gestión de los artefactos conceptuales derivados del trabajo grupal, gestión de las interacciones grupales; y documentación de la trazabilidad de las interacciones de los miembros. Tampoco se dispone de las herramientas de modelado correspondientes.

D. Objetivo General y Objetivos Específicos: El objetivo de este proyecto es sistematizar el conocimiento

existente sobre espacios virtuales de trabajo colaborativo y formular una propuesta unificada de herramientas para su modelado y diseño. Objetivo específico vinculado a la Hipótesis I: 1.- Desarrollar herramientas para el modelado y diseño de

espacios virtuales para trabajo colaborativo, con énfasis en las interacciones humanas que deben soportar.

Objetivos específicos vinculados a la Hipótesis II: 2.- Desarrollar un arquetipo patrón de arquitectura de espacio

virtual que guie el diseño de espacios virtuales dedicados al desarrollo de proyectos grupales.

3.- Desarrollar herramientas para realizar mediciones de interacción en grupos que realicen trabajo colaborativo basado en espacios virtuales.

IV. METODOLOGÍA Para el Objetivo Específico 1 se propone: (i) realizar una

investigación documental exploratoria sobre las técnicas de modelado existentes; (ii) identificar casos de estudio y casos de validación; (iii) desarrollar mediante la metodología de prototipado evolutivo los siguientes formalismos de modelado de interacciones humanas: casos de interacción y diagramas de interacción grupal; diagrama de desarrollo grupal de objetos conceptuales, y diagrama de secuencia de dinámica grupal; y (iv) realizar pruebas de concepto en los casos de estudio y casos de validación identificados que validen los formalismos desarrollados.

Para el Objetivo Específico 2 se propone: (i) realizar una investigación documental exploratoria sobre arquitecturas para espacios virtuales; (ii) desarrollar mediante la metodología de prototipado evolutivo un arquetipo patrón de arquitectura de espacio virtual que guíe el diseño de espacios virtuales dedicados al desarrollo de proyectos grupales; y (iii) realizar


32

pruebas de concepto que validen el arquetipo patrón de arquitectura propuesto.

Para el Objetivo Específico 3 se propone: (i) realizar una investigación documental exploratoria sobre herramientas para realizar mediciones de interacción en grupos que realicen trabajo colaborativo, (ii) identificar casos de estudio y casos de validación, (iii) desarrollar mediante la metodología de prototipado evolutivo métricas de interacción grupal mediada por espacios virtuales; y (iv) realizar pruebas de concepto en los casos de estudio y casos de validación identificados que validen las métricas propuestas.

FINANCIAMIENTO Este proyecto de investigación tiene financiamiento por

subsidio UNLa-SCyT-33A166 de la Secretaria de Ciencia y Técnica de la Universidad Nacional de Lanús, Argentina.

REFERENCES [1] Salazar, C. 1999. Teletrabajo. Ingeniería informática, 4. ISSN

0717-4195. [2] Leiner, B., Cerf, V., Clark, D., Kahn, R., Kleinrock, L., Lynch,

D. Postel, J., Roberts, L., Wolf, S. 1999. Brief History of the Internet. CERN Document Server. Report Number cs.NI/9901011.

[3] Rodríguez, D., Charczuk, N., Garbarini, R., García-Martínez, R. 2012. Trabajo Colaborativo basado en Espacios Virtuales. Proceedings II Jornadas de Enseñanza de la Ingeniería. Programa de Tecnología Educativa y Enseñanza de la Ingeniería. Secretaria de Ciencia, Tecnología y Posgrado. Universidad Tecnológica Nacional.

[4] Bibbo, L.,García, D., Pons, C. 2008. A Domain Specific Language for the Development of Collaborative Systems. Proccedings International Conference of the Chilean Computer Science Society (SCCC '08). Pàg. 3-12. ISBN 978-0-7695-3403-9.

[5] Rodríguez, D. 2012. Espacios Virtuales para la Formación de Investigadores. Elementos de Analisis y Diseño. Tesis de Maestría en Tecnología Informática Aplicada a la Educación. Facultad de Informática. Universidad Nacional de La Plata.

[6] Carlsen, S. 1997. Conceptual Modeling and Composition of Flexible Work Flow Models. PhD Thesis on Engineering. Information Systems Group. Department of Computer and Information Science. Norwegian University of Science and Technology. http://www.idi.ntnu.no/ ~sif8060/pensum/A15-thesis-sca.pdf. Página vigente al 21/12/10.

[7] Drucker, P. 1988. The Coming of the New Organization. Harvard Business Review, Nber. January-February. Pág. 45-53. ISSN 0017-8012.

[8] Nonaka, I. 1991. The Knowledge-Creating Company. Harvard Business Review, Nber. November-December. Pág. 96-104. ISSN 0017-8012.

[9] Nonaka, I. 1994. A Dynamic Theory of Organizational Knowledge Creation. Organizational Science, 5201412014: 14-37. ISSN 1526-5455.

[10] García Martínez, R. y Britos, P. 2004. Ingeniería de Sistemas Expertos. Editorial Nueva Librería. ISBN 987-1104-15-4.

[11] Nonaka, I. 2007. The Knowledge-Creating Company. Harvard Business Review, Nber. July-August. Pág. 162-171. ISSN 0017-8012.

[12] Jablonski, S., Bussler, C. 1996. Workflow Management: Modeling Concepts, Architecture and Implementation. International Thomson Computer Press ISBN 185-0322-22-8.

[13] Garrido, J. 2003. AMENITIES: Una Metodología para el Desarrollo de Sistemas Cooperativos Basada en Modelos de

Comportamiento y Tareas. Tesis Doctoral del Departamento de Lenguajes y Sistemas Informáticos. Universidad de Granada. España.

[14] Isla, J., Gutiérrez, F., Gea, M., Garrido, J. 2004. Descripción de Patrones de Organización y su Modelado con AMENITIES. Proceedings 4ª Jornadas Iberoamericanas de Ingeniería del Software e Ingeniería del Conocimiento. Pág. 3-14. ISBN 978-987-1437-47-6.

[15] Isla, J., Gutiérrez, F., Paderewski, P. 2007. Una Aproximación Basada en Patrones para el Modelado Conceptual de Sistemas Cooperativos. IEEE Latin America Transactions, 5201442014: 204-210.

[16] Noguera, M. 2009. Modelado y Análisis de Sistemas CSCW Siguiendo un Enfoque de Ingeniería dirigido por Ontologías. Tesis Doctoral en Informática. Departamento de Lenguajes y Sistemas Informáticos. Universidad de Granada. http://hera.ugr.es/tesisugr /18014094.pdf. Página vigente al 21/12/10.

[17] Fields, B., Merrian, N., Dearden, A. 1997. DMVIS: Design, Modelling and Validation of Interactive Systems. En Design, Specification and Verification of Interactive Systems. Springer-Verlag.

[18] García Peñalvo, F., García Carrasco, J. 2002. Los espacios virtuales educativos en el ámbito de internet un refuerzo a la formación tradicional. Teoría de la Educación: Educación y Cultura en la Sociedad de la Información, Nº. 3. ISSN 1138-9737.

[19] García Carrasco, J., García del Dujo, A., López Fernández, R. 1999. Nuevas tecnologías y formación. PCWEEK. Editorial America Iberica.

[20] Rodríguez, D., Bertone, R., García-Martínez, R. 2009. Consideraciones sobre el Uso de Espacios Virtuales en la Formación de Investigadores. Revista de Informática Educativa y Medios Audiovisuales, 6: 35-42. ISSN 1667-8338

[21] Rodríguez, D. 2010. Diseño Conceptual de Espacios Virtuales para la Formación de Investigadores. Propuesta Técnica de Tesis de Maestría en Tecnología Informática Aplicada a la Educación. Facultad de Informática. Universidad Nacional de La Plata.

[22] Rodríguez, D., Bertone, R., García-Martínez, R. 2010a. Collaborative Research Training Based on Virtual Spaces. En Key Competencies in the Knowledge Society 2014Eds. Reynolds, N. & Turcsányi-Szabó, M.2014. IFIP Advances in Information and Communication Technology, 324: 344-353. ISBN 978-3-642-15377-8.

[23] Rodríguez, D., Pollo-Cattaneo, F., Bertone, R., García-Martínez, R. 2010b. Elementos para el Análisis y Diseño Conceptual de Espacios Virtuales de Trabajo Colaborativo Orientados a la Formación de Investigadores. Anales del XVI Congreso Argentino de Ciencias de la Computación. Pág. 364-373. ISBN 978-950-9474-49-9.

[24] Rodríguez, D., Bertone, R. García-Martínez, R. 2010c. Formación de Investigadores Mediada por Espacios Virtuales. Fundamentación y Prueba de Concepto. Proceedings del V Congreso de Tecnología en Educación y Educación en Tecnología. Pág. 512-421. ISBN 978-987-1242-42-9.

[25] Charczuk, N. 2011. Identificación de Usos Educativos de Espacios de Encuentro Virtual. 2014en preparación2014. Propuesta Técnica de Tesis de Maestría en Tecnología Informática Aplicada a la Educación. Facultad de Informática. Universidad Nacional de La Plata. Codirector: Mg. Darío Rodríguez.

[26] Garbarini, R. 2013. Diseño Conceptual de Espacios Virtuales para el desarrollo de proyectos en materias de carrera de grado en preparación. Propuesta Técnica de Tesis de Maestría en Tecnología Informática Aplicada a la Educación. Facultad de


33

Informática. Universidad Nacional de La Plata. Mg. Darío Rodríguez.

[27] Rodríguez, D., Bertone, R., Pollo-Cattaneo, F., García-Martínez, R. 2012a. Modelo Colaborativo de Formación de Investigadores. Proceedings II Jornadas de Enseñanza de la Ingeniería2014en prensa2014. Programa de Tecnología Educativa y Enseñanza de la Ingeniería. Secretaria de Ciencia, Tecnología y Posgrado. Universidad Tecnológica Nacional.

Darío Rodríguez. Es Diseñador Multimedial por la Escuela de Arte Multimedial Da Vinci, Licenciado en Comunicación Audiovisual por la Facultad de Ciencias de la Interacción Social de la Universidad del Museo Social Argentino, y Magister en Tecnología Informática Aplicada en Educación en la Facultad de Informática de la Universidad Nacional de La Plata. Es Docente Instructor en la Licenciatura en Sistemas y codirector del

proyecto UNLa 33A166 de la Universidad Nacional de Lanus. Sus intereses en investigación son los modelos colaborativos de construcción de conocimiento.

Norberto Charczuk. Es Profesor para Educación Media, Técnica y Agraria por el Instituto Superior de Formación Docente, Apoyo y Perfeccionamiento Educativo DENO Nº 2957, es Licenciado en Calidad de la Gestión de la Educación por la Universidad del Salvador. Es Docente Instructor en la Licenciatura en Sistemas de la Universidad Nacional de Lanus. Sus intereses en investigación son los modelos sociometricos

en espacios virtuales de trabajo colaborativo aplicados a la enseñanza superior.

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 de la Universidad Nacional de Lanus. 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.