INTERFAZ UNIVERSAL ENTRE UN SISTEMA DE GESTIÓN DE ACTIVOS ... · industrial (activos industriales) y su uso permite monitorear los costos que genera un activo durante su ciclo de

PROYECTO FIN DE CARRERA

INTERFAZ UNIVERSAL ENTRE UN

SISTEMA DE GESTIÓN DE ACTIVOS Y

UN SISTEMA DE GESTIÓN DE

COMPRAS

AUTOR: JAVIER SÁNCHEZ JIMÉNEZ

MADRID, JUNIO DE 2009

UNIVERSIDAD PONTIFICIA COMILLAS

ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)

INGENIERO SUPERIOR EN INFORMÁTICA

Interfaz Universal entre un sistema de gestión de activos y un sistema de gestión de compras

II


III

Resumen


IV

La distribución de un producto informático para la gestión de activos, como es

Datastream, implica la integración con otros productos informáticos del cliente.

Dicha integración es especialmente importante en el caso de la gestión de compras,

ya que los activos que se gestionan con Datastream son los mismos cuya compra se

gestiona con otros productos informáticos de diferentes suministradores.

Para evitar tener que desarrollar aplicaciones específicas para cada cliente, de forma

que se integre Datastream con el software que dicho cliente tenga para realizar la

gestión de compras, se ha desarrollado en el presente Proyecto Fin de Carrera, una

herramienta, denominada UNIGUI, que permite definir dos modelos de datos (el de

Datastream y el de la otra aplicación) así como un sencillo lenguaje para editar Jobs

de intercambio de información entre ambos paquetes de software.

El objetivo de la herramienta será, por lo tanto, permitir el intercambio de toda la

información asociada a cualquier herramienta del mercado dedicada a la gestión de

compras con una herramienta específica de gestión de activos empresariales

(Datastream), usada actualmente por nuestra empresa.

La herramienta también ofrecerá la posibilidad de gestionar el mantenimiento de

todos los activos almacenados, centralizando por tanto este proceso en un solo

sistema. Las empresas participantes, por tanto, dejarán de realizar esta tarea.


V

Existen dos tipos de usuarios que tendrán distintas funciones dentro del proceso de

gestión. Estos usuarios son los clientes de cada empresa participante y el

administrador. Cada uno de ellos contará con unas funciones específicas dentro del

sistema.

El ciclo de vida del proyecto se basa en un modelo lineal o en cascada. Cada etapa

del proyecto no comienza hasta que la anterior etapa se haya finalizado por

completo, lo cual es idóneo para un proyecto de estas características.

En resumen, el sistema permitirá la posible comunicación y operabilidad entre

diferentes herramientas de gestión de activos y de compras de forma totalmente

transparente para las empresas participantes, y usando toda la información implicada

en este proceso proporcionará información de valor derivada de ésta.


VI

Abstract


VII

The distribution of a computer science product for the management of assets, as it is

Datastream, implies the total integration with other computer science products of the

client.

This integration is specially important in the case of the management of purchases,

since the assets that are managed with Datastream are such whose purchase is

managed with other computer science products of different suppliers.

In order to avoid to have to develop specific applications for each client, making

possible that Datastream could be integrated with the software that this client

possesses to carry out the management of purchases, in the present Project has been

developed a tool, denominated UNIGUI, that allows to define two data models (the

one of Datastream and the one of the other application) as well as a simple language

to publish Jobs of exchange of information between both software packages.

The objective of the tool will be, therefore, to allow the interchange of all the

information associated to any tool of the market dedicated to the management of

purchases with a specific tool of management of enterprise assets (Datastream), used

at the moment by our company.

The tool also will offer the possibility of managing the maintenance of all the stored

assets, centralizing therefore this process in a single system. The participant

companies, therefore, will let make this task.


VIII

Two types of users exist who will have different functions within the management

process. These users are clients of each participant company and administrator. Each

one of them will count on specific functions within the system.

The cycle of life of the project is based on a linear model, also known as cascade.

Each stage of the project does not begin until the previous stage has been finalized

completely, which is suitable for a project of these characteristics.

In summary, the system will allow the possible communication and operation

between different tools from management of assets and purchases with total

transparency for the participant companies, and using all the information implied in

this process, it will provide information of value derived from this one.


IX

ÍNDICE

PARTE I. MEMORIA…………………………………………………………….. 1

1. INTRODUCCIÓN ……...……………………………………………………... 1

1.1. PLANTEAMIENTO DEL PROYECTO ……..…….…………………………..… 1

1.2. ESTADO DEL ARTE …………….…………..…………………........................... 3

1.2.1. SISTEMAS DE GESTIÓN DE ACTIVOS ………..….………………....... 3

1.2.2. SISTEMAS DE GESTIÓN DE COMPRAS ……..……............................. 39

2. METODOLOGÍA ...………………………………………………………. 59

2.1. ETAPAS DE DESARROLLO .....……………………………………………. 62

2.1.1. IDENTIFICACIÓN DE NECESIDADES (IDN) ....……………............ 62

2.1.2. ANÁLISIS DE REQUISITOS (ARQ) ......………………………. ……. 63

2.1.3. ESTUDIO DE LA ARQUITECTURA (EAQ) ...………………............. 65

2.1.4. DISEÑO EXTERNO (DEX) …………………………………………... 67

2.1.5. DISEÑO INTERNO (DIN) ………...………………………………….. 68

2.1.6. PROGRAMACIÓN (PRO) ………………………………………..…… 70

2.1.7. PRUEBAS DEL SISTEMA (PRU) ……………………………………. 72

2.1.8. IMPLANTACIÓN (IMP) ………………………………………............ 73

2.1.9. MANTENIMIENTO (MAN) …………………………………………... 73

2.2. ESTRUCTURA DE DIVISIÓN DEL TRABAJO ……………….….……….. 74

3. IDENTIFICACIÓN DE NECESIDADES …………………………............. 77

3.1. INTRODUCCIÓN ……………………………………………………………. 77

3.2. OBJETIVOS DEL SISTEMA ………………………………………………... 78

3.3. ALCANCE DEL SISTEMA …………………………………………………. 80


X

3.4. TIPOLOGÍA DE USUARIOS ……………………………………………….. 81

3.5. RESTRICCIONES …………………………………………………………… 82

3.6. ORGANIZACIÓN DEL PROYECTO ………………………………………. 82

3.7. ANTECEDENTES DEL SISTEMA …………………………………………. 83

3.8. PLANIFICACIÓN …………………………………………………………… 84

4. ANÁLISIS DE REQUISITOS ……………………………………………… 86

4.1. INTRODUCCIÓN ……………………………………………………………. 86

4.2. DESCRIPCIÓN DE UN PROCESO DE ORDEN DE COMPRA …………… 87

4.3. LISTA DE REQUISITOS ……………………………………………………. 89

4.4. CARACTERÍSTICAS DE CADA REQUISITO …………………………….. 90

4.5. DIAGRAMA DE CONTEXTO …………………………………………….. 100

4.6. DIAGRAMA DE PRIMER NIVEL ………………………………………… 102

4.7. DIAGRAMAS DE SEGUNDO NIVEL ……………………………………. 106

4.8. MODELO CONCEPTUAL DE DATOS …………………………………… 114

5. ESTUDIO DE LA ARQUITECTURA …………………………………… 124

5.1. INTRODUCCIÓN …………………………………………………………... 124

5.2. ARQUITECTURA SOFTWARE …………………………………………… 124

5.3. ARQUITECTURA HARDWARE ………………………………………….. 126

6. DISEÑO …………………………………………………………………….. 128

6.1. INTRODUCCIÓN …………………………………………………….…….. 128

6.2. MODELO FÍSICO DE PROCESOS ………………………………….…….. 128

6.2.1. PSEUDOCÓDIGO proceso GESTIÓN

ENTIDADES DS (PFC_PRO_01) ….………………………….…..… 129


ATRIBUTOS DS (PFC_PRO_02) ….……………………………...… 129


XI


ENTIDADES SGC (PFC_PRO_03) ………………………………….. 130


ATRIBUTOS SGC (PFC_PRO_04) …...…………………………...… 131

6.2.5. PSEUDOCÓDIGO proceso GESTIÓN CASOS (PFC_PRO_05) …… 132

6.2.6. PSEUDOCÓDIGO proceso GESTIÓN JOBS (PFC_PRO_06) ……… 133

6.2.7. PSEUDOCÓDIGO proceso GESTIÓN TAREAS (PFC_PRO_07) …. 134


FRECUENCIAS (PFC_PRO_08) …………………………………….. 135

6.2.9. PSEUDOCÓDIGO proceso GESTIÓN TIPOS DE

TAREAS (PFC_PRO_09) ……………………………………………. 136


EMPRESAS - SISTEMAS (PFC_PRO_10)…………………………... 137

6.2.11. PSEUDOCÓDIGO GESTIÓN DE USUARIOS (PFC_PRO_11)……. 137

6.3. MODELO FÍSICO DE LA BASE DE DATOS …………………………….. 138

7. PROGRAMACIÓN .……………………………………………………….. 141

7.1. INTRODUCCIÓN ………………………………………………………….. 141

7.2. DISEÑO DEL INTERFAZ DE USUARIO ………………………………… 142

7.2.1. CRITERIOS …………………………………………………………... 142

7.2.2. DISEÑO DE FORMULARIOS ………………………………………. 145

7.2.3. MANUAL DE USUARIO ……………………………………………. 147


XII

8. PRUEBAS …………………………………………………………………... 149

8.1. INTRODUCCIÓN …………………………………………………………... 149

8.2. PRUEBAS UNITARIAS ……………………………………………………. 150

8.3. PRUEBAS FUNCIONALES ………………………………………………... 150

8.4. PRUEBAS DE SEGURIDAD …………………………………………......... 151

8.5. PRUEBAS DE ACEPTACIÓN DEL USUARIO …………………………... 151

8.6. PRUEBAS DE REGRESIÓN ……………………………………………….. 151

9. IMPLANTACIÓN …………………………………………………………. 153

10. PRESUPUESTO ………………………………...…………………………. 155

10.1. INTRODUCCIÓN ………………………………………………………….. 155

10.2. DIVISIÓN DE COSTES .…………………………………………………… 155

11. CONCLUSIONES …………………………………………………………. 158

12. BIBLIOGRAFÍA ………………………………………………………...… 160

PARTE II. ANEXOS……………………………………………………………. 164

ANEXO A. MANUAL DE USUARIO…………………………………………. 164

ANEXO B. MANUAL DE IMPRESIÓN Y CREACIÓN DE FICHEROS...... 181

PARTE I: MEMORIA

1.1.1.1. Introducción


2

1. INTRODUCCIÓN

1.1. PLANTEAMIENTO DEL PROYECTO

El proyecto presente consiste en el desarrollo de un interfaz universal, denominada

‘UNIGUI’, que permita capturar información en tiempo real entre un sistema de Gestión

de Activos (DATASTREAM en nuestro caso) y un sistema de Gestión de Compras

cualquiera. El objetivo principal es construir una herramienta que permita total

comunicación y operabilidad entre ambos sistemas de forma totalmente transparente.

Nuestra empresa (EMPRESARIOS AGRUPADOS) cuenta actualmente con la herramienta

DATASTREAM para realizar la gestión de todos sus activos, siendo uno de los principales

proveedores de esta herramienta tanto en España como en todos los países en los que lleva

a cabo proyectos. Por ello, se tiene mucho interés en el desarrollo del proyecto ya que

supondría el origen de la compatibilidad de sistemas con clientes que cuentan con gestores

de compras propios.

Se implementarán un conjunto de protocolos y estándares para permitir el

intercambio de datos entre ambos sistemas usando un estándar universal para

almacenamiento de datos, en principio basado en MS Access para garantizar la

viabilidad de intercambio de información entre ambos sistemas. El proyecto incluye

tanto el análisis, como el diseño, la implementación y la documentación del interfaz.


3

1.2. ESTADO DEL ARTE

1.2.1. SISTEMAS DE GESTIÓN DE ACTIVOS

Un Sistema de Gestión de Activos (‘SGA’ en adelante) se define como un conjunto

de herramientas informáticas que debidamente aplicadas permiten la optimización

del desempeño de una empresa o planta industrial. Este sistema actúa sobre los

activos de la empresa que están involucrados directamente en la producción

industrial (activos industriales) y su uso permite monitorear los costos que genera un

activo durante su ciclo de vida y disminuir las interrupciones imprevistas de

funcionamiento. La gestión de activos se encarga, por lo tanto, de asegurar que todos

los equipos y componentes en los que se ha invertido dinero realicen su trabajo de la

forma más eficiente posible, y, a su vez, dar la posibilidad al usuario de estar

informado de forma continua de lo que sucede a medida que transcurre el tiempo,

con el fin de tomar decisiones de forma documentada.

Desde el día en que se instalan los equipos de una planta, estos comienzan una

paulatina degradación, de la que no se suele tener constancia hasta que algo grave

ocurre, provocando que el proceso deje de ser completamente fiable. Por este motivo,

se marca como objetivo interceptar el avance de la mencionada degradación para no

llegar a ésta situación.

Un SGA es parte activa de la Gestión de Mantenimiento moderna y permite obtener

información importante del desempeño de los activos en el tiempo. En concreto, el


4

SGA nos entregará información de los activos de planta, alertas y alarmas de

mantenimiento, monitoreo del ciclo de vida del activo, indicadores de gestión para la

medición de estrategias de la compañía y mejoras en la seguridad industrial.

La gerencia de Mantenimiento debe decidir la implementación de todas aquellas

actividades, prácticas sistemáticas y herramientas que ayuden a lograr el mejor

desempeño posible para los activos industriales. Su principal utilidad consiste en el

descubrimiento de actividades de mantenimiento que no estén dando el resultado

esperado, que estén consumiendo más recursos de lo debido o bien procesos de

trabajo que deban ser modificados.

¿Qué nos aportan estas tecnologías?

Dependiendo del proveedor con el que decidamos implementar estas soluciones, un

SGA de una empresa incorpora en una base de datos digital toda la información de

funcionamiento, especificaciones y descripción de los equipos. Esto permite realizar

las labores de mantenimiento en menor tiempo, aumentando la eficiencia y

finalmente reduciendo los costos.

Está demostrado que un SGA también puede ser un excelente aliado de los

ingenieros que están incorporando la filosofía del mantenimiento predictivo, gracias

a la capacidad que estos sistemas tienen para comunicarse con los equipos de campo.


5

1.2.1.1. COMPONENTES DE UN SISTEMA DE GESTIÓN DE ACTIVOS

Un SGA debe incluir, entre otros, los siguientes módulos:

� Inventario de activos y componentes.

� Costos asociados.

� Almacenes y repuestos.

� Personal.

� Compras.

� Mantenimiento Preventivo.

� Mantenimiento Correctivo.

� Mantenimiento Modificativo.

• Inventario de activos y componentes.

Su propósito consiste en la recopilación de información relevante que describa de

manera completa los activos de tal forma que al realizar una consulta sobre

cualquiera de ellos, esta refleje la condición real del bien en cuestión.

No todos los activos son iguales. Se debe de considerar el contar con el soporte

necesario especializado al momento de realizar un inventario. No es lo mismo tomar

datos físicos de los activos de una Universidad, que básicamente lo que

encontraríamos sería mobiliario y equipo de oficina, que realizar el inventario de una

planta química, por ejemplo; las características físicas que describen a uno y otro

activo son totalmente de naturaleza distinta.


6

El inventario tendrá mejor calidad de información si lo realiza conforme al criterio de

la Unidad Mínima Indivisible (UMI). Se entiende como UMI aquella unidad de

maquinaria integrada por el equipo propiamente dicho, accionado por un

determinado mecanismo o transmisión, seguido, en su caso, de equipos o

instalaciones menores, así como su ingeniería, directamente relacionados con este

equipo, como son: instalaciones de ingeniería civil, mecánica, eléctrica, bombas,

válvulas, tuberías, instrumentos, etc., y que por lo tanto definan una capacidad

productiva.

La información relativa a activos se resume a continuación:

� Identificación del activo: código, descripción, estado (Instalado, en

reparación, etc.) y organización.

� Detalles del equipo: clase, categoría, costo, fecha inicio, valor y criticidad.

� Detalles de la instalación: costo de reparaciones necesarias y valor de

reemplazo.

� Detalles de rastreo: fabricante, nº de serie y modelo.

� Asociación de piezas: pieza, almacén, estante y lote.

� Jerarquía: activo padre, dependencia, ubicación y posición.


7

• Costos asociados

Su propósito consiste en la recopilación de información relativa a operaciones o

tareas en las que interviene un activo, lo cual se consigue asociando a cada orden de

trabajo todos los activos que intervienen en ella.

La información relativa a costos asociados se resume a continuación:

� Costos: código de orden de trabajo, tipo, organización, moneda, costo de

materiales, costo de mano de obra, costo de herramientas, costo total, horas

trabajadas, estado, fecha inicial y descripción.

• Almacenes y repuestos.

El módulo de gestión de almacén nos permite llevar a cabo las distintas tareas

relacionadas con el mantenimiento de los stocks de repuestos y herramientas, es

decir, que no están funcionando actualmente en la empresa, así como la gestión de

las órdenes de compra (OC’s). A parte, se debe contar con la correspondiente

Gestión de Control especificando para cada equipo o repuesto sus datos de interés:

identificador único, cantidad de stock, control stock (quién, cuando, salida/entrada),

pedidos, etc.

Las tareas que podemos llevar a cabo con este módulo son:

� Mantenimientos de fichas de repuestos y herramientas.

� Mantenimiento de fichas de proveedores.


8

� Entradas y salidas de almacén.

� Control de stocks mínimos.

� Gestión de órdenes de compra.

La información relativa a almacenes se resume a continuación:

� Identificación: código almacén, descripción, clase y organización.

� Detalles del almacén: Ubicación, grupo, almacén padre, plazo de entrega

(días), impresora de etiquetas y plantillas para etiquetas (despacho, recibo

OC, recibo entre almacenes, etc.).

La información relativa a repuestos, es decir, stock almacenado, se resume a

continuación:

� Piezas: código, descripción, organización, estante, lote, cantidad almacenada

y cantidad para reparación.

• Personal.

Su propósito consiste en la recopilación de información concerniente a los

trabajadores de la empresa, los cuales son los encargados de realizar tareas y

servicios (almacenados a su vez en forma de OT’s, revisiones, etc.).

La información relativa a personal se resume a continuación:


9

� Identificación: código de trabajador, descripción y organización.

� Detalles del empleado: taller, clase, ocupación, teléfono, usuario asociado y

dirección de correo.

• Compras.

En el módulo de compras se gestiona todo el proceso de adquisición de materiales y

servicios, desde la solicitud de compra que expresa la necesidad, pasando por el

circuito de autorizaciones, hasta la emisión del pedido generada por la OC.

Asimismo, se controla la recepción de materiales mediante la entrada de los

correspondientes albaranes, y el proceso finaliza con la aceptación de facturas.

