UNIVERSIDAD MAYOR DE SAN ANDRÉS

FACULTAD DE CIENCIAS PURAS Y NATURALES

CARRERA DE INFORMÁTICA

PROYECTO DE GRADO
“SISTEMA WEB DE ADMINISTRACIÓN Y CONTROL DEL
ALMACENAMIENTO DE ARTÍCULOS EN EL ALMACÉN
CENTRAL Y EN SUBALMACENES
CASO: GOBIERNO AUTÓNOMO MUNICIPAL DE EL ALTO”

PARA OPTAR AL TÍTULO DE LICENCIATURA EN INFORMÁTICA

MENCIÓN: INGENIERÍA DE SISTEMAS INFORMÁTICOS

POR: JOSUE OSCAR ESPEJO QUENTA

TUTOR METODOLÓGICO: [Link]. GROVER ALEX RODRÍGUEZ RAMÍREZ

ASESOR: PH.D. YOHONI CUENCA SARZURI

LA PAZ - BOLIVIA
2020
 UNIVERSIDAD MAYOR DE SAN ANDRÉS
FACULTAD DE CIENCIAS PURAS Y
NATURALES CARRERA DE INFORMÁTICA

LA CARRERA DE INFORMÁTICA DE LA FACULTAD DE CIENCIAS PURAS

Y NATURALES PERTENECIENTE A LA UNIVERSIDAD MAYOR DE SAN
ANDRÉS AUTORIZA EL USO DE LA INFORMACIÓN CONTENIDA EN ESTE
DOCUMENTO SI LOS PROPÓSITOS SON ESTRICTAMENTE ACADÉMICOS.

LICENCIA DE USO

El usuario está autorizado a:

a) Visualizar el documento mediante el uso de un ordenador o dispositivo móvil.

b) Copiar, almacenar o imprimir si ha de ser de uso exclusivamente personal y privado.
c) Copiar textualmente parte(s) de su contenido mencionando la fuente y/o haciendo
la referencia correspondiente respetando normas de redacción e investigación.

El usuario no puede publicar, distribuir o realizar emisión o exhibición alguna de este

material, sin la autorización correspondiente.

TODOS LOS DERECHOS RESERVADOS. EL USO NO AUTORIZADO DE

LOS CONTENIDOS PUBLICADOS EN ESTE SITIO DERIVARA EN EL
INICIO DE ACCIONES LEGALES CONTEMPLADOS EN LA LEY DE
DERECHOS DE AUTOR.

i
 Dedicatoria

A Dios, por darme la vida llena de salud

hasta ahora, por fortalecerme en
momentos de dificultad y adversidad,
iluminando mi camino a cada momento y
abrirme las puertas a oportunidades de
aprendizaje.

A mis padres Braulio Espejo e Hilaria

Quenta, quienes me apoyaron día a día en
cada etapa de mi vida, me dieron
consejos de gran valor, me enseñaron
valores y por darme todo su amor.

ii
 Agradecimientos

Agradecer primeramente a Dios por protegerme y guiarme en mi vida, llenarme de

ánimos cuando estaba cansado y por darme el discernimiento suficiente para tomar
las decisiones más acertadas para mi vida.

A mi familia que siempre me apoyo, mi padre Braulio Espejo una persona trabajadora
quien me enseño que la clave del éxito es el esfuerzo constante y la confianza en Dios,
mi madre Hilaria Quenta que siempre creyó en mí y me enseño que la empatía hacia
las demás personas y seguir siempre mis sueños y mi hermana Jeannine Espejo quien
es mi ejemplo a seguir quien me enseñó a dar todo de mi si quiero lograr algo.

Agradecer a mi tutor metodológico [Link]. Grover Alex Rodríguez Ramírez, por su

paciencia y su dedicación, no solo como tutor sino como persona.

Dar mis agradecimientos también a mi Asesor Ph.D. Yohoni Cuenca Sarzuri, una
persona llena de inteligencia y de sabios consejos, quien dedico su tiempo a la ayuda
del desarrollo de este proyecto de grado desde el inicio hasta el final.

A la unidad de sistemas del Gobierno Autónomo Municipal de El Alto, por ser unas
personas muy amables y darme la oportunidad de desarrollar este proyecto.

A todas las personas que lograron que la universidad sea un lugar muy agradable, a
Andrea Belén por sus consejos, por acompañarme y guiarme en cada año de la
carrera y ayudarme siempre a conseguir llegar más lejos, a Ericka, Gunar, Rous,
Boris, Jorge y todos con los cuales compartí experiencias para recordar.

A los chicos del centro de estudiantes, donde podíamos despejarnos del estrés de la
universidad y pasar un buen momento con su compañía.

iii
 ÍNDICE

1. CAPÍTULO I MARCO REFERENCIAL ............................................................ 18

1.1. INTRODUCCIÓN .................................................................................................. 18

1.2. PLANTEAMIENTO DEL PROBLEMA ............................................................. 19

1.2.1. ANTECEDENTES DEL PROBLEMA ............................................................. 19

1.2.2. TRABAJOS SIMILARES .................................................................................. 20

1.2.3. FORMULACIÓN DEL PROBLEMA............................................................... 21

1.2.4. PROBLEMAS SECUNDARIOS ........................................................................ 21

1.3. DEFINICIÓN DEL OBJETIVO........................................................................... 22

1.3.1. OBJETIVO GENERAL...................................................................................... 22

1.3.2. OBJETIVOS ESPECÍFICOS ............................................................................ 22

1.4. JUSTIFICACIÓN .................................................................................................. 22

1.4.1. JUSTIFICACIÓN SOCIAL ............................................................................... 22

1.4.2. JUSTIFICACIÓN ECONÓMICA ..................................................................... 23

1.4.3. JUSTIFICACIÓN TECNOLÓGICA ................................................................ 23

1.5. ALCANCES Y LÍMITES ...................................................................................... 24

1.5.1. ALCANCES ......................................................................................................... 24

1.5.2. LÍMITES .............................................................................................................. 24

1.6. DISEÑO METODOLÓGICO ............................................................................... 25

2. CAPÍTULO II MARCO TEÓRICO .................................................................... 26

2.1. MARCO INSTITUCIONAL ................................................................................. 26

2.1.1. VISIÓN ................................................................................................................. 26

2.1.2. MISIÓN ................................................................................................................ 26

2.1.3. ORGANIGRAMA ............................................................................................... 26

2.1.4. UNIDAD DE ALMACENES .............................................................................. 26

iv
2.2. METODOLOGÍA DE DESARROLLO ............................................................... 27

2.2.1. METODOLOGÍAS AGILES Y WEB ............................................................... 27

2.2.2. METODOLOGÍA SCRUM ................................................................................ 28

2.2.3. ROLES SCRUM .................................................................................................. 29

[Link]. PRODUCT OWNER ........................................................................................ 29

[Link]. SCRUM MASTER ........................................................................................... 30

[Link]. SCRUM TEAM................................................................................................. 30

2.2.4. ARTEFACTOS DE SCRUM ............................................................................. 31

[Link]. PILA DEL PRODUCTO.................................................................................. 32

[Link]. PILA DEL SPRINT .......................................................................................... 32

[Link]. INCREMENTO ................................................................................................ 33

2.2.5. EVENTOS DE SCRUM ...................................................................................... 33

2.2.6. FASES DE SCRUM ............................................................................................ 34

[Link]. PRE GAME ....................................................................................................... 34

[Link]. GAME ................................................................................................................ 34

[Link]. POST GAME .................................................................................................... 35

2.3. INGENIERÍA WEB ............................................................................................... 35

2.3.1. METODOLOGÍA UML-BASED WEB ENGINEERING (UWE) ................. 35

2.3.2. REQUISITOS DE UWE ..................................................................................... 36

2.3.3. ETAPAS DE UWE .............................................................................................. 36

[Link]. MODELO DE CASOS DE USO ..................................................................... 37

[Link]. MODELO DE CONTENIDO .......................................................................... 37

[Link]. MODELO NAVEGACIONAL ........................................................................ 38

[Link]. MODELO DE PRESENTACIÓN ................................................................... 38

[Link]. MODELO DE PROCESOS ............................................................................. 39

v
2.4. TECNOLOGÍA DE SOFTWARE ........................................................................ 40

2.4.1. FRAMEWORK ................................................................................................... 40

2.4.2. BACKEND ........................................................................................................... 41

2.4.3. LARAVEL ........................................................................................................... 41

2.4.4. BOOTSTRAP 4 ................................................................................................... 41

2.5. TEMAS RELACIONADOS .................................................................................. 41

2.5.1. INVENTARIOS ................................................................................................... 41

2.5.2. MÉTODO P.E.P.S. .............................................................................................. 42

2.6. CALIDAD DE SOFTWARE - NORMA ISO 9126 ............................................. 42

2.6.1. FUNCIONALIDAD ............................................................................................. 43

2.6.2. CONFIABILIDAD .............................................................................................. 44

2.6.3. USABILIDAD ...................................................................................................... 44

2.6.4. EFICIENCIA ....................................................................................................... 45

2.6.5. MANTENIBILIDAD........................................................................................... 45

2.6.6. PORTABILIDAD ................................................................................................ 46

2.7. COSTOS Y BENEFICIOS .................................................................................... 46

2.7.1. MODELO COCOMO II ..................................................................................... 46

[Link]. ESTIMACIÓN DE ESFUERZO ..................................................................... 48

[Link]. MÉTRICAS DE SOFTWARE ........................................................................ 48

2.8. SEGURIDAD .......................................................................................................... 50

2.8.1. SEGURIDAD DE LA INFORMACIÓN ........................................................... 50

2.8.2. SEGURIDAD INFORMÁTICA ........................................................................ 51

3. CAPÍTULO III MARCO APLICATIVO ............................................................ 52

3.1. INTRODUCCIÓN .................................................................................................. 52

3.2. APLICACIÓN DE LAS DOS METODOLOGÍAS ............................................. 52

vi
3.3. PRE – GAME ......................................................................................................... 53

3.3.1. PLANEAMIENTO .............................................................................................. 53

3.3.2. CLASIFICACIÓN DE USUARIO Y ROLES .................................................. 54

3.3.3. HISTORIAS DE USUARIO ............................................................................... 55

3.3.4. PILA DEL PRODUCTO .................................................................................... 66

3.3.5. REQUERIMIENTOS DE HARDWARE Y SOFTWARE .............................. 69

3.4. GAME ..................................................................................................................... 69

3.4.1. SPRINT 0 ............................................................................................................. 69

[Link]. PLANIFICACIÓN............................................................................................ 70

[Link]. DESARROLLO ................................................................................................ 70

[Link]. PRUEBAS.......................................................................................................... 74

3.4.2. SPRINT 1 ............................................................................................................. 75

[Link]. PLANIFICACIÓN............................................................................................ 75

[Link]. DESARROLLO ................................................................................................ 76

[Link]. PRUEBAS.......................................................................................................... 84

3.4.3. SPRINT 2 ............................................................................................................. 85

[Link]. PLANIFICACIÓN............................................................................................ 85

[Link]. DESARROLLO ................................................................................................ 86

[Link]. PRUEBAS.......................................................................................................... 94

3.4.4. SPRINT 3 ............................................................................................................. 94

[Link]. PLANIFICACIÓN............................................................................................ 95

[Link]. DESARROLLO ................................................................................................ 96

[Link]. PRUEBAS........................................................................................................ 104

3.4.5. SPRINT 4 ........................................................................................................... 104

[Link]. PLANIFICACIÓN.......................................................................................... 104

vii
[Link]. DESARROLLO .............................................................................................. 105

[Link]. PRUEBAS........................................................................................................ 111

3.5. POST GAME ........................................................................................................ 112

3.5.1. PRUEBAS DE INTEGRACIÓN ...................................................................... 112

3.5.2. PRUEBAS DE ACCESO DE USUARIOS ...................................................... 113

3.5.3. DISEÑO DE INTERFACES ............................................................................ 114

4. CAPÍTULO IV MÉTRICAS DE CALIDAD .................................................... 132

4.1. INTRODUCCIÓN ................................................................................................ 132

4.2. FACTORES DE CALIDAD ISO 9126 ............................................................... 132

4.2.1. FUNCIONALIDAD ........................................................................................... 133

4.2.2. CONFIABILIDAD ............................................................................................ 140

4.2.3. USABILIDAD .................................................................................................... 142

4.2.4. MANTENIBILIDAD......................................................................................... 142

4.2.5. PORTABILIDAD .............................................................................................. 143

4.2.6. CALIDAD GLOBAL ........................................................................................ 144

5. CAPÍTULO V EVALUACIÓN DE COSTO Y BENEFICIO ......................... 146

5.1. INTRODUCCIÓN ................................................................................................ 146

5.2. ANÁLISIS DE COSTOS - COCOMO II ........................................................... 146

5.2.1. ESTIMACIÓN DE ESFUERZO ...................................................................... 146

5.2.2. COSTO DE SOFTWARE................................................................................. 148

[Link]. COSTO DE ELABORACIÓN DEL PROYECTO...................................... 149

[Link]. COSTO DE IMPLEMENTACIÓN DEL PROYECTO ............................. 149

[Link]. COSTO TOTAL ............................................................................................. 149

5.3. CALCULO DE VALOR ACTUAL NETO – VAN ........................................... 150

5.4. RELACIÓN COSTO BENEFICIO .................................................................... 151

viii
6. CAPÍTULO VI SEGURIDAD DE SISTEMA ................................................... 152

6.1. NIVEL FÍSICO .................................................................................................... 152

6.2. NIVEL LÓGICO .................................................................................................. 152

6.2.1. AUTENTICACIÓN DE USUARIOS .............................................................. 153

6.2.2. ENCRIPTACIÓN DE DATOS ........................................................................ 153

6.2.3. PROTECCIÓN POR PETICIONES GET ..................................................... 153

6.2.4. SEGURIDAD EN LA BASE DE DATOS ....................................................... 154

7. CAPÍTULO VII CONCLUSIONES Y RECOMENDACIONES .................... 155

7.1. CONCLUSIONES ................................................................................................ 155

7.2. RECOMENDACIONES ...................................................................................... 156

BIBLIOGRAFÍA .............................................................................................................. 157

ANEXOS ........................................................................................................................... 160

ix
ÍNDICE DE FIGURAS

figura 2.1 Roles, artefactos y eventos principales de SCRUM ................................................ 29

figura 2.2 Diagrama del ciclo iterativo Scrum ......................................................................... 31

figura 2.3 Ejemplo de pila del producto ................................................................................... 32

figura 2.4 Casos de uso UWE ................................................................................................... 37

figura 2.5 Modelo de contenido de UWE ................................................................................. 37

figura 2.6 Estereotipos del Modelo Navegacional.................................................................... 38

figura 2.7 Modelo de navegación de UWE .............................................................................. 38

figura 2.8 Estereotipos del modelo de presentación ................................................................. 39

figura 2.9 Modelo de presentación UWE ................................................................................. 39

figura 2.10 Modelo de proceso UWE ....................................................................................... 40

figura 3.1 Etapas de SCRUM con UWE ................................................................................. 53

figura 3.2 Diagrama Entidad relacion Sprint 0 ......................................................................... 71

figura 3.3 Modelo físico de la base de datos ............................................................................ 72

figura 3.4 Modelo relacional de la base de datos ..................................................................... 73

figura 3.5 Implementación de la base de datos en MySQL ..................................................... 74

figura 3.6 Caso de uso de administración y acceso de usuarios .............................................. 77

figura 3.7 Caso de uso de gestión de organigrama ................................................................... 78

figura 3.8 Diagrama entidad relación Sprint 1 ......................................................................... 80

figura 3.9 Diagrama fisico Sprint 1 .......................................................................................... 80

figura 3.10 Diagrama de clases del módulo Gestión de usuarios ............................................. 81

figura 3.11 Diagrama de navegación del módulo de Gestión de usuarios ............................... 82

figura 3.12 Diagrama de presentación del módulo de Gestión de usuarios ............................. 83

figura 3.13 Diagrama de presentación del módulo de ingreso al sistema ............................... 83

figura 3.14 Diagrama de presentación del módulo de ingreso al sistema ............................... 84

figura 3.15 Caso de uso de gestión de almacenes.................................................................... 87

x
figura 3.16 Caso de uso de gestión de artículos ...................................................................... 88

figura 3.17 Diagrama entidad relación Sprint 2 ....................................................................... 90

figura 3.18 Diagrama físico de la base de datos Sprint 2 ......................................................... 90

figura 3.19 Diagrama de clases de contenido del módulo Gestión de artículos y almacén..... 91

figura 3.20 Diagrama de navegación del módulo de Gestión de artículos y almacenes .......... 92

figura 3.21 Diagrama de presentación del módulo de Gestión de almacenes ......................... 93

figura 3.22 Diagrama de presentación del módulo de Gestión de artículos ............................. 93

figura 3.23 Caso de uso de notas de ingreso........................................................................... 96

figura 3.24 Caso de uso de notas de pedido ............................................................................. 98

figura 3.25 Diagrama entidad relación Sprint 3 ..................................................................... 100

figura 3.26 Modelo fisico de la base de datos Sprint 3........................................................... 100

figura 3.27 Diagrama de clases de contenido del módulo ingresos y pedidos ....................... 101

figura 3.28 Diagrama de navegación del módulo de ingreso y pedidos ................................. 102

figura 3.29 Diagrama de presentación del módulo de ingresos .............................................. 103

figura 3.30 Diagrama de presentación del módulo de pedidos............................................... 103

figura 3.31 Caso de uso de reportes valorados ....................................................................... 106

figura 3.32 Diagrama entidad relación Sprint 4 ..................................................................... 108

figura 3.33 Diagrama físico de la base de datos Sprint 4 ....................................................... 108

figura 3.34 Diagrama de clases de contenido del módulo reportes ........................................ 109

figura3.35 Diagrama de navegación del módulo de reportes ................................................. 110

figura 3.36 Diagrama de presentación del módulo de reportes .............................................. 111

figura 3.37 Validación de ingreso al sistema .......................................................................... 114

figura 3.38 Ingreso al sistema como administrador – almacén central .................................. 115

figura 3.39 Crear nuevo usuario ............................................................................................. 115

figura 3.40 Gestión de los usuarios ........................................................................................ 116

figura 3.41 Registro del organigrama ..................................................................................... 116

xi
figura 3.42 Gestión de proveedores ........................................................................................ 117

figura 3.43 Gestión de Funcionarios ...................................................................................... 118

figura 3.44 Creación de almacén ............................................................................................ 119

figura 3.45 Gestión de almacenes ........................................................................................... 119

figura 3.46 Gestión de clasificador presupuestario ................................................................ 120

figura 3.47 Gestión de artículos.............................................................................................. 121

figura 3.48 Vista de existencias y porcentajes ........................................................................ 121

figura 3.49 Crear nota de ingreso ........................................................................................... 122

figura 3.50 Gestión de ingresos .............................................................................................. 123

figura 3.51 Reporte de nota de ingreso ................................................................................... 123

figura 3.52 Registro de nota de pedido ................................................................................... 124

figura 3.53 Gestión de notas de pedidos ................................................................................. 124

figura 3.54 Reporte de nota de pedido .................................................................................... 125

figura 3.55 Cierre de gestión .................................................................................................. 126

figura 3.56 Reporte de kardex ................................................................................................ 126

figura 3.57 Reporte de kardex en pdf ..................................................................................... 127

figura 3.58 Reporte de kardex en Excel ................................................................................. 128

figura 3.59 Reporte mensual valorado .................................................................................... 128

figura 3.60 Reporte mensual valorado en pdf......................................................................... 129

figura 3.61 Reporte por unidad ............................................................................................... 129

figura 3.62 Reporte por proveedor ......................................................................................... 130

figura 3.63 Ingreso usuario Contador ..................................................................................... 130

figura 3.64 Reporte como contador ........................................................................................ 131

xii
ÍNDICE DE TABLAS

Tabla 1.1 Características de Equipos en la Institución ............................................................. 23

Tabla 2.1 Preguntas de usabilidad ............................................................................................ 45

Tabla 2.2 Productividad promedio ........................................................................................... 48

Tabla 2.3 Valores por lenguaje de programación ..................................................................... 50

Tabla 3.1 Asignación de roles y responsabilidades de SCRUM ............................................. 54

Tabla 3.2 Clasificación de usuarios ......................................................................................... 54

Tabla 3.3 Gestión de usuarios.................................................................................................. 56

Tabla 3.4 Diseño de la base de datos ....................................................................................... 56

Tabla 3.5 Autenticación de ingreso de usuarios ...................................................................... 56

Tabla 3.6 Creación de nuevos usuarios ................................................................................... 57

Tabla 3.7 Modificación y borrado de usuarios ........................................................................ 57

Tabla 3.8 Crear y registrar la estructura del organigrama ....................................................... 58

Tabla 3.9 Crear almacén Central y sub almacenes ................................................................... 58

Tabla 3.10 Crear la partida presupuestaria ............................................................................... 58

Tabla 3.11 Gestionar la información de artículos.................................................................... 59

Tabla 3.12 Crear y registrar la estructura del Gobierno Autónomo Municipal de El Alto ..... 59

Tabla 3.13 Gestión de proveedores ......................................................................................... 59

Tabla 3.14 Control de movimiento del proveedor .................................................................... 60

Tabla 3.15 Gestión de funcionarios de las unidades ............................................................... 60

Tabla 3.16 Acceso a la información de stock .......................................................................... 61

Tabla 3.17 Porcentaje de existencia de materiales .................................................................. 61

Tabla 3.18 Ingreso de artículos ............................................................................................... 61

Tabla 3.19 Generar nota de Ingreso......................................................................................... 62

Tabla 3.20 Anular nota de Ingreso ........................................................................................... 62

Tabla 3.21 Pedido de artículos ................................................................................................ 63

xiii
Tabla 3.22 Generar nota de pedido .......................................................................................... 63

Tabla 3.23 Aprobar y anular las notas de pedido ..................................................................... 63

Tabla 3.24 Reporte de kardex .................................................................................................. 64

Tabla 3.25 Reporte mensual valorado ..................................................................................... 64

Tabla 3.26 Generar los movimientos de las unidades ............................................................. 65

Tabla 3.27 Realizar el cierre de gestión .................................................................................. 65

Tabla 3.28 Enlace a la unidad de contabilidad ........................................................................ 65

Tabla 3.29 Product backlog ..................................................................................................... 66

Tabla 3.30 Sprint 0 .................................................................................................................. 70

Tabla 3.31 Pila de Sprint 0 ....................................................................................................... 70

Tabla 3.32 Pruebas unitarias sprint 0....................................................................................... 74

Tabla 3.33 Sprint 1 .................................................................................................................. 75

Tabla 3.34 Pila de Sprint 1 ....................................................................................................... 75

Tabla 3.35 Caso de uso de administración y acceso de usuarios ............................................ 77

Tabla 3.36 Caso de uso de gestión de organigrama ................................................................ 79

Tabla 3.37 Pruebas unitarias sprint 1....................................................................................... 84

Tabla 3.38 Sprint 2 ................................................................................................................. 85

Tabla 3.39 Pila de Sprint 2 ...................................................................................................... 85

Tabla 3.40 Caso de uso de gestión de almacenes ................................................................... 87

Tabla 3.41 Caso de uso de gestión de artículos ....................................................................... 89

Tabla 3.42 Pruebas unitarias sprint 2....................................................................................... 94

Tabla 3.43 Sprint 3 .................................................................................................................. 94

Tabla 3.44 Pila de Sprint 3 ...................................................................................................... 95

Tabla 3.45 Caso de uso de notas de ingreso ........................................................................... 97

Tabla 3.46 Caso de uso de notas de pedido ............................................................................. 98

Tabla 3.47 Pruebas unitarias sprint 3..................................................................................... 104

xiv
Tabla 3.48 Sprint 4 ................................................................................................................ 104

Tabla 3.49 Pila de Sprint 4 .................................................................................................... 105

Tabla 3.50 Caso de uso de reportes valorados....................................................................... 106

Tabla 3.51 Pruebas unitarias sprint 4..................................................................................... 111

Tabla 3.52 Tabla de pruebas de integración .......................................................................... 112

Tabla 3.53 Tabla de pruebas de acceso de usuarios .............................................................. 113

