Relais v1-n1-revista

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

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

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

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

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

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

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

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

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

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

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

10
intervalos difusos. Para cada valor lingüístico se define un
intervalo expresado por cuatro valores numéricos (entre
cero y diez) que representan los puntos de ruptura (o puntos
angulares) de su función de pertenencia correspondiente.
Estos intervalos, junto con la representación gráfica de la
función de pertenencia, se indican en la figura 1.
Paso 3: Calcular la valoración de cada dimensión.
Para calcular la valoración de cada dimensión del proyecto,
los intervalos difusos (obtenidos en el paso anterior) son
ponderados considerando su peso correspondiente (definido
en la tabla 1). El intervalo que representa la valoración de
cada dimensión ( Id ) se calcula con la fórmula (1):
⎟
⎟
⎟
⎟
⎟
⎟
⎟
⎠
⎞
⎜
⎜
⎜
⎜
⎜
⎜
⎜
⎝
⎛
=
=
⋅
⋅+
⎟
⎟
⎟
⎟
⎟
⎟
⎟
⎠
⎞
⎜
⎜
⎜
⎜
⎜
⎜
⎜
⎝
⎛
=
⎟
⎟
⎠
⎞
⎜
⎜
⎝
⎛
=⋅=
∑
∑
∑
∑
dn
i
idP
dn
i
idC
idP
dn
i idC
idP
dn
i
idP
dI
1
)
1
(
2
1
1
1
2
1
(1)
Donde:
Id: representa el intervalo difuso calculado para la dimensión d
(usando como nomenclatura ‘P’ para plausibilidad, ‘A’ para
adecuación y ‘E’ para criterio de éxito).
Pdi: representa el peso de la característica i perteneciente a la
dimensión d.
Cdi: representa el intervalo difuso asignado a la característica i
perteneciente a la dimensión d.
nd: representa la cantidad de características asociada a la dimensión
d.
Está fórmula está formada por la combinación de la media
armónica y la media aritmética del conjunto de intervalos.
De esta forma se busca reducir la influencia de valores
bajos en el cálculo de la dimensión.
Ya que el resultado de la fórmula anterior es otro intervalo
difuso, para convertir dicho intervalo en un único valor
numérico ( Vd ) se utiliza la media aritmética de los valores
del intervalo como se indica en la fórmula (2):
4
4
1
∑
== i
idI
dV
(2)
Donde:
Vd: representa el valor numérico calculado para la dimensión d.
Idi: representa el valor de la posición i del intervalo difuso calculado
para la dimensión d .
Paso 4: Calcular la valoración global de la viabilidad del
proyecto.
Finalmente, los valores numéricos calculados en el paso
anterior para cada dimensión ( Vd ) son combinados a través
de una media aritmética ponderada (la cual es indicada en
la fórmula 3) y así se consigue el valor de la viabilidad
global del proyecto (EV ).
22
688 EVAVPV
EV
⋅+⋅+⋅
=
(3)
Donde:
EV: representa el valor global de la viabilidad del proyecto.
VP: representa el valor para la dimensión plausibilidad.
VA: representa el valor para la dimensión adecuación.
VE: representa el valor para la dimensión criterio de éxito.
Valor = ‘nada’
Intervalo Difuso= (0,0; 0,0; 1,2; 2,2)
Valor = ‘poco’
Valor = ‘regular’
Valor = ‘mucho’
Valor = ‘todo’
Fig. 1. Representación de la Función de Pertenencia y asignación de Intervalo
Difuso para los Valores Lingüísticos.
Paso 5: Interpretar los resultados obtenidos.
Una vez que los valores correspondientes a cada dimensión
y al proyecto global son calculados (pasos 3 y 4
respectivamente), deben ser analizados. Por un lado, para
interpretar los resultados de la viabilidad de cada
dimensión, se recomienda graficar la función de
pertenencia del intervalo difuso (Id). Se considera que la

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

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

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

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

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

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

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

Relais v1-n1-revista

Recommandé

Recommandé

Contenu connexe

En vedette

En vedette (6)

Similaire à Relais v1-n1-revista

Similaire à Relais v1-n1-revista (20)

Dernier

Dernier (6)

Relais v1-n1-revista