Un esquema básico de gestión de compras se muestra en el siguiente gráfico:

Esquema Básico de Gestión de Compras.


10

La información relativa a compras (OC’s) se resume a continuación:

� Identificación: código OC, descripción, organización, fecha de la orden,

autorizador y fecha de autorización.

� Detalles de OC: estado, almacén, creador, fecha vencimiento, comprador,

clase y dirección de entrega alternativa.

� Detalles de proveedores: código, moneda, tasa de cambio y plazo de entrega

(días).

� Totales de orden de compra: impuesto total, descuento total, valor total de las

piezas, valor total del servicio, valor total de la OC.

� Términos de OC: método de envío, condiciones de pago, condiciones de

flete, método de pago y tarjeta de crédito.

• Mantenimiento Preventivo.

El mantenimiento de los equipos es esencial para asegurar una operación adecuada

de los mismos. La finalidad del mantenimiento preventivo es encontrar y corregir los

problemas en maquinaria antes de que estos provoquen fallos. El mantenimiento

preventivo puede ser definido como una lista completa de actividades, todas ellas

realizadas por usuarios, operadores, y mantenimiento para asegurar el correcto

funcionamiento de la planta, edificios, máquinas, equipos, vehículos, etc.

Realizar mantenimiento preventivo en los activos de una empresa de manera

organizada y proactiva genera muchos beneficios, como por ejemplo:


11

� Aumento de la disponibilidad: a través del aumento del tiempo entre

incidencias (fallos) y la disminución del tiempo medio de reparaciones.

� Aumento de la productividad: por medio de una mejor planificación y

organización.

� Reducción de costes derivados: debido a una mejor planificación, un menor

número de solicitudes de servicios de emergencia y una menor cantidad de

picos de servicio.

� Reducción de inventarios: a través del establecimiento de planes de trabajo

que identifican con exactitud cuales son los materiales requeridos y cuando

serán necesarios para su aplicación en órdenes de trabajo.

� Reducción de compra de materiales: debido a las mejores prácticas y

decisiones de compra y a un menor número de compras de emergencia.

� Reducción de consumo de energía eléctrica: a través de la implementación de

rutas de inspección de puntos donde hay mayores pérdidas de energía.


12

• Mantenimiento Correctivo.

También denominado mantenimiento reactivo, es aquel trabajo que involucra una

cantidad determinada de tareas de reparación no programadas con el objetivo de

restaurar la función de un activo una vez producido un paro imprevisto. Las causas

que pueden originar un paro imprevisto se deben a desperfectos no detectados

durante las inspecciones predictivas, a errores operacionales, a la ausencia de tareas

de mantenimiento y, a requerimientos de producción que generan políticas como la

de "repara cuando falle".

Existen desventajas cuando dejamos trabajar una máquina hasta la condición de

reparar cuando falle, ya que generalmente los costos por impacto total son mayores

que si se hubiera inspeccionado y realizado las tareas de mantenimiento adecuadas

que mitigaran o eliminaran la situación de fallo en la máquina.

Diferencia costo / desempeño de una estrategia de mantenimiento preventivo y un mantenimiento correctivo.


13

• Mantenimiento Modificativo.

Tiene por objeto cambiar, variar o modificar las características propias del equipo,

para realizar un mejor mantenimiento, incrementar la producción o cualquier tipo de

mejora que aumente su calidad. Las causas que motivan estos cambios pueden ser de

cualquier tipo, tales como obras, cambio de usos o de ubicación, políticas, nuevas

normativas, etc.

El tamaño de una instalación y el número de usuarios son directamente

proporcionales a las necesidades de este mantenimiento.


14

1.2.1.2. RELACIÓN ENTRE LOS DIFERENTES MÓDULOS DE UN

SISTEMA DE GESTIÓN DE ACTIVOS

Una vez definidos los módulos que deben componer un SGA, el siguiente paso es

definir cómo se relacionan entre sí. Antes de nada, se van a definir las características

más importantes a cumplir por todos los módulos.

La principal característica que cumplen todos los módulos es que forman un sistema

integrado. En general, podemos definir un sistema integrado como un sistema de

propósito especial diseñado para llevar a cabo una función específica. Un sistema

integrado lleva a cabo una o unas pocas tareas predefinidas, generalmente con

requerimientos muy específicos, y a menudo incluye hardware específico para cada

tarea, y partes mecánicas que no se encuentran en sistemas de propósito general.

Como el sistema está dedicado a una tarea específica, los ingenieros de diseño

pueden optimizarlo, reduciendo su tamaño y costes. En la figura siguiente se muestra

un ejemplo de sistema integrado:


15

Otra característica importante de los SGA es su interfaz, es decir, la forma en la que

se accede a los datos. El interfaz de un SGA suele estar basado en estándares que

permiten cierta homogeneización del uso por parte de los usuarios.

En el caso de los SGA, ésta estandarización se pone de manifiesto en aspectos

relacionados con la propia funcionalidad de la herramienta, tales como:

• La gestión de los datos en la pantalla (Creación de registros, borrado,

modificación, duplicado, etc.).

• Desplazamiento en los registros del panel (Botones ‘Siguiente’ y ‘Anterior’,

etc.).

• Realización de consultas (por cualquier columna, ordenación, agrupadas,

etc.).

• Acceso a otras pantallas relacionadas (arrastrando datos).

• Acceso a otras pantallas no relacionadas (sin arrastrar datos). Teniendo en

cuenta la propiedad de Integración del Sistema, se debe poder llegar de

cualquier pantalla a cualquier otra.

• Ayuda en línea.

• Opciones de navegación (‘Aceptar’, ‘Cancelar’ y ‘Salir’). Las opciones

‘Aceptar’ y ‘Salir’ implican la gestión correspondiente con la Base de Datos.


16

Es muy importante que los SGA integren el control de los flujos de trabajo. Estas

aplicaciones automatizan la secuencia de acciones en la ejecución de cada proceso,

permiten realizar un seguimiento de cada etapa del mismo y aportan las herramientas

necesarias para su control o gestión del flujo de trabajo. Esta integración, en el caso

de los SGA, es posible mediante la estructura de la propia aplicación, es decir, la

forma en que se distribuyen y se recorren los paneles y, con ello, la forma en la que

se permite a los usuarios realizar las diferentes operaciones posibles.

Todos los módulos que componen el sistema están relacionados entre sí. El módulo

más importante, como es lógico, será el formado por todos los activos o elementos

que forman parte de la empresa; el resto de módulos derivan a partir de éste, por lo

que la relación entre todos los módulos está asegurada. Veamos un ejemplo

perfectamente válido de un esquema de división de un SGA:


17

Subsistema Activos (Rojo):

• Activos. Los recursos son uno de los activos más valiosos de una empresa. La

planificación de la capacidad de recursos, el control de la disponibilidad de

los recursos y el seguimiento de los costes sólo son algunas de las

necesidades de gestión que pueden demandar atención constante. Una

supervisión precisa del coste y el uso de los recursos permite mejorar la

gestión de recursos y tener un mejor conocimiento de la capacidad global de

recursos de la empresa. Éste área permite, a su vez, utilizar modelos de

fijación de precios flexibles, lo que facilita la facturación a través del área de

la aplicación ventas y cobros o el registro de los costes en proyectos.

Las relaciones del módulo de activos se muestran en el siguiente gráfico:


18

• Mantenimiento. Para ser competitivos existen algunos factores claves como

es la Calidad, por la que se debe brindar a nuestros clientes los productos y

servicios que satisfagan sus necesidades, pero también debemos entre estas

necesidades, satisfacer el precio que los clientes están dispuestos a pagar por

el producto o servicio que le brindamos así como el tiempo que tardamos en

ofrecérselo.

Estos factores debemos cumplirlos sin descuidar las exigencias en temas de

Seguridad y Medio Ambiente que hoy día son tan claves para la

competitividad como los primeros, dada la toma de conciencia que ha habido

en estos temas.

Pero la calidad y la productividad, el respeto a la seguridad y al medio

ambiente, no son cosas que sea suficiente hacerlas durante un día o dos, ni

durante un mes o dos, debemos lograrlas siempre y para ello necesitamos el

aporte del factor clave de la competitividad: la confiabilidad.

La confiabilidad es lo que me permite asegurar los cuatro primeros factores

claves a lo largo del tiempo y por lo tanto asegurar la competitividad.

Obtener Confiabilidad solo es posible con el correcto Mantenimiento.

Es entonces por la incidencia que el mantenimiento tiene en los factores

claves, confiabilidad, seguridad, medio ambiente, calidad y productividad, así


19

como en otros no menos importantes como la disponibilidad, el costo-eficacia

y el uso racional de la energía, que se lo ubica actualmente en los primeros

planos de la dirección empresarial.

Hoy en día existen muchas técnicas o “Herramientas” a aplicar en lo referente

al mantenimiento, entre las cuales destacan:

� OIM – Optimización Integral de Mantenimiento.

� TQM – Gestión Total de la Calidad.

� TPM – Mantenimiento Productivo Total.

� LCC – Costo del Ciclo de Vida.

� Gestión y Evaluación de Riesgos.

� Monitoreo de la Condición y Análisis Predictivo.

� Gestión por Indicadores.

� Sistemas Expertos.


20

Los procesos de mantenimiento se asocian de manera unívoca a cada activo,

por lo que, a su vez, estarán asociados a las distintas piezas que lo forman.

Esta relación quedará reflejada perfectamente en la base de datos, con las

correspondientes relaciones entre las tablas de Tipos de Mantenimientos-

Piezas-Activos.

• Almacenes. La gestión de almacenes implica una serie de decisiones básicas:

� Decidir el número de almacenes y su tamaño.

� Elegir las localizaciones para los almacenes.

� El tipo y nivel de mecanización. La primera decisión es si utilizar

almacenes en propiedad, alquilados o almacenes ajenos. Algunos

productos requieren almacenes especializados como, por ejemplo, los

productos congelados. Otra decisión fundamental es el nivel de

automatización de los almacenes. Actualmente podemos disponer de

almacenes totalmente automatizados, aunque en ocasiones resulta más

rentable un nivel intermedio de automatización.

� Establecer la organización y los procedimientos concretos de gestión.

� El número de almacenes depende de varios factores. Un factor

fundamental es el coste y la duración de los transportes. Otros factores


21

fundamentales se relacionan con las características del producto y del

mercado.

� La localización de los almacenes se decide analizando los costes de los

diversos emplazamientos alternativos. Y teniendo como restricción

fundamental el tiempo máximo de respuesta a los pedidos de los clientes.

� Establecer el sistema de organización. Se hace preciso decidir el número

de empleados de los almacenes, seleccionarlos, formarlos y asignarles

responsabilidades. Un aspecto importante en los almacenes es la

distribución en planta. Es decir, como se reparten por la superficie del

almacén los distintos productos.

Dentro de los almacenes será preciso determinar como se moverán los

productos, la información y las personas o medios mecánicos. Las

distintas etapas o tareas que se desarrollarán desde la recepción de los

productos en el almacén hasta su salida.

Se deben definir de forma precisa los procedimientos a seguir, es decir, cómo

se realizará el trabajo, establecer las distintas tareas de cada proceso y cómo

se realizarán.

Las relaciones de la tabla almacenes se muestran en el siguiente gráfico:


22

• Operación. Comprende todas las acciones que pueden ser llevadas a cabo

por la empresa tales como adquisición de herramientas, realización de

técnicas de análisis y control para gestión con eficiencia de todos los

recursos, planificación y optimización estratégica de todos los procesos

operativos (productivos y logísticos), análisis del impacto de los conceptos de

calidad, medioambiente y seguridad laboral en la gestión de operaciones, etc.

En nuestro caso, las acciones posibles tienen relación con:

� Recepciones de reparaciones internas.

� Despacho/Devolución de piezas.

� Recibo sin OC.


23

� Recibo con OC.

� Inspecciones.

� Inventario físico.

� Envíos entre almacenes.

� Recepción entre almacenes.

� Devoluciones al proveedor.

• Gestión de Diseño. Ante una oferta amplia de productos, el diseño permite la

diferenciación del producto y la introducción de valores simbólicos,

funcionales y estéticos que justifican frente al usuario los mayores precios.

La competitividad de una empresa está definida por la naturaleza de su

relación con el mercado a través del producto. Esta relación permite la

identificación de tres elementos clave: empresa, producto y mercado, que en

su intercalación mutua determinan la competitividad de la empresa. Desde el

punto de vista de la empresa podemos considerar al diseño como un

instrumento de gestión dirigido a incrementar su competitividad mediante la

concepción de nuevos productos.

El diseño actúa sobre el producto aportándole las propiedades que le permiten

satisfacer las necesidades que el mercado demanda. A su vez, permite

diferenciar el producto dotándole de una imagen adaptada a los deseos del

mercado.


24

Podemos definir la gestión del diseño como el conjunto de técnicas de gestión

empresarial dirigidas a maximizar, al menor coste posible, la competitividad

que obtiene la empresa por la incorporación y utilización del diseño

industrial.

El diseño innova en las siguientes áreas fundamentales que afectan a la

competitividad de los productos y de las empresas:

� Introduce calidad y estética en el producto contribuyendo a su

diferenciación.

� Racionaliza los procesos productivos reduciendo los costes y

colaborando en la búsqueda del liderazgo de costes.

� Mejora las prestaciones del producto aumentando su valor de uso.

� Mejora la comunicación e imagen de la empresa al actuar sobre sus

comunicaciones externas e internas.

Las relaciones de la Gestión de Diseño se muestran en el siguiente gráfico:


25

• Repuestos. El objetivo fundamental de los almacenes de repuestos es dar

soporte a las tareas de mantenimiento, tanto a aquellas tareas planeadas como

aquellas no planeadas. Por ello, cobra sentido una política de inventario cuya

demanda de repuestos tenga su origen en: mantenimiento y operaciones.

Muchas técnicas tradicionalmente utilizadas para optimizar las tenencias de

inventarios de repuestos fracasan justamente por olvidar al mantenimiento y

las operaciones, origen de la demanda de repuestos. Esto no es extraño dado

que justamente muchas de estas técnicas tradicionales se desarrollaron no

para el manejo de inventarios de repuestos de ingeniería, sino para el manejo

de stocks de producción.

El aumento de la automatización industrial y el incremento de la complejidad

de los activos físicos hace que el número y la variedad de fallos posibles haya


26

aumentado aceleradamente en los últimos años, por lo que a la par ha

aumentado el número de repuestos necesarios para reparar esos fallos. A su

vez, como la producción depende cada vez más del correcto funcionamiento

de activos físicos, las consecuencias de la indisponibilidad de estos activos

son cada vez peores, por lo que la indisponibilidad de planta por espera de

repuestos se considera inadmisible. Esto genera una fuerte presión por

aumentar los niveles de inventario de repuestos.

La combinación de estos dos factores ha generado un aumento alarmante en

el valor del stock de repuestos. De representar un costo inmovilizado

prácticamente insignificante se ha transformado en una importantísima

inversión de capital, muchas veces de varios millones de euros. Esto ha

despertado el interés de la gerencia por reducir este capital inmovilizado,

