DESARROLLO DE UNA APLICACIÓN WEB PARA EL · PDF fileADMINISTRATIVO DE REQUISICION PARA...

DESARROLLO DE UNA APLICACIÓN WEB PARA EL SOPORTE DEL SUBSISTEMA ADMINISTRATIVO DE REQUISICION

PARA COMPRAS CON CAJA CHICA EN LA EMPRESA SMURFIT KAPPA, S.A.

Autor: Álvarez, Argenis C.I. 20.699.885

DESARROLLO DE UNA APLICACIÓN WEB PARA EL SOPORTE DEL SUBSISTEMA ADMINISTRATIVO DE REQUISICION

PARA COMPRAS CON CAJA CHICA EN LA EMPRESA SMURFIT KAPPA, S.A.

Empresa: Smurfit Kappa Cartón de Venezuela, S.A.


Urb. Yuma II, calle Nº 3. Municipio San Diego Teléfono: (0241) 8714240 (master) – Fax: (0241) 8712394

REPÚBLICA BOLIVARIANA DE VENEZUELA UNIVERSIDAD JOSÉ ANTONIO PÁEZ

FACULTAD DE INGENIERÍA ESCUELA DE INGENIERÍA EN COMPUTACIÓN

DESARROLLO DE UNA APLICACIÓN WEB PARA EL SOPORTE DE L SUBSISTEMA ADMINISTRATIVO DE REQUISICION PARA COMPR AS

CON CAJA CHICA EN LA EMPRESA SMURFIT KAPPA S.A.

______________________________________________

Nombre, firma y cedula de identidad del tutor académico

______________________________________________

Nombre, firma y cedula de identidad del tutor empresarial


San Diego, Agosto 2014

DEDICATORIA

Este trabajo de grado se lo dedico a mis padres quienes me han impulsado en

todo momento a lograr mis metas y a cumplir mis objetivos, motivándome y

apoyándome moral y psicológicamente,brindándome la oportunidad de ser un

profesional y estando presentes en todo momento encaminándome hacia el éxito.

Ustedes hicieron posible este gran logro, ahora es mi turno de regresar un poco de

todo lo que me han dado.

AGRADECIMIENTOS

A lo largo de estos años de mi carrera son muchas las personas que han

participado en este trabajoy a quienes quiero expresar mi gratitud por la confianza y

el apoyo que me han brindado de forma incondicional y desinteresada.

Primeramente quiero darle las gracias a Dios por permitirme cumplir ésta meta,

pordarme fuerza y salud a lo largo de mi vida y así lograr culminar exitosamente mis

estudios.

A mi alma mater la Universidad José Antonio Páez, por otorgarme un lugar

donde formarme personal y profesionalmenteviviendo nuevas experiencias, por el

excelente personal administrativo y académico que la conforman.

A mistutores, gracias por toda la ayuda, regaños, concejos, paciencia, tolerancia

y sus mejores intenciones de que éste trabajo de grado resaltara entre los mejores.

A mis compañeros y amigos con los cuales he compartido incontables horas de

trabajo y apoyo mutuo, a ellos agradezco por los buenos y malos momentos, por la

ayuda que me brindaron cuando más la necesitaba.

Un sincero agradecimiento en especial a Reni Pribac y a Ricardo Veronese por

el aporte de sus experiencias y conocimientos que me ayudaron a ampliar los

míosfacilitándome así la culminaciónde éste gran logro.

A toda mifamilia, por estar siempre presente, encaminándome, aconsejándome,

brindándome su apoyo, por aguantarme y escucharme.

No puedo olvidar a mi amiga de toda la vida Mariana Barreto a quien tanto

aprecio,gracias por estar siempre ahí apoyándome, motivándome, confiado en míy

ayudándome en mis debilidades metodológicas, gracias por el cariño y el respaldo.

También tengo que agradecer a mi hermana y a mi sobrina Jimena por

motivarme a seguir adelante con el objetivo de la construcción de un mejor país y un

mejor futuro para ella que viene en camino a éste mundo.

REPÚBLICA BOLIVARIANA DE VENEZUELA

UNIVERSIDAD JOSÉ ANTONIO PÁEZ FACULTAD DE INGENIERÍA

ESCUELA DE INGENIERÍA EN COMPUTACIÓN

ACEPTACIÓN DEL TUTOR

Quien suscribe, Norma J. Romero C. portador de la cédula de identidad N°

19.617.579, en mi carácter de tutor del trabajo de grado presentado por el ciudadano

Argenis Álvarez, portador de la cédula de identidad N° 20.699.885, titulado

desarrollo de una aplicación web para el soporte del subsistema administrativo de

requisición para compras con caja chica en la empresa Smurfit Kappa, S.A.

Presentado como requisito parcial para optar al título de Ingeniero de Computación,

considero que dicho trabajo reúne los requisitos y méritos suficientes para ser

sometido a la presentación pública y evaluación por parte del jurado examinador que

se designe.

En San Diego, a los 4 días del mes de Septiembre del año dos mil catorce.

___________________________

Ing. Norma J. Romero C. C.I.: 19.617.579

ÍNDICE

CONTENIDO Pp.

ÍNDICE DE FIGURAS ………………………………………………….. ix ÍNDICE DE FIGURAS ………………………………………………….. xi RESUMEN………………………………….……………………………. xiii INTRODUCCIÓN ……………………………………………………….. 1 CAPÍTULO I LA EMPRESA 1.1 Nombre……………………………………………………… 3 1.2 Ubicación………………..……………………….………….. 3 1.3 Identificación de la Empresa.………..………………………. 3 1.4 Fundación……………………………………………………. 4 1.5 Misión……..………………………………………………… 4 1.6 Visión…...…………………………………………………… 5 1.7 Política…….………………………………………………… 5 II EL PROBLEMA 2.1 Planteamiento del Problema….…………………………...… 6 2.1.1 Formulación del Problema………………………………. 9 2.2 Objetivos de la Investigación…….…………………………. 9 2.2.1 Objetivos Generales…...………………………………… 9 2.2.2 Objetivos Específicos…………………………………..... 9 2.3 Justificación de la Investigación………...…………………... 9 2.4 Alcance………………………..………...…………………... 10 2.5 Limitaciones.....………………..………...…………………... 11 III MARCO TEORICO 3.1 Antecedentes……….………………………………………... 12 3.2 Bases Teóricas…………..…………………………………... 13 3.2.1 Gestión Documental...………………………………….... 13 3.2.2 Sistema de Información….……………………………..... 15 3.2.3 Metodología para el Desarrollo de Software…...……….... 13

16 3.2.3.1 Extreme Programing (XP)…………………………...... 13

16 3.2.4 Active Server Pages (ASP)…...……………………........... 13

18 3.2.4.1 Versiones de ASP….………........……………….......... 13

19 3.2.5 Sistema de Gestión de Base de Datos (SGBD)…………... 19 3.2.6 UnifiedModelingLanguage (UML)……….……………. 3.2.6.1 Diagrama casos de uso………….…………...……......

21 22

3.3 Definición de Términos Básicos…...………………………... 24

CONCLUSIONES………………………………....…….………….. 87 RECOMENDACIONES………..………………....…….………….. 89 REFERENCIAS………………………………....…….…………….. 90 Bibliográficas………………….…………………………........… 90 Electrónicas…………..…………………………………….……. 90

IV MARCO METODOLOGICO 4.1 Tipo de Investigación……...…….………..…………………. 26 4.2 Diseño de la Investigación…………...……..……………….. 4.3 Nivel de la Investigación……………………………………. 4.4 Población y Muestra………...……………………………….

26 27 27

4.5 Técnicas de Recolección de Datos....…….…………………. 28 4.6Fases Metodológicas…..…………...…….…………………. 28 4.6.1 Fase I: Planificación...…………………………………..... 28 4.6.2 Fase II: Diseño………..….……………………………..... 29 4.6.3 Fase III: Desarrollo………………………..…...………..... 13

29 4.6.4 Fase IV: Pruebas………….…...……………………........... 13

30 V RESULTADOS 5.1 Fase I: Planificación ………..….……………………...……. 5.1.1 Usuarios del sistema…….……………………………….. 5.1.2 Historias de usuarios…….…………………………….…. 5.1.3 Planificación de entrega…….……………………………. 5.1.4 Iteraciones…….……………………………………….….

31 31 32 34 36

5.2 Fase II: Diseño …….……………………………………...… 5.2.1 Modelado de casos de uso…….………………………...... 5.2.2 Descripción de casos de uso…….……………………...... 5.2.3 Modelo de la base de datos …….………………………... 5.2.4 Diccionario de datos…….………………………….....…. 5.2.5 Diseño de Interfaces …….…………………………..…... 5.2.6 Arquitectura del sistema…….………………………..….. 5.2.7 Mapa del sitio……………….………………………..…..

40 40 43 62 63 70 71 72

5.3 Fase III: Desarrollo …………..………...……………….…... 5.3.1 Pantallas del sistema…….…………………………….…. 5.4 Fase IV: Pruebas …………..………...……………………....

72 73 83

ÍNDICE DE FIGURAS

CONTENIDO

FIGURA Pág.

1 Fases de la Metodología XP …………………………………..………...….17

2 Ejemplo del flujo de una página ASP .………………………...………...….19

3 Caso de uso: Consultas de usuario común.………………..…...…………....41

4 Caso de uso: Administrador …………...……………………..…...……...…41

5 Caso de uso: Agente……………………..………………..…...…………….42

6 Diagrama de modelo entidad relación…...………………..…...…………….62

7 Diagrama del modelo relacional………....………………..…...…………….63

8 Diccionario de datos. Tabla _Agentes.......………………..…...…………….64

9 Diccionario de datos. Tabla _Areas.......………………..…...……………….65

10 Diccionario de datos. Tabla _CentrosCostos.......……………...…………….65

11 Diccionario de datos. Tabla _ControlC.......…………………...…………….66

12 Diccionario de datos. Tabla _DetalleSolicitudes.......……..…...…………….66

13 Diccionario de datos. Tabla _Items.......………………..…...……………….67

14 Diccionario de datos. Tabla _Mensajeros.......……………....……………….67

15 Diccionario de datos. Tabla _Plantas.......……………..…………………….68

16 Diccionario de datos. Tabla _Recibos.......……………….....……………….69

17 Diccionario de datos. Tabla _Solicitudes.......……………………………….69

18 Diseño de interfaz.......……………………………………………………….70

19 Arquitectura del sistema……………….........……………………………….71

20 Mapa del sitio………………………….........……………………………….72

21 Pantalla Mis Solicitudes……………….........……………………………….73

22 Pantalla Solicitar……………………….........……………………………….74

23 Pantalla Tramitar……………….........……………………………………….75

24 Pantalla Ejecutar……………….........……………………………………….76

25 Pantalla Generar recibo…………………….........………..………………….77

26 Pantalla Cargar Compra…...…........……………………………………...….78

27 Pantalla Control de Compras…........……………………………………..….79

28 Pantalla Reporte de solicitudes…………………………………………..…..80

29 Pantalla Reporte grafico……….........…………………………………….….81

30 Pantalla Mantenimiento de tablas……….........……………………………...82

ÍNDICE DE TABLAS

CONTENIDO

CUADRO Pág.

1 ............................................................................................................... Histor

ia de Usuario: Solicitud de requisición ..................................................... 32

2 Historia de Usuario: Detalle solicitud ....................................................... 32

3 Historia de Usuario: Tramitar solicitud ..................................................... 33

4 Historia de Usuario: Ejecutar .................................................................... 33

5 Historia de Usuario: Incluir compra .......................................................... 33

6 Historia de Usuario: Generar recibo .......................................................... 34

7 Historia de Usuario: Administración de tablas maestras........................... 34

8 Historia de Usuario: Administración de privilegios .................................. 34

9 Estimación de esfuerzos ............................................................................ 35

10 Iteraciones ................................................................................................. 35

11 Plan de entregas ......................................................................................... 36

12 Tarea 1 ....................................................................................................... 37

13 Tarea 2 ....................................................................................................... 38

14 Tarea 3 ....................................................................................................... 38

15 Tarea 4 ....................................................................................................... 39

16 Tarea 5 ....................................................................................................... 39

17 Tarea 6 ....................................................................................................... 39

18 Tarea 7 ....................................................................................................... 40

19 Tarea 8 ....................................................................................................... 40

20 Descripción de caso de uso “tramitar” ...................................................... 43

21 Descripción de caso de uso “ejecutar” ...................................................... 45

22 Descripción de caso de uso “control de compras” .................................... 47

23 Descripción de caso de uso “incluir compra” ........................................... 48

24 Descripción de caso de uso “generar recibo” ............................................ 50

25 Descripción de caso de uso “consultar reporte” ........................................ 51

26 Descripción de caso de uso “consulta de reporte grafico” ........................ 52

27 Descripción de caso de uso “mantenimiento” ........................................... 53

28 Descripción de caso de uso “gestión de ítems” ......................................... 54

29 Descripción de caso de uso “gestionar departamentos” ............................ 56

30 Descripción de caso de uso “gestionar mensajeros” ................................. 57

31 Descripción de caso de uso “privilegios del usuario” ............................... 59

32 Descripción de caso de uso “nivel de usuario” ......................................... 60

33 Prueba N° 1 ............................................................................................... 83

34 Prueba N° 2 ............................................................................................... 83

35 Prueba N° 3 ............................................................................................... 84

36 Prueba N° 4 ............................................................................................... 85

37 Prueba N° 5 ............................................................................................... 85

38 Prueba N° 6 ............................................................................................... 86

39 Prueba N° 7 ............................................................................................... 86

40 Prueba N° 8 ............................................................................................... 86

xiii

REPÚBLICA BOLIVARIANA DE VENEZUELA UNIVERSIDAD JOSÉ ANTONIO PÁEZ

CARRERA INGENIERÍA FACULTAD DE INGENIERÍA EN COMPUTACIÓN

DESARROLLO DE UNA APLICACIÓN WEB PARA EL SOPORTE DE L

