universidad central del ecuador facultad de …€¦ · padres alejandro cárdenas y patricia lara...

UNIVERSIDAD CENTRAL DEL ECUADOR FACULTAD DE

INGENIERÍA, CIENCIAS FÍSICAS Y MATEMÁTICA

CARRERA DE INGENIERÍA INFORMÁTICA

Control de Existencias de Bodega para la Universidad Central Del Ecuador

Trabajo de Titulación Modalidad Proyecto Integrador, Previo a la

obtención del título de Ingeniero Informático

AUTORES: Luis Alejandro Cárdenas Lara

Alexis Paul Chalco Loya

TUTOR: MSc. Mauro Leonardo Rosas Lara

Quito, 2019

ii

DERECHOS DE AUTOR

Nosotros, Alexis Paul Chalco Loya y Luis Alejandro Cárdenas Lara, en calidad de autores y

titulares de los derechos morales y patrimoniales del trabajo de titulación del Control de

Existencias de Bodega para la Universidad Central del Ecuador modalidad proyecto integrador de

conformidad con el Art. 114 del CODIGO ORGANICO DE LA ECONOMIA SOCIAL DE LOS

CONOCIMIENTOS. CREATIVIDAD E INNOVACION, concedemos a favor de la Universidad

Central del Ecuador una licencia gratuita, intransferible y no exclusiva para el uso no comercial

de la obra, con fines estrictamente académicos. Conservamos a nuestro favor todos los derechos

de autores sobre la obra, establecidos en la normativa citada.

Así mismo, autorizamos a la Universidad Central del Ecuador para que realice la digitalización

y publicación de este trabajo de titulación en el repositorio virtual, de conformidad a lo dispuesto

en el Art. 144 de la Ley Orgánica de Educación Superior.

Los autores declaran que la obra objeto de la presente autorización es original en su forma de

expresión y no infringe el derecho de autor de terceros asumiendo la responsabilidad por cualquier

reclamación que pudiera presentarse por esta causa y liberando a la Universidad Central del

Ecuador de toda responsabilidad.

________________ __________________

Alexis Paul Chalco Loya Luis Alejandro Cárdenas Lara

C.C. 1720537099 C.C. 172634978

[email protected] [email protected]

iii

APROBACION DEL TUTOR

En mi calidad de Tutor del Trabajo de Titulación, presentado por ALEXIS PAUL CHALCO

LOYA Y LUIS ALEJANDRO CÁRDENAS LARA, para optar por el grado de Ingeniero en

Informática; cuyo título es: CONTROL DE EXISTENCIAS DE BODEGA PARA LA

UNIVERSIDAD CENTRAL DEL ECUADOR, considero que dicho trabajo reúne los requisitos

y méritos suficientes para ser sometidos a la presentación pública y evaluación por parte del

tribunal examinador que se designe.

En la ciudad de Quito, a los 17 días del mes de Julio de 2019

_________________________

MSc. Mauro Leonardo Rosas Lara

DOCENTE-TUTOR

C.C. 1711642965

iv

DEDICATORIA

El presente proyecto de graduación se lo dedicado a quienes me han apoyado

incondicionalmente durante la duración de la carrera. A mis adorables y grandiosos

padres Alejandro Cárdenas y Patricia Lara por el apoyo por estar siempre conmigo

por tener fe en mis capacidades, A mi hermana María José porque cada que lo

necesite me dio su apoyo y aliento oportunamente. Y sobre todo a Dios por darme

salud a mí, y a mis padres porque sin cada uno de ellos no hubiera alcanzado mi

objetivo y darme vida para poder cumplir con este logro.

Luis Cárdenas.

v

El presente trabajo de titulación se lo dedico a mis padres que siempre han estado

acompañándome en toda la carrera, inculcándome buenos hábitos de perseverancia y

dedicación, que fueron de gran motivación para poder culminar con la carrera. A

mis hermanos que siempre han estado junto cuando más los he necesitado, a mi

querida novia guiándome por un buen camino para poder ser una buena persona y

excelente profesional. Y sobre todo doy gracias a Dios por darme las fuerzas para

continuar y lograr mi objetivo, mi familia que este logro es grac ias a todo el

esfuerzo que cada uno aporto para poder cumplir con este logro.

Alexis Paul Chalco Loya.

vi

AGRADECIMIENTO

Agradezco primeramente a Dios por sus bendiciones por darme fortaleza y

sabiduría para terminar mi carrera universitaria con éxi to.

A mis padres porque sin su apoyo incondicional y confianza no hubiera alcanzado

esta meta. A mi hermana María José por siempre apoyarme y ser la gran y valiosa

persona que es.

A todos mis familiares en general por creer en mí. A mis amigos y compañeros de

universidad por su sincera amistad y ayudarme cuando los necesite.

A mi tutor Ing. Mauro Rosas por su disposición ayuda y tiempo que nos brindó

para iniciar y terminar exitosamente el presente trabajo.

Luis Cárdenas.

vii

Agradezco a Dios por todas sus lecciones en el día a día y sobre todo por las

bendiciones y actitud necesaria para poder culminar mi carrera universitaria con

éxito.

A mis padres que son un pilar muy fundamental de mi vida y con ellos soy una

mejor persona y conformamos una familia muy unidad. A mi novia y a mi hija que a

través de ellas me han dado la fortaleza para poder ser una gran persona.

A todos mis familiares por la confianza que me han tenido. A mis amigos que

fueron una segunda familia que tuve en la universidad apoyándome en momentos que

más necesitaba.

A mi tutor Ing. Mauro Rosas por la ayuda proporcionada que nos brindó para

iniciar y terminar exitosamente el presente trabajo.


viii

CONTENIDO

DERECHOS DE AUTOR ....................................................................................................... ii

APROBACION DEL TUTOR ............................................................................................... iii

DEDICATORIA ...................................................................................................................... iv

AGRADECIMIENTO ............................................................................................................ vi

CONTENIDO ........................................................................................................................ viii

LISTA DE TABLAS .............................................................................................................. xii

LISTA DE ILUSTRACIONES ............................................................................................. xv

RESUMEN ............................................................................................................................. xvi

ABSTRACT .......................................................................................................................... xvii

1. INTRODUCCION ........................................................................................................ 1

1.1. Antecedentes ................................................................................................................. 1

1.2. Planteamiento del Problema ......................................................................................... 2

1.3. Justificación .................................................................................................................. 3

1.4. Objetivos ....................................................................................................................... 4

1.4.1. Objetivo General. .................................................................................................. 4

1.4.2. Objetivos Específicos. ........................................................................................... 4

1.5. Alcance ......................................................................................................................... 5

1.6. Limitaciones ................................................................................................................. 5

ix

1.7. Análisis de herramientas ............................................................................................... 6

2. MARCO TEORICO ..................................................................................................... 7

2.1. Metodologías............................................................................................................. 7

2.1.1. Metodología de Investigación ............................................................................... 7

2.1.2. Metodología de Desarrollo ....................................................................................... 9

2.1.2.1. Análisis Comparativo de las Metodologías. .................................................... 10

2.1.2.2. Proceso XP. ..................................................................................................... 11

2.1.2.3. Programación Extrema XP. ............................................................................. 12

2.1.2.4. Fases de la Metodología XP. ........................................................................... 13

2.1.2.5. Valores de la Programación Extrema. ............................................................. 15

2.1.3. Metodología para Bienes de Control Administrativo ............................................. 17

2.1.3.1. Bienes Sujetos a Control Administrativo. ....................................................... 17

3. DESARROLLO .......................................................................................................... 22

3.1. Metodología de programación .................................................................................... 22

Exploración de Información. ...................................................................................... 22

Planificación. .............................................................................................................. 23

x

Iteración. ..................................................................................................................... 23

Producción. ................................................................................................................. 23

3.2. Identificación del Proceso de Control de Existencia de Bodega ............................ 24

3.3. Identificación de Roles en el Sistema. .................................................................... 28

3.4. Análisis del Diseño. ................................................................................................ 29

3.4.1. Modelo Entidad Relación. ...................................................................................... 33

3.5. Análisis de Requerimientos .................................................................................... 34

3.5. Historia de Usuarios. ............................................................................................... 36

3.6. Modelo de Casos de Uso......................................................................................... 44

3.7. Diagrama General de Secuencia del Sistema ............................................................. 55

3.8. Metodología para el Control de Bienes no Sujetos a Control .................................... 56

4. PRUEBAS, CONCLUSIONES Y RECOMENDACIONES ..................................... 58

4.4. Pruebas. ................................................................................................................... 58

4.2. Conclusiones ........................................................................................................... 87

4.2. Recomendaciones ................................................................................................... 88

BIBLIOGRAFÍA .................................................................................................................... 89

xi

ANEXOS ................................................................................................................................. 91

DICCIONARIO DE LA BASE DE DATOS ....................................................................... 92

DESCRIPCIÓN DE LAS TABLAS Y SUS ATRIBUTOS. ................................................ 92

xii

LISTA DE TABLAS

Tabla 1 Herramientas de desarrollo ........................................................................................... 6

Tabla 2 Método de Investigación ............................................................................................... 8

Tabla 3 Comparacion de Metodologias Agiles Propuestas. ..................................................... 10

Tabla 4 Plantilla de historias de usuario .................................................................................. 14

Tabla 5 Identificación de roles en el sistema ........................................................................... 28

Tabla 6 Nombre de la base de datos ......................................................................................... 29

Tabla 7 Abreviaturas de tablas ................................................................................................. 30

Tabla 8 Requerimiento funcionales ......................................................................................... 35

Tabla 9 Nombres Historias de Usuarios ................................................................................... 36

Tabla 10 Historia de Usuario Ingreso al Sistema ..................................................................... 37

Tabla 11 Historia de Usuario Administrar Usuarios ................................................................ 38

Tabla 12 Historia de Usuario Ingresar Insumos ....................................................................... 39

Tabla 13 Historia de Usuario Egresar Insumos ........................................................................ 40

Tabla 14 Historia de Usuario Pedidos ...................................................................................... 41

Tabla 15 Historia Transferir Insumos ...................................................................................... 42

xiii

Tabla 16 Historia de Reportes .................................................................................................. 43

Tabla 17 Historia de Alarmas .................................................................................................. 44

Tabla 18 Caso de Uso Inicio de Sesión .................................................................................... 45

Tabla 19 Caso de Uso Administración de Usuarios ................................................................. 46

Tabla 20 Caso de Uso Pedidos ................................................................................................. 47

Tabla 21 Caso de Uso Ingresos ................................................................................................ 49

Tabla 22 Caso de Uso Egresos ................................................................................................. 50

Tabla 23 Caso de Uso Reportes ............................................................................................... 52

Tabla 24 Caso de uso transferencias ........................................................................................ 53

Tabla 25 Catálogo de Bienes no Depreciables ......................................................................... 56

Tabla 26 Resultados Pruebas de Interfaz ................................................................................. 58

Tabla 27 Calificación de métricas de navegadores .................................................................. 59

Tabla 28 Resultados Obtenidos de las métricas de navegadores ............................................. 59

Tabla 29 Prueba de caja negra al módulo de creación de usuarios .......................................... 61

Tabla 30 Prueba de caja negra al módulo de asignación de cargos ......................................... 62

Tabla 31 Prueba de caja negra al módulo de creación de SubBodega ..................................... 64

xiv

Tabla 32 Prueba de caja negra al módulo de creación de catálogos ........................................ 65

Tabla 33 Prueba de caja negra al módulo de creación de proveedores .................................... 66

Tabla 34 Prueba de caja negra al módulo de creación de áreas ............................................... 68

Tabla 35 Prueba de caja negra al módulo de Ingresos ............................................................. 69

Tabla 36 Prueba de caja negra al módulo de pedidos .............................................................. 73

Tabla 37 Prueba de caja negra al módulo de egresos ............................................................... 75

Tabla 38 Prueba de caja negra al módulo abastecer bodega .................................................... 77

Tabla 39 Herramientas de pruebas de stress ............................................................................ 82

Tabla 40 Descripción de campos JMeter ................................................................................. 85

xv

LISTA DE ILUSTRACIONES

Ilustración 1: Proceso XP (Cevallos, 2015) [3] ....................................................................... 12

Ilustración 2: Ciclos Iterativos comparados con XP [3] .......................................................... 13

Ilustración 3: Diagrama del Proceso de Control de Existencia de Bodega. ............................. 25

Ilustración 4: Diagrama Modelo Entidad Relación. ................................................................. 33

Ilustración 5: Diagrama de Secuencia del Control Existencias de Bodega ............................ 55

Ilustración 6: Pantalla de configuración JMeter ....................................................................... 83

Ilustración 7: Resumen de reporte de pruebas ......................................................................... 84

Ilustración 8: Gráfica de resultados JMeter. ............................................................................ 86

xvi

TITULO: Control de Existencias de Bodega para la Universidad Central del Ecuador.

AUTORES: Luis Alejandro Cárdenas Lara


TUTOR: MSc. Mauro Leonardo Rosas Lara

RESUMEN

El presente proyecto tiene como objetivo desarrollar una aplicación web que permita mejorar

el almacenamiento, recepción y despacho de activos no depreciables en la Universidad Central del

Ecuador. La cual no contaba con un sistema centralizado para toda esta información, esto permitirá

a los usuarios finales hacer pedidos, despachar y generar informes según los roles que tengan

asignados, por lo cual fue desarrollado con la metodología ágil XP que se enfoca en el desarrollo

de este tipo de aplicaciones. La arquitectura es multiusuario y de fácil administración, para

asegurar el mayor porcentaje de disponibilidad del sistema en cualquier circunstancia.

Implementando en una base de datos en ORACLE y ejecutando en servidor de aplicaciones

wildfly. Todos estos requerimientos fueron establecidos por La Dirección de Tecnologías de la

Información y Telecomunicaciones (DTIC) de la Universidad Central del Ecuador.

PALABRAS CLAVE: APLICACIÓN WEB UCE / METODOLOGIA AGIL/ MANEJO DE

ROLES / JAVA / SERVIDOR DE APLICACIONES WILDFLY

xvii

TITLE: Control of Existences of Bodega for the Central University of Ecuador.

Author: Luis Alejandro Cárdenas Lara


Tutor: MSc. Mauro Leonardo Rosas Lara

ABSTRACT

The objective of this project is to develop a web application that allows improving the storage,

reception and dispatch of non-depreciable assets at the Central University of Ecuador. Which did

not have a single centralized system for all this information, the system will allow end users to

order, dispatch and generate reports according to the roles assigned to them, for which it was

developed with the agile XP methodology that is focuses on the development of this type of

applications. The architecture is multiuser, centralized and easy to manage, to ensure the highest

percentage of system availability in any circumstance. The ORACLE database engine was