adoptando en muchos casos políticas irracionales ("todo repuesto no utilizado

durante 2 años o más es retirado de stock"), acarreando en muchos casos

grandes pérdidas económicas por no tener los repuestos disponibles cuando

son requeridos. Como si esto fuera poco, la tendencia de la industria a adoptar

métodos de producción just in time, y la tendencia a abandonar el

mantenimiento preventivo para adoptar estrategias de mantenimiento

predictivo, han dificultado aún más la determinación de políticas de repuesto

adecuadas.


27

Subsistema Trabajo (Azul):

• Gestión documental. La gestión documental consiste en el uso de tecnología

y procedimientos que permiten la gestión y el acceso unificado a información

generada en la organización:

� Al personal de la empresa.

� A clientes y proveedores.

Los beneficios clave de estas prácticas son:

� Establecer un nuevo espacio de trabajo compartido empresa / cliente.

� Aumentar el valor de la información de la empresa.

� Evitar la duplicación de tareas así como los tiempos de búsqueda de

información interna.

� Incrementar la calidad de servicio y la productividad.

Puntos clave de la implantación de una solución de Gestión Documental:

� Grupos y Roles. Acceso selectivo a la información.

� Workflow. Procesos online.

� Acceso descentralizado a la información.

� Punto único de Acceso. Múltiples fuentes de información.

� Detección de patrones de comportamiento. Calidad del servicio.

� La oficina sin papel.

� Compartición de Información. Empresa - Departamentos – Clientes.


28

• Gestión del Trabajo (Workflow). Workflow se refiere al flujo de trabajo a

seguir para la consecución de una tarea o trabajo predeterminado. Se define

como un sistema de secuencia de tareas de un proceso de negocio. Organiza y

controla tareas, recursos y reglas necesarias para completar el proceso de

negocio.

Las nuevas tendencias, a la hora de regular las organizaciones, hacen del

Workflow una herramienta clave para lograr mayor agilidad y aumentar la

descentralización de las actividades administrativas y comerciales.

La evolución de Workflow consiste en buscar la máxima automatización de

los procesos de trabajo y el control total de las diferentes etapas, durante las

cuales los documentos, la información o las tareas pasan de un participante a

otro, según unas normas o procedimientos previamente definidos.

Un sistema Workflow se caracteriza, principalmente, por una adecuada

integración con sistemas de información actuales: bases de datos, gestión

documental, mensajería, ERP, etc., permitiendo la ampliación de un

Workflow, de un simple proceso a la integración de varios procesos de

negocio interrelacionados.

Las funciones más importantes de este módulo tienen que ver con:

� Inspecciones.

� Controles de revisión.


29

� Solicitudes de servicio.

� Registro de mano de obra de los empleados.

� Resultados de calibración.

� Solicitudes de planificación de capital.

� Órdenes de Trabajo.

� Solicitudes de trabajo.

� Proyectos.

• Personal (Empleados). Hay algunas habilidades que son necesarias para

tener éxito en la gestión de los empleados de una empresa:

� Conocer y dominar las normas reguladoras en materia laboral para poder

tener la capacidad de actuación en función de la situación que se tenga

que afrontar.

� Proporcionar las capacidades y habilidades necesarias para aplicarlas en

la gestión de personal y las relaciones laborales de la organización.

� Dotar a los participantes de una formación sólida y especializada en la

Gestión de Personal y Relaciones Laborales para poder actuar

correctamente y afrontar los problemas que se puedan plantear en el día a

día de la realidad empresarial de manera que puedan responsabilizarse,

tanto dentro de una empresa como en calidad de asesores.


30

Las principales relaciones del módulo de trabajadores se muestran en el

siguiente gráfico:

• Seguridad. Este módulo es uno de los más delicados dentro de un SGA. La

razón es que es el encargado de gestionar, a parte de los propios parámetros

de configuración e instalación de todo el sistema, elementos tan importantes

como períodos de cierre, seguridad de las organizaciones, configuración de

las propias organizaciones y su definición, definición de grupos de usuarios

de la aplicación así como su configuración, gestión de permisos, etc.


31

• Formación. El desarrollo de políticas de formación en el seno de las

empresas, es una actividad que se ha convertido en estos últimos años en uno

de los pilares sobre el que se asienta la competitividad de las mismas. Este

hecho viene motivado por la importancia que se concede en las

organizaciones a los activos intangibles, buena parte de los cuales están

conformados por el capital humano. La necesidad de buscar soluciones, por

una parte a la falta de cualificaciones que el mercado laboral proporciona al

entorno empresarial, así como por la insuficiencia o desorientación de los

esfuerzos que en esta materia se están realizando por parte de las instituciones

públicas, conducen a que las empresas se vean embarcadas en la tarea de

prestar especial atención al reciclaje profesional de sus trabajadores para

atender tanto a la introducción de nuevas tecnologías, como a la

reestructuración organizativa que se lleva a cabo en estas.

La gestión de las actividades formativas en las empresas es un elemento

prioritario a considerar, sobre todo en aquellos sectores que se encuentran en

un momento de transformación estructural en sus procesos productivos.

Subsistema Finanzas (Verde):

• Archivo. La implantación de un sistema de gestión documental (SGD) es un

elemento clave en la actividad de la empresa, tanto en grandes organizaciones

como en la pequeña y mediana empresa. Las empresas deben contemplar los

sistemas de gestión documental como una tecnología que contribuye a


32

mejorar los procesos administrativos en los que la información se encuentra

en soporte documental, o bien es información estructurada.

El concepto clave para el análisis de los SGD es el de documento o archivo:

� Un documento de archivo es el testimonio material de un hecho o acto

realizado en el ejercicio de sus funciones por personas físicas o

jurídicas, públicas o privadas, de acuerdo con unas características de

tipo material y formal.

� Documento es toda información fijada materialmente sobre un soporte.

Los SGD son los sistemas encargados de gestionar y tratar en todos sus

aspectos la información fijada en un soporte.

En un SGA podemos hacer uso de esta gestión para los siguientes

documentos:

� Trabajo (OT’s).

� Compras (OC’s).

� Transacciones de Stock.

� Pistas de Auditorias.

� Registros electrónicos.


33

• Presupuestos. Un presupuesto es un plan integrador y coordinador que

expresa en términos financieros con respecto a las operaciones y recursos que

forman parte de una empresa para un período determinado y bajo ciertas

condiciones, con el fin de lograr los objetivos fijados por la alta gerencia

aplicados a cada centro de responsabilidad de la organización.

El presupuesto tradicional se ha basado en los inputs. En este caso, las

normas y la estandarización de los procesos son el principal foco de atención.

En general se valora el cumplimiento del principio de economía (relación

entre los inputs previstos y los reales). La restricción está en los inputs y, por

tanto, el objeto del control se fija en el cumplimiento de los mismos.

El presupuesto orientado a la producción de bienes y servicios centra la

atención en los productos (outputs). Es importante la relación entre los inputs

y los outputs. En este modelo de presupuestación es importante la

consecución de la máxima eficiencia (relación inputs con outputs, en el

sentido de obtener el máximo output dado un input, o de minimizar los inputs

necesarios para obtener un determinado output).


34

El presupuesto orientado a resultados se basa en aquello que se quiere

obtener y centra la atención en los resultados y en los impactos.

Adicionalmente a los objetivos de economía y de eficiencia, también se

persigue la eficacia (obtención de los objetivos deseados).

En un SGA, las posibilidades de gestión de un presupuesto son las siguientes:

� Información del presupuesto: estructura, descripción, plazo,

organización, padre, tipo de calendario, fecha creación, estado

(aprobado/congelado), valor actual, fecha aprobación y persona

responsable.

� Tipos de calendario del presupuesto (anual, mensual, semestral).

� Grupos de presupuesto.

� Estructuras de presupuesto.

� Plazos de presupuesto.

• Compras. Las empresas comerciales compran productos para venderlos. Por

tanto la partida más importante de sus gastos son las compras. Un

departamento de compras eficiente es esencial para el éxito de cualquier

intermediario. Las tendencias actuales en la gestión de compras son:

� Investigar a los proveedores y buscarlos de forma activa: conseguir los

mejores proveedores ampliando el ámbito de búsqueda. Las grandes

cadenas están localizando proveedores en todo el mundo. Por tanto, no


35

hay que esperar a los proveedores sino desarrollar una activa labor de

búsqueda con criterios amplios.

� Aumentar la información: sobre los productos, costes y proveedores que

maneja el departamento de compras.

� Disminuir el número de proveedores: para reducir costes de compra y de

gestión Por ejemplo, los fabricantes de automóviles han reducido de

forma drástica el número de proveedores.

� Aumentar las compras a cada proveedor: para tener mayor poder de

negociación para ser un comprador importante.

� Cooperar y coordinarse con el proveedor: para disminuir costes. La

coordinación con los suministradores es fundamental para conseguir los

productos en el momento del tiempo oportuno al mínimo coste. Esto

supone una importante reducción de costes que se reparten entre la cadena

y el suministrador. Los distintos sistemas que permiten realizar los

pedidos de productos por ordenador son otra forma de cooperar que

disminuye los costes.

Un SGA, por lo tanto, deberá ofrecer una relación directa del área de

compras con los siguientes módulos:


36

• Contabilidad. La contabilidad es una técnica que se ocupa de registrar,

clasificar y resumir las operaciones mercantiles de un negocio con el fin de

interpretar sus resultados. Por consiguiente, los gerentes o directores a través

de la contabilidad podrán orientarse sobre el curso que siguen sus negocios

mediante datos contables y estadísticos. Estos datos permiten conocer la

estabilidad y solvencia de la compañía, la corriente de cobros y pagos, las

tendencias de las ventas, costos y gastos generales, entre otros. De manera

que se pueda conocer la capacidad financiera de la empresa.

Los objetivos de la contabilidad son: proporcionar información a dueños,

accionistas, bancos y gerentes, con relación a la naturaleza del valor de las

cosas que el negocio deba a terceros. Sin embargo, su primordial objetivo es


37

suministrar información razonada, con base en registros técnicos, de las

operaciones realizadas por un ente privado o público. Para ello deberá

realizar:

� Registros con bases en sistemas y procedimientos técnicos adaptados

a la diversidad de operaciones que pueda realizar un determinado ente.

� Clasificar operaciones registradas como medio para obtener objetivos

propuestos.

� Interpretar los resultados con el fin de dar información detallada y

razonada.

Con relación a la información suministrada, esta deberá cumplir con un

objetivo administrativo y uno financiero:

� Administrativo: ofrecer información a los usuarios internos para

suministrar y facilitar a la administración intrínseca la planificación,

toma de decisiones y control de operaciones. Para ello, comprende

información histórica presente y futura de cada departamento en que

se subdivida la organización de la empresa.

� Financiero: proporcionar información a usuarios externos de las

operaciones realizadas por un ente, fundamentalmente en el pasado

por lo que también se le denomina contabilidad histórica. La


38

contabilidad es de gran importancia porque todas las empresas tienen

la necesidad de llevar un control de sus negociaciones mercantiles y

financieras. Así obtendrá mayor productividad y aprovechamiento de

su patrimonio. Por otra parte, los servicios aportados por la

contabilidad son imprescindibles para obtener información de carácter

legal.

Una aplicación de SGA puede ser perfectamente utilizada para llevar la

contabilidad de la empresa. El motivo es que la herramienta almacena, como

se ha descrito hasta el momento, todos los recursos o activos así como las

operaciones y servicios en los que intervienen éstos, es decir, el archivo

histórico; por ello, se tiene almacenada toda la información valiosa referente a

la contabilidad, la cual puede ser tratada para la elaboración de informes de

distinta índole, perfectamente definibles por la alta gerencia de la empresa. La

elaboración de informes es otra de las funciones vitales de un SGA.


39

1.2.2. SISTEMAS DE GESTIÓN DE COMPRAS

Como se ha visto en el anterior punto, un gestor de activos puede contener un

módulo integrado para Compras (‘SGC’ en adelante); sin embargo, es muy frecuente

que cada empresa tenga un sistema gestor de compras diferente, dedicado a esta tarea

de forma autónoma. Existen multitud de herramientas de este tipo, tales como

Oracle, SAP o NAVISION, por ejemplo. En este punto vamos a realizar un análisis

de la estructura y funcionamiento de un gestor de compras estándar en el que se

puedan englobar todos los sistemas de esta índole.

La gestión de las compras es una tarea asignada al servicio de suministros, cuya

función se asemeja a la de un gran almacén mayorista.

La tarea del servicio de suministros no es solo la de intervenir en la gestión de las

compras, sino que también interviene en la gestión de las existencias de sus

almacenes.

La gestión de las compras lleva asociadas las siguientes tareas:

• Prever y planificar las necesidades. Control de emisión de OCs.

• Identificar y elegir a los posibles proveedores.

• Seleccionar los productos a comprar con criterios de calidad, servicio y

precio.

• Confirmar las entregas de material.

• Realizar los pagos de los productos recibidos.


40

• Enviar los productos al área o departamento que los solicitó.

• Coordinar con el resto de las áreas para identificar las necesidades.

El área de Compras tiene una importancia sustantiva en las empresas, porque es el

área que articula las necesidades de producción de la empresa al proveerla de los

materiales que necesita para cumplir su tarea y porque es el área en la que se genera

el proceso de pagos. Es el área que gestiona la salida del dinero de la empresa, para

lo cual se debe garantizar comprar la mejor calidad al menor costo posible.

Existen 2 factores que hacen que el departamento de compras se sitúe en un

determinado nivel jerárquico en la estructura de la empresa: la naturaleza o el tipo

del negocio al que se dedica la empresa y la especialización.

La compra, en general, se inicia a partir de los requerimientos de los distintos

sectores de la empresa y se formaliza con un documento escrito; éste es el momento

en el que el área de Compras inicia su gestión. El responsable realiza comparativas

de los precios y selecciona al proveedor. Luego genera la orden de compra para

notificar al proveedor que se le ha adjudicado la compra y además para notificar a las

demás áreas de la empresa. El proceso continúa con la recepción del pedido y de la

factura para emitir el pago.

Se denomina política de compras a los criterios generados desde la dirección de una

empresa con respecto a las condiciones, plazos de pago, tipos de proveedores, etc.,

que se aplican para realizar todas las adquisiciones. Comprar es una ciencia y


41

comprar bien es vender bien. Cada euro ahorrado tiene efecto directo sobre las

utilidades de la empresa. En la actualidad, la dirección requiere del profesional de

compras:

• Capacidad para negociar.

• Capacidad de liderar.

• Mantenerse actualizado sobre el mercado.

• Seleccionar adecuadamente a los proveedores.

• Reducir la gestión administrativa de compras.

• Contar con conocimiento técnico.

El planeamiento de compras es el conjunto de planes sistematizados y encaminados a

dirigir las compras dentro de la empresa, el cual responde a las siguientes preguntas:

¿qué comprar?, ¿cuánto?, ¿cómo?, ¿cuándo?, ¿a quién?

Del análisis del presupuesto de producción surgen las necesidades de materiales a

comprar, por lo que debe efectuarse el presupuesto de compras. Al comienzo de cada

período se calculan los requerimientos que serán indispensables, a fin de cubrir las

necesidades de fabricación y mantener las existencias en los niveles de stock de

seguridad.


42

1.2.2.1. OBJETO

Garantizar la adquisición de recursos y/o contratación de servicios a través de la

definición de directrices encaminadas al cumplimiento y mejoramiento de las

condiciones de calidad, precio y tiempos de entrega. Las actividades más importantes

de este proceso se enumeran a continuación:

• Reconocimiento de la necesidad.

El proceso de compra comienza cuando el comprador reconoce la necesidad de

adquirir un producto o servicio a partir de reconocer una diferencia entre el

estado deseado y el estado real existente. Esta necesidad puede surgir por

impulsos externos o internos.

• Búsqueda de información.

En esta etapa el comprador debe recopilar toda la información que considera

necesaria para fundamentar sus análisis y la toma de decisiones. Esta información

está relacionada con la definición de los proveedores posibles, información sobre

los parámetros de las ofertas de cada proveedor, las características y exigencias

de los consumidores de la empresa, características del objeto de

aprovisionamiento y otras informaciones relacionadas con el mercado y la

empresa.


43

• Formación de alternativas.

A partir de la información recopilada el comprador determinará las alternativas

de compra ante las que se enfrenta, caracterizando a cada una de las alternativas

con aquellos parámetros relevantes.

• Evaluación de alternativas.

El comprador en cada compra determina cuáles son los principales criterios de

selección. A partir de esta definición se evalúa de acuerdo a dichos criterios cada

alternativa y sobre la base de la ponderación de los distintos criterios se llega a

una evaluación integral de cada alternativa para llegar a seleccionar la que es más

conveniente para la empresa.

• Decisión de compra.

Considerando la evaluación anterior y el esquema de fuerzas de los actores de la

compra se llega a la decisión de compra que contempla un conjunto de

parámetros tales como: el proveedor, la cantidad a comprar, el valor de la

compra, forma de pago, sujeto de la transportación, lugar de entrega, fecha de

entrega, características del producto, envase y embalaje a utilizar y otros

elementos.


44

• Ejecución de la compra.

Esta etapa comprende el conjunto de acciones para ejecutar la decisión de

compra tomada anteriormente. Esta etapa tiene una gran importancia ya que en la

misma es que se logra la materialización de la compra y requiere de una atención

esmerada para ejecutar la compra ajustándose a los parámetros que conforman la

decisión de compra.

• Monitoreo post compra.

Una vez ejecutada la compra debe mantenerse un monitoreo del producto o

servicio durante todo el ciclo de consumo o uso con vista a detectar posibles

fallos que puedan ser objeto de reclamación, así como aumentar la información

sobre la marca correspondiente, lo cual es de mucha utilidad en próximas

compras.

1.2.2.2. IMPORTANCIA DE LA FUNCIÓN DE COMPRAS

Medir la competitividad de una empresa es medir su participación en el mercado.

Uno de los medios para mejorar la competitividad es producir a bajos costos y con

alta calidad. Esta afirmación implica que el sistema de producción debe ser

abastecido de recursos que cumplan con las condiciones más ventajosas posibles, las

cuales son:

• El precio de compra.

• El plazo de pago.


45

• El plazo de entrega el servicio de posventa.

• La calidad.

• La estabilidad del proveedor.

Una de las responsabilidades de los que conducen empresas es dirigir y coordinar el

proceso de compras para cumplir con la producción y las ventas. La planificación de

este proceso se relaciona directamente con las funciones de stock. La gestión exitosa

en las compras y en el manejo de inventarios permite: asegurar el normal flujo de

materiales para las áreas que los transforman en los productos que la empresa

comercializa; y la distribución y entrega del producto terminado a los clientes.

La eficacia en la gestión de compras se medirá en función de:

� El control de gastos y costos que permita ahorrar recursos financieros.

� El manejo de stocks mínimos que aseguren el cumplimiento de las ventas

esperadas.

� La habilidad para encontrar fuentes de abastecimiento.

� La posibilidad de investigar y conocer nuevos materiales disponibles en el

mercado.


46

1.2.2.3. TIPOS

En cualquier empresa, no todas las compras se llevan a cabo siguiendo idénticos

procesos.

Son factores determinantes de la forma de realizar la adquisición de bienes: la

actividad habitual desarrollada por la empresa, la importancia de la empresa dentro

del contexto del mercado (poder de compra), el tipo de artículo a adquirir, la

importancia de la compra, la situación geográfica del proveedor, las características

del vendedor, etc.

Se puede considerar que, se podrá actuar más coherentemente, si se tienen definidas

de forma independiente:

• Las compras normales. • La adquisición de elementos denominados menores. • Los bienes importados. • Las incorporaciones de bienes del activo fijo.

No obstante, es razonable pensar que se debe efectuar en ciertos casos, por ejemplo,

la adquisición de un elemento que se puede encasillar dentro de lo que se denomina

compra normal, pero que se toman pautas particulares de algunas de la tres restantes

formas de comprar mencionadas.


47

� Las Compras normales.

Se ubican dentro de esta forma de comprar, las materia primas a incorporase en un

proceso productivo y en otros bienes o elementos representativos de una erogación

de carácter general identificada con el área de producción, comercialización o

administración.

Habitualmente, se trata de elementos sobre los cuales se posee información relativa a

la cantidad máxima, mínima y al punto de pedido.

Resumiendo, se puede decir que abarca aquellos elementos de consumo repetitivo

para el desarrollo habitual de la empresa.

� Adquisición de elementos menores.

Los elementos menores son aquellos que son necesarios para el desarrollo de la

empresa pero se precisan solo en un momento determinado, como por ejemplo una

pieza de repuesto, un libro contable, etc. La compra de estos elementos se realiza

generalmente empleando un fondo fijo. Incluso, esas operaciones de compra se hacen

por una cantidad limitada.

No es conveniente centralizar este tipo de compras a un solo departamento. Lo más

conveniente es que el responsable del sector que necesite un bien de este tipo realice

la compra.


48

� Compras en el exterior.

Existe una marcada diferencia en la forma de actuar entre una compra local y aquella

efectuada en el exterior.

Cuando se importan bienes deben contemplarse particularidades vinculadas con el

vendedor, el flete, impuestos, los seguros de cambio y transporte, entre otros. Se

debe prestar especial atención a la calidad de los bienes a comprar. También es de

tener en cuenta lo relativo a lo de la moneda empleada en la operación, haciendo

hincapié en el riesgo que surge desde que el producto se embarca o sale del depósito

del proveedor hasta la llegada al país del comprador.

Las compras efectuadas en el exterior se realizan frecuentemente en un volumen más

considerable que para las compras locales, para abaratar los costes de mercadería,

fletes, etc. También, suele tratarse de bienes de elevado precio y por tal motivo las

precauciones a tomar deben ser más estrictas.

� Compras de bienes del activo fijo.

Se caracteriza por tratarse de elementos que no requieren de una reposición

permanente. Incluye maquinarias, motores, herramientas, instalaciones, inmuebles,

etc.

En virtud de que el desembolso en estas operaciones es, en general, de importancia,

se solicita para la autorización de la misma la conformidad de un alto representante

de la empresa, como la del gerente general o la persona que lo sustituye en caso de

ausencia o imposibilidad de aquel, o en ultima instancia, del directorio si se trata de

una adquisición de gran envergadura.


49

1.2.2.4. RELACIONES CON OTRAS ÁREAS DE LA EMPRESA

El área de compras se relaciona estrechamente con varios módulos importantes del

negocio, entre los que destacan:

• Dirección General: fijación de políticas generales, procedimientos y análisis

de los cambios del entorno.

• Producción: información sobre plazos de entrega, costo de los insumos,

calidad disponible.

• Finanzas: fijación de las políticas financieras, requerimientos de fondo y

presupuestos.

• Recepción y almacenes: administración en la logística de movimientos y

coordinación de necesidades de espacio.

• Contabilidad: control de inventarios, costeo de materiales, y valoraciones y

provisiones de las compras.

1.2.2.5. CONTROL DE LA FUNCIÓN DE COMPRAS

• Índice de compras:

Significación de las compras respecto a las ventas en términos porcentuales.


50

• Índice de coste del departamento de compras:

Significado del coste del departamento de compras (coste de gestión) en

relación al valor de las compras.

• Coste de un pedido de compras:

Se determinará por el cociente entre el coste del departamento de compras y

el número de pedidos emitidos.

• Índice de concentración de compras:

Revela el importe medio de compra por pedido.

• Índice de carga de trabajo:

Cantidad media de compras por empleado. Se determina por el cociente entre

el valor de las compras y el número de empleados del departamento de

compras.

• Índice de concentración de proveedores:

Recoge el número medio de pedidos que se adjudica a cada proveedor.

Se obtiene dividiendo el número de pedidos entre el número de proveedores.


51

• Cifra de negocios por proveedor:

Indica el volumen de compras por proveedor. Se obtiene dividiendo el valor

de las compras realizadas entre el número de proveedores.

• Índice de rotación de stocks de materias primas:

Indica el número de veces que rota el stock medio respecto a la cantidad de

materias primas (materiales) comprados. Se determina dividiendo el valor de

las compras anuales entre el stock medio anual.

• Índice de rechazos:

Relación entre el valor de las devoluciones y el valor de las compras,

expresado en términos porcentuales. Se obtiene dividiendo el Valor de las

Devoluciones entre el valor de las Compras y multiplicado por 100.

• Índice de financiación de las compras por proveedores:

Indica el porcentaje del valor de las compras que es financiado por los

proveedores.

Se obtiene dividiendo el saldo medio de proveedores entre el valor de las

compras y multiplicado por 100.


52

• Días de crédito por parte de los proveedores:

Si el período de análisis es el año, se puede determinar por la relación entre el

valor financiado por los proveedores y el de las compras anuales y

multiplicado por los 360 días del año.

1.2.2.6. PROCEDIMIENTO

A. Planificación.

•••• Selección de proveedores y contratistas.

Esta actividad se realiza a través de la auditoría que se realiza a los Proveedores y

Contratistas de la empresa, para aquellos proveedores que conforman el pareto de

compras, y aquellos seleccionados por los Directores de área considerados como

proveedores o contratistas críticos o que inciden sobre el desempeño de los

procesos y en el servicio prestado.

El resultado de esta etapa es un listado de Proveedores y Contratistas aprobados

así como los registros de evaluación de los mismos.

•••• Elaborar el presupuesto anual de compras.

Tarea que será llevaba a cabo por la dirección de la empresa y dará como

resultado el presupuesto para compras.


53

B. Realizar la Compra.

•••• Detección de la necesidad de compra.

Cada área de la empresa genera sus necesidades de compra mensuales según el

giro ordinario de la compañía. Para ello no se deben olvidar del ya fijado

presupuesto anual para el total de las compras de la empresa, por lo que habrá

que realizar una planificación por áreas asignando los máximos permitidos,

cantidad a la que cada área deberá ajustar sus gastos.

•••• Cotización.

Se contacta a los proveedores y contratistas seleccionados para solicitarles

cotización de acuerdo al tipo de bien o servicio a adquirir. Para el caso de

proyectos especiales, se elaborarán los términos de referencia de la compra y se

publicarán para que los proveedores puedan entregar sus propuestas.

Cuando el artículo o servicio requerido es objeto de un acuerdo comercial previo,

una vez que los requisitos están fijados, el solicitante de la compra procede a

generar la orden de compra respectiva sin que haya lugar a cotizaciones

adicionales.

•••• Fijación de los requisitos.

Los requisitos son definidos según las necesidades detectadas y presupuestadas.

El área solicitante debe rellenar completamente la solicitud de Adquisiciones y/o


54

Contrataciones fijado en la empresa que contiene las especificaciones del

producto o servicio. Debe estar firmado por el Director del área.

La Solicitud de Adquisiciones y/o Contrataciones es entregada al Auxiliar de

Compras, quien se encargará de asignar la cuenta contable y el centro de costo a

afectar y revisar que la solicitud cumpla con los requisitos pertinentes, como:

� Firma Solicitante.

� Asignación de Cuenta.

� Descripción clara y especifica del producto o servicio solicitado.

� Anexo de cotizaciones y cuadro comparativo de propuestas Si la compra

es un Activo Fijo, la solicitud será enviada a la Dirección para su

aprobación.

Se utilizan 2 copias: una para el folder consecutivo del Auxiliar de Compras, que

se anexa a la copia de orden de compra, o contrato y una para el solicitante.

•••• Aprobación de Compras.

Se procede a elaborar el contrato según aplique. También se solicita una vez sea

aprobada la compra, una póliza de cumplimiento como garantía y respaldo según

los requisitos exigidos.


55

•••• Seguimiento a la Compra.

Se hace seguimiento a las condiciones de entrega, garantías, calidad, etc.,

pactadas con el proveedor.

•••• Verificación del producto o servicio comprado.

Se validan las características del producto comprado, para constatar que cumple

con los requisitos según lo especificado en la Orden de

Compra/Servicio/Contrato. Si existe alguna inconsistencia se hace la devolución

o reclamo al proveedor y se solicita cambio o mejora del servicio.

•••• Control de Inventarios.

Se hace un ingreso en el almacén, con un listado de inventario previo elaborado

por la Asistente de Dirección.

Anualmente se realiza inventario físico por parte de cada Director con el apoyo

de la Asistente de Dirección.

C. Verificación/Evaluación.

•••• Seguimiento al proveedor y Contratista.

De acuerdo al desempeño mostrado por el proveedor el interesado en la compra

le hace un seguimiento según los criterios de evaluación, los cuales son tenidos


56

en cuenta al momento de su re-evaluación anual o según los reclamos

presentados en el período seleccionado.

El resultado de esta etapa, por lo tanto, dará como resultado un registro de

evaluación de Proveedores y Contratistas.

D. Post-análisis y optimización.

•••• Retroalimentación con proveedores.

Se efectúan reuniones para la mejora de aspectos claves de desempeño por

proveedor. Se analiza todo el proceso y se definen actuaciones o normas para

operaciones posteriores lo cual irá provocando un proceso de optimización de

todo el proceso.

1.2.2.7. POLÍTICAS GENERALES DE COMPRAS

• Se exige a los proveedores certificados de la Cámara de Comercio de la ciudad

donde esté radicada la empresa. En este certificado debe constar que su

matrícula mercantil se encuentra al día. En caso de que sea una compra en el

extranjero, se exigirá el certificado siempre y cuando la compra supere un

salario mínimo legal vigente.

• La Entidad efectuará sus compras en condiciones de pago y precios justos

acordes con las leyes de oferta y demanda imperantes en el mercado.


57

• Las compras se realizan a proveedores que aseguren el mantenimiento, soporte

y garantías del producto.

• Se buscará que la adquisición de los bienes, insumos, suministros y servicios

sea oportuna, evitando riesgos por escasez o sobre-costos de inventario.

• Regulación de los conflictos de interés entre la respectiva entidad y

funcionarios o terceros, así como de la obligación de manifestar oportunamente

tales conflictos en todos los eventos que se presenten. La transparencia en la

adquisición de bienes o servicios estará garantizada con el cumplimiento de lo

dispuesto en la Declaración de Principios Éticos de la Fundación Carnaval de

Barranquilla.

• Regulación respecto de la prevención y prohibición del uso indebido de

información conocida en razón de la labor o de las funciones, que pueda ser

utilizada en provecho de funcionarios, agentes o terceros (confidencialidad de

la información).

• Se dará preferencia a aquellos proveedores que son fabricantes o representantes

directos de los mismos productos y mantener la uniformidad en líneas y

marcas.


58

• En caso de realizar compras con proveedores exclusivos, éstas deberán ser

revisadas periódicamente con el fin de evitar que la empresa quede

desprotegida ante eventuales problemas de los mismos.

• Todas las empresas cumplirán invariablemente los procesos de cotización,

autorización y adjudicación. En caso de que este proceso no se cumpla, siempre

habrá una constancia escrita.

• Excluir el trámite de pólizas cuando el producto o el servicio sea entregado en

forma anticipada, o la naturaleza del servicio no lo requiera.

• Procurar la participación del mayor número de oferentes y de demandantes

idóneos para garantizar una efectiva exposición al mercado.

• Se seleccionaran las mejores propuestas para la Entidad, atendiendo factores

objetivos previamente establecidos.


59

2.2.2.2. Metodología


60

2. METODOLOGÍA

En este apartado se va a describir de forma general la metodología elegida para la

elaboración del proyecto.

Existe un gran número de metodologías a la hora de afrontar el desarrollo de un

proyecto de software. Por lo general, se determina cuál de ellas es la más beneficiosa

a la hora de aplicarla en la elaboración de un proyecto en función de la naturaleza del

mismo, aunque en algunos casos se utilizan varias de manera simultánea, extrayendo

lo mejor de cada una de ellas

Para la elaboración de este proyecto, se ha determinado que la metodología idónea

dada su naturaleza es el modelo lineal o en cascada.

La metodología de desarrollo en cascada se caracteriza por tener un conjunto de

etapas o fases bien definidas, en la que cada etapa del ciclo de vida no comienza su

desarrollo hasta que la etapa anterior no ha sido finalizada por completo. Además,

con la finalización de cada etapa, se obtiene un documento o producto final, que es

revisado, validado y aprobado. En la gran mayoría de los casos, este documento

constituye el punto de partida de la siguiente etapa.


61

En el caso de este proyecto, se considera de vital importancia no finalizar una etapa

hasta que se esté completamente seguro de que los resultados obtenidos en la misma

son correctos y hayan sido supervisados y aprobados por el cliente, ya que de la

corrección de los resultados extraídos en cada una de ellas depende la corrección del

resto del proyecto.

La siguiente figura representa un ejemplo de la división en etapas en las que se puede

subdividir la metodología lineal o en cascada.

Ciclo de vida lineal o en cascada.


62

2.1. ETAPAS DE DESAROLLO

En los siguientes apartados se va a definir el conjunto de etapas que componen el

desarrollo de un proyecto informático mediante el uso de la Metodología en Cascada.

Para cada uno de ellos se detallará su objetivo, tareas a realizar así como los

entregables obtenidos.

2.1.1. IDENTIFICACIÓN DE NECESIDADES

En esta etapa, se debe conseguir identificar cuales son los objetivos y necesidades

que el cliente quiere satisfacer a través del proyecto a desarrollar. Para ello, se deberá

llevar a cabo un dialogo con un interlocutor en el cliente que tenga un conocimiento

profundo sobre la temática del sistema a desarrollar. En esta etapa se definirán, al

menos, los siguientes conceptos:

• Objetivos del sistema. Se trata de objetivos de tipo empresarial y no de tipo

informático.

• Alcance del sistema. Funciones de negocio a considerar dentro del alcance.

• Tipología de usuarios finales. Se debe tener una ligera idea sobre a que

perfil de personas va dirigido el producto final a obtener.


63

• Restricciones. Se deben identificar y considerar aquellas restricciones que

pueden afectar al plan de proyecto y a su desarrollo.

• Organización y funciones empresariales. Conocer la organización del

cliente para determinar en que usuarios influirá el desarrollo del proyecto.

• Antecedentes. Recopilar información sobre cualquier sistema existente que

realizará una labor similar al que se va a implantar, así como los motivos que

han llevado a la organización del cliente a realizar este proyecto.

Toda esta información es recopilada básicamente a través de entrevistas con el

cliente.

Como resultado de esta etapa, la información que se ha ido recogiendo a lo largo de

la misma se especifica en el denominado “Documento de Conceptos del sistema”.

2.1.2. ANÁLISIS DE REQUISITOS (ARQ)

Los objetivos a alcanzar en esta fase son los siguientes:

• Alcanzar un conocimiento suficiente del sistema y del negocio para proponer

en marcha la solución propuesta.

• Expresar el conocimiento adquirido mediante dos modelos:

� Modelo de procesos, tanto físicos como lógicos.

� Modelo de datos

• Obtener la aprobación del cliente, para avanzar en el nuevo sistema.


64

En el caso de existir algún tipo de sistema similar al que deseamos implantar o

alguna versión anterior del mismo en el momento de la realización del proyecto, se

procederá a obtener el modelo de procesos, tanto físicos como lógicos, de dicho

sistema.

En el caso de nuestro proyecto, al ser un sistema de nueva implantación, no será

necesaria la realización del proceso anterior al no existir ningún sistema similar ya

implantado en cliente.

Se elaborará la denominada “Lista de Requisitos”, que contiene una relación lo más

detallada posible de los requisitos solicitados al sistema por el cliente, a partir de los

objetivos marcados en el “Documento de Conceptos del sistema”. En cada uno de los

objetivos, se establecen los requisitos que se solicitan al sistema para cumplir con

cada uno.

Se procederá a la elaboración, usando para ello la “Lista de Requisitos” citada en el

párrafo anterior, del modelo de procesos lógico del sistema a implantar, que recogerá

aquellas informaciones esenciales para el negocio, eliminándose aquellas que no

resulten esenciales. Este modelo deberá representar qué hace el sistema, sin importar

cómo lo hace. Este modelo ha de incorporar los requisitos del usuario para el sistema

a implantar.


65

La siguiente actividad a realizar en esta etapa es la elaboración del modelo

conceptual de datos. Dicho modelo representa la familia de datos o entidades de

negocio utilizadas por el sistema, así como las posibles interrelaciones existentes

entre ellos.

Una vez que haya sido definida la plataforma tecnológica a utilizar, se podrán

conocer los componentes físicos que formarán parte de nuestro sistema y, por lo

tanto, estaremos en disposición de elaborar el estudio del modelo de procesos físicos.

En cuanto a los datos se refiere, el modelo físico que construye la base de datos y

ficheros del sistema debe estar completado antes de iniciar la etapa de programación.

2.1.3. ESTUDIO DE LA ARQUITECTURA (EAQ)

En esta fase, se deben alcanzar los siguientes objetivos:

• Definir el conjunto de posibles soluciones que se adapten, tanto a nivel

software, hardware como de comunicaciones, a los requisitos y restricciones

del sistema.

• Elegir una de las soluciones anteriores como la alternativa a implantar.

• Obtener la aprobación del cliente para la solución seleccionada.


66

Para alcanzar el conjunto de objetivos citados en los puntos anteriores, se procederá a

la realización de un estudio de la tecnología hardware, software y de comunicaciones

de cada una de las soluciones o prototipos propuestos.

Se evaluará cada una de las alternativas atendiendo a diferentes aspectos tales como:

estratégicos, organizativos, operativos, técnicos y económicos.

Una vez que se dispongan de los criterios suficientes, se procederá a la elección que

de la arquitectura que será implantada con la realización del proyecto y se procederá

a la elaboración de la planificación general del proyecto.

El plan general de proyecto es un documento en el que se definen el conjunto de

etapas, actividades, hitos importantes, recursos y calendarios por los que se regirá el

desarrollo del proyecto.

Como resultados de esta etapa, además del citado plan general del proyecto, se

obtienen los diferentes esquemas gráficos de funcionamiento de cada una de las

alternativas propuestas, así como sus especificaciones hardware, software y de

comunicaciones.

Además, se dispondrá de la matriz de evaluación de las distintas alternativas que

justificará la elección final de una de las mismas.


67

2.1.4. DISEÑO EXTERNO (DEX)

A lo largo de esta etapa, han de completarse los siguientes objetivos:

• Completar el modelo de procesos, tanto lógicos como físicos, establecidos en

la etapa de Análisis de Requisitos de acuerdo a las plataformas hardware y

software elegidos en la etapa anterior.

• Definir la estrategia de los planes de pruebas, implantación, formación y

conversión.

En primer lugar, se introducirá en el modelo lógico, ya generado en la etapa de

“Análisis de Requisitos”, para dar una visión física no sólo de qué hace el sistema

sino de cómo lo hace.

Se diseñarán las entradas y salidas del sistema, entendiéndose como entrada y salida

el conjunto de ventanas, informes, ficheros y formularios que se necesiten para el

correcto funcionamiento del mismo.

Se especificarán los procesos con un mayor nivel de detalle, indicando características

tales como en que servidor o estación se ejecutaran, frecuencias de ejecución o el

tipo de arquitectura del proceso: Bach, online, cliente, servicio, clase, etc.


68

En esta etapa se deberán estimar los volúmenes de ficheros y transacciones críticas

para servir de guía al modelo lógico de datos.

Se establecen los procesos de control, seguridad y auditabilidad que sean necesarios

para la gestión y operación del proceso de explotación. Son procesos de control los

registros que podamos incorporar para verificar el funcionamiento correcto del

sistema. Los procesos de seguridad se refieren a la protección de los componentes

del sistema, tanto en su acceso como en su destrucción o pérdida. Los procesos de

auditabilidad están destinados a registrar las operaciones que se realizan, con sus

características organizativas. Si el proyecto no requiere de este tipo de procesos, no

deberán ser incorporados.

Se prepara la estrategia de instalación, mediante los planes de pruebas, implantación,

formación y conversión. En esta etapa no se define ninguno de estos planes, pero si

se describe la estrategia a seguir en ellos.

2.1.5. DISEÑO INTERNO (DIN)

A lo largo de esta etapa se identifican y diseñan los diversos componentes software

del sistema, describiendo detalladamente sus especificaciones físicas. Dependiendo

de la arquitectura elegida para el desarrollo, estos componentes podrán ser muy

diversos. Gracias a ello, podremos dividir el sistema en subsistemas atendiendo a la

tipología de los procesos, y así especificar y diseñar sus componentes.


69

Los objetivos a alcanzar a lo largo de esta etapa son los siguientes:

• Identificar y diseñar los componentes software de cada subsistema.

• Especificar cada uno de los programas a desarrollar.

• Obtener el modelo físico de la base de datos.

• Completar los planes de pruebas, implantación formación y conversión.

Para alcanzar los objetivos anteriores comenzaremos por la división del sistema o

subsistema, diseñando cada componente según su arquitectura.

Se definen y completan la estructura de los ficheros intermedios o de trabajo a

utilizar en cada función de negocio: archivos temporales o intermedios, archivos de

movimiento, históricos, de seguridad, etc. En la etapa anterior se diseñaron todas las

entradas y salidas considerando los ficheros que se utilizarán para introducir o

generar información al/del sistema. Ahora deben diseñarse aquellos ficheros

intermedios utilizados en cada función.

A partir del modelo lógico de datos, se obtiene el modelo físico que se constituye con

las sentencias de definición y creación de la base de datos.

Se desarrollan las especificaciones de los programas, o Cuadernos de Carga. Cada

programa, rutina, módulo o subprograma requiere de una especificación que irá


70

dirigida a tres áreas diferentes. En primer lugar, este documento será utilizado por el

programador a la hora de realizar su trabajo de codificación y pruebas del programa a

desarrollar. En segundo lugar, estas especificaciones serán empleadas por los

diseñadores de pruebas a la hora de preparar sus juegos de ensayos para comprobar

la robustez del sistema. Por último, esta documentación constituye la base necesaria

para poder mantener los programas desarrollados, evitándose tener que analizar el

código fuente de la aplicación para averiguar cual es su función.

En esta etapa, por último, se completaran los planes de pruebas, implantación,

formación y conversión, cuya descripción comenzó en la etapa anterior. En esta

etapa se establecerán los planes especificando las actividades, recursos humanos y

materiales y el calendario de fechas de realización.

Como resumen, el Output de esta etapa deberá estar formado por: el modelo físico de

datos y diseño de ficheros, las especificaciones de los programas o Cuadernos de

Carga y los planes de pruebas, implantación, formación y conversión.

2.1.6. PROGRAMACIÓN (PRO)

A lo largo de esta etapa debemos de conseguir la transformación del sistema en un

conjunto de programas que puedan ser ejecutados correctamente, bajo criterios de

calidad.

Los objetivos de esta etapa son los siguientes:


71

• Codificar los programas y componentes que forman el software del sistema.

• Realizar la prueba unitaria de cada uno de los programas y componentes

desarrollados

• Documentar la operación del sistema, elaborando el manual de usuario y la

guía de explotación del sistema.

Para ello, se comenzará por la codificación de los programas en los lenguajes

establecidos según las especificaciones del Cuaderno de Cargas.

Una vez finalizada la codificación de los programas, se procederá a la realización de

las pruebas de los programas y componentes software del sistema.

Se elaborará el manual de usuario y la guía de explotación. El manual de usuario esta

compuesto por el conjunto de las instrucciones de operación del sistema y va

dirigido, sobre todo, a los futuros usuarios del sistema. La guía de explotación, sin

embargo, va dirigida a la las personas que en su día serán las encargadas de la

explotación del sistema, debiendo establecerse en ella la planificación de tareas tanto

programadas como aperiódicas, los soportes de entrada y salida que se manipulan,

las operaciones de seguridad o de backup, la obtención de históricos, la parada y

mantenimiento del sistema, etc.


72

2.1.7. PRUEBAS DEL SISTEMA (PRU)

Una vez desarrolladas en la etapa anterior las pruebas de los componentes a nivel

individual, en esta etapa deben realizarse una serie de pruebas para conseguir integrar

todo el sistema, de acuerdo al Plan de Pruebas elaborado durante la etapa de “Diseño

Interno”.

Por lo tanto, el objetivo de esta etapa es someter al sistema desarrollado y a sus

componentes, a una serie de verificaciones encaminadas a garantizar un nivel de

fiabilidad aceptable.

Esta fase es crítica y debe por lo tanto ser planificada, diseñada y realizada con el

mismo rigor y control con el que se realiza el desarrollo del sistema.

Para ello, comenzaremos por ejecutar el ciclo de pruebas necesarias. Este ciclo

recoge las distintas pruebas alas que puede someterse el software, desde las pruebas

de encadenamiento entre programas, hasta las pruebas de estrés para diagnosticar el

rendimiento del sistema ante condiciones extremas de operación y concurrencia de

usuarios.

Se conseguirá la aprobación, por parte del cliente, de las pruebas del sistema. Una de

las pruebas a realizar en el ciclo es la aceptación del usuario, donde este verifica el

funcionamiento del sistema y su usabilidad ajustada a las necesidades especificadas

en los requisitos.

Se procederá al proceso de formación del personal que utilizará el nuevo sistema.


73

2.1.8. IMPLANTACIÓN (IMP)

Una vez probada la integridad del software del sistema, llega el momento en que se

debe transferir el software producido del Centro de Desarrollo o Pruebas al Centro de

Producción, para llevarse a cabo la explotación del sistema.

El conjunto de las actividades a desarrollar en esta fase ha sido previamente definido

en las planificaciones realizadas en fases anteriores (plan de conversión y plan de

implantación), siendo en esta fase donde se lleva a cabo la materialización de los

mismos.

Para ello, se debe preveer la migración necesaria del software configurado a cada

uno de los equipos y estaciones de trabajo.

Así mismo, se deberán realizar pruebas de carga y rendimiento en los equipos donde

se vaya a instalar el software, garantizándose así la correcta instalación y

configuración del software. Dichas pruebas deberán ser aprobadas por el cliente.

Por último se cumplimentarán todas las tareas descritas en los planes de

implantación, instalación y configuración.

2.1.9. MANTENIMIENTO (MAN)

El ciclo de desarrollo queda finalizado con la implantación y entrega del sistema al

cliente pero, generalmente, con la entrega del software suele acompañarse un período


74

de mantenimiento posterior en estos equipos, que ofrece al cliente una garantía de un

servicio técnico para subsanar cualquier incidencia o mejora dentro del sistema.

Es importante diferenciar entre dos tipos de mantenimiento:

• Mantenimiento correctivo. Consiste en la atención de las incidencias y errores

detectados durante la operación del sistema, debiéndose diagnosticar, subsanar y

actualizar rápidamente para mantener el nivel de servicio esperado por él.

• Mantenimiento adaptativo. Atiende a las mejoras y versiones del software o del

sistema, debido a cambios en el negocio o incorporación de nueva tecnología.

En este punto, deberá pactarse con el cliente el tipo de mantenimiento, en caso de

darse, que se le ofrecerá, así como el periodo de tiempo durante el cual se dará.

2.2. ESTRUCTURA DE DIVISIÓN DEL TRABAJO (EDT)

En la siguiente figura se muestra el Esquema de división de Tareas, también

conocido como EDT, donde se pueden observar el conjunto de paquetes de trabajo, o

Work Packages (WP), en los que se va a dividir el desarrollo del proyecto, así como

el conjunto de actividades que los componen.

El propósito de cada uno de los paquetes de trabajo y sus actividades ha sido

proporcionada en anteriores puntos dentro de este capitulo dedicado a la Metodología

del proyecto.

Interfaz Universal entre un sistem

a de gestión

de activos y un sistem

a de gestión

de compras


3.3.3.3. Identificación de Necesidades


77

3. IDENTIFICACIÓN DE NECESIDADES

3.1. INTRODUCCIÓN

En esta fase se deben definir las relaciones entre los participantes en el desarrollo del

proyecto. Para ello, se realizan una serie de reuniones en las que se debe dejar

definidos ciertos aspectos de la herramienta, tales como: los objetivos que se

pretende alcanzar con su desarrollo y el alcance, la tipología de usuarios y sus

requerimientos, restricciones de todo tipo que afecten de manera directa al desarrollo

del proyecto, la estructura organizativa del equipo (empresa) y los antecedentes del

sistema en el caso de que los hubiese.

Dada la naturaleza del proyecto, se necesitará información de los elementos

manejados por un SGA, así como los elementos específicos involucrados en una

Orden de Compra. Una vez obtenidos los datos por separado, a través de la

realización de varias entrevistas con usuarios de las herramientas, nuestra tarea

consistirá en la definición de un estándar que recopile toda la información

coincidente en ambos sistemas, lo que a su vez ayudará en la definición de objetivos

y alcance del propio proyecto.

Por último, en esta fase se analizan los antecedentes del sistema, lo cual, en el caso

de que los hubiese, ayudará a la mejor comprensión de la herramienta, ya que

agilizará la inducción de conocimiento en las entrevistas mediante la preparación de

éstas por parte del entrevistador, es decir, nosotros mismos.


78

3.2. OBJETIVOS DEL SISTEMA

El principal objetivo del sistema consiste en la creación de un sistema que actúe

como intermediario entre el sistema de gestión de activos de nuestra empresa

(DATASTREAM) y los sistemas gestores de compras de nuestras empresas cliente,

que pueden ser de cualquier tipo (ORACLE, SAP, NAVISION, etc.). Es justo por

este motivo, el que las empresas cliente puedan tener instalados gestores de compras

propios y no deseen cambiarlo, que se hace necesario el desarrollo de una aplicación

que haga de intermediaria entre estos sistemas y, por lo tanto, se justifica el

desarrollo de nuestro proyecto. A continuación se muestra un gráfico esquemático

resumen de esta situación:


79

El objetivo final del sistema consiste en la definición de todos los activos de valor

para poder realizar su gestión sea cual sea el SGA utilizado. De esta manera, tras

construir nuestro sistema conseguiremos un estándar de comunicación universal

entre sistemas gestores de activos y de compras usando la herramienta más extendida

de almacenamiento de bases de datos (Access), abarcando por tanto la mayor

amplitud de usuarios posible. La herramienta debe permitir, por tanto, comunicación

entre ambas partes, facilitando el proceso de transmisión y conversión de los datos de

forma totalmente transparente al usuario.

Se pretende abordar el proyecto ya que resulta una propuesta interesante en el

mercado de la gestión de activos, teniendo en cuenta la ausencia actual de una

herramienta que permita la función del sistema que se pretende desarrollar. Por tanto,

el desarrollo se ve altamente justificado para empresas que haciendo uso de una

herramienta de gestión de activos, necesiten comunicarse o intercambiar parte o el

total de su información con otra u otras empresas, o, por ejemplo, si una misma

empresa hace uso de distintas herramientas de este tipo en diferentes departamentos

o sedes y necesita tener centralizada o unificada toda la información.


80

3.3. ALCANCE DEL SISTEMA

El alcance del proyecto está limitado inicialmente, ya que en lo referente al

almacenamiento de datos se pretende realizar el desarrollo para Access, siendo

ampliable a medida que se vaya desarrollando la herramienta o en el futuro (Toad de

Oracle, DB2, MySql, etc.). El alcance real es la definición y creación de una base de

datos universal donde se centralicen todos los datos para la gestión de activos, así

como el desarrollo de una herramienta capaz de realizar el proceso de conversión y

traducción de los datos entre este tipo de sistemas.

Las funciones más importantes en el desarrollo del sistema se especifican a

continuación:

• Definición de los datos de valor.

En esta fase se pretende hacer una recopilación de todos los datos necesarios que

intervengan habitualmente en una operación de compras. Para ello, analizaremos

por separado los datos requeridos en un SGA elegido por nosotros (DS en nuestro

caso), así como los datos usados generalmente en la gestión de compras.

• Creación de la base de datos.

Una vez tengamos definidos los datos de valor a gestionar en nuestro sistema,

procederemos a la creación de una base de datos en Access basándonos en estos

datos.


81

• Creación de la Interfaz.

A partir de este momento, la tarea se centrará en la construcción de la aplicación,

centrándonos en las tareas de conversión de los datos entre sistemas así como de

que esto se realice de la forma más transparente posible a los usuarios.

3.4. TIPOLOGÍA DE USUARIOS

La tipología de los usuarios finales de este proyecto será cualquier persona que

intervenga en el proceso de compras de la empresa así como cualquiera que tenga

relación con la gestión y control de activos de la misma (áreas de Finanzas, Mercado,

Producción, Personal, etc.).

La gestión de los usuarios de la aplicación será llevada a cabo por el administrador

de la herramienta, el cual posee privilegios totales sobre ésta. Los usuarios no

administradores, sin embargo, tendrán un acceso restringido a la herramienta por lo

que sólo podrán acceder a las partes específicas diseñadas para los usuarios de

nuestras empresas cliente.


82

3.5. RESTRICCIONES

El proyecto está sujeto básicamente a dos tipos de restricciones:

• De tipo temporal: la falta de tiempo es la principal restricción del proyecto.

El plazo para que la herramienta esté totalmente operativa está fijada para

mediados del mes de Mayo de 2009.

• Al tipo de herramientas: hay que tener en cuenta que para la realización de

nuestro proyecto, hemos elegido un SGA específico, en concreto

DATASTREAM

3.6. ORGANIZACIÓN DEL PROYECTO

En este módulo se va a mostrar un organigrama que representa un esquema de las

partes implicadas en el proyecto. Este quedará dividido de la siguiente manera:


83

3.7. ANTECEDENTES DEL SISTEMA

La empresa, actualmente, no dispone de una herramienta que cuente con las

características del sistema que se pretende construir. Fuera de la empresa, tampoco se

conoce ninguna herramienta que ofrezca este servicio, por lo que se considera una

buena oportunidad de negocio, a parte, obviamente, de aprovecharla para la propia

explotación dentro de la empresa, lo cual les permitiría unificar todos los sistemas de

gestión de activos en un único sistema; el principal beneficio que puede obtener la

empresa será la optimización de los servicios que ofrecen los SGA en términos

totales. Como ya se ha comentado anteriormente, la herramienta será totalmente

escalable por lo que en el futuro se podrán añadir todas las nuevas funcionalidades

asociadas que se deseen, así como hacer extensible el manejo de los datos a cualquier

tipo de herramienta de bases de datos.

Los objetivos básicos de la empresa a la hora de poner en funcionamiento la

herramienta son, como casi siempre, el ahorro de tiempo y dinero. Ya se han citado

las ventajas y beneficios del uso de los SGA, por lo que a cualquier empresa le

beneficiaría poder realizar ésta tarea sea cual sea la cantidad que posea de sistemas

de este tipo. Por otra parte, no hay que olvidar que uno de los objetivos más

importantes del desarrollo del proyecto siempre ha sido el contar con un sistema de

control dinámico de todos los activos con los que cuenta una empresa, sean del tipo

que sean. Este control complementa a su vez los objetivos de ahorro de tiempo y

dinero, ya que ese es justamente el objetivo principal de un SGA. Con todo ello, se

pretende la mejora de la calidad del servicio del sistema.


a de gestión


a de gestión

de compras

3.8.

PL

AN

IFIC

AC

IÓN


4.4.4.4. Análisis de requisitos


86

4. ANÁLISIS DE REQUISITOS

4.1. INTRODUCCIÓN

En esta fase del proyecto se profundiza en los requisitos necesarios para conseguir

los objetivos fijados anteriormente. Este análisis consumirá un tiempo considerable

ya que se necesitan definir claramente las funcionalidades de la herramienta, así

como los procesos actuales mediante los cuales se realizan las operaciones de

compras y de gestión de activos, y, por último, el proceso de toda esta información

dando como resultado los datos necesarios para la definición de la base de datos

unificada. Todo ello se realizará por medio de sucesivas entrevistas con usuarios

finales de las herramientas en cuestión, lo cual se considera el método más oportuno

para la comprensión de los procesos y poder realizar la herramienta de la manera más

necesaria y útil para los propios usuarios de la misma.

Los objetivos fijados en la etapa de identificación de necesidades así como los

requisitos de la aplicación se citan a continuación:

• Descripción de un proceso de Orden de Compra.

• Lista de requisitos.

• Características de cada requisito.


87

4.2. DESCRIPCIÓN DE UN PROCESO DE ORDEN DE COMPRA

A continuación se va a realizar una breve descripción de todos los elementos

implicados en un proceso completo de compras. El proceso es el siguiente:

Al rellenarse una Orden de Compra, el sistema comprueba si los datos introducidos

son correctos y, a parte, si se han introducido todos los datos requeridos

obligatoriamente, ya que algunos de los campos de una OC son opcionales mientras

que otros, los requeridos, son obligatorios.

Rellenar OC

¿Correcta?

Notificar

a usuario

Registrar en

el Sistema

Si

Resolución

Incidencia

Actualización

en BBDD

No


88

Tras mostrar al usuario el motivo del fallo, si este decide solucionarlo, el sistema

vuelve a procesar la OC realizando las mismas comprobaciones y, en el caso de que

todo sea correcto, se registra en el sistema con el consecuente reflejo en la base de

datos.

A continuación se muestran los posibles errores que pueden producirse en el proceso

de dado de alta de una OC:

• El usuario no ha introducido la organización a la que le será asignada la OC.

• El usuario no ha introducido el almacén al que se enviará y se asignará la

OC.

• El usuario no ha introducido el originador de la OC, es decir, el responsable

en última instancia de esta.

• El usuario no ha introducido la fecha de vencimiento de la OC.

• El usuario no ha introducido el proveedor correspondiente asociado.

• El usuario no ha introducido el tipo de moneda asociada al proveedor.

Una vez la OC ha sido procesada de forma correcta, el siguiente paso es registrarla

en el sistema. El estado con el que se puede registrar puede tomar tres valores:

incompleto, aprobado y cancelado. Una vez que la OC adquiere uno de los estados

aprobado o cancelado, el resto de campos quedan deshabilitados por lo que los datos

se convierten en finales y no se pueden volver a modificar.


89

4.3. LISTA DE REQUISITOS

• Definición y creación de una base de datos única.

• Crear un listado con toda la información de la base de datos.

• Información detallada de una Orden de Compra.

• Gestión de acceso a la aplicación.

• Gestión de acceso a la información.

• Realizar un pre-diseño de las pantallas del futuro sistema.

• Generación de comentarios ante incidencias.

• Tratamiento de duplicidad en los datos.

• Listado de Meta-Modelos de datos e impresión en fichero.

• Listado de Tareas por usuario e impresión en fichero.


90

4.4. CARACTERÍSTICAS DE CADA REQUISITO

En este punto se van a comentar las características de cada uno de los requisitos

citados en el apartado anterior:

HOJA DE REQUISITOS

Identificación

Proyecto: Interfaz Universal entre un Gestor de Activos y un Sistema de Gestión de

Compras.

Jefe de proyecto: Javier Sánchez Jiménez

Requisito

Definición y creación de una base de datos única

Fecha Versión Origen Identificación de requisito

29/09/2008 1.0 Jefe de Proyecto R1

Descripción del requisito

Definición y creación de una base de datos unificada que contenga toda la información

de nuestra empresa así como de nuestras empresas cliente.

Objetivo

Agilizar el trabajo relacionado con bases de datos de los clientes, aportando mayor

cantidad de información sobre los datos así como facilitando su gestión.


91

HOJA DE REQUISITOS

Identificación


Compras.


Requisito

Crear un listado con toda la información de la base de datos.




Definición de un listado que contenga todos los meta-modelos de tablas de las bases de

datos existentes actualmente, tanto para nuestra empresa como para nuestras empresas

cliente.

Objetivo

Agilizar posteriormente la tarea de asociación de las distintas entidades y sus atributos

relacionados en el proceso de definición de Meta-Modelos de datos.


92

HOJA DE REQUISITOS

Identificación


Compras.


Requisito

Información detallada de una Orden de Compra.




Recopilar información sobre estándares en la realización del proceso de compras, es

decir, toda la posible información de valor que esté relacionada con una Orden de

Compra. La realización de esta recopilación de información se debe realizar, como

mínimo, en todas nuestras empresas cliente.

Objetivo

Agilizar el proceso posterior de definición de un estándar de Orden de Compra así

como la obtención de información valiosa del propio proceso por el que atraviesa una

Orden, y los elementos que intervienen en este proceso.


93

HOJA DE REQUISITOS

Identificación


Compras.


Requisito

Gestión de acceso a la aplicación.




Definición de las políticas de seguridad para usuarios según sus privilegios.

Objetivo

Evitar el uso indebido de la aplicación.


94

HOJA DE REQUISITOS

Identificación


Compras.


Requisito

Gestión de acceso a la información.




Definición del alcance sobre la información de cada tipo de usuario. Cada usuario

deberá poder acceder a los datos relacionados a la empresa (y, por tanto, sistema) a la

que pertenece y en ningún caso a datos de otras empresas.

Objetivo

Asegurar a nuestros clientes unos niveles de seguridad y fiabilidad adecuados.


95

HOJA DE REQUISITOS

Identificación


Compras.


Requisito

Realizar un pre-diseño de las pantallas del futuro sistema.


15/10/2008 1.0 Jefe de Proyecto,

Cliente R6


Realizar un pre-diseño en papel de las pantallas a las que va a acceder un usuario de la

herramienta dependiendo del tipo que sea, definiendo, por tanto, tanto la navegación

como los elementos intervinientes en cada pantalla.

Objetivo

Realizar una estimación del alcance y de las dimensiones de la herramienta, así como la

agilización del proceso posterior de diseño y desarrollo.


96

HOJA DE REQUISITOS

Identificación


Compras.


Requisito

Generación de comentarios ante incidencias.




Definición de unos estándares así como la elaboración de un listado de comentarios que

mostrará la herramienta ante posibles incidencias o errores, definiendo el origen del

problema así como los pasos para su resolución.

Objetivo

Tener una base de documentación sobre el uso de la herramienta. Ello nos agilizará

posteriormente la batería de pruebas de la herramienta así como la elaboración del

manual de usuario final.


97

HOJA DE REQUISITOS

Identificación


Compras.


Requisito

Tratamiento de duplicidad en los datos.




Definición de unos protocolos de actuación ante posibles duplicados en el sistema así

como el control y validación de los datos de entrada y, por lo tanto, su formato.

Objetivo

Asegurar coherencia en los datos y, como consecuencia, fiabilidad del sistema.


98

HOJA DE REQUISITOS

Identificación


Compras.


Requisito

Listado de Meta-Modelos de datos e impresión en fichero.



Cliente R9


Definición de la pantalla en la que se van a mostrar los datos relacionados con los meta-

modelos definidos, del contenido así como del formato de estos datos. Se debe definir,

por otra parte, el formato del fichero en el que se van a mostrar los datos.

Objetivo

Agilizar el proceso posterior de diseño y codificación de la pantalla.


99

HOJA DE REQUISITOS

Identificación


Compras.


Requisito

Listado de Tareas por usuario e impresión en fichero.



Cliente R10


Definición de la pantalla en la que se van a mostrar los datos relacionados con las

Tareas definidas, del contenido así como del formato de estos datos. Se debe definir,

por otra parte, el formato del fichero en el que se van a mostrar los datos.

Objetivo

Agilizar el proceso posterior de diseño y codificación de la pantalla.


100

4.5. DIAGRAMA DE CONTEXTO

Como se puede observar en el diagrama, existen 2 entidades externas claramente

diferenciadas: nuestra empresa, en la que contamos con una base de datos propia de

nuestro sistema de gestión de activos (DataStream), y las empresas cliente, que

siendo cual sea su número, cada una de ellas contará a su vez con una base de datos

propia del sistema de gestión de compras que tengan instalado.

Dos empresas cliente pueden contar con el mismo sistema de gestión de compras y,

sin embargo, tener las bases de datos distintas (las bases de datos están

particularizadas). El objetivo de la herramienta es unificar toda la información y

permitir su completa gestión.


101

A continuación vamos a proceder a describir las bases de datos con las que va a

contar nuestro sistema:

• Meta-Modelos de Datos. Está formada por varias tablas. Almacena todos los

Meta-modelos de datos creados para los clientes. No existe limitación en el

número de Meta-modelos definidos entre dos sistemas.

La base de datos será de lectura y escritura.

• Ficheros. Almacén de los ficheros creados con información relativa a Meta-

modelos de datos y de Tareas de clientes. Los ficheros son creados por la

herramienta a solicitud de un cliente, por lo que únicamente mostrarán datos

asociados a la empresa y sistema que tenga asociados éste.

La base de datos será de escritura.

Como se ha citado anteriormente, nuestra empresa y los clientes son los que van a

suministrar los datos requeridos a nuestro sistema, mientras que el usuario

(administrador de la herramienta) va a poder hacer uso de esta información según las

distintas posibilidades implementadas en la aplicación.

En los diagramas de flujo de primer y segundo nivel se especificará en mayor detalle

en contenido de estos flujos.


102

4.6. DIAGRAMA DE PRIMER NIVEL

En el anterior diagrama se muestra, de forma general, los principales procesos con

los que va a contar la aplicación. A continuación se va a proceder a realizar una

breve descripción de cada uno de los procesos. Se procederá a realizar una mayor

profundización (o explosión) de aquellos procesos que cuenten con una mayor

complejidad, procurando darles una mayor especificación.


103

• Login: al entrar en la aplicación el usuario introduce sus datos (nombre de

usuario y contraseña) para que el sistema los valide. Una vez los datos han

sido validados, el sistema comprueba el perfil del usuario determinando los

privilegios con los que contará dentro de la aplicación.

• Menú general aplicación: se procede a mostrar las diferentes opciones que

ofrece la aplicación según los privilegios del usuario que accede. Las

opciones se enumeran a continuación:

� Menú administrador: el usuario que accede es de tipo administrador y, por

lo tanto, tiene acceso completo a las opciones que ofrece la aplicación

(operaciones de consulta, alta, baja y modificación). Sus diferentes

opciones son:

1. Gestión Meta-Modelo de datos.

a. Administración Modelo de datos de DATASTREAM.

b. Administración Modelo de datos de Sistemas Gestores de

Compras.

c. Administración de Casos.

2. Gestión de Jobs.

a. Gestión de Tareas.

b. Gestión de Frecuencias.

c. Gestión de Tipos de Tareas.

d. Gestión de Jobs.


104

3. Administración de Empresas – Sistemas.

4. Gestión de usuarios.

� Menú usuario: el usuario que accede es de tipo usuario y, por lo tanto,

tiene acceso restringido a las opciones que ofrece la aplicación

(operaciones de consulta).

1. Visualización Meta-Modelo de datos.

2. Visualización de Jobs - Tareas.

Como se puede comprobar, los usuarios no administradores cuentan con un

menú distinto al del administrador, quedando restringido su área de acción a

consulta de información asociada a su propia empresa y sistema.

• Administración de usuarios: el usuario administrador es capaz de realizar una

típica gestión de los usuarios de un sistema; si el usuario cuenta con

privilegios suficientes, es decir, es administrador del sistema, será capaz de

llevar a cabo una gestión de los usuarios ya existentes (modificación y baja)

así como de realizar los pasos necesarios para dar de alta a nuevos. En

cualquier caso, no se permite dar de baja al usuario Administrador.

• Gestión del meta-modelo de datos: esta opción ofrece la posibilidad de la

gestión de los meta-modelos de datos, siempre y cuando se sea el usuario

administrador, y representa el núcleo principal de la aplicación.


105

• Editor de Jobs: el usuario de tipo administrador es capaz de realizar la

gestión total de todos los procesos relacionados con Jobs y tareas, así como

de todos los elementos implicados en estos dos procesos (Tipos de tareas y

frecuencias). Los usuarios no administradores tienen la posibilidad de

consulta de los Jobs creados con todas sus tareas asociadas.

• Gestión de Empresas - Sistemas: el usuario administrador es el encargado de

la gestión de la información de nuestras empresas cliente así como de sus

sistemas de gestión de compras asociadas.

• Visualización Meta-modelos de datos: esta opción ofrece a los usuarios

cliente la posibilidad de visualización en formato de tabla de todos los Meta-

Modelos de datos asociados a su empresa y sistema, así como la generación

de un fichero de salida con toda esta información.

• Visualización Jobs - Tareas: esta opción ofrece a los usuarios cliente la

posibilidad de visualización en formato de tabla de todas las tareas

dependientes de sus Jobs, así como la generación de un fichero de salida con

toda esta información.


106

4.7. DIAGRAMAS DE SEGUNDO NIVEL

Login

1.1.- Validar usuario: al introducir el usuario sus credenciales, nombre y contraseña,

el sistema valida estos datos en la base de datos de USUARIOS, donde se valida

tanto si existe el usuario como si la contraseña es válida, dando como resultado el

tipo de usuario que accede a la aplicación para ser usado en el siguiente proceso.

1.2.- Asignar privilegios usuario: recibe el tipo de usuario que accede a la aplicación

y establece los privilegios asociados a ese tipo de usuario, determinando, por tanto,

las opciones que tendrá habilitadas de la aplicación (filtros de información).


107

Administración de usuarios

3.1.- Gestión de usuarios: el usuario administrador es capaz de realizar una gestión

típica de los usuarios del sistema. Los cambios se darán de alta en la base de datos de

USUARIOS, mientras que de la tabla EMPRESAS-SISTEMAS se leerán las

distintas empresas – sistemas dadas de alta para la inserción de un nuevo usuario en

una de ellas.

Como se ha comentado anteriormente, el Administrador puede dar de baja cualquier

usuario pero no se puede dar de baja a sí mismo. Esto se decidió que fuera así debido

a la intención de centralizar toda la gestión en un único usuario de nuestra empresa, y

así evitar gestiones paralelas que pudiesen provocar incoherencia en los datos de las

tablas.


108

Administración del meta-modelo de datos

4.1.- Menú Meta-modelo: se muestran las diferentes opciones permitidas respecto a

la administración del meta-modelo de datos, siendo en total 4: Administración del

modelo de datos de DATASTREAM, Administración del modelo de datos de SGC,

Administración de casos y, por último, análisis del Meta-modelo.

4.2.- Administración Modelo de datos DATASTREAM: ofrece la posibilidad de

gestión de los diccionarios de datos (Entidades DS y de Atributos DS) del sistema

DATASTREAM con el que cuenta nuestra empresa, lo cual afecta a los diccionarios

de Entidades y Atributos generales de la aplicación dada la relación existente entre

las tablas.


109

4.3.- Administración Modelo de datos SGC’s: ofrece la posibilidad de gestión de los

diccionarios de datos (Entidades SGC y de Atributos SGC) de los diferentes

Sistemas de Compras con los que cuentan nuestros clientes, lo cual afecta de igual

manera a los diccionarios de Entidades y Atributos generales.

4.4.- Administración de Casos: ofrece la posibilidad de gestión de los Casos

definidos entre un Atributo de una Entidad de DS y un Atributo de una Entidad de

SGC. El siguiente gráfico muestra un ejemplo de éste proceso de asociación o Caso:


110

4.5.- Análisis de Meta-Modelos: este proceso realiza un análisis de coherencia y

validado de datos que intervienen en el proceso de asociación. Su función es avisar

de cualquier incidencia o problema encontrado durante el proceso.

Edición de Jobs

5.1.- Menú Editor Jobs: se muestran las diferentes opciones permitidas respecto a la

gestión de Jobs, siendo en total 4: Gestión de tareas, Gestión de frecuencias, Gestión

de tipos de tareas y Gestión de Jobs.


111

5.2.- Gestión de Tareas: ofrece la posibilidad de gestión de las tareas almacenadas en

el sistema; cada tarea tendrá asociada un Job específico. Éste proceso requiere de la

lectura de tres bases de datos correspondientes a los diferentes atributos con los que

cuenta una Tarea: la frecuencia con la que se va a realizar, el tipo de la Tarea y la

Entidad a la que se atribuye la ejecución de la propia Tarea.

5.3.- Gestión de frecuencias: ofrece la posibilidad de gestión de las frecuencias que

luego serán asignadas a las tareas que se den de alta en el sistema. Cada tarea tendrá

asociada una frecuencia específica.

5.4.- Gestión de tipos de tareas: ofrece la posibilidad de gestión de los diferentes

tipos de tareas que se pueden llevar a cabo en las entidades de nuestro sistema. Cada

tarea tiene asociada un tipo de tarea específica.


112

Visualización de Meta-Modelos de datos

7.1.- Seleccionar Entidad: una vez el usuario accede a esta pantalla, se le ofrece la

posibilidad de seleccionar entre las distintas Entidades definidas en su empresa –

sistema para mostrar únicamente los meta-modelos asociados a estas Entidades.

7.2.- Visualización de Meta-Modelos: una vez el usuario ha seleccionado una

Entidad específica, se le muestran todos los meta-modelos asociados a esta Entidad

en formato de tabla.


113

7.3.- Imprimir Listado: se ofrece la posibilidad al usuario de realizar una impresión

en papel de la tabla resultado según el filtrado realizado previamente por éste.

7.4.- Generar documento: se ofrece la posibilidad al usuario de crear un fichero con

la información específica que haya seleccionado previamente.

Visualización de Jobs-Tareas

8.1.- Seleccionar Job: una vez el usuario accede a esta pantalla, se le ofrece la

posibilidad de seleccionar entre los distintos Jobs que tiene asociados.

8.2.- Visualización de Tareas: una vez el usuario ha seleccionado un Job específico,

se le muestran todos los datos asociados a la Tarea específica en formato de tabla.


114

8.3.- Imprimir Listado: se ofrece la posibilidad al usuario de realizar una impresión

en papel de la tabla resultado según el filtrado realizado previamente por éste.

8.4.- Generar documento: se ofrece la posibilidad al usuario de crear un fichero con

la información específica que haya seleccionado previamente.

4.8. MODELO CONCEPTUAL DE DATOS

El Modelo de Datos describe las características principales de los datos del sistema,

es decir, determina cuáles son las familias o entidades de datos de negocio, sus

relaciones y sus atributos más importantes. Se utiliza la información de los flujos de

datos, almacenes, registros y atributos del modelo lógico para identificar las

entidades de datos del sistema.

Los datos están normalizados, ya que están identificados los grupos diferentes de

información y sus dependencias consiguiendo una arquitectura coherente con el

sistema mecanizado.

Todas las tablas cumplen con las tres formas normales de la normalización:


115

• Primera Forma Normal (1FN):

Una entidad está en 1FN si cada atributo que la constituye, y que no participa

como identificador de ella, es pendiente funcional de dicho identificador.

• Segunda Forma Normal (2FN):

Una entidad está en 2FN si está en 1FN, y si todos los atributos que la

constituyen y que no participan como identificador son dependientes

funcionales de la totalidad del identificador y no de una sola parte de éste.

• Tercera Forma Normal (3FN):

Una entidad está en 3FN si todos los atributos que la componen, y que no

constituyen el identificador de ella, son independientes funcionales entre sí.

Normalizando el Modelo de Datos se consigue evitar redundancias y dar

integridad a los datos.

El modelo de Datos lógico final se muestra a continuación:


116

Las tablas que componen el sistema así como sus atributos se describen a

continuación:


117

Tabla USUARIOS: tabla en que se almacena toda la información relativa a usuarios

de la aplicación. Dicha tabla cuenta con los siguientes campos:

• NOMBRE_USUARIO: Nombre del usuario de la aplicación.

• CONTRASEÑA: Contraseña del usuario de la aplicación.

• PRIVILEGIOS: identificador que indica los privilegios asociados a un

usuario.

• NOMBRE_EMPRESA_SISTEMA: Nombre compuesto de la empresa y del

sistema de gestión que tiene integrado.

Tabla EMPRESAS-SISTEMAS: tabla en que se almacena toda la información

relativa a las empresas cliente con sus respectivos sistemas de Gestión de compra

asociado. Dicha tabla cuenta con los siguientes campos:



• DESCRIPCIÓN_EMPRESA_SISTEMA: Descripción de la Empresa y su

SGC (opcional).

Tabla ENTIDADES: tabla en que se almacena toda la información cruzada relativa a

entidades. Dicha tabla cuenta con los siguientes campos:

• IDENTIFICADOR_ENTIDAD_TOTAL: Número de identificador único de

la entidad (sea del sistema que sea).


118

• NOMBRE_ENTIDAD: Nombre de la entidad.



Tabla ATRIBUTOS: tabla en que se almacena toda la información cruzada relativa a

atributos. Dicha tabla cuenta con los siguientes campos:

• IDENTIFICADOR_ENTIDAD: Número de identificador de la entidad.

• NOMBRE_ENTIDAD: Nombre de la entidad.

• IDENTIFICADOR_ATRIBUTO_TOTAL: Número de identificador único

del atributo (sea del SGC que sea).

• IDENTIFICADOR_ATRIBUTO_DS: Número identificador del atributo de

DS.

• NOMBRE_ATRIBUTO: Nombre del Atributo.



Tabla ENTIDADES_DS: tabla en que se almacena toda la información relativa a

entidades de la base de datos de DS. Dicha tabla cuenta con los siguientes campos:

• IDENTIFICADOR_ENTIDAD_DS: Número de identificador de la entidad

de DS.

• NOMBRE_ENTIDAD_DS: Nombre de la entidad de DS.


119

• NOMBRE_EMPRESA_SISTEMA_DS: Nombre compuesto de la empresa y

del sistema de gestión que tiene integrado nuestra empresa (AE y DS,

respectivamente).

Tabla ATRIBUTOS_DS: tabla en que se almacena toda la información relativa a

atributos de la base de datos de DS. Dicha tabla cuenta con los siguientes campos:

• IDENTIFICADOR_ENTIDAD_DS: Número de identificador de la entidad

de DS.

• NOMBRE_ENTIDAD_DS: Nombre de la entidad de DS.


DS.

• NOMBRE_ATRIBUTO_DS: Nombre del atributo de DS.

• NOMBRE_EMPRESA_SISTEMA_DS: Nombre compuesto de la empresa y

del sistema de gestión que tiene integrado nuestra empresa (AE y DS,

respectivamente).

Tabla ENTIDADES_SGC: tabla en que se almacena toda la información relativa a

entidades de un SGC. Dicha tabla cuenta con los siguientes campos:

• IDENTIFICADOR_ENTIDAD_SGC: Número de identificador de la entidad

del SGC específico.

• NOMBRE_ENTIDAD_SGCX: Nombre de la entidad del SGC específico.


120

• NOMBRE_EMPRESA_SISTEMA_ SGC: Nombre compuesto de la empresa

y del sistema de gestión de compras que tiene integrado.

Tabla ATRIBUTOS_SGC: tabla en que se almacena toda la información relativa a

atributos de las bases de datos de SGC. Dicha tabla cuenta con los siguientes

campos:

• IDENTIFICADOR_ENTIDAD_SGC: Número de identificador de la entidad

de SGC específica.

• IDENTIFICADOR_ATRIBUTO_SGC: Número identificador del atributo de

SGC específico.

• NOMBRE_ATRIBUTO_SGC: Nombre del atributo del SGC específico.

Tabla CASOS: tabla en que se almacena toda la información relativa a relaciones

entre entidades entre DS y entidades de cualquier SGC’s. Se podrán definir tantos

casos (o metamodelos de datos) como se desee. Dicha tabla cuenta con los siguientes

campos:

• IDENTIFICADOR_CASO: Número de identificador del caso.

• NOMBRE_CASO: Nombre específico del caso (único).

• IDENTIFICADOR_ENTIDAD_DS: Número identificador de la entidad de

DS.

• IDENTIFICADOR_ENTIDAD_SGC: Número identificador de la entidad de

SGC específica.


121


DS.

• IDENTIFICADOR_ATRIBUTO_SGC: Número identificador del atributo de

SGC específico.

Tabla JOBS: tabla en que se almacena toda la información relativa a JOBS. Dicha

tabla cuenta con los siguientes campos:

• IDENTIFICADOR_JOB: Número de identificador del JOB.

• NOMBRE_JOB: Nombre único del Job.

• DESCRIPCIÓN_JOB: Descripción del Job (opcional).

• NOMBRE_USUARIO: Nombre del usuario asignado al JOB.

Tabla TAREAS: tabla en que se almacena toda la información relativa a tareas.

Dicha tabla cuenta con los siguientes campos:

• IDENTIFICADOR_JOB: Número de identificador del JOB.

• IDENTIFICADOR_TAREA: Número de identificador de la tarea.

• NOMBRE_TAREA: Nombre de la Tarea.

• IDENTIFICADOR_TIPO_TAREA: Número de identificador del tipo de

tarea asociado a la tarea.

• IDENTIFICADOR_FRECUENCIA: Número de identificador de la

frecuencia asociada a la Tarea.

• IDENTIFICADOR_ENTIDAD: Número de identificador de la entidad

asociada a la tarea.


122

Tabla TIPOS_TAREAS: tabla en que se almacena toda la información relativa a

tipos de tareas. Dicha tabla cuenta con los siguientes campos:

• IDENTIFICADOR_TIPO_TAREA: Número de identificador del tipo de

tarea.

• NOMBRE_TIPO_TAREA: Nombre del tipo de tarea.

• DESCRIPCIÓN_TIPO_TAREA: descripción del tipo de la tarea (opcional).

Tabla FRECUENCIAS: tabla en que se almacena toda la información relativa a

frecuencias. Dicha tabla cuenta con los siguientes campos:

• IDENTIFICADOR_FRECUENCIA: Número de identificador de la

frecuencia.

• NOMBRE_FRECUENCIA: Nombre de la tarea.

• DESCRIPCIÓN_TIPO_TAREA: descripción de la frecuencia (opcional).


123

5. Estudio de la

Arquitectura


124

5. ESTUDIO DE LA ARQUITECTURA

5.1. INTRODUCCIÓN

En este apartado se describe la arquitectura seleccionada para el proyecto así como

los distintos recursos Software y Hardware requeridos para el posible desarrollo y

explotación de la aplicación.

5.2. ARQUITECTURA SOFTWARE

El proyecto se ha realizado bajo el sistema operativo Windows XP Profesional. El

proceso de documentación y preparación de su formato se ha realizado mediante

Microsoft Office Word 2003, mientras que para la realización de los distintos

diagramas y gráficos se ha utilizado Microsoft Office Power Point 2007.

La tecnología que se va a utilizar para el desarrollo de la aplicación será JAVA. Para

ello, vamos a hacer uso de dos entornos de desarrollo integrados: Eclipse SDK y

NetBeans IDE 6.5.

La plataforma NetBeans permite que las aplicaciones sean desarrolladas a partir de

un conjunto de componentes de software llamados módulos. Un módulo es un

archivo Java que contiene clases de java escritas para interactuar con las API’s de

NetBeans y un archivo especial (manifest file) que lo identifica como módulo. Las

aplicaciones construidas a partir de módulos pueden ser extendidas agregándole

nuevos módulos.


125

Debido a la modularidad ofrecida por NetBeans, se subdividirá la codificación en dos

partes:

1) Diseño exterior de las pantallas (diseño gráfico). La herramienta empleada

