Gestión y control de incidencias en stock - IIT Comillas · proyecto fin de carrera control y gestiÓn de incidencias en stock autora: miriam serrano conde madrid, septiembre de

PROYECTO FIN DE CARRERA

CONTROL Y GESTIÓN DE INCIDENCIAS EN STOCK

AUTORA: MIRIAM SERRANO CONDE

MADRID, SEPTIEMBRE DE 2007

UNIVERSIDAD PONTIFICIA COMILLAS

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

INGENIERO EN INFORMÁTICA

Autorizada la entrega del proyecto de la alumna:

Miriam Serrano Conde

DIRECTORES DEL PROYECTO

Eduardo Alcalde Lancharro

Fdo.: …………………… Fecha: 07/09/07

Marijke Thierens

Fdo.: …………………… Fecha: 07/09/07

Vº Bº del Coordinador de Proyectos

Eduardo Alcalde Lancharro

Fdo.: …………………… Fecha: 14/09/07

II

Control y gestión de incidencias en stock

Los momentos importantes de la

vida siempre van acompañados

de la familia y los amigos a

todos ellos les dedico este trabajo.

III


AGRADECIMIENTOS

Ahora que finaliza esta etapa de mi vida que tanto me ha aportado. Miro a mi

alrededor y veo que la gente importante sigue conmigo. Agradezco a mis padres, Pilar y

Santiago, su apoyo incondicional en todo momento. A mis hermanos que han sido

comprensivos y pacientes en esos días tan largos de estudio y nerviosismo. Y al resto de

mi familia por haber estado pendientes de mi.

Gracias a Borja que siempre me ha ayudado a seguir hacía delante. También

recordar a todos mis compañeros por todos esos momentos de risas y desesperaciones

que han marcado nuestra carrera que sin ellos no habría sido lo mismo. Y por supuesto a

todos mis amigos que han sido importantísimos en estos años cada uno a su manera.

Un agradecimiento especial a mis directores, los dos han sabido aportarme fuerzas

en los momentos de flaqueza durante el desarrollo de este proyecto. Y a todas aquellas

personas que de una manera o de otra han sido participes de mi formación personal y

profesional.

IV


RESUMEN

La aplicación de gestión y control de incidencias en stock, es una herramienta de

apoyo para el correcto tratamiento de las piezas retenidas en almacenes debido a diversas

causas, tanto las ajenas al proceso como del propio proceso de recepción de piezas.

Este proyecto tratará de proporcionar trazabilidad al flujo de piezas que presenten

algún tipo de problema en el momento de entrada en el almacén, es decir, al intentar ser

procesada en el sistema interno de la empresa surge un conflicto y esa pieza queda parada

en el almacén.

La herramienta también agilizará las comunicaciones entre los distintos

implicados en el proceso de solucionar la incidencia que causa la retención del material,

además de solucionar muchas de ellas de manera automática. De esta forma se podrán

evitar sobrecargas de trabajo. Para agilizar el proceso se habilitará la posibilidad de filtrar

las incidencias según su tipología y poder así priorizar en función de su importancia. La

herramienta proporcionará además la posibilidad de disponer de estadísticas relativas a

los mencionados incidentes para cada uno de los almacenes de la empresa.

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

de cada pieza. Estos usuarios son almacén, logística, administrador y supervisores.

Cada uno de los cuatro perfiles tiene unas funciones específicas y no tienen la

posibilidad de realizar partes del proceso que no estén estipuladas por los requisitos

evitando así posibles errores o cambios no supervisados.

Las funciones básicas de cada uno de ellos son:

Usuarios de almacén: Darán de alta piezas con algún tipo de incidencia y las

procesarán cuando esté resuelto el problema.

Usuarios de logística: Serán los encargados de la resolución y el seguimiento de

cada una de las piezas que hayan sido dadas de alta en el almacén.

V


Usuarios administrador: Comprenden a su vez dos subcategorías: la primera

dispondrá de mayores privilegios dentro del ámbito del almacén, y la segunda tendrá

todos los privilegios existentes en la aplicación.

Usuarios informativos: Estos usuarios sólo tendrán acceso a la aplicación de

forma informativa no tendrán la posibilidad de realizar ningún cambio dentro de la

aplicación.

El ciclo de vida del proyecto se basa en un modelo evolutivo o incremental. Se

parte de unos requisitos básicos para una primera iteración, una vez alcanzados se va

incrementado la complejidad de las iteraciones con el objetivo de conseguir una

herramienta más eficiente. El proyecto consta de diversos procesos para el tratamiento de

cada una de las incidencias, luego para su análisis y compresión se mezcla el modelo

anterior con el utilizado por Edgard Yourdon, que es un modelo orientado a funciones y

procesos. La combinación de estos dos modelos facilita el desarrollo de la herramienta.

VI


ABSTRACT

The stock-incident control and management application is a software facility

designed in order to be a support for the correct management of the retained pieces in a

store due to either the operative of the receipt process or other external issues.

The project will try to provide a full solution for these pieces presenting any kind

of problem in the admission process at the store. If any incident arises when a piece is

being processed by the internal system of the store, the new facility will manage such

incident and will collect all the available information in order to coordinate all the

members involved in the settlement of the incident.

The new application not only will speed up the internal communication among

personnel involved in the resolution of the event causing the piece retention but also will

solve many of these incidents automatically. In this sense, a great amount of time and

work will be saved. The application will include a function that will provide the

possibility of filtering the incidents attending to its type in order to attach the adequate

importance to each one of them. Another functionality available will be the statistical

information provided for each of the stores separately.

Four types of users with different roles in the piece processing have been

identified: store, logistics, administrator and information

Each one of these users has their own assigned tasks and is entitled to execute just

certain parts of the process. They will not be allowed to operate in parts of the process

they are supposed not to take part in avoiding errors and unauthorized changes.

Basic functions of the users are listed below:

Store users: They will register the pieces causing the incidence and will process

them as soon it becomes solved.

VII


Logistic users: They will be in charge of the registered pieces and will be in

charge of the follow-up and resolution of the incidence.

Administrator users: Comprises two different types, first of them will have full

access to the part of the application regarding the store; the second one will have full

access to the application.

Information users: They will only be able to access the application in a read-only

basis. They are not allowed to change anything regarding the process status.

The Project life cycle is based in a increasing-evolutive model. Starting from

some basic requirements for a first iteration and once reached such requirements,

complexity is progressively increasing in successive iterations in order to get a more

efficient tool. The project comprises several processes for the management of each kind

of event, for a further development uses a model like Edgard Yourdon’s function and

process-oriented model. The combination of both models makes the development of the

tool easier.

VIII


ÍNDICE

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

1. IDENTIFICACIÓN DE NECESIDADES................................................................ 3

1.1. INTRODUCCIÓN .............................................................................................. 4

1.2. OBJETIVOS DEL SISTEMA............................................................................. 5

1.3. ALCANCE DEL SISTEMA ............................................................................... 6

1.4. TIPOLOGÍA DE USUARIO............................................................................. 10

1.5. RESTRICCIONES............................................................................................ 11

1.6. ORGANIZACIÓN Y FUNCIONES EMPRESARIALES................................ 11

1.7. ANTECEDENTES ........................................................................................... 13

2. ANÁLISIS DE REQUISITOS ................................................................................. 16

2.1. INTRODUCCIÓN ............................................................................................ 17

2.2. DESCRIPCIÓN DEL PROCESO DE UNA INCIDENCIA ............................. 18

2.3. LISTA DE REQUISITOS................................................................................. 23

2.4. CARACTERÍSTICAS DE LOS REQUISITOS................................................ 24

2.5. DIAGRAMA DE CONTEXTO ........................................................................ 40

2.6. DIAGRAMA DE PRIMER NIVEL.................................................................. 41

2.7. DIAGRAMAS DE SEGUNDO NIVEL............................................................ 46

3. ARQUITECTURA.................................................................................................... 65

3.1. INTRODUCCIÓN ............................................................................................ 66

3.2. RECURSOS SOFTWARE................................................................................ 66

IX


3.3. RECURSOS HARDWARE.............................................................................. 68

4. DISEÑO DE ENTRADAS Y SALIDAS ................................................................. 69

4.1. INTRODUCCIÓN ............................................................................................ 70

4.2. DISEÑO DE VENTANAS ............................................................................... 70

5. IMPLEMENTACIÓN .............................................................................................. 84

5.1. INTRODUCCIÓN ............................................................................................ 85

5.2. ENTORNO ASP ............................................................................................... 85

5.3. TRATAMIENTO DE LA BASE DE DATOS ................................................. 93

5.4. SCRIPT’S & JAVASCRIPT........................................................................... 101

5.5. TAREAS PROGRAMADAS.......................................................................... 103

6. PLAN DE PRUEBAS ............................................................................................. 104

6.1. INTRODUCCIÓN .......................................................................................... 105

6.2. PRUEBAS UNITARIAS ................................................................................ 105

6.3. PRUEBAS FUNCIONALES.......................................................................... 106

6.4. PRUEBAS DE SEGURIDAD......................................................................... 106

6.5. PRUEBAS DE ACEPTACIÓN ...................................................................... 107

6.6. PRUEBAS DE REGRESIÓN ......................................................................... 108

7. PLANIFICACIÓN REAL...................................................................................... 109

8. VALORACIÓN ECONÓMICA............................................................................ 113

8.1. INTRODUCCIÓN .......................................................................................... 114

8.2. COSTES DE PERSONAL .............................................................................. 114

X


8.3. COSTES DE SOFTWARE ............................................................................. 115

8.4. COSTES DE HARDWARE............................................................................ 116

8.5. COSTES TOTALES ....................................................................................... 117

9. CONCLUSIONES................................................................................................... 118

ANEXO A ...................................................................................................................... 120

ANEXO B ...................................................................................................................... 141

1


INTRODUCCIÓN

La función de la herramienta implementada consiste en gestionar las posibles

incidencias que se produzcan durante el flujo de entrada y salida de stock en el almacén.

La aplicación facilita las comunicaciones entre los distintos departamentos que estén

involucrados en dar una solución a la incidencia, además se encarga de la automatización

del cruce de sistemas de la propia empresa y resolución automática de algunas de las

incidencias. Toda la información volcada en la aplicación quedará registrada y

conformará una valiosa fuente de información estadística.

Los usuarios de la aplicación se dividen en cuatro perfiles con unas funciones

específicas y para mayor seguridad no tienen la posibilidad de realizar partes del proceso

que no estén estipuladas.

Usuarios de almacén: Darán de alta piezas con algún tipo de incidencia y las

procesarán cuando esté resuelto el problema.

Usuarios de logística: Serán los encargados de la resolución y el seguimiento de

cada una de las piezas que hayan sido dadas de alta en el almacén.

Usuarios administrador: Comprenden a su vez dos subcategorías: la primera

dispondrá de mayores privilegios dentro del ámbito del almacén, y la segunda tendrá

todos los privilegios existentes en la aplicación.

2


Usuarios informativos: Estos usuarios sólo tendrán acceso a la aplicación de

forma informativa no tendrán la posibilidad de realizar ningún cambio dentro de la

aplicación.

3


Capítulo 1 Identificación de

necesidades

4


1. IDENTIFICACIÓN DE NECESIDADES

1.1. INTRODUCCIÓN

En esta fase del proyecto es importante establecer las relaciones con los

responsables involucrados en el desarrollo del mismo. En el transcurso de estos contactos

se establecen los puntos básicos para iniciar el modelado de la herramienta: se identifican

las diferentes tipologías de usuarios, se recaban cada uno de los requerimientos y

necesidades de dichos usuarios y se establecen así los objetivos y alcance el proyecto.

La obtención de la información se realiza a través de entrevistas con la gerente del

departamento de logística y con la gerente de los almacenes. Estas entrevistas clarifican

los objetivos que se esperan de la aplicación por parte de cada departamento y ayudan a

establecer el alcance del proyecto.

En esta fase además se presentan los antecedentes del proyecto, que son

fundamentales para profundizar en la comprensión del funcionamiento y la motivación

para el desarrollo de esta herramienta.

5


1.2. OBJETIVOS DEL SISTEMA

El objetivo final del sistema es unificar todos los datos de las piezas que

produzcan alguna incidencia para poder centralizar toda la información y facilitar así su

gestión. De esta manera se conseguirá un control superior y una mayor velocidad en el

procesamiento de la información lo que redundará en un menor número de retenciones de

material en los almacenes. Con esto se busca evitar la paralización de rotación de los

inventarios ya que la paralización de una pieza en almacén por presentar un problema

supone una pérdida de espacio para el almacén y de dinero para la empresa en conjunto.

La herramienta debe ofrecer la posibilidad de que exista una comunicación entre

las partes, donde cada implicado en el proceso de resolución de la incidencia pueda

interactuar con el resto de compañeros para dar solución al problema.

Estos dos objetivos son los prioritarios para el arranque del sistema aunque

existirán otros objetivos no vitales, que darán mayor funcionalidad a la herramienta que

se pretende desarrollar: la posibilidad de cruzar los datos introducidos en la aplicación

con los sistemas internos de la empresa y localizar las incidencias; posibilidad de

modificar el status en el que se encuentra una pieza; habilitar una función que permita

revisar piezas que han sido procesadas y la creación de un histórico.

6


1.3. ALCANCE DEL SISTEMA

El alcance del sistema es muy amplio y, a medida que el proyecto siga su cauce,

éste podrá variar en ciertos aspectos realizando ampliaciones del mismo. El alcance real

es la creación de una base de datos única donde se centralicen y gestionen todas las

incidencias de stock y a la que tengan acceso todos los usuarios implicados.

Un mayor detalle del alcance del proyecto se detalla a continuación:

Unificación total de los datos

El objetivo básico es unificar todos los datos necesarios para la resolución de las

incidencias así como los de control de las mismas.

Todos estos datos se encuentran distribuidos en distintas bases de datos y en

diversos ficheros Excel. El manejo y control de éstos produce un problema de integridad

y coherencia de datos, presentándose problemas de duplicidad, pérdidas y otros errores

que hacen difícilmente controlable un volumen elevado de incidencias de stock. Por

tanto, esta unificación, además de aportar integridad de los datos, también proporcionará

un acceso más rápido y fiable a los mismos por todos los usuarios.

Se cargarán todos los datos existentes en los distintos soportes y se creará un

acceso donde se habilite la posibilidad de introducir en la base de datos los datos de las

7


piezas que tengan una incidencia en el almacén. De esta forma, siempre se tendrá la

última información del estado de las piezas.

Creación y gestión de perfiles de usuarios

Se tratará de realizar distintos perfiles de usuarios donde cada uno de ellos tenga

una serie de funcionalidades para resolver las incidencias recogidas en la aplicación.

Cada uno de estos perfiles contiene un número de usuarios los cuales tienen identificador,