Tabla 4.1 Atributos de calidad................................................................................................ 132

Tabla 4.2 Entradas de usuario................................................................................................ 134

Tabla 4.3 Salidas de usuario .................................................................................................. 134

Tabla 4.4 Peticiones de usuario .............................................................................................. 135

Tabla 4.5 Archivos del sistema.............................................................................................. 136

Tabla 4.6 Interfaces externas ................................................................................................. 137

Tabla 4.7 Factor de ponderación ........................................................................................... 137

Tabla 4.8 Valores de ajustes de complejidad ........................................................................ 138

Tabla 4.9 Valores de confiabilidad ........................................................................................ 141

Tabla 4.10 Encuesta de usabilidad ........................................................................................ 142

Tabla 4.11 Calidad global del sistema ................................................................................... 144

Tabla 5.1 Coeficientes de COCOMO II ................................................................................ 147

Tabla 5.2 Factor LDC/PF ...................................................................................................... 147

Tabla 5.3 Costo de elaboración ............................................................................................. 149

Tabla 5.4 Costo total.............................................................................................................. 149

Tabla 5.5 Calculo de VAN ..................................................................................................... 151

xv
 RESUMEN

El uso de las Tecnologías de la Información y Comunicaciones TIC nos ayuda a resolver

diversas tareas y optimizar procesos que serían bastante costosos si los hiciéramos
manualmente, por esta razón y por la evolución de las redes e internet es que muchas
empresas e instituciones optan por integrar un sistema de información para agilizar el trabajo,
facilitar muchas tareas y tener un registro de sus actividades más ordenado.

Este proyecto tiene como fin ser un sistema de información y de administración de los
artículos de un almacén central y sub almacenes, tanto en sus movimientos como en reportes.
Este proyecto de grado es titulado “SISTEMA WEB DE ADMINISTRACIÓN Y CONTROL
DEL ALMACENAMIENTO DE ARTÍCULOS EN EL ALMACÉN CENTRAL Y EN
SUBALMACENES, CASO: GOBIERNO AUTÓNOMO MUNICIPAL DE EL ALTO”
desarrollado para los departamentos en los cuales exista un sub almacén y para la unidad de
almacenes como almacén central. Lo que nos da como resultado que se desarrolló un sistema
web para la administración y control del almacenamiento de artículos en el almacén central y
los subalmacenes desconcentrados para que el proceso de movimiento de artículos sea ágil y
su información sea actualizada en el Gobierno Autónomo Municipal de El Alto.

Para el desarrollo del presente proyecto se utilizó la metodología SCRUM la cual nos
proporciona un método ordenado de desarrollo, haciendo de este un desarrollo ágil dividido en
etapas, las cuales se denominan Sprints en base a las historias de usuario, dichas historias de
usuario se recolectan de entrevistas con el personal de la unidad de almacenes que opera como
almacén central. Se utilizó también la metodología de desarrollo UML y para el desarrollo
web se aplica la metodología denominada UWE usando los diversos modelos que nos
presenta, nos ayudó a realizar un modelado más ordenado y preciso.

Para el aspecto de calidad de software se aplicó los factores de calidad basados en el ISO-
9126 y para obtener el costo del sistema de opto por aplicar el modelo de costos de COCOMO
II que es el más utilizado y probado.

Palabras Clave: Subalmacenes, SCRUM, Método P.E.P.S, Metodología UWE. COCOMO II.

xvi
 ABSTRACT

The use of Information Technology and Communications ICT helps us to solve various tasks
and optimize processes that would be quite costly if we did manually, for this reason and the
evolution of networks and the Internet is that many companies and institutions choose to
integrate an information system to streamline work, facilitate many tasks and have a record of
their activities more orderly.

This project aims to be an information system and management of items in a central

warehouse and sub-warehouses, both in their movements and in reports. This degree project is
entitled "WEB SYSTEM FOR THE ADMINISTRATION AND CONTROL OF STORAGE
OF ITEMS IN THE CENTRAL WAREHOUSE AND SUB-WAREHOUSES, CASE:
MUNICIPAL GOVERNMENT OF THE HIGH" developed for the departments in which
there is a sub-warehouse and for the warehouse unit as a central warehouse. The result is that
a web system was developed for the administration and control of the storage of articles in the
central warehouse and the deconcentrated sub-warehouses so that the process of movement of
articles is agile and its information is updated in the Municipal Autonomous Government of
El Alto.

For the development of this project we used the SCRUM methodology which provides an
orderly method of development, making this an agile development divided into stages, which
are called Sprints based on user stories, these user stories are collected from interviews with
staff of the warehouse unit that operates as a central warehouse. We also used the UML
development methodology and for the web development we applied the methodology called
UWE using the different models that it presents us, it helped us to make a more ordered and
precise modeling.

For the software quality aspect, we applied the quality factors based on ISO-9126 and to
obtain the cost of the system we opted to apply the COCOMO II cost model which is the most
used and tested.

Keywords: Sub-warehouses, SCRUM, P.E.P.S Method, UWE Methodology. COCOMO II.

xvii
1. CAPÍTULO I MARCO REFERENCIAL

1.1. INTRODUCCIÓN

El 6 de marzo de 1985, el Congreso Nacional aprobó la Ley 728, creando la Cuarta Sección
Municipal de la provincia Murillo, con su capital El Alto, fue elevada al rango de ciudad, por
la Ley 1014 de fecha 26 de septiembre de 1988; el mismo que dio lugar a la división de la
ciudad de La Paz y El Alto, previamente este territorio era administrado como parte del
municipio vecino de La Paz(Ley Nº 728, 1985).

En entrevista con Elizabeth Blanco, Responsable de Almacenes se pudo rescatar: La secretaria

de almacenes es la máxima responsable de los artículos ingresantes y salientes, así como de
los subalmacenes. El almacén central es una instancia operativa de la Unidad de Almacenes
dependiente de la Dirección Administrativa Financiera, administra actividades y
procedimientos relativos al ingreso, registro, distribución, y control de material.

El subalmacén es el área operativa dependiente del almacén central de la unidad de almacenes,

cuenta con un solo responsable que es encargado que tiene un espacio físico en una unidad del
Gobierno Autónomo Municipal de El Alto.

Actualmente los subalmacenes no cuentan con una forma automática de organizar sus
materiales, no están organizados ni implementados de manera oficial, por lo cual sus procesos
de pedido e ingresos pasan siempre por el almacén central, que controla sus procesos y la
cantidad de existencias en sus subalmacenes.

Se debe sistematizar este proceso, así cada subalmacén podrá administrar sus propios artículos
y sus movimientos, bajo supervisión del almacén central que bajo reglamento es la entidad
responsable de ellos.

La información del almacén central es única y solo se maneja en el almacén central, sin
embargo, se crearán subalmacenes que tienen el objetico especifico de optimizar la
disponibilidad de bienes de consumo en 21 subalmacenes inicialmente creados por la
Resolución Administrativa Municipal Ejecutiva Nº 071/19, por lo cual es de cumplimiento
obligatorio(Resolucion Administrativa Municipal Ejecutiva N° 071/19, 2019).

18
Según la Justificación Técnica: Con este Proyecto se diseñará un sistema de información
donde se busca facilitar y organizar las actividades y elaboración de kardex, registro de
pedidos, de entradas y salidas, apoyando con nuevas tendencias tecnológicas generando
soluciones efectivas. El sistema de información será una herramienta moderna que se
caracteriza por la facilidad de búsqueda y eso permitirá a la unidad responsable del almacén
tener un control sobre su inventario real y actualizado en el menor tiempo posible.

Para ayudar al buen funcionamiento del alancen central y los subalmacenes se ha decidido
desarrollar un sistema web para la administración y control del almacenamiento de artículos
en el almacén central y los subalmacenes desconcentrados para que el proceso de movimiento
de artículos y su información sea actualizada en el Gobierno Autónomo Municipal de El Alto.

1.2. PLANTEAMIENTO DEL PROBLEMA

1.2.1. ANTECEDENTES DEL PROBLEMA

El almacenamiento de artículos y productos es una de las tareas más importantes para la

unidad de almacenes, se controlan las salidas e ingresos y todo el movimiento, todo esto es
para evitar que haya perdidas de información y perdidas de los artículos, actualmente todos los
artículos están centralizados en un almacén central y todo pedido de material e ingreso de
material debe hacerse directamente al almacén central, dando mucho trabajo a este ya que el
número de unidades solicitantes es demasiado grande y el proceso de control de stock se
vuelve una tarea tediosa ya que existen continuos movimientos en el almacén central.

El sistema actual no contempla la posibilidad de generar subalmacenes para facilitar las tareas
del almacén central y así poder descentralizar la información y distribuirla de manera
pertinente teniendo un constante control de parte del almacén central y por parte del
departamento de contabilidad.

Actualmente el almacenamiento y emisión de los reportes se encuentra registrada

generalmente en hojas de cálculo Excel, son elaboradas manualmente, como también el
llenado de solicitudes de pedido de material son transcritas por el personal, teniendo que usar
las notas de pedido llenadas a mano para buscar en el depósito la existencia de artículos.

19
Se carece de un orden en las etapas de movimiento de material, pedido en borrador, pedido
verificado con el stock disponible y pedido aprobado y entregado, provocando así el riesgo de
pérdida de la información o de material en el almacén y subalmacenes.

Se toma demasiado tiempo en ingresar artículos y en realizar pedidos al almacén debido al

llenado manual de formularios, ya que con el formulario llenado el encargado de almacenes
debe verificar la existencia de materiales dando así una respuesta lenta.

1.2.2. TRABAJOS SIMILARES

En la biblioteca de la Carrera de Informática de la Universidad Mayor de San Andrés se

cuenta con algunos proyectos de grado relacionados con control de almacenes e inventarios
pertinentes a diferentes instituciones, entre los cuales podemos mencionar a los siguientes:

• Proyecto de Grado “Sistema Para la Administración y Seguimiento de Almacenes con

Modelos de Inventarios. Caso: Honorable Cámara de Diputados Unidad de Almacenes”,
El presente proyecto desarrolla un sistema para la administración y seguimiento de
insumos y materiales de almacenes con modelos de inventarios para manejar de manera
óptima los reportes necesarios y que estos se actualices constantemente en la Unidad de
Almacenes de la Honorable Cámara de [Link] el respectivo desarrollo del sistema
se vio conveniente usar una metodología de Investigación, y la metodología empleada es
la Metodología de Investigación Mixta, donde se asocia los enfoques cualitativo y
cuantitativo. Entre las herramientas que se usó MySQL, PHP, aplicaciones en tres
capas(Huarachi, 2013).
• Proyecto de Grado “Sistema de Gestión de Almacenes. Caso: Ministerio de Minería y
Metalurgia”, El presente proyecto desarrolla un sistema el cual se le permite al encargado
del almacén llevar el control eficiente del inventario y facilitar sus tareas, así como a los
empleados contar con la información necesaria e inmediata para realizar los respectivos
pedidos de material. Para el respectivo desarrollo del sistema se aplicó la metodología
SCRUM, debido a las características del proyecto. Entre las herramientas que se usó
APACHE, MySQL, PHP, XAMPP, desarrollado con el framework Codeigniter
dependiente de PHP (Parra, 2013).

20
• Proyecto de Grado “Sistema web de control de compras, ventas e inventarios caso
Comercial Ariana”. Se automatiza y centraliza la información sobre sus compras, ventas e
[Link] desarrollo del proyecto se basó en las fases propuestas por la Metodología
de Desarrollo Ágil XP (Extreme Programming – Programación Extrema) el cual fue muy
útil al momento de diseñar las funciones y la interfaz del usuario. Como herramienta de
desarrollo de aplicaciones web se utilizó el framework Laravel en su versión 5.4
complementado con el gestor de base de datos MySQL. Para el diseño responsivo como
los dispositivos móviles adaptables se utilizó el framework Bootstrap, acompañado de
Javascript, JQuery y PHP(Carrillo, 2017).
• Proyecto de Grado “Sistema web de gestión y control de almacenes e inventarios Caso:
Ministerio de planificación del desarrollo”. El presente proyecto presente proyecto se
realizó para almacenes del Ministerio de Planificación del Desarrollo el cual solicita un
sistema actualizado, que genere reportes, inventarios, solicitudes, ingresos de materiales,
salidas. El proyecto fue realizado con la metodología ágil SCRUM para el análisis y
diseño del sistema, para el modelado de sistemas se utilizó la propuesta de WebUML. El
sistema fue desarrollado en un entorno WEB con el framework Laravel, Backend PHP,
Frontend Javascript y la base de datos está desarrollada en MySQL(Hinojosa, 2018).

1.2.3. FORMULACIÓN DEL PROBLEMA

Con lo expuesto anteriormente se define el planteamiento del siguiente problema central

dentro del Gobierno Autónomo Municipal de El Alto:

¿Cómo administrar y controlarel almacenamiento de artículos en el almacén central y

subalmacenes desconcentrados para que el proceso de movimiento de artículos sea ágil y su
información seaactualizada en el Gobierno Autónomo Municipal de El Alto?

1.2.4. PROBLEMAS SECUNDARIOS

• Los subalmacenes no están bajo un control del almacén central, además que los
subalmacenes no tiene un acceso al sistema.
• Los subalmacenes carecen de un sistema que cubra sus necesidades básicas los procesos
de movimiento y control de artículos.

21
• La falta de clasificación de los artículos impide una mejor organización de ellos de
acuerdo a sus características.
• El registro de ingresos y pedidos no se hace de una forma automática, provocando errores
en los registros de los movimientos.
• La información de entradas y salidas de artículos de los subalmacenes no es clara y precisa
teniendo errores en los reportes.

1.3. DEFINICIÓN DEL OBJETIVO

1.3.1. OBJETIVO GENERAL

Desarrollar un sistema web para la administración y controldel almacenamiento de artículos

en el almacén centraly los subalmacenesdesconcentrados para que el proceso de movimiento
de artículos sea ágil y su información sea actualizada en el Gobierno Autónomo Municipal de
El Alto.

1.3.2. OBJETIVOS ESPECÍFICOS

• Diseñar una base de datos que permita un manejo de los subalmacenes y los relacione con
el almacén central para su respectivo control.
• Determinar los requerimientos necesarios para el análisis y diseño del sistema de
subalmacenes y cubrir así las necesidades del Gobierno Autónomo Municipal de El Alto.
• Diseñar un módulode registro de artículos, clasificando estos de manera ordenada según su
clasificador presupuestario.
• Brindar una verificación continua en las cantidades de los artículos para no generar
pérdidas en el stock.
• Guardar la información necesaria para lograr tener un registro de los movimientos de cada
artículo según cada subalmacén, utilizando la mayor cantidad de cifras significativas para
no perder información en redondeos.

1.4. JUSTIFICACIÓN

1.4.1. JUSTIFICACIÓN SOCIAL

El desarrollo e implementación de este sistema permitirá al personal del Gobierno Autónomo

Municipal de El Alto, en sus subalmacenes, una herramienta idónea la cual ayudará y

22
conectaráa los subalmacenes con el almacén central, haciendo el trabajo más fácil y eficiente y
dando un control al almacén central sobre sus subalmacenes.

Se logrará una integración de subalmacenes con las unidades solicitantes, una distribución
más eficiente de artículos y un control más eficiente por parte de unidades de contabilidad.

1.4.2. JUSTIFICACIÓN ECONÓMICA

La implementación del sistema provocara que los tramites sean mucho más rápidos y los
gastos sean reducidos, además se realizara un control en los movimientos, de esta forma se
evitara que se pierdan artículos o que se genere un incremento de los precios
injustificadamente.

El proyecto permite incrementar los beneficios de tiempo sobre el costo que es el tiempo que
se invierte en realizar un pedido o ingreso al almacén central, logrando una descentralización
en los subalmacenes para mejorar los tiempos de respuesta.

1.4.3. JUSTIFICACIÓN TECNOLÓGICA

En el Gobierno Autónomo Municipal de El Alto en la unidad de Almacenes y los

subalmacenes cuentan con personal capacitado, con encargados que tienen conocimientos de
computación básica, suficiente para el manejo del sistema que se va implementar. Las
características de los equipos se encuentran detallados en la Tabla 1.1, mostrada a
continuación.

Tabla 1.1Características de Equipos en la Institución

TECNOLOGÍA EN LA INSTITUCIÓN
Procesador Core i3 hasta Core i7
Memoria RAM 4 GB
Servidor Servidor físico con sistema Linux
Sistema Operativo en las computadoras Windows 8 a Windows 10
Fuente(División de Almacenes y Sistemas, 2019)

23
1.5. ALCANCES Y LÍMITES

A continuación, se describen los alcances y límites del presente proyecto de grado.

1.5.1. ALCANCES

El sistema estará disponible para los usuarios registrados en el sistema según el rol que se les
sea asignado y con acceso a los módulos según las funciones que realiza.

• Beneficiará a los diferentes subalmacenes del Gobierno Autónomo Municipal de El Alto,

llegando a las unidades de las que dependen los subalmacenes.
• Módulo de administración, el cual solo podrá tener acceso el almacén central que
gestionará a los usuarios existentes y sus permisos de ingreso.
• Módulo de Registro de subalmacenes, el cual se asignará un responsable y se relacionará
el almacén la unidad responsable.
• Módulo de gestión de materiales, en este módulo se registran los artículos y se les asigna
una clasificación, una unidad de medida y su descripción detallada.
• Módulo de Ingreso de artículos, este módulo realiza el registro de los artículos que
ingresan al almacén central o a subalmacenes, con todos los datos correspondientes.
• Módulo de Salida de artículos, los artículos son repartidos entre las unidades solicitantes
de la alcaldía.
• Módulo de reportes, los reportes pueden ser generados por los diferentes almacenes,
haciéndolos por artículos en específico o por categoría.
• Módulo de cierre de gestión, una vez la gestión se cierre se realiza un inventario final, y
sumando los saldos se da inicio a una nueva gestión.

1.5.2. LÍMITES

Los límites para el desarrollo del proyecto son los siguientes:

• El sistema solo podrá accederse desde una plataforma web.

• El acceso al sistema solo lo podrán realizar los usuarios registrados en el sistema de
subalmacenes.
• El personal de los subalmacenes no podrá editar sus movimientos de artículos de ninguna
forma.

24
• El sistema no realiza trabajo del personal de contabilidad, como ser ajuste de saldos y
balance de cuentas, entre otros.

1.6. DISEÑO METODOLÓGICO

En este trabajo de investigación se usará la metodología SCRUM junto con la metodología

UML-BASED WEB ENGINEERING (UWE).

Los principales beneficios que proporciona SCRUM son:

• Entrega mensual (o quincenal) de resultados (los requisitos más prioritarios en ese

momento, ya completados) lo cual proporciona las siguientes ventajas:
• Gestión regular de las expectativas del cliente y basada en resultados tangibles.
• Resultados anticipados (time to market).
• Flexibilidad y adaptación respecto a las necesidades del cliente, cambios en el mercado,
etc.
• Gestión sistemática del Retorno de Inversión.
• Mitigación sistemática de los riesgos del proyecto.
• Productividad y calidad.
• Alineamiento entre el cliente y el equipo de desarrollo.

25
2. CAPÍTULO IIMARCO TEÓRICO

2.1. MARCO INSTITUCIONAL

El 6 de marzo de 1985, el Congreso Nacional aprobó la Ley Nº 728 que crea la Cuarta
Sección Municipal de la provincia Murillo, con su capital El Alto. El 26 de septiembre de
1988 se promulga la Ley Nº 1014 elevando a El Alto a rango de ciudad.

2.1.1. VISIÓN

El Alto con cultura, valores y liderazgo propios, seguro, moderno, con equidad e igualdad de
oportunidades, impulsa el desarrollo sustentable de la ciudad y se articula a la región
(INFORME DE RENDICIÓN PÚBLICA DE CUENTAS INICIAL, 2018).

2.1.2. MISIÓN

Gobierno autónomo, transparente, moderno y eficiente (INFORME DE RENDICIÓN

PÚBLICA DE CUENTAS INICIAL, 2018).

2.1.3. ORGANIGRAMA

La estructura orgánica del Gobierno Autónomo Municipal de El Alto a la gestión 2018 se

muestra en la sección de ANEXOS:

2.1.4. UNIDAD DE ALMACENES

Administrar las actividades y procedimientos relativos al ingreso, registro, almacenamiento,

distribución, medidas de salvaguarda y control de los bienes de consumo en el G.A.M.E.A.
optimizando la disponibilidad de bienes de consumo, el control de sus operaciones y la
minimización de los costos de almacenamiento adquiridos con recursos propios o
financiamiento externo, donados o trasferidos por otras instituciones(Manual de Organizacion
y Funciones, 2018, pág. 50).

Dada la importancia de esta unidad y de los futuros sub almacenes que se va administrar se
procede a desarrollar este sistema. Actualmente el sistema que se maneja no cumple con los
requerimientos actuales, en especial en el manejo de sub almacenes y también presenta errores
al generar reportes, esto debido a errores de redondeo de decimales.

26
2.2. METODOLOGÍA DE DESARROLLO

Las metodologías de desarrollo de software son indispensables para crear o actualizar

software de calidad que cumpla con los requisitos de los usuarios; son una parte fundamental
de la Ingeniería de software la cual denomina metodología a un conjunto de métodos
coherentes y relacionados por unos principios comunes (Rivas, Corona, Gutierrez, &
Hernandez, 2015).

Para el siguiente trabajo se usará una de las metodologías agiles ya que es totalmente
conveniente debido a los requerimientos de la empresa y el poco tiempo que se tiene para
entregar los módulos, también se usará una metodología Web debido a que el entorno de
desarrollo se realizará en un entorno web y este tipo de metodología nos permitirá modelar
aplicaciones web, prestando especial atención en sistematización y personalización.

2.2.1. METODOLOGÍAS AGILES Y WEB

Hablando de las metodologías agiles, actualmente, las empresas operan en un entorno global
que cambia rápidamente; en ese sentido, deben responder a nuevas oportunidades y mercados,
al cambio de las condiciones económicas así, como al surgimiento de productos y servicios
nuevos y competitivos. Para ello es necesario emplear computadoras y dispositivos
computacionales, por lo que el software es partícipe de casi todas las operaciones
empresariales, de modo que debe desarrollarse de manera ágil para responder con oportunidad
y calidad a todo lo necesario.

Hablando de metodologías Web, el crecimiento desenfrenado que está teniendo la web está
ocasionando un impacto en la sociedad, y el nuevo manejo de información en las diferentes
áreas ha hecho que las personas tiendan a realizar sus actividades por esta vía. La ingeniería y
las metodologías web están relacionadas con el establecimiento y utilización de principios
científicos, de ingeniería y gestión, y con enfoques sistemáticos y disciplinados del éxito y
desarrollo (Rivas, Corona, Gutierrez, & Hernandez, 2015).

Las metodologías para aplicaciones Web contienen fases para el desarrollo de software que
pueden aumentar o disminuir dependiendo del método que utilicen, según Nieves Del Valle la
mayoría de los métodos coinciden en las siguientes etapas:

27
• Diseño Conceptual: en esta sección se abarca temas relaciones a la especificación del
dominio del problema, a través de su definición y las relaciones que contrae.
• Diseño Navegacional: está enfocado en lo que respecta al acceso y forma en la que los
datos son visibles.
• Diseño de la presentación o diseño de interfaz: se centra en la forma en la que la
información va a ser mostrada a los usuarios, cabe mencionar en esta sección intervienen
mayormente el cliente definiendo los requerimientos y lo usuarios defiendo como quieren
interactuar con el sistema.
• Implantación: es la construcción del software a partir de los artefactos generados en las
etapas previas.

2.2.2. METODOLOGÍA SCRUM

Los principios SCRUM son congruentes con el manifiesto ágil y se utilizan para guiar
actividades de desarrollo dentro de un proceso de análisis que incorpora las siguientes
actividades estructurales: requerimientos, análisis, diseño, evolución y entrega. Dentro de cada
actividad estructural, las tareas del trabajo ocurren con un patrón del proceso (que se estudia
en el párrafo siguiente) llamado sprint. El trabajo realizado dentro de un sprint (el número de
éstos que requiere cada actividad estructural variará en función de la complejidad y tamaño
del producto) se adapta al problema en cuestión y se define y con frecuencia se modifica en
tiempo real por parte del equipo Scrum (Pressman, 2010).

