REVISTA LATINOAMERICANA DE INGENIERIA DE...

REVISTA LATINOAMERICANA DE INGENIERIA DE SOFTWARE JUNIO 2013 VOLUMEN 1 NUMERO 3 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 La Esencia de la Ingeniería de Software: El Núcleo de Semat Ivar Jacobson, Pan-Wei Ng, Paul E. McMahon, Ian Spence y Svante Lidman Traducción de: Carlos Mario Zapata Jaramillo

71-78

Modelo de Proceso de Conceptualización de Requisitos Alejandro Hossian

79-101

Procedimiento de Explotación de Información para la Identificación de Campos anómalos en Base de Datos alfanuméricas Horacio Kuna, German Pautsch, Alice Rambo, Martin Rey, J. Cortes, S. Rolón

102-106

Un Modelo de Ciclo de Vida y Mapa de Actividades para Proyectos de Explotación de Información Hernán Arboleya

107-124

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

RAUL AGUILAR VERA (México) Cuerpo Academico de Ingenieria de Software

Facultad de Matemáticas Universidad Autonoma de Yucatán

PAOLA BRITOS (Argentina)

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 (Argentina)

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 (Argentina)

Grupo de Investigación de Sistemas Inteligentes en Ingeniería

Facultad Regional del Neuquén Universidad Tecnológica Nacional

BELL MANRIQUE LOSADA (Colombia) Programa de Ingeniería de Sistemas

Facultad de Ingeniería Universidad de Medellín

CLAUDIO MENESES VILLEGAS (Chile)

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. (Venezuela) Facultad de Ingeniería

Escuela de Ingeniería de Sistemas Universidad de Los Andes

MARÍA FLORENCIA POLLO-CATTANEO (Argentina)

Grupo de Estudio en Metodologías de Ingeniería de Software

Facultad Regional Buenos Aires Universidad Tecnológica Nacional

JOSÉ ANTONIO POW-SANG (Perú) Maestría en Informática

Pontifica Universidad Católica del Perú

DIEGO VALLESPIR (Uruguay) Instituto de Computación

Universidad de la Republica

CARLOS MARIO ZAPATA JARAMILLO (Colombia) Departamento de Ciencias de la Computación y de la

Decisión Facultad de Minas

Universidad Nacional de Colombia

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 (Traductor), Ivar Jacobson, Pan-Wei Ng, Paul E. McMahon, Ian Spence, Svante Lidman. 2013. La Esencia de la Ingeniería de Software: El Núcleo de Semat. Revista Latinoamericana de Ingeniería de Software, 1(3): 71-78, ISSN 2314-2642

71

La Esencia de la Ingeniería de Software: El Núcleo de Semat

Ivar Jacobson, Pan-Wei Ng, Paul E. McMahon, Ian Spence y Svante Lidman

Integrantes de la iniciativa Semat (Método y Teoría de la Ingeniería de Software)

Traducción de: Carlos Mario Zapata Jaramillo Facultad de Minas

Universidad Nacional de Colombia Medellín, Colombia

[email protected]

Artículo publicado originalmente en Communications of the ACM, vol. 55, no. 12, december 2012, pp. 42-49. El traductor declara tener autorización de los autores para difundir la versión en español en la Revista Latinoamericana de Ingeniería de

Software, sin que ello presente incompatibilidades o vulnere los derechos de Communications of the ACM.

Resumen— Esta es una traducción del artículo que se publicó en Communications of the ACM en Diciembre de 2012 bajo el título “The Essence of Software Engineering: The SEMAT Kernel” y se realiza debido a la importancia que adquiere el tema para la audiencia de hispanoparlantes, de forma que se pueda generar un acceso a lo que constituye uno de los últimos adelantos en Ingeniería de Software.

Palabras clave— Núcleo, alfa, espacio de actividad, estado, Semat

I. INTRODUCCIÓN Todo aquel que desarrolla software sabe que es un negocio

complejo y riesgoso y que sus participantes siempre buscan nuevas ideas que los conduzcan a desarrollar mejor software. Por fortuna, la ingeniería de software es aún una profesión joven y creciente que mira las innovaciones y mejoras en las mejores prácticas cada año. Por ejemplo, basta mirar las mejoras y beneficios que el pensamiento lean y ágil tuvo sobre los equipos de desarrollo de software.

Los equipos exitosos de desarrollo de software necesitan establecer un balance entre las entregas rápidas de sistemas de software que trabajen bien, la satisfacción de sus interesados, el tratamiento de sus riesgos y la mejora de sus formas de trabajo. Para eso, ellos necesitan un marco de pensamiento efectivo que cierre la brecha entre su actual forma de trabajo y cualquier idea nueva que quieran adoptar. Este artículo presenta ese marco de pensamiento en forma de un núcleo accionable, que podría beneficiar cualquier equipo que desee balancear sus riesgos y mejorar su forma de trabajo.

El trabajo en el núcleo, la esencia de la ingeniería de software, se inspiró y es una respuesta directa al llamado a la acción de los Métodos y Teoría de la Ingeniería de Software (Semat, por sus iniciales en inglés; nota del traductor: si bien el origen de la palabra Semat lo constituyen las iniciales de las palabras que conforman la sigla, acogiendo el espíritu de la iniciativa, se prefiere colocarlo con mayúscula inicial, pues se pretende que, más que un acrónimo, se convierta en un sustantivo), el cual es, a su modo, un pequeño paso hacia la redefinición de la ingeniería de software.

Ivar Jacobson, Bertrand Meyer y Richard Soley fundaron Semat en septiembre de 2009, cuando sintieron que había llegado el momento de cambiar fundamentalmente la forma en

que la gente trabaja con métodos de desarrollo de software [3, 4, 8]. Ellos escribieron una declaración del llamado a la acción, que en pocas líneas identifica una cantidad de problemas críticos, explica por qué se necesita actuar y sugiere qué se necesita para hacerlo. El llamado a la acción es:

Algunas áreas de la ingeniería de software hoy en día sufren prácticas inmaduras. Los problemas específicos incluyen: • La prevalencia de bogas más típicas en la industria de la

moda que en una disciplina ingenieril. • La carencia de una base teórica sonora y ampliamente

aceptada. • La gran cantidad de métodos y variantes de métodos, con

diferencias que poco se entienden y que se magnifican artificialmente.

• La carencia de evaluación y validación experimentales y creíbles.

• La separación entre la práctica industrial y la investigación académica.

La afirmación del llamado a la acción de Semat de que la industria de software es propensa a bogas y modas hace que la gente asuma que Semat se opone a las nuevas ideas. Esto no podría estar más lejos de la verdad. Como usted podrá ver en este artículo y en el libro que pronto se publicará, llamado “La esencia de la ingeniería de software: aplicando el núcleo de Semat” [6], los partidarios de Semat son muy entusiastas con las nuevas ideas. Ellos están en contra del comportamiento contrario a lo lean y a lo ágil. Este comportamiento proviene de gente que adopta soluciones inapropiadas porque creen que esas soluciones están de moda o porque los presionan sus pares o la corrección política.

Semat apoya un proceso para redefinir la ingeniería de software, basado en una teoría sólida, principios probados y mejores prácticas que: • Incluyan un núcleo de elementos ampliamente aceptados y

que se pueda extender a usos específicos. • Traten asuntos tecnológicos y humanos. • Los apoyen la industria, la academia, los investigadores y

los usuarios. • Apoyen la extensión ante los requisitos cambiantes y la

tecnología. El llamado a la acción de Semat recibió un amplio apoyo,

incluyendo una lista creciente de signatarios y partidarios


72

(http://www.semat.org). En febrero de 2010, los fundadores de Semat desarrollaron el llamado a la acción por medio de una declaración de visión [5]. De acuerdo con esta visión, Semat se enfoca en dos objetivos principales: encontrar un núcleo de elementos ampliamente aceptados y la definición de una base teórica sólida.

En gran medida, esas dos tareas son independientes una de otra. Encontrar el núcleo y sus elementos es un ejercicio pragmático que requiere desarrolladores experimentados de software con conocimiento de muchos de los métodos existentes. Definir la base teórica es una investigación académica y podría tomar muchos años para conseguir un resultado exitoso.

II. EL PODER DE UN TERRENO COMÚN El primer paso de Semat era identificar un terreno común

para la ingeniería de software. Este terreno común se manifestaba como un núcleo de elementos esenciales que son universales a todos los esfuerzos de desarrollo de software y un lenguaje sencillo para describir métodos y prácticas. El núcleo se publicó inicialmente en la entrega [2, 9] que hizo Semat al OMG (Grupo de Gestión de Objetos, por sus siglas en inglés). Como se muestra en las figuras 1 y 2, el núcleo contiene un pequeño número de “cosas con las que siempre trabajamos” y “cosas que siempre hacemos” cuando se desarrollan sistemas de software. También se está adelantando trabajo para definir las “habilidades que siempre necesitamos tener”, pero esto tendrá que esperar hasta futuras versiones del núcleo.

Más que un modelo conceptual, el núcleo provee:

• Un marco de pensamiento para que los equipos razonen sobre el progreso que están haciendo y la salud de sus esfuerzos.

• Un terreno común para la discusión, mejoramiento, comparación e intercambio de métodos y prácticas de ingeniería de software.

• Un marco para que los equipos ensamblen y mejoren continuamente su forma de trabajo, mediante la composición de prácticas definidas por separado y de diverso origen.

• Un fundamento para la definición de medidas que no dependan de las prácticas, para evaluar la calidad del software producido y los métodos que se usan para producirlo.

• Más importante aún, una forma de ayudarle a los equipos a comprender dónde están, qué deberían hacer luego y dónde necesitan mejorar.

III. LA IDEA GENERAL

¿Qué hace del núcleo algo más que sólo un modelo conceptual de la ingeniería de software? ¿Qué es lo realmente nuevo acá? Esto se puede resumir en sus principios fundamentales (véase la Figura 3), que realmente suministran tres características únicas del núcleo: es accionable, es extensible y es práctico.

Fig. 1. Cosas con las que siempre trabajamos.


73

Fig. 2. Cosas que siempre hacemos.

Fig. 3. Principios fundamentales que apoyan el núcleo.

El núcleo es accionable. Una característica única del núcleo es la forma en que maneja las “cosas con qué trabajar”. Ellas se capturan como alfas en lugar de productos de trabajo (tales como documentos). Un alfa es un elemento esencial del esfuerzo de ingeniería de software, el cual es relevante para una evaluación de su progreso y salud. Como se muestra en la Figura 1, Semat identificó siete alfas: oportunidad, interesados, requisitos, sistema de software, trabajo, forma de trabajo y equipo.

Los alfas se caracterizan por un simple conjunto de estados que representan su progreso y salud. Por ejemplo, el sistema de software se mueve entre los estados “con arquitectura seleccionada”, “demostrable”, “usable”, “listo”, “operacional” y “retirado”. Cada estado tiene una lista de chequeo que especifica los criterios necesarios para alcanzar un estado. Esos estados hacen que el núcleo sea accionable y lo habilitan para guiar el comportamiento de los equipos de desarrollo de software.

El núcleo no presenta el desarrollo de software como un proceso lineal, sino como una red de elementos que colaboran y que se deben balancear y mantener, de modo que los equipos puedan hacer progresos efectivos y eficientes, eliminar desperdicios y desarrollar muy buen software. Los alfas en el núcleo proveen un marco general para dirigir y hacer progresar los esfuerzos de desarrollo de software, sin importar las prácticas que se apliquen o la filosofía que se siga.

A medida que se agregan prácticas al núcleo, se agregarán nuevos alfas para representar las cosas que dirijan o inhiban el progreso de los alfas del núcleo. Por ejemplo, el alfa “requisitos” no se tratará en conjunto, sino que avanzará ítem por ítem. El progreso de los ítems individuales de requisitos conducirá o inhibirá el progreso y salud del alfa “requisitos”. Los ítems de requisitos pueden ser de diferentes tipos, por ejemplo, características, historias de usuario o porciones de casos de uso. Cada tipo se puede representar como un alfa y tener unos estados a seguir. El beneficio de relacionar esos ítems pequeños con el núcleo de granularidad más gruesa radica en que permite seguir la salud del esfuerzo en conjunto. Esto proporciona un balance necesario al seguimiento de bajo nivel de los ítems individuales, permitiendo a los equipos entender y optimizar sus formas de trabajo.

El núcleo es extensible. Otra característica única del núcleo es la manera en que se puede extender para apoyar diferentes proyectos (por ejemplo, nuevos desarrollos, mejoras a sistemas legados, desarrollos internos, desarrollos externos, líneas de productos de software, etc.). El núcleo le ayuda a agregar prácticas, tales como historias de usuario, casos de uso, desarrollo basado en componentes, arquitectura, programación por pares, reuniones diarias de pie, equipos auto organizados y otras. Se buscan prácticas para construir los métodos que usted necesita. Por ejemplo, diferentes métodos se podrían ensamblar para desarrollo interno y subcontratado o para el desarrollo de sistemas embebidos de seguridad crítica y sistemas de reporte de asistencia administrativa.


74

La separación de prácticas es la idea clave aquí. Ya que el término “práctica” se usó ampliamente en la industria por muchos años, el núcleo tiene un enfoque específico en el manejo e intercambio de prácticas. Las prácticas se representan como unidades modulares separadas y distintas, que un equipo puede escoger usar o no. Esto contrasta con los enfoques tradicionales que tratan el desarrollo de software como una sopa de prácticas que no se diferencian y conduce a los equipos a deshacerse de lo bueno y lo malo cuando se mueven de un método a otro.

El núcleo es práctico. Quizá la característica más importante del núcleo es la manera en que se usa en la práctica. Los enfoques tradicionales de los métodos de desarrollo de software tienden a enfocarse en apoyar a los ingenieros de procesos o los ingenieros de calidad. El núcleo, en contraste, es un marco de pensamiento tangible y práctico que apoya a los profesionales de software a medida que realizan su trabajo.

Por ejemplo, el núcleo se puede “tocar” y usar [7, 10] empleando tarjetas (véase la figura 4). Las tarjetas proporcionan recordatorios concisos y señales para los miembros del equipo, a medida que realizan sus tareas diarias. Al proporcionar listas de chequeo y sugerencias prácticas, en lugar de discusiones conceptuales, el núcleo se convierte en algo que el equipo usa diariamente. Esta es una diferencia fundamental con los enfoques tradicionales, que tienden a exagerar el énfasis en las descripciones de los métodos, en lugar del uso de los métodos y, por ello, sólo los suele consultar gente nueva del equipo.

Las tarjetas proporcionan una descripción concisa que sirve como recordatorios para los miembros del equipo. Ellos pueden mantener el núcleo como un pequeño mazo de tarjetas en sus bolsillos, que fácilmente pueden extraer para discutir el estado actual del desarrollo, la asignación de trabajo y la colaboración entre los miembros del equipo. Los equipos también pueden discutir áreas de mejoramiento refiriéndose a las tarjetas. Así, el núcleo no es sólo una descripción pesada de lo que un equipo necesita hacer. En su lugar, forma una parte esencial de lo que hacen cada día.

El núcleo en acción. El núcleo tiene muchas aplicaciones en las vidas diarias de los profesionales de software. Algunas de ellas son: • Correr una iteración o un sprint.

• Correr el desarrollo completo, desde la idea hasta el producto.

• Escalar hacia grandes organizaciones y esfuerzos complejos de desarrollo de software.

La primera aplicación, la planeación de una iteración, se usa acá como un ejemplo de lo que un equipo puede hacer con el núcleo. Las otras se cubren completamente en La Esencia de la Ingeniería de Software: aplicando el núcleo de Semat.

El ejemplo que se presenta acá asume que una compañía tiene muy poco en cuanto a procesos formales. En el pasado, se creía en tener individuos creativos y habilidosos en los equipos experimentados, pero la compañía no crecía ni tenía muchas nuevas contrataciones. Esos nuevos empleados, la mayoría recién salidos de la universidad, tienen buenas habilidades técnicas (por ejemplo en lenguajes de programación), pero no son tan habilidosos en otros aspectos del desarrollo de software, como el trabajo con los interesados para lograr acuerdos en los requisitos.

Esta compañía tiene un equipo de desarrollo que es responsable por hacer una aplicación móvil para redes sociales que permita a los usuarios compartir ideas, fotos y comentarios y navegar por ellos. El equipo comenzó con sólo dos desarrolladores, Smith (el líder del equipo) y Tom, los cuales tenían familiaridad con el núcleo. Luego, se les unieron otros dos desarrolladores, Dick y Harriet, que eran nuevos en el trabajo y no tenían experiencia previa en el núcleo. Para Smith, el líder del equipo, el éxito significaba más que funcionalidad, cronograma y calidad. Este equipo corría el desarrollo de forma iterativa. Usted puede pensar en planear una iteración de la manera siguiente: 1. Determine dónde está: resuelva el estado actual del

esfuerzo 2. Determine a dónde ir: decida en qué enfocarse luego y

cuáles serán los objetivos de la próxima iteración.

3. Determine cómo llegar allá: póngase de acuerdo en las tareas que el equipo necesita para lograr los objetivos.

Fig. 4. Las tarjetas hacen tangible el núcleo.


75

IV. DETERMINE DÓNDE ESTÁ EL EQUIPO UTILIZANDO EL NÚCLEO

Supongamos que Smith y su equipo llevan seis semanas en el desarrollo. Ellos proporcionaron una demostración temprana del sistema a sus interesados, quienes se sintieron satisfechos y proporcionaron una valiosa retroalimentación. Sin embargo, el sistema aún no lo pueden correr los usuarios finales. Usted puede usar el núcleo para hacer esto de varias formas. Si usted está empleando tarjetas de estado de los alfas, entonces usted puede hacer un tutorial como sigue: 1. Coloque las tarjetas de cada alfa en una fila de una tabla

con el primer estado a la izquierda y el último estado a la derecha.

2. Deténgase en cada estado y pregunte a su equipo si se logró ese estado.

3. Si se logró el estado, mueva la tarjeta hacia la izquierda. Continúe con la siguiente tarjeta hasta que logre el estado que su equipo aún no logra.

4. Mueva esta tarjeta de estado y el resto de las tarjetas pendientes de estado hacia la derecha.

La Figura 5 muestra los estados que el equipo de Smith logró a la izquierda y aquellos que aún no logró a la derecha. Por simplicidad, la Figura 5 muestra sólo tres de los alfas del núcleo.

Determine a dónde ir con el núcleo. Una vez el equipo se pone de acuerdo en los estados de los alfas, los miembros discuten los próximos estados “objetivo” deseados, que guían su planeación. El equipo se pone de acuerdo para usar los inmediatamente próximos estados de los alfas para ayudar a establecer los objetivos de la próxima iteración, como se muestra en la Figura 6.

El nombre del estado del alfa suministra una pista para comprender lo que se necesita lograr para alcanzar un estado. Los miembros del equipo pueden encontrar más al leer y comprender las listas de chequeo de los estados de los alfas. Al recorrer los estados de cada alfa uno a uno, un equipo se puede familiarizar rápidamente con lo que se requiere para lograr cada estado. De esta manera, el equipo aprende sobre los alfas del núcleo al mismo tiempo que determina el estado actual de su desarrollo y sus estados objetivo siguientes.

Determine cómo llegar allá con el núcleo. Smith y su equipo buscan los próximos estados objetivo y se ponen de acuerdo en lo que necesitan para establecer algunas prioridades. Primero, ellos necesitan determinar su forma de trabajo: trabajando bien, luego su sistema de software: usable y, finalmente, sus requisitos: tratados. La razón es simple: si no se tiene la forma de trabajo trabajando bien, se impedirían sus intentos de tener el sistema de software usable. Además, ellos se pusieron de acuerdo en la prioridad para los ítems de requisitos perdidos necesarios para lograr el estado requisitos: tratados.

Smith y su equipo luego discutieron lo que necesitaban hacer para lograr esos estados, como se muestra en la Tabla 1. Al recorrer los estados objetivo de los alfas, Smith es capaz de determinar un conjunto de objetivos y tareas para la próxima iteración.

Cómo el núcleo ayuda a planear iteraciones. Un buen plan debe ser inclusivo, lo que significa que debe incluir todos los ítems esenciales y cubrir el equipo como un todo. También, debe ser concreto, de modo que el equipo lo pueda accionar. El equipo debería, también, tener una manera de monitorear su progreso contra el plan.

Fig. 5. El equipo usa los alfas para determinar los estados actuales.


76

Estado objetivo Cómo el equipo planea alcanzarlo

Tanto Dick como Harriet estuvieron de acuerdo en que tenían dificultades para aplicar las pruebas automáticas. Ellos necesitaban ayuda para progresar. Tom estuvo de acuerdo en que él tenía que invertir tiempo enseñándoles.

Se agregó una tarea a la lista de pendientes de la iteración para que Tom condujera un entrenamiento en pruebas automáticas para Dick y Harriet.

• Tarea 1. Conducir entrenamiento en pruebas automáticas.

Este estado nos recuerda que el sistema de software debe mostrar que es de la calidad y funcionalidad suficientes para ser útil para los usuarios. Hasta acá, el equipo de Smith estuvo haciendo pruebas dentro de su entorno de desarrollo. Ahora, se deberían conducir pruebas dentro de un entorno de aceptación de pruebas, que debían preparar. Esto generó las siguientes tareas:

• Tarea 2: Preparar el entorno de pruebas de aceptación. El equipo de Smith tenía que lograr que todos los ítems de requisitos fueran actualmente demostrables en el sistema para completarlos. Esto significaba que cada ítem de requisitos se debía probar completamente dentro del entorno de aceptación de pruebas.

• Tarea 3: Completar el ítem de requisitos A: “Navegar en línea y fuera de línea.

• Tarea 4: Completar el ítem de requisitos B: “Publicar comentarios (en línea y fuera de línea).

• Tarea 5: Completar el ítem de requisitos C: “Navegar álbumes”.

Este estado nos recuerda la necesidad de trabajar con los interesados para asegurar que ellos están felices con el sistema producido. En nuestra historia, Smith tenía que trabajar con Angela, la representante del cliente, para determinar cuáles ítems de requisitos adicionales se necesitaba implementar. Esto generó la siguiente tarea adicional:

• Tarea 6: Hablar con Angela y acordar con ella los ítems de requisitos, dentro de la iteración, que harán que el sistema sea digno de considerarse operativo.

Fig. 6. Los próximos pasos seleccionados y la manera como los alcanzará el equipo.

El núcleo le ayuda a lograr esto de la manera siguiente: Inclusivo. Los alfas del núcleo sirven como recordatorios

de las diferentes dimensiones del desarrollo de software, ayudando a crear un plan que trate todas las dimensiones de manera balanceada.

Concreto. Las listas de chequeo para cada estado de alfa suministran pistas sobre lo que se necesita hacer en la iteración. Las listas de chequeo mismas ayudan a determinar su progreso, haciendo claro lo que usted tiene que hacer y comparando esto con lo que se supone que usted hace.

V. EL NÚCLEO EN EL MUNDO REAL

Si bien las ideas que aquí se presentan serán nuevas para muchos de ustedes, la academia y la industria las vienen aplicando de forma exitosa en el mundo real. En todos los

casos, ellos usan el núcleo y las prácticas que se desarrollaron en Ivar Jacobson International [1, 10]. Entre los primeros en adoptar la idea del núcleo se cuentan: • MunichRe, la compañía líder en seguros del mundo, donde

una familia de “modelos de colaboración” se ensambló para cubrir el espectro completo del software y el trabajo de aplicación. Cuatro modelos de colaboración (exploratorio, estándar, mantenimiento y soporte) se construyeron en el núcleo mismo desde el mismo conjunto de doce prácticas.

• Fujitsu Services, donde el paquete Apt se construyó sobre una versión previa del núcleo de la ingeniería de software, incluyendo formas de trabajo ágiles y en cascada [1].

• Una de las mayores compañías japonesas de electrónica de consumo, donde los procesos de software se definieron sobre una versión previa del núcleo, ayudando a los


77

equipos a aplicar nuevas prácticas y a gestionar un proveedor de desarrollo externo.

• KPN, donde un proceso basado en el núcleo se adaptó para más de 300 proyectos a lo largo de trece programas como parte de un movimiento hacia el desarrollo iterativo. El núcleo también suministró la base para un nuevo proceso de aseguramiento de la calidad enfocado en los resultados, que se podría aplicar a todos los proyectos sin importar el método o las prácticas que se empleen.

• El mayor departamento de gobierno del Reino Unido, donde un paquete ágil basado en el núcleo se introdujo para habilitar la agilidad disciplinada y el seguimiento del progreso y salud de los proyectos de forma independiente a las prácticas.

El núcleo ya se usa en cursos de ingeniería de software de primero y segundo año en el Instituto Real de Tecnología KTH en Suecia. Después de que los estudiantes de los cursos de primer año dirigieron sus proyectos, se adentraron en los alfas de Semat y compararon los resultados de sus proyectos, bajo la dirección de Anders Sjögren. Los estudiantes tuvieron la oportunidad de familiarizarse con los alfas y evaluarlos para obtener una visión del progreso y salud de los proyectos. En los cursos de segundo año que condujo Mira Kajko-Mattsson, a los estudiantes se les preguntó el uso del núcleo de Semat cuando corrían sus proyectos sin importar el método que siguieran. Como se muestra en la Figura 3, Kajko-Mattsson creó un escenario de desarrollo de software y lo evaluó para cada alfa, sus estados y los ítems de la lista de chequeo de estados. A los estudiantes se les pidió, luego, hacer lo mismo cuando dirigían y evaluaban sus proyectos.

Las experiencias de esos cursos proporcionaron lecciones muy valiosas. Por ejemplo, el núcleo asegura que todos los aspectos esenciales de la ingeniería de software se consideran en un proyecto. Al emparejar los resultados contra los alfas del núcleo, los estudiantes pudieron identificar fácilmente los lados bueno y malo de sus métodos de desarrollo. El núcleo también preparó a los estudiantes para los futuros esfuerzos de desarrollo de software con un mínimo de esfuerzo en enseñanza. Siguiendo los alfas del núcleo, los estudiantes pudieron aprender el alcance total del esfuerzo en ingeniería de software y, así, vieron lo que se requería de ellos en su futuro como profesionales (véase la Figura 7).

Cómo se relaciona el núcleo con lo ágil y otros paradigmas. El núcleo se puede usar con todas las prácticas técnicas y administrativas populares, incluyendo Scrum, Kanban, iteraciones basadas en riesgos, cascada, desarrollo dirigido por casos de uso, desarrollo dirigido por pruebas de aceptación, integración continua y desarrollo dirigido por pruebas. Esto ayudará a los grupos a embarcarse en el desarrollo de productos de software nuevos e innovadores, y aquellos involucrados en mejorar y mantener productos de software establecidos. Esto ayudará, también, a equipos de todos los tamaños, desde equipos individuales hasta programas fuertes de ingeniería de software de más de 1000 personas.

Por ejemplo, el núcleo apoya los valores del Manifiesto Ágil. Con su enfoque en listas de chequeo y resultados y su inherente independencia de las prácticas, el núcleo valora los individuos y las interacciones por encima de los procesos y las herramientas. Con su enfoque en las necesidades de los equipos profesionales de desarrollo de software, el núcleo valora la forma de trabajo y privilegia las responsabilidades del equipo por encima de los métodos.

El núcleo no compite de ninguna manera con los métodos existentes, sean ellos ágiles o de otro tipo. Por el contrario, el núcleo es agnóstico para el método que elija el equipo. Aún si su equipo está usando un método particular, el núcleo aún puede ayudar. Sin importar el método que se use, como Robert Martin señala en su prefacio a La esencia de la ingeniería de software, los proyectos, aún los ágiles, se pueden desordenar y, cuando lo hacen, los equipos necesitan saber más. Ahí es donde yace el verdadero valor del núcleo, pues puede guiar un equipo a las acciones que necesitan realizar para regresar a la senda, para extender su método o para tratar un vacío crítico en su forma de trabajo. Se enfoca en las necesidades del profesional de software y los valores del “uso de los métodos” por encima de “la descripción de las definiciones de los métodos” (como era normal en el pasado).

El núcleo no sólo apoya las mejores prácticas modernas, sino que también reconoce que una gran cantidad de software ya se desarrolló y necesita que lo mantengan. Este software vivirá por décadas y lo tendrán que mantener de manera eficiente. Esto significa que la forma como trabaje este software tendrá que evolucionar a lo largo del software mismo.

Fig. 7. Visualización del enfoque pedagógico cuando se enseña con el núcleo de Semat.


78

Nuevas prácticas se tendrán que introducir de manera que complementen las que ya están en uso. El núcleo proporciona los mecanismos para migrar los métodos legados desde los monolíticos enfoques en cascada hasta los más modernos métodos ágiles y más allá, de forma evolucionaria. Esto le permite cambiar sus métodos legados práctica a práctica, mientras mantiene y mejora la habilidad del equipo para hacer entregas.

Cómo le ayuda el núcleo. El uso del núcleo tiene muchos beneficios para los profesionales de software, ya sean experimentados o novatos, y para los equipos en que trabajan. Por ejemplo, el núcleo ayuda a evaluar el progreso y salud de los esfuerzos de desarrollo de software, evaluar las prácticas actuales y mejorar la forma de trabajo. También, ayuda a mejorar la comunicación, a moverse más fácilmente entre equipos y a adoptar nuevas ideas. El núcleo ayudará a la industria en conjunto, al mejorar la interoperabilidad entre los equipos, los proveedores y las organizaciones de desarrollo.

Al proporcionar un fundamento independiente de las prácticas para la definición de los métodos de software, el núcleo tiene también el poder de transformar completamente la forma en que se definen los métodos y se intercambian las prácticas. Por ejemplo, al permitir a los equipos mezclar y emparejar prácticas de diferentes fuentes para construir y mejorar la forma de trabajo, el núcleo trata dos de los problemas metodológicos clave que enfrenta la industria: • Los equipos no se encuentran ya atrapados en sus

métodos. Ellos pueden mejorar continuamente su forma de trabajo al agregar o remover prácticas cuando la situación lo exija.

• Los metodólogos no necesitan más gastar tiempo en describir los métodos completos. Ellos pueden fácilmente describir sus nuevas ideas de manera concisa y reutilizable.

Finalmente, el núcleo beneficia la academia. El núcleo proporciona la base para la creación de cursos fundamentales de la ingeniería de software, que se pueden luego complementar con cursos adicionales sobre prácticas específicas (ya sea parte del currículum educativo inicial o después durante el desarrollo profesional de los estudiantes). Igualmente importante es la habilidad del núcleo para actuar como un modelo de referencia compartido y habilitar la investigación y experimentación adicional.

REFERENCIAS [1] Azoff, M. Apt Methods and Tools, Fujitsu. Ovum Technology

Report. Reference Code O100032-002 (Jan. 2011). [2] Fujitsu, Ivar Jacobson Internat ional AB, Model Driven

Solutions. Essence—kernel and language for software engineering. Initial submission, 2012, version 1.0.

[3] Jacobson, I. and Meyer, B. Methods need theory. Dr. Dobb’s Journal, (2009).

[4] Jacobson, I., Meyer, B. and Soley, R. Call for action: The SEMAT initiative. Dr. Dobb’s Journal, (2009).

[5] Jacobson, I., Meyer, B. and Soley, R. The SEMAT vision statement, (2009).

[6] Jacobson, I., Pan-Wei Ng, McMahon, P., Spence, I. and Lidman S. The Essence of Software Engineering—Applying the SEMAT Kernel. Addison-Wesley. (Forthcoming in Jan. 2013 but available in a prepublication version on safaribooksonline.com.)

[7] Jacobson, I., Pan-Wei Ng and Spence, I. Enough of process—let’s do practices. Journal of Object Technology 6, 6 (2007), 41-67.

[8] Jacobson, I. and Spence, I. Why we need a theory for software engineering. Dr. Dobb’s Journal, (2009).

[9] Object Management Group (OMG). RFP: A foundation for the Agile creation and enactment of software engineering methods, (2012).

[10] Pan-Wei Ng and Magee, M. Lightweight application lifecycle management using state cards. Agile Journal (Oct. 2010)

Ivar Jacobson, el presidente de Ivar Jacobson International, es uno de los padres de los componentes y de la artuite3ctura de componentes, los casos de uso, el lenguaje unificado de modelado y el proceso unificado racional. Ha contribuido al modelado de negocios moderno y al desarrollo de software orientado a aspectos.

Pan-Wei Ng entrena el desarrollo de sistemas a gran escala que involucran muchos millones de líneas de código y cientos de personas por cada versión, ayudándoles a la transición hacia una forma de trabajo lean y ágil, sin olvidar el mejoramiento de su código y arquitectura y las pruebas por medio de casos de uso y aspectos. Es coautor, con Ivar Jacobson, del libro “Desarrollo de software orientado a

aspectos con casos de uso”.

Paul McMahon es un consultor independiente que se enfoca en el entrenamiento de gerentes de proyectos, líderes de proyectos y profesionales de software en el uso práctico de las técnicas lean y ágiles en entornos restringidos. Ha sido líder de la iniciativa Semat desde sus inicios. Ian Spence es oficial de tecnología en jefe en Ivar Jacobson International y el líder del equipo para el desarrollo del núcleo de Semat. Introdujo cientos de proyectos a las prácticas iterativas y ágiles y también lideró numerosos proyectos exitosos de transformación a gran escala trabajando con organizaciones de más de 5000 personas.

Svante Lidman tiene una amplia experiencia en la construcción de equipos de desarrollo de software en empresas de alto rendimiento. Ha ocupado cargos en Hansoft AB, Ivar Jacobson International, Microsoft, Rational Software y Objectory, entre otras. Desde mediados de 2010, Lidman es el agente de cambio que lidera la más grande transición lean/ágil de todos los tiempos en Escandinavia.

Carlos Mario Zapata se desempeña actualmente como Profesor Asociado del Departamento de Ciencias de la Computación y de la Decisión de la Universidad Nacional de Colombia, Sede Medellín. Es, además, presidente del Comité Ejecutivo del Capítulo Latinoamericano de Semat y también es uno de los traductores oficiales del libro “La Esencia de la

Ingeniería de Software: aplicando el núcleo de Semat”.

Alejandro Hossian. 2013. Modelo de Proceso de Conceptualización de Requisitos. Revista Latinoamericana de Ingeniería de Software, 1(3): 79-101, ISSN 2314-2642

79

Modelo de Proceso de Conceptualización de Requisitos

Alejandro Hossian

Grupo de de Investigación en Sistemas Inteligentes Aplicados a Ingeniería Facultad Regional Neuquén

Universidad Tecnológica Nacional Neuquén, Argentina

[email protected]

Resumen — El proceso de captura de requisitos constituye un proceso con connotaciones sociales relacionadas con diferentes personas (stakeholders), una circunstancia que hace que se presenten ciertos problemas cuando se lleva adelante la conceptualización de requisitos. En este trabajo se propone un Proceso de Conceptualización de Requisitos que se estructura en dos fases: (a) Análisis Orientado a al Problema: cuyo objetivo es comprender el problema dado por el usuario en el dominio en el que este se lleva a cabo, y (b) Análisis de Orientado al Producto: cuyo objetivo es obtener las funcionalidades que el usuario espera del producto de software a desarrollar, teniendo en cuenta la relación de estas con la realidad expresada por el usuario en su discurso. Se proponen seis técnicas que articulan cada una de las tareas que componen las fases de proceso propuesto.

Palabras Clave — Proceso de captura de requisitos, conceptualización de requisitos, proceso de conceptualización de requisitos, análisis orientado a al problema, análisis de orientado al producto, técnicas de modelado.

I. INTRODUCCION En estadios tempranos de la Ingeniería de Requerimientos,

Alford [1], Yeh y Zave [2] y Davis [3] identificaron la necesidad de obtener una representación intermedia de la información obtenida – conceptualización de los requisitos –, facilitando de esta manera una captura adecuada del problema a resolver por parte del profesional de ingeniería de software antes de pasar a la construcción de los modelos conceptuales, habida cuenta de que una correcta construcción de estos modelos es fundamental para el éxito en el desarrollo del proyecto software, mientras que su incorrección puede perjudicar seriamente a las organizaciones implicadas [4].

Asimismo cabe señalar, que la escasa existencia de trabajos referidos a la elaboración de representaciones intermedias de los caudales de información obtenidos a lo largo de la actividad de educción, tendientes a una búsqueda de reducción de la complejidad de la realidad y su problemática expresada por el cliente y/o usuario en su discurso, agravan aún más este problema.

En este sentido y en lo que se refiere a la gestión de requisitos en el campo de los sistemas de información, se pueden citar algunos principios fundamentales de estructuración de la información – “Partición, Abstracción y Proyección” –, los cuáles proporcionan una estructura de conocimiento a fin de contribuir a una visión simplificada de la realidad y su problemática [5]. Los elementos que suelen

utilizarse para este análisis de problemas son los objetos, las funciones y los estados, pudiendo éstos describirse en múltiples niveles de detalle. Dado que hay tantas relaciones que pueden existir entre todos los elementos, se hace necesario disponer de una estructura de conocimiento (colección estructurada de conceptos y sus interrelaciones) que permita la captura estas relaciones.

A partir de la partición, es posible capturar la relación estructural “agregación/parte de” entre objetos, funciones o estados en el dominio del problema. A partir de la abstracción, es posible capturar las relaciones estructurales “general/específico” o “ejemplo de” entre objetos, funciones o estados en el dominio del problema. A partir de la proyección, es posible capturar la relación estructural “visión de” entre objetos, funciones o estados en el dominio del problema.

Si bien estos principios ofrecen su aporte a los efectos de precisar un mejor entendimiento de sus requisitos, son de carácter muy general y de poco nivel de detalle.

De igual manera y en lo que respecta a la gestión del conocimiento dentro del campo de los sistemas basados en conocimientos (SBC), se puede citar una técnica de representación intermedia como el “Análisis de Protocolos” [6]. Este método es de gran utilidad a los fines de obtener heurísticas que el experto utiliza en la solución de problemas, pero que le resulta difícil explicar [7].

En síntesis, esta técnica consiste en grabar en un protocolo el comportamiento del experto mientras este trabaja en la solución del problema. Luego ese protocolo se transcribe y se analiza para, finalmente, interpretarlo y convertirlo en un conjunto de razonamientos que convergen a la solución del problema. La reconstrucción de esta solución permite modelar los conocimientos del experto.

La forma más clásica de representar este conocimiento consiste en codificar el mismo en la forma de reglas de producción, las cuáles presentan una parte izquierda [PI] y una parte derecha [PD] (Si..[PI].. Entonces..[PD]..).

Cabe destacar, que si bien esta técnica permite poner en evidencia carencias y fallos en el documento de educción de conocimientos, también es cierto que determinados procesos no son reportados por el experto y que no todos los conocimientos son fáciles de representar en forma de reglas [8].

Se ha propuesto como objetivo de este trabajo definir un marco metodológico que incorpore una actividad de conceptualización tendiente a mejorar la comprensión y captura de requisitos de usuario en la fase de análisis de la Ingeniería de Requerimientos del Software. Esta actividad de conceptualización buscará plasmar en un esquema de


80

representación integrado la realidad descripta por el cliente y/o usuario en su universo de discurso, así como también la problemática embebida en ella que se intenta resolver mediante una solución software.

La investigación se enfoca a plantear un proceso de conceptualización que funcione a modo de puente vinculando las actividades propias de la educción y el modelado de requisitos en la Ingeniería del Software. Con base en problemas de comunicación e interpretación entre clientes y/o usuarios y desarrolladores, surge la necesidad de una representación intermedia que facilite la consistencia del proceso de convergencia de los requisitos planteados por el usuario hacia los respectivos modelos conceptuales.

La investigación ha buscado formular contribuciones sobre: [a] actividades de conceptualización de requisitos de usuario capaces de proporcionar un mecanismo de análisis del discurso que permita al desarrollador relevar aquellos aspectos significativos de la realidad y su problemática, [b] mecanismos de derivación de esquemas de representación que faciliten la comprensión del problema de usuario y su asociación con aspectos de la solución software a implementar, y [c] estrategias que fortalezcan los canales de comunicación entre clientes, usuarios y desarrolladores a los efectos de optimizar la validez de las representaciones elaboradas para modelar la realidad y su problemática en función de su grado de aproximación al entorno del usuario.

Se presenta la Descripción del Problema (Sección II) en la que se señala la importancia que tiene la actividad de requisitos para la comprensión del problema de investigación, se caracterizan las actividades de educción de requisitos y de modelado conceptual, así como la forma en que se vinculan entre ellas para la construcción de los modelos conceptuales, se identifica el problema de investigación a partir de las dificultades provenientes del proceso de educción y como estas impactan en la construcción de los modelos conceptuales, se caracteriza el problema abierto y se concluye con un sumario de investigación.

Se propone una solución (Sección III) basada en: un modelo de proceso de conceptualización de Requisitos, del cual se abordan las cuestiones generales de mayor relevancia, se presenta la propuesta de dicho modelo y se explican en detalle las dos fases que componen el modelo (fase de Análisis Orientado al Problema y fase de Análisis Orientado al Producto), junto con las tareas que deben realizarse para llevar a cabo estas fases y los productos que se obtienen con la implementación de las mencionadas tareas. Se introducen las técnicas asociadas a las tareas del modelo de proceso. En primer término se presentan las técnicas utilizadas en la fase de Análisis Orientado al Problema como: la Técnica de Segmentación del Discurso de Usuario (TS – DU), las Técnicas Cognitivas de Identificación de Conocimientos Factuales, Procedurales, Contextuales y de Asociación (TCI - CFPCA) y la Técnica de Construcción del Diagrama de Espacio Problema de Escenarios de Usuario (TCD – EPEU). En segundo término se presentan las técnicas utilizadas en la fase de Análisis Orientado al Producto como: la Técnica de Construcción del Diagrama de Escenarios de Usuario (TCD – EU), la Técnica de Refinamiento del Diagrama de Escenarios de Usuario (TRD – EU) y la Técnica de Construcción del Diagrama del Mapa Unificado de Escenarios de Usuario (TCD – MUEU).

Finalmente se formulan conclusiones (Sección IV) se presentan las aportaciones y se destacan las futuras líneas de investigación que se consideran de interés en base al problema abierto que se presenta en este trabajo.

II. DESCRIPCIÓN DEL PROBLEMA En esta sección se presenta la importancia que tiene la

actividad de requisitos para la comprensión del problema de investigación (sección II.A), se caracterizan las actividades de educción de requisitos y de modelado conceptual, así como la forma en que se vinculan entre ellas para la construcción de los modelos conceptuales (sección II.B), se identifica el problema de investigación a partir de las dificultades provenientes del proceso de educción y como estas impactan en la construcción de los modelos conceptuales (sección II.C), se caracteriza el problema abierto (sección II.D) y se concluye con un sumario de investigación (sección II.E).

A. La Actividad de Requisitos en la Comprensión del Problema En el proceso de desarrollo de software se pueden

distinguir diferentes actividades que han de llevarse a cabo. De acuerdo al enfoque tradicional, el ciclo de vida del producto software supone un modelo en el cuál dicho producto evoluciona a través de una secuencia ordenada de transiciones de una fase a la siguiente conforme a una aproximación lineal o secuencial. En este sentido, el ciclo de vida del producto software se ha estructurado en las siguientes fases: Requisitos, Diseño, Implementación, Pruebas y Mantenimiento [3].

De las actividades citadas, cabe destacar que la actividad de Requisitos posee especial importancia en la construcción de un producto software, habida cuenta de que su principal objetivo consiste en identificar, entender y especificar las necesidades del usuario [9].

No obstante la poca uniformidad que se encuentra en la terminología empleada en las diferentes actividades relacionadas con los Requisitos [10], en el presente trabajo se utilizará la terminología propuesta por Davis [3], En este sentido, se entiende que la fase de Requisitos está compuesta por dos actividades que, aunque conceptualmente se establecen como diferentes, ambas se encuentran relacionadas: 1. Análisis del Problema cuya finalidad consiste en entender

de manera precisa el problema que se ha de resolver y caracterizar la solución que este tiene.

2. Especificación de Requisitos cuya finalidad es crear un documento que constituye la especificación de requisitos del software, y en el cuál se describe con exactitud lo que el usuario espera del futuro producto software a desarrollar. En el contexto de este lineamiento, el presente trabajo de

investigación se enmarca dentro del proceso de “Análisis del Problema”. Esta actividad resulta ser de vital importancia dentro del proceso de desarrollo, ya que como se indicara anteriormente, tiene como objetivo entender la necesidad del usuario y como ésta necesidad debe ser resuelta o satisfecha. Como consecuencia de este proceso, los desarrolladores se encontrarán en condiciones de abordar la construcción del sistema [11].

A modo de conclusión en lo que respecta al encuadre del problema de investigación dentro de la tarea de Análisis, conviene citar las palabras de Davis [3] en este sentido:


81

“El Análisis es la actividad que incluye aprender acerca del problema a resolver […..], entender las necesidades de los potenciales usuarios, tratar de identificar quien es realmente el usuario y entender todas las restricciones a la solución”

En el marco de esta cita, dos términos resultan ser de suma importancia: aprender y entender. El análisis constituye una actividad que pretende proporcionar al Ingeniero de Requisitos (IR) el conocimiento necesario para solucionar los problemas que surgen en un dominio determinado y que, habitualmente, le es ajeno.

En otras palabras, el conocimiento a adquirir es extraño para el IR, y sólo puede obtenerse mediante un aprendizaje in situ, es decir, a través de una inmersión en el dominio del problema. Dominio éste que pertenece a los usuarios, quienes son los encargados de vivenciar el problema al cual el Ingeniero de Requisitos (IR) debe darle una solución.

A partir del análisis es posible “identificar los conceptos relevantes del problema a resolver”, como así también “entender las restricciones que debe cumplir cualquier solución software que le sea aplicable”. En función del conocimiento adquirido en esta fase, el IR estará en condiciones de derivar una solución para el problema planteado por el usuario.

B. Educción de Requisitos y Modelado Conceptual Conforme a la definición de Davis expresada en sección

anterior, acerca del significado de la tarea de Análisis, caben distinguir, dentro del proceso por medio del cual se lleva a cabo esta tarea, dos subprocesos que resultan ser sustanciales para llevar a cabo con éxito la construcción de un producto software: “Educción de Requisitos” y “Modelado Conceptual”. A continuación se proporciona una breve caracterización de estos subprocesos: Educción de Requisitos: este proceso tiene como objetivo adquirir el conocimiento del dominio de la organización usuario, de manera tal de que sea posible identificar los conceptos, relaciones y funciones más relevantes. Como consecuencia del desarrollo de este proceso se obtiene lo que se denomina Universo de Discurso, al cual se lo puede definir como aquella parte del mundo cuya información va a ser manejada por el sistema software a construir [12]. Modelado Conceptual: este proceso tiene como objetivo la construcción de modelos que describen parte del mundo real de una forma no ambigua y no redundante [9], y que representan el problema y su solución [13]. Habida cuenta de que estos modelos permiten clasificar la información recolectada en el proceso de Educción, y por consiguiente, comprender mejor el problema en cuestión, a estos modelos se los denomina Modelos Conceptuales.

En virtud de lo expuesto, se estima conveniente hacer referencia a dos citas importantes del significado de los modelos conceptuales en relación con el universo de discurso: la primera señala que los modelos conceptuales constituyen una representación del universo de discurso en el cual tiene lugar el problema [14]; la segunda, por su parte, define a los modelos conceptuales como una descripción del universo de discurso haciendo uso del lenguaje y la forma de pensar de los expertos del dominio y de los usuarios [13]. La figura 1 ilustra el proceso de construcción de los modelos conceptuales a partir de la actividad de educción de requisitos.

C. Identificación del Problema de Investigación En la sección anterior, han sido caracterizados cada uno de

los procesos de Educción de Requisitos y Modelado Conceptual, así como también la vinculación que se establece entre ambos a partir de los productos que de ellos se generan (Universo de Discurso y Modelos Conceptuales).

A los efectos de identificar el problema que se pretende resolver en el presente artículo, se debe empezar por identificar los inconvenientes que presenta el primer eslabón del proceso macro que se ilustra en la figura 1; es decir el proceso de educción de requisitos. El proceso de educción, cuyo objetivo central consiste en dar a luz a los requisitos, no solo constituye un proceso de carácter técnico para construir un determinado sistema, sino también un proceso con importantes connotaciones de tipo social que involucra a distintas personas (stakeholders); circunstancia ésta que origina que se presenten ciertos problemas a la hora de la realización de dicho proceso de educción [15]. Asimismo, con respecto a los stakeholders cabe aclarar que dicho término se utiliza en referencia a cualquier persona o grupo que se verá afectado por el sistema en forma directa o indirecta; entre los mismos se pueden citar a usuarios finales que interactúan con el sistema, así como también a demás personas que pueden verse afectadas por la puesta en marcha del mismo (profesionales que proporcionan mantenimiento a otros sistemas relacionados, expertos en el dominio del sistema y gerentes de negocio, entre otros).

Fig. 1. Relación entre los procesos de Educción de Requisitos y Modelado Conceptual

Los problemas citados anteriormente pueden ser enfocados en función de los inconvenientes a los que se ven enfrentados los ingenieros de requisitos a la hora de relevar y comprender los requisitos que manifiestan los diferentes stakeholders [16], [17]. Estos problemas pueden ser sintetizados de la siguiente manera: En la mayoría de los casos los stakeholders desconocen lo que desean obtener del sistema informático, resultándoles difícil expresar cual es el problema que pretenden que sea resuelto y, en consecuencia, lo que deseen que haga el sistema. Por lo general, los stakeholders manifiestan sus requisitos con su propio lenguaje natural y con un conocimiento implícito de su propia labor. Por consiguiente, los ingenieros de requisitos, que en la generalidad de los casos carecen de la


82

experiencia y el conocimiento en el dominio del usuario, deben comprender en forma correcta estos requisitos. Muy posiblemente, los diferentes stakeholders involucrados en la construcción del sistema posean diferentes requisitos, los cuales pueden ser expresados de varias formas distintas. Por consiguiente, los ingenieros de requisitos deben tener en consideración todas las posibles fuentes potenciales de requisitos y hallar coincidencias y conflictos. También es posible que factores de carácter político tengan cierta influencia en los requisitos del sistema. A modo de ejemplo, un director de un cierto departamento puede solicitar requisitos del sistema a los efectos de tener mayor influencia en el seno de la organización.

Continuando en esta línea, por las razones expuestas se puede afirmar que el proceso de educción es difícil de llevar a cabo. En este sentido, conforme a Christel [18] y con idea de complementar los problemas expresados anteriormente, se estima conveniente añadir las siguientes consideraciones: Mucha información importante para la construcción del producto software no llega a ser verbalizada, quedando así plasmados importantes huecos en la información capturada. En la mayoría de los casos el proceso de educción se lleva a cabo en forma pasiva en relación con el cliente y/o usuario, cuando en realidad debe ser afrontado en forma cooperativa.

Ahora bien, en virtud del conjunto de limitaciones a las que hacen mención Sommerville y Christel, propias del proceso de educción, es que surge la necesidad de explorar y analizar aquellas particularidades que son inherentes a este proceso y que, en tal sentido, contribuyen a caracterizarla.

Caracterizada la tarea de educción, se infiere que el eje de la misma se focaliza en la comunicación que se establece entre el usuario y el IR. Este, cuando desarrolla su trabajo de educción, debe capturar y modelar una realidad que enmarca una problemática, y cuya solución, debe ser abordada a través de un producto software. Siendo esta realidad un elemento intangible y, por lo general también compleja, es que también resulta difícil su captura.

Ahora bien, la captura de esta realidad junto con su problemática quedan plasmadas en el discurso del usuario, a partir del cuál el IR debe confeccionar el universo de ese discurso (“situaciones, hechos, objetos, etc., en los que se focaliza el estudio durante la educción y que, en consecuencia, resultan ser sustanciales a la hora de abordar el desarrollo del futuro sistema software [12]”), a los efectos de poder alcanzar así los modelos conceptuales ya en la fase de análisis de requisitos.

Estos inconvenientes, propios del proceso de educción, hacen que se dificulte la elaboración del universo de discurso por parte del IR, así como también la construcción de modelos conceptuales adecuados [19], [20]; es decir que estos problemas, que comienzan a manifestarse en el proceso de educción de requisitos y a partir de la comunicación entre el usuario y el ingeniero, seguramente se propagarán en la actividad de construcción de los modelos conceptuales. Estos inconvenientes confluirán, de manera inexorable, hacia la obtención de un software de baja calidad [21].

D. Problema Abierto El problema abierto que se identifica en la presente sección,

consiste en la necesidad de estructurar y categorizar la masa de

información proveniente del proceso de educción a los efectos de facilitar la comprensión del problema manifestado por el usuario [3], [10], [22]. En otros términos, conceptualizar los requisitos.

La insuficiencia en el tratamiento de la complejidad contenida en el discurso del usuario en la literatura correspondiente, y la necesidad de cubrirla, ha sido resaltada por diversos autores: [23], [24], [12], [25], [26], [10], [27], [15], [28], [29] entre otros. Estos autores mencionan las dificultades para la construcción de los modelos conceptuales a partir de la información recogida en el proceso de educción y plasmada en el discurso de usuario. Asimismo cabe resaltar, que dichas dificultades dotan al proceso de Análisis de un grado tal de inmadurez que hace que sea difícil llevar a cabo en forma efectiva esta actividad, al mismo tiempo que dificulta la adopción de este enfoque en las organizaciones.

Por consiguiente y en virtud de todo lo expuesto, el problema abierto que se aborda en este artículo, consiste en la existencia de una “brecha conceptual”, lo que se denomina un “gap” [23], [3], [30] en la transición de un proceso (Educción de Requisitos) a otro proceso (Modelado Conceptual). Este concepto se ilustra en la figura 2:

Fig. 2. Representación del “gap” entre los procesos de Educción de Requisitos y Modelado Conceptual

A causa de lo expuesto, se manifiesta la necesidad de conceptualizar los requisitos manifestados por el usuario en su discurso antes de pasar a la construcción de los modelos conceptuales, con el objeto de reducir la complejidad mencionada y favorecer la comprensión del problema planteado por el usuario, contribuyendo así a la obtención de Modelos Conceptuales de mayor calidad [19], [4].

Asimismo, es importante señalar la muy escasa cantidad de trabajos existentes en la literatura científica sobre la elaboración de representaciones intermedias de los caudales de información obtenidos por el IR en el proceso de educción. En otras palabras, trabajos que estén orientados a la búsqueda de reducción de la complejidad de la realidad y su problemática expresada por el usuario en su discurso.

El Modelo de Proceso de Conceptualización de Requisitos que se presenta en la Sección III, correspondiente a la Solución del problema identificado, pretende realizar un aporte en este sentido. Con el soporte conceptual de tópicos pertenecientes a otras disciplinas, tales como el Análisis de Protocolo proveniente del campo de la Ingeniería del Conocimiento; y las Técnicas Cognitivas propias del campo de las Teoría Educativas, se analiza en detalle el Discurso del Usuario a los fines de estructurar y caracterizar el cuerpo de información presente en el mismo.

E. Sumario de Investigación De lo expuesto precedentemente surgen las siguientes

preguntas de investigación: Pregunta 1: ¿Se puede plantear distinciones en el discurso del

usuario que permitan diferenciar subdominios de análisis que minimicen la brecha conceptual entre


83

la educción de requisitos y el modelado conceptual? En caso afirmativo: ¿Cuales?

Pregunta 2: ¿De existir tales distinciones, se puede plantear un proceso que permita transformar el discurso del usuario en un conjunto de formalismos que lo sistematicen y lo documenten? De ser posible: ¿Cuáles son las fases de dicho proceso, las tareas vinculadas a cada fase y las técnicas asociadas a cada tarea?

Se proponen soluciones a los interrogantes planteados en la próxima sección.

III. SOLUCIÓN En esta sección se presenta: un Modelo de proceso de

conceptualización de Requisitos, del cual se abordan las cuestiones generales de mayor relevancia, se presenta la propuesta de dicho modelo, la que se describe a partir de su estructura general, los escenarios de usuario, y el enfoque cognitivista en la construcción de los mismos. Luego se explican en detalle las dos fases que componen el modelo (fase de Análisis Orientado al Problema y fase de Análisis Orientado al Producto), junto con las tareas que deben realizarse para llevar a cabo estas fases y los productos que se obtienen con la implementación de las mencionadas tareas. Se introducen las técnicas asociadas a las tareas del modelo de proceso. En primer término se presentan las técnicas utilizadas en la fase de Análisis Orientado al Problema como: la Técnica de Segmentación del Discurso de Usuario (TS – DU), las Técnicas Cognitivas de Identificación de Conocimientos Factuales, Procedurales, Contextuales y de Asociación (TCI - CFPCA) y la Técnica de Construcción del Diagrama de Espacio Problema de Escenarios de Usuario (TCD – EPEU). En segundo término se presentan las técnicas utilizadas en la fase de Análisis Orientado al Producto como: la Técnica de Construcción del Diagrama de Escenarios de Usuario (TCD – EU), la Técnica de Refinamiento del Diagrama de Escenarios de Usuario (TRD – EU) y la Técnica de Construcción del Diagrama del Mapa Unificado de Escenarios de Usuario Refinados (TCD – MUEUR).

A. Modelo de proceso de conceptualización de requisitos En esta sección se presenta una propuesta de modelo de

proceso de conceptualización de Requisitos estructurada en tres partes: generalidades, propuesta del modelo de proceso de conceptualización de requisitos y fases, tareas y productos.

1) Generalización En función del análisis realizado en la sección