para que quede constancia de las acciones que realiza cada usuario de la aplicación.

En un principio se plantean cuatro tipos de usuarios que se dividen en:

trabajadores del departamento de logística, personal del almacén, administrador de la

aplicación y un usuario con un acceso sólo informativo. El conjunto de acciones que

podrá realizar cada uno de los usuarios se describirá con mayor detalle más adelante en el

presente documento.

Comunicación fiable en la resolución de incidencias

Los dos puntos anteriores hacen posible cumplir con este objetivo. Hasta el

momento la comunicación entre las distintas partes se ha venido realizando mediante el

envió de correos electrónicos adjuntando los diversos ficheros. Sin embargo, el aumento

en número y tamaño de éstos, hace que el tratamiento sea cada vez más tedioso y menos

fiable por lo que se plantea como objetivo que la herramienta agilice el flujo de

información de tal forma que ésta esté permanentemente actualizada. Para ello se

8


utilizará Internet que habilita la posibilidad de acceso por todos los usuarios que tendrán

así la posibilidad de ver los cambios en tiempo real.

Automatización de los cruces con las BBDD de HP y reconocimiento automático de las

incidencias

Las incidencias se deben resolver en los sistemas internos de la empresa. Para ello

toda la información de las incidencias recogidas en la herramienta serán cruzadas con la

información de las piezas de las bases de datos del sistema interno de HP, para poder así

identificar el tipo de incidencia de cada una de las piezas y agilizándose de esta manera la

resolución de estas.

Verificación de piezas procesadas

Realizar un nuevo cruce de base de datos para comprobar que las piezas que han

sido procesadas en el almacén están correctamente procesadas en los sistemas internos.

Es una manera de supervisar el trabajo que se realiza en los almacenes.

Gestión y acceso a datos históricos

Crear una base de datos donde se almacene toda la información de las piezas

procesadas hasta el momento. Implementar junto a la base de datos un sistema de

búsqueda dicha información para el usuario.

9


Resolución de piezas duplicadas

Debido al gran número de tablas existentes en el sistema interno y a que en esas

tablas existen duplicidades, el cruzamiento de datos con la herramienta genera líneas

duplicadas que en un principio se resolverán de manera manual. El nuevo objetivo se

fijado es la resolución del máximo número de estas duplicidades de forma automática.

Obtención de estadísticas de datos sobre el estado del stock retenido

Con los datos recogidos en la aplicación se mostrará la información del número de

piezas que existe en cada estado para poder así priorizar qué incidencias son más críticas.

Además se mostrará el número de piezas procesadas hasta el momento y el total de piezas

existentes en el momento actual.

10


1.4. TIPOLOGÍA DE USUARIO

La aplicación que se pretende diseñar esta orientada a solventar el problema de la

llegada de piezas con errores. Por eso es una herramienta enfocada a los trabajadores de

la compañía y habrá que controlar el acceso de otras personas ajenas a ella. Es importante

establecer cuáles serán las funciones de cada uno de los usuarios así como los privilegios

mínimos de los que habrá que dotar a cada uno para que puedan ejercer sus funciones.

El alta, baja y modificación de permisos de los usuarios será una función única del

administrador de la aplicación. A cada usuario se le proveerá de nombre y clave para

posibilitar su acceso a la aplicación.

Los cuatro perfiles de usuarios que se van a crear son: (1) para empleados de los

almacenes; (2) para los trabajadores del departamento de logística; (3) perfil informativo

y por último; (4) el administrativo.

Cada uno de los perfiles tendrá las siguientes funcionalidades:

Perfil de almacén: Darán de alta piezas con algún tipo de incidencia y las

procesarán cuando los responsables hayan resuelto el problema.

Perfil de logística: Responsable de dar solución y el seguimiento de cada una de

las piezas que hayan sido dadas de alta en el almacén.

11


Perfil administrador: Este perfil tiene como función gestionar y controlar el buen

funcionamiento de la herramienta. Será el encargado de dar de alta a nuevos usuarios,

modificar campos que otros perfiles no tengan permitidos. Realizar el paso al histórico de

la pieza, controlar el cruce de sistemas y la duplicidad de líneas.

Perfil informativo: Estos usuarios sólo tendrán acceso a la aplicación a título

informativo de tal forma que no tendrán la posibilidad de realizar ningún cambio dentro

de la herramienta.

1.5. RESTRICCIONES

La falta de tiempo es la principal restricción del proyecto. La misma que tienen

todos los proyectos de desarrollo de software hoy en día. La aplicación es necesaria

cuanto antes debido a que el problema que ésta trata de gestionar es inminente que tenga

lugar.

Al ser una aplicación Web, será necesario que todos los usuarios de la herramienta

tengan punto de acceso a Internet.

1.6. ORGANIZACIÓN Y FUNCIONES EMPRESARIALES

En este punto se representa de forma esquemática el organigrama de las partes

implicadas en el proyecto. En el proyecto existen dos actores principales implicados en el

12


proceso de gestionar las incidencias. Por un lado está el departamento de almacenes y por

otro el departamento de logística.

La organización de los almacenes es la siguiente:

La organización del departamento de logística:

Los gerentes de ambas partes son los encargados de determinar los objetivos

necesarios para el proyecto. Para profundizar en los procesos se realizan entrevistas con

los empleados que son los encargados día a día de solventar los problemas.

GERENTE DE ALMACENES

EMPLEADOS OFICINA

EMPLEADOS ALMACÉN

SUPERVISOR

EMPLEADOS OFICINA

DIRECTOR LOGÍSTICA

GERENTE DE LOGÍSTICA

13


1.7. ANTECEDENTES

Este proyecto surgió en Hewlett Packard. Empresa que ofrece una tecnología

adaptada para los negocios y la vida. Las soluciones de la compañía abarcan

infraestructura de TI, dispositivos informáticos personales y de acceso, servicios

globales, imagen e impresión para consumidores y pequeñas y medianas empresas.

La empresa tiene una extensa trayectoria. Desde la fusión del año 2002 con

Compaq Computer Corporation se ha forjando un equipo dinámico y potente de más de

140.000 empleados con capacidades en 178 países que hacen negocios en más de 40

divisas y 10 idiomas diferentes.

Tras esta fusión comienza un proceso de unificación de las dos grandes compañías

con la consecuente unión de sus sistemas en un único sistema informático de gestión.

Esta unión comenzó a principios del 2003 y como sucede en todo proyecto de

gran envergadura comienzan a surgir incidencias que no habían sido previstas y se

producen los retrasos de fechas en las integraciones.

En 2005 comenzó la integración de los sistemas en el área de servicios de la

empresa del que depende el departamento que iba a realizar este proyecto. La

implementación de la nueva fase provocaba problemas de coordinación y comunicación

entre el sistema nuevo y el antiguo por tanto la gestión quedaba a medio camino entre el

antiguo y el nuevo sistema lo que provocaba grandes incidencias.

14


En un principio, el número de piezas no procesables que surgieron era reducido y

el protocolo para resolverlas no estaba estipulado formalmente. Simplemente se

comunicaba el problema por teléfono o vía mail y así comenzaba el tratamiento. Pero en

el momento que para resolver el problema era necesario que interviniesen más de dos

personas surgían problemas y muchas veces pérdidas de información, por lo que no se

llegaba a solucionar la incidencia de forma rápida y eficiente. Esta situación sólo ha sido

sostenible mientras el número de incidencias ha sido reducido. El incremento de las

incidencias ha aconsejado un tratamiento automatizado de estas situaciones con el que se

proporcionarán una mayor y mejor operatividad a la gestión de stocks en la compañía.

En un primer momento, conforme el número de incidencias alcanzaba mayor

envergadura, en el almacén central se creó un protocolo rudimentario basado en un

fichero Excel para el control de dichas piezas. Este fichero contenían la información de

las incidencias y el procedimiento era el siguiente:

1. Introducción de datos de la pieza con incidencia en el almacén en el fichero.

2. Envío del fichero a la oficina de HP (logística).

3. Tratamiento de la pieza realizando un cruce con el sistema.

4. Resolución del problema.

5. Devolución del fichero con la tratamiento que se debe dar a la pieza.

Lógicamente, este fichero tendría que ser actualizado diariamente, conforme

fuesen acaeciendo las incidencias. Los puntos tres y cuatro del protocolo requerían

mucho tiempo, dicha actualización se hacía efectiva dos veces por semana. Este proceso

15


tan tedioso provocaba un consumo de recursos significativo hasta el extremo que se hacía

necesaria la plena dedicación a tiempo completo de un empleado exclusivamente a esta

tarea. Además este mecanismo presentaba carencias en lo que se refiere a fiabilidad, ya

que la inserción de datos podía tener errores y a la hora de cruzar los datos del fichero de

datos con el sistema interno provocaba que la pieza no se encontrase.

Tras el cruce de datos había que solucionar la incidencia, para ello se utilizaban

una serie de macros que trataban los datos obtenidos del cruce, pero éstas no

contemplaban todos los posibles casos y muchos había que solucionarlos de forma

manual. Las distintas incidencias se clasificaban con un estado y cada uno se colocaba en

una hoja del fichero Excel. Durante el traspaso de las líneas que habían cambiado de

estado se producían perdidas de información. Además resultaba difícil mantener toda la

información actualizada.

Todo esto, unido a una constante rotación de personal tanto en los almacenes

como en el departamento de logística y a que el problema se reproducía en el resto de

almacenes de España, para cada uno de los cuales había que crear un fichero Excel

distinto, hacía inviable la metodología tradicional de gestión de incidencias.

Tras dos meses con este mecanismo, el número de incidencias seguía aumentado

y la nueva aplicación cobraba mayor urgencia. Todavía no se había producido la segunda

integración que afectaría directamente a la gestión de piezas en el almacén.

16


Capítulo 2 Análisis de requisitos

17


2. ANALISIS DE REQUISITOS

2.1. INTRODUCCIÓN

En esta etapa se profundiza en los requisitos que son necesarios para obtener los

objetivos esperados. A este análisis se le dedica un tiempo considerable ya que, para

establecer claramente como llevar a cabo todas funcionalidades que son necesarias en la

aplicación, es preciso realizar entrevistas a los usuarios finales y al personal que resuelve

las incidencias. Ésta es la única vía para poder comprender mejor el funcionamiento de

los procesos y obtener una herramienta más útil y funcional para todos los usuarios de la

misma.

Los productos obtenidos de la definición de las necesidades, los problemas y los

requisitos necesarios son:

o Descripción del proceso de una incidencia.

o Lista de requisitos.

o Características de cada requisito.

o Diagrama de contexto.

o DFD.

o Modelo de datos.

18


2.2. DESCRIPCIÓN DEL PROCESO DE UNA INCIDENCIA

En este apartado se presenta un breve informe sobre el tratamiento que se realiza a

una incidencia en el flujo de recepción de piezas.

El proceso de recepción de piezas es el siguiente:

A la llegada de una pieza al almacén, se comprueba si los datos introducidos en el

sistema y los datos de identificación de la pieza, corresponden con la pieza recibida.

Cuando esto no ocurre se produce la incidencia y se debe retener la pieza dentro del

¿Procesable?

Registrar en sistema

Notificación incidencia

Resolución incidencia

Ubicar en almacén

Retención incidencia

Recepción de pieza

Si

No

19


almacén. La incidencia se notifica al departamento de logística que será el responsable de

tomar las medidas necesarias parar resolver el problema. Una vez solucionada la

incidencia la pieza vuelve a intentar ser procesada, si todo es correcto se registra en los

sistemas la recepción y se ubica dentro del almacén. En caso de volver a tener problemas

entra de nuevo en el flujo de incidencias.

A continuación se explican los diferentes tipos de incidencias que pueden

producirse en el proceso de recepción de piezas en el almacén.

• REVIEW DATA: La pieza no contiene información suficiente para ser

procesada, no se encuentra en los sistemas.

• 4243: En el sistema la pieza esta registrada como nueva y en su recepción en el

almacén esta deteriorada.

• WS: Los datos que se adjuntan con la pieza no corresponden con la pieza física.

• PF: La pieza pertenece a un caso que todavía no ha sido cerrado.

• NOT ASSIGNED: La pieza no esta asignada a ningún caso.

20


• WFM NOT CSO: La pieza tiene la información de uno de los sistemas (WFM)

pero este no puede ser visto desde el almacén, así que la pieza se retiene hasta

obtener el CSO.

• OTHERS: Casos especiales que requieren un tratamiento individualizado.

Según el tipo de incidencia que tenga lugar los responsables del departamento de

logística podrá optar por las siguientes soluciones, por motivos de confidencialidad no se

entrará en el detalle del porqué de estas decisiones.

• AJUSTEMENT +: Procesar la pieza como un ajuste positivo dentro del sistema.

• E-RETURNS: Piezas que se van procesar como gastadas dentro del sistema sin

importar su estado físico.

• CREDIT: La pieza se reasigna a otro caso existen en el sistema.

• CHECKED: Los datos se han revisado y corregido.

21


En el siguiente esquema se representa las acciones que se pueden tomar según el

tipo de incidencia:

review checked

not assigned

pf

not assigned

WFM not CSO

4243

ws

E-returns

Other

Adjustment +

E-returns Credit Checked

E-returns

Credit

Other

Other

22


En el siguiente esquema se representa que perfil es responsable de cada tipo de

incidencia:

STATUS RESPONSABLE

Review Almacén

Adjustment + Almacén

Credit Almacén

E-returns Almacén

4243 Logística

WS Logística

not assigned Logística

Other Logística

pf Logística

WFM not CSO Logística

23


2.3. LISTA DE REQUISITOS

• Creación de una base de datos única.

• Listar en una tabla la información de la base de datos.

• Cargar los datos de una nueva pieza retenida.

• Información detallada de una pieza.

• Modificar el estado una pieza.

• Gestión de acceso.

• Generación de comentarios automáticos.

• Aplicación de filtros.

• Cruce de los datos con los sistemas internos.

• Resolución automática de incidencias.

• Mostrar estadísticas.

• Histórico de piezas.

• Descargar las base de datos en un Excel.

• Tratamiento de la duplicidad de líneas.

• Listar piezas preparadas para procesar.

• Reubicación de las piezas.

24


2.4. CARACTERÍSTICAS DE LOS REQUISITOS

A continuación se presentan las características de cada uno de los requisitos

anteriormente listados.

HOJA DE REQUISITOS

IDENTIFICACIÓN Proyecto : Control y gestión de incidencias en stock Jefe de proyecto: Miriam Serrano Conde REQUISITO Creación de una base de datos única Fecha Versión Estado Prioridad 15/10/2005 1.0

Oficial Alta

Fuente Página Identificación requisito

Cliente 1

R_1