Como método ágil:

• Es un modo de desarrollo adaptable, antes que predictivo.

• Está orientado a las personas, más que a los procesos.
• Emplea el modelo de construcción incremental basado eniteraciones y revisiones.

Las prácticas empleadas por SCRUM para mantener uncontrol ágil en el proyecto son:
Revisión de las iteraciones,Desarrollo incremental, Desarrollo evolutivo, Auto organización
del equipo y Colaboración(Mariño & Alfonzo, 2014).

Los roles, artefactos y eventos principales se resumen en la Figura 2.1. a continuación.

28
 figura 2.1Roles, artefactos y eventos principales de SCRUM
Fuente: (Mariño & Alfonzo, 2014)
2.2.3. ROLES SCRUM

El Equipo Scrum consiste en un Dueño de Producto (Product Owner), el Equipo de Desarrollo

(Development Team) y un Scrum Master. Los Equipos Scrum son auto-organizados y
multifuncionales. Los equipos auto-organizados eligen la mejor forma de llevar a cabo su
trabajo y no son dirigidos por personas externas al equipo. Los equipos multifuncionales
tienen todas las competencias necesarias para llevar a cabo el trabajo sin depender de otras
personas que no son parte del equipo. El modelo de equipo en Scrum está diseñado para
optimizar la flexibilidad, la creatividad y la productividad(Pressman, 2010).

[Link]. PRODUCT OWNER

El Dueño de Producto es el responsable de maximizar el valor del producto y del trabajo del
Equipo de Desarrollo. El cómo se lleva a cabo esto podría variar ampliamente entre distintas
organizaciones. El Dueño de Producto es la única persona responsable de gestionar la Lista
del Producto o como se conoce Product Backlog.(Kniberg, 2010).

29
La gestión de la Lista del Producto incluye:

• Expresar claramente los elementos de la Lista del Producto;

• Ordenar los elementos en la Lista del Producto para alcanzar los objetivos y misiones de la
mejor manera posible.
• Optimizar el valor del trabajo desempeñado por el Equipo de Desarrollo.
• Asegurar que la Lista del Producto es visible, transparente y clara para todos, y que
muestra aquello en lo que el equipo trabajará a continuación.
• Asegurar que el Equipo de Desarrollo entiende los elementos de la Lista del Producto al
nivel necesario(Kniberg, 2010).

[Link]. SCRUM MASTER

Responsable del proceso SCRUM, de cumplir la meta y resolver los problemas. Así como
también, de asegurarse que el proyecto se lleve a cabo de acuerdo con las prácticas, valores y
reglas de SCRUM y que progrese según lo previsto.

El scrum master es un líder que está al servicio del equipo. Ayuda a las personas externas a
entender qué interacciones con el equipo pueden ser útiles y cuáles no. El scrum master ayuda
a todos a modificar estas interacciones para maximizar el valor creado por el
equipo(Pressman, 2010).

[Link]. SCRUM TEAM

Lo forman el grupo de profesionales que realizan el incremento de cada sprint. Se recomienda

que un equipo scrum tenga no menos de 3 ni más de 9 personas. Más allá de 9 resulta difícil
mantener la comunicación directa, y se manifiestan con más intensidad los roces habituales de
la dinámica de grupos (que comienzan a aparecer a partir de 6 personas). En elcómputo del
número de miembros del equipo de desarrollo no se consideran ni el Scrum Master niel
propietario del producto.

No se trata de un grupo de trabajo formado por un arquitecto, diseñador o analista,

programadoresy testers. Es un equipo multifuncional, en el que todos los miembros trabajan
de forma solidariacon responsabilidad compartida. Es posible que algunos miembros sean

30
especialistas en áreasconcretas, pero la responsabilidad es el incremento de cada sprint y recae
sobre el equipo dedesarrollo en conjunto(Menzinsky, Scrum Master, 2019).

En el equipo:

• Todos conocen y comprenden la visión del propietario del producto.

• Aportan y colaboran con el propietario del producto en el desarrollo de la pila del
producto.
• Comparten de forma conjunta el objetivo de cada sprint y la responsabilidad del logro.
• Todos los miembros participan en las decisiones.
• Se respetan las opiniones y aportes de todos.
• Todos conocen Scrum.

2.2.4. ARTEFACTOS DE SCRUM

• Pila del producto: (product backlog) lista de requisitos de usuario, que a partir de la
visión inicial del producto crece y evoluciona durante el desarrollo.
• Pila del sprint: (sprint backlog) lista de los trabajos que debe realizar el equipo durante el
sprint para generar el incremento previsto.
• Incremento: resultado de cada sprint(Menzinsky, Scrum Manager, 2016).

Estos 3 elementos trabajan en conjunto como se puede ver en la figura 2.2.

figura 2.2Diagrama del ciclo iterativo Scrum

Fuente: (Menzinsky, Scrum Master, 2019)

31
[Link]. PILA DEL PRODUCTO

La pila del producto es la lista ordenada de todo aquello que el propietario de producto cree
que necesita el producto.

Es el inventario de funcionalidades, mejoras, tecnología y corrección de errores que deben

incorporarse al producto a través de los sucesivos sprints. Representa todo aquello que esperan
el cliente, los usuarios, y en general los interesados. Todo lo que suponga un trabajo que debe
realizar el equipo debe estar reflejado en esta pila.

Si se emplea formato de lista, la información mínima que se suele incluir para cada historia de
usuario es:

• Descripción de la funcionalidad/requisito, denominado “historia de usuario”.

• Prioridad.
• Preestimación del esfuerzo necesario.
• Si se ve conveniente Nº de Sprint en el que se realiza.

Un ejemplo en el cual se podría basar la pila de producto es el siguiente, representado en la

figura 2.3.

figura 2.3Ejemplo de pila del producto

Fuente: (Menzinsky, Scrum Master, 2019)
[Link]. PILA DEL SPRINT

La pila del sprint (sprint Backlog) es la lista de las tareas necesarias para construir las historias
de usuario que se van a realizar en un [Link] confecciona el equipo en la reunión de
planificación del sprint, indicando para cada tarea el esfuerzo previsto para realizarla.

32
 La pila del sprint descompone las historias de usuario en unidades de tamaño adecuado
para monitorizar el avance a diario, e identificar riesgos y problemas sin necesidad de
procesos de gestión complejos(Menzinsky, Scrum Manager, 2016).

[Link]. INCREMENTO

El incremento es la parte de producto producida en un sprint, y tiene como característica el

estarcompletamente terminada y operativa, en condiciones de ser entregada al [Link] se
deben considerar como Incremento a prototipos, módulos o sub-módulos, ni partespendientes
de pruebas o integración. Se toma en cuenta que:

• Cada elemento de la pila del producto se refiere a funcionalidades entregables, no a

trabajosinternos del tipo “diseño de la base de datos”.
• Se produce un “incremento” en cada iteración.

Sin embargo, es una excepción frecuente el primer sprint, que se suele denominar “sprint
0”.cuando tiene objetivos del tipo “contrastar la plataforma y el diseño” que resultan
necesarios alcomenzar algunos proyectos, e implican trabajos de diseño o desarrollo de
prototipos paracontrastar las expectativas de la plataforma o tecnología que se va a
emplear(Menzinsky, Scrum Master, 2019).

2.2.5. EVENTOS DE SCRUM

• Sprint: nombre que recibe cada iteración de desarrollo. Es el núcleo central que genera el
pulso de avance a ritmo de “tiempos prefijados” (time boxing).
• Reunión de Planificación del sprint: reunión de trabajo que marca el inicio de cada
sprint en la que se determina cuál es el objetivo del sprint y las tareas necesarias para
conseguirlo.
• Scrum diario: breve reunión diaria del equipo, en la que cada miembro responde a tres
cuestiones:
o El trabajo realizado el día anterior.
o El que tiene previsto realizar.
o Cosas que puede necesitar, o impedimentos que deben eliminarse para poder realizar el
trabajo.

33
• Revisión del sprint: análisis e inspección del incremento generado, y adaptación de la
pila del producto si resulta necesario (Menzinsky, Scrum Manager, 2016)

2.2.6. FASES DE SCRUM

Scrum es una metodología Ágil, está basada en iteración y revisiones. El ciclo de vida de
SCRUM está compuesto de tres fases que son el pre Game, Game y el post Game(Palacio,
2008).

[Link]. PRE GAME

Las tareas que se realizan en esta primera etapa son:

• Planeación: Todos los miembros del equipo incluyendo el cliente se reúnen para
determinar el análisis del problema. En este paso se puede dividir las tareas en:
o Recopilación: Donde se extrae los requerimientos para conformar el producto
backlog, priorizados de acuerdo al cliente y los usuarios que interactúan con el
proyecto.
o Análisis de riesgos y controles apropiados para los riesgos, la selección del tipo de
herramienta a trabajar, cálculo y la estimación del costo.
• Arquitectura: El objetivo de esta etapa es diseñar como los elementos del backlog del
producto serán puestos en ejecución. Se revisa los ítems del backlog, el análisis y el
tiempo aproximado para terminar la tarea (Palacio, 2008).

[Link]. GAME

Una vez realizado el pre – Game se opta por realizar los siguientes puntos

• Planeación del Sprint. Antes de comenzar cada sprint, se lleva a cabo reuniones para
refinar y priorizar nuevamente el producto backlog luego pasara a ser un Sprint backlog
con las Actividades realizadas, los responsables y la duración de cada actividad.
• Desarrollo de Sprint. El trabajo generalmente se organiza en iteraciones de 2 a 3 semanas.
El sprint es el desarrollo de la nueva funcionalidad del producto. Esta fase provee la
siguiente documentación.
• Revisión del Sprint. Al final de cada iteración se lleva a cabo una reunión de revisión en
donde se encuentra la nueva funcionalidad del producto, las metas incluyendo la

34
 información de las funciones, diseño ventaja, inconvenientes y esfuerzo del
equipo(Palacio, 2008).

[Link]. POST GAME

La etapa final, denominada según SCRUM, es el cierre o Post – Game: En esta última etapa se
realiza la preparación operacional, incluyendo la documentación final necesaria para la
prestación.

Realizando las Pruebas de Rendimiento o Esfuerzo del Proyecto, también a esta etapa se debe
realizar dependiendo del tipo de producto las interfaces finales para el usuario y el
entrenamiento del Plantel (usuarios) o el marketing para la venta del nuevo producto(Palacio,
2008).

2.3. INGENIERÍA WEB

Según el sitio oficial de UWE(München, 2016). La Ingeniería Web propone nuevos métodos
para el diseño de aplicaciones que se ejecutan en esta nueva plataforma que es la World Wide
Web. Uno de estos métodos es UWE UML Web Engineering, el cual aprovecha la notación
estándar del UML e incorpora elementos que son propios del desarrollo Web

2.3.1. METODOLOGÍAUML-BASED WEB ENGINEERING (UWE)

“Es una propuesta metodológica basada en el Proceso Unificado y UML para el desarrollo de
aplicaciones Web. Cubre todo el ciclo de vida de este tipo de aplicaciones, centrando además
su atención en aplicaciones personalizadas” (Escalona & Koch, 2002, p. 65)

Según José Escalona y Nora Koch (2002), UWE es una metodología que abarca todos los
procesos de la construcción de las aplicaciones Web, sin embargo, se centra más en la
recopilación y validación de requisitos (funcionales y no funcionales) dando como resultado
un modelo de casos de uso y documentación acerca de los usuarios del sistema, casos de uso e
interfaz.

UML-Based Web Engineering (UWE) que está basado en UML y en el proceso unificado que
nos permitirá modelar aplicaciones web, utilizada en la ingeniería web, prestando especial
atención en sistematización y personalización (sistemas adaptativos).

35
2.3.2. REQUISITOS DE UWE

UWE clasifica los requisitos en dos grandes grupos: funcionales y no funcionales. Los
requisitos funcionales tratados por UWE son:

• Requisitos relacionados con el contenido.

• Requisitos relacionados con la estructura.
• Requisitos relacionados con la presentación.
• Requisitos relacionados con la adaptación.
• Requisitos relacionados con los usuarios.

Además, UWE propone como técnicas apropiadas para la captura de los requisitos de un
sistema web las entrevistas, los cuestionarios y los checklists y los casos de uso, los escenarios
y el glosario para la definición de requisitos. Para la validación propone walk-throughs,
auditorías y prototipos (Escalona & Koch, 2002).

2.3.3. ETAPAS DE UWE

Una de las ventajas de que UWE extienda el estándar UML es la flexibilidad de éste para la
definición de un lenguaje de modelado específico para el dominio web y sobretodo la
aceptación universal de dicho estándar en el campo de la ingeniería del software. Otra gran
ventaja es que actualmente existen múltiples de herramientas CASE basadas en UML, con lo
cual es relativamente sencillo su utilización y ampliación para utilizar los objetos de modelado
definidos en UWE. El modelo que propone UWE está compuesto por 5 etapas o sub-modelos:

• Modelo de Casos de Uso: modelo para capturar los requisitos del sistema.
• Modelo de Contenido: es un modelo conceptual para el desarrollo del contenido.
• Modelo de Navegación: es modelo de usuario, en el cual se incluyen modelos estáticos y
modelos dinámicos.
• Modelo de Presentación: en el cual se encuentra la presentación del sistema.
• Modelo Abstracto: incluye el modelo a de interfaz de usuario y el modelo de ciclo de vida
del objeto(Maximilians, 2011).

36
[Link]. MODELO DE CASOS DE USO

En UWE se distinguen casos de uso, para ilustrar si los datos persistentes de la aplicación son
modificados o no. En la Figura 2.4 se muestra el grafico de ejemplo acerca de un caso de uso.

figura 2.4Casos de uso UWE

Fuente: (Maximilians, 2011)
[Link]. MODELO DE CONTENIDO

Este modelo especifica cómo se encuentra relacionados los contenidos del Sistema, define
laestructura de los datos que se encuentran alojados del Sistema Web. Este es un diagrama
UMLnormal de clases, por ello debemos pensar en las clases que son necesarias como sus
[Link] la Figura 2.5 se muestra el grafico de ejemplo.

figura 2.5Modelo de contenido de UWE

Fuente: (Maximilians, 2011)

37
[Link]. MODELO NAVEGACIONAL

Este modelo está basado en el modelado de los requerimientos y contenido. Las clases del
modelo de contenido que son consideradas relevantes para la navegación incluyen en el
modelo de navegación, como sus asociaciones, representando los navigationClass y
navigationLinks. En la figura 2.6 se ve los estereotipos usados y en la figura 2.7 se muestra el
grafico de ejemplo.

figura 2.6Estereotipos del Modelo Navegacional

Fuente: (Maximilians, 2011)

figura 2.7 Modelo de navegación de UWE

Fuente: (Maximilians, 2011)
[Link]. MODELO DE PRESENTACIÓN

Es un modelo basado en el modelo de navegación y los elementos representados son usados

para presentar los nodos de navegación – cada atributo del <navigationClass>está
representado por un elemento de la UI. Cada atributo del <navigationClass>es representado en

38
el modelo de presentación por el elemento de la UI correspondiente, como, por ejemplo: un
elemento de “next” es usado para representar el atributo “titulo” del <navigationClass>y un
elemento “image” es usado para representar el atributo “foto”. Generalmente el contenido de
distintos <navigationNodes> es presentado en una página Web, las <presentationPage> en
UWE. En este modelo se representa las clases de navegación y de procesos que pertenecen a
cada página Web. Estos elementos se describen en la figura 2.8

figura 2.8Estereotipos del modelo de presentación

Fuente: (Maximilians, 2011)
En la figura 2.9 se muestra el grafico de ejemplo.

figura 2.9 Modelo de presentación UWE

Fuente: (Maximilians, 2011)
[Link]. MODELO DE PROCESOS

Este tipo de modelo define el comportamiento y los detalles de un proceso de negocio. El

process flow, como también se lo llama, describe minuciosamente los pasos dentro de un

39
proceso, en el caso que el usuario navegue por éste. Está representado por diagramas de
actividad [Link] la figura 2.10 se muestra el grafico de ejemplo.

figura 2.10 Modelo de proceso UWE

Fuente: (Maximilians, 2011)

2.4. TECNOLOGÍA DE SOFTWARE

El programa de tecnología en Desarrollo de Software forma tecnólogos competitivos con

capacidad de ejecutar las fases del desarrollo de software, usando métodos y estándares
internacionales; Enfocados aspectos como: Desarrollo de aplicaciones virtuales, Bases de
datos, administración Web y la seguridad informática, competencias que buscan aumentar las
posibilidades de desarrollo y globalizado por las Tecnologías de Información.

2.4.1. FRAMEWORK

El concepto framework se emplea en muchos ámbitos del desarrollo de sistemas software, no

solo en el ámbito de aplicaciones Web. Podemos encontrar frameworks para el desarrollo de
aplicaciones médicas, de visión por computador, para el desarrollo de juegos, y para cualquier
ámbito que pueda ocurrírsenos.

40
En general, con el término framework, nos estamos refiriendo a una estructura software
compuesta de componentes personalizables e intercambiables para el desarrollo de una
aplicación. En otras palabras, un framework se puede considerar como una aplicación
genérica incompleta y configurable a la que podemos añadirle las últimas piezas para construir
una aplicación concreta (Gutiérrez, 2015).

2.4.2. BACKEND

El Backend en el desarrollo web, es la parte que controla toda la lógica que hay detrás de una
aplicación. Sería algo así como el cerebro de nuestra aplicación, que hoy en día están más que
optimizados y depurados por desarrolladores experimentados y toda la comunidad de personas
que estos traen consigo(Martinez, 2018).

2.4.3. LARAVEL

Este framework hace que el odiado lenguaje de programación PHP vuelva a ser entretenido a
la hora de programar. Laravel ofrece soluciones directas y sencillas a complejas
funcionalidades en una aplicación, como podían ser el modelado de datos, realización de
tareas periódicas, adaptación al modelo MVC, entre muchas otras. A todo esto, se le suma una
documentación muy trabajada y una comunidad de desarrolladores cada vez más extensa.
Además, cabe destacar, que con la reciente versión de PHP 7.0, se ha duplicado el rendimiento
de las aplicaciones escritas en este lenguaje de programación(Laravel, 2016).

2.4.4. BOOTSTRAP 4

Bootstrap 4 es la última versión de un de las librerías más populares en el mundo desarrollado

por el equipo de Twitter y lanzado en código abierto para ser mejorado, es un kit de
herramientas para desarrollar con HTML, CSS y JS. Crea un prototipo rápido de las ideas y es
apto para crear aplicaciones grandes con ayuda de otras librerías (Bootstrap, 2018).

2.5. TEMAS RELACIONADOS

2.5.1. INVENTARIOS

El control de inventarios busca mantener disponible los productos que se requieren para la
empresa y para los clientes, por lo que implica la coordinación de las áreas de compras,
manufactura distribución.

41
“Los inventarios son acumulaciones de materias primas, provisiones, componentes, trabajo en
proceso y productos terminados que aparecen en numerosos puntos a lo largo del canal de
producción y de logística de una empresa.” (Ronald, 2004).

Se denominan inventarios o existencias al conjunto de mercaderías (artículos, Productos, etc.)

que posee una entidad pública o privada, a unadeterminada fecha para su venta, en el caso de
una empresa comercial, o para su uso en el caso de una empresa pública (Gandarillas, 2018).

2.5.2. MÉTODO P.E.P.S.

En el ámbito comercial, es común el famoso método P.E.P.S, este es una especie de sistema
que facilita la salida de toda la mercancía que ha entrado al negocio de manera actualizada,
permitiendo llevar un mejor control en el inventario. Las siglas P.E.P.S. significan “primeras
en entrar, primeras en salir”.

Muchas empresas recurren a este método para poder ir sacando toda la mercancía que tienen
para la venta, y así no acumular mercancía no vendida. Desde las empresas pequeñas hasta las
más grandes, utilizan el P.E.P.S, el cual permite la constante renovación de inventario y ofrece
muchas ventajas en el ámbito económico y contable.

El P.E.P.S. es un método de fácil funcionamiento, con él la mercancía más antigua de las

empresas van a salir y ser vendidas, para que estas no se queden perdidas u olvidadas en el
almacén, permitiendo a la empresa mayor ganancia y orden en el inventario (Pacheco, 2019).

2.6. CALIDAD DE SOFTWARE - NORMA ISO 9126

ISO 9126 era un estándar internacional para la evaluación de la calidad del software. Fue
reemplazado en 2005 por el conjunto de normas SQuaRE, ISO 25000:2014, la cual desarrolla
los mismos conceptos.

Las métricas para la evaluación del software se pueden catalogar en métricas de productividad
(enfocadas al rendimiento) de Calidad que son enfocadas al nivel de ajuste a los requisitos
explícitos e implícitos del cliente y Métricas Técnicas que son orientadas a características
como complejidad, y grado de modularidad, más que en el proceso de desarrollo(Ruiz, 2006).

42
También Ruiz (2006) define la siguiente formula que es capaz de dar los puntos función, el
cual nos dará el tamaño del software o un aproximado, y pretende medir la funcionalidad
entregada al usuario independientemente de la tecnología utilizada para la construcción y
explotación del software, y también ser útil en cualquiera de las fases de vida del software,
desde el diseño inicial hasta la implementación y mantenimiento.

𝑃𝐹 = 𝑐𝑢𝑒𝑛𝑡𝑎𝑇𝑜𝑡𝑎𝑙 ∗ (0.65 + 0.01 ∗ ∑ 𝐹𝑖 )

A continuación, se detalla cada una de las características que establece el estándar ISO-9126.

Funcionalidad: En este grupo se conjunta una serie de atributos que permiten calificar si un
producto de software maneja en forma adecuada el conjunto de funciones que satisfagan las
necesidades para las cuales fue diseñado.

Confiabilidad: Aquí se agrupan un conjunto de atributos que se refieren a la capacidad del

software de mantener su nivel de ejecución bajo condiciones normales en un periodo de
tiempo establecido.

Usabilidad: Consiste de un conjunto de atributos que permiten evaluar el esfuerzo necesario

que deberá invertir el usuario para utilizar el sistema.

Eficiencia: Esta característica permite evaluar la relación entre el nivel de funcionamiento del
software y la cantidad de recursos usados.

Mantenibilidad: Se refiere a los atributos que permiten medir el esfuerzo necesario para
realizar modificaciones al software, ya sea por la corrección de errores o por el incremento de
funcionalidad.

Portabilidad: En este caso, se refiere a la habilidad del software de ser transferido de un

ambiente a otro (Abud, 2012).

2.6.1. FUNCIONALIDAD

Según Abud (2012) las funcionalidades del sistema, se miden a través de su complejidad. La
funcionalidad no puede ser medida directamente, por lo tanto, corresponde la incorporación de

43
un mecanismo discreto (punto función) para obtener un resultado medible y cuantificable en
base a la siguiente fórmula:

𝑃𝐹 = 𝑐𝑢𝑒𝑛𝑡𝑎𝑇𝑜𝑡𝑎𝑙 ∗ (0.65 + 0.01 ∗ ∑ 𝐹𝑖 )

2.6.2. CONFIABILIDAD

La confiabilidad del sistema se define como: “La probabilidad de operación libre de fallas de
un programa de computadora en un entorno determinado y durante un tiempo específico”

Para calcular la confiabilidad de cada módulo se usó de la fórmula:

𝑅(𝑡) = 𝑒 −𝜆𝑡

Donde:

𝑹(𝒕): confiabilidad de un componente del sistema t.

𝝀: Tasa de constantes de fallo, se define como: 𝜆 = Numero de fallas al ingreso al sistema /

número total de accesos al sistema

t: periodo de operación de tiempo.

𝒆−𝝀𝒕 : Probabilidad de falla de un componente o subsistema en el tiempo t.

2.6.3. USABILIDAD

Cuando se habla de usabilidad, se espera que el sistema sea de fácil entendimiento y

aprendizaje. Cabe resaltar que para la norma ISO 9126, la usabilidad no es afectada por la
funcionalidad y eficiencia. La usabilidad está definida por los usuarios finales o personas
afines al sistema. Para la medición de la usabilidad se debe contar con un cuadro de preguntas
donde se deben asignar valores que están definidos en una escala de ajuste de
usabilidad(Abud, 2012).

