UNIVERSIDAD MAYOR DE SAN ANDRÉS

FACULTAD DE CIENCIAS PURAS Y NATURALES

CARRERA DE INFORMÁTICA

PROYECTO DE GRADO

SISTEMA WEB DE CONTROL DE VENTAS E INVENTARIOS

CASO: RED DE ÓPTICAS “VIRTUAL”

Proyecto de Grado para obtener el Título de Licenciatura en Informática

Mención: Ingeniería de Sistemas Informáticos

POR: EVELYN ANGELA ALANEZ ZENTENO

TUTOR: M.Sc. GROVER ALEX RODRÍGUEZ

LA PAZ – BOLIVIA

2021
 HOJA DE CALIFICACIONES

UNIVERSIDAD MAYOR DE SAN ANDRÉS

FACULTAD DE CIENCIAS PURAS Y NATURALES

CARRERA DE INFORMÁTICA

Proyecto de grado:

SISTEMA WEB DE CONTROL DE VENTAS E INVENTARIOS

CASO: RED DE ÓPTICAS “VIRTUAL”

Presentado por: Evelyn Angela Alanez Zenteno

Para optar el grado Académico de Licenciado en Informática

Mención Ingeniería de Sistemas Informáticos

Nota Numeral:

Nota Literal:

Ha sido:

Director de la carrera de informática: Ph. D. Jose Maria Tapia Baltazar

Tutor: M. Sc. Grover Alex Rodriguez Ramirez

Tribunal: Lic. Orihuela Sequeiros Nancy Imelda

Tribunal: Lic. Flores Rojas Manuel Ramiro

Tribunal: M. Sc. Edgar Palmiro Clavijo Cardenas

 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.
 DEDICATORIA

Dedico este trabajo principalmente a Dios por haberme dado la vida,

por permitirme haber llegado hasta este momento

tan importante de mi formación profesional.

A mis amados padres por toda la comprensión, dedicación y todos

los principios que me inculcaron para sobrellevar los golpes y

las victorias de la vida

i
 AGRADECIMIENTO

A Dios, por ser mi fortaleza, por guiar mis pasos, por darme a los mejores padres, por poner
en mi camino a personas maravillosas que me brindaron su amor, cariño y sobre todo por sus
bellas enseñanzas.

A mi mamá y papá, a quienes admiro y amo muchísimo, gracias mamita Maritza Verónica
Zenteno Chuquimia, porque fue por mí, por quien más se sacrificó para sacarme adelante, quien
me enseñó que a pesar de todos los golpes que te de la vida hay que salir adelante, a mi papito
Roberto Alanez Rodríguez, por apoyarme, tenerme paciencia, por sus palabras de aliento,
gracias mami y papi por formarme e inculcarme valores, por darme esa fuerza y ese apoyo
incondicional, no alcanzaría un agradecimiento por todo lo que hicieron por mí, tardé un
poquito más, pero

¡Lo logré!

A mi tutor M.Sc. Grover Alex Rodríguez, por el apoyo, colaboración, seguimiento a este
proyecto, sobre todo agradecer por esas palabras de aliento, por la paciencia y motivación para
seguir adelante.

A todas/os mis amigas/os por ser un apoyo en esta etapa, gracias por sus palabras de aliento,
su comprensión y sobre todo por su bella amistad ¡Gracias Amig@s!

evesita18@gmail.com

ii
 RESUMEN

En un mundo comercial tan competitivo, las empresas deben ser rápidas y eficientes con todos
sus recursos, las tecnologías ayudan a resolver los problemas a través de sistemas innovadores. La
Red de Ópticas “VIRTUAL” se encarga del sistema visual funcionalmente inadecuado, como
empresa desea implementar nuevas herramientas tecnológicas que vayan de acuerdo a sus
necesidades y requerimientos.

El presente proyecto tiene como principal objetivo desarrollar un sistema web para el control
de venta e inventario de productos, de manera que la empresa pueda revisar su política comercial
y las estrategias seguidas, además de implementar pasos para mejorar la productividad y
rentabilidad de la fuerza de ventas.

El proyecto fue desarrollado utilizando metodología de desarrollo ágil XP (Programación

Extrema) por su versatilidad al momento de desarrollar, basándose en sus fases. La fase de diseño
se complementó con el uso de la metodología de Modelado WebML (Web Modeling Language),
que cuenta con diversos esquemas para la representación gráfica de procesos.

Se empleó Web-Site QEM (Método de Evaluación de Calidad) para evaluar y medir la calidad
del producto que se basa en las normas de la ISO 9126 tomando en cuenta: funcionalidad,
confiabilidad, usabilidad y eficiencia, que proporcionan métricas para medir la calidad del
producto final.

Finalmente, los objetivos planteados han sido alcanzados satisfactoriamente de manera que se
produjo un sistema de calidad, que permite tener un control productivo a través de las ventas en
inventarios de productos que se realiza.

Palabras clave: metodología, modelado, funcionalidad, confiabilidad, usabilidad, eficiencia.

Metodología: Metodología de desarrollo ágil Programación Extrema XP.

iii
 ABSTRACT

In such a competitive commercial world, companies must be fast and efficient with all their
resources, technologies help solve problems through innovative systems. The "VIRTUAL" Optics
Network is in charge of the functionally inadequate visual system, as a company it wishes to
implement new technological tools that are in accordance with its needs and requirements.

The main objective of this project is to develop a web system to control the sale and inventory
of products, so that the company can review its commercial policy and the strategies followed, in
addition to implementing steps to improve the productivity and profitability of the sales force.
sales.

The project was developed using the agile development methodology XP (Extreme
Programming) due to its versatility at the time of development, depending on its phases. The design
phase was complemented with the use of the WebML Modeling methodology (Web Modeling
Language), which has various schemes for the graphical representation of processes.

Web-Site QEM (Quality Evaluation Method) was used to evaluate and measure the quality of
the product that is based on the ISO 9126 standards taking into account: functionality, reliability,
usability and efficiency, which provide metrics to measure quality of the final product.

Finally, the proposed objectives have been satisfactorily achieved so that a quality system was
produced, which allows to have a productive control through the sales in product inventories that
are made.

Keywords: methodology, modeling, functionality, reliability, usability, efficiency.

Methodology: Agile development methodology Extreme Programming XP.

iv
 ÍNDICE

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

1.1 Introducción.............................................................................................................1
1.2 Problema .................................................................................................................2
1.2.1 Antecedentes ........................................................................................................2
1.2.1.1 Antecedentes Institucionales .........................................................................2
1.2.1.2 Antecedentes de Proyectos Similares ............................................................3
1.2.2 Planteamiento del Problema .................................................................................5
1.2.3 Formulación del problema....................................................................................5
1.3 Objetivos .................................................................................................................6
1.3.1 Objetivo General ..................................................................................................6
1.3.2 Objetivos Específicos ...........................................................................................6
1.4 Justificaciones ..........................................................................................................6
1.4.1 Justificación Social ..............................................................................................6
1.4.2 Justificación Tecnológica .....................................................................................7
1.4.3 Justificación Económica .......................................................................................8
1.5 Alcances y Limites...................................................................................................8
1.5.1 Alcances ..............................................................................................................8
1.5.2 Límites .................................................................................................................9
1.6 Metodología.............................................................................................................9
1.6.1 Metodología de investigación ...............................................................................9
1.6.2 Metodología de desarrollo .................................................................................. 10

CAPÍTULO II MARCO TEÓRICO .................................................................................. 11

2.1 Marco Institucional ................................................................................................ 11

2.1.1 Funciones y procedimientos. .............................................................................. 13
2.2 Metodología........................................................................................................... 14
2.2.1 Extreme Programming (XP) ............................................................................... 14
2.2.1.1 Valores de la metodología XP .................................................................... 15
2.2.1.2 Prácticas básicas de XP .............................................................................. 16
2.2.1.3 El proceso de desarrollo en XP ................................................................... 17
 2.2.1.4 Características de la Programación Extrema ............................................... 18
2.2.1.5 Roles de XP ............................................................................................... 19
2.2.1.6 Ciclo de vida de XP.................................................................................... 21
2.2.2 Fases de la Metodología XP ............................................................................... 22
2.2.2.1 Fase I – Planificación de Proyectos............................................................. 22
2.2.2.2 Fase II- Diseño ........................................................................................... 27
2.2.2.3 Fase III-Codificación .................................................................................. 29
2.2.2.4 Fase IV-Pruebas ......................................................................................... 30
2.2.3 Ingeniería WEB ................................................................................................. 31
2.2.3.1 WEB Modeling Language (WEBML) ........................................................ 32
2.2.3.2 Objetivos De WEBML ............................................................................... 32
2.2.3.3 Diseño en WEBML .................................................................................... 33
2.2.3.3.1 Modelado Estructural .............................................................................. 34
2.2.3.3.2 Modelado de Hipertexto .......................................................................... 35
2.3 Inventario .............................................................................................................. 41
2.3.1 Tipos de inventarios ........................................................................................... 42
2.3.2 Sistema de Control de Inventario........................................................................ 42
2.3.3 Método primero en entrar primero en salir (PEPS) ............................................. 43
2.3.4 Ventas ................................................................................................................ 44
2.4 Tecnologías de software......................................................................................... 45
2.4.1 Laravel ............................................................................................................... 45
2.4.2 PostgreSQL........................................................................................................ 46
2.4.3 PHP ................................................................................................................... 46
2.4.4 Bootstrap ........................................................................................................... 47
2.4.5 Vue.js ................................................................................................................ 48
2.5 Métricas o calidad de software ............................................................................... 49
2.5.1 Calidad de Software ........................................................................................... 49
2.5.2 Métricas de calidad ............................................................................................ 49
2.5.2.1 Normas ISO/IEC 9126 ............................................................................... 50
2.5.2.2 Metodología de evaluación de calidad ........................................................ 53
2.6 Estudio de costos y beneficio ................................................................................. 53
 2.6.1 Modelo de estimación de proyectos de Software COCOMO .............................. 53
2.6.1.1 Modelo Básico ........................................................................................... 54
2.6.1.2 Modelo intermedio ..................................................................................... 54
2.6.1.3 Modelo detallado ........................................................................................ 56
2.7 Seguridad............................................................................................................... 56
2.7.1 Seguridad Física................................................................................................. 57
2.7.2 Seguridad Lógica ............................................................................................... 58
2.7.2.1 Seguridad a nivel Sistema Operativo .......................................................... 58
2.7.2.2 Seguridad a nivel Gestión de Base de Datos ............................................... 58
2.7.2.3 Seguridad a nivel de Aplicación ................................................................. 59
2.7.3 Recomendaciones OWASP ................................................................................ 59
2.7.3.1 Riesgos en la Seguridad de las Aplicaciones ............................................... 60

CAPÍTULO III MARCO APLICATIVO .......................................................................... 65

3.1 Introducción........................................................................................................... 65
3.2 Fases de la metodología XP ................................................................................... 67
3.2.1 Fase I – Planificación ......................................................................................... 67
3.2.1.1 Clasificación e identificación de roles......................................................... 67
3.2.1.2 Obtención de requerimientos ...................................................................... 68
3.2.1.2.1 Requerimientos funcionales ..................................................................... 68
3.2.1.2.2 Requerimientos no funcionales ................................................................ 70
3.2.1.3 Historias de Usuario y Tarjetas de Tarea..................................................... 71
3.2.1.4 Plan de Iteración......................................................................................... 93
3.2.1.5 Plan de entregas ......................................................................................... 94
3.2.2 Fase II – Diseño ................................................................................................. 94
3.2.2.1 Modelo Estructural ..................................................................................... 95
3.2.2.2 Primera iteración ........................................................................................ 98
3.2.2.3 Segunda iteración ..................................................................................... 104
3.2.2.4 Tercera Iteración ...................................................................................... 112
3.2.2.5 Cuarta Iteración ........................................................................................ 115
3.2.2.6 Diagramas de casos de uso ....................................................................... 119
3.2.3 Fase III – Codificación ..................................................................................... 120
 3.2.4 Fase IV – Pruebas ............................................................................................ 127
3.2.4.1 Pruebas de aceptación............................................................................... 127

CAPÍTULO IV MÉTRICAS DE CALIDAD .................................................................. 141

4.1 Introducción......................................................................................................... 141

4.2 Calidad ................................................................................................................ 141
4.3 Metodología de evaluación de calidad de sitios WEB (WEBSITE QEM) ............. 142
4.3.1 Definición y especificación de requerimientos de calidad ................................. 142
4.3.2 Criterio de preferencia de calidad elemental ..................................................... 144
4.3.3 Especificación de atributos ............................................................................... 144
4.3.4 Definición e implementación de la evaluación elemental .................................. 145

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

5.1 Introducción......................................................................................................... 150

5.2 Evaluación de costo y beneficio ........................................................................... 150
5.2.1 Análisis de costos ............................................................................................. 150
5.2.2 Beneficios ........................................................................................................ 154
5.2.2.1 Valor Actual Neto (VAN) ........................................................................ 154
5.2.2.2 Tasa interna de retorno (TIR) ................................................................... 155
5.3 Costo / Beneficio ................................................................................................. 156

CAPÍTULO VI SEGURIDAD DEL SISTEMA .............................................................. 158

6.1 Introducción......................................................................................................... 158

6.1.1 Seguridad Física............................................................................................... 158
6.1.2 Seguridad Lógica ............................................................................................. 158
6.1.2.1 Seguridad a Nivel del Sistema Operativo .................................................. 158
6.1.2.2 Seguridad a Nivel del Sistema de Gestión de Base de Datos ..................... 159
6.1.2.3 Seguridad a Nivel Aplicación desarrollada (OWASP) .............................. 160
6.1.2.4 Ataque Interno.......................................................................................... 163

CAPÍTULO VII CONLUSIONES Y RECOMENDACIONES ...................................... 164

7.1 Conclusiones........................................................................................................ 164

7.2 Recomendaciones ................................................................................................ 165
BIBLIOGRAFÍA .............................................................................................................. 166

ANEXOS ........................................................................................................................... 172

ANEXO A – ÁRBOL DE PROBLEMAS ....................................................................... 172

ANEXO B – ÁRBOL DE OBJETIVOS .......................................................................... 173
ANEXO C – MARCO LÓGICO ..................................................................................... 174
 ÍNDICE DE FIGURAS

Figura 2.1 Organigrama Institucional .................................................................................... 12

Figura 2.2 Metodología XP: Características .......................................................................... 19

Figura 2.3 Fase de Programación Extrema ............................................................................ 22

Figura 2.4 Metodología XP: Fase I- Planificación del Proyecto XP....................................... 24

Figura 2.5 Componentes de un Sitio Web con Webml .......................................................... 33

Figura 2.6 Diagrama de Estructura........................................................................................ 34

Figura 2.7 WebML: Hipertextos ........................................................................................... 35

Figura 2.8 Unidades de Contenido ........................................................................................ 37

Figura 2.9 Modelado de Navegación ..................................................................................... 38

Figura 2.10 Descripción y Elementos del modelado de Hipertexto ........................................ 40

Figura 2.11 Logo Laravel ..................................................................................................... 45

Figura 2.12 Logo PostgreSQL .............................................................................................. 46

Figura 2.13 Logo PHP .......................................................................................................... 47

Figura 2.14 Logo Bootstrap .................................................................................................. 48

Figura 2.15 Logo Vue.js ....................................................................................................... 49

Figura 2.16 Modelo de evaluación ISO 9126 ........................................................................ 50

Figura 2.17 COCOMO Básico .............................................................................................. 54

Figura 2.18 COCOMO Intermedio........................................................................................ 55

Figura 2.19 Factores de costo en COCOMO Básico .............................................................. 55

Figura 2.20 Riesgos en la Seguridad de las Aplicaciones ...................................................... 61

Figura 2.21 Factores que Determinan el Riesgo de Amenazas ............................................... 61

Figura 2.22 Resumen de los factores de Riesgo del Top 10 ................................................... 64

Figura 3.1 Función de la Metodología XP y WebML ............................................................ 66

Figura 3.2 Diagrama de contexto del sistema ........................................................................ 95

Figura 3.3 Modelo Entidad Relación E-R ............................................................................. 96

Figura 3.4 Base de Datos ...................................................................................................... 97

Figura 3.5 Modelo de Hipertexto – Usuario ........................................................................ 100

Figura 3.6 Modelo de Hipertexto – Roles............................................................................ 101

Figura 3.7 Modelo de Hipertexto – Menú ........................................................................... 101

Figura 3.8 Modelo de Hipertexto – Personal de Trabajo...................................................... 102

Figura 3.9 Modelo de Presentación – Usuario ..................................................................... 102

Figura 3.10 Modelo de Presentación – Rol.......................................................................... 103

Figura 3.11 Modelo de Presentación – Menú ...................................................................... 103

Figura 3.12 Modelo de Presentación – Personal Trabajo ..................................................... 104

Figura 3.13 Modelo de Hipertexto – Sucursal ..................................................................... 107

Figura 3.14 Modelo de Hipertexto – Inventario de productos .............................................. 107

Figura 3.15 Modelo de Hipertexto – Producto..................................................................... 108

Figura 3.16 Modelo de Hipertexto – Categoría ................................................................... 108

Figura 3.17 Modelo de Hipertexto – Proveedor................................................................... 109

Figura 3.18 Modelo de Presentación – Sucursal .................................................................. 109

Figura 3.19 Modelo de Presentación – Inventario ............................................................... 110

Figura 3.20 Modelo de Presentación – Producto ................................................................. 110

Figura 3.21 Modelo de Presentación – Categoría ................................................................ 111

Figura 3.22 Modelo de Presentación – Proveedor ............................................................... 111

Figura 3.23 Modelo de Hipertexto – Factura ....................................................................... 113

Figura 3.24 Modelo de Hipertexto – Cliente y Venta .......................................................... 114

Figura 3.25 Modelo de Presentación – Factura, Cliente y Ventas ........................................ 114

Figura 3.26 Modelo de Hipertexto – Reportes de inventarios .............................................. 116

Figura 3.27 Modelo de Hipertexto – Reportes de Factura .................................................... 117

Figura 3.28 Modelo de Hipertexto – Reportes de Ingresos y Salidas ................................... 117

Figura 3.29 Modelo de Presentación – Reporte de Inventarios ............................................ 118

Figura 3.30 Modelo de Presentación – Reporte Factura....................................................... 118

Figura 3.31 Diagrama de caso de uso del módulo de Inventarios......................................... 119

Figura 3.32 Diagrama de caso de uso del módulo de Ventas y Facturación ......................... 120

Figura 3.33 Pantalla - inicio de Sesión ................................................................................ 121

Figura 3.34 Pantalla – Accesos de Usuarios ........................................................................ 121

Figura 3.35 Pantalla - Roles ................................................................................................ 122

Figura 3.36 Pantalla - Menus .............................................................................................. 122

Figura 3.37 Pantalla – Registro Personal de Trabajo ........................................................... 123

Figura 3.38 Pantalla – Sucursales........................................................................................ 123

Figura 3.39 Pantalla – Inventario ........................................................................................ 124

Figura 3.40 Pantalla – Productos......................................................................................... 124

Figura 3.41 Pantalla – Categorías........................................................................................ 125

Figura 3.42 Pantalla – Registro Proveedor .......................................................................... 125

Figura 3.43 Pantalla – Factura ............................................................................................ 126

Figura 3.44 Pantalla – Ventas ............................................................................................. 126

Figura 3.45 Pantalla – Reportes .......................................................................................... 127

 ÍNDICE DE TABLAS

Tabla 2.1 Plantilla para la Elaboración de Historias de Usuario............................................. 25

Tabla 2.2 Plantilla para Tareas de Ingeniería ......................................................................... 26

Tabla 2.3 Plantilla para las Tarjetas CRC .............................................................................. 29

Tabla 2.4 Modelo propuesto para una Prueba de Aceptación................................................. 31

Tabla 2.5 Métodos de Inventarios ......................................................................................... 44

Tabla 3.1 Identificación de roles ........................................................................................... 67

Tabla 3.2 Historia de Usuario 1- Usuarios............................................................................. 72

Tabla 3.3 Tarjeta de Tarea 1.1 de Historia de Usuario 1 ........................................................ 72

Tabla 3.4 Tarjeta de Tarea 1.2 de Historia de Usuario 1 ........................................................ 73

Tabla 3.5 Tarjeta de Tarea 1.3 de Historia de Usuario 1 ........................................................ 73

Tabla 3.6 Historia de Usuario 2 - Roles ................................................................................ 74

Tabla 3.7 Tarjeta de Tarea 2.1 de Historia de Usuario 2 ........................................................ 74

Tabla 3.8 Tarjeta de Tarea 2.2 de Historia de Usuario 2 ........................................................ 75

Tabla 3.9 Historia de Usuario 3 - Menús ............................................................................... 75

Tabla 3.10 Tarjeta de Tarea 3.1 de Historia de Usuario 3 ...................................................... 76

Tabla 3.11 Tarjeta de Tarea 3.2 de Historia de Usuario 3 ...................................................... 76

Tabla 3.12 Historia de Usuario 4 – Personal de Trabajo ........................................................ 77

Tabla 3.13 Tarjeta de Tarea 4.1 de Historia de Usuario 4 ...................................................... 77

Tabla 3.14 Tarjeta de Tarea 4.2 de Historia de Usuario 4 ...................................................... 78

Tabla 3.15 Historia de Usuario 5 – Sucursal ......................................................................... 78

Tabla 3.16 Tarjeta de Tarea 5.1 de Historia de Usuario 5 ...................................................... 79

Tabla 3.17 Tarjeta de Tarea 5.1 de Historia de Usuario 5 ...................................................... 79

Tabla 3.18 Historia de Usuario 6 – Inventario ....................................................................... 80

Tabla 3.19 Tarjeta de Tarea 6.1 de Historia de Usuario 6 ...................................................... 80

Tabla 3.20 Tarjeta de Tarea 6.2 de Historia de Usuario 6 ...................................................... 81

Tabla 3.21 Historia de Usuario 7 – Registro de Productos ..................................................... 81

Tabla 3.22 Tarjeta de Tarea 7.1 de Historia de Usuario 7 ...................................................... 82

Tabla 3.23 Tarjeta de Tarea 7.2 de Historia de Usuario 7 ...................................................... 82

Tabla 3.24 Historia de Usuario 8 – Categorías ...................................................................... 83

Tabla 3.25 Tarjeta de Tarea 8.1 de Historia de Usuario 8 ...................................................... 83

Tabla 3.26 Historia de Usuario 9 – Proveedor ....................................................................... 84

Tabla 3.27 Tarjeta de Tarea 9.1 de Historia de Usuario 9 ...................................................... 84

Tabla 3.28 Historia de Usuario 10 – Facturación................................................................... 85

Tabla 3.29 Tarjeta de Tarea 10.1 de Historia de Usuario 10 .................................................. 85

Tabla 3.30 Tarjeta de Tarea 10.1 de Historia de Usuario 10 .................................................. 86

Tabla 3.31 Historia de Usuario 11 – Clientes ........................................................................ 86

Tabla 3.32 Tarjeta de Tarea 11.1 de Historia de Usuario 11 .................................................. 87

Tabla 3.33 Historia de Usuario 12 – Ventas .......................................................................... 87

Tabla 3.34 Tarjeta de Tarea 12.1 de Historia de Usuario 12 .................................................. 88

Tabla 3.35 Historia de Usuario 13– Reportes de inventario ................................................... 88

Tabla 3.36 Tarjeta de Tarea 13.1 de Historia de Usuario 13 .................................................. 89

Tabla 3.37 Historia de Usuario 14 – Reportes de facturas ..................................................... 89

Tabla 3.38 Tarjeta de Tarea 14.1 de Historia de Usuario 14 .................................................. 90

Tabla 3.39 Historia de Usuario 15 – Reportes de ingresos salidas ......................................... 90

Tabla 3.40 Tarjeta de Tarea 15.1 de Historia de Usuario 15 .................................................. 91

Tabla 3.41 Resumen de Historia de Usuario.......................................................................... 92

Tabla 3.42 Plan de Iteración ................................................................................................. 93

Tabla 3.43 Plan de Entregas .................................................................................................. 94

Tabla 3.44 Tarjeta CRC - Usuarios ....................................................................................... 98

Tabla 3.45 Tarjeta CRC - Rol ............................................................................................... 99

Tabla 3.46 Tarjeta CRC - Menú ............................................................................................ 99

Tabla 3.47 Tarjeta CRC – Personal_Trabajo ....................................................................... 100

Tabla 3.48 Tarjeta CRC - Sucursal...................................................................................... 105

Tabla 3.49 Tarjeta CRC - Inventario ................................................................................... 105

Tabla 3.50 Tarjeta CRC – Producto .................................................................................... 105

Tabla 3.51 Tarjeta CRC - Categoría .................................................................................... 106

Tabla 3.53 Tarjeta CRC - Factura ....................................................................................... 112

Tabla 3.54 Tarjeta CRC - Cliente ........................................................................................ 112

Tabla 3.55 Tarjeta CRC - Venta.......................................................................................... 113

Tabla 3.56 Tarjeta CRC – Reporte Inventario ..................................................................... 115

Tabla 3.57 Tarjeta CRC – Reporte Factura ......................................................................... 115

Tabla 3.58 Tarjeta CRC – Reporte ingresos y Salidas ......................................................... 116

Tabla 3.59 Prueba de Aceptación – Usuarios ...................................................................... 128

Tabla 3.60 Prueba de Aceptación – Administración de Roles .............................................. 129

Tabla 3.61 Prueba de Aceptación – Administración de menús ............................................ 130

Tabla 3.62 Prueba de Aceptación – Personal de trabajo ...................................................... 131

Tabla 3.63 Prueba de Aceptación – Administración de sucursal .......................................... 132

Tabla 3.64 Prueba de Aceptación – Inventario .................................................................... 133

Tabla 3.65 Prueba de Aceptación – Producto ...................................................................... 134

Tabla 3.66 Prueba de Aceptación – Categoría ..................................................................... 135

Tabla 3.67 Prueba de Aceptación – Proveedor .................................................................... 136

Tabla 3.68 Prueba de Aceptación – Módulo facturación...................................................... 137

Tabla 3.69 Prueba de Aceptación – Cliente ......................................................................... 137

Tabla 3.70 Prueba de Aceptación – Ventas ......................................................................... 138