Descripción de requisito Creación una base de datos donde se pueda unificar todos los datos existentes hasta el momento en una única base de datos. Crear un acceso que permita dar de alta nuevas incidencias. BENEFICIO Aportar mayor fiabilidad a la información de las piezas, teniendo siempre el último estado conocido de la pieza. Además ayuda a la comunicación entre los distintos usuarios ya que todos tendrán acceso a la información desde distintas ubicaciones.

25


HOJA DE REQUISITOS

IDENTIFICACIÓN Proyecto : Control y gestión de incidencias en stock Jefe de proyecto: Miriam Serrano Conde REQUISITO Listar en una tabla la información de la base de datos Fecha Versión Estado Prioridad 15/10/2005 1.0

Oficial Alta


Cliente 2

R_2

Descripción de requisito Crear un listado donde se muestren los datos revelantes de las piezas para el facilitar procesamiento de las mismas. No se muestra la información específica de cada pieza sólo una general. BENEFICIO Tener una vista única de todos los datos. El listado ayudará a detectar con mayor facilidad el tipo de incidencia que tiene una pieza. El usuario que esté implicado en su resolución podrá seleccionar ésta y tener acceso a una información más detallada para resolver el problema. Ésto ahorra tiempo y ayudará a disminuir el número de incidencias pendientes. COMENTARIOS Los datos que se mostrarán se especificarán más adelante cuando las bases de datos estén conformadas.

26


HOJA DE REQUISITOS

IDENTIFICACIÓN Proyecto : Control y gestión de incidencias en stock Jefe de proyecto: Miriam Serrano Conde REQUISITO Cargar los datos de una nueva pieza retenida Fecha Versión Estado Prioridad 15/10/2005 2.0

Oficial Alta


Cliente 3

R_3

Descripción de requisito Permitir dar de alta nuevas piezas que tengan alguna incidencia en el almacén. BENEFICIO Agilizar la comunicación de la nueva incidencia a los encargados de solucionar el problema. Ubicar la pieza dentro del almacén para que, una vez sea resuelta la incidencia, sea sencilla la localización de la pieza para ser procesada en el sistema. COMENTARIOS Los datos a introducir no serán obligatorios ya que en algunos casos el principal problema para no poder procesar la pieza es la falta de los mismos. Para evitar problemas con los distintos sistemas que se utilizan, la fecha la generará la aplicación automáticamente así como el identificador de la incidencia.

27


HOJA DE REQUISITOS

IDENTIFICACIÓN Proyecto : Control y gestión de incidencias en stock Jefe de proyecto: Miriam Serrano Conde REQUISITO Información detallada de una pieza Fecha Versión Estado Prioridad 15/10/2005 1.0

Oficial Alta


Cliente 4

R_4

Descripción de requisito Mostrar la información detallada de la pieza. BENEFICIO Tener toda la información necesaria para resolver la incidencia. En el listado no se pueden ver detalles que son útiles para solucionar el problema. COMENTARIOS Según avance el proyecto existirá un mecanismo de creación de comentarios automáticos que serán muy importantes para conocer cual ha sido la evolución de la pieza en el sistema.

28


HOJA DE REQUISITOS

IDENTIFICACIÓN Proyecto : Control y gestión de incidencias en stock Jefe de proyecto: Miriam Serrano Conde REQUISITO Modificar el estado una pieza Fecha Versión Estado Prioridad 03/02/2006 4.0

Oficial Alta


Cliente 5

R_5

Descripción de requisito Habilitar la posibilidad de cambiar el status en el que se encuentra una pieza. El paso de un status a otro será vital para el correcto procesamiento de las piezas. Por ello, se ha de seguir el protocolo establecido por la empresa para tratar cada tipo de incidencia, solo permitiendo a cada usuario realizar el cambio de status que está autorizado a realizar. Para evitar confusiones, la aplicación predeterminará a qué status posibles se pueden pasar partiendo de un status determinado. BENEFICIO Resolución de incidencias sin necesidad de utilizar otro medio de comunicación. Esto hace más eficiente la resolución de incidencias y evita que se pueda producir cambios de status no establecidos en el proceso de resolución de incidencias. COMENTARIOS Este requisito es muy amplio y ha sufrido muchas revisiones. Inicialmente se pretendía que la aplicación permitiese sólo tres status y actualmente permite muchos más. Por eso ha sido necesario elaborar una descripción detallada de todo el proceso y sus posibles variantes y así determinar dónde se encuentra una pieza y hacia dónde puede evolucionar en el proceso.

29


HOJA DE REQUISITOS

IDENTIFICACIÓN Proyecto : Control y gestión de incidencias en stock Jefe de proyecto: Miriam Serrano Conde REQUISITO Gestión de acceso Fecha Versión Estado Prioridad 15/10/2005 1.0

Oficial Baja


Cliente 6

R_6

Descripción de requisito Cada usuario tendrá unos privilegios concretos y por tanto habrá que establecer sus accesos permitidos. BENEFICIO Evita el uso indebido de la aplicación.

30


HOJA DE REQUISITOS

IDENTIFICACIÓN Proyecto : Control y gestión de incidencias en stock Jefe de proyecto: Miriam Serrano Conde REQUISITO Generación de comentarios automáticos Fecha Versión Estado Prioridad 14/11/2005 1.0

Oficial Media


Cliente 7

R_7

Descripción de requisito La generación de comentarios automáticos se requiere para tener una constancia de todos los cambios de status que se producen sobre una incidencia. También se habilita la posibilidad de generar mensajes de manera manual para facilitar la comunicación entre los involucrados en la resolución. BENEFICIO Proporciona un seguimiento exhaustivo de cada movimiento que tiene la incidencia dentro de la aplicación registrando qué usuario ha realizado un cambio. Además existirá la posibilidad de generar mensajes manualmente como ayuda a la comunicación entre los usuarios. COMENTARIOS Será importante establecer los campos que tendrán los comentarios.

31


HOJA DE REQUISITOS

IDENTIFICACIÓN Proyecto : Control y gestión de incidencias en stock Jefe de proyecto: Miriam Serrano Conde REQUISITO Aplicación de filtros Fecha Versión Estado Prioridad 12/12/2005 1.3

Oficial Media


Cliente 8

R_8

Descripción de requisito Listar solamente por unos criterios determinados los datos existentes con esas características. BENEFICIO Agilizar la búsqueda de determinadas piezas así como disminuir el tiempo de carga de la información ya que el número de piezas a listar será menor una vez filtrada. SOLUCINES SUGERIDAS Crear una interfaz con todos los criterios por los que será posible filtrar.

32


HOJA DE REQUISITOS

IDENTIFICACIÓN Proyecto : Control y gestión de incidencias en stock Jefe de proyecto: Miriam Serrano Conde REQUISITO Cruce de los datos con los sistemas internos. Fecha Versión Estado Prioridad 12/12/2005 1.0

Oficial Media


Cliente 9

R_9

Descripción de requisito Cruzar la base datos de la herramienta con los tres sistemas internos que se utilizan en la empresa: SAM, FMN y WFM. BENEFICIO Recopilar más información de las piezas recogidas en la base de datos de la aplicación y poder luego utilizarla para la resolución de las incidencias. COMENTARIOS Este cruce de sistemas sólo tiene sentido con la posterior realización de resolución de incidencias, requisito especificado a continuación. REQUISITOS RELACIONADOS R_10, R_13

33


HOJA DE REQUISITOS

IDENTIFICACIÓN Proyecto : Control y gestión de incidencias en stock Jefe de proyecto: Miriam Serrano Conde REQUISITO Resolución automática de incidencias Fecha Versión Estado Prioridad 20/10/2005 1.0

Oficial Media


Cliente 10

R_10

Descripción de requisito El resultado del cruce mediante la aplicación de varios algoritmos actualizará la información de la herramienta, con los cambios pertinentes de status y datos de la pieza. BENEFICIO Ahorro de tiempo para los usuarios que debían comprobar de forma individualizada las incidencias en los sistemas. Agiliza el proceso de disminuir el número de incidencias. REQUISITOS RELACIONADOS R_9, R_13

34


HOJA DE REQUISITOS

IDENTIFICACIÓN Proyecto : Control y gestión de incidencias en stock Jefe de proyecto: Miriam Serrano Conde REQUISITO Mostrar estadísticas Fecha Versión Estado Prioridad 12/12/2006 1.0

Oficial Alta


Cliente 11

R_11

Descripción de requisito Crear unas estadísticas donde se muestre la información del número de piezas existentes en cada status y al almacén al que pertenecen. También se mostrará el número total de piezas que han pasado por la herramienta así como el número actual de incidencias abiertas. BENEFICIO Habilitar una función que ayude a determinar qué incidencias se producen con mayor frecuencia o cuáles no están siendo resueltas y así poder facilitar el trabajo de supervisión de todo el proceso. También sirve para comprobar la evolución de la propia aplicación y de la paralización de inventarios existente en cada momento.

35


HOJA DE REQUISITOS

IDENTIFICACIÓN Proyecto : Control y gestión de incidencias en stock Jefe de proyecto: Miriam Serrano Conde REQUISITO Histórico de piezas Fecha Versión Estado Prioridad 12/12/2005 1.0

Oficial Media


Cliente 12

R_12

Descripción de requisito Crear una nueva base de datos donde se almacenen todas las incidencias que ya han sido procesadas y habilitar una función que permita buscar según criterios específicos la pieza o grupo de piezas deseada. BENEFICIO Esta base de datos histórica permite analizar casos que ya se habían resuelto o para comprobar si el proceso había sido el correcto. COMENTARIOS La base de datos será una replica de la que se utiliza para la herramienta, por lo que no será necesario hacer un diseño de esta.

36


HOJA DE REQUISITOS

IDENTIFICACIÓN Proyecto : Control y gestión de incidencias en stock Jefe de proyecto: Miriam Serrano Conde REQUISITO Descargar las base de datos en un Excel Fecha Versión Estado Prioridad 02/02/2006 1.0

Oficial Baja


Cliente 13

R_13

Descripción de requisito Descargar los datos de la base de datos en un formato útil para los usuarios que no tengan un conocimiento amplio de base de datos. BENEFICIO El fichero que se descarga servirá para imprimir datos relevantes para determinados usuarios como pueden ser los almacenes en el momento de realizar una auditoria interna.

37


HOJA DE REQUISITOS

IDENTIFICACIÓN Proyecto : Control y gestión de incidencias en stock Jefe de proyecto: Miriam Serrano Conde REQUISITO Tratamiento de la duplicidad de líneas Fecha Versión Estado Prioridad 12/12/2005 1.0

Oficial Baja


Cliente 14

R_14

Descripción de requisito Las bases de datos de los sistemas internos de la empresa tienen duplicidad de datos en sus tablas, lo que supone un problema para esta herramienta. Hasta este momento, la herramienta localizaba las duplicadas y la resolución debía ser manual. Con este nuevo requisito se busca encontrar un algoritmo que realice las mismas comprobaciones que se hacen manualmente y así resolver las duplicidades de manera automática. BENEFICIO Este requisito ahorra tiempo y recursos de la empresa además de aportar mayor fiabilidad que el mecanismo que se había seguido hasta el momento. REQUISITOS RELACIONADOS R_9, R_10

38


HOJA DE REQUISITOS

IDENTIFICACIÓN Proyecto : Control y gestión de incidencias en stock Jefe de proyecto: Miriam Serrano Conde REQUISITO Listar piezas listas para procesar Fecha Versión Estado Prioridad 01/03/2005 1.0

Oficial Alta


Cliente 15

R_15

Descripción de requisito Listar todas las piezas que se encuentran en status “to process” y una vez que estén procesadas correctamente poder cambiar el status a “processed” sin necesidad de entrar en cada una de ellas para cambiar el status. BENEFICIO Agilizar el trabajo en almacenes ya que en el listado aparece la información mínima necesaria para procesar sin precisar más detalle. Si al empleado imprime las piezas listas para procesar una vez que termina de procesar, todas aquellas que no han tenido problema se seleccionarán fácilmente y cambiarán de status de una vez. Esto es una reducción muy importante de tiempo considerando que la media de procesamiento de piezas es de unas cien al día. COMENTARIOS Este requisito surgió una vez arrancada la aplicación por petición de los usuarios de almacén, debido a la demora de tiempo que suponía entrar en cada pieza.

39


HOJA DE REQUISITOS

DENTIFICACIÓN Proyecto : Control y gestión de incidencias en stock Jefe de proyecto: Miriam Serrano Conde REQUISITO Reubicación de las piezas Fecha Versión Estado Prioridad 10/03/2006 1.0

Oficial Media


Cliente 16

R_16

Descripción de requisito Habilitar una opción por medio de la cual las piezas que se encuentran retenidas en el almacén puedan ser reubicadas dentro de él. BENEFICIO Ayudará a ubicar las piezas tanto cuando estén listas para ser procesadas como para los procesos de auditoria interna. COMENTARIOS Este requisito surgió una vez arrancada la herramienta ya que un problema dentro del almacén, que obligaba a una reubicación de todo el material, supuso un problema para la aplicación. La solución adoptada fue habilitar esta opción de reubicación.

40


2.5. DIAGRAMA DE CONTEXTO

En el diagrama se observa cómo dos entidades externas, donde una corresponde al

usuario del sistema y otra a los sistemas internos de la empresa que va suministrar la

información necesaria para la resolución de incidencias. El flujo de datos representado

entre el sistema y el usuario contiene toda la información que va a ser intercambiada en el

transcurso de resolución de una incidencia determinada. En los diagramas de primer y

segundo nivel se especificará el contenido de estos flujos.

SISTEMA USUARIO

login, password, opción, datos, selección id, acción, datos mensaje, selección filtrar, id, cambio,selección, datos incidencia, filtro, solución

ENTIDAD EXTERNA

menú,alta,listado,acciones,listado_F,incidencia filtro histórico, listado his, informe, manual,fichero,peticíón, error,detalles incidencia

datos sistema

41


2.6. DIAGRAMA DE PRIMER NIVEL

Este diagrama muestra, en rasgos generales, los procesos que tienen lugar en la

aplicación. Conviene remarcar que una vez que el usuario ha sido registrado, la

aplicación guardará el tipo de usuario y siempre estará presente para los distintos

procesos, todos los flujos de datos tendrán presente qué usuario está operando.

Login y password

1 Comprobar

usuario

2 Mostrar menú

3 Dar de

alta incidencia

4 Listar piezas

5 Resolver incidencia

7 Filtrar

incidencias

11 Descargar

manual

6

Generar mensajes

13 Descargar

fichero

12 Resolver

duplicados

14 Gestionar cruce de sistemas

REVERSE

SYSTEM

DUPLICADAS

HISTORICO

REVERSE

USUARIOS Tipo usuario

datos

Opción Opción

Opción

Opción

Opción

Opción

Opción

Opción

Datos

status

Manual Fichero

Alta listado mns_status

10 Generar

estadísticas

Opción

Informe

Opción