installed with version 12c, wildfly application server. All these requirements were established by

the Directorate of Information Technology and Telecommunications (DTIC) of the Central

University of Ecuador.

KEYWORDS: UCE WEB APPLICATION / AGIL METHODOLOGY / ROLL

MANAGEMENT / JAVA / WILDFLY APPLICATION SERVER

1

1. INTRODUCCION

1.1. Antecedentes

En nuestro país la labor de fiscalización, del uso adecuado de los recursos del Estado,

consecución de los objetivos institucionales, administración, custodia de los bienes, verificación

del cumplimiento de la misión y visión de las entidades públicas está a cargo de la Contraloría

General del Estado. Institución que a fin de regular el proceso antes descrito, en el uso de sus

facultades, emite mediante Acuerdos Institucionales, normativa que permita regular el citado

proceso.

Para lo cual las instituciones que conforman el Presupuesto General del Estado acorde a las

directrices emitidas por la Secretaria Nacional de Planificación y Desarrollo y los lineamientos del

Ministerio de Economía y Finanzas Publicas.

Órgano rector que elabora sus planes operativos anuales y definen los presupuestos

institucionales que requieren para dar cumplimientos a sus objetivos, dentro de los cuales se

contempla la adquisición de bienes y/o existencias.

Tal es el caso de la Universidad Central del Ecuador que acorde a los objetivos generales y

específicos del alma mater y de cada una de sus facultades, contemplan dentro de su Planificación

Operativa Anual y Plan Anual de Compras, la adquisición de estos bienes y existencias a través de

los procesos de contratación establecidos por el Servicio de Contratación Pública.

Con la finalidad de contribuir al desarrollo de sus actividades y aportar al cumplimiento de los

objetivos institucionales.

2

El control del uso de los bienes no depreciables de propiedad de las facultades y de las unidades

administrativas de la Universidad Central del Ecuador, a través del tiempo no ha sido el más

óptimo, por cuanto no se ha dispuesto de un sistema informático único que contribuya a mantener

un registro interno actualizado de sus compras y el destino de las mismas.

En este sentido, los guardalmacenes y responsables de las unidades administrativas han optado

por utilizar herramientas informáticas para efectuar el respectivo control.

Sin embargo, este tipo de aplicaciones es susceptible de manipulación, lo que no garantiza el

registro y seguimiento oportuno del uso de lo registrado. Por estas razones, la finalidad de este

proyecto es optimizar las tareas realizadas por los encargados de cada bodega, a través del

establecimiento de un control independientemente de la información de sus activos.

1.2. Planteamiento del Problema

En la Universidad Central del Ecuador, el plan anual de compras es realizado mediante los

ingresos y egresos generados anualmente. De esta manera, la institución puede solicitar la

asignación del nuevo presupuesto al Ministerio de Finanzas, para el siguiente año.

Sin embargo, muchas de las bodegas encargadas de llevar acabo esta actividad no tienen un

sistema confiable y la falta de información global, actualizada y detallada es evidente.

En la actualidad, existen varias herramientas informáticas que permiten almacenar información

del manejo de ingresos y egresos. Pero la Universidad al regirse a órganos de control son los que

deciden si asignan el presupuesto necesario para poder realizar la compra.

3

Es por ello que mediante estudio de campo y recolección de información, se ha optado por el

desarrollo e implementación de un sistema apropiado para el manejo de activos en cada unidad

administrativa y facultades de la Universidad Central del Ecuador.

Dada la necesidad de mejorar lo antes mencionado se realizó una investigación con los

encargados de esta actividad en la universidad, recopilando información de los problemas que se

tiene actualmente.

De lo dicho, el presente proyecto:

Pretende determinar y analizar los diferentes tipos de recolección de información de activos,

tomando en cuenta que solamente se considerará los bienes no depreciables, con el uso de un

sistema de control de inventario.

Centralizando la información que genere el manejo de este tipo de insumos, proporcionando

reportes mensuales y anuales que son necesarios para el control operativo y administrativo.

1.3. Justificación

A lo largo de muchos años, el gobierno ecuatoriano debe cuidar los recursos que asigna a cada

entidad pública, por lo tanto opta por controles regulatorios por parte de la Contraloría General del

Estado. Es por ello que la asignación de presupuesto a universidades públicas lo realiza mediante

el ejercicio fiscal realizado anualmente que establece la proforma para el siguiente periodo,

permitiéndoles a las universidades ser autónomas y encargarse de la distribución adecuada para

cada una de sus unidades administrativas.

4

Por lo antes mencionado, este presente proyecto se enfoca en el estudio y análisis de viabilidad

con los encargados del manejo de presupuesto y control de los bienes, para posteriormente llevar

a cabo su desarrollo e implementación en la Universidad Central del Ecuador.

Debido a que la mayor parte de las facultades y unidades administrativas registran diferentes

tipos de insumos, disponibilidades, rango de precios, caducidad, de acuerdo a los bienes

considerados como activos no depreciables.

Esto permitirá automatizar procedimientos y centralizar información en un sistema informático

para todas sus dependencias, mostrando características que se deben incluir al momento de realizar

pedidos, ingresos o egresos de insumos a través de los encargados, llevando una buena práctica de

usuario y estandarización de la información.

1.4. Objetivos

1.4.1. Objetivo General.

Mejorar el control de registros de insumos no depreciables en todas las facultades y unidades

administrativas de la Universidad Central del Ecuador a través de la implementación de un sistema

que permita automatizar los procesos y llevar de manera organizada la información.

1.4.2. Objetivos Específicos.

Identificar y mejorar cada uno de los procesos que se realice como el registro, seguimiento

y control de los insumos asignados por la Universidad.

Elaborar un sistema que centralice toda la información y permita a todas las bodegas de la

universidad llevar un control adecuado de los bienes no depreciables a su cargo.

5

Generar reportes con información de costos, egresos e ingresos de insumos no depreciables

que tenga a disposición cada facultad y unidad de la universidad para mejorar la toma de

decisiones.

1.5. Alcance

Con la finalidad de facilitar el control de las bodegas y unidades administrativas de la

Universidad, este proyecto permite la generación de los siguientes reportes: cantidad ingresada,

cantidad egresada, cantidad restante en inventario, valor económico, fechas, responsables, cuentas

contables que manejan cada bodega y áreas asignadas.

Consta con alertas para poder tener un control sobre la cantidad de stock en existencia para

poder tomar medidas anticipadas en las compras requeridas y de esta manera poder tener reservas

hasta que se autorice llevar a cabo nuevas adquisiciones. El acceso al sistema será mediante

credenciales usuario y contraseña.

1.6. Limitaciones

El sistema no dispondrá de ningún módulo de generación de facturas.

Este proyecto no tiene vinculación con otros sistemas de la universidad.

El sistema no cuenta con un módulo de compras.

No se realizará migración de información al nuevo sistema.

El sistema no contará con un módulo de respaldo de información.

6

1.7. Análisis de herramientas

En este apartado mencionamos las herramientas utilizadas y los estándares de programación

para el desarrollo del proyecto, tomando en cuenta que estos son establecidos por la Unidad de

Dirección de Tecnologías de la Información y Telecomunicaciones (DTIC) de la Universidad

Central del Ecuador, ya que el sistema será implementado en sus servidores.

A continuación mencionaremos las herramientas utilizadas en el desarrollo del proyecto y que

proporcionamos en la Tabla 1:

Tabla 1

Herramientas de desarrollo

HERRAMIENTA DESCRIPCION

Servidor Web Wildfly versión 10.0

Gestor de Base de Datos Oracle versión 12c

Entorno de desarrollo (IDE) Eclipse versión 4.11

Framework para la Interfaz Grafica Primefaces versión 7.0.x

Lenguaje de Programación Java 8

Reporte JasperReports v6.8.0

7

2. MARCO TEORICO

2.1. Metodologías.

2.1.1. Metodología de Investigación

Este punto trata de la investigación utilizada para el estudio del proyecto, enfocadas en cada

una de las tareas con las cuales se trabajó, encontraremos un modelo metodológico que sirve de

guía para el cumplimiento de los objetivos planteados, recopilando información para encauzar el

estudio con características tomadas en cuenta para la realización del mismo.

Selección y elección de los participantes en el proceso de estudio

La selección y elección de los participantes para determinar el campo de estudio de este

proyecto, fue realizada con anterioridad por parte de la unidad de Dirección de Tecnología de la

Universidad Central del Ecuador, los cuales nos proporcionaron el acceso a cada una de las

bodegas con mayor dificultad en el manejo de bienes no depreciables las cuales se muestran el en

Anexo A.

Realización del trabajo de campo y etapa de recopilación de la información

Para poder realizar el estudio de campo es necesario haber definido de manera correcta los

participantes mencionados anteriormente, ya que son la base para poder continuar con el desarrollo

del proyecto y poder elegir una metodología que brinde las herramientas necesarias.

Las metodologías de investigación que existentes en la actualidad nos proveen una serie de

conceptos, principios y normas que permite avanzar de modo eficiente en el estudio de campo en

las bodegas y unidades administrativas de la universidad, es por ello que de todos los métodos en

8

base a nuestra teoría, elegimos el método inductivo ya que es el que más se acopla a nuestras

necesidades explicado en la siguiente tabla a continuación:

Tabla 2

Método de Investigación

Método Inductivo

Definición

Es una forma de razonar partiendo de una serie de observaciones

particulares que permiten la producción de leyes y conclusiones

generales.

Características

1. Se basa en la observación de hechos y fenómenos.

2. Generaliza a partir de sus observaciones.

3. Sus conclusiones son probables.

4. Tiene el objetivo de generar nuevo conocimiento.

Etapas

Observación

Análisis

Derivación

Contrastación

Dirección del

razonamiento De lo particular a lo general.

Áreas del

conocimiento

Era el método utilizado en las ciencias experimentales. En la

actualidad es usado como parte del método científico en general.

[4] (Ever, 2018)

9

A partir de la Tabla 2 y con la recolección de información, se pudo construir el conocimiento

imprescindible contrastado mediante las necesidades percibidas en las bodegas y unidades

administrativas de la universidad, haciendo uso del razonamiento inductivo que proporciona

mayor análisis de interpretación de datos particulares que permitirán llegar a casos generales.

Con el análisis que nos brindó este método, generamos soluciones a la problemática,

profundizando en las siguientes etapas:

La observación: permite la descripción y registro de requerimientos funcionales que se

requieran para cubrir la necesidad de mejorar el control de la información de activos

custodiados por los encargados de cada dependencia.

El análisis: comprueba e indaga las características de los requerimientos observados que

cumplen las necesidades del control de activos.

La derivación: aspectos comunes de las necesidades del control de activos para llegar a

otros procesos similares.

En la contrastación: se tiene las funcionalidades que deben cumplir los requerimientos para

satisfacer necesidades a todas las bodegas y unidades administrativas existentes,

comprobando el funcionamiento del método inductivo.

De lo antes mencionado y con la aplicación del método inductivo en sus diferentes etapas se

derivó que los problemas generados al tener un control manual o un sistema independiente de

bodega defectuoso, se mejorarían al implementar un sistema centralizado en la unidad de Dirección

de Tecnologías de la Información y Telecomunicaciones (DTIC).

2.1.2. Metodología de Desarrollo

Una metodología de desarrollo “Es un conjunto integrado de técnicas y métodos que permite

abordar de forma abierta cada una de las actividades del ciclo de vida de un proyecto de desarrollo.

Es decir, una metodología establece un camino para desarrollar software de manera sistemática,

proporcionando un estándar de trabajo a la organización. Una definición estándar de metodología

10

puede ser el conjunto de métodos que se utilizan en una determinada actividad con el fin de

formalizarla y optimizarla. Determina los pasos a seguir y cómo realizarlos para finalizar una

tarea” [8] (Pressman, 2002).

2.1.2.1. Análisis Comparativo de las Metodologías.

A continuación realizamos el análisis cuantitativo de las metodologías XP, RUP y Scrum en

base a los siguientes parámetros mostrados en la Tabla 3 [7] (Letelier, 2006), Donde los valores

más altos representan una mayor agilidad.

Tabla 3

Comparacion de Metodologias Agiles Propuestas.

PARAMETROS XP SCRUM RUP

Sistema como algo

cambiante.

10 10 10

Colaboración. 10 10 10

Resultados. 10 10 10

Simplicidad. 10 10 10

Adaptabilidad. 8 9 8

Excelencia técnica. 9 8 9

Prácticas de

colaboración.

10 8 9

TOTAL 67 65 66

11

Con los resultados obtenidos en la Tabla 3, de las calificaciones asignadas a las metodologías

ágiles de desarrollo que más se ajustaban a las necesidades de este proyecto, elegimos la

metodología XP, por las siguientes características:

El usuario es indispensable para la retroalimentación continua del equipo de desarrollo.

La metodología proporciona simplicidad para entender el código y los procesos definidos

en cada fase de desarrollo.

Define roles asociados a cada integrante del proyecto en curso.

2.1.2.2. Proceso XP.

La programación extrema usa un enfoque orientado a objetos como paradigma preferido de

desarrollo, y engloba un conjunto de reglas y prácticas que ocurren en el contexto de cuatro

actividades estructurales: planeación, diseño, codificación y pruebas.

Estas actividades son las mismas que usan métodos tradicionales, pero la ejecución de cada una

estas son diferentes por ser métodos agiles, que pretende hacer ejecuciones rápidas y con la menor

cantidad de errores posibles.

12

Ilustración 1: Proceso XP (Cevallos, 2015) [3]

2.1.2.3. Programación Extrema XP.

La programación extrema (XP) es una metodología ágil para el desarrollo de un sistema o

software, su principal objetivo es dar más productividad estableciendo prioridades a tareas que dan

un resultado directo, basada en la simplicidad, comunicación y realimentación de código

desarrollado.

Entre los objetivos principales de esta metodología además de entregar un sistema de calidad

controlado por las necesidades del usuario están: la satisfacción del cliente, potenciar el trabajo en

grupo, minimizar el riesgo analizando el costo, tiempo, calidad y alcance del proyecto a desarrollar.

El ciclo de vida de un proyecto XP incluye los principios básicos que tienen otras metodologías

como: entender las necesidades del cliente, estimación de tiempo, costo y esfuerzo, crear el

producto, realizar pruebas y entregar el producto al cliente.

Pero a diferencia de metodologías tradicionales, XP propone un ciclo de vida dinámico, donde

en principio no se puede recolectar todas las necesidades del cliente, por esta razón se opta por

13

realizar ciclos de vida cortos (llamadas iteraciones). Esto permite realizar entregables funcionales

al terminar cada etapa del proyecto. Como se muestra en la