SUBSISTEMA ADMINISTRATIVO DE REQUISICION PARA COMPR AS CON CAJA CHICA EN LA EMPRESA SMURFIT KAPPA, S.A

Autor: Álvarez, Argenis Tutor : Norma J. Romero C. Fecha:Septiembre, 2014

RESUMEN

Smurfit Kappa Cartón de Venezuela, S.A. (SKCV) es una empresa cuyo propósito es la elaboración de empaques de cartón la cual actualmente forma parte del grupo mundial Smurfit Kappa Group. Las oficinas corporativas ubicadas en la planta LEO, son las que se encargan de los procesos administrativos de la compañía. Éstas, se encuentran divididas en diferentes departamentos, los cuales cuentan con un control de requisición de compras por caja chica, éste es llevado a mano mediante hojas de cálculo de Microsoft Excel, lo que genera retraso en la elaboración de las solicitudes, inexactitud de los datos, almacenamientos inadecuados de las requisiciones, entre otros problemas frecuentes. Con el propósito de solucionar éstos inconvenientes, se propuso desarrollar un sistema automatizado, el cual eliminará los errores presentes en el mismo y simplificará el proceso a los usuarios que lo emplean. Para esto, se estudió el funcionamiento actual de dicho subsistema para conocer las diferentes opiniones del funcionamiento según los usuarios involucrados, determinando así la problemática presentada en el proceso, para posteriormente definir los requerimientos de información necesarios para el desarrollo del software. Se empleó la metodología XtremePrograming (XP), bajo el Lenguaje de Modelado Unificado (UML), utilizando como editor de texto para el desarrollo Sublime Text 2.0 bajo la plataforma ASP, así como también HTML, JavaScript y como gestor de base de datos SQL Server 2008. El estudio corresponde al tipo de investigación aplicada, bajo el diseño de proyecto factible. Para la recolección de datos se aplicó la observación directa y la entrevista no estructurada.

Descriptores: Requisición, sistema, desarrollo, automatización.

INTRODUCCIÓN

Actualmente las herramientas y metodologías aplicadas para obtener datos

acordes y organizados que se manejan dentro de una institución se apoyan en la

tecnología. Gracias a los avances tecnológicos desarrollados para distintos sistemas

automatizados de información, es posible operar la abundante cantidad de datos que

posee una empresa. Es por ello que el fenómeno de fácil acceso a la información se

da al ser capaz de consultar, modificar y agregar datos que se relacionan de alguna

manera para el uso de análisis y decisiones estratégicas que conlleve a una alta

competitividad de mercado, mejorando de esta manera los procesos que optimizan la

calidad del servicio.

De igual forma, los sistemas automatizados representan una tendencia

tecnológica por medio de la integración y comunicación entre los departamentos de

una organización, cumpliendo con rapidez en el factor tiempo de manera eficiente.

Los datos de transacciones son resguardados permitiendo de esta manera su análisis

posterior.

Con el fin de gestionar de manera eficaz el proceso de solicitud de compras

por caja chica, el proyecto de investigación dio base para el desarrollo de un soporte

del subsistema de requisición de compras mediante caja chica en la red de la empresa

Smurfit Kappa Cartón de Venezuela, S.A. permitiendo de esta manera el ahorro de

tiempo y materiales por parte de los empleados, optimizando el proceso y

amplificando la eficacia dentro de esta organización.Se encuentra en el contenido

desarrollado de cada capítulo la siguiente información:

En el CAPÍTULO I , se describe la empresa que protagoniza el proyecto, su

identificación, ubicación de la empresa, una breve descripción de la misma, el

diagrama organizativo, los productos elaborados, y por ultimo su misión, visión y

valores.

2

En el CAPÍTULO II , se describe la problemática actual, el objetivo general,

objetivos específicos, justificación del desarrollo del proyecto (Sistema de

Información), limitaciones y alcances.

En el CAPÍTULO III , se señalan los antecedentes de la investigación, las

bases teóricas que sustentan la investigación, la definición de términos básicos que

facilita el entendimiento de la investigación en cuanto a las aclaratorias de la

terminología técnica utilizadas.

En el CAPÍTULO IV , se definen las fases metodológicas del proyecto de

investigación, el tipo de investigación, diseño, nivel y se justifica la población y la

muestra escogida, se habla sobre las técnicas de análisis de datos, la metodología a

utilizar y sus respectivas fases.

En el CAPÍTULO V , se muestran los resultados de cada fase de la

metodología aplicada en este proyecto, al igual que las conclusiones,

recomendaciones y referencias bibliográficas que sustentan la presente investigación.

CAPÍTULO I

LA EMPRESA

1.1 Nombre

Smurfit Kappa Cartón de Venezuela S.A.

1.2 Ubicación

Avenida Domingo Olavarría, Zona Industrial Sur, Valencia.

Estado Carabobo. Zona Postal 2003. Venezuela

1.3 Identificación de la Empresa

Smurfit Kappa Group (SKG por sus siglas) es la compañía líder a nivel mundial

en empaques de cartón y está completamente integrada con las actividades

productivas propias tales como la siembra y el manejo de los bosques cultivados, la

investigación y el mejoramiento genético, la recolección, procesamiento y reciclaje

de fibras secundarias, la fabricación y venta de papel, cartulinas, cartón y empaques,

el diseño estructural y gráfico de cajas y estuches, entre otras.

Este grupo es, entonces, un productor integrado, ya que la mayor parte de sus

necesidades de materia prima en las plantas de envasado son surtidas de sus propias

fábricas de papel y, a su vez, el aprovisionamiento de fibra recuperada y madera se

gestiona a través de una combinación de sus propias operaciones forestales y de

compras a terceros.

Esta compañía tiene 330 centros de operación distribuidos en 31 países a nivel

global, estando nueve de estos países en América Latina, siendo Venezuela uno de

estos en los que SKG posee operaciones y Smurfit Kappa Cartón de Venezuela, S.A.

(SKCV por sus siglas) es la empresa que opera para este grupo en el país.

SKG es una empresa orientada a satisfacer las necesidades del mercado interno

nacional ya que atiende las necesidades de la industria alimentaria: alimentos y

bebidas; aceites y grasas; productos agrícolas; galletas y caramelos; productos

cárnicos, bienes y servicios como productos de limpieza y belleza; sector automotriz

4

y farmacéutico. SKVC tiene como visión ser reconocida como la empresa más

exitosa en la industria de papel, cartón y empaques.

1.4Fundación

La lucha y esfuerzo de Smurfit Kappa Cartón de Venezuela, S.A. a principios

de los años 70se acrecentó aún más, al satisfacer las necesidades de los clientes que

buscaban calidadpor encima de todo. Es por ello que decide la aprobación de un

proyecto para la creaciónde un laboratorio corporativo para las corrugadoras del

grupo. Fue de este modo que el 22 de Noviembre de 1971, se cristaliza el anhelado

proyecto y se fundalo que hoy en día se conoce como el Laboratorio Central del

grupo Smurfit Kappa Cartón de Venezuela.

En un principio, el Laboratorio Central se abocó únicamente a prestar servicios

a las plantas corrugadoras pertenecientes a la mencionada división, posteriormente

extendió sus labores al efectuar monitoreos en la calidad de los papeles Liners y

Medios fabricados por los molinos de papel de la corporación, encargándose entonces

de la realización de ensayos a muestras de papel, cartón, cartón corrugado y

empaques.

1.5Misión

Smurfit Cartón de Venezuela, es una empresa que comercializa, desarrolla y

produce soluciones de papel, cartón y empaques.

Mantenemos nuestro liderazgo y crecimiento:

� Superando continuamente las expectativas y necesidades de nuestros clientes.

� Desarrollando fuentes de recursos materiales, productos, servicios y mercados.

� Fomentando asociaciones estratégicas con nuestros clientes y proveedores.

� Operando en armonía con la comunidad, el medio ambiente y apegados a

principios éticos.

� Promoviendo el trabajo en equipo, en un clima laboral seguro.

� Cumpliendo con las expectativas de nuestros accionistas.

5

1.6Visión

Smurfit Cartón de Venezuela será reconocida como la empresa más exitosa en

la industria de papel, cartón y empaques.

Para lograr esta visión:

� Generará un alto nivel de satisfacción en nuestros clientes.

� Creará valor agregado para nuestros accionistas.

� Ofrecerá oportunidades de crecimiento para nuestros trabajadores en un ambiente

de trabajo seguro.

� Operará en armonía con el medio ambiente y la comunidad.

1.7Política

La política de la calidad del Laboratorio Centralcentro de investigaciones y

ensayos de Smurfit Kappa Cartón de Venezuela, es satisfacer las necesidades de

servicios de ensayos de sus clientes; en el sector de papel o cartón, cartón corrugado y

empaques de cartón corrugado, aplicando normas y/o métodos de ensayos

estandarizados y validados, nacionales e internacionales, garantizando: la

transparencia, confiabilidad y confidencialidad, de los trabajos y actividades que se

realizan, acorde con sus principios sobre gestión y aseguramiento de la calidad,

reconocidos mediante la Acreditación de sus métodos de ensayos, según la norma

ISO/IEC 17025, otorgada por SENCAMER (Servicio Autónomo Nacional de

Calidad, Metrología y Reglamentos Técnicos).

CAPÍTULO II

EL PROBLEMA

2.1 Planteamiento del Problema

En un mundo cada vez más competitivo, la automatización de los diferentes

procesos de empresas y organizacionesse ha visto en la necesidad de evolucionar

junto con los avances tecnológicos, buscando que sea confiable y oportuna la

información que manejan, para facilitar una toma de decisiones precisa.Las

aplicaciones web representan una importante herramienta en el control y

administración de la información para los sectores empresariales,como instrumento

que impulsa la efectividad y el desempeño a niveles superiores de excelencia, para

que de esta manera puedan mantenerse como entidad a lo largo del tiempo.

En la actualidad, las pequeñas y grandes empresas se ven beneficiadas con el

uso de aplicaciones web, esto debido a las múltiples ventajas que otorga como lo esla

conectividad entre los diferentes usuarios dentro de las instalaciones, facilitando el

contacto entre ellos mismos al igual quecon los clientesbrindándoles a éstos

respuestas rápidas y de esta manera incrementar la calidad del servicio que se le

brinda al cliente al igual que la de los usuarios propios de la empresa.

La necesidad de automatizar los procesos operativos y la utilización de las

herramientas para el flujo de información que se maneja en la industria, ha llevado

hoy en día a países de todo el mundo, incluyendo a Venezuela, a aplicar estas nuevas

tecnologías con el fin de comprender y analizar los datos generados por las

actividades llevadas a cabo dentro de las compañías.

El departamento de Servicio de Información (DSI), es la división encargada de

la automatización de los procesos operativos de Smurfit Kappa Cartón de Venezuela,

S.A. para los diversos departamentos y plantas de producción a nivel

7

nacional por medio de la utilización de herramientas adecuadas para la elaboración,

control, mantenimiento y soporte de sistemas de información.

Hoy en día, en el departamento de contabilidad en las oficinas corporativas de

la empresa, las requisiciones de compras por caja chica son realizadas manualmente

mediante un formato en hoja de cálculo digital, de acuerdo a los siguientes pasos:

� Identificar y llenar el formato “Requisición de Compras Caja Chica” con los

datos solicitados.

� Verificar los datos del Formato “Requisición Compras Caja Chica” señaladas en

el mismo.

� Firmar en señal de Aprobación de la solicitud.

� Obtener copia del formato “Requisición Compras Caja Chica” (Aprobado) y

entregar el original al encargado de la caja chica.

� Recibir el formato “Requisición Compras Caja Chica” y colocar el sello de

recepción al original y a la copia.

� Devolver copia al solicitante como evidencia de que la compra del material,

suministro o servicio se cancelará en efectivo.

� Recibir copia de la compra y archivarla.

� Preparar el formato “Adelanto Caja Chica Bolívares” con los datos del

mensajero, indicando el monto y especificando el desembolso del efectivo, para

que se realice la compra a través de la caja chica.

� Buscar las firmas de aprobación con los formatos originales de “Requisición

Compras Caja Chica”.

� Entregar el efectivo al mensajero y copias de las “Requisición Compras Caja

Chica”, materiales, suministros y servicios a ser gestionados en efectivo.

� Realizar las compras de los materiales, suministros y servicios solicitados por el

personal

� Entregar facturas originales de los materiales, suministros y servicios realizados

al encargado de la caja chica.

8

� Recibir facturas y anexar los formatos originales de la requisición de compras

por caja chica, sumar el total de las facturas y cuadrar con el efectivo entregado

al mensajero.

� Relacionar las facturas recibidas en una hoja de cálculo digital para llevar así un

control del efectivo gastado por caja chica con la finalidad de hacer el reembolso

a tiempo.

� Archivar la requisición de compras por caja chica y las facturas soportes.

� Entregar al solicitante el material, servicio y/o suministro requerido.

Procesoque consume gran cantidad de tiempo y trabajo, disminuyendo así, la

eficiencia del desarrollo administrativo dentro de la compañía. Como resultado de

este proceso, existen una serie de implicaciones, como lo son: los constantes errores

que se presentan al momento de manejar el formato correspondiente, sumándole a

esto que no existe ningún tipo de validación que le de sustento al sistema, así como

también, en ocasiones, justificación de gastos, falta de coincidencia en los montos de

las requisiciones con el soporte de la compra.

Asimismo, se presentan pérdidas o extravíos de información, representando un

gran riesgo para la compañía dado que no se realiza ningún tipo de registro que quede

almacenado en una base de datos. Es por ello, que se acumula una gran cantidad de

trabajo para el personal, así como también un descenso en la calidad de

administración de la empresa.

Por su parte, los documentos que son generados a raíz de la solicitud de

requisiciones por caja chica, ya sean facturas de compras, formato de requisición o

control de gastos, son almacenados manualmente bajo ningún control, lo que conlleva

