juan david saldarriaga benjumea
TRANSCRIPT
ONTOLOGÍAS PARA CONCEPTUALIZACIÓN DE MODELOS DE NEGOCIO
JUAN DAVID SALDARRIAGA BENJUMEA
UNIVERSIDAD DE MEDELLÍN
FACULTAD DE INGENERÍAS
MEDELLÍN
2013
ONTOLOGÍAS PARA CONCEPTUALIZACIÓN DE MODELOS DE NEGOCIO
JUAN DAVID SALDARRIAGA BENJUMEA
Trabajo de Grado para optar el título de:
Especialista en Gerencia de Información
Asesor
Doctora Marta Silvia Tabares
UNIVERSIDAD DE MEDELLÍN
FACULTAD DE INGENERÍAS
MEDELLÍN
2013
CONTENIDO
pág.
INTRODUCCIÓN 9 1. GENERALIDADES DEL PROYECTO 11
1.1 DEFINICIÓN DEL PROBLEMA 11 1.2 JUSTIFICACIÓN 13 1.3 OBJETIVOS GENERALES Y ESPECÍFICOS 15
1.3.1 GENERAL 15
1.3.2 ESPECÍFICOS 15
1.4 METODOLOGÍA 16
1.4 RESUMEN 17
2. MARCO REFERENCIAL 18
2.1 EL PROCESO DE DESARROLLO DE SOFTWARE 18
2.2 MODELO DE PROCESOS DE NEGOCIO 20
2.3 ONTOLOGÍAS 25 3. ONTOLOGÍAS QUE PUEDEN APOYAR LA GESTIÓN DEL
CONOCIMIENTO 28
3.1 CONCEPTUALIZACIÓN DE ONTOLOGÍAS EN DIFERENTES ENTORNOS. 28
3.2 CONCEPTUALIZACIÓN DE MODELOS, METODOLOGIAS U ONTOLOGÍAS QUE SE PUEDEN ASOCIAR A LA INGENERÍA DE REQUISITOS. 34
3.3 IDENTIFICACIÓN DE ELEMENTOS DE MODELOS,
METODOLOGIAS U ONTOLOGÍAS QUE SE PUEDEN APLICAR O UTILIZAR PARA LA CONCEPTUALIZACIÓN DEL MODELO DEL PROCESO DE NEGOCIO. 46
4. CONCLUSIONES 58 GLOSARIO 59 BIBLIOGRAFÍA 61
LISTA DE FIGURAS
pág.
Figura 1. Ciclo de Vida del Software. 19
Figura 2. Componentes de un Modelo de Negocio. 21
Figura 3. Ejemplo Ontologías. 26
Figura 4. Diagrama Navegación Ontología de Alojamiento. 30
Figura 5. Ejemplo Ontología Musical. 31
Figura 6. Diagrama de Clases Ontológicas E-Salud. 33
Figura 7. Proceso para Construir una Ontología de Dominio Personal. 36
Figura 8. Librería de Ontologías de Miology. 37
Figura 9. Navegación de Ontologías a través Miology. 37
Figura 10. Vista General de la Metodología CreaDO. 39
Figura 11. Fragmentos de Ontologías de Turismo. 40
Figura 12. Arquitectura ODE. 47
Figura 13. Herramienta ODE de Definición de Procesos. 49
Figura 14. Herramienta ODE para el Seguimiento del Proyecto. 49
Figura 15. Mapa Conceptual Entorno de Desarrollo DOSDE 52
Figura 16. Diagrama de la ontología de modelos de negocio
propuesta por Osterwalder. 53
Figura 17. Diagrama Modelo del negocio de Skype. 56
9
INTRODUCCIÓN
La alta competitividad marcada en el mundo de hoy, ha llevado a una gran
rotación de personal a nivel mundial, bien sean ingenieros, tecnólogos u otros
tipos de profesionales de las empresas de desarrollo de software; esto trae
consigo que el conocimiento que éstas adquirieron, de los procesos de las
organizaciones y de los negocios de sus clientes queden en la mete de ellos y no
plasmados o controlados por algún sistema de gestión del conocimiento.
Un punto inicial en el ciclo del desarrollo del software, es el que lleva a considerar
esta investigación: la elicitación de requisitos. Esta fase generalmente es realizada
por ingenieros de sistemas o informáticos, expertos en levantar procesos o
entender el funcionamiento de un flujo de trabajo de una organización o empresa
determinada; ya que para poder comenzar a levantar las necesidades de los
stakeholders, se debe aprender o por lo menos entender cómo es el contexto del
negocio en el cual se está desarrollando una actividad o proceso.
Actualmente, esa conceptualización del modelo del negocio, está en las mentes
de los millones de profesionales que día a día trabajan en esta actividad. Con la
utilización de las ontologías, es posible describir este conocimiento, las ontologías
se basan en definiciones conceptuales dentro de uno o varios dominios, las cuales
pueden ser jerarquizadas mediante la definición de clases o subclases permitiendo
en conjunto dar una definición formal de un dominio en particular, el tener este
conjunto de datos categorizados y encadenados en un modelo de gestión de
conocimiento, permite definir la comprensión del proceso del negocio de cualquier
tema en particular, que perdure en el tiempo y esté disponible para ser consultado,
modificado o ampliado según se vayan presentando los cambios, como
10
consecuencia de eventos coyunturales de los mercados en los cuales se
desenvuelven las organizaciones o por temas legislativos o regulatorios.
La utilización de este medio de gestión de conocimiento posibilitaría minimizar los
riesgos de reprocesos, atrasos en los cronogramas y cumplimiento con las
expectativas del cliente.
El trabajo realizado pretende demostrar eso, que este tipo de distribución del
conocimiento mejora el estado del aprendizaje de los involucrados y mediante
ejemplos reales indicar que esta propuesta es posible utilizarse para el contexto
de la fase de elicitación de requisitos.
11
1. GENERALIDADES DEL PROYECTO
1.1 DEFINICIÓN DEL PROBLEMA
La globalización y el crecimiento de los mercados, traen consigo la necesidad de
soluciones tecnológicas, de manejo de información y comunicación; es por eso,
que para las empresas que ofrecen servicios de este tipo, la competencia es cada
vez mayor. La evolución de los productos de software y tecnología sigue pasos
agigantados, y mantenerse en este medio implica mejorar día a día los diferentes
procesos y metodologías.
Las organizaciones de desarrollo de software, buscan mejorar sus niveles de
madurez, obteniendo certificaciones en calidad y siguiendo enfoques, modelos y
metodologías estándar calificadas y reconocidas a nivel mundial, como son CMMI
“Capability Maturity Model Integration” (CMMI Institute, 2013), RUP “Rational
Unified Process” (IBM, 2013), Métrica V3 “Metodología de Planificación, Desarrollo
y Mantenimiento de Sistemas de Información” (Gobierno de España, 2013), entre
otras. Todas estas coinciden en la importancia de la fase inicial de elicitación de
requisitos, en el proceso de análisis de los sistemas a desarrollar, con el fin de
determinar exactamente, el alcance, las necesidades, los requisitos y comprender
el proceso de negocios del cliente.
Dentro de los movimientos más relevantes que en la ingeniería del software han
ido retomado en los últimos tiempos se puede citar a la necesidad del modelado
de los procesos de negocio (Weske, 2007), constituyéndose en una de las
actividades principales en el ciclo de vida del desarrollo del software. Su objetivo
12
principal es comprender el negocio actual, especialmente sus procesos de
negocio. Independientemente de que los procesos de negocio actuales sean
manuales o estén automatizados, esta tarea es fundamental para entender el
contexto en el que se usará el sistema a desarrollar y promover posibles mejoras.
La identificación del modelo de procesos de negocio constituye el punto de partida
fundamental en la etapa de requisitos donde normalmente el conocimiento
obtenido se pierde en el tiempo de manera total o parcial, puesto que no se
almacena la información de manera adecuada.
En muchos casos, se presenta que el modelo de procesos de negocio es muy
grande y constituye a su vez varios modelos o varios sistemas de información que
pueden desarrollarse en diferentes periodos de tiempo. Es posible que durante la
conceptualización de modelos de negocio para grandes organizaciones, se caiga
en reprocesos, porque cada parte del modelo de procesos de negocio puede ser
identificada varias veces y de diferentes maneras por miembros del equipo de
requisitos de la empresa desarrolladora. Todo esto debido a que cada producto
de software, puede requerir la conceptualización de determinadas actividades o
tareas que tienen en común diferentes procesos.
El reproceso se presenta porque no se almacena una adecuada documentación, y
no es posible retomar temas anteriormente tratados en la contextualización del
modelo de procesos de negocio. Esta información se debería almacenar de tal
forma que solo sea necesario modificarla, complementarla o actualizarla, cuando
realmente cambie algo en el proceso del negocio del cliente.
13
1.2 JUSTIFICACIÓN
La necesidad de una ingeniería de requisitos dentro de la ingeniería del software
es imprescindible para obtener productos de calidad. La calidad no puede
implementarse en las etapas finales de los procesos de desarrollo sino que es una
característica intrínseca al propio producto en cada una de sus fases, definidas en
las especificaciones de los productos. Este inicio de las actividades de calidad en
la ingeniería de requisitos es la base para el aseguramiento de la calidad del
proyecto (Matt, 2008).
Para empresas que hacen desarrollos a la medida, el modelo de procesos de
negocios de cada cliente y de cada producto de software debe documentarse de
tal manera que se pueda reutilizar la información y actualizar en el momento en
que sea necesario; es decir, analizar y comprender el proceso en una sola
oportunidad, evitando reprocesos, que a su vez se reflejan en la planificación y
uso del tiempo, implicando sobrecostos en los proyectos, no solo de desarrollo de
software, sino, en cualquier área de conocimiento.
Con el fin de minimizar el riesgo de este reproceso, y todas sus implicaciones en
costos y cronogramas, además de garantizar un producto de calidad que cumpla
con los requerimientos y expectativas del cliente, se propone documentar los
modelos de procesos de negocio por medio de ontologías, que permitan actualizar
y mejorar cada parte del proceso en cualquier momento.
La documentación del proceso de negocios, permite revisión al detalle con el
cliente, validación de todo el proceso o partes específicas de este; garantizando
que se comprendió el contexto del negocio del cual se desea implementar una
14
aplicación o solución informática y que se construyó de manera correcta la base
para iniciar con la especificación de requisitos.
15
1.3 OBJETIVOS GENERALES Y ESPECÍFICOS
1.3.1 GENERAL
Evidenciar diferentes ontologías que pueden apoyar la gestión del conocimiento
durante la conceptualización del modelo de negocio en la etapa de elicitación de
requisitos en una empresa de desarrollo de software.
1.3.2 ESPECÍFICOS
- Identificar el uso y aplicabilidad de las ontologías en diferentes entornos.
- Identificar modelos o tipos de ontologías que se asocien a la ingeniería de
requisitos y su aplicabilidad en la contextualización en los modelos de negocio.
- Identificar elementos de diferentes modelos o propuestas, que sirvan como base
para definir y aplicar en el modelo de ontologías a utilizar para la
conceptualización del modelo del negocio.
16
1.4 METODOLOGÍA
El proceso investigativo que se adoptó para la realización de este documento, se
enfocó en referenciar apartes de libros, investigaciones, publicaciones, escritos
por expertos, además de sitios web que abordan el tema.
La bibliografía se encuentra explicita en el capítulo de bibliografía al final de este
trabajo.
El desarrollo de éste, se basó en iniciar la identificación, el uso y diferentes
aplicaciones que le dan a las ontologías en áreas del conocimiento humano, se
consultó diferentes autores que explicaron en la práctica, que para todo se puede
usar las ontologías, medicina, turismo, informática, entre otros aspectos tienen
aplicabilidad a este método de gestión de conocimiento.
Luego, buscando información más especializada se encontró metodologías, tipos
de ontologías y herramientas que se usan hoy en día para en el mundo del
desarrollo de software y en especial en la ingeniería de requisitos. Basado en esto
se evidenció que en la actualidad se usan metodologías o propuestas para la
gestión de proyectos de desarrollo de software que permiten tener la
conceptualización del modelo de negocio.
Toda esta información se dividió en los capítulos, orientados al logro de cada uno
de los objetivos específicos que se definieron.
1.5 RESUMEN
Título del trabajo: Ontologías para Conceptualización de Modelos de Negocio.
Autor (s): nombre del autor(s): Juan David Saldarriaga Benjumea.
Título otorgado: Especialista en Gerencia de Información
Asesor del trabajo: Doctora Marta Silvia Tabares
Programa de donde egresa: Especialización en Gerencia de Información
Ciudad: Medellín.
Año: 2013
Una de las principales actividades en el ciclo de vida del desarrollo del software es
comprender el negocio actual, especialmente sus procesos, es decir, el modelo
del proceso del negocio; los ingenieros de requisitos basados en las metodologías
más usadas, plasman necesidades y luego requisitos apoyados en lo que conocen
del proceso a sistematizar, pero este conocimiento no queda documentado en
ninguna parte, hoy esto genera un problema de reprocesamiento.
Las ontologías actualmente se usan en un sin número de áreas, como la medicina,
el turismo, la música, la energía, entre otros, para todas estas, este tipo de
herramienta de gestión de conocimiento, soporta la conceptualización del proceso
del negocio de cualquier organización, es decir, esta herramienta permite
documentar de la mejor manera, todo el proceso del modelo del negocio
relacionando conceptos del proceso en particular y área de negocio de cualquier
empresa de bienes y servicios. La gran ventaja de las ontologías es que pueden
ser compartidas y accedidas en cualquier lugar y momento, además de que éstas
pueden complementarse de más conceptos y definiciones de otras ontologías.
18
2. MARCO REFERENCIAL
2.1 EL PROCESO DE DESARROLLO DE SOFTWARE
Un proceso de desarrollo de software tiene como propósito la producción eficaz y
eficiente de un producto software que reúna los requisitos del cliente. Este
proceso es intensamente intelectual, afectado por la creatividad y juicio de las
personas involucradas (Sommerville, 2000).
A pesar de la variedad de propuestas de proceso de software, existe un conjunto
de actividades fundamentales que se encuentran presentes en todos ellos
(Sommerville, 2000):
1 Especificación de software: se debe definir la funcionalidad y restricciones
operacionales que debe cumplir el software.
2 Diseño e Implementación: se diseña y construye el software de acuerdo a la
especificación.
3 Validación: el software debe validarse, para asegurar que cumpla con lo que
quiere el cliente.
4 Evolución: el software debe evolucionar, para adaptarse a las necesidades del
cliente.
19
Figura 1. Ciclo de Vida del Software. (Sebastián, 2011)
Dentro de los movimientos más relevantes que en la ingeniería del software han
ido surgiendo en los últimos tiempos podemos citar a la necesidad del modelado
de los procesos de negocio (Matt, 2008) y la interoperabilidad entre sistemas. La
ingeniería de requisitos, en el proceso de especificación de software, debe
responder a estas necesidades como parte del ciclo de desarrollo de los sistemas.
20
2.2 MODELO DE PROCESOS DE NEGOCIO.
Un modelo de los procesos del negocio es una abstracción de cómo funciona la
organización. Provee una vista simplificada de la estructura y comportamiento del
negocio que actuará como la base de comunicación, mejora o innovación del
negocio, así como también para definir los requisitos de los diferentes sistemas de
software que pueden soportar al negocio. Entender correctamente el dominio del
negocio, es conocer el dominio del problema, de la situación actual (Leonardi,
2007).
Enfrentarse a un desarrollo sin conocer las características principales ni el
vocabulario propio de su dominio, suele provocar que el producto final no sea el
esperado por clientes ni usuarios, como generalmente sucede hoy en día. El
llevar a cabo reuniones con clientes y usuarios sin conocer las características de
su actividad hará que probablemente no se entiendan sus necesidades y que no
se tenga confianza con el desarrollo que se les entregará (Durán Toro &
Bernárdez Jiménez, 2000).
La etapa de elicitación de requisitos como proceso inicial del ciclo de desarrollo de
software debe incluir la respectiva documentación de la información, desde el
mismo momento que se comprende el dominio de negocios del cliente, hasta el
detalle de casos de uso. Este proceso en la mayoría de las empresas de software
se hace bajo el estándar del lenguaje unificado de modelado UML “Unified
Modeling Language” (IBM, 2013). En los diagramas de UML, se hace la
documentación del modelo de procesos de negocios, mediante el diseño de
diagramas de actividades o de procesos.
21
Una vez identificados los procesos de negocio de la organización, y descritos sus
flujos de trabajo mediante diagramas de actividades, los casos de uso se definen y
estructuran a partir de las actividades de cada proceso, mientras que las entidades
del modelo conceptual se obtienen de los datos que fluyen entre tales actividades.
Los modelos de negocio de las organizaciones evolucionan y es preciso que esa
evolución se vea reflejada en la documentación, para que estos cambios se
incluyan en el momento adecuado en el desarrollo del sistema actual o de los
proyectos posteriores, donde se requiera el mismo proceso de negocios o una
parte de estos.
Figura 2. Componentes de un Modelo de Negocio. (Rodriguez Mera, 2011)
(Rodriguez Mera, 2011) en su presentación de Modelo de Negocio referencia a
Shafer, Smith y Linder que en 2005 después de estudiar 12 deficiones desde 1998
a 2002 desarrallaron el diagrama anteriormente citado, éste identifica cuatro
categorias principales: Opciones Estrategicas (Strategic Choices), Creación de
22
Valor (Creating Value), Captura del Valor (Capturing Value) y Cadena de Valor
(Value Network). Un modelo de negocio se define por las decisiones estratégicas,
a veces hechas por una red de organizaciones, que explican la creación de valor y
captura de valor.
De esto Shafer, Smith y Linder concluyeron que un componente importante de los
modelos de negocio son opciones estratégicas definidas por la gerencia sobre
cómo la organización debe funcionar. Por ejemplo, las decisiones con respecto a
algo así como las prácticas de compensación, contratos públicos, ubicación de las
instalaciones, activos a utilizar, la integración vertical de todas las areas, o las
iniciativas de ventas y mercadeo, en general las decisiones adoptadas por la
administración que definen "la forma en que opera la empresa". (Casadesus-
Masanell & Ricart, 2007)
Según Casadesus & Ricart las opciones estrategicas, no son el único componente
del modelo de negocio. Todos los autores destacan, que éstas se deben conectar
a la creación del valor y captura del valor, o a las diferentes alternativas o metas
que la empresa se quiera proponer. Todo lo anterior se apoya en los procesos que
la organización defina, éstos facilitan de una forma practica entender como se
deben hacer las cosas para cumplir con la estrategia organizacional, pero para
lograr esto muchos autores en la actualidad recomiendan hacer uso del cliclo
PHVA (Planear, Hacer, Verificar y Actuar).
El ciclo PHVA es un ciclo dinámico que puede ser empleado dentro de los
procesos de la Organización. Es una herramienta de simple aplicación y, cuando
se utiliza adecuadamente, puede ayudar mucho en la realización de las
actividades de una manera más organizada y eficaz. Por tanto, adoptar la filosofía
del ciclo PHVA proporciona una guía básica para la gestión de las actividades y
los procesos, la estructura básica de un sistema, y es aplicable a cualquier
organización.
23
A través del ciclo PHVA la empresa planea, estableciendo objetivos, definiendo los
métodos para alcanzar los objetivos y definiendo los indicadores para verificar que
en efecto, éstos fueron logrados. Luego, la empresa implementa y realiza todas
sus actividades según los procedimientos y conforme a los requisitos de los
clientes y a las normas técnicas establecidas, comprobando, monitoreando y
controlando la calidad de los productos y el desempeño de todos los procesos
clave.
Luego, se mantiene esta estrategia de acuerdo a los resultados obtenidos,
haciendo girar de nuevo el ciclo PHVA mediante la realización de una nueva
planificación que permita adecuar la Política y los objetivos de la Calidad, así
como ajustar los procesos a las nuevas circunstancias del mercado. De manera
resumida, el ciclo PHVA se puede describir así:
1. Planificar: establecer los objetivos y procesos necesarios para obtener
los resultados, de conformidad con los requisitos del cliente y las políticas
de la organización.
2. Hacer: implementar procesos para alcanzar los objetivos.
3. Verificar: realizar seguimiento y medir los procesos y los productos en
relación con las políticas, los objetivos y los requisitos, reportando los
resultados alcanzados.
4. Actuar: realizar acciones para promover la mejora del desempeño del
(los) proceso(s).
El ciclo PHVA significa actuar sobre el proceso, resolviendo continuamente las
desviaciones a los resultados esperados. El mantenimiento y la mejora continua
de la capacidad del proceso pueden lograrse aplicando el concepto de PHVA en
cualquier nivel de la Organización, y en cualquier tipo de proceso, ya que está
íntimamente asociado con la planificación, implementación, control y mejora del
desempeño de los procesos.
24
Es aplicable tanto en los procesos estratégicos de Alta Dirección como en
actividades operacionales simples. Por ejemplo, si una empresa telefónica planea
mejorar el servicio a sus suscriptores y para ello, decide modernizar sus centrales
telefónicas (Planificar). Esto lo puede lograr adquiriendo 40 nuevas centrales
digitales e instalándolas progresivamente en toda la ciudad (hacer). Al
departamento técnico le ha sido asignado el trabajo de medir los resultados, en
términos del incremento de llamadas efectuadas en las zonas donde las centrales
han sido instaladas y el número promedio de líneas disponibles, a fin de
compararlas con los valores que se obtienen en las centrales analógicas antiguas
(verificar). Con estos resultados, la Gerencia de Planificación de la empresa
efectúa los ajustes y aplica los resultados en la instalación de futuras centrales
(actuar). La consecuencia de esta metodología de trabajo ha sido que los
problemas que se han presentado durante el proceso de instalación han sido
resueltos oportunamente por el equipo, sin causar demoras apreciables en los
proyectos originales.
La adopción del ciclo PHVA promueve que la práctica de la gestión vaya en pro de
las oportunidades para que la Organización mejore el desempeño de sus procesos
y para que mantenga los clientes actuales y consiga nuevos clientes. Una vez
identificada un área de oportunidad, se puede planificar el cambio y llevarse a
cabo.
Luego se verifican los resultados de la implementación de tal cambio y, según
estos resultados, se actúa para ajustar el cambio o para comenzar el ciclo
nuevamente mediante la planificación de nuevos cambios. (UdeA, 2012)
25
2.3 ONTOLOGÍAS
El termino de ontología es utilizado en la filosofía y en la informática, nos
centraremos en conocer que significa esta palabra para el área relacionada con
este trabajo. Este término hace referencia a un minucioso y riguroso esquema
conceptual dentro de uno o varios dominios, esto con el fin de permitir una fácil
comunicación o intercambio de información entre diferentes sistemas. (Wikipedia,
2013).
Generalmente el termino ontología para el mundo informático, relaciona
precisamente vocabularios fijos, en palabras más prácticas es una descripción
explicita y formal de conceptos de un dominio de clases, describiendo
características del concepto y restricciones sobre estos. (Orrego & Ramirez, 2010)
Una ontología se construye definiendo las clases, organizándolas en una jerarquía
taxonómica (subclase o superclase), posteriormente se definen los conceptos con
sus valores permitidos. (Orrego & Ramirez, 2010)
Ejemplo: Luis tiene un perro llamado Fido,
Luis es una instancia de Persona
Fido es una instancia de Perro
Al construir la ontología a partir de estos datos, tenemos lo siguiente:
26
Figura 3. Ejemplo Ontología. (Orrego & Ramirez, 2010)
Las ontologías permiten trabajar por conceptos, en vez de palabras clave, en los
sistemas de recuperación de información. Desde el punto de vista de las fuentes
de información, estas describen el contenido de los repositorios de datos
independientemente de la representación sintáctica de los mismos, posibilitando
su integración semántica. (Tim Berners-Lee, James Hendler, & Ora Lassila, 2001)
En 1993 Tom Gruber definió una ontología como "una especificación formal y
explícita de una conceptualización" (Grigoris Antoniu & Frank van Harmelen,
2004); es la forma de modelar un dominio del conocimiento a través de la
identificación de los conceptos, relaciones, propiedades y reglas existentes en él.
Su objetivo, de acuerdo a Heflin, es "que sean usadas por personas, bases de
datos y aplicaciones que necesiten compartir información de un dominio" (Heflin,
2004) y generar conocimiento a partir de él.
27
(Quero Bastidas, 2007) ilustra en su trabajo de grado el siguiente ejemplo de
ontología tomando el area de la ingenería de diseño: “…supongamos que un
grupo de ingenieros desea definir un vocabulario de entendimiento común en
cuanto los componente eléctricos, para lograr su objetivo se definie una ontología
de dominio de los componente eléctricos, asumiendo que se tiene un vocabulario
donde se discuten elementos conceptuales como: transistores, amplificadores
operacionales, voltajes y las relaciones existentes entre estos componentes, los
amplificadores operacionales son un tipo de componente eléctrico y los
transistores estan compuestos de amplificadores operacionales”. Identificar este
tipo de vocabulario y su conceptualización requiere tener conocimiento del dominio
que se esta describiendo.
La importancia de las ontologías se describe en dos puntos fundamentales:
El análisis ontológico clarifica la estructura del conocimiento.
Las ontologías permiten compartir conocimiento. (Quero Bastidas, 2007)
Las Ontologías se usan en muchos entornos y tiene la posibilidad de aplicarse en
la vida cotidiana, si se desea; desde aspectos científicos de la medicina, hasta
temas sencillos como definiciones básicas de filosofía. Las ontologías son
herramientas que permiten a cualquier persona con un mínimo conocimiento en un
tema en particular de las ciencias humanas, establecer conceptos y hacer las
relaciones pertinentes de estos con respecto a otros que ya están establecidos por
medio de otras ontologías.
28
3. ONTOLOGÍAS QUE PUEDEN APOYAR LA GESTIÓN
DEL CONOCIMIENTO
3.1 CONCEPTUALIZACIÓN DE ONTOLOGÍAS EN DIFERENTES
ENTORNOS
Aún no existe consenso sobre los diferentes tipos de ontologías existentes, pues
cada autor que trabaja en el tema define su propia clasificación, de acuerdo a
diferentes características. La clasificación realizada por Van Heist G., Schreiber A.
y Wielinga B. en 1997 en su estudio “Using Explicit Ontologies in KBS
Development”, tiene en cuenta “el grado de posible reutilización de una ontología
para hacer la clasificación: Ontologías de representación, Ontologías genéricas,
Ontologías de dominio y Ontologías de aplicación.” (Van Heist G, Schreiber A, &
Wielinga B, 1997)
Otra clasificación realizada por Kedad, Z. & Métais E. en 2002, usa como atributos
para definir las clases, la existencia o no de individuos de la ontología. “Las clases
definidas son: Ontologías taxonómicas, Ontologías descriptivas.” (Zoubida Kedad
& Elisabeth Matias, 2005)
Las ontologías médicas que abundan hoy en la red, son repositorios de
conocimiento en temas específicos de esta área del conocimiento. Son también
ontologías de dominio y se basan en aspecto propios de las ontologías de dominio
académicas. “1. La naturaleza del conocimiento local debe extender su área de
influencia hasta un nivel público, esta es una característica fundamental del
29
conocimiento académico. De hecho es un sistema adecuado de repositorio de
conocimiento, el cual su contenido sea compatible con la función que debe tener.
2. La adquisición colectiva de conocimiento podría ayudar a la construcción de un
repositorio de conocimiento de gran medida. Los expertos humanos podrían
participar incluyendo en éste gran cantidad de aspectos puntuales del
conocimiento individual mediante una entrada distribuida. 3. El repositorio del
conocimiento a utilizar, debe tener información relacionada con respecto al tema.
Algunos ejemplos de ontologías médicas son UMLS, SNOMED, Galeno, MEDIS y
MedDRA”. (Tokosumi, Matsumoto, & Murai, 2007)
El mundo altamente globalizado ha permitido a más personas de todas partes, ir
de un lado a otro. El turismo es sin duda, unos de los principales aspectos de la
sociedad actual que ha crecido notablemente, ayudado por el internet; ahora es
más fácil adquirir planes vacacionales y conocer el destino sin la incertidumbre
que antes representaba para los viajeros el llegar al lugar seleccionado. El e-
commerce, ha sido un punto de partida para e-tourism, este se ha basado en los
principios del comercio electrónico y a su vez a impulsado la creación de
ontologías semánticas basadas en el turismo. (Siricharoen, 2007)
La intención de un usuario al realizar una consulta en un portal de turismo es
buscar aspectos relevantes, como acomodación, infraestructura, cercanía a sitios
de interés, comida, entre otros aspectos; es por esto que el tener una relación
semántica de conceptos de turismo, éstos servirán para relacionar sitios que se
acomoden a la búsqueda del interesado. Esto se logra mediante la definición de
categorías por ejemplo para alternativas culinarias, de acomodación, de sitios de
interés respectivamente. (Siricharoen, 2007).
Un ejemplo es la Ontología de Alojamiento que es una extensión de
GoodRelations (Dr. Martin Hepp, 2011), portal de vocabulario para comercio
electronico, proporciona los elementos adicionales para la descripción de las
30
habitaciones de hotel, los hoteles, los campings y otras formas de alojamiento;
además de sus características, y un modelo compuesto por los precios y
frecuencia que se encuentran en el sector del turismo, por ejemplo, gastos de
limpieza semanal o cargos adicionales de electricidad en casas de vacaciones en
base a las medidas de uso de este servicio. (Hepp, 2013)
En escenarios típicos de hotel, hay que distinguir entre el agente que opera el
hotel (gr: BusinessEntity), el hotel en su conjunto (acco: Hotel), y las habitaciones
del hotel individualmente (acco: HotelRoom). Esta distinción es importante, ya que
es posible que se desee representar características del hotel y de sus
habitaciones. Por ejemplo, un sauna puede ser una característica de habitación o
una característica del hotel. Todas las acomodaciones son instancias de las clases
del portal GoodRelations; gr: Localización y gr: ProductOrService. Las
habitaciones del hotel y los hoteles o parcelas de camping y los camping pueden
vincularse a través de la relación (acco: partof). (Hepp, 2013)
La siguiente ilustración muestra un ejemplo sencillo del uso de la ontología:
Figura 4. Diagrama Navegación Ontología de Alojamiento. (Hepp, 2013)
31
El anterior escenario: Una habitación doble con una cama doble para 99 dólares
americanos por noche para una o dos personas.
La música también se puede representar por medio de una ontología, por ejemplo
Figura 5. Ejemplo Ontología Musical. (Tallarico, 2004)
(Tallarico, 2004) en su presentación de Uso de Ontologías para Recuperación de
Información ilustra que la ontología músical cumple como objetivo el exponer
conocimiento de manera generica para que pueda ser compartido y reutilizado.
Explica que el Jazz y la música clasica puede verse como conceptos dentro los
generos músicales, además que una canción es creada por un compositor, o que
una canción es interpretada por otros tantos artistas.
32
E-salud es una ontología relacionada con el sector salud, esta abarca todo el
proceso proporcionando información al paciente desde los síntomas que tiene y
una vez que el médico le haya dado un tratamiento, seguir utilizando este método
de gestión de conocimiento para dar seguimiento al tratamiento y saber la
evolución que el paciente experimenta. E-Salud, no vienen reemplazar al médico,
sino que le sirve al paciente y al médico para tener información relacionada con
sus pacientes. Y a los pacientes con su médico y su enfermedad.
En muchos países como Dinamarca, Holanda y Suecia, el uso de E-Salud es muy
común, pues aprovechan la tecnología para que este proceso se pueda
administrar con mucha mayor facilidad ya que el usuario podrá acceder a la
información sin estar frente a su médico y desde cualquier parte del mundo. Una
gran ventaja es que podrá obtener información sobre enfermedades, centros de
salud o especialistas con mucha mayor facilidad, también proporcionará
recomendaciones relacionadas con nuestra búsqueda.
Veamos un ejemplo, supongamos que una persona desea saber los especialistas
de alguna enfermedad que se encuentra en una clínica X, esta clínica está muy
lejos de done vive esta persona, al hacer esa búsqueda, la ontología nos mostrará
a los especialistas de esta enfermedad y de esa clínica, pero además nos
mostrará otros resultados, por ejemplo nos sugerirá que existen otros especialistas
y que existen algunos que están mucho más cerca, por lo que podríamos ahorrar
tiempo en la atención de la afección consultada.
Este es solo un ejemplo del potencial de las ontologías, pues como estan
semánticamente relacionadas, el resultado de la búsqueda es mucho mejor,
podríamos obtener resultados también como horarios, citas, tarifas, ecétera.
(Ordonez, 2011)
33
A continuación, se relaciona un diagrama de clases ontologicas de cómo es este
tipo de ontología:
Figura 6. Diagrama de Clases Ontológicas E-Salud. (Ordonez, 2011)
34
3.2 CONCEPTUALIZACIÓN DE MODELOS, METODOLOGIAS U
ONTOLOGÍAS QUE SE PUEDEN ASOCIAR A LA INGENERÍA DE
REQUISITOS
En todo el tipo de industria, tanto de bienes tangibles como intangibles, el
desarrollo de un producto requiere la intervención de gran cantidad de expertos.
Cada uno de estos tiene un punto de vista determinado pero todos comparten
información que es requerida para cada uno de los procesos del desarrollo del
producto como tal. El concepto de “ingeniería virtual el cual se basa en el apoyo
virtual basado en fases de análisis, diseño y simulación del producto” (Mencke,
Vornholt, & Dumke, 2008), se fundamenta en los diferentes modelos y vistas
especializadas que los grupos interdisciplinarios comparten, pero el entender y
comunicar adecuadamente esta información es el principal reto a satisfacer.
Las ontologías permiten tener una herramienta donde esta información se pueda
compartir de manera adecuada. De acuerdo a las diferentes fases de la ingeniería
virtual las ontologías se pueden aplicar de la siguiente manera:
- Fase 1. Modelado y programación (Diseño Virtual), esta fase que se refiere
a la construcción de prototipos virtuales, generalmente se fundamenta en
prototipos ya modelados.
- Fase 2. Simulación (Pruebas y Verificación).
- Fase 3. Visualización e Interacción con la Plataforma, representación de
los objetos virtuales y su interacción. “Estos procesos se puede basar en
las ontologías semánticas” (Mencke, Vornholt, & Dumke, 2008).
35
Una forma genérica para gestionar una ontología es la utilización de una
Aplicación Web que permite a un usuario en particular configurar ontologías de
domino personal. “Miology es la aplicación que le ayuda a los usuarios, de una
manera automática seleccionar y adaptar ontologías existentes para representar
sus propios intereses”. (Speretta & Gauch, 2010).
Miology se define desde cuatro pasos básicos:
- El primero se basa en que el usuario interesado en crear su ontología de
dominio personal, le provea al Módulo de Procesamiento de Documentos,
cierta cantidad de información, páginas web del tema al cual se hace
referencia para la elaboración de la ontología de dominio, éste extrae las
palabras más representativas del dominio.
- El segundo paso, por intermedio del Módulo de Recuperación de
Ontologías toma las palabras representativas y determina el dominio que
tendrá el repositorio de la nueva Ontología.
- El tercer paso, a través del Módulo de Adaptación Ontológica, toma el
dominio de la nueva Ontología y la adapta para que se ajuste mejor a los
documentos que inicialmente proporcionó el usuario interesado en la
creación de la nueva Ontología. Además de esto, dicho módulo, tiene la
facultad de modificar la estructura y el vocabulario.
Por último, el sistema proporciona al usuario la Ontología de Dominio, la cual
puede ser ajustada como sea del agrado del interesado y al finalizar, se almacena
y es indexada en el repositorio.
36
Figura 7. Proceso para Construir una Ontología de Dominio Personal. (Speretta &
Gauch, 2010)
Speretta & Gauch explican que la aplicación proporciona una ambiente público y
otro para usuarios que estén registrados; para el perfil público el sistema provee a
los usuarios una vista de las ontologías propias del repositorio, además permite
crear ontologías de dominio personal temporalmente. El área restringida o para
usuarios registrados permite realizar la carga al repositorio de nuevas ontologías o
la edición de las existentes, en general la administración de este tipo de
información.
37
A continuación se ilustra mediante una imagen de pantalla de Miology, como los
usuarios pueden interactuar con las diferentes ontologías, cada una de ellas
puede ser seleccionada y a su vez ser navegada como se ilustra en la figura 9.
Figura 8. Librería de Ontologías de Miology. (Speretta & Gauch, 2010)
Figura 9. Navegación de Ontologías a través Miology. (Speretta & Gauch, 2010)
38
CreaDO (Sabino , Hugo , Alicia, & Mari Carmen, 2011), es una nueva metodología
para la construcción de ontologías de dominio que sólo contienen el conocimiento
relevante para un propósito específico.
La metodología recibe como primera entrada un conjunto de ontologías
denominadas ontologías de origen (que se obtienen a partir del análisis de
documentos individuales), y como segunda entrada una combinación de
parámetros que tienen un concepto relativo al dominio de las ontologías de origen.
La salida consiste en un dominio de ontología que representa todo el conocimiento
de la mezcla entre las ontologías de origen, con los parámetros.
La metodología, usa técnicas similares a la reutilización de ontologías, tales como
la fusión de ontologías y las técnicas de modularización de la ontología.
La técnica de fusión de ontología, se utiliza para unir de forma consensual el
conocimiento representado en ontología de origen. Sin embargo, se debe tener
en cuenta que las ontologías utilizadas fueron construidas por diferentes personas
y/o por diversos aplicativos, lo cual tiene varias desventajas o aspectos no
favorables, como el uso de diferentes patrones, diferentes taxonomías, o lo más
grave, ontologías mal diseñadas y estructuradas.
CreaDO (Sabino , Hugo , Alicia, & Mari Carmen, 2011), tiene la ventaja de resolver
o mitigar los anteriores problemas, ya que esta metodología incluye un
procedimiento para revisar las ontologías. Básicamente se trata de hacer una
revisión, en la cual se verifica la fuente de la ontología, con el objetivo de
identificar errores estructurales y funcionales, además de la extensión de
elementos de la ontología con información léxica.
39
Es importante indicar que la ontología de fusión, que se basa, como ya se indicó
en encontrar coincidencias entre ontologías, realiza esta búsqueda por medio de
un conjunto de reglas de asignaciones y un algoritmo que identifica coincidencias
entre entidades de las múltiples ontologías. (Identifica solo aquellas coincidencias
que se relacionan con el conocimiento equivalente).
Figura 10. Vista General de la Metodología CreaDO. (Sabino , Hugo , Alicia, &
Mari Carmen, 2011)
A continuación veremos un pequeño caso del funcionamiento de la metodología,
para esto se hará referencia al ejemplo citado por Sabino, Alicia y Carmen en su
informe, éste se basa en dos ontologías de turismo. La primera es la ontología
ETP-Tourism (Programa de Transformación Económico) y la segunda es la
ontología OTN (Ontología de Redes de Transporte), el parámetro de conjunción es
Turismo.
40
Figura 11. Fragmentos de Ontologías de Turismo. (Sabino , Hugo , Alicia, & Mari
Carmen, 2011)
a) Método Evaluación de Ontología. Este, identifica de las ontologías de
entrada errores de diseño y estructurales; el método obtiene información
léxica de cada una de las clases que componen las ontologías; con ésta se
tiene más conocimiento de las clases y permiten encontrar correspondencia
entre dos clases de las ontologías en evaluación, para lograrlo el método se
basa en una búsqueda de sinónimos en WordNet. La información léxica se
usa para determinar similitudes entre dos conceptos y los sinónimos
asociados a esos conceptos. Por ejemplo, en el caso de estudio la
ontología ETP contiene las clases Recreación y Safari. El sinónimo de la
clase Recreación es Diversión y el sinónimo de Safari es Campign, Caza y
Expedición. (Sabino , Hugo , Alicia, & Mari Carmen, 2011)
41
b) Método de Definición del Parámetro de Unificación. Este dato, representa el
dominio de la ontología, éste es utilizado para filtrar el conocimiento
obtenido de la metodología origen. (Sabino , Hugo , Alicia, & Mari Carmen,
2011)
c) Método de Modularización de la Ontología. El objetivo es la obtención de un
módulo de ontología para cada una de las ontologías fuentes. En el caso de
estudio para la ontología ETP el parámetro de unificación es Turismo y su
sinónimo es Turístico, el cual por medio de este método genera un módulo
limpio de ontología, el cual no contiene ningún elemento. Para la ontología
OTN se genera un módulo que contiene nueve clases (Tourism, Service,
Historical_Monument, Tourist_Atraction, Tourist_Office, Vantage_Point,
Location_Reference, Feature, Node), dos propiedades de objetos
(locationReference (Feature, Location_Reference), isDisplayedAt (Service,
Node)) y cuatro propiedades de tipos de datos (alternativeName
(Feature,String), houseNumber (Service, String), externalLink (Feature,
URL), externalLink (Feature, String)). (Sabino , Hugo , Alicia, & Mari
Carmen, 2011)
d) Método Mapeo de Ontología. El objetivo de este es identificar las
correlaciones de las ontologías de origen, para lograrlo el método define un
mapeo entre dos elementos y cuando existe una relación entre estos, se
determina que existe una relación entre las dos ontologías. Todo esto se
realiza por medio de unas reglas de mapeo. Continuando con el ejemplo
equivalentClass(Ferry, Ferry): el elemento Ferry de la ontología ETP
corresponde con el elemento Ferry de la ontología OTN. (Sabino , Hugo ,
Alicia, & Mari Carmen, 2011)
42
e) Método Ontología de Fusión. Tiene como objetivo unir a los módulos
obtenidos del método de modularización para finalmente generar una nueva
ontología. Esta ontología es la nueva ontología de dominio. El método
además utiliza el resultado de la aplicación de las reglas del método de
mapeo. Para el ejemplo citado se tomó el módulo de la ontología OTN
(equivalentClass(Service, Service)) generado por el método de
modularización y el de mapeo con sus reglas de filtrado, el resultado es la
obtención una ontología que contiene:
Diez clases (OTN:Tourism, OTN:Service, ETP:Service,
OTN:Historical_Monument, OTN:Tourist_Atraction,
OTN:Tourist_Office, OTN:Vantage_Point, OTN:Location_Reference,
OTN:Feature, OTN:Node)
Dos propiedades de los objetos (OTN:locationReference
(Feature,Location_Reference), OTN:isDisplayedAt (Service,Node)), y
Cuatro propiedades de tipos de datos (alternativeName (Feature,
String), houseNumber (Service, String), externalLink (Feature, URL),
externalLink (Feature, String)). (Sabino , Hugo , Alicia, & Mari
Carmen, 2011)
f) Método de Evaluación de la Ontología de Dominio. El objetivo es evaluar la
ontología de dominio con el fin de identificar las inconsistencias a nivel de la
estructura. En el ejemplo, la ontología de dominio generada no presenta
inconsistencias en la estructura. (Sabino , Hugo , Alicia, & Mari Carmen,
2011)
43
El método OntOAIr (Medina, Bonilla, & Sánchez, 2008) consta de cuatro tareas
principales: la recolección, la representación, agrupación y la formalización. La
tarea de la recolección obtiene los documentos de las colecciones. La tarea
representación construye una grafía vectorial para cada documento recolectado.
La tarea de agrupamiento se aplica un algoritmo exclusivo jerárquico para los
vectores con el fin de producir un árbol de conglomerados. La tarea de
formalización transforma el árbol de grupos en una ontología de peso ligero.
Las ontologías construidas mediante el método de OntOAIr constituyen un modelo
de datos capaz de proporcionar una terminología clara, que es correctamente
interpretada y usada por los humanos y el software. Las ontologías son también
un modelo de recuperación de información automático, ya que soporta indexación.
El proceso de indexación se basa en dos tareas: (1) la selección de los elementos
informativos de cada registro, y (2) la organización de los registros en las
estructuras de datos que permiten la búsqueda. El proceso de recuperación se ha
implementado a través del modelo de recuperación basado en palabras clave y la
ontología en el modelo de exploración. Estos modelos asumen que un registro
que no coincide con alguno de los términos de la consulta no es relevante.
El método OntOAIr se puede utilizar para apoyar la construcción manual de
ontologías, para agrupar las respuestas de los motores de búsqueda, o como base
para apoyar el razonamiento en contextos de la Web Semántica.
Como se propone en la metodología de CreaDO, este tipo de esquema conceptual
también deberá ser construida a partir de otras ontologías de origen y de los
parámetros que tengan relación con el dominio de dichas representaciones
conceptuales, para de esta manera tener la ontología de fusión que representa
todo el modelo de negocio de un tema en particular. Todo lo anterior, se apoyaría
a partir de la propuesta que tiene el método OntOAIr, el cual al aplicar las cuatro
44
etapas que lo constituyen, garantizarían el tener unos esquemas conceptuales
más reales.
Las metodologías CreaDo y OntoAir contienen información, sobre como
documentar de tal manera que se puedan combinar o fusionar ontologías, como
hacerlo de forma modular, que permiten el uso de consulta automática y soportan
indexación; lo cual puede ser perfectamente aplicable en la documentación de
modelos de negocios, dentro de la etapa de elicitación de requisitos.
(Aranda & Ruiz, 2005) en su informe sobre la clasificación y ejemplos del uso de
ontologías en Ingeniería de Software indican que las ontologías se han convertido
en herramientas que pueden asistir eficientemente en las actividades de desarrollo
y mantenimiento de software ya que, al reducir la ambigüedad y proveer un marco
de unificación, ayudan a compartir conocimiento, facilitan la comunicación y
permiten una alta reutilización de conocimiento.
Las anteriores metodologías y ontologías permiten lograr lo referenciado por
Aranda & Ruiz, la metodología de la ingeniería virtual, la herramienta Miology, la
metodología CreaDO y el método OntOAIr coinciden en en no permitir la
ambigüedad en la información, facilitar la reutilización de los datos, permitir la
conectividad con otras ontologías lo cual facilita tener una gama de conceptos más
amplios y relacionados, además de la facilidad en acceso a los datos a cualquier
nivel, tanto del analista y como del interesado. Ontología de Dominio.
Uschold-Gruninger afirmó que en la Ingeniería de Sistemas, se usan las
ontologías para soportar el diseño y desarrollo de software con varios propósitos,
por ejemplo para el caso de la especificación, el rol que las ontologías juegan en
éste depende del grado de formalidad y automatización dentro de la metodología
de diseño del sistema. Desde un enfoque informal, las ontologías facilitan el
proceso de identificación de requerimientos y la comprensión de las relaciones
45
entre componentes. Esto es particularmente importante cuando existen conjuntos
de diseñadores distribuidos trabajando sobre diferentes dominios. Desde un
enfoque formal, una ontología provee una especificación declarativa de un
sistema, la cual permite a los diseñadores razonar sobre “para qué” se está
diseñando el sistema en lugar de “cómo” soportar la funcionalidad. (Aranda &
Ruiz, 2005)
Siguiendo en la línea del informe de Aranda & Ruiz, en este se cita a Girardi, R.,
Faria C, donde explican que gracias a las ontologías, la etapa de elicitación y
modelado de los requerimientos puede ser llevada a cabo en dos fases: en una
primera se puede elicitar el conocimiento general del dominio y especificarlo en
una o más ontologías, y en una segunda etapa las ontologías obtenidas en la fase
anterior se utilizan como líneas para desarrollar las aplicaciones específicas. La
ontología construida a partir de la primer etapa de adquisición de conocimiento
sirve como vocabulario básico para hablar acerca del dominio y es la base para el
desarrollo de las conceptualizaciones específicas de las aplicaciones que se
quieren construir, esto es precisamente lo que hacen las metodologías y
herramientas explicadas en el capitulo, donde finalmente siempre se generaran
ontologías de dominio. (Girardi & Faria, 2003)
46
3.3 IDENTIFICACIÓN DE ELEMENTOS DE MODELOS,
METODOLOGIAS U ONTOLOGÍAS QUE SE PUEDEN APLICAR O
UTILIZAR PARA LA CONCEPTUALIZACIÓN DEL MODELO DEL
PROCESO DE NEGOCIO.
En los dos anteriores capítulos, varios autores ilustraron que las ontologías son
utilizadas en gran diversidad de entornos, en la actualidad existen muchos
métodos, metodologías, herramientas y tipos de ontologías que apoyan el proceso
de elicitación de requisitos, representación de requerimientos, gestión de
proyectos de software, y representación del modelo del proceso del negocio.
Todas éstas coinciden que las ontologías de dominio son el tipo de ontología que
puede usarse para la representación del proceso del modelo de negocio.
En el 2009 en la quinta conferencia internacional sobre semántica, conocimiento y
red, Bin Wen, Keqing He, Jian Wang explicaron que la conectividad de ontologías
de dominio es una herramienta útil para la representación de requerimientos en la
ingeniería del software. Pero la simple representación de éstos en este tipo de
ontologías no garantiza tener unos requisitos bien elaborados; para lograr esto es
necesario tener presente gran variedad de definiciones de dominio de ontología y
sus algoritmos que generan estas relaciones. (Wen, He, & Wang, 2009).
El entendimiento compartido que proveen las ontologías, permiten establecer
correspondencia y relaciones entre diferentes dominios, de acuerdo a la
investigación realizada por (Quero Bastidas, 2007), Motishi Saeki presentó un
proyecto de investigación en la universidad de Tokio, donde se pretendió buscar
dar soporte al manejo de requerimientos en la ingeniería de software, la
metodología expuesta se basa en el procesamiento semántico de los
47
requerimientos y de los elementos reutilizables basados en las técnicas
ontológicas. Esta consiste básicamente en un sistema de ontologías basado en un
diccionario de términos que pertenecen a un dominio específico; los
requerimientos son levantados en base a palabras relevantes que se encuentran
en el sistema de ontologías.
ODE (Ontology-based software Development Enviroment), es una ontología que
permite realizar gestión de requisitos, calidad de software, análisis de riesgos,
entre otros. Es un sistema basado en un enfoque ontológico que permite integrar
las etapas del desarrollo de software, este sistema permite soportar el proceso de
definición de software, seguimiento e integración. (Quero Bastidas, 2007)
La arquitectura de la ontología ODE se basa en ontologías. Tiene dos niveles,
como se muestra en la siguiente figura. La clase base o nivel de aplicación se
refiere a las clases de aplicación, que modelan los objetos que se ocupan de una
actividad de ingeniería de software. El meta-nivel (o nivel de conocimiento) define
las clases que describen el conocimiento acerca de los objetos en el nivel de base.
Figura 12. Arquitectura ODE. (Falbo, Cruz Natali, Gomes Mian, Bertollo, & Borges
Ruy, 2003)
48
Para ilustrar como ODE administra el conocimiento, se explicará la siguiente
situación: Según (Falbo, Cruz Natali, Gomes Mian, Bertollo, & Borges Ruy, 2003)
en general una actividad de diseño se puede descomponer en diseño
arquitectonico y las actividades de diseño en detalle.
Este conocimiento general se describe en el Paquete de Conocimiento. En la
definición del proceso de software, ODE provee esta guía al administrador del
proyecto, el cual finalmente puede aceptar o no la propuesta. Si es aceptada, se
generan dos nuevas actividades en el Paquete de Contol de Procesos, con sus
correspondientes asociaciones. La Figura 13 ilustra el ejemplo en el contexto de la
herramienta de definición de procesos del software ODE. Una vez definido el
proceso, puede ser ejecutado y monitoreado.
ODE tiene varias herramientas para apoyar las actividades de construcción (tales
como herramientas CASE para el análisis y diseño orientado a objetos), las
actividades de gestión (por ejemplo, herramientas de análisis de puntos de fusión
y administración del riesgo) y actividades de control de calidad (por ejemplo una
herramienta de planeación y control de calidad).
Para el seguimiento de proyectos, ODE ofrece una herramienta que presenta los
procesos y el estado de sus actividades (listo, a la espera, en ejecución, entre
otros.), como se muestra en la figura 14.
49
Figura 13. Herramienta ODE de definición de Procesos. (Falbo, Cruz Natali,
Gomes Mian, Bertollo, & Borges Ruy, 2003)
Figura 14. Herramienta ODE para el Seguimiento del Proyecto. (Falbo, Cruz
Natali, Gomes Mian, Bertollo, & Borges Ruy, 2003)
50
Los requisitos hoy en día se estan apoyando en la utilización de ontologías, sobre
todo ontologías de dominio, ya que cada requisito tiene que ver con una
conceptualización de negocio particular, debido a que estos permanecerán
enmarcados en los procesos organizacioneles, los cuales finalmente son los que
se elicitan para dar soluciones informaticas.
El desarrollo de software esta centrado en el conocimiento. Diferentes tipos de
conocimiento son importantes para dar soporte a las actividades en las
organizaciones que utilizan software, se require conocer nuevas tecnologias,
practicas locales, politicas, regulaciones y conocimiento propio de cómo funcionan
éstas.
En el capítulo del modelo de negocio se expresó, que el ingeniero de requisitos y
finalmente el programador comienzan un trabajo donde debe entender no solo el
software a construir si no el dominio en el que pertenece, es decir, buscar
entender las tareas o actividades que estén asociadas implícitamente con los
conceptos del dominio del proceso de negocio de la organización que se desea
automatizar o gestionar, a través de un aplicativo computacional.
Basado en el concepto DOSDE (DOMINE-ORIENTED SOFTWARE
DEVELPMENT ENVIROMENT), el cual permite tener un modelo organizacional en
cuanto a su estructura, procesos y distribución del conocimiento, se ha definido
una ontología de dominio DOSDE, que permite a través de la subdivisión de
ontologías, facilitar la definición de la composición del negocio. Cada una de éstas
es un grupo de conceptos que comparten un mismo contexto semántico. (Bedoya
& Urrego, 2011)
51
Todo este conocimiento debe ser Organizado. Según Guarino se puede clasificar
de la siguiente manera:
Ontologías de Domino que describen todo el vocabulario relacionado con el
dominio especifico.
Ontologías de Tareas que describen las tareas genéricas o actividades.
Una tarea puede ser definida como "Una secuencia necesaria de pasos
para solucionar un problema".
La ontología de Dominio DOSDE se considera una metodología que está
compuesta por cuatro fases:
La primera es la definición del propósito de la ontología,
La segunda es la conceptualización,
Luego se realiza la formalización
Y por último la validación.
(Bedoya & Urrego, 2011) definen que el propósito es la asistencia a los diferentes
stakeholders tales como ingenieros de negocio, ingenieros de requisitos, analistas,
desarrolladores de software, entre otros; la conceptualización es la más extensa y
es la que requiere la identificación de los conceptos del domino, con una buena
descripción de cada uno, también se describen los atributos, las características de
cada concepto y los valores para cada uno de los atributos.
Una ontología de tareas provee una especificación de objetos y las relaciones
sobre estos, que son necesarias para realizar una tarea.
52
El estado de la tarea en una ontología es compuesto por tres niveles:
Nivel Léxico: el cual lista la los aspectos sintácticos de la solución del
problema.
Nivel Conceptual: contiene las actividades, objetos y estados que
corresponden a los verbos genéricos, sustantivos, y adjetivos definidos en
el nivel Léxico.
Nivel Simbólico: representa conceptos, y restricciones en el lenguaje formal.
Una ontología de tareas se limita a describir la tarea conceptualmente, esto no
especifica cómo debe ser desarrollada. El detalle para la solución del problema es
descrito por un método para la solución de problemas (PSM), en este se plantean
cuales son las tareas a llevar a cabo, cual es su orden, como deben ejecutarse, y
cómo interactúan entre ellas. (Bedoya & Urrego, 2011)
Figura 15. Mapa Conceptual Entorno de Desarrollo DOSDE (Bedoya & Urrego,
2011)
53
Alexander Osterwalder, propone un tipo de ontología genérica que permite
documentar el proceso del modelo de negocio; ésta agrupa las principales
variables de un negocio en particular, a través de la estructura de nueve bloques
temáticos.
Figura 16. Diagrama de la ontología de modelos de negocio propuesta por
Osterwalder. (Márquez García, 2010)
El bloque temático “Propuesta de Valor” representa el conjunto de la oferta de
valor que se dirige a uno o varios segmentos de mercado a través de unos
canales y con una forma específica de relacionamiento con los respectivos
clientes; los tres asuntos anteriores están representados por los bloques de
Relaciones con Clientes, Segmentos de Clientes, Canales de Distribución y
Comunicación ubicados a la derecha de la figura. (Márquez García, 2010)
54
Los bloques ubicados a la izquierda de la grafica, Actividades Clave, Red de
Aliados y Recursos Claves, representan los capitales, actividades y terceros que
actúan como aliados necesarios para producir y mantener la oferta de valor. Los
bloques inferiores representan el reflejo de ingresos y costos del conjunto anterior.
(Márquez García, 2010) cita en más detalle cada uno de los bloques:
Segmentos de clientes: se listan los diferentes tipos de clientes a los que se
dirige la oferta. La clasificación se hace con base en diferencias en
necesidades, forma de accederlos, tipo de relación y rentabilidad, entre
otros. Después se procede a describir en mayor detalle cada uno de ellos,
con base en variables demográficas, geográficas y sicográficas, entre otras.
Propuesta de valor: la oferta es lo que atrae a los clientes; aquello por lo
que están dispuestos a pagar. Se presenta como un paquete de productos
y servicios y los principales atributos de cada uno. Puede haber una oferta
única o varias ofertas y éstas pueden dirigirse a un segmento en particular
o a varios de ellos.
Canales de distribución y comunicación: identificar los canales a través de
los cuales se accede a los clientes para comunicarse con ellos y para
ofrecer la propuesta de valor. Entre ellos están la fuerza de ventas, los
puntos de venta, los afiliados, la publicidad, las reuniones, los sitios web,
etc.
Tipo de relaciones con los clientes: definir cuáles tipos de relaciones se
establecen con cada uno de los segmentos atendidos, desde las más
personalizadas, como tener ejecutivos de cuenta, pasando por relaciones
personales pero masivas como el contact center, hasta aquellas relaciones
55
por medio de los portales web o de voz, automatizados, entre otros. Se
deben tener en cuenta las distintas etapas del ciclo de la relación como
preventa, venta, postventa y migración a nuevas ofertas.
Fuentes de ingresos: son las fuentes de las cuales se reciben los ingresos
por la propuesta de valor que se ofrece. Se incluyen acá: transacciones,
suscripciones, servicios, licenciamiento, alquiler, pauta publicitaria, entre
otros.
Recursos clave: son los recursos que una compañía debe desplegar para
hacer que el negocio funcione. Incluye recursos físicos, intelectuales,
humanos y financieros. Pueden ser propios, arrendados o adquiridos de sus
aliados clave.
Actividades clave: son las principales actividades que deben realizarse
mediante la utilización de los recursos clave para producir la oferta de valor
y para gestionar las relaciones con los clientes y los aliados. Es
imprescindible concentrarse en las competencias esenciales y buscar
aliados para las demás.
Red de aliados: conformada por los aliados y proveedores que deben
identificarse y con los que se establecen relaciones. Para lograr ciclos de
innovación más rápidos y exitosos cada vez es más importante apalancarse
en recursos y actividades de terceros, con los que se puede lograr construir
o complementar la oferta de valor u optimizar costos.
56
Estructura de costos: la estructura de costos está fundamentada en el
listado de los costos más significativos del modelo de negocio,
fundamentalmente recursos, actividades y red de aliados así como su
relación con los demás bloques.
En la figura 17 se presenta, a manera de ejemplo, el modelo de negocio de Skype,
que es una compañía que ofrece servicios de telecomunicaciones sobre la
plataforma de internet; en su oferta se destaca el servicio de las llamadas sin
costo entre usuarios de la misma red (Skype in). Aunque una persona no esté
familiarizada con esta empresa, el modelo representado en el esquema de los
nueve bloques resulta muy comprensible. (Márquez García, 2010)
Figura 17. Diagrama Modelo del negocio de Skype. (Márquez García, 2010)
57
Todos los elementos antes descritos, afianzan el concepto de que la utilidad que
ofrecen las ontologías, permite documentar los modelos de negocio de tal manera,
que son posible actualizarlos y ampliarlos, además de consultarlos. Esto
permitiría evitar el reproceso que se está generando actualmente en la ingeniería
de requisitos.
58
4. CONCLUSIONES
En cualquier área del conocimiento humano es posible el uso de las ontologías,
como vimos en el documento, varios autores indicaron que en la medicina, la
ingeniería civil, la informática, el turismo y en cualquier otro aspecto se puede
hacer uso de esta metodología de divulgación y gestión de conocimiento;
cualquier persona además puede hacer uso de las herramientas que hay en la
internet para elaborar una ontología de un conocimiento en particular sin
necesidad de ser experto en la elaboración correcta de una de estas.
El uso de las ontologías en la ingeniería de los requisitos es más común de lo que
se consideró al momento de plantear la elaboración de esta investigación,
diferentes metodologías y formas de generar ontologías hay en la actualidad que
permiten ser usadas en la ingeniería de requisitos apoyándose en la gestión de la
información para tener la conceptualización del modelo de negocio de lo que se
desea elicitar.
Las ontologías de dominio, son en común las más usadas para poder plasmar el
modelo de negocio en la elicitación de requisitos, se encontró que (Bedoya &
Urrego, 2011) a través de la metodología DOSDE definen que este tipo de
ontología es la más adecuada para soportar dicho proceso y administrar la
información pertinente en de la contextualización del modelo de negocio.
Sin embargo, no es la única metodología que existe para realizar este proceso,
existen muchas que se tratan el documento y pueden ser usadas para apoyar la
gestión del conocimiento durante la conceptualización del modelo de negocio en la
etapa de elicitación de requisitos en una empresa de desarrollo de software.
59
GLOSARIO
CMMI: es un modelo para la mejora y evaluación de procesos para el desarrollo,
mantenimiento y operación de sistemas de software.
CONCEPTUALIZACIÓN DEL MODELO DEL NEGOCIO: abstracción de cómo
funciona la organización. Es tener una vista simplificada de la estructura y
comportamiento del negocio que actuará como la base de comunicación, mejora o
innovación del negocio, así como también para definir los requisitos de los
diferentes sistemas de software que pueden soportar al negocio.
ELECITACIÓN DE REQUISITOS: es el proceso de adquirir (“eliciting”) [sonsacar]
todo el conocimiento relevante necesario para producir un modelo de los
requerimientos de un dominio de problema.
METRICA V3: metodología de Planificación, Desarrollo y Mantenimiento de
sistemas de información, esta metodología es promovida por el Ministerio de
Administraciones Públicas del Gobierno de España, para la planificación,
desarrollo y mantenimiento de sistemas informáticos para la gestión de actividades
del ciclo de vida de los proyectos de software dentro de las Administraciones
Públicas.
http://administracionelectronica.gob.es/?_nfpb=true&_pageLabel=P800292251293
651550991&langPae=es&detalleLista=PAE_000000432
ONTOLOGÍAS: esquema conceptual dentro de uno o varios dominios, éste
permite una fácil comunicación o intercambio de información entre diferentes
sistemas.
60
RUP: es un proceso de desarrollo de software desarrollado por la empresa
Rational Software, actualmente propiedad de IBM. Junto con el Lenguaje
Unificado de Modelado UML, constituye la metodología estándar más utilizada
para el análisis, diseño, implementación y documentación de sistemas orientados
a objetos.
STAKEHOLDERS: desde el punto de vista del desarrollo de sistemas, un
"stakeholder" es aquella persona o entidad que está interesada en la realización
de un proyecto o tarea, auspiciando el mismo ya sea mediante su poder de
decisión y/o de financiamiento o a través de su propio esfuerzo.
61
BIBLIOGRAFÍA
Aranda, Gabriela N.; Ruiz, Francisco, 2005. Clasificación y ejemplos del uso de
ontologías en Ingeniería del Software. XI Congreso Argentino de Ciencias de la
Computación - Universidad Nacional de La Plata
Bedoya, Diana; Urrego, German. (19 de 09 de 2011). ConceptosOntologia. Recuperado
el 14 de 05 de 2013, de http://conceptosontologia.wikispaces.com/
Berners-Lee, T., Hendler , J., & Lassila, O. (2001). The Semantic Web. Scientific
American.
Casadesus-Masanell, Ramon; Ricart, Joan E. 2007. Competing Through Business
Models. Universidad de Navarra - Pamplona, España
CMMI Institute, 2013. Capability Maturity Model Integration - http://cmmiinstitute.com/
Durán Toro, A., & Bernárdez Jiménez, B. (2000). Metodología para la Elicitación de
Requisitos de Sistemas Software V 2.1. Sevilla: Universidad de Sevilla.
Falbo, Ricardo de Almeida; Cruz Natali, Ana Candida; Gomes Mian, Paula; Bertollo,
Gleidson; Borges Ruy, Fabiano, 2003. ODE: Ontology-based software
Development Environment
Girardi, R.; Faria, C., 2003. A Generic Ontology for the Specification of Domain Models. -
Alemania.
62
Gobierno de España, 2013. Métrica v.3 - Portal de Administración Electronica -
http://administracionelectronica.gob.es/?_nfpb=true&_pageLabel=P800292251293
651550991&langPae=es&detalleLista=PAE_000000432
Grigoris, A., & Van Harmelen, F. (2004). A Semantic Web Primer. Cambridge;
Massachusetts: MIT.
Heflin, J. (10 de February de 2004). W3C. Recuperado el 10 de April de 2012, de W3C
Recommendation: http://www.w3.org/TR/webont-req/
Hepp; Dr. Martin, 2011. GoodRelations - http://www.heppnetz.de/projects/goodrelations/
Hepp, Martin 2013. Accommodation Ontology Language Reference - http://ontologies.sti-
innsbruck.at/acco/ns.html#overview
IBM, 2013. IBM - Rational Unified Modeling Language - UML Resource Center -
http://www-01.ibm.com/software/rational/uml/
IBM, 2013. IBM Rational Unified Process (RUP) - http://www-
01.ibm.com/software/rational/rup/
Juárez Pariente, Sabino; Estrada Esquivel, Hugo; Martínez Rebollar, Alicia; Suárez-
Figueroa; Mari Carmen, 2011. CreaDO – A Methodology to Create Domain
Ontologies using Parameter-based Ontology Merging Techniques. 10th Mexican
International Conference on Artificial Intelligence
Kedad, Zoubida, & Matias, Elisabeth. (2005). Ontology - Based Data Cleaning. Paris:
NLBD.
Leonardi, María Carmen. (2007). Modelo de Negocio – Ingenería de Requisitos.
63
Márquez García, Juan Fernando. 2010. Innovación en Modelo de Negocio: La
Metodología de Osterwalder en la Práctica. Universidad EAFIT - Medellín.
Matt, L. (2008). The first key to project success is collaborative requirements definition
and Manegement. Gartner, ID Number: G00160211 .
Medina, M., Bonilla, J., & Sánchez, J. (2008). OntOAIr: a method to construct lightweight
ontologies from document collections. IEEE Computer Society, 115-125.
Mencke, Steffen; Vornholt, Stephan; Dumke, Reiner. (2008). The Role of Ontologies in
Virtual Engineering.
Ordonez, David Antonio. 2011. Scrib - http://www.scribd.com/doc/59670054/Ontologia-
eSalud
Orrego, Erick; Ramirez, Alejandro (2010). ¿Qué es una Ontología?. Universidad de San
Carlos de Guatemala, Guatemala.
Pariente Juárez, S., Estrada Esquivel, H., Martínez Rebollar, A., & Suárez Figueroa, M.
(2011). CreaDO - A Methodology to Create Domain Ontologies using Parameter
based Ontology Merging Tecniques. IEEE Computer Society, 23-28.
Quero Bastidas, Adriana. (2007). Metodología para Desarrollo de Software Basada en
Ontología.
Rodriguez Mera, Jairo. (2011). Modelo de Negocio – La Evolución. Recuperado 15 de 03
de 2013, de slideshare: http://www.slideshare.net/jairodriguez/modelo-de-
negocios-02
64
Sebastián, Juan. (2011). ComuSOFT.com. Recuperado el 01 de 05 de 2013, de
http://www.comusoft.com/
Siricharoen, Waralak V. (2007). E-commerce Adaptation Using Ontologies for E-tourism
Sommerville, I. (2000). Software Engineering. Addison Wesley.
Speretta, Mirco; Gauch, Susan. (2010). Miology: a Web Application for Organizing
Personal Domain Ontologies.
Tallarico, Marcelo. 2004. Uso de Ontología en Recuperación de Información. Universidad
Nacional de Rosario - Facultad de Ciencias Exactas, Ingeniería y Agrimensura.
Rosario, Argentina.
Tokosumi, Akifumi; Matsumoto, Naoko; Murai, Hajime (2007). Medical Ontologies as a
Knowledge Repository.
UdeA, 2012. Metodologias procesos -
guajiros.udea.edu.co/fnsp/cvsp/Practica%20procesos/.../CicloPHVA.pdf
Van Heist, G., Schreiber, A., & Wielinga, B. (1997). Using Explicit Ontologies in KBS
Development. International Journal of Human-Computer Studies, 183-292.
Wen, Bin; He, Keqing; Wang, Jian. (2009). Connecting Ontologies: Semantic Carrier of
Requirements for Networked Software
Weske, M. (2007). Bussiness Process Masnagemente: Concepts,
Languages,Architectures. Berlin: Springrer.
Wikipedia, 2013. Ontología (informática) -
http://es.wikipedia.org/wiki/Ontolog%C3%ADa_(inform%C3%A1tica)