Ilustración 1: Proceso XP (Cevallos, 2015), por cada iteración se hace un ciclo de análisis,

diseño, desarrollo y pruebas pero utilizando un conjunto de reglas y prácticas.

Ilustración 2: Ciclos Iterativos comparados con XP [3]

2.1.2.4. Fases de la Metodología XP.

2.1.2.4.1. Fase de Exploración.

En esta fase se define el alcance del proyecto, básicamente lo que se realiza es una redacción

sencilla de las necesidades del cliente, también conocidas como “historias de usuario”.

Las historias de usuario son una representación superficial del comportamiento del sistema, en

el cual se plantea un escenario semejante al proyecto final. Cada narración debe ser lo

suficientemente comprensible y delimitada para que los programadores puedan implementarlas y

posteriormente diseñarlas. Como punto principal estos relatos sirven para poder estimar un tiempo

14

y plan de ejecución de cada módulo del sistema, además que esto permite reemplazar los

documentos de aceptación para cada prueba utilizando modelos de redacción como se muestra en

la Tabla 4.

Tabla 4

Plantilla de historias de usuario

Historias de Usuario

Número: Permite identificar a una historia de

usuario.

Usuario: Persona que utilizará la

funcionalidad del sistema descrita en la

historia de usuario.

Nombre Historia: Describe de manera general a una historia de usuario.

Prioridad en Negocio: Grado de importancia

que el cliente asigna a una historia de usuario.

Riesgo en Desarrollo: Valor de complejidad

que una historia de usuario representa al

equipo de desarrollo.

Puntos Estimados: Número de semanas que

se necesitará para el desarrollo de una historia

de usuario.

Iteración Asignada: Número de iteración, en

que el cliente desea que se implemente una

historia de usuario.

Programador Responsable: Persona encargada de programar cada historia de usuario.

Descripción: Información detallada de una historia de usuario.

15

Observaciones: Campo opcional utilizado para aclarar, si es necesario, el requerimiento

descrito de una historia de usuario.

Fase de Planificación.

En esta fase lo principal que se debe hacer es planificar cada entrega al cliente y mostrar una

nueva versión.

Es aconsejable que se hagan entregas frecuentes para poder tener control, en caso de aparecer

errores, mitigándolos de manera rápida evitando que se propaguen a más módulos del sistema.

Fase de Iteración.

En esta es la fase con más relevancia en la metodología XP, ya que se desarrolla la funcionalidad

del sistema con el propósito de generar entregables funcionales, las cuales implementan las

historias de usuario recolectadas en la fase de exploración.

Fase de Puesta en Producción

Teniendo en cuenta que en cada iteración se entregan módulos funcionales y sin errores, es

recomendable no implementar el sistema hasta que se haya incorporado todos los módulos en su

totalidad, es decir el sistema con su funcionalidad completa. Esto se debe a que el cliente no estará

completamente satisfecho hasta no tener el producto final.

2.1.2.5. Valores de la Programación Extrema.

Para poder realizar el proceso de desarrollo mencionado en las fases de metodología, se debe

tener una serie de valores y principios para poder lograr su objetivo.

16

Estos valores deben estar presentes en el equipo de desarrollo, clientes y líder de proyecto para

poder tener éxito.

En este apartado se mencionarán los cuatro valores asociados a la metodología XP:

Comunicación.

Se debe tener una comunicación entre el equipo de desarrollo y el cliente, para poder satisfacer

las necesidades de estos y se puedan realizar cambios a medida que avanza el proyecto. La

comunicación debe ser permanente entre desarrollador y cliente ya que la mayoría de los

problemas en muchos proyectos se deben a la falta de comprensión de las necesidades de los

usuarios y esto conlleva a la incertidumbre y a tener un producto que no cumpla con los requisitos

funcionales.

Simplicidad.

La simplicidad es un punto fuerte en la metodología XP, ya que se pretende es que todos puedan

entender el código y los procesos.

Retroalimentación.

La retroalimentación debe estar presente de manera permanente en todo el ciclo de vida del

proyecto, ya que de cada etapa se va tomando aspectos fundamentales para la siguiente etapa y así

consecutivamente.

Coraje

Esta parte se dada por el desarrollador en el momento en que se encuentre en serios problemas

ya sea en desarrollo o diseño del sistema y se deba eliminar completamente algún modulo sin

17

importar cuanto tiempo se haya tardado, así que la persona encargada debe tener el coraje

suficiente para poder hacer los cambios necesarios y lograr resultados óptimos.

2.1.3. Metodología para Bienes de Control Administrativo

En esta sección se detalla la metodología utilizada por las entidades públicas para poder llevar

un seguimiento de los bienes de control administrativo también conocidos como activos no

depreciables. Es decir; las entidades públicas como la Universidad Central del Ecuador tiene un

control regulatorio por parte la Contraloría General del Estado Ecuatoriano (Acuerdo No.

041,2018), entidad que proporciona las normativas mediante decretos constitucionales.

2.1.3.1. Bienes Sujetos a Control Administrativo.

Los bienes sujetos a control administrativo son aquellos que, por naturaleza, al ser utilizados

por la entidad pública no sufren perdida o depreciación en su valor económico.

Según el Acuerdo de la Contraloría General del Estado 41 No. 041-CG-2017, articulo 28 nos

dice que:

“Son bienes no consumibles de propiedad de la entidad u organismo, tendrán una vida útil

superior a un año y serán utilizados en las actividades de la entidad. La clasificación de los bienes

se realizará de acuerdo a la funcionalidad dependiendo de la naturaleza y misión institucional."

Los bienes sujetos a control administrativo deben ser custodiados por una o varias personas,

encargadas de la administración, registro, control y cuidado de los bienes en cada entidad, los

cuales se detallan a continuación:

18

Guardalmacén o Administradora o Administrador de Bienes: persona responsable

administrativo del control en la inspección, recepción, registro, custodia, distribución,

conservación y baja de los bienes.

El guardalmacén usualmente es una persona del área administrativa encargada de la bodega

central de la entidad pública y lleva los procesos necesarios para poder tener control de su

inventario.

Usuario Final o Custodio responsable: persona responsable del cuidado, buen uso, custodia

y conservación de los bienes e inventarios a él asignados para el desempeño de sus funciones y los

que por delegación expresa se agreguen a su cuidado, conforme a las disposiciones legales y

reglamentarias correspondientes.

Custodio Administrativo: el guardalmacén general podrá tener custodios que faciliten el

cuidado y el control de los bienes. Es decir; puede haber sub-bodegas asociadas a la bodega general

y estas tendrán las mismas responsabilidades que el guardalmacén general.

Manteniendo los inventarios actualizados de sus ingresos, egresos, dependiendo de la necesidad

de los usuarios finales.

Además, se debe tomar en consideración que las bodegas o sub-bodegas cumplirán con normas

de seguridad para que los bienes se conserven un lugar seguro y adecuado.

Responsabilidades del Guardalmacén.

19

Además de cuidado y control tareas generales asignadas al guardalmacén, este debe cumplir

con ciertas disposiciones emitidas en el Acuerdo de la Contraloría General del Estado 17 No. 017-

CG-2016, las cuales enunciaremos a continuación:

a) Debe existir una constatación física del proveedor al guardalmacén para controlar,

registrar y custodiar los bienes entregados.

b) La entrega de bienes se debe realizar mediante un acta de entrega al usuario final, donde

constara las condiciones y características de los bienes entregados.

c) El usuario final será el responsable del cuidado, administración de los bienes entregados

a su cuidado.

d) Es responsabilidad del guardalmacén entregar sus inventarios a cada unidad

administrativa.

e) El guardalmacén junto a su equipo de trabajo puede generar reportes internos para poder

tener más control sobre sus inventarios, en donde indique el área, responsable, producto

que se haya entregado.

Baja administrativa de activos no depreciables

Se debe tomar en consideración que el daño, pérdida, destrucción del bien administrativo, una

vez entregado, será responsabilidad del usuario final o persona asignada a su cargo, reponiendo en

bien asignado con características similares o superiores, el mal uso deberá ser comprobado por la

autoridad competente.

20

La baja de un reactivo químico se debe hacer mediante un escrito detallando la situación del

bien, como se indica en el artículo 150 dispuesto en el Acuerdo de la Contraloría General del

Estado 41 No. 041-CG-2017.

Artículo 150: la máxima autoridad dará la autorización respectiva la baja de bienes biológicos,

una vez que se haya comprobado la situación del bien mediante un informe técnico emitido por el

criterio profesional de un responsable asignado a dicha área.

En los casos de pérdida o desaparición de los bienes por hurto, robo, abigeato, fuerza mayor o

caso fortuito se regirá a los artículos 151 y 155 de este reglamento mencionado anteriormente, en

el cual se detallan las siguientes disposiciones.

Para detallar los artículos 151 y 155 dispuestos en el Acuerdo de la Contraloría General del

Estado 41 No. 041-CG-2017, se realizará una interpretación propia en base a estos dos artículos:

Artículo 151: en caso de pérdida o desaparición de los bienes por hurto, robo, abigeato, fuerza

mayor, caso fortuito o por alguna causa semejante, es responsabilidad del custodio, guardalmacén

o persona a cargo indicar mediante un documento el suceso a la Unidad administrativa, la cual

continuará con el trámite correspondiente.

Informando a la máxima autoridad de la entidad del suceso para que este pueda realizar la

denuncia respectiva ante la Fiscalía General del Estado o Policía Nacional, adicionalmente para

poder realizar dicho trámite debe disponer de todos los documentos necesarios proporcionados por

la persona o personas a cargo del custodio de los bienes de la entidad.

21

Artículo 155: para realizar la baja de bienes existen dos tipos de modalidades para poder hacer

este proceso:

En el caso de bienes desaparecidos se debe realizar el procedimiento mencionado anteriormente

descrito en el artículo 151.

Para los bienes destruidos se debe emitir un escrito a la unidad administrativa para realizar el

procedimiento de baja del bien indicado en el artículo 150.

Es responsabilidad del custodio de bodega asignado por la entidad a la que presta sus servicios

acatar las resoluciones dispuestas por la contraloría, además que debe tener todos sus inventarios

actualizados, haciendo uso de herramientas que le faciliten realizar reportes, informes y

documentación detallada de todos los bienes bajo su responsabilidad.

22

3. DESARROLLO

En el presente apartado, mostramos el uso de la metodología XP aplicada al desarrollo e

implementación del sistema control de inventarios de bodega con el fin de proporcionar resultados

satisfactorios al aplicar esta técnica de desarrollo.

3.1. Metodología de programación

Como se explicó en el apartado 2, esta metodología se efectúo con las siguientes fases:

Exploración de Información.

Recolectamos información mediante el estudio de campo e historias de usuario, con el fin

de identificar los módulos principales que satisfagan las necesidades de negocio de las

bodegas, obteniendo los siguientes:

- Módulo de Ingresos.

- Módulo de Pedidos.

- Módulo de Egresos.

- Módulo de Administración de Usuario.

- Módulo de Reportes.

- Módulo de Transferencias

- Módulo de Alertas de Stock.

23

Planificación.

Se planificó reuniones con el custodio de cada bodega, con el propósito de dar a conocer el

funcionamiento del sistema conforme progresaba cada etapa de desarrollo, para corregir

errores tempranamente en cada fase del proyecto.

Las reuniones generaban historias de usuario que fueron necesarias para definir los

compromisos con el cliente mediante actas.

Iteración.

Los módulos mencionados anteriormente generaban entregables funcionales a los clientes

haciéndolos participativos del proyecto y corregir errores, permitiéndonos avanzar con el

proyecto. La aprobación de cada módulo fue necesario para avanzar a la siguiente iteración,

tomando en cuenta las necesidades del usuario reflejadas en las actas.

Producción.

El sistema cuenta con todos los módulos funcionales con los cuales procedemos a realizar

pruebas conjuntas como: pruebas de interfaz, caja negra y de stress, las que permiten observar

el funcionamiento deseado y con la menor cantidad de errores, permitiéndonos poner en

producción el sistema.

24

3.2. Identificación del Proceso de Control de Existencia de Bodega

Tras recopilar información con los custodios encargados de las bodegas de las facultades de la

Universidad Central del Ecuador e identificar los requerimientos para el proyecto, se definió el

siguiente proceso mostrado a continuación:

25

Ilustración 3: Diagrama del Proceso de Control de Existencia de Bodega.

26

3.2.1. Proceso Administrar.

Este proceso se encarga de creación de usuarios que consten en la base de datos de talento

humano de la universidad y asignación de nuevos roles a usuarios que sean parte del sistema.

También gestionara la administración de sud-bodegas y catálogos presupuestarios detallados

posteriormente en este apartado.

3.2.2. Proceso Pedidos.

Este proceso será gestionado por empleados administrativos que generaran un ticket o número

de pedido, con el cual agregará productos pertenecientes a cada bodega, para posteriormente poder

ser despachados por el custodio o guardalmacén encargado.

3.2.3. Proceso Egresos.

Los egresos necesariamente dependen de la correcta ejecución del proceso de pedidos, ya que

los egresos cargan todos los productos provenientes de un pedido en específico, solamente de

esta manera se podrá generar un egreso y actualizar el inventario actual.

3.2.4. Proceso Ingresos.

Este proceso es la parte esencial del transcurso de la información, ya que los ingresos generados

de manera correcta habilitaran los módulos de reportes, generando cálculos necesarios para poder

actualizar las siguientes funcionalidades:

Cálculo del precio promedio para la actualización del inventario, los cuales dependen de

otros factores como: nombre del producto, tipo de unidad a la que pertenece el producto y

bodega de almacenamiento.

27

Actualización de catálogos mensuales por cuentas contables establecidas o reguladas por

el ministerio de finanzas.

3.2.5. Proceso Alertas

Se trata de un sub-proceso de alertas que muestran cuando el insumo alcanza los umbrales

definidos por el consumo de los mismos, teniendo una alerta media y una alerta critica.

Alerta media: toma la mitad del total de la cantidad ingresada hasta el momento en productos

que no tienen caducidad y los que sí tienen toma seis meses antes de su fecha de vencimiento.

Alerta critica: toma el diez por ciento del total de la cantidad ingresada hasta el momento en

productos que no tienen caducidad y los que sí tienen toma tres meses antes de su fecha de

vencimiento.

3.2.6. Proceso de Reportes.

Este proceso permite obtener información de los movimientos que ha generado el sistema para

la toma de decisiones, teniendo en cuenta que cada custodio optara por la decisión final adecuada.

El sistema nos permite obtener reportes por pedidos, egresos, ingresos y catálogos, mediante el

uso de filtros de acuerdo a la necesidad del usuario, los reportes se generan en formato PDF.

3.2.7. Proceso de Transferencias.