para el desarrollo será NetBeans.

2) Diseño interno (lógica de la aplicación). La herramienta empleada en este

caso será Eclipse SDK.

En el desarrollo de la base de datos se va a utilizar Microsoft Office Access 2003

para garantizar la viabilidad de intercambio de información entre ambos sistemas

puesto que es el sistema de gestión de bases de datos relacional más extendido en

todo el mundo empresarial. Como ya se ha comentado anteriormente, se pretende

que el sistema sea escalable por lo que su uso puede ser extendido en el futuro a otras

aplicaciones de gestión de datos tales como MySQL o SQL Server.

La Gestión de Activos se realiza actualmente en nuestra empresa mediante la

herramienta de Gestión de activos empresariales Infor EAM Enterprise Asset

Management, más conocido como DATASTREAM.

Por último, comentar que cualquiera de las aplicaciones de Gestión de Compras

usada por los clientes (SAP, ORACLE, NAVISION, etc.) tiene características

similares a la herramienta Infor EAM.


126

5.3. ARQUITECTURA HARDWARE

El proyecto se va a realizar, tanto el desarrollo de la aplicación como el de la

documentación, sobre un Packard Bell modelo EasyNote, que cuenta con un

procesador Intel Pentium M 1,73 GHz.

La impresora utilizada para las pruebas de impresión de ficheros corresponde a un