acción acciones

selección filtrar

mns_status

9 Gestionar histórico

Listado_his

Filtro histórico

8 Modificar

datos incidencia

id cambio

menu

datos mensaje

Listado_F

selección

42


A continuación se presenta una breve descripción de cada uno de los procesos.

Aquellos que por motivos de su complejidad necesiten mayor especificación para la

comprensión del funcionamiento de la aplicación se desarrollarán en con mayor

profundidad.

• Comprobar usuario: Al entrar en la aplicación el usuario introduce sus datos

para que el sistema los valide. Una vez validado, el sistema comprueba el perfil

del usuario para determinar el tipo de privilegios que tiene dentro de la aplicación.

• Mostrar menú: Se muestran únicamente las opciones que tenga habilitado el

perfil de usuario que se ha validado. La mayoría de las funcionalidades de la

aplicación se encuentran agrupadas dentro del menú. Desde este proceso sale

siempre el mismo flujo de datos (Opción) este contiene el tipo de usuario y la

opción elegida.

• Dar de alta incidencias: El usuario del almacén detecta una pieza con una

incidencia y es en ese momento cuando comienza el flujo de toda la aplicación.

Por tanto la entrada de datos es un proceso importante en el transcurso de la

aplicación. Este proceso recibe los datos de la pieza y se encarga de almacenar

éstos en la base de datos. Una vez que una pieza entra en el sistema toma un status

“open”.

• Listar piezas: Elaboración de un listado con todas las piezas pendientes de

ser procesadas. En él solamente se mostraran los datos imprescindibles para un

análisis rápido del tipo de incidencia y sus posibles causas. Para entrar en los

43


detalles de la incidencia será necesario seleccionar una de ellas. Según el perfil

que tenga el usuario el sistema se habilitará la opción de resolver la incidencia o

no.

• Resolver incidencias: El usuario tiene permiso para dar una solución a un

tipo de incidencia. El sistema muestra las distintas opciones para resolver el

problema en función del status de la pieza y será el usuario el que deberá

determinar cuál de ellas seleccionar.

• Generar mensajes: Cada vez que un usuario realice una modificación en la

incidencia se registrará de manera automática la persona que lleva a cabo el

cambio así como la hora y fecha en que se realiza. También desde aquí se podrán

escribir mensajes manuales para dejar observaciones o tratos especiales a algunas

de las incidencias.

• Filtrar incidencias: Se mostrará una interfaz donde se agruparán todos los

campos por los que se puede listar un conjunto de piezas. El usuario seleccionará

aquellos que requiera para realizar la consulta deseada.

• Modificar datos: Este proceso buscará la pieza que se desea modificar y

habilitará todos los campos como modificables. Para que la aplicación no pierda

integridad solamente está habilitado para el perfil administrador. Una

modificación de datos incontrolada podría llevar de nuevo al problema de perdida

44


de piezas y a un mal uso de la aplicación. Para cualquier cambio de este tipo, el

usuario deberá contactar con los administradores de la aplicación.

• Cargar histórico: Todas las piezas que estén procesadas en el sistema, se

cargarán al histórico. Este proceso sólo lo podrá realizar el administrador. El

proceso consiste en seleccionar todas aquellas piezas que tengan status

“processed” y cargarlas en la base de datos de históricas. Una vez en la nueva

base se borran de la base de datos de reverse.

• Generar estadísticas: Crear un informe donde se muestre la información del

número de piezas existentes en cada status y al almacén al que pertenecen.

• Descargar manual: El usuario en caso de duda siempre podrá descargar el

manual de ayuda, donde se especifican todos los pasos a seguir en cada caso.

• Resolver duplicadas: Las bases de datos del sistema interno de la empresa,

no las de la aplicación, tienen una serie de líneas repetidas y durante el cruce de

sistemas se duplican también las líneas de esta herramienta. Este proceso se

diseña para resolver este problema. Al ser necesario borrar registros de la base de

datos, se considera un proceso delicado por lo que, por motivos de seguridad y

fiabilidad, será el administrador el que ejecute dicho proceso.

• Descargar fichero: El usuario podrá descargar las bases de datos del

sistema.

45


• Cruce de sistemas: Este proceso es muy complejo ya que se interactúa con

tres bases de datos ajenas a la herramienta.

46


2.7. DIAGRAMAS DE SEGUNDO NIVEL

Comprobar usuario

1.1 Validar usuario: El usuario introduce los datos para autentificarse, el sistema

accede a la base de datos de USUARIOS, donde valida si existe y si la contraseña es

correcta, en esa misma consulta obtendrá el tipo de usuario que se ha registrado.

1.2 Establecier privilegios usuario: Con el tipo de usuario se establece el perfil

que será lo que determine que opciones tendrá habilitadas en la herramienta.

1.1 Validar usuario

1.2 Establecer privilegios usuario

USUARIOS

login y password

tipo usuario

error

usuario

47


Dar de alta incidencia

3.1 Leer datos incidencia: El usuario de almacén selecciona la opción de

introducir una nueva pieza, se muestra una pantalla donde debe introducir los distintos

campos.

3.2 Leer datos incidencia: El sistema lee los campos introducidos por el usuario a

través del formulario.

3.3 Comprobar datos: Los campos obligatorios deben estar completos y cumplir

las características necesarias para que sean correctos.

3.4 Registrar incidencia: Se realiza el registro en la base de datos de la

información introducida por el usuario. Y se genera un identificador para la incidencia.

datos incidencia

3.1 Mostrar

formulario

3.3 Comprobar

datos

REVERSE

3.4 Registrar incidencia

datos incidencia

datos incidencia

alta

mns_status

Opción

3.5 Mostrar

confirmación

3.2 Leer datos

incidencia

48


3.5 Mostrar confirmación: Muestra por pantalla el identificador generado por el

sistema para la nueva incidencia registrada y envía un flujo de datos a generar un mensaje

automático ligado a la incidencia.

Listar incidencias

4.1 Cargar incidencias: El usuario selecciona la opción de listar las incidencias,

para ello el sistema carga del sistema todas las piezas que se encuentran en la base de

datos.

4.2 Mostrar listado: Muestra un listado estableciendo el orden y las

características de éste.

4.3 Mostrar incidencia: Recibe el identificador de una pieza y carga la

información obtenida de al base de datos. Muestra esta información más detallada de la

conjunto incidencias

4.1 Cargar

incidencias

opción

REVERSE

selección id

4.2 Mostrar listado

listado

4.3 Mostrar

incidencia

detalles incidencia

status

49


pieza en cuestión. Antes de mostrar los datos el sistema comprueba qué acciones puede

realizar el usuario de acuerdo a su perfil. Si es un usuario sin privilegios sólo visualiza la

información (detalles incidencia). En caso de ser un usuario con permisos el sistema

muestra la información detallada, y envía la información del status al proceso de resolver

incidencias.

Resolver incidencias

5.1 Establecer acciones: El sistema recibe el status de una de las piezas, analiza

qué tipo de acciones se pueden realizar para dicho status.

5.2 Mostrar acciones: Se muestran por pantalla las distintas acciones que puede

realizar el usuario. Estas acciones han sido explicadas con anterioridad en el desarrollo de

tipos acciones 5.1

Establecer acciones

REVERSE

5.2 Mostar

acciones

5.3 Registrar acción

status acción acciones

acción

mns_status

status, dato

50


esta memoria. El usuario, una vez decide que acción va a realizar, informa al sistema

seleccionando ésta y en caso de ser necesario introduciría la información adicional para la

resolución de la incidencia. Toda esta información se recoge en el flujo de datos acción.

5.3 Registrar acción: El sistema registra el nuevo status y la información

adicional que haya sido necesaria para resolver la incidencia. Simultáneamente se

generará un mensaje informando de la acción realizada, para ello se envía en el flujo de

datos mns_status los datos del cambio y el nuevo status.

Generar mensajes

6.1 Obtener datos mensaje: Toma los datos introducidos por el usuario o el status

enviado por el propio sistema.

status, datos

6.1 Obtener datos

mensaje REVERSE

6.2 Generar cuerpo

del mensaje

6.3 Preparar mensaje

mns_status

cuerpo_mensaje

6.4 Registrar mensaje

cuerpo_mensaje

datos mensaje

mensaje

51


6.2 Generar cuerpo del mensaje: El sistema ha registrado un cambio en alguna

incidencia, en este proceso se genera un cuerpo para el mensaje a registrar.

6.3 Preparar mensaje: Monta el mensaje tomando la fecha, hora, usuario

registrado y el cuerpo del mensaje recibido.

6.4 Registrar mensaje: Carga en la base de datos el nuevo mensaje.

Filtrar incidencias

7.1 Mostrar filtros: Muestra por pantalla los campos por los que es posible filtrar.

Este proceso carga de la base de datos las fechas y subcontratas registradas en ésta.

7.1 Mostrar filtros

REVERSE

7.2 Preparar

filtro

Opción

selección filtros

filtro

filtros

conjunto incidencias 7.3

Cargar incidencias

7.4 Mostrar listado

listado_f

fecha, subcontratas

52


7.2 Preparar filtro: El usuario realiza una consulta seleccionando los campos

deseados y el sistema lee la consulta y la prepara.

7.3 Cargar incidencias: Cargan los datos de la búsqueda

7.4 Mostrar listado: Muestra por pantalla el conjunto de incidencias.

Modificar datos

8.1 Cargar incidencia: Se recibe el identificador de la pieza a modificar, este se lee

y se carga toda la información disponible de la incidencia buscada.

8.2 Mostrar datos modificables: Se muestra por pantalla todos los datos cargados

en el sistema y se habilitarán los campos que sean modificables.

datos 8.1

Cargar incidencia

REVERSE

8.2 Mostar datos

modificables

8.4 Leer

cambios

Opción

cambio

incidencia

cambios

mns_status cambios

id

8.3 Leer

cambios

53


8.3 Leer cambios: El usuario introduce los cambios pertinentes y el sistema toma

la información.

8.4 Registrar cambios: Se registran todas las modificaciones realizadas sobre la

incidencia y se genera un flujo información para generar un mensaje automático.

Gestionar histórico

9.1 Preparar descarga

REVERSE

9.2 Cargar

procesadas

Opción

9.3 Descargar procesadas

procesadas

HISTÓRICO

identificadores

9.5 Mostrar filtros

HISTÓRICO

9.6 Preparar

filtro

Opción filtros Histórico

filtro

filtros

conjunto incidencias 9.8

Cargar incidencias

9.7 Mostrar listado

listado_H

fecha, subcontratas

9.4 Borrar

procesadas

54


9.1 Preparar descarga: Obtiene información necesaria de la base de datos para la

posterior descarga de las líneas procesadas. Dicha información se empaqueta en el flujo

de datos identificadores.

9.2 Cargar procesadas: Obtiene la información de todas la líneas procesadas hasta

ese momento en el sistema.

9.3 Descargar procesadas: Toma los datos de las piezas procesadas y las registra

en la base de datos de piezas históricas.

9.4 Borrar procesadas: Una vez cargado el histórico se procede a eliminar dichas

líneas de la base de datos de REVERSE.

Los procesos entre el 9.5 y 9.8 realizan las mismas acciones que los procesos de

filtrar incidencias con la diferencia de acceder a bases de datos diferentes.

55


Estadísticas

10.1 Obtener información: Carga la información necesaria para realizar los

cálculos de las estadísticas.

10.2 Realizar cálculos: Ejecuta los algoritmos pertinentes para obtener los datos

de las estadísticas.

10.3 Preparar informe: Toma los datos de los cálculos realizados y la información

necesaria de los almacenes la carga de la base de datos para generar un informe.

10.1 Obtener

información

REVERSE

10.2

Realizar cálculos

Opción

cálculos

informe

10.3 Preparar informe

10.4 Mostrar informe

informe

información

56


10.4 Mostrar informe: Muestra por pantalla un informe con los totales de los

distintos status y el valor económico que supone cada status para la empresa.

Gestionar duplicadas

12.1 Mostar duplicados: Carga todas las piezas existentes en la base de duplicadas

y las muestra por pantalla. Donde el usuario puede optar por solucionar la duplicidad de

manera manual o automáticamente.

12.2 Solucionar manualmente: El usuario analiza los casos, decide cual de las

líneas es la correcta e introduce el cambio en la aplicación.

12.2

Solucionar manualmente

12.3 Solucionar

automaticamente

12.1 Mostrar

duplicados

DUPLICADAS

cambios

12.4 Registrar cambio

REVERSE

duplicadas solución

datos duplicadas

datos duplicadas

cambios

57


12.3 Solucionar automáticamente: La aplicación realiza una serie de algoritmos

para comprobar qué líneas son las correctas y transmite los cambios a registrar cambio.

12.4 Registrar cambio: Registra los cambios en la base de datos de REVERSE y

tras ésto elimina dichas líneas de la base de DUPLICADAS. Se genera un mensaje con el

cambio para enviar a resolver incidencias.

Gestionar cruce de sistemas

14.1 Generar fichero: El sistema recibe los datos de los sistemas internos de la

empresa, los trata y almacena en un fichero.

14.2 Cargar fichero: La información contenida en el fichero se carga en una base

de SYSTEM que posteriormente será utilizada.

14.1 Generar fichero

SYSTEM

DUPLICADAS

REVERSE

datos sistema

14.2 Cargar fichero

Fichero SYS

14.3 Cruzar datos

14.4 Actualizar

status

58


14.3 Cruzar datos: El sistema toma los datos de la aplicación y los del sistema

cargados en la base de datos SYSTEM para efectuar un cruce de los datos. Los resultados

obtenidos se graban en la base de DUPLICADAS.

14.4 Actualizar status: Toma los datos almacenados del cruce y aplica un

algoritmo capaz de detectar los cambios introducidos en cada pieza y establecer el nuevo

status de la pieza. Si se detecta algún cambio se registrara en la base de datos REVERSE

y se genera un mensaje con la modificación de la incidencia.

59


2.8. MODELADO 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 las tres formas normales de la normalización, que son:

� Primera Forma Normal (1FN): Una entidad está en 1FN si cada atributo que la

constituye, y que no participa como identificador de ella, es dependiente 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.

60


� Tercera Forma Normal (3FN): Una entidad está en 3FN si todos los atributos que

la componen, y que no constituyen el identificador, son independientes

funcionales entre sí. Normalizando el Modelo de Datos se consigue evitar

redundancias y dar integridad a los datos.

El modelo de datos final se compone de cuatro bases de datos, que son

Duplicados, System, Retenidas, Histórico. A continuación se muestra los diagramas

de entidad-relación de cada una de ellas.

Duplicados

System

PRE_REVERSE

SYSTEM PRICE

cargar valorar

1

1

1

1

REVERSE_TMP

ERRORS DUPLICADAS PRICE

errar duplicar valor

N 1

1

N

1 1

61