En este sub-proceso el encargado de cada bodega y con productos a su disposición, tendrá el

control de transferir a bodegas desabastecidas si estas lo solicitaran. Teniendo en cuenta que todas

las transferencias serán almacenadas para el respectivo control de auditoria, ya que este proceso

también será reflejado en el cálculo de los catálogos mensuales por cuentas contables.

28

3.3. Identificación de Roles en el Sistema.

Los siguientes son los actores identificados que se desenvuelven en el manejo del sistema

mostrado en la siguiente tabla:

Tabla 5

Identificación de roles en el sistema

Rol Descripción

Administrador

Persona encargada de la creación de usuarios, asignando rol, facultad

y bodega a la que estará designado como custodio. El proceso de

asignación se realizara mediante una constatación física por parte del

área encargada , indicando que la persona fue asignada para ese cargo

Pedidos

La persona con este rol será responsable de generar los pedidos para

que posteriormente puedan ser despachadas en las sub-bodegas

correspondientes.

Bodeguero

/

Guardalmacén

Persona encargada con este rol será responsable de la creación de

áreas, proveedores y acceso al inventario de todas las sub-bodegas si

existieran.

Sub-bodeguero

Es el responsable de realizar los ingresos y egresos, mediante un

pedido generado por parte del área administrativa o persona

encargada con ese rol.

29

3.4. Análisis del Diseño.

Es importante mencionar que una persona puede cumplir con varios roles simultáneamente,

siempre que estén sujetos a todas las responsabilidades acorde al reglamento estipulado por la

universidad. En este apartado se describe el estándar de la base de datos así como también los

nombres de las tablas y los campos respectivos.

Para la creación de una base de datos se debe tener en cuenta lo siguiente:

Se debe definir en primer lugar un modelo lógico del modelo relacional de la base de datos.

En el caso de que se haga cambios en la base de datos, se debe actualizar el modelo lógico

inicial de la base de datos con el fin de tener todos los cambios registrados.

Nombres de bases de datos.

El nombre de la base de datos está estructurado de la siguiente manera, el cual se describe

en la Tabla 6:

Tabla 6

Nombre de la base de datos

Nombre Proyecto Ambiente Nombre Base de Datos

inventarioBodega desarrollo InventarioBD

30

Nombres de tablas.

Los nombres de las tablas están en singular.

Si el nombre de la tabla contiene más de una palabra, se separa con guiones bajos.

Abreviaturas para los nombres de campos

Si el nombre inicia con una consonante o si el nombre contiene mínimo tres consonantes,

la abreviatura para los nombres de sus campos contienen las tres primeras consonantes de

la palabra

Si el nombre de la tabla contiene dos o más palabras, se unirá las dos primeras letras de

cada palabra.

Si el nombre contiene menos de tres consonantes, la abreviatura para los nombres de sus

campos contiene la primera consonante, la primera vocal y la segunda consonante de la

palabra.

Para la asignación de nombres a las tablas de la base de datos, se tomó las abreviaturas

explicadas anteriormente, teniendo como resultado la siguiente tabla mostrada a continuación:

Tabla 7

Abreviaturas de tablas

Nombre de la tabla Abreviatura Descripción

ROL Rol Contiene los nombres de los roles que

tendrá el sistema.

USUARIO Usr Contiene la información de los usuarios

que se registren en el sistema.

31

USUARIO_ROL Usro Almacena los roles que se asignan a los

usuarios.

SUB_BODEGA Sbbd Almacena información de las sub-

bodegas ingresadas.

BODEGA Dbg Almacena el nombre y la descripción

de las bodegas.

CATALOGO_BODEGA Ctdb Guarda la asignación de catálogos

hacia las bodegas de cada facultad.

CATALOGO_MENSUAL Ctmn

Almacena el cálculo por catálogo de

forma mensual de lo realizado en los

ingresos y egresos.

ROL_BODEGA_FLUJO Robdfl

Registra las intervenciones de cada rol

en la bodega con respecto a los ingresos

y egresos.

ROL_FLUJO_FACULTAD Rofflc

Registra las intervenciones de cada rol

en la cada facultad con respecto a los

ingresos y egresos.

DEPENDENCIA Dpn Almacena el nombre de cada

dependencia creada.

DETALLE_PEDIDO Dtpd Almacena el detalle de la orden de

pedido.

CABECERA_PEDIDO Cbpd Almacena la cabecera de la orden de

pedido.

DETALLE_EGRESO

Dteg

Almacena el detalle de los egresos

generados por el usuario.

CABECERA_EGRESO Cbeg Almacena la cabecera de los egresos

generados por el usuario.

AREA Are Contiene la información de las áreas

creadas por cada bodega.

32

TRANSFERENCIAS Trn

Esta tabla tiene la información

referente a las transferencias de

insumos realizados entre bodegas

INVENTARIO Inv

Registra la información de los insumos

disponible por cada bodega los

movimientos y cálculos realizados por

los catálogos y consolidados

mensuales.

CABECERA_INGRESO Cbin Almacena información de la cabecera

de la factura.

DETALLE_INGRESO Dtin Almacena información de los detalles

de la factura.

PROVEEDOR Prv Posee información de los proveedores

de insumos.

TIPO_INGRESO Tpin Almacena el tipo de ingreso realizado

por el usuario en el sistema.

CATALOGO Ctl

Almacena los nombres de las cuentas

contables utilizadas por las diferentes

facultades de la universidad.

Total Tablas: 24

La Tabla 7 contiene todas las abreviaciones y tablas elaboradas que constan en el sistema de

inventario de existencias, el modelado de las tablas fue desarrollado en el programa CA ERwin

Data Modeler r7.3 y ejecutado en el gestor de base de datos ORACLE 12c.

33

Ilustración 4: Diagrama Modelo Entidad Relación.

3.4.1. Modelo Entidad Relación.

34

3.5. Análisis de Requerimientos

3.4.1. Análisis de Requerimientos no Funcionales.

“Los requerimientos no funcionales suelen referirse a límites o restricciones sobre el

comportamiento del sistema, por lo cual se debe establecer límites y restricciones sobre lo que los

arquitectos de software deben hacer” [8] (Pressman, 2002).

Requerimientos de usabilidad: El usuario necesitara aprender a usar el sistema con una guía

establecida de ayuda, la cual indicará los procedimientos para tener mayor facilidad de uso.

Requerimientos de integración: El sistema centralizará toda la información recolectada en

los servidores de la unidad de Dirección de Tecnologías de la Información y

Telecomunicaciones (DTIC).

Requerimientos de mantenibilidad: El sistema brindará facilidad en su mantenimiento ya

sea para el desarrollo de nuevos módulos, corrección de errores o cambios en las reglas de

negocio, es por eso que el sistema está debidamente documentado tanto en el código fuente

como en los manuales de uso.

Requerimientos de seguridad: La seguridad de datos que brinda el sistema, se hace

mediante mecanismos de control de acceso de autentificación y roles por bodega, los que

permiten la integridad de toda la información independientemente si pertenecen a la misma

bodega.

El sistema ofrece una interfaz gráfica fácil de usar y amigable que permite a los usuario

una adaptación pronta e intuitiva con respecto a su uso.

35

Considerando los requerimientos no funcionales de producto es vital la integración continua de

aplicaciones y el desarrollo de cambios que sean rápidos pero sostenibles en el tiempo.

3.4.2. Análisis de Requerimientos Funcionales.

El sistema pretende gestionar el almacenamiento en bodega de activos no depreciables de cada

facultad para el control y despacho a cada usuario que lo requiera. Se tiene como propósito

almacenar en un repositorio de datos la información concerniente como ingresos de nuevos

insumos, egresos, pedidos entre otros; también se cuenta con manejo de alertas en el sistema, así

como la generación de reportes detallados.

El sistema será capaz de los siguientes requerimientos mostrados en la siguiente tabla:

Tabla 8

Requerimiento funcionales

Requerimientos Descripción

Registrar nuevos clientes en el sistema. Permite el registro de un nuevo usuario

asignándole un rol y cargo en la aplicación

Registrar nuevos insumos en el sistema. Permite ingresar en el sistema todos

insumos especificando el tipo de unidades

fechas y precios.

Registrar nuevos ingresos y egresos de

insumos en el sistema.

Permite el registrar la cantidad entrante y

saliente de insumos en el sistema.

Ingresar información relacionada con la

orden de pedido.

El sistema permitirá obtener un reporte de

pedido autorizado para el despacho de los

insumos.

36

Generación de reportes con los datos

registrados en el sistema.

El usuario podrá visualizar informes de:

Orden de pago de pedidos

Catálogos

Reporte por Pedidos

Reporte por Ingresos

Reporte por Egresos

3.5. Historia de Usuarios.

Esta sección corresponde a la descripción general del funcionamiento del sistema basado en la

fase de exploración de información de la metodología aplicada, empleando el lenguaje natural que

utiliza el cliente final. Estas historias mostrarán los requerimientos iniciales del usuario, y se

aplicaran a cada módulo del sistema como se muestra en la Tabla 9.

Tabla 9

Nombres Historias de Usuarios

Nro. Nombre (Historia de Usuario)

1 Ingreso al Sistema.

2 Administrar Usuarios.

3 Ingresar Insumos.

4 Egresar Insumos.

5 Pedidos.

6 Transferir Insumos.

7 Reportes.

8 Alarmas.

37

Obteniendo, finalmente entre las más importantes un total de 8 historias de usuario.

3.5.1. Historia Ingreso al sistema.

En la Tabla 10 se muestra la información generada en la realización de la historia de usuario

sobre el ingreso al sistema.

Tabla 10

Historia de Usuario Ingreso al Sistema


Número: 1 Usuario: Todos los usuarios.

Nombre Historia: Control de acceso de usuarios al sistema.

Prioridad en Negocio: Alta Riesgo en Desarrollo: Alta

Programador Responsable: Tesista.

Descripción:

Para el ingreso al sistema el usuario podrá ingresar con las credenciales de usuario y

contraseña asignadas por la Universidad Central del Ecuador, para que tenga acceso a

los datos y módulos que corresponden a su perfil de usuario. Existen 4 tipos de

usuarios: administrador, pedidos, bodeguero y sub-bodeguero. Con acceso a la pantalla

principal activándose solo los módulos que implique su perfil.

Observaciones:

El sistema validará y mostrará un mensaje de error si se ingresa un usuario o clave

incorrecta o no registrada en la base de datos.

38

3.5.2. Historia Administrar Usuarios.

En la siguiente tabla se muestra la información acerca de la realización de la historia de usuario

sobre la administración de los usuarios en el sistema.

Tabla 11

Historia de Usuario Administrar Usuarios


Número: 2 Usuario: Administrador.

Nombre Historia: Control de creación de usuarios en el sistema.

Prioridad en Negocio: Alta Riesgo en Desarrollo: Alta


Descripción:

Permitirá la creación de cuentas de usuario en el sistema. Solo el administrador, podrá

realizar esta acción, según sea autorizado previamente por la autoridad pertinente. Se

tendrá que buscar al usuario mediante un filtro al cual se agregara la información que

se requiere para el registro de un nuevo usuario son: Rol, facultad, bodega, sub-bodega.

Observaciones:

Si los datos ingresados son correctos, el sistema mostrara un mensaje de confirmación,

informando que el usuario ha sido creado con éxito, caso contrario mostrara un mensaje

que el usuario no fue encontrado o ya ha sido creado anteriormente.

39

3.5.3. Historia Ingresar Insumos.

La Tabla 12 se muestra la información acerca de la realización de la historia de usuario sobre la

realización de ingreso de insumos al sistema.

Tabla 12

Historia de Usuario Ingresar Insumos


Número: 3 Usuario: Bodeguero.

Nombre Historia: Ingreso de insumos en la base de datos del inventario de bodega.

Prioridad en Negocio: Medio Riesgo en Desarrollo: Medio


Descripción:

Los insumos que se ingresen al sistema se dividen en dos partes en cabecera de la

factura donde va la información referente como código de ingreso, fecha, numero de

factura, proveedor, bodega, responsable, catalogo, IVA, descuento, descripción y el

detalle de los insumos ingresados detallando el tipo de unidad (unidad, kilogramo,

mililitro), nombre, cantidad, caducidad, valor unitario.

Observaciones:

Se llevará control de los ingresos en el sistema mediante un inventario de los productos

por catálogos y en sus respectivas bodegas.

40

3.5.4. Historia Egresar Insumos.

En la Tabla 13 se muestra la información obtenida acerca de la realización de la historia de

usuario sobre egresos de insumos de las bodegas por medio del sistema.

Tabla 13

Historia de Usuario Egresar Insumos


Número: 4 Usuario: Sub-Bodeguero.

Nombre Historia: Control de egreso de insumos del inventario del sistema.



Descripción:

Se registrará el egreso de insumos del sistema donde de forma obligatoria se debe

ingresar el código de pedido para que el sistema pueda desplegar en una tabla de forma

automática los insumos que constan en ese pedido y pueda ser despachados las

cantidades permitidas por el sub-bodeguero.

Observaciones:

Para poder egresar los insumos de una determinada bodega en el sistema, la cantidad

solicitada debe estar dentro de los lumbrales permitidos de despacho por el sistema.

41

3.5.5. Historia de Usuario de Pedidos.


sobre los pedidos que se pueden realizar en el sistema.

Tabla 14

Historia de Usuario Pedidos


Número: 5 Usuario: Pedidos

Nombre Historia: Control de pedidos de insumos hacia la bodega.



Descripción:

Se deberá generar un pedido a través del sistema de manera que se automatice este

proceso de recogimiento de información los campos que llevara esta solicitud son los

siguientes:

Código de pedido, Bodega, fecha, responsable, recibido por y una descripción opcional.

Para posteriormente poder desplegar los insumos disponibles en la bodega

seleccionada.

Observaciones:

El módulo de pedidos generara el código de pedido y la orden la cual deberá ser

aprobada para su despacho y se lo realizada con el código antes mencionado.

42

3.5.6. Historia Transferir Insumos.

La Tabla 15 muestra la información acerca de la realización de la historia de usuario sobre las

transferencias que se realicen en el sistema.

Tabla 15

Historia Transferir Insumos


Número: 6 Usuario: Bodeguero.

Nombre Historia: Transferencias de insumos entre bodegas.

Prioridad en Negocio: Medio Riesgo en Desarrollo: Bajo


Descripción:

Permite al bodeguero poder transferir insumos desde una bodega hacia otra sin tener la

necesidad de generar un pedido.

Observaciones:

Generará una constancia física de que los insumos pasaron de una bodega a otra

haciendo responsable de esta manera al bodeguero que recibe la transferencia de los

insumos.

43

3.5.7. Historia de Reportes.

En la Tabla 16 se muestra la información acerca de la realización de la historia de usuario sobre