correspondiente a la Descripción del Problema, se considera de interés citar nuevamente el problema abierto que se aborda en este artículo, recordando que el mismo se focaliza en la “brecha conceptual” o “gap” presente en la transición del proceso de educción de requisitos de usuario al proceso de modelado conceptual. Esta brecha conceptual dificulta la comprensión del problema manifestado por el usuario y, en consecuencia, constituye un escollo importante para la comprensión del problema manifestado por el usuario por parte del Ingeniero de Requisitos (de ahora en más IR) [23], [3], [30]. La figura 2 ilustra este concepto.

La solución que se propone en este trabajo consiste en la inserción de una actividad de “Conceptualización de Requisitos”, la cuál tiene como finalidad actuar a modo de

puente o enlace (“link”) entre las actividades de educción de requisitos y modelado conceptual, facilitando de esta manera la comprensión del problema manifestado por el usuario y, en consecuencia, la obtención de Modelos Conceptuales de mayor calidad [4], [19], [15], [28], [29]. La ilustración de esta idea se puede visualizar en la figura 3 y en la cual se puede observar la ausencia del “gap”, el cual se sustituye por la actividad de “Conceptualización de Requisitos”.

Fig. 3 Inserción de la actividad de “Conceptualización de Requisitos” entre las

actividades de Educción de Requisitos y Modelado Conceptual

La idea de “conceptualizar” los requisitos de usuario por medio la actividad de “Conceptualización de Requisitos” antes de pasar a la confección de los modelos conceptuales, intenta cubrir esta “brecha conceptual” o “gap” [23], [3], [30] existente en la transición de un proceso (Educción de Requisitos) a otro proceso (Modelado Conceptual), actuando a modo de puente o enlace (“link”) entre dichos procesos. De este modo, se busca establecer una adecuada conexión entre los mismos a partir de la inserción de la actividad de Conceptualización de Requisitos. Este artículo propone el Proceso de Conceptualización de Requisitos como instrumentación de dicha actividad.

A partir de la implementación de esta actividad de conceptualización de requisitos es posible la consecución de un conjunto de representaciones gráficas denominadas Representaciones Intermedias de los Requisitos de Usuario (RIRU), a partir de las cuales es posible “caracterizar” la información contenida en el discurso del usuario (por lo general en formato de “lenguaje natural” y es así como se la supone presentada en este trabajo), a los efectos de que sea mas sencillo su procesamiento para la construcción de los modelos conceptuales. Estas representaciones intermedias estarán conformadas, fundamentalmente, por un conjunto de representaciones gráficas: los Escenarios de Usuario Refinados (EUR), los cuales enlazados en forma adecuada a través del Mapa Unificado de Escenarios de Usuario Refinados MUEUR) permiten caracterizar el discurso del usuario en una forma alternativa al lenguaje natural clásico.

2) Propuesta del Modelo de Proceso de Conceptualización de Requisitos

En esta sección se describe la estructura general del proceso de conceptualización de requisitos y su modo de funcionamiento, un análisis de los escenarios de usuario como soporte fundamental del proceso de conceptualización de requisitos y un abordaje del enfoque cognitivista para la construcción de estos escenarios de usuario.

a) Estructura General del Proceso de Conceptualización de Requisitos

La actividad de conceptualización de requisitos se lleva a cabo por medio de un proceso dual que se denomina Proceso de Conceptualización de Requisitos, el cual está estructurado en dos fases, a saber: i. Una primera fase de Análisis Orientado al Problema,

cuyo objetivo se focaliza en la comprensión del problema


84

planteado por el usuario en el dominio en el cual este tiene lugar.

ii. Una segunda fase de Análisis Orientado al Producto, cuyo objetivo consiste en la obtención de las funcionalidades que el usuario pretende obtener del producto software a desarrollar, teniendo en cuenta la vinculación de estas funcionalidades con la realidad manifestada por el usuario en su discurso.

Este proceso toma como punto de partida el Discurso de Usuario en Lenguaje Natural (DULN) y proporciona como salida el conjunto de Representaciones Intermedias de los Requisitos de Usuario (RIRU). La figura 4 ilustra este concepto:

Fig. 4 Estructura General del “Proceso de Conceptualización de Requisitos”

con sus dos fases y los elementos de entrada y salida

El soporte principal del Proceso de Conceptualización de Requisitos está compuesto por sus dos Fases, donde cada una de ellas está conformada por tres Tareas, y un conjunto de productos que pueden actuar como elemento de entrada y/o de salida de una determinada tarea. En otros términos, cada tarea

precisa de ciertos productos para su realización, los cuales se procesan para proporcionar los correspondientes productos de salida. En la figura 4 se ilustra el modo de funcionamiento del proceso de conceptualización en base a la interdependencia conceptual existente entre la Fases, las Tareas y los Productos. En tal sentido, dicha figura muestra el flujo que siguen estos productos abasteciendo a determinadas tareas para su realización y/o ser procesados para constituirse en salida de las mismas.

En figura 5 se puede observar que en la primera fase de Análisis Orientado al Problema la primera tarea que se lleva a cabo es la de Segmentación del Discurso de Usuario (SDU), la cual necesita del Discurso de Usuario (DU) como producto de entrada y proporciona como producto de salida los correspondientes Segmentos de Texto (ST). Estos ST constituyen a su vez el producto de entrada para la realización de la tarea de Análisis Cognitivo de los Segmentos de Texto (ACST), la cual arroja como producto de salida los Tipos de Conocimiento (TC) embebidos en estos segmentos. A su vez, estos Tipos de Conocimiento (TC) junto con los Segmentos de Texto (ST) conforman el conjunto de productos de entrada necesarios para llevar a cabo la tarea de Construcción del Espacio Problema en Escenarios de Usuario (CEPEU), a partir de la cual se obtiene como producto de salida los correspondientes Espacio Problema en Escenarios de Usuario (EPEU).

Luego se comienza con el desarrollo de la fase de Análisis Orientado al Producto donde la primera tarea que se realiza es la de Construcción de Escenarios de Usuario (CEU), la cual necesita como productos de entrada a los Segmentos de Texto con Tipo de Conocimiento de Asociación (STTCA) y los Espacio Problema en Escenarios de Usuario (EPEU), los cuales se procesan en el desarrollo de esta tarea y se obtienen los respectivos Escenarios de Usuario (EU).

Fig. 5 Interdependencia conceptual entre las Fases, Tareas y Productos


85

Estos Escenarios de Usuario (EU) junto con el Discurso de Usuario (DU) constituyen los productos de entrada para la realización de la tarea de Refinamiento de Escenarios de Usuario (REU), la cual proporciona como producto de salida los correspondientes Escenarios de Usuario Refinados (EUR). Finalmente, con los Escenarios de Usuario Refinados (EUR) y los Segmentos de Texto Refinados (STR) como productos de entrada, se realiza la tarea de Construcción del Mapa Unificado de Escenarios de Usuario Refinados (CMUEUR) y se obtiene el Mapa Unificado de Escenarios de Usuario Refinados (MUEUR).

b) Escenario de Usuario Esta sección se focaliza en el análisis de escenarios de

usuario, cuyo concepto se presenta en la sección “i”, luego se presentan aquellas propiedades y elementos propios de un escenario de usuario que contribuyen a su caracterización (sección ii), y finalmente se proporciona un ejemplo sencillo correspondiente a un escenario de usuario (sección iii).

El concepto de Escenario de Usuario (EU) junto con sus elementos y propiedades, constituyen el soporte conceptual sobre el cual se basa la presente propuesta del proceso de conceptualización de requisitos.

i. Concepto de Escenario de Usuario En el contexto del presente artículo, es sustancial precisar

el concepto de Escenario de Usuario (EU) a los efectos de su caracterización y su posterior construcción. En este sentido, se proporciona la siguiente definición:

“Descripción textual o gráfica de una situación determinada que tiene lugar en el ámbito de aplicación del producto software a desarrollar y que guarda una cierta relación con la realidad (y el problema a resolver) manifestada por el usuario en su discurso”

En base a esta definición, la cual está inspirada en diversos autores que han abordado con anterioridad el estudio de esta técnica como por ejemplo [31], [32], [33], [34], [35], [36], es posible establecer pautas conceptuales que permitan una adecuada caracterización del concepto de escenario de usuario, facilitando de esta manera su proceso de construcción. La correcta confección de los escenarios de usuario le permite al IR elaborar otras herramientas de representación gráfica de los requisitos de usuario, tal como el Mapa de Escenarios de Usuario (MEU), que contribuyen a mejorar la comprensión del problema manifestado por el usuario.

ii. Caracterización de un Escenario de Usuario A continuación se presentan las propiedades y los elementos

de un escenario de usuario que contribuyen a su caracterización: El escenario de usuario constituye una representación, tal como un cuadro o una escena, cuya descripción intenta capturar una situación determinada de la realidad descripta por el usuario en su discurso [37]. El escenario de usuario, como elemento descriptivo de la realidad, tiene lugar en un contexto concreto y bien definido, lo cual contribuye a que todos los elementos que conforman el escenario adquieran verdadero sentido e identidad [38]. En el presente trabajo, el escenario de usuario se representa por medio de un esquema bidimensional (en forma de gráfico rectangular), el cual se caracteriza por contener los siguientes elementos:

1. El escenario de usuario contiene Actores (conceptos, objetos o personas del mundo real), cuya presencia y actividad son relevantes para la situación de la realidad capturada por el escenario.