Las tablas que conforman el modelo de datos se especifican a continuación junto

con sus atributos.

Tabla REVERSE: es la tabla en la que se carga toda la información relevante de una

pieza dada de alta en el sistema. Dicha tabla consta de los siguientes atributos:

• ID_PART: Número de identificador de la pieza.

• REC_DATE: Fecha de recepción de la pieza en el almacén.

• READY TO PROCESS_DATE: Fecha a partir de la cual la pieza se puede

procesar.

• SUBCONTRACTOR: Nombre de la contrata.

• PN_PACKING: Part Number de la pieza.

• CSO_PACKING: CSO en el que está incluida la pieza.

• PACKING_QTY: Cantidad de piezas recibidas en el almacén.

REVERSE

MESSAGES PRICE

informar valor

1

N 1

1

Retenidas

HIS_REVERSE

HIS_MESSAGES

informar

1

N

Histórico

62


• PHY_STATUS: Estado físico del problema.

• HOLD_STATUS: Status de la pieza en el almacén respecto a la aplicación.

• WFM: Número de WFM.

• UBICATION: Referencia de la ubicación dentro del almacén.

• LOCATION: Referencia al almacén.

• FMN_CALL_STATUS: Status del caso en FMN.

• SAM_CALL_STATUS: Status del caso en SAM (OK SI CSO_LOCK = “L” o

“D”).

• SAM_PART_STATUS: Status de la pieza en SAM (nueva o usada).

• FMN_OTC: Tipo de contrato establecido.

• SAM_PART_QTY: Cantidad del part number reflejada en SAM.

• ESC_VALUE: Valor de la pieza.

• REMARKS: Observaciones sobre la pieza la primera vez que se carga en el

sistema.

Tabla PRICE: Almacena el precio de cada una de las piezas cargadas en la aplicación.

• PART_NUMBER: Identificador de la pieza en los sistemas.

• REFERENTE_PRICE: Indica el precio de referencia de una pieza.

Tabla MESSAGES: La tabla almacena todos los mensajes de cada una de las piezas con

los datos de autor y momento de cuando se escribió el mensaje.

63


• ID_MESSAGES: Número de identificación del mensaje.

• ID_REVERSE: Número de identificación de la pieza retenida al que pertenece el

mensaje.

• AUTHOR: Autor del mensaje.

• DATE_MESS: Fecha del mensaje.

• TIME_MESS: Hora del mensaje.

• TEXT_MESS: Texto del mensaje.

Tabla HIS_REVERSE: Recoge todas las piezas que han entrado en algún momento dado

en la aplicación y han sido procesadas correctamente. El contenido de esta tabla es el

mismo que la tabla REVERSE con la diferencia de que hay un campo más que es:

• CLAVE_REVERSE: Identificador del registro de la pieza dentro del histórico.

Tabla HIS_MESSAGES: Recoge todos los mensajes de las piezas cargadas en el

histórico, es una replica exacta de la tabla MESSAGES.

Tabla SYSTEM: Almacena los datos obtenidos del sistema externo a través del cruce de

base de datos.

• ID_SYS: Identificador de la pieza carga de los sistemas.

• CSO_Number: Número del CSO al que pertenece.

• Part_Number: Identificador de una pieza asignada a dicho CSO.

64


• CALL_STATUS: Estado de la llamada al que pertenece el CSO.

• CSO_STATUS: Estado del CSO dentro de la llamada.

• PART_QTY: Cantidad de piezas incluidas en el caso.

• FAULIRE_CODE: Código identificador de la pieza dentro de WFM.

• WFM_SYS: Número dentro de WFM.

Tabla PRE_REVERSE: Almacena los mismos datos que la tabla REVERSE. La tabla

será utilizada como una tabla temporal donde se guarden los datos mientras se están

actualizando los datos en el cruce de sistemas.

Tabla DUPLICADAS: Almacena las líneas que han sido duplicadas en los cruces de los

sistemas. Los atributos son los mismos que en la tabla de REVERSE pero con un campo

más identificando la duplicidad.

Tabla EERRORS: Contiene la información que al ser cargado en los sistemas ha sufrido

algún problema. El conjunto de atributos son los mismos datos que la tabla SYSTEM.

65


Capítulo 3 Arquitectura

66


3. ARQUITECTURA

3.1. INTRODUCCIÓN

En esta etapa se define la estructura de la arquitectura elegida y los distintos

recursos software y hardware que son necesarios para que el correcto funcionamiento de

la herramienta.

3.2. RECURSOS SOFTWARE

El proyecto se realiza bajo el sistema operativo Windows XP Professional. La

elaboración de la documentación se realiza mediante la herramienta Microsoft Word

2003 y PowerPoint para la realización de gráficos.

La tecnología que se va a utilizar será Active Server Pages (ASP), con el fin de

crear una aplicación Web dinámica con la utilización de IIS (Internet Information

Server).

Esta tecnología ASP busca dar solución al problema que actualmente existe de

desarrollo rápido de aplicaciones, al ser una programación similar a VisualBasic, aunque

con algunas limitaciones, que para el proyecto que se quiere realizar no será un problema

en principio.

67


Este modelo tecnológico aprovecha los diversos componentes desarrollados por

algunos controles ActiveX, aunque presenta el problema de la ausencia de información

disponible lo que dificulta mucho una utilización más eficiente de la tecnología.

La versión de ASP que se va utilizar es ASP.NET. Existe un conjunto de

versiones de pre-NET que se denominan ASP clásico, son anteriores al .NET, las cuales

han ido evolucionando. En la última versión ASP 3.0, ya existían 6 objetos integrados

que son Request, Response, Application, ASPError, Server y Session. Estos objetos son

los que dan dinamismos a la aplicación. Para el acceso a base de datos y otras

funcionalidades existe la posibilidad de generar código de scripts del lado del servidor.

En el desarrollo de la base de datos se va a utilizar Microsoft Access, por ser una

herramienta sencilla de utilizar y manejable, aunque sea menos potente que otros gestores

de bases de datos como MySQL o SQL Server. Con este software será suficiente para el

correcto funcionamiento de la aplicación.

La obtención de los datos de los sistemas internos de la empresa donde se va a

implantar esta aplicación, se va a realizar mediante la herramienta Brioquery Enterprise

que es una aplicación de consulta OLAP (Proceso Analítico Online) con consulta

integrada, analítica global de datos y uso de gráficas para análisis interactivo. El interafaz

de BrioQuery Enterprise es muy intuitivo, esto facilita su gestión.

68


WS-FTP Pro es una aplicación de cliente de transferencia de ficheros, basada en

Windows, que permite transferir ficheros entre el PC local y el servidor FTP remoto. Con

esta aplicación se pueden revisar los directorios y ficheros contenidos en el servidor, y

transferir ficheros (cargarlos o descargarlos) en ambos sentidos. La aplicación esta muy

extendida en Internet ya que posee un interfaz gráfico muy intuitivo que facilita su uso.

Una de sus grandes ventajas es se puede integrar con Internet Explorer al descargar

ficheros de un FTP, permite mirroring, transmisión de dos FTPs así como el reenvío

automático de ficheros.

3.3. RECURSOS HARDWARE

El proyecto se realiza con un Compaq Presario SR1689 con un procesador

PENTIUM IV 3,06 GHz. Sobre este ordenador se realiza todo el desarrollo del proyecto a

nivel programación y documentación.

El servidor que se ha utilizado es un HP Integrity Superdome con un procesador

Dual-core Intel Itanium 2 (1.6 GHz). Éste opera bajo el sistema operativo Microsoft

Windows Server 2003. La gestión del servidor no corre a cargo de este proyecto, sólo se

utilizará los servicios que ofrece como servidor aportando un dominio y ubicación para

cargar los ficheros correspondientes.

69


Capítulo 4 Diseño de entradas

y salidas

70


4. DISEÑO DE ENTRADAS Y SALIDAS 4.1. INTRODUCCIÓN

En este capítulo se muestran los distintos interfaces de entrada y salida de datos

del sistema. Realizadas mediante código HTML.

4.2. DISEÑO DE VENTANAS

Diseño Ventana 1 Nombre: Inicio sesión. Descripción: El usuario introduce su nombre de usuario y la clave. Tipo: Entrada / Salida Ventanas a las que llama: 2. Diseño:

71


Diseño Ventana 2 Nombre: Menú Tipo: Entrada / Salida Ventanas a las que llama: 3, 5, 12, 13, 14, 16. Diseño:

Descripción: Muestra las distintas opciones que puede seleccionar el usuario. Según el

perfil del usuario se muestran unos enlaces u otros.

El perfil de almacén y de logística tendrá el menú que muestra a continuación.

El perfil de supervisor sólo tendrá habilitado Listar todas o ver estadísticas.

El perfil de administrador implementa además las siguientes opciones:

- Visualizar duplicadas

- Solución rápida de incidencia

- Paso a histórico

- Dar de alta usuario

72


Diseño Ventana 3 Nombre: Alta Tipo: Entrada Ventanas a las que llama: 2,4. Diseño:

Descripción: La pantalla muestra los campos que debe introducir el usuario. Para la

introducción de la información se van a implementar areas de texto, menos en el estado

físico de la pieza que se predeterminan los estados posibles mediante una lista

deplegable.

El usuario podrá confirmar los datos o volver al menú inicial.

73


Diseño Ventana 4 Nombre: Confirmación Tipo: Salida Ventanas a las que llama: 2,3,5 Diseño:

Descripción: Muestra el identificador con el que se ha registrado la pieza confirmando que

el registro ha sido correcto. Desde esta ventana el usuario podrá volver a hacer un alta,

regresar al menú inicial o listar todas las piezas.

74


Diseño Ventana 5 Nombre: Listar incidencias Tipo: Salida Ventanas a las que llama: 2, 6, 7, 8, 9, 10. Diseño:

Descripción: Muestra los campos relevantes para el usuario encargado de resolver la

incidencia. El identificador se utilizará para seleccionar la pieza y ver los detalles de la

incidencia.

75


Diseño Ventana 6 Nombre: Visualizar incidencia Tipo: Salida Ventanas a las que llama: 7, 11. Diseño:

Descripción: Esta ventana saca por pantalla todos los datos de la pieza que se tengan

registrados junto con todos los mensajes que se han generado.

Dentro de esta pantalla todos los usuarios excepto supervisores podrán reubicar la pieza en

el almacén.

Cada vez que un usuario entre en una incidencia concreta visualizará esta misma pantalla

pero en lugar del recuadro verde se habilita el tipo de tratamiento que se puede dar a la

pieza si el perfil del usuario es el adecuado.

76


Las ventanas de la 7 a la 10 tendrán el mismo formato que la ventana 6, excepto la

zona donde se encuentra el rectángulo ACCIONES RESOLVER INCIDENCIA que será

sustituido por la acción correspondiente.

Diseño Ventana 7 Nombre: Todas Tipo: Entrada / Salida Ventanas a las que llama: 2, 11. Diseño:

Descripción: Las piezas con status other, not assigned y ws lisatarán todas estas opciones.

El usuario debe resolver la incidencia, seleccionando un radiobotton. En caso de que la

incidencia necesite información adicional para resolverse habrá que rellenar el campo

correspondiente.

77


Diseño Ventana 8 Nombre: Procesable Tipo: Entrada / Salida Ventanas a las que llama: 2, 11. Diseño:

Descripción: El usuario lista una pieza que es procesable por el sistema interno de la

empresa e intenta procesar la pieza. Si todo funciona correctamente selecciona el

radiobottom processed, sino tendrá que especificar el tipo de problema que ha tenido.

Diseño Ventana 9 Nombre: 4243 Tipo: Entrada / Salida Ventanas a las que llama: 2, 11. Diseño:

Descripción: El usuario debe resolver la incidencia. Seleccionando un radiobotton. En caso

de ser un crédito se deberá introducir el CSO correspondiente y si tiene otro problema

también se tiene que especificar.

78


Diseño Ventana 10 Nombre: Revisar datos Tipo: Entrada / Salida Ventanas a las que llama: 2, 11. Diseño:

Descripción: El usuario sólo podrá modificar los campos habilitados para ello. Si se

modifican los datos se pulsará changed y sino not changed.

79


Diseño Ventana 11 Nombre: Generar mensaje Tipo: Entrada Ventanas a las que llama: 2, 6, 7, 8, 9, 10. Diseño:

Descripción: El sistema muestra por pantalla el nombre de usuario que esta registrado en la

aplicación para que el usuario sólo pueda modificar los campos habilitados para ello. Si se

modifican los datos se pulsará changad y sino not changed.

80


Diseño Ventana 12 Nombre: Revisar datos Tipo: Entrada / Salida Ventanas a las que llama: 2, 6, 7, 8, 9, 10. Diseño:

Descripción: Esta pantalla se crea para agilizar el momento de procesar piezas. El usuario

proceso un grupo grande de piezas y luego se marcan todas las que han sido procesadas sin

necesidad de acceder a las piezas una por una.

81


Diseño Ventana 13 Nombre: Filtrar datos Tipo: Entrada Ventanas a las que llama: 2, 3. Diseño:

Descripción: Esta pantalla se crea para agilizar el trabajo de los usuarios. Cada usuario

podrá listar todas las piezas que tengan las características seleccionadas, para ello debe

marcar las casillas que desee (por eso se han utilizado chekboxes) y dato por el que filtrar.

82


Diseño Ventana 14 Nombre: Estadísticas Tipo: Salida Ventanas a las que llama: 2, 3. Diseño:

Descripción: La pantalla muestra el número de incidencias por almacén y los totales de cada

uno de los status.

83


Diseño Ventana 15 Nombre: Listar filtros Tipo: Salida Ventanas a las que llama: 2, 6, 7, 8, 9, 10, 13. Diseño:

Descripción: Muestra los datos filtrados de la pieza. Desde esta pantalla se podrá descargar

los datos visualizados en ella en un formato Excel.

Diseño Ventana 16 Nombre: Descarga Manual Tipo: Salida Ventanas a las que llama: 2, 3. Diseño:

Descripción: Muestra la opción de descargar el manual o volver al menú.

84


Capítulo 5 Implementación

85


5. IMPLEMENTACIÓN

5.1. INTRODUCCIÓN

Esta etapa recoge la programación utilizada en la herramienta de gestión, con

explicaciones de los lenguajes de programación usados en los componentes y la

programación utilizada para dar dinamismo a la página Web que ayuda a que exista una

interacción entre cliente y servidor utilizando un gestor de bases de datos.

5.2. ENTORNO ASP

La implementación se realiza bajo un entorno ASP, debido a los requisitos de una

aplicación dinámica e interactiva en la Web. Este entorno se va a combinar con

secuencias de comandos y componentes ActiveX, junto con páginas HTML.

El funcionamiento de una página ASP es sencillo. El usuario solicita un fichero