Tabla 3.71 Prueba de Aceptación – Reportes de Inventario ................................................. 138

Tabla 3.72 Prueba de Aceptación – Reportes de Facturación............................................... 139

Tabla 3.73 Prueba de Aceptación – Reportes de Entradas y Salidas .................................... 140

Tabla 4.1. Árbol de requerimientos de calidad para el Sistema Integrado Académico .......... 143

Tabla 4.2. Resultados de preferencia elementales de Usabilidad ......................................... 146

Tabla 4.3. Resultados de preferencia elementales de Funcionalidad .................................... 146

Tabla 4.4. Resultados de preferencia elementales de Confiabilidad ..................................... 148

Tabla 4.5. Resultados de preferencia elementales de Eficiencia........................................... 148

Tabla 4.6. Resumen Global de Calidad ............................................................................... 148

Tabla 5.1. Coeficientes, Modelo Básico .............................................................................. 151

Tabla 5.2 Selección de multiplicadores de Esfuerzo ............................................................ 152

Tabla 5.3 Coeficientes, Modelo Intermedio......................................................................... 153

Tabla 5.4. Costo estimado................................................................................................... 153

Tabla 5.5. Cantidad nominal por año .................................................................................. 155

 CAPÍTULO I MARCO REFERENCIAL

1.1 Introducción

La mayoría de las organizaciones, empresas, instituciones y otras agrupaciones, requieren de

los Sistemas de Información como la base principal en las actividades que realizan. En informática,

los sistemas de información ayudan a administrar, recolectar, recuperar, procesar, almacenar y

distribuir información relevante para los procesos fundamentales y las particularidades de las

mismas. Autores como Peralta (2008), de una manera más acertada define sistemas de información

como: conjunto de elementos que interactúan entre sí, con el fin de apoyar las actividades de una

empresa o negocio. Teniendo muy en cuenta el equipo computacional necesario para que el sistema

de información pueda operar y el recurso humano que interactúa con el Sistema de Información,

el cual está formado por las personas que utilizan el sistema.

En la ciudad de La Paz, las Ópticas compiten en igualdad de calidad y eficiencia a través de un

servicio diferenciado, es por eso que las Tecnologías de Información y Comunicación (TICs) se

volvieron una herramienta fundamental e imprescindible para una empresa.

Al hacer el desarrollo de la investigación, se ha identificado claramente, el inadecuado control

de las ventas e inventarios que realizan diariamente en la Red de Ópticas “VIRTUAL”, ya que la

administración y los procesos utilizados para el manejo de la información son manuales, por tal

motivo hay muchos problemas a la hora de buscar información oportuna y segura.

1
 El presente proyecto tiene como fin automatizar los procesos administrativos dentro de la Red

de Ópticas, con la implementación del “SISTEMA WEB DE CONTROL DE VENTAS E

INVENTARIOS” que proporcionará mayor información actualizada del funcionamiento de la

empresa, una herramienta útil para la asistencia a los procesos administrativos, consultas, reportes,

control, entre otros.

1.2 Problema

Los problemas que presenta esta Red de Ópticas son: la dificultad en el manejo de

información de las ventas, productos y el mantenimiento de la información contable. Esto se

identifica mediante entrevistas realizadas al personal de las sucursales.

1.2.1 Antecedentes

1.2.1.1 Antecedentes Institucionales

La Red de Ópticas “VIRTUAL” fue creada en la ciudad de La Paz en el año 2017, en un inicio

comercializó monturas y gafas de sol en una galería comercial, ahora cuenta con la asociación de

profesionales en optometría, tomando la decisión de extenderse con dos sucursales en la ciudad de

La Paz y una sucursal en la ciudad de El Alto, formando así una Red de Ópticas, esta cuenta con

personal de trabajo en distintas áreas y desplegados en diferentes sucursales.

Actualmente el control de ventas e inventarios que se realiza en cada una de estas sucursales,

es antigua y deficiente, el registro de los movimientos de entrada y de salida de almacenes de esta

2
empresa son realizados manualmente, lo cual ocasiona la acumulación de la información en gran

cantidad.

▪ Proceso de venta y facturación de la Red de Ópticas “VIRTUAL”: El cliente solicita

el producto (vidrio, montura, medición o todos) en el caso de un servicio completo, el

cliente puede tener las medidas realizada con su respectivo oftalmólogo o puede realizar

las medidas en una de las sucursales de dicha red, además de escoger el tipo de vidrio

más adecuado para su condición visual, y también debe elegir la montura que más le

agrade, el empleado verifica la existencia de los productos elegidos por el cliente para

realizar la respectiva cotización, si el cliente desea realizar el proceso de compra, el

empleado recaba el precio de los productos en moneda racional y entrega el producto

finalizado en un determinado tiempo para finalmente proceder a facturar la venta.

▪ Proceso de inventario de productos de la Red de Ópticas “VIRTUAL”: El

inventario de cada sucursal se encuentra a cargo de un responsable. Estas personas

tienen que actualizar la información al día; deben cuantificar los productos que existen

en la óptica, los que fueron vendidos y también los que sufrieron desperfectos.

1.2.1.2 Antecedentes de Proyectos Similares

En gestiones pasadas se han realizado distintos sistemas de control de ventas e inventarios los

cuales han sido desarrollados según las necesidades de entidades específicas. Entre los muchos

que existen en la carrea de informática de la Universidad Mayor de San Andrés, se pueden citar:

3
• “Sistema web de control de compras, ventas e inventarios caso: empresa EDDYMAR”

de Deysi Vanessa Rojas Laguna en el año 2014. En este proyecto se diseña y desarrolla

un sistema que permite hacer el control de compras, ventas e inventario de la empresa

EDDYMAR, haciendo el uso de la metodología de Desarrollo Ágil XP y modelado con

el Diseño Conceptual de aplicaciones Web (WebML).

• “Sistema de entradas y salidas e inventario Caso: BOLITAL S.R.L” realizado por el

universitario Chiri Honorio Claudia en el año 2010. Se ha observado que en la empresa

Bolital S.R.L., se tenía problemas en el manejo de la información de todas las

actividades que desarrollan debido a que no contaban con un sistema automatizado para

todas las actividades ya sean para las entradas o salidas de productos de la empresa. El

presente proyecto de grado presenta una alternativa para contribuir a la empresa Bolital

S.R.L. tener mejor un manejo de todos los procesos que desarrolla la empresa como ser

entradas y salidas para tener información actualizada de los inventarios de todos los

productos y poder realizar reportes detallados de todas las actividades que realiza ya que

será de gran utilidad para la empresa.

• Sistema web de seguimiento de ventas y cobranzas para la agencia “Cosmos Travel and

Services S.R.L.” de Luis Alfredo Colmena Vargas en el año 2015. En este proyecto se

diseña y desarrolla un sistema en plataforma web que permite hacer control y

seguimiento de la venta y cobranzas de los servicios ofertados por la mencionada

agencia, haciendo uso de la metodología de desarrollo ágil XP (Extreme Programming

4
 • – Programación Extrema) y modelado con el Diseño Conceptual de Aplicaciones Web

(WebML).

1.2.2 Planteamiento del Problema

El problema de controlar ventas e inventarios, radica principalmente en la gran cantidad de

información que se genera en el registro de ingreso, salida y venta de los productos, se pudo

evidenciar que cada sucursal de la Red de Ópticas “VIRTUAL” registra dicha información de

forma manual, lo cual implica, registros erróneos, mala manipulación de la información y pérdida

de información de productos, de manera que tiene como consecuencia pérdidas monetarias así

también disminuye la preferencia de los clientes ante la empresa optando por otras. Con los

procesos empleados para el control de ventas e inventarios de cada sucursal, retarda el manejo

eficiente y eficaz de la administración. Los informes realizados manualmente, causan demoras e

incomodidades para el personal de trabajo, puesto que el tiempo invertido para el control sea

tedioso.

1.2.3 Formulación del problema

¿Cómo mejorar los procesos de control de venta e inventario de productos y tener una mejor

administración en la Red de Ópticas “VIRTUAL”?

5
1.3 Objetivos

1.3.1 Objetivo General

Diseñar e implementar un sistema web para ejecutar el control de ventas e inventarios en la Red

de Ópticas “VIRTUAL”, así mismo poder agilizar los procesos comerciales y optimizar el proceso

de la administración de información de cada sucursal.

1.3.2 Objetivos Específicos

• Diseñar una Base de Datos Relacional.

• Desarrollar el Módulo de control de accesos y permisos adecuados para los diferentes

roles de usuarios y permita realizar a cada usuario sus actividades adecuadamente.

• Desarrollar el módulo de control de inventario y venta de productos.

• Desarrollar el módulo de facturación.

• Desarrollar el módulo de reportes estratégicos, para el control de inventario y venta de

productos, brindando información rápida y confiable.

1.4 Justificaciones

1.4.1 Justificación Social

Con el desarrollo de este proyecto, beneficia a la Red de Ópticas “VIRTUAL” y a todo su

personal, debido a que, mejora los procesos de inventario y venta de productos, además que, el

sistema es amigable con el usuario ayudando al personal a obtener información precisa y ordenada.

6
 El proceso de registro de mantenimiento se automatiza, evitando el desgaste humano y

ayudando al personal a aumentar su nivel productivo. Al tener un control ordenado y preciso sobre

los diversos cambios que se realizan en almacén, se garantiza un mejor suministro de parte de los

proveedores de los materiales para asegurar una producción ininterrumpida y rítmica, ofreciendo

una mejor atención a los clientes y mejorando las ventas.

1.4.2 Justificación Tecnológica

El desarrollo del presente proyecto para la Red de Ópticas “VIRTUAL”, se justifica

técnicamente porque mejora el método y técnica de acceso de datos para la toma de decisiones.

Actualmente cuentan con las herramientas tecnológicas necesarias para la implementación del

sistema de información web, así mismo esta plataforma da la posibilidad a la integración del

seguimiento de información de sus sucursales.

Es importante mencionar que la implementación del proyecto se realiza en su totalidad, con

herramientas de software libre y código abierto, aprovechando estos recursos al máximo para

obtener un producto de calidad, lo cual permite un costo mínimo en el proyecto. Se emplea la

tecnología para compartir o distribuir la información de la base de datos que se dispone en

cualquier computador, utilizando medidas de seguridad para que esta información pueda ser

accedida solo por usuarios autorizados, además de usar una interfaz adecuada y fácil de operar con

cualquier otro usuario

7
1.4.3 Justificación Económica

La justificación económica del proyecto se realiza analizando los ahorros que genera la

implementación del proyecto, el cual permite gestionar la información y procesos evitando errores

en el control de la actividad comercial, los cuales generan pérdidas económicas. Se logra también

descentralizar la información, permitiendo el ahorro en gastos de mantenimiento.

El desarrollo del Sistema es económicamente factible ya que los gastos no son elevados en

comparación con los beneficios que brinda a los usuarios finales.

1.5 Alcances y Limites

1.5.1 Alcances

El presente proyecto está disponible para todos los usuarios registrados que supervisen el

sistema, con acceso a los módulos de acuerdo a las funciones que realiza. El desarrollo del trabajo

se encuentra dentro de los siguientes alcances:

o Módulo administración y autentificación de usuarios

o Módulo de sucursal

o Módulo de inventario de productos

o Módulo de facturación de ventas

o Módulo de reportes

8
1.5.2 Límites

El presente sistema se limita en las siguientes acciones:

• La actualización de información se realiza solo por el personal autorizado.

• La información no puede ser borrada por ningún usuario no autorizado.

• Las acciones que se realicen en la base de datos son controladas por medio de la

administración.

• No elimina reportes ya que pueden ser usados para la administración financiera.

1.6 Metodología

1.6.1 Metodología de investigación

En el proceso de investigación se aplica el Método Científico. El método científico es un

proceso sistemático organizado y dirigido que tiene como objeto fundamental la búsqueda de

procedimientos válidos y confiables sobre hechos y fenómenos, que no se queda sin fundamentos

ni apoyos comprobables.

Se emplea una investigación de tipo Descriptiva que tiene como propósito conocer situaciones,

costumbres y actitudes predominantes a través de la descripción exacta de las actividades, objetos

y procesos predominantes a través de la descripción exacta, su meta no se limita exclusivamente a

la recolección de datos, sino a la predicción e identificación de las relaciones que existen entre dos

o más variables.

9
 El enfoque es Cuantitativo con procesos deductivos, donde cada etapa conduce de forma lógica

a la que viene, sirve para comprobar, explicar o predecir un determinado hecho. La investigación

cuantitativa pone énfasis en el proceso de investigación y no tanto en el resultado.

1.6.2 Metodología de desarrollo

“Las metodologías ágiles promueven las relaciones interpersonales, son adaptativas, se enfocan

en las personas, caracterizándose por existir una estrecha colaboración entre el cliente y el equipo

de desarrollo” (Pérez, Sepúlveda y Yoanna, 2011).

Para el desarrollo de este proyecto de grado, se hace uso de la metodología de desarrollo de

software ágil XP (Extreme Programming o Programación Extrema), Beck define un conjunto de

cinco valores que establecen el fundamento para todo trabajo realizado como parte de XP:

comunicación, simplicidad, retroalimentación, valentía y respeto.

La herramienta que se utiliza para el modelado es WEBML empleada para ofrecer un diseño de

alto nivel de aplicaciones web intensivas en el manejo de datos, que combina técnicas de modelado

ER con UML. WebML soporta una colección de conceptos poderosos que posibilitan un diseño

de alto nivel y provee especificaciones gráficas para producir una descripción (a nivel abstracto)

de la aplicación Web.

10
CAPÍTULO II MARCO TEÓRICO

2.1 Marco Institucional

La Red de Ópticas “VIRTUAL” es una empresa que ofrece una atención especializada en salud

visual, así mismo de comercializar gran cantidad de productos de calidad. Cada sucursal cuenta

con personal calificado en evaluación de capacidades visuales mediante técnicas optométricas,

tallado, montaje, adaptación, suministro, verificación y control de los medios adecuados para la

prevención, detención, protección y mejora de la agudez visual.

La actividad principal de la empresa es la de comercializar productos variados en cuanto a

monturas (montura entera, media montura y montura flotante), estuches de lentes (tipo sobre, tipo

duros y tipo deportivos) y gafas de sol (diferentes modelos).

i. Misión:

Estar comprometidos en dar plena satisfacción a sus clientes, ofreciéndoles una

selección de los mejores y más variados productos a través de un servicio diferenciado,

exclusivos y de alta calidad, apoyándonos en un exquisito trato personalizado, para

lograr que cada cliente se sienta especial y plenamente satisfecho.

ii. Visión:

Consolidarse como la mejor opción de óptica para satisfacer las necesidades de sus

clientes, y ser uno los líderes como la cadena de ópticas de mayor cobertura nacional

bajo el amparo de la tecnología, productividad, talento humano y un profundo espíritu

de servicio.

11
 iii. Objetivos:

▪ Lograr un crecimiento continuo y sostenido en la comercialización de sus diferentes

productos.

▪ Sistematizar la documentación que se encuentra dentro de la empresa.

▪ Realizar la evaluación financiera mediante proyección de costos, gastos, ingresos e

inversión tomando en cuenta la rentabilidad de la empresa.

▪ Beneficiar con costos reducidos a los clientes que realicen la compra de manera

continua.

A continuación, se muestra como está organizada la Red de Ópticas “VIRTUAL” de acuerdo a

su organigrama.

Figura 2.1 Organigrama Institucional

Fuente: Elaboración propia

12
Gerente: Tiene bajo su responsabilidad las funciones de organizar, programar y supervisar las

diferentes actividades.

Optómetra: Está encargado de evaluar la vista y prescribir espejuelos y lentes de contacto.

Auxiliar de óptica: Asesora a los clientes en la selección de sus lentes, monturas o tratamientos

indicados para casos particulares.

Contador: Tiene como función:

▪ Documentar informes financieros para los clientes:

- Revisar los libros contables de los clientes.

- Analizar las ganancias y los gastos.

- Elaborar el balance de los libros financieros.

- Redactar informes sobre el estado financiero de sus clientes.

▪ Manejar registros, sistemas y presupuestos financieros.

▪ Hacer auditorías financieras para sus clientes.

Personal de aseo: Tiene como función velar que se cumplan las normativas de higiene y

seguridad.

2.1.1 Funciones y procedimientos.

La Red de Ópticas “VIRTUAL” no cuenta con un sistema de información, los empleados

registran la información de la siguiente forma:

13
 • El vendedor realiza el registro de la venta de los productos de manera manual.

• El encargado de ventas cuenta los productos de manera manual y son registrados hojas

de papel sin seguridad alguna.

• El personal encargado de la entrega del producto realiza su nota de venta y lo guarda en

una caja donde no existe seguridad alguna.

• El personal encargado de ventas tiene una lista actualizada de productos y no se verifica

si existen productos al margen de agotarse.

• No se verifica el stock antes de realizar la venta de los productos.

2.2 Metodología

El presente proyecto se desarrolla con la Metodología de Programación Extrema (XP).

2.2.1 Extreme Programming (XP)

“La Programación Extrema (XP) es posiblemente el método ágil más conocido y ampliamente

utilizado. El nombre fue acuñado por Beck (Beck, 2000) debido a que el enfoque fue desarrollado

utilizando buenas prácticas reconocidas, como el desarrollo iterativo y con la participación del

cliente en niveles ‘extremos’” (Sommerville, 2005).

Según (Joskowick, 2008) en su trabajo las Reglas y Prácticas en Extreme Programming (XP)

surge como una nueva manera de encarar proyectos de software, proponiendo una metodología

basada esencialmente en la simplicidad y agilidad. Los métodos ágiles son adaptables en lugar de

predictivos. Los métodos “clásicos” tienden a intentar planear una gran parte del proceso del

software en gran detalle para un plazo largo de tiempo. Esto funciona bien hasta que las cosas

14
cambian. Así que su naturaleza es resistirse al cambio. Para los métodos ágiles, no obstante, el

cambio es bienvenido. Intentan ser procesos que se adaptan y crecen en el cambio.

XP es una de las llamadas metodologías ágiles de desarrollo de software más exitosas de los

tiempos recientes. La metodología propuesta en XP está diseñada para entregar el software que los

clientes necesitan en el momento en que lo necesitan. XP alienta a los desarrolladores a responder

a los requerimientos cambiantes de los clientes, aún en fases tardías del ciclo de vida del desarrollo.

La metodología también enfatiza el trabajo en equipo. Tanto gerentes como clientes y

desarrolladores son partes del mismo equipo dedicado a entregar software de calidad.

2.2.1.1 Valores de la metodología XP

Los Valores originales de la programación extrema según (Bustamante y Rodríguez, 2014) son:

simplicidad, comunicación, retroalimentación, coraje o valentía, respeto, donde se detallan a

continuación:

• Simplicidad: Se simplifica el diseño para agilizar el desarrollo y facilitar el

mantenimiento. Para mantener la simplicidad es necesaria la refactorización del código,

ésta es la manera de mantener el código simple a medida que crece. También se aplica

la simplicidad en la documentación, para ello se deben elegir adecuadamente los

nombres de las variables, métodos y clases.

• Comunicación: La comunicación se realiza de diferentes formas. Para los

programadores el código comunica mejor cuanto más simple sea y también la

comunicación con el cliente es fluida ya que el cliente forma parte del equipo de

15
 desarrollo. El cliente decide qué características tienen prioridad y siempre debe estar

disponible para solucionar dudas.

• Retroalimentación (FEEDBACK): Al estar el cliente integrado en el proyecto, su

opinión sobre el estado del proyecto se conoce en tiempo real. Meses de trabajo pueden

tirarse por la borda debido a cambios en los criterios del cliente o malentendidos por

parte del equipo de desarrollo. El código también es una fuente de retroalimentación

gracias a las herramientas de desarrollo.

• Coraje o Valentía: Muchas de las prácticas implican valentía, una de ellas es siempre

diseñar y programar para hoy y no para mañana. La valentía permite a los

desarrolladores que se sientan cómodos con reconstruir su código cuando sea necesario.

También significa persistencia: donde el programador puede permanecer sin avanzar en

un problema complejo por un día entero, y luego lo resolverá rápidamente al día

siguiente, sólo si es persistente.

• Respeto. Se manifiesta de varias formas: todos los integrantes respetan sus trabajos,

porque siempre están luchando por la alta calidad en el producto y buscando el diseño

óptimo para la solución a través de la refactorización del código. A su vez, los miembros

del equipo respetan el trabajo del resto no haciendo menos a otros, esto mejora la

autoestima del equipo y eleva su ritmo de producción.

2.2.1.2 Prácticas básicas de XP

El proceso que recomiendan los autores de XP es el siguiente: identifica el principal problema

del proceso de desarrollo actual. Escoge la práctica que ayuda a resolver ese problema y aplicarla.

16
Cuando haya dejado de ser un problema, escoge el siguiente. En realidad, se recomienda que se

apliquen las prácticas de dos en dos. El objetivo es que las prácticas de XP se apoyan unas a otras

por lo cual dos prácticas aportan más que la suma de ambas y por tanto es más fácil comprobar los

resultados (Robles y Ferrer, 2002).

• El juego de la planificación (the planning game)

• Pequeñas entregas (small releases)

• Metáfora (metaphor)

• Diseño simple (simple design)

• Pruebas (testing)

• Refactorización (refactoring)

• Programación por parejas (pair programming)

• Propiedad colectiva (collective ownership)

• Integración continua (continous integration)

• 40 horas semanales (40-hour week)

• Cliente en casa (on-site costumer)

• Estándares de codificación (coding standards)

2.2.1.3 El proceso de desarrollo en XP

La programación extrema parte del caso habitual de una compañía que desarrolla software,

generalmente software a medida, en la que hay diferentes roles: un equipo de gestión, un equipo

de desarrolladores y los clientes. La relación con el cliente es totalmente diferente a lo que se ha

venido haciendo en las metodologías tradicionales, que se basan fundamentalmente en una fase de

17
captura de requisitos previa al desarrollo y una fase de validación posterior al mismo. Para que el

presente proyecto se ejecute debe seguir pasos donde el desarrollo es la pieza clave de todo el

proceso XP (Robles y Ferrer, 2002)

Todas las tareas tienen como objetivo realizar el desarrollo a la máxima velocidad, sin

interrupciones y siempre en la dirección correcta. El proceso de desarrollo tiene los siguientes

pasos:

• El cliente define el valor de negocio a implementar.

• El programador estima el esfuerzo necesario para su implementación.

• El cliente selecciona qué construir, de acuerdo con sus prioridades y las restricciones de

tiempo.

• El programador construye ese valor de negocio.

• Vuelve al paso 1

2.2.1.4 Características de la Programación Extrema

Según Bustamante y Rodríguez (2014) las características de XP son las siguientes:

18
 Figura 2.2 Metodología XP: Características
Fuente: Bustamante y Rodríguez, 2014

• Se diferencia de las metodologías tradicionales principalmente en que pone más énfasis

en la adaptabilidad que en la previsibilidad.

• Se aplica de manera dinámica durante el ciclo de vida del software.

• Es capaz de adaptarse a los cambios de requisitos.

• Los individuos e interacciones son más importantes que los procesos y herramientas.

• Al individuo y las interacciones del equipo de desarrollo sobre el proceso y las

herramientas.

2.2.1.5 Roles de XP

En este apartado se describen los roles de acuerdo con la propuesta original de Beck. Los roles

originales fueron: Programador, Cliente, Encargado de Pruebas, Encargado de Seguimiento,

Entrenador, Consultor y Gestor. (Loraine, 2012).

• Programador (Programmer). Es el responsable de implementar las historias de

usuario por el cliente. Además, estima el tiempo de desarrollo de cada historia de usuario

19
 para que el cliente pueda asignarle prioridad dentro de la iteración. Cada iteración

incorpora nueva funcionalidad de acuerdo a las prioridades establecidas por el cliente.

El Programador también es responsable de diseñar y ejecutar los test de unidad del

código que ha implementado o modificado.

• Cliente (Customer). Determina la funcionalidad que se pretende en cada iteración y

define las prioridades de implementación según el valor de negocio que aporta cada

historia. El Cliente también es responsable de diseñar y ejecutar los test de aceptación.

• Encargado de las pruebas (Tester). Es el Encargado de ejecutar las pruebas

regularmente, difunde los resultados dentro del equipo y es también el responsable de

las herramientas de soporte para pruebas.

• El encargado de seguimiento (Tracker). Una de las tareas más importante del tracker,

consiste en seguir la evolución de las estimaciones realizadas por los programadores y

compararlas con el tiempo real de desarrollo. De esta forma, puede brindar información

estadística en lo que refiere a la calidad de las estimaciones para que puedan ser

mejoradas.

• Entrenador (Coach). Es responsable del proceso en general. Se encarga de iniciar y de

guiar a las personas del equipo en poner en marcha cada una de las prácticas de la

metodología XP.

• Consultor. Es un miembro externo del equipo con un conocimiento específico en algún

tema necesario para el proyecto. Guía al equipo para resolver un problema específico.

20
 • Gestor (Big boss). Es el vínculo entre el cliente y programadores. Experto en tecnología

y labores de gestión. Construye el plantel del equipo, obtiene los recursos necesarios y

maneja los problemas que se generan. Su labor fundamental es de coordinación.

2.2.1.6 Ciclo de vida de XP

El ciclo de vida ideal de XP según Beck, consiste de seis fases: Exploración, Planificación de

la Entrega, Iteraciones, Producción, Mantenimiento y Muerte del Proyecto (Loraine, 2012). Sin

embargo, no se hace uso de todas ellas, sino así, de las cuatro fases.

• Exploración: en esta fase, el cliente plantea a grandes rasgos las historias de usuario

que son de interés para la primera entrega del producto.

• Planificación de la Entrega: en esta fase el cliente establece la prioridad de cada

historia de usuario

• Iteraciones: esta fase incluye varias iteraciones sobre el sistema antes de ser entregado.

• Producción: la fase de producción requiere de pruebas adicionales y revisiones de

rendimiento antes de que el sistema sea trasladado al entorno del cliente.

• Mantenimiento: mientras la primera versión se encuentra en producción, el proyecto

XP debe mantener el sistema en funcionamiento al mismo tiempo que desarrolla nuevas

iteraciones.

• Muerte del Proyecto: es cuando el cliente no tiene más historias para ser incluidas en