2. Dentro de un escenario de usuario los actores poseen una identidad definida caracterizada por Atributos que asumen valores determinados, los cuales determinan en que estado se encuentra un actor en ese escenario de usuario (instanciación del actor).

3. Dentro de un escenario de usuario los actores pueden vincularse entre sí mediante Relaciones, las cuales ponen de manifiesto la forma en que los actores se vinculan en el marco de la situación de la realidad contenida en el escenario.

4. Dentro de un escenario de usuario los actores pueden llevar a cabo Acciones, a través de las cuales es posible determinar como el comportamiento de un actor en el escenario impacta sobre el mismo modificando su propio estado, es decir alterando el valor de alguno de los atributos del propio actor que las realiza.

Asimismo, estas acciones pueden estar caracterizadas por medio de atributos que contribuyan a describir aspectos particulares de las mismas; así como también, es posible que sea menester que deban cumplirse ciertas condiciones para que estas acciones puedan llevarse a cabo.

5. Dentro de un escenario de usuario los actores pueden llevar a cabo Interacciones, a través de las cuales es posible determinar como el comportamiento de un actor en el escenario impacta sobre otro actor modificando el estado de este último; es decir, alterando el valor de alguno de sus atributos y pudiendo ser que también se produzca un condicionamiento en el comportamiento del actor o se active en este una determinada conducta como consecuencia de la interacción. Asimismo, estas interacciones pueden estar caracterizadas por medio de atributos que contribuyan a describir aspectos particulares de las mismas; así como también, es posible que sea menester que deban cumplirse ciertas condiciones para que estas interacciones puedan llevarse a cabo.

6. A los efectos de que el formalismo de escenarios refleje la relación que debe existir entre la realidad manifestada por el usuario en su discurso y la solución software que debe resolver el problema (embebido en esta realidad); el escenario de usuario debe contener las Funcionalidades requeridas por el usuario vinculadas con los elementos de la realidad (actores, atributos, acciones, interacciones) sobre los cuales se aplican estas funcionalidades.

En base a la caracterización realizada, se asume que la estructura de un escenario de usuario está conformada por dos bloques interconectados, identificados como Espacio – Problema y Espacio – Producto; siendo que el primer bloque contiene aquellos elementos descriptivos de la realidad manifestada por el usuario en su discurso (actores, atributos, valores de atributos, relaciones, acciones e interacciones), mientras que el segundo bloque contiene las distintas funcionalidades (calcular montos, almacenar datos


86

relevantes, entre otros) que el producto software debe realizar sobre la realidad modelada en el espacio – problema, y conforme a los requerimientos de usuario. La conexión de ambos bloques en el escenario de usuario, se representa por medio de una flecha dirigida desde el elemento del espacio – problema sobre el cual se aplica una determinada funcionalidad, hasta la correspondiente funcionalidad.

A modo de síntesis, se puede inferir que la realidad representada en el escenario de usuario a través de todos los elementos que lo conforman contextualiza el problema que se presenta, y contiene toda aquella información relevante para el entendimiento de la realidad y el problema manifestado por el usuario.

A continuación, se ilustra en figura 6 el esquema gráfico general que presenta un escenario de usuario con todos los elementos descriptos. En este sentido, se entiende que para un determinado escenario de usuario no todos los elementos mencionados en la caracterización deben estar presentes; podría ser por caso, que no se registren acciones de los actores que originen modificación de su propio estado cambiando algún valor de alguno de sus atributos o que la interacción entre dos actores no posea atributos. En la parte inferior del esquema de representación de figura 6 se coloca una etiqueta de denominación del escenario de usuario con una numeración correlativa en número romano (EU – I).

Tanto en las acciones como en las interacciones, se representa en el recuadro el atributo correspondiente junto con su valor, además de alguna condición que pudiera tener que cumplirse para que la acción o interacción tenga lugar. Por ejemplo, si fuese el caso de una interacción como Comunicar, en el recuadro se tendría Velocidad – Rápida (atributo con su valor) y Radio Encendida (condición para que se realice la interacción).

Fig. 6 Representación gráfica de un “Escenario de Usuario” con sus elementos

constitutivos

iii. Ejemplo de Escenario de Usuario A los efectos de esclarecer la caracterización realizada en

el apartado anterior, se analiza el siguiente caso correspondiente a un sistema de gestión de mantenimiento de

aeronaves, asumiendo que los elementos que conforman el escenario de usuario ya fueron obtenidos a partir del análisis del discurso de usuario.

Se supone la siguiente caracterización del escenario que se analiza:

El presente escenario captura una situación que representa una porción o segmento de un discurso de usuario, quien podría estar representado por el Jefe de Mantenimiento de Aeronaves, que tiene lugar en un determinado contexto (sector de mantenimiento de un aeropuerto) y que muestra como es el mecanismo de abastecimiento de combustible de una aeronave.

El proceso de construcción del escenario de usuario a partir del análisis de su discurso será explicado posteriormente en esta sección como parte de la metodología que se propone. No obstante, y supuesto realizado este análisis, se asume que a partir del mismo la idea central del segmento de discurso de usuario que se refiere al proceso de abastecimiento de una aeronave en el sector de mantenimiento de un aeropuerto, refleja la siguiente realidad precisada por el usuario y recogida por el IR:

“La aeronave debe poseer una identificación, conocerse su ubicación, si tiene realizado el mantenimiento mecánico y si sus motores están encendidos; asimismo, dado que hay más de una torre de control que controla el movimiento de los aviones, es preciso saber cuál de ellas (cada una posee un número que la identifica) es la que autoriza el abastecimiento. Los demás detalles de esta parte del discurso de usuario, especifican relaciones entre los actores identificados, acciones, interacciones con sus atributos y condiciones. Asimismo, también se relevaron funcionalidades que debe llevar a cabo la aplicación software; tales como llevar un registro de los autorizaciones de abastecimiento que han sido aceptadas por la torre de control en un día determinado y la cantidad total de los mantenimientos mecánicos que han sido realizados en todas las aeronaves que operaron en el sector de mantenimiento en ese mismo día”

En tal sentido, a continuación se detallan los diferentes elementos que conforman el correspondiente escenario de usuario junto con las funcionalidades que se aplican sobre estos:

1. Actores relevantes para la situación de la realidad capturada por el escenario:

• Aeronave • Torre de Control

2. Atributos relevantes de cada uno de estos actores para el desarrollo de su actuación en el escenario y posibles valores que pueden tomar estos atributos, determinando así el estado en que se encuentran cada uno de estos actores en el escenario, es decir, su instanciación:

• Atributos del actor Aeronave: Identificación: posee un valor, por ejemplo

341H2048 Ubicación: toma un valor para un momento dado,

por ejemplo el Hangar N°1 Mantenimiento Mecánico: toma un valor para un

momento dado, por ejemplo el Realizado o No Realizado

Estado de Motores: toma un valor para un momento dado, por ejemplo Encendidos o No Encendidos


87

• Atributos del actor Torre de Control: Número: posee un valor, por ejemplo Torre N°2

Autorización de Abastecimiento: puede tomar el valor Afirmativa o Negativa

3. Relaciones que ponen de manifiesto la forma en que los actores se vinculan en el marco de la situación de la realidad contenida en el escenario de usuario:

• Relación entre el actor Aeronave y Torre de Control:

Controla: esta relación estipula que las torres de control supervisan el movimiento de los aviones para la recarga de combustible

4. Acciones a través de las cuales un actor modifica su propio estado alterando el valor de alguno de sus atributos; se señalan atributos y condiciones que se deben cumplir para que estas acciones puedan llevarse a cabo:

• Acción que lleva a cabo el actor Aeronave: Mover: modifica el valor del atributo ubicación del

actor aeronave, con lo cual cambia su estado; esta acción posee el atributo Velocidad que adopta un valor determinado (por ejemplo 20km/h) y la condición que debe cumplirse para que la acción tenga lugar es que la aeronave tenga los Motores Encendidos.

5. Interacciones a través de las cuales un actor modifica el estado de otro actor con el cual interactúa alterando el valor de alguno de sus atributos; se señalan atributos y condiciones que se deben cumplir para que estas interacciones puedan llevarse a cabo:

• Interacción que tiene lugar entre los actores Aeronave y Torre de Control:

Pedido de Autorización: por medio de esta interacción el actor Aeronave solicita autorización para abastecerse de combustible al actor Torre de Control.

Decisión sobre Autorización: por medio de esta interacción el actor Torre de Control toma una decisión (afirmativa o negativa) sobre el pedido de autorización y se lo informa al actor Aeronave. Ambas interacciones poseen el atributo referido al Tipo de Comunicación que puede ser Simplex, Duplex o Full – Duplex; a su vez, la condición que debe cumplirse para que tengan lugar estas interacciones es que la aeronave tenga el Mantenimiento Mecánico Realizado.

6. Funcionalidades requeridas por el usuario vinculadas con los elementos de la realidad (atributos, acciones, interacciones, etc) sobre los cuales se aplican estas funcionalidades:

• Funcionalidad que se aplica sobre el atributo Mantenimiento Mecánico del actor Aeronave:

Cálculo del total de los mantenimientos mecánicos realizados en todas las aeronaves en un día: por medio de esta funcionalidad el usuario desea conocer la totalidad de los mantenimientos mecánicos realizados por el sector sobre todas las aeronaves en un día determinado.

• Funcionalidad que se aplica sobre el atributo Autorización de Abastecimiento del actor Torre de Control:

Registro de las autorizaciones de abastecimiento aceptadas por la torre de control en un día: por medio de esta funcionalidad el usuario desea tener un registro de aquellas autorizaciones de abastecimiento que fueron aceptadas por la torre de control en un día.

Tal como se puede apreciar en el escenario correspondiente a la figura 7, el mismo representa una instantánea de la realidad reflejada en una parte del discurso de usuario, junto con las prestaciones o funcionalidades que el usuario pretende obtener del producto software a construir. Esto es así en virtud de que los actores representados están instanciados con valores determinados para sus correspondientes atributos.

A continuación se ilustra en figura 7 el esquema gráfico correspondiente a este escenario de usuario con su Espacio – Problema y Espacio – Producto y todos los elementos que fueron identificados por el IR a partir del análisis del discurso de usuario.

Fig. 7 Representación gráfica del “Escenario de Usuario” correspondiente al

mecanismo de abastecimiento de combustible de una aeronave en el sector de mantenimiento de un aeropuerto

* Significa que el atributo y la condición son válidas para ambas interacciones de Pedido de Autorización y Decisión sobre Autorización.

c) Enfoque Cognitivista en la Construcción de Escenario de Usuario

En esta sección se abordan los aspectos generales del Enfoque Cognitivista, el cual constituye el soporte fundamental para la construcción de los Escenarios de Usuario (EU). En este sentido y para una mejor comprensión acerca del uso de este enfoque en la construcción de los EU, es


88

importante destacar que a partir de la información proporcionada por el usuario en su discurso, el IR debe capturar una realidad que incluye un problema que se debe resolver por medio de un producto software. Esta realidad constituye un elemento “intangible” y, por lo general, presenta un importante grado de complejidad; lo cual hace que no resulte sencilla su captura y, por consiguiente, la tarea de modelarla.

Asimismo, es importante destacar que el discurso del usuario constituye una declaración textual de cómo este usuario vivencia (o vivenció) esta realidad junto con el problema a resolver. Esta vivencia le permite al usuario crear en su mente un modelo de la realidad y el problema el cual constituye un importante capital en lo que se refiere a la experiencia de dicha realidad que el IR no posee, lo que origina dificultades en la comprensión de esta realidad y su conexión con el problema a resolver [23], [3].

Tal como se ha especificado la construcción de este “Modelo Mental” o “Estructura Cognitiva” constituye un proceso mental indexado por vivencias y experiencias que son de carácter netamente personal y que tienen lugar en determinados contextos [39], [40]. Conforme a investigaciones llevadas a cabo en Psicología Cognitiva por John Black, este modelo mental contiene de forma integrada diferentes clases de conocimiento [41] [42] tales como: conocimiento factual, conocimiento procedural, conocimiento contextual y conocimiento de asociación.

Cabe consignar que estos tipos de conocimiento se encuentran presentes en el discurso del usuario y su identificación le permite al IR obtener los distintos elementos que componen los escenarios de usuario (actores, atributos, relaciones, acciones, interacciones y funcionalidades), para luego proceder a la construcción de los mismos. En la sección correspondiente a la presentación de las diferentes técnicas que permiten implementar las tareas que componen cada una de las fases del proceso de conceptualización, se explica en detalle la forma de obtener estos elementos y de construir estos escenarios de usuario.

3) Fases, Tareas y Productos En esta sección se presenta un breve sumario acerca de los

diferentes elementos que conforman el soporte del Proceso de Conceptualización de Requisitos, poniendo énfasis en la localización de cada uno de ellos dentro de la estructura del proceso y de como intervienen para que el mismo pueda llevarse a cabo. Tal como se especificó en la sección de Estructura General del Proceso de Conceptualización de Requisitos, este se desarrolla por medio de la implementación de dos fases fundamentales: la fase de Análisis Orientado al Problema y la fase de Análisis Orientado al Producto. Para la realización de cada una de estas fases es necesario llevar a cabo una serie de tareas, las cuales tienen como función el procesamiento de ciertos productos de entrada para obtener los correspondientes productos de salida. Este procesamiento de los productos de entrada se efectúa a través de una determinada Técnica de Transformación especialmente diseñada para cada tarea. En otras palabras, existe una relación biunívoca entre cada una de las tareas que conforman cada fase del proceso y su correspondiente técnica de transformación asociada.

En función de lo expuesto, para la fase de Análisis Orientado al Problema se tienen las siguientes relaciones entre

las tareas y las técnicas que se deben aplicar: para el desarrollo de la tarea Segmentación del Discurso de Usuario (SDU) se aplica la Técnica de Segmentación del Discurso de Usuario (TS – DU), para la implementación de la tarea Análisis Cognitivo de los Segmentos de Texto (ACST) se aplican las Técnicas Cognitivas de Identificación de Conocimientos Factuales, Procedurales, Contextuales y de Asociación (TCI - CFPCA) y para realizar la tarea Construcción del Espacio Problema de Escenarios de Usuario (CEPEU) se aplica la Técnica de Construcción del Diagrama de Espacio Problema de Escenarios de Usuario (TCD – EPEU).

En lo que respecta a la fase de Análisis Orientado al Producto se tienen las siguientes relaciones entre las tareas y las técnicas que se deben aplicar: para el desarrollo de la tarea Construcción de Escenarios de Usuario (CEU) se aplica la Técnica de Construcción del Diagrama de Escenarios de Usuario (TCD – EU), para la implementación de la tarea Refinamiento de Escenarios de Usuario (REU) se aplica la Técnica de Refinamiento del Diagrama de Escenarios de Usuario (TRD – EU) y para realizar la tarea Construcción del Mapa Unificado de Escenarios de Usuario Refinados (CMUEUR) se aplica la Técnica de Construcción del Diagrama del Mapa Unificado de Escenarios de Usuario Refinados (TCD – MUEUR).

En figura 8 se ilustra la relación entre las fases, tareas y productos (con su correspondiente formato de representación) que componen el proceso de conceptualización de requisitos:

C. Técnicas asociadas a las tareas del modelo de

proceso En esta sección se proponen un conjunto de técnicas que le

permiten al IR implementar las correspondientes tareas que conforman el Proceso de Conceptualización de Requisitos. En este sentido, se proponen técnicas que se utilizan para el desarrollo de las fases de Análisis Orientado al Problema y Análisis Orientado al Producto.

1) Técnicas Utilizadas en la Fase de Análisis Orientado al Problema

En esta sección se describen las técnicas utilizadas para el desarrollo de las tareas correspondientes a la fase de Análisis Orientado al Problema: Técnica de Segmentación del Discurso de Usuario (TS – DU), Técnicas Cognitivas de Identificación de Conocimientos Factuales, Procedurales, Contextuales y de Asociación (TCI - CFPCA) y Técnica de Construcción del Diagrama de Espacio Problema de Escenarios de Usuario (TCD – EPEU).

a) Técnica de Segmentación del Discurso de Usuario (TS – DU)

Por medio de esta técnica se implementa la primera tarea que debe llevar a cabo el IR en la fase de Análisis Orientado al Problema, denominada Segmentación del Discurso de Usuario (SDU). Para la aplicación de la TS – DU el IR cuenta con el Discurso de Usuario (DU) en lenguaje natural como producto de entrada, y comienza por una segmentación de dicho DU “frase” por “frase” (llamadas “frases cortas”), luego procede a integrar estas frases en Segmentos de Texto (ST) que identifiquen situaciones de la realidad descripta por el usuario, y finalmente obtener los ST asociados a los diferentes Escenarios de Usuario (EU).


89

Fig. 8 Representación gráfica de las fases, tareas y productos con sus formatos de representación

D. Técnicas asociadas a las tareas del modelo de proceso

En esta sección se proponen un conjunto de técnicas que le permiten al IR implementar las correspondientes tareas que conforman el Proceso de Conceptualización de Requisitos. En este sentido, se proponen técnicas que se utilizan para el desarrollo de las fases de Análisis Orientado al Problema y Análisis Orientado al Producto.

2) Técnicas Utilizadas en la Fase de Análisis Orientado al Problema

En esta sección se describen las técnicas utilizadas para el desarrollo de las tareas correspondientes a la fase de Análisis Orientado al Problema: Técnica de Segmentación del Discurso de Usuario (TS – DU), Técnicas Cognitivas de Identificación de Conocimientos Factuales, Procedurales, Contextuales y de Asociación (TCI - CFPCA) y Técnica de Construcción del Diagrama de Espacio Problema de Escenarios de Usuario (TCD – EPEU).

b) Técnica de Segmentación del Discurso de Usuario (TS – DU)

Por medio de esta técnica se implementa la primera tarea que debe llevar a cabo el IR en la fase de Análisis Orientado al Problema, denominada Segmentación del Discurso de Usuario (SDU). Para la aplicación de la TS – DU el IR cuenta con el Discurso de Usuario (DU) en lenguaje natural como producto de entrada, y comienza por una segmentación de dicho DU “frase” por “frase” (llamadas “frases cortas”), luego procede a integrar estas frases en Segmentos de Texto (ST) que identifiquen situaciones de la realidad descripta por el usuario,

y finalmente obtener los ST asociados a los diferentes Escenarios de Usuario (EU).

Los ST con los EU asociados constituyen el producto de salida que proporciona la TS – DU. La tabla 1 resume los pasos necesarios para la implementación de esta técnica.

Tabla 1. Técnica de Segmentación del Discurso de Usuario (TS – DU)

Paso 1: En este primer paso se realiza un análisis preliminar del DU a los efectos de segmentarlo en “frases cortas”. La idea de segmentar el DU de esta forma proviene de la Ingeniería de Conocimiento y se basa en la técnica de Análisis de Protocolo para educir conocimiento de un experto cuando el mismo relata como resuelve un determinado problema [7], [8]; en este caso, en la fase de “Transcripción del Protocolo”, el ingeniero de conocimiento segmenta y transcribe el relato del experto en base a cuestiones tales como las pausas que realiza el experto en su exposición o las distintas entonaciones a lo largo de su relato. Esta segmentación inicial permite un tratamiento más simple del DU para afrontar el paso 2 de este proceso. Las frases cortas obtenidas constituyen el subproducto de salida correspondiente a este paso.


90

Paso 2: En este segundo paso se integran las “frases cortas” obtenidas en el paso 1 en ST descriptivos de una situación o episodio de la realidad. Estos ST están conformados por conjuntos de frases cortas y constituyen el subproducto de salida correspondiente a este paso.

Paso 3: En este tercer paso se asocia cada uno de los segmentos de texto obtenidos en el paso anterior a un escenario de usuario. Por consiguiente, como resultado de este proceso de asociación se obtienen los correspondientes ST asociados a los EU, los cuales constituyen el producto de salida de esta técnica.

La técnica propuesta y los subproductos que se obtienen se pueden visualizar en figura 9.

Fig. 9 Esquema y subproductos resultantes de aplicar la Técnica de

Segmentación del Discurso de Usuario (TS – DU)

Nota: en cada figura y para cada uno de los productos y subproductos de entrada y salida se ilustran de manera adicional los formatos de representación.

c) Técnicas Cognitivas de Identificación de Conocimientos Factuales, Procedurales, Contextuales y de Asociación (TCI - CFPCA)

Por medio de esta técnica se implementa la segunda tarea que debe llevar a cabo el IR en la fase de Análisis Orientado al Problema, denominada Análisis Cognitivo de los Segmentos de Texto (ACST). Para la aplicación de la TCI – CFPCA el IR dispone como producto de entrada de cada uno de los ST asociados a los EU que fueron obtenidos a partir de la aplicación de la técnica anterior (TS – DU); estos segmentos se procesan con la idea de identificar en los mismos diferentes Tipos de Conocimiento (TC), los cuales se encuentran presentes en el “Modelo Mental” elaborado por el usuario a partir de un proceso mental indexado por vivencias y experiencias que son de carácter netamente personal y que tienen lugar en determinados contextos [39], [40]. Conforme a investigaciones llevadas a cabo en Psicología Cognitiva por John Black, este modelo mental contiene de forma integrada diferentes TC [41], [42], entre los cuales caben citar: TC Factual, TC Procedural, TC Contextual y TC de Asociación. Para comenzar a aplicar la TCI – CFPCA el IR comienza por la identificación de TC Contextual en los ST, para luego continuar con los TC Factual, Procedural y de Asociación. Finalmente, el IR integra estos TC con los ST a los efectos de establecer que TC se corresponden con cada ST. Los ST integrados con los respectivos TC identificados (en formato de

tabla) constituyen el producto de salida que proporciona la TCI – CFPCA. La tabla 2 resume los pasos y procedimientos necesarios para la implementación de esta técnica.

Tabla 2. Técnica Cognitiva de Identificación de Conocimientos Factuales,

Procedurales, Contextuales y de Asociación (TCI - CFPCA)

Paso 1: En este primer paso se realiza el Análisis Cognitivo de los ST a los efectos de identificar los diferentes TC (TC Contextual, TC Factual, TC Procedural y TC de Asociación) en cada uno de los ST asociados a los EU obtenidos a partir de la aplicación de la técnica anterior. La realización de este paso se lleva a cabo por medio de cuatro procedimientos, a saber: i. Identificación de TC Contextual en los ST: por medio de

este procedimiento se realiza el Análisis Cognitivo de los ST a los efectos de identificar TC Contextual en los mismos. Este TC se caracteriza por “saber donde ocurre algo”, es decir, que para la existencia de este TC el cuerpo de texto debe hacer referencia al ámbito o entorno que actúa como marco de soporte de los otros tipos de conocimiento, y por consiguiente, de la realidad descripta por el usuario. Por ejemplo, se identifica TC Contextual en frases descriptivas del tipo: “la gerencia comercial controla toda la facturación que emiten los departamentos de tesorería y finanzas antes de que sean asentadas en el libro diario”. Las frases con TC Contextual constituyen el subproducto de salida correspondiente a este procedimiento.

ii. Identificación de TC Factual en los ST: por medio de este procedimiento se realiza el Análisis Cognitivo de los ST a los efectos de identificar TC Factual en los mismos. Este TC se caracteriza por “saber que algo es”, es decir, que para la existencia de este TC el cuerpo de texto debe hacer referencia a frases declarativas que poseen una afirmación acerca de un hecho. Por ejemplo, se identifica TC Factual en frases tales como: “en ese caso la factura es aceptada”. Las frases con TC Factual constituyen el subproducto de salida correspondiente a este procedimiento.

iii. Identificación de TC Procedural en los ST: por medio de este procedimiento se realiza el Análisis Cognitivo de los ST a los efectos de identificar TC Procedural en los mismos. Este TC se caracteriza por “saber como se hace algo”, es decir, que para la existencia de este TC el cuerpo de texto debe hacer referencia a frases que sugieran un procedimiento para realizar una tarea en una cierta secuencia, o que posean una relación del tipo causa – efecto. Por ejemplo, se identifica TC Procedural en frases tales como: “si la factura es aceptada entonces efectuar el pago”. Las frases con TC Procedural constituyen el


91

subproducto de salida correspondiente a este procedimiento.

iv. Identificación de TC de Asociación en los ST: por medio de este procedimiento se realiza el Análisis Cognitivo de los ST a los efectos de identificar TC de Asociación en los mismos. Este TC se caracteriza por “saber identificar aquellos elementos que intervienen para hacer algo”, es decir, que para la existencia de este TC el cuerpo de texto debe hacer referencia a frases sugieran una cierta funcionalidad que debe realizar el sistema, con actores que intervienen para que la misma pueda llevarse a cabo. Por ejemplo, se identifica conocimiento asociado a un determinado contexto en frases del tipo: “el departamento de Recursos Humanos debe llevar un registro actualizado con los montos mensuales invertidos por departamento en concepto de capacitación de su personal”. La funcionalidad o prestación a la que hace referencia esta frase del discurso “Cálculo del monto en concepto de capacitación de personal por mes y por departamento”, vincula conceptos de la realidad descripta por el usuario como los actores “Departamento de Recursos Humanos”, “Departamento de Ventas”, etc; que son actores necesarios para realizar esta funcionalidad. Las frases con TC de Asociación constituyen el subproducto de salida correspondiente a este procedimiento. Los distintos TC (TC Contextual, TC Factual, TC

Procedural y TC de Asociación) obtenidos constituyen el subproducto de salida correspondiente a este paso.

Paso 2: En este segundo paso se procede a integrar los ST con los TC identificados en los respectivos ST; para lo cual, se confecciona una tabla que indique los diferentes TC contenidos en cada uno de los ST. La tabla de los ST con los respectivos TC identificados constituye el producto de salida de esta técnica. La técnica propuesta y los subproductos que se obtienen se pueden visualizar en figura 10.

Fig. 10 Esquema y subproductos resultantes de aplicar la Técnica Cognitiva de

Identificación de Conocimientos Factuales, Procedurales, Contextuales y de Asociación (TCI - CFPCA)

d) Técnica de Construcción del Diagrama de Espacio Problema de Escenarios de Usuario (TCD – EPEU)

Por medio de esta técnica se implementa la tercera tarea que debe llevar a cabo el IR en la fase de Análisis Orientado al Problema, denominada Construcción del Espacio Problema en Escenarios de Usuario (CEPEU). Para la aplicación de la TCD – EPEU el IR dispone como productos de entrada de cada uno de los ST asociados a los EU obtenidos a partir de la aplicación de la técnica TS – DU, y de los TC identificados en cada uno de los ST (en formato de tabla) obtenidos a partir de la aplicación de la técnica TCI – CFPCA. Para comenzar a aplicar la TCD – EPEU el IR procede a hacer uso de los TC identificados en cada ST (dejando el TC de Asociación para la Fase de Análisis Orientado al Producto) para poder obtener los distintos elementos que componen los EPEU, los cuales son: Actores, Relaciones, Atributos, Acciones e Interacciones. A continuación, el IR procede a identificar el Marco Contextual Base (MCB) en el que se desenvolverán los actores en el EPEU construyéndose un primer diagrama de EPEU a tal efecto. Finalmente, el IR confecciona los restantes diagramas de EPEU encargados de reflejar las distintas realidades proporcionadas por los respectivos ST.

Los diagramas correspondientes a los EPEU constituyen el producto de salida que proporciona la TCD – EPEU. La tabla 3 resume los pasos, procedimientos y subprocedimientos necesarios para la implementación de esta técnica.

Paso 1: En este primer paso el IR hace uso de los respectivos TC (Factual, Procedural y Contextual) para la identificación de los elementos que conforman los diagramas de EPEU para cada uno de los ST asociados. La realización de este paso se lleva a cabo por medio de cuatro procedimientos, a saber:

i. Uso de TC Factual, este procedimiento permite: • identificar conceptos, que se representarán como

actores en los EPEU. • caracterizar los actores que van a conformar los

respectivos EPEU, definiendo para los mismos atributos con sus respectivos valores.

• caracterizar acciones internas en los actores, definiendo para dichas acciones atributos con sus respectivos valores y condiciones para su realización.

• caracterizar interacciones entre actores, definiendo para dichas interacciones atributos con sus respectivos valores y condiciones para su realización.

• identificar las relaciones entre los actores pertenecientes a los respectivos EPEU.

ii. Uso de TC Procedural, este procedimiento permite: • identificar acciones internas en los actores, las

cuales podrán o no ser modificatorias de valores de atributo del actor.

• identificar interacciones entre actores, las cuales podrán modificar o no valores de atributo de los actores que interactúan.

iii. Uso de TC Contextual, este procedimiento permite: • identificar el MCB o ámbito en el que tiene lugar

la realidad descripta por el usuario (Departamento de Producción, Sección de Mantenimiento, etc).


92

• identificar los actores y relaciones que inicialmente conforman el primer EPEU correspondiente al MCB.

Tabla 3. Técnica de Construcción del Diagrama de Espacio Problema en

Escenarios de Usuario (TCD – EPEU)

iv. Uso de TC Procedural, este procedimiento permite: • identificar acciones internas en los actores, las

cuales podrán o no ser modificatorias de valores de atributo del actor.

• identificar interacciones entre actores, las cuales podrán modificar o no valores de atributo de los actores que interactúan.

v. Uso de TC Contextual, este procedimiento permite: • identificar el MCB o ámbito en el que tiene lugar

la realidad descripta por el usuario (Departamento de Producción, Sección de Mantenimiento, etc).

• identificar los actores y relaciones que inicialmente conforman el primer EPEU correspondiente al MCB.

vi. Elaboración de Tablas de Vinculación TC – Elementos de EPEU para cada EPEU, este procedimiento permite sintetizar en formato de tabla toda la información correspondiente a los elementos de cada EPEU (Actores, Relaciones, Atributos, Acciones e Interacciones), obtenidos a partir de los TC contenidos en los ST.

Como resultado de la aplicación de estos procedimientos, se obtienen las respectivas Tablas de Vinculación TC – Elementos de EPEU para cada EPEU, las cuales constituyen el subproducto de salida correspondiente a este paso.

Paso 2: En este segundo paso el IR procede a la construcción del diagrama de EPEU correspondiente al MCB. Para ello, el IR parte de los distintos elementos identificados en el procedimiento 1.3, junto con la Tabla de Vinculación para este EPEU. En tal sentido, y como el objetivo es establecer el marco contextual de la manera más ilustrativa posible, es que el IR representa en este diagrama los actores centrales con sus atributos de identificación (dejando la

incorporación de interacciones y acciones para el próximo paso) y las relaciones entre estos, identificados en el procedimiento 1.3. Por consiguiente, para la realización de este paso se llevan a cabo los siguientes dos procedimientos: i. Incorporación de Actores al Diagrama de EPEU del

MCB: por medio de este procedimiento el IR comienza la construcción del diagrama correspondiente al MCB colocando los actores centrales identificados en el ST que contextualiza el problema.

ii. Incorporación de Relaciones al Diagrama de EPEU del MCB: por medio de este procedimiento el IR continúa la construcción del diagrama a partir de la confección de las correspondientes relaciones entre estos actores, que han sido identificadas en el ST que contextualiza el problema.

Como resultado de la aplicación de estos procedimientos, se obtienen los Actores y Relaciones que conforman el diagrama de EPEU correspondiente al MCB. Este diagrama constituye el subproducto de salida correspondiente a este paso.

Paso 3: En este tercer paso el IR procede a la construcción de los restantes diagramas de EPEU correspondientes a los ST que le continúan al del MCB. Para obtener estos diagramas, el IR parte del diagrama de EPEU del MCB, de los distintos elementos identificados en los procedimientos 1.1 y 1.2., y de las respectivas Tablas de Vinculación para cada EPEU. Por consiguiente, para la realización de este paso se llevan a cabo los siguientes cuatro procedimientos, y sus correspondientes subprocedimientos cuando correspondan, para cada uno de las correspondientes EPEU:

i. Incorporación de Actores al Diagrama de EPEU: por medio de este procedimiento el IR comienza la construcción del diagrama de EPEU correspondiente al ST de que se trate, incorporando los actores que correspondan teniendo en cuenta los ya existentes en el EPEU anterior. Se implementan los siguientes subprocedimientos: • Incorporación de Atributos de actores al

Diagrama: por medio de este subprocedimiento el IR incorpora los atributos que le permiten caracterizar a los actores.

• Incorporación de valores de Atributos de actores al Diagrama: por medio de este subprocedimiento el IR incorpora los valores correspondientes a dichos atributos.

ii. Incorporación de Relaciones al Diagrama: por medio de este procedimiento el IR continúa la construcción del diagrama de EPEU correspondiente al ST de que se trate, teniendo en cuenta las relaciones ya existentes en el EPEU anterior.

iii. Incorporación de Acciones al Diagrama: por medio de este procedimiento el IR continúa la construcción del diagrama de EPEU correspondiente al ST de que se trate, incorporando las acciones que correspondan teniendo en cuenta las ya existentes en el EPEU anterior. Se implementan los siguientes subprocedimientos: • Incorporación de Atributos de acciones al

Diagrama: por medio de este subprocedimiento el IR incorpora los atributos que le permiten caracterizar a las acciones.


93

• Incorporación de valores de Atributos de acciones al Diagrama: por medio de este subprocedimiento el IR incorpora los valores correspondientes a dichos atributos.

• Incorporación de condiciones para la realización de acciones al Diagrama: por medio de este subprocedimiento el IR incorpora las condiciones correspondientes para que pueda realizarse una acción determinada.