.asp al servidor Web a través del explorador. El servidor Web llama a ASP, que lee el

fichero solicitado, ejecuta las secuencias de comandos que encuentre y envía los

resultados al explorador del cliente.

El servidor realiza todo el trabajo necesario para generar las páginas que se envían

al explorador. Por tanto las secuencias no se ejecutan en el cliente sino en el servidor.

Gracias a esto las secuencias de comandos son transparentes al usuario que tan sólo

recibe el resultado de la ejecución en formato HTML.

86


Los ficheros .asp de esta aplicación contienen código ASP y código de HTML.

Cómo todos los ficheros .asp requieren una parte de proceso por el servidor, todos

aquellos ficheros que no necesiten de código ASP se han creado como ficheros .html, con

el objetivo de no sobrecargar el servidor.

El HTML, acrónimo inglés de HyperText Markup Language (lenguaje de marcas

hipertextuales), es un lenguaje de marcación diseñado para estructurar textos y

presentarlos en forma de hipertexto, que es el formato estándar de las páginas Web.

Gracias a Internet y a los navegadores del tipo Internet Explorer, Opera, Firefox o

Netscape, el HTML se ha convertido en uno de los formatos más populares que existen

para la construcción de documentos y también de los más fáciles de aprender.

La extensión del proyecto no permite el análisis de cada una de las páginas

implementadas por ello se van a puntualizar aquellas funcionalidades de la programación

más significativas o que requieran una atención especial.

OBJETOS ASP

Objeto Session: Permite almacenar la información necesaria para una

determinada sesión de usuario. Las variables almacenadas en el objeto Session no se

descartan cuando el usuario pasa de una página a otra dentro de la aplicación, si no que

dichas variables persisten durante todo el tiempo que el usuario tiene acceso a las páginas

de la aplicación. También puede utilizar los métodos de Session para terminar

87


explícitamente una sesión y establecer el periodo de tiempo de espera de inactividad de

las sesiones. En la aplicación este tiempo va a ser de treinta minutos. Si el usuario no

realiza ninguna acción en ese tiempo cuando intente utilizar la aplicación saldrá un

mensaje de error indicando que la sesión ha expirado.

Las variables de Session de un cliente sólo pueden ser accedidas por ese

cliente. El servidor crea automáticamente el objeto Session cuando un usuario que no

tenga actualmente una sesión solicita una página Web de la aplicación.

La aplicación consta de una serie de variables que almacenan valores importantes

para en el correcto transcurso de la aplicación. Como por ejemplo:

El objeto session(“usuario”) contendrá el nombre del usuario. Este dato se obtiene

en el momento que el usuario se registra en la aplicación. Se utiliza sobre todo en el

<% 'Inicialización de variables session("myfilter")="" session("newfilter")=True session("wfm_filter")=false session("hismyfilter")="" session("hisnewfilter")=True session("hiswfm_filter")=false usuario=session("usuario") if not session("aceptado") then response.redirect ("invasion.asp") end if %>

88


momento de generar los mensajes automáticos ya que es necesario que todo movimiento

de la aplicación quede registrado junto con el autor de éste.

Objeto Request: Se utiliza para tener acceso a la información que se pasa en las

peticiones HTTP. Entre dicha información se incluyen los parámetros que se pasan desde

los formularios HTML mediante el método POST o el método GET.

Dependiendo de la forma en que se realice el envío de los datos al servidor se

tendrá que utilizar una u otra de las diversas colecciones del objeto Request. Las

utilizadas en la aplicación son:

FORM recupera datos enviados desde un formulario mediante el método POST.

UERYSTRING recupera datos enviados como cadena de consulta HTTP.

Formularios (FORM)

Los formularios permiten dentro de una página Web solicitar información al

visitante para después procesar ésta. En el formulario se puede solicitar diferentes datos

(campos), cada uno de los cuales quedará asociado a una variable. Una vez se hayan

introducido los valores en los campos, el contenido de estos será enviado a la dirección

(URL) que pueda procesar las variables.

89


La declaración del formulario se pone entre las directivas <FORM></FORM>. En

el interior de la declaración se indican los elementos (variables) de entrada. La directiva

<FORM> tiene los parámetros action, method y [enctype].

A continuación se muestra la parte del código de newreverse.asp donde se genera

el formulario para dar de alta una pieza.

<form METHOD=post action="insert_newreverse.asp"> <table width="507"> <tr> <td width="125" height="34"><%=fecha_recepcion%>:< /td> <%fecha= obtenerDia() fecha_left=left(fecha, 6) fecha_right=right(fecha, 2) fecha=fecha_left & "20" & fecha_right%> <td height="34"><%=fecha%></td></tr> <td height="34"><input type="hidden" name=" REC_DATE" size="20"VALUE="<%=fecha%>"></td></tr> <tr> <td width="125" height="27"> <%=subcontrata_origen %>:</td> <td height="27"><input type="text" name=" SUBCONTRACTOR" size="10" VALUE="<%=session("SUBCONTRACTOR")%>">< /td> </tr> ......... <tr> <td width="125" height="30"><%=physical_statu s%>:</td> <td height="30"> < SELECT NAME="PHY_STATUS" VALUE="<%=session("PHY_STATUS")%>"> <%if session("PHY_STATUS")<>"" then%> <option value="<%=session("PHY_STATUS ")%>"> <%=session("PHY_STATUS")%> <%end if%> < option value="NUEVA">NUEVA <option value="USADA">USADA <option value="DOA">DOA <option value="UNKNOWN">UNKNOWN <option value="WS/WPIB">WS/WPIB <option value="EB">EB </SELECT></tr></td> <tr> ........ <p><center>press the arrow button to confirm all the d ata <input border="0" src="img/arrow_submit.g if" name="I1" width="19" height="16" type="image"> </p> </center> </form>

90


La información del formulario se envía al asp insert_newreverse. El primer campo

no es introducido por el usuario para evitar posibles complicaciones con el formato para

introducir fechas. Además esto ayuda a que los datos del sistema tengan más coherencia

y evita posibles manipulaciones. El entorno ASP permite, mediante unos mecanismos

que más adelante se explicarán, realizar llamadas a funciones como Obtenerfecha(), la

cual devuelve la fecha del sistema tratada para poder ser visualiza en la aplicación

correctamente.

Los campos restantes son campos de texto que no llevan mayor complicación,

excepto el estado físico de la pieza que es un la lista deplegable donde se listan todos los

posibles estados en los que se puede encontrar una pieza cuando tiene una incidencia. Por

último, la etiqueta <p><\p> que contiene el botón para formalizar el formulario.

Una vez se tiene toda la información se pasará a insert_reverse.asp del que se ha

seleccionado la parte relevante de código.

Se almacena en las variables correspondientes los valores del formulario para

posteriormente realizar el registro en la base de datos. Se observa que la variable

FECHA=request.form(" REC_DATE") SUBCONTRATA=request.form(" SUBCONTRACTOR") CSO = request.form("CSO_PACKING") WFM = request.form("WFM") PN = request.form("PN_PACKING") QTY = request.form("PACKING_QTY") PHY=request.form(" PHY_STATUS") STATUS="open" COMENTARIO=request.form("REMARKS") UBI=request.form("UBICATION")

91


STATUS se inicializa a “open” que es el status que le da el sistema a una pieza cuando se

registra. Una vez que se trate no volverá a este status.

QUERYSTRING

La colección QueryString recupera los valores del formulario pasados al servidor

Web como texto a continuación del signo de interrogación de la dirección URL de la

petición. Los valores del formulario se pueden anexar a la dirección URL de la petición

mediante el método GET de HTTP o, manualmente, si se agregan los valores del

formulario a la dirección URL.

En la aplicación, para poder seleccionar una pieza dentro de un listado de piezas,

se ha utilizado esta opción que ofrece el entorno. El usuario no introduce información

solamente selecciona una de las piezas y el sistema toma el identificador la pieza y la

concatena a la URL para pasar la información.

El asp correspondiente trata la información para visualizar todos los datos de la

pieza.

id = Request.QueryString("ID") 'Obtener el ID de la pieza

<td height="21" nowrap width="35" align="center" bgcolor="<%=color%>"> <%cad = "showreverse.asp?ID="&rstemp("ID_PART") %> <center> <a class="navArrowBold" href="<%=cad%>"> <%=rstemp("ID_PART")%></a> </center></td>

92


Objeto Response: Se utiliza para controlar la información que se envía al usuario.

Esto incluye el envío de información directamente al explorador, la redirección del

explorador a otra dirección URL. Este objeto puede implementar varios métodos, en la

aplicación sólo se ha hecho uso del método Redirect, que redirecciona de una página a

otra.

Este método ha sido utilizado en todos los asp que insertaban algún dato en la

base de datos de la herramienta para poder confirmar que el proceso ha finalizado con

éxito.

Objeto Server: Proporciona acceso a los métodos y las propiedades del servidor.

El método que se ha utilizado es el que crea una instancia de un componente ActiveX

(Server.CreateObject).

Los componentes ActiveX se han diseñado para que se ejecuten en el servidor

Web como parte de las aplicaciones Web, proporcionan funcionalidad a las aplicaciones,

como el acceso a ficheros, Bases de datos, etc.

Existen componentes ActiveX para tareas muy diversas, en la aplicación sólo se

ha operado con algunos de los que se incluyen por defecto en la instalación de ASP. Los

objetos y los métodos utilizados por la aplicación se desarrollan en el siguiente apartado

con el tratamiento de las bases de datos.

response.redirect("OK_reverse_requested.asp")

93


5.3. TRATAMIENTO DE LA BASE DE DATOS

En este punto se explicará cómo se ha realizado el acceso a base de datos. Se

mostraran algunas de las sentencias SQL utilizadas en el desarrollo de la aplicación, y

por último una carga de datos al sistema a través de un fichero .txt.

El acceso a la base de datos del servidor se va a realizar en varias fases, primero

se crea un objeto Server indicando el tipo de conexión. El objeto creado se abre

especificando el tipo de base de datos al que se desea acceder, su ubicación en el servidor

correspondiente y las claves para el acceso a la base de datos.

Una vez realizada la conexión con la base de datos correspondiente se pasa a

preparar la sentencia que se desea realizar. En el conjunto de la aplicación se han

requerido gran número de consultas, algunas muy simples y otras que han necesitado de

una preparación previa.

El ejemplo que se muestra en las líneas de código siguientes corresponde al

algoritmo que genera la sentencia SQL para cargar aquellos datos por los que el usuario

está filtrando. La información se recibe a través del formulario Form.

'conexión a la BD origen de los datos. set conntemp = server.createobject("adodb.connecti on") 'conexión a la BD de datos del Retenidas conntemp.Open "PROVIDER=MSDASQL;DRIVER={Microsoft Access Driver (*.mdb)}; DBQ=d:\wwwroot\gsl- iberia.hp.com\Share\1databases\reversewfm\retenida s.mdb;id=pepe;pw d=pepe"

94


cadSQL=" SELECT * FROM REVERSE WHERE " orderby="" anadir="" ' La variable que comienza con C esta a YES entonc es el filtro por ese campo esta activado. If(request.Form("C_ID") ="YES") Then id=request.Form("ID") add=" ID_PART="&id cadSQL=cadSQL & add anadir=" and " Else add=" ID_PART > 1" cadSQL=cadSQL & add anadir=" and " End if If(request.Form("C_STATUS")="YES") Then status=request.Form("STATUS") If (status<>"pareto") then add=" HOLD_STATUS = '" & status & "'" cadSQL=cadSQL & anadir & add anadir=" and " Else add=" HOLD_STATUS LIKE '%" & status & "%'" cadSQL=cadSQL & anadir & add anadir=" and " End if End If If(request.Form("C_REC_DATE")="YES") Then rec_date=request.Form("REC_DATE") fecha=rec_date dia=day(fecha) if (len(dia)=1) then dia = "0"&dia end if mes=month(fecha) if (len(mes)=1) then mes = "0"&mes end if anno=year(fecha) if (len(anno)=2) then anno = "20"&anno end if rec_date=dia&"/"&mes&"/"&anno add=" REC_DATE= '" &rec_date & "'" cadSQL=cadSQL & anadir & add anadir=" and " End if If(request.Form("C_OUTSOURCED")="YES") Then out=request.Form("OUTSOURCED") add=" SUBCONTRACTOR like '"& out & "%'" cadSQL=cadSQL & anadir & add anadir=" and " End if

95


El algoritmo inicializa la variable cadSQL con el inicio de la sentencia indicando

la tabla de la que se necesita filtrar datos. En este caso las piezas que actualmente se

encuentran en el sistema. El usuario selecciona mediante la activación de los checkbox

los campos por los que desea filtrar e introduce los datos, luego el sistema comprueba si

el campo esta activado y si es así toma los datos introducidos en área de texto y los

concatena a la variable cadSQL.

Según el tipo de usuario que realiza la consulta podrá visualizar toda la

información existente en la base de datos o solamente aquella en la que esté implicado.

if (session("tipousuario") =" almacen") then LOCALIZACION=right(session("usuario"),4) 'Los ultimos 4 caracteres del usuario add= " LOCATION = '" & LOCALIZACION&"'" cadSQL=cadSQL & anadir & add anadir=" and " else If(request.Form("C_LOCALIZACION")="YES") Then LOCALIZACION=request.Form("LOCALIZACION") 'Si se elige la opcion all mostramos todos los alm acenes if(request.Form("LOCALIZACION")="ALL") then add= " (LOCATION = 'AMVS' or LOCATION = '7000' or LOCATION = '7001' or LOCATION = '7002' or LOCATION = '7003' or LOCATION = '7004' or LOCATION = '7007' or LOCATION = '7008' or LOCATION = '7009' or LOCATION = 'L300' or LOCATION = 'L301' or LOCATION = 'LOG')" 'sino, mostramos solo el seleccionado else add= " LOCATION = '" & LOCALIZACION &"'" end if cadSQL=cadSQL & anadir & add anadir=" and " End if End if session("newfilter")=false session("myfilter")=cadSQL End if %>

96


Esto se utiliza con el perfil de almacén para que no tenga acceso a los datos de otros

almacenes.

Tras comprobar todos los campos se almacena la sentencia en la variable de

session myfilter por si el usuario tras realizar la consulta y visualizar una pieza en

concreto desea volver a realizar la misma consulta.

Una vez preparada la consulta correspondiente se procede a obtener los datos

necesarios ejecutando la sentencia.

La variable rstemp tiene cargado el resultado de la consulta y para recorrer los

datos se utiliza un bucle while con la condición de no finalizar hasta terminar de leer

todos los datos cargados. Se utiliza este bucle para ir listando cada una de las piezas con

las características seleccionadas por el usuario.

cadSQL = cadSQL & " order by ID_PART" set rstemp=conntemp.execute(cadSQL)

