Lenguaje Unificado de Modelado

Antes de la informática, todos los procesos eran llevados de una forma minuciosa y manualmente, los personajes más distinguidos y con más pericia eran gente indispensable, “gente de oro”, que se encargaba de “x, y ó z” funciones y que no podía ser sustituido. Este verifica el trabajo de los otros. Todo el trabajo se acumulaba alrededor de él.
Esto ha sido a través de los siglos uno de las formas principales de laborar en las empresas, pero algunos cambios han sido progresivos la evolución de las maquinas y la integración de nuevas tecnologías hicieron que aquel trabajo fuese maquina-manual.

Poco a paso algunos pasos del trabajo fueron automatizados con la era de las computadoras. Pero no es a partir de los años setentas que se han desarrollado herramientas que sirven no sólo para hacer el trabajo sino para manejar el flujo de este. El flujo del trabajo es ahora procesado por un computador, y sigue el progreso hoy en día. Este flujo llamado también “workflow”, nos sirve desde el manejo gerencial, hasta la creación o elaboración de una pieza de ropa, de un ensamble de vehículo hasta la construcción de equipo de sonido.

Es por ello que un sistema de gestión automatizada de workflow posee:

El trabajo no es mal colocado o atascado – la gente rara vez requiere recuperar errores por una mala gestión del trabajo. Los encargados pueden centrarse en editar personal y el negocio, tales como su funcionamiento individual, procedimientos óptimos y casos especiales, mejor que la asignación rutinaria de tareas. Ya no más un ejército de despachadores para entregar y dar seguimiento a un trabajo.

Los procedimientos se documentan formalmente y de manera exacta, asegurándose de que el trabajo esté realizado de la manera prevista por la gerencia, resolviendo todo el negocio y los requisitos reguladores. La mejor persona(o máquina) se asigna para hacer cada caso, y los casos más importantes se asignan primero. Los usuarios no pierden tiempo en elegir que artículo para trabajar correcto.

Proceso paralelo, donde dos o más tareas se realizan concurrentemente, es más práctico que en un workflow tradicional y manual. Para hacer las asignaciones, el sistema de gestión de workflow puede encargarse de asignar el trabajo teniendo en cuenta el perfil de cada usuario o equipo y recurso con el que se elabora el trabajo. Para así designar que hará o si tomará decisiones, etc. Así el sistema de saber que tipo de trabajo esta en tramite y espera, materiales forma de hacer, prioridades, etc.

Todo se trabaja como una línea de ensamble o listo a la primera: La mayor parte de trabajos incluso los de oficina, se pueden procesar como una línea de ensamble, donde cada paso es simple y especializado en el proceso.
Es decir alguien se encarga de tomar datos y el sistema de comprobarlos, otro recupera el crédito del cliente, ver las ordenes de compra, o las cuentas por cobrar, etc. Así cuando toda la información se consolida, un especialista puede evaluar al cliente. Y sucesivamente. Los pasos son sencillos.

Es de esta forma que el trabajo se vuelve menos complejo y reducimos entrenamiento. Así el proveer personal es flexible, porque pocos pasos requieren un conocimiento o habilidades, autoridad o licencias especiales.

Un sistema de gestión automatizada de workflow:

Mejora el control de procesos, con menos intervención de la gerencia y menos ocasión para retrasos o colocación de trabajos. Mejora la calidad del servicio, mediante respuestas más rápidas, con el mejor personal disponible.Reduce costos de entrenamiento de personal, pues el trabajo se puede dirigir con procedimientos complejos.

Reduce costos de gestión, permitiendo un mínimo de control, mientras que permite que los encargados se concentren en la consolidación de los empleados y la manipulación de casos especiales y de rutinas de divulgación y distribución.

Mejora la satisfacción del usuario, dándole la confianza de que está haciendo “el mejor producto” y que está dando la satisfacción de terminar ese trabajo con pocos requisitos. Para totalizar: Un sistema de gestión automatizado de workflow es bueno para la compañía, bueno para el cliente y bueno para el usuario.

Editado por:

Victor Hugo Castro

Por qué usar el Workflow?

Publicado por .::UML_SECCION-06_UTEC::. en 20:50 0 comentarios