44
 Tabla 2.1 Preguntas de usabilidad
Nro. Pregunta
1 ¿Es entendible?
¿Las pantallas son agradables a la vista
2
del usuario?
3 ¿Es fácil de aprender?
4 ¿Contiene la información necesaria?
5 ¿Facilita su trabajo?
¿Es fácil navegar por las distintas
6
opciones?
¿El sistema le proporciono las
7
respuestas requeridas?
8 ¿El sistema no presento errores?
Fuente: (Elaboración propia)

2.6.4. EFICIENCIA

La eficiencia es el grado que la aplicación hace óptimo el uso de recursos del sistema,
indicada por los tiempos de uso y recursos utilizados (Pressman, 2010).

2.6.5. MANTENIBILIDAD

La mantenibilidad es la característica que representa la capacidad del sistema a ser modificado

a nivel funcional, correcciones de entorno, cambios y mejoras del sistema (Pressman, 2010).
Para ello, se utilizará la siguiente fórmula:

𝑀𝑡 − (𝐹𝑎 + 𝐹𝑏 + 𝐹𝑐 )
𝐼𝑀𝑆 = ∗ 100
𝑀𝑡
Donde:
𝐼𝑀𝑆 : Índice de madurez del sistema
𝑀𝑡 : Número de módulos actual
𝐹𝑎 : Número de módulos en la versión actual que se han cambiado
𝐹𝑏 : Número de módulos en la versión actual que se han añadido
𝐹𝑐 : Número de módulos en la versión anterior que se han borrado en la versión
actual

45
2.6.6. PORTABILIDAD

Se define como la característica que posee un software para ejecutarse en diferentes

plataformas, el código fuente del software es capaz de reutilizarse en vez de crearse un nuevo
código cuando el software pasa de una plataforma a otra. A mayor portabilidad menor es la
dependencia del software con respecto a la plataforma.

𝐸𝑇
𝐺𝑃 = 1 −
𝐸𝑅
Donde:
𝐺𝑃 : Grado de portabilidad
𝐸𝑇 : Recursos necesarios para llevar el sistema a otro entorno
𝐸𝑅 : Recursos necesarios para crear el sistema en el entorno residente
Si:
𝐺𝑃> 0, la portabilidad es más rentable que el re-desarrollo
𝐺𝑃< 0, el re-desarrollo la portabilidad es más rentable que la portabilidad
𝐺𝑃 = 0, la portabilidad es perfecta

2.7. COSTOS Y BENEFICIOS

Una de las tareas de mayor importancia en la administración de proyectos de software es la

estimación de costos. Si bien es una de las primeras actividades, inmediatamente posterior al
establecimiento de los requerimientos, se ejecuta regularmente a medida que el proyecto
progresa con el fin de ajustar la precisión en la estimación.

2.7.1. MODELO COCOMO II

El modelo COCOMO ha evolucionado debido a los constantes avances en el mercado de

desarrollo de software.

Para evitar confusión el modelo COCOMO original fue re diseñado con el nombre
COCOMO’ 81. Así todas las referencias de COCOMO encontradas en la literatura antes de
1995 se refieren a lo que ahora llamamos COCOMO 81. La mayoría de las referencias
publicadas a partir de 1995 se refieren a COCOMO II.

46
Los objetivos principales que se tuvieron en cuenta para construir el modelo COCOMO II
fueron:

• Desarrollar un modelo de estimación de costo y cronograma de proyectos de software que

se adaptara tanto a las prácticas de desarrollo de la década del 90 como a las futuras.
• Construir una base de datos de proyectos de software que permitiera la calibración
continua del modelo, y así incrementar la precisión en la estimación.
• Implementar una herramienta de software que soportara el modelo.
• Proveer un marco analítico cuantitativo y un conjunto de herramientas y técnicas que
evaluaran el impacto de las mejoras tecnológicas de software sobre los costos y tiempos en
las diferentes etapas del ciclo de vida de desarrollo(Banker, Kauffman, & Kumar, 1994).

COCOMO II está compuesto por tres modelos denominados: Composición de Aplicación,

Diseño Temprano y Post-Arquitectura.

El modelo Composición de Aplicación se emplea en desarrollos de software durante la etapa

de prototipación.

El modelo Diseño Temprano se utiliza en las primeras etapas del desarrollo en las cuales se
evalúan las alternativas de hardware y software de un proyecto. En estas etapas se tiene poca
información, lo que concuerda con el uso de Puntos Función, para estimar tamaño y el uso de
un número reducido de factores de costo.

El modelo Post-Arquitectura se aplica en la etapa de desarrollo propiamente dicho, después

que se define la arquitectura del sistema, y en la etapa de mantenimiento. Este modelo utiliza:

• Puntos Función y/o Líneas de Código Fuente para estimar tamaño, con modificadores que
contemplan el reúso, con y sin traducción automática, y el "desperdicio".
• Un conjunto de 17 atributos, denominados factores de costo, que permiten considerar
características del proyecto referentes al personal, plataforma de desarrollo, entre otras,
que tienen injerencia en los costos(Gómez, Migani, del C.López, & Otazú, 2007).

47
[Link]. ESTIMACIÓN DE ESFUERZO

El esfuerzo necesario para concretar un proyecto de desarrollo de software, cualquiera sea el

modelo empleado, se expresa en meses/persona (PM) y representa los meses de trabajo de una
persona tiempo completo, requeridos para desarrollar el proyecto.

La fórmula propuesta en este modelo es la siguiente:

NOP (Nuevos Puntos Objeto): Tamaño del nuevo software a desarrollar expresado en Puntos
Objeto y se calcula de la siguiente manera:

NOP = OP x (100 - %reúso) /100

OP (Puntos Objeto): Tamaño del software a desarrollar expresado en Puntos Objeto

%reúso: Porcentaje de reúso que se espera lograr en el proyecto

PROD: Es la productividad promedio determinada a partir del análisis de datos de

proyectos.(Banker, Kauffman, & Kumar, 1994), esto se muestra en Tabla 2.

Tabla 2.2Productividad promedio

Fuente: (Banker, Kauffman, & Kumar, 1994).

[Link]. MÉTRICAS DE SOFTWARE

En la estimación del tamaño de software COCOMO II utiliza tres técnicas: Puntos Objeto,
Puntos Función No Ajustados y Líneas de Código Fuente. Además, se emplean otros
parámetros relativos al tamaño que contemplan aspectos tales como: reúso, reingeniería,
conversión, y mantenimiento.

48
Es necesario unificar criterios de medición de tamaño, tanto para poder planificar y controlar
proyectos, como para realizar estudios y análisis entre proyectos en pro de la mejora de
procesos(Park, 1992).

Puntos Función: El modelo COCOMO II usa Puntos Función y/o Líneas de Código Fuente
(SLOC) como basepara medir tamaño en los modelos de estimación de Diseño Temprano y
Post-Arquitectura(Albrecht, 1979).

La fórmula para calcular los puntos función según Albrecht (1979), es la siguiente:

FP = UFP x TCF

Donde:

UFP: Puntos Función no Ajustados

TCF: Factor de Complejidad Técnica

Para calcular los UFP, se deben identificar los siguientes tipos de ítems:

• Entradas Externas (Inputs): Entrada de datos del usuario o de control que ingresan desde el
exterior del sistema para agregar y/o cambiar datos a un archivo lógico interno.
• Salidas Externas (Outputs): Salida de datos de usuario o de control que deja el límite del
sistema de software.
• Archivo Lógicos Internos (Archivos): Incluye cada archivo lógico, es decir cada grupo
lógico de datos que es generado, usado, o mantenido por el sistema de software.
• Archivos Externos de Interface (Interfaces): Archivos transferidos o compartidos entre
sistemas de software.
• Solicitudes Externas (Queries): Combinación única de entrada-salida, donde una entrada
causa y genera una salida inmediata, como un tipo de solicitud externa.

El valor del SLOC, dependerá del lenguaje de programación que se esté utilizando. En la
Tabla 2.3

49
 Tabla 2.3Valores por lenguaje de programación
Factor
Lenguaje Nivel
LCD/PF
C 2.5 128
ANSI BASIC 5 64
JAVA 6 53
ASP 9 36
PHP 11 23
VISUAL C++ 9.5 35

Fuente (Abud, 2012)

2.8. SEGURIDAD

2.8.1. SEGURIDAD DE LA INFORMACIÓN

El propósito de la seguridad de la información es construir un sistema que tenga en cuenta

todos los posibles riesgos en la administración de la información, estén o no relacionados con
la seguridad informática. En concreto, el principio de la seguridad informática es prevenir el
acceso, modificación, uso o destrucción no autorizados de la información, independientemente
del soporte en el que se encuentre ésta.

Se definen unos principios básicos que deben cumplirse cuando nos referimos a la
información:

1. Confidencialidad: Debe prevenirse el revelado de información a personas o sistemas no

autorizados.
2. Integridad: La información debe mantenerse libre de cualquier modificación o alteración
de su contenido que no sea autorizada.
3. Disponibilidad: Así mismo, la información deberá estar accesible y disponible para las
personas o sistemas autorizados cuando así lo requieran.
4. Autenticidad/Autenticación: Es necesario poder garantizarse que el emisor de la
información es quien dice ser.
5. Norepudio: En determinados entornos, no debe caber posibilidad por parte del emisor de
rechazar la autoría de la información (Asensio, 2014).

50
2.8.2. SEGURIDAD INFORMÁTICA

Esta disciplina es la encargada de implementar las medidas técnicas de protección de la

información. Es decir, el despliegue de las tecnologías necesarias (desde el control de acceso,
antivirus, cortafuegos, alertas, etcétera) que, articuladas junto con prácticas de dirección de las
tecnologías de información, establecen las formas de actuación y defensa frente a situaciones
de fallos y brechas de seguridad (Asensio, 2014).

La seguridad informática está concebida para proteger los activos informáticos, mismos que se
presentan a continuación:

• La infraestructura computacional. Es una parte fundamental para el almacenamiento y

gestión de la información, así como para el funcionamiento mismo de la organización. La
función de la seguridad informática en esta área, es velar por que los equipos funcionen
adecuadamente y anticiparse a las fallas, robos, incendios, sabotajes, desastres naturales,
problemas con el suministro eléctrico o cualquier otro factor que atente contra la
infraestructura informática.
• Los usuarios. Son las personas que utilizan la infraestructura tecnológica y de
comunicaciones, además de gestionar la información de las bases de datos y sistemas. Los
accesos a las distintas instancias de administración deben estar protegidas para evitar
fallas involuntarias en el funcionamiento de la plataforma tecnológica.
• La información. Este es el principal activo. Utiliza y reside en la infraestructura
computacional y es utilizada por los usuarios.

La correcta Gestión de la Seguridad de la Información busca establecer y mantener

programas, controles y políticas, que tengan como finalidad conservar la confidencialidad,
integridad y disponibilidad de la información, si alguna de estas características falla no
estamos ante nada seguro (Asensio, 2014).

51
3. CAPÍTULO III MARCO APLICATIVO

3.1. INTRODUCCIÓN

En este capítulo se efectuará el desarrollo del sistema web de administración y control del
almacenamiento de artículos en el almacén central y en subalmacenes para el Gobierno
Autónomo Municipal de El Alto. Dando curso a la aplicación de la metodología de desarrollo
ágil SCRUM, con la ayuda de la metodología de desarrollo web UWE – UML Based Web
Engineeringpara poder obtener la representación conceptual y física del sistema.

La metodología SCRUM es el marco de trabajo adaptativo a las necesidades del proyecto que
utiliza un proceso ágil, iterativo e incremental que respeta las cinco etapas tradicionales de un
proyecto que facilitan su gestión y control; ellas son: planificación, análisis, diseño,
construcción y prueba, e implementación. Para lograr el éxito en el proyecto se define en cada
etapa los entregables, además de definir el alcance de cada Sprint.

3.2. APLICACIÓN DE LAS DOS METODOLOGÍAS

La metodología SCRUM comprende 3 etapas, las cuales se implementan en el sistema, las

etapas son las siguientes:

Pre-Gamees la etapa donde se analizó la planificación para el desarrollo del sistema, así como
los usuarios y el nivel con el cual están involucrados en el sistema. Se recolecto las historias
de usuario determinando el tiempo y la relevancia para formar el Product Backlog.

Gamees la etapa donde a partir del Product Backlog se dividió en diferentes Sprint,al igual
que la etapa anterior se planifico el tiempo de los Sprint; esta es la etapa donde se utilizó la
metodología UWE para el modelado y diseño Web, esto en cada Sprint.

Post-Gameesta fue la etapa donde terminó el producto final, concluyendo con el Product
Backlog y alcanzando las interfaces de pantalla.

En la Figura 3.1 se puede apreciar el modelo de proceso de desarrollo que se utilizó en el

presente proyecto de grado, en el cual podemos apreciar las actividades de la metodología de
desarrollo ágil SCRUM, los pasos que se deben tomar y el momento exacto donde utilizar la
metodología de diseño UWE.

52
 figura 3.1Etapas de SCRUM con UWE
Fuente: (Elaboración propia)

3.3. PRE – GAME

En esta etapa se identifican los requerimientos del sistema según El Gobierno Autónomo
Municipal de El Alto, además de definir los roles y el Product Backlog.

3.3.1. PLANEAMIENTO

La primera actividad es armar una lista exhaustiva de los requerimientos originales del sistema
y los usuarios, los cuales pasarán a ser los ítems de la Pila del Producto (Product Backlog),
luego se procede a ver qué requerimientos son los realmente necesarios, cuáles pueden
posponerse y cuáles eliminarse. Para ello se debe identificar un representante con capacidad
de decisión, para priorizar los requerimientos en base a su importancia y acordar cuáles son
los prioritarios para la fecha de entrega, estas acciones serán realizadas por el Dueño del
Producto (Product Owner), en nuestro caso el dueño del producto es el Gobierno Autónomo
Municipal de El Alto, representado por el Ing. Alejandro Michel Uriarte jefe de la unidad de
sistemas.

53
De esta manera las responsabilidades de la metodología SCRUM están detalladas en la tabla
3.1.

Tabla 3.1Asignación de roles y responsabilidades de SCRUM

Responsabilidad de Rol Encargado

Dueño del producto Gobierno Autónomo Municipal de El Alto

• Jefa de la unidad de Almacenes
• Josue Oscar Espejo Quenta – Scrum
Equipo de Trabajo
Master
• Personal del área de sistemas
• Funcionarios de la Unidad de
Almacenes
• Encargados de los Sub almacenes
Clientes
• Encargados de las unidades del
Gobierno Autónomo Municipal de El
Alto
Fuente (Elaboración propia)

3.3.2. CLASIFICACIÓN DE USUARIO Y ROLES

Se debe identificar a los usuarios que interactuaran con el sistema para poder clasificarlos y
diseñar las respectivas restricciones o tareas específicas que tendrá cada uno de ellos dentro
del Gobierno Autónomo Municipal de El Alto, específicamente en la unidad de almacenes y
en los sub almacenes.

Al clasificar los usuarios y sus respectivos roles, en la tabla 3.2, se tiene ya la idea clara de
cómo hacer la gestión de usuarios en el ingreso al sistema según su rol.

Tabla 3.2Clasificación de usuarios

Usuario Abreviación Descripción
Es el encargado del sistema y además
Administrador y encargado
A tiene la facultad de actuar como
de almacén central
almacén central.

Encargado del sub almacén capaz de

Encargado del sub almacén E
realizar entrada y salida de material.

54
 Funcionarios de distintas unidades que
Solicitantes de la unidades S
trabajan en cualquier en la institución.

Encargado de controlar el ingreso y

Contabilidad C salida de los almacenes con fines de
control.
Fuente (Elaboración propia)

3.3.3. HISTORIAS DE USUARIO

En este apartado vamos a continuar recolectando las historias de usuario según los
requerimientos que nos brindan los distintos usuarios que fueron descrito anteriormente, estas
nos ayudaran a describirlas prioridades y las iteraciones.

Para recolectar las historias de usuario de forma eficiente usaremos los siguientes atributos
para definir una historia de usuario.

Prioridad: El usuario describe el problema y esta es catalogada en prioridad alta, prioridad

media o prioridad baja.

Riesgos en el desarrollo:Se define el riesgo de fallar o hacer una mala implementación de

este requerimiento, se cataloga en alto, medio, bajo.

Iteración y modulo que se le asigna: La iteración en la que se espera que esta historia de
usuario sea implementada, esta iteración dura aproximadamente 4 semanas, dependiendo a la
cantidad de historias de usuario asignadas, por esta razón se procura agrupar las historias
difíciles en menor cantidad y las de mayor facilidad más agrupadas

Puntos estimados: Tiempo que aproximadamente se tardara en realizar esta historia de

usuario, se mide entre 1 a 5 semanas.

Las historias de usuario se describen en las siguientes tablas.

55
 Tabla 3.3Gestión de usuarios
Historia de usuario
Numero:1 Usuario: Administrador
Nombre de la Historia:Gestión de usuarios
Prioridad: Alta Riesgo:Alto
Iteración Asignada: Puntos Estimados: 2
Descripción de la historia:
Los usuarios deben ser registrados y guardados, se deben definir sus roles de usuario para
que solo el administrador pueda ser capaz de crear más usuarios.
Fuente (Elaboración propia)

Tabla 3.4Diseño de la base de datos

Historia de usuario
Numero: 2 Usuario: Administrador
Nombre de la Historia: Diseño de la base de datos
Prioridad: Alta Riesgo: Alto
Iteración Asignada: Puntos Estimados: 3
Descripción de la historia:
El diseño se realiza en el gestor de base de datos MySQL, creando y relacionando las tablas
con el fin de guardar toda la información que sea necesaria para el sistema y evitar así la
duplicidad de datos.
Fuente (Elaboración propia)

Tabla 3.5Autenticación de ingreso de usuarios

Historia de usuario
Numero: 3 Usuario: Administrador, Encargado del sub almacén y
Contabilidad
Nombre de la Historia: Autenticación de ingreso de usuarios
Prioridad: Alta Riesgo: Medio
Iteración Asignada: Puntos Estimados: 2

56
Descripción de la historia:
El usuario debe tener una interfaz de login la cual sea capaz de recibir sus datos y
permitirle el ingreso siempre y cuando sus datos sean correctos, así acceder a las tareas
asignadas por el sistema según su rol.
Fuente (Elaboración propia)

Tabla 3.6Creación de nuevos usuarios

Historia de usuario
Numero: 4 Usuario: Administrador, Encargado almacén central
Nombre de la Historia: Creación de nuevos usuarios
Prioridad: Media Riesgo: Medio
Iteración Asignada: Puntos Estimados: 2
Descripción de la historia:
El administrador podrá crear nuevos usuarios, teniendo los datos requeridos del usuario
nuevo le asignara un usuario y una contraseña.
Fuente (Elaboración propia)

Tabla 3.7Modificación y borrado de usuarios

Historia de usuario
Numero: 5 Usuario: Administrador, Encargado almacén central
Nombre de la Historia: Modificación y borrado de usuarios
Prioridad: Media Riesgo: Medio
Iteración Asignada: Puntos Estimados: 2
Descripción de la historia:
Una vez se tengan los usuarios el administrador es capaz de modificar los datos de los
usuarios, como cambiar su rol o su nombre de usuario, además si desea lo puede eliminar.
Fuente (Elaboración propia)

57
 Tabla 3.8Crear y registrar la estructura del organigrama
Historia de usuario
Numero: 6 Usuario: Administrador, Encargado almacén central
Nombre de la Historia: Crear y registrar la estructura del organigrama
Prioridad: Alta Riesgo: Bajo
Iteración Asignada: Puntos Estimados: 2
Descripción de la historia:
Se registra las direcciones, secretarias, unidades y áreas a la base de datos de sistema. Se
debe registrar las relación de dependencia que tiene cada una de ellas, ver Anexos Figura
2.1.
Fuente (Elaboración propia)

Tabla 3.9Crear almacén Central y sub almacenes

Historia de usuario
Numero: 7 Usuario: Administrador, Encargado almacén central
Nombre de la Historia: Crear almacén Central y sub almacenes
Prioridad: Alta Riesgo: Alto
Iteración Asignada: Puntos Estimados: 3
Descripción de la historia:
Se crea el almacén central y los sub almacenes, el almacén central es encargado de los
demás sub almacenes, al crear cualquiera de los almacenes se registra de manera clara el
usuario encargado y la unidad a la que pertenece, ambas deben están ya registradas en el
sistema.
Fuente (Elaboración propia)

Tabla 3.10Crear la partida presupuestaria

Historia de usuario
Numero: 8 Usuario: Administrador, Encargado almacén central
Nombre de la Historia: Crear la partida presupuestaria
Prioridad: Alta Riesgo: Alto
Iteración Asignada: Puntos Estimados: 2
Descripción de la historia:
El administrador encargado del almacén central será capaz de crear partidas presupuestarias
de acuerdo los clasificadores presupuestarios definidos por Ministerio de Economía y

58
Finanzas públicas.

Fuente (Elaboración propia)

Tabla 3.11Gestionar la información de artículos

Historia de usuario
Numero: 9 Usuario: Administrador, Encargado almacén central
Nombre de la Historia: Gestionar la información de artículos
Prioridad: Alta Riesgo: Medio
Iteración Asignada: Puntos Estimados: 2
Descripción de la historia:
El usuario encargado del almacén central con rol de administrador será capaz de crear y
gestionar a los artículos, tanto modificar como eliminarlos o inhabilitarlos, esto aplica a
todos los subalmacenes.
Fuente (Elaboración propia)

Tabla 3.12Crear y registrar la estructura del Gobierno Autónomo Municipal de El Alto

Historia de usuario
Numero: 10 Usuario: Administrador, Encargado almacén central
Nombre de la Historia: Gestión de unidades de medida
Prioridad: Baja Riesgo: Bajo
Iteración Asignada: Puntos Estimados: 1
Descripción de la historia:
El administrador es capaz de asignar la unidad de medida a cada artículo creado, esto es
muy importante al hacer los movimientos, la unidad puede ser asignada y modificada.
Fuente (Elaboración propia)

Tabla 3.13Gestión de proveedores

Historia de usuario
Numero: 11 Usuario: Administrador, Encargado almacén central,
encargado del sub almacén

59
Nombre de la Historia: Gestión de proveedores
Prioridad: Alta Riesgo: Medio
Iteración Asignada: Puntos Estimados: 2
Descripción de la historia:
El administrador como los encargados del sub almacén serán capaces de adicionar,
modificar y eliminar proveedores.
Fuente (Elaboración propia)

Tabla 3.14Control de movimiento del proveedor

Historia de usuario
Numero: 12 Usuario: Administrador, Encargado almacén central,
encargado del sub almacén
Nombre de la Historia: Control de movimiento del proveedor
Prioridad: Media Riesgo: Medio
Iteración Asignada: Puntos Estimados: 2
Descripción de la historia:
Los encargados de almacén central y sub almacenes son capaces de ver un reporte de los
movimientos que el proveedor ha tenido con el almacén o sub almacén.
Fuente (Elaboración propia)

Tabla 3.15Gestión de funcionarios de las unidades

Historia de usuario
Numero: 13 Usuario: Administrador, Encargado almacén central,
encargado del sub almacén, solicitantes de la unidades
Nombre de la Historia: Gestión de funcionarios de las unidades
Prioridad: Media Riesgo: Medio
Iteración Asignada: Puntos Estimados: 1
Descripción de la historia:
Los encargados de almacén central y sub almacenes registran a los funcionarios que están
involucrados en los movimientos de los productos al hacer solicitudes, estos proporcionan
sus datos y son creados, pudiendo ser modificados o eliminados.
Fuente (Elaboración propia)

60
 Tabla 3.16Acceso a la información de stock
Historia de usuario
Numero: 14 Usuario: Administrador, Encargado almacén central,
encargado del sub almacén
Nombre de la Historia: Acceso a la información de stock
Prioridad: Alta Riesgo: Medio
Iteración Asignada: Puntos Estimados: 2
Descripción de la historia:
Los administradores podrán ver el stock de la lista de artículos de todos los sub almacenes
incluyendo el almacén central, en cambio los encargados de subalmacén solo podrán ver
del sub almacén del que son encargados.
Fuente (Elaboración propia)