while rstemp.EOF = FALSE ………… <td height="21" nowrap width="35" align="center" bgcolor="<%=color%>"> <%cad = "nuevoreverse.asp?ID="& rstemp("ID_PART") %> <center><A class="navArrowBold" h ref="<%=cad%>"> <%=rstemp("ID_PART")%></A></center></td> ………………… rstemp.movenext wend conntemp.close

97


Otro ejemplo es la generación de mensajes automáticos. Cada vez que se realiza

una acción sobre una pieza requiere de una preparación y de dos sentencias. La primera

sentencia para obtener el último identificador del mensaje asignado en el sistema, para

sumarle uno y así tener el nuevo identificador. La segunda para cargar la información en

la base de datos.

En el mensaje que se guarde se debe almacenar la fecha y hora que se obtienen del

sistema mediante dos funciones. El autor se obtiene de la variable de session

nombreUsuario inicializada en el momento de registrarse el usuario. Por último el cuerpo

del mensaje se genera según el tipo de incidencia se procesa con los datos obtenidos del

formulario de solucionar incidencia.

98


El cruce entre la aplicación y los sistemas internos de la empresa trata un fichero

de texto .txt generado por un la herramienta Brioquery. El fichero contiene los datos de la

ejecución de la sentencia, que obtiene los datos necesarios de las piezas registradas en los

de los tres sistemas internos de la empresa.

El tratamiento del fichero se va a realizar mediante un objeto Server del que se

instancia el objeto FileSystemObject.

'Preparar la posicion del mensaje,hora,fecha y auto r. 'Se obtiene el mayor ID para asignarle uno mas al m ensaje mySQL = "select max(ID_MESSAGE) from MESSAGES" set getIDMess = connmen.execute(mySQL) idMess = (getIDMess(0) + 1) 'Inser los datos del mensaje: fecha = obtenerDia() hora = obtenerHora() autor = session("nombreUsuario") 'Si pieza procesada sin problemas: If (accion="QA") Then 'Asignar a otro CSO texto = UCase("Credit part "&rs("PN_PAC KING")&" from CSO: " &nuevo_cso) Else If(accion="OK") then texto = UCase("part "&rs("PN_PACKING")&"/ "&rs("CSO_PACKING")&"have other problem "&problem) else texto = UCase("part "&rs("PN_PACKING")&"/ "&rs("CSO_PACKING")&" ready to "&nuevo_status) End if End if SQLInsertMess=" insert into MESSAGES (ID_MESSAGE, ID_REVERSE, AUTHO R, DATE_MESS, TIME_MESS, TEXT_MESS) values " SQLInsertMess=SQLInsertMess& "("& idMess&","&id_re&",'"&autor&"','"&fecha&"' ,'"&hora&"','"&texto &"')" 'Insertar mensaje set men=connmen.execute(SQLInsertMess)

99


El fichero Macau_WFM.txt ubicado en la ruta especificada se abre en modo

lectura.

El tamaño del fichero es tan grande que la carga de los datos en los formularios de

asp no permite tanto volumen. La solución por la que se optó para resolver el problema

fue crear un grupo de veinte ASP, capaces de leer todo el fichero y cargar información en

la base de datos. Cada una de estas páginas tiene un bucle que no finaliza hasta que

leer quinientas líneas o llegar a final de fichero.

Se utiliza la función read(1) que lee el fichero por caracteres. La lectura del

fichero se realiza carácter a carácter, para ello se implementan una serie de bucles para

cada uno de los datos.

set ObjFileSys = server.createobject ("Scripting.Fi leSystemObject")

set TheTextStream = ObjFileSys.OpenTextFile

("g:\reversedata\datasys\ficheros_carga\Macau_WFM.t xt", 1)

do until contador = 500 or thetextstream.atendofstr eam ……………….. car= thetextstream.read(1) do until asc(car) = 9 CSO_Number = CSO_Number & car car=thetextstream.read(1) loop car= thetextstream.read(1)

100


En cada vuelta del bucle se genera una línea del formulario con un identificador

que corresponde con el número del contador. Una vez que finalice el bucle o se llegue al

final del fichero la página se redirecciona a otro asp que carga los datos en la base de de

datos SYSTEM.

La petición de ejecutar el objeto Request aquí utilizado se realiza mediante la

ejecución de un script. Una vez que el bucle finaliza, el formulario se encuentra cargado

y es el script el que ejecuta la acción submit para que se envie al asp correspondiente

información recogida.

<input type=text name="CSO_LOCK-<%=contador%>" value=<%=CSO_LOCK%>><p> <input type=text name="Part_Qty-<%=contador%>" value=<%=Part_Qty%>><p> <input type=text name="FAILURE_CODE-<%=contador% >" value=<%=FAILURE_CODE%>><p> <input type=text name="WFM_SYS-<%=contador%>" value=<%=WFM_SYS%>><p> <% contador= contador +1 loop 'fin del bucle para un fichero %> <input type=hidden name="contador" value="<%=conta dor%>"> <input type=hidden name="pagina" value=<%=page_nam e%>> </form> <script language="JavaScript"></script>

101


5.4. SCRIPT’S & JAVASCRIPT

Un script es un programa que puede acompañar a un documento HTML o que

puede estar incluido en él. El programa se ejecuta cuando se carga el documento, o en

algún otro instante, como por ejemplo cuando se activa un vínculo. El soporte de scripts

de HTML es independiente del lenguaje de scripts.

En el desarrollo de la aplicación se ha hecho uso de funcionalidad, para poder

ejecutar funciones sin necesidad de duplicar el código en más de un documento y además

para aligerar el peso de las páginas.

El script que se va a ejecutar normalmente llama a un fichero .js. Éste es un

fichero de texto plano que contiene scripts de JavaScript. En éste se pueden guardar

funciones y variables globales que podrán leerse desde cualquier página HTML o ASP.

Por otra parte, hay que indicar que el fichero en cuestión (.js) contendrá sólo código en

Javascript, no etiquetas de ningún tipo, ni siquiera las de apertura y cierre de SCRIPT

(<script> </script> ).

El siguiente código pertenece a un fichero .js cuya funcionalidad es inicializar las

variables de la estructura de todas las páginas con sus enlaces correspondientes.

102


La llamada a esta función se realiza al cargar la página de inicio de la siguiente

manera:

En determinadas ocasiones es necesario ejecutar una función al cargar un ASP,

pero esta función no va a ser reutilizada por ninguna otra página, por lo que no resultaría

muy funcional generar un fichero especifico para ejecutar el script. Se introduce script

entre las etiquetas de <script> y </script>, se determina el tipo de lenguaje que se va a

utilizar y se inserta la función. Un ejemplo de esto es la inicialización del formulario de

filtros.

// SNF JAVASCRIPT snf2_utilities.js VERSION 2.0

// General variables

var onImg = new Array();

var offImg = new Array();

// Files and directory structures

var navImgDir = "../img";

varcssDir="http://welcome.hp.com/country/styles/";

<script language="JavaScript" src=" snf2-js/snf2_utilities.js " type="text/javascript"></script>

103


5.5. TAREAS PROGRAMADAS

El sistema operativo Windows permite la configuración cualquier secuencia de

comandos, programa o documento para que se ejecute en una fecha y horas determinadas,

según le convenga. Esta funcionalidad se va a utilizar para actualizar la base de datos de

la herramienta con los datos de los sistemas de la empresa.

<script language="JavaScript">  </script>

104


Capítulo 6 Plan de pruebas

105


6. PLAN DE PRUEBAS 6.1. INTRODUCCIÓN

Una vez se hayan desarrollado cada uno de los programas componentes de la

aplicación se realizarán cinco pruebas para conseguir la integración absoluta del sistema,

verificar la calidad y un nivel aceptable de fiabilidad.

Las pruebas a realizar serán:

- Pruebas unitarias.

- Pruebas funcionales.

- Pruebas de seguridad.

- Pruebas de aceptación.

- Pruebas de regresión.

6.2. PRUEBAS UNITARIAS

Consisten en comprobar la funcionalidad requerida del programa de acuerdo con

las especificaciones anteriores. Estas pruebas se realizan unitariamente, y comprueban el

buen funcionamiento de las partes por separado de la aplicación. Se comprobarán todas

las funciones y clases antes definidas, en el proceso mismo de programación. Para la

realización de este tipo de pruebas se tendrá la ayuda de herramientas “debuggers”,

capaces de ejecutar paso a paso el programa, mostrando el contenido de variables y/o

alternándolo para forzar a la aplicación a emprender unos caminos u otros.

106


6.3. PRUEBAS FUNCIONALES

Este plan de pruebas comprobará que se cumplen todas las funcionalidades de la

aplicación de forma satisfactoria, definidas previamente en el análisis de requisitos y

ampliadas progresivamente en el resto del documento.

Los funcionamientos a comprobar son:

• Un acceso óptimo y correcto a la base de datos.

• La representación correcta de los datos en la aplicación y del interfaz

gráfico.

• El correcto listado de las piezas retenidas.

• La existencia de un historial y que cumpla con los requisitos acordados.

• La posibilidad de filtrar información correctamente.

• La correcta actualización de las bases de datos.

• Compatibilidad con los navegadores estándar.

• Posibilidad de descargar ficheros con los datos filtrados.

• El buen funcionamiento de la herramienta de administración del sistema.

• La posibilidad de insertar/modificar/borrar datos en las tablas del sistema.

6.4. PRUEBAS DE SEGURIDAD

Esta prueba comprobará las funciones y mecanismos de seguridad en cuanto a

accesibilidad del sistema y las funciones permitidas en cuanto a perfiles de usuario.

107


Los pasos a realizar en esta prueba son:

• Comprobación del funcionamiento del sistema de autentificación.

• Revisar que el almacenamiento de contraseñas e información vulnerable sea

seguro.

• Comprobación de los niveles de usuario y sus privilegios en el tratamiento

de los datos del sistema.

6.5. PRUEBAS DE ACEPTACIÓN

Estas pruebas son las de aceptación del usuario, y con ellas se pretende validar

desde el punto de vista del usuario que la aplicación es correcta. En el aspecto de

utilización se verificará la facilidad de uso del sistema que se debe manejar. El usuario

trabajar con la aplicación y dar una visión de la aplicación respondiendo a las siguientes

preguntas:

• ¿Es agradable el interfaz?

• ¿Considera que la aplicación es intuitiva?

• ¿Qué funcionalidades añadiría?

• ¿Qué mejoraría?

• ¿Qué es lo que más le ha gustado?

• ¿Qué es lo que menos le ha gustado?

• ¿Fue fácil manejarse en la aplicación?

• ¿Han sido adecuados los tiempos de respuesta?

108


• Valoración personal.

• Valoración de la funcionalidad del sistema.

• Valoración de la utilidad del sistema.

6.6. PRUEBAS DE REGRESIÓN

Una vez realizadas las pruebas detalladas anteriormente, se modificará el sistema

para conseguir mejorar la aplicación. Tras la modificación, se deberá volver a comprobar

el sistema, revisando otra vez todas las pruebas. Al finalizar esta revisión, y si la

aplicación no pasa todas las pruebas, se volverá a repetir el proceso tantas veces como

sean necesarias para conseguir una aplicación que cumpla con lo establecido.

109


Capítulo 7 Planificación real

110


7. PLANIFICACIÓN REAL

La realización de este proyecto se ha desarrollado en colaboración con la empresa

Hewlett Packard.

Este proyecto se inició el 8 de Octubre de 2005. Con la primera entrevista con la

gerente del departamento de logística. En ella se establecieron los objetivos y

funcionalidades de la aplicación. En los días siguientes se realiza una planificación inicial

para establecer los plazos de cada una de las etapas. En esta planificación se estableció un

tiempo cada dos semanas para realizar un pequeño informe especificando el avance del

proyecto.

Durante el mes siguiente se llevó a cabo el análisis de requisitos, para el que fue

necesario realizar entrevistas con los distintos implicados en el funcionamiento de cada

uno de los procesos. El objetivo era conseguir profundizar al máximo en todos los

requisitos que se iban a requerir para cada uno de los procesos.

Tras el análisis se define la arquitectura y la tecnología que se iba a utilizar para el

desarrollo de la aplicación.

A mediados de Noviembre se comienza con el diseño de los interfaces gráficos de

la aplicación y el modelo de la base de datos.

111


Una vez realizados los pasos anteriores ya se podía comenzar con la

implementación de los procesos más básicos. La herramienta debía estar terminada para

Febrero aunque no estuviesen todas las funcionalidades listas. Por ello se distingue entre

procesos básicos y los que no lo son.

Conforme se iba implantando la aplicación se fueron produciendo pequeños

cambio en el diseño de la aplicación. A finales de Enero se realizó la primera demo y

junto con ella una batería de pruebas de la que se obtuvo modificaciones importantes y

nuevos requisitos para el sistema que se estaba desarrollando. Comenzando un nuevo

ciclo de análisis pero de menor extensión.

A finales de Febrero se realizaron una serie de auditorias internas para obtener los

datos reales de las piezas retenidas en el almacén para poder cargar dicha información el

día de arranque de la aplicación.

El 1 de Marzo de 2006 se decide arrancar de manera oficial con la aplicación

aunque no estuviera funcionando a pleno rendimiento. Durante los dos meses siguientes

se continúo con la programación de las funciones que no habían sido implementadas

antes del arranque.

La documentación se realiza durante el transcurso del proyecto. Y la elaboración

de esta memoria en el verano para su entrega en el mes de Septiembre.

112


113


Capítulo 8 Valoración económica

114


8. VALORACIÓN ECONÓMICA

8.1. INTRODUCCIÓN

En este capítulo se procede a realizar una valoración económica de los costes

tangibles asociados al desarrollo e implantación del sistema. Para su realización se ha

dividido en tres apartados que son costes de personal, hardware y software. Al final se

detalla el presupuesto de los costes totales del proyecto.

8.2. COSTES DE PERSONAL

En este apartado se van a contabilizar los costes asociados al personal implicado

en el desarrollo del proyecto.

Jefe de proyecto: Responsable de la planificación, ejecución y control del

proyecto. Esta persona es el motor que debe impulsar el avance del proyecto mediante la

toma de decisiones tendentes a la consecución de los objetivos. La estimación de dicho

papel en la vida del proyecto es de un 20%.

Analista de sistemas: Encargado de atender los requerimientos o necesidades de

los usuarios del sistema. Mediante el análisis de las especificaciones técnicas y

funcionales elabora los documentos pertinentes para la posterior implementación. La

dedicación en el proyecto se estima en un 35% del total.

115


Programador: Responsable de desarrollar en código las especificaciones

realizadas por el analista del sistema. El programador es la persona que mayor dedicación

ha tenido en el proyecto, se estima en un 45% de la elaboración total de la aplicación.

La estimación de la duración del proyecto es de 450 horas, en la siguiente tabla se