modelo HP PSC 750.

La empresa en la que trabajamos y, por lo tanto, que cuenta con el Sistema de

Gestión de Activos DATASTREAM instalado, cuenta con una serie de ordenadores

que cuentan con las siguientes especificaciones:

• Hewlett-Packard Company HPCompaq dc7800 Convertible

• Intel Core 2 Duo CPU E8300 @2.83GHz con 1,95 GHz de RAM

• Microsoft Windows XP Profesional Service Pack 2

Para la óptima visualización de la herramienta se debe establecer una resolución de

pantalla de 1440x900 píxeles.


127

6.6.6.6. Diseño


128

6. DISEÑO

6.1. INTRODUCCIÓN

En esta fase del proyecto se va a proceder a mostrar las diferentes ventanas de

entrada y salida de datos del sistema. El programa empleado para la elaboración de

las pantallas es NetBeans IDE 6.5.

6.2. MODELO FÍSICO DE PROCESOS

El modelo físico de procesos representa la estructura del sistema y la organización de

sus componentes:

• Componentes: aplicaciones, programas, módulos, procedimientos.

• Organización de dichos componentes.

Un modelo físico puede ser interpretado con diagramas de estructura, con

flujogramas, con esquemas de proceso o con una combinación de éstos. En nuestro

caso, hemos optado por realizarlos en pseudocódigo de alto nivel.