de igual manera al extravío del soporte de las solicitudes, ocasionando pérdida de

tiempo y un gasto inconveniente de material de impresión.

Siguiendo este orden de ideas, luego de ser completada la solicitud, esta debe

pasar por diferentes departamentos para su posterior aprobación lo que retrasa el

trabajo y la espera del solicitante, acarreando deficiencia dentro del proceso

administrativo implicando de esta manera una contrariedad para la empresa.

9

Dada la ausencia de un sistema automatizado que sostenga el proceso

administrativo descrito, es lamentable que se vean afectados los procedimientos

donde no solo pierde el tiempo que se invierte, sino también se extravía valiosa

información administrativa.

2.1.1Formulación del Problema

Con todo lo anteriormente planteado se llega a formular la siguiente pregunta:

¿De qué manera se podría optimizar el proceso de requisición de compras por caja

chica de la empresa Smurfit Kappa Cartón de Venezuela, S.A?

2.2 Objetivos de la Investigación

2.2.1 Objetivos Generales

Desarrollar una aplicación web para el soporte del subsistema administrativo de

requisiciones de adelantos de caja chica en la empresa Smurfit Kappa Cartón de

Venezuela,S.A.

2.2.2 Objetivos Específicos

� Diagnosticar el proceso de requisición de compras por caja chica mediante

técnicas de recolección de datos, que permitan el conocimiento actual del sistema.

� Identificar los requerimientos necesarios del sistema de acuerdo a los datos ya

obtenidos.

� Diseñar los módulos propios del sistema de requisición de compras por caja

chica en base a los requerimientos identificados.

� Codificar el nuevo sistema a partir de los requerimientos y módulos necesarios a

emplear aplicando la metodología XP.

� Aplicar los distintos casos de pruebas para la detección de errores en el sistema.

2.3 Justificación de la Investigación

Debido a los grandes cambios sufridos por el mercado en los últimos años con

la incorporación de tecnologías informáticas que facilitarán la administración de la

información relevante, con el fin de brindar mejoras en la toma de decisiones

gerenciales, en la actualidad, todas las empresas requieren de la implementación de

10

aplicaciones web o sistemas de información que colaboren con los procesos de

gestiones empresariales.

La implementación de sistemas de información en una compañía, brindan la

posibilidad de obtener grandes ventajas como: incrementar el rendimiento de las

inversiones, mejorar su posición estratégica, acrecentar el valor del mercado de las

acciones, incrementar la capacidad de organización de la empresa, y tornar de esta

manera los procesos a una verdadera competitividad.Es por ello que se ha

desarrollado una aplicación web para el soporte del subsistema administrativo de

requisiciones de adelantos de caja chica en la empresa Smurfit Kappa Cartones de

Venezuela S.A.

El objetivo principal de la aplicación web es permitir el acceso inmediato a la

información de las requisiciones ya sea de personas, datos, software o hardware;

evitar pérdida de tiempo al llevar a cabo transacciones y desarrollar un adecuado

control de las solicitudes de requisición de pagos por caja chica. Por otra parte,

facilita el almacenamiento y consulta de datos, y establece un ambiente de trabajo

más relajado a los usuarios del sistema.

El desarrollo de un sistema de información web acorde a las necesidades de la

compañía también es una herramienta clave para la erradicación de los

inconvenientes que se presentan en el área de administración, situaciones adversas

como lo son el consumo innecesario de tiempo y materiales, lo que trae como

consecuencia gastos para la empresa. De igual modo, con una aplicación web se

garantiza la automatización que avala la integridad de la información que se maneja

dentro del departamento de administración para las solicitudes disminuyendo el

tiempo y material invertido, además de garantizar el respaldo y almacenamiento

apropiado mediante el uso de bases de datos.

2.4 Alcance

El alcance de la presente investigación constituye una mejora respecto al

control del subsistema de requisición de compras con caja chica. De manera tal, que

la funcionabilidad del sistema una vez terminada contara con:

11

� Registro de requisiciones de las diferentes solicitudes de compras por caja chica.

� Aprobación en diferentes niveles de jerarquía de las requisiciones.

� Registro de nuevos ítems a solicitar por requisición en la base de datos.

� Detalles de las solicitudes cargadas, tales como, ítems solicitados, departamento

que solicita, persona que cargo la solicitud, fecha de carga y estado.

� Creación de reportes gráficos exportables del sistema por concepto de cantidad

de solicitudes mensuales.

2.5 Limitaciones

La aplicación del sistema web en las requisiciones de compras por caja chica

debe cumplir con las reglas, políticas, especificaciones y requerimientos propios de la

empresa, lo que sugiere una limitación al momento de la creación del sistema web.

Dicho sistema será desarrollado usando la plataforma ASP y el editor de texto

sublime text 3, empleando como sistema gestor de base de datos Microsoft SQL

Server 2008. De esta manera, esta aplicación web debe ser perfectamente funcional a

la compañía adaptándose a las limitaciones de diseño preestablecidas por el

estereotipo de los sistemas desarrollados en ésta, y bajo las últimas versiones del

navegador Internet Explorer, debido a que las plantas de producción y los

departamentos de Smurfit Kappa S.A, utilizan en sus diferentes versiones este

explorador de internet preestablecido en todos los equipos de trabajo.

Así mismo, la disponibilidad de los empleados de Smurfit Kappa Cartón de

Venezuela S.A, que se encargan de suministrar la información para la adecuada

documentación de los requerimientos necesarios para desarrollo del sistema, es

limitada, siendo este un factor importante a tomar en cuenta en la elaboración del

software.

CAPÍTULO III

MARCO TEÓRICO

3.1 Antecedentes de la investigación

Para la elaboración del sistema, se tomaron en cuenta varias fuentes específicas

de información como referencia, las cuales sirvieron de apoyo para el desarrollo de la

aplicación web. A continuación se describen algunas de estas fuentes:

Da Silva, Sergio(2013) elaboro un trabajo de grado titulado “Desarrollo de un

sistema de información para la gestión de los archivos inactivos en la empresa

Distribuidora Universal Kia, C.A” .El cual fue presentado en la Universidad José

Antonio Páez para optar por el título de Ingeniero en Computación. En éste proyecto

dicho autor escribió sobre cómo se deben gestionar documentos de manera

organizada, simple y rápida implementando un sistema de información web para este

propósito, facilitando el trabajo de la empresa en este proceso, reduciendo tiempo y

costos.

Este sistema de información ayudó en el actual proyecto a la comprensión de la

gestión de documentos de manera digital siendo este un punto de similitud en ambos

proyectos en el control de documentos digitales. Adicionalmente, en dicho trabajose

aplicó la metodología XP (Extreme Programing) para el desarrollo adecuado del

sistema, de manera que esto sirvió también de aporte en el actual trabajo de

investigaciónal tipo de metodología a usar y a la aplicación de ésta.

Duran, Javier (2013), presento un trabajo de grado titulado: “Desarrollo e

Implantación de los módulos de control y de planificación del sistema de

producción en la planta Unión Gráfica de Smurfit Kappa Cartón de Venezuela,

13

S.A.”Paraoptar por el título de ingeniero en informática en la Universidad Nacional

Experimental del Táchira. El propósito de la elaboración de éste sistemafue para

llevar el manejo, control y planificación en la planta Unigra de Smurfit Kappa Cartón

de Venezuela, S.A. mediante un sistema de información, automatizando el antiguo

proceso y facilitando así la gestión de la información, aumentando la precisión de los

reportes de producción y generando una planificación organizada para de esta manera

optimizar dicho proceso.

Este trabajo de grado, contribuye a la investigación actual a comprender la

implementación de la plataforma ASP para la elaboración del sistema de requisición

de compras por caja chica el cual será desarrollado bajo ésta misma plataforma y al

uso de la herramienta Internet Information Server (IIS) como servidor Web.

Por otra parte, Ramos R., Gragory J., (2011), realizo un estudio en su trabajo de

grado para optar por el título de Ingeniero en Informática titulado “Reingeniería del

sistema de gestión y control de rutinas de mantenimiento preventivo de la

gerencia de servicios generales de Orginoco Iron”, presentado a la Universidad

Nacional Experimental de Guayana,la finalidad de éste fue desarrollar la reingeniería

del sistema de gestión y control de rutinas de mantenimiento preventivo la cual

permitiese una mejor organización, en donde se mostraran las diferentes rutinas y de

esta manera llevar un control de las actividades ejecutadas y programadas para el

mantenimiento preventivo y eficiente. Éste sistema se desarrolló en el lenguaje de

programación ASP.

Dicho trabajo sirviócomo base de estudio respecto al lenguaje a utilizar en el

desarrollo de la aplicación web, aportando conocimientos básicos del lenguaje ASP,

así como también las herramientas necesarias para la implementación del mismo.

3.2 Bases Teóricas

3.2.1 Gestión Documental

Fernández Gil Paloma (1999), comenta que “la gestión documental pretende

abarcar desde la elaboración de los documentos hasta su servicio, pasando por su

organización y descripción”.

14

La gestión documental también se puede definir como el conjunto de normas

técnicas y practicas las cuales se usan para llevar una óptima administración en el

flujo de distintos tipos de documentos en cualquier organización, permitiendo el

almacenamiento, el procesado, la captura, la distribución y la recuperación de

documentos.

Dentro de la gestión documental se pueden evidenciar diferentes tipos de

sistemas de información asociados a éste modelo relacional en los cuales se pueden

distinguir dos modelos esenciales:

� Los datacéntricos, basados en la explotación de datos a través de sus relaciones.

En estos sistemas la información, como organización estructurada de los datos,

dependen netamente del propio sistema, y su reconstrucción es imposible fuera

de este. La migración de estos datos a otro sistema pasa a menudo, por su

conversión a documentos.

� Los docucéntricos persiguen la independencia del documento respecto al sistema

productor, permitiendo una mayor dedicación a la definición de su contexto,

identidad, etc.

� Un sistema docucéntrico, tiene parte de datacéntrico, pero con una orientación a

la preservación e independencia del documento.

En la actualidad, coexisten los más diversos sistemas de gestión documental:

desde el simple registro a mano de la correspondencia que entra y sale diariamente,

hasta los más robustos sistemas de información que manejan la documentación

administrativa propias el mismo, así como también en papel o en formato electrónico,

además controlan los flujos de trabajo del proceso de tramitación de los expedientes,

capturan información desde bases de datos de producción, contabilidad y otras

fuentes de información, enlazan con el contenido de archivos, bibliotecas, centros de

documentación y permiten realizar búsquedas sofisticadas y recuperar información de

cualquier lugar.

La gestión documental sirvió como ayuda a la comprensión del proceso con el

cual se llevaban a cabo la gestión de requisiciones de compras por caja chica, debido

15

a que dicho proceso se basaba en la elaboración, descripción y organización de

documentos basándose en un conjunto de normas técnicas para la administración del

flujo de documentos.

3.2.2Sistema de Información

James Senn en su libro “Análisis y Diseño de Sistemas de Información”,

define un sistema de información como “un medio organizado de proporcionar

información pasada, presente y hasta futura (proyecciones) relacionadas con las

operaciones internas y el conocimiento externo de la organización”.

Se conoce también comosistema de información a un conjunto de elementos

que interactúan entre sí que se encargan de procesar datos e información, en función

de cumplir objetivos específicos.

De los anteriores planteamientos se concluye que un sistema de información es

una asociación de elementos: personas, actividades, datos, redes y tecnología

interrelacionados entre sí, que mediante un proceso de recolección y procesamiento

de datos, distribuye información útil que sirve de sustento en la resolución de

problemas y la toma de decisiones de una organización.

En tal sentido, Pechuan (2002) identifica algunas de las características que

resultan necesarias para cualquier Sistema de Información:

� Registro de requisiciones de las diferentes solicitudes de compras por caja chica.

� Aprobación en diferentes niveles de jerarquía de las requisiciones.

� Disponibilidad de información cuando sea necesario y por los medios adecuados.

� Suministro de información de manera selectiva.

� Variedad en la forma de presentación de la información.

� Cierto grado de autonomía para la toma de decisiones.

� Tiempo de respuesta adecuado a las necesidades del usuario.

� Exactitud en la información suministrada.

� Generalidad, como las funciones para atender a las diferentes necesidades.

� Flexibilidad, capacidad de adaptación.

� Fiabilidad, para que el sistema opere correctamente.

16

� Seguridad, protección contra pérdidas.

� Amigabilidad, para el usuario.

De acuerdo a las tecnologías en las que se basan, los sistemas de información

pueden ser entre otros:

� Sistemas cliente/servidor.

� Sistemas basados en tecnologías web.

� Sistemas basados en agentes.

� Sistemas basados orientados a servicios.

3.2.3 Metodología para el Desarrollo de Software

La metodología para el desarrollo de software se conoce como una serie de

herramientas, técnicas, procedimientos y soporte documental para el control del

proceso de diseño y desarrollo de los sistemas de información.

Sommerville (2002), define que “un método de ingeniería de software es un

enfoque estructurado para el desarrollo de software cuyo propósito es facilitar la

producción de software de alta calidad de una forma costeable” .

En esencia, una metodología de desarrollo de software se basa en la

combinación de diferentes tipos de modelos de procesos genéricos para obtener como

resultado un software que solucione algún problema en específico. Por otra parte, una

metodología debe ser capaz de definir con precisión los artefactos, roles y

actividades, junto con prácticas, técnicas recomendadas y guías para la adaptación de

la metodología al proyecto. Por otra parte, la complejidad del proceso del desarrollo

del software ha de ser netamente dependiente de la naturaleza del proyecto en sí, por

lo cual la selección de la metodología a implementar deberá de estar acorde al nivel