los reportes que genera el sistema para mostrar información para la toma de decisiones.

Tabla 16

Historia de Reportes


Número: 7 Usuario: Bodeguero, Sub-Bodeguero.

Nombre Historia: Reportes de movimientos en el sistema.

Prioridad en Negocio: Alto Riesgo en Desarrollo: Medio


Descripción:

Cada vez que el usuario requiera generar reportes podrá acceder al sistema y filtrar

según varias opciones como lo son el número de factura, proveedor, nombre, y fecha

según esto podrá ver los reportes como sea necesario de los cuales existirán varios tipos

de reportes que el sistema podrá generar como los son los siguientes reportes: ingreso,

egreso, pedidos, catálogo

Observaciones:

El reporte de catálogo generara un total de todos los movimientos realizados durante

los meses transcurridos donde el saldo final de cada mes será el saldo inicial del

siguiente mes.

3.5.8. Historia de Alarmas.


sobre las alarmas que se mostraran en el sistema.

44

Tabla 17

Historia de Alarmas


Número: 8 Usuario: Bodeguero, Sub-Bodeguero.

Nombre Historia: Alertas de inventario.



Descripción:

En el sistema se mostraran varios mensajes de alertas que avisaran a los usuarios

cuando los insumos necesiten de la atención de estos.

Existirá 2 puntos en los que el sistema mostrara los mensajes cuando los insumos se

encuentren en el 50% de su stock mostrara el primer aviso al usuario y otro al 10% de

su stock para que el usuario realice las respectivas acciones como solicitar la compra

del insumo a agotarse o no despachar todo el insumo para no dejar el stock en cero.

Observaciones:

El control de las alarmas tiene 2 tipo las cuales son:

Por cantidad

Por fecha de caducidad

3.6. Modelo de Casos de Uso.

Los Casos de Uso “Son una técnica para la captura de requisitos potenciales de un nuevo Sistema o

una actualización de Software. Cada caso de uso proporciona uno o más escenarios que indican cómo

debería interactuar el sistema con el usuario o con otro sistema para conseguir un objetivo específico.

Normalmente, en los casos de usos se evita el empleo de jergas técnicas, prefiriendo en su lugar un

lenguaje más cercano al usuario final” [12] (EcuRed, 2016).

https://www.ecured.cu/Sistema

https://www.ecured.cu/Software

https://www.ecured.cu/index.php?title=Escenarios&action=edit&redlink=1

45

3.6.1. Caso de Uso Inicio de Sesión.

A continuación se detallará el proceso de inicio de sesión al sistema inventario de existencias


Tabla 18 Caso de Uso Inicio de Sesión

Caso de uso N°01

Nombre de caso

de uso:

Iniciar Sesión

ACTORES Administrador, Pedido, Bodeguero, Sub-Bodeguero.

OBJETIVO Permitir al Usuario registrado en el sistema, ingresar al sistema.

PRECONDICIONES El usuario debe estar registrado en la base de datos de la Universidad

Central de Ecuador.

POSCONDICIONES

El usuario podrá ingresar al sistema.

ACCION DEL ACTOR RESPUESTA DEL SISTEMA

46

Ingresar usuario y contraseña. 1. Validar datos.

2. Permitir el ingreso al sistema.

3. Muestra la interfaz correspondiente al rol del

usuario.

Situaciones excepcionales

• Error conectando con la base de datos.

• Datos ingresados erróneos o el usuario no existe.

3.6.2. Caso de Uso Administración de Usuarios.

A continuación se detallará el proceso de administración de usuarios del sistema inventario de

existencias mostrado a continuación:

Tabla 19

Caso de Uso Administración de Usuarios

Caso de uso N°02

Nombre de caso de

uso:

Administración de

Usuarios.

ACTORES Administrador.

OBJETIVO Permitir al Usuario administrador del sistema crear nuevos

usuarios asignándoles roles, facultades, bodegas, sub-bodegas

y áreas.

47

PRECONDICIONES El usuario debe tener rol de

administrador en el sistema.

POSCONDICIONES El usuario podrá crear los usuarios

necesarios autorizados.

FLUJO DE EVENTOS


1. Ingresar al sistema.

2. Ingresar la información

del nuevo usuario.

3. Muestra la interfaz correspondiente al

rol del usuario

4. Guardar datos.


• Error Usuario ya existente.

• Datos ingresados erróneos del usuario.

• No se puede conectar a la base de datos.

• El Usuario no ingresó los campos requeridos (*).

3.6.3. Caso de Uso Pedidos.

En la siguiente tabla detallaremos el proceso de pedidos a bodega usado en el sistema

inventario de existencias:

Tabla 20

Caso de Uso Pedidos

Caso de uso N°03

Nombre de caso de

uso:

Pedidos

48

ACTORES Pedidos.

OBJETIVO Permitir al Usuario con el rol de pedidos ingresar al sistema y

generar pedidos de determinador productos con la cantidad

que le permita el sistema.

PRECONDICIONES El usuario debe tener rol de pedidos en el sistema.

Para poder generar el pedido la cantidad solicitada

debe existir y estar entre los lumbrales permitidos de

despacho.

POSCONDICIONES El usuario debe imprimir el pedido y solicitar al

responsable en bodega.

FLUJO DE EVENTOS


1. Ingresar al sistema.


del pedido.

3. Listar productos.

4. Agregar al pedido.

1. Muestra la interfaz correspondiente al

rol del usuario.

2. Imprimir pedido.


• Cantidad no existente.

• Datos ingresados erróneos del usuario.


3.6.4. Caso de Uso Ingresos.

A continuación se detallará el proceso de ingresos de nuevos productos al sistema inventario

de existencias mostrado en la siguiente tabla:

49

Tabla 21

Caso de Uso Ingresos

Caso de uso N°04 Nombre de caso

de uso:

Ingresos

ACTORES Bodeguero.

OBJETIVO Agregar un nuevo producto al inventario del sistema.

PRECONDICIONES El usuario debe estar registrado en el sistema.

El usuario debe haber iniciado sesión en el sistema.

El usuario debe tener rol de bodeguero en el sistema.

El sistema proveerá al usuario el formulario donde

ingresará la información de los productos del nuevo

ingreso.


1. Ingresar al módulo de

registrar nuevo ingreso

2. Ingresar información del

ingreso.


de los productos.

4. Carga un formulario para la

creación de productos.

5. Valida información ingresada.

6. Almacena la información.

7. Notifica al usuario el estado de

la operación (exitosa o fallida).

50


• No se puede cargar el formulario Registrar nuevo producto.



• Los datos ingresados son incorrectos.

• El producto ya existe.

3.6.5. Caso de Uso Egresos.

En la siguiente tabla se detallará el proceso de egresos realizados en el sistema inventario de

existencias:

Tabla 22

Caso de Uso Egresos

Caso de uso N°05

Nombre de caso de

uso:

Egresos

ACTORES Bodeguero, Sub-Bodeguero.

OBJETIVO Realizar egresos o despachos de los pedidos realizados en el

sistema.

51



El usuario debe tener rol de bodeguero o sub-

bodeguero en el sistema.

El sistema proveerá al usuario el formulario donde

ingresará la información para realizar el egreso.

El sistema validara si la cantidad de productos

solicitados se encuentra dentro de la cantidad

existente en el sistema.

El sistema calculara automáticamente el descuento,

I.V.A, sub-total y el total del egreso

POSCONDICIONES El usuario podrá realizar egresos del inventario del

sistema.

El usuario podrá imprimir los detalles del egreso

realizado.



registrar nuevo egreso

2. Ingresar información del

egreso.

3. Cargar pedido.

4. Aceptar o eliminar

producto.

5. Generar egreso.

6. Imprimir egreso

7. Carga un formulario para

cargar el pedido.

8. Valida información ingresada.

9. Almacena la información.

10. Notifica al usuario el estado de

la operación (exitosa o fallida).




• Los datos ingresados son incorrectos.

• No se encuentra la cantidad para despachar el producto.

52

3.6.6. Caso de Uso Reportes.

A continuación se detallará el proceso de generación de reportes proporcionados por el

sistema inventario de existencias mostrado en la siguiente tabla:

Tabla 23

Caso de Uso Reportes

Caso de uso N°06

Nombre de caso de

uso:

Reportes


OBJETIVO Permitir al Usuario generar reportes de ingresos, egresos,

pedidos y catálogo.



El sistema proveerá las opciones donde debe

seleccionar el tipo de informe del cual pretende

generar el informe.

El sistema proveerá la opción de cargar todos los

datos acerca del tipo de informe seleccionado.

El sistema proveerá filtros para hacer más fácil la

generación del informe.

53

POSCONDICIONES El usuario podrá seleccionar tipo de informe con el fin de

parametrizar el informe a generar.

FLUJO DE EVENTOS


1. Ingresar al módulo de Informes

2. Seleccionar el tipo de informe a

generar.

3. Carga un formulario para la generación de

un informe.


• No se puede cargar el formulario de Informes/Generar Informe.

3.6.7. Caso de Uso Transferencias.

A continuación se detallará el proceso de transferencias de productos hacia diferentes bodegas


Tabla 24

Caso de uso transferencias

Caso de uso N°07

Nombre de caso de

uso:

Transferencias


54

OBJETIVO Permitir al Usuario transferir productos de una bodega hacia

otra para abastecer de ser necesario.



El sistema proveerá la opción de listar todos los

productos de la bodega.

El sistema proveerá filtros para hacer más fácil la

generación del informe.

El sistema proveerá la opción para seleccionar la

cantidad y el destino de los productos.

POSCONDICIONES El usuario tendrá a criterio la cantidad de productos que

desea transferir.

FLUJO DE EVENTOS



Abastecimientos.

2. Listar todos productos de la bodega.

3. Seleccionar cantidad y bodega a

transferir.

4. Generación de pdf de transferencia exitosa.


• No se puede cargar el formulario de Informes/Generar Informe.

• No se puede cargar los productos de la bodega.

55

Ilustración 5: Diagrama de Secuencia del Control Existencias de Bodega

3.7. Diagrama General de Secuencia del Sistema

56

3.8. Metodología para el Control de Bienes no Sujetos a Control

Para poder llevar un control de inventario en la Universidad Central del Ecuador como una

entidad pública, está sujeta a un control regulatorio por parte de la Contraloría General del Estado

mencionada en el apartado 2.1.3.

La cual nos permite tener una normativa necesaria para el sistema que se va a implementar y

proporcione recursos necesarios para el uso del mismo.

Roles: los roles son el pilar básico para el manejo del sistema, ya que como se indica en el

acuerdo de la Contraloría del Estado 41 No. 041-CG-2017, el control de los bienes no

depreciables deben ser manejadas por una o varias personas administrativas, las cuales llevan su

respectivo control mencionadas en el apartado 2.

Catálogo de Bienes no Depreciables: los ingresos a cada bodega se realizan mediante un nuero

de factura de la entidad que los provee y un nombre de catálogo correspondiente al ingreso actual.

El catálogo emitido por la Contraloría General del Estado, consta de un código con las

siguientes categorías, mostradas en la siguiente tabla:

Tabla 25

Catálogo de Bienes no Depreciables

Código Nombre de Catálogo

530801 Alimentos y bebidas

530802 Vestuario, lencería y prendas de protección

530803 Combustibles y lubricantes

57

530804 Material de oficina

530805 Material de aseo

530806 Herramientas

530807 Material de impresión fotográfica, repuestos

530810 Material para laboratorio y uso médico

530811 Material para construcción eléctricos

530812 Materiales didácticos

530813 Repuestos y accesorios

Los nombres de catálogos anteriores pueden aumentar mediante la necesidad de clasificación

de bienes no depreciables, pero estos solamente serán emitidos por la entidad que los regula.

Tipos de Ingresos: adicionalmente para el control interno de los productos, se ha optado por

dividir en tres categorías de ingreso, las cuales detallaremos a continuación:

Unidades: los productos que ingresan por unidades se egresaran por unidades.

Unidad litro: los productos que ingresen por unidad de medida litro, podrán ser

despachadas en su unidad decimal anterior, es decir; en mililitros o viceversa.

Unidad Kilogramo: los productos que ingresen por unidad kilogramo, podrán ser

despachadas en su unidad decimal anterior, es decir; en gramos o viceversa.

58

4. PRUEBAS, CONCLUSIONES Y RECOMENDACIONES

4.4. Pruebas.

Las pruebas que se realizan al aplicativo de software proporcionan información que permite

evaluar la calidad del producto, ya que estas forman parte de la fase de producción de la

metodología usada. A continuación se detallara las pruebas que se realizó al sistema.

4.1.1. Pruebas de Interfaz.

Para tener un mejor funcionamiento del sistema “Inventario de Existencias” en los diferentes

navegadores se tomó en consideración tres navegadores posiblemente más usados por los usuarios

de las bodegas de la Universidad Central del Ecuador, obteniendo los siguientes resultados de las

pruebas realizadas mostrados en la Tabla 26:

Tabla 26

Resultados Pruebas de Interfaz

Navegador Tiempo de

respuesta

Visualización

de resultados

Problemas

Google Chrome Óptimo Óptima Ninguno

Mozilla Firefox Óptimo Óptima Ninguno

Internet

Explorer

Óptimo Óptima Ninguno

Los siguientes son resultados que se obtuvieron como se muestra en la Tabla 26, de las pruebas

que se utilizaron y el navegador que tiene mejores resultados con el funcionamiento del sistema.

59

La Tabla 27 muestra la calificación cualitativa utilizada para las métricas de los navegadores

evaluados.

Tabla 27

Calificación de métricas de navegadores

Calificación

Correcto

Parcial

Incorrecto

Tabla 28

Resultados Obtenidos de las métricas de navegadores

Resultados

Métrica Navegador Calificación

Visualización de

imágenes en el

navegador

Google Chrome Correcto

Mozilla Firefox Correcto

Internet Explorer Correcto

Despliegue de

mensajes en

pantalla




Funcionamiento de

enlaces y botones




Funcionamiento de

todos los diferentes

componentes



Internet Explorer Parcial

60

Con estos resultados se concluye que el sistema inventario de existencias, funciona mejor en

las versiones actuales de los navegadores antes mencionados, por lo tanto es recomendable utilizar

las versiones:

Internet Explorer 10.0

Mozilla Firefox 56.0

Google Chrome 62.0.3202.62

4.1.2. Pruebas de caja negra

Esta es una técnica de pruebas de software la cual ayuda en la fase de producción de la

metodología, en la cual se verifica la funcionalidad correcta de sistema sin tomar en cuenta la

estructura interna del código fuente.

Las pruebas de caja negra fueron enfocadas en las entradas y salidas de datos esperados en el