¿POR QUÉ USAR EL WORKFLOW?

Es hasta un poco tonto hacerse esa pregunta ya que la redefinición y mejora de los procesos de negocio, por un lado, y la posterior automatización de los mismos mediante el uso de herramientas de WorkFlow, por el otro lado, posibilitan y facilitan la integración de las nuevas tecnologías con los procesos de negocio.

Si nos damos cuenta sin el uso del workflow estaríamos sujetos a gastar
mucho mas dinero, tiempo, y personal en realizar tareas que se pueden
automatizar, debido a estas ventajas que proporciona como el incrementos de la rapidez de los procesos, ahorro de dinero se dan algunas ventajas por las cuales las empresas deberían de adoptar a este hijo que les dará mucha ganancia.

La implantación de un sistema de WorkFlow ofrece beneficios sustanciales a las organizaciones, independientemente del sector de mercado en el que operen. La solución de automatización de procesos WorkFlow produce beneficios reales a las empresas y organizaciones, formando parte integral de la infraestructura de las mismas. En general, los resultados indican que los que han implementado la solución WorkFlow, han obtenido los siguientes beneficios:

Eficiencia y estandarización de los mismos.
Lo cual nos lleva a reducir costos, que es lo principal para cualquier empresa o negocio.

La estandarización nos lleva a conocer mejor los procesos y evitar los
errores, que producen grandes gastos en cualquier entorno.

Control de los procesos.
El objetivo de este es monitorear las tareas es decir visualizar cuales tareas se realizar con tiempos no estimados, ósea las que necesitan decisiones al igual que permite ver como se da el cambio de tiempos es decir como avanza el trabajo.

Asignación de las tareas
Lo cual lleva a la definición de los roles de cada parte de la empresa, ya que se definen las tareas que cada quien hará.

Recursos de la empresa
Es decir la disponibilidad de la información para cada uno de los diferente usuario del sistema empresarial en caso de ser necesarios, como por ejemplo la consulta de el saldo de un deudor en una casa de empeño, el agente de el departamento de deudas se vería obligado a consultar su base de datos y tener la disponibilidad de esta información como empleado.

Diseño de los procesos
Es decir la forma en que se realizara la tarea dispuesta de una forma jerárquica lógica, para no redundar y no gastar más tiempo del requerido.

Flujo de información
La cual se transporta de una manera automatizada por el sistema con ayuda de los procesos del workflow.

Se agregan estas:

Mejora del rendimiento y la productividad del trabajo de las personas involucradas en el proceso.
Aumento de la transparencia y visibilidad.
Mayor agilidad y capacidad de respuesta para la adaptación al cambio.

PROCESO DE NEGOCIOS
En nuestro vivir cotidiano vemos como cada empresa desempeña sus funciones de una manera integral es decir formada de diferentes partes con el objetivo de brindar sus servicios independientemente de los que sean; ubiquemos este punto de referencia imaginando una tienda de calzado, hay un vendedor que ofrece el calzado, un gerente que se encarga de tomar las decisiones, el encargado de la facturación y que puede también manejar el sistema; en este caso son tres personas las que se encargan de diferentes roles los cuales realizan diversas tareas que en conjunto llevan al rubro de la empresa que es vender o surtir calzado a la población.

Si nos enfocamos en este ejemplo cada uno de los trabajadores realizan diferentes tareas en sus distintos roles, los cuales serían procesos.

LOS DIFERENTES WORKFLOW’s
Existen tres tipos diferentes de aplicaciones de workflow:

Workflow de producción
Workflow colaborativo
Workflow administrativo

El workflow de producción
En las aplicaciones de workflow de producción, el workflow es la tarea principal de los participantes. Dicho personal puede tener actividades adicionales en su trabajo diario, pero fundamentalmente la realización de workflow. Ejemplo: tramitar solicitudes de crédito.

Es similar a la producción en una línea de ensamble en una fábrica: Debe ejecutarse en el menor tiempo posible, es altamente predecible, repetitivo y de alto volumen. Los trabajadores en la línea de ensamble pasan su mayor parte del tiempo produciendo objetos; pueden participar en actividades adicionales, pero ellas son secundarias.