iv. Incorporación de Interacciones al Diagrama: por medio de este procedimiento el IR continúa la construcción del diagrama de EPEU correspondiente al ST de que se trate, teniendo en cuenta las interacciones ya existentes en el EPEU anterior. Se implementan los siguientes subprocedimientos: • Incorporación de Atributos de interacciones al

Diagrama: por medio de este subprocedimiento el IR incorpora los atributos que le permiten caracterizar a las interacciones.

• Incorporación de valores de Atributos de interacciones al Diagrama: por medio de este subprocedimiento el IR incorpora los valores correspondientes a dichos atributos.

• Incorporación de condiciones para la realización de interacciones al Diagrama: por medio de este subprocedimiento el IR incorpora las condiciones correspondientes para que pueda tener lugar una interacción determinada.

La totalidad de los diagramas de EPEU con sus respectivos elementos constituyen el producto de salida de esta técnica. La técnica propuesta y los subproductos que se obtienen se pueden visualizar en figura 11.

Es muy importante destacar, que tanto en el desarrollo del Paso 2, en lo que se refiere a la construcción del Diagrama de EPEU correspondiente al Marco Contextual Base, como en el desarrollo del Paso 3, en lo que respecta a la construcción de los restantes diagramas, se estimó conveniente utilizar a modo de soporte la técnica de Análisis Estructural de Textos [5], la cual permite identificar la existencia de estructuras textuales fundamentales encargadas de transmitir conocimientos en los textos.

Las estructuras que se emplean en este trabajo son las Definiciones y Afirmaciones. Las primeras permiten detectar conceptos o actores y sus características o atributos, mientras que a partir de las segundas es posible detectar relaciones e interacciones entre conceptos.

El uso de estas estructuras le permite al IR efectuar una suerte de contraste entre los elementos de EU obtenidos con la técnica anterior (TCI – CFPCA) y los detectados por estas estructuras textuales; a la vez que son de gran utilidad para integrar gráficamente estos elementos en el “constructo” llamado EPEU.

3) Técnicas Utilizadas en la Fase de Análisis Orientado al Producto

En esta sección se describen las técnicas utilizadas para el desarrollo de las tareas correspondientes a la fase de Análisis Orientado al Producto: Técnica de Construcción del Diagrama de Escenarios de Usuario (TCD – EU), Técnica de Refinamiento del Diagrama de Escenarios de Usuario (TRD – EU) y Técnica de Construcción del Diagrama del Mapa

Unificado de Escenarios de Usuario Refinados (TCD – MUEUR).

a) Técnica de Construcción del Diagrama de Escenarios de Usuario (TCD – EU)

Por medio de esta técnica se implementa la primera tarea que debe llevar a cabo el IR en la fase de Análisis Orientado al Producto, denominada Construcción de Escenarios de Usuario (CEU). Para la aplicación de la TCD – EU el IR dispone como productos de entrada de aquellos ST asociados a los EU que contienen TC de Asociación, obtenidos a partir de la aplicación de las técnicas TCI – CFPCA, y de cada uno de los Diagramas de EPEU obtenidos a partir de la aplicación de la técnica TCD – EPEU.


Construcción del Diagrama de Espacio Problema en Escenarios de Usuario (TCD – EPEU). Nota: por razones de claridad de ilustración no

se incluyen los correspondientes subprocedimientos en la Figura 11.

Para comenzar a aplicar la TCD – EU el IR procede a hacer uso de los ST con TC de Asociación y de los diagramas de EPEU, lo que le permite obtener las “Funcionalidades” del problema planteado por el usuario, así como también identificar aquellos actores del EPEU que son necesarios para que el sistema realice estas funcionalidades. Con las funcionalidades y los diagramas de EPEU para los cuales se identificaron estas funcionalidades, el IR confecciona los diagramas correspondientes a los bloques del Espacio Producto de Escenarios de Usuario (EPrEU) para estos EPEU [3], [43], [44], [45].

Finalmente, el IR realiza un proceso de asociación a los efectos de obtener los vínculos existentes entre los elementos de los bloques de EPEU y EPrEU, obteniendo así un único diagrama para cada EU conformado por ambos bloques. Aquellos EU que no contengan funcionalidades asociadas, es


94

decir que no posean EPrEU, quedarán conformados por su correspondiente EPEU.

Los diagramas correspondientes a los EU constituyen el producto de salida que proporciona la TCD – EU. La tabla 4 resume los pasos y procedimientos necesarios para la implementación de esta técnica.

Tabla 4. Técnica de Construcción del Diagrama de Escenarios de Usuario

(TCD – EU)

Paso 1: En este primer paso el IR hace uso del TC de Asociación para la identificación de las funcionalidades del producto software a construir y de los actores que son necesarios para llevar a cabo estas funcionalidades correspondientes al EPEU que se analice. La realización de este paso se lleva a cabo por medio de tres procedimientos, a saber:

i. Identificación de Funcionalidades: por medio de este procedimiento el IR identifica las funcionalidades que debe realizar el sistema, las cuales se encuentran embebidas en aquellos ST en los que se ha identificado TC de Asociación.

ii. Identificación de Actores necesarios para realizar las funcionalidades: por medio de este procedimiento el IR identifica aquellos actores de los EPEU que son necesarios para llevar a cabo las funcionalidades obtenidas en 1.1, los cuales también deben identificarse en los mismos ST con TC de Asociación que se exploraron en “i”.

iii. Completar Tablas de Vinculación TC – Elementos de EPEU para los EPEU con TC de Asociación: por medio de este procedimiento el IR completa aquellas Tablas de Vinculación TC – Elementos de EPEU para los EPEU con TC de Asociación, con las funcionalidades y los actores que se necesitan para su realización.

Por consiguiente, las Tablas de Vinculación TC – Elementos de EPEU para los EPEU con TC de Asociación completas con las funcionalidades y actores necesarios para su implementación, constituyen el subproducto de salida correspondiente a este paso.

Paso 2: En este segundo paso, el IR hace uso de las funcionalidades obtenidas (sintetizadas en las Tablas de Vinculación TC – Elementos de EPEU para los EPEU con TC de Asociación) y de los diagramas de EPEU para los cuales se identificaron estas funcionalidades, para confeccionar los diagramas correspondientes a los bloques del Espacio Producto de Escenarios de Usuario (EPrEU) para estos EPEU. Por consiguiente, los Diagramas de EPrEU con las respectivas Funcionalidades constituyen el subproducto de salida de este paso.

Paso 3: En este tercer paso, el IR procede a establecer la “vinculación existente” entre las funcionalidades que conforman cada uno de los diagramas de EPrEU obtenidos en el paso anterior y aquellos actores pertenecientes al correspondiente EPEU que son necesarios para llevar a cabo estas funcionalidades. Para realizar este paso, el IR hace uso de los bloques de EPEU y EPrEU para cada EU. Desde el punto de vista gráfico, esta “vinculación” consiste en una flecha dirigida desde el actor (alojado en el EPEU) a la funcionalidad (alojada en el EPrEU). Por consiguiente, los Diagramas de EU con sus bloques de EPEU y EPrEU y sus correspondientes vinculaciones constituyen el producto de salida de esta técnica. Cabe señalar, que se tendrán diagramas de EU con los dos bloques correspondientes al EPEU y al EPrEU, y diagramas de EU sin el bloque de EPrEU; es decir, solo con el bloque de EPEU. La técnica propuesta y los subproductos que se obtienen se pueden visualizar en figura 12.

b) Técnica de Refinamiento del Diagrama de Escenarios de Usuario (TRD – EU)

Por medio de esta técnica se implementa la segunda tarea que debe llevar a cabo el IR en la fase de Análisis Orientado al Producto, denominada Refinamiento de Escenarios de Usuario (REU). Cabe destacar, que el procedimiento que se lleva a cabo para la aplicación de la TRD – EU incluye tanto al IR como al Usuario. Los productos de entrada con que ambos cuentan para aplicar esta técnica son el Discurso de Usuario (DU) original, o también llamado “en crudo”, el cual cabe recordar constituye el producto de entrada al “Proceso de Conceptualización” desde la fase misma de Análisis Orientado al Problema, y de cada uno de los Escenarios de Usuario (EU) obtenidos en la tarea anterior. Como producto de salida se obtienen los respectivos Diagramas de Escenarios de Usuario Refinados (EUR).


Construcción del Diagrama de Escenarios de Usuario (TCD – EU)

El procedimiento de aplicación de TRD – EU incluye en primer término una revisión conjunta (Usuario e IR) del


95

Discurso de Usuario (DU) original, el cual se lleva a cabo en base a un Análisis de Consistencia del mismo tendiente a identificar inconsistencias, las cuales se clasifican en incompletitudes y contradicciones. Dichas inconsistencias se validan y se depuran para contar con un Discurso de Usuario Refinado (DUR). Estas inconsistencias se ponen de manifiesto en el DU como consecuencia de un lógico “grado de subjetividad” que, muy probablemente, siempre esté presente en el relato del usuario, y que por lo tanto, se ven reflejadas en los EU [3], [20], [46], [47].

A partir de contar con un DU “refinado” (DUR), Usuario e IR realizan un Análisis de Consistencia de los Segmentos de Texto (ST) y Tipos de Conocimiento (TC), el cual consiste en una validación y depuración de los mismos a los efectos de depurar a estos elementos de las inconsistencias provenientes del DU. Luego, Usuario e IR realizan una validación y depuración de los diagramas de EU obtenidos a partir de la aplicación de la técnica TCD – EU, a los efectos de poder contar con diagramas de EUR desprovistos del mayor caudal de subjetividad posible. Como paso final, Usuario e IR efectúan una revisión final de los diagramas de EUR; si ambos consensúan en otorgar grado de conformidad a los mismos se da por concluida la realización de la TRD – EU y se pasa a abordar la próxima técnica del proceso de conceptualización, caso contrario, se comienza nuevamente a aplicar la TRD – EU desde el mismo DU original.

Los diagramas correspondientes a los EUR constituyen el producto de salida que proporciona la TRD – EU. La tabla 5 resume los pasos, procedimientos y subprocedimientos necesarios para la implementación de esta técnica.

Tabla 5. Técnica de Refinamiento del Diagrama de Escenarios de Usuario

(TRD – EU)

Paso 1: En este primer paso, Usuario e IR hacen uso del DU original y realizan el Análisis de Consistencia del DU

basado en la identificación de incompletitudes e inconsistencias, para luego obtener un DU “refinado” (DUR). La realización de este paso se lleva a cabo por medio de tres procedimientos, a saber:

i. Validación y Depuración de Incompletitudes: por medio de este procedimiento Usuario e IR detectan información faltante, como por ejemplo, la omisión acerca de la necesidad de validación de las facturas a pagar. Se procede a completar el párrafo correspondiente al DU original con la información faltante.

ii. Validación y Depuración de Contradicciones: por medio de este procedimiento Usuario e IR detectan información contradictoria, como por ejemplo, si en el DU original de establece que las facturas de pago a proveedores deben ser validadas por la tesorería antes de ser abonadas, y en una revisión posterior del discurso, el usuario dice que para que se efectúe el pago de dichas facturas las mismas deben ser validadas por el departamento de compras. Se procede a corregir el párrafo correspondiente al DU original con la información correcta.

iii. Validación y Depuración del DU: por medio de este procedimiento y con las incompletitudes y contradicciones depuradas, Usuario e IR obtienen un DU que satisface a ambos. A este DU se lo llama DU “refinado” (DUR).

Por consiguiente, el DU “refinado” (DUR) constituye el subproducto de salida de este paso.

Paso 2: En este segundo paso, Usuario e IR realizan un Análisis de Consistencia de los ST y TC obtenidos a partir del DU original, para lo cual hacen uso del DUR obtenido en el paso anterior y de los ST y TC originales. La realización de este paso se fundamenta en el hecho de que las inconsistencias identificadas en el DU original en los procedimientos “i” y “ii”, seguramente se propagan hacia los ST y TC obtenidos en base a ese DU. La realización de este paso se lleva a cabo por medio de dos procedimientos, y sus correspondientes subprocedimientos, a saber:

i. Validación y Depuración de los ST: por medio de este procedimiento Usuario e IR exploran el grado de impacto que experimentan los ST originales al hacer uso del DUR. Se implementan los siguientes subprocedimientos:

• Incidencia del DUR en las “frases cortas”: por medio de este subprocedimiento Usuario e IR analizan la incidencia del DUR obtenido en el Paso 1 en las “frases cortas” obtenidas de la segmentación del DU original. De la aplicación de este subprocedimiento se tienen “frases cortas” nuevas o modificadas, a las que se denomina refinadas.

• Incidencia de las “frases cortas” en los ST: por medio de este subprocedimiento Usuario e IR analizan la incidencia de las “frases cortas” obtenidas en 2.1.1 en los ST originales. De la aplicación de este subprocedimiento se tienen ST nuevos o modificados, a los que se denomina refinados.


96

ii. Validación y Depuración de los TC: por medio de este procedimiento Usuario e IR exploran el grado de impacto que experimentan los TC originales, al hacer uso de los ST obtenidos en 2.1.2. Se implementan los siguientes subprocedimientos:

• Incidencia de los ST en la identificación del TC Contextual: por medio de este subprocedimiento Usuario e IR analizan la incidencia de los ST nuevos o modificados obtenidos en el procedimiento del TC Contextual original. De la aplicación de este subprocedimiento se tiene TC Contextual nuevo o modificado, al cual se lo denomina refinado (TC CR).

• Incidencia de los ST en la identificación del TC Factual: por medio de este subprocedimiento Usuario e IR analizan la incidencia de los ST nuevos o modificados obtenidos en el procedimiento 2.1 en el TC Factual original. De la aplicación de este subprocedimiento se tiene TC Factual nuevo o modificado, al cual se lo denomina refinado (TC FR).

• Incidencia de los ST en la identificación del TC Procedural: por medio de este subprocedimiento Usuario e IR analizan la incidencia de los ST nuevos o modificados obtenidos en el procedimiento 2.1 en el TC Procedural original. De la aplicación de este subprocedimiento se tiene TC Procedural nuevo o modificado, al cual se lo denomina refinado (TC PR).

• Incidencia de los ST en la identificación del TC de Asociación: por medio de este subprocedimiento Usuario e IR analizan la incidencia de los ST nuevos o modificados obtenidos en el procedimiento 2.1 en el TC de Asociación original. De la aplicación de este subprocedimiento se tiene TC de Asociación nuevo o modificado, al cual se lo denomina refinado (TC AR).

Por consiguiente, los ST y TC “refinados” (STR) y (TCR) constituyen el subproducto de salida de este paso.

Paso 3: En este tercer paso, Usuario e IR hacen uso de los diagramas de Escenarios de Usuario EU obtenidos a partir del DU original y los STR y los TCR obtenido en el paso anterior, para realizar una validación y depuración de los EU originales. En este sentido, se comienza por validar y depurar los diagramas de EPEU, continuando con los diagramas de EPrEU, para finalmente obtener los diagramas de Escenarios de Usuario Refinados (EUR). La realización de este paso se lleva a cabo por medio de tres procedimientos, a saber:

i. Refinamiento de los Diagramas de EPEU: por medio de este procedimiento Usuario e IR validan y depuran los diagramas correspondientes a los EPEU originales, a través de la inspección de los elementos que los componen (actores, atributos, relaciones, acciones e interacciones). De esta manera, puede darse el caso de tener que agregar o quitar actores, modificar valores de atributos, incluir nuevas interacciones o acciones, etc. Se procede a corregir los diagramas de EPEU

originales, obteniendo los correspondientes diagramas de EPEU “refinados” (EPEUR).

ii. Refinamiento de los Diagramas de EPrEU: por medio de este procedimiento Usuario e IR validan y depuran los diagramas correspondientes a los EPrEU originales a través de la inspección de las funcionalidades que los conforman, con los STR, TCR (especialmente el TC de Asociación “refinado” (TC AR)) y los diagramas de EPEUR como soporte, obtenidos en 2.1, 2.2 y 3.1. Se procede a corregir diagramas de EprEU originales, obteniendo los correspondientes diagramas de EPrEU “refinados” (EPrEUR).

iii. Obtención de los Diagramas de EUR: por medio de este procedimiento Usuario e IR validan y depuran las “vinculaciones existentes” entre las funcionalidades que conforman cada uno de los diagramas de EPrEUR obtenidos en 3.2 y los correspondientes actores pertenecientes a cada uno de los diagramas de EPEUR obtenidos en 3.1 que son necesarios para llevar a cabo estas funcionalidades. Se procede a corregir los diagramas de EU originales, obteniendo los correspondientes diagramas de EU “refinados” (EUR).

Por consiguiente, los diagramas de EUR constituyen el subproducto de salida de este paso.

Paso 4: En este cuarto paso, Usuario e IR hacen uso de los diagramas de EUR obtenidos en el paso anterior y realizan una “revisión final” de los mismos contrastándolos con los diagramas de EU que se obtuvieron a partir del DU original. En caso de que Usuario e IR den conformidad a los diagramas de EUR obtenidos, estos constituyen el producto de salida de esta técnica y se da por finalizada la misma pasando a la aplicación de la siguiente, caso contrario se vuelve al Paso 1 y se comienza a aplicar la técnica nuevamente tomando como nuevo punto de partida el último DUR y los últimos diagramas de EU.

El modo de implementación de esta técnica responde a un “ciclo de prototipado evolutivo” [16], [48], [49], mediante el cual los EUR obtenidos se validan frente a los EU originales hasta alcanzar un conjunto de EUR que satisfagan a Usuario e IR, volviendo a ejecutar todos los pasos de la técnica. Esta forma de llevar a cabo el proceso tiene su justificación en el siguiente concepto, propio del espíritu del “ciclo de prototipado evolutivo”, el cual establece que los EUR que se van obteniendo en cada ciclo ponen a la luz nuevas inconsistencias en el DU, ya sea en lo que se refiere a aspectos de la realidad del problema como a sus funcionalidades.

Cabe destacar que cada ciclo de aplicación de la técnica, debe llevarse a cabo con el último DUR que se obtuvo del ciclo anterior y los últimos diagramas de EU obtenidos. Este hecho pone en evidencia la importancia que tiene contar con un Discurso de Usuario (DU) “pulido” y “refinado” que refleje de manera fidedigna los requerimientos de usuario, para poder obtener un producto software de de alta calidad. La técnica propuesta y los subproductos que se obtienen se pueden visualizar en figura 13.


97

c) Técnica de Construcción del Diagrama del Mapa Unificado de Escenarios de Usuario Refinados (TCD – MUEUR)

Por medio de esta técnica se implementa la tercera y última tarea que debe llevar a cabo el IR en la fase de Análisis Orientado al Producto, denominada Construcción del Mapa Unificado de Escenarios de Usuario Refinados (CMUEUR). Para la aplicación de la TCD – MUEUR el IR dispone como productos de entrada de cada uno de los STR (asociados a los EUR) y de los diagramas de EUR, ambos obtenidos a partir de la aplicación de la técnica TRD – EU. Como producto de salida se obtiene el Diagrama de Mapa Unificado de Escenarios de Usuario Refinados (MUEUR).

Fig. 13. Esquema y subproductos resultantes de aplicar la Técnica de

Refinamiento del Diagrama de Escenarios de Usuario (TRD – EU)

Nota: por razones de claridad de ilustración no se incluyen los correspondientes subprocedimientos en la Figura 13.

Es importante señalar, que un único escenario es representativo de una determinada situación de la realidad con sus funcionalidades asociadas, y en consecuencia, dicho escenario proporciona información parcial sobre el problema y la realidad en la que este se encuentra embebido [17]. Por tal razón, es que resulta sustancial que un análisis basado en escenarios involucre la observación de un conjunto de los mismos a los efectos de identificar aquellos elementos que permiten vincularlos [50], [35], [36]. En tal sentido, la interconexión de escenarios indica una secuencia en la ocurrencia de diversas situaciones que se encuentran embebidas en el Discurso de Escenario de Usuario Refinado (DUR) y que le permiten al IR documentar el “orden temporal” en que tienen lugar los diferentes escenarios obtenidos [34], [38], [51], así como también cuales escenarios son condición necesaria para la ocurrencia de otros (transición entre escenarios); en otros términos, identificar las

correspondientes relaciones de precedencia entre escenarios. De esta manera, el diagrama de MUEUR representa una secuencia espacio – temporal acerca de cómo el usuario entiende el problema a resolver y la realidad en la que se encuadra dicho problema. El procedimiento de aplicación de TCD – MUEUR incluye un Análisis de Transición de Escenarios de Usuario Refinados (EUR) mediante el cual se identifican los “Disparadores de Escenarios de Usuario Refinados”, los cuales permiten identificar las correspondientes relaciones de precedencia entre EUR. A partir de estos disparadores el IR está en condiciones de establecer los correspondientes vínculos entre EUR que le conducen al Diagrama de MUEUR. El diagrama correspondiente al MUEUR constituye el producto de salida que proporciona esta técnica, la cual se resume en la tabla 6.

Tabla 6. Técnica de Construcción del Diagrama del Mapa Unificado de

Escenarios de Usuario Refinados (TCD – MUEUR)

Paso 1: En este primer paso, el IR identifica los Disparadores de Escenarios de Usuario Refinados (EUR) presentes en los Segmentos de Texto Refinados (STR) y plasmados en los correspondientes EUR. Estos disparadores son considerados como agentes de cambio para cada EUR, ya que producen modificaciones en el cuerpo del escenario estableciendo, de esta manera, aquellos elementos vinculantes entre los mismos que permiten descubrir las correspondientes relaciones de precedencia entre EUR. La realización de este paso se lleva a cabo por medio de cuatro procedimientos de acuerdo a la clase de Disparadores de EUR que identifique el IR, los cuales se deben desarrollar para cada “Transición” entre un EUR y el que le continúa de acuerdo al criterio del IR, partiendo desde como se establece el EUR correspondiente al Marco Contextual Base:

A continuación se especifican cada uno de los cuatro procedimientos que debe llevar a cabo el IR para una “Transición” cualquiera:

i. Identificación de Cambio de Contexto: este disparador se presenta cuando del análisis conjunto de los (STR) y (EUR) el IR identifica un cambio de contexto de la situación que se describe, entendiéndose en tal caso, que se pasa a la descripción de un nuevo EUR. Por ejemplo, si el usuario pasa de describir lo que está sucediendo en el Departamento de Recursos Humanos a describir acontecimientos que tienen lugar en el Departamento de Control de Presupuesto; entonces el IR identifica un cambio de contexto que necesariamente implica una nueva situación, y por


98

consiguiente, un nuevo escenario de usuario con nuevos actores y nuevas relaciones. Cuando se describe el Marco Contextual Base (que generalmente corresponde al EUR I), este disparador debe hacer referencia a los actores centrales que componen dicho marco y las correspondientes relaciones entre ellos. En cualquiera de estos casos, cuando se produce un cambio de contexto o cuando se describe el Marco Contextual Base, por lo general el disparador tiene su origen en algún STR del DUR. A este tipo de disparador se lo llama Disparador de EUR Tipo I.

ii. Identificación de Cambio de Estado en Actores: este disparador se presenta cuando del análisis conjunto de los (STR) y (EUR) el IR identifica un cambio de estado en uno o más actores que componen un EUR, entendiendo tal cambio como adición de un nuevo atributo en el actor o cambio de valor de un atributo de este, por lo que se pasa a tener un nuevo EUR con estas modificaciones. Estos cambios pueden producirse a causa de acciones internas de los actores, interacciones entre actores o desde los mismos STR del DUR. Por ejemplo, si en un sistema de reserva de hotel una habitación pasa del estado de “libre” al estado de “reservada”, entonces en el actor habitación cambia el valor del atributo disponibilidad de libre a reservada; lo cual origina la transición hacia un nuevo EUR donde pueden tener lugar acciones tales como otorgarle a un pasajero un código de reserva para esa habitación. A este tipo de disparador se lo llama Disparador de EUR Tipo II.

iii. Identificación de Nuevos Actores: este disparador se presenta cuando del análisis conjunto de los (STR) y (EUR) el IR identifica eventos que modifican la composición del EUR actual, como ser el caso del agregado de un nuevo actor. De esta manera, se pasa a tener un nuevo EUR con estas modificaciones. Por lo general, estos cambios se producen a causa de los mismos STR del DUR. Por ejemplo, el ingreso de un nuevo avión en el espacio aéreo de un aeropuerto se puede ver como un evento que origina la transición a un nuevo EUR en un sistema de control de tráfico aéreo. A este tipo de disparador se lo llama Disparador de EUR Tipo III.

iv. Identificación de Funcionalidades: este disparador se presenta cuando del análisis conjunto de los (STR) y (EUR) el IR identifica la presencia de funcionalidades que debe realizar el producto software, modificando la composición del EPrEUR (dado que las funcionalidades se alojan en el Espacio Producto del Escenario de Usuario Refinado) y, en consecuencia, del EUR actual. También es importante identificar aquellos actores que son necesarios para realizar la funcionalidad. Por lo general, estos cambios se producen a causa de los mismos STR del DUR. Por ejemplo, que la organización pretenda llevar una estadística semanal de los clientes que deben dos o más

cuotas. La incorporación de esta prestación al Espacio Producto de un determinado EUR origina la transición hacia un nuevo EUR. A este tipo de disparador se lo llama Disparador de EUR Tipo IV. Es importante destacar, que los Disparadores de EUR son originados a causa de hechos correspondientes a la realidad contenida en el DUR; por tal razón, es preciso que cuando el IR identifica un Disparador de EUR también haga referencia a la causa que lo origina, es decir cuál es el hecho de la realidad que da lugar a la presencia de ese disparador. En síntesis, el término disparador engloba tanto al cambio que se produce en el cuerpo del EUR como así también a la causa que lo produce. Por ejemplo, si se produce un cambio en el valor de un atributo de un cierto actor del escenario (disparador tipo II que origina la transición a otro EUR), la causa de este disparador podría ser una interacción de este actor con otro, o si se produce la incorporación de una funcionalidad al espacio producto de un determinado escenario (disparador tipo IV que origina la transición a otro EUR), pudiendo ser la causa de este disparador un cierto párrafo perteneciente a un determinado segmento de texto. Conforme a lo expuesto, es importante documentar un disparador de EUR en función de las características mencionadas y también dependiendo del tipo de disparador.

A continuación se presenta un formato de documentación para cada tipo de EUR, suponiendo una situación cualquiera de transición de escenarios para un sistema determinado y asumiendo que en caso de existir más de un disparador del mismo tipo para la misma transición de un EUR a otro EUR, se los distingue con una apóstrofe; por ejemplo: Disparador de EUR tipo IV (EUR I – EUR II), Disparador de EUR tipo IV (EUR I – EUR II)’, Disparador de EUR tipo IV (EUR I – EUR II)’’, Disparador de EUR tipo IV (EUR I – EUR II)’’’, y así siguiendo. Cabe aclarar, que para los EUR que figuran entre paréntesis significa que el disparador origina la transición desde el EUR que figura en primer término al EUR que se encuentra en segundo término. Explicado este detalle, se ilustra el formato de representación de disparador para un sistema de reserva de habitaciones en un complejo hotelero:

• Disparador de EUR tipo I (EUR I correspondiente al Marco Contextual Base “Sector de Reservas”)

Actores: Gerente de Sector, Jefe de Sector, Formulario de Reserva y Habitación

Relación 1: “Reporta” (entre los Actores Gerente de Sector y Jefe de Sector)

Relación 2: “Controla” (entre los Actores Jefe de Sector y Formulario de Reserva)

o Causa: DUR “STR asociado al EUR I correspondiente al Marco Contextual Base”

• Disparador de EUR tipo II (EUR I – EUR II) Actor: Formulario de Reserva Atributo: Procesamiento Valor en EUR I: Sin procesar Valor en EUR II: Procesado


99

Causa: Interacción “Procesa desde el actor Jefe de Sector al actor Formulario de Reserva” en el EUR II • Disparador de EUR tipo III (EUR II – EUR III)

Actor que se agrega al EUR III: Pasajero Atributos: Nombre, Apellido, DNI, Domicilio y N°

de Visita Causa: DUR “STR asociado al EUR III”

• Disparador de EUR tipo II (EUR III – EUR IV) Actor: Habitación Atributo: Disponibilidad Valor en EUR III: Libre Valor en EUR IV: Reservada Causa: Interacción “Autoriza Reserva desde el actor

Jefe de Sector al actor Habitación” en el EUR IV • Disparador de EUR tipo IV (EUR IV – EUR V)

Funcionalidad: Registro mensual sobre la cantidad de veces que se ocupó cada habitación

Actores necesarios para realizar la funcionalidad: Habitación

Causa: DUR “STR asociado al EUR V” • Disparador de EUR tipo IV (EUR IV – EUR V)’

Funcionalidad: Registro mensual sobre la cantidad de veces que se reservó cada habitación

Actores necesarios para realizar la funcionalidad: Formulario de Reserva

Causa: DUR “STR asociado al EUR V” Cabe aclarar con respecto a estas dos funcionalidades que

se pretenden realizar en un sistema de esta clase, que las mismas se distinguen en el hecho de que una habitación puede ser reservada por un pasajero para un determinado período de tiempo, pero no necesariamente ser ocupada. Por tal razón es aceptable suponer que el Gerente del Sector desee contrastar los registros que se obtengan por medio de estas dos funcionalidades.

Obtenidos los diferentes tipos de Disparadores de EUR por medio de cada uno de los procedimientos de este paso, estos constituyen el subproducto de salida del mismo. De esta manera, el IR está en condiciones de abordar el desarrollo del próximo paso de la técnica.

Paso 2: En este segundo paso, el IR procede a la Construcción del Diagrama de MUEUR, para lo cual se parte de un primer EUR que identifica el Marco Contextual Base (Disparador tipo I), y en el cual se desarrolla la realidad manifestada por el usuario en su discurso. A partir de este primer EUR y con los disparadores tipo II, III y IV identificados en el paso 1, se comienza a elaborar el encadenamiento de los EUR que luego dará lugar al diagrama de MUEUR. En este sentido, el IR debe contemplar que los disparadores pueden presentarse en forma separada o conjunta en un determinado EUR; en otras palabras, la transición de un EUR a otro puede darse a causa de uno o más disparadores, siendo facultad del IR establecer cual o cuales son los disparadores que dan lugar a la transición de un EUR a otro EUR. Por ejemplo, si a partir de un determinado STR asociado a un EUR se identificase el agregado de un nuevo actor y también el cambio en el valor de un atributo de otro actor del mismo EUR (disparadores tipo III y II respectivamente), estos hechos constituirían los dos disparadores que darían lugar al próximo EUR. Por consiguiente, el Diagrama del MUEUR con sus respectivos EUR correctamente “conectados”, constituyen el producto de salida de esta técnica, y por

consiguiente del proceso de Conceptualización de Requisitos propuesto. La técnica propuesta y los subproductos que se obtienen se pueden visualizar en figura 14.

Fig. 14. Esquema y subproductos resultantes de aplicar la Técnica de

Construcción del Diagrama del Mapa Unificado de Escenarios de Usuario Refinados (TCD – MUEUR)

IV. CONCLUSIONES A continuación se presentan las aportaciones de este

trabajo y se destacan las futuras líneas de investigación que se consideran de interés en base al problema abierto que se presenta en este artículo.

A. Aportaciones del trabajo de investigación En este trabajo se ha corroborado que se pueden plantear

distinciones en el discurso del usuario que permitan diferenciar sub-dominios de análisis que minimicen la brecha conceptual entre la educción de requisitos y el modelado conceptual. Estos sub-dominios son los relacionados con: [a] la descripción de los componentes de la realidad del ambiente de trabajo del usuario que su discurso pone en evidencia; y [b] los aspectos relacionados con las funcionalidades que el usuario espera que el artefacto software posea.

En este contexto, este artículo ha propuesto: • Un modelo de proceso de conceptualización de

requisitos que se desarrolla en dos fases: una de Análisis Orientado al Problema y la otra de Análisis Orientado al Producto.

• Para la Fase de Análisis Orientado al Problema, se han propuesto las siguientes tareas: [i] Segmentación del Discurso de Usuario, la cual necesita del Discurso de Usuario como producto de entrada y proporciona como producto de salida los correspondientes Segmentos de Texto, [ii] Análisis Cognitivo de los Segmentos de Texto, que toma como producto de entrada a los Segmentos de Texto y proporciona como producto de salida los Tipos de Conocimiento embebidos en estos segmentos; y [iii] Construcción del Espacio Problema en Escenarios de Usuario, que tiene como insumos a los Tipos de Conocimiento y a los Segmentos de Texto, y proporciona como producto de salida los correspondientes Diagramas de Espacio Problema en Escenarios de Usuario.

• Para la Fase de Análisis Orientado al Producto, se han propuesto las siguientes tareas: [iv] Construcción de Escenarios de Usuario, la cual necesita como


100

productos de entrada a los Segmentos de Texto con Tipo de Conocimiento de Asociación y los Espacio Problema en Escenarios de Usuario, los cuales se procesan en el desarrollo de esta tarea y se obtienen los respectivos Escenarios de Usuario (EU); [v] Refinamiento de Escenarios de Usuario, que tiene como insumos a los Escenarios de Usuario y al Discurso de Usuario, que proporciona como producto de salida los correspondientes Escenarios de Usuario Refinados y [vi] Construcción del Mapa Unificado de Escenarios de Usuario Refinados que tiene como insumos los Escenarios de Usuario Refinados y los Segmentos de Texto Refinados (STR) para producir el Mapa Unificado de Escenarios de Usuario Refinados.

