The best article we wrote in our entire lives

Transcripción

Gestión de conocimiento en grupos de
desarrollo de software
Jorge A. Quiroga
[email protected]
Universidad de los Andes, Bogotá, Colombia.
Resumen.
La gestión de conocimiento es una preocupación vigente de las
organizaciones hoy en día. Esto es especialmente cierto en el caso de las
organizaciones que producen y/o mantienen software dado que estas son
actividades que tienen una relación muy fuerte con la creación y distribución
del conocimiento. En este artículo se presenta una definición de lo que
significa la gestión de conocimiento en una organización, junto con
argumentos que soportan el por qué es importante la gestión de
conocimiento en la ingeniería de software. Finalmente se expone una
iniciativa que se está llevando a cabo para desarrollar una herramienta que
pretende aportar a la gestión de conocimiento en un grupo de desarrollo de
software.
Palabras clave.
Gestión de conocimiento, Ingeniería de Software, Ontología.
1 INTRODUCCIÓN
La preocupación por la gestión de conocimiento ha existido desde hace muchos años y se
puede rastrear hasta los tiempo de Peter Drucker en 1969 [16]. En el mundo ha habido
una creciente preocupación por otorgarle cada vez más importancia al conocimiento en
las organizaciones dándole un valor importante como activo [13][16]. Según plantea
Skyrme en [13], una de las razones por las cuales esto ha sucedido, es porque el valor de
una organización está representado por los activos intangibles – la gente, el know-how,
las marcas, patentes, licencias, etc.
En el caso de las empresas que desarrollan software es aun más evidente el gran
valor que aportan los activos intangibles, en principio por la misma naturaleza del
proceso de producción: la construcción de software es una actividad cognitiva y
fuertemente dependiente del conocimiento [18].
Sin embargo, las soluciones no son tan evidentes como el problema. Las diferentes
referencias ([7],[13],[14],[17]) presentan estudios de variadas aproximaciones que se han
utilizado y se encuentran tanto casos de éxito como casos de fracaso. El objetivo de este
artículo es explicar qué significa la gestión de conocimiento, exponer por qué es
importante en la ingeniería de software y finalmente presentar una inciativa real para el
desarrollo de una aplicación (SKM: Software Knowledge Management) que ayude a
gestionar el conocimiento en una organización de desarrollo de software. La aplicación
PARADIGMA - REVISTA ELECTRONICA EN CONSTRUCCIÓN DE SOFTWARE
2
[email protected]
será evaluada por un grupo de desarrollo real, el grupo QualDev del Grupo de
Investigación de Construcción de Software de la Universidad de los Andes [12].
El artículo está organizado de la siguiente manera. En la parte dos, se presenta una
definición de la gestión de conocimiento. En la parte tres, se explica por qué es
importante la gestión de conocimiento en el desarrollo de software. En la parte cuatro, y
basándose en las anteriores, se presenta una iniciativa real que está en proceso para la
construcción de la aplicación SKM. Esta aplicación pretende ayudar a gestionar el
conocimiento en los grupos de desarrollo de software, específicamente en la etapa de
diseño del proceso de construcción. Finalmente en la parte cinco se concluye y se
presentan posibles investigaciones futuras.
2 INTRODUCCIÓN A LA GESTIÓN DE CONOCIMIENTO
La definición de conocimiento del diccionario de la Real Academia de la Lengua Español
[6] es: “Acción y efecto de conocer.” Conocer: “Averiguar por el ejercicio de las
facultades intelectuales la naturaleza, cualidades y relaciones de las cosas.”. Aunque
algunas otras definiciones generales de conocimiento se pueden encontrar en la literatura,
es natural que la definición que tenga cada organización sea diferente debido a que éste es
un concepto subjetivo, en principio, como explican Bonifacio, Bouquet, & Traverso en
[3], porque su creación consiste en un acto subjetivo: el de la interpretación de
información. Por esto no existe una única manera de gestionar el conocimiento, es
necesario que una organización logre definir el concepto de conocimiento adecuadamente
(de lo contrario podría crear sistemas que nadie utiliza como Zephyr presentado en [4]),
sujeto a la manera como se hacen los procesos, a la cultura de trabajo que exista, a la
industria a la que pertenezca, etc. [4].
El conocimiento se puede subdividir en dos categorías, el conocimiento tácito (o
implícito) y el conocimiento explícito [3][4][7]. En los términos que lo pone Stewart en
[16], el conocimiento explícito es aquel que ya existe en forma de artefactos v.gr.,
documentos, reportes de trabajo, de productos, etc. Por otro lado, el conocimiento
implícito es aquel que está en la mente de las personas y en la experiencia. En principio el
conocimiento explícito es más fácil de gestionar que el implícito [3][16] porque puede ser
codificado y articulado de manera más fácil. Es más difícil que aquel que tiene
conocimiento en su cabeza (por ejemplo el saber cómo montar una bicicleta) lo pueda
expresar, codificar y compartir. Esto sucede porque cada persona tiene un marco de
referencia propio a través del cual interpreta y expresa el conocimiento. Lograr mediar
entre dos individuos para sentar acuerdos sobre su base de conocimiento es complicado
[3].
¿Qué es gestión de conocimiento? Thomas Davenport citado en [7] lo explica como
“un método para simplificar el proceso de compartir, distribuir, capturar, crear y entender
el conocimiento en una compañía”. Citado en el mismo trabajo, K.M. Wiig (1995) resalta
otros dos objetivos importantes de la gestión de conocimiento: (1) descubrir, desarrollar,
mantener y asegurar los recursos intelectuales y de conocimiento de una organización y
(2) determinar el conocimiento y la experiencia requerida para desarrollar tareas,
organizarlo, hacer que el conocimiento necesario esté disponible, codificado y distribuido
entre los actores relevantes.
VOL. 1
Gestión de conocimiento en grupos de desarrollo de software 3
En general se puede hablar de cuatro procesos en la gestión del conocimiento dentro
de cualquier organización: (1) Desarrollar nuevo conocimiento (2) Asegurar el
conocimiento existente (3) Distribuir el conocimiento y (4) Combinar el conocimiento
disponible [5].
3 ¿QUÉ IMPORTANCIA TIENE LA GESTIÓN DE
CONOCIMIENTO EN LA INGENIERÍA DE SOFTWARE?
A diferencia de otras disciplinas de la ingeniería, la ingeniería de software, como explica
Sommerville en [15], se ocupa de teorías, métodos y herramientas necesarias para
desarrollar software y no de materiales regidos por leyes físicas o por procesos de
manufactura. El conocimiento está implícito todo el tiempo en la naturaleza de los
procesos y resultados, debido a que el software está compuesto, de manera simplificada,
de ideas plasmadas en código: es intangible. La gestión de conocimiento en la ingeniería
de software es necesaria por la naturaleza del proceso mismo. En [18] se muestra cómo el
desarrollo de software es un proceso cognitivo que depende fuertemente del
conocimiento y por esto mismo es indispensable gestionarlo. Detallemos el proceso más
a fondo para entender varias de sus caracterizaciones que resaltan su relación con el
conocimiento y por ende, la importancia que tiene gestionarlo:
1. El proceso de desarrollo de software necesita conocimiento de diferentes
dominios; por lo menos de dos, el de la computación y el de dominio de
aplicación.
2. El conocimiento que se utiliza para construir una aplicación está distribuido entre
el desarrollador y el mundo exterior y es necesario aprender a integrar diferentes
fuentes de conocimiento en el mundo para lograr desarrollar la solución.
3. El objetivo del proceso de desarrollo no está completamente definido al
comienzo, se va determinando dinámicamente.
4. El proceso de desarrollo es una conversación continua entre las mentes humanas y
la construcción que se va logrando (es un proceso cíclico).
5. El proceso de desarrollo se distribuye a lo largo de un grupo social (incluso a
través de barreras geográficas) y a lo largo del tiempo.
6. En el proceso de desarrollo el conocimiento está distribuido en todo el grupo en la
medida en que cada desarrollador aporta un poco al grupo para complementar el
conocimiento.
Entendiendo la relación que tiene el proceso de construcción de software con el
conocimiento, se puede inferir entonces que es necesario gestionar el conocimiento para
poder lograr los siguiente objetivos: (1) entender el conocimiento que existe en el
dominio de la aplicación; (2) brindar a los desarrolladores una forma fácil y eficiente de
encontrar la información que necesitan para el desarrollo; (3) brindarle al grupo de
desarrollo una manera de que pueda hacer seguimiento de los objetivos planteados al
comienzo del proceso de desarrollo, que se puedan registrar los cambios que han surgido
y las implicaciones que estos cambios han forzado; (4) brindar un apoyo a los
desarrolladores que le permita a cada uno retroalimentar y construir sobre lo que ya se ha
hecho y sobre retroalimentaciones de otros miembros del grupo; (5) brindar un apoyo en
términos de colaboración entre los diferentes miembros del grupo para que
VOL. 1
4
[email protected]
complementen su conocimiento y construyan sobre los resultados producto de las
interacciones.
Pero no sólo es el proceso de desarrollo de software el qué depende fuertemente del
conocimiento, es también la organización como tal. Como se menciona en [1] es
necesario que las empresas que desarrollan software reconozcan que el conocimiento es
su ventaja competitiva y que es la base para la innovación, es por lo tanto uno de sus más
valiosos activos. Además la industria de software, según afirma Hein (1998) citado en
[1], la rotación de empleados en este sector asciende hasta un 40% anual. Entendiendo
que el conocimiento es un activo importante para las empresas que desarrollan software
¿cómo evitar que el conocimiento se deprecie? y ¿cómo retener ese conocimiento que en
potencia se fugaría con el empleado que se va? Ambas preguntas son un ejemplo de las
problemáticas que la gestión de conocimiento trata de resolver en el ámbito de la
ingeniería de software.
Algunas otras problemáticas concretas que se han identificado y que se mencionan
en [7] para un caso de estudio en una empresa alemana de software:
1. Los desarrolladores tienen problemas adaptándose a diferentes plataformas de
tecnología y herramientas.
2. Los desarrolladores toman mucho tiempo antes de obtener buenas habilidades de
programación y de administración de proyectos.
3. El conocimiento que un desarrollador genera, por ejemplo al resolver un problema
específico, no se dispersa a otros desarrolladores u otros grupos, haciendo que el
mismo problema se resuelva una y otra vez desde el comienzo y que se repitan los
mismos errores.
Finalmente, otras problemáticas que he detectado trabajando para el proyecto CUPI3
(Mejoramiento en la enseñanza/aprendizaje de software) de la Universidad de los Andes:
1. Las decisiones que se toman en la etapa de diseño no se registran de manera
formal y explícita argumentando con justificaciones claras y concisas.
2. Las decisiones que se toman en la etapa de diseño no se relacionan con los
diferentes artefactos generados durante esta etapa (diagramas de diseño,
diagramas de clase, casos de uso, diagramas de secuencia, entre otros).
Con el fin de abordar poco a poco el problema de la gestión de conocimiento en la
práctica, he conformado un grupo junto con otros cuatro estudiantes en el cual hemos
comenzado a construir una herramienta para solucionar las últimas problemáticas
mencionadas. El grupo de desarrollo fue creado únicamente con este propósito y bajo el
marco del Proyecto de Mitad de Carrera del departamento de Ingeniería de Sistemas de la
Universidad de los Andes. A continuación se muestra el trabajo.
VOL. 1
4
SKM: UNA PROPUESTA CONCRETA PARA ABORDAR EL
PROBLEMA
La etapa de diseño, en el proceso de desarrollo de software, es el pilar sobre el cuál se
llevan a cabo las etapas posteriores. Consideramos de suma importancia poder gestionar
el conocimiento que se genera en esta etapa por ser el que estará siempre en profunda
transformacion y será necesario revisarlo, aprender de él y compartirlo para poder
construir un producto de alta calidad y de manera eficiente. De hecho, el conocimiento
que se genera en esta etapa no es únicamente de suma importancia para el resto de etapas,
sino también para los ciclos que continuan. Dado que el proceso de construcción de
software es un proceso cíclico, es necesario poder utilizar el conocimiento que se ha
generado previamente para avanzar en el proceso: “pararse en los hombros del gigante”
como dijo Issac Newton.
Como se mencionó al final de la sección anterior, se conformó un grupo para que
construyera una herramienta que permitiera apoyar la solución de las dos últimas
problemáticas detectadas en el proceso de desarrollo de software:
1. Las decisiones que se toman en la etapa de diseño no se registran de manera
formal y explícita argumentando con justificaciones claras y concisas.
2. Las decisiones que se toman en la etapa de diseño no se relacionan con los
diferentes artefactos generados durante esta etapa (diagramas de diseño,
diagramas de clase, casos de uso, diagramas de secuencia, entre otros).
Hay que notar que la solución de estas problemáticas implicaría apoyar únicamente dos
de los procesos de gestión de conocimiento que se identificaron anteriormente en la
sección dos: asegurar el conocimiento existente y distribuir el conocimiento. En otras
palabras, el proyecto no contempla los procesos de desarrollar nuevo conocimiento, ni de
combinar el conocimiento existente.
Para el momento en que se escribe este artículo, únicamente el primer problema
(registrar las decisiones) ha sido tratado, implementado y probado. A continuación se
describe de qué se trata la solución.
Se decidió que la herramienta SKM (Software Knowledge Management) sería una
herramienta web basada en ontologías. La decisión de que fuera web se tomó con el fin
de que (1) se pueda integrar a otras herramientas de gestión de conocimiento
(generalmente implementadas sobre una intranet) y (2) de que el conocimiento se pueda
registrar, modificar y consultar desde cualquier computaor con conexión a internet. La
decisión de que fuera basada en ontologías proviene (1) del artículo de Sure [17], en
donde explica cómo las ontologías han demostrado ser la respuesta correcta para
estructurar y modelar problemas de conocimiento y (2) de un interés personal de los
integrantes del grupo en investigar este tipo de aplicaciones, dado que es uno de los
pilares de la prometedora Semantic Web según Berners-Lee [2]. Para esto, el grupo se
propuso los objetivos definidos en la Fig. 1.
VOL. 1
6
[email protected]
Figura 1 – Objetivos planteados para la realización de SKM.
El primer paso fue desarrollar la ontología que se utilizaría para registrar o asegurar el
conocimiento. Para esto se utilizó Protégé [11], un editor de ontologías de la Universidad
de Stanford, USA. La ontología se desarrolló en OWL [10], el lenguaje estándar hoy en
día para dicha tarea. El resultado se puede ver en el Anexo I escrito en OWL, o en la Fig.
2 como una representación gráfica.
Decisión de Diseño
Decisión de
Arquitectura
Jorge A. Quiroga
elaboradaPor
Justificación de
Arquitectura
Justificación2
Decisión2
justificadoPor
Decisión1
Decisión de
Persistencia
elaboradaEn
Justificación1
Justificación de
Persistencia
9 Enero 2007
Justificación3
Decisión3
Decisión4
texto
Justificación4
…
…
“Se decidió
implementar el
patrón MVC…”
Figura 2 – Representación gráfica de la ontología
VOL. 1
texto
“MVC
permite.
..”
El segundo paso fue entrar a definir ¿qué información sería deseable recolectar con
respecto a una decisión de diseño? Y se llegó al siguiente formato expuesto en Fig. 2 con
un ejemplo. Este formato está implementado en una interfaz html.
Identificador:
JD - 6
Nombre:
Estructura de datos para contener discos y canciones
Categoría:
Estructuras de datos
Decisión:
La estructura que contendrá tanto los discos como las canciones será un ArrayList.
Justificación:
Se utiliza esta estructura simplemente para facilitar el entendimiento del ejemplo a
los estudiantes ya que están acostumbrados a utilizar esta estructura en cursos
pasados.
Figura 3 – Formulario para registrar decisiones de diseño.
Tanto el identificador como el nombre logran diferenciar con precisión una decisión de
otra. La categoría permite agrupar las decisiones en conjuntos lógicos como por ejemplo:
decisión de estructuras de datos, decisión de arquitectura, decisión de las relaciones de
arquitectura, decisión de persistencia, decisión de algorítmica, entre otras. Finalmente, la
justificación obliga al grupo a considerar el por qué de una decisión, a justificarla con
argumentos fuertes (patrones, arquitecturas, complejidad), proceso que mucha veces
obviamos como ingenieros de software.
El último paso fue entrar a definir cómo mostrar el conocimiento registrado. Para
esto decidimos utilizar la herramienta Exhibit [8] de la universidad de MIT, que es muy
flexible porque permite al usuario utilizar diferentes filtros para consultar los datos. Para
poder utilizar esta herramienta fue necesario procesar el OWL para transformar el
conocimiento escrito en términos de la ontología a JSON [9], el lenguaje con el cuál se
construye el resultado en Exhibit. Todo el proceso se muestra en Fig. 4.
Figura 4 – Proceso para registrar una decisión.
Como se mencionó anteriormente, hasta el momento SKM sólo resuelve una de las
problemáticas detectadas, registrar las decisiones. Las funcionalidades de (1) registrar las
decisiones de diseño de acuerdo a la ontología y de (2) visualizarlas utilizando Exhibit,
son las únicas que se encuentran implementadas y probadas. El siguiente paso para
cumplir con los objetivos planteados por el grupo es permitir que se puedan relacionar las
VOL. 1
8
[email protected]
decisiones con otros artefactos de conocimiento i.e. código, diagramas UML, imágenes,
documentos, etc.
Si el lector está interesado en hacerle un seguimiento futuro a la herramienta, o en
conocer un poco más acerca de la investigación y el desarrollo que se está haciendo,
puede ingresar a la página http://skm.uniandes.edu.co
5 CONCLUSIONES Y TRABAJOS FUTUROS
Varias definiciones se pueden encontrar del término conocimiento; estas dependen del
contexto en el cual se utilice. Cuando hablamos de conocimiento en el contexto de las
organizaciones, traspasa la barrera del contexto y su significado llega incluso a diferir
entre una organización y otra. En el estudio realizado previamente, se expuso la fuerte
relación que existe entre el conocimiento y las organizaciones relacionadas con la
construcción de software. Se mostró también, cómo diferentes procesos dentro de estas
organizaciones están ligadas a la gestión de conocimiento y la gran atención que
últimamente este tema ha venido recibiendo y debe recibir en una economía de
conocimiento. Con el fin de ahondar más en el tema y de explorarlo en la práctica, se está
desarrollando la herramienta SKM que pretende ayudar a gestionar el conocimiento que
se crea en la etapa de diseño, más específicamente, a gestionar las decisiones y
justificaciones de diseño que surgen durante el proceso de creación de software.
Sin embargo, hay que resaltar que una de las conclusiones más claras que destacan la
mayoría de referencias, es el hecho de que la gestión de conocimiento debe abordarse de
una manera interdisciplinaria. No debe depender únicamente de una herramienta basada
en tecnologías de información y comunicación (TICs), debe contemplar otros aspectos de
la organización como su cultura, la definición de sus procesos, la definición de sus
objetivos, su estructura organizacional, entre otros. Es por esto que valdría la pena una
futura investigación que contemple el estado del arte, no sólo enfocado en la parte de
herramientas para la gestión de conocimiento, sino que comprenda una visión más amplía
que permita formular propuestas íntegras.
Con el fin de complementar esta pequeña investigación, se podrían utilizar métodos
de observación y análisis en un estudio de campo, en diferentes grupos de desarrollo que
se encuentren tanto en el ámbito académico como en el ámbito empresarial para
preguntarse: ¿Cómo se está gestionando el conocimiento (en cuanto a procesos y
herramientas) en las organizaciones que desarrollan software en Colombia? ¿Qué
beneficios reales están brindando estas prácticas? ¿Qué complicaciones se han
presentado? ¿Qué limitaciones se pueden observar en los procesos de desarrollo que la
gestión de conocimiento pueda entrar a resolver? ¿Qué prácticas, procesos y herramientas
han resultado útiles para gestionar el conocimiento en la práctica? Entre otras que habría
que entrar a definir.
En cuanto a la herramienta, se deja como trabajo futuro la solución al resto de las
problemáticas identificadas en cuanto a gestión de conocimiento en grupos de desarrollo
de software. SKM solo trata dos de estas, pero esto no significa que las otras sean menos
relevantes. Igualmente habría que entrar a determinar cómo apoyar los dos procesos de
VOL. 1
gestión de conocimiento que no se contemplaron en SKM: desarrollar nuevo
conocimiento y combinar el conocimiento existente.
6 AGRADECIMIENTOS
Gracias a la doctora Rubby Casallas del Grupo de Investigación en Construcción de
Software de la Universidad de los Andes, quien motivó a formalizar el estudio de lo que
en principio fue sólo un tema de interés, y quien aportó siempre al proyecto con su apoyo.
Gracias al resto de miembros del grupo de SKM con quienes hemos venido haciendo
tangible aquello que a veces logra enredársenos en nuestra mente.
REFERENCIAS
[1] Baskerville, R., & Jan, P.-H. (1999). Knowledge Capability and Maturity in Software
Management. ACM SIGMIS Database , 30 (2), 26-43.
[2] Bernes-Lee, T., Hendler, J., & Lassila, O. (2001, Mayo 17). The Semantic Web.
Scientific American .
[3] Bonifacio, M., Bouquet, P., & Traverso, P. (2002). Enabling Distributed Knowledge
Management: Managerial and Technological Implications . (Novática, Ed.) The
European Journal for the Informatics Professionals (http://www.upgrade-cepis.org) , 3,
23-30.
[4] Bossen C. & Dalsgaard P. (2005). Conceptualization and Appropriation: The
Evolving Use of a Collaborative Knowledge Management System. Proceedings of the 4th
decennial conference on Critical computing: between sense and sensibility CC '05 ACM
Press. Recuperado el 1ro de Marzo de 2007 de la base de datos The ACM Digital
Library.
[5] Chou D., Lin, B. (2002). Development of Web-based knowledge management
systems. Human Systems Management Volumen 21, (3), p153. Recuperado el 1ro de
Marzo de 2007 de la base de datos Business Source Complete adscrita a EBSCO.
[6] Diccionario Real Academia de la Lengua Española. (n.d.). Diccionario de la lengua
española - Vigésima segunda edición. Retrieved Abril 3, 2007, from http://www.rae.es
[7] Dingsoeyr, T., & Conradi, R. (2002). A Survey of Case Studies of the Use of
Knowledge Management in Software Engineering. International Journal of Software
Engineering and Knowledge Engineering , 12 (4), 391-414.
[8] Exhibit. http://simile.mit.edu/exhibit
[9] JSON. http://www.json.org/
VOL. 1
10
[email protected]
[10] OWL – Web Ontology Language. http://www.w3.org/TR/owl-features/
[11] Protégé Ontology Editor. http://protege.stanford.edu
[12] Qualdev (http://qualdev.uniandes.edu.co). Grupo de desarrollo que pertenece al
Grupo de Investigación en Construcción de Software del Departamento de Sistemas y
Computación de la Universidad de los Andes, Bogotá, Colombia.
[13] Skyrme, D. J. (1998). Knowledge management solutions - the IT contribution. ACM
SISGROUP Bulletin , 19 (1), 34-39.
[14] Sole, D., & Applegate, L. (2000, Diciembre). Knowledge sharing practices and
technology use norms in dispersed development teams. Proceedings of the twenty first
international conference on Information systems ICIS '00 , 581-587.
[15] Sommerville, I. (1996). Software Engineering. Addison Wesley.
[16] Stewart, K. A., Baskerville, R., Storey, V. C., Senn, J. A., Raven, A., & Long, C.
(2000). Confronting the assumptions underlying the management of knowledge: an
agenda for understanding and investigating knowledge management. ACM SIGMIS
Database , 31 (4), 41-53.
[17] Sure, Y., Staab, S., & Studer, R. (2002). Methodology for Development and
Employment of Ontology based Knowledge Management Applications. ACM SIGMOD
Record , 31 (4), 18-23.
[18] Ye, Y. (2006). Supporting Software Development as Knowledge-Intensive and
Collaborative Activity. (A. Press, Ed.) Proceedings of the 2006 international workshop
on Workshop on interdisciplinary software engineering research , 15-22.
VOL. 1
Anexos
Anexo 1 – Ontología para describir decisiones que se toman en la etapa de diseño del proceso de desarrollo
de software.
<?xml version="1.0"?>
<rdf:RDF
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:xsd="http://www.w3.org/2001/XMLSchema#"
xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"
xmlns:owl="http://www.w3.org/2002/07/owl#"
xmlns="http://quiroga.no-ip.org/softwareDesignOntology#"
xml:base="http://quiroga.no-ip.org/softwareDesignOntology">
<owl:Ontology rdf:about=""/>
<owl:Class rdf:ID="Justificacion_de_Visualización">
<owl:disjointWith>
<owl:Class rdf:ID="Justificacion_de_Elemento_Visual"/>
</owl:disjointWith>
<owl:disjointWith>
<owl:Class rdf:ID="Justificacion_de_Elemento_de_Interaccion"/>
</owl:disjointWith>
<rdfs:subClassOf>
<owl:Class rdf:ID="Justificacion_Decision_de_Interfaz"/>
</rdfs:subClassOf>
</owl:Class>
<owl:Class rdf:ID="Decision_de_Elemento_Visual">
<owl:disjointWith>
<owl:Class rdf:ID="Decision_de_Elemento_de_Interaccion"/>
</owl:disjointWith>
<owl:disjointWith>
<owl:Class rdf:ID="Decision_de_Visualización"/>
</owl:disjointWith>
<rdfs:subClassOf>
<owl:Class rdf:ID="Decision_de_Interfaz"/>
</rdfs:subClassOf>
</owl:Class>
<owl:Class rdf:about="#Decision_de_Elemento_de_Interaccion">
<owl:disjointWith rdf:resource="#Decision_de_Elemento_Visual"/>
<owl:disjointWith>
<owl:Class rdf:about="#Decision_de_Visualización"/>
</owl:disjointWith>
<rdfs:subClassOf>
<owl:Class rdf:about="#Decision_de_Interfaz"/>
</rdfs:subClassOf>
</owl:Class>
<owl:Class rdf:ID="Decision_de_Persistencia">
<owl:disjointWith>
<owl:Class rdf:ID="Decision_de_Arquitectura"/>
</owl:disjointWith>
<owl:disjointWith>
<owl:Class rdf:ID="Decision_de_Estructura_de_Datos"/>
</owl:disjointWith>
<owl:disjointWith>
<owl:Class rdf:ID="Decision_de_Algoritmica"/>
</owl:disjointWith>
VOL. 1
12
[email protected]
<owl:disjointWith>
<owl:Class rdf:ID="Decision_de_Relaciones_Arquitecturas"/>
</owl:disjointWith>
<rdfs:subClassOf>
<owl:Class rdf:ID="Decision_de_Kernel"/>
</rdfs:subClassOf>
</owl:Class>
<owl:Class rdf:about="#Justificacion_Decision_de_Interfaz">
<rdfs:subClassOf>
<owl:Class rdf:ID="Justificacion_de_Disenho"/>
</rdfs:subClassOf>
</owl:Class>
<owl:Class rdf:ID="Justificacion_de_Arquitectura">
<owl:disjointWith>
<owl:Class rdf:ID="Justificacion_de_Estructuras_de_Datos"/>
</owl:disjointWith>
<owl:disjointWith>
<owl:Class rdf:ID="Justificacion_de_Algoritmica"/>
</owl:disjointWith>
<owl:disjointWith>
<owl:Class rdf:ID="Justificacion_de_Persistencia"/>
</owl:disjointWith>
<owl:disjointWith>
<owl:Class rdf:ID="Justificacion_de_Relaciones_de_Arquitecturas"/>
</owl:disjointWith>
<rdfs:subClassOf>
<owl:Class rdf:ID="Justificacion_Decision_de_Kernel"/>
</rdfs:subClassOf>
</owl:Class>
<owl:Class rdf:about="#Decision_de_Estructura_de_Datos">
<rdfs:subClassOf>
<owl:Class rdf:about="#Decision_de_Kernel"/>
</rdfs:subClassOf>
<owl:disjointWith>
<owl:Class rdf:about="#Decision_de_Arquitectura"/>
</owl:disjointWith>
<owl:disjointWith>
<owl:Class rdf:about="#Decision_de_Algoritmica"/>
</owl:disjointWith>
<owl:disjointWith rdf:resource="#Decision_de_Persistencia"/>
<owl:disjointWith>
<owl:Class rdf:about="#Decision_de_Relaciones_Arquitecturas"/>
</owl:disjointWith>
</owl:Class>
<owl:Class rdf:about="#Justificacion_de_Relaciones_de_Arquitecturas">
<owl:disjointWith rdf:resource="#Justificacion_de_Arquitectura"/>
<owl:disjointWith>
<owl:Class rdf:about="#Justificacion_de_Estructuras_de_Datos"/>
</owl:disjointWith>
<owl:disjointWith>
<owl:Class rdf:about="#Justificacion_de_Algoritmica"/>
</owl:disjointWith>
<owl:disjointWith>
<owl:Class rdf:about="#Justificacion_de_Persistencia"/>
</owl:disjointWith>
<rdfs:subClassOf>
VOL. 1
<owl:Class rdf:about="#Justificacion_Decision_de_Kernel"/>
</rdfs:subClassOf>
</owl:Class>
<owl:Class rdf:about="#Justificacion_de_Algoritmica">
<owl:disjointWith>
</owl:disjointWith>
<owl:disjointWith>
<owl:Class rdf:about="#Justificacion_de_Persistencia"/>
</owl:disjointWith>
<owl:disjointWith rdf:resource="#Justificacion_de_Relaciones_de_Arquitecturas"/>
<rdfs:subClassOf>
</rdfs:subClassOf>
</owl:Class>
<owl:Class rdf:about="#Justificacion_de_Elemento_de_Interaccion">
<rdfs:subClassOf rdf:resource="#Justificacion_Decision_de_Interfaz"/>
<owl:disjointWith>
<owl:Class rdf:about="#Justificacion_de_Elemento_Visual"/>
</owl:disjointWith>
<owl:disjointWith rdf:resource="#Justificacion_de_Visualización"/>
</owl:Class>
<owl:Class rdf:about="#Decision_de_Relaciones_Arquitecturas">
<rdfs:subClassOf>
</rdfs:subClassOf>
<owl:disjointWith>
</owl:disjointWith>
<owl:disjointWith rdf:resource="#Decision_de_Estructura_de_Datos"/>
<owl:disjointWith>
<owl:Class rdf:about="#Decision_de_Algoritmica"/>
</owl:disjointWith>
</owl:Class>
<owl:Class rdf:ID="Decision_de_Disenho"/>
<owl:Class rdf:about="#Decision_de_Interfaz">
<rdfs:subClassOf rdf:resource="#Decision_de_Disenho"/>
</owl:Class>
<owl:Class rdf:about="#Decision_de_Algoritmica">
<rdfs:subClassOf>
</rdfs:subClassOf>
<owl:disjointWith>
</owl:disjointWith>
<owl:disjointWith rdf:resource="#Decision_de_Relaciones_Arquitecturas"/>
</owl:Class>
<owl:Class rdf:about="#Decision_de_Kernel">
<rdfs:subClassOf rdf:resource="#Decision_de_Disenho"/>
</owl:Class>
<owl:Class rdf:about="#Justificacion_de_Persistencia">
VOL. 1
14
[email protected]
<owl:disjointWith>
</owl:disjointWith>
<owl:disjointWith rdf:resource="#Justificacion_de_Algoritmica"/>
<rdfs:subClassOf>
</rdfs:subClassOf>
</owl:Class>
<owl:Class rdf:about="#Decision_de_Visualización">
<owl:disjointWith rdf:resource="#Decision_de_Elemento_Visual"/>
<owl:disjointWith rdf:resource="#Decision_de_Elemento_de_Interaccion"/>
<rdfs:subClassOf rdf:resource="#Decision_de_Interfaz"/>
</owl:Class>
<owl:Class rdf:about="#Justificacion_de_Estructuras_de_Datos">
<owl:disjointWith rdf:resource="#Justificacion_de_Algoritmica"/>
<owl:disjointWith rdf:resource="#Justificacion_de_Persistencia"/>
<rdfs:subClassOf>
</rdfs:subClassOf>
</owl:Class>
<owl:Class rdf:about="#Justificacion_Decision_de_Kernel">
<rdfs:subClassOf rdf:resource="#Justificacion_de_Disenho"/>
</owl:Class>
<owl:Class rdf:about="#Justificacion_de_Elemento_Visual">
<rdfs:subClassOf rdf:resource="#Justificacion_Decision_de_Interfaz"/>
<owl:disjointWith rdf:resource="#Justificacion_de_Elemento_de_Interaccion"/>
<owl:disjointWith rdf:resource="#Justificacion_de_Visualización"/>
</owl:Class>
<owl:Class rdf:about="#Decision_de_Arquitectura">
<rdfs:subClassOf rdf:resource="#Decision_de_Kernel"/>
<owl:disjointWith rdf:resource="#Decision_de_Algoritmica"/>
<owl:disjointWith rdf:resource="#Decision_de_Relaciones_Arquitecturas"/>
</owl:Class>
<owl:DatatypeProperty rdf:ID="registrada_en">
<rdfs:domain>
<owl:Class>
<owl:unionOf rdf:parseType="Collection">
<owl:Class rdf:about="#Decision_de_Disenho"/>
<owl:Class rdf:about="#Justificacion_de_Disenho"/>
</owl:unionOf>
</owl:Class>
</rdfs:domain>
<rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#date"/>
</owl:DatatypeProperty>
<owl:DatatypeProperty rdf:ID="identificado_por">
<rdfs:domain rdf:resource="#Decision_de_Disenho"/>
<rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#int"/>
</owl:DatatypeProperty>
<owl:TransitiveProperty rdf:ID="justificada_por">
<rdf:type rdf:resource="http://www.w3.org/2002/07/owl#ObjectProperty"/>
<rdfs:domain rdf:resource="#Decision_de_Disenho"/>
VOL. 1
<rdfs:range rdf:resource="#Justificacion_de_Disenho"/>
</owl:TransitiveProperty>
</rdf:RDF>

VOL. 1

The best article we wrote in our entire lives

Transcripción

Documentos relacionados

OWL Road Traffic Management

promo-electroforesis