Upload
tranhanh
View
215
Download
0
Embed Size (px)
Citation preview
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
Control y gestión de incidencias en stock
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
Control y gestión de incidencias en stock
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
Control y gestión de incidencias en stock
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
Control y gestión de incidencias en stock
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
Control y gestión de incidencias en stock
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
Control y gestión de incidencias en stock
Í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
Control y gestión de incidencias en stock
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
Control y gestión de incidencias en stock
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
Control y gestión de incidencias en stock
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
Control y gestión de incidencias en stock
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
Control y gestión de incidencias en stock
Capítulo 1 Identificación de
necesidades
4
Control y gestión de incidencias en stock
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
Control y gestión de incidencias en stock
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
Control y gestión de incidencias en stock
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
Control y gestión de incidencias en stock
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
Control y gestión de incidencias en stock
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
Control y gestión de incidencias en stock
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
Control y gestión de incidencias en stock
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
Control y gestión de incidencias en stock
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
Control y gestión de incidencias en stock
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
Control y gestión de incidencias en stock
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
Control y gestión de incidencias en stock
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
Control y gestión de incidencias en stock
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
Control y gestión de incidencias en stock
Capítulo 2 Análisis de requisitos
17
Control y gestión de incidencias en stock
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
Control y gestión de incidencias en stock
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
Control y gestión de incidencias en stock
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
Control y gestión de incidencias en stock
• 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
Control y gestión de incidencias en stock
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
Control y gestión de incidencias en stock
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
Control y gestión de incidencias en stock
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
Control y gestión de incidencias en stock
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
Control y gestión de incidencias en stock
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
Fuente Página Identificación requisito
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
Control y gestión de incidencias en stock
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
Fuente Página Identificación requisito
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
Control y gestión de incidencias en stock
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
Fuente Página Identificación requisito
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
Control y gestión de incidencias en stock
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
Fuente Página Identificación requisito
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
Control y gestión de incidencias en stock
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
Fuente Página Identificación requisito
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
Control y gestión de incidencias en stock
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
Fuente Página Identificación requisito
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
Control y gestión de incidencias en stock
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
Fuente Página Identificación requisito
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
Control y gestión de incidencias en stock
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
Fuente Página Identificación requisito
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
Control y gestión de incidencias en stock
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
Fuente Página Identificación requisito
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
Control y gestión de incidencias en stock
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
Fuente Página Identificación requisito
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
Control y gestión de incidencias en stock
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
Fuente Página Identificación requisito
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
Control y gestión de incidencias en stock
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
Fuente Página Identificación requisito
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
Control y gestión de incidencias en stock
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
Fuente Página Identificación requisito
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
Control y gestión de incidencias en stock
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
Fuente Página Identificación requisito
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
Control y gestión de incidencias en stock
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
Fuente Página Identificación requisito
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
Control y gestión de incidencias en stock
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
Control y gestión de incidencias en stock
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
Control y gestión de incidencias en stock
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
Control y gestión de incidencias en stock
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
Control y gestión de incidencias en stock
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
Control y gestión de incidencias en stock
• Cruce de sistemas: Este proceso es muy complejo ya que se interactúa con
tres bases de datos ajenas a la herramienta.
46
Control y gestión de incidencias en stock
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
Control y gestión de incidencias en stock
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
Control y gestión de incidencias en stock
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
Control y gestión de incidencias en stock
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
Control y gestión de incidencias en stock
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
Control y gestión de incidencias en stock
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
Control y gestión de incidencias en stock
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
Control y gestión de incidencias en stock
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
Control y gestión de incidencias en stock
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
Control y gestión de incidencias en stock
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
Control y gestión de incidencias en stock
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
Control y gestión de incidencias en stock
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
Control y gestión de incidencias en stock
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
Control y gestión de incidencias en stock
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
Control y gestión de incidencias en stock
� 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
Control y gestión de incidencias en stock
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
Control y gestión de incidencias en stock
• 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
Control y gestión de incidencias en stock
• 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
Control y gestión de incidencias en stock
• 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
Control y gestión de incidencias en stock
Capítulo 3 Arquitectura
66
Control y gestión de incidencias en stock
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
Control y gestión de incidencias en stock
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
Control y gestión de incidencias en stock
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
Control y gestión de incidencias en stock
Capítulo 4 Diseño de entradas
y salidas
70
Control y gestión de incidencias en stock
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
Control y gestión de incidencias en stock
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
Control y gestión de incidencias en stock
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
Control y gestión de incidencias en stock
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
Control y gestión de incidencias en stock
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
Control y gestión de incidencias en stock
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
Control y gestión de incidencias en stock
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
Control y gestión de incidencias en stock
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
Control y gestión de incidencias en stock
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
Control y gestión de incidencias en stock
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
Control y gestión de incidencias en stock
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
Control y gestión de incidencias en stock
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
Control y gestión de incidencias en stock
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
Control y gestión de incidencias en stock
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
Control y gestión de incidencias en stock
Capítulo 5 Implementación
85
Control y gestión de incidencias en stock
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
Control y gestión de incidencias en stock
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
Control y gestión de incidencias en stock
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
Control y gestión de incidencias en stock
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
Control y gestión de incidencias en stock
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
Control y gestión de incidencias en stock
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
Control y gestión de incidencias en stock
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
Control y gestión de incidencias en stock
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
Control y gestión de incidencias en stock
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
Control y gestión de incidencias en stock
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
Control y gestión de incidencias en stock
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
Control y gestión de incidencias en stock
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
Control y gestión de incidencias en stock
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
Control y gestión de incidencias en stock
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
Control y gestión de incidencias en stock
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
Control y gestión de incidencias en stock
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"><!-- document.formulario.submit() //--></script>
101
Control y gestión de incidencias en stock
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
Control y gestión de incidencias en stock
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
Control y gestión de incidencias en stock
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"> <!-- function preparafiltros(valor) { if (valor!="") document.forms[0].submit(); }; //fin filtra --> </script>
104
Control y gestión de incidencias en stock
Capítulo 6 Plan de pruebas
105
Control y gestión de incidencias en stock
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
Control y gestión de incidencias en stock
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
Control y gestión de incidencias en stock
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
Control y gestión de incidencias en stock
• 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
Control y gestión de incidencias en stock
Capítulo 7 Planificación real
110
Control y gestión de incidencias en stock
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
Control y gestión de incidencias en stock
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
Control y gestión de incidencias en stock
113
Control y gestión de incidencias en stock
Capítulo 8 Valoración económica
114
Control y gestión de incidencias en stock
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
Control y gestión de incidencias en stock
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
Control y gestión de incidencias en stock
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
Coste licencia ( € )
Total ( € )
Ordenador Compaq
750
750
Servidor HP
3500
350
Total
1100
117
Control y gestión de incidencias en stock
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
Coste licencia ( € )
Personal
15080
Software
2505
Hardware
1100
Total sin IVA
18685
IVA (16%)
2990
Total con IVA
21675
118
Control y gestión de incidencias en stock
Capítulo 9 Conclusiones
119
Control y gestión de incidencias en stock
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
Control y gestión de incidencias en stock
Anexo A
121
Control y gestión de incidencias en stock
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
Control y gestión de incidencias en stock
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
Control y gestión de incidencias en stock
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
Control y gestión de incidencias en stock
• 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
Control y gestión de incidencias en stock
� 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
Control y gestión de incidencias en stock
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
Control y gestión de incidencias en stock
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
Control y gestión de incidencias en stock
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
Control y gestión de incidencias en stock
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
Control y gestión de incidencias en stock
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
Control y gestión de incidencias en stock
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
Control y gestión de incidencias en stock
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
Control y gestión de incidencias en stock
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
Control y gestión de incidencias en stock
• 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
Control y gestión de incidencias en stock
• 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
Control y gestión de incidencias en stock
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
Control y gestión de incidencias en stock
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
Control y gestión de incidencias en stock
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
Control y gestión de incidencias en stock
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
Control y gestión de incidencias en stock
141
Control y gestión de incidencias en stock
Anexo B
142
Control y gestión de incidencias en stock
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.