• Para la Fase de Análisis Orientado al Problema, se han desarrollado las técnicas: Técnica de Segmentación del Discurso de Usuario, Técnicas Cognitivas de Identificación de Conocimientos Factuales, Procedurales, Contextuales y de Asociación y la Técnica de Construcción del Diagrama de Espacio Problema de Escenarios de Usuario.

• Para la Fase de Análisis Orientado al Producto, se han desarrollado las técnicas: Técnica de Construcción del Diagrama de Escenarios de Usuario, Técnica de Refinamiento del Diagrama de Escenarios de Usuario y Técnica de Construcción del Diagrama del Mapa Unificado de Escenarios de Usuario Refinado.

• La propuesta de modelo de proceso de conceptualización de requisitos, las tareas y técnicas asociadas han sido validadas en dos dominios de conocimiento con características bien diferenciadas: el primero sobre un Sistema de Abastecimiento de Combustible de Aeronaves en el Contexto de las Operaciones Aeroportuarias, el cual se circunscribe en el dominio de los sistemas de información clásicos; y el segundo correspondiente a un Sistema de Operaciones Bancarias por Cajero Automático, el cual se circunscribe dentro de los sistemas de información transaccional.

B. Futuras líneas de investigación Durante el desarrollo de este proyecto han surgido

cuestiones que si bien no son centrales al tema abordado en la misma, constituyen temas concomitantes que (en opinión de quien escribe) darían lugar a las siguientes líneas de investigación futuras: • En este trabajo se han utilizado técnicas de Análisis

Cognitivo y técnicas de Ingeniería de Conocimiento. Estos conocimientos no forman parte de la los estándares fijados para la disciplina con lo que cabe preguntarse: ♦ ¿Qué conocimiento debería tener el ingeniero de

requisitos para poder realizar conceptualización de requisitos? ♦ ¿Debería buscarse una formación interdisciplinaria? ♦ ¿Qué disciplinas deberían estar involucradas?

• El proceso de conceptualización de requisitos suele ser subestimado al momento de asignar tiempos y recursos en la correspondiente planificación y presupuestación del proyecto. Poder concebir un proceso con fases y tareas como las propuestas en este artículo acerca posiciones respecto de disponer de objetos conceptuales a los que

asignarle recursos y prever su desarrollo en una línea de tiempo. En este contexto, se plantea el interés de trabajar en el desarrollo de herramientas que permitan estimar el esfuerzo que llevaría realizar este proceso de conceptualización.

• Si bien el proceso propuesto en este trabajo aporta sistematicidad al proceso de conceptualización de requisitos y el mismo ha sido validado en dominios representativos, quedan como temas de trabajo abiertos: ♦ La validación empírica más amplia del proceso de

conceptualización de requisitos mediante la técnica de muestras apareadas basadas en grupos experimental y de control. ♦ La validación empírica de las técnicas propuestas en

un conjunto vasto y representativo de dominios de aplicación (sistemas de tiempo real entre otros).

• A los efectos de poder obtener modelos conceptuales de “alta calidad”, entre los cuales se pueden citar: diagramas de casos de uso, diagramas de clases, diagramas de objetos, diagramas de interacción (secuencia y colaboración) y diagramas de estado, entre otros; seria aconsejable considerar una línea de investigación orientada a estudiar como se derivan estos modelos a partir de los diferentes productos que proporciona el proceso propuesto en este trabajo.

V. REFERENCIAS [1] Alford, M. 1977. A Requirements Engineering Methodology for

Real-Time Processing Requirements. IEEE Transactions on Software Engineering, SE-3(1).

[2] Yeh, R., Zave, P. 1980. Specifiying Software Requirements, Proc. of the IEEE, 68(9): 1077-1085.

[3] Davis, A. 1993. Software Requirements: Objects, Functions and States; Prentice-Hall International.

[4] Chen, P. 1990. Entity-relationship Approach to Data Modeling. In Systemand Software Requirements Engineering, Thayer RH, Dorfman M (eds). IEEE. Computer Society Press.

[5] Juristo, N. 1991. Método de construcción del núcleo de una base de conocimientos a partir de un modelo de clasificación documental. Tesis Doctoral, Universidad Politécnica de Madrid.

[6] Newell, A., y Simon, H. 1972. Human Problem Solving. Englewood Cliffs, NJ: Prentice Hall.

[7] Gómez, A., N. Juristo, C. Montes, J. Pazos, Ingeniería del Conocimiento, Ed. Centro de Estudios Ramón Areces, (1997).

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

[9] Kotonya, G., and Sommerville, I. 1998. Requirements Engineering: Processes and Techniques. John Wiley and Sons.

[10] Faulk, S. 1997. Software Requirements: A Tutorial; In Software Engineering, IEEE Computer Society Press, pp 82-101.

[11] Blum, B.I. Beyond Programming: To a New Era of Design. Oxford University Press, 1996.

[12] Wieringa, R. 1995. Requirements Engineering: Frameworks for Understanding; John Wiley.

[13] Beringer, D. 1995. Model Architecture Frame: Quality Management in a Multi Method Environment; Proceedings of the SQM’95.

[14] Van Griethuysen, J.J.; ISO – Concepts and Terminology for the Conceptual Schema and the Information Base; N695, ISO/TC9/SC5/WG3, 1982.


101

[15] Chatzoglou P., Soteriou A. 1999. A DEA framework to assess the efficiency of the software requirements capture and analysis process. Decision-Sciences. 30(2): 503-31.

[16] Sommerville, I. 2005. Ingeniería de Software, Addison-Wesley. [17] Robertson S. 2002. Project Sociology: Identifying and involving

the stakeholders, ICFAI University Press. [18] Christel, M. and Kang, K. 1992. Issues in Requirements

Elicitation. Software Engineering Institute Technical Report CMU/SEI-92-TR-12. Carnegie Mellon University.

[19] Van der Vos, B., Gulla, J., Van de Riet, R., 1995. Verification of Conceptual Models based in Linguistic Knowledge. NLDB 1995

[20] [Loucopoulos, P., Karakostas, V. 1995. System Requirements Engineering. McGraw-Hill.

[21] Zave, P. 1990. A Comparison of the Major Approaches to Software Specification and Design. In System and Software Requirements Engineering, Thayer RH, Dorfman M (eds). IEEE. Computer Society Press.

[22] Kaindl, H. 1999. Difficulties in the transition from OO analysis to design. IEEE Software, 16(5).

[23] Sutcliffe, A., Maiden, N. 1992. Analysing the Novice Analyst: Cognitive Models in Software Engineering; International Journal of Man-Machine Studies, 36(5).

[24] Yu, E., Mylopoulos, J. 1994. Uderstanding “Why” in Software Process Modelling, Analysis and Design; Proceedings of the 16th International Conference on Software Engineering.

[25] Holtzblatt, K., and H. Beyer. Requirements Gathering: The Human Factor. Communications of the ACM, 38, 5 (May 1995), pp. 31-32.

[26] Beringer, D. 1996. The Goals of the Analysis Model; Technical Report 96/216.

[27] Jalote, P. 1997. An Integrated Approach to Software Engineering; Springer-Verlag.

[28] Juristo, N., Moreno, A. 2000. Introductory paper: Reflections on Conceptual Modeling. Data and Knowledge Engineering, 33(2): 103-117.

[29] Davis, A. and Hickey, A. 2003. Requirements Elicitation and Requirements Elicitation Technique Selection: A Model of Two Knowledge-Intensive Software Development Processes. Proceedings of the Thirty-Sixth Hawaii International Conference on System Sciences, Los Alamitos, California: IEEE Computer Society Press.

[30] Robertson, S., Robertson, J. 1999. Mastering the Requirements Process. Addison-Wesley.

[31] Booch, G.; Object-Oriented Design with Applications; Benjamin Cummings, 1991.

[32] Jacobson, I; Object-Oriented Software Engineering: a Use Case Approach; Addison-Wesley, 1992.

[33] Potts C. Using schematic scenarios to understand user needs. In: Proceedings of DIS’95 – Symposium on designing interactive systems: processes, practices and techniques. ACM Press/ University of Michigan, 1995, pp 247–256.

[34] Carroll, J. 1995. Introduction: The Scenario Perspective on System Development, en "Scenario- Based Design: Envisioning Work and Technology in System Development", editor J. Carroll John Wiley & Sons.

[35] Zorman L. Requirements envisaging by utilizing scenarios (Rebus). PhD dissertation, University of Southern California, 1995.

[36] Leite, J., Hadad, G., Doorn, J., Kaplan, G. 2000. A Scenario Construction Process, Requirements Engineering Journal, Vol.5(1): 38-61.

[37] Breitman KK, Leite JCSP. A framework for scenario evolution. In: Proceedings of the IEEE international conference on requirements engineering. IEEE Computer Society Press, Los Alamitos, CA, 1998, pp 214–221.

[38] Hadad, G., Kaplan, G., Oliveros, A., Leite, J. 1997. Construcción de Escenarios a partir del Léxico Extendido del Lenguaje. Proceedings del Simposio de Tecnología de Software. XXVI JAIIO. Pág. 65-77.

[39] Manilow, A. 2005. Teaching proportion word problems using a multiple linked-representational software design – Columbia University doctoral dissertation.

[40] Anderson, J. 2006. Cognitive Psychology and its implications – Watson Guptill Publications.

[41] Black. J. 1992. Types of Knowledge Representation CCTE Report.Teachers College. Columbia University Press.

[42] Hossian, A. 2003. Sistema de Asistencia a la Selección de Estrategias y Actividades Instruccionales. Tesis de Master en Ingeniería de Software – Universidad Politécnica de Madrid, Madrid. http://www.iidia.com.ar/rgm/tesistas/hossiantesisdemagister.pdf. Pagina vigente al 14/01/2012.

[43] Potts C., K. Takahashi, A.I. Anton, Inquiry-based requirements analysis. In IEEE Software 11(2), pp. 21-32, 1994.

[44] Rolland, C., Souveyet, C, Ben Achour, C.: Guiding Goal Modeling Using Scenarios, IEEE Transactions on Software Engineering, Vol. 24, N° 12, 1998, pp. 1055 – 1071.

[45] Rolland C., Grosz G., Kla R., Experience With Goal-Scenario Coupling In Requirements

[46] [Kavakli E., Loucopoulos P., Filippidou D., Using Scenarios to Systematically Support Goal- Directed Elaboration for Information System Requirements, IEEE Symposium and Workshop on Engineering of Computer Based Systems (ECBS'96), 1996, GERMANY.

[47] Leite, J., Rossi, G., Balaguer, F., Maiorana, V., Kaplan, G., Hadad, G., Oliveros, A. 1997. Enhancing a Requirements Baseline with Scenarios. Proceedings of IEEE Third International Requirements Engineering Symposium, IEEE Computer Society Press. Pàg. 44-53.

[48] Pressman, R. S. 2001. Ingeniería del Software: Un enfoque práctico. 3 ed. McGraw-Hill, Madrid. Reigeluth, C. M. 1999. Instructional design theories and models: a new paradigm of instructional theory. Lawrence Erlbaum Associates Publishers. Washington. USA

[49] [Böehm, B. W. A Spiral Model of Software Development and Enhancement. Computer, May 1988, pp. 61-72.

[50] Booch, G.: Scenarios, Report on Object Analysis and Design, Vol. 1, N° 3, 1994, pp. 3-6.

[51] Hossian, A., Sierra, E., Britos, P., Ochoa, A., García-Martínez, R. 2007. Hacia una Metodología Orientada al Conocimiento para la Educción de Requisitos en Ingeniería del Software. Proceedings VI Ibero-American Symposium on Software Engineering: 107-114.

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. Profesor de la Universidad Tecnológica Nacional - Facultad Regional Neuquén (UTN - FRN). Director del Grupo de de Investigación en

Sistemas Inteligentes Aplicados a Ingeniería. Sus temas de interés incluyen: robótica, redes neuronales artificiales e Inteligencia Artificial.

Horacio Kuna, Germán Pautsch, Alice Rambo, Martín Rey, José Cortés, Silvina Rolon. 2013. Procedimiento de Explotación de Información para la Identificación de Campos anómalos en Base de Datos Alfanuméricas.

Revista Latinoamericana de Ingeniería de Software, 1(3): 102-106, ISSN 2314-2642

102

Procedimiento de Explotación de Información para la Identificación de Campos anómalos en Base de Datos

Alfanuméricas

Horacio Kuna1,2, German Pautsch1, Aalice Rambo1, Martin Rey1, J.ose Cortes1, Silvina Rolón. 1. Departamento de Informática,

Facultad de Ciencias Exactas Químicas y Naturales Universidad Nacional de Misiones. Misiones, Argentina

2. Fac. de Ingeniería – Universidad Nacional de Itapúa, Paraguay [email protected]

Resumen—La auditoría de sistemas dentro de las organizaciones desempeña una actividad de control y prevención sobre los sistemas, los cuales manejan uno de los activos más importantes que tienen las organizaciones que es la información. Para realizar estas actividades los auditores cuentan con una serie de técnicas y herramientas que los asisten, las Técnicas de Auditoría Asistidas por Computadora (TAACs). El presente trabajo muestra un procedimiento que utiliza técnicas de minería de datos que logran detectar campos considerados anómalos en una base de datos.

Abstract—The audit of systems within organizations may perform a control and prevention on systems that handle one of the most important assets in the organizations, this asset is the information. To perform these activities the auditors have a number of techniques and tools that assist them, the Computer assisted audit techniques (CAATs). This paper shows a method that uses data mining techniques that detect anomalous fields in the database.

Index Terms—Campos Anómalos, Bases de Datos, Datamining.

I. INTRODUCCION El manejo de la información en las organizaciones en formatos digitalizados y electrónicos es un elemento en constante crecimiento, que lleva a almacenar grandes volúmenes de datos provenientes de diversas fuentes. Puede suceder que durante su captura o procesamiento se generen situaciones que los afectan volviéndolos anómalos, estos datos con valores extremos pueden afectar la calidad de la información que se utiliza tanto para las operaciones transaccionales como para las orientadas a la toma de decisiones. Por este motivo, la auditoría de los sistemas y de los datos que manipulan los mismos es una práctica no solo recomendable sino además aceptada por todos los integrantes de la organización, ya que establece mecanismos que ayudan a lograr mayor confianza en la información que se obtiene y procesa. Dentro de las técnicas y herramientas que utilizan los auditores de sistemas existen diferentes propuestas. La MD (minería de datos), conocida como el proceso de extracción inteligente de información no evidente, pero presente en las bases de datos, es una de ellas pero su aplicación es aún incipiente. Algunas técnicas de MD se encuentran orientadas a detección de outliers [1]. Un outlier es aquel dato [2] que, por sus

características diferenciadoras en comparación a los demás datos contenidos en la BD, es sospechoso de haber sido introducido por otros mecanismos. Los datos anómalos pueden crear distorsión en los resultados obtenidos al realizar cualquier tipo de análisis sobre los mismos. Sin embargo son menos frecuentes los estudios sobre la calidad de los datos, considerando a los outliers como posibles datos inaceptables, teniendo en cuenta como criterios de calidad la detección de datos anómalos, sucios o con ruido. En cuanto a realizar trabajos específicos de MD existen propuestas que definen una serie de actividades tendientes a ordenar el proceso, entre ellos la metodología SEMMA [3] (Sample, Explore, Modify, Model, Assess), también aparece CRISP-DM (Cross-Industry Standard Processfor Data Mining) [4] y P3TQ [5] (Product, Place, Price, Time, Quantity). Sobre la detección de outliers existen trabajos que definen una taxonomía de las anomalías detectadas en la búsqueda de outliers [6] en diferentes contextos como detección de fraude tanto en tarjetas de crédito [7] [8] como en teléfonos celulares [9], entre otros. El problema que aparece en todos los trabajos que desarrollan algoritmos para la detección de outliers en Bases de Datos (BD) es que los mismos detectan las tuplas o filas que son consideradas anómalas y no detectan específicamente cuál es el campo específico de esa fila que tiene valores atípicos. Cuando se analizan grandes BD que contienen una importante cantidad de atributos, esta limitación de solo poder detectar las filas con valores anómalos es un inconveniente para el auditor, ya que debe realizar un análisis manual de cada uno de los campos de la fila sospechosa de contar con elementos que no son considerados normales. Un solo algoritmo no soluciona este déficit, por eso este trabajo propone un procedimiento que combina varios algoritmos para poder detectar específicamente cuál es el campo anómalo en una BD alfanumérica. El presente trabajo plantea utilizar técnicas de MD, entre ellas LOF (Local Outlier Factor) [10] que es un algoritmo basado en la densidad, creado específicamente para detectar outliers y da como resultado un valor de un objeto p que representa el grado en que p es un outlier, de esta manera se logra identificar valores inconsistentes pudiendo mejorar la calidad de los datos. El presente artículo propone un procedimiento el cual determina las filas y los campos dentro de un conjunto de

Horacio Kuna, Germán Pautsch, Alice Rambo, Martín Rey, José Cortés, Silvina Rolon. 2013. Procedimiento de Explotación de Información para la Identificación de Campos anómalos en Base de Datos Alfanuméricas. Revista Latinoamericana de Ingeniería de Software, 1(1): 1-3, ISSN 2314-2642

103

datos alfanuméricos que son outliers. Cabe destacar dos aspectos, primero que se trabaja con datos alfanuméricos obteniendo muy buenos resultados y segundo, que se logra identificar exactamente la fila y la columna donde aparece el outlier. En la sección 2, Materiales y métodos, se describen los algoritmos utilizados y el procedimiento diseñado. En la sección 3, Resultados y discusión, se presentan los resultados obtenidos en la experimentación. En la sección 4, Conclusiones, se identifican los principales logros del presente estudio.

En la sección 5, Referencias, se puede observar el compendio bibliográfico utilizado de referencia

II. MATERIALES Y MÉTODOS El procedimiento propuesto utiliza una serie de pasos para determinar específicamente los campos (fila, columna/ registro, campo) que representa probablemente un dato anómalo; el proceso se aplicó sobre campos alfanuméricos.

A. Algoritmos de inducción El proceso en primera instancia utiliza el algoritmo C4.5 para crear un árbol de decisión para determinar los campos significativos. Para ello el algoritmo realiza particiones en forma recursiva utilizando la estrategia “primero en profundidad” (depthfirst)[11]. En las pruebas sucesivas que realiza, busca aquellas cuyo resultado brindan la mayor ganancia de información. En el caso de atributos discretos la prueba considera una cantidad de resultados teniendo en cuenta el número de valores posibles que puede tomar el atributo. La detección de los atributos significativos dentro de la BD, aplicando algoritmos de Inducción como el algoritmo C4.5, permiten reducir el espacio de búsqueda de datos anómalos a solo aquellos campos que son relevantes en la BD, es decir, aquellos atributos que representan dentro del grupo de datos a los que aportan más información para clasificar al atributo target u objetivo, y poder de esta manera optimizar la performance y funcionamiento del procedimiento que detecta los campos anómalos. Con este conocimiento el experto en el dominio podrá seleccionar los atributos a ser analizados en busca de outliers y descartar otros sin relevancia. (p.e. Nombre, Apellido, etc)

B. Algoritmo basado en la densidad. LOF (Local Outlier Factor)

Dentro del presente procedimiento hay una etapa para determinar la calidad de las filas aplicando LOF (Local Outlier Factor) [12], el cual pertenece al conjunto de técnicas basadas en densidad para la detección de outliers. Esta técnica hace uso de la estimación de densidad de los objetos, para ello, los objetos localizados en regiones de baja densidad y, que son relativamente distantes de sus vecinos, se consideran anómalos.

( )

( )( )( )

( )| |xNx xlrd

ylrd

=xLOFMinPts

MinPtsNy MinPts

MinPts

MinPts

∑∈

Cálculo de LOF (1)

Dada una instancia x, su lrd se define como la inversa de la distancia de alcanzabilidad promedio basada en la vecindad más cercana MinPts de la instancia x. Cuando la densidad de los vecinos de una instancia x es alta o, cuando su densidad es baja, entonces su LOF será grande y puede ser considerado un outlier [10]. El algoritmo LOF determina un factor local de outlier, este factor puede tomar valores entre 0 e ∞, este valor es incorporado a cada tupla para su posterior análisis. Este algoritmo incorporado al procedimiento logra identificar la tupla que posee el campo con datos inconsistentes o con ruido. En particular, LOF es utilizado en el procedimiento para analizar la entrada (E) tomando siempre como referencia los valores existentes en las salidas (S) que corresponden al atributo definido como objetivo o target. Los valores MinPts son ingresados a la herramienta a través de la configuración de parámetros. La configuración de estos parámetros debe realizarse con el asesoramiento de un experto en el dominio así como la elección del valor de LOF resultante. Este último determinará el umbral por el cual un dato será o no un outlier.

C. Teoría de la Información La teoría de la información nace como un modelo matemático enunciado en 1948 por Claude Shannon[13]. El sistema de comunicación propuesto posee una fuente que determina los mensajes a ser transmitidos, un transmisor que codifica el mensaje convirtiéndolo en una señal que se propaga por medio de un canal de transmisión. La señal llega al decodificador que la convierte nuevamente en el mensaje para el destinatario. Este mensaje puede ser idéntico al generado en el emisor, o similar, en el caso que se encuentre sometido el canal de transmisión a una fuente de ruido durante la transmisión del mensaje. La información se mide mediante la entropía, que es un término de la termodinámica que mide el nivel de desorden de un sistema; en teoría de la información, se refiere a la cantidad de información promedio que contienen los símbolos usados. Es decir, cuanto menor probabilidad de aparición tiene un símbolo, mayor es la cantidad de información que el mismo aporta.

Entropía (2) Como puede observarse n la función 2 de entropía de un set discreto de probabilidadesp1; : : : ;pn. Shannon 1943. Esta teoría aplicada en proceso de minería de datos [14] indica la posibilidad de trabajar los datos desde binomios del tipo “mensaje de entrada” (E) y “mensaje de salida” (S) para detectar los outliers en cada atributo. Si consideramos el ejemplo de arrojar un dado (E), sobre esta acción resultante (S) debería existir un número entre 1 y 6. Si esto no es así estaríamos en presencia de un outlier. De esta manera, cuanto menor sea la probabilidad del par (E) – (S) analizado, más tendencia presentará a corresponderse con una inconsistencia. Teniendo en cuenta lo anteriormente mencionado se utiliza LOF para analizar la entrada (E) tomando siempre como



104

referencia los valores existentes en las salidas (S) que corresponden al atributo definido como objetivo o target.

D. Procedimiento propuesto. El procedimiento propuesto consta de cinco pasos los cuales abordan los conceptos vistos anteriormente. La aplicación de algoritmos de inducción en una primer instancia de acuerdo al atributo target u objetivo definido previamente. Una vez identificado el conjunto de atributos representativos del set de datos, teniendo en cuenta los conceptos de teoría de información, por cada uno de ellos se componen pares entradas-salidas (E+S) con cada atributo y el atributo target identificado. Para evitar inconvenientes con los valores nulos, estos son reemplazados por una etiqueta “nulo”, y se aplica LOF como algoritmo basado en la densidad para determinar que aquellos elementos que se encuentran en regiones de baja densidad se consideran anómalos.

Fig. 1. Procedimiento de clasificación utilizando LOF para detectar outliers

A continuación se detallan cada una de las etapas que involucran al procedimiento descripto anteriormente, los mismos pueden verse en el diagrama de la figura 1.

• Paso 1: Se procede a tomar los datos del repositorio, para ello se utilizó la instancia Read CSV de la herramienta utilizada, Rapid Miner [17].

• Paso 2: Luego con la instancia Set Role se indica el atributo target u objetivo.

• Paso 3: Posteriormente con el operador Decision Tree se aplica el algoritmo c4.5 que deriva en el árbol de

decisión que va a utilizarse como pre proceso para la selección de los atributos que son más relevantes para clasificar al target definido.

• Los pasos desde 4.1 a 4.3 se realizan por cada atributo seleccionado a partir del algoritmo de inducción.

o Paso 4.1: Por cada atributo representado en el árbol se ejecuta el sub proceso de minería, el cual arma un bin, conjunto de datos (E)+(S) como se explicó anteriormente, tomando como entrada (E) el atributo seleccionado y como salida (S) el atributo target u objetivo. Esto se realiza en el flujo de minería con el operador Select Attributes.

o Paso 4.2: Los datos que componen al atributo entrada son analizados en busca de valores nulos, los cuales de existir, en la instancia ReplaceMissingValues son reemplazados por una etiqueta para su posterior proceso.

o Paso 4.3: Por último, se aplica LOF al bin (E)+(S) dando como resultado la generación de un atributo outlier

• Paso 5: Se filtran aquellos pares de datos bin (E)-(S) cuyo valor de outlier, al ser distinto de cero (0), nos indica la presencia de un dato anómalo que no aporta información y corresponde a ruido en referencia al target definido.

E. Experimentación Los datos corresponden a las bases de datos de Hongos pertenecientes al repositorio “Machine Learning Repository” de la UCI (University of California - IRVINE) [15]. Es una BD nominal que posee una clasificación de hongos que permiten definir un atributo, objetivo o target que es el campo: “clase” sobre el cual se evaluan los demás atributos. La BD tiene 23 atributos y 8124 tuplas. En la tabla 1 se observan los atributos de la BD.

TABLA 1 ATRIBUTOS DE LA BD HONGOS

Forma _sombrero

Superficie _sombrero

Superficie _sombrero

Magulladuras

Olor Tipo _membrana

Espaciado _membrana

Tamaño _membrana

Color

membrana Forma _tronco

Raiz_tronco Sup_tronco _arriba_anillo

Sup_tronco_ debajo_anillo

ColorTronco _arriba_anillo

ColorTronco _debajo_anillo

Tipo_velo

Color_ velo

Cantidad _anillos

Tipo_anillo

Color_esporas

Poblacion

Habitat

Clase (Target)

Además se realizan diversas pruebas en bases de datos reales obteniendo similares resultados. El software para aplicar los algoritmos de minería es el Rapid Miner [16] y para los resultados se utilizó Calc de Open Office [17]. Cuando se experimenta con Bases de Datos reales que no responden a un tipo de distribución específico, como es este caso, la individualización previa de los campos considerados anómalos se dificulta, por este motivo con el objetivo de

NO

Paso 1: Leer BD

Inicio

Paso 2: Seleccionar atributo objetivo (target)

Si hay atributos

Paso 4.1: Seleccionar atributos par (E) - (S)

Paso 4.2: Reemplazar valores nulos

Paso 4.3: Aplicar LOF a cada par (E) -(S)

Paso 5: Filtrar los

pares (E)-(S) cuyo atributo

outlier calculadoten

ga valor distinto de

cero (0) ó ∞

Fin

Paso 3: Aplicar c4.5 identificando los atributos más significativos

SI

S

Horacio Kuna, Germán Pautsch, Alice Rambo, Martín Rey, José Cortés, Silvina Rolon. 2013. Procedimiento de Explotación de Información para la Identificación de Campos anómalos en Base de Datos Alfanuméricas. Revista Latinoamericana de Ingeniería de Software, 1(1): 1-3, ISSN 2314-2642

105

validar los resultados del procedimiento propuesto se analizó en forma detallada la BD con un experto en hongos comestibles, quien detectó en forma manual los posibles outliers existentes en la BD, encontrándose un total de 59 campos que el experto consideró sospechosos de ser anómalos. En el presente caso de estudio se ha configurado reemplazar en la entrada (E) los valores nulos por la etiqueta “nulo”, de esta manera se mantiene la característica nominal de los datos. Para la instancia DetectOutier (LOF) incorporada dentro del flujo de minería en la herramienta Rapid Miner, los valores de configuración para MinPts se definen como límite inferior en 10 y límite superior en 20 y el cálculo de la función de la distancia que se utiliza para el cálculo de la misma entre dos objetos es la distancia euclidiana. En la figura 2 puede verse el flujo de minería creado en el RapidMiner. Al ejecutar el flujo de minería, LOF detecta los outliers presentes en el atributo seleccionado como (E) incorporando el atributo outlier calculado y colocándole el valor ∞ (infinito). Esto se puede observar en la vista de resultados activando la opción Data View, donde se puede verificar que un valor de outlier distinto de cero o infinito representará ruido en el atributo (E). Como se mencionó anteriormente, cuanto menor sea la probabilidad del par (E) – (S) analizado, mayor es la posibilidad de que corresponda a una inconsistencia. Se forman los “bin” [14] con los atributos de entrada (E) y el atributo target (S) y su cálculo de LOF representando la relación existente entre (E) y el elemento (S). En la teoría la información, cuando Shannon [13] hace referencia a la cantidad de información que aporta el elemento, la cual se corresponde con la probabilidad de que ese elemento aparezca en la salida donde E es el mensaje emitido y S es el mensaje recibido. En el presente proceso el elemento (E) con baja densidad con respecto al elemento (S) representa alta probabilidad de que represente ruido (elemento anómalo). Se utiliza LOF donde la densidad de ese elemento con respecto al atributo target es muy baja, por lo cual indica que es probable que se corresponda con ruido.

III. RESULTADOS El resultado de ejecutar el algoritmo C4.5 permitió definir 5 atributos significativos: espaciado_membrana, forma_sombrero, forma_tronco, olor, tipo_membrana, junto con el atributo target: clase. En la BD de hongos al analizar el atributo forma de sombrero, se encontraron 4 registros con forma de sombrero cónica y clase venenoso identificados como outliers, cabe destacar que no hay otra combinación con forma de sombrero cónica. También aparece el atributo “forma de sombrero” = “acampanado” con “clase” = “venenoso”, los 4 únicos registros con esa combinación se registraron como outliers, todos los demás registros con forma de sombrero acampanada corresponden a la clase ingeribles. Esto se repite en el atributo “olor”, donde el olor es un atributo con mucho peso (marcado por el árbol de decisiones generado en el procedimiento). Sin embargo, difícilmente un hongo que no tenga olor puede ser venenoso. Se detectan 10 casos entre los registros utilizados en esta prueba. En el atributo “tipo membrana” aparecen 18 registros con la combinación “tipo membrana” = “adherida” y “clase” =

“venenoso”, el experto consideró esta combinación como anómala. En la tabla 2, en la columna aciertos se determina en base a los outliers detectados y los existentes en la BD. Como se puede observar en el caso del atributo “forma tronco”, los 12 campos detectados como outliers correspondían a datos nulos.

TABLA II. OUTLIERS DETECTADOS EN LA BASE DE DATOS DE HONGOS

Atributo Cant. datos Outliers detecta-

dos

Outliers existen-

tes Datos nulos Aciertos

espaciado_ membrana 8124 8 8 0 100,00%

forma_sombrero 8124 12 8 0 100,00%

forma_tronco 8124 27 15 12 100,00%

Olor 8124 10 10 0 100,00%

tipo_membrana 8124 18 18 0 100,00% Del total de 59 campos considerados outliers por el experto, el procedimiento detectó el 100% de estos campos.

IV. CONCLUSIONES El procedimiento especificado permite de manera sencilla identificar qué campos y qué atributos presentan algún tipo de inconsistencia. El porcentaje de acierto es mucho mayor al esperado registrándose un 100% de detección de outliers. El procedimiento precisa de un campo clasificador o target para realizar las combinaciones de (E) – (S). En futuras líneas de investigación se plantea probar el comportamiento del presente procedimiento con algoritmos de clusterización.

V. REFERENCIAS [1] Torr P.H.S. and Murray D. W.: Outlier Detection and Motion

Segmentation. Sensor Fusion VI Volume: 2059, Pages: 432-44. Robotics Research Gorup, Department of Engineering Science, University of Oxford Parks Road, Oxford OX1 3PJ, UK. (1993)

[2] Hawkings, D.: Identification of Outliers.Chapman and Hall. London. (1980)

[3] SEMMA. 2008. http://www.sas.com/technologies/analytics/ datamining/miner/semma.html. Vigencia 15/09/08.

[4] CRISP-DM. 2008. http://www.crisp-dm.org/ Vigencia 15/09/08. [5] Pyle, D.: Business Modeling and Business intelligence. Morgan

Kaufmann Publishers (2003) [6] Chandola V., Banerjee A., and Kumar V.: Anomaly Detection:

A Survey. University of Minnesota. Pg 15-58. ACM Computing Surveys, Vol. 41, No. 3, Article 15. (2009).

[7] Bolton, R. And Hand, D.: Unsupervised profiling methods for fraud detection. In Proceedings of the Conference on Credit Scoring and Credit Control VII. (1999)

[8] Teng, H., Chen, K., and Lu, S.: Adaptive real-time anomaly

detection using inductively generated sequential patterns. In Proceedings of the IEEE Computer Society Symposium on Research in Security and Privacy. IEEE ComputerSocietyPress, 278–284. (1990).

[9] Fawcett, T. and Provost, F.: Activity monitoring: noticing interesting changes in behavior. In Proceedings of the 5th ACM SIGKDD International Press, 53–62. Conference on Knowledge Discovery and Data Mining. ACM (1999).



106

[10] Breunig M. Kriegel H., Ng R., Sander J. LOF: Identifying Density-Based Local Outliers. Proc. ACM SIGMOD 2000 Int. Conf. On Management of Data, Dalles, TX, 2000.

[11] Quinlan J. R., C4.5: Programs for Machine Learning. Morgan Kaufmann Publishers, San Mateo, California. EEUU.(1993).

[12] Hu T. and Sungs S. Y.: Detecting pattern-based outliers. Pattern Recognition Letters, vol. 24, no. 16, pp. 3059-3068. (2003).

[13] Shannon C. A Mathematical Theory of Communication. Reprinted with corrections from The Bell System Technical Journal, Vol. 27, pp. 379–423, 623–656, July, October, 1948.

[14] Ferreyra M. Powerhouse: Data Mining usando Teoría de la información. Octubre (2007).

[15] Frank, A. & Asuncion, A. (2010). UCI Machine Learning Repository [http://archive.ics.uci.edu/ml]. Irvine, CA: University of California, School of Information and Computer Science.: últimavisita 20/05/2012.

A. Software Utilizado [16] RapidMiner. Sistema Open Source para minería de datos.

http://rapid-i.com/content/view/26/84/lang,en/ (18-02-2012) [17] Open Office. Calc. Programa de Hoja de Cálculo. Open Source.

http://www.libreoffice.org/features/calc/ (18-02-2012).

Horacio Kuna. Licenciado en Sistemas egresado de la Universidad de Morón, Master en Ingeniería del Software egresado del ITBA y la Universidad Politécnica de Madrid. Profesor Titular, Director del Departamento de Informática y del Programa de Investigación en Computación de la Fac. De Cs.Exactas Químicas y Nat. de la Universidad Nacional de Misiones-Argentina. Docente-Investigador de la Facultad de Ingeniería de la Universidad Nacional de Itapúa-Paraguay. Doctorando de Ingeniería en Sistemas y Computación, Universidad de Málaga-España, DEA aprobado, en desarrollo de tesis.

German Pautch. Licenciado en Sistemas de Información, egresado y actualmente docente de las cátedras Bases de Datos y Trabajo Final de la carrera Licenciatura en Sistemas de Información de la Facultad de Ciencias Exactas, Químicas y Naturales, Universidad Nacional de Misiones. Como no docente, responsable del Departamento de Sistemas de la Dirección de Tecnología para la Gestión de la Facultad de Ciencias Económicas, Universidad Nacional de Misiones

Alice Rambo. Ingeniera en Sistemas. Profesora de Informática. Docente a cargo de la cátedra Inteligencia Artificial y Sistemas Expertos y Modelos y Simulación de la Carrera de Licenciatura en Sistemas de Información. Docente Investigador del Departamento de Informática de la Facultad de Ciencias Exactas Químicas y Naturales de la Universidad Nacional de Misiones

Rey Martín. Licenciado en Sistemas de Información. Docente-Investigador del Departamento de Informática. Facultad de Ciencias Exactas Químicas y Naturales. Universidad Nacional de Misiones.

José Cortes. Alumno avanzado de la carrera de Licenciatura en Sistemas de Información. Investigador del Departamento de Informática. Facultad de Ciencias Exactas Químicas y Naturales. Universidad Nacional de Misiones.

Silvina Rolon. Profesora de Inglés egresada del "Instituto Superior del Profesorado Antonio Ruiz de Montoya" y licenciada en Lengua Inglesa, egresada de la Universidad Nacional del Litoral. Actualmente, estoy trabajando en la Universidad de la Cuenca del Plata como profesora adjunta dictando las cátedras de Inglés I y II en las carreras Lic en Psicología, Lic en Nutrición, Lic en Psicopedagogía y Abogacía.

Hernan Arboleya.. 2013. Propuesta de Ciclo de Vida y Mapa de Actividades para Proyectos de Explotación de Información. Revista Latinoamericana de Ingeniería de Software, 1(3): 107-124, ISSN 2314-2642

107

Propuesta de Ciclo de Vida y Mapa de Actividades para Proyectos de Explotación de Información

Hernán Arboleya Laboratorio de Investigación y Desarrollo en Ingeniería de Explotación de Información

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

Resumen— La Explotación de la Información es una sub-

disciplina informática que le aporta herramientas a la Inteligencia del Negocio [18] para poder transformar la información en conocimiento [15] que sirva de base para llevar a cabo la toma de decisiones dentro de las organizaciones. Dado que este tipo de proyectos se diferencian a los proyectos convencionales de construcción de software y que la metodologías existente para Proyectos de Explotación de Información no contemplan ni tiene en cuenta los riesgos que dentro de los mismos pueden ocurrir, en esta investigación se propone el diseño de un Modelo de Ciclo de Vida especifico que tenga un análisis de los riesgos. Posteriormente se plantea la construcción de un Mapa de Actividades teniendo en cuenta el Modelo de Ciclo de Vida desarrollado y los procesos del Modelo de Procesos seleccionado [25].

Palabras Claves – Explotación de Información, Modelo de Ciclo de Vida, Modelo de Procesos, Mapa de Actividades

I. INTRODUCCION Aquí se presenta una introducción al trabajo de

investigación que se ha realizado: se mencionan objetivos (sección A), luego se define el alcance que va a tener (sección B), se evalúan los fundamentos que dan soporte al mismo (sección C) y se presenta la estructura que presenta la investigación (sección D).

A. Objetivos de la Investigación Esta Investigación tiene como objetivo general la

construcción de un Modelo de Ciclo de Vida que contemple los riesgos existentes en cualquier Proyecto de Explotación de Información (E.I.), teniendo como base la metodología CRISP-DM [6] y, por sobre todo, las mejoras que le ha hecho Vanrell a dicha metodología con la presentación de su Modelo de Procesos, agregándole las actividades pertenecientes a los procesos de Administración de Proyectos [25].

Además, se plantea como objetivo general lograr un Mapa de Actividades teniendo como ejes el Modelo de Ciclo de Vida propuesto y el Modelo de Procesos seleccionado en este trabajo [25].

Por otro lado, esta Investigación posee como objetivos específicos:

• Intentar describir a los Modelos de Ciclo de Vida existentes para desarrollo de software convencional;

• Poder describir la metodología CRISP-DM [6] existente para Proyectos de E.I, mencionar sus alcances, ventajas y sus fases;

• Identificar y describir los procesos del Modelo de Procesos seleccionado [25];

• Seleccionar las tareas adecuadas de la metodología CRISP-DM [6] y de las fases convencionales de cualquier sistema software tradicional para la construcción del Modelo de Ciclo de Vida;

• Construir el Modelo de Ciclo de Vida que tenga en cuenta los riesgos y sirva como base para el diseño de estos particulares estilos de proyectos; y

• Diseñar a partir del Modelo desarrollado y del Modelo de Proceso seleccionado [25] y descripto un Mapa de Actividades donde se marcan que actividades del proceso software se va a ejecutar en un determinado tiempo.

B. Alcance El alcance de este Trabajo de Investigación es establecer

las falencias que posee CRISP-DM [6] para la realización de Proyectos de Explotación de Información justificando la creación de un Modelo de Ciclo de Vida que contemple los riesgos que dentro de los proyectos pueden llegar a ocurrir.

Adicionalmente se lleva a cabo la descripción de los Modelos de Ciclo de Vida existentes tanto para Proyectos Convencionales de Desarrollo de Software como así también para Proyectos de Explotación de Información.

Por otro lado se describen y analizan los Modelos de Procesos de interés para este artículo de investigación.

Al mismo tiempo se incluye la construcción de un Mapa de Actividades que tenga como ejes el Modelo de Ciclo de Vida propuesto y el Modelo de Procesos seleccionado dentro del Trabajo.

C. Fundamentos de la Investigación Dentro de los distintos proyectos que son llevados a cabo

por empresas dedicadas al área de tecnologías de la información se encuentra un conjunto denominado Proyectos de Explotación de Información (E.I.). Estos proyectos son especiales, poseen características únicas que lo diferencian de los proyectos comunes de sistemas.

Para los desarrollos de este estilo de proyectos se cuentan actualmente con distintos tipos de técnicas y metodologías que soportan la puesta en marcha de los mismos. A pesar de ello y por la gran importancia que tiene la información y la utilización de la misma para proveer de conocimiento a las empresas, es necesario tener en cuenta los riesgos que en este tipo de proyectos pueden llegar a ocurrir, para lograr estabilidad y que el proyecto no sufra contratiempos.


108

Es por ello que se detecta la necesidad de desarrollar un Modelo de Ciclo de Vida para este tipo de proyectos, el cual incluya un análisis y trato de los riesgos existentes y resulte eficaz para la empresa que vaya a llevar a cabo este tipo de Proyectos particulares. Además, resulta necesario la construcción de un Mapa de Actividades que determine qué actividades se llevan a cabo y cuales se descartan, y que tenga como ejes el Modelo de Ciclo de Vida a proponer y el Modelo de Procesos para Proyectos de Explotación de Información seleccionado [25]

D. Estructura de la Investigación En la sección 1 (uno) se presenta una Introducción al

trabajo de investigación que se lleva a cabo. En la sección 2 (dos) se describe brevemente en que

constan los Proyectos de E.I., al mismo tiempo se presentan los distintos tipos de Modelos de Ciclo de Vida que se encuentran para Proyectos de Desarrollo Tradicional de Software. Posteriormente se selecciona un Modelo que sirve de base para el desarrollo del Modelo de Ciclo de Vida para Proyectos de E.I. y, se analiza y describe en detalla cada fase de la metodología CRISP-DM [6] que se utiliza para desarrollar Proyectos de este estilo. Al mismo tiempo se analiza COMPETISOFT [19] el cual sirve de base para la construcción del Modelo de Procesos para Proyectos de Explotación de Información que se utiliza en este trabajo [25].

En la sección 3 (tres) se presenta el problema de la presente investigación al poseer la necesidad de tener un Modelo de Ciclo de Vida para estos Proyectos de E.I, el cual sirva para el desarrollo de los mismos pero al mismo tiempo contemple y trate los riesgos.

En la sección 4 (cuatro) se propone una solución para el problema anteriormente descripto. Por lo tanto se lleva a cabo la construcción de un Modelo de Ciclo de Vida que contemple y tenga en cuenta los riesgos existentes en cualquier Proyecto de E.I.. Seguido a esto se construye un Mapa de Actividades que tenga como ejes en primer lugar el Modelo de Ciclo de Vida propuesto y en segundo lugar los procesos presentes en el Modelo de Procesos seleccionado en este trabajo [25].

En el capítulo 5 (cinco) se describen las conclusiones obtenidas a partir del desarrollo de esta Investigación, dando respuesta a los interrogantes de investigación y describiendo las futuras líneas de investigación a desarrollar a partir del mismo.

II. ESTADO DE LA CUESTIÓ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 [22]. Dicho conocimiento es previamente desconocido y puede resultar útil para algún proceso de decisión [23]. La información es un patrimonio muy importante para todas las organizaciones y, la utilización y aprovechamiento de la misma de forma correcta y oportuna, le puede producir infinitos beneficios ya que por medios de procesos de explotación de información los miembros de la organización se puede dotar de conocimiento que resulta indispensable para la toma de decisiones, logrando certeza y eficiencia en las mismas.

En la sección A se describen y analizan los Modelos de Ciclo de Vida que son de interés para esta Investigación (tanto el Modelo de Ciclo de Vida en Espiral de Boehm [1]

como la metodología CRISP-DM [6]). Además, en la sección B, se presentan los Modelos de Procesos que colaboran en esta Investigación: en primer lugar se lleva describe el Modelo de Procesos Competisoft [19] (subsección B.1) y en segundo lugar se analiza y describe el Modelo de Procesos seleccionado por este trabajo [25] (subsección B.2.)

A. Modelos de Ciclo de Vida de interés En esta sección se presentan los Modelos de Ciclo de Vida

disponibles para el Desarrollo de Software tradicional y además se describe la metodología CRISP-DM [6] disponible para Proyectos de E.I. A.1) Modelos de Ciclo de Vida para Desarrollo de Software tradicional

El primer modelo concebido fue el de Desarrollo en Cascada. Este modelo se representa como un simple modelo con forma de cascada de las etapas del software. En este modelo la evaluación del producto software procede a través de una secuencia ordenada de transiciones de una fase a la siguiente según un orden lineal.

Otro Modelo de Ciclo de Vida concebido es el de Prototipado, el cual se utiliza cuando el cliente no tiene una idea muy detallada de lo que necesita, o cuando el ingeniero de software o está muy seguro de la viabilidad de la solución que tiene en mente. Este modelo tiene como objetivo contrarrestar la congelación de requisitos mal comprendidos. El desarrollo en Espiral es un modelo de ciclo de vida del software definido por primera vez por Barry Boehm en 1986 [6]. Las actividades de este modelo se conforman en una espiral, en la que cada bucle o iteración representa un conjunto de actividades. Este Modelo de Ciclo de Vida tiene en cuenta fuertemente el riesgo que aparece a la hora de desarrollar software. Para ello, se comienza mirando las posibles alternativas de desarrollo, se opta por la de riesgo más asumible y se hace un ciclo de la espiral. Este sistema es muy utilizado en proyectos grandes y complejos como puede ser, por ejemplo, la creación de un Sistema Operativo. Al ser un modelo de Ciclo de Vida orientado a la gestión de riesgo se dice que uno de los aspectos fundamentales de su éxito radica en que el equipo que lo aplique tenga la necesaria experiencia y habilidad para detectar y catalogar correctamente los riesgos. Las principales ventajas encontradas en este modelo de ciclo de vida en comparación con otros modelos son que Su rango de opciones permiten utilizar los modelos de proceso de construcción de software tradicionales, su orientación al riesgo evita muchas dificultades, se presta atención a las opciones que permiten la reutilización de software existente, se centra en la eliminación de errores y alternativas poco atractivas, no establece una diferenciación entre desarrollo de software y mantenimiento del sistema, proporciona un marco estable para desarrollos integrados hardware-software, incorpora objetivos de calidad e, integra el desarrollo con el mantenimiento.

Entre las desventajas se puede mencionar que genera mucho tiempo en el desarrollo del sistema, es un modelo costoso y, requiere experiencia en la identificación de riesgos. A.2.) Metodología CRISP-DM Esta metodología define un ciclo de vida de los proyectos de explotación de Información que define las principales fases de un proyecto de este tipo. Estas fases son: Entendimiento de Negocios, Entendimiento de los Datos, Preparación de los Datos, Modelado, Evaluación y


109

Despliegue. A continuación se analizará cada una de esas fases, indicando las actividades y propósitos generales de cada una de las mismas [6]: • Comprensión del negocio (Objetivos y requerimientos

desde una perspectiva no técnica) • Establecimiento de los objetivos del negocio

(Contexto inicial, objetivos, criterios de éxito) • Evaluación de la situación (Inventario de recursos,

requerimientos, supuestos, terminologías propias del negocio,…)

• Establecimiento de los objetivos de la minería de datos (objetivos y criterios de éxito)

• Generación del plan del proyecto (plan, herramientas, equipo y técnicas)

• Comprensión de los datos (Familiarizarse con los datos teniendo presente los objetivos del negocio) • Recopilación inicial de datos • Descripción de los datos • Exploración de los datos • Verificación de calidad de datos

• Preparación de los datos (Obtener la vista minable o dataset) • Selección de los datos • Limpieza de datos • Construcción de datos • Integración de datos • Formateo de datos

• Modelado (Aplicar las técnicas de minería de datos a los dataset) • Selección de la técnica de modelado • Diseño de la evaluación • Construcción del modelo • Evaluación del modelo

• Evaluación (De los modelos de la fase anteriores para determinar si son útiles a las necesidades del negocio) • Evaluación de resultados • Revisar el proceso • Establecimiento de los siguientes pasos o acciones

• Despliegue (Explotar utilidad de los modelos, integrándolos en las tareas de toma de decisiones de la organización) • Planificación de despliegue • Planificación de la monitorización y del

mantenimiento • Generación de informe final • Revisión del proyecto

Esta metodología para proyectos de minería de datos es muy útil para comprender esta tecnología o extraer ideas para diseñar o revisar métodos de trabajo para proyectos de similares características.

A partir del trabajo realizado por Britos [3], se proponen cinco procesos de explotación de información que pueden ser considerados por CRISP-DM dentro de la etapa de Modelado.

Los procesos de explotación de información definidos son los siguientes:

• Descubrimiento de Reglas de Comportamiento • Descubrimiento de Grupos • Ponderación de Interdependencia de Atributos • Descubrimiento de Reglas de Pertenencia a Grupos

• Ponderación de Reglas de Comportamiento o de la Pertenencia a Grupos

El proceso de Descubrimiento de Reglas se utiliza al querer identificar condiciones para obtener resultados del dominio del problema. Puede ser utilizado para descubrir las características del local más visitado por los clientes o establecer las características de los clientes con alto grado de fidelidad a la marca.

El proceso de Descubrimiento de Grupos es útil en los casos en que necesitemos identificar una partición dentro de la información disponible dentro del dominio de un problema.

El proceso de Ponderación de Interdependencia de Atributos se utiliza cuando se desea identificar los factores con mayor incidencia sobre un determinado resultado de un problema. Son ejemplos aplicables a este proceso la determinación de factores que poseen incidencia sobre las ventas o la individualización de atributos clave que convierten en vendible a un determinado producto.

El proceso de Descubrimiento de Reglas de Pertenencia a Grupos es utilizado cuando se necesita identificar las condiciones de pertenencia a cada una de las clases en una partición desconocida pero que se encuentra presente en la masa de información disponible sobre el dominio del problema. Este tipo de proceso puede ser utilizado para la segmentación etaria de estudiantes y el comportamiento de cada segmento o la determinación de las clases de las llamadas telefónicas en una región y caracterización de cada clase.

Finalmente, el proceso de Ponderación de Reglas de Comportamiento de la Pertenencia a Grupos se utiliza cuando se requiere identificar las condiciones con mayor incidencia sobre la obtención de un determinado resultado en el dominio del problema, ya sea por la mayor medida en la que inciden sobre su comportamiento o las que mejor definen la pertenencia a un grupo.

Como ejemplos de este tipo de proceso se puede citar la identificación del factor dominante que incide en el alza de ventas de un producto dado o el rasgo con mayor presencia en los clientes con alto grado de fidelidad a la marca.

B. Modelos de Procesos de Interés En esta sección se describen los distintos Modelos de

Procesos que son de interés para esta investigación: en primer lugar en la subseccion B.1). se analiza y describe al Modelo de Procesos CompetiSoft [19], y posteriormente en la subseccion B.2) se presenta el Modelo de Procesos propuesto por Vanrell [25] en su Trabajo de Tesis. B.1.) Competisoft Se basa inicialmente en MoProSoft [20] el cual es un modelo de procesos para el desarrollo de software creado por encargo de la Secretaría de Economía Mexicana para servir de base a la norma Mexicana para la Industria de Desarrollo y Mantenimiento de Software, e incorporando el método de evaluación EvalProSoft [21] y una división en etapas de madurez de los procesos similar a las identificadas en CMM o CMMI, entre otras pequeñas modificaciones.