En un banco por ejemplo, los individuos a cargo de la aprobación de solicitudes de crédito sólo realizan workflow para esa actividad es improbable que otros funcionarios del banco realicen esa actividad fuera del departamento.

Debido a la naturaleza su naturaleza de "producción", dichas aplicaciones deben cumplir con algunos de los siguientes atributos: Velocidad de transferencia, o sea, la velocidad con que las tareas pasan de un paso a otro.

Es muy importante en el workflow de producción, ya que es la tarea principal de los participantes. Es improductivo que un miembro del equipo no haga nada mientras espera a que le llegue trabajo.

Una vez establecido el flujo, este permanece sin cambio por largo tiempo. El workflow de producción suele estar circunscrito a un sólo departamento, la escalabilidad, o capacidad de "crecer" no es importante. Este tipo de soluciones están optimizadas para trasladar grandes volúmenes de información e imágenes a lo largo de rutas preestablecidas.

El workflow de producción fue el primer tipo de workflow desarrollado y mercadeado, esto, porque generalmente no se requería de una base distribuida de usuarios a lo largo de la compañía para lo que es indispensable contar con una red local (LAN).

Workflow colaborativo
Involucra procesos estructurados o semi-estructurados que permiten a varias personas participar en un grupo de trabajo, ejemplos de ello lo constituyen el diseño arquitectónico o ingenieril, generación de informes, producción de material publicitario, revisión de documentos legales, etc.

Estos procesos involucran típicamente un "documento" que hace las veces de contenedor de la
información, viajando de paso en paso y en cada uno de ellos el partícipe realiza una tarea o acción sobre el "documento".

Es importante para la aplicación preservar la integridad tanto del documento como del proceso. Fundamentalmente participan "knowledge workers", por tanto está restringido a ciertos grupos "creativos" dentro de la organización.

También es importante que una buena solución no sea "intrusiva" ya que el trabajo de conocimiento es un proceso mental que involucra la creatividad, la que no se desea restringir o encasillar.

El workflow colaborativo debe ser muy flexible ya que el trabajo creativo puede tomar rumbos inesperados. Las soluciones de workflow colaborativo suelen estar centradas en el "documento".

Workflow administrativo
Involucra procesos administrativos tales como ordenes de compra, hojas de tiempos y movimientos, reportes de gastos, cambios de ordenes, reportes de calidad y muchas otras actividades que traspasan las barreras departamentales e inclusive de la empresa misma.

Existen un gran número de procesos administrativos en cada organización, por ello la solución debe ser capaz de manejar muchos procesos diferentes. Casi cualquier persona es un participante potencial, de ahí que la escalabilidad de la solución sea de mucha importante.

El workflow administrativo es diferente para cada organización y también cambia con frecuencia; de ahí la gran importancia de poder cambiar los procesos fácilmente.

Ya que cualquiera en la empresa es un participante potencial, es necesario poder distribuir el software al mayor número de usuarios con la menor carga logística posible.

Modelado de workflow
Este es el punto en que de forma formal se genera el modelo sobre el cual se implementar las distintas tareas y proceso que una empresa hará a la hora de trabajar en conjunto, de forma tal que este sea un ambiente competitivo para las diferentes interfaces, y satisfaga los diferentes roles.

A continuación se mencionaran los diferentes conceptos elementales en la
generación del modelo:

Tareas
Las tareas son las acciones hechas individualmente por los diferentes roles, cada una de estas es hecha únicamente por una persona previamente definida en los roles.

Personas
Las tareas son realizadas por estos ósea los empleados que tiene que seguir las reglas del juego (que serian los agentes y personas importantes).

Roles
los roles definen las distintas capacidades dentro del sistema y de la empresa, una persona puede tener mas de un rol como por ejemplo un mesero puede tener el rol de ofrecer el servicio a la mesa, sin embargo tamben puede ingresar al sistema la orden y cobrarla.

Rutas
Son los pasos a seguir de los documentos dentro del sistema. Existen varios tipos de ruteos que son:

* Rutas fijas
Los documentos siguen en el mismo camino estas son previamente definidas.

* Rutas de condición
Estas dependen de una condición