sistema, obteniendo resultados de los diferentes escenarios que se produzcan en las diferentes

funcionalidades. Basándonos en los requerimientos no funcionales y funcionales mencionados

anteriormente en el apartado 3.

A continuación se muestra una técnica llamada partición de equivalencia, esta permite examinar

los valores ingresados en las entradas del sistema, descubriendo de manera inmediata errores que

se pueden producir en la ejecución y pueden ser detectados y corregidos a tiempo. En las siguientes

tablas se presentan múltiples pruebas realizadas a cada uno de los módulos con que posee el

sistema:

61

Caso de Prueba No. 1

Tabla 29

Prueba de caja negra al módulo de creación de usuarios

MÓDULO Creación de usuarios

TAREA Buscar al usuario en la base de datos de talento humano

y verificar si es usuario activo.

Verificar si un usuario puede volver a registrarse.

Verificar si un usuario no perteneciente a la base de

datos de talento humano puede registrarse.

Verificar si los campos que son requeridos están

validados para la creación del usuario.

PRERREQUISITOS El usuario de soporte debe estar registrado en la base

de datos.

PASOS 1. Ingresar al sistema inventario de existencia,

sección administrar, crear nuevo usuario.

2. Buscar un usuario por su número de cédula y

listar coincidencias.

3. Ingresar datos adicionales para el registro y

asignación de rol del nuevo usuario.

4. Clic botón crear usuario.

ENTRADA/ACCIÓN DEL USUARIO SALIDA

ESPERADA

ESTADO

El administrador ingresa la cédula de un usuario

registrado y busca las coincidencias.

El usuario se

muestra en la tabla

de coincidencias y

se habilita el botón

crear usuario.

OK


registrado en el sistema inventario de existencias.

El usuario se

muestra en la tabla

de coincidencias

pero no se habilita el

botón crear usuario

OK

62

El administrador ingresa un número de cédula no

perteneciente a la base de datos de talento

humano.

No se muestra

ninguna

coincidencia por lo

que el botón crear

usuario se encuentra

deshabilitado.

OK

Una vez que el administrador encuentra el usuario

procederá a ingresar los siguientes campos:

Rol

Facultad

Bodega

SubBodega

Descripción de SubBodega

Para posteriormente dar clic en el botón crear

usuario.

Si todos los campos

son correctos creara

el nuevo usuario de

lo contrario

mostrara mensajes

de los campos que

requieran alguna

corrección

OK


Tabla 30

Prueba de caja negra al módulo de asignación de cargos

MÓDULO Asignar nuevo cargo

TAREA Buscar al usuario en la base de datos del sistema

inventarios de existencias y verificar si es usuario activo.

Verificar si un usuario puede volver a registrarse con el rol

previamente asignado en la creación de usuarios mostrada

en la Tabla 30.

Verificar si un usuario no perteneciente a la base de datos

del sistema inventarios de existencias y puede registrarse.

Verificar si el campo que es requerido está validado para

la asignación de un nuevo rol.

PRERREQUISITOS El usuario de soporte debe estar registrado en la base de datos.

63

PASOS 1. Ingresar al sistema inventario de existencia, sección

administrar, asignar nuevo cargo.

2. Buscar un usuario por su número de cédula y listar

coincidencias.

3. Ingresar datos adicionales para el registro y asignación de

rol del nuevo usuario.

4. Clic botón asignar nuevo cargo.


ESPERADA

ESTADO


registrado y busca las coincidencias.

El usuario se

muestra en la tabla

de coincidencias y

se habilita el botón

asignar nuevo

cargo.

OK


registrado en el sistema inventario de existencias.

El usuario se muestra

en la tabla de

coincidencias y se

habilita el botón

asignar nuevo cargo

OK

El administrador ingresa un número de cédula no

perteneciente a la base de datos del sistema

inventario de existencias.

No se muestra

ninguna

coincidencia por lo

que el botón asignar

nuevo cargo se

encuentra

deshabilitado.

OK

Una vez que el administrador encuentra el usuario

procederá a ingresar el nuevo rol.

Si el rol para el

usuario existente ya

ha sido creado no

permitirá la

asignación del

mismo rol.

OK

64


Tabla 31

Prueba de caja negra al módulo de creación de SubBodega

MÓDULO Crear SubBodega

TAREA Ingresar campos requeridos para la creación de la nueva

SubBodega.

Verificar si la SubBodega asignada a la bodega principal

ya ha sido registrada anteriormente.

Modificar SubBodegas.

Verificar que los campos requeridos para la modificación

de la SubBodega estén validados.



administrar, crear SubBodega.

2. Ingresar datos adicionales para la creación de la nueva

SubBodega.

3. Clic botón crear nueva SubBodega.

4. Clic botón listar SubBodegas.

5. Clic botón modificar SubBodega.

6. Clic botón actualizar.


ESPERADA

ESTADO

El administrador ingresa los campos requeridos

para la creación de la nueva SubBodega.

Si los datos

ingresados son

correctos procederá

a crear la nueva

SubBodega.

OK


para la creación de la nueva SubBodega.

Si el nombre de la

SubBodega ya está

asignada a la bodega

principal no permite

crear SubBodegas

repetidas.

OK

65

El administrador modifica los datos de la

SubBodega existente.

Actualiza los datos

de la SubBodega

existente de manera

exitosa.

OK


para la modificación de la SubBodega existente.

Si el nombre de la

SubBodega ya está

asignado a la bodega

principal no

permitirá modificar

la SubBodega.

OK


Tabla 32

Prueba de caja negra al módulo de creación de catálogos

MÓDULO Crear Catalogo

TAREA Ingresar campos requeridos para la creación de un nuevo

catálogo.

Verificar si los campos requeridos están correctamente

validados.

Modificar catálogos.


de los catálogos están validados.



administrar, crear catálogo.

2. Ingresar datos nuevos para la creación del catálogo.

3. Clic botón crear nuevo catálogo.

4. Clic botón listar catálogos.

5. Clic botón modificar catálogo.


66


ESPERADA

ESTADO

El administrador debe ingresar los campos

requeridos para la creación del nuevo catálogo.

Si los datos

ingresados son


a crear el nuevo

catálogo.

OK


para la creación del nuevo catálogo.

Si el número y

nombre de la cuenta

son correctamente

ingresados el sistema

almacena los datos

ingresados.

OK

El administrador modifica los datos del catálogo

existente.

Actualiza los datos

del catálogo

existente de manera

exitosa.

OK


para la modificación del catálogo existente.

Si el número de

cuenta y el nombre

ya están asignada a

la bodega principal

no permitirá

modificar el

catálogo.

OK


Tabla 33

Prueba de caja negra al módulo de creación de proveedores

MÓDULO Crear Proveedor

TAREA Ingresar campos requeridos para la creación de un nuevo

proveedor.


validados.

Modificar proveedor.

67


del proveedor están validados y almacenados.



registrar, nuevo proveedor.

2. Ingresar datos nuevos del proveedor para su creación.

3. Clic botón crear nuevo proveedor.

4. Clic botón listar proveedores.

5. Clic botón modificar proveedor.



ESPERADA

ESTADO

El bodeguero debe ingresar los campos requeridos

para la creación del nuevo proveedor.

Si los datos

ingresados son


a la creación del

nuevo proveedor.

OK

El bodeguero ingresa los campos requeridos para

la creación del nuevo proveedor.

Si los datos están

correctamente

ingresados en el

sistema los

almacenara los datos

caso contrario

mostrara mensajes

de aviso.

OK

El bodeguero modifica los datos de un proveedor

ya existente.

Actualiza los datos

del proveedor

existente de manera

exitosa.

OK


la modificación de un proveedor existente.

El sistema


del proveedor

existente y en caso

contrario no

OK

68


el proveedor.


Tabla 34

Prueba de caja negra al módulo de creación de áreas

MÓDULO Nueva Área

TAREA Ingresar el campo requerido para la creación de la nueva

área.

Verificar si el campo requerido está correctamente

validado.

Modificar área.

Verificar que el campo requerido para la modificación

del área está validado y almacenado.

PRERREQUISITOS El usuario debe estar registrado en la base de datos.


registrar, nueva área.

2. Ingresar el nombre del área para su creación.

3. Clic botón crear nueva área.

4. Clic botón listar áreas.

5. Clic botón modificar área.



ESPERADA

ESTADO

El bodeguero debe ingresar el campo requerido

para la creación de la nueva área.

Si el nombre del

área ingresado es

correcto procederá

a la creación de la

nueva área.

OK

69


la creación de la nueva área.

Si los datos están

correctamente

ingresados en el

sistema los


caso contrario

mostrara mensajes

de aviso.

OK

El bodeguero modifica los datos del área ya

existente.

Actualiza el nombre

del área existente de

manera exitosa. OK

El bodeguero ingresa el campo requerido para la

modificación del área existente.

El sistema


del área existente y

en caso contrario no


el área.

OK


Tabla 35

Prueba de caja negra al módulo de Ingresos

MÓDULO Nuevo Ingreso

TAREA Ingresar los campos requeridos para la creación del nuevo ingreso.

Verificar si los campos requeridos están correctamente validados

al guardar los datos.

Verificar si los campos requeridos están validados al agregar un

producto.

Verificar si el cálculo del subtotal, IVA, descuento y total son

correctos.

Verificar si el cálculo del costo promedio correspondiente al nuevo

producto o producto existente se genera de manera correcta.

Verificar si se generó el ingreso de manera correcta en el

inventario general, catalogo mensual y catalogo por bodega.


70

PASOS 1. Ingresar al sistema inventario de existencia, sección registrar,

nuevo ingreso.

2. Ingresar correctamente los campos requeridos.

3. Clic botón guardar.

4. Clic botón aceptar.

5. Clic botón agregar producto.

6. Clic botón añadir producto.

ENTRADA/ACCIÓN

DEL USUARIO

DESCRIPCIÓN SALIDA ESPERADA

El bodeguero debe

ingresar los campos

requeridos para la

creación del nuevo

ingreso.

Si los campos del

ingreso están

correctamente

ingresados se

procederá a la

creación de la

cabecera del

ingreso.

El bodeguero ingresa mal

los campos requeridos o

los deja en blanco.

Si los datos no

están

correctamente

ingresados o con

campos requeridos

en blanco se

mostrara mensajes

de aviso y no

permite guardar.

El bodeguero ingresa los

datos requeridos del

nuevo producto.

Si los campos

ingresados son

correctos se

agregara el nuevo

producto a la tabla

de detalle de

ingresos.

71

El bodeguero ingreso en

la cabecera el IVA de

12% con descuento de 0 e

ingresa 100 lápices de

valor unitario de 0.40

centavos

El sistema

almaceno y cálculo

internamente lo

siguiente:

s𝑢𝑏𝑡𝑜𝑡𝑎𝑙 =

(0,40 ∗ 100) =

40

𝑡𝑜𝑡𝑎𝑙 =

𝑠𝑢𝑏𝑡𝑜𝑡𝑎𝑙 +

(𝑠𝑢𝑏𝑡𝑜𝑡𝑎𝑙 ∗

0,12) −

(𝑠𝑢𝑏𝑡𝑜𝑡𝑎𝑙 ∗ 0)=

44,80

Una vez que el usuario o

custodio se asegura que

los productos están

ingresado de manera

correcta, procederá a

generar el ingreso en el

inventario general.

El sistema toma el

total de cada

producto para

realizar el

siguiente cálculo:

𝑝𝑟𝑜𝑚𝑒𝑑𝑖𝑜

=𝑡𝑜𝑡𝑎𝑙

100

Siempre y cuando

el catalogo

presupuestario,

presentación y

bodega sean la

misma. Ya que si

el sistema

encuentra un

registro similar lo

modifica con el

nuevo precio

promedio para

cada producto, de

otro modo creara el

nuevo ítem.

72

El usuario ingresa a los

reportes de los ingresos y

visualiza que los cambios

se hayan realizado.

El sistema registra

la siguiente

información:

Inventario general,

catálogo general y

catálogo por

bodega, en los

cuales registró y

actualizó los datos

de los productos

ingresados.

Inventario General

Catalogo general

Catalogo por bodega

73


Tabla 36

Prueba de caja negra al módulo de pedidos

MÓDULO Nuevo Pedido

TAREA Ingresar los campos requeridos para la creación del nuevo

pedido.


validados al guardar.

Verificar si el producto fue agregado al pedido.

Verificar que la cantidad de productos solicitados en el pedido

no sobrepasan los existentes en bodega.


PASOS 1. Ingresar al sistema inventario de existencia, sección registrar,

nuevo pedido.


3. Clic botón guardar.


5. Clic botón listar productos.

6. Clic botón añadir pedido.

7. Clic botón editar

ENTRADA/ACCIÓN

DEL USUARIO


El usuario debe ingresar

los campos requeridos

para la creación del

nuevo pedido.

Si los campos del

pedido están

correctamente

ingresados se

procederá a la

creación del

encabezado del

pedido.

74

El usuario ingresó mal los

campos requeridos o los

deja en blanco.

Si los datos no están

correctamente

ingresados o con

campos requeridos

en blanco, se

mostrara mensajes

de aviso y no

permite guardar.

El usuario lista los

productos y procede a

añadir al pedido actual.

Si el producto fue

añadido

correctamente se

agregaran al pedido

actual.

El usuario edita la

cantidad de productos

agregados al pedido.

El sistema permite

al usuario editar la

cantidad de

productos para su

despacho.

El usuario ingresa de

manera incorrecta o una

cantidad superior a la que

puede ser despachada.

El sistema validó

que la cantidad de

productos

solicitados se

encuentres dentro de

los lumbrales

permitidos de

despacho.

75


Tabla 37

Prueba de caja negra al módulo de egresos

MÓDULO Nuevo Egreso

TAREA Ingresar los campos requeridos para la creación del

nuevo egreso.


validados al cargar el pedido.

Verificar si el egreso se cargó correctamente.

Verificar si la cantidad de productos del pedido se puede

despachar.

Verificar si el egreso se generó correctamente en el

inventario general, inventario por bodega, catalogo

mensual y catalogo por bodega.



registrar, nuevo egreso


3. Clic botón cargar pedido

4. Clic botón editar.


6. Clic botón generar egreso.

ENTRADA/ACCIÓN

DEL USUARIO


El bodeguero debe ingresar

los campos requeridos para

la creación del nuevo

egreso.

Si los campos del

egreso están

correctamente

ingresados se

procederá a cargar

el pedido.

76

Si el bodeguero ingresa mal

el código del pedido o

ingresa mal los campos

requeridos.

Si los datos no están

correctamente

ingresados o con

campos requeridos

en blanco se

mostrara mensajes

de aviso y no

permite cargar el

pedido.

El bodeguero da clic en el

botón cargar pedido.