129

6.2.1. PSEUDOCÓDIGO PROCESO GESTIÓN ENTIDADES DS

(PFC_PRO_01)

Cargar_Datos (Entidades_DS)

Si (Opción = Modificar) Entonces

Leer (Nombre_Entidad_DS)

Actualizar_Entidad (Id_Entidad_DS,

Nombre_Entidad_DS, Nombre_Empresa_Sistema_DS)

Fin Si

Si (Opción = Dar de Baja) Entonces

Borrar_Entidad (Id_Entidad_DS)

Fin Si

Si (Opción = Dar de Alta) Entonces

Leer (Nombre_Entidad_DS)

Insertar_Entidad (Nombre_Entidad_DS,

Nombre_Empresa_Sistema_DS)

Fin Si

6.2.2. PSEUDOCÓDIGO PROCESO GESTIÓN DE ATRIBUTOS DS

(PFC_PRO_02)


Cargar_Datos (Atributos_DS)


130


Leer (Nombre_Atributo_DS)

Actualizar_Atributo (Id_Entidad_DS,

Nombre_Entidad_DS, Id_Atributo_DS,

Nombre_Atributo_DS, Nombre_Empresa_Sistema_DS)

Fin Si


Borrar_Atributo (Id_Atributo_DS)

Fin Si