el sistema.

21
2.2.2 Fases de la Metodología XP

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

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

actividades estructurales: planeación, diseño, codificación y pruebas (Pressman, 2010).

Figura 2.3 Fase de Programación Extrema

Fuente: Canos, 2012
2.2.2.1 Fase I – Planificación de Proyectos

La actividad de planeación (también llamada juego de planeación) comienza escuchando,

actividad para recabar requerimientos que permite que los miembros técnicos del equipo XP

entiendan el contexto del negocio para el software y adquieran la sensibilidad de la salida y

características principales y funcionalidad que se requieren. Escuchar lleva a la creación de algunas

historias (también llamadas historias del usuario) que describen la salida necesaria, características

y funcionalidad del software que se va a elaborar. El cliente asigna un valor (es decir, una

prioridad) a la historia con base en el valor general de la característica o función para el negocio.

22
Después, los miembros del equipo XP evalúan cada historia y le asignan un costo, medido en

semanas de desarrollo. Si se estima que la historia requiere más de tres semanas de desarrollo, se

pide al cliente que la descomponga en historias más chicas. Es importante observar que en

cualquier momento es posible escribir nuevas historias.

Los clientes y desarrolladores trabajan juntos para decidir cómo agrupar las historias en la

siguiente entrega que desarrollará el equipo XP. El equipo XP ordena las historias que serán

desarrolladas en una de tres formas:

1) Todas las historias se implementarán de inmediato.

2) Las historias con más valor entrarán a la programación de actividades y se

implementarán en primer lugar.

3) Las historias más riesgosas formarán parte de la programación de actividades y se

implementarán primero.

Después de la primera entrega del proyecto (también llamada incremento de software), el

equipo XP calcula la velocidad de éste. La velocidad del proyecto se usa para:

1) Ayudar a estimar las fechas de entrega y programar las actividades para las entregas

posteriores.

2) Determinar si se ha hecho un gran compromiso para todas las historias durante todo el

desarrollo del proyecto. Si esto ocurre, se modifica el contenido de las entregas o se

cambian las fechas de entrega final.

23
 A medida que avanza el trabajo, el cliente puede agregar historias, cambiar el valor de una ya

existente, descomponerlas o eliminarlas. Entonces, el equipo XP reconsidera todas las entregas

faltantes y modifica sus planes en consecuencia (Pressman, 2010).

La planificación del proyecto, según la metodología XP se plasma en la Figura 2.4.

Figura 2.4 Metodología XP: Fase I- Planificación del Proyecto XP

Fuente: Bustamante y Rodríguez, 2014

Los Conceptos básicos de la planificación (Bustamante y Rodríguez, 2014) son:

• Historias de usuario: El primer paso de cualquier proyecto que siga la metodología XP

es definir las historias de usuario con el cliente. Las historias de usuario constan de 3 o

4 líneas escritas por el cliente en un lenguaje no técnico sin hacer mucho hincapié en

los detalles; no se debe hablar ni de posibles algoritmos para su implementación ni de

diseños de base de datos adecuados, etc. Son usadas para estimar tiempos de desarrollo

de la parte de la aplicación que describen. También se utilizan en la fase de pruebas,

para verificar si el programa cumple con lo que especifica la historia de usuario.

24
 Tabla 2.1 Plantilla para la Elaboración de Historias de Usuario
HISTORIA DE USUARIO
Usuario: Persona que utilizará la funcionalidad
Número: Número único que permite
del sistema descrita en la historia de usuario
identificar a una historia de usuario.
(Administrador, ayudante, etc.)
Nombre Historia: Describe de manera general a una historia de usuario.
Puntos Estimados: Número de Prioridad del Negocio: Grado de importancia que
semanas que se necesitará para el el cliente asigna a una historia de usuario.
desarrollo de una historia de usuario (Alta/Media/Baja)
Iteración Asignada: Número de
Riesgo de Desarrollo: Valor de complejidad que
iteración, en que el cliente desea que
una historia de usuario representa al equipo de
se implemente una historia de
desarrollo. (Alto/Medio/Bajo)
usuario
Descripción: Información detallada de una historia de usuario.
Observaciones: Campo opcional utilizado para aclarar, si es necesario, el requerimiento
descrito en una historia de usuario.
Fuente: Chiluisa y Loarte, 2014

• Planificación de Entregas (Release Planning): Un Release plan es una planificación

donde los desarrolladores y clientes establecen los tiempos de implementación ideales

de las historias de usuario, la prioridad con la que serán implementadas y las historias

que serán implementadas en cada versión del programa. Después de un Release plan

tienen que estar claros estos cuatro factores: los objetivos que se deben cumplir, el

tiempo que tardarán en desarrollarse y publicarse las versiones del programa, el número

de personas que trabajarán en el desarrollo y cómo se evaluará la calidad del trabajo

realizado.

25
 • Tareas de ingenierías (Task Card): Una Historias de Usuario se descompone en varias

tareas de ingeniería, las cuales describen las actividades que se realizarán en cada

historia de usuario, así mismo las tareas de ingeniería se vinculan más al desarrollador,

ya que permite tener un acercamiento con el código (Ferreira Escutia, 2013).

Tabla 2.2 Plantilla para Tareas de Ingeniería

TAREA DE INGENIERÍA
Número de tarea: Permite identificar a Número de historia: Número asignado de la
una tarea de ingeniería. historia correspondiente.
Nombre de tarea: Describe de manera general a una tarea de ingeniería.
Puntos estimados: Número de días que se
Tipo de tarea: Tipo al que corresponde
necesitará para el desarrollo de una tarea de
la tarea de ingeniería.
ingeniería.
Fecha inicio: Fecha inicial de la Fecha fin: Final concluida de la tarea de
creación de la tarea de ingeniería. ingeniería
Programador responsable: Persona encargada de programas la tarea de ingeniería.
Descripción: Información detallada de la tarea de ingeniería.
Fuente: Ferreira, 2013

• Iteraciones: Todo proyecto que siga la metodología X.P. se ha de dividir en iteraciones

de aproximadamente 3 semanas de duración. Al comienzo de cada iteración los clientes

deben seleccionar las historias de usuario definidas en el ReleasePlanning que serán

implementadas. También se seleccionan las historias de usuario que no pasaron el test

de aceptación que se realizó al terminar la iteración anterior. Estas historias de usuario

son divididas en tareas de entre 1 y 3 días de duración que se asignarán a los

programadores.

26
 • La Velocidad del Proyecto: Es una medida que representa la rapidez con la que se

desarrolla el proyecto; estimarla es muy sencillo, basta con contar el número de historias

de usuario que se pueden implementar en una iteración; de esta forma, se sabrá el cupo

de historias que se pueden desarrollar en las distintas iteraciones.

𝐍𝐮𝐦𝐞𝐫𝐨 𝐝𝐞 𝐇𝐢𝐬𝐭𝐨𝐫𝐢𝐚𝐬 𝐝𝐞 𝐔𝐬𝐮𝐚𝐫𝐢𝐨

𝐕𝐞𝐥𝐨𝐜𝐢𝐝𝐚𝐝 𝐝𝐞𝐥 𝐏𝐫𝐨𝐲𝐞𝐜𝐭𝐨 =
𝐍𝐮𝐦𝐞𝐫𝐨 𝐝𝐞 𝐒𝐞𝐦𝐚𝐧𝐚𝐬

• Programación en Parejas: La metodología XP aconseja la programación en parejas

pues incrementa la productividad y la calidad del software desarrollado, el trabajo en

pareja involucra a dos programadores trabajando en el mismo equipo; mientras uno

codifica haciendo hincapié en la calidad de la función o método que está

implementando, el otro analiza si ese método o función es adecuado y está bien

diseñado. De esta forma se consigue un código y diseño con gran calidad.

• Reuniones Diarias: Es necesario que los desarrolladores se reúnan diariamente y

expongan sus problemas, soluciones e ideas de forma conjunta. Las reuniones tienen

que ser fluidas y todo el mundo tiene que tener voz y voto.

2.2.2.2 Fase II- Diseño

El diseño XP sigue rigurosamente el principio MS (mantenlo sencillo). Un diseño sencillo

siempre se prefiere sobre una representación más compleja. Además, el diseño guía la

implementación de una historia conforme se escribe: nada más y nada menos. Se desalienta el

diseño de funcionalidad adicional porque el desarrollador supone que se requerirá después.

27
 XP estimula el uso de las tarjetas CRC como un mecanismo eficaz para pensar en el software

en un contexto orientado a objetos. Las tarjetas CRC (clase-responsabilidad-colaborador)

identifican y organizan las clases orientadas a objetos que son relevantes para el incremento actual

de software. Las tarjetas CRC son el único producto del trabajo de diseño que se genera como

parte del proceso XP. Si en el diseño de una historia se encuentra un problema de diseño difícil,

XP recomienda la creación inmediata de un prototipo operativo de esa porción del diseño.

Entonces, se implementa y evalúa el prototipo del diseño, llamado solución en punta. El objetivo

es disminuir el riesgo cuando comience la implementación verdadera y validar las estimaciones

originales para la historia que contiene el problema de diseño. XP estimula el rediseño, técnica de

construcción que también es un método para la optimización del diseño.

Fowler (2002) describe el rediseño del siguiente modo: Rediseño es el proceso mediante el cual

se cambia un sistema de software en forma tal que no altere el comportamiento externo del código,

pero sí mejore la estructura interna. Es una manera disciplinada de limpiar el código y modificar

o simplificar el diseño interno que minimiza la probabilidad de introducir errores. En esencia,

cuando se rediseña, se mejora el diseño del código después de haber sido escrito.

Como el diseño XP virtualmente no utiliza notación y genera pocos, si alguno, productos del

trabajo que no sean tarjetas CRC y soluciones en punta, el diseño es visto como un artefacto en

transición que puede y debe modificarse continuamente a medida que avanza la construcción.

Un concepto central en XP es que el diseño ocurre tanto antes como después de que comienza

la codificación. Rediseñar significa que el diseño se hace de manera continua conforme se

construye el sistema (Pressman, 2010).

28
 Tabla 2.3 Plantilla para las Tarjetas CRC
TARJETAS CRC
Nombre de la clase: Nombre de la clase al cual hace referencia la tarjeta
Responsabilidades: Atributos y Colaboradores: Clases que colaboran
operaciones de la clase. con la clase citada en la tarjeta.
Fuente: Chiluisa y Loarte, 2014
2.2.2.3 Fase III-Codificación

Después de que las historias han sido desarrolladas y de que se ha hecho el trabajo de diseño

preliminar, el equipo no inicia la codificación, sino que desarrolla una serie de pruebas unitarias a

cada una de las historias que se van a incluir en la entrega en curso (incremento de software). Una

vez creada la prueba unitaria, el desarrollador está mejor capacitado para centrarse en lo que debe

implementarse para pasar la prueba. No se agrega nada extraño (MS). Una vez que el código está

terminado, se le aplica de inmediato una prueba unitaria, con lo que se obtiene retroalimentación

instantánea para los desarrolladores.

Un concepto clave durante la actividad de codificación es la programación por parejas. XP

recomienda que dos personas trabajen juntas en una estación de trabajo con el objeto de crear

código para una historia. Esto da un mecanismo para la solución de problemas en tiempo real y

para el aseguramiento de la calidad también en tiempo real (el código se revisa conforme se crea).

También mantiene a los desarrolladores centrados en el problema de que se trate.

A medida que las parejas de programadores terminan su trabajo, el código que desarrollan se

integra con el trabajo de los demás. En ciertos casos, esto lo lleva a cabo a diario un equipo de

integración. En otros, las parejas de programadores tienen la responsabilidad de la integración.

Esta estrategia de integración continua ayuda a evitar los problemas de compatibilidad e interfaces

29
y brinda un ambiente de prueba de humo que ayuda a descubrir a tiempo los errores (Pressman,

2010).

2.2.2.4 Fase IV-Pruebas

Según Joskowicz (2008), en XP se realizan las siguientes pruebas:

• Pruebas unitarias: Las pruebas unitarias son una de las piedras angulares de XP. Todos

los módulos deben de pasar las pruebas unitarias antes de ser liberados o publicados.

Por otra parte, como se mencionó anteriormente, las pruebas deben ser definidas antes

de realizar el código Test-driven programming. Que todo código liberado pase

correctamente las pruebas unitarias es lo que habilita que funcione la propiedad

colectiva del código. En este sentido, el sistema y el conjunto de pruebas debe ser

guardado junto con el código, para que pueda ser utilizado por otros desarrolladores, en

caso de tener que corregir, cambiar o recodificar parte del mismo.

• Detección y corrección de errores: Cuando se encuentra un error bug, éste debe ser

corregido inmediatamente, y se deben tener precauciones para que errores similares no

vuelvan a ocurrir. Asimismo, se generan nuevas pruebas para verificar que el error haya

sido resuelto.

• Pruebas de aceptación: Las pruebas de aceptación son creadas en base a las historias

de usuarios, en cada ciclo de la iteración del desarrollo. El cliente debe especificar uno

o diversos escenarios para comprobar que una historia de usuario ha sido correctamente

implementada. Las pruebas de aceptación son consideradas como pruebas de caja

negra. Los clientes son responsables de verificar que los resultados de estas pruebas

30
 sean correctos. Asimismo, en caso de que fallen varias pruebas, deben indicar el orden

de prioridad de resolución. Una historia de usuario no se puede considerar terminada

hasta tanto pase correctamente todas las pruebas de aceptación.

Tabla 2.4 Modelo propuesto para una Prueba de Aceptación

CASO DE PRUEBA DE ACEPTACIÓN
Código: Historia de Usuario: (Nro. y Nombre)
Descripción:
Condiciones de Ejecución:
Entrada/ Pasos de ejecución:
Resultado Esperado:
Evaluación de la Prueba:
Fuente: Ramírez, 2013

2.2.3 Ingeniería WEB

“La ingeniería web es la aplicación de metodologías sistemáticas, disciplinadas y cuantificables

al desarrollo eficiente, operación y evolución de aplicaciones de alta calidad” (Sevilla, 2014).

Según Malleas (2009) en Murugesan, Deshpande y S., promotores iniciales del establecimiento

de la Ingeniería Web como nueva disciplina, dan la siguiente definición: Es el proceso utilizado

para crear, implantar y mantener aplicaciones y sistemas Web de alta calidad. Esta breve definición

nos lleva a abordar un aspecto clave de cualquier proyecto como es determinar qué tipo de proceso

es más adecuado en función de las características del mismo.

El desarrollo de aplicaciones Web posee determinadas características que lo hacen diferente del

desarrollo de aplicaciones o software tradicional y sistemas de información. La ingeniería de la

Web es multidisciplinar (Mallea, 2009).

31
2.2.3.1 WEB Modeling Language (WEBML)

Con la introducción del Internet y de la Web en concreto, se han abierto infinidad de

posibilidades en cuanto al acceso y uso de información desde cualquier parte del mundo. Con los

avances en tecnología, cada vez se demandan aplicaciones más rápidas, ligeras y robustas que

permitan ser usadas sin importar ni el lugar, ni el horario. Las aplicaciones Web tienen varias

ventajas sobre los programas de software tradicionales, como la compatibilidad multiplataforma y

el acceso concurrente de múltiples usuarios. WebML es un lenguaje de especificación de alto nivel,

para diseñar aplicaciones Web que usan datos intensivos, que además cubre aspectos avanzados

de modelado de sitios Web, incluyendo presentación, modelado de usuarios y personalización

(Carmona, 2008).

WebML es una notación para especificar complejos sitios Web en el ámbito conceptual (Ceri,

2002), que permite apoyar las actividades del diseño de estos, a partir de su descripción desde

distintos puntos de vista como son el conceptual, el navegacional y el de presentación, entre otros

(Gonzáles, Reyes y Vásquez, 2009).

2.2.3.2 Objetivos De WEBML

Según Barraza (2010) los objetivos principales de WebML son:

• Expresar la estructura de una aplicación

• Proveer múltiples vistas del mismo contenido

• Separar el contenido de la información de su composición en páginas, y navegación

• Almacenar meta-información

32
 • Modelar usuarios y comunidades

• Posibilitar la especificación de operaciones de manipulación de datos

2.2.3.3 Diseño en WEBML

De acuerdo a Barraza (2010) el diseño de aplicaciones en WebML consiste en especificar sus

características en términos de varios tipos de abstracciones ortogonales.

Cada una capturada mediante un modelo distinto los cuáles (Barraza, 2010) son:

- El modelo estructural

- El modelo e hipertexto

- Modelo de presentación

Figura 2.5 Componentes de un Sitio Web con Webml

Fuente: Silvera, Figueroa, Gil, Diaz, Villanueva, Gonzales, Gil y Chauque, 2015

33
2.2.3.3.1 Modelado Estructural

Cuando se trabaja con WebML el proceso de desarrollo comienza con la descripción conceptual

del sistema, en la cual, utilizando herramientas CASE para modelado, como UML, DIA, Enterprise

Architec, se representa la estructura estática del sistema, mediante la definición de entidades o

contenedores de datos y sus relaciones.

Una característica a destacar de WebML es que no exige ninguna herramienta específica para

hacer este modelo (Gonzáles, Reyes y Vásquez, 2009).

El elemento fundamental del modelo de estructura son las entidades (contenedores de datos) y

las relaciones (conectores de entidades), las entidades deben tener atributos con un tipo asociado

y las relaciones deben tener una cardinalidad y un rol asociado. En la imagen se muestra un ejemplo

de un diagrama de estructura, el cual consiste de cuatro entidades Artist, Album, Review, Track y

tres relaciones Artist2Album, Artist2Review, Album2track (Carmona, 2008).

Figura 2.6 Diagrama de Estructura

Fuente: Carmona, 2008

34
2.2.3.3.2 Modelado de Hipertexto

El modelo de hipertexto que posibilita la definición de páginas y enlaces de hipertexto que

constituyen la aplicación.

Este utiliza, a su vez, dos sub modelos (Barraza, 2010):

- El modelo de composición

- El modelo de navegación

Figura 2.7 WebML: Hipertextos

Fuerte: Barraza,2010

a) Modelo de composición

El propósito del diagrama de composición es definir los nodos que forman parte del

hipertexto contenido en el sitio Web, es decir, se especifican las páginas y las unidades

(elementos atómicos de información que deben aparecer en el sitio Web) que componen

el sitio Web (Carmona, 2008).

Según Carmona (2008) WebML soporta seis tipos de unidades que pueden ser usadas

para componer hipertexto:

35
Unidades de Datos: Muestran información sobre un solo objeto, son definidas para

seleccionar una mezcla de información. Para definir una unidad de datos se requiere la

indicación del concepto al cual se refiere la unidad y la selección de los atributos de la

unidad.

Unidad Multidatos: Muestra información sobre un conjunto de objetos, presenta

múltiples instancias de una entidad o componente. Una unidad multidatos tiene dos

partes: el contenedor que incluye las instancias que se desean mostrar y la unidad de

datos usada para la presentación de cada instancia.

Unidad Índice: presenta múltiples instancias de una unidad o componente como una

lista, esta unidad tiene dos partes principales: el contenedor que incluye las instancias

que se desean mostrar (las instancias deben ser una entidad, una relación o un

componente) y los atributos usados como clave del índice.

Unidad Scroller: provee comandos para desplazarse a través de los objetos en un

contenedor. Esta unidad es normalmente usada junto con una unidad de datos, la cual

representa el elemento actual visualizado del contenedor.

Unidad Filtro: provee campos de entrada para buscar los objetos en un contenedor, esta

unidad es normalmente usada junto con una unidad índice o multidatos, la cual muestra

los objetos que coinciden con las condiciones de búsqueda.

Unidad Directa: Expresa un tipo particular de índice, el cual contiene un solo objeto

asociado a otro objeto por una relación uno a uno.

36
 Figura 2.8 Unidades de Contenido
Fuente: Web Modeling Language, 2017

Una página es una abstracción de una región independiente de la pantalla, la cual es tratada

como un bloque de interfaz independiente. Las páginas deben ser internamente organizadas en

unidades y/o recursivamente en páginas, para este último las subpáginas de la página contenedora

son tratadas como bloques de presentación independientes, hay dos formas de visualizar las

subpáginas: conjuntas (se muestran las subpáginas al mismo tiempo) o disjuntas (unas páginas se

muestran como alternativas de otras) (Carmona, 2008)

b) Modelado de navegación

El propósito del diagrama de navegación es especificar la forma en la cual las unidades

y las páginas son conectadas para formar un hipertexto, para esto WebML provee la

noción de enlaces, de los cuales hay dos tipos (Carmona, 2008):

Enlaces contextuales: conectan unidades de una forma coherente a la semántica

expresada por el diagrama de estructura de la aplicación. Un enlace contextual lleva

información (de contexto) de la unidad de origen a la unidad destino, esta información

es usada para determinar el objeto o conjunto de objetos a ser mostrados en la unidad

destino.

37
 Enlaces no contextuales: conectan páginas libremente, independientemente del

contexto

Figura 2.9 Modelado de Navegación

Fuente: Ceri, 2000

A pesar que WebML se creó inicialmente para el diseño de aplicaciones Web intensivas en

datos, esta es, sin duda, una de las metodologías que más esfuerzos de adaptación ha realizado en

la necesidad de dar soporte al desarrollo de aplicaciones orientadas a servicios. WebML ha sido

extendido, para dar soporte al desarrollo de aplicaciones que integran, tantos servicios Web,

definiendo nuevas primitivas para la representación de estos en el modelo de hipertexto, como

también procesos de negocios, añadiendo para ello una nueva etapa de análisis de los procesos y

extendiendo el modelo estructural y de hipertexto para la captura de procesos. (Brambilla y

Butti,2006)

- Elementos del modelo de hipertexto

En la Figura 2.10 muestra la representación gráficas y descripción de los elementos de

hipertexto el cual sirve al modelado del sistema además que permite al arquitecto de

información el especificar cómo las unidades, definidas sobre objetos de datos, son

38
compuestas dentro de las páginas. Para este proyecto se utilizaron las necesarias según

el módulo y los requerimientos que se tienen para el sistema.

39
Figura 2.10 Descripción y Elementos del modelado de Hipertexto
Fuente: Barraza, 2010

40
 c) Modelo de presentación

En esta fase se define claramente la apariencia gráfica de cada una de las páginas que

conformarán el proyecto. WebML no incluye un modelo específico para establecer la

presentación a nivel conceptual (Gonzáles, Reyes y Vásquez, 2009).

2.3 Inventario

Inventario se refiere a las existencias de un artículo o determinado recurso que está almacenado

y que espera ser usado por la organización. Un sistema de inventario es el conjunto de políticas y

controles que supervisa los niveles de inventario y determina cuáles son los niveles que deben

mantenerse, cuando hay que reabastecer el inventario y de qué tamaño deben ser los pedidos

(Mongua y Sandoval, 2009).

La necesidad de establecer un programa de entrega de materiales para evitar situaciones de

inactividad que repercutan negativamente en los costos de los factores productivos, hace preciso

realizar una discriminación de artículos con el fin de determinar de entre todos ellos cuáles son los

que, por sus características, precisan un control más riguroso. El inventario en una empresa son

las existencias que se destinan a la venta directa o destinada indirectamente al proceso productivo.

Los inventarios pueden8 ser definidos, como una provisión de materiales, con el objetivo de

facilitar la comunidad del proceso productivo y la facilitación de los pedidos de consumidores y

clientes, estos se representan en cualquier organización (Hernández, 2010).

En el ámbito comercial, el inventario se representa en un esquema de ventas donde se registran

las operaciones que se producen desde que el cliente efectúa un pedido a las instalaciones hasta

que se realiza su entrega. (Mongua y Sandoval, 2009).

41
2.3.1 Tipos de inventarios

Existen diferentes tipos de inventarios que se pueden realizar en un determinado tiempo y en

una determinada ocasión.

• Inventarios finales: Se realizan cada vez que se cierra el periodo fiscal, habitualmente

el 31 de diciembre.

• Inventarios periódicos: Se realizan cada determinado tiempo dentro de una empresa.

• Inventarios iniciales: Se registran todos los bienes de la empresa; solo se documenta

los bienes existentes en el o en los días de elaboración. Por lo general se elaboran al

inicio del periodo contable, que suele ser el 1 de enero.

• Inventarios de productos en proceso de fabricación: Incluyen los bienes que ha

adquirido una empresa de tipo manufacturera o industrial y están en proceso aún de

manufactura; se cuantifican a través de la cantidad de materiales, de la mano de obra o

de los gastos de fabricación, aplicables a la fecha de cierre.

• Inventarios de materias primas: Incluyen los materiales que se requieren para la

elaboración de los productos y que aún no se han procesado de ninguna manera.

2.3.2 Sistema de Control de Inventario

Mora (2011) describe la importancia de implementar una correcta gestión de inventarios, la

misma se encuentra: en la utilidad que reportan las existencias en almacén, referida a la cantidad

de artículos necesarios para cubrir la demanda, ser oportunos teniendo los artículos en el tiempo y

lugar deseado, garantizar la calidad del producto y ofrecer el mejor precio. Si las empresas, no

42
llevan sus inventarios de la manera correcta pueden tener contratiempos en sus actividades

comerciales, ya que, al no estar abastecidos de los productos o insumos necesarios no podrán cubrir

la demanda del mercado, o en caso contrario, al mantener existencias por encima de lo requerido,

se origina la merma de la mercancía que se encuentre en stock.

Cada vez son más las empresas, así como diversas instituciones que dedican esfuerzos a

conseguir un buen sistema de información de Control de Inventarios para la cadena de suministro.

Por lo tanto, para lograr un control efectivo de los inventarios es necesario una buena coordinación

y una cooperación entre los elementos del sistema (Sánchez, Vargas, Reyez y Vidal, 2011).

2.3.3 Método primero en entrar primero en salir (PEPS)

Este método identificado también como “PEPS”, se basa en el supuesto de que los primeros

artículos en entrar al almacén son los primeros en salir de él. Se ha considerado conveniente este

método, porque da lugar a una evaluación del inventario concordado con la tendencia de los

precios; puesto que se presupone que el inventario está integrado por las compras más recientes y

esta valorizado a los costos también más recientes, la valorización sigue entonces la tendencia del

mercado. Método PEPS, tipo de inventario perpetuo que detalla por medio de la tarjeta de control