Si todos los datos

fueron llenados de

forma correcta el

sistema carga todos

los productos del

pedido solicitado

para su despacho.

El bodeguero edita una

mayor cantidad de productos

agregados al pedido.

El sistema permite al

bodeguero editar la

cantidad de

productos para su

despacho, si esta

cantidad es la

adecuada generara el

egreso.

El usuario ingresa una

cantidad superior a la que

puede ser despachada por el

bodeguero o edita mal el tipo

de unidades del producto.

El sistema valido

que la cantidad de

productos

solicitados se

encuentres dentro de

los umbrales

permitidos de

despacho.

77


Tabla 38

Prueba de caja negra al módulo abastecer bodega

MÓDULO Abastecer Bodega

TAREA Verificar si se enlistan los productos disponibles en la bodega.

Verificar la selección de cantidad y bodega a transferir los

productos.

Verificar la confirmación de la transferencia de productos a

otra bodega.

Verificar que la cantidad de producto de la transferencia

abasteció a la bodega designada, restando el producto de la

bodega que transfiere.

Verificar si la transferencia se registró en las transferencias por

bodega y catalogo por bodega de manera exitosa.



Abastecimientos, abastecer bodega.

2. Clic botón listar productos.

3. Clic botón abastecer bodega.


ENTRADA/ACCIÓN

DEL USUARIO


El bodeguero da clic en

el botón listar productos

para mostrar las

existencias en su

bodega.

Se listaran todos

los productos de

esa bodega en el

caso que los

tuviese.

El bodeguero ingresa la

cantidad a transferir y

selecciona la bodega a

cual se realizara la

transferencia.

Si los datos son

correctos y la

cantidad está

dentro de lo

permitido el

despacho se

78

realizara

exitosamente.

El bodeguero acepta

realizar la

transferencia hacia otra

bodega.

El sistema restara

la cantidad de la

bodega desde la

cual se realiza la

transferencia y

sumara los

productos a la

bodega

seleccionada.

El usuario después de

realizar la

transferencia verifica

en la vista de la bodega

si los cambios se

realizaron con éxito.

El sistema realiza

la transferencia y

calcula el valor de

la transferencia y

eso le suma a la

bodega de destino

también en el

catálogo mostrara

las transferencias

realizadas y

recibidas en cada

mes.

Transferencia de la bodega de salida

Catalogo de transferencia

Transferencia en la bodega destino

4.1.3. Pruebas de Estrés

En esta prueba se somete al software a condiciones de exigencias extremas y permite medir su

respuesta ante las mismas. Entre la diversidad de aplicaciones que permiten realizar este

procedimiento la mayor parte tienen una licencia de software propietaria. A continuación se

mencionara herramientas opensource de pruebas de stress para realizar la comparativa según sus

características.

79

SmartMeter.io

Permite la creación sencilla de escenarios de prueba sin scripts utilizando la llamada Grabadora,

pero aun así le permite realizar ediciones avanzadas de la prueba. También sobresale en el informe

de pruebas y hace uso de funciones como la evaluación automática de criterios de prueba, la

comparación de ejecuciones de prueba y el análisis de tendencias. Es totalmente compatible con

la integración de CI / CD. Disponible para Windows, Mac OS y Linux.

Características:

Creación de escenarios de prueba sin script

Informes completos con evaluación automática y comparación de ejecuciones de prueba

Prueba de GUI ejecutada con resultados en tiempo real

Extractor de cuerpos de respuesta de vanguardia (Extractor de cuerpos de límites)

Listo para CI / CD

Protocolos:

HTTP, JDBC, LDAP, SOAP, JMS y FTP

(Ahmedabad, 2011)[1]

80

LoadRunner

Esta es una versión de prueba de rendimiento empresarial de Loadrunner y una plataforma

habilitada tanto para la estandarización global como para el rendimiento CoE de formación.

Características:

Reducir el costo de las pruebas de carga distribuida

Pase de proyectos individuales a un Centro de Excelencia (CoE) de pruebas a gran

escala que consolida el hardware, estandariza las mejores prácticas y aprovecha los

recursos de pruebas globales.

Reduzca el riesgo de implementar sistemas que no cumplan con los requisitos de

rendimiento mediante el uso de pruebas efectivas de carga empresarial.

Reduzca los costos de hardware y software al predecir con precisión la capacidad del

sistema

Identifique la causa raíz de los problemas de rendimiento de la aplicación de forma

rápida y precisa

Seguimiento efectivo de la utilización de la herramienta.

Acceso basado en navegador a recursos de prueba globales y uso óptimo de la granja de

generadores de carga.

Protocolos:

Todos los protocolos son compatibles con Load Runner


81

Apache JMeter

JMeter es una herramienta de código abierto que se puede usar para pruebas de rendimiento y

carga para analizar y medir el rendimiento de una variedad de servicios. Estas herramientas se

utilizan principalmente para aplicaciones de servicios web y web.

Características:

Esta herramienta no exige una infraestructura de vanguardia para las pruebas de carga

y es compatible con múltiples inyectores de carga administrados por un solo controlador

Altamente portátil y compatible con el 100% de todas las aplicaciones basadas en Java.

Menos esfuerzos de scripting en comparación con otras herramientas debido a su GUI

fácil de usar las tablas y gráficos simples, suficientes para analizar estadísticas de carga

clave y monitores de uso de recursos.

Admite colectores Tomcat integrados en tiempo real para monitoreo

Protocolos

Web: HTTP, HTTPS, servicios web: XML, SOAP, etc., protocolos basados en Java, FTP


82

Comparación de Herramientas

Con las distintas herramientas mencionadas es necesario realizar una comparativa que permitan

cumplir el objetivo de las pruebas tomando las siguientes características que se utilizaron para la

selección, mencionadas a continuación

Tipo de licencia

Sistema operativo soportado por la herramienta para su instalación

Número máximo de conexiones permitidas

Tipo de reportes proporcionados por la herramienta.

En la Tabla 39 se resumen los resultados obtenidos en dichas características.

Tabla 39

Herramientas de pruebas de stress

Herramienta Licencia Sistema

Operativo

Conexiones

Soportadas

Formato de

Reportes

LoadRunner Opensource Windows XP o

superior

30.000 Texto y gráfico.

JMeter Opensource Cualquier SO

con Java

80.000 Texto y

gráfico(limitada)

SmartMeter.io Opensource Windows XP o

superior

50000 Grafico

De acuerdo con las características cualitativas observadas en la Tabla 39, se decidió usar la

herramienta de apache JMeter, ya que es una herramienta que permite obtener resultados en base

a la concurrencia de usuario que van a acceder al Sistema Inventario de Existencias.

83

Escenario para pruebas

Para la simulación de concurrencia de usuarios accediendo al sistema simultáneamente, se tomó

en cuenta las siguientes características de software y hardware mencionadas a continuación:

Computador Intel Core i5 de 2,40Ghz

Memoria RAM 6 GB

Sistema Operativo Windows 10 pro de 64bits.

Navegador google Chrome 62.0.3202.62.

Resultados obtenidos

En el siguiente escenario simula el acceso de 5 usuarios simultáneos a todos los módulos

existentes durante 50 repeticiones de 1 segundo por cada clic.

Ilustración 6: Pantalla de configuración JMeter

Como se observa en la Ilustración 6. Se puede especificar el número de hilos en paralelo, así

como el tiempo de arranque de cada uno, y un número de iteraciones que hará cada uno de ellos.

84

También podemos planificar la ejecución de la prueba indicando la hora de arranque y parada, o

la duración del test en segundos y el tiempo de arranque del mismo.

JMeter posee dos tipos de controladores:

Agentes de pruebas: Permiten enviar peticiones http desde la herramienta hacia el servidor.

Controladores de lógica: Permite controlar el comportamiento de la prueba, y tomar

decisiones en función de situaciones.

A continuación se muestra información obtenida por la concurrencia simultánea de las

peticiones http realizadas al servidor de la aplicación.

Ilustración 7: Resumen de reporte de pruebas

85

Para una mejor descripción de la Ilustración 14, se describen los parámetros utilizados por la

herramienta, proporcionando un resumen de la simulación finalizada.

Tabla 40

Descripción de campos JMeter

CAMPO DESCRIPCIÓN

Label Nombre de la muestra

Numero de Muestras El número de muestras para cada URL.

Tiempo de Inicio Hora completa de inicio de cada prueba en el sistema

Media El tiempo medio transcurrido para un conjunto de resultados.

Mín El mínimo tiempo transcurrido para las muestras de la URL dada.

Máx El máximo tiempo transcurrido para las muestras de la URL dada.

Error % Porcentaje de las peticiones con errores.

Rendimiento Rendimiento medido en base a peticiones por segundo/minuto/hora.

Kb/sec Rendimiento medido en Kilobytes por segundo.

Avg. Bytes Tamaño medio de la respuesta de la muestra medido en bytes.

Estado Estado de aprobación o desaprobación de la prueba en el sistema

Latencia Retardo de la prueba en pasar los datos en el sistema

En la prueba se observó un total de 15000 muestras, con un promedio de retardo de dos

segundos entre la finalización de un módulo e inicio de otro, también la aprobación correcta de

cada módulo. Indicando que el sistema responde correctamente a la prueba de stress de 5 usuarios

interactuando con el sistema cada segundo durante 50 repeticiones, creando latencia de respuesta

de bytes normal pero sin caer o colapsar el sistema.

86

A continuación se muestra una gráfica de resultados de la totalidad de las funcionalidades que

posee el sistema:

Ilustración 8: Gráfica de resultados JMeter.

El gráfico ejemplifica que para un número de No. De Muestra de 15000 peticiones al servidor,

se obtuvo una Desviación de 1034, una última Muestra de 8, un rendimiento de 2.271,867/minuto

y una media de 342.

87

4.2. Conclusiones

1. Dada las necesidades observadas se mejoró la manera en que los bodegueros llevan el

control de inventarios y almacenamiento de la información.

2. Se centraliza el manejo y uso de la información en el sistema para que la Universidad

Central del Ecuador pueda llevar un control en la designación de presupuesto asignado

a cada facultad, para la adquisición de activos no depreciables.

3. Con la generación de reportes que brinda el sistema las autoridades de la universidad

podrán tomar decisiones más acordes para el uso y manejo de los bienes no

depreciables.

4. Debido a que en la construcción del sistema apareció un nuevo proceso que no estuvo

considerado en la levantamiento de información, el sistema no cubre el modulo

correspondiente a las devoluciones de insumos.

5. Existen insumos no depreciables que tienen caducidad y para evitar que estos insumos

sean dados de baja por estos motivos el sistema cuenta con alertas que le avisaran al

usuario con anticipación para que este tome las medidas correspondientes.

88

4.2. Recomendaciones

1. Se recomienda acorde a lo mencionado en el punto 4 de las conclusiones, incorporar un

módulo de devoluciones de productos, para los usuarios que acceden a los mismos, en caso

que por motivos administrativos tenga que regresar a manos del custodio encargado de

cada bodega.

2. Debido a que existe flujo de funcionarios que rotan en sus actividades en la universidad, el

sistema cuenta con los debidos manuales de respaldo para que los nuevos empleados

cuenten con esta información, se recomienda el uso de los manuales elaborados para su

correcto uso.

3. Como el sistema no cuenta con un sistema de respaldos automáticos, es recomendable que

la Dirección de Tecnología de la Universidad Central del Ecuador realice estas actividades

de forma programada para precautelar la integridad y almacenamiento de la información

que genere el sistema inventario de existencias.

89

BIBLIOGRAFÍA

1. Ahmedabad, G. (2011). Guru99 Tech Pvt Ltd. Recuperado de

https://www.guru99.com/performance-testing-tools.html

2. Cadena, R. (2016). Arquitectura de proyectos JEE. Quito, Pichincha, Ecuador.

3. Cevallos, K. (2015). INGENIERÍA DEL SOFTWARE. Recuperado de

https://ingsotfwarekarlacevallos.wordpress.com/2015/05/08/metodologia-de-desarrollo-

agil-xp-y-scrum/

4. EcuRed. (2016). Recuperado de

https://www.ecured.cu/index.php?title=Caso_de_uso&oldid=2612478

5. Ever, A. (2018). Diferenciador. Recuperado de

https://www.diferenciador.com/diferencia-entre-metodo-inductivo-y-deductivo/

6. Hernández, R., Fernández C, & Baptista, P. (2000). Metodología de la investigación.

México: 2da. Edición. Mc Graw Hill.

7. Hommel, S. (1999). Convenciones de Código para el lenguaje de programación JAVA™.

8. Joskowicz, I. J. (2008 ). Reglas y Prácticas en eXtreme Programming .

9. Letelier, P. (2006). Ciencia y Técnica Administrativa. Recuperado de

http://www.cyta.com.ar/ta0502/v5n2a1.htm#11

10. Pressman, R. (2002). Ingeniería de Software: Un enfoque práctico. Madrid: McGrawHill.

90

11. Valladarez, S. M., Gaitan, M. E., & Reyes, N. N. (2016). Metodologia Ágil de Desarrollo

de Software Programaciòn. Managua. Recuperado de

http://repositorio.unan.edu.ni/1365/1/62161.pdf

12. Virginia Dra, A. d. (1996). Metodología de la Investigación Científica. Tacna, Perú:

Sierra Lombardía.

13. Wells, D. (1999). The Rules of Extreme Programming. Extreme Programing, 1.

91

ANEXOS

92

ANEXO A:

DICCIONARIO DE LA BASE DE DATOS

DESCRIPCIÓN DE LAS TABLAS Y SUS ATRIBUTOS.

Tabla: ROL.

Tabla Nombre Descripción Tipo Dato Obligatorio Clave

Primaria

rol_id Identificador

del rol

Integer Si Si

rol_nombre Nombre del

rol.

VarChar(2

0)

No No

Tabla: USUARIO

Tabla Nombre Descripción Tipo

Dato Obligatorio

Clave

Primaria

usr_id Identificador

del usuario Integer Si Si

usr_cedula

Número de

cedula del

usuario.

VarChar(2

0) No

No

usr_usuario

Usuario

utilizado en

el sistema.

VarChar(2

0) No No

usr_passwor

d

Contraseña

de ingreso.

VarChar(2

0) No No

ROL

rol_id

rol_nombre

USUARIO

usr_id

usr_cedulausr_usuariousr_password

93

Tabla ROL_USUARIO

Tabla Nombre Descripción Tipo Dato Obligat

orio

Clave

Primaria

rous_id

Identificador

de la tabla

rol_usuario

Integer Si Si

rol_id Identificador

del rol. Integer Si

No

usr_id Identificador

del usuario. Integer Si No

usro_descrip

cion

Descripción

del usuario VarChar(20) No No