* Rutas ad hoc
El usuario elige a donde ir.

Construcción de las rutas

AND-split

A partir de una fuente la información es distribuida

AND-join
A partir de varios lugares de fuentes estos convergen hacia un solo destino.

OR-split
A partir de un lugar los documentos toman un destino entre varios.

OR-join
A partir de uno o más orígenes, dentro de varios, convergen hacia un solo destino.

Loop
En este caso se hace un circuito cerrado es decir la información circula en el mismo.

Reglas de transición
Son las reglas a las cuales se someten los datos es decir las condiciones que esta puede o no pude cumplir.

Datos
Por lógica archivos del workflow, documentos, imágenes, correos, etc. que se involucren con el sistema, para llevar a cabo el trabajo deseado. Se encuentran los datos de control que son los que manejan la lógica del sistema, los datos relevantes que son los que se rutean en las diferentes tareas del flujo, y los datos de aplicación que son accedidos solamente por las
aplicaciones.

A estos datos se les da una restricción es decir no todos los empleados tienen acceso a toda la base de datos ya que podrían ser mal utilizados ósea podría haber fuga de información.

Eventos
Son interrupciones que contienen la información de un mensaje, estos se pueden producir por los usuarios mediante un proceso.

Plazos
Son los tiempos de realización de tareas, son por ejemplo el tiempo máximo para una tarea, y aquí podemos emplear los eventos, después de que cierta tarea sea terminada que se dispare un evento.

Procesos
Son los que definitivamente se deben de utilizar debido a que se da oportunidad que se coloquen procesos que casi nunca se utilizan.

Políticas
Las empresas tienden a tener ciertas reglas del juego de su negocio por ejemplo en las tiendas de comidas rápidas es un política que los sobrantes de comida se desechen, los cual es desde un punto de vista negarle el derecho de comer a alguien.

Edición:
Melvin Amaya.
Edwin Cartagena.

Ingeniería de requisitos.

Publicado por .::UML_SECCION-06_UTEC::. en 20:46 0 comentarios

Determinación de necesidades Clientes

Ingeniería de requisitos

En la ingeniería de sistemas y la ingeniería de software la Ingeniería de requisitos comprende todas las tareas relacionadas con la determinación de las necesidades o de las condiciones a satisfacer para un software nuevo o modificado, tomando en cuenta los diversos requisitos de los inversores, que pueden entrar en conflicto entre ellos.

Muchas veces se habla de requerimientos en vez de requisitos, esto se debe a una mala traducción del inglés. La palabra requirement debe ser traducida como requisito, mientras que requerimiento se traduce al inglés como request.

El propósito de la ingeniería de requisitos es hacer que los mismos alcancen un estado óptimo antes de alcanzar la fase de diseño en el proyecto. Los buenos requisitos deben ser medibles, comprobables, sin ambigüedades o contradicciones, etc.

Fases de implementación

Desde un punto de vista conceptual, las actividades son de 5 clases.

Obtener requisitos:

A través de entrevistas o comunicación con clientes o usuarios, para saber cuáles son sus deseos.
Analizar requisitos:

Detectar y corregir las falencias comunicativas, transformando los requisitos obtenidos de entrevistas y requisitos, en condiciones apropiadas para ser tratados por el diseño.
Documentar requisitos:

Igual que todas las etapas, los requisitos deben estar debidamente documentados.
Verificar los requisitos:

Consiste en comprobar el correcto funcionamiento de un requisito en la aplicación
Validar los requisitos:

Comprobar que los requisitos implementados se corresponden con lo que inicialmente se pretendía.

Técnicas principales

La ingeniería de requisitos puede ser un proceso largo y arduo para el que se requiere de habilidades psicológicas. Los nuevos sistemas cambian el entorno y las relaciones entre la gente, así que es importante identificar a todas las personas implicadas, considerar sus necesidades y asegurar que entienden las implicaciones de los nuevos sistemas. Los analistas pueden emplear varias técnicas para obtener los requisitos del cliente. Históricamente, esto ha incluido técnicas tales como las entrevistas, o talleres con grupos para crear listas de requisitos. Técnicas más modernas incluyen los prototipos, y utilizan casos de uso. Cuando sea necesario, el analista empleará una combinación de estos métodos para establecer los requisitos exactos de las personas implicadas, para producir un sistema que resuelva las necesidades del negocio.