Tabla 3.17Porcentaje de existencia de materiales

Historia de usuario
Numero: 15 Usuario: Administrador, Encargado almacén central,
encargado del sub almacén
Nombre de la Historia: Porcentaje de existencia de materiales
Prioridad: Alta Riesgo: Alto
Iteración Asignada: Puntos Estimados: 3
Descripción de la historia:
Los encargados de almacén podrán visualizar el porcentaje de stock por cada uno de los
artículos de su almacén, ellos podrán advertir si el porcentaje de stock es inferior a 50%
25% 10%, ya que esta información es decisiva al momento de adquirir artículos.
Fuente (Elaboración propia)

Tabla 3.18Ingreso de artículos

Historia de usuario
Numero: 16 Usuario: Administrador, Encargado almacén central,
encargado del sub almacén
Nombre de la Historia: Ingreso de artículos
Prioridad: Alta Riesgo: Alto
Iteración Asignada: Puntos Estimados: 4

61
Descripción de la historia:
Los encargados de almacén podrán ingresar una serie de artículos agregando los datos del
proveedor, fecha, numero de comprobante entre otros, de cada artículo se ingresará los
datos como el costo unitario, la cantidad, la fecha de vencimiento si es un artículo
perecedero y una descripción. Cada nota de ingreso genera un lote diferente de los artículos
ingresados.
Fuente (Elaboración propia)

Tabla 3.19Generar nota de Ingreso

Historia de usuario
Numero: 17 Usuario: Administrador, Encargado almacén central,
encargado del sub almacén
Nombre de la Historia: Generar nota de Ingreso
Prioridad: Media Riesgo: Alto
Iteración Asignada: Puntos Estimados: 3
Descripción de la historia:
Se genera un reporte en pdf del registro del ingreso de los artículos. Esta nota debe
contener el nombre del respectivo almacén y el número de comprobante.
Fuente (Elaboración propia)

Tabla 3.20Anular nota de Ingreso

Historia de usuario
Numero: 18 Usuario: Administrador, Encargado almacén central,
encargado del sub almacén
Nombre de la Historia: Anular nota de Ingreso
Prioridad: Media Riesgo: Alto
Iteración Asignada: Puntos Estimados: 3
Descripción de la historia:
El encargado del almacén es capaz de anular una nota de ingreso siempre y cuando no haya
existido salidas de ningún artículo de dicha nota de ingreso.
Fuente (Elaboración propia)

62
 Tabla 3.21Pedido de artículos
Historia de usuario
Numero: 19 Usuario: Administrador, Encargado almacén central,
encargado del sub almacén, solicitantes de la unidades
Nombre de la Historia: Pedido de artículos
Prioridad: Alta Riesgo: Alto
Iteración Asignada: Puntos Estimados: 5
Descripción de la historia:
Los encargados de almacenes podrán generar notas de pedido según una nota física enviada
por una unidad de la organización. Registrar la unidad, el funcionario solicitante y los datos
de los artículos que está solicitando la unidad, especialmente el lote del artículo.
Fuente (Elaboración propia)

Tabla 3.22Generar nota de pedido

Historia de usuario
Numero: 20 Usuario: Administrador, Encargado almacén central,
encargado del sub almacén
Nombre de la Historia: Generar nota de pedido
Prioridad: Media Riesgo: Alto
Iteración Asignada: Puntos Estimados: 3
Descripción de la historia:
Los administradores podrán genera notas de pedido en pdf con 5 copias para diferentes
departamentos.
Fuente (Elaboración propia)

Tabla 3.23Aprobar y anular las notas de pedido

Historia de usuario
Numero: 21 Usuario: Administrador, Encargado almacén central,
encargado de subalmacén
Nombre de la Historia: Aprobar y anular las notas de pedido
Prioridad: Media Riesgo: Alto
Iteración Asignada: Puntos Estimados: 3

63
Descripción de la historia:
Los administradores pueden aprobar los pedidos al momento de la entrega física de los
artículos y anular los pedidos siempre que no hayan sido aprobados.
Fuente (Elaboración propia)

Tabla 3.24Reporte de kardex

Historia de usuario
Numero: 22 Usuario: Administrador, Encargado almacén central,
encargado de subalmacén
Nombre de la Historia: Reporte de kardex
Prioridad: Alta Riesgo: Alto
Iteración Asignada: Puntos Estimados: 5
Descripción de la historia:
El encargado de almacén puede realizar un reporte de un artículo, dentro de un rango de
meses, el reporte contiene los movimientos de dicho artículo dentro del almacén, con un
detalle de Debe-Haber igualado al saldo en stock. El reporte debe generarse en pdf y en
Excel.
Fuente (Elaboración propia)

Tabla 3.25Reporte mensual valorado

Historia de usuario
Numero: 23 Usuario: Administrador, Encargado almacén central,
encargado de subalmacén
Nombre de la Historia: Reporte mensual valorado
Prioridad: Alta Riesgo: Alto
Iteración Asignada: Puntos Estimados: 5
Descripción de la historia:
El encargado de almacén genera un reporte de los movimientos de los artículos que
corresponden a un clasificador presupuestario elegido. Este reporte es generado en pdf y
Excel.
Fuente (Elaboración propia)

64
 Tabla 3.26Generar los movimientos de las unidades
Historia de usuario
Numero: 24 Usuario: Administrador, Encargado almacén central,
encargado de subalmacén
Nombre de la Historia: Generar los movimientos de las unidades
Prioridad: Baja Riesgo: Bajo
Iteración Asignada: Puntos Estimados: 2
Descripción de la historia:
Los encargados de almacén generan los reportes del movimiento de las unidades en
relación con su almacén.
Fuente (Elaboración propia)

Tabla 3.27Realizar el cierre de gestión

Historia de usuario
Numero: 25 Usuario: Administrador, Encargado almacén central,
encargado de subalmacén
Nombre de la Historia: Realizar el cierre de gestión
Prioridad: Media Riesgo: Medio
Iteración Asignada: Puntos Estimados: 1
Descripción de la historia:
Se la gestión sumando todos los lotes de los artículos y promediando el precio si es
necesario.
Fuente (Elaboración propia)

Tabla 3.28Enlace a la unidad de contabilidad

Historia de usuario
Numero: 26 Usuario: Contabilidad
Nombre de la Historia: Enlace a la unidad de contabilidad
Prioridad: Baja Riesgo: Medio
Iteración Asignada: Puntos Estimados: 1
Descripción de la historia:
Se asignó un nuevo rol de contabilidad para poder obtener la información de los
almacenes, en especial los movimientos y los saldos de los artículos.
Fuente (Elaboración propia)

65
3.3.4. PILA DEL PRODUCTO

Ahora dividimos los requerimientos para iniciar con una organización de las tareas, su
prioridad y todos los detalles que conlleva para poder ajustar correctamente las fechas y tareas
propiamente de la metodología, de esa forma obtenemos la pila de productos o el product
backlog en la tabla 3.29 a continuación.

Tabla 3.29Product backlog

Tiempo
Id Nombre Prioridad Modulo Prueba
en días

Gestión de Módulo de Ingreso de datos de usuarios a la

1 Alta 2
usuarios usuarios BD.
Diseño de la base Se realizó el modelo relacional de
2 Alta 7
de datos la base de datos.
Entrar, abrir la página de
Autenticación de autenticación del sistema, escribir
Módulo de
3 ingreso de Alta 1 nombre y contraseña de usuario,
usuarios
usuarios si son válidas se re direcciona a la
página del menú principal.
Creación de Módulo de
4 Alta 2 Formulario de nuevos usuarios.
nuevos usuarios usuarios
Modificación y
Módulo de Ver la lista de usuarios con
5 borrado de Alta 2
usuarios opciones de editar y eliminar.
usuarios
Crear y registrar Formulario de secretaria,
Módulo de
6 la estructura del Alta 4 direcciones, unidades y áreas,
usuarios
organigrama relacionadas una a la otra.
Formulario de ingreso de datos
Crear almacén Módulo de
del almacén, agregando su
7 Central y sub Alta artículos y 6
encargado que es un usuario
almacenes almacén
registrado.
Módulo de
Crear la partida Crear una partida desde un
8 Alta artículos y 3
presupuestaria formulario.
almacén

66
 Gestionar la Módulo de Ver la lista de artículos con sus
9 información de Media artículos y 2 datos y ser capaz de crear,
artículos almacén eliminar y modificar estos.
Gestión de Módulo de
Agregar una unidad desde un
10 unidades de Media artículos y 1
formulario.
medida almacén
Listar los proveedores y agregar
Gestión de Módulo de
11 Alta 3 uno nuevo además de modificar y
proveedores usuarios
eliminar los existentes.
Seleccionar con un rango de
Control de
Módulo de fechas y a un proveedor para
12 movimiento del Media 4
reportes generar un reporte de sus entradas
proveedor
al almacén.
Gestión de Lista los funcionarios y agregar
Módulo de
13 funcionarios de Alta 3 uno nuevo además de modificar y
usuarios
las unidades eliminar los existentes.
Acceso a la Módulo de Lista los productos del almacén
14 información de Media artículos y 5 con la cantidad de stock que
stock almacén tienen actualmente en una lista.
Lista los productos con el
Porcentaje de Módulo de
porcentaje de su stock, marca con
15 existencia de Media artículos y 4
otros colores los porcentajes
materiales almacén
menores a 50%, 25% y 10%
Módulo de Accede a un formulario en el cual
Ingreso de
16 Media Ingresos y 6 se introducen datos del proveedor
artículos
Pedidos y los artículos que ingresan.
Módulo de Genera un reporte en pdf y Excel
Generar nota de
17 Media Ingresos y 6 seleccionando uno de los ingresos
Ingreso
Pedidos ya realizados.
Módulo de En la lista de ingresos se puede
Anular nota de
18 Media Ingresos y 3 anular aquellos que no han tenido
Ingreso
Pedidos pedidos de sus artículos.
Módulo de Se abre un formulario para llenar
Pedido de
19 Media Ingresos y 6 lista de artículos que se pide y
artículos
Pedidos que unidad la pide.

67
 Módulo de Genera un reporte en pdf y Excel
Generar nota de
20 Media Ingresos y 6 seleccionando uno de los pedidos
pedido
Pedidos ya realizados.
En la lista de pedidos se puede
Aprobar y anular Módulo de aprobar los pedidos que están en
21 las notas de Media Ingresos y 3 borrador, también se puede anular
pedido Pedidos aquellos pedidos que aún no están
aprobados.
Se introduce un rango de fechas y
Reporte de Módulo de un artículo para generar un
22 Media 5
kardex reportes reporte en pdf y Excel para
conocer los movimientos.
Se introduce un rango de fechas y
un clasificador presupuestario
para generar un reporte en pdf y
Reporte mensual Módulo de
23 Media 5 Excel para conocer los
valorado reportes
movimientos de los artículos
comprendidos dentro del
clasificador seleccionado.
Se introduce un rango de fechas y
Generar los
Módulo de una unidad, dirección, área o
24 movimientos de Media 4
reportes secretaria para conocer sus
las unidades
movimientos en pdf y Excel.
Se lista todos los artículos con
stock hasta la fecha sacando la
suma de todos sus lotes y un
Módulo de promedio de sus costos.
Realizar el cierre
25 Baja Ingresos y 6 al cerrar gestión se cierran los
de gestión
Pedidos movimientos de los lotes pasados
y se crea un nuevo lote de inicio
de gestión. Esto se lo realiza por
lo general al acabar el año.
Un nivel de usuario que solo tiene
Enlace a la acceso a reporte de kardex y
Módulo de
26 unidad de Baja 5 reporte mensual valorado, puede
reportes
contabilidad sacar estos reportes de todos los
almacenes.

Fuente (Elaboración propia)

68
3.3.5. REQUERIMIENTOS DE HARDWARE Y SOFTWARE

Los requerimientos de hardware que permiten que el sistema funcione correctamente son:

• Pc de escritorio o laptop.
• Memoria RAM 2 GB o superior.
• Espacio de disco duro de 10 GB o superior.
• Procesador Dual - Core o superior (32 o 64 bits).

Los requerimientos de software son:

• MagicDRAW 18,4 con su plugin MagicUWE, para el diseño de los modelos de casos de
uso, conceptual, de navegación y de presentación.
• Navicat en conexión a base de datos MySQL, para el diseño de base de datos.
• HeidiSQL para realizar las consultas de la base de datos implentada.
• PHP con el framework Laravel, como lenguaje de programación del lado del servidor y
Bootstrap, como diseño con estilos web y plantilla Admin LTE.
• Apache, como servidor web.
• Google Chrome, como navegador web.
• Windows 7 o superior, como sistema operativo.

3.4. GAME

El propósito de esta etapa, es implementar el sistema para la entrega en una serie de

iteraciones llamadas Sprints.

3.4.1. SPRINT 0

Vamos a empezar con la iteración que denominamos iteración 0 o sprint 0 ya que en esta fase
vamos a realizar una tarea que podíamos hacerla en la etapa de planificación, pero por su
complejidad la realizamos en un sprint, ya se tiene definido el tiempo que tomara
implementarlo, días de trabajo y fecha de inicio, todo explicado en la tabla 3.30.

69
 Tabla 3.30Sprint 0
Sprint Módulo Inicio Duración

0 Diseño de la base de datos 05/11/2019 7 días

Fuente (Elaboración propia)

[Link]. PLANIFICACIÓN

Las actividades realizadas durante esta iteración se las puede observar en la tabla 3.31, que
constituye la pila de sprint correspondiente.

Objetivo: Comenzar con el desarrollo de los primeros requerimientos que se encuentran

actualmente en la Pila del Producto para obtener la primera versión funcional del software.

Tabla 3.31Pila de Sprint 0

Elementos del
Nro. Tareas Duración Estado
product backlog
• Realizar el diseño conceptual y
físico de la base de datos,
considerándolo un
requerimiento esencial y
Diseño de la base
1 tomando en cuenta los demás 7 días Terminado
de datos
requerimientos.
• Implementar el diseño
relacional en el gestor de base
de datos MySQL.
Fuente (Elaboración propia)

[Link]. DESARROLLO

Siguiendo con las tareas para el elemento número 1 de la pila de sprint se realizó el diseño
conceptual de la base de datos.

70
DIAGRAMA ENTIDAD RELACIÓN DE LA BASE DE DATOS

figura 3.2Diagrama Entidad relacion Sprint 0

Fuente: (Elaboración propia)

71
DIAGRAMA RELACIONAL DE LA BASE DE DATOS

figura 3.3 Modelo físico de la base de datos

Fuente: (Elaboración propia)

72
MODELO DE CONTENIDO DE LA BASE DE DATOS

figura 3.4 Modelo relacional de la base de datos

Fuente: (Elaboración propia)

73
[Link]. PRUEBAS

Se hizo las pruebas unitarias al servidor de base de datos donde se implementó la base de
datos.

Tabla 3.32Pruebas unitarias sprint 0

Nro. Descripción de la prueba Resultado

1 Se puede hacer consultas a la base de datos Cumple

Fuente (Elaboración propia)

IMPLEMENTACIÓN DE LA BASE DE DATOS

figura 3.5 Implementación de la base de datos en MySQL

Fuente: (Elaboración propia)

74
3.4.2. SPRINT 1

En este sprint se toma en cuenta todo lo relacionado con la información de los usuarios, tanto
los que son encargados en los almacenes y los que no tienen un ingreso, pero si una
interacción, además de guardar información de la organización, ya se tiene definido el tiempo
que tomara implementarlo, días de trabajo y fecha de inicio, todo explicado en la tabla 3.33.

Tabla 3.33Sprint 1
Sprint Módulo Inicio Duración

1 Gestión de usuarios 13/11/2019 17 días

Fuente (Elaboración propia)

[Link]. PLANIFICACIÓN

Las actividades realizadas durante esta iteración se las puede observar en la tabla 3.34, que
constituye la pila de sprint correspondiente.

Objetivo: Definir la prioridad de cada uno de los elementos de la pila de sprint para su pronto
desarrollo y poder entregar la versión de usuarios y llenado de primeros datos.

Tabla 3.34Pila de Sprint 1

Elementos del
Nro. Tareas Duración Estado
product backlog
• Realizar el modelo de los
usuarios con modelos basados
en UWE.
1 Gestión de usuarios 2 días Terminado
• Definir los atributos de la base
de datos para guardar los
distintos usuarios.
• Identificar los usuarios
Autenticación de
2 mediante un login el cual valida 1 días Terminado
ingreso de usuarios
su email y su contraseña,
• Codificar un formulario con los
datos y niveles necesarios para
Creación de nuevos
3 el registro de un nuevo usuario. 2 días Terminado
usuarios
• Realizar diagrama de casos de
uso.

75
 • Listar los usuarios existentes
Modificación y siendo posible borrarlos
4 2 días Terminado
borrado de usuarios verificando el nivel de rol del
usuario logeado al sistema.
• Codificar 4 formularios con los
datos para el registro de una
Crear y registrar la
nueva secretaria, dirección,
5 estructura del 4 días Terminado
unidad y área.
organigrama
• Realizar diagrama de casos de
uso.
• Codificar un formulario para
Gestión de registro de proveedores.
6 3 días Terminado
proveedores • Diseñar los modelos respecto a
la metodología UWE.
• Codificar un formulario para
Gestión de
registro de funcionarios.
7 funcionarios de las 3 días Terminado
• Diseñar los modelos respecto a
unidades
la metodología UWE.
Fuente (Elaboración propia)

[Link]. DESARROLLO

MODELO DE REQUERIMIENTOS

Según el modelo UWE se debe analizar los requerimientos existentes en la pila del primer
sprint y eso lo haremos utilizando diagramas de caso de uso, para eso vamos a unir en un solo
diagrama la gestión de usuarios con las altas bajas y modificaciones de los usuarios, para tener
un diagrama de caso de uso más completo, esto se aprecia en la figura 3.6 y figura 3.7.

Caso de uso de administración y acceso de usuarios

76
 figura 3.6 Caso de uso de administración y acceso de usuarios
Fuente: (Elaboración propia)

Tabla 3.35Caso de uso de administración y acceso de usuarios

Caso de Uso General
Actores Encargado de almacén central – Administrador,
encargado del sub almacén, contabilidad.
Descripción Permite ingresar al sistema a los 3 actores, previamente
registrados.
Mostrará las acciones que cada uno tenga disponibles.
El administrador será el único capaz de gestionar a los
usuarios.
Pre - condición Los actores deben tener estar registrados y tener un rol en
el sistema.
Flujo normal Paso Acción

77
 1 El actor ingresa su email y contraseña al sistema
para su posible ingreso.
2 El sistema verifica los datos, si los datos son
correctos el actor ingresa y ve sus tareas.
3 Si el actor es un administrador tendrá las tareas de
gestión de usuarios además de tener las de un
actor encargado del sub almacén
Flujo alternativo El actor administrador tendrá más opciones de gestión.
Excepciones Paso Acción
2 Si la verificación es falsa no ingresa al sistema.
Cometarios El tiempo de respuesta dependerá del flujo de red.
Fuente (Elaboración propia)

Caso de uso de gestión de organigrama

figura 3.7 Caso de uso de gestión de organigrama

78
 Fuente: (Elaboración propia)

Tabla 3.36Caso de uso de gestión de organigrama

Caso de Uso General
Actores Encargado de almacén central – Administrador
Descripción Permite registrar el organigrama de la alcaldía con todas
sus secretarias, direcciones, unidades y áreas.
Pre - condición El actor debe ser un administrador.
Flujo normal Paso Acción
1 Se ingresa los datos de las secretarias necesarias
y se guarda.
2 Se ingresa los datos de las direcciones necesarias
y se guarda.
3 Se ingresa los datos de las unidades necesarias y
se guarda.
4 Se ingresa los datos de las áreas necesarias y se
guarda.
Flujo alternativo Se puede omitir la creación de áreas.
Excepciones Paso Acción
2 No se podrá crear si no existe una secretaria a la
cual apuntar la dependencia.
3 No se podrá crear si no existe una dirección a la
cual apuntar la dependencia.
4 No se podrá crear si no existe una unidad a la cual
apuntar la dependencia.
Cometarios El tiempo de respuesta dependerá del flujo de red.
Las secretarias pueden funcionar como la máxima
instancia de dependencia.
Fuente (Elaboración propia)

MODELO DE DATOS

El modelo de datos contempla todas las tablas relacionadas al diseño de autentificación y a la

estructura del organigrama de la institución, secretaria, direcciones, unidades y áreas, esto se
ve en la figura 3.8 y figura 3.9.

Diagrama entidad relación

79
 figura 3.8Diagrama entidad relación Sprint 1
Fuente (Elaboración propia)

Diagrama físico

figura 3.9Diagrama fisico Sprint 1

Fuente (Elaboración propia)

80
MODELO DE CONTENIDO

A partir de la identificación de los requerimientos del sistema y posteriormente los casos de

uso que propone la metodología UWE, la solución planteada debe contar con un conjunto de
entidades que ayuden a satisfacer dichas necesidades determinadas. Estas entidades son
representadas a través del modelo conceptual. La Figura 3.10, muestra las clases principales
de la autenticación de usuarios.

figura 3.10 Diagrama de clases del módulo Gestión de usuarios

Fuente: (Elaboración propia)

81
MODELO DE NAVEGACIÓN

En este modelo se especifica la relación interna del sitio web, es decir cómo se relaciona cada
página web con las demás. La Figura 3.11, presenta el modelo de navegación para los
módulos de gestión de usuarios junto con la gestión de la organización.

figura 3.11 Diagrama de navegación del módulo de Gestión de usuarios

Fuente: (Elaboración propia)

MODELO DE PRESENTACIÓN

En este modelo se procede a mostrar las vistas que interactúan y muestran contenido a los
diferentes usuarios, se muestra un contenido de los nodos de la interfaz de usuario ordenado y
enlazando nodo a nodo. Se representa como cada nodo es presentado al usuario.
La Figura 3.12, muestra la página de ingreso al sistema.

82
 figura 3.12Diagrama de presentación del módulo de Gestión de usuarios
Fuente: (Elaboración propia)

La figura 3.13 muestra la página principal al ingresar al sistema.

figura 3.13 Diagrama de presentación del módulo de ingreso al sistema

Fuente: (Elaboración propia)

83
La figura 3.14 muestra la gestión de usuarios

figura 3.14 Diagrama de presentación del módulo de ingreso al sistema

Fuente: (Elaboración propia)

[Link]. PRUEBAS

Se hizo las pruebas unitarias a los sub módulos que se diseñaron, los resultados se expresan en
la tabla 3.37.

Tabla 3.37Pruebas unitarias sprint 1

Nro. Descripción de la prueba Resultado

Se encuentran las tablas necesarias en la base de datos para

1 Cumple
almacenar los datos de los diferentes usuarios
Se ingresa con un login al sistema verificando sus datos para
2 Cumple
permitir o rechazar el ingreso
Crea y añade a la base de datos nuevos usuarios con los datos
3 Cumple
necesarios para hacer el control

4 Modifica y elimina los usuarios ya existentes Cumple

Crea y registra secretarias, direcciones, unidades y áreas

5 Cumple
siguiendo el orden de relación entre ellas.

6 Registra los datos de los proveedores al sistema, sin darles un Cumple

84
 acceso

Registra un usuario denominado contabilidad que tiene permiso

7 Cumple
restringido a la mayoría de las tareas de los demás
Fuente (Elaboración propia)

3.4.3. SPRINT 2

En este sprint se toma en cuenta todo lo relacionado con la información los artículos y los
almacenes, eso incluye las partidas presupuestarias y los registros de existencias actuales de
los almacenes, ya se tiene definido el tiempo que tomara implementarlo, días de trabajo y
fecha de inicio, todo explicado en la tabla 3.38.

Tabla 3.38Sprint 2
Sprint Módulo Inicio Duración
Gestión de artículos y
2 02/12/2019 21 días
almacén
Fuente (Elaboración propia)

[Link]. PLANIFICACIÓN

Las actividades realizadas durante esta iteración se las puede observar en la tabla 3.39, que
constituye la pila de sprint correspondiente.