detallan los salarios de los implicados y el porcentaje de actuación en el proyecto.

Perfil

Euros / hora

% Dedicación

Horas dedicadas

Costes totales

Jefe de proyecto

50

20

90

4500

Analista sistema

35

35

158

5530

Programador 25

45

202

5050

Total

15080

8.3. COSTES DE SOFTWARE

En este punto se valoran todas las aplicaciones necesarias para el desarrollo e

implementación de la aplicación. El software utilizado se detalla a continuación.

116


Software

Coste licencia ( € )

S.O. Windows XP Professional 310

Microsoft Office 2003

600

Acrobat Proffessional

500

Brioquery 6.0

450

WS_FTP Professional 7.5

645

Total

2505

8.4. COSTES DE HARDWARE

En este apartado se van a valorar aquellos dispositivos necesarios para el

desarrollo del proyecto. El servidor al ser un recurso compartido con otras aplicaciones

que tiene la empresa solamente se imputará un 10% del coste del mismo.

Hardware


Total ( € )

Ordenador Compaq

750

750

Servidor HP

3500

350

Total

1100

117


8.5. COSTES TOTALES

En este apartado se realizará la suma de los costes anteriores obteniendo así el

coste final del desarrollo del proyecto.

Coste


Personal

15080

Software

2505

Hardware

1100

Total sin IVA

18685

IVA (16%)

2990

Total con IVA

21675

118


Capítulo 9 Conclusiones

119


9. CONCLUSIONES

La posibilidad de realizar una aplicación de esta envergadura desde la idea

original hasta su implementación completa pasando por todas las fases para su desarrollo,

ha supuesto todo un reto personal. La mayor aportación que se ha podido recibir de este

proyecto ha sido la utilización de todos los conocimientos adquiridos desde el comienzo

de la carrera y dando un sentido al porqué de las asignaturas y el contenido de las

mismas. Ha sido el colofón final para terminar la carrera con una base importante.

También ha servido para dar valor a la capacidad que se ha ido desarrollando durante la

carrera a enfrentarse a problemas no previstos y buscar las herramientas para solventarlo

sin rendirse por camino. Todo esto junto con la posibilidad de trabajar en una de las

grandes empresas del sector y conocer su funcionamiento de desde dentro ha sido muy

satisfactorio.

Este proyecto no sólo ha dado valor a la autora sino a la empresa para la que se ha

realizado ya que el éxito de la aplicación ha ayudado a ahorrar muchos costes y solventar

muchas incidencias y sobretodo a evitar la pérdida de recursos. Esto hace que el proyecto

tenga aún más valor.

En conclusión el éxito del proyecto no sólo ha sido el buen funcionamiento y

aceptación que ha tenido la aplicación gracias a su interfaz sencillo e intuitivo, sino el

enriquecimiento personal para la autora del mismo.

120


Anexo A

121


MANUAL DE USUARIO 1. Acceso a la aplicación.

2. Menú principal.

3. Introducir incidencias.

4. Solucionar incidencias.

4.1. Gestiones almacén.

4.1.1. Review data.

4.1.2. To Process.

4.1.3. Credit.

4.1.4. E-returns.

4.2. Gestiones logísica.

4.2.1. Not assigned.

4.2.2. Wfm not CSO.

4.2.3. 4243.

4.2.4. WS.

4.3. Gestión sistema.

4.3.1. Duplicated.

4.3.2. Workitng.

4.3.3. Open.

5. Procesar rápido incidencias.

6. Cambios ubicaciones.

7. Búsquedas – Filtros.

8. Estadísticas.

122


1. Acceso a la aplicación

El acceso a la aplicación se realiza a través de la página de validación del usuario.

Como se puede ver en la imagen en esta página sólo requiere del usuario y contraseña

para el acceso.

Así se accederá directamente al menú principal de la aplicación.

123


2. Menú principal

La página principal de la aplicación ofrece 7 opciones de menú tal y como muestra la

imagen.

3. Introducir incidencias

Elige en el Menú principal, la primera opción: “insert a new reverse”. Esta opción

ofrece incluir una nueva pieza en la lista de piezas con incidencias. Los datos que se

solicita sobre la pieza son:

124


• Outsourced activity: Procedencia de la pieza (p.e. HP Bilbao, Infodec Madrid,

…)

• Cso packing: Número CSO de la pieza.

• WFM: Número WFM de la pieza.

• Part number packing: Part number de la pieza.

• Physical status: Estado físico en el que se encuentra la pieza.

� NUEVA.

� USADA.

� DOA.

� UNKNOWN.

� WS/WPIB (Wrong Shipment/Wrong part in Box).

� EB (Empty Box).

� Packing quantity: Cantidad de piezas.

� Ubication � Ubicación de la pieza (dónde se guarda la pieza en el almacén

mientras que se espera la resolución de la incidencia, p.e. Pallet 2, Caja 15/12,

24C, …)

125


� Remarks � Comentarios a cerca de la pieza.

Se debe introducir de estos datos todos los conocidos. Después de confirmar los datos de

la pieza (pinchar flecha tras “press the arrow button to confirm all the data”), esta

aparecerá incluida en la lista de incidencias.

Tras confirmar:

126


El número de la incidencia es 15969. Desde aquí se pode introducir una nueva

incidencia, listar todas las piezas o volver al menú principal.

4. Solucionar incidencias

La segunda opción en el Menú principal: “View all the reverse”, muestra la lista

de todas las piezas retenidas. Si el perfil del usuario es del almacén sólo listará las piezas

asociados a éste.

En la lista general se obtienen algunos datos sobre la pieza. Sin embargo, a través

del número de identificador de la pieza se puede acceder a toda su información. (Pinchar

en la columna ID, sobre el número de la incidencia que se quiera revisar).

127


Una parte de la información son los datos introducidos al incluir la incidencia y

otra parte son datos añadidos por el sistema o por las personas en HP que gestionan las

incidencias.

El dato más importante para gestionar las incidencias en la aplicación es el

STATUS de la incidencia.

El STATUS de la incidencia indica quién tiene que actuar sobre la incidencia y

qué se debe hacer. Tras realizar la acción correspondiente, la persona cambia el status y

así pasa la incidencia a la siguiente persona responsable de continuar con el proceso.

128


4.1 Gestión almacén

4.1.1 Review data

En el caso de una pieza con status “review data”, logística quiere que el almacén

verifica que los datos introducidos sobre la pieza son correctos, ya que se tienen

problemas en encontrar la pieza en los sistemas.

Se puede modificar el CSO number, WFM number, partnumber y estatus físico de

la pieza sobrescribiendo los datos que existen y señalando después la opción “changed”,

o por el contrario si los datos son correctos y la revisión no ha causado ninguna

modificación se marcará la opción “not change”. Y pinchar a continuación la flecha tras

“press the arrow button to confirm all the data”.

129


Si se realiza algún cambio de vuelta al listado la pieza obtendrá el status

“checked” y sino el nuevo status “not assigned”, para que alguien en logística tomará

acción sobre la pieza.

4.1.2 To Process

En el caso de una pieza con status “to process”, lógistica indica al almacén que la

incidencia ha sido resuelto y que ahora en los sistemas todo debe estar en acuerdo con los

criterios para procesar una pieza con normalidad.

El almacén debe procesar la pieza según el proceso estándar (verificar CSO Lock

= L o D, pieza nueva tiene A o pieza usada tiene C o V,…) y posteriormente indicar en la

aplicación si se ha podido procesar o no.

130


Se puede observar, se que hay dos posibilidades asociadas a una pieza con este

estatus:

• Processed: Se seleccionará esta opción cuando la pieza haya sido procesada

correctamente.

• Not processed: Ésta será la opción adecuada cuando la pieza no se haya

podido procesar debido a algún problema, que también será especificado a

través de la opción “problem with”.

131


Posibles opciones por lo que la pieza no ha sido procesada son:

• WS = Wrong Shipment: cuando se coge la pieza para procesarla, el almacén

se da cuenta que es un wrong shipment y anteriormente no ha sido reportado

de esa forma.

• 4243: El estatus físico de la pieza no concuerda con el estatus en la pantalla

CU de SAM.

• Not assigned: La pieza no aparece en la pantalla CU de SAM.

• Other: No se podía procesar por algún otro motivo que los especificados. En

este caso se debe añadir un comentario explicativo “add a new message” con

el motivo para que las personas en lógistica pueden tomar acción.

NOTA: Si una pieza de la lista no se ha procesado simplemente porque no ha

habido tiempo para ello, no se modificará la incidencia con ninguna de estas opciones.

No se hará nada con la incidencia, se quedará tal y como está y en sucesivos accesos a la

aplicación la pieza continuará con el mismo estatus “to process”.

132


4.1.3 Credit

En el caso de una pieza con status “credit” , logística indica al almacén que la

pieza físicamente nueva ya no se encuentra en el CSO indicado, y por eso se debe

acreditar del CSO o pool indicado en el comentario y devolver a AMVS.

De la misma manera que en el caso de “to process”, el almacén debe

posteriormente indicar en la aplicación si la pieza se ha podido procesar (acreditar) o no.

4.1.4 E-returns

En el caso de una pieza con status “e-returns”, logística indica al almacén que la

pieza físicamente usada ya no se debe revisar en SAM, y se puede simplemente enviar a

AMVS junto con los demás piezas gastadas (apuntándola en el packinglist), dónde será

procesada en la herramienta e-returns.

De la misma manera que en el caso de “to process”, el almacén debe

posteriormente indicar en la aplicación si la pieza se ha podido procesar (devolver a

AMVS como gastada) o no.

133


4.2 Gestión logística

4.2.1 Not assigned

Las piezas con este status son aquellas que no están asignadas a ningún caso CSO

o éste no es correcto.

Las acciones que se pueden realizar son cuatro.

134


• positive adjustment �� ajustar una pieza a +.

• e-returns �� Piezas que se van a procesar como gastadas.

• credit from �� La pieza se asigna a otro CSO, que se debe introducir en el

espacio que aparece a su derecha.

• CSO correct �� Se introduce el CSO correcto de la pieza.

4.2.2 WFM not CSO

Las piezas con este status son aquellas que posen en número de WFM pero no

tienen el número de CSO correspondiente. Este status se trata con las mismas opciones

que se encuentran en una pieza not assigned.

4.2.1 4243

Un caso 4243 es aquel en el que la pieza es USADA mientras que el sistema

refleja un status A (=nueva).

Respecto a una pieza con status 4243, se pueden realizar tres acciones:

• e-returns �� Piezas que se van a procesar como gastadas.

135


• credit from �� La pieza se asigna a otro CSO, que se debe introducir en el

espacio que aparece a su derecha.

• Other �� Cualquier otro caso no contemplado, que se debe registrar en el

espacio de su derecha.

4.3 Gestión sistema

4.3.1 Duplicated

Las piezas con status duplicated quedan fuera del tratamiento por parte del

usuario. Son piezas que debido al cruce con los sistemas han resultado duplicadas y que

temporalmente se encuentran con este status hasta que los administradores del sistema

resuelvan esta duplicación y actualicen en la aplicación los datos correctos para continuar

con el tratamiento de la pieza.

4.3.2 Working

El status working de una pieza refleja que ha sido tratada por el sistema pero aún

no cumple las condiciones requeridas para pasar a alguno de los otros status. Éstas serán

típicamente piezas cuyo caso aún está abierto en los sistemas.

136


4.3.3 Open

Cuando una pieza se inserta por primera vez en la aplicación adquiere el estatus

open. Este status lo mantendrá la pieza hasta que haya sido tratada por el sistema pasando

así al nuevo status que le corresponda.

5. Procesar rápido incidencias

La tercera opción en el Menú principal: “List reverse to process”, muestra la lista

de todas las piezas en el almacén que se puede procesar, es decir, las que tienen el estatus

“ to process” o “e-returns”.

Los “credit” no están incluidos, ya que se necesita entrar en el detalle para obtener

la información del comentario para saber de qué pool o CSO acreditar la pieza.

137


En la primera columna (OK) se puede marcar todas las piezas que han sido

procesadas sin necesidad de acceder a las piezas una por una. Si una vez marcado se

pincha “press the arrow to process the selected reverse”, todas esas piezas pasarán al

estatus “processed”.

6. Cambios ubicaciones

El campo “Ubication” de una incidencia, que el almacén rellena cuando introduce

una nueva incidencia, indica dónde se guarda la pieza en el almacén mientras que se

espera la resolución de la incidencia.

Si el almacén quiere guardar la pieza en otro sitio, se puede actualizar el campo

“Ubication” en la aplicación, independientemente del estatus que tiene la incidencia.

Ejemplo: La pieza retenida A3714-69002 del CSO 7000EBM4501 está guardada

en el Pallet 3 y la incidencia está pendiente de resolver. Ahora el almacén la cambia de

ubicación y la guarda en A-13.

Se escribe el cuadro blanco la ubicación nuevo A-13 y se pulsa en “ubication

change”.

138


7. Búsquedas - Filtros

Esta opción en el Menú principal: “Filters”, permite realizar búsquedas dentro de

la aplicación según varios criterios.

139


Se deben seleccionar aquellos campos por los que se este interesado filtrar y

pinchar sobre la flecha. En caso de necesitar realizar otra filtración se deberían resetear

los filtros. El resultado de la búsqueda:

Una vez realizada la búsqueda se puede descargar la información obtenida en un

fichero Excel, realizar una nueva búsqueda o regresar al menú principal.

8. Estadísticas

En “Statistical Information”, se obtiene un informe con los datos sobre los

números de piezas retenidas junto con su valor.

140


141


Anexo B

142


BIBLIOGRAFÍA

[POWEL02] Thomas Powell. Fritz Schneider; “JavaScript. Manual de referencia”, 1ª

Edición, McGraw-Hill, 2002.

[FERRA02] Alex Ferrara, Matthew MacDonald; “Programming .NET web services”,

O’Reilly, 2002.

[RIVER02] Enrique Rivero. Luis Martínez. Luis Reina. Juan Benavides. Juan Mª

Olaizola. Introducción al SQL para Usuarios y Progamadores. Thomson

2004.

[BARRA01] Barranco de Areba, Jesús; “METODOLOGÍA DEL ANÁLISIS

ESTRUCTURURADO DE SISTEMAS”; 2º Edición, Universidad

Pontificia de Comillas, 2001.

Páginas Web utilizadas a modo de ayuda:

www.wikipedia.org: enciclopedia libre.

www.microsoft.com, página oficial de Microsoft.

www.asptutor.com/asp/default.asp, tutorial de programación ASP.

www.desarrolloweb.com, desarrollo aplicaciones Web.

www.sql.org/, utilización de sql.

Documents

Gestión y control de incidencias en stock - IIT Comillas · proyecto fin de carrera control y gestiÓn de incidencias en stock autora: miriam serrano conde madrid, septiembre de