Entrevistas

Las entrevistas son un método común. Por lo general no se entrevista a toda la gente que se relacionará con el sistema, sino a una selección de personas que represente a todos los sectores críticos de la organización, con el énfasis puesto en los sectores más afectados o que harán un uso más frecuente del nuevo sistema. Los requisitos que surgen de las entrevistas a menudo se contradicen unos a otros o se formulan desde la ignorancia de los detalles del funcionamiento del sistema, sus potencialidades, interdependencias o limitaciones; por lo que se debe trabajar con los mismos para corregir sus fallos.

Las entrevistas pueden ser personales o grupales.

Talleres

Los requisitos tienen a menudo implicaciones cruzadas desconocidas para las personas implicadas individuales y que a menudo no se descubren en las entrevistas o quedan incompletamente definidas durante la misma. Estas implicaciones cruzadas pueden descubrirse realizando en un ambiente controlado, talleres facilitados por un analista del negocio, en donde las personas implicadas participan en discusiones para descubrir requisitos, analizan sus detalles y las implicaciones cruzadas. A menudo es útil la selección de un secretario dedicado a la documentación de la discusión, liberando al analista del negocio para centrarse en el proceso de la definición de los requisitos y para dirigir la discusión.

Forma de contrato

En lugar de una entrevista, se pueden llenar formularios o contratos indicando los requisitos. En sistemas muy complejos éstos pueden tener centenares de páginas.

Objetivos medibles

Los requisitos formulados por los usuarios se toman como objetivos generales, a largo plazo, y en cambio se los debe analizar una y otra vez desde el punto de vista del sistema hasta determinar los objetivos críticos del funcionamiento interno que luego darán forma a los comportamientos apreciables por el usuario. Luego, se establecen formas de medir el progreso en la construcción, para evaluar en cualquier momento qué tan avanzado se encuentra el proyecto.

Prototipos

Un prototipo es una pequeña muestra, de funcionalidad limitada, de cómo sería el producto final una vez terminado. Ayudan a conocer la opinión de los usuarios y rectificar algunos aspectos antes de llegar al producto terminado.

Casos de uso

Un caso de uso es una técnica para documentar posibles requisitos, graficando la relación del sistema con los usuarios u otros sistemas. Dado que el propio sistema aparece como una caja negra, y sólo se representa su interacción con entidades externas, permite omitir dichos aspectos y determinar los que realmente corresponden a las entidades externas. El objetivo de esta práctica es mejorar la comunicación entre los usuarios y los desarrolladores, mediante la prueba temprana de prototipos para minimizar cambios hacia el final del proyecto y reducir los costes finales. Esta técnica se enfrenta a los siguientes peligros potenciales.

A los directivos, una vez que ven un prototipo, les cuesta comprender que queda mucho trabajo por hacer para completar el diseño final.
Los diseñadores tienden a reutilizar el código de los prototipos por temor a “perder el tiempo” al comenzar otra vez.
Los prototipos ayudan principalmente a las decisiones del diseño y de la interfaz de usuario. Sin embargo, no proporcionan explícitamente cuáles son los requisitos.
Los diseñadores y los usuarios finales pueden centrarse demasiado en el diseño de la interfaz de usuario y demasiado poco en producir un sistema que sirva el proceso del negocio.

Los prototipos pueden ser: diagramas, aplicaciones operativas con funcionalidades sintetizadas. Los diagramas, en los casos donde se espera que el software final tenga diseño gráfico, se realizan en una variedad de documentos de diseño gráficos y a menudo elimina todo el color del diseño del software (es decir utilizar una gama de grises). Esto ayuda a prevenir la confusión sobre la apariencia final de la aplicación.

Especificación de requisitos del software

Una especificación de requisitos del software es una descripción completa del comportamiento del sistema a desarrollar. Incluye un conjunto de casos de uso que describen todas las interacciones que se prevén que los usuarios tendrán con el software. También contiene requisitos no funcionales (o suplementarios). Los requisitos no funcionales son los requisitos que imponen restricciones al diseño o funcionamiento del sistema (tal como requisitos de funcionamiento, estándares de calidad, o requisitos del diseño).