de aporte del proyecto. `

3.2.3.1 Extreme Programming (XP)

La programación extrema o Extreme Programming es una metodología ligera

de desarrollo de softwareque se basa en la simplicidad, la comunicación y la

realimentación o reutilización de código. La metodología XP es ideal para proyectos

de corto plazo y de menos de 10 programadores.

17

Según Pinciroli (2011), la programación extrema se trata de una metodología de desarrollo liviana, cuenta con pocas herramientas de modelado y se cuida bastante de incorporar otras adicionales”. Es una metodología que da mayor importancia a la capacidad de respuesta a un cambio que al seguimiento estricto de un plan específico, también es importante la comunicación constante de todo el equipo con el cliente para así lograr un desarrollo sencillo del sistema.

Así mismo, la flexibilidad que la metodología XP propone que se lleve

constantemente con el cliente permite estar preparados para cambios que en ciertas

ocasiones representa un costo importante para el proyecto. A continuación en la

figura 2, se muestran las distintas fases características de ésta metodología:

Figura 1: Fases de la Metodología XP

Fuente: Álvarez, Argenis (2014)

La esencia de la metodología XP se adapta en varios aspectos al desarrollo del

actual proyecto, por factores tales como el corto tiempo requerido por el cliente, las

constantes reuniones con el mismo al igual que la cantidad de personas que formaron

parte del equipo de trabajo que participó en éste.

18

3.2.4 Active Server Pages (ASP)

Es una tecnología creada por Microsoft para la elaboración de sitios web. Se

trata de un marco sobre el cual se construye contenido dinámico de aplicacionesy

páginas web del tipo “lado del servidor”. Desarrollada con el fin de suplantar a la

tecnología CGI.

La tecnología ASP va de la mano con el servidor Internet Information Server de

Microsoft, ésta apareció por primera vez en su versión 1.0 en Diciembre de 1996, la

cual se ejecutaba sobre IIS 3.0. Después surgió la versión 2.0 que corría sobre IIS 4.0

y la versión más actual es la 3.0, la cual corre sobre IIS 6.0. Por ultimo Microsoft

lanzó una nueva versión llamada ASP .NET que es parte de una filosofía de

desarrollo nueva de esta empresa.Las paginas ASP por lo general suelen estar

programadas en el lenguaje VBScript, sin embargo también se puede programar en

otros tipos de lenguajes, como JScript yPerlScript.

Con páginas simples de HTML, el cliente solicita una página al servidor, éste a

su vez envía y muestra la página tal cual en el explorador. Por otra parte, las paginas

en ASP, ejecutan los scripts por el servidor antes de ser enviados al cliente. El

servidor los procesa mediante la dll llamada asp.dll, que es la que interpreta los

mandatos ASP, y le regresa al cliente una página HTML sin código de servidor

Una página ASP funciona de la siguiente manera:

� Un usuario por medio del explorador solicita una página ASP.

� La solicitud llega al servidor en donde se encuentra alojada la página que se pidió.

� El servidor procesa la página y devuelve el código HTML.

� El usuario visualiza la página en su navegador.

19

Figura 2Ejemplo del flujo de una página ASP.


En la figura 2 se ejemplifica el flujo del esquema descrito anteriormente, se

puede observar que para el usuario no existe diferencia entre ASP y HTML debido a

que su explorador siempre recibe código HTML puro, el que requiere realizar un

trabajo extra es el servidor, ya que éste tiene que procesar el código ASP y

transformarlo en HTML para luego enviarlo de vuelta al cliente.

Para éste proyecto se requirió usar como lenguaje de programación ASP debido

a que los servidores de la empresa Smurfit Kappa Cartón de Venezuela, S.A. operan

sobre el sistema operativo Microsoft Windows e Internet Information Services (IIS)

como servidor web, utilizando como preferencia para el desarrollo de sus sistemas la

plataforma ASP.

3.2.4.1 Versiones de ASP

� ASP 1.0 (distribuido con IIS 3.0)



� ASP.NET (parte de la plataforma .NET de Microsoft).

3.2.5 Sistema de Gestión de Base de Datos (SGBD)

Un sistema de gestión de base de datos es una serie de programas que permiten

la creación y el mantenimiento de una base de datos, asegurando la integridad,

confidencialidad y seguridad de los datos. El objetivo principal de un sistema de

gestión de base de datos es servir de interfaz entre el usuario y la base de datos

20

suministrándole a éste las herramientas necesarias que permitan la manipulación, en

términos abstractos, de los datos, es decir, de manera que no le sea necesario conocer

de qué manera se encuentran almacenados los datos en el computador, ni el método

de acceso empleado.

Los SGBD poseen lenguajes especiales para manipular la información

almacenada en las bases de datos que facilitan el trabajo de los usuarios. Estos

brindan facilidad a la hora de la elaboración de las tablas y la creación de relaciones

entre la información contenidas en ellas.

Las principales características de los SGBD son:

� Abstracción de la información: El Administrador del SGBD ahorra a los usuarios

detalles acerca del almacenamiento físico de los datos. No suele ser de gran

importancia para el usuario si una base de datos ocupa uno o cientos de archivos. Así,

se definen varios niveles de abstracción.

� Independencia: La independencia de los datos se refiere a la capacidad de

modificar el esquema (físico o lógico) de una base de datos sin la necesidad de

realizar cambios en las aplicaciones que se sirven de ella.

� Redundancia mínima: Lo óptimo es que la redundancia sea nula; no obstante, en

algunos casos la complejidad de los cálculos hace inevitable la aparición de

redundancias.

� Consistencia: En aquellos casos en los que no se ha logrado una redundancia nula,

es necesario que todos los datos repetidos se actualicen de forma simultánea.

� Integridad. Se trata de garantizar la validez de los datos almacenados. Es decir,

proteger los datos ante inconvenientes de hardware, datos introducidos por usuarios

descuidados, o cualquier otra situación capaz de corromper la información

almacenada.

� Seguridad: Garantizar que la información permanezca segura frente a usuarios

malintencionados, que intenten tener acceso a información privilegiada; frente a

ataques que deseen manipular o destruir la información; o simplemente ante las

torpezas de algún usuario autorizado pero despistado. Normalmente, los SGBD

21

cuentan con un complejo sistema de permisos a usuarios y grupos de usuarios, que

permiten otorgar diversos tipos de privilegios.

� Respaldo y recuperación: Proporcionar formas eficientes de realizar copias de

seguridad, y restaurar estas copias.

� Control de la concurrencia: En la mayoría de entornos (excepto quizás el

doméstico), lo más común es que sean muchos los usuarios que acceden a una base

de datos, para recuperar información, almacenarla o modificarla. Y también es

frecuente que los accesos se realicen de forma simultánea. el SGBD debe controlar

este acceso concurrente a la información, que podría derivar en inconsistencias.

� Tiempo de respuesta: Es considerablemente importante el tiempo que tarda en

darnos la información y en almacenar los cambios realizados.

En la elaboración del actual software se utilizó como sistema gestor de base de

datos Microsoft SQL Server, un software producido por Microsoft basado en el

modelo relacional, debido a que en la empresa Smurfit Kappa Cartón de Venezuela,

S.A., se emplea dicho gestor para la creación y el mantenimiento de las bases de

datos de los proyectos que se desarrollan en ésta.

3.2.6Unified Modeling Language (UML)

Se trata de un lenguaje gráfico para construir, documentar, visualizar y

especificar un sistema de software. En otras palabras, UML se utiliza como una

técnica para definir un sistema de software especificando todas sus fases.

Schmuller (2003), lo define como un lenguaje que permite modelar, construir y documentar los elementos que forman un sistema orientado a objetos, UML no define un proceso de desarrollo especifico; es una notación que puede ser aplicada a diferentes tipos de sistemas informáticos o de otras ramas. Este lenguaje posibilita la captura, comunicación y nivelación de conocimiento estratégico, táctico y operacional para facilitar el incremento de valor, aumentando la calidad, reduciendo costos y reduciendo el tiempo de presentación al mercado; manejando riesgos y siendo proactivo para el posible aumento de complejidad o cambio.

22

Este concepto nace en 1994 cubriendo los aspectos principales de todos los

métodos de diseño antecesores y, precisamente, los padres de UML son Grady

Booch, autor del método Booch; James Rumbaugh, autor del método OMT e Ivar

Jacobson, autor de los métodos OOSE y Objectory. La versión 1.0 de UML fue

liberada en Enero de 1997 y ha sido utilizado con éxito en sistemas construidos para

toda clase de industrias alrededor del mundo: hospitales, bancos, comunicaciones,

aeronáutica, finanzas, etc.

UML puede usarse para modelar desde sistemas de información hasta

aplicaciones distribuidas basadas en Web, pasando por sistemas empotrados de

tiempo real. UML es solamente un lenguaje por lo que es sólo una parte de un

método de desarrollo software, es independiente del proceso aunque para que sea

óptimo debe usarse en un proceso dirigido por casos de uso, centrado en la

arquitectura, iterativo e incremental.

Los principales beneficios de UML son:

� Mejores tiempos totales de desarrollo (de 50 % o más).

� Modelar sistemas (y no sólo de software) utilizando conceptos orientados a

objetos.

� Establecer conceptos y artefactos ejecutables.

� Encaminar el desarrollo del escalamiento en sistemas complejos de misión crítica.

� Crear un lenguaje de modelado utilizado tanto por humanos como por máquinas.

� Mejor soporte a la planeación y al control de proyectos.

� Alta reutilización y minimización de costos.

3.2.6.1Diagramacasos de uso

En UML, los casos de uso son una técnica para especificar el comportamiento

de un sistema, éstos no son parte del diseño, sino parte del análisis. De manera tal que

al ser parte del análisis describen qué es lo que el sistema debe hacer desde el punto

de vista del usuario. Es decir, describen un uso del sistema y cómo este interactúa con

los actores del sistema.

23

Todo sistema de información ofrece a su entorno una serie de servicios. Un

caso de uso es una forma de aducir cómo alguien o algo externo a un sistema lo usa.

Tomando en cuenta que “alguien o algo” hace referencia a que los sistemas son

usados no sólo por personas, sino también por otros sistemas de hardware y software.

En otras palabras un caso de uso no es más que una descripción de una

secuencia de pasos que un actor del sistema deberá realizar para llevar a cabo algún

proceso. Éstos son independientes del método de diseño que se implemente, y por

consiguiente del método de programación. Una vez documentados los requerimientos

de un sistema con casos de uso, se puede diseñar un sistema “estructurado”

(manteniendo una separación entre datos y funciones), o un sistema Orientado a

Objetos, sin que la técnica sea de mayor o menor utilidad en alguno de los dos casos.

Dando así una mayor flexibilidad al método, y probablemente contribuyendo a su

éxito.

Los diagramas de caso de uso forman parte de uno de los cinco tipos de

diagramas en UML para modelar aspectos dinámicos de sistemas. Los diagramas de

casos de uso son de gran importanciaa la hora de modelar el comportamiento de un

sistema, un subsistema o una clase. Cada uno muestra un conjunto de casos de uso,

actores y sus relaciones en el sistema.En este tipo de diagrama intervienen algunos

conceptos nuevos: un actor es una entidad externa al sistema que se modela y que

puede interactuar con él; un ejemplo de actor podría ser un usuario o cualquier otro

sistema.

En un diagrama de casos de uso, no se muestran los casos de uso

detalladamente; solo se resumen algunas de las relaciones entre los casos de uso, los

actores y los sistemas. En otras palabras, en el diagrama no se muestra el orden en el

que se llevan a cabo los pasos para lograr los objetivos de cada caso de uso y su

principal ventaja consta en la facilidad para ser interpretados, lo que hace que sean

especialmente útiles en la comunicación con el cliente.

Para el desarrollo del actual sistema se emplearon diagramas de casos de uso y

modelos casos como herramienta del lenguaje UML, la cual ayudó a un mejor

24

entendimiento del funcionamiento del sistema al cliente cumpliendo la función de

mostrar las diferentes elecciones que tienen los diferentes actores dentro del sistema

en cuestión.

3.3 Definición de Términos Básicos

� Aplicación Web: Son todas aquellas aplicaciones informáticas donde los usuarios

pueden acceder a estas por medio de una red como internet o intranet, estas

aplicaciones son codificadas por lenguajes que interpretan los navegadores web los

cuales reproducen la aplicación al usuario.

� Archivo: Se conoce como archivo a un conjunto ordenado de documentos

elaborado por una sociedad, una institución o una persona en el marco de sus

actividades y funciones.

� Automatización: La automatización es un sistema donde tareas de producción que

son habitualmente realizadas por operadores humanos, se transfieren a un conjunto de

elementos tecnológicos mecánicos o electrónicos.

� Base de Datos: Es un conjunto de datos informativos almacenados

organizadamente por registros (formado por todos los campos referidos a una entidad

u objeto almacenado) y campos (cada uno de los elementos que componen un

registro) para su posterior uso.

� Caja Chica: Fondo disponible de dinero en efectivo asignado para agilizar las

compras y/o pagos menores en una determinada organización, el cual puede estar

justificado con efectivo, vales o facturas con su requisición de compras previa.

� Factura: Documento fiscal que soporta la compra de algún artículo o el uso de un

servicio. La misma debe ir firmada por el Gerente del área y debe ir acompañada por

la requisición de compras.

� HTML: El lenguaje de marcas de hipertexto por sus siglas en inglés, es una

tecnología que organiza una base de información en distintos bloques de contenidos,

estos contenidos se conectan a través de una serie de enlaces que al ser activados se

produce la recuperación de información presentada en forma de hipertexto, que es el

formato estándar de las páginas web.

25

� Internet Information Services (ISS): ISS es un conjunto de servicios para

servidores operando bajo el sistema operativo Microsoft Windows. Este servicio es

usado para convertir un computador en un servidor web ya sea en internet o en una

red intranet. En otras palabras, las computadoras que dispongan de este servicio

instalado tienen la capacidad de publicar páginas web local y remotamente.

� JavaScript: Es un lenguaje de programación orientado a las páginas web. El

lenguaje JavaScript puede interactuar con el código HTML, permitiéndole a los

desarrolladores elaborar contenido dinámico en las páginas web; es un lenguaje

interpretado, es decir, no requiere compilación ya que funciona del lado del cliente.

� Microsoft SQL Server: Es una herramienta para la gestión de base de datos

creada por Microsoft, el cual está basado en un modelo relacional. Microsoft SQL

Server es capaz de manejar grandes cantidades de datos de manera simultánea, esta es

una de las razones por la cual numerosas compañías a nivel mundial usan esta

herramienta para la gestión de sus bases de datos.

� Requisición de Compras por Caja Chica: Documento que formaliza la solicitud

de compras y/o pagos menores ante la Caja Chica.

� StructuredQueryLanguage(SQL): El lenguaje de consulta estructurado por sus

siglas en inglés, es un lenguaje que surgió a raíz de un proyecto de investigación en el

año 1974 por la empresa IBM para el acceso a bases de datos de tipo relacionales que

permite especificar distintas clases de operaciones entre ellas. Este es un lenguaje

universal que se encuentra implementado en todos los motores de bases de datos, por

lo cual éste es el lenguaje estándar de comunicación entre los diversos motores

existentes.

CAPÍTULO IV

MARCO METODOLÓGICO

4.1 Tipo de Investigación

El proyectose encuentra enmarcado dentro del modelo de una investigación

especial, que lleva a la creación de un producto tangible, susceptible a ser utilizado

como solución a problemas correctamente identificados y documentados. Es por ello

que dicha investigación está enfocada a proporcionar soluciones viablesa problemas

presentados en la empresa Smurfit Kappa Cartón de Venezuela, S.A. más

específicamente en las oficinas corporativas situadas en la planta LEO, mediante la

creación de un producto tangible.

Hernández (2006) señala que: Los proyectos especiales, en todos los casos, deben incluir la demostración de la necesidad de la creación o de la importancia del aporte, según sea el caso, la fundamentación teórica, la descripción de la metodología utilizada y el resultado concreto del trabajo en forma acabada. En el caso de las Tesis Doctorales sólo se aceptarán Proyectos Especiales cuando tengan como soporte un sólido diseño de investigación, conlleven o se deriven de elaboraciones conceptuales originales del estudiante y el resultado tangible se caracterice por su significativo valor innovador. (p. 14)

4.2 Diseño de la Investigación

El diseño de este trabajo de grado,se encuadra dentro de los lineamientos de una

investigación de campo. SegúnArias (2004), “consiste en la recolección de datos

directamente de la realidad donde ocurren los hechos, sin manipular o controlar

variables alguna”.

.Los objetivos formulados en este proyecto se adaptan al proceso de desarrollo

del sistema en sí, para esto fue esencial medir de fuente directa la opinión de los

usuarios implicados en el proceso de solicitud de requisiciones de compras por caja

chica, a fin de determinar las necesidades para la mejora de este proceso.

27

4.3 Nivel de la Investigación

Según su nivel es una investigación descriptiva,sobre esto Balestrini (2002)

expone que “los estudios descriptivos, infieren la descripción con mayor precisión,

acerca de las singularidades de una realidad estudiada, podrá estar referido a una

comunidad, una organización, un hecho delictivo, las características de un tipo de

gestión” (p. 6).

En base a lo anteriormente expuesto, el presente trabajo se asienta en las bases

de una investigación de tipo descriptiva, ya que en éste se analizan con gran detalle

las características de la problemática actual en referencia a el proceso de solicitud de

requisición de compras por caja chica en la empresa, empleando técnicas adecuadas

para la recolección de datos para su posterior análisis y descripción.

4.4 Población y Muestra

Tamayo y Tamayo (1997), señala que “la población se define como la totalidad

del fenómeno a estudiar donde las unidades de población posee una característica

común la cual se estudia y da origen a los datos de la investigación”(p.114).

Por otro lado Balestrini (2006), define la población como: “conjunto finito o

infinito de personas, casos o elementos, que presentan características comunes” (p.

137). De igual manera señala que: “una muestra es una parte representativa de una

población, cuyas características deben producirse en ella, lo más exactamente

posible” (p.141).

Castro (2003), la muestra se clasifica en probabilística y no probabilística. La probabilística, son aquellas donde todos los miembros de la población tienen la misma opción de conformarla a su vez pueden ser: muestra aleatoria simple, muestra de azar sistemático, muestra estratificada o por conglomerado o áreas. La no probabilística, la elección de los miembros para el estudio dependerá de un criterio específico del investigador, lo que significa que no todos los miembros de la población tienen igualdad de oportunidad de conformarla.

28

Por otro lado, Ramírez (1999), indica que "la mayoría de los autores coinciden

que se puede tomar un aproximado del 30% de la población y se tendría una muestra

con un nivel elevado de representatividad". (p. 91).

En este sentido, la población que constituye la presente investigación está

representada por todo el personal administrativoque posee acceso a la intranet en las

oficinas corporativas a excepción de los pasanteslos cuales representan

aproximadamente un total de ciento cincuenta (150). Así mismo, tomando como

marco las bases anteriormente pautadas, se tomó una muestra probabilística aleatoria

simple, la cual está compuesta por treinta (30) representantes del área de contabilidad

y quince (15) representantes del área de servicios de información.

4.5 Técnicas de Recolección de Datos

De acuerdo con Arias (1999), “las técnicas de recolección de datos son las

distintas formas o maneras de obtener la información” (P.53).Durante el

levantamiento de informaciónpara la recopilación de requerimientos y posterior

elaboración del software, se emplearon como técnicas de recolección de datos la

entrevista y la observación directa.

4.6 FasesMetodológicas

Para desarrollar las fases conforme a los requerimientos del sistema y cumplir

con la finalidad del proyecto, es necesario la selección de una metodología adecuada

que cumpla conlas necesidades de la empresa, el tiempo disponible y la complejidad

del sistema.

En este sentido, fue seleccionada la metodología eXtremeProgramming (XP,

por sus siglas en inglés) junto con el lenguaje unificado de modelado (UML, por sus

siglas en ingles) para el desarrollo del sistema de control de requisiciones de compras

por caja chica.

4.6.1 Fase I: Planificación

En esta fase se realizó el levantamiento de información con el fin de determinar

los requerimientos del sistema, conocer cómo se maneja el actual proceso para poder

definir las expectativas de la organización respecto al software en desarrollo. En este

29

sentido, se realizaron una serie de entrevistas a los actores responsables del uso del

sistema actual.

Adicionalmente a esto, se crearon historias de usuarios a los principales

usuarios que tenían una amplia comprensión del proceso manual que se lleva

actualmente,para determinar los requerimientos del sistema y posteriormenteelaborar

un plan de trabajo que luego será divido en iteraciones partiendo de niveles de

prioridad y de este modo poder estimar el tiempo en que se desarrollara el proyecto y

que se realizara en cada momento.

4.6.2 Fase II: Diseño

La metodología XP consiguió diseños simples y sencillos, de manera que fuera

lo menos complejo posible para lograr un diseño fácilmente descifrable que a la larga

costará menos tiempo y esfuerzo desarrollar.

Para la fase del diseño del sistema se empleó el uso del diagrama de entidad-

relación (ER) y el diccionario de datos de éste para la posterior elaboración de la base

de datos, se utilizóla herramienta UML, específicamente los diagramas de casos de

uso y sus especificaciones, que proporciona la identificación de los actores

responsables de las distintas tareas del sistema. Igualmente, se elaboraron los diseños

de interfaces correspondientes al sistema de acuerdo a las necesidades del cliente,

tomando en cuenta los datos previamente recolectados al igual que los

requerimientos.

4.6.3 Fase III: Desarrollo

El objetivo principal de esta etapa fuecodificar la aplicación web, la cualcontó

con las características más importantes según los requisitos predefinidos en el

levantamiento de información.Al programar el sistema se tomó en cuenta los

requerimientos funcionales y no funcionales ya dados por las historias de usuarios.

En esta fase los diseños de bases de datos y diagramas mediante UML fueron

trasladados a código, con el fin de realizar la integración de la base de datos, la

interfaz del usuario y el código de programación que le aporta al sistema la

30

funcionalidad para la que se esbozó. Es por esto que se muestra en esta fase las

pantallas que han sido desarrolladas para la aplicación.

4.6.4 Fase IV: Pruebas

Las pruebas al sistema es la última fase de la metodología XP, siendo ésta de

gran importancia ya que es considerada como la fase más estricta, la cual consiste en

la realización de los distintos tipos de testal sistema para comprobar que todos los

módulos funcionen según lo planificado; en caso de que alguno de estos módulos

presente algún error deberá corregirse antes de ser implementados.

Es en esta fase cuando se evaluó la funcionalidad del sistema, al ser esta muy

poco extensa, no se hizo test que analicen partes de las mismas, sino que las pruebas

se ejecutaron para las funcionalidades generales que debe cumplir el programa

especificado en la descripción de exigencias pedidas por Smurfit Kappa S.A.

CAPITULO V

RESULTADOS

5.1.Fase I: Planificación

En esta fase se conocieron los principales procesos del funcionamiento actual

del subsistema administrativo de requisición de compras por caja chica de la empresa

SMURFIT KAPPA, S.A., para la comprensión del mismo, al igual que las

necesidades que éste presentaba por parte del cliente.

5.1.1. Usuarios del sistema

De acuerdo a la recolección de datos anteriormente realizada para el

levantamiento de información y posterior desarrollo del software, se obtuvieron los

siguientes usuarios participantes del sistema.

Cada usuarioque fue considerado en la interacción con el sistema, cumple

unpapel importante y especifico en cada una de las historias de usuario presentadas

más adelante, ya que éstos son los que resultaran beneficiados por el uso adecuado

del sistema. El sistema se compone por tres tipos de usuarios, los cuales son:

� Usuario Común: este usuario representa el nivel más básico de privilegio en el

sistema, posee lacapacidadde generar una solicitud de requisición de compra por caja

chica, acceder al detalle de sus solicitudes e imprimir las mismas y están

representados por todos los usuarios de la planta LEO de la empresa Smurfit Kappa

Cartones de Venezuela S.A., a excepción de los pasantes.

� Agente: este usuario depende de preferencias de acceso a diferentes módulos del

sistema cargadas en la base de datos, y tiene la función de tramitar solicitudes,

ejecutar solicitudes, cargar compras, acceder al control de compras, generar recibos,

acceder a los reportes del sistema y realizar mantenimiento de las tablas maestras de

la base de datos dependiendo de las preferencias que éste posea.

� Administrador: este usuario tiene la función realizar mantenimiento a las tablas

maestras y de administrar los privilegios de usuarios. Es responsable de la seguridad

del sistema.

32

5.1.2. Historias de usuarios

Los requerimientos para el desarrollo del sistema se obtuvieron mediante una

serie de reuniones con la encargada de la administración del actual proceso de

requisición de compras por caja chica de (Rodríguez, Mireya) y el Tutor Empresarial

(Ramírez, Yonnattal). Dichos requerimientos fueron plasmados en las historias de

usuario (HU).

A continuación se exponen los cuadros de cada una de las historias realizadas:

Cuadro 1. Historia de Usuario: Solicitud de requisición

Historia de Usuario Número: 1 Nombre:Solicitud de requisición Riesgo en Desarrollo: Medio Prioridad: Alta Cliente:Usuario Común Descripción: Se requiere un módulo que permita a todo aquel usuario con acceso al sistema, realizar una solicitud de requisición de compras por caja chica Observación:


Cuadro 2. Historia de Usuario: Detalle de Solicitud

Historia de Usuario Número: 2 Nombre: Detalle de Solicitud Riesgo en Desarrollo: Bajo Prioridad: Alta Cliente: Usuario Común, Agente, Administrador Descripción: El detalle de cada solicitud cargada en el sistema debe ser accesible por cualquier usuario que ingrese a éste, el cual especifica el departamento de la persona que solicita, la fecha en que fue cargada la solicitud, rechazada o aprobada, el agente que aprobó o rechazó, el estado de la solicitud y los ítems cargados en la misma. Observación:


33

Cuadro 3. Historia de Usuario: Tramitar solicitud

Historia de Usuario Número: 3 Nombre: Tramitar solicitud Riesgo en Desarrollo: Bajo Prioridad: Alta Cliente: Agente Descripción: Se requiere que cada solicitud cargada en el sistema pase ser tramitada por el gerente o encargado de área donde ésta fue cargada, de manera que la solicitud pueda ser aprobada o rechazada por éste agente. Observación:


Cuadro 4. Historia de Usuario: Ejecutar solicitud

Historia de Usuario Número: 4 Nombre: Ejecutar solicitud Riesgo en Desarrollo: Bajo Prioridad: Alta Cliente: Agente Descripción:Se requiere que las solicitudes que se encuentran en estado de aprobadas pasan a ser ejecutadas por el agente que posee la preferencia de acceso indicada para esta tarea, accediendo al detalle dicha solicitud y ejecutando la misma. Observación:


Cuadro 5. Historia de Usuario: Incluir Compra

Historia de Usuario Número: 5 Nombre: Incluir Compra Riesgo en Desarrollo: Bajo Prioridad: Alta Cliente: Agente Descripción: El agente encargado del manejo de requisición de compras por caja chica requiere un módulo en el cual se puedan cargar en el sistema los detalles de cada compra realizada por concepto de requisición. Observación:


34

Cuadro 6. Historia de Usuario: Generar Recibo

Historia de Usuario Número: 6 Nombre: Generar Recibo Riesgo en Desarrollo: Bajo Prioridad: Alta Cliente: Agente Descripción:Se requiere generar un recibo para llevar el control de compras que realiza cada mensajero especificando el monto de la compra en bolívares, los datos del mensajero y el concepto de la compra. Observación:


Cuadro 7. Historia de Usuario: Administración de Tablas Maestras

Historia de Usuario Número: 7 Nombre: Administración de Tablas Maestras Riesgo en Desarrollo: Alto Prioridad: Alta Cliente: Agente, Administrador Descripción: Se requiere un módulo individual para editar las tablas maestras de ítems, mensajeros y departamentos. Observación:


Cuadro 8. Historia de Usuario: Administración de Privilegios

Historia de Usuario Número: 8 Nombre: Administración de Privilegios Riesgo en Desarrollo: Alto Prioridad: Alta Cliente: Administrador Descripción: El administrador debe ser capaz de editar los privilegios o preferencias de los Agentes actores del sistema. Observación:


5.1.3. Planificación de entrega

El esfuerzo y el tiempo requerido en el transcurso del proyecto es requisito

necesario para poder elaborar un plan de entregas real para el software en desarrollo,

basándose en las actividades que se sugieren en cada historia de usuario.

35

Cuadro 9. Estimación de Esfuerzos

N° de Historia

Nombre de Historia Riesgo Prioridad Equivalencia en tiempo

(días)

1 Solicitud de requisición

Medio Alta 5

2 Detalle de Solicitud Bajo Alta 3 3 Tramitar solicitud Bajo Alta 4 4 Ejecutar solicitud Bajo Alta 2 5 Incluir Compra Bajo Alta 3 6 Generar Recibo Medio Alta 3

7 Administración de Tablas Maestras

Alto Alta 4

8 Administración de

Privilegios Alto Alta 3


Luego de haber estimado el esfuerzo de cada historia de usuario y el riesgo que

puede presentar al momento del desarrollo de cada una éstas y tomando en cuenta el

tiempo que se lleva terminar cada requerimiento así como también el flujo que

llevaba el anterior proceso manual, se puede establecer el orden en que las historias

de usuario van hacer entregadas a la empresa, las cuales se evidencian en el Cuadro

10:

Cuadro 10. Iteraciones

N° de Historia Nombre de Historia Iteración 1 Solicitud de requisición 1

2 Detalle de Solicitud

3 Tramitar solicitud 2

4 Ejecutar solicitud 5 Incluir Compra

3 6 Generar Recibo 7 Administración de Tablas Maestras

4 8 Administración de Privilegios


36

Cumpliendo con los requerimientos exigidos por el cliente, se realizó la

planificación para el diseño y la elaboración de los diferentes módulos del sistema en

base al flujo del proceso de éste, donde se establecen las fechas de entrega al igual

que la duración de las tareas basadas en las historias de usuario.

A continuación se muestran los cuadros de las tareas de las historias de usuario:

Cuadro 11. Plan de Entregas

N° Historia

N° de Tarea

Tarea Iteración Fecha de Inicio

Fecha de Finalización

1 1 Diseñar el módulo de solicitud

de requisiciones 1

22/05/2014 28/05/2014

1 1.1 Elaborar el módulo de solicitud

de requisiciones 02/06/2014 06/06/2014

2 2 Elaborar un estilo para las

tablas que muestran el detalle de las solicitudes

02/06/2014 06/06/2014

3 3 Elaborar el modulo que permita

tramitar las solicitudes 2

11/06/2014 19/06/2014

4 4 Elaborar el modulo que permita

ejecutar las solicitudes aprobadas

25/06/2014 30/06/2014

5 5 Elaborar el modulo para incluir

compras 3

08/07/2014 14/07/2014

6 6 Diseñar el formulario que

genera el recibo 22/07/2014 28/07/2014

7 7

Diseñar interfaz para acceder al mantenimiento de cada una de las tablas maestras y el módulo

de éstas 4 04/08/2014 07/08/2014

8 8 Elaborar modulo para editar

privilegios de Agentes 11/08/2014 14/08/2014


5.1.4. Iteraciones

Cumpliendo con lo establecido en el plan de entregas, las iteraciones que se

deben cumplir son las siguientes:

37

Cuadro 12. Tarea 1

Tarea 1 Historia de usuario: 1 Iteración N°: 1 Tarea a implementar:Diseñar el módulo de solicitud de requisiciones Tipo de tarea:Diseño Fecha de Inicio: 22/05/2014 Fecha Final: 28/05/2014 Descripción: Diseñarel módulo que permita a todo aquel usuario con acceso al sistema, realizar una solicitud de requisición de compras por caja chica. Observación:


Cuadro 12.1 Tarea 1.1

Tarea 1.1 Historia de usuario: 1 Iteración N°: 1 Tarea a implementar: Elaborar el módulo de solicitud de requisiciones Tipo de tarea: Elaboración Fecha de Inicio: 02/06/2014 Fecha Final: 06/06/2014 Descripción: Elaborar en base al diseño previamente realizado, el módulo que permita a todo aquel usuario con acceso al sistema a realizar solicitudes de requisición de compras por caja chica validando los datos ingresados en el formulario de solicitud. Observación:


38

Cuadro 13. Tarea 2

Tarea 2 Histori a de usuario: 2 Iteración N°: 1 Tarea a implementar:Elaborar un estilo para las tablas que muestran el detalle de las solicitudes Tipo de tarea:Elaboración de estilo Fecha de Inicio: 02/06/2014 Fecha Final: 06/06/2014 Descripción: Elaborarlas tablas que le mostraran al usuario el detalle de la solicitud a la que éste está accediendo. Así mismo incluir en el módulo de detalle solicitud las opciones de imprimir, aprobar, rechazar de acuerdo a las condiciones anteriormente definidas. Observación:


Cuadro 14. Tarea 3

Tarea 3 Historia de usuario: 3 Iteración N°: 2 Tarea a implementar:Elaborar el modulo que permita tramitar las solicitudes Tipo de tarea:Elaboración Fecha de Inicio: 11/06/2014 Fecha Final: 19/06/2014 Descripción: Elaborar la tabla que muestre las solicitudes cargadas según el departamento correspondiente al agente que se encuentre en este módulo, permitiéndole a este acceder al detalle de cada solicitud de su área y aprobarla o rechazarla. Observación:


39

Cuadro 15. Tarea 4

Tarea 4 Historia de usuario: 4 Iteración N°: 2 Tarea a implementar:Elaborar el modulo que permita ejecutar las solicitudes aprobadas Tipo de tarea:Elaboración Fecha de Inicio: 25/06/2014 Fecha Final: 30/06/2014 Descripción:Elaborar el diseño de la tabla que muestre las solicitudes en estado de aprobadas de manera que el agente responsable de ejecutar estas solicitudes pueda acceder al detalle de cada una de ellas e imprimirlas. Observación:


Cuadro 16. Tarea 5

Tarea 5 Historia de usuario: 5 Iteración N°: 3 Tarea a implementar:Elaborar el modulo para incluir compras Tipo de tarea:Elaboración Fecha de Inicio: 08/07/2014 Fecha Final: 14/07/2014 Descripción:Elaborar el modulo que permita incluir las compras realizadas por concepto de caja chica, cargando el detalle de la compra previamente realizada. Observación:


Cuadro 17. Tarea 6

Tarea 6 Historia de usuario: 6 Iteración N°: 3 Tarea a implementar:Diseñar el formulario que genera el recibo Tipo de tarea:Diseño Fecha de Inicio: 22/07/2014 Fecha Final: 28/07/2014 Descripción: Diseñar el modelo formulario que permita generar un recibo de compras especificando, el monto en bolívares de dicha compra, así como también, el mensajero encargado de realizar dicha compra, y el concepto. Observación:


40

Cuadro 18. Tarea 7

Tarea 7 Historia de usuario: 7 Iteración N°: 4 Tarea a implementar:Diseñar interfaz para acceder al mantenimiento de cada una de las tablas maestras y el módulo de éstas Tipo de tarea:Diseño Fecha de Inicio: 04/08/2014 Fecha Final: 07/08/2014 Descripción:Diseñar la interfaz principal para el mantenimiento de las diferentes tablas maestras del sistema y desarrollar el modulo que permita la edición de cada una de éstas. Observación:


Cuadro 19. Tarea 8

Tarea 8 Historia de usuario: 8 Iteración N°: 4 Tarea a implementar:Elaborar modulo para editar privilegios de Agentes Tipo de tarea:Elaboración Fecha de Inicio: 11/08/2014 Fecha Final: 14/08/2014 Descripción:Elaborar el modulo que le permita al administrador editar los privilegios o preferencias de los Agentes actores del sistema. Observación:


5.2.Fase II:Diseño

5.2.1. Modelado de casos de uso

Se realizó el diagrama de casos de uso correspondiente a este proyecto

paradescribir la funcionalidad del sistema desde el punto de vista del cliente,

detallando todos los requisitos y acciones en las que el usuario estará involucrado.

41

Figura 3: Caso de uso: Consultas de usuario común


Figura 4: Caso de uso: Administrador


42

Figura 5: Caso de uso: Agente


43

5.2.2. Descripción de casos de uso

A continuación se muestra la especificación de los casos de uso para cada uno

de los actores:

Cuadro 20. Descripción de caso de uso “Tramitar”.

Caso de Uso Tramitar Elaborado por Álvarez, Argenis Fecha Elaboración 15/07/2014

Objetivo Encargado de gestionar los tramites del software, como

los detalles de solicitud, e internamente su aprobación,

rechazo, y la manera de imprimirlo.

Entradas • Aprobar

• Rechazar

Precondiciones • El usuario debe estar registrado

• El usuario debe tener el nivel que le permita

acceder a este módulo.

Salidas Trámite generado

Posibles:

• Detalles de solicitud: donde se puede consultar

su aprobación, rechazo (explicado con motivos),

o imprimir el trámite.

Post-condición éxito Mostrar mensaje de éxito

Post-condición fallo Mostrar mensaje de error.

Rol Responsable Agente

Otros Actores No aplica

Actor / Secuencia normal

Agente 1. Accede al módulo dependiendo del privilegio que posea.

Agente 2. Tramita solicitud seleccionada


44

Cuadro 20.1. Continuación de descripción de caso de uso “Tramitar”.

Sistema 3. Envía la información a la base de datos.

Sistema 4. Validar los datos ingresados

• Condición de éxito: Paso 5

• Fallo: Desplegar Mensaje_1 y luego Paso 1

Sistema 5. Desplegar mensaje_2 yPosible:

• Llamar caso de uso “aprobar”.

• Llamar caso de uso “rechazar”.

• Llamar caso de uso “imprimir”.

• Fin.

Actor / Secuencia alternativa

Usuario 5. El usuario ingresa campos incorrectos.

Sistema 6. Desplegar Mensaje_1 y Paso 1

Observaciones:

Mensajes Desplegados

Mensaje_1

Error

Error Tramitando solicitud.

Verifique la información dada.

Mensaje_2 Solicitud Tramitada con éxito, desea:

• Aprobar

• Rechazar

• Imprimir

• Salir


45

Cuadro 21. Descripción de caso de uso “Ejecutar”.

Caso de Uso Ejecutar Elaborado por Álvarez, Argenis Fecha Elaboración 15/07/2014

Objetivo Envía la solicitud donde es posible ver el detalle de la

misma

Entradas




Salidas Ejecución exitosa

Posibles:

• Detalles de solicitud







Agente 2. Ejecuta solicitud seleccionada.






46

Cuadro 21.1. Continuación de descripción de caso de uso “Ejecutar”

Sistema 5. Desplegar mensaje_2 yPosible:

• Llamar caso de uso “detalle de solicitud”

• Fin.




Observaciones:


Mensaje_1

Error

Error ejecutando solicitud.


Mensaje_2 Solicitud ejecutada con éxito, desea:

• Ver detalle

• Salir


47

Cuadro 22. Descripción de caso de uso “control de compras”.

Caso de Uso Control de compras Elaborado por Álvarez, Argenis Fecha Elaboración 15/07/2014

Objetivo Este caso de uso se encarga de controlar las compras

emitidas en la empresa.

Entradas




Salidas Consulta generada.







Agente 2. Consulta compra seleccionada.



• Condición de éxito: Fin.




48



Cuadro 22.1. Continuación de descripción de caso de uso “control de compras”

Observaciones:


Mensaje_1

Error

Error realizando consulta.



Cuadro 23. Descripción de caso de uso “incluir compra”.

Caso de Uso Incluir compra Elaborado por Álvarez, Argenis Fecha Elaboración 15/07/2014

Objetivo Como su nombre lo indica, este caso de uso se encarga de

incluir una compra emitida en la empresa.

Entradas • Ítem de la compra

• Proveedor del ítem

• Concepto de la compra

• Centro de costo

• Monto de la compra




Salidas Compra insertada.






49

Cuadro 23.1. Continuación de descripción de caso de uso “incluir compra”



Agente 2. Ingresa datos de la nueva compra.








Observaciones:


Mensaje_1

Error

Error insertando compra.



50

Cuadro 24. Descripción de caso de uso “generar recibo”.

Caso de Uso Generar recibo Elaborado por Álvarez, Argenis Fecha Elaboración 15/07/2014

Objetivo Se encarga de generar recibos de las compras que se

encuentran alojadas en el sistema.

Entradas • Mensajero

• Monto en Bolívares

• Concepto




Salidas Recibo generado.

Post-condición éxito Mostrar mensaje de éxito.






Agente 2. Selecciona compra para generar la salida

Sistema 3. Recibo generado y

Posible:

• Llamar caso de uso “insertar compra”

• Llamar caso de uso “editar recibo”.

Observaciones:



51

Cuadro 25. Descripción de caso de uso “consultar reporte”.

Caso de Uso Consultar reporte Elaborado por Álvarez, Argenis Fecha Elaboración 15/07/2014

Objetivo Consulta reportes emitidos en el sistema y tiene la opción

de ver el detalle de la solicitud asociada.

Entradas • Código de solicitud




Salidas Consulta exitosa.







Agente 2. Selecciona el reporte.


Sistema 4. Consulta generada y

Posible:

• Llamar caso de uso “detalle de solicitud”

Observaciones:



52

Cuadro 26. Descripción de caso de uso “consulta de reporte grafico”.

Caso de Uso Consultar reporte de grafico Elaborado por Álvarez, Argenis Fecha Elaboración 15/07/2014

Objetivo Consulta gráficos de reportes emitidos en el sistema.

Entradas




Salidas Consulta exitosa.







Agente 2. Selecciona el reporte.


Sistema 4. Consulta generada

Observaciones:



53

Cuadro 27. Descripción de caso de uso “mantenimiento”.

Caso de Uso Mantenimiento Elaborado por Álvarez, Argenis Fecha Elaboración 15/07/2014

Objetivo Mantenimiento es un caso que engloba casos de uso de gestión

para la administración del sistema.

Entradas


• El usuario debe tener el nivel que le permita acceder a

este módulo.

Salidas Llamada exitosa

Post-condición

éxito

Mostrar mensaje de éxito

Post-condición

fallo

Mostrar mensaje de error.





Agente 2. Selecciona los posibles:

• Llamar caso de uso “modificar ítems”

• Llamar caso de uso “modificar departamentos”

• Llamar caso de uso “modificar mensajeros”

• Llamar caso de uso “privilegio de los usuarios”




54



Cuadro 27.1. Continuación de descripción de caso de uso “mantenimiento”.

Observaciones:


Mensaje_1

Error

Error interno


Cuadro 28. Descripción de caso de uso “gestión de ítems”.

Caso de Uso Gestión de ítems Elaborado por Álvarez, Argenis Fecha Elaboración 15/07/2014

Objetivo Se encarga de crear o editar los ítems del sistema.

Entradas • Descripción del Ítem

• Proveedor del Ítem


• El usuario debe tener el nivel que le permita acceder a

este módulo.

Salidas Ítem creado/modificado.

Post-condición

éxito

Mostrar mensaje de éxito

Post-condición

fallo

Mostrar mensaje de error.



55




Cuadro 28.1. Continuación de descripción de caso de uso “gestión de ítems”.

Agente 2. Consulta items y posible:

• Crea nuevo item.

• Edita item existente.








Observaciones:


Mensaje_1

Error

Error insertando datos.



56

Cuadro 29. Descripción de caso de uso “gestionar departamentos”.

Caso de Uso Gestionar departamentos Elaborado por Álvarez, Argenis Fecha Elaboración 15/07/2014

Objetivo Se encarga de crear o editar los departamentos del sistema.

Entradas • Código de área

• Nombre

• Tramita

• VPA

• VPC




Salidas departamento creado/modificado.







Agente 2. Consulta los departamentos y posible:

• Crea nuevo departamento

• Edita departamento existente.






57

Cuadro 29.1. Continuación de descripción de caso de uso “gestionar departamentos”.




Observaciones:


Mensaje_1

Error




Cuadro 30. Descripción de caso de uso “gestionar mensajeros”.

Caso de Uso Gestionar mensajeros Elaborado por Álvarez, Argenis Fecha Elaboración 15/07/2014

Objetivo Se encarga de crear o editar los usuarios mensajeros del

sistema.

Entradas • Nombre

• Cedula de identidad

• Numero de teléfono




Salidas Usuario mensajero creado/modificado.





58

Cuadro 30.1. Continuación de descripción de caso de uso “gestionar mensajeros”.




Agente 2. Consulta los departamentos y posible:

• Crea nuevo mensajero

• Edita mensajero existente.








Observaciones:


Mensaje_1

Error




59

Cuadro 31. Descripción de caso de uso “privilegios del usuario”.

Caso de Uso Privilegios del usuario Elaborado por Álvarez, Argenis Fecha Elaboración 15/07/2014

Objetivo Se encarga de editar los privilegios de los usuarios

Entradas • Nivel de usuario




Salidas Privilegio modificado.







Agente 2. Consulta los privilegios disponibles y

• Edita privilegio existente.









60

Cuadro 31.1. Continuación de descripción de caso de uso “privilegios del usuario”.

Observaciones:


Mensaje_1

Error




Cuadro 32. Descripción de caso de uso “nivel del usuario”

Caso de Uso Nivel del usuario Elaborado por Álvarez, Argenis Fecha Elaboración 15/07/2014

Objetivo Encargado de traer información de la base de datos

referente a los niveles del usuario que ingresó al sistema.

Entradas • Identificador del usuario

Precondiciones • El usuario debe estar registrado.

Salidas Nivel cargado con éxito.



Rol Responsable Usuario

Otros Actores Sistema


Usuario 1. Ingresa al sistema.

Sistema 2. Envía identificador del usuario a la base de dato a través de

una consulta para verificar cual nivel tiene asignado.


61

Cuadro 32.1. Continuación de descripción de caso de uso “nivel del usuario”.

Sistema 3. El sistema dependiendo del nivel del usuario empieza a

llamar a los módulos y ventanas que tiene disponible,

generando el cuerpo de la página específico para ese

usuario.

Sistema 5. Fin.


Usuario 6. Al ingresar al sistema el usuario no tiene ningún nivel

asignado, por lo que no podrá visualizar ciertos

elementos.

Sistema 7. Fin.

Observaciones:


Mensaje_1

Error

Error interno

Intente nuevamente.


62

5.2.3. Modelo de la base de datos

A continuación en la Figura 6 se presenta el modelo de cómo se desarrolló la base de datos del sistema:

Figura 6: Diagrama del Modelo Entidad Relación


63

Igualmente en la Figura 7se muestra el modelo lógico que refleja las diferentes

tablas que forman la base de datos y sus interrelaciones:

Figura 7: Diagrama del Modelo Relacional


5.2.4 Diccionario de datos

Además del modelo lógico relacional, se realizó un diccionario de datos,

donde se especificó la relación entre tablas, tipo de dato y verificación de campos

nulos para cada atributo de las tablas para obtener un desarrollo correcto y de fácil

entendimiento de la base de datos, cumpliendo con los requerimientos del cliente y

del sistema:

64

Figura 8: Diccionario de datos. Tabla _Agentes


Figura 8.1: Diccionario de datos. Tabla _Agentes


65

Figura 9: Diccionario de datos. Tabla _Areas


Figura 9.1: Diccionario de datos. Tabla _Areas


Figura 10: Diccionario de datos. Tabla _CentrosCostos


66

Figura 10.1: Diccionario de datos. Tabla _CentrosCostos


Figura 11: Diccionario de datos. Tabla _ControlC


Figura 11.1: Diccionario de datos. Tabla _ControlC


Figura 12: Diccionario de datos. Tabla _DetalleSolicitudes


67

Figura 12.1: Diccionario de datos. Tabla _DetalleSolicitudes


Figura 13: Diccionario de datos. Tabla _Items


Figura 13.1: Diccionario de datos. Tabla _Items


Figura 14: Diccionario de datos. Tabla _Mensajeros


68

Figura 14.1: Diccionario de datos. Tabla _Mensajeros


Figura 15: Diccionario de datos. Tabla _Plantas


Figura 15.1: Diccionario de datos. Tabla _Plantas


Figura 16: Diccionario de datos. Tabla _Recibos

69

Fuente: Álvarez, Argenis

(2014)

Figura 16.1: Diccionario de datos. Tabla _Recibos


Figura 17: Diccionario de datos. Tabla _Solicitudes


70

Figura 17.1: Diccionario de datos. Tabla _Solicitudes


5.2.5 Diseño de Interfaces

En lasiguiente figura se muestra el diseño de la interfaz,elaborada en base al

prototipo de interfaz que maneja la empresa en sus sistemas:

Figura 18: Diseño de Interfaz


71

5.2.6. Arquitectura del sistema

El diseño de la arquitectura del sistema se fundamentó en tres capas separadas,

llevando a cabo un desarrollo segmentado en varios niveles. A continuación se

describen cada una de estas capas:

� Capa de presentación: es la presentación del programa mediante una interfaz

gráfica, esta capa es la que ve el usuario final y usa para interactuar con el sistema en

sí, comunica y captura la información. Esta capa se comunica únicamente con la capa

de negocio.

� Capa de negocio: es donde se reciben las peticiones del usuario, mediante

programas que son ejecutados para posteriormenteenviarlas respuestas tras el

proceso,estableciendo todas las reglas que deben cumplirse. Se comunica con la capa

presentación y con la capa de datos.

� Capa de datos: es donde residen los datos del sistema y es la encargada de

administrar los mismos. Recibe solicitudes de almacenamiento o recuperación de la

información desde la capa de negocio.

A continuación se presentan dichas capas en la Figura 8:

Figura 19: Arquitectura del sistema


72

5.2.7. Mapa del sitio

A continuación en la Figura 20, se muestra los diferentes módulos accesibles

por los actores del sistema que posee la estructura del sitio:

Figura 20: Mapa del sitio


5.3.Fase III: Desarrollo

La información recaudada por todas las fases anteriores se afianza en esta fase,

está se desarrolló bajo el lenguaje de programación ASP, empleando los servicios de

Internet Information Server (IIS). Así mismo, se utilizó HTML, JavaScript y hojas de

estilo (CSS). El tiempo de desarrollo fue de entre siete (7) y ocho (8) horas diarias,

cinco (5) días a la semana, en una estación de trabajo bajo el sistema operativo

Windows 7 Ultimate 32 Bits, el software requirió correr bajo ambiente Windows

empleando su navegador web predeterminado Internet Explorer ya que ese es el

sistema operativo y el único navegador de internet de la empresa para poder correr las

aplicaciones o herramientas de trabajo.

73

El desarrollo de la base de datos se realizó con la herramienta SQL Server

Management Studio 2012. Esta herramienta posee una interfaz gráfica donde se crean

las tablas, relaciones entre ellas, atributos clave y foráneos, tipo de dato, tamaño de

dato y diagrama de base de datos.

5.3.1. Pantallas del sistema

En las siguientes figuras se presentan las diferentes pantallas de usuario del

sistema, que han sido creadas mediante la codificación en el lenguaje de

programación elegido para el proyecto.

5.3.1.1 Mis Solicitudes

Una vez que el usuario ingrese al sistema a través de la intranet de la empresa, se

muestra la pantalla inicial con las solicitudes cargadas por dicho usuario al igual que

el número de solicitud, la fecha en que fue cargada, y el estado de las mismas.

Figura 21: Pantalla Mis Solicitudes


74

5.3.1.2 Solicitar

Al ingresar en el módulo de “Solicitar”, se muestra al usuario un formato para

generar una solicitud de requisición de compra por caja chica, el cual se compone por

el nombre del departamento al que el usuario pertenece, la fecha actual, el logo de la

compañía, la cantidad de ítems que se quieren solicitar, el tipo de élo de los ítems y

un campo que se activa en caso de que el o los ítem que se quieren solicitar no se

encuentren cargados en la tabla maestra de ítems del sistema.

Figura 22: Pantalla Solicitar


75

5.3.1.3 Tramitar

El modulo “Tramitar” muestra las solicitudes que han sido cargadas en el sistema

y se encuentra en estado de “Cargadas”, éstas se filtran por el departamento del

agente que haya ingresado al sistema. Así mismo, las solicitudes pueden ser filtradas

por el número de solicitud y se puede acceder al detalle de estas haciendo click en el

número de la solicitud deseada.

Figura 23: Pantalla Tramitar


76

5.3.1.4 Ejecutar

En el módulo Ejecutar se muestra una tabla con las solicitudes que ya están

aprobadas por el agente responsable, al igual que los datos más relevantes de dichas

solicitudes tales como, el número de solicitud, el departamento del usuario que la

cargó, la fecha en que fue cargada y el nombre del usuario que generó la solicitud.

Figura 24: Pantalla Ejecutar


77

5.3.1.5 Generar Recibo

Para realizar una compra se debe crear previamente un recibo entrando al

módulo de Generar Recibo el cual está conformado por el logo de la empresa, un

menú desplegable con la lista de los mensajeros, una casilla que se activa

automáticamente en caso de que el mensajero encargado de realizar la compra no se

encuentre en la tabla maestra mensajeros de la base de datos, el concepto de la

compra y las casillas “Recibido por” y “Aprobado por” las cuales deben ser firmadas

por los agentes responsables una vez sea impreso el recibo.

Figura 25: Pantalla Generar Recibo


78

5.3.1.6 Control de Compras

Una vez se haya realizado una compra, el encargado de la caja chica deberá

cargar dicha compra con los detalles de la misma en la base de datos mediante el

módulo de Control de Compra, especificando el tipo de ítem que se compró, el

proveedor del ítem en caso de que el ítem que se compró no exista en la base de

datos, el concepto de la compra, el centro de costo, y la cantidad en bolívares.

Figura 26: Pantalla Cargar Compra


79

5.3.1.7 Compras

El encargado de la administración de la caja chica puede ver las compras que se

han realizado ingresando al módulo “Compras”, el cual muestra el número de la

compra, el proveedor, el ítem, el concepto, el centro de costo, la fecha en que se cargó

y el monto en bolívares. La consulta se puede filtrar por cantidad de registros y/o por

el mes. Así mismo, se muestra el total en bolívares de las compras que arroje la

consulta.

Figura 27: Pantalla Control de Compras


80

5.3.1.8 Reporte de Solicitudes

Todas las solicitudes que han sido cargadas en el sistema (aprobadas,

rechazadas y cargadas) se muestran en el módulo de “Reporte de Solicitudes”

mediante una tabla la cual se compone de los datos más relevantes de la solicitud,

tales como el número, el departamento, la fecha de carga, el solicitante y el estado de

la solicitud. Éstas se pueden ordenar, alfabéticamente por departamento, solicitante o

estado, así como también numéricamente por número de solicitud al igual que por

fecha en que fue cargada.

Figura 28: Pantalla Reporte de Solicitudes


81

5.3.1.9 Reporte Grafico

En el módulo “Reporte Grafico” se muestra un gráfico de barras de la cantidad

de solicitudes mensuales generadas, el cual se puede exportar tanto en formato

imagen como PDF.

Figura 29: Pantalla Reporte Grafico


82

5.3.1.10 Mantenimiento de Tablas

Para la administración de las tablas maestras el usuario encargado de esta tarea

puede realizarla accediendo al módulo “Mantenimiento de Tablas” el cual muestra las

tablas posibles para el mantenimiento de las mismas.

Figura 30: Pantalla Mantenimiento de Tablas


83

5.4 Fase IV: Pruebas

Para comprobar el funcionamiento de cada uno de los requerimientos del

sistema, se realizaron pruebas de caja negra en los principales módulos del sistema.

Los resultados obtenidos se muestran en los cuadros a continuación:

Cuadro 33. Prueba N° 1

Caso de prueba: Evaluación del módulo generar solicitud Fecha: 07/05/2014 Identificador: 1 Historia de Usuario: 1 Tipo de prueba:Validación Estrategia:caja negra Descripción:Generar una solicitud de requisición de compra por caja chica, se comprueba que los ingresados en el formulario concuerden con los almacenados en la base de datos. Entradas:Cantidad de ítems, tipo de ítem. Resultados esperados: La solicitud debe ser almacenada en la base de datos con la información ingresada por el usuario. Resultado: Exitoso Observaciones:



Caso de prueba: Evaluación del módulo detalle solicitud Fecha: 15/05/2014 Identificador: 2 Historia de Usuario: 2 Tipo de prueba: Validación Estrategia: caja negra Descripción: Ingresar al detalle de una solicitud cargada en el sistema Entradas:No aplica Resultados esperados: Se deben mostrar los detalles de la solicitud que coincidan con los almacenados en la base de datos. Resultado: Fallido Observaciones: No se mostraron los ítems de la solicitud


84

Cuadro 34.1. Prueba N° 2

Caso de prueba: Evaluación del módulo detalle solicitud Fecha: 15/05/2014 Identificador: 2 Historia de Usuario: 2 Tipo de prueba: Validación Estrategia: caja negra Descripción: Ingresar al detalle de una solicitud cargada en el sistema Entradas: No aplica Resultados esperados: Se deben mostrar los detalles de la solicitud que coincidan con los almacenados en la base de datos. Resultado: Exitoso Observaciones: Se corrigieron los errores del módulo



Caso de prueba: Evaluación del módulo tramitar solicitud Fecha: 21/05/2014 Identificador: 3 Historia de Usuario: 3 Tipo de prueba: Validación Estrategia: caja negra Descripción: Visualizar únicamente las solicitudes que se encuentran en estado cargadas en el sistema, pertenecientes al mismo departamento del agente actualmente con la sesión activa y proceder a rechazar una solicitud. Entradas: Motivo de rechazo Resultados esperados: Se deben mostrar las solicitudes cargadas en el sistema, posteriormente la solicitud seleccionada debe cambiar su estado actual en la base de datos a rechazada y se deben actualizar los datos de quien la rechazo, el motivo de rechazo, la fecha en que se tramitó/rechazó y el usuario responsable de esta acción. Resultado: Exitoso Observaciones:


85


Caso de prueba: Evaluación del módulo ejecutar solicitud Fecha: 27/05/2014 Identificador: 4 Historia de Usuario: 4 Tipo de prueba: Validación Estrategia: caja negra Descripción: Visualizar únicamente las solicitudes que se encuentran en estado aprobadas en el sistema ingresar a una de éstas e imprimirla. Entradas:No aplica Resultados esperados:Se deben mostrar las solicitudes aprobadas, luego se debe imprimir la solicitud seleccionada Resultado: Exitoso Observaciones:



Caso de prueba: Evaluación del módulo incluir compra Fecha: 04/06/2014 Identificador: 5 Historia de Usuario: 5 Tipo de prueba: Validación Estrategia: caja negra Descripción:Cargar una compra en el sistema y verificar que los datos ingresados por el usuario concuerden con los almacenados en la base de datos Entradas:Tipo de ítem, proveedor, concepto, centro de costo, monto de la compra. Resultados esperados: La compra debe ser almacenada en la base de datos con la información ingresada por el usuario en el formulario. Resultado: Exitoso Observaciones:


86


Caso de prueba: Evaluación del módulo generar recibo Fecha: 06/06/2014 Identificador: 6 Historia de Usuario: 6 Tipo de prueba: Validación Estrategia: caja negra Descripción:Generar un recibo de compra Entradas:Mensajero, monto del recibo, concepto. Resultados esperados:El recibo se almacena en la base de datos con la información ingresada por el usuario, posteriormente se abre una ventana emergente para que éste pueda ser impreso. Resultado: Exitoso Observaciones:



Caso de prueba: Evaluación del módulo administrar tablas maestras Fecha: 09/06/2014 Identificador: 7 Historia de Usuario: 7 Tipo de prueba: Validación Estrategia: caja negra Descripción: Modificar tabla maestra de ítems Entradas: Nombre del ítem, proveedor. Resultados esperados: Se guarda el ítem en la base de datos con la misma información ingresada por el usuario en el formulario. Resultado: Exitoso Observaciones:



Caso de prueba: Evaluación del módulo administración de privilegios Fecha: 12/06/2014 Identificador: 8 Historia de Usuario: 8 Tipo de prueba: Validación Estrategia: caja negra Descripción: Modificar privilegios de agentes Entradas:Nivel de privilegio, usuario agente. Resultados esperados:Se modifica el privilegio del agente Resultado: Exitoso Observaciones:


87

CONCLUSIONES

En todas las empresas se consideran como factores elementales la

automatización y el control en cualquier proceso que se lleve a cabo. En el transcurso

del proceso de pasantía realizadas en la empresa Smurfit Kappa Cartones de

Venezuela, S.A., se ha logrado cumplir de manera satisfactoria el objetivo principal

que fue desarrollar un software que lleve el control de requisición de compras por

caja chicaautomatizando el subproceso anteriormente existente en la empresa,

obteniendo los resultados apropiados que se esperaban con la realización de éste

proyecto.

A lo largo del desarrollo del proceso de investigación y construcción de este

proyecto,se logró cumplir con cada uno de los requisitos que el cliente y los usuarios

actores en el sistema requerían, en el tiempo establecido gracias a la metodología XP,

que fue aplicada para el desarrollo del sistema. La cual consistió en cuatro fases:

planificación, diseño, desarrollo y pruebas.

En la planificación del proyecto, se obtuvo una gran participación de los

usuarios actores del sistema, los cuales aportaron ideas, requisitos, criticas, opiniones

y sugerencias referentes al software, lo que ayudó al levantamiento de

requerimientos.

En la fase de diseño,se tomaron en cuenta las limitaciones implantadas por los

estándares de la empresa en el desarrollo de sus sistemas, sin embargó usando las

herramientas adecuadas, se logró un diseño simple, sencillo, intuitivo y agradable al

usuario en el producto final, adaptado a la metodología seleccionada para éste

proyecto.

Durante la fase de desarrollo, se cumplió con el objetivo de crear el sistema

web de requisición de compras por caja chica, ya que se obtuvo el producto final que

88

realizó exitosamente todas sus funciones en el ambiente de trabajo indicado por el

cliente.

Igualmente, se realizaron pruebas individuales del funcionamiento de cada

uno de los módulos del sistema mediante la aplicación de técnicas de pruebas de caja

negra, logrando detectar errores que no se manifestaron en la etapa de desarrollo,

teniendo que eliminar, modificar o agregar ciertas funcionalidades en el sistema, para

de esta manera lograr la completa satisfacción del cliente.

El resultado de éste proyecto es una aplicación que responde a las necesidades

de la automatización, soporte y control del sistema administrativo de gestión de

compras por caja chica alcanzando todos los objetivos planteados.

89

RECOMENDACIONES

Para el desempeño eficaz del sistema y en definitiva para la usabilidad del

mismo, se sugiere ubicar a un único agente encargado del área administrativa de las

solicitudes de requisiciones de compras por caja chica, para así lograr un mayor

control del flujo de datos generado.

El software está diseñado para ser escalable, por lo que se pueden

implementar nuevas funcionalidades con mayor facilidad, de manera tal que se

recomienda continuar con el desarrollo de módulos para una futura implantación del

mismo en las diferentes plantas de la empresa a nivel nacional para sacarle mayor

provecho a éste.

Se recomienda designar a un desarrollador web del departamento de

información para realizar un mantenimiento mensual a la base de datos del sistema

para llevar un control de los registros almacenados y optimizar el funcionamiento del

mismo.

90

REFERENCIAS

Bibliográficas

Arias, F. (1999): Bases Metodológicas de la Investigación Educativa. Barcelona:

Ceac.

Barrientos, A. (2002): Proceso metodológico de auditoría informática aplicado a

la evaluación y seguimiento de sistemas de gestión desarrollados con el

estándar de modelado UML, Universidad de Oriente La Habana Cuba –

Universidad Autónoma Tomás Frías, Tesis de Maestría en Ingeniería

Informática, Potosí-Bolivia.

Hernandez, C, C. Fernandez, P. Baptista. (2006): Metodología de la investigación.

Tercera Segunda Edición. Mexico: Mc Graw Hill.

IanSommerville (2005): Ingeniería del software. Editorial Pearson. Séptima

Edición.

Kendall, J., Kendall, K. (2005): Análisis y desarrollo de sistemas. Sexta Edición.

Mexico: Pearson Educación.

Villarroel, E. (2009): Desarrollo de un Sistema Administrativo para gestionar los

proyectos en la Coordinación de Investigación de la Universidad de

Oriente Núcleo de Monagas, Instituto Universitario Politécnico “Santiago

Mariño”, Trabajo Especial de Grado.

Electrónicas

Ángela Molano Castellanos (2008): Pruebas del Software “Caja blanca y Caja

negra”. Disponible: http://angelmolsoftware.blogspot.com/2008/11/pruebas-

del-software-caja-blanca-y-caja.html, Consulta: 2014, Febrero 9

91

Barrientos, A. (2005): El desarrollo de sistemas de información empleando el

lenguaje de modelo Unificado UML, Disponible: http://www.monografias.

com/trabajos16/lenguaje-modelado-unificado/lenguaje-modelado-

unificado.shtml#PRINCIP. Consulta: 2014, Enero 16

Curso de ASP. Disponible: http://www.aspya.com.ar/index.php?op=1. Consulta: 2014, Marzo 5.

Manuel Calero Solís (2003): Una explicación de la programación extrema (XP). Disponible: http://www.willydev.net/descargas/prev/ExplicaXP.pdf. Consulta: 2013, Diciembre 27.

Magín Rodríguez (2010): Tipos de Investigación. Disponible: http://metodologiamecanica.blogspot.com/2010/06/tipos-de-investigacion.html, Consulta: 2014, Febrero 26.

Población y Muestra (2006): La Población y Muestra. Disponible: http://msctecnologiaeducativa3.blogspot.com/p/poblacion-y-muestra_19.html [Consulta: 2014, Septiembre 27]

Vega, E. (2005): Los sistemas de información y su importancia para las organizaciones y las empresas. Documento en línea disponible: http://www.monografias.com/trabajos24/tics-empresas/tics-empresas.shtml. Consulta: 2013, Diciembre 29.

DESARROLLO DE UNA APLICACIÓN WEB PARA EL · PDF fileADMINISTRATIVO DE REQUISICION PARA...

Documents

Transcript of DESARROLLO DE UNA APLICACIÓN WEB PARA EL · PDF fileADMINISTRATIVO DE REQUISICION PARA...

Fundación Smurfit Cartón de Colombiafundacionsmurfitcartondecolombia.org/pdf/fundacion-smurfit-carton... · igualdad de libertades y de oportunidades. Ser líder en Responsabilidad

Ordenes de requisicion

Smurfit kappa cartón de Colombia S.A

REQUISICION DE MATERIALES - …recursosbiblio.url.edu.gt/publicjlg/biblio_sin_paredes/fac_ing/... · FORMATO REQUISICION MATERIALES Laboratorio Nombre de la Práctica N ... mismas

ACERCA DE SMURFIT KAPPA COLOMBIA 8³n... · En Smurfit Kappa Colombia somos líderes en el suministro de empaques y productos a base de papel, así como los mayores recicladores de

Copia de 7a Auditoria Smurfit 7b Evid No Cert

Informe Anual 2018 - Fundación Smurfit Kappa...Informe Anual 2018 – Fundación Smurfit Kappa Colombia 9 EDUCACIÓN En la Fundación Smurfit Kappa formamos niños, jóvenes y adultos

Documentación Inicial para Participantes, Observadores e ...20 Brigada Smurfit Kappa 1 Sector Privado 21 Brigada Smurfit Kappa 2 Sector Privado 22 Brigada Smurfit Kappa 3 Sector Privado

Nuestra Comunidad - Smurfit Kappa

TABLA DE CONTENIDO ARTÍCULO PÁGINA fileAdministrativo; Srta. Ingrid Molina Mora y Srta. Rebeca Sura Fonseca, Sector Estudiantil, y Dr. Rafael González Ballar, representante de la

APROXIMACIÓN AL VALOR DE SMURFIT KAPPA CARTÓN DE …

Orden de Compra y Requisicion de Compra

Procedimiento de LA DECLARACIÓN SUMARIA DE · PDF fileadministrativo (DUA). -4-Procedimiento: Declaración Sumaria de depósito temporal Diciembre de 2012 Versión: 2.0 Port de Barcelona

TERCER TRIMESTRE... · dechihuahuasur requisicion de pago 1 reembolso unidad organica solicitante: direccion academica persona solicitante. lic. fatima bae-za pago nombre sara martinez

Smurfit Carton de Colombia S.A.

Nombre: Área: SUMINISTROS REQUISICION DE … · REQUISICION DE SUMINISTROS ... Req. Incluir inventario Activo y Accesorios Reposición Elementos de Papelería Nombre y especificaciones

INSTITUTO POLITÉCNICO NACIONAL SECRETARÍA · PDF fileadministrativo y financiero ... Evaluará la función administrativa total o parcial de una empresa. HORAS No. ... (datos generales

Informe Financiero Anual 2013 Smurfit Kappa Colombia

L–TP–2.7 HORNOS DE PROCESO, REQUISICION, ANALISIS DE OFERTAS Y DETALLES DE COMPRA

Experiencias de Smurfit Cartón de Venezuela en el Comercio Internacional