Leer (Nombre_Atributo_DS)

Insertar_ Atributo (Id_Entidad_DS,

Nombre_Entidad_DS, Nombre_Atributo_DS,

Nombre_Empresa_Sistema_DS)

Fin Si

6.2.3. PSEUDOCÓDIGO PROCESO GESTIÓN DE ENTIDADES SGC

(PFC_PRO_03)

Cargar_Datos (Nombre_Empresa_Sistema_SGC)

Cargar_Datos (Entidades_SGC)



131

Leer (Nombre_Entidad_SGC)

Actualizar_Entidad (Id_Entidad_SGC,

Nombre_Entidad_SGC, Nombre_Empresa_Sistema_SGC)

Fin Si


Borrar_Entidad (Id_Entidad_SGC)

Fin Si


Leer (Nombre_Entidad_SGC)

Insertar_Entidad (Nombre_Entidad_SGC,

Nombre_Empresa_Sistema_SGC)

Fin Si

6.2.4. PSEUDOCÓDIGO PROCESO GESTIÓN DE ATRIBUTOS SGC

(PFC_PRO_04)



Cargar_Datos (Atributos_SGC)


Leer (Nombre_Atributo_SGC)

Actualizar_Atributo (Id_Entidad_SGC,


132

Nombre_Entidad_SGC, Id_Atributo_SGC,

Nombre_Atributo_SGC, Nombre_Empresa_Sistema_SGC)

Fin Si


Borrar_Atributo (Id_Atributo_SGC)

Fin Si


Leer (Nombre_Atributo_SGC)

Insertar_ Atributo (Id_Entidad_SGC,

Nombre_Entidad_SGC, Nombre_Atributo_SGC,

Nombre_Empresa_Sistema_SGC)

Fin Si

6.2.5. PSEUDOCÓDIGO PROCESO GESTIÓN DE CASOS (PFC_PRO_05)



Cargar_Datos (Atributos_DS)


Cargar_Datos (Atributos_SGC)

Cargar_Datos (Casos)



133

Borrar_Caso (Id_Caso)

Fin Si


Leer (Nombre_Caso)

Insertar_ Caso (Id_Entidad_DS,

Id_Entidad_SGC, Id_Atributo_DS, Id_Atributo_SGC)

Fin Si

6.2.6. PSEUDOCÓDIGO PROCESO GESTIÓN DE JOBS (PFC_PRO_06)

Cargar_Datos (Usuarios)

Cargar_Datos (Jobs)


Leer (Nombre_Job)

Leer (Descripción_Job)

Actualizar_Job (Id_Job,

Nombre_Job, Descripción_Job, Usuario)

Fin Si


Borrar_Job (Id_Job)

Fin Si



134

Leer (Nombre_Job)

Leer (Descripción_Job)

Insertar_Job (Nombre_Job, Descripción_Job,

Usuario)

Fin Si

6.2.7. PSEUDOCÓDIGO PROCESO GESTIÓN DE TAREAS (PFC_PRO_07)

Cargar_Datos (Jobs)

Cargar_Datos (Tipos_de_Tareas)

Cargar_Datos (Frecuencias)

Cargar_Datos (Entidades)

Cargar_Datos (Tareas)


Borrar_Tarea (Id_Tarea)

Fin Si


Leer (Nombre_Tarea)

Insertar_ Tarea (Id_Job, Nombre_Tarea,

Id_Tipo_Tarea, Id_Frecuencia, Id_Entidad)

Fin Si


135

6.2.8. PSEUDOCÓDIGO PROCESO GESTIÓN DE FRECUENCIAS

(PFC_PRO_08)

Cargar_Datos (Frecuencias)


Leer (Nombre_Frecuencia)

Leer (Descripción_Frecuencia)

Actualizar_Frecuencia (Id_Frecuencia,

Nombre_Frecuencia, Descripción_Frecuencia)

Fin Si


Borrar_Frecuencia (Id_Frecuencia)

Fin Si


Leer (Nombre_Frecuencia)

Leer (Descripción_Frecuencia)

Insertar_Frecuencia (Nombre_Frecuencia,

Descripción_Frecuencia)

Fin Si


136

6.2.9. PSEUDOCÓDIGO PROCESO GESTIÓN DE TIPOS DE TAREAS

(PFC_PRO_09)

Cargar_Datos (Tipos_de_Tareas)


Leer (Nombre_Tipo_de_Tarea)

Leer (Descripción_Tipo_Tarea)

Actualizar_Tipo_de_Tarea (Id_Tipo_de_Tarea,

Nombre_Tipo_de_Tarea,

Descripción_Tipo_de_Tarea)

Fin Si


Borrar_Tipo_de_Tarea (Id_Tipo_de_Tarea)

Fin Si


Leer (Nombre_Tipo_de_Tarea)

Leer (Descripción_Tipo_de_Tarea)

Insertar_Tipo_de_Tarea (Nombre_Tipo_de_Tarea,

Descripción_Tipo_de_Tarea)

Fin Si


137

6.2.10. PSEUDOCÓDIGO PROCESO GESTIÓN DE EMPRESAS -

SISTEMAS (PFC_PRO_10)

Cargar_Datos (Empresas_Sistemas)


Borrar_Empresa_Sistema (Id_Empresa_Sistema)

Fin Si


Leer (Nombre_Empresa_Sistema)

Leer (Descripción_Empresa_Sistema)

Insertar_Tipo_de_Tarea (Nombre_Empresa_Sistema,

Descripción_Empresa_Sistema)

Fin Si

6.2.11. PSEUDOCÓDIGO PROCESO GESTIÓN DE USUARIOS

(PFC_PRO_11)

Cargar_Datos (Empresas_Sistemas)

Cargar_Datos (Usuarios)


Borrar_Usuario(Id_Usuario)

Fin Si



138

Leer (Nombre_Usuario)

Leer (Contraseña)

Insertar_Usuario (Nombre_Usuario, Contraseña)

Fin Si

6.3. MODELO FÍSICO DE LA BASE DE DATOS

El modelo físico de datos representa la organización física de los datos en:

• Bases de datos y archivos integrados por registros que se almacenan juntos

físicamente.

• Agrupación de registros en áreas de almacenamiento físico (áreas, “table

spaces”, etc.), donde residirán físicamente los datos.

• Forma en que físicamente se almacenan las interrelaciones entre registros

(índices, apuntadores, claves extranjeras, claves secundarias, etc.).

A continuación se muestra una captura del modelo físico de nuestro sistema,

realizado con MS Access 2003, herramienta en la que se ha construido toda la base

de datos:


a de gestión


a de gestión

de compras


7.7.7.7. Programación


141

7. PROGRAMACIÓN

7.1. INTRODUCCIÓN

En esta fase del proyecto se va a proceder a la construcción del sistema según los

criterios establecidos dando como resultado un conjunto de programas que puedan

ser ejecutados de forma correcta y cumpliendo con los diseños de funcionalidad

establecidos en puntos anteriores.

Para ello, se va a seguir una rutina de pasos a seguir en la elaboración de cada unidad

por separado, analizando 3 puntos clave:

• Entradas: todos los datos de ingreso en la aplicación.

• Procesos: son los diferentes procedimientos en los cuales se usarán los datos

proporcionados por el usuario.

• Salidas: resultado de estos procesos.

Una buena definición del problema, junto con una descripción detallada de las

especificaciones de entrada y salida, son los requisitos más importantes para llegar a

una solución eficaz.

Una vez se hayan desarrollado todas las unidades del programa, se procederá a la

elaboración del manual de usuario y de implantación asociados que expliquen

detalladamente todas las especificaciones descritas en este mismo apartado.


142

7.2. DISEÑO DEL INTERFAZ DE USUARIO

A continuación se van a especificar los criterios empleados para la elaboración del

diseño de la Interfaz del sistema.

Para ello se adjuntan varias capturas que contienen imágenes de los componentes

seleccionados para la resolución del problema de cada unidad del programa (descrito

en el apartado anterior). Los componentes corresponden a elementos de diseño de la

aplicación NetBeans IDE 6.5.

7.2.1. CRITERIOS

El objetivo es construir una aplicación sencilla, lo más intuitiva posible que facilite

su explotación por parte del usuario.

Para ello se ha optado por utilizar el sistema de formularios proporcionado por la

herramienta NetBeans IDE 6.5. Estos formularios permiten la inserción de paneles en

los cuales se pueden agregar de forma intuitiva los componentes que se requieran así

como la navegación entre estos diferentes paneles.

El diseño incluye, de igual manera, el propio diseño de ventanas emergentes las

cuales pueden tener distintas funcionalidades:

• Aviso de un error.


143

• Aviso de carácter informativo.

• Ingresado de datos

• Aceptación o cancelación de una operación (validación).

NetBeans ofrece una serie de componentes aptos para ser ubicados dentro de los

formularios. Estos componentes se van a utilizar para la gestión de información de

entrada y salida, por lo que se considera de alta importancia una buena selección de

los mismos. A continuación se muestra un listado de los componentes ofrecidos para

el manejo de esta información:

• CheckBox/RadioButton: permite al usuario la selección

de una opción añadida. Su estado puede ser seleccionado

o no seleccionado.

• ComboBox: permite al usuario la selección entre un

conjunto de opciones. Estas opciones habrán sido

previamente cargadas desde la base de datos.

• TextBox: permite tanto el ingreso de datos como

el mostrado de éstos. Para mayor información se

suele acompañar de un Label en el que se describe

su título así como de un Tooltip con información adicional sobre el dato.


144

• TextArea: permite al usuario la introducción de una

cantidad numerosa de caracteres (para descripciones,

por ejemplo). Se suele acompañar de una barra de Scroll

vertical y así como de una horizontal para facilitar su visionado.

• Table: permite al usuario la introducción y

visualización ordenada de una alta cantidad de datos

en un mismo elemento. Se puede acompañar de igual

manera de una barra de Scroll vertical y horizontal para facilitar su visionado.

• Button: permite al usuario provocar el comienzo de una

acción o proceso, la cual será brevemente descrita mediante

un texto contenido en el interior del propio botón así como de

un Tooltip si fuera necesario la ampliación de ésta información.

• Menú: permite al usuario la navegación entre las

Diferentes pantallas de la aplicación.


145

7.2.2. DISEÑO DE FORMULARIOS

En este apartado se va a proceder a detallar, ayudándonos de imágenes realizadas con

NetBeans, cómo será la disposición de los distintos componentes en el tipo de

formulario final que se va a diseñar para la aplicación.

Diseño del Formulario Principal de la aplicación

Área de Menú Área de Pantallas


146

Diseño del Formulario tipo de Gestión de datos

Áreas de Datos

Botones

ComboBox


147

Diseño del Formulario tipo de salida de datos con componente Table

7.2.3. MANUAL DE USUARIO

Se adjunta como Anexo A.

Tabla de salida de datos


148

8.8.8.8. Pruebas


149

8. PRUEBAS

8.1. INTRODUCCIÓN

Una vez terminada la fase de programación, se va a proceder a realizar un conjunto

de pruebas que van a conseguir la integración total del sistema, así como asegurar los

niveles prefijados inicialmente de calidad y fiabilidad.

Una vez realizadas todas las pruebas, si los resultados son satisfactorios, se procederá

a la implantación del sistema en su entorno de trabajo final. Si, por el contrario, los

resultados no son aceptables, se procederá a la resolución de los problemas que han