de inventario, las salidas y entradas de las mercancías. Establece que la primera mercancía que se

compra es l primera en venderse o salir.

En tales condiciones, el costo está absorbiendo materiales a precio más reciente, que son los

más bajos. El objetivo final de esta técnica es que las utilidades sean más conservadoras.

43
 En cuanto se agota el producto más antiguo, con su correspondiente costo de adquisición. En

inventario tiende a quedar valorado al costo de adquisición más reciente. Considerada que la

primera unidad adquirida, son las primeras surtidas al ser vendidas. La existencia en el inventario

corresponde a las compras más recientes.

Diferencias entre los métodos de inventarios:

Tabla 2.5 Métodos de Inventarios

Este método tiene como base que la última existencia
Últimos en entrar, primeros en
en entrar es la primera en salir. Esto es que los últimos
salir (UEPS)
productos adquiridos son los primeros que se venden.
Aplicándolo a las mercaderías, significa que las
existencias que primero entran al inventario son las
Primero en entrar, primero en
que primero salen del mismo, esto quiere decir que las
Salir (PEPS)
primeras que se compran son las primeras que se
venden.
Este método consiste en hallar el costo promedio de
cada uno de los artículos que hay en el inventario final,
Precio Promedio Ponderado
cuando las unidades son idénticas en apariencia, pero
(P.P.P)
no en el precio de adquisición por cuanto se han
comprado distintas épocas y a diferentes precios.
Fuente: Métodos, técnicas y sistemas de evaluación de inventarios un enfoque global, 2015

2.3.4 Ventas

Tiene múltiples definiciones dependiendo del contexto en el que se maneje. La venta es el

intercambio de servicios y productos. Es a su vez entendida como un contrato donde el sujeto que

actúa como vendedor transmite un derecho, bienes o servicios al comprador a cambio de una

determinada suma de dinero. La venta puede ser tanto un proceso personal como impersonal donde

el comprador puede ser influido por el vendedor. Desde el punto de vista contable y financiero, la

44
venta es el montón total cobrado por productos o servicios prestados. En cualquier situación, las

ventas son el corazón de cualquier negocio y actividad fundamental (Arana, 2014).

2.4 Tecnologías de software

2.4.1 Laravel

(Pitt, Otwell, & Ufano) Afirma que Laravel es un framework de código abierto para desarrollar

aplicaciones y servicios web con PHP 5. Su objetivo es desarrollar aplicaciones con código PHP

de forma elegante y simple. Fue creado en 2011 y tiene una gran influencia de frameworks como

Ruby on Rails, Sinatra y ASP.NET MVC.

Laravel es un framework joven con gran futuro. Cuenta con una comunidad llena de energía,

documentación atractiva de contenido claro y completo; y, además, ofrece las funcionalidades

necesarias para desarrollar aplicaciones modernas de manera fácil y segura. Está equipado con un

montón de características interesantes, incluyendo enrutamiento RESTful, PHP nativo o atractivo

motor ligero y muchos más. Construido con varios componentes de Symfony, Laravel ofrece a las

aplicaciones web una increíble base de código confiable y bien probado.

Figura 2.11 Logo Laravel

Fuente: Desarrolladores web,2011

45
2.4.2 PostgreSQL

Es un gestor de base de datos relacional, libre y de código abierto (RDBMS) haciendo hincapié

en la extensibilidad y el cumplimiento SQL. Presenta transacciones de atomicidad, consistencia,

aislamiento, durabilidad (ACID), vistas actualizables automáticamente, vistas materializadas,

disparadores, claves externas y procedimientos almacenados. Está diseñado para manejar una

variedad de cargas de trabajo, desde maquinas individuales hasta almacenes de datos o servicios

web con muchos usuarios concurrentes.

Figura 2.12 Logo PostgreSQL

Fuente: EnterpriseDB,2013

2.4.3 PHP

(Heurtel, 2013) Afirma que PHP (acrónimo recursivo de PHP: Hypertext Preprocessor) es un

lenguaje de código abierto muy popular especialmente adecuado para el desarrollo web y que

puede ser incrustado en HTML. En lugar de usar muchos comandos para mostrar HTML (como

en C o en Perl), las páginas de PHP contienen HTML con código incrustado.

Lo que distingue a PHP de algo del lado del cliente como Javascript es que el código es

ejecutado en el servidor, generando HTML y enviándolo al cliente. El cliente recibirá el resultado

de ejecutar el script, aunque no se sabrá el código subyacente que era. El servidor web puede ser

46
configurado incluso para que procese todos los ficheros HTML con PHP, por lo que no hay manera

de que los usuarios puedan saber qué se tiene debajo de la manga. Lo mejor de utilizar PHP es su

extrema simplicidad para el principiante, pero a su vez ofrece muchas características avanzadas

para los programadores profesionales. No sienta miedo de leer la larga lista de características de

PHP. En unas pocas horas podrá empezar a escribir sus primeros scripts.

(Heurtel, 2013) afirma que, aunque el desarrollo de PHP está centrado en la programación de

scripts del lado del servidor, se puede utilizar para muchas otras cosas.

Figura 2.13 Logo PHP

Fuente: Wikipedia, 2005

2.4.4 Bootstrap

Biblioteca multiplataforma o conjunto de herramientas de código abierto para diseño de sitios

y aplicaciones web. Contiene plantillas de diseño con tipografía, formularios, botones, cuadros,

menús de navegación y otros elementos de diseño basado en HTML y CSS, así como extensiones

de JavaScript adicionales. A diferencia de muchos frameworks web, solo se ocupa del

desarrollo front-end. Bootstrap tiene un soporte relativamente incompleto para HTML5 Y CSS3,

pero es compatible con la mayoría de los navegadores web. La información básica de

compatibilidad de sitios web o aplicaciones está disponible para todos los dispositivos y

navegadores. Existe un concepto de compatibilidad parcial que hace disponible la información

47
básica de un sitio web para todos los dispositivos y navegadores. Por ejemplo, las propiedades

introducidas en CSS3 para las esquinas redondeadas, gradientes y sombras son usadas por

Bootstrap a pesar de la falta de soporte de navegadores antiguos. Esto extiende la funcionalidad

de la herramienta, pero no es requerida para su uso. Desde la versión 2.0 también soporta diseños

web adaptables. Esto significa que el diseño gráfico de la página se ajusta dinámicamente, tomando

en cuenta las características del dispositivo usado (Computadoras, tabletas, teléfonos móviles).

Figura 2.14 Logo Bootstrap

Fuente: Bootstrap,2010

2.4.5 Vue.js

Es un framework progresivo para construir interfaces de usuario. A diferencia de otros

frameworks monolíticos, Vue.js está diseñado desde cero para ser adoptable de forma incremental.

La biblioteca principal se centra solo en la capa de vista y es fácil de recoger e integrar con otras

bibliotecas o proyectos existentes. Por otro lado, Vue.js también es perfectamente capaz de

impulsar aplicaciones sofisticadas de una sola página cuando se usa en combinación con

herramientas modernas y bibliotecas de soporte.

Descripción: Vue.js cuenta con una arquitectura de adaptación gradual que se centra en la

representación declarativa y la composición de componentes. La biblioteca central se centra sólo

en la capa de vista. Las características avanzadas necesarias para aplicaciones complejas como el

48
enrutamiento, la gestión de estados y las herramientas de construcción se ofrecen a través de

librerías y paquetes de poyo mantenidos oficialmente, con Nuxt.js como una de las soluciones más

populares. Vue.js permite extender el HTML con atributos HTML llamados directivas. Las

directivas ofrecen funcionalidad a las aplicaciones HTML, y vienen como directivas.

Figura 2.15 Logo Vue.js

Fuente: Vue.jss, 2013

2.5 Métricas o calidad de software

2.5.1 Calidad de Software

La calidad de software es la concordancia con los requisitos funcionales y de rendimiento

explícitamente establecidos, con los estándares de desarrollo explícitamente documentados, y con

las características implícitas que se espera de todo software desarrollado profesionalmente.

(Pressman, 2005).

2.5.2 Métricas de calidad

En Ingeniería de Software una medida suele proporcionar una indicación cualitativa de la

extensión, la calidad, la dimensión, la capacidad o el tamaño de algún atributo de un producto o

procesos, la medición es el acto de determinar una medida.

49
 Métrica se define como una medida cuantitativa del grado en que un sistema, componente o

proceso posee un atributo determinado. En Ingeniería de Software se recopila medidas y se

desarrolla métricas para obtener los indicadores, los mismos que proporcionan conocimientos para

mejorar los procesos, el proyecto o el producto. (Pressman, 2005).

2.5.2.1 Normas ISO/IEC 9126

Hablar de calidad de software implica la necesidad de contar con parámetros que permitan

establecer los niveles mínimos que un producto de este tipo debe alcanzar para que se considere

de calidad.

ISO 9126 es un estándar internacional para la evaluación del Software, fue originalmente

desarrollado en 1991 para proporcionar un esquema para la evaluación de calidad del software. La

normativa define seis características de la aplicación, estas seis características son dividas en un

Número de sub-características, las cuales representan un modelo detallado para la evaluación de

cualquier sistema informático. (Pressman, 2005).

Figura 2.16 Modelo de evaluación ISO 9126

Fuente: Timetoast, 2005

50
• Usabilidad: La capacidad del producto software para ser entendido, aprendido, usado

y ser atractivo para el usuario, cuando se una bajo condiciones específicas.

a) Capacidad para ser entendido: La capacidad del producto software que permite

al usuario entender si el software es adecuado y como ser usado para unas tareas

o condiciones de uso particular.

b) Capacidad para ser aprendido: La capacidad del producto software que permite

al usuario aprender sobre su aplicación.

c) Capacidad para ser operado

• Funcionalidad: La capacidad del producto software para proporcionar funciones

declaradas e implícitas cuando se usa bajo condiciones especificadas.

a) Adecuación

b) Exactitud

c) Interoperabilidad

d) Seguridad de acceso

• Fiabilidad: La capacidad del producto software para mantener un nivel especificado de

prestaciones cuando se usa bajo condiciones especificadas.

a) Madurez

b) Capacidad de atracción

c) Cumplimiento de la usabilidad

• Eficiencia: La capacidad del producto software para proporcionar prestaciones

apropiadas, relativas a la cantidad de recursos usados, bajo condiciones determinadas.

a) Comportamiento temporal

51
 b) Utilización de recursos

c) Cumplimiento de la eficiencia

• Mantenibilidad: La capacidad del producto software para ser modificado.

Las modificaciones podrían incluir correcciones, mejoras o adaptación del software a

cambios en el entorno, y requisitos y especificaciones funcionales.

a) Capacidad para ser analizado

b) Capacidad para ser cambiado

c) Estabilidad

d) Capacidad para ser probado

e) Cumplimiento de la Mantenibilidad

• Portabilidad: La capacidad del producto software para ser transferido de un entorno a

otro.

a) Adaptabilidad: La capacidad del producto software para ser adaptado a

diferentes entornos especificados, sin aplicar acciones o mecanismos distintos

de aquellos proporcionados para ese propósito por software considerado.

b) Instalabilidad: La capacidad del producto software para instalado en un entorno

especificado.

c) Coexistencia: La capacidad del producto software para coexistir con otro

software independiente, en un entorno común, compartiendo recursos comunes.

d) Capacidad para reemplazar: La capacidad del producto software para ser usado

en lugar de otro producto software, para el mismo propósito, en el mismo

entorno.

52
 e) Cumplimiento de la portabilidad: La capacidad del producto software para

adherirse a normas o conversaciones relacionadas con la portabilidad.

2.5.2.2 Metodología de evaluación de calidad

El enfoque propuesto por Olsina, es esencialmente integral, flexible y robusto, y cubre la mayor

parte de las actividades en el proceso de evaluación, comparación y selección de artefactos Web.

(Olsina, 98).

La estrategia propuesta, denominada Metodología de Evaluación de calidad de Sitios Web (o,

en inglés, Web-site Quality Evaluation Method, o, metodología Web-site QEM), pretende

proponer un enfoque sistemático, disciplinado y cuantitativo que se ajuste a la evaluación,

comparación y análisis de calidad de los sistemas de información centrados en la Web. Web-site

QEM, incluye un conjunto de fases, actividades, productos, modelos y constructores de procesos

que intervienen en el proceso de evaluación, comparación y ordenamiento de calidad. Una de las

metas principales en la metodología, es comprender el grado de cumplimiento de un conjunto de

características con respecto a los requerimientos establecidos. De este modo, otro aporte

interesante consiste en la definición de características, sub-características y atributos cuantificables

considerando dominios de aplicaciones Web particulares. (Rossi, 1999).

2.6 Estudio de costos y beneficio

2.6.1 Modelo de estimación de proyectos de Software COCOMO

En el año 1981 Barry Boehm pública el modelo COCOMO, acorde a las prácticas de desarrollo

de software de aquel momento. (Boehm, 1981).

53
 Barry Boehm detalla un modelo amplio de estimación de costos llamado COCOMO

(Constructive Cost Model). La palabra “constructive” se refiere al hecho que el modelo ayuda a

un estimador a comprender mejor la complejidad del software; este modelo es un ejemplo de

variable simple estático y es usado por miles de administradores de proyecto de software.

COCOMO ayuda a estimar el esfuerzo, tiempo, gente y costos (ya sea estos de desarrollo,

equipamiento y mantenimiento). El modelo provee tres “niveles” de aplicación: básico, intermedio

y avanzado, basados en los factores considerados por el modelo.

2.6.1.1 Modelo Básico

Este modelo hace sus previsiones en función del tamaño del proyecto médico en miles de líneas

de código (KSLOC). Estas estimaciones de esfuerzo calculadas, se representas en Personas – Mes

(PM), considerando 152 horas de trabajo mensuales, y 19 días de trabajo por mes.

Figura 2.17 COCOMO Básico

Fuente: Cwel, 2006
2.6.1.2 Modelo intermedio

El modelo intermedio y el detallado, usan un factor de ajuste del esfuerzo (EAF), y los

coeficientes de las ecuaciones de esfuerzo varían notoriamente con respecto a los del modelo

básico, permaneciendo el cálculo del tiempo sin cambios.

54
 Figura 2.18 COCOMO Intermedio
Fuente: Cwel, 2006

Este modelo obtiene unos mejores resultados, en gran parte debido al establecimiento de 15

factores de costo, que determinan la duración y el costo del proyecto. En la Figura 2.19 se puede

apreciar los diferentes factores de costo establecidos en COCOMO.

Figura 2.19 Factores de costo en COCOMO Básico

Fuente: Cwel, 2006

55
 El factor de ajuste del esfuerzo (EAF), se calcula multiplicando los correspondientes factores

asociados a cada variable de costo. Otro de los motivos que justifica que el modelo intermedio

obtenga mejores resultados que el básico es la posibilidad de poder dividir el sistema en

componentes. Esto implica que valores como SLOC o los factores de costo puedan ser escogidos

en función de determinadas partes del sistema, no considerándolo como un todo. De esta manera

se pueden hacer estimaciones sobre el personal, el costo y la duración de cada componente,

permitiéndose así elaborar distintas estrategias de desarrollo.

2.6.1.3 Modelo detallado

La única diferencia existente entre el modelo intermedio y el detallado, es que este último utiliza

diferentes multiplicadores del esfuerzo para cada fase del proyecto. Las seis fases que define

COCOMO son: requerimientos, diseño del producto, diseño detallado, codificación y pruebas de

unidad, integración y test y por último mantenimiento. Las fases comprendidas entre el diseño del

producto y la integración y test son llamadas fases de desarrollo.

2.7 Seguridad

La seguridad del software es una actividad que garantiza la calidad del software, se centra en la

identificación y evaluación de riesgos potenciales y los mismos pueden llegar a producir impactos

negativos en el sistema. Hacer consideraciones de seguridad significa ponerse a pensar como el

agresor trata de encontrar el diagrama de vulnerabilidades y buscar mecanismos que puedan

solucionar estas vulnerabilidades. Algunas de estas pueden ser:

✓ Inyección SQL

56
 ✓ Script entre sitios

✓ Modificación de ingreso

✓ Reemplazo de identidad

✓ Ataques XSS

A la hora de desarrollar un sistema de información hay que tomar en cuenta dos aspectos

importantes con relación a su seguridad, y esta es la física y la otra es la lógica. A continuación,

se hará una descripción de las mismas.

2.7.1 Seguridad Física

La seguridad física de los sistemas informáticos consiste en la aplicación de barreras físicas y

procedimientos de control como medidas de prevención y contramedidas contra las amenazas a

los recursos y la información confidencial de la Institución. La posibilidad de acceder físicamente

a una computadora, en general a cualquier sistema operativo hace inútiles casi todas las medidas

de seguridad que haya aplicado sobre él. Es necesario garantizar la seguridad global de la red y los

sistemas conectados a ella, evidentemente el nivel de seguridad física depende completamente del

entorno donde se ubiquen los puntos a proteger. Pero ¿Cómo hacerlo? ¿Cómo prevenir un acceso

físico no autorizado a un determinado punto? hay soluciones de diferente tipo desde la instalación

de videocámaras, pasando por tarjetas inteligentes o control con las llaves que abren determinada

puerta, así también los biométricos, los más recomendados estos últimos.

Cuando la prevención es difícil por cualquier motivo (técnico, económico, humano, etc.) es

deseable que un potencial ataque sea detectado cuanto antes, para minimizar así sus efectos, para

ello, es importante concienciar a todo el personal su papel en la política de seguridad del entorno,

57
si por ejemplo un usuario autorizado detecta presencia de alguien de quien sospecha que no tiene

autorización para estar en una determinada estancia debe avisar inmediatamente al administrador

o al responsable de los equipos, que a su vez puedan avisar al servicio de seguridad si es necesario

(Hernández,2007).

2.7.2 Seguridad Lógica

Hernández (2007) sostiene que la seguridad lógica consiste en la aplicación de barreras y

procedimientos que resguarden el acceso a los datos y solo se permita acceder a ellos a las personas

autorizadas para ello.

2.7.2.1 Seguridad a nivel Sistema Operativo

Entre las medidas que se deben tomar a nivel del sistema operativo son:

• Restringir el acceso al arranque (desde el BIOS) al S.O. los programas y archivos.

• Otorgar a los usuarios permisos de solo lectura para los directorios necesarios.

• Denegar el acceso de forma predeterminada.

• Proteger el archivo de configuración de registro.

• Asegurarse de que los servicios son actuales comprobando con frecuencia si hay

actualizaciones de seguridad.

• Reducir el nivel de permisos de acceso para los servicios de red.

2.7.2.2 Seguridad a nivel Gestión de Base de Datos

A continuación, se describen las medidas de seguridad a tomar en cuenta para la base de datos.

58
 • Restringir los permisos a los usuarios.

• Cambiar el usuario root.

• Eliminar la cuenta de prueba y la base de datos de prueba.

• Revisar periódicamente los usuarios y la base de datos para asegurar que tienen los

permisos otorgados en su momento

2.7.2.3 Seguridad a nivel de Aplicación

Entre las medidas que se tomarán a nivel de aplicación están.

• Asignación de roles de usuario.

• Encriptación de las contraseñas de usuario.

• Asignación de privilegios.

• Generación de un log de sucesos.

• Asegurarse que esté deshabilitada la función de autocompletado en el navegador.

2.7.3 Recomendaciones OWASP

El Open Web Application Security Project (OWASP) es un espacio abierto de la comunidad

dedicada a la búsqueda y la lucha contra las causas del software inseguro. Todas las herramientas,

documentos y los capítulos de OWASP son gratuitos y abiertos. (Wiesmann, Curphey, Stock y

Stirbei, 2017).

Así también estos autores mencionan que OWASP es un nuevo tipo de entidad en el mercado

de la seguridad. “Nuestra libertad de las presiones comerciales nos permite brindar información

59
imparcial, práctica y rentable sobre seguridad de las aplicaciones”, no está afiliado con ninguna

compañía de tecnología, sin embargo, apoya la utilización de tecnología de seguridad.

Las aplicaciones seguras no se dan por sí mismas – son en cambio el resultado de una

organización decidiendo que va a producir aplicaciones seguras. OWASP no desea forzar un

enfoque particular o requerir a la organización el cumplimiento de leyes que no la afectan – cada

organización es diferente. Sin embargo, a los fines de obtener una aplicación segura, se requiere

como mínimo: Una gestión organizacional que abogue por la seguridad políticas de seguridad

documentadas y apropiadamente basadas en estándares nacionales. Una metodología de desarrollo

con adecuados puntos de control y actividades de seguridad Gestión segura de versiones y

configuración. Muchos de los controles contenidos en la Guía OWASP se encuentran

influenciados por requerimientos incluidos en estándares nacionales o marcos de control tales

como ISO; normalmente los controles seleccionados de la guía satisfacen los requerimientos

relevantes de ISO 27001 o ISO 31000 (Wiesmann, Curphey, Stock y Stirbei, 2017).

2.7.3.1 Riesgos en la Seguridad de las Aplicaciones

Los atacantes pueden, potencialmente, utilizar diferentes rutas a través de su aplicación para

perjudicar su negocio u organización. Cada uno de estos caminos representa un riesgo que puede

o no ser suficientemente grave como para merecer atención. En la Figura 2.20 se muestran estas

posibles amenazas.

60
 Figura 2.20 Riesgos en la Seguridad de las Aplicaciones
Fuente: (Wiesmann, Curphey, Stock y Stirbei, 2017)

Algunas veces, estos caminos son fáciles de encontrar y explotar, mientras que otras son

extremadamente difíciles. De la misma manera, el perjuicio ocasionado puede no tener

consecuencias, o puede dejarlo en la quiebra. A fin de determinar el riesgo para su organización,

puede evaluar la probabilidad asociada a cada agente de amenaza, vector de ataque, debilidad de

seguridad y combinarlo con una estimación del impacto técnico y de negocio, juntos, estos factores

determinan su riesgo general, como se puede observar en la Figura 2.21.

Figura 2.21 Factores que Determinan el Riesgo de Amenazas

Fuente: (Wiesmann, Curphey, Stock y Stirbei, 2017)

A continuación, se describen los riesgos en la seguridad de las aplicaciones (Top 10)

(Wiesmann, Curphey, Stock y Stirbei, 2017).

• A1: 2017 (Inyección) Las fallas de inyección, como SQL, NoSQL, OS o LDAP ocurren

cuando se envían datos no confiables a un intérprete, como parte de un comando o

consulta. Los datos dañinos del atacante pueden engañar al intérprete para que ejecute

comandos involuntarios o acceda a los datos sin la debida autorización.

61
• A2: 2017 (Pérdida de Autenticación) Las funciones de la aplicación relacionadas a la

autenticación y gestión de sesiones son implementadas incorrectamente, permitiendo a

los atacantes comprometer usuarios y contraseñas, token de sesiones, o explotar otras

fallas de implementación para asumir la identidad de otros usuarios (temporal o

permanentemente).

• A3: 201 (Exposición de Datos Sensibles) Muchas aplicaciones web y APIs no protegen

adecuadamente datos sensibles, tales como información financiera, de salud o

información personalmente identificable (PII). Los atacantes pueden robar o modificar

estos datos protegidos inadecuadamente para llevar a cabo fraudes con tarjeta de crédito,

robos de identidad u otros delitos. Los datos sensibles requieren métodos de protección

adicionales, como el cifrado en almacenamiento y tránsito.

• A4: 2017 (Entidades Externas XML (XXE)) Muchos procesadores XML antiguos o mal

configurados evalúan referencias a entidades externas en documentos XML. Las

entidades externas pueden utilizarse para revelar archivos internos mediante la URI o

archivos internos en servidores no actualizados, escanear puertos de la LAN, ejecutar

código de forma remota y realizar ataques de denegación de servicio (DoS).

• A5: 2017 (Pérdida de Control de Acceso) Las restricciones sobre lo que los usuarios

autenticados pueden hacer no se aplican correctamente. Los atacantes pueden explotar

estos defectos para acceder, de forma no autorizada, a funcionalidades y/o datos, cuentas

de otros usuarios, ver archivos sensibles, modificar datos, cambiar derechos de acceso

y permisos, etc.

62
• A6: 2017 (Configuración de Seguridad Incorrecta) La configuración de seguridad

incorrecta es un problema muy común y se debe en parte a establecer la configuración

de forma manual, ad hoc o por omisión (o directamente por la falta de configuración).

Son ejemplos, S3 buckets abiertos, cabeceras HTTP mal configuradas, mensajes de

error con contenido sensible, falta de parches y actualizaciones, frameworks,

dependencias y componentes desactualizados, etc.

• A7: 2017 (Secuencia de Comandos en Sitios Cruzados (XSS)) Los XSS ocurren cuando

una aplicación toma datos no confiables y los envía al navegador web sin una validación

y codificación apropiada, o actualiza una página web existente con datos suministrados

por el usuario utilizando una API que ejecuta JavaScript en el navegador. Permiten

ejecutar comandos en el navegador de la víctima y el atacante puede secuestrar una

sesión, modificar (defacement) los sitios web, o re direccionar al usuario hacia un sitio

malicioso.

• A8: 2017 (Deserialización Insegura) Estos defectos ocurren cuando una aplicación

recibe objetos serializados dañinos y estos objetos pueden ser manipulados o borrados

por el atacante para realizar ataques de repetición, inyecciones o elevar sus privilegios

de ejecución. En el peor de los casos, la deserialización insegura puede conducir a la

ejecución remota de código en el servidor.

• A9: 2017 (Componentes con Vulnerabilidades Conocidas) Los componentes como

bibliotecas, frameworks y otros módulos se ejecutan con los mismos privilegios que la

aplicación. Si se explota un componente vulnerable, el ataque puede provocar una

pérdida de datos o tomar el control del servidor. Las aplicaciones y API que utilizan

63
 componentes con vulnerabilidades conocidas pueden debilitar las defensas de las

aplicaciones y permitir diversos ataques e impactos.

• A10: 2017 (Registro y Monitoreo Insuficientes) El registro y monitoreo insuficiente,

junto a la fatal de respuesta ante incidentes permiten a los atacantes mantener el ataque

en el tiempo, pivotear a otros sistemas y manipular, extraer o destruir datos. Los estudios

muestran que el tiempo de detección de una brecha de seguridad es mayor a 200 días,

siendo típicamente detectado por terceros en lugar de por procesos internos.