Objetivo: Definir la prioridad de cada uno de los elementos de la pila de sprint para su pronto
desarrollo y poder entregar la versión de usuarios y llenado de primeros datos.

Tabla 3.39Pila de Sprint 2

Elementos del
Nro. Tareas Duración Estado
product backlog
• Realizar las paginas necesarias
para crear un almacén,
asignando un usuario
Crear almacén
correspondiente como
1 Central y sub 6 Terminado
responsable.
almacenes
• Diseñar a base de modelos de
UWE.
• Crear diagrama de caso de uso

85
 • Crear la partida con los datos
correspondientes para agrupar a
Crear la partida los artículos.
2 3 Terminado
presupuestaria • Diseñar a base de modelos de
UWE.
• Crear diagrama de caso de uso
• Realizar el CRUD de los
Gestionar la artículos.
3 información de • Diseñar a base de modelos de 2 Terminado
artículos UWE.
• Crear diagrama de caso de uso
• Registrar el nombre de las
unidades de medida.
Gestión de unidades
4 • Diseñar a base de modelos de 1 Terminado
de medida
UWE.
• Crear diagrama de caso de uso
• Listar el stock actual de los
Acceso a la artículos en los almacenes.
5 información de • Diseñar a base de modelos de 5 Terminado
stock UWE.
• Crear diagrama de caso de uso
• Mostrar alertas de colores si el
Porcentaje de porcentaje de stock es bajo.
6 existencia de • Diseñar a base de modelos de 4 Terminado
materiales UWE.
• Crear diagrama de caso de uso
Fuente (Elaboración propia)

[Link]. DESARROLLO

MODELO DE REQUERIMIENTOS

Según el modelo UWE se debe analizar los requerimientos existentes en la pila del segundo
sprint y eso lo realizamos utilizando diagramas de caso de uso, para facilitar la interpretación
del diagrama de caso de uso se unirán los sub módulos de artículos y los sub módulos de
almacén. Esto se ve en las figuras 3.15 y 3.16.

86
Caso de uso de gestión de almacenes

figura 3.15Caso de uso de gestión de almacenes

Fuente: (Elaboración propia)

Tabla 3.40Caso de uso de gestión de almacenes

Caso de Uso General
Actores Encargado de almacén central – administrador.
Encargado del sub almacén
Descripción El administrador crea un almacén central y otros sub
almacenes para los usuarios encargados.
Se visualizan los stocks de los almacenes, el almacén
central podrá ver de todos.
Pre - condición Los actores deben tener asignado un almacén, en caso de
no tenerlo el administrador debe asignar uno.
Flujo normal Paso Acción
1 El administrador crea el almacén sea central o sub
almacén.

87
 2 El administrador asigna el almacén creado a un
usuario.
3 Si el actor es encargado del almacén central
puede ver el stock y las alertas de los demás sub
almacenes.
4 El actor encargado del sub almacén podrá ver el
stock de su sub almacén.
Flujo alternativo En lugar de crear y asignar se puede modificar el
encargado de un almacén creado.
Excepciones Paso Acción
2 Si el usuario elegido ya tiene un almacén
asignado no podrá tener otro.
Cometarios El tiempo de respuesta dependerá del flujo de red.
Los almacenes sin stock presentaran una tabla vacía, esto
no es un fallo.
Fuente (Elaboración propia)

Caso de uso de gestión de artículos

figura 3.16 Caso de uso de gestión de artículos

Fuente: (Elaboración propia)

88
 Tabla 3.41Caso de uso de gestión de artículos
Caso de Uso General
Actores Encargado de almacén central – Administrador
Descripción Gestionar partidas presupuestarias y artículos.
Registrar unidades de medida.
Pre - condición El actor debe ser un administrador.
El actor debe estar dentro del sistema.
Flujo normal Paso Acción
1 Se crea la partida presupuestaria con un código
único.
2 Se crea una artículo con un código único y
dependiendo de una partida presupuestaria..
3 Se asigna una unidad de medida.
Flujo alternativo Se puede modificar y cambiar su estado a inactivo las
partidas presupuestarias y los artículos.
Excepciones Paso Acción
2 No se podrá crear un artículo si no existe
previamente la partida presupuestaria de la que
depende.
3 Si la unidad de medida deseada no existe se
procede a crear una nueva.
Cometarios El tiempo de respuesta dependerá del flujo de red.
Las partidas presupuestarias solo se pueden cambiar de
estado a inactivo y no borrarse, esto para no afectar la
integridad de la base de datos.
Fuente (Elaboración propia)

MODELO DE DATOS

El modelo de datos incluye a las tablas que interactúan para administrar a los almacenes y a
los artículos, esto incluye usuarios y clasificador presupuestario, esto se ve en la figura 3.17 y
figura 3.18.

89
Diagrama entidad relación

figura 3.17Diagrama entidad relación Sprint 2

Fuente (Elaboración propia)

Diagrama físico

figura 3.18Diagrama físico de la base de datos Sprint 2

Fuente (Elaboración propia)

90
MODELO DE CONTENIDO

A partir de la identificación de los requerimientos del sistema y posteriormente los casos de

uso que propone la metodología UWE, la solución planteada debe contar con un conjunto de
entidades que ayuden a satisfacer dichas necesidades determinadas. Estas entidades son
representadas a través del modelo de contenido. La Figura 3.19, muestra las clases principales
de gestión de artículos y de almacén.

figura 3.19Diagrama de clases de contenido del módulo Gestión de artículos y almacén

Fuente: (Elaboración propia)

MODELO DE NAVEGACIÓN

En este modelo explicamos cómo se interactúa y se mueve entre las páginas del sistema un
usuario. La Figura 3.20, presenta el modelo de navegación para los módulos de gestión de
usuarios junto con la gestión de la organización.

91
 figura 3.20Diagrama de navegación del módulo de Gestión de artículos y almacenes
Fuente: (Elaboración propia)

MODELO DE PRESENTACIÓN

En este modelo se procede a mostrar las vistas que interactúan y muestran contenido a los
diferentes usuarios, se muestra un contenido de los nodos de la interfaz de usuario ordenado y
enlazando nodo a nodo. Se representa como cada nodo es presentado al usuario.
La Figura 3.21, muestra la lista de almacenes y crear uno nuevo.

92
 figura 3.21 Diagrama de presentación del módulo de Gestión de almacenes
Fuente: (Elaboración propia)

La figura 3.22 muestra la lista de artículos y crear uno nuevo.

figura 3.22 Diagrama de presentación del módulo de Gestión de artículos

Fuente: (Elaboración propia)

93
[Link]. PRUEBAS

Se hizo las pruebas unitarias a los sub módulos que se diseñaron, los resultados se expresan en
la tabla 3.42.

Tabla 3.42Pruebas unitarias sprint 2

Nro. Descripción de la prueba Resultado

Se encuentran en la base de datos en la tabla correspondiente

1 los registros de los almacenes creados, así como todas sus Cumple
relaciones.
Se registran en la base de datos las partidas presupuestarias,
2 Cumple
teniendo un código de partida único.
Se registran en la base de datos los artículos, teniendo un
3 Cumple
código de partida único.
Se agregan las unidades de medida para asignarle a un artículo
4 Cumple
en específico.
Se listan todos los artículos por cada almacén, estos con su
5 Cumple
stock, incluso cuando estos están en cero.
Se lista los porcentajes de los stocks por cada artículo en
6 existencias de almacén, estos cambian de color al estar debajo Cumple
de un porcentaje definido.
Fuente (Elaboración propia)

3.4.4. SPRINT 3

En este sprint se toman en cuenta todos los movimientos de los artículos que existen dentro
del almacén y con otros almacenes, tanto de ingresos, pedidos y traspasos entre almacenes, ya
se tiene definido el tiempo que tomara implementarlo, días de trabajo y fecha de inicio, todo
explicado en la tabla 3.43.

Tabla 3.43Sprint 3
Sprint Módulo Inicio Duración

3 Ingresos y pedidos 27/12/2019 36 días

Fuente (Elaboración propia)

94
[Link]. PLANIFICACIÓN

Las actividades realizadas durante esta iteración se las puede observar en la tabla 3.44, que
constituye la pila de sprint correspondiente.

Objetivo: Definir la prioridad de cada uno de los elementos de la pila de sprint para su pronto
desarrollo y poder entregar la versión de usuarios y llenado de primeros datos.

Tabla 3.44Pila de Sprint 3

Elementos del
Nro. Tareas Duración Estado
product backlog
• Realizar las paginas necesarias
con los campos suficientes para
registrar una nota de ingreso
1 Ingreso de artículos con sus diferentes artículos. 6 días Terminado
• Diseñar a base de modelos de
UWE.
• Crear diagrama de caso de uso

Generar nota de • Generar el pdf y el Excel de la

2 Ingreso nota de ingreso 6 días Terminado
• Crear diagrama de caso de uso
Anular nota de • Anular verificando que no
3 3 días Terminado
Ingreso hayan salidos artículos.
• Codificar ventanas que puedan
registrar y modificar las notas
de pedido.
4 Pedido de artículos 6 días Terminado
• Diseñar a base de modelos de
UWE.
• Crear diagrama de caso de uso
• Listar los pedidos en una
Generar nota de ventana y generar sus notas en
5 6 días Terminado
pedido pdf y Excel.
• Crear diagrama de caso de uso
• Anular las notas previa
Aprobar y anular las verificación.
6 3 días Terminado
notas de pedido • Diseñar la ventana de
aprobación de las notas.

95
 • Codificar la ventana para
Realizar el cierre de realizar el cierre de gestión.
7 6 días Terminado
gestión • Visualizar antes los artículos y
sus nuevos precios y stock.
Fuente (Elaboración propia)

[Link]. DESARROLLO

MODELO DE REQUERIMIENTOS

Según el modelo UWE se debe analizar los requerimientos existentes en la pila del
tercersprint y eso lo realizamos utilizando diagramas de caso de uso, se dividirá los sub
módulos en los pedidos y los ingresos, figura 3.23 y figura 3.24.

Caso de uso de notas de ingreso

figura 3.23 Caso de uso de notas de ingreso

Fuente: (Elaboración propia)

96
 Tabla 3.45Caso de uso de notas de ingreso
Caso de Uso General
Actores Encargado de almacén central.
Encargado del sub almacén
Descripción El encargado de almacén o sub almacén podrá acceder a
ingresar más artículos o nuevos artículos para aumentar el
stock en su almacén.
Pre - condición Los actores deben estar registrados en el sistema con un
almacén.
Deben existir artículos y proveedores creados.
Flujo normal Paso Acción
1 El actor de almacén ingresa al formulario de
nueva nota de pedido.
2 El actor selecciona un proveedor.
3 Se listan los artículos que están ingresando
haciendo un detalle de ellos, cada uno de estos
supondrá un nuevo lote.
4 Se guarda y genera la nota de ingreso
Flujo alternativo Se puede anular la nota de ingreso si no hubieron salidas
de artículos.
Excepciones Paso Acción
3 Si el atributo número de comprobante ya existe
no se podrá guardar.
Cometarios El tiempo de respuesta dependerá del flujo de red.
Fuente (Elaboración propia)

Caso de uso de notas de pedido

97
 figura 3.24Caso de uso de notas de pedido
Fuente: (Elaboración propia)

Tabla 3.46Caso de uso de notas de pedido

Caso de Uso General
Actores Encargado de almacén central.
Encargado del sub almacén.
Solicitante.
Descripción El encargado de almacén o sub almacén podrá acceder a
disminuir el stock de su almacén repartiendo productos a
unidades solicitantes.
Pre - condición Los actores encajados de almacén deben estar registrados
en el sistema con un almacén.
El nombre del solicitante debe estar registrado así como
su unidad.
Flujo normal Paso Acción
1 El actor de almacén ingresa al formulario de
nueva nota de pedido.

98
 2 El actor selecciona la unidad y el registro del
funcionario solicitante.
3 Se listan por lote del más antiguo al más nuevo
los artículos deseados. El actor elegirá los
artículos y sus lotes.
4 Se registra la cantidad pedida y la cantidad
aprobada por artículo.
5 Se guarda y se genera la nota de pedido.
6 Las notas de pedido se aprueban ingresando los
datos del funcionario que recogió los artículos.
Flujo alternativo Se pueden anular las notas de pedido que no hayan sido
aprobadas, sin afectar al stock del almacén.
Excepciones Paso Acción
3 No puede seleccionar el articulo más reciente, de
hacerlo incumple la regla de P.E.P.S.
3 No se podrá elegir dos veces el artículo del
mismo lote.
4 La cantidad pedida debe ser menor o igual a la
cantidad aprobada.
5 Si el atributo número de comprobante ya existe
no se podrá guardar.
Cometarios El tiempo de respuesta dependerá del flujo de red.
Fuente (Elaboración propia)

MODELO DE DATOS

El modelo de datos incluye a las tablas que se usan al hacer una nota de ingreso de artículos y
de pedido de artículos que es muy común que lo hagan las unidades y al ingresar que se
registre un proveedor, esto se ve en la figura 3.25 y figura 3.26.

99
Diagrama entidad relación

figura 3.25Diagrama entidad relación Sprint 3

Fuente (Elaboración propia)

Diagrama físico

figura 3.26Modelo fisico de la base de datos Sprint 3

Fuente (Elaboración propia)

100
MODELO DE CONTENIDO

A partir de la identificación de los requerimientos del sistema y posteriormente los casos de

uso que propone la metodología UWE, la solución planteada debe contar con un conjunto de
entidades que ayuden a satisfacer dichas necesidades determinadas. Estas entidades son
representadas a través del modelo de contenido. La Figura 3.27 muestra los movimientos de
ingreso y salida del almacén.

figura 3.27Diagrama de clases de contenido del módulo ingresos y pedidos

Fuente: (Elaboración propia)

101
MODELO DE NAVEGACIÓN

En este modelo explicamos cómo se interactúa y se mueve entre las páginas del sistema un
usuario. La Figura 3.28 presenta el modelo de navegación para los ingreso y pedido del
almacén.

figura 3.28 Diagrama de navegación del módulo de ingreso y pedidos

Fuente: (Elaboración propia)

MODELO DE PRESENTACIÓN

En este modelo se procede a mostrar las vistas que interactúan y muestran contenido a los
diferentes usuarios, se muestra un contenido de los nodos de la interfaz de usuario ordenado y
enlazando nodo a nodo. Se representa como cada nodo es presentado al usuario.
La Figura 3.29, muestra la lista de notas de ingresos y crear uno nuevo.

102
 figura 3.29Diagrama de presentación del módulo de ingresos
Fuente: (Elaboración propia)

La figura 3.30 muestra la lista de notas de pedido y crear uno nuevo.

figura 3.30 Diagrama de presentación del módulo de pedidos

Fuente: (Elaboración propia)

103
[Link]. PRUEBAS

Se hizo las pruebas unitarias a los sub módulos que se diseñaron, los resultados se expresan en
la tabla 3.47.

Tabla 3.47Pruebas unitarias sprint 3

Nro. Descripción de la prueba Resultado

Se encuentran en la base de datos en la tabla correspondiente a

1 Cumple
las notas de ingreso, así como todas sus relaciones.

2 Se generan notas de ingreso en pdf y Excel. Cumple

3 Se anulan las notas de ingreso que no sufren pedidos. Cumple

Se encuentran en la base de datos en la tabla correspondiente a

4 Cumple
las notas de pedido, así como todas sus relaciones.

5 Se generan notas de pedido en pdf y Excel. Cumple

Se aprueban cambiando el estado a aprobado las notas de

6 Cumple
pedido y se anulan las que no fueron aprobadas.
Fuente (Elaboración propia)

3.4.5. SPRINT 4

En este sprint se toman en cuenta todos reportes que genera el sistema, en especial los que
sirven de control de stock y de contabilidad, ya se tiene definido el tiempo que tomara
implementarlo, días de trabajo y fecha de inicio, todo explicado en la tabla 3.48.

Tabla 3.48Sprint 4
Sprint Módulo Inicio Duración

3 Obtener reportes 05/02/2020 23 días

Fuente (Elaboración propia)

[Link]. PLANIFICACIÓN

Las actividades realizadas durante esta iteración se las puede observar en la tabla 3.49, que
constituye la pila de sprint correspondiente.

104
Objetivo: Definir la prioridad de cada uno de los elementos de la pila de sprint para su pronto
desarrollo y poder entregar la versión de usuarios y llenado de primeros datos.

Tabla 3.49Pila de Sprint 4

Elementos del
Nro. Tareas Duración Estado
product backlog
• Realizar el reporte de los
Control de registros de ingreso de cierto
1 movimiento del proveedor. 4 días Terminado
proveedor • Diseñar a base de modelos de
UWE.
• Codificar la ventana con un
rango de fechas para sacar el
Reporte de kardex
2 reporte. 5 días Terminado
• Generar el pdf y el Excel.
• Crear diagrama de caso de uso
• Codificar la ventana con un
rango de fechas para sacar el
Reporte mensual
3 reporte. 5 días Terminado
valorado
• Generar el pdf y el Excel.
• Crear diagrama de caso de uso
• Codificar la ventana con un
Generar los rango de fechas para sacar el
4 movimientos de las reporte. 4 días Terminado
unidades • Generar el pdf y el Excel.
• Crear diagrama de caso de uso
• Crear un nuevo acceso a un
Enlace a la unidad
5 usuario con ciertas facultades 5 días Terminado
de contabilidad
limitadas.
Fuente (Elaboración propia)

[Link]. DESARROLLO

MODELO DE REQUERIMIENTOS

Según el modelo UWE se debe analizar los requerimientos existentes en la pila del cuarto
sprint y eso lo realizamos utilizando diagramas de caso de uso. Se unirán los reportes
similares.

105
Caso de uso reportes valorados

figura 3.31Caso de uso de reportes valorados

Fuente: (Elaboración propia)

Tabla 3.50Caso de uso de reportes valorados

Caso de Uso General
Actores Encargado de almacén central.
Encargado del sub almacén.
Contabilidad.
Descripción Se generar reportes contables capaces de ofrecer
información histórica de los movimientos.
Pre - condición Los actores encargados de almacén deben estar
registrados en el sistema con un almacén.
El actor de contabilidad debe estar dentro del sistema, no
tiene almacén asignado.
Flujo normal Paso Acción

106
 1 El actor de ingresa al formulario de reporte y
selecciona los rangos de fecha.
2 Selecciona alguno de los siguientes: articulo,
clasificador, unidad, proveedor, dependiendo al
tipo de reporte que genere.
3 En caso de ser actor de contabilidad selecciona
adicionalmente el almacén.
4 Genera el reporte en pdf y Excel.
Flujo alternativo Se puede generar el reporte si necesidad de descargar en
pdf o Excel.
Excepciones Paso Acción
1 La fecha inicial debe ser más antigua que la fecha
final.
Cometarios El tiempo de respuesta dependerá del flujo de red.
Fuente (Elaboración propia)

MODELO DE DATOS

El modelo de datos incluye a las tablas que necesitamos y sus relaciones para lograr generar
los reportes de acuerdo a los requerimientos, tomando en cuenta la consistencia de datos, esto
se ve en la figura 3.32 y figura 3.33.

Diagrama entidad relación

107
 figura 3.32Diagrama entidad relación Sprint 4
Fuente (Elaboración propia)

Diagrama físico

figura 3.33Diagrama físico de la base de datos Sprint 4

Fuente (Elaboración propia)

MODELO DE CONTENIDO

108
A partir de la identificación de los requerimientos del sistema y posteriormente los casos de
uso que propone la metodología UWE, la solución planteada debe contar con un conjunto de
entidades que ayuden a satisfacer dichas necesidades determinadas. Estas entidades son
representadas a través del modelo de contenido. La Figura 3.34 muestra los movimientos de
ingreso y salida del almacén.

figura 3.34 Diagrama de clases de contenido del módulo reportes

Fuente: (Elaboración propia)

MODELO DE NAVEGACIÓN

En este modelo explicamos cómo se interactúa y se mueve entre las páginas del sistema un
usuario. La Figura 3.35, presenta el modelo de navegación para los reportes.

109
 figura 3.35 Diagrama de navegación del módulo de reportes
Fuente: (Elaboración propia)

MODELO DE PRESENTACIÓN

En este modelo se procede a mostrar las vistas que interactúan y muestran contenido a los
diferentes usuarios, se muestra un contenido de los nodos de la interfaz de usuario ordenado y
enlazando nodo a nodo. Se representa como cada nodo es presentado al usuario.
La Figura 3.36, muestra el formulario de reporte genérico, ya que todos usan uno similar.

110
 figura 3.36Diagrama de presentación del módulo de reportes
Fuente: (Elaboración propia)

[Link]. PRUEBAS

Se hizo las pruebas unitarias a los sub módulos que se diseñaron, los resultados se expresan en
la tabla 3.37.

Tabla 3.51Pruebas unitarias sprint 4

Nro. Descripción de la prueba Resultado

Se realiza la consulta para obtener el historial de proveedores y

1 Cumple
sus ingresos al almacén.
Reporte de kardex con datos y cifras ajustadas para un historial
2 Cumple
de movimientos.
Reporte de los clasificadores presupuestarios haciendo un
3 Cumple
resumen de sus artículos.
Reporte de las secretarias, direcciones, unidades y áreas sobre
4 Cumple
los pedidos que hacen al almacén.

111
 Ingreso diferenciado para rol de contabilidad capaz de sacar
5 Cumple
reporte de kardex y mensual valorado de todos los almacenes.
Fuente (Elaboración propia)

3.5. POST GAME

Luego de haber culminado todas las iteraciones, en esta última etapa de la metodología
Scrum, se realiza la etapa de pruebas y el diseño de interfaces.

3.5.1. PRUEBAS DE INTEGRACIÓN

Las pruebas de integración se aplicarán con el fin de verificar que todos los módulos
funcionan correctamente en conjunto una vez que se hayan probado de forma individual o
unitaria, estas pruebas ya se realizaron y se verifico el correcto funcionamiento de todas las
ventanas en interacción con el usuario.

La siguiente tabla 3.52 muestra las pruebas de integración que se hicieron:

Tabla 3.52Tabla de pruebas de integración

Nro. Descripción de prueba Resultado

Luego de validar al usuario mediante la ventana de login lo re

1 Cumple
direcciona a la pantalla de inicio.

2 El sistema tiene un menú lateral fácil, intuitivo y funcional. Cumple

Los usuarios tienen la vista de opciones limitada dependiendo a

3 Cumple
su rol.
Todas las opciones del menú conectan con la respetiva ventana
4 Cumple
o tarea.
Los datos ingresados a la base de datos están restringidos a los
5 usuarios comunes, incluso el administrador no tiene acceso a Cumple
datos confidenciales.

6 Se realizan consultas con funciones para agilizar el proceso. Cumple

Todos los módulos tienen un validador de usuario logeado para

7 Cumple
evitar ingresos desde otra máquina.
El sistema funciona correctamente en la arquitectura de
8 Cumple
software propuesta

112
 Las sesiones se cierran automáticamente cuando detecta
9 Cumple
inactividad
Fuente (Elaboración propia)

3.5.2. PRUEBAS DE ACCESO DE USUARIOS

Las pruebas de acceso de usuario se realizan a fin de verificar los módulos relacionados con
cada rol de usuario que tiene acceso al sistema. Se explica el resultado en la tabla 3.53.

Tabla 3.53Tabla de pruebas de acceso de usuarios

Tipo de usuario Acceso

- Módulo de gestión de usuarios

- Módulo de gestión de almacenes
- Módulo de gestión de artículos
- Módulo de gestión de organigrama
- Módulo de control a sub almacenes
Administrador – Almacén
- Módulo de gestión de funcionarios
central
- Módulo de gestión de proveedores
- Módulo de registro de entradas
- Módulo de registro de pedidos
- Módulo de consulta de reportes
- Módulo de cierre de gestión
- Módulo de gestión de funcionarios
- Módulo de gestión de proveedores
- Módulo de registro de entradas
Sub almacenes
- Módulo de registro de pedidos
- Módulo de consulta de reportes
- Módulo de cierre de gestión
- Módulo de reportes de todos los
Contabilidad
almacenes
Fuente (Elaboración propia)

Cada usuario ingresa con existo y puede realizar las tareas descritas en la tabla anterior.

