Diseño Multidimensional guiado por Ontología

Tamaño: px
Comenzar la demostración a partir de la página:

Download "Diseño Multidimensional guiado por Ontología"

Transcripción

1 Diseño Multidimensional guiado por Ontología Sebastián Giménez, Regina Motz, Fernando Carpani, Diego Gayoso, Cecilia Colombatto Instituto de Computación, Universidad de la República, Julio Herrera y Reissig 565, Montevideo, Uruguay {carpani, rmotz Resumen. Este trabajo presenta guías de diseño conceptual multidimensional para data warehouses basadas en el análisis de requerimientos y en la ontología del dominio. Se ejemplifica con un caso de estudio real y se compara la propuesta con otras existentes. Keywords: Modelo Conceptual Multidimensional, Data Warehouse, Ontología. 1 Introducción El diseño multidimensional es ampliamente utilizado como representación conceptual de un Data Warehouse. Un Data Warehouse (DW) es una base de datos que almacena información para la toma de decisiones, que no es un sistema transaccional sino fuertemente caracterizado por ser un sistema OLAP, acrónimo en inglés de procesamiento analítico en línea (On-Line Analytical Processing). El modelo multidimensional, o la metáfora del cubo, sirven para organizar los datos en torno a un eje de datos a ser analizados (hechos), un eje de las descripciones más importantes de esos datos (medidas) y otro eje que describe las dimensiones en que los datos pueden ser analizados. Si bien no existe un consenso de estándar en el modelo multidimensional a usar, sí existe acuerdo en la importancia de distinguir entre un diseño conceptual, un diseño lógico y un diseño físico [1, 2, 3]. El diseño conceptual apunta a la construcción de un esquema conceptual en concordancia con el modelo conceptual elegido que sea independiente de la implementación y que sea expresivo en la representación de los requerimientos del usuario. El diseño lógico toma el esquema conceptual y crea el correspondiente esquema lógico en la plataforma elegida considerando restricciones operacionales. El diseño físico se enfoca en el desarrollo específico referente a una implementación. Como señalado en [4], existen varias propuestas de metodologías para diseños en estos tres niveles, pero no existen aún metodologías sencillas, prácticas, para que desde el punto de vista industrial sirvan para mejorar el diseño conceptual de un DW. En este trabajo presentamos una propuesta para realizar el diseño conceptual multidimensional con el desafío de obtener un diseño fácil de reutilizar, de extender y de administrar. Nuestra propuesta es trabajar desde una fase de captura de requerimientos del usuario con correspondencias tanto desde una ontología de

2 dominio como desde el modelo conceptual utilizado. Mostramos como estas correspondencias permiten el diseño conceptual del DW de manera ordenada y documentada y permiten además desarrollar una clara trazabilidad de los conceptos presentes en la realidad hasta su representación en el modelo multidimensional, favoreciendo de esta forma, la administración de los cambios en los requerimientos. Generalmente ocurre que una vez que se implanta un DW, los requerimientos que originaron al mismo van cambiando, además de adicionarse nuevos. Por esto es importante que el Data Warehouse sea flexible a nuevos cambios, y que su mantenimiento sea lo menos costoso posible. Una ontología se puede definir como la especificación explícita de una conceptualización [5]. Cuando el conocimiento de un dominio es representado en un formalismo declarativo, el conjunto de objetos que pueden ser representados es llamado el universo de discurso. Este conjunto de objetos, y las relaciones descriptibles entre ellos, es reflejado en el vocabulario con el cual se representa conocimiento. En una ontología se asocian mediante definiciones los nombres de las entidades en el universo de discurso (por ejemplo clases, relaciones, funciones u otros objetos) con cierto texto expresado en lenguaje natural que las describe y con axiomas que restringen la interpretación y otorgan la característica de bien formados a dichos términos. Uno de los principales objetivos que tiene la utilización de ontologías es la de realizar inferencias sobre los conceptos. Mediante el uso de herramientas tales como razonadores es posible detectar inconsistencias, con el beneficio de obtener puntos de retrocesos menores y por lo tanto con menor costo asociado al mantenimiento del diseño guiado por ontología. El resto del artículo está organizado de la siguiente forma. La Sección 2 presenta las características particulares del modelo multidimensional utilizado, CMDM. La Sección 3 presenta las fases de nuestro enfoque mientras que la Sección 4 presenta la derivación del modelo conceptual desde la ontología de dominio. Para una mejor comprensión, la Sección 5 presenta una aplicación práctica de nuestra propuesta, experimentada en un ambiente real de diseño de DW. Finalmente la Sección 6 presenta algunas conclusiones y líneas de trabajo futuro. 2 El Modelo Multidimensional CMDM El objetivo fundamental de CMDM [6, 7] es permitir la especificación de una determinada realidad en términos multidimensionales. En una base de datos multidimensional, la información se representa como matrices multidimensionales, cuadros de múltiples entradas o funciones de varias variables sobre conjuntos finitos. Cada una de estas matrices se denomina Cubo. El esquema de un cubo queda determinado dando a conocer sus ejes con sus respectivas estructuras y la estructura de los datos que se presentan en cada celda de la matriz. Se asume que los datos en todas las celdas son uniformes, es decir, todas las posiciones de la matriz tienen datos con igual estructura. A los ejes se les llama Dimensiones y al dato que se presenta en la matriz, se le llama Medida. Generalmente, las dimensiones se estructuran en jerarquías de agregación. A cada nivel de una jerarquía se le llama Nivel de Agregación o simplemente Nivel. De esta forma, se puede considerar que

3 toda dimensión siempre tiene por lo menos una jerarquía con un único nivel. Pero una dimensión puede tener más de una jerarquía. Un ejemplo típico, es una dimensión que representa tiempo. En este caso, los niveles bimestre y trimestre no están relacionados entre sí, a pesar de que ambos están relacionados con mes y año. Para lograr representar esta realidad, CMDM presenta tres estructuras básicas: Niveles, Dimensiones y Relaciones Dimensionales. Niveles: Un nivel representa un conjunto de objetos que son de un mismo tipo. Cada nivel debe tener un nombre y un tipo. Conceptualmente, no tiene diferencia con cualquier elemento del Modelo Entidad Relación que pueda ser considerado un conjunto de Entidades. Dimensiones: Una dimensión está determinada por una jerarquía de niveles. Las dimensiones deben poder estructurarse en niveles, donde cada nivel debe tener una declaración en el conjunto de declaraciones del esquema. De esta forma, una dimensión es una tupla formada por un conjunto de niveles previamente declarados y un orden parcial con mínimo definido sobre los niveles. Toda dimensión, además, tendrá un identificador. Relaciones Dimensionales: Una relación dimensional representa el conjunto de todos los cubos que se pueden construir a partir de los niveles de un conjunto dado de dimensiones. Se asume que en cada uno de los cubos que pertenecen a la instancia de la relación dimensional, debe aparecer al menos un nivel de cada una de las dimensiones que participan en la relación. En CMDM, un cubo es una función que va del producto cartesiano de las instancias de los niveles en los booleanos. De esta forma, cualquier nivel puede cumplir el rol de medida. Por lo tanto, el esquema de una relación dimensional está dado por un grafo en forma de estrella. En las siguientes secciones mostramos el proceso a seguir para poder derivar qué conceptos de la realidad deben modelarse como dimensiones, cuáles como niveles, y cuál es la jerarquía que modela varios niveles. Más detalles sobre el modelo CMDM pueden consultarse en [6,7]. 3 Fases en el Diseño Multidimensional En el presente trabajo se propone una metodología que abarca desde la etapa inicial de Business modeling [8] hasta el diseño conceptual del DW. La metodología propuesta está soportada por una serie de fases apoyadas por el uso de una ontología de dominio. Esto permite lograr una visión global de los conceptos, realizar inferencias, verificar la consistencia del modelo y obtener la trazabilidad de los conceptos a lo largo del proceso. El ciclo de vida de la metodología propuesta consiste en tres fases secuenciales, diagramadas en la Figura 1, donde cada uno de los óvalos identifica una fase y las flechas marcadas en negro indican las dependencias más importantes y frecuentes entre las mismas.

4 Realidad Modelado de Conceptos Matriz de Requerimientos Modelo Conceptual Multidimensional (CMDM) Fase 1 Comprensión de la Realidad Fase 2 Modelado de Dominio Fase 3 Modelado Conceptual Multidimensional Requerimientos Ontología Fig. 1: Fases del Diseño Multidimensional guiado por Ontología. Fase I Análisis de la Realidad. El objetivo de esta fase es identificar todos los conceptos que componen el dominio del problema, junto con las relaciones existentes entre los mismos y las restricciones identificada para cada uno. Esta fase pretende transformar el conocimiento tácito que se encuentra en los expertos conocedores de la realidad en conocimiento explícito, de forma que el mismo se encuentre documentado y almacenado para que cualquier otro interesado en comprender la realidad pueda hacer uso de dicho conocimiento cuando lo considere necesario. Como entrada de esta fase se requiere el conjunto de requerimientos iniciales y la realidad planteada. Como resultado de la fase se cuenta con el documento Metadata de Conceptos, el cual contiene la información de contexto y datos importantes identificados para cada concepto. En este documento se incluye una descripción del dominio relevado, sobre el cual se deberá resolver los requerimientos, siendo la base para la realización del modelo de la realidad que se realizará en la Fase II (Modelado del Dominio). Los participantes de esta fase son los expertos conocedores de la realidad y analistas del equipo de desarrollo. Como condiciones para la finalización de la fase es necesario considerar que todo concepto que forme parte de la resolución de un requerimiento esté definido en el documento Metadata de Conceptos. Fase II Modelado del Dominio. El objetivo de esta fase es construir un modelo que represente, utilizando un modelo formal, los conceptos de la Fase I, detallados en el documento Metadata de Conceptos. El modelo incluirá la información y características más importantes, relaciones definidas y las restricciones consideradas en el análisis de la realidad, abstrayendo la realidad presentada y eliminando posibles inconsistencias y/o conflictos que no se hubieran identificado en la Fase I. Como entrada de la fase se requiere el documento Metadata de Conceptos obtenido en la fase I y el conjunto de requerimientos. Como resultado de la fase se obtiene la ontología que es el modelo semántico de dominio que representa la realidad relevada, modelando la información de contexto y datos importantes identificados para cada concepto, las relaciones entre estos y las restricciones identificadas. Adicionalmente, al finalizar la fase se cuenta con la Matriz de Requerimientos que refleja la interacción entre los conceptos y relaciones del modelo de dominio, y los requerimientos

5 analizados. Los participantes de esta fase son los analistas del equipo de desarrollo, diseñadores que formen parte del equipo de desarrollo y expertos conocedores de la realidad para consultas puntuales. Como condiciones para la finalización de la fase es necesario considerar que todo concepto que forme parte de la resolución de un requerimiento esté definido en la ontología de dominio. En los casos que se realicen cambios en la realidad será necesario validar que estas modificaciones se encuentren reflejadas en el documento Metadata de Conceptos y el modelo de dominio. Fase III Construcción del Modelo Multidimensional. El objetivo de esta fase es construir el modelo multidimensional CMDM a partir de la ontología de dominio guiado por los requerimientos. Como entrada de la fase se requiere el documento Metadata de Conceptos resultante de la Fase I del proceso, la Ontología del Dominio y la Matriz de Requerimientos obtenidos en la Fase II y el conjunto de Requerimientos iniciales. Para realizar el proceso de transformación de los conceptos y relaciones definidos en la ontología del dominio al modelo conceptual multidimensional es necesario contar con reglas que dirijan dicha transformación (estas reglas se muestran en la siguiente sección). Como resultado de la fase se cuenta con el modelo conceptual multidimensional. Como condición para finalizar la fase es necesario considerar que todos los requerimientos estén resueltos mediante el modelo conceptual. 4 Propuesta de Derivación del Modelo Multidimensional Para realizar la transformación del modelo de dominio, representado mediante una ontología, al modelo multidimensional CMDM, se propone un conjunto de once reglas, a partir de los cuales se podrán inducir pautas o condiciones que permitan tomar decisiones de diseño al momento de construir el modelo multidimensional CMDM. Regla 1 Definición de clases candidatas a niveles del modelo multidimensional. Para aplicar esta regla es necesario contar con la matriz de requerimientos y la Ontología de dominio. Para cada clase del conjunto C se identifican sus restricciones propias (no heredadas). Se agrega al conjunto C las clases correspondientes al rango de cada una de las propiedades participantes en las restricciones antes identificadas. Para cada una de las clases del conjunto C se identifica si la misma pertenece a una categorización en la ontología. En caso que se cumpla esta condición todas sus superclases se agregan al conjunto C. Las clases del conjunto C que en la ontología tengan al menos una propiedad que no sea heredada, son consideradas como correspondientes a niveles en CMDM. Regla 2 Definición de niveles del modelo multidimensional. Para aplicar esta regla es necesario contar con el conjunto de clases candidatas a niveles (Regla 1) y la ontología de dominio. Para cada una de las clases del conjunto de clases consideradas como correspondientes a niveles del modelo multidimensional, se identifica en la ontología su nombre y las propiedades definidas como datos simples (Data Properties). Cada uno de los niveles se nombrará según el nombre que la clase tenga

6 definido en la ontología. Los atributos de los niveles quedarán determinados por las propiedades definidas como propias, considerando solo los datos simples. Regla 3 Definición de Cardinalidades. Esta regla sirve para identificar las relaciones existentes entre las clases del conjunto de clases a mapearse como niveles. Para aplicar esta regla es necesario contar con el conjunto de clases a corresponderse como niveles y la Ontología de dominio. A continuación se detallan las consideraciones realizadas para obtener la cardinalidad. 1. En las relaciones para las cuales no se haya definido una restricción de cardinalidad se considera que la cardinalidad asociada desde la clase dominio a la clase rango es N. Esto se define así porque al no existir restricción de cardinalidad definida se establece que un individuo del dominio puede relacionarse con N entidades de la clase rango. 2. Si una relación tiene definida una relación inversa, la cardinalidad definida en la dirección rango-dominio está dada por las restricciones de cardinalidad para la relación inversa definida. 3. Si una relación no tiene definida una relación inversa, la cardinalidad definida para esta relación inversa se asume como cardinalidad N, en dirección rangodominio. Con esto se denota que un individuo de la clase rango puede relacionarse con N individuos de la clase dominio. En las relaciones para las cuales no se haya definido una restricción de cardinalidad se considera que la cardinalidad asociada desde la clase dominio a la clase rango es N. Si una relación no tiene definida una relación inversa, la cardinalidad definida para esta relación inversa se asume como cardinalidad N, en dirección rango-dominio. La cardinalidad entre dos clases queda definida por la cardinalidad de la relación entre estas dos clases y la cardinalidad de su relación inversa. Regla 4 Identificación de orden entre niveles a partir de cardinalidad N:1. Esta cardinalidad establece que las entidades pertenecientes a la clase dominio pueden relacionarse con una única entidad del rango y que a la vez una entidad del rango puede asociarse a muchos (denotando esto como N) individuos del dominio. Esto puede interpretarse como una posible relación de agrupación de datos desde la clase dominio hacia la clase rango. Para aplicar esta regla es necesario contar con la ontología de dominio, el conjunto de relaciones identificadas con cardinalidad N:1 y el conjunto de niveles. Para cada relación del conjunto de relaciones identificadas con cardinalidad N:1 se define un orden entre dos niveles donde la clase que participa con cardinalidad N se corresponde como nivel inferior y la clase que participa con cardinalidad 1 se corresponde como nivel superior. De esta manera se obtiene un orden entre los niveles en CMDM. Regla 5 Identificación de orden entre niveles a partir de cardinalidad 1:N. Para aplicar esta regla es necesario contar con la ontología de dominio, el conjunto de relaciones identificadas con cardinalidad 1:N y el conjunto de niveles. Para cada relación del conjunto de relaciones identificadas con cardinalidad 1:N, se define un orden entre dos niveles donde la clase con cardinalidad 1 se corresponde como nivel superior y la clase que participa con cardinalidad N se corresponde como nivel inferior. De esta manera se obtiene un orden entre los niveles en CMDM. Regla 6 Identificación de orden entre niveles a partir de cardinalidad N:N. Esta cardinalidad establece que cualquier elemento de una de las clases que interviene en la cardinalidad, puede asociarse con una cantidad no definida de elementos de la otra

7 clase participante. Para aplicar esta regla es necesario contar con la ontología de dominio, el conjunto de relaciones identificadas con cardinalidad N:N, y el conjunto de niveles. Esta regla define cuando dos niveles no pueden ser parte de una misma jerarquía. Las clases que definen estas relaciones son independientes entre sí, no existiendo características por la cual sea posible agruparlas. Es posible considerar dos posibles casos.(figura 2): (i) las clases se corresponden como niveles de jerarquías diferentes en una misma dimensión, y (ii) las clases se corresponden como niveles de diferentes dimensiones. La decisión entre (i) y (ii) depende del caso en particular que se esté resolviendo pero las clases nunca podrán corresponderse como niveles de una misma jerarquía. Ontología CMDM Cardinalidad N:N C1 C2 N C1 N Posible Equivalencia C2 Posible Equivalencia C1 C2 Fig. 2 : Correspondencias de cardinalidad N:N Regla 7 Identificación de orden entre niveles a partir de relaciones 1:1 con totalidad. Dada la relación que cumple con cardinalidad 1:1 y cuenta con la propiedad de totalidad, ya sea para la clase dominio o para la clase rango, se construye la jerarquía haciendo corresponder la clase para la cual se cumple la totalidad como nivel superior y la clase restante conforma el nivel inferior. De este modo, al realizar las operaciones entre niveles, es posible obtener elementos que cumplan las características dadas, descartando aquellos que no lo hagan. Para aplicar esta regla es necesario contar con la ontología de dominio, el conjunto de niveles identificados que participan en una relación con cardinalidad 1:1 con totalidad. Regla 8 Identificación de orden entre niveles a partir de cardinalidad 1:1. Cualquiera de las clases participantes en la cardinalidad puede ser considerada como nivel superior o inferior, quedando a criterio del diseñador definir el orden entre los niveles. Esta decisión depende del caso en particular que se esté resolviendo Regla 9 Categorización de las subclases. Cuando una clase tiene un conjunto de subclases y a su vez estas clases tienen la propiedad de ser disjuntas entre sí, se cumple que cada subclase es una categorización o clasificación de los elementos de la superclase, según alguna característica. (Por ejemplo las clases Auto, Camioneta y Camión son disjuntas entre sí y son subclases de la clase Vehículo). Dado que las subclases son una especialización de la superclase, es posible considerar un nuevo nivel que permita representar la característica común de las subclases (en el ejemplo todas son un tipo de vehículo). Según lo definido es posible conformar un nuevo orden entre niveles, donde la superclase sé corresponde como el nivel inferior y el

8 nuevo nivel como superior. El nuevo nivel tiene miembros que representan las distintas categorizaciones, para esto se define un atributo que permite identificar cada uno de los elementos que conforman el nivel. Por lo tanto, en este regla, para cada clase del conjunto de clases a corresponderse como niveles, se debe identificar aquellas que son superclases y cuyas subclases sean disjuntas. Dada una superclase del conjunto, pueden obtenerse un nuevo orden entre niveles donde la superclase se corresponda como nivel inferior y como nivel superior se crea un nivel que agrupe todas las subclases. Al nivel superior se le asigna un nombre que identifique la agrupación, por ejemplo TipoCategoría. (Figura 3). Para este nivel se define un atributo que permita identificar cada uno de los elementos que lo conforman. Para aplicar esta regla es necesario contar con la ontología de dominio y el conjunto de clases a corresponderse como niveles. Herencia: Ontología Niveles: CMDM C1 C11 Tipo Cat 1 (C11, C12, ) C12 N C2 (C11 y C12 Disjuntas) Fig. 3: Correspondencia de herencia Regla 10 Identificación de dimensiones en CMDM. En esta regla se busca identificar las tuplas de niveles ordenados las cuales tengan algún nivel en común. Una dimensión queda formada por el subconjunto de tuplas de niveles previamente ordenados que tengan algún nivel en común, manteniendo el orden parcial definido entre ellos. Las dimensiones deben tener un nivel mínimo donde exista un identificador para cada elemento de la misma. Gráficamente la dimensión se forma uniendo las tuplas ordenadas según el nivel en común, manteniendo el orden definido. Todos los niveles deben formar parte de alguna dimensión. Puede ocurrir que exista una dimensión con un único nivel. Para aplicar esta regla es necesario contar con el conjunto de niveles y el conjunto de niveles parcialmente ordenados. Regla 11 Identificación de relaciones dimensionales en CMDM. En el caso de contar con una dimensión donde a partir de su nivel inferior I se desprendan varias jerarquías, y a su vez la cardinalidad entre I con los niveles superiores sea N:1 en todos los casos, es posible definir una relación dimensional donde I sea el eje central de la relación. Las dimensiones que definen dicha relación dimensional quedan formadas por el conjunto de niveles superiores a partir del eje central. En el caso de contar con un conjunto de dimensiones donde su nivel inferior I es común a todas, y a su vez la cardinalidad entre I y los niveles superiores sea N:1 en todos los casos, es posible definir una relación dimensional donde I sea el eje central de la relación. Las

9 dimensiones que definen dicha relación dimensional quedan formadas por el conjunto de niveles superiores a partir del eje central. Esta consideración queda en manos del diseñador, ya que debe ser él quien defina el eje central de la discusión. 5 Ejemplo Práctico Como caso practico, para poder aplicar la metodología desarrollada en el proyecto y poder comparar los resultados, se realizó el re-diseño de un conjunto de indicadores existentes. El DW que alberga dichos indicadores se encuentra desarrollado sobre el sistema OPEN SIC (Sistema de Información Clínica) de la empresa Soluziona. OPENSIC es un Sistema de Información Clínico Integrado orientado a organizaciones prestadoras de servicios de salud. Fase I. En primera instancia se presentaron los siguientes 4 requerimientos que forman el conjunto de requerimientos iniciales: (R1) Porcentaje de egresos quirúrgicos, (R2) Promedio de estancia, (R3) Tasa de mortalidad infantil y (R4) Tasa de mortalidad infantil post neo-natal. Lo primero es realizar un análisis conceptual de cada uno de los requerimientos. Para esto, en el caso presentado se desglosó cada uno en los conceptos que lo conforman, como por ejemplo egreso quirúrgico, estancia, mortalidad infantil y mortalidad infantil post neo-natal. Se define entonces, junto a personal de la empresa, una descripción para cada requerimiento de manera de dejar explícito el objetivo de cada uno. Las descripciones definidas para cada requerimiento son las siguientes: 1. Porcentaje de egresos quirúrgicos: porcentaje de egresos quirúrgicos sobre la cantidad de egresos totales en un período determinado 2. Promedio de estancia: promedio de tiempo de internación (días) de los pacientes en un período determinado 3. Tasa de mortalidad infantil: cantidad de defunciones de pacientes menores de 1 año en relación con el número de nacidos vivos durante el mismo período 4. Tasa de mortalidad infantil post neo-natal: cantidad de defunciones de pacientes entre 28 y 364 días de edad en relación con el número de nacidos vivos durante el mismo período. Analizando el requerimiento 1.se deriva que para este requerimiento existen tres conceptos identificados egreso quirúrgico, egreso hospitalario y tiempo. Como resultado de esta fase se tiene el documento Metadata de Conceptos en el cual se establece el sentido y la semántica de cada uno de los conceptos identificados en la realidad guiada por los requerimientos. La propuesta que planteamos presenta una plantilla diseñada con el fin de brindar ayuda al momento de definir la información de contexto y datos importantes identificados para cada concepto, sin embargo, por motivos de espacio omitimos el desarrollo de esta fase pero la misma se puede encontrar en [9].

10 Fase II. En esta fase se trabaja sobre la Ontología del Dominio definiendo el conjunto de conceptos, las relaciones existentes entre estos y las restricciones de cada uno. Esta ontología permitió, mediante el uso del razonador Racer [10], realizar el chequeo de consistencia del modelo. Como observación particular del caso propuesto, ocurre que al momento de crear la ontología además de modelar las relaciones definidas en el documento Metadata de Conceptos surgieron nuevas relaciones, inferidas del modelo que no se habían identificado hasta el momento pero que efectivamente se cumplen entre los elementos del modelo. La Figura 4 ilustra gráficamente las relaciones encontradas para el requerimiento 1. Fig. 4 : Gráfica de la ontología de dominio correspondiente al requerimiento 1. Una vez identificados los conceptos y relaciones participantes en la resolución del requerimiento analizado, éstos se agregan a la Matriz de Requerimientos. De esta manera resulta sencillo verificar si un cambio afecta o no la resolución de un requerimiento simplemente identificando si el concepto o relación modificada participa o no en la resolución del requerimiento en cuestión. En [9] se utiliza una tabla que define, para cada requerimiento, el conjunto de dimensiones y medidas necesarias para su resolución. La matriz propuesta en esta etapa, a diferencia de la matriz utilizada en [9], vincula cada requerimiento con los conceptos y relaciones que participan en su resolución, es decir vincula cada requerimiento con un concepto semántico y no con una estructura del modelo conceptual.. En la Figura 5 se presenta la matriz de requerimientos con los conceptos identificados para el requerimiento R1. Fase III. Aplicando la Regla 1 se obtiene que las clases candidatas a corresponderse como niveles en el modelo multidimensional son: Egreso_Hospitalario y Actividad_Quirurgica. Aplicando la Regla 2 de forma iterativa se identifican las clases Prestación, Internado, Admitido, Persona y Registro que son agregadas al conjunto de candidatas a niveles del modelo. La Regla 3, a partir de las nuevas clases participantes de la resolución del requerimiento, actualiza la matriz de

11 requerimientos de manera de incluir las clases y las is-a. De esta manera, ante cambios en el requerimiento se puede seguir la traza de las clases y relaciones que se ven afectadas (Figura 6). Concepto R1 R2 R3 R4 Clases Egreso_Quirurgico Egreso_Hospitalario Actividad_Quirurgica Fecha Relaciones internado_tiene_actividadquirurgica egresohospitalario_tiene_fechaegreso Herencia Egreso_Quirurgico is a Egreso_Hospitalario Fig. 5 - Matriz de Requerimientos luego de la Fase II. Concepto R1 R2 R3 R4 Clases Egreso_Quirurgico Egreso_Hospitalario Actividad_Quirurgica Prestación Internado Admitido Persona Registro Relaciones internado_tiene_actividadquirurgica actividadquirurgica de_internado Herencia Egreso_Quirurgico is a Egreso_Hospitalario Egreso_Hospitalario is a Internado Internado is a Admitido Admitido is a Persona ActividadQuirurgica is a Prestacion Prestacion is a Registro l Fig. 6 - Matriz de Requerimientos Fase III, luego de la Regla 3. Las jerarquías del modelo multidimensional se obtendrán mediante la ejecución de las Reglas 4 a la 9, donde las Reglas 4 a la 7 se basan totalmente en la cardinalidad de las relaciones identificadas. Las Reglas 8 y 9 consideran, además, la condición de totalidad de las relaciones. La cardinalidad definida para las relaciones de interés son lasque muestra la Figura 7. Es importante aclarar que la relación internado_tiene_actividadquirurgica no es de interés dado que depende de la clase Egreso_Quirurgico que no es candidata a nivel en el modelo CMDM. Aplicando la Regla 4 a la relación actividadquirurgica de_internado se obtiene Internado como

12 nivel superior a Actividad_quirurgica, y aplicando la Regla 5 al resto de las relaciones se obtiene que Egreso_Hospitalario, Internado y Admitido corresponde a niveles superiores respectivamente de Internado, Admitido y Persona. Aplicando luego la Regla 10 se obtienen las dimensiones ilustradas en la Figura 8. Relación Clase Origen (Co) Clase Destino (Cd) Cardinalidad desde Co a Cd actividadquirurgica Actividad_quirurgica Internado N:1 de_internado Egreso_Quirurgico is a Egreso_Quirurgico Egreso_Hos N:1 Egreso_Hospitalario pitalario Egreso_Hospitalario is Egreso_Hospitalario Internado 1:N a Internado Internado is a Internado Admitido 1:N Admitido Admitido is a Persona Admitido Persona 1:N ActividadQuirurgica is Actividad_quirurgica Prestacion 1:N a Prestacion Prestacion is a Prestacion Registro 1:N Registro Fig. 7: Cardinalidad de la Relaciones de interés. VVVVV Egreso_Hospitalario Internado Admitido Persona Nombre:String Cedula:String Telefono:String BBBBB Egreso_Hospitalario Internado Actividad_quirurgica Descripción:String Prestacion Registro Descripcion:String Fig. 8: Dimensiones resultado de la aplicación de la Regla 10. Para la identificación de las relaciones dimensionales no se puede aplicar la Regla 11 ya que no se está en el caso de tener un conjunto de dimensiones donde su nivel mínimo forme parte de más de una dimensión o a partir de su nivel mínimo se desprendan varias jerarquías, resultando entonces las relaciones dimensionales de la Figura 9.

13 Fecha Personas Egresos Registro Fig. 9: Relaciones Dimensionales. 6 Conclusiones y Trabajos Futuros En este trabajo presentamos una propuesta metodológica para el diseño conceptual multidimensional guiado por ontología del dominio. Existen diversos trabajos sobre como realizar el diseño multidimensional. En [11] se presenta una metodología guiada por los requerimientos para el diseño conceptual, sin embargo no cuenta con un relevamiento del significado de los conceptos del dominio como lo proponemos a través de la ontología, ni prevé mecanismos para ayudar a la evolución de los requerimientos como la Matriz de Requerimientos que presentamos. En [12] se propone una adaptación de una arquitectura estándar para el desarrollo de software, llamada MDA (Model Driven Architecture) que guía el ciclo de vida completo del diseño, desarrollo, integración y administración de aplicaciones utilizando modelos en desarrollo de software. Se describe como crear los distintos artefactos (modelos) MDA por medio de extensiones de UML, también se describen las transformaciones necesarias entre modelos utilizando la aproximación Query/View/Transformatcin (QVT). Aunque se explicita la transformación de los distintos modelos, no es claro como se construye el modelo multidimensional, del cual parte la arquitectura. Creemos que las pautas presentadas para las tres Fases del diseño Multidimensional acompañadas con las Reglas de derivación desde la Ontología son un mecanismo práctico, viable para ser ensayado en casos reales. La Tabla 1 compara nuestra propuesta, que llamamos MD4DW [13], con otras. Los parámetros considerados son: si se genera un modelo conceptual multidimensional, si hay ejemplos complejos de aplicación de la propuesta, si se justifican los pasos seguidos en la obtención de la propuesta, si se consideran los requerimientos en la etapa de Análisis y Diseño, si existe trazabilidad desde los conceptos de la realidad hasta el modelo conceptual multidimensional, si la propuesta brinda soporte para la realización del análisis de impacto frente a cambios en los requerimientos, la última columna indica si la propuesta propone la elaboración de un modelo semántico que contenga el significado de los conceptos del dominio. En estos momentos estamos a la búsqueda de diseñadores de DW que quieran experimentar nuestra propuesta, creemos que es necesario que sea aplicada por terceras partes externas al proyecto para poder evaluar objetivamente sus impactos.

14 Como trabajo futuro es importante estudiar la viabilidad de automatizar el proceso generando un software integral que permita asistir la construcción de un DW, basándose en MD4DW, desde el análisis de la realidad hasta el diseño físico. Tabla 1. Comparación de Metodologías para diseño de DW. PROPUESTA M.Concep. Ej Justif. Req. Traza Imp. M. Semántico Golf98 [1] X X Gio05 [11] X X -- X Maz05 [12] X X X Kim98 [14] -- X MD4DW [13] X X X X X X X Referencias [1] Golfarelli, M.; Rizzi S.: A methodological framework for data warehouse design. In Proc. DOLAP, pages 3-9 (1998). [2] Huesemann B., Lechtenboerger J., Vossen G.: Conceptual data warehouse design. In Proc. DMDW, pages 3-9 (2000). [3] Luján-Mora S., Trujillo J.: A comprehensive method for data warehouse design. In Proc. DMDW (2003). [4] Rizzi, S., Abelló A., Lechtenboerger J., Trujillo J.: Research in DataWarehouse Modeling and Design: Dead or Alive? DOLAP, USA (2006). [5] Gruber T. R: A Translation Approach to Portable Ontology Specifications. Knowledge Acquisition, 5(2), 1993, pp (1993). [6] Carpani.F.: CMDM: Un Modelo Conceptual para la Especificación de Bases Multidimensionales,Tesis de Maestría, Facultad de Ingeniería, UdelaR, (2000). [7] Carpani, F., Ruggia R.: An Integrity Constraints Language for a Conceptual Multidimensional Data Model XIII International Conference on Software Engineering & Knowledge Engineering (SEKE'01), Buenos Aires, Argentina, (2001). [8] IBM Rup: Rational Unified Process, [9] Ballard, C., Herreman D., Schau D. Bell D. Kim R., Valncic E.: Data Modeling Techniques for Data Warehousing SG IBM Red Book.ISBN (1998). [10] Racer - [11] Giorgini P., Rizzi S., Garzetti M.: Goal-Orientes Requierement Analysis for Data Warehouse Design. Engineering Applications of Artificial Intelligence, Elsvier (2005). [12] Mazon J., Trujillo J.,.Serrano M., Piattini M., Applying MDA to the Development of Data Warehouse, DOLAP 05 (2005). [13] Gimenez S., Godoy D. Colombatto C. Carpani F, Motz R.: Proyecto MD4DW: Metadata for Data Warehouse. Universidad de la República (Uruguay) [14] Kimball, R. Reeves, L. Ross, M. Thornthwaite, W.: The Datawarehouse Lifecycle Toolkit. John Wiley & Son, Inc.(1998).

UNIDAD 2: Abstracción del Mundo real Al Paradigma Orientado a Objetos

UNIDAD 2: Abstracción del Mundo real Al Paradigma Orientado a Objetos 2.1. Principios básicos del Modelado de Objetos UNIDAD 2: Abstracción del Mundo real Al Paradigma Orientado a Objetos Hoy en día muchos de los procesos que intervienen en un negocio o empresa y que resuelven

Más detalles

Ingeniería de Software con UML Unified Modeling Language Lenguaje Unificado de Modelado

Ingeniería de Software con UML Unified Modeling Language Lenguaje Unificado de Modelado Ingeniería de Software con UML Unified Modeling Language Lenguaje Unificado de Modelado 1. Introducción Unified Modeling Languaje Fuente: Booch- Jacobson-Rumbauch y diversos sitios Internet, entre otros:

Más detalles

BASES DE DATOS. Ivon Tarazona Oriana Gomez

BASES DE DATOS. Ivon Tarazona Oriana Gomez BASES DE DATOS Ivon Tarazona Oriana Gomez Introducción Introducción Ventajas e (Unified Modeling Language) Es un lenguaje usado para especificar, visualizar y documentar los diferentes aspectos relativos

Más detalles

Programación orientada a

Programación orientada a Programación orientada a objetos con Java Pedro Corcuera Dpto. Matemática Aplicada y Ciencias de la Computación Universidad de Cantabria corcuerp@unican.es Objetivos Presentar los conceptos de la programación

Más detalles

Evaluación de una Metodología para la construcción de Data Warehouses

Evaluación de una Metodología para la construcción de Data Warehouses Instituto de Computación Facultad de Ingeniería Universidad de la República Evaluación de una Metodología para la construcción de Data Warehouses Data Warehouse para la plataforma EVA Agustín Mullin Proyecto

Más detalles

Sistema de análisis de información. Resumen de metodología técnica

Sistema de análisis de información. Resumen de metodología técnica Sistema de análisis de información Resumen de metodología técnica Tabla de Contenidos 1Arquitectura general de una solución de BI y DW...4 2Orígenes y extracción de datos...5 2.1Procesos de extracción...5

Más detalles

Implementación de herramientas CASE que asistan en el Diseño de Data Warehouses

Implementación de herramientas CASE que asistan en el Diseño de Data Warehouses Implementación de herramientas CASE que asistan en el Diseño de Data Warehouses Verónika Peralta, Raúl Ruggia Universidad de la República, Uruguay. {vperalta, ruggia}@fing.edu.uy Resumen: Un Data Warehouse

Más detalles

Diagrama de Clases. Diagrama de Clases

Diagrama de Clases. Diagrama de Clases Diagrama de Clases 1 Diagrama de Clases El propósito de este diagrama es el de representar los objetos fundamentales del sistema, es decir los que percibe el usuario y con los que espera tratar para completar

Más detalles

Análisis del Sistema de Información

Análisis del Sistema de Información Análisis del Sistema de Información ÍNDICE DESCRIPCIÓN Y OBJETIVOS... 2 ACTIVIDAD ASI 1: DEFINICIÓN DEL SISTEMA... 6 Tarea ASI 1.1: Determinación del Alcance del Sistema... 6 Tarea ASI 1.2: Identificación

Más detalles

Introducción. Metadatos

Introducción. Metadatos Introducción La red crece por momentos las necesidades que parecían cubiertas hace relativamente poco tiempo empiezan a quedarse obsoletas. Deben buscarse nuevas soluciones que dinamicen los sistemas de

Más detalles

Construcción de un sistema de apoyo a la toma de decisiones para el área gerencial del Hospital de Clínicas

Construcción de un sistema de apoyo a la toma de decisiones para el área gerencial del Hospital de Clínicas Construcción de un sistema de apoyo a la toma de decisiones para el área gerencial del Hospital de Clínicas Alejandro Gutiérrez, Regina Motz, Beatriz Revello, Lydia Silva Instituto de Computación, Facultad

Más detalles

ANEXO A - Plan de Proyecto. 1. - EDT de la solución EDT GENERAL DEL PROYECTO1

ANEXO A - Plan de Proyecto. 1. - EDT de la solución EDT GENERAL DEL PROYECTO1 ANEXO A - Plan de Proyecto 1. - EDT de la solución EDT GENERAL DEL PROYECTO1 2.- Diagrama de Gantt de la Solución DIAGRAMA DE GANTT- FASE INICIAL DOCUMENTACION Y ANALISIS2 DIAGRAMA DE GANTT- FASE FINAL

Más detalles

UNIVERSIDAD NACIONAL MAYOR DE SAN MARCOS (Universidad del Perú, DECANA DE AMÉRICA) SYLLABO

UNIVERSIDAD NACIONAL MAYOR DE SAN MARCOS (Universidad del Perú, DECANA DE AMÉRICA) SYLLABO UNIVERSIDAD NACIONAL MAYOR DE SAN MARCOS (Universidad del Perú, DECANA DE AMÉRICA) FACULTAD DE INGENIERIA DE SISTEMAS E INFORMATICA Escuela Académico Profesional de Ingeniería de Sistemas 1. ESPECIFICACIONES

Más detalles

Análisis del proceso de carga del Sistema de Data Warehousing de Enseñanza de la Facultad de Ingeniería

Análisis del proceso de carga del Sistema de Data Warehousing de Enseñanza de la Facultad de Ingeniería Análisis del proceso de carga del Sistema de Data Warehousing de Enseñanza de la Facultad de Ingeniería Lorena Etcheverry, Pablo Gatto, Salvador Tercia CSI, Instituto de Computación, Facultad de Ingeniería

Más detalles

CAPÍTULO 5. DESARROLLO Y PRUEBAS

CAPÍTULO 5. DESARROLLO Y PRUEBAS CAPÍTULO 5. DESARROLLO Y PRUEBAS 5.1 Introducción a las Tecnologías 5.1.1 Herramientas 5.1.1.1 SQL Server Es un sistema que sirve para la gestión de base de datos basado en un modelo relacional. Así mismo

Más detalles

Transformación de modelos en el proceso de obtención de Modelos Conceptuales partiendo de BPMN

Transformación de modelos en el proceso de obtención de Modelos Conceptuales partiendo de BPMN Transformación de modelos en el proceso de obtención de Modelos Conceptuales partiendo de BPMN Fernández Taurant, Juan Pablo Marciszack, Marcelo Martín Universidad Tecnológica Nacional, Facultad Regional

Más detalles

Sistemas de Información II. Introducción al Proceso Unificado de Desarrollo de Software. Autor: Ing. Silverio Bonilla 1

Sistemas de Información II. Introducción al Proceso Unificado de Desarrollo de Software. Autor: Ing. Silverio Bonilla 1 Introducción al Proceso Unificado de Desarrollo de Software Autor: Ing. Silverio Bonilla 1 James Rumbaugh et al. Concepto de Método Una metodología de ingeniería del software es un proceso para producir

Más detalles

Clase 10. Ingeniería de ontologías. Mg. A. G. Stankevicius. Segundo Cuatrimestre

Clase 10. Ingeniería de ontologías. Mg. A. G. Stankevicius. Segundo Cuatrimestre Ingeniería de Aplicaciones para la Web Semántica Clase 10 Ingeniería de ontologías Mg. A. G. Stankevicius Segundo Cuatrimestre 2005 Copyright 2 Copyright 2005 A. G. Stankevicius. Se asegura la libertad

Más detalles

Gerencia de Procesos de Negocio (Business Process Management, BPM). Lic. Patricia Palacios Zuleta

Gerencia de Procesos de Negocio (Business Process Management, BPM). Lic. Patricia Palacios Zuleta Gerencia de Procesos de Negocio (Business Process Management, BPM). Lic. Patricia Palacios Zuleta (Business Process Management, BPM). La Gerencia de los Procesos del Negocio: Se define como: "integración

Más detalles

IMPLEMENTACIÓN DE UN DATA MART PARA UN SERVICIO DE DOSIMETRÍA EXTERNA.

IMPLEMENTACIÓN DE UN DATA MART PARA UN SERVICIO DE DOSIMETRÍA EXTERNA. X Congreso Regional Latinoamericano IRPA de Protección y Seguridad Radiológica Radioprotección: Nuevos Desafíos para un Mundo en Evolución Buenos Aires, 12 al 17 de abril, 2015 SOCIEDAD ARGENTINA DE RADIOPROTECCIÓN

Más detalles

Aplicaciones Web a tu medida!

Aplicaciones Web a tu medida! Nota aclaratoria: El presente documento se realizó tomando como base el documento titulado Ingeniería de Requisitos en Aplicaciones para la Web Un estudio comparativo escrito por María José Escalona (Universidad

Más detalles

Inteligencia de Negocios Introducción. Por Elizabeth León Guzmán, Ph.D. Profesora Ingeniería de Sistemas Grupo de Investigación MIDAS

Inteligencia de Negocios Introducción. Por Elizabeth León Guzmán, Ph.D. Profesora Ingeniería de Sistemas Grupo de Investigación MIDAS Inteligencia de Negocios Introducción Por Elizabeth León Guzmán, Ph.D. Profesora Ingeniería de Sistemas Grupo de Investigación MIDAS Agenda 1.Introducción 2.Definición 3.ETL 4.Bodega de Datos 5.Data Mart

Más detalles

Metodologías de desarrollo para Service Oriented Architectures con Rational Unified Process

Metodologías de desarrollo para Service Oriented Architectures con Rational Unified Process Metodologías de desarrollo para Service Oriented Architectures con Rational Unified Process Andrea Delgado 1, Ignacio García-Rodríguez de Guzmán 2, Francisco Ruiz 2, Mario Piattini 2 1 Instituto de Computación,

Más detalles

Capitulo III. Diseño del Sistema.

Capitulo III. Diseño del Sistema. Capitulo III. Diseño del Sistema. Para el desarrollo del sistema en la presente tesis se utilizo el paradigma orientado a objetos utilizando el lenguaje Java en su versión 1.2. Por medio de este lenguaje

Más detalles

Concepción - Chile Marcela Varas Universidad de Concepción Chile - 2012

Concepción - Chile Marcela Varas Universidad de Concepción Chile - 2012 Presentación Concepción - Chile www.udec.cl Universidad de Concepción - Chile Estudiantes Universidad de Concepción Departamento de Ingeniería Informática y Ciencias de la Computación Facultad de Ingeniería

Más detalles

JISBD2007-02: Model-driven reverse engineering for data warehouse design

JISBD2007-02: Model-driven reverse engineering for data warehouse design JISBD2007-02: Model-driven reverse engineering for data warehouse design J.-N. Mazón y J. Trujillo Abstract Data warehouses integrate several operational sources to provide a multidimensional analysis

Más detalles

Cómo usar MDE para obtener Modelos de Simulación a partir de Modelos de Negocio

Cómo usar MDE para obtener Modelos de Simulación a partir de Modelos de Negocio Cómo usar MDE para obtener Modelos de Simulación a partir de Modelos de Negocio M. Teresa García 1, Mercedes Ruiz 1 y Cristina Vicente-Chicote 2 1 Departamento de Lenguajes y Sistemas Informáticos Universidad

Más detalles

Rational Unified Process (RUP)

Rational Unified Process (RUP) Rational Unified Process (RUP) Este documento presenta un resumen de Rational Unified Process (RUP). Se describe la historia de la metodología, características principales y estructura del proceso. RUP

Más detalles

Administración de Variabilidad en una línea de producto basada en modelos

Administración de Variabilidad en una línea de producto basada en modelos Administración de Variabilidad en una línea de producto basada en modelos Kelly Garcés Carlos Parra Hugo Arboleda Andres Yie Rubby Casallas Universidad de los Andes, Bogotá k-garces @uniandes.edu.co Universidad

Más detalles

Una Arquitectura para una Herramienta de Patrones de Diseño

Una Arquitectura para una Herramienta de Patrones de Diseño Una Arquitectura para una Herramienta de Patrones de Diseño José Sáez Martínez 1, Jesús García Molina, Pedro J. Jiménez García Departamento de Informática, Lenguajes y Sistemas. Campus de Espinardo C.P.

Más detalles

Diseño de un Almacén de datos basado en Data Warehouse Engineering Process (DWEP) y HEFESTO

Diseño de un Almacén de datos basado en Data Warehouse Engineering Process (DWEP) y HEFESTO Diseño de un Almacén de datos basado en Data Warehouse Engineering Process (DWEP) y HEFESTO Castelán García Leopoldo, Ocharán Hernández Jorge Octavio Maestría en Ingeniería de Software, Facultad de Estadística

Más detalles

Dirección de Informatización, Universidad Camagüey, Cuba. lindsay.gomez@reduc.edu.cu b

Dirección de Informatización, Universidad Camagüey, Cuba. lindsay.gomez@reduc.edu.cu b The conceptual modeling in the process of computer-assisted generation of data warehouse models Lindsay Alonso Gómez-Beltrán a, Rosendo Moreno-Rodríguez b & Ramiro Pérez-Vázquez c a Dirección de Informatización,

Más detalles

CAPÍTULO 2 DATA WAREHOUSES

CAPÍTULO 2 DATA WAREHOUSES CAPÍTULO 2 DATA WAREHOUSES Un Data Warehouse (DW) es un gran repositorio lógico de datos que permite el acceso y la manipulación flexible de grandes volúmenes de información provenientes tanto de transacciones

Más detalles

Análisis de Herramientas CASE para uso didáctico en Diseño de Bases de Datos

Análisis de Herramientas CASE para uso didáctico en Diseño de Bases de Datos Análisis de Herramientas CASE para uso didáctico en Diseño de Bases de Datos Cecilia Belletti, Regina Motz cecibell@adinet.com.uy, motz@athenea.ort.edu.uy Facultad de Ingeniería, Universidad ORT Uruguay

Más detalles

LINEAMIENTOS GENERALES PARA LA IMPLEMENTACIÓN DE PROCESOS ELECTRÓNICOS

LINEAMIENTOS GENERALES PARA LA IMPLEMENTACIÓN DE PROCESOS ELECTRÓNICOS LINEAMIENTOS GENERALES PARA LA IMPLEMENTACIÓN DE PROCESOS LINEAMIENTOS GENERALES PARA LA IMPLEMENTACIÓN DE PROCESOS Ministerio de Tecnologías de la Información y las Comunicaciones Programa de Gobierno

Más detalles

Índice. http://www.dicampus.es

Índice. http://www.dicampus.es Módulo 2 UML Índice Introducción a UML Lenguaje Unificado de Modelado (UML) Diagramas UML Diagramas de casos de uso Diagramas estructurales: Clases Diagramas estructurales: Objetos Diagramas de interacción:

Más detalles

GUIA METODOLOGÍCA PARA LA IMPLEMENTACIÓN DE BODEGA DE DATOS CORPORATIVA Y SOLUCIONES DE INTELIGENCIA DE NEGOCIOS

GUIA METODOLOGÍCA PARA LA IMPLEMENTACIÓN DE BODEGA DE DATOS CORPORATIVA Y SOLUCIONES DE INTELIGENCIA DE NEGOCIOS BODEGA DE DATOS CORPORATIVA Y SOLUCIONES DE Oficina de Informática Departamento Nacional de Planeación Bogotá, 2013 TABLA DE CONTENIDO PÁGINA: 2 de 35 VERSIÓN: 0 1 OBJETIVO... 3 2 ALCANCE... 3 3 REFERENCIAS

Más detalles

Un Escenario para Diseño Lógico de Data Warehouses

Un Escenario para Diseño Lógico de Data Warehouses Un Escenario para Diseño Lógico de Data Warehouses Verónika Peralta Instituto de Computación, Facultad de Ingeniería, Universidad de la República Montevideo, Uruguay vperalta@fing.edu.uy Resumen: Los Data

Más detalles

Análisis comparativo entre CIMOSA (CIM-Open System Architecture) y DEM (Dynamic Enterprise Modelling)

Análisis comparativo entre CIMOSA (CIM-Open System Architecture) y DEM (Dynamic Enterprise Modelling) 3rd International Conference on Industrial Engineering and Industrial Management XIII Congreso de Ingeniería de Organización Barcelona-Terrassa, September 2nd-4th 2009 Análisis comparativo entre CIMOSA

Más detalles

Paradigmas para el diseño multidimensional de almacenes de datos: un mapeo sistemático

Paradigmas para el diseño multidimensional de almacenes de datos: un mapeo sistemático Paradigmas para el diseño multidimensional de almacenes de datos: un mapeo sistemático Pablo Enrique Espinoza Navarrete Ingeniería informática Universidad de La Frontera Temuco, Chile p.espinoza04@ufromail.cl

Más detalles

[ ] introducción. Desarrollo de un sistema de información con inteligencia de negocios para la oficina de egresados de la FUKL.

[ ] introducción. Desarrollo de un sistema de información con inteligencia de negocios para la oficina de egresados de la FUKL. [ ] resumen Se describe el Sistema de Información de Egresados (SIE) realizado como respuesta a una problemática de gestión y análisis de datos que se presentaba en la Oficina de Egresados de la Fundación

Más detalles

Visión global del proceso de construcción de datawarehouse

Visión global del proceso de construcción de datawarehouse Instituto de Computación Facultad de Ingeniería Universidad de la República Visión global del proceso de construcción de datawarehouse athalie Deppen Paola Ricca Diego Trías Proyecto de Grado Agosto, 200

Más detalles

PROCESOS SOFTWARE. Según esta estrategia, todo proceso debe planificarse, implantarse y evaluarse, para luego actuar sobre él.

PROCESOS SOFTWARE. Según esta estrategia, todo proceso debe planificarse, implantarse y evaluarse, para luego actuar sobre él. PROCESOS SOFTWARE MOTIVACIÓN? Con independencia de la metodología o modelo implementado, es común la estrategia para la mejora continua de la calidad, basada en el Círculo de Deming o Plan, Do, Check,

Más detalles

Búsqueda sobre catálogos basada en ontologías

Búsqueda sobre catálogos basada en ontologías Búsqueda sobre catálogos basada en ontologías Alianis Pérez Sosa, Yuniel Eliades Proenza Arias Universidad de las Ciencias Informáticas. Carretera a San Antonio Km 2 ½, Reparto Torrens, La Lisa, Ciudad

Más detalles

DIAGRAMA DE CLASES EN UML

DIAGRAMA DE CLASES EN UML DIAGRAMA DE CLASES EN UML Mg. Juan José Flores Cueto jflores@usmp.edu.pe Ing. Carmen Bertolotti Zuñiga cbertolotti@usmp.edu.pe INTRODUCCIÓN UML (Unified Modeling Language) es un lenguaje que permite modelar,

Más detalles

Desarrollo de Ontologías

Desarrollo de Ontologías Desarrollo de Ontologías ECSDI LSI-FIB-UPC cbea Curso 2014/2015 ECSDI (LSI-FIB-UPC cbea) Desarrollo de Ontologías Curso 2014/2015 1 / 31 Índice 1 Introducción 2 Metodologías de desarrollo ECSDI (LSI-FIB-UPC

Más detalles

Inicio de MO Inicio de MD Inicio de MF. Documento de Análisis. Base de datos de las especificaciones OMT. MO, MD, MF Detallados. Librería de Clases

Inicio de MO Inicio de MD Inicio de MF. Documento de Análisis. Base de datos de las especificaciones OMT. MO, MD, MF Detallados. Librería de Clases 3.2 TÉCNICA DE MODELADO DE OBJETOS (OMT) (JAMES RUMBAUGH). 3.2.1 Introducción. En este documento se trata tanto el OMT-1 como el OMT-2, el primero contenido en el Libro Modelado y Diseño Orientado (Metodología

Más detalles

M III ABSTRACCIÓN Y CLASIFICACIÓN

M III ABSTRACCIÓN Y CLASIFICACIÓN M III ABSTRACCIÓN Y CLASIFICACIÓN COMPLEJIDAD Y ABSTRACCIÓN La abstracción en el desarrollo del programario En todo el proceso de abstracción siempre hay una parte de la situación o del problema que se

Más detalles

CUALIFICACIÓN SISTEMAS DE GESTIÓN DE INFORMACIÓN PROFESIONAL. Nivel 3. Versión 5 Situación RD 1201/2007 Actualización

CUALIFICACIÓN SISTEMAS DE GESTIÓN DE INFORMACIÓN PROFESIONAL. Nivel 3. Versión 5 Situación RD 1201/2007 Actualización Página 1 de 16 CUALIFICACIÓN SISTEMAS DE GESTIÓN DE INFORMACIÓN PROFESIONAL Familia Profesional Informática y Comunicaciones Nivel 3 Código IFC304_3 Versión 5 Situación RD 1201/2007 Actualización Competencia

Más detalles

CICLO SUPERIOR DESARROLLO DE APLICACIONES MULTIPLATAFORMA

CICLO SUPERIOR DESARROLLO DE APLICACIONES MULTIPLATAFORMA CICLO SUPERIOR DESARROLLO DE APLICACIONES MULTIPLATAFORMA PROGRAMACIÓN DIDACTICA ANUAL Parte específica del módulo: 0485. Programación Departamento de Familia Profesional de Informática Curso: 2014-15

Más detalles

Ontologías ECSDI. Curso 2014/2015. LSI-FIB-UPC cbea. ECSDI (LSI-FIB-UPC cbea) Ontologías Curso 2014/2015 1 / 36

Ontologías ECSDI. Curso 2014/2015. LSI-FIB-UPC cbea. ECSDI (LSI-FIB-UPC cbea) Ontologías Curso 2014/2015 1 / 36 Ontologías ECSDI LSI-FIB-UPC cbea Curso 2014/2015 ECSDI (LSI-FIB-UPC cbea) Ontologías Curso 2014/2015 1 / 36 Índice 1 Introducción 2 Ontologias 3 Proyectos de Ontologías 4 Elementos de un ontología ECSDI

Más detalles

Definición del modelo del negocio y del dominio utilizando Razonamiento Basado en Casos.

Definición del modelo del negocio y del dominio utilizando Razonamiento Basado en Casos. Definición del modelo del negocio y del dominio utilizando Razonamiento Basado en Casos. Autora: MSc. Martha D. Delgado Dapena. Centro de Estudios de Ingeniería de Sistemas. e-mail: marta@ceis.ispjae.edu.cu

Más detalles

Organizaciones Virtuales e Integración de Información. José Abásolo Prieto

Organizaciones Virtuales e Integración de Información. José Abásolo Prieto Organizaciones Virtuales e Integración de Información José Abásolo Prieto Universidad de los Andes Objetivo de la charla Mostrar que aunque la problemática de integración de información distribuida y heterogénea

Más detalles

Introducción a la Programación Orientada a Objetos (POO) Introducción a la Programación Orientada a Objetos (POO)

Introducción a la Programación Orientada a Objetos (POO) Introducción a la Programación Orientada a Objetos (POO) Diseño Orientado a Objetos. Metodología enfocada a la solución de problemas complejos. Complejidad del software. Problemas difíciles de precisar. Definición de requerimientos vago y cambio en el desarrollo

Más detalles

CAPÍTULO IV - GUÍA PARA HACER ANÁLISIS Y DISEÑO ORIENTADO A OBJETOS

CAPÍTULO IV - GUÍA PARA HACER ANÁLISIS Y DISEÑO ORIENTADO A OBJETOS CAPÍTULO IV - GUÍA PARA HACER ANÁLISIS Y DISEÑO ORIENTADO A OBJETOS 4.1 Diferencias entre análisis y diseño La división entre el análisis y diseño es poco clara, el trabajo de los dos se mezcla continuamente

Más detalles

Conexión de Reglas de Negocios con Aspectos: estrategias y herramienta

Conexión de Reglas de Negocios con Aspectos: estrategias y herramienta Conexión de Reglas de Negocios con Aspectos: estrategias y herramienta Sandra Casas y Cecilia Fuentes Zamorano UARG, Universidad Nacional de la Patagonia Austral Campus Universitario, Piloto Riversa s/n

Más detalles

ARQUITECTURA DE UNA BODEGA DE DATOS

ARQUITECTURA DE UNA BODEGA DE DATOS ARQUITECTURA DE UNA BODEGA DE DATOS Estructura de contenidos INTRODUCCIÓN... 3 1. ARQUITECTURA DE UNA BODEGA DE DATOS... 3 1.1 PROPIEDADES... 3 1.2 ARQUITECTURA DE UNA CAPA... 4 1.3 ARQUITECTURA DE DOS

Más detalles

Módulo Minería de Datos

Módulo Minería de Datos Módulo Minería de Datos Diplomado Por Elizabeth León Guzmán, Ph.D. Profesora Ingeniería de Sistemas Grupo de Investigación MIDAS Análsis Dimensional OLAP On-Line Analytical Processing Estructura del Proceso

Más detalles

Diseño del Sistema de Información

Diseño del Sistema de Información Diseño del Sistema de Información ÍNDICE DESCRIPCIÓN Y OBJETIVOS...2 ACTIVIDAD DSI 1: DEFINICIÓN DE LA ARQUITECTURA DEL SISTEMA...7 Tarea DSI 1.1: Definición de Niveles de Arquitectura...9 Tarea DSI 1.2:

Más detalles

MODELADO DE OBJETOS. {brossi,pbritos,rgm}@itba.edu.ar

MODELADO DE OBJETOS. {brossi,pbritos,rgm}@itba.edu.ar MODELADO DE OBJETOS Bibiana ROSSI, Paola BRITOS y Ramón GARCIA MARTINEZ, CAPIS - Centro de Actualizacion Permanente en Ingeniería de Software Escuela de Posgrado. ITBA. 0. INTRODUCCION {brossi,pbritos,rgm}@itba.edu.ar

Más detalles

UML. Lenguaje de Modelado Unificado

UML. Lenguaje de Modelado Unificado Lenguaje de Modelado Unificado Concepto de Reseña Histórica Características Estándares que conforman Modelo Relacional con Ventajas Críticas Concepto de (Unified( Modeling language) Es un lenguaje usado

Más detalles

Unidad III Modelamiento Multidimencional. Tecnología DATAWAREHOUSE

Unidad III Modelamiento Multidimencional. Tecnología DATAWAREHOUSE Unidad III Modelamiento Multidimencional Tecnología DATAWAREHOUSE Datawarehouse Colección de datos integrados, variantes en el tiempo, no volátiles, orientados a temas de interés para la gestión de una

Más detalles

Diseño del Sistema de Información

Diseño del Sistema de Información Diseño del Sistema de Información ÍNDICE DESCRIPCIÓN Y OBJETIVOS... 2 ACTIVIDAD DSI 1: DEFINICIÓN DE LA ARQUITECTURA DEL SISTEMA... 7 Tarea DSI 1.1: Definición de Niveles de Arquitectura... 9 Tarea DSI

Más detalles

AUTOMATIZACION DE PROCESOS DE DESARROLLO DE SOFTWARE DEFINIDOS CON SPEM

AUTOMATIZACION DE PROCESOS DE DESARROLLO DE SOFTWARE DEFINIDOS CON SPEM AUTOMATIZACION DE PROCESOS DE DESARROLLO DE SOFTWARE DEFINIDOS CON SPEM Fabio A. Zorzan y Daniel Riesco Resumen Esta línea de investigación propone una alternativa para lograr la automatización de la gestión

Más detalles

Metodología de Ingeniería del Software para el desarrollo y mantenimiento de sistemas de información del Gobierno de Extremadura

Metodología de Ingeniería del Software para el desarrollo y mantenimiento de sistemas de información del Gobierno de Extremadura Metodología de Ingeniería del Software para el desarrollo y mantenimiento de sistemas de información del Gobierno de Extremadura Página 1 de 23 Índice del Documento 1.- Introducción... Página 4 2.- Propuesta

Más detalles

METODOLOGÍA PARA ORGANIZAR, RECUPERAR Y COMPARTIR

METODOLOGÍA PARA ORGANIZAR, RECUPERAR Y COMPARTIR METODOLOGÍA PARA ORGANIZAR, RECUPERAR Y COMPARTIR RECURSOS DE INFORMACIÓN Y CONOCIMIENTO EN UN CENTRO I+D+I EN LA PLATAFORMA SURICATA Marrero, S.R; Nelson, J.C; Galán, M; Ocón, A.; Rubio, E. sonia@cicei.com;

Más detalles

Desafíos de gestionar proyectos de analítica de negocios

Desafíos de gestionar proyectos de analítica de negocios Desafíos de gestionar proyectos de analítica de negocios Desafíos de gestionar proyectos de analítica de negocios Tipología de proyectos BA Complejidad de proyectos BA Proyectos BA versus tradicionales

Más detalles

Curso de Pentaho. Business Intelligence and Data Warehousing with Pentaho

Curso de Pentaho. Business Intelligence and Data Warehousing with Pentaho Curso de Pentaho Business Intelligence and Data Warehousing with Pentaho Descripción: Pentaho proporciona inteligencia de negocios (BI) y soluciones de almacenamiento de datos (dataware house) a una fracción

Más detalles

Business Information Warehouse Manual SAP BW Business Information Warehouse

Business Information Warehouse Manual SAP BW Business Information Warehouse Manual SAP BW Business Information Warehouse Manual SAP BW / BI Business Information Warehouse Página 1 Confidencialidad Este documento es propiedad de E-SAP (CVOSOFT) por lo tanto, no podrá ser publicado

Más detalles

Los Datos que generan la Información

Los Datos que generan la Información Los Datos que generan la Información Introducción El objetivo de esta guía es mostrar las herramientas tecnológicas vigentes en la actualidad, para contener los datos que generan información. Es importante

Más detalles

Capítulo 4. Ontologías y su representación jerárquica.

Capítulo 4. Ontologías y su representación jerárquica. Capítulo 4. Ontologías y su representación jerárquica. En la interpretación de alto nivel de información visual, se tienen muchos progresos en la derivación de características de bajo nivel a partir de

Más detalles

Bases de Datos Tema 4 Modelo Entidad/Interrelación (ERM de Chen)

Bases de Datos Tema 4 Modelo Entidad/Interrelación (ERM de Chen) Departamento de Lenguajes y Sistemas Informáticos E.T.S. Ingeniería Informática. Universidad de Sevilla Avda Reina Mercedes s/n. 402 Sevilla Tlf/Fax 954 557 39 E-mail lsi@lsi.us.es Web www.lsi.us.es E.T.S.

Más detalles

Ingeniería de Software

Ingeniería de Software Ingeniería de Software MSDN Ingeniería de Software...1 Ingeniería del Software_/_ Ingeniería y Programación...1 Análisis de Requerimientos...2 Especificación...3 Diseño...4 Desarrollo en Equipo...5 Mantenimiento...6

Más detalles

MODELO DIMENSIONAL DE BODEGAS DE DATOS ADAPTABLE A EMPRESAS MIPYMES DE VENTAS AL DETAL

MODELO DIMENSIONAL DE BODEGAS DE DATOS ADAPTABLE A EMPRESAS MIPYMES DE VENTAS AL DETAL MODELO DIMENSIONAL DE BODEGAS DE DATOS ADAPTABLE A EMPRESAS MIPYMES DE VENTAS AL DETAL 1 Ing. Ingrid Paola Solano Benítez¹ Mg. Martha Eliana Mendoza Becerra² ¹ Docente Tiempo Completo, Facultad de Ingeniería,

Más detalles

Una Introducción al UML. El Modelo de Proceso de Negocio

Una Introducción al UML. El Modelo de Proceso de Negocio Una Introducción al UML Autor: Geoffrey Sparks, Sparx Systems, Australia Traducción: Fernando Pinciroli (Solus S.A., Argentina) y Aleksandar Orlic (Craftware Consultores Ltda., Chile) www.sparxsystems.com.ar

Más detalles

BASES DE DATOS TEMA 4 DISEÑO DE BASES DE DATOS RELACIONALES

BASES DE DATOS TEMA 4 DISEÑO DE BASES DE DATOS RELACIONALES BASES DE DATOS TEMA 4 DISEÑO DE BASES DE DATOS RELACIONALES El modelo relacional se basa en dos ramas de las matemáticas: la teoría de conjuntos y la lógica de predicados de primer orden. El hecho de que

Más detalles

RUP. Rational Unified Process

RUP. Rational Unified Process RUP Rational Unified Process Rational Unified Process Basado en 6 mejores prácticas de la industria de software: Desarrollo incremental Administración de requisitos Uso de arquitecturas basadas en componentes

Más detalles

DEPARTAMENTO: Ingeniería e Investigaciones Tecnológicas 1114. ASIGNATURA: BASE DE DATOS Año 2011

DEPARTAMENTO: Ingeniería e Investigaciones Tecnológicas 1114. ASIGNATURA: BASE DE DATOS Año 2011 DEPARTAMENTO: Ingeniería e Investigaciones Tecnológicas Código Asignatura 1114 ASIGNATURA: BASE DE DATOS Año 2011 FUNDAMENTACIÓN Base de datos contribuye a la formación del Ingeniero en Informática por

Más detalles

Modelo de Procesos para la Gestión de Requerimientos en Proyectos de Explotación de Información

Modelo de Procesos para la Gestión de Requerimientos en Proyectos de Explotación de Información Modelo de Procesos para la Gestión de Requerimientos en Proyectos de Explotación de Información Pollo-Cattaneo, M. F. 1,2, Mansilla, D 2,Vegega, C 2, Pesado, P. 3, García-Martínez, R. 4, P. Britos, P.

Más detalles

Diseño de almacén de datos para el análisis eficiente de la información de incidentes informáticos y mantenimientos.

Diseño de almacén de datos para el análisis eficiente de la información de incidentes informáticos y mantenimientos. Diseño de almacén de datos para el análisis eficiente de la información de incidentes informáticos y mantenimientos. Ing. Corso Cynthia, Ing. Luque Claudio, Ing. Ciceri Leonardo, Sr Donnet Matías Grupo

Más detalles

INGENIERÍA DEL SOFTWARE

INGENIERÍA DEL SOFTWARE INGENIERÍA DEL SOFTWARE Sesión No. 2 Nombre: Procesos de ingeniería del software INGENIERÍA DEL SOFTWARE 1 Contextualización La ingeniería de software actualmente es muy importante, pues con los avances

Más detalles

ISO 19103. Lenguaje de Esquema Conceptual

ISO 19103. Lenguaje de Esquema Conceptual ISO 19103 Lenguaje de Esquema Conceptual La ISO 19103 establece normas y guías para la adopción y uso de un Lenguaje de Esquema Conceptual (CSL) para desarrollar modelos o esquemas de información geográfica,

Más detalles

Herramienta de gestión de trazabilidad de requerimientos en proyectos de software

Herramienta de gestión de trazabilidad de requerimientos en proyectos de software Herramienta de gestión de trazabilidad de requerimientos en proyectos de software Alfredo Villafañe 1, María de los A. Ferraro 1, Yanina Medina 1, Cristina Greiner 1, Gladys Dapozo 1, Marcelo Estayno 2

Más detalles

Unidad II: Diseño de Bases de Datos y el modelo E-R. 2.1 El Proceso de Diseño

Unidad II: Diseño de Bases de Datos y el modelo E-R. 2.1 El Proceso de Diseño Unidad II: Diseño de Bases de Datos y el modelo E-R. 2.1 El Proceso de Diseño El proceso de diseño para una base de datos consta básicamente de 7 pasos, los cuáles se describen en la siguiente imagen.

Más detalles

Trabajo de Grado Análisis comparativo de Lenguajes Notacionales para Modelado de Procesos

Trabajo de Grado Análisis comparativo de Lenguajes Notacionales para Modelado de Procesos Trabajo de Grado Análisis comparativo de Lenguajes Notacionales para Modelado de Procesos Autora: Vasquez Pilar María Directora: Dra. Giandini Roxana Codirectora: Mg. Bazán Patricia Agenda Introducción.

Más detalles

UNIVERSIDAD UNION BOLIVARIANA CARRERA DE INGENIERIA DE SISTEMAS

UNIVERSIDAD UNION BOLIVARIANA CARRERA DE INGENIERIA DE SISTEMAS UNIVERSIDAD UNION BOLIVARIANA CARRERA DE INGENIERIA DE SISTEMAS METODOLOGIAS AGILES PROCESO UNIFICADO AGIL (AUP) MATERIA : INGENIERIA SOFTWARE DOCENTE : LIC. ERVIN FLORES ESTUDIANTE : JORGE LUIS CORDERO

Más detalles

ARQUITECTURA ESCALABLE PARA LA DETECCIÓN DE PATRONES SECUENCIALES DIFUSOS EN MINERÍA DE DATOS CUANTITATIVA

ARQUITECTURA ESCALABLE PARA LA DETECCIÓN DE PATRONES SECUENCIALES DIFUSOS EN MINERÍA DE DATOS CUANTITATIVA ARQUITECTURA ESCALABLE PARA LA DETECCIÓN DE PATRONES SECUENCIALES DIFUSOS EN MINERÍA DE DATOS CUANTITATIVA Pablo F. Provasi 1 Lucio J. Kleisinger 1 Francisco R. Villatoro 2 1 Dpto. de Informática, Universidad

Más detalles

IBM Rational Method Composer V7.5.1 ofrece creación de métodos simplificados e interoperabilidad en IBM Rational Team Concert

IBM Rational Method Composer V7.5.1 ofrece creación de métodos simplificados e interoperabilidad en IBM Rational Team Concert con fecha 30 de noviembre de 2010 IBM Rational Method Composer V7.5.1 ofrece creación de métodos simplificados e interoperabilidad en IBM Rational Team Concert Índice 1 Información general 2 Fecha de disponibilidad

Más detalles

Estudio Comparativo de Técnicas de Modelado de Negocio

Estudio Comparativo de Técnicas de Modelado de Negocio Estudio Comparativo de Técnicas de Modelado de Negocio Juan José Cadavid 1, Carlos Andrés Ospina 1, Juan Bernardo Quintero 2 1 Avansoft S.A. Medellín, Colombia {jjcadavid, caospina}@avansoft.com 2 ABC-Flex

Más detalles

Mejora en la Administración de Procesos de Desarrollo de Software Tipo SPEM Automatizados Bajo Workflow

Mejora en la Administración de Procesos de Desarrollo de Software Tipo SPEM Automatizados Bajo Workflow Mejora en la Administración de Procesos de Desarrollo de Software Tipo SPEM Automatizados Bajo Workflow Fabio A. Zorzan 1 y Daniel Riesco 2 Resumen Esta línea de investigación pretende aportar a la mejora

Más detalles

DESARROLLO DE SOFTWARE EMPRESARIAL. Jonás Montilva C. Judith Barrios A. Universidad de Los Andes

DESARROLLO DE SOFTWARE EMPRESARIAL. Jonás Montilva C. Judith Barrios A. Universidad de Los Andes DESARROLLO DE SOFTWARE EMPRESARIAL Jonás Montilva C. Judith Barrios A. Universidad de Los Andes Desarrollo de Software Empresarial Derechos Reservados. Ninguna parte de este documento puede ser reproducida,

Más detalles

Especificación de requerimientos

Especificación de requerimientos Especificación de requerimientos 1. Requerimientos funcionales y no funcionales 2. Especificación de requerimientos en lenguaje natural 3. Herramientas de especificación Modelado de datos Diagramas entidad/relación

Más detalles

Derivación de requisitos y construcción de trazabilidad entre artefactos del proceso de desarrollo

Derivación de requisitos y construcción de trazabilidad entre artefactos del proceso de desarrollo Derivación de requisitos y construcción de trazabilidad entre artefactos del proceso de desarrollo Cecilia Datko 1, Yanela Carllinni 2 Analista de Sistemas en el Depto. Sistemas de la Dirección de Informática

Más detalles

Qué es una ontología?

Qué es una ontología? Ontologías Qué es una ontología? Una ontología define un vocabulario común para investigadores que necesitan compartir información del dominio. Contiene: Definiciones de conceptos básicos Relaciones que

Más detalles

Definición. Data Warehousing: almacenamiento, transformación y distribución de datos útiles para los responsables de tomar decisiones 9/29/2006 4

Definición. Data Warehousing: almacenamiento, transformación y distribución de datos útiles para los responsables de tomar decisiones 9/29/2006 4 Definición Data Warehousing: almacenamiento, transformación y distribución de datos útiles para los responsables de tomar decisiones 9/29/2006 4 Definición (cont.) Un Data Warehouse es una colección de

Más detalles

Anexo 4 Documento de Arquitectura

Anexo 4 Documento de Arquitectura Anexo 4 Documento de Arquitectura 1. Introducción El anexo se describe el propósito y alcance referentes al proyecto correspondiente al documento de arquitectura. 2. Propósito El propósito del anexo de

Más detalles

14. Ingeniería de software. Ing. Alejandro Adorjan

14. Ingeniería de software. Ing. Alejandro Adorjan 14. Ing. Alejandro Adorjan : un enfoque en ingeniería de requerimientos Introducción La ingeniería de software es una disciplina que estudia la aplicación de la teoría, el conocimiento y la práctica de

Más detalles

El Proceso Unificado

El Proceso Unificado El Proceso Unificado de Desarrollo de Software Prof. Gustavo J. Sabio Alcance de la presentación QA Entradas Proceso de desarrollo Salida equipo Cliente sistemas Cliente necesidades actividades varias

Más detalles