Su propósito es fomentar la estandarización de las operaciones de pequeñas y medianas empresas o departamentos internos de desarrollo, a través de la incorporación de las mejores prácticas en gestión e ingeniería de software, esperando “elevar la capacidad de las organizaciones para ofrecer servicios con calidad y alcanzar niveles internacionales de competitividad” [19].


110

El modelo busca ser fácil de entender, fácil de aprender, no costoso en su adopción y ser la base para alcanzar evaluaciones exitosas con otros modelos o normas como ISO/IEC 15504 o CMMI.

Este modelo puede ser utilizado tanto por organizaciones que no cuenten con procesos establecidos, ajustándolo de acuerdo a sus necesidades, como por organizaciones que ya poseen procesos establecidos que pueden utilizarlo como punto de referencia para identificar los elementos que les hace falta cubrir.

La estructura del modelo se encuentra dividida en tres categorías [19]: Alta Dirección (DIR), Gerencia (GER) y Operaciones (OPE) reflejando la estructura de una organización. Estas categorías contienen los procesos de gestión de negocio (DIR), gestión de procesos, gestión de proyectos y gestión de recursos (GER) y administración de un proyecto específico, desarrollo de software y mantenimiento de software (OPE). B.2.) Modelo de Procesos

En su trabajo Modelo de Proceso de Operación para Proyectos de Explotación de Información [24], Vanrell propone un marco teórico para la creación de modelo de procesos de operación para proyectos de explotación de información para PYMEs, siguiendo los lineamientos del modelo de procesos para la industria de software (COMPETISOFT [19]).

Así, propone mantener los procesos definidos en COMPETISOFT [19] como Administración de Proyectos y Desarrollo de Proyectos readecuándolos a los proyectos de explotación de información. Para esto elimina las tareas del proceso de desarrollo y las reemplaza por las fases de CRISP-DM [6] que se relacionan con el desarrollo del proyecto.

La reestructuración de estos dos procesos en el desarrollo de proyectos de Explotación de Información brinda mayor claridad a las tareas de administración ya que, como se menciona anteriormente, las tareas de administración que se encuentran mencionadas en las metodologías evaluadas se encuentran dentro de un mismo proceso de desarrollo.

Esta división no se limita a separar las tareas existentes en las metodologías sino que se construye el nuevo proceso basándose en el proceso de administración utilizado para el desarrollo de software clásico, específicamente el definido en el modelo Competisoft, lo cual enriquece el proceso de administración de proyectos [25]. A este proceso se lo adecuó para responder a las exigencias de los proyectos de Explotación de Información.

Las actividades de administración de proyectos son actividades que deben llevarse en paralelo en procesos separados.

Es por esto que el autor decidió separar algunas de las tareas definidas en el ciclo de desarrollo de CRISP-DM [6] para incluirlas en un ciclo diferente que pasará a formar parte del proceso de administración de proyectos.

III. PROBLEMA En esta sección se incluye en primer lugar el contexto del

problema de la presente investigación (sección A), luego se describe el problema en cuestión (sección B) y por último se llevan a cabo preguntas de investigación (sección C).

A. Contexto del Problema Al intentar llevar adelante diferentes Proyectos de

Explotación de Información se utilizan diferentes metodologías y herramientas para poder desarrollarlos. En la actualidad más allá de proyectos de software tradicional cada día más empresas desarrollan proyectos de explotación de información que les permitirá desarrollar conocimiento el cual beneficiará al momento de la toma de decisiones, por lo que es necesario metodologías y herramientas que puedan estimarlos, analizando riesgos existentes en los mismos y mejorando su calidad. Este artículo de investigación apunta a eso.

B. Descripción del Problema Teniendo en cuenta y, aceptando que los proyectos de

Explotación de Información poseen características particulares y distintas a los proyectos convencionales y tradicionales de software, es necesario contar con un Modelo de Ciclo de Vida para este tipo de Proyectos que se adapte a las necesidades y requerimientos de los mismos.

Teniendo como base las metodologías y modelos de ciclos de vida para proyectos tradicionales de software y contando con la metodología CRISP-DM [6] para Proyectos de Explotación de Información, se ha encontrado que no hay ninguna herramienta o metodología que tenga en cuenta los posibles riesgos que pueden tener este tipo de proyectos.

Teniendo en cuenta este problema de no contar con un Modelo de Ciclo de Vida que sirva para Proyectos de Explotación de Información (teniendo como base las fases descriptas en CRISP-DM [6] necesarias para llevar a cabo este tipo de Proyectos), que tenga en cuenta y analice los riesgos que pueden en ellos ocurrir; se detecta que es necesario construir un Modelo de Ciclo de Vida que tenga en cuenta los riesgos y sirva como base para el diseño de estos particulares estilos de proyectos y al mismo tiempo, diseñar a partir del Modelo desarrollado [25]y del Modelo de Proceso seleccionado y descripto, un Mapa de Actividades donde se marcan qué actividades del proceso software se va a ejecutar en un determinado tiempo.

C. Preguntas de Investigación Teniendo en cuenta el problema planteado surgen los

siguientes interrogantes que se intentan responder a lo largo de este trabajo:

• ¿Es posible construir un Modelo de Ciclo de Vida para Proyectos de Explotación de Información que además de las tareas necesarias para los mismos tenga en cuenta los riesgos?

• ¿Se podrá construir un Mapa de actividades teniendo como ejes el Modelo de Ciclo de Vida a proponer con el Modelo de Procesos descripto en la sección anterior que tenga en cuenta tanto los procesos de Administración como los de Desarrollo?

Luego de presentar estos interrogantes y teniendo en cuenta la problemática descripta en este capítulo, en el siguiente capítulo se presenta la propuesta de un Modelo de Ciclo de Vida adaptado a los Proyectos de Explotación de Información que solucione esta problemática existente y, posteriormente, se lleva a cabo la construcción de un Mapa de Actividades teniendo como ejes el Modelo de Procesos propuesto por Vanrell [25] y el Modelo de Ciclo de Vida desarrollado en el presente Trabajo.


111

IV. SOLUCIÓN Esta sección está compuesta en primer lugar por la

propuesta de un Modelo de Ciclo de Vida para el problema en cuestión (sección A) y, en segundo lugar, por la construcción de un Mapa de Actividades teniendo como ejes el Modelo de Ciclo de Vida propuesto y el Modelo de Procesos seleccionado (sección B).

A. Modelo de Ciclo de Vida Como ya se ha mencionado, se ha tomado la base del

Modelo de Ciclo en Espiral de Boehm readaptando las fases a las actividades descriptas por el Modelo de Procesos desarrollado por Vanrell [25] para Proyectos de Explotación de Información, el cual posee un valor agregado en comparación a la metodología existente para este tipo de Proyectos como es CRIS-DM [6]. Estas actividades corresponden a las 6 fases de dicha metodología: Entendimiento del Negocio, Entendimiento de los Datos, Preparación de los Datos, Modelado, Evaluación y Despliegue.

Básicamente, en cada vuelta del espiral se realizan actividades correspondientes al Modelo de Procesos correspondiente para Proyectos de E.I. [25] luego se planea la próxima iteración, se lleva a cabo un análisis de riesgo y por último se realiza la presentación y desarrollo de un prototipo a partir de las fases de Desarrollo en si del Modelo de Ciclo de Vida. Estas actividades se realizan hasta cubrir todas las fases de la metodología para Proyectos de Explotación de Información.

Entre los ejes Evaluación de alternativas, identificación y resolución de riesgos (análisis de riesgos) y el eje de Desarrollo, verificación del producto del próximo nivel se desarrollan distintos prototipos y simulaciones, modelos y benchmark, tanto para ir viendo con el cliente si lo entendido por el grupo de desarrollo es lo correcto y se está avanzando adecuadamente en el transcurso del proyecto o si hay que modificar algo, como también para ir analizando el rendimiento del sistema y/o de los componentes desarrollados hasta el momento. Teniendo en cuenta lo dicho, en la figura 1 se puede observar el Modelo de Ciclo de Vida desarrollado para cubrir las necesidades planteadas en la sección 3. Este modelo planteado incluye más vueltas al espiral para abarcar todos los procesos del Modelo de Procesos que derivan de las fases de CRISP-DM y para garantizar la no aparición de riesgos y el desarrollo tranquilo del Proyecto.

Se ha determinado que es necesario ilustrar en el Modelo de Ciclo de Vida en Espiral propuesto las tareas y subprocesos correspondientes a la Administración del Proyecto [25]. Estos subprocesos abarcan todo el largo del desarrollo del Proyecto y dan soporte a las actividades de desarrollo propiamente dichas, manteniendo “los Procesos de Desarrollo en movimiento y corregir aquellos desvíos que se produzcan con el fin de lograr una finalización exitosa del proyecto” [25]. Este proceso de Administración que se ubica a lo largo del Modelo de Ciclo de Vida propuesto tiene la función de recolectar información que le sea útil a los procesos de Desarrollo para aumentar la calidad de los mismos permitiendo realizar ajustes y mantener un estándar en la realización de distintos proyectos.

En la primera vuelta del espiral propuesto, en el eje de desarrollo (verificación del producto del próximo nivel), se lleva a cabo la tarea de determinar los Objetivos del Negocio.

Mediante esta actividad, se describen los objetivos primarios del cliente, desde una perspectiva del negocio. Además de los objetivos del negocio primario, allí hay típicamente otras preguntas de negocio relacionadas con lo que al cliente le gustaría administrar. Por otro lado, se describen los criterios del éxito del negocio, los resultados útiles que se desean para el proyecto y bajo qué circunstancias se va a dar como aprobado el desarrollo del proyecto a realizar. Pasando al próximo eje del espiral, se realiza la Planificación de Requisitos y Planificación del Ciclo de Vida del Proyecto de Explotación de Información a realizar.

Teniendo en cuenta la primera iteración, se lleva a cabo un análisis de riesgo (AR1), donde se lleva a cabo el estudio y previsión de futuros riesgos que puedan llegar a ocurrir teniendo en cuenta lo descripto, modelado y desarrollado hasta el momento.

En la segunda vuelta del espiral, situándonos en el eje de Desarrollo, Adaptación y Pruebas, se continúan con las actividades de la fase de Entendimiento del Negocio de la metodología CRISP-DM [6] y tomadas en los Procesos de Desarrollo de Proyectos del Modelo de Procesos de Vanrell [25] para Proyectos de Explotación de Información. En primer lugar se lleva a cabo la Evaluación de la Situación, en la cual se realiza una investigación más detallada sobre los recursos, restricciones, presunciones, y otros factores que deberían ser considerados en la determinación del objetivo de análisis de datos y el plan de proyecto.

Las salidas de esta actividad serán Inventarios de recursos, Requerimientos, presunciones y restricciones, Riesgos y contingencias, Terminología y Costos y beneficios.

Posteriormente a esta actividad y siguiendo con el análisis de la segunda vuelta del espiral propuesto se tiene la Determinación de los Objetivos del Proyecto de Explotación de Información en sí. A diferencia de los Objetivos del Negocio planteados en la primera vuelta, en esta actividad se declaran los objetivos del proyecto en términos técnicos.

Como salida a esta actividad se obtienen los Objetivos del Proyecto de Explotación de Información (descripción de las salidas intencionadas del proyecto que permiten el logro de los objetivos de negocio) y los Criterios de Éxito del Proyecto de Explotación de Información (definición de los criterios de un resultado exitoso para el proyecto en términos técnicos).

Luego de la descripción de los Objetivos del Proyecto de Explotación de Información se debe desarrollar un Plan de Proyecto, en el cual se especifican los pasos a ser realizados durante el resto del proyecto, incluyendo la selección inicial de herramientas y técnicas.

Las salidas de esta actividad son el Plan de Proyecto en sí, donde se listan las etapas a ser ejecutadas en el proyecto, juntos con su duración, recursos requeridos, entradas, salidas, y dependencias; y además la Evaluación de Herramientas y Técnicas.

Finalizando con las tareas de la segunda vuelta del espiral y siguiendo situados en el eje de Desarrollo, Adaptación y Pruebas, se realiza al final una Validación de los Objetivos, donde se analizan los objetivos planteados para el Proyecto de Explotación de Información y se determina si cumple técnica y funcionalmente con lo que el cliente ha solicitado. Superando esta actividad, se pasa al eje de Planeamiento de la Siguiente Fase, donde se realiza la Planificación de la Selección de Datos.


112

Fig. 1. Modelo de Ciclo de Vida en Espiral propuesto

Teniendo en cuenta la segunda iteración, se lleva a cabo un

análisis de riesgo (AR2), donde se lleva a cabo el estudio y previsión de futuros riesgos que puedan llegar a ocurrir teniendo en cuenta lo descripto, modelado y desarrollado hasta el momento.

Luego de la segunda iteración, del Análisis de Riesgo 2 (AR2) y teniendo como referencia los procesos que corren en paralelo y a lo largo de todo el Modelo de Ciclo de Vida como son las Simulaciones, los Modelos y los Benchmarks, como así también los Subprocesos de Administración de Proyectos [25] se pasa a la tercera iteración partiendo del Eje de Desarrollo, Adaptación y Pruebas.

Durante esta iteración se llevan a cabo tareas correspondientes a la Fase de Entendimiento de los Datos de la Metodología CRISP-DM [6] y de los Procesos de Desarrollo de Proyectos del Modelo de Procesos [25] para Proyectos de Explotación de Información.

En primer lugar se lleva a cabo la Recolección de Datos primarios o iniciales, donde se accede a los datos listados en los Recursos del Proyecto y donde se incluye carga de datos, si es necesario para la comprensión de los datos.

Como salida perteneciente a esta actividad se obtiene el Informe de Colección de Datos Inicial, donde quedan listados el conjunto de datos obtenido junto con sus posiciones, los métodos usados para adquirirlos, algunos de los problemas encontrados y algunas de las resoluciones alcanzadas.

Posteriormente se realiza la actividad de Descripción de los Datos donde se examina las propiedades "gruesas" o "superficiales" de los datos e informe adquiridos en los resultados.

La salida de esta actividad es un Informe de descripción de datos donde se describen los datos que han sido adquiridos, incluyendo el formato de los datos, la cantidad de datos (por ejemplo, el número de registros y campos en cada tabla), los


113

identificadores de los campos, y cualquier otro rasgo superficial que ha sido descubierto.

En tercer lugar se realiza la Exploración de los Datos donde se dirigen interrogantes de minería de datos usando preguntas, visualización, y técnicas de reporte incluyendo la distribución de atributos claves relacionados entre pares o pequeños números de atributos, los resultados de simples agregaciones, las propiedades de las subpoblaciones significativas, y análisis estadísticos simples. Como salida a esta actividad se obtiene un Informe de Exploración de Datos donde se describen los resultados de esta tarea, incluyendo primeras conclusiones o hipótesis iniciales y su impacto sobre el resto del proyecto.

Por último se lleva a cabo una Verificación de la Calidad de los Datos, donde se examina la calidad de los datos, realizando preguntas como: ¿Los datos están completos? ¿Son correctos, o estos contienen errores y, si hay errores, que tan comunes son estos? ¿Hay valores omitidos en los datos? Si es así, ¿cómo se representan estos, donde ocurre esto, y que tan comunes son estos? [6]