Las estrategias recomendadas para la especificación de los requisitos del software están descritas por IEEE 830-1998. Este estándar describe las estructuras posibles, contenido deseable, y calidades de una especificación de requisitos del software.

Los requisitos se dividen en tres:

Funcionales: son los que el usuario necesita que efectúe el software. Ej: el sistema debe emitir un comprobante al asentar la entrega de mercadería.
No funcionales: son los "recursos" para que trabaje el sistema de información (redes, tecnología). Ej: el soporte de almacenamiento a usar debe ser MySQL.
Empresariales u Organizacionales: son el marco contextual en el cual se implantará el sistema para conseguir un objetivo macro. Ej: abaratar costos de expedición.

Identificación de las personas involucradas

Debido a que los cambios que introduce un sistema nuevo tienden a afectar a más de un tipo de usuario, los analistas de requisitos han de tomar en consideración a todos los implicados para que se obtengan y depuren sus requisitos de la forma más fidedigna posible. Entre las personas implicadas hay que considerar:

Organizaciones que integran la organización del analista que está diseñando el sistema
Organizaciones o sistemas de respaldo
Dirección
Usuarios

Problemas

Relacionados con las personas involucradas

Vías que pueden dificultar la determinación de los requisitos son:

Los usuarios no tiene claro lo que desean
Los usuarios no se involucran en la elaboración de requisitos escritos
Los usuarios insisten en nuevos requisitos después de que el coste y la programación se hayan fijado.
La comunicación con los usuarios es lenta
Los usuarios no participan en revisiones o son incapaces de hacerlo.
Los usuarios no comprenden los problemas técnicos
Los usuarios no entienden el proceso del desarrollo

Esto puede conducir a la situación donde las exigencias del consumidor cambian, incluso cuando el desarrollo del producto ya está en marcha.

Relacionados con los analistas

La correcta redacción de las Especificaciones de requisitos Software es imprescindible para el correcto desarrollo del proyecto. Por ello, en su redacción hay que evitar:

Uso de terminología ambigua en la redacción de los documentos de requisitos
Sobreespecificación de los requisitos
Escritura poco legible, voz pasiva, abuso de negaciones
Uso de verbos en condicional, expresiones subjetivas
Ausencia de términos y verbos del dominio de la aplicación

Relacionados con los desarrolladores

Los problemas posibles causados por los desarrolladores durante análisis de requisitos son:

El personal técnico y los usuarios finales pueden tener diversos vocabularios y pueden llegar a creer incorrectamente que están de acuerdo, no dándose cuenta del desacuerdo hasta que se provee el producto final.
Los desarrolladores pueden intentar encajar el sistema en un modelo existente, en vez de desarrollar un sistema adaptado a las necesidades del cliente.
El análisis de requisitos se puede realizar a menudo por los ingenieros o programadores, en vez de personal con las habilidades de relación con la gente y el conocimiento apropiados para entender las necesidades de un cliente correctamente.

Soluciones aplicadas

Una solución aplicada en los problemas de comunicaciones ha sido emplear a especialistas en análisis del negocio o del sistema.

Las técnicas introducidas en los años 90 tienden al uso de prototipos, lenguaje unificado de modelado, casos de uso, y el desarrollo ágil de software.

Otros tipos de herramientas aplicadas para salvar las diferencias entre los usuarios y las organizaciones de tecnología de la información y que permiten la comprobación de las aplicaciones son:

Pizarras electrónicas para bosquejar los algoritmos y para probar alternativas
Capacidad de capturar la lógica del negocio y los datos necesarios
Capacidad de generar los prototipos que imitan fielmente el producto final
Interactividad
La capacidad para agregar requisitos contextuales y otro comentarios
Capacidad para que usuarios remotos y distribuidos operen con el prototipo

Por último, se requieren herramientas que permitan medir, de forma objetiva, la calidad de una especificación de requisitos.

Editado por:

Oscar Calderon

Proceso Unificado