causado la no aceptabilidad realizando para ello una documentación completa de éste

proceso; para ello, se describirá cada uno de los problemas, sus causas y las medidas

tomadas para su resolución. Una vez que se hayan subsanado todos los problemas, se

repetirá la etapa de pruebas desde el principio.

Las pruebas que serán llevadas a cabo son las siguientes:

• Pruebas unitarias.

• Pruebas funcionales.

• Pruebas de seguridad.

• Pruebas de explotabilidad.

• Pruebas de aceptación del usuario.

• Pruebas de regresión.


150

8.2. PRUEBAS UNITARIAS

Consiste en la comprobación del funcionamiento de todo el sistema según las

especificaciones iniciales. Para ello, las pruebas se realizarán de forma unitaria,

comprobando el funcionamiento correcto de cada unidad de la aplicación.

Ésta fase se incluye dentro de la fase de programación.

8.3. PRUEBAS FUNCIONALES

Consiste en comprobar que se cumplen todas las funciones de la aplicación tal y

como se habían prefijado en las etapas de análisis de requisitos y diseño físico de

procesos. Algunas de estas funciones se resumen a continuación:

• Acceso óptimo a la base de datos.

• Coherencia de los datos de la base de datos.

• Ubicación correcta de los datos en el Interfaz de la aplicación.

• Contenido correcto de los datos en cada ubicación.

• Correcto funcionamiento de los filtros de datos.

• Correcto funcionamiento de los ficheros de salida de datos.

• Contenido correcto de los ficheros de salida.

• Correcto funcionamiento de la gestión de datos desde la Interfaz contra la base

de datos.


151

8.4. PRUEBAS DE SEGURIDAD

Consiste en la comprobación del cumplimiento de los mecanismos de seguridad del

sistema en cuanto a accesibilidad del sistema (gestión de contraseñas así como

vulnerabilidad del sistema de encriptado) y el acceso a datos según el perfil del

usuario que accede a la aplicación.

8.5. PRUEBAS DE ACEPTACIÓN DEL USUARIO

El objetivo de estas pruebas es la aceptación del sistema por parte de los usuarios

finales de la aplicación; en nuestro caso, ésta labor será llevada a cabo por el

administrador de la herramienta, perteneciente a nuestra propia empresa, así como

por parte de los usuarios que van a interactuar con ella desde nuestras empresas

cliente. Se debe verificar la facilidad de uso de la herramienta.

La aceptación de todos los intervinientes en ésta prueba supone la aprobación final

para la implantación del sistema en el entorno de trabajo real.

8.6. PRUEBAS DE REGRESIÓN

Una vez realizadas todas las pruebas anteriores, y justo antes de la fase de

implantación, se hará una revisión del sistema para su optimización teniendo en

cuenta los resultados obtenidos en éstas.

Ésta fase se realizará tantas veces como sea necesario hasta que el sistema cumpla

con todos los requisitos establecidos.


152

9.9.9.9. Implantación


153

9. IMPLANTACIÓN

Una vez hayan sido realizadas todas las pruebas dando como resultado la aceptación

final del sistema, se va a proceder a la implantación de éste en el entorno real de

producción en el que se va a llevar a cabo su explotación.

La implantación del sistema supone la preparación de las estaciones de trabajo de los

usuarios finales que van a usarla. Para empezar, se deben revisar las características

Hardware de los equipos donde se va a instalar el sistema comprobando que cuentan

con unos requisitos mínimos necesarios para asegurar su correcto funcionamiento;

ésta tarea se realizará para todas nuestras empresas cliente. A continuación, se

procederá a instalar en todos los equipos el conjunto de aplicaciones desarrolladas así

como el software necesario para posibilitar su correcto acceso y uso.

Dado que el sistema da opción a impresión de ficheros, se debe comprobar el

correcto funcionamiento de la/s impresora/s en línea realizando las configuraciones

necesarias si fuese necesario.

Una vez se haya realizado la completa integración del sistema, se procederá a

realizar una serie de pruebas que aseguren el correcto funcionamiento del sistema. La

aceptación final del usuario significará el final de esta etapa.


154

10.10.10.10. Presupuesto


155

10. PRESUPUESTO

10.1. INTRODUCCIÓN

En este apartado se va a proceder a realizar una valoración económica de los costes

asociados al desarrollo e implantación del presente proyecto. Para ello, se ha

decidido dividir la valoración en dos partes:

• Valoración económica del personal por paquete de trabajo.

• Costes Hardware y Software.

10.2. DIVISIÓN DE COSTES

En este apartado se va a realizar una subdivisión de los costes asociados del proyecto

por persona implicada y paquete de trabajo en el que intervenga, así como de los

costes Hardware y Software asociados al desarrollo.

Para ello recordamos que los intervinientes en el proceso de desarrollo del proyecto

se encuentran especificados en el apartado 3.6 (Organización del Proyecto),

mientras que la subdivisión en paquetes de trabajo se puede encontrar especificado

en el apartado 2.2 (Estructura de Descomposición del Proyecto). Las

especificaciones Software y Hardware, se especifican en los apartados 5.2 y 5.3,

respectivamente.


156

A continuación se muestra el gráfico de valoración económica de personal por

paquete de trabajo en el que interviene:

La estimación de la duración del proyecto es de 1172 horas, que, teniendo en cuenta

las respectivas tarifas del personal que interviene en su desarrollo así como los costes

de Software y Hardware asociados, supone un coste total de 74.885 Euros.


157

11.11.11.11. Conclusiones


158

11. CONCLUSIONES

El desarrollo de un proyecto de esta envergadura, con todo lo que ello conlleva, ha

supuesto un verdadero reto personal. Para su realización, no sólo se ha requerido de

los conocimientos adquiridos durante toda la carrera, sino que se ha requerido un

estudio profundo especializado del sector y de las herramientas que se utilizan

actualmente tanto nuestra empresa (DataStream) como en cualquier otra empresa del

sector. Por otra parte, también ha servido para poder comprobar personalmente el

coste y las dimensiones de la realización de un proyecto real.

La ampliación de conocimientos así como la posibilidad de trabajar en una empresa

de estas características viendo su funcionamiento desde dentro, ha resultado una

experiencia muy enriquecedora y satisfactoria.

Como añadido a todo esto, me ha sido posible aprender mucho sobre aplicaciones

informáticas usadas actualmente en el sector así como la profundización en

aplicaciones de gestión de activos empresariales, en mi caso, DataStream.

En conclusión, el éxito del proyecto no solo se debe al desarrollo y funcionamiento

satisfactorio de un sistema que permite mejorar un proceso actual de nuestra

empresa, con los ahorros de recursos que ello conlleva (tiempo y, por lo tanto,

dinero), sino que también se debe a la satisfacción y enriquecimiento personal por

haberlo realizado con éxito.


159

12.12.12.12. Bibliografía


160

12. BIBLIOGRAFÍA

La mayoría de las fuentes de información utilizadas para el desarrollo del proyecto

están en la Web. A parte, se han utilizado varios manuales especializados en

herramientas de gestión de activos y de compras. Todas ellas se listan a

continuación:

[MAES] “Metodología del Análisis Estructurado de Sistemas”, Jesús Barranco

de Areba, 2001.

[MDLP] “Metodología de la Programación”, Eduardo Alcalde, 2001.

[GPI] Apuntes de la asignatura de Gestión de Proyectos Informáticos, 5º

IINF, ICAI.

[JAVA] Apuntes de la asignatura de programación en JAVA, 2º IINF, ICAI.

[SAP] Apuntes de la asignatura de libre elección SAP/R3, ICAI.

[MOA] “Manual de Ingeniería del Software”, Empresarios Agrupados, 1990.

[DS] “Manual de usuario de la herramienta Datastream 7i”, Empresarios

Agrupados, 2005.


161

• Páginas Web:

[WIKI] Wikipedia, la enciclopedia libre:

http://es.wikipedia.org/wiki/Wikipedia:Portada

[SGA] Sistemas de Gestión de Activos:

http://www.ineco.cl/noticias/tecnicos/sistema-de-gestion-de-activos.htm

[SMPC] Sistema de Mantenimiento Preventivo-Correctivo

http://www.aquadcs.com/Manuales/07_GESTION_ALMACEN.htm

[GCCI] Gestión de Compras, comercio Internacional

http://www.gestiondecompras.com/es/Empresa/Presentacion.php

[SIG] Sistemas Integrados de Gestión

http://www.eumed.net/ce/2008b/rvm.htm

[OM] Optimización del Mantenimiento

http://www.aciem.org/bancoconocimiento/O/OptimacionIntegraldeMantenimiento/O

ptimacionIntegraldeMantenimiento.asp


162

[SGC] Generalidades sobre la Gestión de Compras

http://www.gestiopolis.com/marketing/generalidades-sobre-la-gestion-de-

compras.htm

[IEE] Infor EAM España

http://www.infor.es/

[JAVA2] Programación en JAVA

http://www.geocities.com/jmordax/

[WDP] Foros de la Web del Programador

http://www.lawebdelprogramador.com/news/

[FDW[ Foros del Web

http://www.forosdelweb.com/f45/creacion-tablemodel-680093/

[FJH] Foros JAVA Hispano

http://www.javahispano.org/forum/


163

PARTE II: ANEXOS

Anexo A: Manual de Usuario


164

MANUAL DE USUARIO

1. Acceso a la aplicación.

2. Menú principal Administrador.

2.1. Gestión de Entidades.

2.1.1. Entidades DATASTREAM.

2.1.2. Entidades de SGC.

2.2. Gestión de Atributos.

2.2.1. Atributos DATASTREAM.

2.2.2. Atributos de SGC.

2.3. Gestión de Casos.

2.4. Gestión de Jobs.

2.5. Gestión de Tareas.

2.6. Gestión de Frecuencias.

2.7. Gestión de Tipos de Tareas.

2.8. Gestión de Empresas – Sistemas.

2.9. Gestión de Usuarios.

3. Menú principal Usuario.

3.1. Visualización de Casos.

3.2. Visualización de Jobs – Tareas.


165

1. Acceso a la aplicación.

El acceso a la aplicación comienza con la presentación de la ventana de bienvenida

de la aplicación. Como se puede ver en la imagen, no existe interacción de datos, ya

que se trata de una ventana de transición.

La pulsación en cualquier parte de la ventana produce la navegación hacia la pantalla

de validación de los usuarios. En esta ventana el usuario introduce sus datos de

acceso a la aplicación. Se trata, por tanto, de una ventana de entrada de datos. Si los

datos del usuario no son correctos, se le informa de esta situación mediante una

ventana de diálogo; si, por el contrario, los datos son correctos, se produce la

navegación a la pantalla de Menú de Administrador o la pantalla de Menú de

Usuario, dependiendo de si se trata de un usuario de tipo administrador o de uno de

tipo no administrador, respectivamente. El diseño se muestra a continuación:


166

2. Menú Principal Administrador.

El usuario de tipo administrador tiene la posibilidad de navegar hacia todas las

opciones que ofrece la aplicación tal y como muestra la imagen:


167

2.1. Gestión de Entidades.

2.1.1. Gestión de Entidades de DATASTREAM.

Esta pantalla cuenta con varias funciones: dar de alta nuevas entidades, mostrar las

entidades existentes, modificarlas y/o darlas de baja. Por tanto, se trata de una

pantalla tanto de entrada como de salida. El dato que se solicita para dar de alta una

nueva Entidad de DATASTREAM es el nombre de la propia Entidad; no pueden

existir dos Entidades con el mismo nombre.

El diseño se muestra a continuación:


168

2.1.2. Gestión de Entidades de SGC.

Esta pantalla cuenta con varias funciones: dado de alta de nuevas entidades, listado

de las entidades existentes, modificaciones y/o dado de baja. Por tanto, se trata de

una pantalla tanto de entrada como de salida. La diferencia lógica respecto a la

pantalla de Gestión del Diccionario de entidades de DS es que en ésta pantalla se

ofrece la posibilidad de selección de la empresa – sistema en la que se desea realizar

la gestión. El nombre de la Entidad debe ser único.



169

2.3. Gestión de Atributos.

2.3.1. Gestión de Atributos de DATASTREAM.

Esta pantalla cuenta con varias funciones: selección de la entidad asociada a los

atributos que se desean gestionar, dado de alta de nuevos atributos, listado de los

atributos existentes asociados a la entidad, modificaciones y/o dado de baja. Es una

pantalla tanto de entrada como de salida. El dato que se solicita para dar de alta un

nuevo Atributo de DATASTREAM es el nombre del propio Atributo; no pueden

existir dos Atributos con el mismo nombre.



170

2.3.1. Gestión de Atributos de SGC.

Esta pantalla cuenta con varias funciones: selección de la entidad asociada a los

atributos que se desean gestionar, dado de alta de nuevos atributos, listado de los

atributos existentes asociados a la entidad, modificaciones y/o dado de baja. Es una

pantalla tanto de entrada como de salida. El dato que se solicita para dar de alta un

nuevo Atributo de DATASTREAM es el nombre del propio Atributo; no pueden

existir dos Atributos con el mismo nombre. Por último, se ofrece la posibilidad de

selección de la empresa – sistema en la que se desea realizar la gestión.


171

2.4. Gestión de Casos.

Esta pantalla cuenta con varias funciones: dado de alta nuevos Casos, dada de baja de

estos Casos y listado de las entidades y atributos asociados de nuestra empresa y de

las empresas clientes. Es una pantalla tanto de entrada como de salida. El único dato

requerido para dar de alta es el nombre del Caso, el cual debe ser único.



172

2.5. Gestión de Jobs.

Esta pantalla cuenta con varias funciones: listado de todos los usuarios dados de alta

en el sistema, dado de alta de nuevos Jobs (asociadas al usuario seleccionado

previamente) y dado de baja de estos Jobs. Es una pantalla tanto de entrada como de

salida. Los datos requeridos son el nombre del nuevo Job, el cual debe ser único, y su

descripción, la cual es opcional.



173

2.6. Gestión de Tareas

Esta pantalla cuenta con varias funciones: listado de todos los Jobs dados de alta en

el sistema, dado de alta de nuevas tareas (asociadas al Job seleccionado previamente)

y dado de baja de estas tareas. Es una pantalla tanto de entrada como de salida. Los

datos requeridos para dar de alta son el nombre de la nueva tarea, el cual debe ser

único, el tipo de tarea, la frecuencia y la Entidad a la que va asociada, todos ellos

obligatorios.



174

2.7. Gestión de Frecuencias.

Esta pantalla cuenta con varias funciones: dado de alta de nuevas Frecuencias, listado

de todas las frecuencias dadas de alta previamente en el sistema, modificaciones y/o

dado de baja. Es una pantalla tanto de entrada como de salida. Los datos requeridos

son el nombre de la nueva frecuencia, el cual debe ser único, y su descripción, la cual

es opcional.



175

2.8. Gestión de Tipos de Tareas.

Esta pantalla cuenta con varias funciones: dado de alta de nuevos Tipos de tareas,

listado de todos los Tipos de tareas dados de alta previamente en el sistema,

modificaciones y/o dado de baja. Es una pantalla tanto de entrada como de salida.

Los datos requeridos son el nombre del nuevo tipo de tarea, el cual debe ser único, y

su descripción, la cual es opcional.



176

2.8. Gestión de Empresas - Sistemas.

Esta pantalla cuenta con varias funciones: dado de alta de nuevas empresas con su

SGC asociado, listado de todas las empresas y dado de baja. Es una pantalla tanto de

entrada como de salida. Los datos requeridos son el nombre de la nueva Empresa -

Sistema, el cual debe ser único, y su descripción, la cual es opcional.



177

2.9. Gestión de Usuarios.

Esta pantalla cuenta con varias funciones: dado de alta de nuevos usuarios asociados

a una empresa - sistema, listado de todas las empresas dadas de alta previamente en

el sistema y dado de baja de estos usuarios. Es una pantalla tanto de entrada como de

salida. Los datos requeridos son el nombre del nuevo usuario, el cual debe ser único,

su contraseña y la empresa a cual queda asociado. Todos ellos son obligatorios.



178

3. Menú principal Usuario.

La pantalla Menú Principal – Usuario es similar a la pantalla de Administrador, con

la diferencia obvia del acceso a las pantallas específicas para los usuarios. Como se

observa en la imagen, el usuario es capaz de acceder a todas estas opciones:


179

3.1. Visualización de Casos.

Esta pantalla pertenece al menú de usuarios y cuenta con varias funciones: listado de

todas las entidades asociadas al cliente que ha ingresado en la aplicación, listado en

formato de tabla de todos los casos asociadas a la entidad seleccionada, impresión de

la tabla de tareas en formato papel y generación de un informe con toda esta

información (una guía para estas dos últimas funciones se encuentra descrita en el

Anexo B del presente Proyecto). Es una pantalla sólo de salida.



180

3.2. Visualización de Jobs y Tareas.

Esta pantalla pertenece al menú de usuarios y cuenta con varias funciones: listado de

todos los Jobs asociados al cliente que ha ingresado en la aplicación, listado en

formato de tabla de todas las tareas asociadas al Job seleccionado, impresión de la

tabla de tareas en formato papel y generación de un informe con toda esta

información (una guía para estas dos últimas funciones se encuentra descrita en el

Anexo B del presente Proyecto). Es una pantalla sólo de salida.



181

Anexo B: Manual de Impresión

y creación de Ficheros


182

El presente Anexo pretende ofrecer una guía orientativa para la función de impresión

y creado de ficheros que tienen incorporadas las pantallas de visualización de Casos

y de visualización de Jobs y Tareas. Para acceder a estas opciones, el usuario debe

pulsar el botón de ‘Imprimir’ lo cual hace saltar el asistente de JAVA para

configuración de impresiones, tal y como se puede observar en la siguiente imagen:


183

Configuración de Impresiones.

Si la opción que desea realizar el usuario es la impresión en formato tabla de los

datos, deberá seleccionar una impresora en línea de su red y a continuación realizar

una configuración de la impresión tal y como la desee (pestañas ‘Configurar página’

y ‘Aspecto’).

Si el tamaño de hoja de impresión deseado por el usuario es de tamaño A4, se

recomienda seleccionar la propiedad Orientación Horizontal para su óptima visión.

En el gráfico siguiente se indican estos pasos:


184

Configuración de Ficheros.

Si la opción que desea realizar el usuario es la creación de un fichero que contenga

los datos en formato de tabla, se recomienda la selección por parte del usuario del

servicio de impresión Microsoft XPS Document Writer; ésta opción ofrece la

posibilidad de selección de color de la tabla (en la pestaña ‘Aspecto’), lo cual se

recomienda. A continuación, el usuario debe realizar una configuración del resto de

parámetros tal y como lo desee.


185

El resultado de éste proceso se muestra en la siguiente imagen a modo de ejemplo:

Documents

INTERFAZ UNIVERSAL ENTRE UN SISTEMA DE GESTIÓN DE ACTIVOS ... · industrial (activos industriales) y su uso permite monitorear los costos que genera un activo durante su ciclo de