Al finalizar las actividades de la tercera vuelta en el espiral posicionados en el eje de Desarrollo, Adaptación y Pruebas, se pasa al eje de Planeamiento de la siguiente fase llevando a cabo la Planificación de Preparación de los Datos.

Teniendo en cuenta la tercera iteración y situados en el eje de Evaluación de Alternativas e identificación y resolución de riesgos, se lleva a cabo un análisis de riesgo (AR3), donde se lleva a cabo el estudio y previsión de futuros riesgos que puedan llegar a ocurrir teniendo en cuenta lo descripto, modelado y desarrollado hasta el momento

En la cuarta vuelta del espiral propuesto se llevan a cabo las tareas pertenecientes a la fase de Preparación de los Datos de la metodología CRISP-DM [6] y de los Procesos de Desarrollo del Modelo de Procesos [25] para Proyectos de Explotación de Información.

En primer lugar se realiza la Selección de Datos, donde se decide que datos serán usados para el análisis. Los criterios incluyen la importancia a los objetivos de la minería de datos, la calidad, y las restricciones técnicas como límites sobre el volumen de datos o los tipos de datos.

Como salida correspondiente a dicha tarea se obtiene un razonamiento para inclusión o exclusión de datos y los motivos de esa determinación [6].

Posteriormente se lleva a cabo la Limpieza de Datos, que implica la selección de los subconjuntos de datos limpios, la inserción de datos por defectos adecuados, o técnicas más ambiciosas tales como la estimación de datos faltantes mediante modelado.

La salida asociada a esta tarea es un Informe de la Limpieza de Datos, donde se describe que decisiones y acciones fueron tomadas para dirigir los problemas de calidad de datos informados.

A continuación se construyen las operaciones de preparación de datos tales como la producción de atributos derivados o el ingreso de nuevos registros, o la transformación de valores para atributos existentes en la actividad Construcción de Datos.

Las salidas correspondientes a esta actividad son Atributos derivados (atributos nuevos que son construidos de uno o más atributos existentes en el mismo registro) y los Registros generados (creación de registros completamente nuevos).

Luego, en la actividad Integración de Datos, se definen los métodos por el cual la información es combinada de múltiples tablas o registros para crear nuevos registros o valores. Esta actividad tiene como salida la Combinación de Datos, en la cual se realiza la unión simultánea de dos o más tablas que tienen información diferente sobre el mismo objeto.

En cuarto lugar, se lleva a cabo el Formateo de Datos, en el cual se realizan modificaciones principalmente sintácticas hechas a los datos que no cambian su significado, pero podría ser requerido por la herramienta de modelado. A partir de dicha actividad se obtienen los Datos formateados.

Por último y para finalizar las actividades pertenecientes a la fase de Preparación de los Datos, se lleva a cabo la Validación de los mismos para determinar si los mismos son realmente correctos y servirán para el desarrollo del Proyecto de Explotación de Información.

Pasando al siguiente eje, se realiza la Planificación del Modelo y se lleva a cabo un análisis de riesgo (AR4), donde se lleva a cabo el estudio y previsión de futuros riesgos que puedan llegar a ocurrir teniendo en cuenta lo descripto, modelado y desarrollado hasta el momento

A partir de aquí, en la quinta vuelta del espiral, comienza las actividades pertenecientes a la fase de Modelado correspondiente a la metodología CRISP-DM [6] y de los Procesos de Desarrollo del Modelo de Procesos [25] para Proyectos de Explotación de Información. En esta fase se producen iteraciones, ya que se construirán n cantidad de modelos y prototipos hasta alcanzar el modelo que más se adecue a las pretensiones y requerimientos que el cliente ha brindado.

En primer lugar se lleva a cabo la Selección de Técnica de Modelado 1, donde se elige la técnica de modelado específico, por ejemplo, un árbol decisión construido con C4.5. Como salida a esta actividad se obtiene la Técnica de Modelado seleccionada y Presunciones del Modelado.

A continuación de la Selección de la Técnica de Modelado 1 se realiza la Generación de Prueba de Diseño 1, donde se genera un procedimiento o el mecanismo para probar la calidad y validez del modelo. A partir de dicha actividad se genera la Prueba de Diseño, donde se describe el plan intencionado para el entrenamiento, la prueba, y la evaluación de los modelos.

Posteriormente, se realiza la primer Construcción del Modelo, donde se ejecuta la herramienta de modelado sobre el conjunto de datos preparados para crear uno o más modelos. Al finalizar dicha actividad se obtienen los parámetros de ajustes (Lista de los parámetros y sus valores escogidos, también con el razonamiento para elegir los parámetros de ajustes), el/los modelo/s en sí (modelos reales producidos por la herramienta de modelado, no un informe) y la descripción del/os modelo/s presentado/s (descripción de los modelos obtenidos e informe sobre la interpretación de los modelos y documentar cualquier dificultad encontrada con sus significados).

Al finalizar las 3 actividades mencionadas anteriormente, se lleva a cabo la primer Evaluación del Modelo (Evaluación del Modelo 1) donde se interpreta los modelos según el conocimiento de dominio, los criterios de éxitos de minería de datos, y el diseño de prueba deseado, se juzga el éxito de la aplicación del modelado y se descubre técnicas más adecuadas. Se evalúa los modelos según los criterios de evaluación. La salida es la Evaluación del/os Modelo/s en sí


114

donde se resumen los resultados de esta tarea, se enlista las calidades de los modelos generados y se clasifica su calidad en relación con cada otro; y se obtienen los parámetros de ajustes revisados, donde se revisan los parámetros de ajuste para la siguiente corrida en la tarea de Construcción del Modelo.

Al finalizar este cuarto de vuelta, se realiza la Planificación de Evaluación y Despliegue 1 y en el eje de Evaluación de alternativas e identificación y resolución de Riesgos se lleva a cabo el Análisis de Riesgo numero 5 (AR5).

Luego del AR5, se realiza el Prototipo 1, donde se lleva a cabo la demostración del Modelo construido y se analiza si cumple o no con lo que el cliente solicito.

Dependiendo de la satisfacción o cumplimiento del Modelo, se realizan 2 vueltas más al espiral, con las mismas actividades descriptas anteriormente, hasta que finalmente el Modelo construido y desarrollado sea el adecuado para cumplir con los Objetivos planteados en un primer momento en el Proyecto.

Esas vueltas en blanco son previas a la conformación del Modelo final y aprobado y cada una de ellas es acompañada por un Análisis de Riesgo y la construcción de un Prototipo. Además, los subprocesos de Administración de Proyectos [25] acompañan estas tareas en paralelo.

En la anteúltima vuelta del espiral se lleva a cabo la ultima construcción del Modelo (Construcción Modelo n), donde n es la variable que indica cuantas veces se han llevado a cabo las actividades de la fase de Modelado hasta finalmente cumplir con los establecido.

Por último se pasa al eje de Planeamiento de la Siguiente fase para realizar la Planificación y Despliegue final (n), se pasa al siguiente eje realizando el Análisis de Riesgo n+4 (ya que previo al Prototipo 1 y AR5 se han llevado a cabo 4 análisis de Riesgo) y se construye el Prototipo final o Prototipo Operacional, que muestra el Modelo final o definitivo.

En la última vuelta del espiral propuesto se llevan a cabo las actividades de las fases de Evaluación y Despliegue de la metodología CRISP-DM [6] y de los Procesos de Desarrollo del Modelo de Procesos [25] para Proyectos de Explotación de Información.

En primer lugar se Evalúan los Resultados, donde se analiza el grado al que el modelo responde a los objetivos de negocio y procura determinar si hay alguna decisión de negocio por el que este modelo es deficiente. Además verifica otros resultados generados por la minería de datos.

La salida a esta actividad es la Evaluación de los Resultados de la minería de datos en lo que concierne a criterios del éxito del negocio, y por otro lado, los Modelos finalmente aprobados.

Por otro lado, en segundo lugar, se realiza la Revisión del Proceso, donde los modelos resultantes pasan a ser satisfactorios y a satisfacer las necesidades de negocio y se lleva a cabo una revisión más cuidadosa de los compromisos de la minería de datos para determinar si hay cualquier factor importante o tarea que de algún modo ha sido pasada por alto. Como salida a esta actividad se tiene la Revisión del Proceso propiamente dicha, donde se resume la revisión de proceso y destaca las actividades que han sido omitidas y/o aquellas que deberían ser repetidas.

Luego de la Revisión del Proceso, se Determinan los Próximos Pasos, donde según los resultados de la evaluación y la revisión de proceso, el equipo de proyecto decide como

proceder. En esta instancia el equipo decide si hay que terminar este proyecto y tomar medidas sobre el desarrollo si es apropiado, tanto iniciar más iteraciones, o comenzar nuevos proyectos de minería de datos.

Las salidas a esta actividad es una Lista de Posibles Acciones y Decisión (se describe la decisión en cuanto a cómo proceder, junto con el razonamiento).

Pasando a las actividades de Despliegue, en primer lugar se lleva a cabo el Desarrollo del Plan, donde de acuerdo al desarrollo de los resultados de minería de datos en el negocio, esta tarea toma los resultados de la evaluación y determina una estrategia para el desarrollo. La salida de esta actividad es el Plan propiamente dicho.

Luego del Plan descripto anteriormente se realiza un Plan de Supervisión y Mantenimiento, ya que son cuestiones importantes si los resultados de minería de datos son parte del negocio cotidiano y de su ambiente.

Al finalizar esta tarea se obtiene el Plan propiamente dicho que resume la estrategia de supervisión y mantenimiento incluyendo los pasos necesarios y como realizarlos.

Posteriormente se pasa a la actividad de Producción de Informe Final, donde el líder del proyecto y su equipo sobrescribe un informe final. Según el plan de desarrollo, este informe puede ser sólo un resumen del proyecto y sus experiencias o esto puede ser una presentación final y comprensiva de los resultados de minería de datos.

La salida a esta tarea es el Informe definitivo y la Presentación final, donde puede haber una reunión en la conclusión del proyecto en el que los resultados son presentados verbalmente al cliente.

Por último, se lleva a cabo una Revisión General del Proyecto, donde se evalúa lo que fue correcto y lo que se equivocó, lo que fue bien hecho y lo que necesita para ser mejorado. La salida correspondiente es la Documentación de la experiencia de realización del Proyecto, donde se resumen las experiencias importantes ganadas durante el proyecto.

B. Mapa de Actividades Se presentan en las figuras 2 y 3 el Mapa de Actividades

construido y propuesto, teniendo como ejes en primer lugar el Modelo de Ciclo de Vida propuesto que tuvo como base el Modelo de Ciclo de Vida en Espiral que propuso Boehm y las fases del Modelo de Procesos desarrollado por Vanrell para Proyectos de Explotación de Información, agregándole procesos de Administración de Proyectos los cuales la metodología existente, CRISP-DM [6], no poseía, y en segundo lugar el Modelo de Procesos de Vanrell propiamente dicho [25].

Como se puede observar, se dividen las actividades de los Procesos de Administración de Proyectos y los Procesos de Desarrollo de Proyectos, tal como describe Vanrell en su trabajo [25]. Por otro lado, cada columna es una fase o actividad que se lleva a cabo en el Modelo de Ciclo de Vida propuesto en esta investigación, marcando la división por vuelta.

Las actividades de Administración de Proyectos no están ocupados del desarrollo propiamente dicho del Proyectos de Explotación de Información, sino que son procesos en paralelo y que tienen la función de recolectar información que le sea útil a los procesos de Desarrollo para aumentar la calidad de los mismos permitiendo realizar ajustes y mantener un estándar en la realización de distintos proyectos llevando a


115

cabo la conversión de procesos caóticos y aislados en procesos repetitivos y controlados [25]. Por ello mismo se puede ver que las actividades de Administración de Proyectos abarcan todo el Ciclo de Vida, soportando y manteniendo las actividades de Desarrollo de Proyectos del Modelo de Vanrell.

En la primera vuelta del espiral la única fase que se lleva a cabo es la de Objetivos del Negocio, donde se describen los objetivos primarios del cliente, desde una perspectiva del negocio. Teniendo en cuenta los procesos y tareas que se definen en el Modelo de Procesos para Proyectos de Explotación de Información propuesto por Vanrell [25] se puede decir que dentro de los Procesos de Administración de Proyectos se encuentran la Planificación/Entendimiento del Negocio, la Realización, la Evaluación y Control y el Cierre/Entrega.

En primer lugar, dentro de la Planificación /Entendimiento del Negocio, la única actividad que se realiza es la de Entendimiento del Negocio. Esto se debe a que la salida correspondiente a esta tarea es la Base de Conocimiento del Negocio, cuyas actividades previas son la de por medio de organigramas, redes de expertos e informes relacionados con el negocio, desarrollar gráficos organizacionales, identificar personas claves, sponsor interno, si existe comité de gobierno, las unidades del negocio que serán impactadas, etc. Por otro lado, otra salida correspondiente a esta tarea son los Objetivos del Negocio propiamente dicho, describiendo el problema en términos generales, evaluando el estado actual del proyecto, especificando los requerimientos y preguntas del negocio, determinando los beneficios esperados en términos de negocio. Por último, dentro de aquí se determinan los Criterios del Éxito del negocio y se identifican quienes determinan dichos criterios. Por otro lado, no se han marcado las actividades de Definir el proceso específico basado en la descripción del proyecto y el proceso de desarrollo y mantenimiento; Definir el protocolo de entrega con el cliente; Definir ciclos y actividades con base en la descripción del proyecto y en el proceso específico; Determinar tiempo estimado para cada actividad; Elaborar plan de adquisiciones y capacitación; Establecer el equipo de trabajo; Establecer el calendario de actividades; Calcular el costo estimado del proyecto; Evaluación de la situación; Producir un Plan de Proyecto; Producir un Plan de Desarrollo; y Formalizar el inicio de un nuevo ciclo del proyecto dado que se ha entendido que dichas actividades no corresponden al Negocio en sí, sino mas a los Objetivos del Proyecto de Explotación de Información en sí mismo.

En la tabla 1 se presentan las descripciones de los códigos de las fases del Modelo de Ciclo de Vida propuesto, utilizados en el Mapa de Actividades.

Por otro lado, dentro de la Realización, se ha definido que no se lleva a cabo ninguna actividad en la Fase de Objetivos del Negocio, ya que son actividades más relacionadas con el Proyecto de Explotación en sí, su realización y con el seguimiento y monitoreo que se realiza durante el desarrollo del Proyecto.

En tercer lugar, dentro de Evaluación y Control, se ha determinado que la única actividad que se hará en esta Fase es la de Generar el reporte de seguimiento del proyecto, dado que dentro de la misma se evalúan si los objetivos del negocio y del uso del modelo puede cambiar a lo largo del tiempo y se documenta lo más completamente posible el problema inicial que el modelo está intentando resolver. Por otro lado, las

tareas de Evaluar el cumplimiento del plan de proyecto y plan de desarrollo; y Analizar y controlar los riesgos no se contemplan en esta Fase, dado que son más ligados al Plan del Proyecto de Explotación de Información en sí que del Negocio.

TABLA I. CÓDIGOS DEL MAPA DE ACTIVIDADES

Código Descripción O.N. Objetivos del Negocio E.Sit. Evaluación de la Situación O.P. Objetivos del Proyecto de E.I. P.P. Plan De Proyecto Val.O. Validación de Objetivos R.D. Recolección de Datos D.D. Descripción de Datos E.D. Exploración de Datos Ver.CD. Verificación Calidad de Datos S.D. Selección de Datos L.D. Limpieza de Datos C.D. Construcción de Datos I.D. Integración de Datos F.D. Formateo de Datos Val.D. Validación Datos S.T.M. Selección Técnica Modelado G.P.D. Generación Prueba de Diseño C.M. Construcción Modelo E.M. Evaluación Modelo E.R. Evaluación Resultados R.P. Revisión Proceso D.P.P. Determinación Próximos Pasos D.P. Desarrollo Plan P.S.M. Plan Supervisión y Mantenimiento I.P. Informe Producto R.Py. Revisión Proyecto

Por último, dentro del Cierre / Entrega, se definió que no

se lleva ninguna tarea dentro de esta Fase, dado que estas actividades tienen más que ver con las últimas fases del Modelo de Ciclo de Vida, donde se lleva a cabo el Cierre y Entrega del Proyecto de Explotación de Información desarrollado.

Dentro de los Procesos de Desarrollo de Proyecto definido por Vanrell en su Modelo de Procesos [25], se encuentran Entendimiento del Negocio, Entendimiento de los Datos, Preparación de los Datos, Modelado, Evaluación y Entrega.

En primer lugar, dentro del subproceso Entendimiento del Negocio, se ha definido que su actividad Determinar las metas del Data Mining ha de llevarse en la Fase Objetivos del Negocio del Modelo de Ciclo de Vida, dado que se trasladan los interrogantes del negocio a metas del proyecto de Explotación de Información y se realiza informe indicando una traducción de los interrogantes a metas de negocio. Por otro lado, dentro de los demás subprocesos correspondiente a los procesos de Desarrollo del Proyecto, se ha determinado que no se lleva a cabo ninguna tarea dentro de esta fase, dado que las mismas tienen más que ver con fases siguientes y más avanzadas del Modelo de Ciclo de Vida propuesto.

En la segunda vuelta del Modelo en Espiral cuenta con las siguientes fases: Evaluación de la Situación, Objetivos del Proyecto de Explotación de Información, Plan del Proyecto y Validación de Objetivos.

Empezando a analizar en detalle a la fase de Evaluación de la Situación, se puede determinar que dentro del subproceso Planificación/Entendimiento del Negocio correspondiente a los Procesos de Administración de Proyectos, las únicas actividades que se llevan a cabo son la de Entendimiento del


116

Negocio y Evaluación de la Situación, ya que se entiende que dentro de ellas tareas tales como evaluar el estado actual del proyecto, identificar necesidades y expectativas de los usuarios, identificar los recursos hardware disponible, establecer si los planes de mantenimiento de hardware entran en conflicto con la disponibilidad de hardware necesaria para el proyecto de Explotación de Información, identificar las fuentes de datos, chequear las disponibilidades de herramientas y técnicas, identificar analistas de mercado, entre otras, resultan necesarias realizarlas en dicha frase

Siguiendo con el análisis correspondiente a la fase de Evaluación de la Situación, se dictamina que las actividades pertenecientes tanto al SubProceso Realización, Evaluación y Control, y Cierre /Entrega, no se llevan a cabo dentro de esta fase puesto que la misma es prematura y dichas actividades corresponden cuando el Proyecto está más avanzado y se encuentra en etapas posteriores. Dentro de los Procesos de Desarrollo de Proyectos, en el único Proceso que se llevan a cabo actividades en esta Fase es en el de Entendimiento del Negocio.

Dentro de este SubProceso se lleva a cabo la tarea de Determinar las metas del Proyecto de Explotación de Información. Tareas de SubProcesos siguientes tales como Entendimiento de los Datos, Preparación de los Datos, Modelado, Evaluación y Entrega no se llevan a cabo en esta Fase del Modelo de Ciclo de Vida ya que es un fase inicial y dichos procesos corresponden a tareas posteriores.

Siguiendo con el análisis de la segunda vuelta del Modelo de Ciclo de Vida en Espiral propuesto, la fase que se analiza a continuación es la de Objetivos del Proyecto de Explotación de Información.

Dentro de los Procesos de Administración de Proyectos, las únicas tareas que se llevan a cabo en el SubProceso Planificación/Entendimiento del Negocio son las de Entendimiento de Negocio y Definir el proceso específico basado en la descripción del proyecto y el proceso de desarrollo y mantenimiento. Se ha definido esto ya que tareas tales como evaluar la descripción del proyecto, evaluar el proceso de desarrollo y mantenimiento, describir el problema en términos generales, clasificar prerrequisitos del proyecto, especificar los beneficios esperados y definir el proceso específico a utilizar, son necesarias desarrollarlas en esta fase para dejar en claro los objetivos propios del Proyecto.

Por otro lado, las tareas correspondiente al SubProceso de Realización no se realiza ninguna salvo las de recibir y analizar las solicitudes de cambio del cliente y realizar reuniones con el equipo de trabajo y cliente para reportar avances y tomar acuerdos, ya que recibir solicitudes de cambio del cliente y las Realizaciónes de reuniones con el cliente pueden afectar a los Objetivos establecidos para el Proyecto de Explotación de Información.

Dentro del SubProceso de Evaluación y Control, la actividad que se lleva a cabo es la de generar el reporte de seguimiento del cliente, ya que se analiza que cosas pueden cambiar a futuro. Por otro lado, dentro del SubProceso de Cierre/Entrega, no se lleva a cabo ninguna actividad ya que se entiende que corresponden a fases posteriores.

Siguiendo con el análisis de esta fase, dentro de los Procesos de Desarrollo de Proyecto, el único SubProceso que se relaciona con esta fase es la de Entendimiento del Negocio. Es así ya que determinar las metas del proyecto de Explotación de Información específica los criterios de

valoración de los modelos, determina los benchmarks para la evaluación de criterios y especifica criterios a valoración de criterios subjetivos, entre otras tareas.

Las otras actividades que corresponden a los demás SubProcesos de Desarrollo de Proyectos, se entiende que no corresponden a esta fase ya que son actividades que se deben desarrollar fases posteriores.

La siguiente fase a analizar es la de Plan del Proyecto. Dentro de los Procesos de Administración del Proyecto, en esta fase, salvo en la tarea de Entendimiento del Negocio, se llevan a cabo todas las tareas tanto del SubProceso de Planificación /Entendimiento del Negocio como de Realización. Se lleva a cabo esta asunción ya que todas esas actividades influyen en el Plan de Proyecto desarrollado, tales como la generación de una base de conocimiento del negocio, la definición de los objetivos del negocio, definición de criterios del éxito, desarrollo de Plan de Entrega, Plan de Desarrollo, Plan de Adquisiciones, armado de Calendario de actividades, estimación de costos, generación de inventario de recursos, riesgos y contingencias, descripción de la terminología empleada, lista de técnicas, reporte de seguimiento y monitoreo.

Dentro de los Procesos de Administración de Proyectos, las únicas tareas que se llevan a cabo en el SubProceso Planificación/Entendimiento del Negocio son las de Entendimiento de Negocio y Definir el proceso específico basado en la descripción del proyecto y el proceso de desarrollo y mantenimiento. Se ha definido esto ya que tareas tales como evaluar la descripción del proyecto, evaluar el proceso de desarrollo y mantenimiento, describir el problema en términos generales, clasificar prerrequisitos del proyecto, especificar los beneficios esperados y definir el proceso específico a utilizar, son incluidas dentro de esta fase.

Por otro lado, las tareas correspondiente al SubProceso de Realización no se realiza ninguna salvo las de recibir y analizar las solicitudes de cambio del cliente y realizar reuniones con el equipo de trabajo y cliente para reportar avances y tomar acuerdos, ya que recibir solicitudes de cambio del cliente y las Realizaciones de reuniones con el cliente pueden afectar y es importante tener en cuenta los Objetivos establecidos para el Proyecto de Explotación de Información.

Dentro del SubProceso de Evaluación y Control, la actividad que se lleva a cabo es la de generar el reporte de seguimiento del cliente, ya que se analiza que cosas pueden cambiar a futuro. Por otro lado, dentro del SubProceso de Cierre/Entrega, no se lleva a cabo ninguna actividad ya que se entiende que corresponden a fases posteriores.

Siguiendo con el análisis de esta fase, dentro de los Procesos de Desarrollo de Proyecto, el único SubProceso que se relaciona con esta fase es la de Entendimiento del Negocio.

Es así ya que determinar las metas del proyecto de Explotación de Información específica los criterios de valoración de los modelos, determina los benchmarks para la evaluación de criterios y especifica criterios a valoración de criterios subjetivos, entre otras tareas.


La siguiente fase a analizar es la de Plan del Proyecto.


117

Fig. 2. Mapa de Actividades Propuesto para Administración de Proyectos


118

Fig. 3. Mapa de Actividades Propuesto para Desarrollo de Proyectos

Dentro de los Procesos de Administración del Proyecto, en esta fase, salvo en la tarea de Entendimiento del Negocio, se llevan a cabo todas las tareas tanto del SubProceso de Planificación / Entendimiento del Negocio como de Realización. Se lleva a cabo esta asunción ya que todas esas actividades influyen en el Plan de Proyecto desarrollado, tales como la generación de una base de conocimiento del negocio, la definición de los objetivos del negocio, definición de criterios del éxito, desarrollo de Plan de Entrega, Plan de Desarrollo, Plan de Adquisiciones, armado de Calendario de actividades, estimación de costos, generación de inventario de recursos, riesgos y contingencias, descripción de la terminología empleada, lista de técnicas, reporte de seguimiento y monitoreo.

Dentro de los Procesos de Administración de Proyectos, las únicas tareas que se llevan a cabo en el SubProceso Planificación/Entendimiento del Negocio son las de Entendimiento de Negocio y Definir el proceso específico basado en la descripción del proyecto y el proceso de desarrollo y mantenimiento. Se ha definido esto ya que tareas tales como evaluar la descripción del proyecto, evaluar el proceso de desarrollo y mantenimiento, describir el problema en términos generales, clasificar prerrequisitos del proyecto, especificar los beneficios esperados y definir el proceso específico a utilizar, son incluidas dentro de esta fase.

Por otro lado, las tareas correspondiente al SubProceso de Realización no se realiza ninguna salvo las de recibir y analizar las solicitudes de cambio del cliente y realizar reuniones con el equipo de trabajo y cliente para reportar avances y tomar acuerdos, ya que recibir solicitudes de cambio del cliente y las Realizaciones de reuniones con el cliente pueden afectar y es importante tener en cuenta los Objetivos establecidos para el Proyecto de Explotación de Información.

Dentro del SubProceso de Evaluación y Control, la actividad que se lleva a cabo es la de generar el reporte de

seguimiento del cliente, ya que se analiza que cosas pueden cambiar a futuro. Por otro lado, dentro del SubProceso de Cierre/Entrega, no se lleva a cabo ninguna actividad ya que se entiende que corresponden a fases posteriores.

Siguiendo con el análisis de esta fase, dentro de los Procesos de Desarrollo de Proyecto, el único SubProceso que se relaciona con esta fase es la de Entendimiento del Negocio. Es así ya que determinar las metas del proyecto de Explotación de Información específica los criterios de valoración de los modelos, determina los benchmarks para la evaluación de criterios y especifica criterios a valoración de criterios subjetivos, entre otras tareas.


La siguiente fase a analizar es la de Plan del Proyecto. Dentro de los Procesos de Administración del Proyecto, en esta fase, salvo en la tarea de Entendimiento del Negocio, se llevan a cabo todas las tareas tanto del SubProceso de Planificación /Entendimiento del Negocio como de Realización. Se lleva a cabo esta asunción ya que todas esas actividades influyen en el Plan de Proyecto desarrollado, tales como la generación de una base de conocimiento del negocio, la definición de los objetivos del negocio, definición de criterios del éxito, desarrollo de Plan de Entrega, Plan de Desarrollo, Plan de Adquisiciones, armado de Calendario de actividades, estimación de costos, generación de inventario de recursos, riesgos y contingencias, descripción de la terminología empleada, lista de técnicas, reporte de seguimiento y monitoreo.

Por otro lado, dentro de la Evaluación y Control, la actividad que se lleva a cabo es la de generar el reporte de seguimiento del proyecto, ya que afecta al Plan de Proyecto. Las actividades de cierre/entrega no se realizan en esta fase ya que no corresponde a esta altura.


119

Dentro de los Proceso de Desarrollo del Proyecto, en el único SubProceso donde se realiza una actividad en esta fase es en el de Entendimiento del Negocio, debido a que las metas del proyecto de Explotación de Información y los Criterios del Éxito del Proyecto de E.I. quedan registrados en la conformación del Plan de Proyecto.

Las demás actividades correspondientes a los demás SubProcesos de Desarrollo del Proyecto no se llevan a cabo en esta fase ya que son actividades posteriores a las configuraciones del Plan de Proyecto.

La última fase dentro de la segunda vuelta que se lleva a cabo en el Modelo de Ciclo de Vida en Espiral propuesto es la de Validación de Objetivos.

Dentro de los Procesos de Administración del Proyecto, en esta fase al igual que la fase anterior, salvo en la tarea de Entendimiento del Negocio y la de definir el proceso específico basado en la descripción del proyecto y el proceso de desarrollo y mantenimiento, se desarrollan todas las tareas tanto del SubProceso de Planificación /Entendimiento del Negocio como de Realización. Se asume esto puesto que todas esas actividades influyen en el Plan de Proyecto desarrollado, tales como la generación de una base de conocimiento del negocio, la definición de los objetivos del negocio, definición de criterios del éxito, desarrollo de Plan de Entrega, Plan de Desarrollo, Plan de Adquisiciones, armado de Calendario de actividades, estimación de costos, generación de inventario de recursos, riesgos y contingencias, descripción de la terminología empleada, lista de técnicas, reporte de seguimiento y monitoreo. Dentro de la Evaluación y Control se lleva a cabo la tarea de generar el reporte de seguimiento del cliente, ya que se evalúan si los objetivos pueden cambiar a lo largo del Proyecto.

En los Procesos de Desarrollo del Proyecto la única actividad que se realiza en esta fase es la de determinar las metas del Data Mining, correspondiente al SubProceso de Entendimiento del Negocio. Las demás actividades de los restantes 5 SubProcesos no corresponden a esta fase ya que como se ha mencionado en otras fases, esas tareas son ligadas a etapas posteriores

La primera fase de la tercera vuelta del espiral es la de Recolección de Datos. Teniendo en cuenta los Procesos de Administración de Proyectos, dentro de la Planificación/Entendimiento del Negocio, la única tarea que se lleva a cabo es la de Evaluación de la Situación. Esto es así ya que tareas como identificar las fuentes de datos, identificar los distintos tipos de fuentes de datos, identificar fuentes de conocimiento, chequear la disponibilidad de técnicas y herramientas, identificar los administradores de sistemas, bases de datos, entre otras, se vinculan estrechamente con esta Fase.

Por otro lado, las actividades anteriores y posteriores de este SubProceso no se realizan en esta fase del Modelo ya que se entiende que deben hacerse en otras fases debido al tiempo de desarrollo del Proyecto. Las actividades pertenecientes a los SubProcesos de Realización, Evaluación y Control, y Cierre/Entrega, no se vinculan con esta fase puesto que son actividades que se llevan a cabo en fases posteriores y no se relacionan con la Recolección de Datos propiamente dicha.

Entrando en los Procesos de Desarrollo de Proyectos, se define que las actividades pertenecientes al SubProceso de Entendimiento del Negocio no se llevan a cabo en esta fase ya que son tareas propias de las 2 primeras vueltas del espiral.

Sin embargo, la tarea de Reunir los Datos Iniciales del SubProceso de Entendimiento de los Datos sí se realiza ya que se identifica cual es la información necesaria, se chequea si la información está disponible, se especifica el criterio de selección, se seleccionan datos dentro de tablas o archivos, se evalúa como se debe adquirir datos faltantes, se analiza si los datos contienen entradas de texto libre evaluar, si es necesario codificarla para el modelado o su es necesario agrupar entradas específicas, y se describe como se debe extraer los datos entre otras tareas.

Por otro lado, las demás actividades de este SubProceso y de los SubProcesos de Preparación de los Datos, Modelado, Evaluación y Entrega no se llevan a cabo ya que son tareas de fases siguientes.

La próxima fase a analizar es la de Descripción de Datos. Empezando por los Procesos de Administración de Proyectos, la única tarea que se lleva a cabo es la de Evaluación de la Situación, dentro del SubProceso de Planificación/Entendimiento del Negocio. Esto se define así ya que se entre otras tareas se identifican las fuentes de datos, se describe el conocimiento (background), se listan las asunciones de la calidad de los datos, se chequean las restricciones generales en torno a los datos, se cheque la accesibilidad que los datos poseen, etc. Las actividades siguientes de este SubProceso no se asignan a esta fase ya que se entiende que tienen que ver más con el Negocio que con los Datos y su análisis en sí. Además, los demás SubProcesos no se relacionan con esta Fase ya que cubren mas a otras que se llevan a cabo más adelante.

Considerando los Procesos de Desarrollo de Proyecto, las actividades del SubProceso de Entendimiento de Negocio no se relaciona con esta fase dado que son actividades de fases anteriores. En cambio, la actividad de describir los datos del SubProceso de Entendimiento de los datos sí, ya que se identifican los datos y métodos de captura, se acceden a las fuentes de datos, se usan análisis estadísticos, se chequea el volumen de datos, se chequea la disponibilidad y accesibilidad, se chequean los tipos de atributos, se analiza la correlación de atributos, entre otras tareas. Por otro lado, las demás actividades de este SubProceso y las actividades de Preparación de los Datos, Modelado, Evaluación y Entrega se realizan en fases posteriores, cuando el Proyecto esté más avanzado en cuanto a su desarrollo.

Siguiendo con las fases correspondientes a la tercera vuelta, se analiza la Exploración de Datos. En primer lugar, dentro de los Procesos de Administración de Proyectos, se lleva a cabo en el SubProceso de Planificación /Entendimiento del Negocio la tarea de Evaluación de la Situación, tal como las dos fases anteriores de esta vuelta del Modelo de Ciclo de Vida en Espiral, ya que se chequean los derechos de acceso a las fuentes de datos, se chequean las técnicas de acceso a los datos, si el conocimiento relevante es accesible, etc. Por otro lado, las actividades de los SubProcesos siguientes no se realizan en esta fase ya que dan soporte y se relacionan con fases más avanzadas.