Publicado por .::UML_SECCION-06_UTEC::. en 20:45 0 comentarios

Proceso Unificado

View more presentations from UML seccion 06 UTEC 01-2010.

Almacenes de Datos

Publicado por .::UML_SECCION-06_UTEC::. en 6:24 0 comentarios

Función de un almacén de datos

En un almacén de datos lo que se quiere es contener datos que son necesarios o útiles para una organización, es decir, que se utiliza como un repositorio de datos para posteriormente transformarlos en información útil para el usuario. Un almacén de datos debe entregar la información correcta a la gente indicada en el momento óptimo y en el formato adecuado. El almacén de datos da respuesta a las necesidades de usuarios expertos, utilizando Sistemas de Soporte a Decisiones (DSS), Sistemas de información ejecutiva (EIS) o herramientas para hacer consultas o informes. Los usuarios finales pueden hacer fácilmente consultas sobre sus almacenes de datos sin tocar o afectar la operación del sistema.

Bill Inmon fue uno de los primeros autores en escribir sobre el tema de los almacenes de datos, define data warehouse (almacén de datos) en términos de las características del repositorio de datos:

Orientado a temas.- Los datos en la base de datos están organizados de manera que todos los elementos de datos relativos al mismo evento u objeto del mundo real queden unidos entre sí.
Variante en el tiempo.- Los cambios producidos en los datos a lo largo del tiempo quedan registrados para que los informes que se puedan generar reflejen esas variaciones.
No volátil.- La información no se modifica ni se elimina, una vez almacenado un dato, éste se convierte en información de sólo lectura, y se mantiene para futuras consultas.
Integrado.- La base de datos contiene los datos de todos los sistemas operacionales de la organización, y dichos datos deben ser consistentes.

Definición de Bill Inmon.

Defiende una metodología descendente a la hora de diseñar un almacén de datos, ya que de esta forma se considerarán mejor todos los datos corporativos. En esta metodología los Data marts se crearán después de haber terminado el data warehouse completo de la organización.

Definición de Ralph Kimball

Éste es otro conocido autor en el tema de los data warehouse, define un almacén de datos como: "una copia de las transacciones de datos específicamente estructurada para la consulta y el análisis". También fue Kimball quien determinó que un data warehouse no era más que: "la unión de todos los Data marts de una entidad". Defiende por tanto una metodología ascendente a la hora de diseñar un almacén de datos.

Una definición más amplia de almacén de datos

Las definiciones anteriores se centran en los datos en sí mismos. Sin embargo, los medios para obtener y analizar esos datos, para extraerlos, transformarlos y cargarlos, así como las diferentes formas para realizar la gestión de datos son componentes esenciales de un almacén de datos.

Muchas referencias a un almacén de datos utilizan esta definición más amplia. Por lo tanto, en esta definición se incluyen herramientas para la inteligencia empresarial, herramientas para extraer, transformar y cargar datos en el almacén de datos, y herramientas para gestionar y recuperar los metadatos.

En el funcionamiento de un almacén de los datos son muy importantes las siguientes ideas:

Integración de los datos provenientes de bases de datos distribuidas por las diferentes unidades de la organización y que con frecuencia tendrán diferentes estructuras (fuentes heterogéneas). Se debe facilitar una descripción global y un análisis comprensivo de toda la organización en el almacén de datos.
Separación de los datos usados en operaciones diarias de los datos usados en el almacén de datos para los propósitos de divulgación, de ayuda en la toma de decisiones, para el análisis y para operaciones de control. Ambos tipos de datos no deben coincidir en la misma base de datos, ya que obedecen a objetivos muy distintos y podrían entorpecerse entre sí.

Periódicamente, se importan datos al almacén de datos de los distintos sistemas de planeamiento de recursos de la entidad (ERP) y de otros sistemas de software relacionados con el negocio para la transformación posterior. Es práctica común normalizar los datos antes de combinarlos en el almacén de datos mediante herramientas de extracción, transformación y carga (ETL). Estas herramientas leen los datos primarios (a menudo bases de datos OLTP de un negocio), realizan el proceso de transformación al almacén de datos (filtración, adaptación, cambios de formato, etc.) y escriben en el almacén.

Data marts