113
3.5.3. DISEÑO DE INTERFACES

Se mostrarán las capturas de las interfaces agrupadas por sprint para cumplir con los
requerimientos planteados.

SPRINT 1 – GESTIÓN DE USUARIOS

Autentificación

En esta ventana mostramos el login de ingreso al sistema, este nos pedirá el correo y el
password, como se ve en la figura 3.37, de ser correctos se direcciona a la ventana principal
mostrando opciones según el rol.

figura 3.37Validación de ingreso al sistema

Fuente: (Elaboración propia)

Ingreso al sistema

Esta es la ventana que se muestra luego de tener un ingreso exitoso, tenemos habilitadas todas
las acciones como administrador como se ve en la figura 3.38.

114
 figura 3.38 Ingreso al sistema como administrador – almacén central
Fuente: (Elaboración propia)

Agregar nuevo usuario

Un paso muy importante es crear más usuarios que serán encargados de los sub almacenes,
esto se aprecia claramente en la figura 3.39, se piden los datos necesarios para poder
administrar al usuario.

figura 3.39Crear nuevo usuario

Fuente: (Elaboración propia)

115
Gestión de usuarios

En esta ventana se mostrar un listado de los usuarios del sistema, incluso los que están
inactivos, esto se puede apreciar en la figura 3.40.

figura 3.40Gestión de los usuarios

Fuente: (Elaboración propia)

Registro del organigrama

En esta ventana se puede registrar las áreas, unidades, direcciones y secretarias. Esto se puede
ver en la figura 3.41.

figura 3.41Registro del organigrama

Fuente: (Elaboración propia)

116
Gestión de proveedores

Esta ventana nos proporciona la opción de agregar más proveedores, agregando sus datos
básicos podremos agregarlo, eliminarlo o editarlo, además podremos buscar cualquier
proveedor con su nombre. Esto se aprecia en la figura 3.42.

figura 3.42Gestión de proveedores

Fuente: (Elaboración propia)

Gestión de Funcionarios

En la figura 3.43 se ve la ventana en la cual tendremos el listado de los funcionarios que

trabajan actualmente en la alcaldía y tienen interacción directa con el sistema. Se registran los
datos básicos para agregar uno nuevo especificando cual es la unidad en la cual trabaja.

117
 figura 3.43Gestión de Funcionarios
Fuente: (Elaboración propia)

SPRINT 2 – GESTIÓN DE ARTÍCULOS Y ALMACÉN

Agregar sub almacenes

En esta interfaz podemos adicionar un sub almacén, es muy importante que se añada un
encargado que será un usuario existente con ingreso, además se debe incluir a la unidad que
esta pertenece, esto se aprecia en la figura 3.44.

118
 figura 3.44Creación de almacén
Fuente: (Elaboración propia)
Gestión de almacenes

Esta ventana nos ayudara a visualizar los sub almacenes activos, también se pueden eliminar o
editar para asignarle otro responsable, esto se puede ver en la figura 3.45.

figura 3.45Gestión de almacenes

Fuente: (Elaboración propia)

119
Clasificador presupuestario

Esta interfaz nos permite registrar y gestionar el clasificador presupuestario, que será de gran
ayuda para organizar los artículos, este clasificador se lo registra con los datos necesarios y
con un código único, esto se puede ver en la figura 3.46.

figura 3.46Gestión de clasificador presupuestario

Fuente: (Elaboración propia)
Artículos

Esta ventana nos da las herramientas necesarias para administrar los artículos, podemos crear
un nuevo artículo seleccionando el clasificador presupuestario correspondiente y además de
poder listar, podemos editarlo y cambiar su estado a inactivo, esto se puede ver en la figura
3.47.

120
 figura 3.47Gestión de artículos
Fuente: (Elaboración propia)
Stocks y porcentajes

En la figura 3.48 se aprecia cómo podemos visualizar el stock de los artículos y el porcentaje
de existencias en relación a la cantidad inicial, los porcentajes son de gran ayuda ya que se
pintan de color según la cantidad dando alertas cuando están por debajo del 50%.

figura 3.48 Vista de existencias y porcentajes

Fuente: (Elaboración propia)

121
SPRINT 3 – INGRESOS Y PEDIDOS

Ingresos de artículos

En la figura 3.49 se aprecia los datos requeridos para realizar una nota de ingreso, todos los
datos son de vital importancia para registrar la nota de ingreso, seleccionando el proveedor,
articulo y cantidad.

figura 3.49 Crear nota de ingreso

Fuente: (Elaboración propia)
Las notas de ingreso registradas se muestran en un listado como se ve en la figura 3.50, estas
se pueden anular solo si el botón está marcado con rojo de lo contrario es imposible anularla.

122
 figura 3.50Gestión de ingresos
Fuente: (Elaboración propia)
La nota de ingreso se la puede descargar y mostrar en formato PDF como se ve en la figura
3.51.

figura 3.51 Reporte de nota de ingreso

Fuente: (Elaboración propia)

123
Pedido de artículos

En la figura 3.52 se puede observar la ventana de realizar un pedido, esta solicita todos los
datos necesarios, como ser la unidad que solicita, el funcionario y la lista de artículos con su
cantidad.

figura 3.52 Registro de nota de pedido

Fuente: (Elaboración propia)
En la figura 3.53 se observa el listado de los pedidos realizados, estos se pueden anular o
aprobar, aquellos que ya se hayan anulado o pedido no se muestran con esas opciones.

figura 3.53 Gestión de notas de pedidos

Fuente: (Elaboración propia)

124
El pedido se lo puede generar en formato PDF, queda bien remarcado el estado en el que esta,
es este caso es aprobado, pero si es un pedido anulado nos muestra con una marca de agua
indicando ANULADO, lo mismo pasa si aúnestá en borrador sin aprobar, esto se ve en la
figura 3.54.

figura 3.54Reporte de nota de pedido

Fuente: (Elaboración propia)
Cierre de gestión

Esta ventana se encarga de cerrar la gestión promediando los costos, se muestra el listado de
artículos que existen y su stock con el promedio del precio unitario, figura 3.55.

125
 figura 3.55Cierre de gestión
Fuente: (Elaboración propia)

SPRINT 4 – OBTENER REPORTES

Kardex

Esta ventana nos pedirá los datos del artículo que deseamos consultar y el rango de fechas
para su respectivo reporte, se ve en la figura 3.56.

figura 3.56 Reporte de kardex

Fuente: (Elaboración propia)

126
El reporte que se genera puede ser también en pdf que nos da un resumen completo y
ordenado del articulo según requerimientos de la unidad de almacenes, esto se ve en la figura
3.57, con el ejemplo del artículo de Papel Carbónico y sus movimientos.

figura 3.57Reporte de kardex en pdf

Fuente: (Elaboración propia)

Este reporte de kardex también puede ser descargado en un formato de hoja de cálculo Excel, esta
facilita la realización de tareas de contabilidad, se ve en la figura 3.58.

127
 figura 3.58Reporte de kardex en Excel
Fuente: (Elaboración propia)
Se mostrará el resumen de sus movimientos, como se ve en la figura 3.59.

figura 3.59Reporte mensual valorado

Fuente: (Elaboración propia)

128
Este reporte también puede ser descargado en formato PDF cumpliendo las normas de estética
solicitadas como se ve en la figura 3.60.

figura 3.60Reporte mensual valorado en pdf

Fuente: (Elaboración propia)
Reporte por unidad

En la figura 3.61 se puede ver el formato de ingreso de datos para obtener un reporte de los
movimientos por unidad, los artículos, la cantidad y fechas en las que realizo pedidos.

figura 3.61Reporte por unidad

Fuente: (Elaboración propia)

129
Reporte por proveedor

En la figura 3.62 se aprecia los campos que se requiere para obtener el reporte de los
movimientos por proveedor, cuando y en qué cantidad trajo artículos al almacén.

figura 3.62Reporte por proveedor

Fuente: (Elaboración propia)
Usuario contabilidad

El usuario con el rol de contabilidad solamente tiene acceso a las funciones de reportes, como
se puede ver en la figura 3.63.

figura 3.63 Ingreso usuario Contador

Fuente: (Elaboración propia)

130
Los reportes los puede sacar por cada uno de los almacenes y no solo así de uno, como se ve
en la figura 3.64.

figura 3.64 Reporte como contador

Fuente: (Elaboración propia)

131
4. CAPÍTULO IV MÉTRICAS DE CALIDAD

4.1. INTRODUCCIÓN

La calidad del software es el grado en que el producto de software incorpora un conjunto

decaracterísticas, de tal manera que se garantiza su eficiencia de uso, respecto a
losrequerimientos de los clientes, es decir, la calidad del software es el grado en el que
uncliente percibe que el software cumple con sus expectativas.

Dentro de la ingeniería de software se cuenta con modelos y normas de calidad, que

nosdescriben los factores de calidad a evaluar en los productos de software, el modelo que
seaplica para el presente proyecto de grado es la norma ISO 9126.

4.2. FACTORES DE CALIDAD ISO 9126

La norma ISO 9126 tiene una serie de características las cuales debemos tomar en cuenta para
obtener una buena estimación de calidad.

El estándar ISO 9126, clasifica la calidad del software en un conjunto estructurado de

característica y sub características, ha sido desarrollado en un intento de identificar los
atributos clave de calidad para el software. Este estándar identifica 6 atributos clave de
calidad, descritos en la tabla 4.1 a continuación:

Tabla 4.1Atributos de calidad

Atributo Descripción

Capacidad del software de proveer los servicios

Funcionalidad necesarios para
cumplir con los requisitos funcionales.
Capacidad del software de mantener las prestaciones
requeridas del
Confiabilidad
sistema, durante un tiempo establecido y bajo un
conjunto de condiciones definidas.
Esfuerzo requerido por el usuario para utilizar el
Usabilidad
producto satisfactoriamente.
Esfuerzo necesario para adaptarse a las nuevas
Mantenibilidad
especificaciones y requisitos del software.

132
 La facilidad con que el software puede ser llevado de
Portabilidad
un entorno a otro.

Calidad Global La suma de todas las anteriores características.

Fuente (Elaboración propia)

4.2.1. FUNCIONALIDAD

Métrica para obtener una valoración mediante el cálculo del punto función en base a la
evaluación de un conjunto de características y capacidades que se listan a continuación, que
debe cumplir el sistema.
• Número de entradas de usuario
• Número de salidas de usuario
• Número de peticiones de usuario
• Número de archivos
• Número de interfaces externas

Para calcular puntos función (PF), se utiliza la siguiente relación:

𝑃𝐹 = 𝑐𝑢𝑒𝑛𝑡𝑎𝑇𝑜𝑡𝑎𝑙 ∗ (0.65 + 0.01 ∗ ∑ 𝐹𝑖 )

Donde

PF: Medida de funcionalidad.

Cuenta Total: Es la suma de los siguientes datos:

Número de entradas de usuario + Número de salidas de usuario + Número de

peticiones de usuario + Número de archivos + Número de interfaces externas

0.65: Confiabilidad del proyecto, varia de 1% al 100% (0 a 1).

0.01: Error mínimo aceptable de complejidad.

∑ 𝑭𝒊 : Son los valores de ajuste de complejidad, donde 1 ≤ 𝑖 ≤ 14

Tomando en cuenta estos pasos, inicialmente definimos los siguientes puntos:

Número de entradas de usuario

133
Es el número de los momentos en que el usuario va a introducir información al Sistema, se
puede observar en la Tabla 4.2, las entradas de usuario que tiene el sistema.

Tabla 4.2Entradas de usuario

Nro. Entradas
1 Registro de usuarios
2 Registro de almacenes
3 Registro de funcionarios
4 Registro de proveedores
5 Registro de la organización de la alcaldía
6 Registro de unidades
7 Registro de partidas presupuestarias
8 Registro de artículos
9 Registro de ingresos
10 Registro de pedidos
11 Registro de la revisión de solicitud
12 Registro de menús de acceso
Fuente (Elaboración propia)

Número de salidas de usuario

Es la información elaborada por el sistema, pueden ser los reportes y/o cualquier formato de
salida ya sea impreso o en pantalla que son emitidas al usuario, se puede observar en la Tabla
4.3, las salidas que tiene el usuario.

Tabla 4.3Salidas de usuario

Nro. Salidas
1 Reporte de stock por almacén
2 Reporte de bajos stocks
3 Reporte de nota de ingreso
4 Reporte de nota de pedido
5 Reporte de kardex

134
 6 Reporte mensual valorado
7 Reporte por proveedor
8 Reporte por unidad
9 Reporte de promedio de artículos
Fuente (Elaboración propia)

Número de peticiones de usuario

Es una entrada interactiva que produce la generación de alguna respuesta del software
inmediata, es decir, que se espera que el programa responda al usuario, llámense consultas y
similares, se puede observar en la Tabla 4.4, las peticiones que tiene el usuario con el sistema.

Tabla 4.4Peticiones de usuario

Nro. Peticiones
1 Autentificación por login
2 Listado de almacenes
3 Listado de partidas presupuestarias
4 Listado de usuarios
5 Listado de artículos
6 Listado de secretarias
7 Listado de direcciones
8 Listado de unidades
9 Listado de áreas
10 Modificación del organigrama
11 Listado de existencias en almacenes
12 Eliminación de usuarios inactivos
13 Listado de ingresos anulados
14 Listado de pedidos aprobados
15 Listado de pedidos pendientes
16 Listado de pedidos anulados

135
 17 Listado de lotes por orden de fecha
18 Listado de proveedores
19 Listado de funcionarios
20 Modificación de funcionarios
21 Listado de usuario contabilidad
22 Listado de unidades de medida
23 Modificación de proveedores
24 Eliminación de funcionarios
25 Eliminación de proveedores
26 Listado de artículos por vencer
Fuente (Elaboración propia)

Número de archivos

Es la cantidad de archivos necesarios para que el sistema funcione, es decir un grupo lógico de
datos que puede ser una parte de una gran base de datos o un archivo independiente, se puede
observar en la Tabla 4.5, los archivos.

Tabla 4.5Archivos del sistema

Nro. Archivos
1 Usuarios
2 Almacenes
3 Partidas presupuestarias
4 Artículos
5 Proveedores
6 Funcionarios
7 Unidades
8 Ingresos
9 Pedidos
10 Reporte kardex
Fuente (Elaboración propia)

136
Número de interfaces externas

Son todas las interfaces externas legibles que sirven para la computadora y que permiten la
transmisión de la información, se puede observar en la Tabla 4.6, las interfaces externas.

Tabla 4.6 Interfaces externas

Nro. Interface
1 Frontend con conexión a internet.
2 Backend con conexión intranet.
3 Servidor con conexión intranet.
Fuente (Elaboración propia)

Factor de ponderación

Una vez que los obtenidos los datos, estos son colocados en la tabla y se elige una
ponderación, que representa el grado de complejidad que se prevé para cada una de las
opciones, ver la Tabla 4.7.

Tabla 4.7Factor de ponderación

Factor de ponderación
Parámetro de medida cuenta Total
Simple Medio Complejo

Nro. de entradas de usuario 12 * 3 4 6 = 48

Nro. de salidas de usuario 9 * 3 4 7 = 36

Nro. de peticiones de usuario 26 * 7 10 15 = 260

Nro. de archivos 10 * 3 4 5 = 40

Nro. de interfaces externas 3 * 5 7 10 = 21

Cuenta total 405

Fuente (Elaboración propia)

137
La cuenta total de los puntos de función obtenidos se debe ajustar en función a las
características ambientales del sistema. Los valores de ajuste de complejidad Fi donde i puede
variar de 1 hasta 14 los valores de ajuste de complejidad basados en las respuestas a las
preguntas formuladas de la siguiente tabla 4.8:

Tabla 4.8Valores de ajustes de complejidad

Sin influencia

Significativo
Moderado
Incidental

Esencial
Medio
# Factores de complejidad Total

0 1 2 3 4 5

¿Requiere el sistema copias de seguridad y de

1 4
recuperación fiables?

2 ¿Se requiere comunicación de datos? 5

3 ¿Existen funciones de procesos distribuidos? 3

4 ¿Es crítico el rendimiento? 4

¿Sera ejecutado el sistema en un SO existente y

5 4
fuertemente utilizado?

¿Requiere el sistema entrada de datos

6 5
interactiva?

¿Requiere la entrada de datos interactiva que se

7 4
utilicen varias pantallas o varias operaciones?

8 ¿Se utilizan los archivos maestros de forma

4
interactiva?

9 ¿Son complejas las entradas, las salidas y/o las

5
peticiones?

138
 10 ¿Es complejo el procesamiento interno? 4

11 ¿Se ha diseñado el código para ser reutilizable? 4

12 ¿Están incluidas en el diseño la conversión y la

4
instalación?

13 ¿Se ha diseñado el sistema para soportar

diferentes instalaciones en diferentes 5
organizaciones?

14 ¿Se ha diseñado la aplicación para facilitar los

cambios y para ser fácilmente utilizada por el 5
usuario?

Factor de ajuste de complejidad 60

Fuente (Elaboración propia)

Reemplazando los datos en la fórmula de puntos función, es decir en (i) se tiene:

𝑃𝐹 = 𝑐𝑢𝑒𝑛𝑡𝑎𝑇𝑜𝑡𝑎𝑙 ∗ (0.65 + 0.01 ∗ ∑ 𝐹𝑖 )

𝑃𝐹 = 405 ∗ (0.65 + 0.01 ∗ 60)

𝑃𝐹 = 506.25

El punto función del sistema web es de 506.25, PF = 506.25.

Luego, comparando los valores de funcionalidad del sistema con el PF máximo que se puede
alcanzar:

𝑃𝐹 𝑚𝑎𝑥𝑖𝑚𝑜 = 405 ∗ (0.65 + 0.01 ∗ 70)

𝑃𝐹 𝑚𝑎𝑥𝑖𝑚𝑜 = 546.75

Con máximos valores de ajuste a la complejidad se tiene que la funcionalidad real es:

139
 506.25
𝑓𝑢𝑛𝑐𝑖𝑜𝑛𝑎𝑙𝑖𝑑𝑎𝑑 = ( ) ∗ 100
546.75

𝑓𝑢𝑛𝑐𝑖𝑜𝑛𝑎𝑙𝑖𝑑𝑎𝑑 = 92.59 %

El resultado se traduce en que: El Sistema Web De Administración y Control Del

Almacenamiento De Artículos En El Almacén Central y En Subalmacenes, cumple las
necesidades solicitadas con una probabilidad de 92.59% que funcione sin riesgos y una
probabilidad de 7.41% de fallas o colapso en sistema.

4.2.2. CONFIABILIDAD

La confiabilidad es la capacidad del software para asegurar un nivel de funcionamiento

adecuado cuando es utilizando en condiciones específicas. Para este punto se hizo el análisis
del nivel de confiabilidad del sistema, para lo cual primeramente se considera la confiablidad
de cada módulo o subsistema de forma independiente.

Para calcular la confiabilidad de cada módulo se usó de la fórmula:

𝑅(𝑡) = 𝑒 −𝜆𝑡

Donde:

𝑹(𝒕): confiabilidad de un componente del sistema t.

𝝀: Tasa de constantes de fallo, se define como: 𝜆 = Numero de fallas al ingreso al sistema /

número total de accesos al sistema

t: periodo de operación de tiempo.

𝒆−𝝀𝒕 : Probabilidad de falla de un componente o subsistema en el tiempo t.

Se realizaron las pruebas de los módulos durante 8 horas en operación, al finalizar se logró
obtener los siguientes datos reflejado en la tabla 4.9:

140
 Tabla 4.9Valores de confiabilidad
Nro. Modulo 𝝀 𝒕 𝑹(𝒕)
1 Módulo de ingreso 0.008 8 horas 0.93
2 Módulo de artículos y almacén 0.015 8 horas 0.88
3 Módulo de ingresos 0.003 8 horas 0.97
4 Módulo de pedidos 0.021 8 horas 0.84
5 Módulo de reportes 0.008 8 horas 0.93
Fuente (Elaboración propia)

Vamos a dividir las fallas en las que un componente falla y afecta a todo, fallo en serie y
donde todos los componentes fallan en su conjunto, fallo en paralelo.

Es por eso que la confiabilidad del sistema estaría dada por la fórmula:

𝐶𝑜𝑛𝑓𝑖𝑎𝑏𝑖𝑙𝑖𝑑𝑎𝑑 = 𝑅𝑠 ∗ 𝑅𝑝

Donde:

𝑅𝑝 = 𝑅1 = 0.93

𝑅𝑠 = 1 − (1 − 𝑅2 )(1 − 𝑅3 )(1 − 𝑅4 )(1 − 𝑅5 )

𝑅𝑠 = 1 − (1 − 0.88)(1 − 0.97)(1 − 0.84)(1 − 0.93)

𝑅𝑠 = 0.99995968

Por lo tanto, la confiabilidad del sistema está dada por:

𝐶𝑜𝑛𝑓𝑖𝑎𝑏𝑖𝑙𝑖𝑑𝑎𝑑 = 0.99995968 ∗ 0.93

𝐶𝑜𝑛𝑓𝑖𝑎𝑏𝑖𝑙𝑖𝑑𝑎𝑑 = 0.93

𝐶𝑜𝑛𝑓𝑖𝑎𝑏𝑖𝑙𝑖𝑑𝑎𝑑 = 93%

De esto concluimos que el nivel de confiabilidad del sistema es de 93%, esto quiere decir que
existe un 7% de probabilidad que el sistema pueda fallar cuando se exceda un determinado

141
tiempo de uso continuo, esto puede ser ocasionado por fallos en el servidor, mala conexión de
red o mal uso del sistema por parte del usuario.

4.2.3. USABILIDAD

La usabilidad es la capacidad del software de ser entendido, aprendido, y usado de forma fácil
y atractiva. Se realizó un sondeo entre los usuarios que usaron el sistema, en este caso 10
usuarios. La tabla 4.10 muestra los resultados:

Tabla 4.10Encuesta de usabilidad

Nro. Pregunta Si No % de Si
1 ¿Es entendible? 9 1 90
¿Las pantallas son agradables a la vista 7 3 70
2
del usuario?
3 ¿Es fácil de aprender? 10 0 100
4 ¿Contiene la información necesaria? 10 0 100
5 ¿Facilita su trabajo? 9 1 90
¿Es fácil navegar por las distintas 9 1 90
6
opciones?
¿El sistema le proporciono las 10 0 100
7
respuestas requeridas?
8 ¿El sistema no presento errores? 9 1 90
Promedio 91.25
Fuente (Elaboración propia)

De los usuarios entrevistados el 91% le parece fácil de usar el sistema, amigable, intuitivo y
practico.

Esto nos da un agrado de usabilidad del 91.25% entre todos los usuarios y un 8.75% no
comprende el funcionamiento y no satisface sus necesidades.

4.2.4. MANTENIBILIDAD

La Mantenibilidad es la cualidad que tiene el software para ser modificado. Incluyendo

correcciones o mejoras del software, a cambios en el entorno, y especificaciones de

142
requerimientos funcionales, para poder medir la calidad del mantenimiento del sistema
utilizaremos el índice de madurez del software (IMS), que indica la estabilidad de un producto
de software.
Se lo calcula de la siguiente forma:
𝑀𝑡 − (𝐹𝑎 + 𝐹𝑏 + 𝐹𝑐 )
𝐼𝑀𝑆 = ∗ 100
𝑀𝑡
Donde:
𝐼𝑀𝑆 : Índice de madurez del sistema
𝑀𝑡 : Número de módulos actual
𝐹𝑎 : Número de módulos en la versión actual que se han cambiado
𝐹𝑏 : Número de módulos en la versión actual que se han añadido
𝐹𝑐 : Número de módulos en la versión anterior que se han borrado en la versión
actual

Entonces:

5 − (0 + 0 + 0)
𝐼𝑀𝑆 = ∗ 100
5
5
𝐼𝑀𝑆 = ∗ 100
5

𝐼𝑀𝑆 = 100 %

Se puede concluir, que el sistema cuenta con un 100% de mantenibilidad.

4.2.5. PORTABILIDAD

La portabilidad es la capacidad con la que un software puede ser llevado de un entorno a otro,
considera la facilidad de instalación, ajuste y adaptación al cambio. Para medir la portabilidad
se hará uso de la siguiente fórmula:

𝐸𝑇
𝐺𝑃 = 1 −
𝐸𝑅

143
Donde:
𝐺𝑃 : Grado de portabilidad
𝐸𝑇 : Recursos necesarios para llevar el sistema a otro entorno
𝐸𝑅 : Recursos necesarios para crear el sistema en el entorno residente
Si:
𝐺𝑃> 0, la portabilidad es más rentable que el re-desarrollo
𝐺𝑃< 0, el re-desarrollo la portabilidad es más rentable que la portabilidad
𝐺𝑃 = 0, la portabilidad es perfecta

Para llevar el sistema web a otro entorno se necesita una memoria extraíble de 4 GB o más
capacidad, para crear el sistema en el entorno residente se necesita inicialmente 1 servidor con
sistema operativo este puede ser cualquiera (Windows, Linux o Mac OS en sus diferentes
versiones), y servidor Apache, el lenguaje de programación PHP, el gestor de base de datos
MySQL, los cuales deben estar instalados en los servidores y un navegador web.

Con esta información requerida por la fórmula, se procede a calcular el grado de portabilidad:

1
𝐺𝑃 = 1 − = 1 − 0.20 = 80%
5

Por lo que se concluye que el sistema web tiene un grado de portabilidad del 80%.

4.2.6. CALIDAD GLOBAL

Una vez obtenidos todos los datos de los factores de la calidad de software que tiene
propuesto el estándar de calidad ISO 9126, se procede a calcular la calidad global del sistema
de información, la cual se despliega en la siguiente tabla 4.11.

Tabla 4.11Calidad global del sistema

Atributo Valor en %

Funcionalidad 92.59

Confiabilidad 93

Usabilidad 91.25

144
 Mantenibilidad 100

Portabilidad 80

Calidad Global 91.37

Fuente (Elaboración propia)

Con este resultado se define la calidad total del sistema planteado como 91.37 % amigable,
entendible, necesario, intuitivo y útil para los usuarios.

145
5. CAPÍTULO V EVALUACIÓN DE COSTO Y BENEFICIO

5.1. INTRODUCCIÓN

La técnica de análisis de costo y beneficio, tiene como objetivo fundamental proporcionar una
medida sobre la rentabilidad de un proyecto, haciendo una comparación de los costos
previstos con los beneficios esperados en la realización del mismo. Esta técnica se debe
utilizar al comparar proyectos y así poder tener una buena toma de decisiones

Como se mencionó en el punto 2.5, se hará uso del modelo matemático COCOMO
(COCOMO II) y las fórmulas descritas para tal objetivo.

5.2. ANÁLISIS DE COSTOS - COCOMO II

5.2.1. ESTIMACIÓN DE ESFUERZO

Se usarán las siguientes fórmulas:

𝐸 = 𝑎(𝐾𝐿𝐷𝐶)𝑏

𝐷 = 𝑐(𝐸)𝑑

Para obtener:

𝐸
𝑃=
𝐷

Donde:

E: Esfuerzo requerido por el proyecto expresado en persona-mes.

D: Tiempo requerido por el proyecto expresado en meses.

P: Número de personas requeridas para el proyecto.

a, b, c y d: Constantes con valores definidos según cada sub-modelo.

KLDC:Cantidad de líneas de código distribuidas en miles.

146
COCOMO II se divide en 3 modos y se establecen los coeficientes de la siguiente forma en la
tabla 5.1:

Tabla 5.1Coeficientes de COCOMO II

Proyecto de software a b c d
Orgánico 2.4 1.05 2.5 0.38
Semi-acoplado 3 1.12 2.5 0.35
Empotrado 3.6 1.2 2.5 0.32
Fuente (Gómez, Migani, del C.López, & Otazú, 2007)

Para determinar el esfuerzo nominal en el modelo COCOMO II los puntos función no

ajustados, obtenidos en el apartado anterior, tienen que ser convertidos a líneas de código
fuente considerando el lenguaje de implementación, para esto se toma en cuenta la siguiente
tabla 5.2.

Tabla 5.2Factor LDC/PF

Factor
Lenguaje Nivel
LCD/PF
C 2.5 128
ANSI BASIC 5 64
JAVA 6 53
ASP 9 36
PHP 11 23
VISUAL C++ 9.5 35

Fuente (Gómez, Migani, del C.López, & Otazú, 2007)

Como el sistema está desarrollado en PHP se tomará su factor LDC/PF igual a 23, coeficiente
ya determinado en la anterior tabla.

El Punto de función del proyecto calculado en el capítulo IV nos dio igual a 506.25, usando
estos datos se obtiene las líneas de código.

𝐿𝐷𝐶 = 𝑃𝐹 ∗ 𝐹𝑎𝑐𝑡𝑜𝑟𝐿𝐶𝐷/𝑃𝐹

𝐿𝐷𝐶 = 506.25 ∗ 23

147
 𝐿𝐷𝐶 = 11643.75

𝐾𝐿𝐷𝐶 = 𝐿𝐶𝐷/1000

𝐾𝐿𝐷𝐶 = 11.64

Se tomará como tipo de proyecto el Semi-acoplado por las características que tiene el sistema
y las diferentes características que posee. De esta manera usando los datos de la tabla 5.1 de
los datos a b c d de Semi acoplado.

𝐸 = 3(11.64)1.12

𝐸 = 46.88

𝐷 = 2.5(46.88)0.35

𝐷 = 9.61

Para obtener:

46.88
𝑃=
9.61

𝑃 = 4.88 ≅ 5

Por lo tanto 4.88 se redondea a 5 Personas que son desarrolladores.

5.2.2. COSTO DE SOFTWARE

Tomando como base el salario aproximado de un programador junior 300 $, esta cifra se toma
en cuenta para estimar el costo del software:

𝐶𝑜𝑠𝑡𝑜 𝑑𝑒 𝑑𝑒𝑠𝑎𝑟𝑟𝑜𝑙𝑙𝑜 = 𝑃𝑟𝑜𝑔𝑟𝑎𝑚𝑎𝑑𝑜𝑟𝑒𝑠 ∗ 𝑠𝑎𝑙𝑎𝑟𝑖𝑜 𝑝𝑟𝑜𝑔𝑟𝑎𝑚𝑎𝑑𝑜𝑟 ∗ 𝑑𝑢𝑟𝑎𝑐𝑖𝑜𝑛

𝐶𝑜𝑠𝑡𝑜 𝑑𝑒 𝑑𝑒𝑠𝑎𝑟𝑟𝑜𝑙𝑙𝑜 = 5 ∗ 300 ∗ 4

𝐶𝑜𝑠𝑡𝑜 𝑑𝑒 𝑑𝑒𝑠𝑎𝑟𝑟𝑜𝑙𝑙𝑜 = 6000 $

148
[Link]. COSTO DE ELABORACIÓN DEL PROYECTO

Los costos de elaboración del proyecto se detallan en la tabla 5.3:

Tabla 5.3Costo de elaboración

Descripción Costo $us
Análisis del proyecto 200
Pasajes 120
Material de escritorio 50
Otros 10
Total 380

Fuente (Elaboración propia)

[Link]. COSTO DE IMPLEMENTACIÓN DEL PROYECTO

El Gobierno Autónomo Municipal de El Alto cuenta con los equipos necesarios, servidor en
Linux. Por lo tanto, el costo es de 0.

[Link]. COSTO TOTAL

El costo total es la suma de todos los costos, de software proyecto e implementación. Esto de
describe en la tabla 5.4.

Tabla 5.4Costo total

Descripción Costo $us
Costo de desarrollo 6000
Costo de elaboración 380
Costo de implementación 0
Costo Total 6380

Fuente (Elaboración propia)

De esa forma se define el costo del proyecto en 6380 dólares.

149
5.3. CALCULO DE VALOR ACTUAL NETO – VAN

El VAN es un procedimiento que permite calcular el valor presente de un determinado

número de flujos de futuros ingresos y egresos que tendrá el proyecto. Este método consiste
en descontar el momento actual, es decir actualizar por medio de una tasa de flujos de caja
futuros del proyecto, a ese valor se le resta la inversión inicial, así el valor obtenido es el valor
actual neto.

𝐺𝑎𝑛𝑎𝑛𝑐𝑖𝑎𝑠
𝑉𝐴𝑁 = ∑ − 𝑙0
(1 + 𝑘)𝑛

Dónde:

VAN: Valor Actual Neto.

Ganancias: ingreso del flujo anual.

𝒍𝟎 : Es el valor del desembolso inicial de la inversión.

𝒌: Tasa de descuento o tasa de interés al préstamo.

𝒏: Es el número de periodos considerados.

Los valores de ganancia esperados para el presente proyecto se calculan para 4 años, en este
caso se utilizará una taza de 10% que es un índice de préstamo, para calcular el VAN se tiene
lo siguiente:
𝑖𝑛𝑣𝑒𝑟𝑠𝑖𝑜𝑛 = 6380

𝑘 = 10%

Para hallar los valores de ganancia esperados se aplican las formulas presentadas en la
siguiente tabla 5.5:

150
 Tabla 5.5Calculo de VAN
Flujo de caja 𝑮𝒂𝒏𝒂𝒏𝒄𝒊𝒂𝒔
Año (𝟏 + 𝒌)𝒏
Ganancia (𝟏 + 𝒌)𝒏
1 0 1.1 0

2 3000 1.21 2479.34

3 6000 1.331 4507.89

4 7000 1.4641 4781.09
Total 16000 5.1 11768.31

Fuente (Elaboración propia)

Aplicando la formula

𝐺𝑎𝑛𝑎𝑛𝑐𝑖𝑎𝑠
𝑉𝐴𝑁 = ∑ − 𝑙0
(1 + 𝑘)𝑛

𝑉𝐴𝑁 = 11768.31 − 6380

𝑉𝐴𝑁 = 5388.31

Se tiene que el valor obtenido es mayor a cero por lo que la inversión es factible en un
principio y el proyecto es rentable.

5.4. RELACIÓN COSTO BENEFICIO

Para hallar la relación del costo beneficio se utiliza la siguiente formula:

𝐶𝑜𝑠𝑡𝑜
𝑏𝑒𝑛𝑒𝑓𝑖𝑐𝑖𝑜

Reemplazamos con los valores encontrados anteriormente, resulta lo siguiente.

6380
= 1.595
4000

Por cada dólar invertido la empresa gana 1.595 $.

151
6. CAPÍTULO VISEGURIDAD DE SISTEMA

La seguridad del sistema es de vital importancia para el buen funcionamiento y así evitar
vulnerabilidades de seguridad. El Gobierno Autónomo Municipal de El Alto cuenta con una
unidad encargada del mantenimiento de los diferentes sistemas que utilizan.

Dividiremos la seguridad del sistema en lógico y físico, detallaremos estas a su vez.

Además,la unidad de sistemas usa un servidor propio lo cual facilita el ingreso a los sistemas
que están alojadas en el servidor.

Los problemas de seguridad para sitios y sistemas de información web deben ser
contempladosdesde su diseño lógico hasta su implementación final, teniendo en cuenta
factores internos yexternos como: vulnerabilidades en los componentes de software,
encriptación de los mensajes,gestión eficiente de los usuarios de las bases de datos,
configuración adecuada de lainfraestructura y telecomunicaciones. A continuación, se detallan
las medidas de seguridad quese contemplaron al momento de la implementación del sistema
de información web.

6.1. NIVEL FÍSICO

A nivel físico el sistema se resguarda dentro de un servidor con Linux Ubuntu dentro de la
unidad de sistemas, ya que esta unidad maneja todo lo referente a [Link] otorga el acceso
a un miembro de la unidad de sistemas encargado de la administración de algunas funciones
básicas, posteriormente se asignó un usuario administrador al encargado del almacén central.

La unidad de almacenes y los diferentes sub almacenes podrán acceder al sistema desde sus
computadoras las cuales se encuentran en la misma red dentro de la institución.

El departamento de tecnología para el acceso físico al servidor cuenta con una habitación
exclusiva para el resguardo de servidores y demás elementos importantes.

6.2. NIVEL LÓGICO

La seguridad lógica se tomó en cuenta en cada etapa de la implementación del sistema como
ser la autenticación de usuarios, la asignación de grupos y accesos a usuarios quepertenecen al
módulo de autenticación y seguridad del sistema, también se implementóvalidación para los

152
datos de entrada que tiene el sistema, y finalmente toda la seguridad delframework Laravel
basado en PHP.

6.2.1. AUTENTICACIÓN DE USUARIOS

El acceso al sistema al sistema es controlado por la autentificación la cual se refleja en la

ventana de login en la figura 3.26, en la cual un usuariodebe introducir datos correctos de
email y contraseña, estos datos son validados con códigoJavaScript de lado del cliente que
controla la sintaxis de los campos, asegurando que sea te tipo email y la contraseña con
minino 6 caracteres, como también códigoPHP de la del servidor que verifica si los datos
introducidos son correctos.

Los diferentes accesos muestran la información requerida por cada usuario dependiendo a su
rol que son: Administrador – encargado de almacén central, encargado de subalmacén y área
de contabilidad. Cada uno de estos usuarios accede a las operaciones que le son asignadas y
las que requiere.

6.2.2. ENCRIPTACIÓN DE DATOS

La encriptación en el desarrollo del sistema se la contemplo en diversos módulos, en especial

en el módulo de autentificación con las contraseñas, para este caso se tomó los recaudos
apropiados en esta parte utilizando el encriptado AES (Advanced Encryption Standard) el cual
es soportado por MySQL en campos netamente binarios ya que AES trabaja en este sistema.

El encriptador de Laravel usa OpenSSL para proporcionar encriptación AES-256 y AES-

[Link] los valores cifrados de Laravel se firman utilizando un código de autenticación de
mensaje (MAC) para que su valor subyacente no se pueda modificar una vez cifrado.

6.2.3. PROTECCIÓN POR PETICIONES GET

Uno de los aspectos o desventajas al trabajar con el patrón estructurado en este tipo
desistemas, es la vulnerabilidad en las peticiones GET con esto nos referimos a las peticiones
que se hacen desde la URL del navegador, en el cual se pueden solicitar formularios para
editar la base de datos o los ataques por ventanas en las cuales se pueden alterar las
variablesPOST y además al poseer usuarios con distintos privilegios pueden los mismos
ingresar a lastareas de otros usuarios, para nuestro caso se tomó todos los recaudos necesarios

153
para todas las peticiones GET dentro del sistema restringiendo el accesos tanto a los
formularios como a los controladores que se encargan del contacto netamente con la base de
datos.

6.2.4. SEGURIDAD EN LA BASE DE DATOS

La seguridad en la base de datos es muy importante, es especial en este sistema ya que en la

base de datos se guardan los datos de todos los movimientos de los artículos de cada almacén
y son primordiales para sacar reportes históricos. Es por eso que la unidad de sistemas hace
copias de seguridad a los datos cada cierto tiempo y estas las guarda en forma física como
lógicas, cada cierto tiempo se guardan en pendrives; así se podrá garantizar la seguridad de los
datos que posee la empresa no solo del sistema actual sino de toda su información.

Las inyecciones SQL son cadenas de instrucciones SQL que un usuario puede introducir
encualquier campo de entrada de un formulario. El frameworkLaravel está equipado para
evitar este tipo de ataques ya que para hacer consultas este nos pide hacer las consultas por
medio de funciones que pueden ser usadas solamente por los modelos, además que nos
permite manejar Eloquent ORM que es una forma más segura e eficiente de realizar las
consultas a la base de datos. Estas funciones internas del framework proveen protección
contra las inyecciones SQL y están destinadas a realizar solo un tipo de acción.

154
7. CAPÍTULO VIICONCLUSIONES Y RECOMENDACIONES
A la conclusión del presente proyecto se detallan las conclusiones y recomendaciones.

7.1. CONCLUSIONES

Se concluye que el presente proyecto titulado “SISTEMA WEB DE ADMINISTRACIÓN Y

CONTROL DEL ALMACENAMIENTO DE ARTÍCULOS EN EL ALMACÉN CENTRAL
Y EN SUBALMACENES CASO: GOBIERNO AUTÓNOMO MUNICIPAL DE EL ALTO”
fue cubierto satisfactoriamente y desarrollado según las métricas de calidad requeridas,
cumpliendo los requerimientos solicitados por el personal del área de sistemas y el área de
almacenes.

Para el seguimiento del desarrollo de este proyectose utilizó la metodología SCRUM. Se

concluye que fue una herramienta de mucha utilidad, debido a que permitió realizar un
seguimiento eficiente en todas las fases del proyecto, permitiendo la identificación de las
actividades relevantes, una definición adecuada de los tiempos por cada iteración y lograr una
organización adecuada para la planificación y ejecución de las tareas.

El diseño web fue apoyado con la metodología de modelado web UWE. Se concluye, que esta
permitió dar al proyecto el enfoque sistemático,disciplinado y cuantificable en cuanto al
desarrollo y operación. Además de dar herramientas para el diseño del sistema.

En cuanto al registro de artículos se clasifico estos de acuerdo al clasificador presupuestario

que se detalla en la normativa vigente según el Ministerio de Economía y Finanzas Publicas.
Estos artículos se registran con la información necesaria para poder identificarlos y
registrarlos en los almacenes.

El sistema también cuenta con un método de verificación de stock el cual no permite repartir
más artículos de los que existen; además de notificar mediante una lista aquellos artículos que
existen y su actual stock, de esta manera se facilita el ingreso y pedido de artículos entre
distintas unidades hacia el almacén o sub almacén.

También se consideró ciertos aspectos importantes al momento de realizar ingresos y pedidos,

siendo estos bastante sensibles respecto a las cifras significativas, ya que pequeños decimales

155
pueden afectar el resultado en gran manera; por esto se consideró usar valores de tipo flotante
para evitar pérdidas y para mostrar unos reportes más estéticos se hace el redondeo a 2
decimales.

También se implementó ciertos aspectos de seguridad para poder cuidar la integridad del
sistema ante la pérdida de datos o mala manipulación, se implementó uso de sesiones
autodestructivas,así cuando el usuario autentificado no realice ninguna acción en un corto
periodo.

El sistema permite generar todos los reportes solicitados, como el reporte de Kardex y el
reporte mensual valorado que son los más importantes, estos de acuerdo al nivel de acceso que
tenga el usuario, estos reportes no solo en formato PDF sino también en hojas de cálculo
Excel para revisiones en la institución,

7.2. RECOMENDACIONES

Se recomienda mantener el servidor y base de datos actualizada, en futuras implantaciones o

actualizaciones usar una base de datos No SQLya que la cantidad de datos puede llegar a ser
muy grande para un sistema vertical.

Extender el sistema a un entorno móvil, debido a la facilidad de los miembros de

subalmacenes para manejar sus celulares al momento de la entrega y descargo de artículos, a
pesar que el sistema es responsivo se sugiere crear una aplicación.

Asignar personal capacitado en el uso del sistema, así como la inclusión de políticas de
manejo del mismo, utilizando procesos de digitalización de documentos por tecnología OCR
para los requerimientos de artículos, facilitando el trabajo de transcripción del pedido.

Se recomienda actualizar el sistema con las nuevas tecnologías de desarrollo web basadas en
JavaScript, de acuerdo a la capacidad y disponibilidad del servidor de la institución.

Implementar un sistema web el cual esté vinculado con el sistema web ya implantado en el
área de salud del Gobierno Autónomo Municipal de El Alto, de esta manera conectar la
información y tener una base de datos más grande y controlar mejor los artículos de los
hospitales.

156
BIBLIOGRAFÍA
Abud, M. A. (30 de Enero de 2012). Calidad en la Industria del Software. La Norma ISO-
9126. Obtenido de Calidad en la Industria del Software. La Norma ISO-9126:
[Link]/empresasindigenas/docs/[Link]

Albrecht, A. J. (1979). Measuring Application Development Productivity. Proceedings of IBM

Applications Development Symposium (págs. 83-92). Monterey: IBM Corp.

Asensio, L. (2014). Seguridad en aplicaciones web: Una vision Practica. Leganés:

Unversidad Carlos III de Madrid.

Banker, R., Kauffman, R., & Kumar, R. (1994). An Empirical Test of Object-Based Output
Measurement Metrics in a Computer Aided Software Engineering (Case)
[Link] of Management Information.

Bootstrap. (23 de diciembre de 2018). Introduccion . Obtenido de Introduccion :

[Link]

Carrillo. (2017). Sistema web de control de compras, ventas e inventarios caso Comercial
Ariana. La Paz: Carrera de Informatica, Universidad Mayor de San Andres.

(2018). Decreto Municipal N° 094. El Alto: Gobierno Autonomo Municipal de El Alto.

Del Valle, N. (2010). Metodologías de diseño usadas en ingeniería Web, su vinculación.

Madrid: Universidad Nacional de la Plata.

Escalona, M. J., & Koch, N. (2002). Ingeniería de Requisitos en aplicaciones para la web.
Sevilla: Escuela Técnica Superior de Ingeniería Informática de U de Sevilla.

Gandarillas, J. (2018). Temas de Contabilidad Intermedia.

Gómez, A., Migani, S., del C.López, M., & Otazú, A. (29 de 05 de 2007). wordpress.
Obtenido de [Link]

Gutiérrez, J. (2015). investigacion_ficheros. Obtenido de investigacion_ficheros:

[Link]

157
Hinojosa, J. (2018). Sistema web de gestión y control de almacenes e inventarios Caso:
Ministerio de planificación del desarrollo. La Paz: Carrera de Informatica ,
Universidad Mayor de San Andres.

Huarachi, M. R. (2013). Sistema Para la Administración y Seguimiento de Almacenes con

Modelos de Inventarios. Caso: Honorable Cámara de Diputados Unidad de
Almacenes. La Paz: Carrera de Informatica.

INFORME DE RENDICIÓN PÚBLICA DE CUENTAS INICIAL. (2018). El Alto: GAMEA.

Kniberg, H. (2010). Lo mejor de SCRUM. USA California: InfoQ.

Laravel. (2016). GuiaLaravel. Obtenido de GuiaLaravel: [Link]

Ley Nº 728. (06 de marzo de 1985). Obtenido de Ley Nº 728:

[Link]

Manual de Organizacion y Funciones. (2018). El Alto: Gobierno Autonomo Municipal de El

Alto.

Mariño, S., & Alfonzo, P. (diciembre de 2014). Implementación de SCRUM en el diseño del
proyecto del Trabajo Final de Aplicación. Scientia et Technica Año XIX, 19(4), 413-
418.

Martinez, D. (30 de noviembre de 2018). tiThink. Obtenido de tiThink:

[Link]
desarrollo-de-software/

Maximilians, L. (2011). UWE Metamodel and Profile . Germany: Institute for Informatics.

Menzinsky, A. (Julio de 2016). Scrum Manager. Obtenido de

[Link]
manager/

Menzinsky, A. (2019). Scrum master. Madrid: Creative.

158
München, L. (10 de 08 de 2016). UWE – UML-based Web Engineering. Obtenido de
Universität: [Link]

Pacheco, J. (24 de Marzo de 2019). Web y empresas. Obtenido de Web y empresas:

[Link]

Palacio, J. (2008). principios de diseño e implementación de campos de [Link]ña: Safe

Creative.

Park, R. E. (1992). Software Size Measurement: A Framework for Counting Source

[Link]: Software Engineering Institute.

Parra, A. (2013). Sistema de Gestión de Almacenes. Caso: Ministerio de Minería y

Metalurgia. La Paz: Carrera de Infromatica, Universidad Mayor de San Andres.

Pressman, R. (2010). Ingeniería del [Link] York: The McGraw-Hill Companies.

Resolucion Administrativa Municipal Ejecutiva N° 071/19. (2019). El Alto, La Paz, Bolivia.

Rivas, C. I., Corona, V. P., Gutierrez, J. F., & Hernandez, L. (2015). Metodologías actuales de
desarrollo de software. Revista Tecnología e Innovación, 980-986.

Ronald, B. (2004). administración de la cadena de suministro.

Ruiz, A. (2006). Avances en sistemas e informatica. Medellin: Redalyc.

159
 ANEXOS
ORGANIGRAMA DE LA INSTITUCIÓN

160
DOCUMENTACIÓN