Teniendo en cuenta los Procesos de Desarrollo de Proyectos, el SubProceso que lleva a cabo una actividad en esta fase es la de Entendimiento del Negocio. Dentro del mismo, se realiza la exploración de datos, o sea analizar propiedades de atributos interesantes en detalle, identificar características de sub-poblaciones, considerar y evaluar información y resultados en los reportes de descripción de


120

datos, formular hipótesis e identificar acciones, transformar hipótesis en metas de Explotación de Información si es posible, clarificar las metas de Explotación de Información o hacerlas más precisas y realizar análisis básicos para verificar las hipótesis. Las actividades de los SubProcesos siguientes se realizan en fases más adelantadas por su avance en el desarrollo del Proyecto de E.I.

La última fase a analizar en esta vuelta del Modelo de Ciclo de Vida en Espiral es la de Verificación Calidad de Datos. En primer lugar, teniendo en cuenta los Procesos de Administración de Proyectos, se lleva a cabo la tarea de Evaluación de la Situación del SubProceso de Planificación/Entendimiento del Negocio, ya que se listan las presunciones de calidad de los datos. Luego, dentro del SubProceso de Realización, se realiza la tarea de recolectar reportes de actividades y mediciones y sugerencias de mejora y productos de trabajo. Se informa que esta actividad se realiza en esta fase dado que se generan un informe con los datos recolectados, se realizan los ajustes necesarios, se promueven las sugerencias de mejora en caso de ser adecuadas, se recolectan productos de trabajo, entre otras. Estas actividades influyen en la verificación de la calidad de datos. Las actividades de los demás SubProcesos correspondientes a la Administración de Proyecto corresponden a fases más avanzadas.

Por otro lado y finalizando con el análisis de la tercera vuelta del Modelo de Ciclo de Vida en Espiral, la actividad que se desarrolla en esta fase dentro de los Procesos de Desarrollo de Proyectos, es la de verificar la calidad de datos propiamente dicho, correspondiente al SubProceso de Entendimiento de los Datos. Dentro de esta actividad se incluyen tareas tales como identificar valores especiales y catalogar su significado, chequear claves, chequear cubrimientos, identificar atributos faltantes, chequear desviaciones, dar significado a la falta de datos, planear como lidiar con los ruidos, detectar tipos de ruidos, entre otros. Este tipo de actividad es propia de esta fase y de ninguna otra. Las demás actividades de los SubProcesos continuos corresponden a fases siguientes del Modelo de Ciclo de Vida propuesto.

La primera fase en analizar de la cuarta vuelta del espiral es la de Selección de Datos. Teniendo en cuenta los Procesos de Administración de Proyectos, en el único SubProceso donde se lleva a cabo una actividad es en la de Planificación /Entendimiento del Negocio. La actividad que se realiza en esta fase es la de Evaluación de la Situación, dado que registran las fuentes de datos, fuentes de conocimientos, se describen los datos, se identifican tipos de fuentes de conocimientos, entre otras. Las actividades de los demás SubProcesos no han de llevarse a cabo en dicha fase dado que no se relacionan directamente con la selección de datos propiamente dicha y además, dan soporte a fases posteriores en el desarrollo del proyecto.

Teniendo en cuenta los Procesos de Desarrollo de Proyectos, esta fase realiza las siguientes actividades pertenecientes al SubProceso de Preparación de los Datos: Tareas Preparatorias y Selección de Datos. Con relación a la primer actividad mencionada, se ha de llevar a cabo la reunión de datos producidos por la fase de preparación de datos y, con respecto a la selección de datos propiamente dicha, se recolectan datos adicionales apropiados, se realizan test de significancia, se reconsideran los criterios de selección de datos, se seleccionan diferentes subconjuntos de datos, se

documentan razones de exclusión e inclusión, etc. Se ha definido estas actividades para esta fase ya que se relacionan con la selección de datos y no las demás ya que son propias de fases siguientes, como limpieza, construcción, integración y formateo.

En segundo lugar, analizando las actividades vinculadas con la fase de Limpieza de Datos, se define que tal como con la Selección de Datos, el único SubProceso de Administración de Proyecto que tiene actividades en esta fase es la de Planeamiento /Entendimiento del Negocio, ya que se realiza la Evaluación de la Situación y la Producción de un Plan de Desarrollo. La evaluación de la situación da soporte a la generación de limpieza de los datos obtenidos con las listas de asunciones y de riesgos producidas. Además, en la Producción de un Plan de Desarrollo quedan registrados los pasos críticos y técnicas de limpieza que se llevan a cabo.

Por otro lado, teniendo en cuenta los Procesos de Desarrollo de Proyectos, se realiza la actividad de limpiar los datos pertenecientes al SubProceso de Preparación de los Datos, dado que se reconsidera como lidiar con los tipos de ruidos, se corrigen, remueven e ignoran los ruidos, se decide como lidiar con valores especiales y se reconsidera la selección de datos con base a experiencia de limpieza. Como se ha mencionado en fases anteriores, las actividades tanto de SubProceso de Modelado y Evaluación están relacionadas con fases más avanzadas del espiral.

Siguiendo con el análisis de la cuarta vuelta del Modelo de Ciclo de Vida en Espiral propuesto en este capítulo, la siguiente fase en ser analizada es la de Construcción de Datos. Con respecto a los Procesos de Administración de Proyectos, se lleva a cabo dentro del SubProceso de Preparación /Entendimiento del Negocio la actividad de Evaluación de la Situación y la de Producción de un Plan de Desarrollo. Ambas actividades dan soporte a nivel administrativo a la construcción de datos y sus técnicas de transformaciones.

Teniendo en cuenta los Procesos de Desarrollo de Proyectos, se lleva a cabo la actividad de construir los datos, dentro del SubProceso de Preparación de los Datos, chequeando los mecanismos de construcción disponibles, decidiendo si es mejor realizar la construcción dentro o fuera de la herramienta, reconsiderando los criterios de selección de datos, decidiendo si hay que normalizar atributos, decidiendo como pueden ser construidos o imputados atributos faltantes, realizando pasos de transformación o chequeando técnicas disponibles de generación de registros si son necesarios.

La siguiente fase de esta vuelta del espiral es la de Integración de Datos. Entrando en los Procesos de Administración de Proyecto, las actividades que se realizan tal como en las fases anteriores son las de Evaluación de la Situación y la de Producción de un Plan de Desarrollo, del SubProceso de Preparación/Entendimiento del Negocio. Tal como se menciono en la fase anterior, estas actividades dejan sentadas a nivel administrativo las técnicas de integración de los datos. Las actividades posteriores a estos procesos corresponden a fases avanzadas del proyecto desarrollado.

Por otro lado, dentro de los Procesos de Desarrollo de Proyectos, específicamente en el SubProceso de Preparación de los Datos, se realiza la actividad de integrar los datos propiamente dicha. Esto es ya que se chequean si las facilidades de integración son capaces de integrar las fuentes de entrada como es requerido, se integran las fuentes y almacenan los resultados, y se reconsideran los criterios de


121

selección de los datos basándose en las experiencias de integración.

La quinta fase en ser analizada de esta vuelta del Modelo en Espiral es la de Formateo de Datos. Teniendo en cuenta los Procesos de Administración de Proyectos, se realiza la actividad de Evaluar la Situación y la de Producir un Plan de Desarrollo del SubProceso de Planeamiento / Entendimiento del Negocio.

Dentro de los Procesos de Desarrollo de Proyecto, se realiza la actividad de formatear los datos que se realiza en el SubProceso de Preparación de los Datos. Las tareas que se llevan a cabo son las de reordenar los atributos si es requerido por las herramientas utilizadas, reordenar los registros si es necesario, reformatear valores para satisfacer los requerimientos de las herramientas utilizadas, entre otras.

La última fase de esta vuelta del espiral es la de Validación de los Datos. Con respecto a los Procesos de Administración de Proyectos se realizan las actividades de evaluar la situación, producir un plan de proyecto, producir un plan de desarrollo y formalizar el inicio de un nuevo ciclo del proyecto. A nivel gerencial y administrativo se da soporte por medio de estas actividades a la validación de los datos obtenidos y seleccionados, quedando registrados que los datos son validos y cumplen con los requerimientos del Proyecto. Por medio de la validación exitosa de los datos, se da inicio al ciclo correspondiente del proyecto y se les comunica a los interesados.

Por otro lado, dentro de los Procesos de Desarrollo de Procesos, la actividad que se vincula con esta fase es la de formatear los datos, dado que es la última actividad del SubProceso de Preparación de los Datos, y por medio de esta ya quedan los datos listos para ser usados en la construcción del modelo y finalmente se validan para corroborar si realmente cumplen con los requerimiento establecidos en el proyecto.

En la quinta vuelta del Modelo de Ciclo de Vida en Espiral propuesto en este capítulo se encuentran las siguientes fases: Selección Técnica de Modelado, Generación Prueba de Diseño, Construcción Modelo y Evaluación del Modelo.

Comenzando por la fase de Selección Técnica de Modelado, se puede observar que dentro de los Procesos de Administración de Proyectos, específicamente en el SubProceso de Realización, posee la actividad de acordar las tareas con el equipo del trabajo, puesto que se revisan las tareas a realizar, se evalúan los roles y se distribuyen las tareas. Por medio de estas actividades se brinda soporte a las actividades de desarrollo propias como la selección de la técnica a utilizar para desarrollar el modelo.

Teniendo en cuenta los Procesos de Desarrollo de Proyectos y dentro del SubProceso Modelado, se realiza la actividad de seleccionar la técnica de modelado propiamente dicha, mediante la cual se decide sobre la técnica apropiada para ejercitar teniendo en mente la herramienta seleccionada, se define cualquier asunción hecha por la técnica acerca de los datos, se comparan las asunciones con las hechas en el reporte de descripción de dato, y se asegura que las asunciones se mantienen y regresar a la fase de preparación de datos si es necesario.

En segundo lugar, siguiendo con la fase de Generación Prueba de Diseño y dentro de los Procesos de Administración de Proyectos se realizan las actividades de acordar las tareas con el equipo del trabajo y acordar la distribución de

información, pertenecientes al SubProceso Realización. Por medio de estas tareas se distribuyen las tareas, se identifica la información requerida para cada tarea y cada plan de prueba del modelo a construir, y se distribuye la información a todo el equipo responsable del desarrollo del Proyecto. Las actividades siguientes de este SubProceso y de los SubProcesos siguientes corresponden a fases más avanzadas donde el Modelo ya fue desarrollado y lo que queda son tareas tales como evaluación y entrega al cliente.

Por otro lado, dentro de los Procesos de Desarrollo de Proyectos, se realiza la actividad de generar el diseño del test, en el SubProceso de Modelado, donde se chequean los diseños de test existentes para cada meta de E.I. de forma separada, se deciden los pasos necesarios y se preparan los datos requeridos para testear. Las siguientes actividades de estos Procesos corresponden a fases siguientes donde el Modelo ya está construido.

La tercera fase de esta vuelta del espiral es la de Construcción del Modelo. En los Procesos de Administración de Proyectos se llevan a cabo las actividades de acordar las tareas con el equipo de trabajo, acordar la distribución de la información y revisar con el responsable la Descripción del producto, el equipo de trabajo y el calendario, pertenecientes al SubProceso de Realización. Por medio de estas tareas, en esta fase donde se ejecuta la técnica y se construye el modelo, a nivel administrativo se distribuye la información a cada responsable, se reúne con el equipo responsable del desarrollo del modelo, se revisa la Descripción del producto, se revisa el cumplimiento del calendario y se realizan correcciones si son necesarios. Como se ha mencionado anteriormente en la explicación del Modelo de Ciclo de Vida propuesto, en esta vuelta del espiral se cicla, donde los distintos prototipos desarrollados y Evaluaciones hechas sobre el modelo juegan un papel importante.

Adicionalmente, en los Procesos de Desarrollo de Proyecto, se realiza la actividad de construir el modelo propiamente dicho, actividad situada en el SubProceso de Modelado. Mediante esta actividad se setean los parámetros iniciales, se documentan razones de selección, se ejecuta la técnica seleccionada, se procesan los resultados, se describen las características del modelo, se da una explicación detallada del mismo, y se brinda una interpretación del mismo. En esta fase ya se encuentra desarrollado y validado el modelo, por lo que las actividades siguientes tendrán que ver con la Evaluación y Entrega.

La última fase de esta vuelta del espiral es la de Evaluación del Modelo. Dentro de los Procesos de Administración de Proyectos, específicamente en el SubProceso de Realización, se realizan las siguientes actividades: revisar con el responsable la descripción del producto, el equipo de trabajo y el calendario, revisar cumplimiento del plan de adquisiciones y capacitación, administrar subcontratos, recolectar reportes de actividades y mediciones y sugerencias de mejora y productos de trabajo, registrar costo real del proyecto, revisar el registro de rastreo basado en los productos de trabajo recolectados y revisar los productos terminados durante el proyecto. Por medio de estas actividades y una vez desarrollado el Modelo, se realizan correcciones si son necesarias, se controla cumplimiento, se realizan ajustes necesarios del plan de adquisición, se revisan subcontratos, se recolectan reportes de actividades y mediciones, se recolectan los productos del trabajo, se revisa


122

el costo real del proyecto, se revisa el registro de rastreo de los producto, y finalmente se revisan los productos terminados durante el Proyecto y se registran los mismos.

Además, entrando en los Procesos de Desarrollo de Proyectos, se realiza la actividad de evaluar el modelo, perteneciente al SubProceso de Modelado, por la cual se evalúan los resultados con respecto a los criterios de evaluación, se testean los resultados de acuerdo a la estrategia de testeo, se comparan la evaluación de los resultados y su interpretación, se seleccionan los mejores modelos, se interpretan los resultados en términos de negocios, se chequea el impacto para las metas de E.I., se chequea la confiabilidad de los resultados, se valoran los resultados, y se ajustan los parámetros para obtener un mejor modelo en caso de ser necesario o se cree conveniente.

En la última vuelta del espiral, en la fase de Evaluación de Resultados y dentro de los Procesos de Administración de Proyectos, se realiza la actividad de evaluar el cumplimiento del Plan de Proyecto y Plan de Desarrollo, correspondiente al SubProceso de Evaluación y Control. Por medio de esta actividad se evalúa el cumplimiento del plan de proyecto, se ajusta el mismo, se generan informes, se evalúa el plan de plan de desarrollo y se ajusta el mismo. Estas actividades se desarrollan una vez construido el modelo, por lo que las actividades anteriores no pertenecen a esta fase y fases siguientes tienen más que ver con fases avanzadas de la Evaluación y de la Entrega/Cierre.

Por otro lado, en los Procesos de Desarrollo de Proyectos, se lleva a cabo la actividad de evaluar resultados, incluida en el SubProceso de Evaluación. En esta actividad se entienden los resultados del Proyecto de E.I., se interpretan los resultados, se evalúan y valoran los resultados, se compara la evaluación, se chequea si existen nuevos objetivos del negocio y finalmente se obtiene la aprobación de los modelos.

En segundo lugar, la fase de Revisión Proyecto posee incluida dentro de los Procesos de Administración de Proyecto, la actividad de evaluar el cumplimiento del Plan de Proyecto y Plan de Desarrollo, correspondiente al SubProceso de Evaluación y Control. En esta actividad se revisa y evalúa el Proyecto y los Planes de los mismos, tanto el de Desarrollo como el de Proyecto en sí.

Teniendo en cuenta los Procesos de Desarrollo de Proyectos, se realiza la actividad de revisar el proyecto del SubProceso de Evaluación, en la cual se da un examen del proceso de E.I. utilizado, se analiza el proceso de E.I., se evalúa como puede ser mejorado, se identifican fallas, se identifican pasos faltantes, se identifican alternativas y se revisan resultados del Proyecto de E.I. con respecto a los criterios del éxito del negocio.

La siguiente fase de esta vuelta del espiral es la de Determinación de los Próximos Pasos, en la cual por medio de los Procesos de Administración de Proyectos y más específicamente en el SubProceso de Evaluación y Control, lleva a cabo la tarea de evaluar el cumplimiento del plan de proyecto y plan de desarrollo, donde genera informes de ajustes del plan de desarrollo y plan de proyecto, y genera un Reporte de Seguimiento / Plan de Monitoreo y Mantenimiento, previo paso al Cierre y Entrega del Proyecto.

Por otro lado, en los Procesos de Desarrollo de Proyectos (SubProceso de Evaluación), se incluye la actividad de determinar próximos pasos, donde analiza el potencial de despliegue de cada resultado, se estima el potencial de mejora

del proceso actual, se chequea recursos sobrantes para determinar si permiten realizar iteraciones del proceso adicionales, se recomiendan alternativas de continuidad, se refina el plan de proceso, se ranquean las posibles acciones y se selecciona y documenta las razones de elección.

La cuarta fase correspondiente a esta última vuelta del Modelo de Ciclo de Vida en Espiral es la de Desarrollo Plan. Teniendo en cuenta los Procesos de Administración de Proyecto, se define que posee las actividades de evaluar el cumplimiento del plan de proyecto y plan de desarrollo, analizar y controlar los riesgos, generar el reporte de seguimiento del proyecto (SubProceso de Evaluación y Control) y formalizar la terminación del proyecto o ciclo, llevar a cabo el cierre del contrato con subcontratistas, generar el reporte de mediciones y sugerencias de mejora, y planear la entrega(SubProceso Cierre/Entrega). Estas actividades generar un Plan de Seguimiento y Plan de Monitoreo y Mantenimiento, documentos de aceptación, informes de subcontratistas, reportes de mediciones y sugerencias de mejoras.

En los Procesos de Desarrollo de Proyectos, se lleva a cabo la actividad de producir un reporte final, perteneciente al SubProceso de Entrega. En esta actividad se identifican que reportes son necesarios para finalizar el Proyecto en cuestión.

En quinto lugar se encuentra la fase de Plan Supervisión y Mantenimiento, donde por medio de los Procesos de Administración de Proyectos, lleva a cabo las tareas de recibir y analizar las solicitudes de cambio del cliente, realizar reuniones con el equipo de trabajo y cliente para reportar avances y tomar acuerdos (SubProceso de Realización), evaluar el cumplimiento del plan de proyecto y plan de desarrollo, analizar y controlar los riesgos, generar el reporte de seguimiento del proyecto (SubProceso de Evaluación y Control) y formalizar la terminación del proyecto o ciclo, llevar a cabo el cierre del contrato con subcontratistas, generar el reporte de mediciones y sugerencias de mejora, y planear la entrega (SubProceso Cierre/Entrega). Por medio de estas tareas se obtiene a nivel administrativo el Plan propiamente dicho que resume la estrategia de supervisión y mantenimiento incluyendo los pasos necesarios y como realizarlos.

Teniendo en cuenta los Procesos de Desarrollo de Proyectos, se lleva a cabo la tarea de producir un reporte final (SubProceso Entrega), donde se esboza la estructura del informe, se seleccionan los descubrimientos a ser incluidos en el reporte, se informa la estrategia de supervisión y mantenimiento y se escribe finalmente el reporte.

La siguiente fase del Modelo de Ciclo de Vida es la de Informe Producto, donde por medio de los Procesos de Administración de Proyectos lleva a cabo las siguientes actividades: recibir y analizar las solicitudes de cambio del cliente, realizar reuniones con el equipo de trabajo y cliente para reportar avances y tomar acuerdos (SubProceso de Realización), evaluar el cumplimiento del plan de proyecto y plan de desarrollo, analizar y controlar los riesgos, generar el reporte de seguimiento del proyecto (SubProceso de Evaluación y Control) y formalizar la terminación del proyecto o ciclo, llevar a cabo el cierre del contrato con subcontratistas, generar el reporte de mediciones y sugerencias de mejora, y planear la entrega (SubProceso Cierre/Entrega). Por medio de estas actividades se generan los Reportes de Seguimiento y Mantenimiento, se realiza Informe de SubContratistas, Reportes de Mediciones, se documenta el


123

proceso de E.I. específico, se resumen los detalles para futuros Proyectos similares, se realiza un informe de los contratos, se comunica la finalización a todos los interesados, entre otras tareas.

Teniendo en cuenta los Procesos de Desarrollo de Proyectos, se lleva a cabo la actividad de producir un reporte final perteneciente al SubProceso de Entrega. En esta actividad se escribe el reporte e informe final y se lleva a cabo la presentación final del Proyecto.

La última fase del Modelo de Ciclo de Vida en Espiral propuesto en este capítulo y que se analiza con respecto al Mapa de Actividades construido es la de Revisión Proyecto. Teniendo en cuenta los Procesos de Administración de Proyectos, se llevan a cabo las siguientes tareas: recibir y analizar las solicitudes de cambio del cliente, realizar reuniones con el equipo de trabajo y cliente para reportar avances y tomar acuerdos (SubProceso de Realización), evaluar el cumplimiento del plan de proyecto y plan de desarrollo, analizar y controlar los riesgos, generar el reporte de seguimiento del proyecto (SubProceso de Evaluación y Control) y formalizar la terminación del proyecto o ciclo, llevar a cabo el cierre del contrato con subcontratistas, generar el reporte de mediciones y sugerencias de mejora, y planear la entrega (SubProceso Cierre/Entrega). Por medio de estas actividades se generan los reportes e informes finales y se lleva a cabo el Plan de Entrega, donde se planifica la entrega de los productos generados.

Con respecto a los Procesos de Desarrollo de Proyectos, se realiza la actividad de producir un reporte final perteneciente al SubProceso de Entrega, donde se lleva a cabo la Presentación Final del Proyecto y donde se documenta todo el desarrollo del Proyecto para futuras experiencias y trabajos similares a realizar.

V. CONCLUSIÓN En esta sección se detallan las conclusiones obtenidas de la

presente investigación, mencionando en un principio los aportes brindados (sección A) para finalmente destacar las futuras líneas de investigación a partir del problema mencionado dentro de este articulo de investigación (sección B).

A. Aportes del artículo de Investigación Se ha comprobado que si bien la metodología existente

para Proyectos de Explotación de Información, CRISP-DM [6], es la más completa para desarrollo de este tipo de Proyectos, hay fases que no cubre tal como los Procesos de Administración. Por ello, se ha detectado necesaria la utilización del Modelo de Procesos desarrollado por Vanrell [25], el cual le brinda un valor agregado a la metodología CRISP-DM al incluirle los Procesos de Administración. Estos procesos de Administración tienen la función de recolectar información que le sea útil a los procesos de Desarrollo para aumentar la calidad de los mismos permitiendo realizar ajustes y mantener un estándar en la realización de distintos proyectos llevando a cabo la conversión de procesos caóticos y aislados en procesos repetitivos y controlados.

Además de esto, se detecta que la metodología CRISP-DM no posee un Análisis enfocado a los Riesgos. Tal como ocurre en los Desarrollos Convencionales de Software, en los Proyectos de Explotación de Información también pueden ocurrir Riesgos y es fundamentar detectarlos y tratarlos

tempranamente para que no haya inconvenientes en el Desarrollo del Proyecto.

Finalmente, en este Articulo de Investigación se ha desarrollado un Modelo de Ciclo de Vida que sirve para llevar a cabo Proyectos de Explotación de Información, tomando la mejora que ha hecho Vanrell [25] a la metodología CRISP-DM [6] con los SubProcesos de Administración de Proyectos, y realizando un enfoque a los Riesgos tomando como base el Modelo de Ciclo de Vida en Espiral desarrollado por Boehm para Proyecto Convencionales [1].

Se puede dictaminar que el Modelo propuesto en este Articulo de Investigación es superador a la Metodología CRISP-DM [6] ya que tiene en cuenta los SubProcesos de Administración de Proyectos que se realizan a lo largo de todo el desarrollo del mismo, y principalmente le agrega un Análisis enfocado a los Riesgos que dentro de los mismos pueden ocurrir.

Por otro lado se ha construido un Mapa de Actividades, el cual se encuentra constituido por las actividades pertenecientes a los SubProcesos de Administración y Desarrollo de Proyecto correspondiente al Modelo de Procesos realizado por Vanrell [25], y por las fases que se han conformado en el Modelo de Ciclo de Vida en Espiral construido en este articulo.

A partir de allí, se definieron las actividades del Modelo de Procesos que se realizan en cada fase del Modelo de Ciclo de Vida, justificando su elección.

Por otro lado, las respuestas a los interrogantes planteados en la sección 3 pueden ser resumidas en las siguientes conclusiones: • Se ha logrado llevar a cabo la construcción de un Modelo

de Ciclo de Vida que es útil para el desarrollo de distintos Proyectos de Explotación de Información y que posee un Análisis de Riesgo, cuya característica no existía en las metodologías existentes hasta el momento.

• Finalmente, en este artículo se ha construido un Mapa de Actividades que posee como ejes en primer lugar las actividades del Modelo de Procesos desarrollado por Vanrell [25], tanto de Administración como de Desarrollo, y en segundo lugar las fases pertenecientes al Modelo de Ciclo de Vida propuesto en el presente Trabajo.

B. Futuras líneas de Investigación Se plantea como futuras líneas de trabajos poder llevar a

cabo el desarrollo de una cantidad más amplia y variada de Proyectos de Explotación de Información para continuar evaluando la viabilidad de las Propuestas desarrolladas en el presente Artículo de Investigación.

Si bien el Mapa de Actividades contempla todas las actividades pertenecientes al Modelo de Procesos desarrollado por Vanrell [25], resulta un punto de interés seguir analizándolo para evaluar las actividades aplicadas en cada fase del Modelo de Ciclo de Vida. Además, por medio de casos de prueba, se puede verificar la falta de alguna actividad dentro de alguna fase del Modelo de Ciclo de Vida construido.

II. REFERENCIAS [1] Boehm, B.W., C. Abts, A.W. Brown, S. Chulani, B.K.Clark, E.

Horowitz, R. Madachy, D. Reifer, B. Steece.(2000). Software Cost Estimation with COCOMO II, Prentice-Hall, Englewood Cliffs Boehm, Barry W., TRW Defense Systems Group (1988), A Spiral Model of Software Development and Enhancement


124

[2] Britos, P. (2008a). Procesos de Explotación de Información Basados en Sistemas Inteligentes. Tesis Doctoral Universidad Nacional de la Plata. La Plata.Buenos Aires. Argentina.

[3] Britos, P., Dieste, O., García-Martínez, R. 2008. Requirements Elicitation in Data Mining for Business Intelligence Projects. En Advances in Information Systems Research, Education and Practice. David Avison, George M. Kasper, Barbara Pernici, Isabel Ramos, Dewald Roode Eds. (Boston: Springer), IFIP Series, 274: 139–150.

[4] Britos, P., Grosser, H., Rodríguez, D., Garcia-Martinez, R. (2008b). Detecting Unusual Changes of Users Consumption. En Artificial Intelligence and Practice II, Max Bramer Ed. (Boston: Springer), IFIP Series, 276: 297-306.

[5] Britos, P., Jiménez Rey, E., García-Martínez, E. (2008c). Work in Progress: Programming Misunderstandings Discovering Process Based On Intelligent Data Mining Tools. Proceedings 38th ASEE/IEEE Frontiers in Education Conference.

[6] Chapman, P., Clinton, J., Kerber, R., Khabaza, T., Reinartz, T., Shearer, C. y Wirth, R. (2000).CRISP-DM 1.0 Step-by-step Data Mining guide. U.S.A. http://www.crisp-dm.org/. Página web vigente al 1/09/09.

[7] Cogliati, M., Britos, P., García-Martínez, R. (2006) Patterns in Temporal Series of Meteorological Variables Using SOM & TDIDT In: Bramer M (ed) Artificial Intelligence in Theory and Practice, Boston, Springer, IFIP Series 217:305-314

[8] D’Atri, M., Rodriguez, D., García-Martínez, R. 2009. Improving Pipeline Risk Models by Using Data Mining Techniques. 24th World Gas Conference Proceedings (CD). Paper 663.

[9] Felgaer, P., Britos, P., and García-Martínez, R. (2006) Prediction in Health Domain Using Bayesian Network Optimization Based on Induction Learning Techniques. Int. J. of Mod. Ph. C 17(3): 447-455

[10] Flores, D., Garcia-Martinez, R. Fernandez, E., Merlino, H., Rodriguez, D., Britos, P. (2009). Detección de Patrones para la Prevención de Daños y/o Averías en la Industria Automotriz. Proceedings XV Congreso Argentino de Ciencias de la Computación. Workshop de Base de Datos y Minería de Datos. Págs. 1021-1030. ISBN 978-897-24068-4-1.

[11] García-Martínez, R., Britos, P., Pesado, P., Bertone, R., Pollo-Cattaneo, F., Rodríguez, D., Pytel, P., Vanrell, J. (2011b). Towards an Information Mining Engineering. En Software Engineering: Methods, Modeling, and Teaching (ed. C. Zapata Jaramillo). Editorial de la Universidad de Medellín (en prensa).

[12] García-Martínez, R., Lelli, R., Merlino, H., Cornachia, L., Rodriguez, D., Pytel, P.,Arboleya, H. (2011a). Ingeniería de Proyectos de Explotación de Información para PYMES. Proceedings XIII Workshop de Investigadores en Ciencias de la Computación. Pág. 253-257.

[13] Grosser, H., Britos, P., García-Martínez, R. (2005) Detecting Fraud in Mobile Telephony Using Neural Networks. LNAI 3533:613-615.

[14] Kuna, H., García Martínez, R. Villatoro, F. 2010. Pattern Discovery in University Students Desertion Based on Data Mining. Advances and Applications in Statistical Sciences Journal, 2(2): 275-286. ISSN 0974-6811

[15] Langseth, J., Vivatrat, N. (2003). Why Proactive Business Intelligence is a Hallmark of the Real-Time Enterprise: Outward Bound. Intelligent Enterprise 5(18): 34-41.

[16] Lemus, M. A. (2005). Modelo de Procesos para la Industria de Software. Secretaría de Economía de México. http://www.comunidadmoprosoft.org.mx/. Página web vigente al 1/09/09.

[17] Lockheed-Martin, (1998). LLC PRICE Systems, PRICE S Reference Manual Version 3.0, Lockheed-Martin.

[18] Negash, S., Gray, P. (2008). Business Intelligence. En Handbook on Decision Support Systems 2, ed. F. Burstein y C. Holsapple (Heidelberg, Springer), Pág. 175-193.

[19] Oktaba, H., Piattini, M., Pino, F.J., Orozco, M.J. y Alquicira, C. (2008). Competisoft, Mejora de Procesos Software para Pequeñas y Medianas Empresas y Proyectos. Ra-Ma.

[20] Oktaba, H., Alquicira Esquivel, C., Ramos, A. S., Martínez Martínez, A., Quintanilla Ozorio, G., RuvalcabaLópez, M., López Lira Hinojo, F., Rivera López, M. E., Orozco Mendoza, M. J., Fernández Ordoñez, Y. y Flores

[21] Oktaba, H., Alquicira Esquivel, C., Ramos, A. S., Palacios Elizalde, J., Pérez Escobar, C. J. y López Lira Hinojo, F. (2004). Método de Evaluación de Procesos para la Industria de Software. Secretaría de Economía de México.http://www.software.net.mx/NR/rdonlyres/ED7B3399-0CA4-412E-9FAC-EEB94F85C5F/1224/EvalProSoftv11.pdf. Página web vigente al 1/09/09.

[22] Schiefer, J., Jeng, J., Kapoor, S., Chowdhary, P. (2004). Process Information Factory: A Data Management Approach for Enhancing Business Process Intelligence. Proceedings 2004 IEEE International Conference on E-Commerce Technology. Pág. 162-169.

[23] Stefanovic, N., Majstorovic. V., Stefanovic, D. (2006). Supply Chain Business Intelligence Model. Proceedings 13th International Conference on Life Cycle Engineering. Pág. 613-618.

[24] Vanrell, J., Bertone, R., García Martínez, R. Modelo de Proceso de Operación para Proyectos de Explotacion de Información. Anuales del XVI Congreso Argentino de Ciencias de la Computación. Pág. 674-682. ISBN 978-950-9474-49-9.

[25] Vanrell, J. A., García-Martínez, R., Bertone, R. (2010b). Un Modelo de Procesos de Explotación de Información. Proceedings XII Workshop de Investigadores en Ciencias de la Computación. Pág. 167-171. ISBN 978-950-34-0652-6.

[26] Vanrell, J. A. (2009). Elementos para un Modelo de Procesos de Explotación de Información para PyMES. Trabajo de Especialidad en Ingeniería en Sistemas de Información. Facultad Regional Buenos Aires. Universidad Tecnológica Nacional. http://posgrado.frba.utn.edu.ar/investigacion/especialidades/vanr elltrabajofinaldeespecialidad.pdf. Página vigente al 24/07/10.

Hernan Arboleya. Es Analista Programador Universitario y Licenciado en Sistemas por la Universidad Nacional de Lanús. Es Asistente de Docencia en las Asignaturas Ingeniería de Software I y Proyecto de Software. Es Asistente de Investigación del Laboratorio de Investigación y Desarrollo en Ingeniería de Explotación de Información en el Grupo de Investigación en Sistemas de Información del Departamento de

Desarrollo Productivo y Tecnológico de la Universidad Nacional de Lanús.

REVISTA LATINOAMERICANA DE INGENIERIA DE...

Documents

Transcript of REVISTA LATINOAMERICANA DE INGENIERIA DE...