Los Data marts son subconjuntos de datos de un data warehouse para áreas especificas.

Entre las características de data mart destacan:

Usuarios limitados.
Área especifica.
Tiene un propósito específico.
Tiene una función de apoyo.

Cubos de información

Los cubos de información o cubos OLAP funcionan como los cubos de rompecabezas en los juegos, en el juego se trata de armar los colores y en el data warehouse se trata de organizar los datos por tablas o relaciones; los primeros (el juego) tienen 3 dimensiones, los cubos OLAP tienen un número indefinido de dimensiones, razón por la cual también reciben el nombre de hipercubos.

Un cubo OLAP contendrá datos de una determinada variable que se desea analizar, proporcionando una vista lógica de los datos provistos por el sistema de información hacia el data warehouse, esta vista estará dispuesta según unas dimensiones y podrá contener información calculada. El análisis de los datos está basado en las dimensiones del hipercubo, por lo tanto, se trata de un análisis multidimensional.

A la información de un cubo puede acceder el ejecutivo mediante "tablas dinámicas" en una hoja de cálculo o a través de programas personalizados. Las tablas dinámicas le permiten manipular las vistas (cruces, filtrados, organización, totales) de la información con mucha facilidad.

Las diferentes operaciones que se pueden realizar con cubos de información se producen con mucha rapidez. Llevando estos conceptos a un data warehouse, éste es una colección de datos que está formada por «dimensiones» y «variables», entendiendo como dimensiones a aquellos elementos que participan en el análisis y variables a los valores que se desean analizar.

Dimensiones

Las dimensiones de un cubo son atributos relativos a las variables, son las perspectivas de análisis de las variables (forman parte de la tabla de dimensiones).

Son catálogos de información complementaria necesaria para la presentación de los datos a los usuarios, como por ejemplo: descripciones, nombres, zonas, rangos de tiempo, etc. Es decir, la información general complementaria a cada uno de los registros de la tabla de hechos.

Variables

También llamadas “indicadores de gestión”, son los datos que están siendo analizados. Forman parte de la tabla de hechos. Más formalmente, las variables representan algún aspecto cuantificable o medible de los objetos o eventos a analizar. Normalmente, las variables son representadas por valores detallados y numéricos para cada instancia del objeto o evento medido. En forma contraria, las dimensiones son atributos relativos a las variables, y son utilizadas para indexar, ordenar, agrupar o abreviar los valores de las mismas.

Las dimensiones poseen una granularidad menor, tomando como valores un conjunto de elementos menor que el de las variables; ejemplos de dimensiones podrían ser: “productos”, “localidades” (o zonas), “el tiempo” (medido en días, horas, semanas, etc.)

Ejemplos de variables podrían ser:

Beneficios
Gastos
Ventas
etc.

Metadatos

Uno de los componentes más importantes de la arquitectura de un almacén de datos son los metadatos. Se define comúnmente como "datos acerca de los datos", en el sentido de que se trata de datos que describen cuál es la estructura de los datos que se van a almacenar y cómo se relacionan.

El metadato documenta, entre otras cosas, qué tablas existen en una base de datos, qué columnas posee cada una de las tablas y qué tipo de datos se pueden almacenar. Los datos son de interés para el usuario final, el metadato es de interés para los programas que tienen que manejar estos datos. Sin embargo, el rol que cumple el metadato en un entorno de almacén de datos es muy diferente al rol que cumple en los ambientes operacionales. En el ámbito de los data warehouse el metadato juega un papel fundamental, su función consiste en recoger todas las definiciones de la organización y el concepto de los datos en el almacén de datos, debe contener toda la información concerniente a:

Tablas
Columnas de tablas
Relaciones entre tablas
Jerarquías y Dimensiones de datos
Entidades y Relaciones

Editado por:

Griselda Arely Hernández

Lenguaje Unificado de Modelado

Páginas

viernes, 16 de abril de 2010

Tutorial UML

jueves, 15 de abril de 2010

Uml Lenguaje de Modelado

Diagramas de Clases y Procedimientos de UseCase

Diagrama de secuencia.

miércoles, 14 de abril de 2010

Diagramas de Actividad

Workflow