En la Figura 2.22 se muestra un resumen de los factores de riesgo del top 10 que propone

OWASP.

Figura 2.22 Resumen de los factores de Riesgo del Top 10

Fuente: (Wiesmann, Curphey, Stock y Stirbei, 2017

64
CAPÍTULO III MARCO APLICATIVO

3.1 Introducción

En este capítulo se detalla la forma de organización y métodos de trabajo del sistema, se hará

uso de las metodologías y herramientas descritas anteriormente, las mismas que nos servirán para

el desarrollo del sistema y todos sus módulos.

Al comenzar con el desarrollo del sistema se observó que la comunicación con el equipo de

trabajo era muy importante, desde el cliente que forma parte del equipo haciendo conocer la forma

del trabajo actual, explicando paso a paso el procedimiento en el área de ventas y captar las

necesidades de los mismos.

Por estas razones se hará el uso de la metodología XP, donde claramente pone en comunicación

directa y continua a clientes y desarrolladores, este aspecto fue aplicado ya que se mantuvieron

reuniones frecuentes con el personal del cliente, quienes se integraron al proyecto para establecer

prioridades y resolver dudas. Dicha metodología fue elegida porque responde de manera favorable

a un ambiente de requerimientos dinámicamente cambiantes. Además, aborda los riesgos del

proyecto y las prácticas, están creadas para mitigar los riesgos y elevar las probabilidades de éxito.

El análisis de los requerimientos resultó un tanto moroso, debido a la ambigüedad con la que se

manejan varios aspectos como ser las peticiones del cliente. También influye la cantidad de

producto que compra un cliente, además depende del tipo de producto, quedando sujeto a la

categoría del producto.

65
 En el esquema que se muestra a continuación se ve como la metodología de desarrollo ágil

programación extrema XP, interactuara con el modelado web WebML. XP ayudará al desarrollo

del proyecto atreves de las iteraciones, donde cada iteración comprenderá las fases de

planificación, diseño, desarrollo y pruebas. Interactuando con la fase de diseño del modelo

WebML haciendo el uso de los modelos de datos, modelo de hipertexto y finalmente el modelo de

presentación.

Figura 3.1 Función de la Metodología XP y WebML

Fuente: Elaboración Propia

66
3.2 Fases de la metodología XP

3.2.1 Fase I – Planificación

En esta primera fase se mostrará la forma de actual mediante Historias de Usuarios, además de

los requerimientos de los sistemas Web, se definirán todas las tareas que serán necesarias para

poder desarrollar la aplicación esto mediante las Tarjetas de Tareas y por último se realizará el

Plan de Entregas que contendrá las iteraciones a realizar para el desarrollo del presente proyecto.

3.2.1.1 Clasificación e identificación de roles

Se deben identificar a todos los roles que van a interactuar con el sistema, y posteriormente se

los clasifica en clases y subclases de actores, de esta manera se organiza mejor el acceso a la

información del sistema y se tiene mejor control y seguimiento sobre los usuarios, evitando

confusiones sobre las funciones que debe ejecutar cada usuario.

Tabla 3.1 Identificación de roles

ROL DESCRIPCIÓN
Tiene acceso a todas opciones del sistema, configura
Administrador del
Administrador

parámetros del sistema, administra usuarios y realiza

Sistema
la asignación de los mismos.
Es la persona encargada de realizar el control y
Gerente seguimiento de la empresa. Tiene acceso a todos los
módulos.
Registra ventas, devuelve reportes de ventas, visualiza
Encargado de Ventas y
la disposición de productos, registra clientes, emite
Usuario del

operaciones
sistema

factura.
Encargado de registrar los productos, genera reportes
Encargado de Bodega de los inventarios, realiza la verificación de existencia
de productos.
Fuente: Elaboración propia

67
3.2.1.2 Obtención de requerimientos

Se plantea una clasificación de requerimientos en dos tipos: Los funcionales y los no

funcionales. Los requerimientos funcionales definen características sobre el funcionamiento del

sistema, es decir, describen las transformaciones que el sistema realiza sobre las entradas para

producir salidas. Por otro lado, se tienen los requerimientos no funcionales, los cuales determinan

características que puedan limitar el sistema (Sommerville, 2011).

A continuación, se muestra cada uno de los requerimientos que fueron descritos por el cliente

y los futuros usuarios del sistema:

3.2.1.2.1 Requerimientos funcionales

A. Módulo de administración del sistema

Todo sistema debe contar con un módulo donde el usuario pueda administrar los ajustes

básicos del sistema, como:

RA-1 Administrar usuarios: El sistema debe contar con este módulo, donde el usuario

pueda administrar los ajustes básicos del sistema, así como permitir la asignación de un

role a un usuario.

RA-2 Administrar roles: Encargado de limitar el acceso a los recursos del sistema, el

sistema debe permitir la administración de los roles.

RA-3 Administrar menús: El sistema debe permitir la administración de los menús,

pertenecientes a cada rol.

RA-4 Administrar personal de trabajo: Crear, listar, modificar y eliminar registros de

personal.

68
B. Módulo de inventarios

RB-1 Registrar información de productos nuevos parar la empresa: El administrador

debe registrar el ingreso de nuevos productos al sistema para la empresa.

RB-2 Administración de productos: Se debe contar con las opciones de agregar,

modificar y eliminar los productos.

RB-3 Relación directa del inventario con las ventas: En cada transacción de venta, al

realizar la aprobación de un pedido realizado por un cliente, el inventario debe

incrementar o disminuir en el ítem respectivo.

69
 RB-4 Administración de bodegas: Se debe contar con las opciones de agregar, listar,

modificar y eliminar registros de bodega.

RB-5 Administración de categorías: Se debe contar con las opciones de agregar,

modificar y eliminar registros de títulos, también llamados categorías.

C. Módulo de ventas

RC-1 Facturación: el sistema debe permitir realizar la factura correspondiente a la venta

realizada.

RC-2 Registro de ventas: Al realizar la respectiva factura, el sistema debe registrar la

venta.

RC-3 Registro de clientes: Al realizar la respectiva factura, el sistema debe registrar a

los clientes.

3.2.1.2.2 Requerimientos no funcionales

• La aplicación web estará desarrollada bajo el framework Laravel

• La aplicación web debe ser totalmente funcional en los equipos que posee el cliente.

• La aplicación web debe tener un entorno gráfico amigable al usuario, además de que el

usuario debe adaptarse fácilmente al uso del sistema.

70
3.2.1.3 Historias de Usuario y Tarjetas de Tarea

A partir del conjunto de especificaciones y requerimientos que se obtuvieron en las reuniones

llevadas a cabo con el cliente, sobre las funciones que el sistema debería realizar, se pudo construir

las historias de usuario que cuentan con prioridades, puntos, riesgos e iteraciones.

En esta fase también se hace uso de Tarjetas de Tarea, las cuales tienen el objetivo de definir

de forma clara y concreta las tareas a realizar para implementar una historia de usuario. Se hará un

análisis más profundo en las historias de usuario. De aquí en adelante se hará referencia al término

“ABM” que significa Altas, Bajas y Modificaciones, son el conjunto de funciones básicas que todo

módulo debería tener.

A continuación, se detallan las Historias de Usuario y Tarjetas de Tarea más importantes:

Historias de Usuario - Usuarios: La asignación, modificación y eliminación de usuarios por

el administrador del sistema es una tarea primordial para la empresa. La tabla que se muestra a

continuación (Ver tabla 3.2) es la historia de usuario de Usuarios:

71
 Tabla 3.2 Historia de Usuario 1- Usuarios
HISTORIA DE USUARIO
Número: 1 Usuario: Administrador del sistema
Nombre de Historia: Administración de usuarios
Puntos Estimados: 2 Prioridad de negocio: Alta
Iteración asignada: 1 Riesgo de desarrollo: Alto
Descripción: Se desarrollará el módulo de autenticación de usuario, el cual
permitirá el ingreso al sistema, usando un nombre de usuario y contraseña teniendo
en cuenta que cada uno cuenta con privilegios que restringen su actividad dentro
del sistema.
Fuente: Elaboración propia

La historia de usuario 1 contara con tareas que ayuden a crear el módulo de interfaz y la consulta

a la base de datos para tener acceso al menú principal

Tabla 3.3 Tarjeta de Tarea 1.1 de Historia de Usuario 1

TAREA
Número de tarea: 1.1 Número de Historia: 1
Nombre de Tarea: Desarrollo del módulo de introducción nombre de usuario y
contraseña del usuario
Tipo de Tarea: Desarrollo Puntos estimados: 1
Programador Responsable: Evelyn Angela Alanez Zenteno
Descripción: Se desarrolla un módulo el cual será la página principal antes de
poder utilizar el sistema esta contará con los campos que será usuario y la
contraseña.
Fuente: Elaboración propia

La Tarjeta de Tarea 1.1 (Ver tabla 3.3) Pertenece a la Historia de Usuario 1 en este se muestra

el desarrollo del módulo de autenticación, debe cumplir la función de permitir al personal el acceso

al sistema.

72
 Tabla 3.4 Tarjeta de Tarea 1.2 de Historia de Usuario 1
TAREA
Número de tarea: 1.2 Número de Historia: 1
Nombre de Tarea: Diseño de la interfaz de introducción nombre de usuario y
contraseña del usuario.
Tipo de Tarea: Diseño Puntos estimados: 2
Programador Responsable: Evelyn Angela Alanez Zenteno
Descripción: Se desarrolla una interfaz la cual será la página principal antes de
poder utilizar el sistema, esta contara con dos campos que serán usuario y la
contraseña.
Fuente: Elaboración propia

El diseño de la Tarjeta de Tarea 1.2 (Ver tabla 3.4) se elaborará con una interfaz de manera

sencilla para que el personal pueda ingresar, de esta misma manera el personal de trabajo podrá

ingresar y comenzar a usar a el sistema

Tabla 3.5 Tarjeta de Tarea 1.3 de Historia de Usuario 1

TAREA
Número de tarea:1.3 Número de Historia:1
Nombre de Tarea: Validación de datos introducidos
Tipo de Tarea: Validación Puntos estimados: 2
Programador Responsable: Evelyn Angela Alanez Zenteno
Descripción: Una vez registrada los campos se presionará el botón enviar para
ingresar al menú principal del sistema, en caso de haber ingresado algún dato que
no corresponda al usuario se mostrará un mensaje de “Usuario no Registrado”.
Fuente: Elaboración propia

En el módulo se restringe al acceso de usuario al sistema y se hace la creación de una consulta

a la base de datos para poder validar solo a usuarios registrados (Ver tabla 3.5).

73
 Historia de Usuario – Roles: La administración de roles para la empresa tiene una prioridad

alta para la empresa, debido a que, permitirá restringir las opciones de accesos según al rol

asignado a cada usuario. A continuación, se muestra la historia de usuario (Ver tabla 3.6):

Tabla 3.6 Historia de Usuario 2 - Roles

HISTORIA DE USUARIO
Número: 2 Usuario: Administrador del sistema
Nombre de Historia: Administración de roles
Puntos Estimados: 1 Prioridad de negocio: Alta
Iteración asignada: 1 Riesgo de desarrollo: Alto
Descripción: Se desarrollará el módulo de administración de roles, donde el
usuario podrá modificar el nombre del rol, el menú correspondiente; así también,
el sistema debe permitir la eliminación de un rol.
Fuente: Elaboración propia

La historia de usuario de administración de roles contará con tareas que ayuden a crear el

módulo de interfaz y consulta a la base de datos (Ver tabla 3.7), como se muestra a continuación:

Tabla 3.7 Tarjeta de Tarea 2.1 de Historia de Usuario 2

TAREA
Número de tarea: 2.1 Número de Historia: 2
Nombre de Tarea: Diseño de la interfaz de administración de roles
Tipo de Tarea: Diseño Puntos estimados: 2
Programador Responsable: Evelyn Angela Alanez Zenteno
Descripción: Se desarrolla una interfaz donde se observe el listado de los roles
existentes, así como las opciones de agregar, editar nombre, editar menú y eliminar.
Fuente: Elaboración propia

La Tarjeta de Tarea 2.2 (Ver tabla 3.8), pertenece a la historia de usuario 2, esta muestra las

tareas necesarias para el alta, baja y modificación de nombre y menú de los roles:

74
 Tabla 3.8 Tarjeta de Tarea 2.2 de Historia de Usuario 2
TAREA
Número de tarea: 2.2 Número de Historia: 2
Nombre de Tarea: ABM de roles
Tipo de Tarea: Desarrollo Puntos estimados: 3
Programador Responsable: Evelyn Angela Alanez Zenteno
Descripción: Crear las funciones para agregar, modificar, eliminar y listar los roles y
menús de cada rol existentes a nivel vista y controlador.
Fuente: Elaboración propia

Historia de Usuario – Menús: La administración del menú de los roles (Ver tabla 3.9), es una

tarea importante para la empresa debido a que, el sistema debe ser flexible para la modificación de

los mismos.

Tabla 3.9 Historia de Usuario 3 - Menús

HISTORIA DE USUARIO
Número: 3 Usuario: Administrador del sistema
Nombre de Historia: Administración de menús de menús
Puntos Estimados: 1 Prioridad de negocio: Alta
Iteración asignada: 1 Riesgo de desarrollo: Alto
Descripción: Se desarrollará el módulo de administración de roles, donde el
usuario podrá modificar el nombre del rol, el menú correspondiente; así también,
el sistema debe permitir la eliminación de un rol.
Fuente: Elaboración propia

A continuación, se muestran las tarjetas de tarea necesarias para la implementación de la historia

de usuario de administración de menús de roles:

75
 Tabla 3.10 Tarjeta de Tarea 3.1 de Historia de Usuario 3
TAREA
Número de tarea: 3.1 Número de Historia: 3
Nombre de Tarea: Diseño de la interfaz de administración de menús
Tipo de Tarea: Diseño Puntos estimados: 2
Programador Responsable: Evelyn Angela Alanez Zenteno
Descripción: Se desarrolla una interfaz para el desarrollo de administración de
menús de roles, los formularios que permitan agregar nuevos menús y editar, así
como la opción de eliminar. Además de la interfaz de listado.
Fuente: Elaboración propia

La Tarjeta de Tarea 3.1 (Ver tabla 3.10), pertenece a la historia de usuario 3, esta muestra las

tareas necesarias para el diseño de la interfaz del listado de menús.

Tabla 3.11 Tarjeta de Tarea 3.2 de Historia de Usuario 3

TAREA
Número de tarea: 3.2 Número de Historia: 3
Nombre de Tarea: ABM de menús
Tipo de Tarea: Desarrollo Puntos estimados: 3
Programador Responsable: Evelyn Angela Alanez Zenteno
Descripción: Crear las funciones para agregar, modificar, eliminar y listar menús
a nivel vista y controlador.
Fuente: Elaboración propia

La Tarjeta de Tarea 3.2 (Ver tabla 3.11), pertenece a la historia de usuario 3, esta muestra las

tareas necesarias para el desarrollo del listado de menús.

Historia de Usuario – Personal de trabajo: A continuación, se muestra a la tabla de la historia

de usuario de Personal

76
 Tabla 3.12 Historia de Usuario 4 – Personal de Trabajo
HISTORIA DE USUARIO
Número: 4 Usuario: Administrador del sistema
Nombre de Historia: Administración de personal de trabajo
Puntos Estimados: 1 Prioridad de negocio: Media
Iteración asignada: 1 Riesgo de desarrollo: Medio
Descripción: El sistema debe permitir la autentificación del personal con los
privilegios que le fueron asignados, así como, la modificación y eliminación de los
mismos.
Fuente: Elaboración propia

A continuación, se muestran las tarjetas de tarea necesarias para la implementación de la historia

de usuario de administración de personal de trabajo:

Tabla 3.13 Tarjeta de Tarea 4.1 de Historia de Usuario 4

TAREA
Número de tarea: 4.1 Número de Historia: 4
Nombre de Tarea: Diseño de la interfaz del módulo del personal de trabajo
Tipo de Tarea: Diseño Puntos estimados: 2
Programador Responsable: Evelyn Angela Alanez Zenteno
Descripción: Se creará un formulario que permita realizar el registro al empleado,
además de comprobar que estos datos son almacenados correctamente en la base de
datos.
Fuente: Elaboración propia

La Tarjeta de Tarea 4.1 (Ver tabla 3.13) pertenece a la historia de usuario 4, esta describe las

tareas necesarias para el diseño de interfaz del módulo de personal.

77
 Tabla 3.14 Tarjeta de Tarea 4.2 de Historia de Usuario 4
TAREA
Número de tarea: 4.2 Número de Historia: 4
Nombre de Tarea: ABM de personal de trabajo
Tipo de Tarea: Desarrollo Puntos estimados: 3
Programador Responsable: Evelyn Angela Alanez Zenteno
Descripción: Se implementará las clases necesarias para el alta, baja y modificación
de los datos del personal de la empresa.
Fuente: Elaboración propia

En la tarjeta de tarea 4.2 (Ver tabla 3.14), se describen las tareas necesarias para el alta,

modificación y eliminación de los datos del personal de la empresa.

Historias de Usuario - Sucursal: A continuación, se muestra a la tabla de la historia de usuario

del módulo sucursal.

Tabla 3.15 Historia de Usuario 5 – Sucursal

HISTORIA DE USUARIO
Número: 5 Usuario: Encargado de sucursal
Nombre de Historia: Módulo Sucursal
Puntos Estimados: 1 Prioridad de negocio: Alta
Iteración asignada: 2 Riesgo de desarrollo: Alto
Descripción: El sistema permite realizar el registro de las sucursales, con
características que fueron definidas por la empresa, además de permitir la
modificación y eliminación de las mismas.
Fuente: Elaboración propia

La Tarjeta de Tarea 5.1 (Ver tabla 3.16) pertenece a la historia de usuario 5, esta describe las

tareas necesarias para el diseño de interfaz del módulo sucursal.

78
 Tabla 3.16 Tarjeta de Tarea 5.1 de Historia de Usuario 5
TAREA
Número de tarea: 5.1 Número de Historia: 5
Nombre de Tarea: Diseño de la interfaz del módulo sucursal
Tipo de Tarea: Diseño Puntos estimados: 2
Programador Responsable: Evelyn Angela Alanez Zenteno
Descripción: Se creará un formulario que permita realizar el registro de las sucursales,
además de comprobar que estos datos son almacenados correctamente en la base de
datos.
Fuente: Elaboración propia

En la tarjeta de tarea 5.2 (Ver tabla 3.17), se describen las tareas necesarias para el alta,

modificación y eliminación de los datos de cada sucursal.

Tabla 3.17 Tarjeta de Tarea 5.1 de Historia de Usuario 5

TAREA
Número de tarea: 5.2 Número de Historia: 5
Nombre de Tarea: ABM de sucursal
Tipo de Tarea: Desarrollo Puntos estimados: 2
Programador Responsable: Evelyn Angela Alanez Zenteno
Descripción: Se implementará las clases necesarias para el alta, baja y modificación
de las sucursales de la empresa.
Fuente: Elaboración propia

Historias de Usuario – Inventarios: Este módulo tiene una importancia alta para la empresa,

debido a que, con el sistema a implementarse se desea tener un buen control de los productos que

existen en bodega; además, se debe observar un listado de todos los productos con las cantidades

disponibles. A continuación, se muestra la historia de usuario de Inventarios (Ver tabla 3.18):

79
 Tabla 3.18 Historia de Usuario 6 – Inventario
HISTORIA DE USUARIO
Número: 6 Usuario: Encargado de ventas, encargado de bodega
Nombre de Historia: Inventario de productos
Puntos Estimados: 2 Prioridad de negocio: Alta
Iteración asignada: 2 Riesgo de desarrollo: Alto
Descripción: El sistema debe contar con el módulo de inventarios, que mostrará
un listado de los productos con sus cantidades existentes en bodega, además que se
debe registrar información sobre el usuario y fecha que añadió el producto, así
mismo si este se elimina
Fuente: Elaboración propia

La historia de usuario 6, se descompondrá en la siguiente tarjeta de tarea 6.1 (Ver tabla 3.19),

que describe las actividades que se deben realizar para el ingreso de productos a inventario.

Tabla 3.19 Tarjeta de Tarea 6.1 de Historia de Usuario 6

TAREA
Número de tarea: 6.1 Número de Historia: 6
Nombre de Tarea: Función de ingreso de productos a Inventarios
Tipo de Tarea: Desarrollo Puntos estimados: 5
Programador Responsable: Evelyn Angela Alanez Zenteno
Descripción: Crear las funciones y procedimientos necesarios para ingresar,
modificar y eliminar productos al inventario a nivel vista y controlador, permitiendo
actualizar el stock de los productos existentes.
Fuente: Elaboración propia

A continuación, se muestra la tarjeta de tarea 6.2 (Ver tabla 3.20) de la historia de usuario de

Inventarios:

80
 Tabla 3.20 Tarjeta de Tarea 6.2 de Historia de Usuario 6
TAREA
Número de tarea: 6.2 Número de Historia: 6
Nombre de Tarea: Desarrollo del módulo de inventarios
Tipo de Tarea: Desarrollo Puntos estimados: 4
Programador Responsable: Evelyn Angela Alanez Zenteno
Descripción: Se mostrará un listado de todos los productos existentes en bodega con
la descripción necesaria de cada producto.
Fuente: Elaboración propia

Historias de Usuario - Productos: Esta historia de usuario tiene una prioridad alta para la red

de Ópticas. El riesgo de desarrollo es alto debido a que este objeto es un objeto base del sistema y

es preciso definirlo de la forma más clara. El sistema debe registrar la información necesaria de

los productos que ofrece la empresa, así como permitir la actualización necesaria de los mismos.

Como se muestra a continuación en la Historia de Usuario 7 (Ver tabla 3.21).

Tabla 3.21 Historia de Usuario 7 – Registro de Productos

HISTORIA DE USUARIO
Usuario: Encargado de ventas y operaciones
Número: 7
y encargado de bodega
Nombre de Historia: Registro de productos
Puntos Estimados: 2 Prioridad de negocio: Alta
Iteración asignada: 2 Riesgo de desarrollo: Alto
Descripción: El sistema permite realizar el registro de los productos, con
características que fueron definidas por la empresa, además de permitir la
modificación y eliminación de cada producto.
Fuente: Elaboración propia

A continuación, la Tarjeta de Tarea 7.1 (Ver tabla 3.22), describe la interfaz del módulo de

productos:

81
 Tabla 3.22 Tarjeta de Tarea 7.1 de Historia de Usuario 7
TAREA
Número de tarea: 7.1 Número de Historia: 7
Nombre de Tarea: Diseño de la interfaz del módulo de Productos
Tipo de Tarea: Diseño Puntos estimados: 4
Programador Responsable: Evelyn Angela Alanez Zenteno
Descripción: Se creará el formulario que permita introducir todas las características
de los productos: código de producto, nombre, precio, stock, presentación, detalle.
Fuente: Elaboración propia

Se muestra la tarjeta de tarea 7.2 (Ver tabla 3.23) perteneciente a la historia de usuario 7, que

describe las ABM de los productos:

Tabla 3.23 Tarjeta de Tarea 7.2 de Historia de Usuario 7

TAREA
Número de tarea: 7.2 Número de Historia: 7
Nombre de Tarea: ABM de Productos
Tipo de Tarea: Desarrollo Puntos estimados: 4
Programador Responsable: Evelyn Angela Alanez Zenteno
Descripción: Se implementarán las clases necesarias para permitir el alta,
modificación y eliminación de productos. El sistema deberá almacenar correctamente
esta información en la base de datos, además de mostrar el listado de los productos.
Fuente: Elaboración propia

Historias de Usuario – Categorías: El sistema debe realizar el ABM de los registros de

categorías, como se muestra en la Historia de Usuario 8 (Ver tabla 3.24):

82
 Tabla 3.24 Historia de Usuario 8 – Categorías
HISTORIA DE USUARIO
Número: 8 Usuario: Encargado de ventas y operaciones
y encargado de bodega
Nombre de Historia: Administración de categorías
Puntos Estimados: 1 Prioridad de negocio: Media
Iteración asignada: 2 Riesgo de desarrollo: Medio
Descripción: El sistema debe permitir crear, listar, modificar y eliminar los registros
de las categorías.
Fuente: Elaboración propia

A continuación, se muestran la tarjeta de tarea 8.1 (Ver tabla 3.25), necesaria para la

implementación de la historia de usuario de Títulos:

Tabla 3.25 Tarjeta de Tarea 8.1 de Historia de Usuario 8

TAREA
Número de tarea: 8.1 Número de Historia: 8
Nombre de Tarea: ABM de categorías
Tipo de Tarea: Desarrollo Puntos estimados: 2
Programador Responsable: Evelyn Angela Alanez Zenteno
Descripción: Crear funciones para crear, modificar, eliminar y listar los títulos a
nivel vista y controlador, los cuales clasifican a los productos.
Fuente: Elaboración propia

Historias de Usuario – Proveedores: El sistema debe registrar los datos de los proveedores
con los que tiene contacto la empresa, para brindar más información sobre la materia prima que
se adquieren de cada uno. A continuación, se describe la historia de usuario 9, Proveedores (Ver
tabla 3.26):

83
 Tabla 3.26 Historia de Usuario 9 – Proveedor
HISTORIA DE USUARIO
Usuario: Gerente, Encargado de ventas y
Número: 9
operaciones, Encargado de bodega.
Nombre de Historia: Registro de Proveedor
Puntos Estimados: 1 Prioridad de negocio: Medio
Iteración asignada: 2 Riesgo de desarrollo: Media
Descripción: El sistema debe permitir al usuario el registro de los proveedores,
permitiendo además la modificación y eliminación de los mismos.
Fuente: Elaboración propia

La historia de usuario de proveedores, se descompone en la tarjeta de tarea 9.1, que se muestran

a continuación:

Tabla 3.27 Tarjeta de Tarea 9.1 de Historia de Usuario 9

TAREA
Número de tarea: 9.1 Número de Historia: 9
Nombre de Tarea: ABM de Proveedores
Tipo de Tarea: Desarrollo Puntos estimados: 2
Programador Responsable: Evelyn Angela Alanez Zenteno
Descripción: Se implementará las tareas necesarias para que el sistema permita
realizar el alta, baja y modificación de los datos de proveedores.
Fuente: Elaboración propia

Historia de usuario – Facturación: A continuación, se muestra a la tabla de la historia de

usuario 10, Módulo Facturación (Ver tabla 3.28).

84
 Tabla 3.28 Historia de Usuario 10 – Facturación
HISTORIA DE USUARIO
Número: 10 Usuario: Encargado de Venta
Nombre de Historia: Módulo Facturación
Puntos Estimados: 4 Prioridad de negocio: Alta
Iteración asignada: 3 Riesgo de desarrollo: Alto
Descripción: En este módulo el sistema realizará el registro de facturas y generará
las mismas.
Observación: Debe haber una relación de factura con las ventas y clientes.
Fuente: Elaboración propia

La Tarjeta de Tarea 10.1 (Ver tabla 3.29) pertenece a la historia de usuario 10, esta describe las

tareas necesarias para el diseño de interfaz de módulo de facturación.

Tabla 3.29 Tarjeta de Tarea 10.1 de Historia de Usuario 10

TAREA
Número de tarea: 10.1 Número de Historia: 10
Nombre de Tarea: Diseño de la interfaz del módulo Facturación
Tipo de Tarea: Diseño Puntos estimados: 5
Programador Responsable: Evelyn Angela Alanez Zenteno
Descripción: Se creará la interfaz para el módulo de facturación, con sus respectivas
opciones.
Fuente: Elaboración propia

Se muestra la tarjeta de tarea 10.2 (Ver tabla 3.30) perteneciente a la historia de usuario 10, que

describe las ABM de Módulo facturación:

85
 Tabla 3.30 Tarjeta de Tarea 10.1 de Historia de Usuario 10
TAREA
Número de tarea: 10.2 Número de Historia: 10
Nombre de Tarea: ABM de Módulo Facturación
Tipo de Tarea: Desarrollo Puntos estimados: 8
Programador Responsable: Evelyn Angela Alanez Zenteno
Descripción: Se implementará las tareas necesarias para que el sistema
permita realizar el alta, baja y modificación del módulo de facturación.
Fuente: Elaboración propia

Historia de Usuario – Clientes: El sistema debe permitir el registro de los clientes en el

sistema, para que los mismos puedan realizar sus pedidos en cualquier momento y lugar, ayudando

a llevar un mejor control sobre las ventas que se realizan a cada uno. La tabla que se muestra a

continuación (Ver tabla 3.31) es la historia de usuario de Clientes:

Tabla 3.31 Historia de Usuario 11 – Clientes

HISTORIA DE USUARIO
Usuario: Encargado de ventas y
Número: 11
operaciones
Nombre de Historia: Clientes
Puntos Estimados: 1 Prioridad de negocio: Alta
Iteración asignada: 3 Riesgo de desarrollo: Alto
Descripción: El sistema debe permitir el registro de los clientes.
Fuente: Elaboración propia

En la tarjeta de tarea 11.1 (Ver tabla 3.32), se describen las tareas necesarias para la historia de

usuario de clientes.

86
 Tabla 3.32 Tarjeta de Tarea 11.1 de Historia de Usuario 11
TAREA
Número de tarea: 11.1 Número de Historia: 11
Nombre de Tarea: Clientes
Tipo de Tarea: Desarrollo Puntos estimados: 3
Programador Responsable: Evelyn Angela Alanez Zenteno
Descripción: Se implementará las clases necesarias para el módulo de clientes.
Fuente: Elaboración propia

Historia de Usuario – Ventas: El sistema debe registrar las ventas que se realizan en la

sucursal de acuerdo a los productos con los que cuenta, el cual debe ser atendido por el personal

de ventas que tiene la empresa. A continuación, se muestra historia de usuario 12, Ventas (Ver

tabla 3.33):

Tabla 3.33 Historia de Usuario 12 – Ventas

HISTORIA DE USUARIO
Número: 12 Usuario: Encargado de ventas
Nombre de Historia: Ventas
Puntos Estimados: 1 Prioridad de negocio: Alta
Iteración asignada: 3 Riesgo de desarrollo: Alto
Descripción: En este módulo el sistema realizará el registro de las ventas.
Fuente: Elaboración propia

En la tarjeta de tarea 12.1 (Ver tabla 3.34), se describen las tareas necesarias para la historia de

usuario de clientes.

87
 Tabla 3.34 Tarjeta de Tarea 12.1 de Historia de Usuario 12
TAREA
Número de tarea: 12.1 Número de Historia: 12
Nombre de Tarea: Ventas
Tipo de Tarea: Desarrollo Puntos estimados: 3
Programador Responsable: Evelyn Angela Alanez Zenteno
Descripción: Se implementará las clases necesarias para el módulo de ventas.
Fuente: Elaboración propia

En esta área tanto como el personal de venta, como el administrador podrán realizar las ventas,

pues los dos tienen acceso a ventas, este acceso se dio al administrador porque en casos especiales

el administrador podrá realizar el rol de personal de ventas.

Historias de Usuario – Reportes: El sistema debe devolver reportes que brinden información

real y precisa para apoyar a una mejor toma de decisiones en la empresa. A continuación, se

muestra las historias de usuarios 13, Reportes (Ver tabla 3.35).

Historia de usuario - Reportes de inventarios:

Tabla 3.35 Historia de Usuario 13– Reportes de inventario

HISTORIA DE USUARIO
Usuario: Gerente, encargado de
Número: 13
ventas, encargado de bodega
Nombre de Historia: Reportes de inventarios
Puntos Estimados: 1 Prioridad de negocio: Alta
Iteración asignada: 4 Riesgo de desarrollo: Media
Descripción: El sistema debe proveer un reporte donde se pueda visualizar es
stock de los productos.
Fuente: Elaboración propia

88
 La tarjeta de tarea 13.1 (Ver tabla 3.36), indica las tareas necesarias para la implementación del

módulo de reporte de inventarios.

Tabla 3.36 Tarjeta de Tarea 13.1 de Historia de Usuario 13

TAREA
Número de tarea: 13.1 Número de Historia: 13
Nombre de Tarea: Desarrollo de reportes del módulo de inventarios.
Tipo de Tarea: Desarrollo Puntos estimados: 3
Programador Responsable: Evelyn Angela Alanez Zenteno
Descripción: Implementar las funciones necesarias para los reportes de inventarios
a nivel vista.
Fuente: Elaboración propia

Historia de usuario - Reportes de facturas:

Tabla 3.37 Historia de Usuario 14 – Reportes de facturas

HISTORIA DE USUARIO
Usuario: Gerente, encargado de
Número: 14
ventas, encargado de bodega
Nombre de Historia: Reportes de Facturas
Puntos Estimados: 1 Prioridad de negocio: Alta
Iteración asignada: 4 Riesgo de desarrollo: Media
Descripción: El sistema debe proveer un reporte donde se pueda visualizar las
facturas emitidas, con sus respectivas ventas y clientes
Fuente: Elaboración propia

La tarjeta de tarea 14.1 (Ver tabla 3.38), indica las tareas necesarias para la implementación del

módulo de reporte de inventarios.

89
 Tabla 3.38 Tarjeta de Tarea 14.1 de Historia de Usuario 14
TAREA
Número de tarea: 14.1 Número de Historia: 14
Nombre de Tarea: Desarrollo de reportes de facturación
Tipo de Tarea: Desarrollo Puntos estimados: 3
Programador Responsable: Evelyn Angela Alanez Zenteno
Descripción: Crear las funciones necesarias a nivel vista y controlador, para que el
sistema pueda generar reportes que muestres las facturas realizadas en rangos de
fechas.
Fuente: Elaboración propia

La siguiente tabla muestra un resumen de las Historias de Usuario y su implementación.

Historia de usuario - Reportes de ingresos y salidas de productos:

Tabla 3.39 Historia de Usuario 15 – Reportes de ingresos salidas

HISTORIA DE USUARIO
Usuario: Gerente, encargado de ventas,
Número: 15
encargado de bodega
Nombre de Historia: Reportes de ingresos y salidas
Puntos Estimados: 1 Prioridad de negocio: Alta
Iteración asignada: 4 Riesgo de desarrollo: Media
Descripción: El sistema debe proveer un reporte donde se pueda visualizar los
ingresos y las salidas de los productos al inventario.
Fuente: Elaboración propia

La tarjeta de tarea 15.1 (Ver tabla 3.40), indica las tareas necesarias para la implementación del

módulo de reporte de ingresos y salidas de productos.

90
 Tabla 3.40 Tarjeta de Tarea 15.1 de Historia de Usuario 15
TAREA
Número de tarea: 15.1 Número de Historia: 15
Nombre de Tarea: Desarrollo de reportes de ingresos y salidas
Tipo de Tarea: Desarrollo Puntos estimados: 3
Programador Responsable: Evelyn Angela Alanez Zenteno
Descripción: Crear las funciones necesarias a nivel vista y controlador, para que el
sistema pueda generar reportes que muestren los ingresos y salidas de productos.
Fuente: Elaboración propia

En la Tabla 3.41 muestra un resumen de las Historias de Usuario y su implementación.

91
 Tabla 3.41 Resumen de Historia de Usuario
Puntos
No Nombre Prioridad Riesgo Iteraciones
estimados

1 Administración de usuario Alta Alto 2 1

2 Administración de roles Alta Alto 1 1

3 Administración de menús Alta Alto 1 1

Administración de
4 Media Medio 1 1
personal de trabajo

5 Módulo Sucursal Alta Alto 1 2

6 Inventarios de productos Alta Alta 2 2

7 Registro de Producto Alta Alto 2 2

Administración de
8 Medio Medio 1 2
categorías

9 Registro de Proveedor Media Medio 1 2

10 Módulo Facturación Alta Alto 4 3

11 Cliente Alta Alta 1 3

12 Ventas Alta Alto 1 3

13 Reportes de inventarios Alta Medio 1 4

14 Repostes de facturación Alta Medio 1 4

Reportes de ingresos y
15 Alta Medio 1 4
salidas de productos
Fuente: Elaboración Propia

92
3.2.1.4 Plan de Iteración

Tabla 3.42 Plan de Iteración

HISTORIAS DE FECHA FECHA

ITERACIONES DURACION
USUARIO INICIO FIN
• Administración de
usuario
• Administración de
roles
Primera 5 semanas 01-02-2021 05-02-2021
• Administración de
menús
• Administración de
personal de trabajo
• Sucursal
• Inventario
Segunda • Producto 5 semanas 01-03-2021 02-04-2021
• Administración de
categorías
• Facturación
Tercera • Clientes 6 semanas 01-04-2021 07-05-2021
• Ventas
• Reportes de
inventario
• Reportes de
Cuarta facturación 5 semanas 10-05-2021 11-06-2021
• Reportes de
ingresos y salidas
de productos
Fuente: Elaboración Propia

93
3.2.1.5 Plan de entregas

Tabla 3.43 Plan de Entregas

Fuente: Elaboración Propia

3.2.2 Fase II – Diseño

En esta fase se presentarán diseños simples siguiendo el principio MS (mantenlo sencillo),

como sugiere la metodología XP. Para lograr una mejor comprensión de la funcionalidad del

sistema, manifestando de manera clara su objetivo. El diseño de los modelos está basado en el

lenguaje WebML.

Previamente, se elaboró el diagrama de contexto del sistema (Ver Figura 3.2). Éste identifica

las entidades externas que tienen vínculo con sistema y que se interrelacionan de alguna forma con

el sistema, así como los flujos de datos entre cada entidad y el sistema.

94
 Figura 3.2 Diagrama de contexto del sistema
Fuente: Elaboración propia
3.2.2.1 Modelo Estructural

El modelo estructural, representa la estructura estática del sistema, mediante la definición de

entidades o contenedores de datos y sus relaciones, la interrelación entre ellas y el comportamiento

a nivel funcional entre estas. A continuación, se muestra el modelo Entidad Relación (Ver Figura

3.3) y la estructura de la base de datos (Ver Figura 3.4):

95
 Figura 3.3 Modelo Entidad Relación E-R
Fuente: Elaboración Propia

A continuación, en la Figura 3.3 se muestra la base de datos que está asociado al sistema que

cuenta con todas las tablas con cada uno de los atributos derivados de las entidades

96
 Figura 3.4 Base de Datos
Fuente: Elaboración Propia

97
3.2.2.2 Primera iteración

Entre los requisitos de la metodología WebML tenemos el modelo de presentación que vendría

a ser la representación de los diagramas de hipertexto de forma visual, al igual que se presentaran

las Tarjetas CRC. A continuación, se realizará la representación de dichos modelos para su

posterior implementación y desarrollo.

• Tarjeta CRC

A continuación, se mostrarán las tarjetas C.R.C. de las clases principales del sistema.

➢ Clase Usuario:

Tabla 3.44 Tarjeta CRC - Usuarios

TARJETAS CRC
Nombre de la clase: Usuario
RESPONSABILIDADES: COLABORADORES:
- Crea registros de usuario - Personal de trabajo
- Crea, modifica, elimina
registros de usuario
- Identificación de rol
Fuente: Elaboración Propia

98
➢ Clase Rol:

Tabla 3.45 Tarjeta CRC - Rol

TARJETAS CRC
Nombre de la clase: Rol
RESPONSABILIDADES: COLABORADORES:
- Crea, modifica, elimina - Personal de trabajo
registros de rol
- Listar roles
Fuente: Elaboración Propia

➢ Clase Menú

Tabla 3.46 Tarjeta CRC - Menú

TARJETAS CRC
Nombre de la clase: Menú
RESPONSABILIDADES: COLABORADORES:
- Identificación de rol - Rol
- Crea, modifica, elimina
registros de menús
- Lista de menús
Fuente: Elaboración Propia

99
 ➢ Clase Personal_Trabajo

Tabla 3.47 Tarjeta CRC – Personal_Trabajo

TARJETAS CRC
Nombre de la clase: Personal_Trabajo
RESPONSABILIDADES: COLABORADORES:
- Identificación de rol - Registro de personal
- Crea, modifica, elimina de trabajo
registros de personal de - Base de datos del
trabajo personal de trabajo
- Lista de personal de trabajo
Fuente: Elaboración Propia

• Modelo de Hipertexto

En el diagrama que se muestra a continuación (Ver Figura 3.5) muestra la forma en que

se va desarrollar el módulo de usuario que pertenece la Historia de Usuario 1. En esta

se muestra la composición y la parte de navegacional desde el inicio hasta el despliegue

del mismo.

Figura 3.5 Modelo de Hipertexto – Usuario

Fuente: Elaboración Propia

100
 El diagrama que se ve a continuación (Ver Figura 3.6), se muestra el módulo de administración

de roles que pertenece a la Historia de Usuario 2 y sus respectivas tareas, de manera navegacional

y sus componentes de la página.

Figura 3.6 Modelo de Hipertexto – Roles

Fuente: Elaboración Propia

El diagrama que se ve a continuación (Ver Figura 3.7), muestra el módulo de administración

de menús que pertenece a la Historia de Usuario 3 y sus respectivas tareas, de manera navegacional

y sus componentes de la página.

Figura 3.7 Modelo de Hipertexto – Menú

Fuente: Elaboración Propia.

101
 El diagrama que se ve a continuación (Ver Figura 3.8), muestra el módulo de administración

de personal de trabajo que pertenece a la Historia de Usuario 4 y sus respectivas tareas, de manera

navegacional y sus componentes de la página.

Figura 3.8 Modelo de Hipertexto – Personal de Trabajo

Fuente: Elaboración Propia.

• Modelo de Presentación

La siguiente Figura muestra el modelo de presentación de la clase de Usuario:

Figura 3.9 Modelo de Presentación – Usuario

Fuente: Elaboración Propia.

102
La pantalla de Roles del sistema (Ver Figura 3.10) muestra las opciones de agregar,

editar los registros de roles.

Figura 3.10 Modelo de Presentación – Rol

Fuente: Elaboración Propia.

La pantalla de Menús del sistema (Ver Figura 3.11) muestra las opciones de agregar,

editar los registros de menús.

Figura 3.11 Modelo de Presentación – Menú

Fuente: Elaboración Propia.

103
 La pantalla de Personal de trabajo del sistema (Ver Figura 3.12) muestra las opciones de

agregar, editar los registros del personal de trabajo.

Figura 3.12 Modelo de Presentación – Personal Trabajo

Fuente: Elaboración Propia.
3.2.2.3 Segunda iteración

A continuación, se realiza una descripción de Hipertexto y de Presentación para las Historias

de Usuario correspondientes a la segunda iteración.

• Tarjeta CRC

Estas son las tarjetas C.R.C de la segunda iteración:

104
➢ Clase Sucursal

Tabla 3.48 Tarjeta CRC - Sucursal

TARJETAS CRC
Nombre de la clase: Sucursal
RESPONSABILIDADES: COLABORADORES:
- Identificación de rol - Base de datos de
- Crea, modifica, elimina registros sucursales
de sucursal
- Lista de sucursales
Fuente: Elaboración Propia

➢ Clase Inventario

Tabla 3.49 Tarjeta CRC - Inventario

TARJETAS CRC
Nombre de la clase: Inventario
RESPONSABILIDADES: COLABORADORES:
- Crea registros de inventario - Productos
- Modifica registros de inventario
- Identificación de rol
Fuente: Elaboración Propia

➢ Clase Producto

Tabla 3.50 Tarjeta CRC – Producto

TARJETAS CRC
Nombre de la clase: Producto
RESPONSABILIDADES: COLABORADORES:
- Crea, modifica, elimina - categoría
registros de productos - Base de datos de
- Provee lista de productos categoría
Fuente: Elaboración Propia

105
 ➢ Clase Categoría

Tabla 3.51 Tarjeta CRC - Categoría

TARJETAS CRC
Nombre de la clase: Categoría
RESPONSABILIDADES: COLABORADORES:
- Identificación de rol - Producto
- Crea, modifica, elimina
registros de categoría
- Lista categoría
Fuente: Elaboración Propia

➢ Clase Proveedor

Tabla 3.52 Tarjeta CRC – Proveedor

TARJETAS CRC
Nombre de la clase: Proveedor
RESPONSABILIDADES: COLABORADORES:
- Identificación de rol - Registro proveedores
- Crea, modifica, elimina - Base de datos de
registros de proveedores proveedores
- Lista de proveedor
Fuente: Elaboración Propia

• Modelo de Hipertexto

El diagrama que se ve a continuación (Ver Figura 3.13), se muestra el módulo de

sucursal que pertenece a la Historia de Usuario 5:

106
 Figura 3.13 Modelo de Hipertexto – Sucursal
Fuente: Elaboración Propia.

El diagrama que se ve a continuación (Ver Figura 3.14), se muestra el Inventario de

productos que pertenece a la Historia de Usuario 6:

Figura 3.14 Modelo de Hipertexto – Inventario de productos

Fuente: Elaboración Propia.

El diagrama que se ve a continuación (Ver Figura 3.15), se muestra el módulo registro

de productos que pertenece a la Historia de Usuario 7:

107
 Figura 3.15 Modelo de Hipertexto – Producto
Fuente: Elaboración Propia.

El diagrama que se ve a continuación (Ver Figura 3.16), se muestra la administración

de categorías que pertenece a la Historia de Usuario 8:

Figura 3.16 Modelo de Hipertexto – Categoría

Fuente: Elaboración Propia.

El diagrama que se ve a continuación (Ver Figura 3.17), se muestra el registro de

proveedor que pertenece a la Historia de Usuario 9:

108
 Figura 3.17 Modelo de Hipertexto – Proveedor
Fuente: Elaboración Propia.

• Modelo de presentación

La siguiente imagen (Ver Figura 3.18) muestra el modelo de presentación de la clase

Sucursal:

Figura 3.18 Modelo de Presentación – Sucursal

Fuente: Elaboración Propia.

La pantalla de Inventario del sistema (Ver Figura 3.19) la forma en que se almacenará

los productos.

109
 Figura 3.19 Modelo de Presentación – Inventario
Fuente: Elaboración Propia.

La siguiente imagen (Ver Figura 3.20) muestra el modelo de presentación de la clase

Productos.

Figura 3.20 Modelo de Presentación – Producto

Fuente: Elaboración Propia.

La siguiente imagen (Ver Figura 3.21) muestra el modelo de presentación de la clase

Categorías.

110
 Figura 3.21 Modelo de Presentación – Categoría
Fuente: Elaboración Propia.

La siguiente imagen (Ver Figura 3.22) muestra el modelo de presentación de la clase

Proveedor.

Figura 3.22 Modelo de Presentación – Proveedor

Fuente: Elaboración Propia.

111
3.2.2.4 Tercera Iteración

A continuación, se realiza una descripción de Hipertexto y de Presentación para las Historias

de Usuario correspondientes a la tercera iteración.

• Tarjeta CRC

A continuación, se muestra la tarjeta CRC correspondiente a la tercera iteración.

➢ Clase Factura

Tabla 3.53 Tarjeta CRC - Factura

TARJETAS CRC
Nombre de la clase: Factura
RESPONSABILIDADES: COLABORADORES:
- Crea, modifica, elimina - Registro de factura
registros de factura - Base de datos de
- Identificación de rol factura
Fuente: Elaboración Propia

➢ Clase Cliente

Tabla 3.54 Tarjeta CRC - Cliente

TARJETAS CRC
Nombre de la clase: Cliente
RESPONSABILIDADES: COLABORADORES:
- Crea, modifica, elimina - Registro de clientes
registros de clientes - Base de datos de
- Listar clientes clientes
Fuente: Elaboración Propia

112
 ➢ Clase Venta

Tabla 3.55 Tarjeta CRC - Venta

TARJETAS CRC
Nombre de la clase: Venta
RESPONSABILIDADES: COLABORADORES:
- Identificación de rol - Clientes
- Genera factura - Productos
Fuente: Elaboración Propia

• Modelo de Hipertexto

El diagrama que se ve a continuación (Ver Figura 3.23), se muestra el módulo de

facturación que pertenece a la Historia de Usuario 10:

Figura 3.23 Modelo de Hipertexto – Factura

Fuente: Elaboración Propia.

El diagrama que se ve a continuación (Ver Figura 3.24), se muestra clientes y ventas

que pertenece a la Historia de Usuario 11 y 12:

113
 Figura 3.24 Modelo de Hipertexto – Cliente y Venta
Fuente: Elaboración Propia.

• Modelo de presentación

La pantalla de Ventas (Ver Figura 3.25) muestra los campos que se tendrá en el

momento de registrar las ventas diarias. Esta información almacenada tendrá la opción

de guardar Ingresar nuevas ventas.

Figura 3.25 Modelo de Presentación – Factura, Cliente y Ventas

Fuente: Elaboración Propia.

114
3.2.2.5 Cuarta Iteración

A continuación, se realiza una descripción de Hipertexto y de Presentación para las Historias

de Usuario correspondientes a la cuarta iteración.

• Tarjeta CRC

A continuación, se observa la tarjeta CRC correspondiente a la cuarta iteración.

➢ Clase Reportes de inventario

Tabla 3.56 Tarjeta CRC – Reporte Inventario

TARJETAS CRC
Nombre de la clase: Inventario
RESPONSABILIDADES: COLABORADORES:
- Identificación de rol - Inventario
- Imprimir reportes - Salida de productos
- Ingreso de productos
Fuente: Elaboración Propia

➢ Clase Reportes de facturación

Tabla 3.57 Tarjeta CRC – Reporte Factura

TARJETAS CRC
Nombre de la clase: Inventario
RESPONSABILIDADES: COLABORADORES:
- Identificación de rol - Venta
- Imprimir reportes - Cliente
- Factura
Fuente: Elaboración Propia

115
 ➢ Clase Reportes de Ingresos y Salidas de productos

Tabla 3.58 Tarjeta CRC – Reporte ingresos y Salidas

TARJETAS CRC
Nombre de la clase: Inventario
RESPONSABILIDADES: COLABORADORES:
- Identificación de rol - Registros de ingresos
- Imprimir reportes - Registros de salidas
Fuente: Elaboración Propia

• Modelo Hipertexto

El siguiente diagrama (Figura 3.26) muestra los reportes de inventarios que corresponde

a la historia de usuario 13.

Figura 3.26 Modelo de Hipertexto – Reportes de inventarios

Fuente: Elaboración Propia.

El siguiente diagrama (Figura 3.27) se muestra los reportes de facturación que

corresponde a la historia de usuario 14.

116
 Figura 3.27 Modelo de Hipertexto – Reportes de Factura
Fuente: Elaboración Propia.

El siguiente diagrama (Figura 3.28) se muestra los reportes de ingresos y salidas que

corresponde a la historia de usuario 15.

Figura 3.28 Modelo de Hipertexto – Reportes de Ingresos y Salidas

Fuente: Elaboración Propia.

• Modelo de presentación

La siguiente Figura muestra el modelo de presentación de la clase de Reportes de

inventarios:

117
 Figura 3.29 Modelo de Presentación – Reporte de Inventarios
Fuente: Elaboración Propia.

La siguiente Figura muestra el modelo de presentación de la clase de Reportes de facturación:

Figura 3.30 Modelo de Presentación – Reporte Factura

Fuente: Elaboración Propia.

La siguiente Figura muestra el modelo de presentación de la clase de Reportes de

ingreso y salida de productos:

118
3.2.2.6 Diagramas de casos de uso

Para apoyar la fase de diseño, se hará uso de los diagramas de casos de uso del Lenguaje de

Modelado Unificado (UML) que permiten representar que hará el sistema, pero no como funciona.

A continuación, se muestran los diagramas de casos de uso más importantes:

Figura 3.31 Diagrama de caso de uso del módulo de Inventarios

Fuente: Elaboración propia

119
 Figura 3.32 Diagrama de caso de uso del módulo de Ventas y Facturación
Fuente: Elaboración propia

3.2.3 Fase III – Codificación

Después de que las historias han sido desarrolladas y de que se ha hecho el trabajo de diseño

preliminar, en esta fase se realiza la programación del sistema acorde al plan de entrega realizadas

anteriormente, teniendo en cuenta todas las características que se presentaron y diseñaron.

120
 A continuación, se muestran la captura de pantalla de inicio del sistema (Ver Figura 3.33), en

el cual se debe ingresar los datos.

Figura 3.33 Pantalla - inicio de Sesión

Fuente: Elaboración propia

A continuación, se muestra la pantalla de control de accesos de usuarios (Ver Figura 3.34):

Figura 3.34 Pantalla – Accesos de Usuarios

Fuente: Elaboración propia

121
 A continuación, se muestra la pantalla del módulo de administración de roles (Ver Figura 3.35):

Figura 3.35 Pantalla - Roles

Fuente: Elaboración propia

A continuación, en la Figura 3.36, se muestra la pantalla del módulo de administración de

Menús:

Figura 3.36 Pantalla - Menus

Fuente: Elaboración propia

122
En la siguiente Figura observamos el registro del personal de trabajo (Ver Figura 3.37):

Figura 3.37 Pantalla – Registro Personal de Trabajo

Fuente: Elaboración propia

En la siguiente Figura observamos el módulo sucursal (Ver Figura 3.38):

Figura 3.38 Pantalla – Sucursales

Fuente: Elaboración propia

En la siguiente Figura observamos el inventario de productos (Ver Figura 3.39):

123
 Figura 3.39 Pantalla – Inventario
Fuente: Elaboración propia

En la siguiente Figura observamos el registro de productos (Ver Figura 3.40):

Figura 3.40 Pantalla – Productos

Fuente: Elaboración propia

A continuación, en la Figura 3.41 se muestra la pantalla del módulo de administración de

Categorías:

124
 Figura 3.41 Pantalla – Categorías
Fuente: Elaboración propia

A continuación, se muestra la pantalla del módulo de registro de Proveedor (Ver Figura 3.42):

Figura 3.42 Pantalla – Registro Proveedor

Fuente: Elaboración propia

A continuación, se muestra la pantalla de la emisión de Factura (Ver Figura 3.43).

125
 Figura 3.43 Pantalla – Factura
Fuente: Elaboración propia

En la Figura 3.44 observamos el registro de Ventas:

Figura 3.44 Pantalla – Ventas

Fuente: Elaboración propia

En la siguiente Figura observamos Reportes de ingresos y salidas de productos (Ver Figura 3.45).

126
 Figura 3.45 Pantalla – Reportes
Fuente: Elaboración propia

3.2.4 Fase IV – Pruebas

Para esta fase se va a realizar una serie de pruebas hechas a los módulos ya implementados

Y utilizados dentro de la empresa, se utilizará la tarjeta de aceptación o llamado pruebas de

aceptación, a continuación, se presentan todas las tarjetas de aceptación, que fueron calificadas

dentro del departamento de distribución.

3.2.4.1 Pruebas de aceptación

Las pruebas de aceptación fueron creadas en base a las historias de usuarios, en las distintas

iteraciones que se tuvo, para ver la correcta implementación de una historia de usuario por parte

del cliente. Este tipo de pruebas fueron realizadas para cada entrega del software en las distintas

iteraciones que se tuvo, ya que fueron definidas en el reverso de cada historia de usuario.

Las siguientes Figuras muestran todas las pruebas de aceptación requeridas por el cliente en

cada historia de usuario:

127
Administración de usuarios: Esta prueba (Ver tabla 3.59) busca encontrar todo tipo de errores

que se generen durante el proceso de registro de un usuario nuevo en el sistema. Además de

controlar el correcto acceso al sistema según al rol asignado a cada usuario.

Tabla 3.59 Prueba de Aceptación – Usuarios

CASO DE PRUEBA DE ACEPTACIÓN
Código: 1 Historia de Usuario: H1: Administración de usuarios
Descripción:
• Controlar que no se permita registrar el formulario de Usuario Nuevo, si es
que los campos obligatorios no están presentes o llenados correctamente.
• Mostrar un mensaje de confirmación una vez que se haya hecho el registro
correctamente.
Condiciones de Ejecución: Servidor ejecutándose, ingresar al sistema con los datos
correctos.
Entrada/ Pasos de ejecución: Gerente, Administrador del sistema, jefe de ventas y
operaciones, Encargado de almacén, Encargado de mantenimiento de maquinaria y el
cliente podrán ingresar al sistema previa autentificación.
Resultado Esperado: El sistema responde al ingreso de datos, usuario y password,
ingresando al menú principal del sistema, según el tipo rol asignado para el usuario
para empezar a interactuar con el mismo. Así como el correcto registro de un nuevo
usuario y contraseña.
Evaluación de la Prueba: Aceptada
Fuente: Elaboración propia

128
Administración de roles: La prueba de aceptación 2 comprueba la funcionalidad de las

ejecuciones de cada función asociada de la historia de usuario 2, que luego de haber realizado las

pruebas correspondientes se obtuvo el siguiente resultado (Ver tabla 3.60).

Tabla 3.60 Prueba de Aceptación – Administración de Roles

CASO DE PRUEBA DE ACEPTACIÓN
Código: 2 Historia de Usuario: H2: Administración de roles
Descripción:
• Controlar que se realice el ABM de roles de manera correcta.
Condiciones de Ejecución: Servidor ejecutándose, ingresar al Módulo de roles
Entrada/ Pasos de ejecución: Gerente, Administrador del sistema, podrán realizar
cambios en la asignación de roles al sistema.
Resultado Esperado: El sistema responde de manera correcta a la alta, baja y
modificación de roles asignados a los usuarios.
Evaluación de la Prueba: Aceptada
Fuente: Elaboración propia

Administración de menús: La prueba de aceptación 3 comprueba la funcionalidad de las

ejecuciones de cada función asociada de la historia de usuario 3, que luego de haber realizado las

pruebas correspondientes se obtuvo el siguiente resultado (Ver tabla 3.61).

129
 Tabla 3.61 Prueba de Aceptación – Administración de menús
CASO DE PRUEBA DE ACEPTACIÓN
Código: 3 Historia de Usuario: H3: Administración de menús
Descripción:
• Controlar que realice la ABM de menús de manera correcta.
• Controlar que los menús sean correctamente asignados a los roles.
Condiciones de Ejecución: Servidor ejecutándose, ingresar al Módulo de menús.
Entrada/ Pasos de ejecución: Gerente, Administrador del sistema pueden realizar
cambios en a los menús de cada rol.
Resultado Esperado: El sistema responde de manera correcta al alta, baja y
modificación de menús y la correcta asignación de roles.
Evaluación de la Prueba: Aceptada
Fuente: Elaboración propia

Administración de personal de trabajo: Esta prueba (Ver tabla 3.62) busca encontrar todo tipo

de errores que se generen durante el proceso de registro, modificación y eliminación de los datos

del personal en el sistema.

130
 Tabla 3.62 Prueba de Aceptación – Personal de trabajo
CASO DE PRUEBA DE ACEPTACIÓN
Código: 4 Historia de Usuario: H4: Administración de usuarios
Descripción:
• Controlar el registro del personal de manera correcta.
• Controlar la baja del personal.
Condiciones de Ejecución: Servidor ejecutándose, ingresar al módulo de personal de
trabajo.
Entrada/ Pasos de ejecución: Gerente, Administrador del sistema y el personal que
tenga asignado y su rol este Módulo puede realizar cambios en la información de algún
empleado.
Resultado Esperado: El sistema responde al correcto registro de personal, así como la
modificación de los registros, mostrando información correcta y actualizada sobre el
personal de la empresa.
Evaluación de la Prueba: Aceptada

Fuente: Elaboración propia

Administración de sucursal: Esta prueba (Ver tabla 3.63) busca encontrar todo tipo de errores

que se generen durante el proceso de registro, modificación y eliminación de los datos de las

sucursales.

131
 Tabla 3.63 Prueba de Aceptación – Administración de sucursal
CASO DE PRUEBA DE ACEPTACIÓN
Código: 5 Historia de Usuario: H5: Administración de sucursal
Descripción:
• Controla el registro de cada sucursal de manera correcta.
• Mostrar un mensaje de confirmación una vez que se haya hecho el registro
correctamente.
Condiciones de Ejecución: Servidor ejecutándose, ingresar al sistema con los datos
correctos.
Entrada/ Pasos de ejecución: Gerente, Administrador del sistema, jefe de ventas y
operaciones, Encargado de almacén,
Resultado Esperado: El sistema responde al ingreso de datos, así como el correcto
registro de una nueva sucursal.
Evaluación de la Prueba: Aceptada
Fuente: Elaboración propia

Inventarios de productos: A continuación, se muestra la prueba de aceptación de la historia de

usuario de inventarios (Ver tabla 3.64):

132
 Tabla 3.64 Prueba de Aceptación – Inventario
CASO DE PRUEBA DE ACEPTACIÓN
Código: 6 Historia de Usuario: H6: Inventarios de productos
Descripción:
• Controlar que el registro de nuevos productos de manera correcta.
• Controlar la correcta actualización del stock de productos.
• Contar con información correcta sobre los datos de los productos
registrados en el sistema.
Condiciones de Ejecución: Servidor ejecutándose, ingresar al Módulo de inventarios.
Entrada/ Pasos de ejecución: El Gerente, encargado de bodega, encargado de ventas
y operaciones, además del personal que tenga asignado en su rol este módulo puede
realizar cambios en la información de los productos.
Resultado Esperado: El sistema responde al correcto registro de nuevos productos,
así como la correcta actualización del stock de los productos cuando se realiza la
aprobación de un pedido realizado por algún cliente, mostrando información correcta y
actualizada.
Evaluación de la Prueba: Aceptada
Fuente: Elaboración propia

Productos: A continuación, se muestra la prueba de aceptación de la historia de usuario de

Registro de productos (Ver tabla 3.65):

133
 Tabla 3.65 Prueba de Aceptación – Producto
CASO DE PRUEBA DE ACEPTACIÓN
Código: 7 Historia de Usuario: H7: Registro de productos
Descripción:
• Verificar que los precios de los productos sean correctos.
• Verificar que se realice el correcto registro de productos, mostrando un
mensaje de confirmación una vez que se haya hecho el registro.
• Controlar que se realice de manera correcta la baja y modificación de
productos
Condiciones de Ejecución: Servidor ejecutándose, ingresar al Módulo de productos.
Entrada/ Pasos de ejecución: El encargado de ventas y operaciones y el Encargado de
bodega y el personal autorizado realiza la alta, baja y modificación de productos al
sistema.
Resultado Esperado: El sistema responde al correcto registro de productos, así como
la modificación y eliminación de los registros.
Evaluación de la Prueba: Aceptada
Fuente: Elaboración propia

Administración de categorías: Esta prueba de aceptación (Ver tabla 3.66) hará una evaluación

sobre el módulo de administración de categorías, el resultado se muestra a continuación:

134
 Tabla 3.66 Prueba de Aceptación – Categoría
CASO DE PRUEBA DE ACEPTACIÓN
Historia de Usuario: H8: Administración de
Código: 8
categorías
Descripción:
• Controlar y verificar ABM de categorías.
Condiciones de Ejecución: Servidor ejecutándose, ingresar al Módulo de categorías.
Entrada/ Pasos de ejecución: El encargado de bodega o el personal encargado realiza
el registro de un nuevo título y modificación a un registro.
Resultado Esperado: El sistema responde al correcto registro de categorías y
modificaciones realizadas.
Evaluación de la Prueba: Aceptada
Fuente: Elaboración propia

Registro de proveedor: Esta prueba de aceptación (Ver tabla 3.67) hará una evaluación sobre el

módulo de registro de proveedor, el resultado se muestra a continuación:

135
 Tabla 3.67 Prueba de Aceptación – Proveedor
CASO DE PRUEBA DE ACEPTACIÓN
Código: 9 Historia de Usuario: H9: Registro de proveedor
Descripción:
• Controlar que el registro de proveedores de manera correcta.
• Controlar la baja de proveedores
• Contar con información correcta sobre los datos del proveedor registrado en el
sistema.
Condiciones de Ejecución: Servidor ejecutándose, ingresar al Módulo de proveedores.
Entrada/ Pasos de ejecución: El personal que tenga asignado en su rol este módulo
puede realizar cambios en la información de algún proveedor.
Resultado Esperado: El sistema responde al correcto registro de los datos de los
proveedores, así como la modificación y eliminación de los registros, mostrando
información correcta y actualizada.
Evaluación de la Prueba: Aceptada
Fuente: Elaboración propia

Módulo Facturación: Esta prueba de aceptación (Ver tabla 3.68) hará una evaluación sobre el

módulo de facturación, el resultado se muestra a continuación:

136
 Tabla 3.68 Prueba de Aceptación – Módulo facturación
CASO DE PRUEBA DE ACEPTACIÓN
Código: 10 Historia de Usuario: H10: Módulo de Facturación
Descripción:
• Controlar que el registro de facturas manera correcta.
Condiciones de Ejecución: Servidor ejecutándose, ingresar al Módulo de facturación.
Entrada/ Pasos de ejecución: El personal que tenga asignado en su rol este módulo
puede realizar cambios en la información de algún dato en facturas.
Resultado Esperado: el sistema responde al correcto registro y realización de facturas
Evaluación de la Prueba: Aceptada
Fuente: Elaboración propia

Cliente: La siguiente prueba de aceptación (Ver tabla 3.69) pertenece a la historia de usuario de

administración de clientes, obteniendo el siguiente resultado:

Tabla 3.69 Prueba de Aceptación – Cliente

CASO DE PRUEBA DE ACEPTACIÓN
Código: 11 Historia de Usuario: H11: Cliente
Descripción:
• Controlar que se registre de manera correcta.
Condiciones de Ejecución: Servidor ejecutándose.
Entrada/ Pasos de ejecución: El personal que tenga asignado en su rol el módulo de
facturas puede realizar cambios en la información de los clientes.
Resultado Esperado: el sistema responde al correcto registro de clientes ya que va
relacionado con facturas
Evaluación de la Prueba: Aceptada
Fuente: Elaboración propia

Ventas: La siguiente prueba de aceptación (Ver tabla 3.70) pertenece a la historia de usuario de

administración de clientes, obteniendo el siguiente resultado:

137
 Tabla 3.70 Prueba de Aceptación – Ventas
CASO DE PRUEBA DE ACEPTACIÓN
Código: 12 Historia de Usuario: H12: Ventas
Descripción:
• Controlar que se registre de manera correcta.
Condiciones de Ejecución: Servidor ejecutándose.
Entrada/ Pasos de ejecución: El personal que tenga asignado en su rol el módulo de
facturas puede realizar cambios en la información de las ventas.
Resultado Esperado: el sistema responde al correcto registro ventas ya que va
relacionado con facturas
Evaluación de la Prueba: Aceptada
Fuente: Elaboración propia

Reporte de inventarios: A continuación, se muestra la prueba de aceptación de la historia de

usuario de Reporte de inventarios (Ver tabla 3.71):

Tabla 3.71 Prueba de Aceptación – Reportes de Inventario

CASO DE PRUEBA DE ACEPTACIÓN
Código: 13 Historia de Usuario: H13: Reportes de Inventarios
Descripción:
• Controlar que se genere el reporte mostrando datos correctos.
Condiciones de Ejecución: Servidor ejecutándose, ingresar al módulo de reporte de
inventarios.
Entrada/ Pasos de ejecución: El Gerente, Encargado de almacén acceden al módulo y
el personal que tenga asignado a su rol este módulo.
Resultado Esperado: El sistema muestra información real en los reportes de
inventarios
Evaluación de la Prueba: Aceptada
Fuente: Elaboración propia

138
Reporte de facturación: A continuación, se muestra la prueba de aceptación de la historia de

usuario de Reporte de facturación (Ver tabla 3.72):

Tabla 3.72 Prueba de Aceptación – Reportes de Facturación

CASO DE PRUEBA DE ACEPTACIÓN
Código: 14 Historia de Usuario: H14: Reportes de Facturación
Descripción:
• Controlar que se genere el reporte mostrando datos correctos.
Condiciones de Ejecución: Servidor ejecutándose, ingresar al módulo de reporte de
facturación.
Entrada/ Pasos de ejecución: El Gerente, Encargado de almacén acceden al módulo y
el personal que tenga asignado a su rol este módulo.
Resultado Esperado: El sistema muestra información real en los reportes de
facturación.
Evaluación de la Prueba: Aceptada
Fuente: Elaboración propia

Reporte de entradas y salidas de productos: A continuación, se muestra la prueba de aceptación

de la historia de usuario de Reporte de entradas y salidas de productos (Ver tabla 3.73):

139
 Tabla 3.73 Prueba de Aceptación – Reportes de Entradas y Salidas
CASO DE PRUEBA DE ACEPTACIÓN
Historia de Usuario: H15: Reportes de entradas y
Código: 15
salidas
Descripción:
• Controlar que se genere el reporte mostrando datos correctos.
Condiciones de Ejecución: Servidor ejecutándose, ingresar al módulo de reporte de
entradas y salidas.
Entrada/ Pasos de ejecución: El Gerente, Encargado de almacén acceden al módulo y
el personal que tenga asignado a su rol este módulo.
Resultado Esperado: El sistema muestra información real en los reportes de entradas
y salidas.
Evaluación de la Prueba: Aceptada
Fuente: Elaboración propia

140
CAPÍTULO IV MÉTRICAS DE CALIDAD

4.1 Introducción

Los sistemas Web están en constante crecimiento, por tanto, la utilización sistemática y

disciplinada de métodos, modelos y técnicas de Ingeniería de Software para el desarrollo, el

mantenimiento, y la evaluación de la calidad de los sitios Web debería ser un requerimiento

obligatorio, principalmente en los proyectos de mediana o gran escala. Una de las metas principales

de la evaluación y comparación de calidad de artefactos Web, radica en medir, analizar y

comprender el grado de cumplimiento de un conjunto de características y atributos con respecto a

los requerimientos de calidad establecidos, para un perfil de usuario y dominio de aplicación

dados.

4.2 Calidad

La calidad de un producto de Software debe evaluarse usando un modelo de calidad, midiendo

atributos internos (típicamente, medidas estáticas de productos intermedios), o puede ser evaluada

midiendo atributos externos (típicamente, medidas de comportamiento del código cuando se está

ejecutando). Además, el objetivo de un producto es que tenga el efecto requerido en un contexto

de uso particular.

En el proceso de evaluación de requerimientos de calidad de artefactos Web complejos, se

observa la necesidad de contar con la metodología cuantitativa, integrada, flexible y robusta, que

se apoye en principios y prácticas de Ingeniería de Software para la evaluación y comparación y

características y atributos, con el objetivo de obtener resultados justificables.

141
 Las metodologías para evaluar la calidad de uso que se adoptara en el presente proyecto

denominado Sistema Integrado Académico es Web-Site QEM (Quality Evaluación Method),

siguiendo las fases de dicha metodología.

4.3 Metodología de evaluación de calidad de sitios WEB (WEBSITE QEM)

En esta fase se sigue los pasos y actividades para la evaluación de la calidad utilizando la

metodología Web-Site QEM, siguiendo las tareas propias de cada fase.

4.3.1 Definición y especificación de requerimientos de calidad

En esta fase se define un conjunto de propiedades (atributos y características), de los

requerimientos de calidad los cuales deben responder a necesidades de un perfil de usuario,

teniendo como base el árbol propuesto por las metodologías Web-Site QEM.

El árbol de requerimientos para el Sistema Integrado Académico se muestra a continuación en

la siguiente tabla.

142
Tabla 4.1. Árbol de requerimientos de calidad para el Sistema Integrado Académico

Fuente: Elaboración propia

143
4.3.2 Criterio de preferencia de calidad elemental

Para esta fase se determina los criterios de evaluación cuantificable, que se aplicara en los

criterios de preferencia Elemental del modelo Web-Site QEM.

El tipo de criterio elemental que se utilizara, es el criterio de preferencia elemental absoluta de

variable discreta ya que emplea para determinar la preferencia absoluta discreta.

Se debe determinar los valores de las variables de preferencias de calidad elemental (IEi) para

cada atributo Ai (hojas de árbol de requerimientos, es importante mencionar que cada atributo Ai

tendrá asociado una variable Xi ∈ R, que tomará un valor real a partir de un proceso de medición

el cual producirá un valor de IEi que interpreta el porcentaje del requerimiento satisfecho).

4.3.3 Especificación de atributos

Se debe especificar los atributos del árbol existente para encontrar los índices de calidad

elemental (IEi), estos índices se utilizaron en los diferentes criterios de evaluación descritos a

continuación.

CVN (Criterio de Variable Normalizada):

Indicador Elemental (IE) = (X/Y) *100% Donde:

X = ∑𝑃𝑢𝑛𝑡𝑎𝑗𝑒 𝑚á𝑥𝑖𝑚𝑜

Y = ∑𝑃𝑢𝑛𝑡𝑎𝑗𝑒 𝑜𝑏𝑡𝑒𝑛𝑖𝑑𝑜

CN (Criterio Normalizado):

144
 Indicador Elemental (IE) = (X/Y) *100% Donde:

X = Cantidad Total de datos para la variable.

Y = Cantidad Total de datos.

CB (Criterio Binario):

Indicador Elemental (IE) = 0 si no existe.

Indicador Elemental (IE) = 1 si existe.

CMN (Criterio Multinivel):

Indicador Elemental (IE) = 0 Ausente

Indicador Elemental (IE) = 1 Presente Parcial

Indicador Elemental (IE) = 2 Presente

CPD: Sujeto a la objetividad del observador.

4.3.4 Definición e implementación de la evaluación elemental

Partiendo el árbol de requerimientos para cada uno de los atributos Ai determinar la variable Xi

que tomara un valor real a partir del proceso de medición.

Asimismo, para cada variable Xi se deberá hacer corresponder una preferencia elemental IEi,

(Ver tabla 4.2) donde se muestra los valores de los criterios elementales para cada uno de los

atributos la característica de la usabilidad.

145
 Tabla 4.2. Resultados de preferencia elementales de Usabilidad

Fuente: Elaboración propia

La tabla 4.3 muestra los valores de los criterios elementales para cada uno de los atributos la

característica de la funcionalidad.

Tabla 4.3. Resultados de preferencia elementales de Funcionalidad

146
 Fuente: Elaboración propia

La tabla 4.4 muestra los valores de los criterios elementales para cada uno de los atributos la

característica de la confiabilidad.

147
 Tabla 4.4. Resultados de preferencia elementales de Confiabilidad

Fuente: Elaboración propia

La tabla 4.5 muestra los valores de los criterios elementales para cada uno de los atributos la

característica de la eficiencia.

Tabla 4.5. Resultados de preferencia elementales de Eficiencia

Fuente: Elaboración propia

Los valores obtenidos en la evaluación elemental se resumen (Ver tabla 4.6) para obtener la

evaluación global del Sistema Integrado Académico.

Tabla 4.6. Resumen Global de Calidad

Fuente: Elaboración propia

148
 Para hallar la calidad global del sistema, obtenemos el promedio porcentual de todas las

métricas ya realizadas.

Así la calidad global será:

𝑢𝑠𝑎𝑏𝑖𝑙𝑖𝑑𝑎𝑑 + 𝑓𝑢𝑛𝑐𝑖𝑜𝑛𝑎𝑙𝑖𝑑𝑎𝑑 + 𝑐𝑜𝑛𝑓𝑖𝑎𝑏𝑖𝑙𝑖𝑑𝑎𝑑 + 𝑒𝑓𝑖𝑐𝑖𝑒𝑛𝑐𝑖𝑎

𝐶𝑎𝑙𝑖𝑑𝑎𝑑𝐺𝑙𝑜𝑏𝑎𝑙 =
4

86.33% + 94.0% + 88.0% + 100.0%

𝐶𝑎𝑙𝑖𝑑𝑎𝑑𝐺𝑙𝑜𝑏𝑎𝑙 =
4

378.33%
𝐶𝑎𝑙𝑖𝑑𝑎𝑑𝐺𝑙𝑜𝑏𝑎𝑙 =
4

𝐶𝑎𝑙𝑖𝑑𝑎𝑑𝐺𝑙𝑜𝑏𝑎𝑙 = 94.5825% ≈ 94.58%

De acuerdo a la valoración de la calidad del sitio web, aplicando la metodología Web-Site QEM

el valor obtenido de la calidad global es 82.28%, el cual está definido dentro de los márgenes de

satisfacción (60% a 100%). (Olsina, 2002)

149
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 de la rentabilidad de un proyecto, mediante la 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 para la toma de decisiones.

5.2 Evaluación de costo y beneficio

Como se conoce una de las tareas de mayor importancia en la planificación de proyectos de

software es la estimación, la cual cosiste en determinar, con cierto grado de certeza, los recursos

de hardware y software, costo, tiempo y esfuerzo necesario para el desarrollo de los mismos.

5.2.1 Análisis de costos

Como se mencionó anteriormente en el capítulo 2 modelo de costo o COCOMO, es un modelo

de estimación de costos de software, orientado a la magnitud del producto final, midiendo el

tamaño del proyecto en líneas de código principalmente. El modelo provee tres niveles de

aplicación: Básico, Intermedio y Avanzado, basándose en los factores considerados por el modelo.

La ecuación de COCOMO es este modelo básico es:

𝐸 = 𝑎 ∗ 𝐾𝐿𝑂𝐶 𝑏

𝐷 = 𝑐 ∗ 𝐸𝑑

150
 𝑃 = 𝐸/𝐷

Donde E es el esfuerzo aplicado en personas por mes, D es el tiempo de desarrollo en meses,

KLOC es el número de líneas de código estimadas para el proyecto (en miles) y P es el número de

personas necesarias. Los coeficientes a, b, c, d se obtienen (Ver tabla 5.1):

Tabla 5.1. Coeficientes, Modelo Básico

Fuente: Elaboración propia

Para el proyecto se considera el modo orgánico y se realizaron los siguientes cálculos:

a = 2.4, b = 1.05, c = 2.5, d = 0.38, KLOC = 20

𝐸 = 2.4 ∗ 201.05 = 55.76 [Personas /mes]

𝐷 = 2.5 ∗ 55.760.38 = 11.52 Meses

55.76
𝑃= = 4.84 𝑃𝑒𝑟𝑠𝑜𝑛𝑎𝑠
11.52

Para mejorar esta estimación aplicamos el modelo intermedio Post-Arquitectura este añade al

modelo básico quince modificadores opcionales para tener en cuenta en el entorno de trabajo,

incrementado así la precisión de la estimación seleccionamos nuestros calificadores para cada

atributo, (Ver tabla 5.2.).

151
 Tabla 5.2 Selección de multiplicadores de Esfuerzo

Fuente: Elaboración propia

Tenemos cantidad de líneas de código físicas 20000 LDC lo que equivale a 20 KLDC, usaremos

el tipo orgánico ya que nuestro proyecto no supera las 50 KLCD, y es el más apropiado en este

caso los coeficientes a y b se obtienes de la tabla

152
 Tabla 5.3 Coeficientes, Modelo Intermedio

Fuente: Elaboración propia

El esfuerzo 𝐸 = 𝑎 𝐾𝐿𝐷𝐶𝐷𝑏 ∗ ∏15

𝑖=1 𝐸𝑀𝑖

E = 3.20 ∗ 201.05 (0.88 ∗ 1 ∗ 1 ∗ 1.11 ∗ 1 ∗ 1 ∗ 1.07 ∗ 0.86 ∗ 1 ∗ 0.86 ∗ 1 ∗ 0.95 ∗ 0.91 ∗ 0.83 ∗ 1)

E = 41.23 [personas / mes]

El tiempo de desarrollo 𝑫 = 𝒄 ∗ 𝑬𝒅

𝐷 = 2.5 ∗ 41.230.38 = 10.27 meses

𝐸 41.23
Número de personas necesarias 𝑝 = 𝐷 = 10.27 = 4.01 personas

𝐿𝐶𝐷 16000 𝐿𝐶𝐷

Productividad 𝑃𝑅 = = = 654
𝐸 24.47 𝑝𝑒𝑟𝑠𝑜𝑛𝑎𝑠 𝑚𝑒𝑠

Considerando que el sueldo de un desarrollador depende de la experiencia del mismo y es un

valor muy subjetivo, se da valor según la oferta de los programadores en el mercado de 1300 Bs.

Realizando los costos necesarios para implantar el sistema se tiene la siguiente tabla:

Tabla 5.4. Costo estimado

Fuente: Elaboración propia

153
 Lo que nos lleva a que el costo estimado es de 25000 Bs.

5.2.2 Beneficios

Para evaluar el beneficio se calculará con el método del Valor Actual Neto (VAN) y la tasa

interna de Retorno (TIR).

5.2.2.1 Valor Actual Neto (VAN)

El Valor Actual Neto (VAN), es un método cuya principal aplicación es determinar la

rentabilidad de una inversión. Como su nombre indica, trata de determinar el valor que ahora tiene

la inversión sobre la base de los importes que se percibirán en plazos determinados. Para

complementar, junto a la Tasa Interna de Rentabilidad (TIR), se dará una idea bastante clara de la

factibilidad/rentabilidad del proyecto de inversión.

El VAN se calcula por medio de los flujos de inversión, cuyo resultado refleja si la inversión

en el proyecto genera beneficios o no. Su fórmula es la siguiente:

𝐺𝑎𝑛𝑛𝑐𝑖𝑎𝑠
𝑉𝐴𝑁 = ∑ (1+𝑘) 𝑛
−1o

Donde:

• Ganancias: ingreso del flujo anual

• Io: es el valor del desembolso inicial de la inversión

• n: es el número de periodos considerados

• k: tasa de descuento o tasa de interés de la inversión

154
 Los valores de ganancia esperados para el presente proyecto se calculan para 4 años, para este

caso en particular utilizaremos una tasa de descuento del 11%, ya que es la tasa actual de interés

de préstamo en las entidades financieras. Para calcular el valor del VAN se tiene lo siguiente:

Inversión = 25000 Bs = 3591.95 $us

TD = 11%

Los valores de ganancia esperados se detallan en la siguiente tabla:

Tabla 5.5. Cantidad nominal por año

Fuente: Elaboración propia

Para hallar el VAN tenemos:

4200 4400 4700 5100

𝑉𝐴𝑁 = (1+0.11)1 + (1+0.11)2 + (1+0.11)3 + (1+0.11)4 −3591.95

VAN = 14151.0499 $us = 98491.31 Bs

Como el valor obtenido del VAN es mayor a cero, se puede afirmar que el proyecto es rentable.

5.2.2.2 Tasa interna de retorno (TIR)

El TIR es una tasa de descuento TD de un proyecto de inversión para que sea rentable. Cuando

el VAN toma un valor igual a 0, k pasa a llamarse TIR. En términos generales: Las inversiones

más interesantes son aquellas que proporcionan mayor TIR.

155
 • Si TIR es inferior a la tasa de descuento de la empresa, la inversión debería ser

desestimada.

• Si TIR es superior la tasa de descuento de la empresa la inversión es factible.

𝑄1 𝑄2 𝑄𝑛
𝑇𝐼𝑅 = −10 + 1
+ 2
+ ⋯+
(1 + 𝐾 ) (1 + 𝑘 ) (1 + 𝑘 )𝑛

• Io: es el valor del desembolso inicial de la inversión

• n: es el número de periodos considerados

• k: tasa de descuento o tasa de interés de la inversión

Entonces para hallar el TIR se necesita la inversión de 3591.95 $us.

Para hallar el TIR se hace uso de la fórmula del VAN, solo hace que el valor de VAN sea igual

a 0, se tiene la siguiente ecuación:

4200 4400 4700 5100

𝑂 = −3591.95 + 1
+ 2
+ 3
+
(1 + 𝑇𝐼𝑅) (1 + 𝑇𝐼𝑅) (1 + 𝑇𝐼𝑅) (1 + 𝑇𝐼𝑅)4

TIR= 34%

Se tiene en el cálculo que la tasa interna de retorno es superior a la tasa de descuento; por lo

tanto, la inversión es factible.

5.3 Costo / Beneficio

Para hallar el costo beneficio de un proyecto se aplica la siguiente ecuación:

𝐶: 𝐶𝑜𝑠𝑡𝑜
B: Beneficio

156
Reemplazando los valores previamente calculados en la ecuación, tenemos:

𝐶 25000
= = 0.25
B 98491.31

Por tanto, por cada boliviano invertido, la empresa tiene una ganancia de 0.25 ctvs.

157
CAPÍTULO VI SEGURIDAD DEL SISTEMA

6.1 Introducción

La seguridad de un sistema, se lo define como un conjunto de medidas preventivas que se

aplican para el resguardo y la protección de la información, buscando siempre mantener la

confidencialidad, la disponibilidad y la integridad del mismo.

Así también, se tomó en cuenta aspectos como; la seguridad física (Infraestructura), la seguridad

lógica, misma que es catalogada por niveles y se hace uso de las recomendaciones que propone la

metodología OWASP,

6.1.1 Seguridad Física

La Red de Ópticas “Virtual” cuenta con un circuito cerrado de cámaras de video vigilancia en

cada sucursal, mismas que están instaladas tanto en el exterior como en el interior de cada una.

6.1.2 Seguridad Lógica

En esta parte, se tomó en cuenta los siguientes aspectos, la seguridad a nivel del sistema

operativo, seguridad a nivel del sistema de gestión de la base de datos y a nivel de la aplicación

desarrollada.

6.1.2.1 Seguridad a Nivel del Sistema Operativo

Las medidas de seguridad que se tomaron para evitar vulnerabilidades a nivel del sistema

operativo fueron las siguientes:

158
 ▪ Colocación de un pasword.

▪ Se bloqueó la línea de comandos del sistema operativo (cmd).

▪ Se bloqueó la opción de ejecutar del sistema operativo solamente el administrador puede

hacer uso del mismo.

▪ Mediante el uso de la herramienta bitlocker se encriptó los discos duros de la empresa,

al cual solamente el administrador del sistema tiene acceso.

▪ Solamente el administrador del sistema tiene acceso al sistema TPLINK para la

modificación de las contraseñas del wifi y otros.

Cabe mencionar que todas las computadoras de empresa cuentan con un sello de garantía.

6.1.2.2 Seguridad a Nivel del Sistema de Gestión de Base de Datos

En este tipo de nivel las medidas que se tomaron fueron las siguientes:

▪ Se deshabilitó cualquier acceso vía http tanto a la parte de administración como a la API

Rest.

▪ Se creó el usuario admin con el role “root” en la base de datos admin, para que solo este

pueda tener acceso a la base de datos.

▪ Se tiene un plan de backups y recuperación de la base de datos.

▪ Las conexiones entrantes y salientes utilizan la configuración TLS / SSL.

▪ El motor de almacenamiento Wired Tiger se lo ha configurado para que pueda encriptar

los datos en la capa de almacenamiento.

159
6.1.2.3 Seguridad a Nivel Aplicación desarrollada (OWASP)

Para este nivel lo que se hizo fue utilizar las recomendaciones de la metodología OWASP, las

cuales se las describen a continuación:

• Pentest Externo: El objetivo de este tipo de test, es acceder en forma remota a los

equipos de la institución y posicionarse como administrador del sistema. Se compone

de un número considerable de pruebas.

• Validación de Entradas: Las entradas de las diversas interfaces de captura de datos

fueron validadas mediante:

o Input Validation: Se verificó que la aplicación valida los datos ingresados en

los distintos formularios y campos de ingreso de la aplicación.

o Link Transversal: Se intentó identificar URLs no utilizadas por la aplicación,

enumerando las mismas o bien obteniéndolas del código fuente de una URL

activa.

o Path Truncation: Se intentó truncar las URLs activas para obtener el listado de

los archivos fuente desprotegidos.

o Common File Checks: Mediante la alteración de URLs, se intentó identificar y

acceder a los archivos ocultos o no disponibles para los usuarios.

o Hidden Web Paths: Se intentó identificar paths, referencias dentro del código

fuente del sitio o líneas comentadas con la finalidad de identificar URLs no

autorizadas.

160
 Como conclusión de esta fase, se pudo determinar que el nivel de probabilidad de riesgo es

medio.

▪ Administración de Sesión: Se intentó realizar la contaminación de cookies y variables

de sesión mediante el uso de la prueba Session Hijacking. El portal permite intentar un

número determinado de intentos de ingreso al sistema, por lo que este ataque no es

latente y sujeto a programas que intenten descubrir la contraseña por fuerza bruta.

▪ No se identificaron vulnerabilidades respecto a las restricciones a nivel de autenticación

para el acceso al sistema. El nivel de probabilidad de riesgo es bajo.

▪ De igual forma los inicios de sesión de un determinado usuario en diversas terminales

están controlados, el sistema no permite sesiones simultáneas, de una misma o de

diferentes IP sean estas internas o externas. Por lo que se determinó que el nivel de

probabilidad de riesgo es bajo.

▪ Infraestructura: Se verificó que el sistema no es vulnerable a ataques Cross-

FrameScripting (XFS). Es decir que los atacantes no pueden aprovecharse de las fallas

que tengan algunos navegadores para acceder a los datos privados de un tercer sitio web.

Se concluyó que su nivel de riesgo es bajo.

▪ Pérdida de Control de Acceso: A través de este tipo de prueba lo que se hizo fue buscar

la elevación de privilegios, es decir, actuar como un usuario sin iniciar sesión o actuar

como un administrador con una cuenta estándar. Así también se verifico el acceso

forzado a páginas autenticadas como un usuario no autenticado o con un privilegió que

no le corresponde, para ello se hizo uso del método de inyección Json. Esta prueba

161
 corresponde a la recomendación OWASP A5. Al finalizar las pruebas se concluyó que

tiene una probabilidad de riesgo baja.

▪ Revelación de la Información: En esta parte se intentó revelar información relacionada

a la administración de contraseñas del usuario. Este tipo de prueba corresponde a la

recomendación A6 de OWASP. Cabe mencionar que el sistema cuenta con el tipo de

cifrado de datos denominado SHA1. Al final de la prueba se pudo determinar que el

nivel de probabilidad de riesgo es bajo.

▪ Uso de Componentes con vulnerabilidades Conocidas: Mediante el uso del

analizador retire.js se hizo pruebas para determinar las vulnerabilidades en los

componentes que conforman el sistema y si estos están actualizados y configurados

correctamente, esta prueba corresponde a la recomendación A9 de OWASP. Al final de

las pruebas realizadas se determinó que tiene una probabilidad de riesgo media.

▪ Registro y Monitoreo Insuficientes: Se realizó una serie de pruebas para determinar

el nivel de vulnerabilidad del sistema cuando no tiene un monitoreo y registro adecuado,

se verifico los inicios de sesión, los fallos a la hora de iniciar sesión, las advertencias,

los umbrales de alerta y las pruebas de penetración que se realizaron con diferentes

herramientas, se pudo verificar que no existe una monitorización y alerta efectivos

acerca de actividades que se realizan en el sistema, por lo cual se determinó que el grado

de probabilidad de riesgo es alto, pero el impacto a nivel del negocio es mediano. Esta

prueba corresponde a las recomendaciones OWASP A10.

162
6.1.2.4 Ataque Interno

En esta etapa lo que se hizo fue utilizar puentes internos para determinar las vulnerabilidades y

la seguridad interna.

Se estableció que puede hacer un atacante interno y hasta donde es capaz de penetrar en el

sistema siendo un usuario con privilegios bajos. Este test también incluyó pruebas de:

▪ Análisis de protocolos internos y sus vulnerabilidades

▪ Autenticación de usuarios

▪ Verificación de permisos y recursos compartidos

▪ Test de los servidores principales (WWW, DNS, FTP, SMTP, etc.)

▪ Nivel de detección de la intrusión de los sistemas

▪ Análisis de la seguridad de las estaciones de trabajo

▪ Verificación de reglas de acceso

▪ Ataques de Denegación de Servicio.

163
CAPÍTULO VII CONLUSIONES Y RECOMENDACIONES

7.1 Conclusiones

El desarrollo e implementación del Sistema Web de control de inventarios, ventas de productos

de la empresa Red de Ópticas “VIRTUAL” fue exitoso, lográndose alcanzar el objetivo general

planteado en el presente proyecto, así como los objetivos específicos:

▪ Se logró proporcionar un eficaz y rápido acceso a la información, que evite la pérdida

de tiempo del personal, empleándolo en procesos más productivos.

▪ Se estableció los accesos y permisos adecuados para los diferentes roles de usuarios,

que permita realizar a cada usuario sus actividades adecuadamente.

▪ Se logró proporcionar las opciones necesarias a los usuarios para la actualización de la

base de datos del sistema.

▪ Se tiene un control sobre la disponibilidad de productos que se encuentran en almacén

para brindar un mejor servicio a sus clientes.

▪ Se estableció un correcto registro de nuevos productos con las características necesarias.

▪ Se consiguió generar los reportes estratégicos a solicitud de la empresa para el control

de inventario y ventas de productos, brindando información rápida y confiable para

apoyar una mejor toma de decisiones en la empresa.

Es importante destacar que hoy en día para que una empresa sea altamente competitiva es

necesario contar con información acertada, el sistema implementado según a las necesidades y

requerimientos de la empresa cumple con todos los objetivos planteados, de manera que la

164
información se encuentre a disposición del cliente para un mejor control de sus procesos. Esto se

logró mediante la ejecución de las fases propuestas por la metodología XP.

Para finalizar, se evidencio que la implementación de nuevas tecnologías en empresas para

mejorar y automatizar sus procesos, así como, la integración de metodologías y arquitecturas como

en este caso fueron XP, WebML, lograron el buen desarrollo del proyecto y la integración de

información.

7.2 Recomendaciones

A partir del presente trabajo, en cuanto a la empresa Red de Ópticas” VIRTUAL” en general se

propone las siguientes recomendaciones:

▪ Se recomienda adicionar un sistema de control de asistencia de personal, dado que los

empleados no cuentan con este sistema.

▪ Se recomienda extender el sistema a un entorno móvil.

▪ Se recomienda utilizar la metodología XP en proyectos cortos y medianos, para

disminuir el tiempo de desarrollo.

165
BIBLIOGRAFÍA

Barraza F, s.a Metodologías de Diseño de Aplicaciones Web Parte B, Maestría en

Ingeniería

Beck, Kent (2003) “Addison -Wesley Professional – Una explicación de la

Programación wExtrema”, USA

Brambilla M., Butti S. 2006 Quince años de desarrollo industrial model -driven de
aplicaciones front-end: desde webml hasta WebRatio e IFML, Politécnico
Milano, Milán Italia

Silvera, J. A., Figueroa, D., Gil, G., Diaz, M., Villanueva, E., Gonzales, V., Gil, D.
y Chauque, E. (2015). Metodología WEBML aplicada a un sistema de gestión
de calidad en centros de investigación. Facultad de Ciencias Exactas
Universidad Nacional de Salta.

Sommerville, I. (2005). Ingeniería de software (7ma ed.). Madrid: Pearson

Educación. Recuperado de:
http://zeus.inf.ucv.cl/~bcrawford/EnfoquesDeDesarrolloDeSwYLenguajesDe
Model

Torres, R. (2017). Departamento de Ingeniería Industrial, Universidad Nacional

Autónoma de México. Recuperado de:
https://es.scribd.com/document/299512441/Diseno -deLa-Cadena-de-
Suministro-Un-Enfoque-Sistemico

Almanza D., (2015) “Sistema de Registro, Seguimiento y Control de Tesis Caso:

Biblioteca Central”, mención a Ingeniera en Sistemas, Ecuador, Universidad
Estatal Península de Santa Elena Facultad de Sistemas y Telecomunicaciones
Escuela de Informática Carrera de Informática

166
Álvarez, J. R., & Arias, M. (s.f.). “Método Extreme Programming”. Recuperado de:
http://www.ia.uned.es/ia/asignaturas/adms/GuiaDidADMS/node61.html`

Anaya A., Plaza E. (2006) Programación Extrema XP (Extreme Programming), página

2, Cauca-Colombia

Arana J., 2014 “Desarrollo e implementación de un sistema de gestión de ventas de

repuestos automotrices en el almacén de auto repuestos eléctricos marcos en la
parroquia Posorja cantón Guayaquil, provincia del Guayas”, mención a
Ingeniera en Sistemas, Ecuador, Universid ad Estatal Península de Santa Elena
Facultad de Sistemas y Telecomunicaciones Escuela de Informática Carrera de
Informática.

Almanza D., 2015 “Sistema de Registro, Seguimiento y Control de Tesis Caso:

Biblioteca Central”, mención a Ingeniera en Sistemas, E cuador, Universidad
Estatal Península de Santa Elena Facultad de Sistemas y Telecomunicaciones
Escuela de Informática Carrera de Informática.

Álvarez, J. R., & Arias, M. (s.f.). “Método Extreme Programming”. [en línea]
<http://www.ia.uned.es/ia/asignaturas/adms/GuiaDidADMS/node61.html/>`
[16 de 05 de 2015]

Anaya A., Plaza E. (2006) Programación Extrema XP (Extreme Programming), página

2, Cauca-Colombia

Arana J., (2014) “Desarrollo e implementación de un sistema de gestión de ventas de

repuestos automotrices en el almacén de auto repuestos eléctricos marcos en la
parroquia Posorja cantón Guayaquil, provincia del Guayas”, mención a
Ingeniera en Sistemas, Ecuador, Universi dad Estatal Península de Santa Elena
Facultad de Sistemas y Telecomunicaciones Escuela de Informática Carrera de
Informática.

167
Fowler, M. y Beck, K. (2002). Refactoring: Improving the Design of Existing Code,
Addison Wesley. Recuperado de:
https://www.csie.ntu.edu.tw/~r95004/Refactoring_improving_the_design_of_
existin g_code.pdf

Gónzales, L. F., Reyes, A. X. y Vásquez, G.H. (2009). Diseño de aplicaciones web

basadas en arquitecturas orientadas a servicios (AOS), utilizando Webml.
Politécnico Colombiano Jaime Isaza Cadavid, Facultad de Ingenierías.
Recuperado de:
http://www.iiis.org/CDs2009/CD2009CSC/CISCI2009/PapersPdf/C553FU.pdf

Hernández, J. I. (2014). Análisis y Desarrollo Web. Recuperado de :

https://books.google.com.bo/books?id=nYDVBQAAQBAJ&printsec=fr ontcov
er&d

Joskowicz, J. (2008). Reglas y Prácticas en Extreme Programming. Recuperado de:

https://iie.fing.edu.uy/~josej/docs/XP%20 -%20Jose%20Joskowicz.pdf

Kendall, K. E. y Kendall, J. (2005). Análisis y diseño de sistemas (6ta ed.). México:

Pearson Educación. Recuperado de
https://books.google.com.bo/books?id=5rZA0FggusC&printsec=frontcover#v
=onepage&q&f=false

Laínez, J. R. (2014). Desarrollo de Software Ágil: Extreme Programming y Scrum.

Recuperado de
https://books.google.com.bo/books?id=M4fJCgAAQBAJ& printsec=frontcover
#v=o nepage&q&f=false

Letelier, P. y Penades, M. C. (2006). Metodologías agiles para el desarrollo de

software: eXtreme Programming (XP). Universidad Politécnica Valencia.
Recuperado de http://www.cyta.com.ar/ta0502/v5n2a1.htm

168
Loraine, G. (2012). Metodologías agiles y desarrollo basado en conocimiento.
Facultad de Informática Universidad Nacional de la Plata. Recuperado de:
http://sedici.unlp.edu.ar/bitstream/handle/10915/24942/Documento_completo
__.pdf %3Fsequence%3D1

Mallea, J. E. (2009). Ingeniería web. Carrera de Ingeniería Informática, Universidad

Autónoma Juan Misael Saracho, Tarija, Bolivia. Recuperado de:
http://juanedgarmallea.blogspot.com/2009/06/ingenieria -web.html

Meléndez, S. M. (2016). Metodología ágil de desarrollo de so ftware programación

extrema. Departamento de Computación Universidad Nacional Autónoma de
Nicaragua, Managua. Recuperado de
http://repositorio.unan.edu.ni/1365/1/62161.pdf

Mendoza, M. C. (2016). Sistema web de control de inventarios, manufacturación y

producto final para la empresa Industrial Comercial de Alimentos INCADEX
S.R.L. Carrera de Informática Universidad Mayor de San Andrés

Mongua, P. J. y Sandoval, H. E. (2009). Propuesta de un modelo de inventarios para

la mejora del ciclo logístico de una distribuidora de confites ubicada en la
ciudad de Barcelona, Estado Anzoátegui. Departamento de Computación y
Sistemas, Universidad de Oriente Núcleo de Anzoátegui. Recuperado de:
http://webquestcreator2.com/majwq/public/files/files_user/5098/Tesis.PROP
UEST A%20DE%20UN%20MODELO%20DE%20INVENTARIO.pdf

Montenegro, J. S. (2014). Sistema web de registro y control de unidades educativas

para la unidad de alimentación complementaria escolar (UNACE), Caso:
G.A.M.L.P. Carrera de Informática, Universidad Mayor de San A ndrés.
Recuperado de:
http://repositorio.umsa.bo/bitstream/handle/123456789/9270/T.2846.pdf?sequ
ence= 1

169
Montoya, C. A. y Boyero M. R. (2011). Los sistemas de información como
herramienta para la competitividad organizacional. Recuperado de
http://www.ceipa.edu.co/lupa/index.php/lupa/article/view/120/235

Mora, L. A. (2010). Gestión logística integral Las mejores prácticas en la cadena de

abastecimientos. Ecoe Ediciones. Bogotá. Recuperado de:
http://www.academia.edu/29853903/Gestion_Logistica_Integral__Lui s_An%
C3%ADbal_Mora_Garc%C3%ADa

Muugesan, S., Deshpande, Y., Hansen, S. & Ginige, A. (2001). Web Engineering: A
new discipline for development of web -based systems

Pérez, D., Sepúlveda, J. C., Oliveros, Y. I. (2011). Extreme Programming (XP):

Aplicación en un caso de estudio. Editorial Académica Española

Pressman, R. S. (2010). Ingeniería del software. Un enfoque práctico (7ma ed.).

México: McGraw-Hill Interamericana Editores, S.A. Recuperado de :
http://cotana.informatica.edu.bo/downloads/ldIngenieria.de. software.enfoque.
practico.7ed.Pressman.PDF

Quelca, V. (2016). Sistema web de control de compras, ventas e inventarios y

verificación de temperatura de medicamentos usando RFID y alarmas
tempranas caso: Farmacias la Casa de Salud. Carrera de Informática
Universidad Mayor de San Andrés

Quisbert, V. V. (2015). Sistema web de control de ventas e inventarios de insumos

caso: LA ESPAÑOLA. Carrera de Informática Universidad Mayor de San
Andrés.

Ramírez, F. S. (2013). Sistema de información para el servicio médi co del S.I.N.

(Servicio de Impuestos Nacionales). Carrera de Informática Universidad Mayor
de San Andrés Recuperado de:

170
 http://repositorio.umsa.bo/bitstream/handle/123456789/8701/T.2715.pdf?sequ
ence= 1

Riquelme, M. (2017_s.a.). La cadena de valor de Micha el Porter. Recuperado de:

https://www.webyempresas.com/la -cadena-de-valor-de-michael-porter/

Sánchez, M., Vargas, M., Reyes, B. A. y Vida, O. L. (2011). Sistema d información

para el control de inventarios del almacén del ITS. Departamento de Sistemas
y Computación, Instituto Tecnológico de Saltillo. Recuperado de:
http://www.redalyc.org/pdf/944/94419100007.pdf

Sevilla, P. (2014). Ingeniería web. Universidad de Managua. Recuperado de:

http://sevillajarquin.udem.edu.ni/?p=66

Silvera, J. A., Figueroa, D., Gil, G., Diaz, M., Villanueva, E., Gonzales, V., Gil, D.
y Chauque, E. (2015). Metodología WEBML aplicada a un sistema de gestión
de calidad en centros de investigación. Facultad de Ciencias Exactas
Universidad Nacional de Salta. Recuperado de:
http://sedici.unlp.edu.ar/bitstream/handle/10915/45929/Documento_completo.
pdf?s equence=1

Sommerville, I. (2005). Ingeniería de software (7ma ed.). Madrid: Pearson

Educación. Recuperado de
http://zeus.inf.ucv.cl/~bcrawford/EnfoquesDeDesarrolloDeSwYLenguajesDe
Model
ado/Ingenieria%20del%20Software%207ma.%20Ed.%20%20Ian%20Sommerv
ille.pdf

Torres, R. (2017). Departamento de Ingeniería Industrial, Universidad Nacional

Autónoma de México. Recuperado de:
https://es.scribd.com/document/299512441/Diseno -deLa-Cadena-de-
Suministro-Un-Enfoque-Sistemico

171
ANEXOS

ANEXO A – ÁRBOL DE PROBLEMAS

172
ANEXO B – ÁRBOL DE OBJETIVOS

173
ANEXO C – MARCO LÓGICO

174
DOCUMENTACIÓN