Tabla SUB_BODEGA


orio

Clave

Primar

ia

subo_id

Identificador

de la tabla de

sub-bodega

Integer Si Si

subo_nombre Nombre de la

sub-bodega VarChar(20) No

No

bdg_id Identificador

de la bodega. Integer Si No

sbbd_descrip

cion

Descripción de

la sub-bodega VarChar(20) No No

Tabla BODEGA

Tabla Nombre Descripción Tipo Dato Obligato

rio

Clave

Primaria

bdg_id

Identificador

de la tabla de

bodega

Integer Si Si

ROL_USUARIO

rous_id

rol_id (FK)usr_id (FK)usro_descripcion

SUB_BODEGA

subo_id

subo_nombrebdg_id (FK)sbbd_descripcion

94

bdg_nombre Nombre de la

bodega

VarChar(20

) No

No

sbbd_descrip

cion

Descripción de

la bodega

VarChar(20

) No No

Tabla CATALOGO_BODEGA


Dato

Obligat

orio

Clave

Primaria

ctbd_id

Identificador de

la tabla de

catalogo_bodeg

a

Date Si Si

ctbd_ingres

os

Cuenta para

realizar los

ingresos

VarChar(1

8) No

No

ctbd_egreso

s

Cuenta para

realizar los

egresos

VarChar(1

8) No No

ctbd_transf

erencia_sali

da

Nombre de la

transferencia de

salida.

VarChar(1

8) No No

ctbd_transf

erencia_des

tino

Nombre de la

transferencia

hacia el destino.

VarChar(1

8) No No

ctbd_saldo_

inicial

Saldo inicia de

la cuenta.

VarChar(1

8) No No

ctbd_total_

mes Total del mes.

VarChar(1

8) No No

ctbd_bodeg

a

Nombre de la

bodega.

VarChar(1

8) No No

ctbd_catalo

go

Nombre del

catálogo.

VarChar(1

8) No No

ctbd_fecha

Fecha de

consulta por

catálogo.

VarChar(1

8) No No

bdg_id Identificador de

bodega. Integer Si No

BODEGA

bdg_id

bdg_nombrebdg_descripcion

CATALOGO_BODEGA

ctbd_id

ctbd_ingresosctbd_egresosctbd_transferencia_salidactbd_transferencia_destinoctbd_saldo_inicialctbd_total_mesctbd_bodegactbd_catalogoctbd_fechabdg_id (FK)

95

Tabla CATALOGO_MENSUAL


orio

Clave

Primar

ia

ctmn_id

Identificador de

la tabla de

catalogo_mensu

al

VarChar(18) Si Si

ctmn_ingresos

Cuenta para

realizar los

ingresos

mensuales.

VarChar(18) No No

ctmn_saldo_in

icial

Saldo inicia de

la cuenta por

mes.

VarChar(18) No No

ctmn_total_ing

resos

Cuenta total de

los ingreso por

mes.

VarChar(18) No No

ctmn _egresos

Cuenta para

realizar los

egresos por

mes.

VarChar(18) No No

ctmn_total_me

s Total del mes. VarChar(18) No No

ctmn_fecha

Total fecha de

la consulta por

mes.

VarChar(18) No No

bdg_id Identificador de

la bodega. Integer No No

Tabla ROL_BODEGA_FLUJO

CATALOGO_MENSUAL

ctmn_id

ctmn_ingresosctmn_saldo_inicialctmn_total_ingresosctmn_egresosctmn_total_mesctmn_fechabdg_id (FK)

96


orio

Clave

Primaria

robdf_id

Identificador

de la tabla de

rol_bodega_fl

ujo

VarChar(18) Si Si

robdf_descri

pcion

Descripción de

la tabla

rol_bodega_fl

ujo

VarChar(18) No No

subo_id

Identificador

de la sub-

bodega.

Integer No No

roflfc_id

Identificador

de la tabla

rol_flujo_facul

tad

Integer No No

Tabla ROL_FLUJO_FACULTAD


rio

Clave

Primaria

roflfc_id

Identificador

de la tabla

rol_flujo_facul

tad.

Integer Si Si

fcl_id Identificador

de facultad. Integer No

No

rous_id Identificador

de rol_usuario. Integer No No

roflfc_descri

pcion

Descripción de

la tabla

rol_flujo_facul

tad

VarChar(18

) No No

ROL_BODEGA_FLUJO

robdfl_id

robdfl_descripcionsubo_id (FK)roflfc_id (FK)

ROL_FLUJO_FACULTAD

roflfc_id

fcl_id (FK)rous_id (FK)roflfc_descripcion

97

Tabla DEPENDENCIA


rio

Clave

Primaria

dpn_id

Identificador

de la tabla

dependencias.

Integer Si Si

fcl_nombre Nombre de la

dependencia.

VarChar(20

) No No

Tabla DETALLE_PEDIDO


orio

Clave

Primaria

dtpd_id

Identificador del

detalle del

pedido.

Char(18) Si Si

dtpd_nombre Nombre del

producto.

VarChar(20

) No

No

dtpd_cantida

d

Cantidad a

solicitar. Integer No No

dtpd_valor_u

nitario

Valor unitario

del producto. Integer No No

dtpd_id_inve

ntario

Numero de

código del

producto.

Integer No No

dtpd_catalog

o

Nombre de la

cuenta en el

pedido.

Char(18) No No

dtpd_present

acion

Tipo de

unidades. Char(18) No No

cbpd_id

Identificador de

la cabecera del

pedido.

Integer No No

DEPENDENCIA

dpn_id

dpn_nombre

DETALLE_PEDIDO

dtpd_id

dtpd_nombredtpd_cantidaddtpd_valor_unitariodtpd_id_inventariodtpd_catalogodtpd_presentacioncbpd_id (FK)

98

Tabla CABECERA_PEDIDO

Tabla Nombre Descripción Tipo Dato Oblig

atorio

Clave

Primaria

cbpd_id

Identificador de

la cabecera del

pedido.

Integer Si Si

cbpd_fecha

Fecha de

ingreso del

pedido.

Date No No

cbpd_respon

sable

Responsable de

realizar el

pedido.

VarChar(20) No No

cbpd_entrega

do

Quien realiza el

pedido. VarChar(20) No No

cbpd_descrip

cion

Descripción

opcional del

pedido

Char(18) No No

robdf_id

Identificador de

la tabla

rol_bodega_fluj

o.

Integer No No

CABECERA_PEDIDO

cbpd_id

cbpd_fecha

cbpd_responsable

cbpd_entregado

cbpd_descripcion

robdfl_id (FK)

99

Tabla DETALLE_EGRESO


orio

Clave

Primaria

dteg_id

Identificador del

detalle del

egreso.

Char(18) Si Si

dteg_nombre Nombre del

producto.

VarChar(20

) No

No

dteg_cantida

d

Cantidad a

despachar. Integer No No

dteg_valor_u

nitario

Valor unitario

del producto. Integer No No

dteg_valor_t

otal

Valor total de

todos los

productos.

Integer No No

cbeg_id

Identificador de

la tabla de

cabecera_egreso

Integer No No

inv_id

Identificador de

la tabla

inventario.

Integer No No

Tabla CABECERA_EGRESO


orio

Clave

Primaria

cbeg_id

Identificador de

la cabecera del

egreso.

Integer Si Si

cbeg_codigo

Código del

pedido para

realizar el

egreso.

VarChar(20

) No No

cbeg_fecha

Fecha de

despacho del

pedido.

Date No No

DETALLE_EGRESO

dteg_id

dteg_nombre

dteg_cantidad

dteg_valor_unitario

dteg_valor_total

cbeg_id (FK)

inv_id (FK)

CABECERA_EGRESO

cbeg_id

cbeg_codigo

cbeg_fecha

cbeg_responsable

cbeg_entregado

cbeg_descripcion

cbeg_total_egreso

fk_area_are_cbeg_cabecera (FK)

robdfl_id (FK)

cbeg_id_pedido

100

cbeg_respons

able

Responsable de

realizar el

egreso.

VarChar(20

) No No

cbeg_entrega

do

Quien realiza el

pedido.

VarChar(20

) No No

cbeg_descrip

cion

Descripción

opcional del

egreso

VarChar(20

) No No

cbeg_total_e

greso

Suma total del

egreso. Integer No No

fk_area_are_

cbeg_cabecer

a

Llave foránea

de la tabla

cabecera_egreso

Integer No No

robdf_id

Identificador de

la tabla

rol_bodega_fluj

o.

Char(18) No No

cbeg_id_pedi

do

Identificador de

la table pedidos Char(18) No No

Tabla AREA


rio

Clave

Primaria

are_id Identificador

de área. Integer Si

Si

are_nombre Nombre del

área.

VarChar(20

) No No

bdg_id

Identificador

de la tabla

bodega.

Integer No No

Tabla TRANSFERENCIAS


Dato

Obli

gatorio

Clave

Primaria

trn_id

Identificador

de

transferencias.

Char(18) Si Si

AREA

are_id

are_nombre

bdg_id (FK)

101

trn_bodeg

a_salida

Nombre de la

bodega de

salida.

Char(18) No No

trn_bodeg

a_destino

Nombre de la

bodega de

destino.

Char(18) No No

trn_produ

cto

Nombre de

producto. Char(18) No No

trn_cantid

ad

Cantidad a

transferir. Char(18) No No

trn_costo

Total del

costo de la

transferencia.

Char(18) No No

bdg_id

Identificador

de la tabla de

bodega.

integer No No

Tabla INVENTARIO


Dato

Obligat

orio

Clave

Primar

ia

inv_id Identificador de

inventario. Char(18) Si Si

inv_nombre Nombre del

inventario. Char(18) No

No

inv_cantidad Cantidad total. Char(18) No No

inv_tipo_item

Tipo de

producto

ingresado.

Char(18) No No

inv_caducidad Caducidad

existente. Char(18) No No

TRANSFERENCIAS

trn_id

trn_bodega_salida

trn_bodega_destino

trn_producto

trn_cantidad

trn_costo

bdg_id (FK)

INVENTARIO

inv_id

inv_nombre

inv_cantidad

inv_tipo_item

inv_caducidad

inv_fecha_caducidad

inv_fecha_ingreso

inv_valor_unitario

inv_valor_total

inv_catalogo

inv_nombre_bodega

bdg_id (FK)

102

inv_fecha_caducid

ad

Fecha de

caducidad del

producto.

Char(18) No No

inv_fecha_ingreso Fecha de

ingreso. Char(18) No No

inv_valor_unitario Valor unitario

del producto. Char(18) No No

inv_valor_total Valor total del

ingreso. Char(18) No No

inv_catalogo Tipo de cuenta

del producto. Char(18) No No

inv_nombre_bodeg

a

Nombre de la

bodega. Char(18) No No

bdg_id

Identificador de

la tabla de

bodega.

Integer No No

Tabla DETALLE_INGRESO


orio

Clave

Primar

ia

dtin_id

Identificador del

detalle del

ingreso.

Char(18) Si Si

dtin_nombre Nombre del

producto. VarChar(20) No

No

dtin_cantidad Cantidad a

ingresar. Integer No No

dtin_caducid

ad

Caducidad en el

producto, VarChar(20) No No

dtin_fecha_c

aducidad

Fecha de

caducidad del

producto.

Date No No

dtin_valor_u

nitario

Valor unitario del

producto. Integer No No

dtin_valor_to

tal

Valor total de

todos los

productos.

Integer No No

fk_tipo_ing_t

pin_dti_detal

le

Llave foránea de

la tabla

detalle_ingresoo

Integer No No

DETALLE_INGRESO

dtin_id

dtin_nombre

dtin_cantidad

dtin_caducidad

dtin_fecha_caducidad

dtin_valor_unitario

dtin_valor_total

fk_tipo_ing_tpin_dti_detalle_ (FK)

ctl_id (FK)

cbin_id (FK)

sbbd_id (FK)

103

ctl_id Identificador de

la tabla catálogo. Interger No No

cbin_id

Identificador de

la tabla

cabecera_ingreso

Integer No No

sbbd_id Identificador de la

tabla sub-bodega. Integer No No

Tabla CABECERA_INGRESO


rio

Clave

Primar

ia

cbin_id

Identificador de

la cabecera del

ingreso.

Integer Si Si

cbin_codi

go

Código del

ingreso. VarChar(20) No No

cbin_fech

a

Fecha de

ingreso. Date No

No

cbin_num

ero_factur

a

Número de la

factura. VarChar(20) No No

cbin_desc

ripcion

Descripción

opcional del

ingreso

VarChar(20) No No

cbin_resp

onsable

Responsable de

realizar el

ingreso.

VarChar(20) No No

cbeg_total

_ingreso

Suma total del

ingreso. Integer No No

fk_area_ar

e_cbin_ca

becera

Llave foránea

de la tabla

cabecera_egreso

Integer No No

cbin_iva Iva de los

productos Char(18) No No

cdin_desc

uento

Descuento del

producto. Char(18) No No

robdf_id Identificador de

la tabla Char(18) No No

CABECERA_INGRESO

cbin_id

cbin_codigo

cbin_fecha

cbin_numero_factura

cbin_descripcion

cbin_responsable

cbin_total_ingreso

fk_proveedo_prv_cbin_cabecera (FK)

cbin_iva

cbin_descuento

robdfl_id (FK)

104

rol_bodega_fluj

o

Tabla PROVEEDOR

Tabla Nombre Descripción Tipo Dato Oblig

atorio

Clave

Primaria

prv_id Identificador de

proveedores. Integer Si Si

prv_ruc RUC del

proveedor. VarChar(18) No

No

prv_nombre Nombre del

proveedor. VarChar(18) No No

prv_direccio

n

Dirección del


prv_telefono Teléfono del


prv_mail

Correo

electrónico del

proveedor.

VarChar(18) No No

bdg_id

Identificador de

la tabla de

bodega.

Integer No No

PROVEEDOR

prv_id

prv_ruc

prv_nombre

prv_direccion

prv_telefono

prv_mail

bdg_id (FK)

105

Tabla TIPO_INGRESO


orio

Clave

Primaria

tpin_id

Identificador

de tipo de

ingreso.

Integer Si Si

tpin_nombre

Nombre del

tipo de

ingreso.

VarChar(20) No No

Tabla CATALOGO


rio

Clave

Primaria

ctl_id Identificador

de catálogo. Integer Si

Si

ctl_codigo Código del

catálogo.

VarChar(20

) No No

ctl_nombre Nombre del

catálogo.

VarChar(20

) No No

TIPO_INGRESO

tpin_id

tpin_nombre

CATALOGO

ctl_id

ctl_codigo

ctl_nombre

universidad central del ecuador facultad de …€¦ · padres alejandro cárdenas y patricia lara...

Documents