UNIVERSIDAD MAYOR DE SAN ANDRÉS

FACULTAD DE CIENCIAS PURAS Y NATURALES

CARRERA DE INFORMÁTICA

PROYECTO DE GRADO

SISTEMA WEB DE CONTROL DE COMPRAS, VENTAS E

INVENTARIOS
CASO: “ELECTROLUX”

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

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

POSTULANTE: NINOSKA ELIZABETH TUMIRI LOPEZ

TUTOR METODOLÓGICO: M. SC. ALDO VALDEZ ALVARADO
ASESOR: M. SC. GERMAN HUANCA TICONA

LA PAZ – BOLIVIA
2020
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

Este proyecto va dedicado en especial a mis padres Paulino Tumiri y Marcela Lopez, a mis
hermanos, a mi esposo, a mi hijo, a mis amigas y compañeros que me brindaron su apoyo,
consejos, en todo el camino, por enseñarme a no darme por vencida tan fácilmente y que
puedes lograr todo lo que te propongas siempre y cuando sea con determinación.
AGRADECIMIENTOS

A mis papitos por la paciencia, el esfuerzo, el cariño, que han tenido conmigo, mis hermanos
Estela, Elvira, Catalina, Marco, Claudia, Pamela y Daniela, por darme fuerza, por su
comprensión y por brindarme todo su apoyo.

A mi esposo y amigo Ronald por estar ahí alentándome, por acompañarme, por su
comprensión, y a mi pequeño hijo Anthony por ser mi motor.

A mi tutor metodológico M. Sc. Aldo Valdez Alvarado por la orientación, el conocimiento,

por ser un buen guía para poder realizar el Proyecto de Grado.

A mi asesor M. Sc. Germán Huanca Ticona, por su paciencia y comprensión para realizar las
revisiones, por sus recomendaciones para el desarrollo del Proyecto de Grado.

A los docentes por todas sus enseñanzas, por su paciencia.

A mi amiga Vanesa por su amistad, por todo el apoyo para terminar el proyecto de grado.

ii
 RESÚMEN

El presente proyecto se ha desarrollado en la Empresa Electrolux con la ayuda de la

administración, al estar preocupado con el proceso del control de compras, control de ventas,
control de inventarios, éstos principalmente que son difíciles de controlar de forma manual,
estos procesos eran realizados con formularios en Microsoft Excel sin ningún tipo de
limitación. La Empresa Electrolux no cuenta con un sistema de control sistematizado que
pueda controlar las compras, las ventas e inventarios, por lo que se desarrolló un sistema web
para el control de compras, ventas e inventarios, que requieren también de un control de
proveedores, facturación, control de personal y reportes a clientes, para optimizar el tiempo,
y un manejo adecuado de la información.

El proyecto fue realizado con la metodología de desarrollo de software OpenUp para el

análisis y diseño del sistema, para el modelado del sistema web se usó la propuesta de
Ingeniería Web basado en UWE, también se utilizó la herramienta de diagramación basada
en la web MagicDraw para representar los diferentes diagramas requeridos para el modelado
del sistema.

La empresa trabaja sobre la plataforma de Windows 7, 8 y 8.1, por lo que el sistema fue
desarrollado en un entorno WEB con PHP y como gestor de base de datos MySQL.

La calidad del sistema fue medida con la metodología WebQEM, también se realizó la
descripción de las medidas de seguridad para el correcto manejo del sistema y la medición
para el cálculo de costos se realizó con COCOMO II.

Palabras Clave: Metodología OpenUp, UWE, Sistema Web, COCOMO II.

iii
 ABSTRACT

This project has been developed in the Electrolux Company with the help of the
administration, being concerned with the process of purchasing control, sales control,
inventory control, mainly those that are difficult to control manually, these processes were
made with forms in Microsoft Excel without any limitations.

The Electrolux Company does not have a systematized control system that can control
purchases, sales and inventories, so a web system for the control of purchases, sales and
inventories is controlled, which can also be a supplier control, billing, personnel control and
reports to clients, to adapt the time, and an adequate handling of the information.

The project was carried out with the OpenUp software development methodology for the
analysis and design of the system, for the web system modeling the UWE-based Web
Engineering proposal was used, the web-based diagramming tool Lucidchart was also found
for represent the different diagrams required for system modeling.

The company works on the Windows 7, 8 and 8.1 platform, so the system was developed in
a WEB environment with PHP and as a MySQL database manager.

The quality of the system was measured with the WebQEM methodology, the description of
the security measures for the correct management of the system was also made and the
measurement for the calculation of costs was made with COCOMO II.

Keywords: OpenUp Methodology, UWE, Web System, COCOMO II.

iv
 ÍNDICE GENERAL

CAPÍTULO I .......................................................................................................................... 1
MARCO INTRODUCTORIO ................................................................................................ 1
1.1. INTRODUCCIÓN ........................................................................................................... 1
1.2. ANTECEDENTES .......................................................................................................... 2
1.2.1. ANTECEDENTES INSTITUCIONALES ................................................................... 2
1.2.1.1. MISIÓN ................................................................................................................ 2
1.2.1.2. VISIÓN ................................................................................................................ 2
1.2.1.3. OBJETIVOS......................................................................................................... 2
1.2.1.4. ORGANIGRAMA ............................................................................................... 3
1.2.2. ANTECEDENTES DE PROYECTOS SIMILARES .................................................. 4
1.3. PLANTEAMIENTO DEL PROBLEMA ........................................................................ 6
1.3.1. PROBLEMA CENTRAL ............................................................................................. 7
1.3.2. PROBLEMAS SECUNDARIOS ................................................................................. 7
1.4. DEFINICIÓN DE OBJETIVOS ...................................................................................... 7
1.4.1. OBJETIVO GENERAL ............................................................................................... 7
1.4.2. OBJETIVOS ESPECÍFICOS ....................................................................................... 7
1.5. JUSTIFICACIÓN ............................................................................................................ 8
1.5.1. JUSTIFICACIÓN ECONÓMICA ................................................................................ 8
1.5.2. JUSTIFICACIÓN SOCIAL ......................................................................................... 8
1.5.3. JUSTIFICACIÓN TECNOLÓGICA ........................................................................... 8
1.6. ALCANCES Y LÍMITES ............................................................................................... 9
1.6.1. ALCANCES ................................................................................................................. 9
1.6.2. LÍMITES ...................................................................................................................... 9
1.7. APORTES ..................................................................................................................... 10
1.7.1. PRÁCTICO ................................................................................................................ 10
1.7.2. TEÓRICO ................................................................................................................... 10

v
1.8. METODOLOGÍA .......................................................................................................... 10
CAPÍTULO II ....................................................................................................................... 12
MARCO TEÓRICO ............................................................................................................. 12
2.1. INTRODUCCIÓN ......................................................................................................... 12
2.2. INGENIERÍA DE SOFTWARE ................................................................................... 12
2.3. METODOLOGÍA DE DESARROLLO DE SOFTWARE ........................................... 12
2.3.1. MODELO DE DESARROLLO ÁGIL ....................................................................... 13
2.4. METODOLOGÍA DE DESARROLLO OPENUP ....................................................... 14
2.4.1. FASES DE OPENUP ................................................................................................. 15
2.4.2. ACTIVIDADES DE OPENUP .................................................................................. 17
2.4.3. ROLES DE OPENUP................................................................................................. 18
2.5. INGENIERÍA WEB ...................................................................................................... 19
2.6. METODOLOGÍAS WEB.............................................................................................. 20
2.6.1. METODOLOGÍA WEB BASADA EN UML (UWE) .............................................. 21
2.6.2. ACTIVIDADES DE MODELADO UWE ................................................................. 21
2.6.2.1. ESPECIFICACIÓN DE REQUERIMIENTOS ..................................................... 22
2.6.2.2. MODELO LÓGICO – CONCEPTUAL ................................................................. 23
2.6.2.3. MODELO DE NAVEGACIÓN .............................................................................. 24
2.6.2.4. MODELO DE PRESENTACIÓN .......................................................................... 25
2.6.3. FASES DE DESARROLLO UWE ............................................................................ 26
2.7. PLATAFORMA TECNOLÓGICA ............................................................................... 27
2.7.1. FRAMEWORK LARAVEL ...................................................................................... 27
2.7.2. LENGUAJES DE PROGRAMACIÓN ...................................................................... 27
2.7.2.1. PHP .......................................................................................................................... 27
2.7.3. BASE DE DATOS ..................................................................................................... 28
2.7.3.1. MYSQL ................................................................................................................... 28
2.7.4. HERRAMIENTAS ..................................................................................................... 28
2.7.4.1. SUBLIME TEXT .................................................................................................... 28

vi
2.8. COMPRA ...................................................................................................................... 29
2.8.1. CONTROL DE COMPRAS ....................................................................................... 29
2.9. VENTA.......................................................................................................................... 30
2.9.1. CONTROL DE VENTAS .......................................................................................... 30
2.10. INVENTARIO ........................................................................................................... 30
2.10.1. CONTROL DE INVENTARIOS ............................................................................. 31
2.11. PROCESO DE FACTURACIÓN ............................................................................... 33
2.12. CONTROL DE PERSONAL ...................................................................................... 33
CAPÍTULO III ..................................................................................................................... 35
MARCO APLICATIVO ...................................................................................................... 35
3.1. INTRODUCCIÓN ......................................................................................................... 35
3.1.1. RELACIÓN ENTRE OPENUP Y UWE ................................................................... 35
3.2. DESARROLLO ............................................................................................................ 37
3.2.1. DOCUMENTOS ENTREGABLES .......................................................................... 37
3.2.2. FASE DE INICIO ....................................................................................................... 38
3.2.2.1. MODELO DE REQUERIMIENTOS ...................................................................... 38
3.2.2.2. IDENTIFICACIÓN DE INTERESADOS (STAKEHOLDERS) ........................... 40
3.2.2.3. DESCRIPCIÓN DE POSIBLE SOLUCIÓN .......................................................... 41
3.2.2.4. VISIÓN GENERAL DEL SISTEMA .................................................................... 42
3.2.3. FASE DE ELABORACIÓN ...................................................................................... 45
3.2.3.1. ARQUITECTURA .................................................................................................. 45
3.2.3.2. ANÁLISIS ............................................................................................................... 45
3.2.3.3. DISEÑO .................................................................................................................. 55
3.2.4. FASE DE CONSTRUCCIÓN ................................................................................... 63
3.2.4.1. IMPLEMENTACIÓN ............................................................................................. 63
3.2.5. FASE DE TRANSICIÓN ........................................................................................... 67
3.2.5.1. PRUEBAS DE ESTRÉS ......................................................................................... 67
3.2.5.2. PRUEBA ................................................................................................................. 69

vii
CAPÍTULO IV ..................................................................................................................... 75
CALIDAD Y SEGURIDAD ................................................................................................ 75
4.1. INTRODUCCIÓN ......................................................................................................... 75
4.2. CALIDAD ..................................................................................................................... 75
4.2.1. METODOLOGÍA WEB - SITE QEM ....................................................................... 75
4.2.1.1. PRINCIPALES FASES, PROCESOS Y ACTIVIDADES DE WEB - SITE QEM75
4.2.1.2. TIPO DE CRITERIO ELEMENTAL...................................................................... 78
4.2.2. FASE DE DEFINICIÓN E IMPLEMENTACIÓN DE LA EVALUACIÓN
ELEMENTAL ...................................................................................................................... 78
4.2.2.1. CARACTERÍSTICAS Y ATRIBUTOS ................................................................. 78
i) USABILIDAD .............................................................................................................. 79
ii) FUNCIONALIDAD ...................................................................................................... 80
iii) CONFIABILIDAD ........................................................................................................ 82
iv) EFICIENCIA ................................................................................................................. 83
4.2.3. CALIDAD GLOBAL ................................................................................................. 83
4.3. SEGURIDAD ................................................................................................................ 84
4.4. SEGURIDAD POR NIVELES ..................................................................................... 84
4.4.1. SEGURIDAD A NIVEL DE BASE DE DATOS ...................................................... 84
4.4.2. SEGURIDAD A NIVEL DEL SERVIDOR .......................................................... 85
4.4.2.1. SERVIDOR WEB .................................................................................................. 85
4.4.3. SEGURIDAD A NIVEL DE APLICACIÓN ............................................................. 86
4.4.3.1. AUTENTICACIÓN................................................................................................. 86
4.4.3.2. CONTROL DE ACCESO ....................................................................................... 87
CAPÍTULO V ...................................................................................................................... 88
ANÁLISIS COSTO BENEFICIO ........................................................................................ 88
5.1. INTRODUCCIÓN ......................................................................................................... 88
5.2. MÉTODO COCOMO II ................................................................................................ 88
5.3. COSTO DEL PROYECTO ........................................................................................... 88
5.3.1. PUNTO FUNCIÓN .................................................................................................... 88

viii
5.3.1.1. CÁLCULO DE FACTOR DE AJUSTE DE LA COMPLEJIDAD ........................ 89
5.3.2. CONVERSIÓN DE PFA LDC (LÍNEAS DE CÓDIGO) .......................................... 90
5.3.3. ESTIMACIONES DE ESFUERZO Y ESTIMADO PARA HALLAR LA
DURACIÓN DEL PROYECTO .......................................................................................... 91
5.3.3.1. ESFUERZO NOMINAL ......................................................................................... 91
5.4. ESTIMACIONES DE DURACIÓN DE PROYECTO ................................................. 96
5.5. ESTIMACIÓN DEL PERSONAL DEL PROYECTO ................................................. 97
5.6. COSTO DE DESARROLLO ........................................................................................ 98
5.7. COSTO DE IMPLEMENTACIÓN Y ELABORACIÓN ............................................. 98
5.9. CÁLCULO BENEFICIO TIR Y VAN ......................................................................... 99
5.9.1. VALOR ACTUAL NETO (VAN) ............................................................................. 99
5.9.2. TASA DE INTERÉS DE RETORNO (TIR)............................................................ 101
5.10. COSTO BENEFICIO ................................................................................................ 101
CAPÍTULO VI ................................................................................................................... 103
CONCLUSIONES Y RECOMENDACIONES ................................................................. 103
6.1. CONCLUSIONES ....................................................................................................... 103
6.2. RECOMENDACIONES ............................................................................................. 103
BIBLIOGRAFÍA ................................................................................................................ 105
Anexo A - Árbol de problemas........................................................................................... 107
Anexo B - Árbol de objetivos ............................................................................................. 107
Anexo C - Marco Lógico .................................................................................................... 108

ix
 ÍNDICE DE FIGURAS

Figura 1.1. Organigrama de la empresa ELECTROLUX ----------------------------------------- 3

Figura 2.2. Sucursales de la empresa ELECTROLUX -------------------------------------------- 4
Figura 1.3. Elementos básicos de una metodología ---------------------------------------------- 11
Figura 2.1. Ciclo de Vida de un proyecto según OpenUp --------------------------------------- 15
Figura 2.2. Estructura básica y dependencias de la Especificación de Requerimientos ---- 23
Figura 2.3. Modelo Lógico -------------------------------------------------------------------------- 23
Figura 2.4. Modelo Conceptual --------------------------------------------------------------------- 24
Figura 2.5. Modelo de Navegación, UWE -------------------------------------------------------- 24
Figura 2.6. Estereotipos e iconos, Modelo de Navegación UWE ------------------------------ 25
Figura 2.7. Modelo de Presentación, UWE ------------------------------------------------------- 25
Figura 2.8. Estereotipos e iconos, UWE ----------------------------------------------------------- 26
Figura 3.1. Caso de uso principal ------------------------------------------------------------------- 46
Figura 3.2. Caso de uso secundario – Control de Compras ------------------------------------- 47
Figura 3.3. Caso de uso secundario – Control de Ventas --------------------------------------- 48
Figura 3.4. Caso de uso secundario – Control de Inventario ----------------------------------- 49
Figura 3.5. Caso de uso secundario – Control de Proveedores --------------------------------- 50
Figura 3.6. Caso de uso secundario – Facturación ----------------------------------------------- 51
Figura 3.7. Caso de uso secundario – Control de Personal ------------------------------------- 52
Figura 3.8. Caso de uso secundario – Reportes --------------------------------------------------- 53
Figura 3.9. Diagrama de Clases --------------------------------------------------------------------- 54
Figura 3.10. Modelo de Presentación - Control de Compras ----------------------------------- 55
Figura 3.11. Modelo de Presentación - Control de Ventas -------------------------------------- 55
Figura 3.12. Modelo de Presentación - Control de Inventario ---------------------------------- 56
Figura 3.13. Modelo de Presentación - Control de Proveedores ------------------------------- 56
Figura 3.14. Modelo de Presentación - Facturación --------------------------------------------- 57
Figura 3.15. Modelo de Presentación - Control de Personal ------------------------------------ 57
Figura 3.16. Modelo de Presentación - Reporte a Clientes ------------------------------------- 58

x
Figura 3.17. Modelo de Navegación - Control de Compras ------------------------------------ 58
Figura 3.18. Modelo de Navegación - Control de Ventas --------------------------------------- 59
Figura 3.19. Modelo de Navegación - Control de Inventario ----------------------------------- 59
Figura 3.20. Modelo de Navegación - Control de Proveedores -------------------------------- 60
Figura 3.21. Modelo de Navegación - Facturación ---------------------------------------------- 60
Figura 3.22. Modelo de Navegación - Control de Personal ------------------------------------- 61
Figura 3.23. Modelo de Navegación - Reporte a Clientes -------------------------------------- 61
Figura 3.24. Modelo Entidad - Relación ----------------------------------------------------------- 62
Figura 3.25. Modelo Relacional -------------------------------------------------------------------- 63
Figura 3.26. Sucursales de la Empresa ------------------------------------------------------------- 64
Figura 3.27. Artículos de la Empresa -------------------------------------------------------------- 65
Figura 3.28. Proveedores de la Empresa ----------------------------------------------------------- 65
Figura 3.29. Clientes de la Empresa ---------------------------------------------------------------- 66
Figura 3.30. Ventas de la Empresa ----------------------------------------------------------------- 66
Figura 3.31. Compras de la Empresa --------------------------------------------------------------- 67
Figura 3.32. Inventario de la Empresa ------------------------------------------------------------- 67
Figura 3.33. Resultado de la prueba con 50 usuarios en cada página ------------------------- 68
Figura 3.34. Resultado de la prueba con 100 usuarios en cada página ------------------------ 69
Figura 4.1. Fases de WebQEM --------------------------------------------------------------------- 76

xi
 INDICE DE TABLAS
Tabla 2.1. Fases de OpenUp ------------------------------------------------------------------------- 16
Tabla 2.2. Actividades de OpenUp ----------------------------------------------------------------- 17
Tabla 2.3. Roles de OpenUp------------------------------------------------------------------------- 18
Tabla 2.4. Fase de la Metodología Web ----------------------------------------------------------- 20
Tabla 2.5. Actividades de Modelado UWE ------------------------------------------------------- 21
Tabla 2.6. Fases de Desarrollo UWE--------------------------------------------------------------- 26
Tabla 3.1. Relación de los artefactos de OpenUp – UWE -------------------------------------- 36
Tabla 3.2. Documentos Entregables ---------------------------------------------------------------- 37
Tabla 3.3. Requerimientos funcionales del control de compras -------------------------------- 38
Tabla 3.4. Requerimientos funcionales del control de ventas ---------------------------------- 39
Tabla 3.5. Requerimientos funcionales del control de inventario ------------------------------ 39
Tabla 3.6. Requerimientos funcionales del control de proveedores --------------------------- 39
Tabla 3.7. Requerimientos funcionales del módulo de facturación ---------------------------- 40
Tabla 3.8. Requerimientos funcionales del control de personal -------------------------------- 40
Tabla 3.9. Requerimientos funcionales del control de reportes -------------------------------- 40
Tabla 3.10. Identificación de interesados ---------------------------------------------------------- 41
Tabla 3.11. Problemas relacionados al administrador del sistema ----------------------------- 41
Tabla 3.12. Problemas relacionados al personal administrativo ------------------------------- 42
Tabla 3.13. Problemas relacionados al cliente ---------------------------------------------------- 42
Tabla 3.14. Solución propuesta al control de compras ------------------------------------------ 43
Tabla 3.15. Solución propuesta al control de ventas --------------------------------------------- 43
Tabla 3.16. Solución propuesta al control de inventario ---------------------------------------- 43
Tabla 3.17 Solución propuesta al control de proveedores. -------------------------------------- 44
Tabla 3.18 Solución propuesta al módulo de facturación. -------------------------------------- 44
Tabla 3.19. Solución propuesta al control de personal ------------------------------------------ 44
Tabla 3.20. Solución propuesta al control de reportes ------------------------------------------- 45
Tabla 3.21. Especificaciones de caso de uso - Control de Compras -------------------------- 47
Tabla 3.22. Especificaciones de caso de uso - Control de Ventas----------------------------- 48

xii
Tabla 3.23. Especificaciones de caso de uso - Control de Inventario ------------------------ 49
Tabla 3.24. Especificaciones de caso de uso - Control de Proveedores ---------------------- 50
Tabla 3.25. Especificaciones de caso de uso - Facturación ------------------------------------ 51
Tabla 3.26. Especificaciones de caso de uso - Control de Personal -------------------------- 52
Tabla 3.27. Especificaciones de caso de uso - Reportes ---------------------------------------- 53
Tabla 3.28. Identificación de actores --------------------------------------------------------------- 54
Tabla 3.29. Herramientas de desarrollo ------------------------------------------------------------ 64
Tabla 3.30. Prueba de correspondencia - Control de Compras --------------------------------- 69
Tabla 3.31. Prueba de correspondencia - Control de Ventas ----------------------------------- 70
Tabla 3.32. Prueba de correspondencia - Control de Inventario ------------------------------- 71
Tabla 3.33. Prueba de correspondencia - Control de Proveedores ----------------------------- 71
Tabla 3.34. Prueba de correspondencia - Facturación ------------------------------------------- 72
Tabla 3.35. Prueba de correspondencia - Control de Personal --------------------------------- 73
Tabla 3.36. Prueba de correspondencia - Reporte a Clientes ----------------------------------- 74
Tabla 4.1. Resultados de preferencia elemental - Usabilidad----------------------------------- 79
Tabla 4.2. Resultados de preferencia elemental - Funcionalidad ------------------------------ 81
Tabla 4.3. Resultados de preferencia elemental - Confiabilidad ------------------------------- 82
Tabla 4.4. Resultados de preferencia elemental - Eficiencia ----------------------------------- 83
Tabla 4.5. Resultados - Calidad Global ------------------------------------------------------------ 84
Tabla 5.1. Interfaces Parámetros de medición ---------------------------------------------------- 88
Tabla 5.2. Cálculo de punto de función ajustada ------------------------------------------------- 89
Tabla 5.3. Factor de Ajuste -------------------------------------------------------------------------- 90
Tabla 5.4. Tabla de conversión factor LDC ------------------------------------------------------- 90
Tabla 5.5. Tabla de Factores de Escala ------------------------------------------------------------ 92
Tabla 5.6. Tabla de Factor de Escala Wj ---------------------------------------------------------- 93
Tabla 5.7. Tabla de multiplicadores del esfuerzo requerido ------------------------------------ 94
Tabla 5.8. Conductores de costo -------------------------------------------------------------------- 95
Tabla 5.9. Costo de implementación y elaboración del proyecto ------------------------------ 99
Tabla 5.10. Flujo de caja por año ------------------------------------------------------------------ 100

xiii
 CAPÍTULO I

MARCO INTRODUCTORIO

1.1. INTRODUCCIÓN

El avance de la tecnología ha ayudado a varias empresas con diferentes sistemas web, ya que
facilitan la labor a las empresas otorgando una información rápida para un mejor control y
manejo en las actividades que hay en cada empresa.

En la comunidad empresarial los sistemas web de control son una herramienta que le facilita
el trabajo. Cada vez las empresas son más dinámicas y tienen más control haciendo uso de
nuevas herramientas que agilicen el trabajo.

En la actualidad se encuentran empresas que siguen con el trabajo manual que les dificulta el
manejo y la actualización de datos, como es el caso de la empresa unipersonal
ELECTROLUX que desea mejorar el desempeño laboral.

Se informó a la empresa sobre los beneficios de tener un sistema web que le facilite el trabajo,
mejorando el control de sus actividades, contando coque el sistema web realice el control
dando solución a los problemas que se presenten, sobre todo en la actualización de datos.

Se realizará una interfaz con la herramienta framework Laravel. Para almacenar toda la
información y los registros que se realizará por el gerente respecto a cada control que se
programe, contará con una base de datos con la ayuda del gestor MySql, esperando cumplir
con los requisitos y necesidades de la empresa logrando un mejor desempeño en el trabajo.

El presente proyecto procura desarrollar un sistema web que controlará la compra, venta e
inventarios evitando que la empresa realice este trabajo de manera manual produciendo
pérdida de la información, resolviendo los problemas con los que cuenta, permitiendo que no
sea un trabajo moroso.
1.2. ANTECEDENTES

1.2.1. ANTECEDENTES INSTITUCIONALES

ELECTROLUX, empresa conformada el año 1991, comenzó sus actividades con la venta
puerta a puerta de equipos de limpieza comercializando aspiradora y lustradoras domésticas,
posteriormente se fueron conformando sucursales a nivel La Paz; llegando a distribuir
equipos de limpieza industriales, línea blanca (cocinas, heladeras, hornos). ELECTROLUX
en sus inicios fue representante de ELECTROLUX PERU.

ELECTROLUX es una empresa unipersonal que distribuye a nivel nacional toda la gama en
cuanto equipos y electrodomésticos de la marca ELECTROLUX, SOMELA, BOSH; además
de venta de repuestos y servicio técnico en general que llegan a garantizar los productos.

1.2.1.1. MISIÓN

Ofrecemos electrodomésticos con tecnología actualizada y diseño atractivo para el hogar y

otros ambientes; cumplimos con las expectativas del mercado, con el compromiso de brindar
el mejor servicio integral, estilo y calidad de vida.

1.2.1.2. VISIÓN
Seremos la mejor opción para los hogares en Bolivia, con creciente participación en el
mercado nacionales, con electrodomésticos de tecnología actualizada y diseño atractivo,
fundamentados en:
- Liderazgo en servicio integral a nuestros clientes.
- El gran valor de nuestras marcas en el país.
- Flexibilidad y capacidad de respuesta.
- Personal competente y de alto desempeño.
- Ser una empresa socialmente responsable.

1.2.1.3. OBJETIVOS
Los objetivos de la empresa son los siguientes:
- Innovación

2
- Satisfacción de clientes
- Crecimiento nacional
- Productividad y calidad
- Valorización de la Compañía
- Valor de nuestra gente

1.2.1.4. ORGANIGRAMA
En la figura 1.1 se observa la representación gráfica de la empresa:

Figura 1.1. Organigrama de la empresa ELECTROLUX

Fuente: ELECTROLUX, 2019

La empresa ELECTROLUX cuenta con una oficina central y tres sucursales:

- Oficina Central se encuentra en la zona de San Pedro, calle Otero de la Vega.

- Sucursal Calacoto se encuentra en la Av. Ballivián No. 788, esquina calle 9.
- Sucursal 20 de octubre se encuentra entre las calles Aspiazu y Fernando Guachalla,
Edificio La Paz, Sopocachi
- Sucursal Federico Suazo se encuentra en la zona central, calle Federico Suazo No.
1178, esquina Campero.

En la figura 1.2 se muestra las sucursales de la empresa:

3
 Figura 1.2. Sucursales de la empresa ELECTROLUX
Fuente: ELECTROLUX, 2020

1.2.2. ANTECEDENTES DE PROYECTOS SIMILARES

Se ha encontrado en la Universidad Mayor de San Andrés proyectos similares que a

continuación se da a conocer con su respectivo resumen:

“SISTEMA WEB DE CONTROL DE VENTAS E INVENTARIOS CASO:

MICHELLINE”
Autor: Patricia Aduviri Perez
Año: 2016
Institución: Universidad Mayor de San Andrés

4
Resumen: El presente proyecto fue desarrollado para el control de ventas e inventarios, así
saber el ingreso y egreso de productos, de acuerdo a ello poder distribuir de manera eficiente
a los puntos de ventas de la empresa Michelline logrando a la empresa mejorar sus ingresos.
El proyecto utilizó la metodología de desarrollo ágil se XP (Extreme Proramming) por su
versatilidad al momento de desarrollar, gracias a su trabajo por iteraciones, así mismo de
disponer de pocas herramientas útiles para el desarrollo del sistema. Para complementar a
XP se utilizó la metodología de Modelado WebML (Web Modeling Languaje) que es un
lenguaje de modelado para la especificación de Sistemas Web, proporcionando los modelos
complementarios a XP.
Para la implementación se utilizó como gestor de base de datos MySQL, además como
lenguaje de programación se utiliza PHP. La calidad del sistema se lo realizo bajo el estándar
ISO 9126 que evalúa aspectos como usabilidad, funcionalidad, confiabilidad, mantenibilidad
y portabilidad, proporcionando una evaluación tras la implementación del Sistema Web.

“APLICACIÓN MÓVIL DE CONTROL DE VENTAS E INVENTARIOS CON

ALERTAS TEMPRANAS
CASO: EMPRESA IMPORTADORA Y DISTRIBUIDORA DE ALIMENTOS E
INSUMOS PARA MASCOTAS SAN GABRIEL PET ”
Autor: Efrain Alberto Villca Apaza
Año: 2018
Institución: Universidad Mayor de San Andrés
Resumen: El proyecto hace referencia al desarrollo de una aplicación para plataformas
Android, con la cual se pretende ayudar al control de registro de ventas e inventarios para la
empresa San Gabriel PET.

Para el desarrollo de la aplicación móvil se utilizó la metodología Mobile-D cuyo enfoque y

características la hacen especialmente apta para el mercado de dispositivos móviles, donde
los requerimientos cambian constantemente y el software se requiere en el momento justo.
Se ha utilizado el Android Studio para el desarrollo de la aplicación móvil. Se creó una base

5
de datos SQLite para el almacenamiento de la información de manera interna. Para el mejor
entendimiento del proyecto se añadió un manual de usuario de la aplicación móvil.

“SISTEMA EN PLATAFORMA MIXTA PARA EL CONTROL DE VENTAS E

INVENTARIOS CON CÓDIGO QR CASO: IMPORTADORA LU.CE.R.”
Autor: Walter Calle Mamani
Año: 2018
Institución: Universidad Mayor de San Andrés
Resumen: El presente documento contiene el proceso de desarrollo de un sistema de
plataforma mixta para el control de ventas e inventarios, así saber el ingreso y egreso de
productos, donde los mismos comprenden de filtros, lubricantes y separadores de aceite, estos
tendrán la característica de tener pegado un código QR con la intención de capturar la
información del mismo de forma rápida, cómoda y eficientemente desde un dispositivo
móvil, de acuerdo a ello poder distribuir de manera eficiente los pedidos realizados por la
empresa distribuidora LU.CE.R. Logrando la mejora de sus ingresos y eficiencia.
Para lograr el desarrollo del proyecto, se ha hecho uso de la metodología extreme
Programming (XP) como metodología de desarrollo con apoyo del Lenguaje Unificado de
Modelado (UML) para el diseño.

1.3. PLANTEAMIENTO DEL PROBLEMA

La mala manipulación de la información que se genera en el registro de las compras, ventas

e inventario de los productos, ya que se la realiza de manera manual lo que podría generar
confusión al momento de la actualización de datos.
La empresa unipersonal ELECTROLUX utiliza programas de apoyo como Excel o solo
papeles (facturas, contratos, entre otros), que no les satisface con las opciones que requieren
para facilitar el trabajo, al no contar con un sistema web de control, no se tiene información
precisa y confiable que le ayude a tomar decisiones. Para optimizar los procesos de
organización para la empresa, es necesario tener un control total de las funciones y un
incremento de la calidad de resultados, eficiencia y rentabilidad.

6
1.3.1. PROBLEMA CENTRAL

¿Cómo mejorar el control de compras, ventas e inventarios de la empresa ELECTROLUX?

1.3.2. PROBLEMAS SECUNDARIOS

● Los informes de las compras, ventas e inventarios son realizados de forma manual,
provoca la pérdida económica en ventas y retraso en el registro.
● El acceso de la información no se da de forma ágil, genera pérdida de tiempo.
● Se hace uso de programas para inventarios que no ayudan con los requisitos de la
empresa, el registro de la compra y venta de productos es inseguro.
● Se tiene un control manual del ingreso y salida de los productos, existe riesgo de pérdida
de información sobre el inventario.
● La información sobre las compras, ventas e inventarios de cada sucursal no se encuentra
centralizada, ocasiona que las consultas retrasan a los estados financieros de las ventas,
riesgos de pérdidas de datos en capital.
● La facturación se realiza de forma manual, produciendo gastos por el uso de papel.
● No se tiene un control del personal del trabajo, ocasionando retraso en las tareas.
● No existe un reporte a clientes, ocasionando pérdida de estos.

1.4. DEFINICIÓN DE OBJETIVOS

1.4.1. OBJETIVO GENERAL

Desarrollar un sistema web de control de compras, ventas e inventarios para la empresa

ELECTROLUX, mejorando el manejo y la actualización de datos.

1.4.2. OBJETIVOS ESPECÍFICOS

● Generar registros de compras, ventas e inventarios.

● Obtener información de forma ágil.
● Facilitar el registro de artículos para obtener información correcta y actualizada para la
compra y venta.
● Actualizar información sobre el ingreso y salida de los artículos en el inventario.

7
● Centralizar información de cada sucursal.
● Automatizar la información de facturación.
● Producir el control del personal de trabajo.
● Realizar un reporte a los clientes de la empresa.

1.5. JUSTIFICACIÓN

1.5.1. JUSTIFICACIÓN ECONÓMICA

El presente proyecto proporciona un control de los procesos de compra, venta e inventarios,

facturación, control al personal de trabajo y reporte de clientes, disminuyendo la pérdida de
tiempo. Muy aparte de las necesidades de la empresa se automatizará la facturación para
evitar gastos en papel, control al personal de trabajo y reporte de los clientes evitando pérdida
de tiempo y clientes.

En el desarrollo del sistema se emplearán herramientas que reemplacen los trabajos de forma
manual y otros programas que no sean necesarios, los cuales generan un costo innecesario a
la empresa.

1.5.2. JUSTIFICACIÓN SOCIAL

El sistema web permite mejorar el trabajo del registro de compra, venta e inventarios,
facturación, control al personal de trabajo y reporte de clientes, porque permitirá información
ágil y actualizada al personal, otorgando un agradable ambiente de trabajo y brindando una
calidad de servicio. El personal de ventas realizará su trabajo con más facilidad y puntualidad,
en las distintas sucursales que están en la ciudad de la Paz.

1.5.3. JUSTIFICACIÓN TECNOLÓGICA

La empresa cuenta con las herramientas informáticas en hardware y software necesarias para
implementar y mantener el sistema web para el control de compras, ventas e inventarios,
facturación, control al personal de trabajo y reporte de clientes. El sistema web de control da

8
la posibilidad del seguimiento de la información de sus sucursales que se encuentran en la
ciudad de La Paz.
1.6. ALCANCES Y LÍMITES

1.6.1. ALCANCES

El proyecto estará disponible para los usuarios registrados, accediendo a los módulos de
acuerdo a sus funciones. El sistema contará con los siguientes módulos:

● Módulo de compras: registrar la compra que realiza la empresa a algún proveedor

registrado.

● Módulo de ventas: obtener los datos del cliente, registrar los productos que comprará el
cliente, registrar el modo de pago y verificar disponibilidad del producto por sucursales.

● Módulo de inventario: registrar los productos que ingresan a la empresa por los distintos
proveedores y tener información de las ventas.

● Módulo de proveedores: registrar los datos de los proveedores, editar la información del
proveedor, eliminar proveedor y registrar los productos que ofrecen cada proveedor.

● Módulo de facturación: mostrar detalles de la compra, datos cliente, nombre vendedor y

la totalidad del pago.

● Módulo de control de personal: registro de la información de cada trabajador que está

en la empresa, el horario y la asistencia.

● Módulo de reportes: se encargará de generar reportes que permitan al usuario tener una
información de los avisos en tiempo real de ofertas, informes periódicos y costos.

1.6.2. LÍMITES

Los límites del proyecto se mencionan a continuación:

● No se garantizará la satisfacción de cliente, ante un posible mal uso del sistema.

● La actualización de datos será realizada por el personal autorizado.

9
● No se implementará un control con huella digital para el personal de trabajo.
● El registro de los datos deberá realizarlo el personal administrativo.

1.7. APORTES

1.7.1. PRÁCTICO

Un sistema web beneficia a toda empresa que requiere de registros de compras, ventas e
inventarios. Este proyecto representa un gran beneficio para la empresa ELECTROLUX, que
por diferentes factores realizan hasta el momento un trabajo de forma manual.

El proyecto permite solucionar las necesidades para minimizar tiempos, mejor control y
seguimiento que se tiene que realizar.

Facilitar la labor de la empresa en las actividades que se realizan de forma manual,

automatizando los procesos que la empresa realiza como las ventas y pedidos de productos,
la centralización de la información en una base de datos que permite acceder de manera
inmediata a la información de las ventas y pedidos de productos, al igual que en la
facturación, control de personal y reporte de clientes, ya que estos procesos son de vital
importancia para la empresa.

1.7.2. TEÓRICO
Se utilizará la metodología de desarrollo OpenUp, diseñado para pequeños equipos
organizados y es completa en el sentido de que manifiesta por completo el proceso de
construir un sistema.

Para el diseño web se utilizará la ayuda del modelado web: UWE (Ingeniería Web Basada en
UML) para el proceso de creación de aplicaciones detallada.

1.8. METODOLOGÍA

En el desarrollo del presente trabajo se utilizará la investigación científica, con un enfoque

cualitativo que estudia la realidad en su contexto natural y como sucede, sacando e
interpretando fenómenos de acuerdo con las personas implicadas.

10
Se hará uso del método deductivo para deducir conclusiones lógicas a partir de una serie de
premisas o principios. Con la técnica exploratorio descriptivo, aplicando técnicas y
herramientas de ingeniería de software, como se observa en la figura 1.3.

Figura 1.3. Elementos básicos de una metodología

Fuente: Ramírez, 2015

Para la ingeniería de software, el desarrollo del sistema web se utilizará la metodología

OpenUp, junto a UWE (Ingeniería Web Basada en UML) con las herramientas: Framework
Laravel y MySQL para la base de datos.

Para la implementación del sistema web se aplicará WebML, que es un lenguaje de modelado
para el desarrollo de aplicaciones web, la metodología está orientada a las aplicaciones que
hacen uso intensivo de datos.

11
 CAPÍTULO II

MARCO TEÓRICO

2.1. INTRODUCCIÓN

En el marco teórico se incorpora los conocimientos de los conceptos previos de las

herramientas, metodologías entre otros ya mencionadas anteriormente, los cuales son
fundamentales para un correcto uso para desarrollar adecuadamente el proyecto.

Para desarrollar el presente proyecto se muestra los siguientes conceptos de mayor

importancia. Es imprescindible estudiar la parte teórica, como definiciones, características,
estructuras, entre otras.

2.2. INGENIERÍA DE SOFTWARE

La ingeniería de software es el estudio de los principios y metodologías para el desarrollo y

mantenimiento de sistemas de software (Zelkovitz, 1978).

Es la aplicación práctica del conocimiento científico en el desarrollo y construcción de

programas de computadoras y la documentación asociada requerida para desarrollar, operar
y mantenerlos. Se conoce también como desarrollo de software de producción (Bohem,
1976).

La aplicación de un enfoque sistemático, disciplinado y cuantificable al desarrollo de

operación y mantenimiento del software (IEEE, 1993).

2.3. METODOLOGÍA DE DESARROLLO DE SOFTWARE

Podemos definir a las Metodologías de Desarrollo de Software como aquellos

procedimientos o marcos (técnicas o instrucciones dada la redundancia) que nos permitirán
crear software de calidad. Cabe destacar que estos métodos no son impuestos, como
desarrollador puedes elegir seguirlos o no, solo son recomendaciones que se aconseja seguir
para mejorar nuestro trabajo. Son básicamente un marco de trabajo usado para estructurar,

12
 planificar y controlar el proceso de desarrollo en sistemas de información. Estas son
básicamente usadas con los siguientes objetivos:

● Definir actividades a llevarse a cabo en un Proyecto.

● Unificar criterios en la organización para el desarrollo del proyecto.
● Proporcionar puntos de control y revisión.
● Asegurar la uniformidad y calidad tanto del desarrollo como del sistema en sí
● Satisfacer las necesidades de los usuarios del sistema.
● Conseguir un mayor nivel de rendimiento y eficiencia del personal asignado al desarrollo.
● Ajustarse a los plazos y costos previstos en la planificación.
● Generar de forma adecuada la documentación asociada a los sistemas.
● Facilitar el mantenimiento posterior de los sistemas.

2.3.1. MODELO DE DESARROLLO ÁGIL

Las Metodologías Ágiles son aquellas que permiten adaptar la forma de trabajo a las
condiciones del proyecto, consiguiendo flexibilidad e inmediatez en la respuesta para
amoldar el proyecto y su desarrollo a las circunstancias específicas del entorno.

En lugar de crear una documentación de proyecto tradicional, Ágil se enfoca en mínima

documentación (mínima – no ninguna documentación) y la entrega de soluciones
funcionando (software que funcione para el caso de TI).

Las metodologías Ágiles cuentan con las siguientes características:

● Mejora la motivación e implicación del equipo de trabajo: Es importante escuchar las

opiniones tanto del cliente como de los desarrolladores incluidos en el equipo, toda opinión
es útil para la realización del proyecto.
● Mejoran la satisfacción del cliente: En este tipo de metodologías es común trabajar
activamente con el cliente, escuchando sus opiniones y mostrándole avances constantes del
proyecto.

13
● Ahorrar tiempo en costes: En estas metodologías se toma en cuenta mucho el hecho
de mantenerse dentro del presupuesto y dentro de los tiempos de entrega.
● Se trabaja con mayor velocidad y eficiencia: Cada cierto periodo de tiempo corto se
entrega una muestra de los avances del proyecto en versiones funcionales, lo que permite
corregir errores e implementar mejoras de acuerdo a comentarios del equipo o cliente,
además de mejorar así la calidad y eficiencia de trabajo.
● Eliminación de características innecesarias del producto: Al escuchar constantemente
las opiniones del cliente se pueden eliminar características o necesidades que realmente no
son necesarias o prioritarias en el desarrollo del proyecto.
● Mejora la calidad del Producto: La interacción entre el cliente y los desarrolladores
tiene como objetivo crear un proyecto que cumpla las necesidades justas del cliente.
● Alertar rápidamente tanto de errores como de problemas: Se detectan fácilmente
situaciones como errores o bugs, excesos de presupuesto o tiempos de desarrollo.

Como podemos leer, las Metodologías Agiles son aquellas que básicamente se basan en
interactuar directamente con el cliente desarrollando y entregando avances parciales del
trabajo hasta tener la versión final del mismo.

El modelo Ágil ha evolucionado para coexistir junto con un pensamiento más tradicional de
Dirección de Proyectos y actividades de desarrollo. Puedes también adoptar mezclas híbridas
de Ágil y acercamientos de desarrollo más tradicionales. Esto ha hecho que el movimiento
sea la corriente prevaleciente y segura para la mayoría de las organizaciones.

2.4. METODOLOGÍA DE DESARROLLO OPENUP

Es un proceso modelo y extensible, dirigido a gestión y desarrollo de proyectos de software

basados en un desarrollo iterativo, ágil e incremental apropiado para proyectos pequeños y
de bajos recursos; y es aplicable a un conjunto amplio de plataformas y aplicaciones de
desarrollo. OpenUP es una metodología gratis, ágil, modificable y evolutiva que se puede
integrar con otras metodologías ya que pueden resolverse las tareas de desarrollo utilizando
las prácticas de XP (Pair Programing, TDD, Refactoring) y pueden realizarse las iteraciones

14
utilizando las actividades de SCRUM. Además, brinda una referencia clara y simplificada
para la inducción de nuevo personal (Medina, 2014).

2.4.1. FASES DE OPENUP

Las fases o el ciclo de vida se pueden observar en la figura 2.1 que se muestra a continuación:

Figura 2.1. Ciclo de Vida de un proyecto según OpenUp

Fuente: Fundación Wikimedia, Inc., 2019

El OpenUP está organizado en dos dimensiones diferentes pero interrelacionadas: el método

y el proceso. El contenido del método es donde los elementos del método (roles, tareas,
artefactos y lineamientos) son definidos, sin tener en cuenta como son utilizados en el ciclo
de vida del proyecto. El proceso es donde los elementos del método son aplicados de forma
ordenada en el tiempo.

El OpenUp estructura el ciclo de vida de un proyecto en cuatro fases que se muestran en la

tabla 2.1, las cuales son: inicio o concepción, elaboración, construcción y transición.

15
 Tabla 2.1. Fases de OpenUp
Fases Conceptos Objetivos
En esta fase, las necesidades de cada  Entender qué construir.
participante del proyecto son tomadas  Identificar funcionalidad
Iteración de en cuenta y plasmadas en objetivos Clave.
Fase de del proyecto. Se definen para el  Determinar al menos una
Inicio proyecto: el ámbito, los límites, el posible solución.
criterio de aceptación y los casos de  Entender costos, calendario
uso críticos. y riesgos del proyecto.
En esta fase se realizan tareas de  Obtener un entendimiento
análisis del dominio y definición de la con mayor nivel de detalle
arquitectura del sistema. Se debe de los requerimientos.
elaborar un plan de proyecto,  Diseñar, implementar y
Iteración de
estableciendo unos requisitos y validar la línea base
Fase de
arquitectura estables. Al final de la arquitectónica.
Elaboración
fase se debe tener una definición clara  Mitigar riesgos y lograr
y precisa de los casos de uso, actores, estimaciones de costos y
la arquitectura del sistema y un calendario más precisos.
prototipo ejecutable.
En esta fase todos los componentes y  Iterativamente desarrollar
funcionalidades del sistema que falten un producto completo que
por implementar son realizados, pueda ser transicionado a la
Iteración de probados e integrados. Los resultados comunidad usuaria.
Fase de obtenidos en forma de incrementos  Minimizar los costos de
Construcción ejecutables deben ser desarrollados de desarrollo y lograr cierto
la forma más rápida posible sin dejar nivel de paralelismo.
de lado la calidad de lo desarrollado

16
 Esta fase corresponde a la  Realizar Beta Testing para
introducción del producto en la determinar si se alcanzaron
comunidad d usuarios, cuando el las expectativas de los
producto está lo suficiente maduro. usuarios.
La fase de transición consta de las  Alcanzar la concordancia
sub-fases de pruebas beta, pilotaje y con los stakeholders de que
Iteración de
capacitación de los usuarios finales, el producto está terminado.
Fase de
de los encargados del mantenimiento  Mejorar la performance
Transición
del sistema. En función a la respuesta futura a través del análisis
obtenida por los usuarios puede ser retrospectivo del proyecto.
necesario realizar cambios en las
entregas finales o implementar alguna
funcionalidad más solicitada por la
mayoría.
Fuente: Medina, 2014

2.4.2. ACTIVIDADES DE OPENUP

La metodología OpenUp consta de seis actividades que se muestran en la tabla 2.2, las cuales
incluyen tareas y estas se relacionan con otros elementos de dichas actividades.

Tabla 2.2. Actividades de OpenUp

Fases Actividades Definición
Esta actividad define el inicio del proyecto, la
Identificación de
Inicio identificación de interesados, la descripción de
requerimientos
posibles soluciones y la visión general del sistema.
Esta actividad crea una arquitectura sólida de
Arquitectura
elementos tecnológicos para el sistema.
Elaboración
Esta actividad analiza los requerimientos
Análisis
arquitectónicos.

17
 Esta actividad adapta el diseño para que coincida con
Diseño
el entorno de implementación.
Esta actividad explica cómo implementar una
solución técnica que se ajusta en el proyecto de los
Construcción Implementación
trabajos dentro de la arquitectura y es compatible con
los requisitos.
Esta actividad es la especificación de un conjunto de
Transición Pruebas pruebas de entrada, condiciones de ejecución y
resultados esperados.
Fuente: Technology Group, 2013

2.4.3. ROLES DE OPENUP

OpenUp está constituido por seis roles: tester, desarrollador, líder del proyecto, analista,
arquitecto y stakeholders (partes interesadas) que podemos observar en la tabla 2.3 que se
muestra a continuación.

Tabla 2.3. Roles de OpenUp

Roles Definición
Es el responsable de actividades básicas de la prueba, se encarga
de la identificación, definición, implementación y realización de
Tester las pruebas necesarias. Así como el registro de pruebas y el análisis
de resultados.

Es responsable de desarrollar una parte del sistema o el sistema

completo dependiendo de la magnitud del mismo. Se encarga del

Desarrollador diseño ajustándolo a la arquitectura, a la creación de prototipos de

la interfaz de usuario, la unidad de prueba e integrar los
componentes que forman parte de la solución.

18
 Dirige la planificación del proyecto en colaboración con las partes
Líder del interesadas y el equipo, coordina las interacciones de los
proyecto interesados, mantenimiento al equipo del proyecto enfocado en los
objetivos del mismo.

Analista Es el que representa al cliente y el usuario final.

El arquitecto es el responsable del diseño de arquitectura del

Arquitecto
software.
Representa al grupo que está interesado en el proyecto, quienes
Stakeholders
necesariamente deberán de ser satisfechos por el mismo.

Fuente: OpenUp, 2014

2.5. INGENIERÍA WEB

La ingeniería web se debe al crecimiento desenfrenado que está teniendo la Web está
ocasionando un impacto en la sociedad y el nuevo manejo que se le está dando a la
información en las diferentes áreas en que se presenta ha hecho que las personas tiendan a
realizar todas sus actividades por esta vía.

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 (Mallea,
2009).

Cualquier producto o sistema importante es merecedor de recibir una ingeniería. Esto

significa que hay que entender el problema, diseñar una solución viable, implementarla de
una manera sólida y comprobarla en profundidad. Probablemente también se deberían
controlar los cambios a medida que el trabajo vaya avanzando, y disponer de mecanismos
para asegurar la calidad del resultado final. Muchos de los que desarrollan en web no opinan
lo mismo; ellos piensan que su mundo es realmente diferente, y que los enfoques de
ingeniería de software convencionales no aplican para ellos (Pressman, 2010).

19
2.6. METODOLOGÍAS WEB

Es una propuesta para el desarrollo de sitios Web, en la que el sistema se define en base a los
grupos de usuarios. Cada usuario tiene que suplir una necesidad de información y sigue unos
requerimientos que el sitio web debe cumplir.

Las metodologías de Desarrollo Web se basan en satisfacer las necesidades de cada grupo
de usuarios, pero no puede garantizar que la información no sea repetida, no tiene sistema
que evalúe seguridad ni funcionalidad, por tal motivo es superada por otras metodologías
web.

Pueden ser utilizados en el desarrollo de sitios web que manejan diferentes tipos de usuarios
con diferentes accesos de información. Al ser orientado al usuario se encarga que la
navegabilidad de éste sea la apropiada para satisfacer las necesidades de consulta de los
diferentes tipos de usuarios (Valarezo, 2018).

Propone cuatro etapas o fases que se describen en la tabla 2.4:

Tabla 2.4. Fase de la Metodología Web

Fase Descripción
Intenta detectar los perfiles de usuarios para los cuales
se construye la aplicación.
Fase de Modelo de Usuario Tomando en cuenta los objetivos de la empresa y la
planificación inicial del sitio web se hace la
clasificación y descripción de usuarios.
Realiza el modelado de objetos y el diseño de
Fase de Diseño Conceptual
navegación.
Fase de Diseño e Orientado a la interfaz para cada usuario, maneja la
Implementación estructura, presentación y diseño lógico de los datos.
Fase de Realización de Se codifica en el lenguaje seleccionado para el
Implementación desarrollo del sitio web, tomando en cuenta que sea

20
 flexible y así dejando las posibilidades de mejorar y
ampliar a nuevos requisitos.
Fuente: Valarezo, 2018

2.6.1. METODOLOGÍA WEB BASADA EN UML (UWE)

Para Roque (2019), UWE es un proceso del desarrollo para aplicación web enfocada sobre
el diseño sistemático, la personalización y la generación semiautomática de escenarios que
guíen el proceso de desarrollo de una aplicación Web.

UWE describe una metodología de diseño sistemática, basada en las técnicas de UML, la
notación de UML y los mecanismos de extensión de UML.

Es una herramienta que nos permitirá modelar aplicaciones web, utilizada en la ingeniería
web, prestando especial atención en sistematización y personalización (sistemas
adaptativos).

UWE es una propuesta basada en el proceso unificado y OpenUp pero adaptados a la web.
En requisitos separa las fases de captura, definición y validación.

Hace además una clasificación y un tratamiento especial dependiendo del carácter de cada
requisito.

2.6.2. ACTIVIDADES DE MODELADO UWE

Se realiza distintos tipos de actividades en base al modelado UWE que se muestra en la tabla
2.5 a continuación:

Tabla 2.5. Actividades de Modelado UWE

ACTIVIDADES DEFINICIÓN

La especificación de requerimientos de software (ERS) es

Especificación de
una descripción completa del comportamiento del sistema
Requerimientos
que se va a desarrollar. Incluye un conjunto de casos de uso

21
 que describe todas las interacciones que tendrán los usuarios
con el software. Se hace uso del modelo de caos de uso.

Modelo Lógico – Especifica cómo se encuentran relacionados los contenidos

Conceptual del sistema.

- Enlace de los elementos de navegación.

Modelo de Navegación
- Unidades de navegación llamados “nodos”

Representación esquemática de los objetos visibles al

Modelo de Presentación
usuario.

Interacción Temporal Presenta los objetos que participan en la interacción.

Proveen la representación funcional dinámica del modelo

Escenarios Web
de navegación

Fuente: Misantla, 2015

2.6.2.1. ESPECIFICACIÓN DE REQUERIMIENTOS

La ERS es el principal producto del proceso de Ingeniería de Requisitos junto con los
modelos conceptuales que se incluyen en el Análisis del Sistema (DAS).

Aunque existen diversas propuestas sobre su contenido y el número de documentos en los

que puede dividirse, en el contexto de MADEJA se asumirá que la ERS es un documento que
contiene tanto las necesidades de negocio de clientes y usuarios, como la propuesta de
solución de los ingenieros de requisitos (requisitos del sistema a desarrollar, o requisitos de
producto en terminología de CMMI-DEV).

Estos conceptos se muestran en la figura 2.2, en la que pueden verse sus relaciones de
trazabilidad hacia productos previos con impacto en su contenido como pueden ser el Pliego
de Prescripciones Técnicas, la Oferta Seleccionada y el Estudio de Viabilidad del Sistema,
en el caso de que estos documentos existieran para el proyecto en curso.

22
 Figura 2.2. Estructura básica y dependencias de la Especificación de Requerimientos
Fuente: Junta de Andalucía, 2003

2.6.2.2. MODELO LÓGICO – CONCEPTUAL

El modelo lógico contiene las clases de estereotipo entity, muestra entre ellas y sus atributos,
se observa en la figura 2.3 a continuación:

Figura 2.3. Modelo Lógico

Fuente: WRA Income S.L., 2000

23
El modelo conceptual contiene las clases de estereotipo entity y muestra las multiplicidades
entre ellas, podemos observar en la figura 2.4:

Figura 2.4. Modelo Conceptual

Fuente: WRA Income S.L., 2000

2.6.2.3. MODELO DE NAVEGACIÓN

Podemos ver el modelo de navegación en la figura 2.5:

Figura 2.5. Modelo de Navegación, UWE

Fuente: UWE, 2016

24
Los nombres de estereotipos y sus iconos del modelo de navegación se pueden observar en
la figura 2.6 a continuación:

Figura 2.6. Estereotipos e iconos, Modelo de Navegación UWE

Fuente: UWE, 2016

2.6.2.4. MODELO DE PRESENTACIÓN

El modelo de presentación describe dónde y cómo los objetos de navegación y accesos

primitivos serán presentados al usuario, es decir, una representación esquemática de los
objetos visible al usuario, como se observa en la figura 2.7:

Figura 2.7. Modelo de Presentación, UWE

Fuente: UWE, 2016

25
En la figura 2.8 se muestra los nombres de estereotipos y sus iconos:

Figura 2.8. Estereotipos e iconos, UWE

Fuente: UWE, 2016

2.6.3. FASES DE DESARROLLO UWE

A continuación, podemos ver las fases de desarrollo UWE en la tabla 2.6:

Tabla 2.6. Fases de Desarrollo UWE

Captura, análisis y Durante esta fase, se adquieren, reúnen y especifican las
especificación de características funcionales y no funcionales que deberá
requisitos cumplir el sistema web.
Se basa en la especificación de requisitos producido por el
análisis de los requerimientos (fase de análisis), el diseño
define cómo estos requisitos se cumplirán, la estructura que
Diseño del Sistema
debe darse al sistema web. Se dan a conocer los diagramas:
de Casos de Usos, Conceptual, Físico, de Clases y los
modelos: Navegacional y de Presentación.
Durante esta etapa se realizan las tareas que se conocen
como programación, que consiste esencialmente, en llevar
Codificación
a código fuente, en el lenguaje de programación elegido,
todo lo diseñado en la fase anterior.
Las pruebas se utilizan para asegurar el correcto
Pruebas funcionamiento de secciones de código.

26
 Es el proceso por el cual los programas desarrollados son
Instalación o Fase transferidos apropiadamente al computador destino,
de Implementación inicializados y eventualmente, configurados, todo ello con
propósito de ser ya utilizados por el usuario final.
Es el proceso de control, mejora y optimización del
software ya desarrollado e instalado, que también incluye
Mantenimiento
depuración de errores y defectos que puedan haberse
filtrado de la fase de pruebas de control.
Fuente: Cabello, 2013

2.7. PLATAFORMA TECNOLÓGICA

2.7.1. FRAMEWORK LARAVEL

Para Baquero (2015), Laravel es uno de los frameworks de código abierto más fáciles de
asimilar para PHP. Es simple, muy potente y tiene una interfaz elegante y divertida de usar.
Fue creado en 2011 y tiene una gran influencia de frameworks como Ruby on Rails, Sinatra
y ASP.NET MVC.

El objetivo de Laravel es el de ser un framework que permita el uso de una sintaxis refinada
y expresiva para crear código de forma sencilla, evitando el «código espagueti» y
permitiendo multitud de funcionalidades. Aprovecha todo lo bueno de otros frameworks y
utiliza las características de las últimas versiones de PHP. La mayor parte de su estructura
está formada por dependencias, especialmente de Symfony, lo que implica que el desarrollo
de Laravel dependa también del desarrollo de sus dependencias.

2.7.2. LENGUAJES DE PROGRAMACIÓN

2.7.2.1. PHP

PHP identifica a un lenguaje de programación que nació como Personal Home Page (PHP)
Tools, PHP suele procesarse directamente en el servidor, aunque también puede usarse a
través de software 27 capaz de ejecutar comandos y para el desarrollo de otra clase de

27
programas, sin embargo, en la actualidad está vinculado a PHP Hypertext Pre-Processor
(Venemedia, 2014).

Para Alvarez (2001), PHP es el acrónimo de Hipertext Preprocesor. Es un lenguaje de

programación del lado del servidor gratuito e independiente de plataforma, rápido, con una
gran librería de funciones y mucha documentación.

Las páginas que se ejecutan en el servidor pueden realizar accesos a bases de datos,
conexiones en red, y otras tareas para crear la página final que verá el cliente.

2.7.3. BASE DE DATOS

2.7.3.1. MYSQL

MySQL es un sistema de administración de bases de datos relacional (RDBMS). Se trata de

un programa capaz de almacenar una enorme cantidad de datos de gran variedad y de
distribuirlos para cubrir las necesidades de cualquier tipo de organización, desde pequeños
establecimientos comerciales a grandes empresas y organismos administrativos.

MySQL se ofrece en dos ediciones diferentes: el servidor de comunidad MySQL de código

abierto y el servidor empresarial propietario. MySQL Enterprise Server se diferencia por una
serie de extensiones propietarias que se instalan como complementos de servidor, pero por
lo demás comparte el sistema de numeración de versiones y se construye desde el mismo
código base.

2.7.4. HERRAMIENTAS

2.7.4.1. SUBLIME TEXT

Sublime Text es un editor de texto avanzado especialmente diseñado para desarrolladores y

se destaca por sus funcionalidades e interfaz del usuario. Sublime Text es ligero,
multiplataforma y cuenta con abundaste plugins.

No es software libre o de código abierto (BISBÉ Y BENITEZ, 2015).

28
2.8. COMPRA

La compra hace referencia a la acción de obtener o adquirir, a cambio de un precio

determinado, un producto o un servicio. Pero también se considera “compra” el objeto
adquirido, una vez consumado el acto de adquisición.

El acto de compra presume la existencia de otra parte, que es la que recibe el precio pactado
por la prestación, es decir, la venta. Resulta obvio que cada parte necesita de la existencia de
la otra para cumplir su función, lo que se plasma en la conocida expresión “compra-venta”
(Raffino, 2019).

2.8.1. CONTROL DE COMPRAS

Comprar es una actividad que conocemos desde pequeños; nos rodean productos y servicios
que queremos tener, pero no podemos tenerlo todo. Tenemos que decidir si realmente es un
producto, artículo o servicio que necesitamos y si el precio es accesible para nuestra cartera.
Para una empresa realizar compras es un proceso un poco más largo y detallado que va desde
elegir los productos, seleccionar a los proveedores hasta negociar el precio, condiciones de
pago y fecha de entrega. Es por eso que en una empresa el departamento de compras lleva
un papel muy importante, los encargados de realizar las compras aceptan una gran
responsabilidad, ya que deben buscar y encontrar el producto con el mejor precio, la calidad
esperada y con un tiempo de entrega corto; es decir recae en ellos la eficacia y buen control
del dinero de nuestra empresa.

Comprar en una empresa suele verse como una salida de dinero, pero debemos verlo como
una inversión, ya que cuando la decisión de compra se tomó de acuerdo a las necesidades y
deseos de los clientes recuperaremos lo que hemos invertido (y un poco más) en forma de
ganancias. Hacer compras inteligentes permite administrar estratégicamente los recursos,
evitar problemas y contribuye a la satisfacción del cliente. Para dejar de ver las compras
como un gasto, se recomienda que las empresas establezcan un «control de compras» y si

29
además de esto en tu empresa cuentan con un sistema de compras, tu vida y la de tu equipo
de trabajo serán más sencillas.

El control de compras es un plan que nos ayuda a mantener el funcionamiento adecuado de

las compras de nuestra empresa. En los objetivos principales de mantener un control de
compras en tu empresa se encuentran:

● Asegurar que el proveedor entregue lo comprado en el tiempo y calidad acordada.

● Definir los procesos para la gestión de compras y documentarlos con el objetivo de
detectar oportunidades de mejora.
● Elegir a los proveedores que nos ofrezcan mejor calidad a mejor precio.
● Identificar las necesidades de nuestros clientes.
● Entre otros.

El contenido del método es donde los elementos del método (roles, tareas y artefactos) son
definidos, sin tener en cuenta como son utilizados en el ciclo de vida del proyecto.

2.9. VENTA

Para Thompson (2006), la venta es una de las actividades más pretendidas por empresas,
organizaciones o personas que ofrecen algo (productos, servicios u otros) en su mercado
meta, debido a que su éxito depende directamente de la cantidad de veces que realicen ésta
actividad, de lo bien que lo hagan y de cuán rentable les resulte hacerlo.

2.9.1. CONTROL DE VENTAS

Este módulo permitirá realizar la gestión correspondiente a cotizaciones, pedidos,

remisiones y facturación de mercancía, venta de productos y servicios en diferentes unidades
de medida (MaGisterSoftware, 2011).

2.10. INVENTARIO

Para Bernard (2002), un inventario representa la existencia de bienes muebles e inmuebles

que tiene la empresa para comerciar con ellos, comprándolos y vendiéndolos tal cual o

30
procesándolos primero antes de venderlos, en un período económico determinado. Deben
aparecer en el grupo de Activo Circulante.

2.10.1. CONTROL DE INVENTARIOS

El control de inventario se refiere a todos los procesos que coadyuvan al suministro,

accesibilidad y almacenamiento de productos en alguna compañía para minimizar los
tiempos y costos relacionados con el manejo del mismo: es un mecanismo a través del cual,
la organización administra de manera eficiente el movimiento y almacenamiento de
mercancía, así como el flujo de información y recursos que resultan de ello.

Para una implementación plena se deben seguir las siguientes recomendaciones:

● Mantener un catálogo con los productos que se manejan. Organizar la información que
se posea sobre las existencias y complementarla con detalles pertinentes, además de
depurarla de manera constante, facilita la visualización de necesidades y oportunidades
del inventario en tiempo real.

● Clasificar los productos. Aunado a lo anterior, separar por grupos semánticos: ya sea por
proveedor, éxito de venta o rezago, hará más accesible la información del inventario, así
como agilizará la toma de medidas necesarias (reabastecimiento, re-ofertas, entre otras).

● Establecer un método y periodicidad para la realización de inventarios:

1. Inventario perpetuo. Se hace un registro continuo (día a día) de la producción y

venta de artículos, por lo que se puede conocer el costo del inventario y las
existencias en el mismo sin tener que determinar una fecha de inventariado.

2. Inventario periódico. Se eligen fechas específicas para contabilizar la mercancía

según las necesidades de la empresa, lo que suele requerir más tiempo y esfuerzo.
Debe considerarse el cese de actividades momentáneo.

● Comprender conceptos clave para su integración:

31
 1. Stock máximo. Límite de unidades, por artículo, que se desea mantener en
almacén según las ganancias y costos que representen.

2. Stock mínimo (de seguridad). Existencias mínimas, por artículo, que se requieren
en almacén considerando labores de reabastecimiento y las posibles pérdidas que
su carencia signifique.
3. Punto re-orden. Momento (medido por la cantidad de existencias) en el que se
deben realizar órdenes de reabastecimiento tomando en cuenta tiempos y costos
de proveedores.
● Monitorear y actualizar de manera constante la información recopilada, y el sistema
utilizado. Así se podrá solicitar la compra de unidades antes de que se agoten, rotar
mercancía generando campañas atractivas, reconocer la utilidad de los métodos
implementados, identificar áreas de oportunidad e integrar mejoras.
● Integrar herramientas especializadas. Estas aceleran el cumplimiento de las actividades
relacionadas con el inventario al permitir el acceso a interfaces de gestión automatizadas.

Beneficios de ejercer un buen control de inventario:

▪ Información relevante y vigente sobre las existencias, posibilitando mejores tomas de

decisiones
▪ Acentúa la efectividad de la compañía y la eficiencia de sus procedimientos
▪ Incrementa la calidad de servicio al cliente.
▪ Ayuda a la identificación pertinente de estacionalidad o flujo de los productos
▪ Optimiza la inversión de recursos (económicos, humanos y temporales)
▪ Permite tener un mejor conocimiento y control de las entradas, salidas y localización de
mercancía: se reducen pérdidas, se optimiza el espacio en almacén y aumenta la atención
sobre la existencia (reconociendo posibles robos y mermas).

La finalidad y beneficio primordial de este control es facilitar las operaciones a las

compañías y negocios para impulsar la venta de productos y servicios, equilibrando las tareas

32
para atender la oferta y demanda, así como perfeccionando la cultura de organización
empresarial para posicionar la marca y su oferta en la consciencia de las audiencias y en el
competitivo mercado (Castro, 2016).

2.11. PROCESO DE FACTURACIÓN

En un ciclo de transacción típico, se genera una factura después de concluido el proceso

contractual y de venta. El proceso de facturación tradicional siempre ha formado parte de un
conjunto más amplio de procesos de negocio en el comercio que incluyen la colocación y
aceptación de una orden, el procesamiento de la orden, la entrega de la mercancía y el pago
final. Este es un proceso de compra-a-pago desde la perspectiva del comprador, y uno de
pedido-a-cobro desde la perspectiva del vendedor. Juntos reciben el nombre de “proceso
comercial”.

Por consiguiente, desde un punto de vista del proceso de negocio, una factura nunca es un
documento aislado, sino que siempre es el resultado—y está ligado con—otras actividades.

Los aspectos de pago de una factura generalmente involucran la generación de un pago por
parte del receptor de la factura en respuesta a los detalles de pago que aparecen en la misma.
Debido a que una factura es en parte una solicitud de pago, existen claras sinergias entre los
sistemas de pago y el proceso de facturación.

Nótese que la factura no es un documento bancario. Los enlaces del proceso de facturación
y los bancos pueden proporcionar servicios adicionales como el procesamiento, la
distribución de la factura y el financiamiento de la cadena de suministro (Comisión
Económica de las Naciones Unidas, 2012).

2.12. CONTROL DE PERSONAL

En la ecuación personal-organización, la administración del personal es, sin duda alguna, un

tema de interés, como lo demuestra la gran cantidad de libros de texto, manuales, trabajos
descriptivos y analíticos, y artículos que tratan de esa materia. Es un tema que en años
recientes ha interesado, en grado sumo, a los planificadores, administradores, educadores,

33
sociólogos e investigadores interesados en la dinámica de la vida organizativa. Estos
profesionales han señalado, definido y puntualizado la mayoría de los componentes
fundamentales de este campo (Etienne, 1986).

Los autores de publicaciones serias sobre el tema, se ven obligados a preparar nuevas
ediciones de sus libros con relativa frecuencia, a fin de hacer resaltar la naturaleza cambiante
de los conceptos sobre el personal, dar cabida a nuevas ideas sobre la materia y fijar nuevas
pautas.

Del análisis de la definición se puede concluir que el control de personal es un proceso (una
serie de etapas ordenadas) y que tiene como finalidad conocer las incidencias sobre la
asistencia del personal que se dan en la empresa, para lo que se sirve de una serie de
herramientas de recogida, registro y tratamiento de la información.

Su finalidad se puede concretar en dos objetivos:

• Evaluación del desempeño. Detectar los problemas de funcionamiento del personal y

determinar las causas que los producen para tomar decisiones que mejoren la situación.
• Cumplimiento de la disciplina. Controlar el cumplimiento de las normas por parte de los
trabajadores respecto a las entradas y salidas, el cumplimiento del horario de trabajo, la
realización de horas extras, los permisos, las vacaciones, las licencias y los retrasos.

34
 CAPÍTULO III

MARCO APLICATIVO

3.1. INTRODUCCIÓN

Para el desarrollo de todo producto de software se deben realizar un orden, que no solo
incluye su producción, también incluye la utilización y mantenimiento, esto se llama ciclo de
vida o proceso de desarrollo del software.

En este capítulo se especifica la forma de organización, para trabajar con la metodología

OpenUp como se hizo referencia en el capítulo anterior, y el uso de UWE aplicado a la
metodología de desarrollo.

3.1.1. RELACIÓN ENTRE OPENUP Y UWE

OpenUP es un proceso de desarrollo de software mínimamente suficiente, esto quiere decir

que incluye solo el contenido fundamental, esto es que no provee orientación sobre temas en
los que el proyecto tiene que lidiar, como son: el tamaño del equipo, el cumplimiento,
seguridad, orientación tecnológica entre otras. Sin embargo, OpenUP es completa en el
sentido de que manifiesta por completo el proceso de construir un sistema.

El principal objetivo del enfoque UWE es proporcionar: un lenguaje de modelado específico

del dominio basado en UML; una metodología dirigida por modelos; herramientas de soporte
para el diseño sistemático; y herramientas de soporte para la generación semi-automática de
Aplicaciones Web.

La notación de UWE se define como una ligera extensión de UML, proporcionando un perfil
UML para el dominio específico de la web.

En la tabla 3.1 se realiza la descripción de la metodología de desarrollo OpenUp

relacionándolo con la metodología UWE, incluyendo las fases e indicando los artefactos de
OpenUp y UWE:

35
 Tabla 3.1. Relación de los artefactos de OpenUp – UWE
Fases Artefactos de OpenUp Artefactos de UWE
Inicio del proyecto Identificación de interesados
Iteración de administración y Descripción de posible
planeación solución
Fase de Requerimientos administrativos Visión general del sistema
Inicio Determinar la factibilidad de la
No aplica
arquitectura
Término de los objetivos del ciclo de
No aplica
vida
Iteración de administración y
No aplica
planeación
Requerimientos tecnológicos y
Requerimientos administrativos
análisis
Definir la arquitectura Entorno de desarrollo
Fase de
Desarrollar una solución por
Elaboración No aplica
requerimientos dentro del contexto
Validar construcción Diseño de interfaces
Tareas en curso No aplica
Término de la arquitectura del ciclo
No aplica
de vida
Iteración de administración y
No aplica
planeación
Requerimientos administrativos No aplica
Fase de
Desarrollar una solución por
Construcción Justificación de herramientas
requerimientos dentro del contexto
Validar construcción Pantallas del sistema
Tareas en curso No aplica

36
 Término de la capacidad operativa
No aplica
inicial
Iteración de administración y
No aplica
planeación
Desarrollar una solución por
Fase de No aplica
requerimientos dentro del contexto
Transición
Validar construcción No aplica
Término del lanzamiento del
Pruebas
producto
Fuente: Camacho, 2017

3.2. DESARROLLO

Se emplea la metodología OpenUp de acuerdo a las fases, necesidades y requerimientos de

la empresa. Se desarrolla la arquitectura y el diseño del prototipo mediante iteraciones la cual
nos permite facilitar la elaboración del proyecto.

3.2.1. DOCUMENTOS ENTREGABLES

A continuación, en la tabla 3.2 se señalan los documentos entregables que se crearon para
el sistema web con la metodología OpenUp:

Tabla 3.2. Documentos Entregables

Fase Actividad Documento
Se desarrolla el sistema de acuerdo al control de
compra, venta e inventario.
Identificación de
Inicio Identificación de interesados
Requerimientos
Descripción de posibles soluciones
Visión generalizada del sistema
Elaboración Arquitectura Elementos tecnológicos

37
 Especificaciones de casos de uso
Análisis Identificación de actores
Modelo de clases
Modelo de Presentación
Modelo de Navegación
Diseño
Modelo Entidad – Relación
Modelo Relacional
Desarrollo de la solución
Construcción Implementación Herramientas de desarrollo
Pantallas del sistema
Transición Prueba Prueba del sistema
Fuente: Elaboración Propia

3.2.2. FASE DE INICIO

En esta fase se representará la arquitectura de software y se determinará posibles soluciones,

los cuales deben tomar en cuenta las necesidades y requerimientos de la empresa.

3.2.2.1. MODELO DE REQUERIMIENTOS

El modelo de requerimientos es aquella planificación que se tuvo con el dueño de la empresa

y el personal administrativo, en la tabla 3.3 se presenta el módulo de control de compras que
se tuvo en el análisis de requerimientos.

Tabla 3.3. Requerimientos funcionales del control de compras

Código Prioridad Descripción
CC-01 Alta Productos comprados
CC-02 Alta Información sobre el producto comprado
Fuente: Elaboración Propia

38
En la tabla 3.4 se presenta el módulo de control de ventas del análisis de requerimientos:

Tabla 3.4. Requerimientos funcionales del control de ventas

Código Prioridad Descripción

CV-01 Alta Clientes

CV-02 Media Movimiento de productos

Fuente: Elaboración Propia

En la tabla 3.5 se presenta el módulo de control de inventario del análisis de requerimientos:

Tabla 3.5. Requerimientos funcionales del control de inventario

Código Prioridad Descripción

CI-01 Baja Existencia de producto

CI-02 Medio Productos vendidos

CI-03 Alta Pedidos de productos

Fuente: Elaboración Propia

En la tabla 3.6 se presenta el módulo de control de proveedores que se tuvo en el análisis de

requerimientos:

Tabla 3.6. Requerimientos funcionales del control de proveedores

Código Prioridad Descripción

CP-01 Alta Proveedores

CP-02 Alta Productos comprados

CP-03 Alta Pedidos de productos

Fuente: Elaboración Propia

En la tabla 3.7 se presenta el módulo de facturación del análisis de requerimientos:

39
 Tabla 3.7. Requerimientos funcionales del módulo de facturación
Código Prioridad Descripción
CF-01 Alta Datos de Cliente
CF-02 Alta Datos de Vendedor
CF-03 Alta Detalle de los productos
Fuente: Elaboración Propia

En la tabla 3.8 se presenta el módulo de control de personal que se tuvo en el análisis de

requerimientos:

Tabla 3.8. Requerimientos funcionales del control de personal

Código Prioridad Descripción

CPE-01 Alta Asistencia

CPE-02 Media Licencias

CPE-03 Baja Vacaciones

CPE-04 Alta Informe General

Fuente: Elaboración Propia

En la tabla 3.9 se presenta el módulo de reportes que se tuvo en el análisis de requerimientos:

Tabla 3.9. Requerimientos funcionales del control de reportes
Código Prioridad Descripción
CR-01 Alta Clientes
CR-02 Media Movimiento en los costos de los productos
Fuente: Elaboración Propia

3.2.2.2. IDENTIFICACIÓN DE INTERESADOS (STAKEHOLDERS)

Con la ayuda de OpenUp se describe a los interesados de la fase de inicio. Esto ayuda a la
empresa para ver el desarrollo del sistema. Involucrados, parte interesada o interesados hace

40
referencia a una persona, organización o empresa que tiene interés en una empresa u
organización dada. En la tabla 3.10 se detalla la identificación de los interesados.

Tabla 3.10. Identificación de interesados

Nombre Descripción Responsabilidades
Se encarga de administrar el Tiene la responsabilidad de controlar la
Dueño de la sistema. compra, venta, inventario, facturación,
empresa control de personal y reporte a los
clientes.
Personal Empleados de la empresa. Tiene la responsabilidad de manejar el
Administrativo sistema de manera externa.
Se encargan de entregar Tienen la responsabilidad de proveer
Proveedores
artículos a la empresa. artículos a la empresa.
Cartera de clientes. Son las personas interesadas para realizar
Clientes
las compras.
Fuente: Elaboración Propia

3.2.2.3. DESCRIPCIÓN DE POSIBLE SOLUCIÓN

Teniendo en cuenta la tabla anterior, se debe realizar un detalle de los problemas a resolver
en la empresa, eso se puede ver en las siguientes tablas. En la tabla 3.11 se detalla la los
problemas a resolver del sueño de la empresa:

Tabla 3.11. Problemas relacionados al administrador del sistema

Para Administrar el sistema.
Quien Dueño de la empresa.
El Sistema web de control de compra, venta e inventario
Que Para tener un control más eficiente de su empresa.
Nuestro Producto Desarrollar un sistema web de control de compra, venta e inventario.
Fuente: Elaboración Propia

41
En la tabla 3.12 se detalla los problemas a resolver del personal administrativo:

Tabla 3.12. Problemas relacionados al personal administrativo

Para Personal administrativo.

Quien Trabajadores de la empresa.

El Sistema web de control de compra, venta e inventario

Que Para registrar las compras, ventas e inventario.

Nuestro Producto Desarrollar un sistema web de control de compra, venta e inventario.

Fuente: Elaboración Propia

En la tabla 3.13 se detalla los problemas a resolver de los clientes:

Tabla 3.13. Problemas relacionados al cliente

Para Clientes.

Quien Cartera de clientes.

El Sistema web de control de compra, venta e inventario

Que Para registrar los pedidos.

Nuestro Producto Desarrollar un sistema web de control de compra, venta e inventario.

Fuente: Elaboración Propia

3.2.2.4. VISIÓN GENERAL DEL SISTEMA

En esta sección se considera las características que tienen el sistema web y las necesidades
de la empresa. Se describe la solución implementando las propuestas que se tiene como
sistema web.

En la tabla 3.14 se detalla la posible solución con el módulo de control de compras:

42
 Tabla 3.14. Solución propuesta al control de compras

Fuente: Elaboración Propia

En la tabla 3.15 se detalla la posible solución con el módulo de control de ventas:

Tabla 3.15. Solución propuesta al control de ventas

Fuente: Elaboración Propia

En la tabla 3.16 se detalla la posible solución con el módulo de control de inventario:

Tabla 3.16. Solución propuesta al control de inventario

Fuente: Elaboración Propia

43
En la tabla 3.17 se detalla la posible solución con el módulo de control de proveedores:

Tabla 3.17. Solución propuesta al control de proveedores

Fuente: Elaboración Propia

En la tabla 3.18 se detalla la posible solución con el módulo de facturación:

Tabla 3.18. Solución propuesta al módulo de facturación

Fuente: Elaboración Propia

En la tabla 3.19 se detalla la posible solución con el módulo de control de personal:

Tabla 3.19. Solución propuesta al control de personal

Fuente: Elaboración Propia

44
En la tabla 3.20 se detalla la posible solución con el módulo de reportes:

Tabla 3.20. Solución propuesta al control de reportes

Fuente: Elaboración Propia

3.2.3. FASE DE ELABORACIÓN

La fase de elaboración es la encargada de determinar la solución técnica del proyecto. Así
como durante la fase de inicio se determinó el qué, ahora es necesario el cómo.

3.2.3.1. ARQUITECTURA

Para realizar el proyecto se debe considerar los siguientes elementos tecnológicos:

- Una computadora.
- Internet.
- Servidor Web (que contenga gestor de base de datos MySQL y una plataforma de desarrollo
PHP).

3.2.3.2. ANÁLISIS

En el análisis se dará a conocer las características o cualidades del proyecto, para obtener una
mejor comprensión del alcance que se tiene.

a) ESPECIFICACIONES DE CASOS DE USO

Los casos de uso describen el comportamiento del proyecto, contiene una descripción textual
de todas las maneras que los actores previstos podrían trabajar con el proyecto.

A continuación, se presenta los casos de uso y sus respectivas especificaciones:

45
i. CASO DE USO PRINCIPAL

El caso de uso principal mostrará en general los módulos que contienen el sistema.

De este caso de uso se irá desglosando el módulo de compras con su respectivo caso de uso
detallando los roles que cumplirá cada usuario, el módulo de ventas con su respectivo caso
de uso detallando de la misma manera los roles que cumplirán los usuarios en este módulo,
así también como el módulo de inventario, proveedores, facturación, control de personal y
reporte a clientes. En la figura 3.1 se presenta el caso de uso principal el cual esta descrito
por los módulos definidos anteriormente:

Figura 3.1. Caso de uso principal

Fuente: Elaboración Propia

ii. CASOS DE USO SECUNDARIOS

A continuación, se presenta los casos de uso secundarios, que corresponden a cada módulo.

- CONTROL DE COMPRAS
En la figura 3.2 se presenta el caso de uso secundario del control de compras donde los
involucrados son: el dueño de la empresa y el personal administrativo.

46
 Figura 3.2. Caso de uso secundario – Control de Compras
Fuente: Elaboración Propia

- ESPECIFICACIÓN CASO DE USO – CONTROL DE COMPRAS

En la tabla 3.21 se muestra la especificación de caso de uso del control de compras:

Tabla 3.21. Especificaciones de caso de uso - Control de Compras

Fuente: Elaboración Propia

47
- CONTROL DE VENTAS
En la figura 3.3 se presenta el caso de uso secundario del control de ventas donde los
involucrados son: el dueño de la empresa y clientes.

Figura 3.3. Caso de uso secundario – Control de Ventas

Fuente: Elaboración Propia

- ESPECIFICACIÓN CASO DE USO – CONTROL DE VENTAS

En la tabla 3.22 se muestra la especificación de caso de uso del control de ventas:

Tabla 3.22. Especificaciones de caso de uso - Control de Ventas

Fuente: Elaboración Propia

48
- CONTROL DE INVENTARIO
En la figura 3.4 se presenta el caso de uso secundario del control de inventario:

Figura 3.4. Caso de uso secundario – Control de Inventario

Fuente: Elaboración Propia

- ESPECIFICACIÓN CASO DE USO – CONTROL DE INVENTARIO

En la tabla 3.23 se muestra la especificación de caso de uso del control de inventario:

Tabla 3.23. Especificaciones de caso de uso - Control de Inventario

Fuente: Elaboración Propia

49
- CONTROL DE PROVEEDORES
En la figura 3.5 se presenta el caso de uso secundario del control de proveedores:

Figura 3.5. Caso de uso secundario – Control de Proveedores

Fuente: Elaboración Propia

- ESPECIFICACIÓN CASO DE USO – CONTROL DE PROVEEDORES

En la tabla 3.24 se muestra la especificación de caso de uso del control de proveedores:

Tabla 3.24. Especificaciones de caso de uso - Control de Proveedores

Fuente: Elaboración Propia

50
- FACTURACIÓN
En la figura 3.6 se presenta el caso de uso secundario de la facturación:

Figura 3.6. Caso de uso secundario – Facturación

Fuente: Elaboración Propia

- ESPECIFICACIÓN CASO DE USO – FACTURACIÓN

En la tabla 3.25 se muestra la especificación de caso de uso de facturación:

Tabla 3.25. Especificaciones de caso de uso - Facturación

Fuente: Elaboración Propia

51
- CONTROL DE PERSONAL
En la figura 3.7 se presenta el caso de uso secundario del control de personal:

Figura 3.7. Caso de uso secundario – Control de Personal

Fuente: Elaboración Propia

- ESPECIFICACIÓN CASO DE USO – CONTROL DE PERSONAL

En la tabla 3.26 se muestra la especificación de caso de uso del control de personal:

Tabla 3.26. Especificaciones de caso de uso - Control de Personal

Fuente: Elaboración Propia

52
- REPORTES
En la figura 3.8 se presenta el caso de uso secundario de reportes:

Figura 3.8. Caso de uso secundario – Reportes

Fuente: Elaboración Propia

- ESPECIFICACIÓN CASO DE USO – REPORTES

En la tabla 3.27 se muestra la especificación de caso de uso de reportes:

Tabla 3.27. Especificaciones de caso de uso - Reportes

Fuente: Elaboración Propia

53
b) IDENTIFICACIÓN DE ACTORES
En la tabla 3.28 se detalla la descripción de los actores identificados:

Tabla 3.28. Identificación de actores

Actores Definición
Dueño de la empresa Es la persona que interactúa con todo el sistema web.
Personal Es la persona que solo se encarga de los registros de la
Administrativo producción.
Proveedores Es la persona que provee de productos a la empresa.
Clientes Es la persona encargada de realizar los pedidos o la compra.
Fuente: Elaboración Propia

c) MODELO DE CLASES
A continuación, en la figura 3.9 se observa el diagrama de clases.

Figura 3.9. Diagrama de Clases

Fuente: Elaboración Propia

54
3.2.3.3. DISEÑO

a) MODELO DE PRESENTACIÓN
El modelo de presentación que se muestran correspondiente a los casos de uso citados
anteriormente, representa la parte de diseño que se muestra en el sistema y los módulos.

i) MODELO DE PRESENTACIÓN PARA EL CONTROL DE COMPRAS

En la figura 3.10 se muestra el modelo de presentación para el control de compras:

Figura 3.10.: Modelo de Presentación - Control de Compras

Fuente: Elaboración Propia

ii) MODELO DE PRESENTACIÓN PARA EL CONTROL DE VENTAS

En la figura 3.11 se muestra el modelo de presentación para el control de ventas:

Figura 3.11.: Modelo de Presentación - Control de Ventas

Fuente: Elaboración Propia

55
iii) MODELO DE PRESENTACIÓN PARA EL CONTROL DE INVENTARIO
En la figura 3.12 se muestra el modelo de presentación para el control de inventario:

Figura 3.12: Modelo de Presentación - Control de Inventario

Fuente: Elaboración Propia

iv) MODELO DE PRESENTACIÓN PARA EL CONTROL DE PROVEEDORES

En la figura 3.13 se muestra el modelo de presentación para el control de proveedores:

Figura 3.13: Modelo de Presentación - Control de Proveedores

Fuente: Elaboración Propia

v) MODELO DE PRESENTACIÓN PARA LA FACTURACIÓN

En la figura 3.14 se muestra el modelo de presentación para la facturación:

56
 Figura 3.14: Modelo de Presentación - Facturación
Fuente: Elaboración Propia

vi) MODELO DE PRESENTACIÓN PARA EL CONTROL DE PERSONAL

En la figura 3.15 se muestra el modelo de presentación para el control de personal:

Figura 3.15: Modelo de Presentación - Control de Personal

Fuente: Elaboración Propia

vii) MODELO DE PRESENTACIÓN PARA EL REPORTE A CLIENTES

En la figura 3.16 se muestra el modelo de presentación para el control de inventario:

57
 Figura 3.16: Modelo de Presentación - Reporte a Clientes
Fuente: Elaboración Propia

b) MODELO DE NAVEGACIÓN
Continuando, presentaremos el modelo de navegación correspondiente a los distintos casos
de uso citados anteriormente la cual se realiza mediante nodos y enlaces.

i) MODELO DE NAVEGACIÓN PARA EL CONTROL DE COMPRAS

En la figura 3.17, se presenta el modelo de navegación correspondiente al control de compras
del sistema.

Figura 3.17: Modelo de Navegación - Control de Compras

Fuente: Elaboración Propia

ii) MODELO DE NAVEGACIÓN PARA EL CONTROL DE VENTAS

En la figura 3.18 se presenta el modelo de navegación correspondiente al control de ventas
del sistema.

58
 Figura 3.18: Modelo de Navegación - Control de Ventas
Fuente: Elaboración Propia

iii) MODELO DE NAVEGACIÓN PARA EL CONTROL DE INVENTARIO

En la figura 3.19 se presenta el modelo de navegación correspondiente al control de

inventario del sistema.

Figura 3.19: Modelo de Navegación - Control de Inventario

Fuente: Elaboración Propia

iv) MODELO DE NAVEGACIÓN PARA EL CONTROL DE PROVEEDORES

En la figura 3.20 se presenta el modelo de navegación correspondiente al control de
proveedores del sistema.

59
 Figura 3.20: Modelo de Navegación - Control de Proveedores
Fuente: Elaboración Propia

v) MODELO DE NAVEGACIÓN PARA LA FACTURACIÓN

En la figura 3.21 se presenta el modelo de navegación correspondiente a la facturación del
sistema.

Figura 3.21: Modelo de Navegación - Facturación

Fuente: Elaboración Propia

vi) MODELO DE NAVEGACIÓN PARA EL CONTROL DE PERSONAL

En la figura 3.22 se presenta el modelo de navegación correspondiente al control de personal
del sistema.

60
 Figura 3.22: Modelo de Navegación - Control de Personal
Fuente: Elaboración Propia

vii) MODELO DE NAVEGACIÓN PARA EL REPORTE A CLIENTES

En la figura 3.23 se presenta el modelo de navegación correspondiente al reporte a clientes
del sistema.

Figura 3.23: Modelo de Navegación - Reporte a Clientes

Fuente: Elaboración Propia

c) MODELO ENTIDAD-RELACIÓN

Un modelo entidad-relación o diagrama entidad-relación (a veces denominado por sus siglas

en inglés, E-R"Entity relationship"; en español DER: "Diagrama de Entidad-Relación") es
una herramienta para el modelado de datos que permite representar las entidades relevantes
de un sistema de información, así como sus interrelaciones y propiedades. En la figura 3.24

61
podemos observar las entidades, atributos y el conjunto de relaciones que tiene el sistema.
Son necesarias otras técnicas para lograr un modelo directamente implementarle en una base
de datos. Brevemente:

- Permite mostrar resultados entre otras entidades pertenecientes a las existentes de manera
que se encuentre la normalidad de archivos que se almacenarán.

- Representa una “cosa”, "objeto" o "concepto" del mundo real con existencia
independiente, es decir, se diferencia únicamente de otro objeto o cosa, incluso siendo
del mismo tipo, o una misma entidad.

Figura 3.24: Modelo Entidad - Relación

Fuente: Elaboración Propia

d) MODELO DE RELACIONAL

El modelo relacional, para el modelado y la gestión de bases de datos, es un modelo de datos

basado en la lógica de predicados y en la teoría de conjuntos. Es el modelo más utilizado en
la actualidad para modelar problemas reales y administrar datos dinámicamente.

62
A continuación, en la figura 3.25 se presenta el modelo relacional correspondiente al sistema.

Figura 3.25: Modelo Relacional

Fuente: Elaboración Propia

3.2.4. FASE DE CONSTRUCCIÓN

En esta fase se define los puntos planteados anteriormente y herramientas que se utilizaron
en la elaboración del sistema.

3.2.4.1. IMPLEMENTACIÓN
La implementación constituye la realización de determinados procesos y estructuras en un
sistema.

a) DESARROLLO DE LA SOLUCIÓN
Una vez analizado el problema ya se tiene clara la idea de lo que se requiere y cómo se va
a lograr. En esta instancia se inicia el desarrollo del proyecto.

b) HERRAMIENTAS DE DESARROLLO
En la tabla 3.29 se detalla las herramientas elegidas en la construcción del sistema.

63
 Tabla 3.29. Herramientas de desarrollo
Herramienta Descripción Logo

Apache Servidor Web

Laravel Framework

MagucDraw Diseñador UWE

MySQL Gestor de Base de Datos

PHP Lenguaje de Programación

Sublime Text Editor de texto

Fuente: Elaboración Propia

C) PANTALLAS DEL SISTEMA

En la figura 3.26 están las sucursales donde se pueda añadir, editar o eliminar:

Figura 3.26: Sucursales de la Empresa

Fuente: Elaboración Propia

64
En la figura 3.27 están los artículos existentes donde se puede buscar, editar o eliminar:

Figura 3.27: Artículos de la Empresa

Fuente: Elaboración Propia

En la figura 3.28 se observa como añadir, buscar editar o eliminar a los proveedores:

Figura 3.28: Proveedores de la Empresa

Fuente: Elaboración Propia

65
En la figura 3.29 se observa como añadir, buscar editar o eliminar a los clientes:

Figura 3.29: Clientes de la Empresa

Fuente: Elaboración Propia

En la figura 3.30 se observa como añadir, buscar editar o eliminar las ventas:

Figura 3.30: Ventas de la Empresa

Fuente: Elaboración Propia

En la figura 3.31 se observa como añadir, buscar editar o eliminar las compras:

66
 Figura 3.31: Compras de la Empresa
Fuente: Elaboración Propia

En la figura 3.32 se observa como buscar, editar o eliminar el inventario:

Figura 3.32: Inventario de la Empresa

Fuente: Elaboración Propia

3.2.5. FASE DE TRANSICIÓN

En esta fase la construcción del sistema ya está casi finalizada.

3.2.5.1. PRUEBAS DE ESTRÉS

Desarrollado el sistema, se procede a ejecutar las pruebas correspondientes para poder

verificar la funcionalidad de los procedimientos que se efectúan.

Esta prueba se utiliza normalmente para romper la aplicación. Se va doblando el número de

usuarios que se agregan a la aplicación y se ejecuta una prueba de carga hasta que se rompe.

Este tipo de prueba se realiza para determinar la solidez de la aplicación en los momentos de
carga extrema y ayuda a los administradores para determinar si la aplicación rendirá lo
suficiente en caso de que la carga real supere a la carga esperada. Para tal prueba se utilizará

67
JMeter (herramienta de Apache Software Foundation), es un software de código abierto, que
puede ser utilizado como una herramienta de prueba de carga para analizar y medir el
rendimiento de una variedad de servicios, con énfasis en aplicaciones web.

Para cada ingreso de los usuarios se dejó un tiempo de 1 segundo de periodo de subida, es
decir, los usuarios interactuaran al mismo tiempo, cada uno con una sesión diferente y con
diferentes actividades, se registró los tiempos de respuesta y datos estadísticos generados por
la herramienta JMeter.

Como se puede observar en la figura se muestra el resultado de la prueba con 50 usuarios

ingresados al mismo tiempo en la página de inicio, la página de administración de usuarios
y roles, la página de administración de clientes y servicios, la página de reportes, haciendo
un total de 200 usuarios navegando en el sistema sin ningún problema, obteniendo un error
del 0% en todas las páginas elegidas para la prueba.

Figura 3.33: Resultado de la prueba con 50 usuarios en cada página

Fuente: Elaboración Propia

Por otra parte, si aumentamos el número de usuarios a 100 en cada página, como muestra la
figura, veremos como el sistema web colapsa ya que están en ese momento existen 400
usuarios navegando en ese instante, obteniendo un margen de error entre 30% y 90%

68
 Figura3.34: Resultado de la prueba con 100 usuarios en cada página
Fuente: Elaboración Propia

En conclusión el sistema soporta hasta 50 usuarios por página, si aumenta un usuario más el
sistema colapsa, en algunas páginas tardará en responder, en otras no se obtendrá ninguna
respuesta.

La finalidad de estas pruebas se realiza para conocer la cantidad de usuarios que puede
soportar el sistema y el servidor web de la empresa.

3.2.5.2. PRUEBA

Para verificar la funcionalidad y usabilidad del sistema, se deben realizar pruebas, a

continuación, se muestra el caso de prueba correspondiente a cada módulo.

En la tabla 3.30 se tiene la prueba de correspondencia del control de compras:

Tabla 3.30. Prueba de correspondencia - Control de Compras

Casos de pruebas control de compras
Descripción Controla la entrada de los productos adquiridos
Tipo Funcional
Precondición El personal administrativo debe autenticarse
Postcondición El personal administrativo ingresa al sistema
Procedimiento de pruebas

69
 Actor El dueño de la empresa
El dueño de la empresa entra El sistema valida el nombre de personal del
con nombre de personal dueño de la empresa
Resultado obtenido
Intentos Sin observaciones
Cumple No se encuentra fallas
Fuente: Elaboración Propia

En la tabla 3.31 se tiene la prueba de correspondencia del control de ventas:

Tabla 3.31. Prueba de correspondencia - Control de Ventas

Casos de pruebas control de ventas

Descripción Controla la salida de las ventas

Tipo Funcional

Precondición El dueño de la empresa y el personal

administrativo deben autenticarse

Postcondición El dueño de la empresa y personal

administrativo ingresan al sistema

Procedimiento de pruebas

Actor El dueño de la empresa y personal

administrativo

El dueño de la empresa y El sistema valida el nombre de personal del

personal administrativo entran dueño de la empresa y personal administrativo
con nombre de personal

Resultado obtenido

Intentos Sin observaciones

Cumple No se encuentra fallas

Fuente: Elaboración Propia

70
En la tabla 3.32 se tiene la prueba de correspondencia del control de inventario:

Tabla 3.32. Prueba de correspondencia - Control de Inventario

Casos de pruebas control de inventario

Descripción Controla la entrada y salida de los productos

Tipo Funcional

Precondición El dueño de la empresa y el personal

administrativo deben autenticarse

Postcondición El dueño de la empresa y personal

administrativo ingresan al sistema

Procedimiento de pruebas

Actor El dueño de la empresa y personal

administrativo

El dueño de la empresa y El sistema valida el nombre de personal del

personal administrativo entran dueño de la empresa y personal administrativo
con nombre de personal

Resultado obtenido

Intentos Sin observaciones

Cumple No se encuentra fallas

Fuente: Elaboración Propia

En la tabla 3.33 se tiene la prueba de correspondencia del control de proveedores:

Tabla 3.33. Prueba de correspondencia - Control de Proveedores

Casos de pruebas control de proveedores

Descripción Controla el registro de proveedores

Tipo Funcional

71
 Precondición El dueño de la empresa debe autenticarse

Postcondición El dueño de la empresa ingresa al sistema

Procedimiento de pruebas

Actor El dueño de la empresa

El dueño de la empresa entra El sistema valida el nombre de personal del dueño

con nombre de personal de la empresa

Resultado obtenido

Intentos Sin observaciones

Cumple No se encuentra fallas

Fuente: Elaboración Propia

En la tabla 3.34 se tiene la prueba de correspondencia de la facturación:

Tabla 3.34. Prueba de correspondencia - Facturación

Casos de pruebas facturación
Descripción Registra datos de compra y venta
Tipo Funcional
Precondición El dueño de la empresa y personal administrativo
deben autenticarse
Postcondición El dueño de la empresa y personal administrativo
ingresan al sistema
Procedimiento de pruebas
Actor El dueño de la empresa y personal administrativo
El dueño de la empresa y El sistema valida el nombre de personal del dueño
personal administrativo de la empresa y personal administrativo
entran con nombre de
personal
Resultado obtenido

72
 Intentos Sin observaciones
Cumple No se encuentra fallas
Fuente: Elaboración Propia

En la tabla 3.35 se tiene la prueba de correspondencia del control de personal:

Tabla 3.35. Prueba de correspondencia - Control de Personal

Casos de pruebas control de personal

Descripción Control del registro de personal

Tipo Funcional

Precondición El dueño de la empresa y personal administrativo deben

autenticarse

Postcondición El dueño de la empresa y personal administrativo ingresan

al sistema

Procedimiento de pruebas

Actor El dueño de la empresa y personal administrativo

El dueño de la empresa El sistema valida el nombre de personal del dueño de la

y personal empresa y personal administrativo
administrativo entran
con nombre de personal

Resultado obtenido

Intentos Sin observaciones

Cumple No se encuentra fallas

Fuente: Elaboración Propia

En la tabla 3.36 se tiene la prueba de correspondencia del reporte a clientes:

73
 Tabla 3.36. Prueba de correspondencia - Reporte a Clientes
Casos de pruebas reporte a clientes

Descripción Registra reportes de ofertas a los clientes

Tipo Funcional

Precondición El dueño de la empresa y personal administrativo

deben autenticarse

Postcondición El dueño de la empresa y personal administrativo

ingresan al sistema

Procedimiento de pruebas

Actor El dueño de la empresa y personal administrativo

El dueño de la empresa y El sistema valida el nombre de personal del dueño

personal administrativo de la empresa y personal administrativo
entran con nombre de
personal

Resultado obtenido

Intentos Sin observaciones

Cumple No se encuentra fallas

Fuente: Elaboración Propia

74
 CAPÍTULO IV

CALIDAD Y SEGURIDAD

4.1. INTRODUCCIÓN

En este capítulo se establece la calidad del sistema web en base a parámetros de medición y
medidas de seguridad que tiene el sistema, ya sean los procedimientos, técnicas e
instrumentos aplicados por entes capacitados para garantizar un correcto funcionamiento.

4.2. CALIDAD

4.2.1. METODOLOGÍA WEB - SITE QEM

Es una 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), que propone un enfoque sistemático,
disciplinado y cuantitativo que se adecua a la evaluación, comparación y análisis de calidad
de sistemas de información centrados en la Web, éste mismo está basado en las normas de
calidad de la ISO 9126.

En la tarea “Especificando Requerimientos de Calidad para artefactos Web”, de la ISO 9126,

los evaluadores deben especificar las características, subcaracterísticas y atributos de calidad
agrupándolas en un árbol de requerimientos.

Estas características de alto nivel son: usabilidad, funcionalidad, confiabilidad, eficiencia,

portabilidad, y mantenibilidad (Olsina, 1999).

4.2.1.1. PRINCIPALES FASES, PROCESOS Y ACTIVIDADES DE WEB - SITE

QEM

Se describe para la metodología Web - site QEM, las principales fases, actividades, modelos
y algunos constructores intervinientes en el proceso de evaluación, comparación y ranquin
de calidad.

75
A continuación, en la figura 4.1 se puede observar las fases de la metodología WebQEM y
los pasos del proceso.

Figura 4.1: Fases de WebQEM

Fuente: Olsina, 2007

i) DEFINICIÓN DE LAS METAS DE EVALUACIÓN Y SELECCIÓN DEL

PERFIL DE USUARIO

Los evaluadores deben definir las metas y establecer el alcance del proyecto de evaluación
web. La evaluación puede llevarse a cabo tanto en la fase de desarrollo como en la fase
operativa de un proyecto Web, y se puede valorar la calidad de un producto completo o bien
se puede valorar la calidad de un conjunto de características y atributos de un componente.

Los resultados podrán ser utilizados para comprender, mejorar, controlar o predecir la calidad
de los productos. Por otra parte, la relativa importancia de las características y atributos
dependen del perfil de usuario seleccionado y del dominio de la aplicación.

Para propósito se consideran tres perfiles de usuario a un alto nivel de abstracción, como ser
visitantes, desarrolladores y gerenciadores.

76
ii) DEFINICIÓN DE LOS REQUERIMIENTOS DE CALIDAD Y/O COSTO

Los evaluadores deben acordar y especificar los atributos y características de calidad que van
a estar presentes en el proceso, agrupándolos en un árbol de requerimientos.

A cada atributo se le asocia una variable en el dominio numérico, esta variable puede tomar
un valor real, que podrá ser medido y computado.

iii) DEFINICIÓN DE CRITERIOS DE PREFERENCIA ELEMENTALES Y

PROCEDIMIENTOS DE MEDICIÓN

Los evaluadores deben definir una base de criterios para la evaluación elemental y realizar el
proceso de medición y puntaje elemental.

Un criterio de evaluación elemental declara y especifica cómo medir atributos cuantificables,

el resultado final es una preferencia el cual puede ser interpretado como grado o porcentaje
del requerimiento.

Por lo tanto para cada métrica de un atributo se necesitamos establecer un rango de valores
aceptables y definir la función de criterio que producirá una correspondencia entre el valor
de la métrica con el nuevo valor que representa la preferencia elemental.

iv) DEFINICIÓN DE ESTRUCTURAS DE AGREGACIÓN E

IMPLEMENTACIÓN DE LA EVALUACIÓN GLOBAL

Anteriormente se definieron preferencias de calidad elemental para los atributos

considerados en el árbol de requerimientos. Por lo tanto, aplicando un mecanismo de
agregación paso a paso, las preferencias elementales se pueden agrupar convenientemente
para producir al final un esquema de agregación.

Las preferencias de calidad parcial y global se pueden obtener mediante cálculo conforme al
modelo de agregación y puntaje empleado.

77
v) ANÁLISIS DE RESULTADOS Y RECOMENDACIONES

Una vez diseñado e implementado el proyecto de evaluación, el proceso culmina con la

documentación de las conclusiones y recomendaciones. Los evaluadores analizan los
resultados considerando las metas y el perfil de usuario establecidos (OLSINA, 2007).

4.2.1.2. TIPO DE CRITERIO ELEMENTAL

A continuación, veremos los distintos tipos del criterio elemental:

- Criterio de variable normalizada:

CVN: IE = (X/Y)*100.

Con X=∑ Puntaje obtenido; Y=∑ Puntaje Máximo.

- Criterio Binario:
CB: IE = 0 si No Existe; IE = 1 si existe.
- Criterio de Preferencia Directa:
CPD: Sujeto a la objetividad del observador.
- Criterio de Multiniveles:
CMN: IE = 0 ≈ 0 Ausente;
IE = 1 ≈ 60 Presencia Parcial;
IE = 2 ≈ 100 Presente

4.2.2. FASE DE DEFINICIÓN E IMPLEMENTACIÓN DE LA EVALUACIÓN

ELEMENTAL

Para cada uno de los factores se define u conjunto de características que pueden
descomponerse en múltiples niveles de sub características hasta llegar a los atributos web
cuantificables.

4.2.2.1. CARACTERÍSTICAS Y ATRIBUTOS

A continuación, se procedió a la evaluación de la usabilidad, funcionalidad, confiabilidad y

eficiencia.

78
i) USABILIDAD
Consiste de un conjunto de atributos que permiten evaluar el esfuerzo necesario que deberá
invertir el usuario para utilizar el sistema web.

Es una característica de calidad de producto de alto nivel, que se la puede medir mediante
cálculo a partir de métricas directas e indirectas. Representa la capacidad o potencialidad del
producto para ser utilizado, comprendido y operado por los usuarios, además de ser atractivo.

A continuación, en la tabla 4.1 se realiza la evaluación de la usabilidad:

Tabla 4.1. Resultados de preferencia elemental - Usabilidad

Código Atributo Criterio IEI%

Elemental

1. Usabilidad CVN 89,65

1.1. Comprensibilidad Global del Sitio CVN 100

1.1.1. Esquema de Organización Global CVN 100

1.1.1.1. Mapa del Sitio CB 100

1.1.1.2. Tabla de Contenidos CB 100

1.1.2. Calidad en el Sistema de Etiquetado CB 100

1.1.2.1. Etiquetado Textual CB 100

1.1.1.2. Etiquetado con Iconos CB 100

1.2. Mecanismos de Ayuda y Retroalimentación CVN 96.11

1.2.1. Calidad de Ayuda CVN 95

1.2.1.1. Ayuda Explicadora Oriental de Usuario CPD 90

1.2.1.2. Ayuda de la búsqueda CPD 100

1.2.2. Directorio de Direcciones CVN 93.33

79
 1.2.2.1. Directorio E-mail CB 100

1.2.2.2. Formulario de Entradas CPD 90

1.2.2.3. Reportes CPD 90

1.3. Aspectos de Interfaces y Estéticos CVN 95.83

1.3.1. Cohesividad al Agrupar los Objetos de Control CB 100

Principales

1.3.2. Permanencia y Estabilidad en la Presentación de los CB 100

Controles Principales

1.3.2.1. Permanencia de Controles Directos CB 100

1.3.2.2. Permanencia de Controles Indirectos CB 100

1.3.2.3. Estabilidad CVN 100

1.3.3. Aspectos de Estilo CMN 93.33

1.3.3.1. Uniformidad en el Color de Enlaces CMN 100

1.3.3.2. Uniformidad en el Estilo Global CMN 90

1.3.3.3. Guía de Estilo Global CMN 90

1.3.4. Preferencia Estética CPD 90

Fuente: Elaboración Propia

Se tiene el 89,65% esto quiere decir que si se toma una muestra de 20 usuarios 18 usuarios
tuvieron un correcto funcionamiento y 2 tuvieron errores.

ii) FUNCIONALIDAD

Se define como un conjunto de atributos que otorgan la existencia de un conjunto de

funciones y sus propiedades específicas. Las funciones son aquellas que satisfacen conjuntos
de usuarios declarados o implícitos. (ISO9126, 2005)

A continuación, en la tabla 4.2 se tiene la evaluación elemental para la funcionalidad:

80
 Tabla 4.2. Resultados de preferencia elemental - Funcionalidad
Código Atributo Criterio IEI%

Elemental

2. Funcionalidad CVN 96,25

2.1. Aspectos de Búsqueda y Recuperación CVN 100

2.1.1. Mecanismo de Búsqueda en el Sitio Web CVN 100

2.1.1.1. Búsqueda Restringida CVN 100

2.1.1.1.1. de Productos CB 100

2.1.1.1.2. de Personal CB 100

2.1.1.1.3. de Compras CB 100

2.1.1.1.4. de Ventas CB 100

2.1.1.1.5. de Proveedores CB 100

2.1.1.1.6. de Facturas CB 100

2.1.1.2. Búsqueda Global CMN 100

2.2. Aspectos de Navegación y Exploración CVN 100

2.2.1. Navegabilidad CVN 100

2.2.1.1. Nivel de Desplazamiento CVN 100

2.2.1.1.1. Desplazamiento Vertical CB 100

2.2.1.1.2. Desplazamiento Horizontal CB 100

2.3. Aspectos del Dominio orientados al personal CVN 98.75

Técnico

2.3.1. Relevancia de Contenido CVN 97.5

2.3.1.1. Información de la Empresa CVN 100

81
 2.3.1.1.1. Historia y situación actual del inventario CB 100

2.3.1.1.2. Información de los Requerimientos CB 90

2.3.1.2. Información del Personal CVN 100

2.3.1.3. Información de Ventas CVN 100

Fuente: Elaboración Propia

Si se toma el 96,25% de una muestra de 20 usuarios, esto nos quiere decir que 19 usuarios
tuvieron éxito y 1 tuvo problemas.

iii) CONFIABILIDAD

Se define como un conjunto de atributos que da la habilidad del software para mantener las
condiciones de establecer su propio nivel de desempeño por un periodo determinado.
(ISO9126, 2005)

En la tabla 4.3 se tiene la evaluación elemental para la confiabilidad:

Tabla 4.3. Resultados de preferencia elemental - Confiabilidad

Código Atributo Criterio IEI%
Elemental
3. Confiabilidad CVN 90
3.1. No deficiencia CVN 90
3.1.1. Errores de enlaces CVN 100
3.1.1.1. Enlaces rotos CMN 100
3.1.1.2. Enlaces inválidos CMN 100
3.1.1.3. Enlaces no implementados CMN 100
3.1.2. Errores o deficiencias varias CVN 80
Deficiencia o cualidades ausentes debido a diferentes CMN 100
3.1.2.1.
navegadores(browsers)
Fuente: Elaboración Propia

82
Se tiene el 90% de confiabilidad, si se toma una muestra de 20 usuarios, 18 funcionaron
correctamente y 2 usuarios tuvieron errores.

iv) EFICIENCIA

Se define como un conjunto de atributos que otorgan la relación entre el nivel de rendimiento
del software y la cantidad de recursos usados por el usuario, bajo las condiciones
establecidas. (ISO9126, 2005)

A continuación, en la tabla 4.4 se tiene la evaluación elemental para la eficiencia:

Tabla 4.4. Resultados de preferencia elemental - Eficiencia

Fuente: Elaboración Propia

Se tiene el 95%, esto quiere decir si tomamos una muestra de 20 usuarios, 19 usuarios
funcionaron correctamente y 1 usuario tuvo errores.

4.2.3. CALIDAD GLOBAL

A continuación, en la tabla 4.5 se puede observar los resultados de la calidad global:

83
 Tabla 4.5. Resultados - Calidad Global

Fuente: Elaboración Propia

Se obtuvo un total de 92,725% esto quiere decir que la calidad del sistema es altamente
satisfactoria por lo tanto se considera aceptable el producto. Un ejemplo sería tomar una
población de 20 usuarios ingresaron al sistema y se concluye que de los 20 usuarios por lo
menos 18 usuarios ingresaron correctamente al sistema y el restante que son 2 usuarios
tuvieron problemas para ingresar.

4.3. SEGURIDAD

Los problemas de seguridad para sitios y sistemas web deben ser contemplados desde el
momento del diseño lógico. Los peligros se identifican al principio del proceso de desarrollo
de software y las características de su diseño se especifican de modo que los eliminen o
controlen.

4.4. SEGURIDAD POR NIVELES

Los niveles de seguridad proporcionan acceso a los diferentes módulos del sistema.

4.4.1. SEGURIDAD A NIVEL DE BASE DE DATOS

MySQL implementa seguridad en varios niveles, protección de los ficheros de la base de

datos. Todos los ficheros almacenados en la base de datos están protegidos contra escritura
por cualquier cuenta que no sea la del superusuario de MySQL.

84
 Las conexiones de los clientes al servidor de la base de datos están permitidas, por defecto,
únicamente mediante sockets Unix locales y no mediante sockets TCP/IP.

Esto quiere decir que la conexión a la base de datos sólo se hace forma local, por ejemplo, la
aplicación puede usar esta conexión porque está en el mismo servidor; sin embargo, cualquier
otra aplicación externa al servidor que quiera conectarse a la base de datos mediante sockets
TCP/IP no está permitida.

En ese caso, los sockets TCP/IP solo pueden ser usados para conectarse al servidor.

 Solo se tiene un usuario que puede ingresar a la base de datos y tiene el rol de administrador.
La autenticación de MySQL tiene su propio método interno el cual se hace mediante una
solicitud de autenticación que se compara con un código Hash almacenado localmente.

 Los passwords de los usuarios que pueden ingresar al sistema están almacenados en forma
codificada por el algoritmo MD5.

4.4.2. SEGURIDAD A NIVEL DEL SERVIDOR

La seguridad a nivel del servidor en el desarrollo de una aplicación web requiere de una serie
de herramientas del lado del servidor como: servidores web, servidores de aplicación,
servidores de bases de datos, lenguajes de servidor, los cuales comprometen a la aplicación
si no se elimina:

- Vulnerabilidades debidas al uso de versiones no actualizadas.

- Configuraciones por defecto inadecuadas.
- Activación de cuentas por defecto

4.4.2.1.SERVIDOR WEB

Los problemas de seguridad relacionados con el protocolo HTTP, en función de los datos a
los que pueden afectar, se dividen en: seguridad en el servidor web y seguridad en la red, por
tanto, se tiene:

85
- Seguridad en el servidor web, es necesario garantizar que la información almacenada en la
maquina servidora no pueda ser modificada sin autorización que permanezca disponible y
que solo pueda ser accedida por los usuarios que estén permitidos.

- Seguridad en la red, es cuando un usuario se conecta a un servidor web se produce un

intercambio de información entre ambos, es vital garantizar que los datos que recibe el cliente
desde el servidor sean los mismos que se están enviando y también garantizar que la
información que el usuario envía hacia el servidor no sea capturada, por un atacante.

4.4.3. SEGURIDAD A NIVEL DE APLICACIÓN

Los ataques a nivel de aplicación son una amenaza en constante aumento contra la seguridad
web. Utilizan una gran variedad de medios para paralizar un sitio Web e introducirse en él,
lo que provoca resultados que varían desde un menor rendimiento del sitio Web hasta robos
de datos y una desprotección de la infraestructura.

La seguridad web se divide en:

- Integridad, consistente en que el activo de información no ha sido alterado de manera no

autorizada, además de garantizar que los datos sean los que se supone que son.
- Confidencialidad, asegurar que solo los individuos autorizados tengan acceso a los recursos
que se intercambian.
- Disponibilidad, garantizar el correcto funcionamiento de los sistemas de información.
- Autenticación, asegurar que solo los individuos autorizados tengan acceso a los recursos.

- Trazabilidad, consiste en que las actualizaciones de una entidad pueden ser imputadas
exclusivamente a dicha entidad.

4.4.3.1. AUTENTICACIÓN

Gracias a una contraseña que sirve para verificar nombre de usuarios y contraseñas que se
registra encriptados con MD5 en la base de datos, se puede garantizar el acceso a recursos
únicamente a las personas autorizadas.

86
4.4.3.2. CONTROL DE ACCESO

Es el control de acceso de los usuarios a zonas restringidas de la aplicación, en este control

intervienen los conceptos de Autenticación y Autorización.

El framework Laravel que utilizamos tiene las siguientes características más relevantes en
cuanto a seguridad relacionadas con las tareas que realiza el sistema tales como:

i) AUTENTICACIÓN Y AUTORIZACIÓN

La autenticación y la autorización van ligadas principalmente a los accesos de los usuarios a

distintos niveles de información. El proceso de autenticación implementa la autenticación de
usuarios tanto como empleados como administrador del sistema que corresponde al jefe
quien determinara las autorizaciones que estén permitidas, además permite verificar la
compatibilidad y la procedencia ya sea de un programa, una función, una secuencia o una
persona.

ii) SEGURIDAD EN FORMULARIOS

Todos los formularios presentados a los diferentes usuarios fueron completamente validados
empleando las facilidades que nos brindó el helper de form validation verificando aspectos
relevantes como el password solicitándolo 2 veces para garantizar que fuera escrito
correctamente y comprobando también que la dirección electrónica proporcionada fuera
adecuada, no permitiendo que se enviaran formularios incompletos o incorrectamente
diligenciados e informando a los usuarios acerca de los campos faltantes o incorrectos para
su oportuna corrección.

87
 CAPÍTULO V

ANÁLISIS COSTO BENEFICIO

5.1. INTRODUCCIÓN

En este capítulo se consideran los costos de desarrollo dado que no podría hablar de los costos
de equipos para la implementación del sistema ya que la institución cuenta con una tecnología
que le permite satisfacer los requerimientos de software y hardware.

5.2. MÉTODO COCOMO II

A pesar que la solución informática fue desarrollada por una sola persona en el marco de un
Proyecto de Grado, es importante conocer la estimación real del costo del proyecto en
condiciones reales, así como tener presente la valoración del tiempo y del esfuerzo necesario
para el emprendimiento, traducido en índices monetarios. Un método para calcular estos
parámetros es el COCOMO II (COnstructive COst MOdel), modelo que en su segunda
versión, está orientado a los Puntos Función. Para estimar el costo total del sistema se
tomarán en cuenta los siguientes costos: Costo de la elaboración del proyecto, costo del
software desarrollado y costos de la implementación del sistema.

5.3. COSTO DEL PROYECTO

5.3.1. PUNTO FUNCIÓN

Primero se debe hallar los puntos función no ajustados (PFNA) para esto se parte de la
identificación de 5 características que se detallan a continuación.

Tabla 5.1. Interfaces Parámetros de medición

PARÁMETROS DE FACTOR DE
CUENTAS TOTALES
MEDICIÓN PONDERACIÓN
N° de entradas de usuario 15 3 4 6 45
N° de salidas de usuario 15 4 5 7 60

88
 N° de peticiones de usuario 4 5 4 6 16
N° de archivos 12 7 10 15 84
N° de interfaces externas 0 2 7 10 0
TOTAL, DE CUENTAS 205
Fuente: COCOMO II, 2009

5.3.1.1. CÁLCULO DE FACTOR DE AJUSTE DE LA COMPLEJIDAD

Los valores son expresados en la escala de 0 a 5, donde el 0 no es importante y el 5 es

fundamental, se tiene la tabla5.2:

Tabla 5.2. Cálculo de punto de función ajustada

Fuente: COCOMO II, 2009

A continuación, se calcula el factor de ajuste en la tabla 5.3:

89
 Tabla 5.3. Factor de Ajuste
Factor de ajuste 0,65+0,01*fi()

Factor de ajuste 0,65+0,01*47

Factor de ajuste 1,12

Fuente: Elaboración Propia

A continuación, en la ecuación 5.1 se obtiene el Punto Función Ajustado (PFA):

𝑃𝐹𝐴 = 𝑃𝐹 ∗ (0.65 + 0.01 * ∑Fi) Ecuación 5.1

Reemplazando PF que está dado por el total de cuentas de la tabla 5.1 y el total (∑Fi) de la
tabla 5.2 en la ecuación 5.1 se tiene:

𝑃𝐹𝐴 = 205 ∗ (0.65 + 0.01 * 47)

𝑃𝐹𝐴 = 205 ∗ (1.12)

𝑃F𝐴 = 229.6

5.3.2. CONVERSIÓN DE PFA LDC (LÍNEAS DE CÓDIGO)

Esta conversión se la realiza en la tabla 5.4 tomando en cuenta el lenguaje de

implementación:

Tabla 5.4. Tabla de conversión factor LDC

Lenguaje LDC / PF
Ensamblador 320
C 128
ANSI COBOL 105
Pascal 90
PHP 29

90
 C++ 64
Visual Basic 42
SQL 12
Fuente: COCOMO II, 2009

La fórmula para el cálculo de líneas de código LDC está dada por la ecuación 5.2

LDC = PFA * Factor LDC/PF Ecuación 5.2

Reemplazando el valor obtenido PFA de la ecuación 5.1 en la ecuación 5.2 se tiene:

LDC = 229.6 * 29

LDC = 6658.4

A continuación, se tiene la ecuación 5.3 para calcular Kilo líneas de código o miles de líneas
de código (KLDA):

𝐿𝐷𝐶
𝐾𝐿𝐷𝐶 =1000 Ecuación 5.3

Reemplazando el valor obtenido de la ecuación 5.2 en la ecuación 5.3 se tiene:

6658.4
𝐾𝐿𝐷𝐶 = 1000

𝐾𝐿𝐷𝐶 = 6.66

5.3.3. ESTIMACIONES DE ESFUERZO Y ESTIMADO PARA HALLAR LA

DURACIÓN DEL PROYECTO

5.3.3.1. ESFUERZO NOMINAL

A continuación, se calculará el esfuerzo nominal que está dado por la siguiente formula:

PMNominal = A * (KLDC) B Ecuación 5.4

Calculando B con la siguiente fórmula:

91
 B = 0.91 + 0.01 * ∑5𝑗=1 Wj Ecuación 5.5

Donde:

B: Factor exponencial de escala, basado en factores de escala que influyen exponencialmente

en la productividad.

Wj: Factores de escala

PMNominal : Esfuerzo nominal del proyecto de software

KLDC: Tamaño del software a desarrollar expresado en miles de líneas de código fuente

A: Constante derivada de la calibración igual a 2.94.

 Factores de escala (Wj)

Los siguientes factores exponenciales de escala B que influyen en la productividad y

esfuerzo.

Tabla 5.5. Tabla de Factores de Escala

Factores de escala (Wj) Significado

PREC(Procedencia) Experiencia en la aplicación del mismo tipo.

FLEX(Flexibilidad de desarrollo) Grado de sujeción del desarrollo a tiempo y

requisitos.

RESL(Resolución de arquitectura y Identificación de riesgos en la aplicación.

riesgos)

TEAM(Cohesión de equipo) Nivel de integración del equipo de desarrollo.

PMAT(Madurez del proceso) Experiencia en el modelo de desarrollo.

Fuente: COCOMO II, 2009

En la tabla 5.6 se describe el factor de escala Wj.

92
 Tabla 5.6. Tabla de Factor de Escala Wj
Factores Muy Bajo Nominal Alto Muy Extra
de Escala Bajo Alto Alto

PREC 6.2 4.96 3.72 2.48 1.24 0

FLEX 5.07 4.05 3.04 2.03 1.01 0

RESL 7.07 5.65 4.24 2.83 1.41 0

TEAM 5.48 4.38 3.29 2.19 1.1 0

PMAT 7.8 6.29 4.68 3.12 1.56 0

Fuente: COCOMO II, 2009

Mediante la ecuación 5.5 hallamos el esfuerzo nominal de proyecto.

B = 0.91+0.01*(1.24+2.03+0+1.1+3.12)

B = 0.98

Remplazando B en la ecuación 5.4

PMNominal = A * (KLDC)B

PMNominal = 2.94 * (6.66)0.98

PMNominal = 18.85 [Personas*mes]

El resultado del esfuerzo nominal del proyecto de software quiere decir que se necesitan 19
personas trabajando a jornada completa por un mes para terminar el proyecto en ese tiempo.

5.3.3.2. ESFUERZO ESTIMADO

A continuación, la ecuación 5.6 realizará el cálculo del esfuerzo estimado:

93
 PMEstimado=PMNominal* ∏17
𝑡=1 𝐸𝑀 i Ecuación 5.6

Donde:

PMEstimado: Esfuerzo estimado del proyecto que está basado en los multiplicadores de esfuerzo
para su ejecución.

EMi: Factor de esfuerzo compuesto obtenido a partir de los indicadores.

PMNominal: Esfuerzo nominal del proyecto

 Multiplicadores de esfuerzo

Servirán para hallar el esfuerzo inicial, estos se clasifican en cuatro grupos que se verá en la
tabla 5.7 a continuación:

Tabla 5.7. Tabla de multiplicadores del esfuerzo requerido

FACTOR DE ESFUERZO POST ARQUITECTURA
Producto RELY DATA DOCU CPLX RUSE
Plataforma TIME STOR PVOL
Personal ACAP AEXP PCAP PEXP LTEX PCON
Proyecto TOOL SITE SCED
Fuente: COCOMO II, 2009

Donde la nomenclatura empleada es la siguiente:

RELY: Seguridad requerida

DATA: Tamaño de la base de datos

DOCU: Documentación adaptada al ciclo de vida

CPLX: Complejidad

RUSE: Reutilización requerida

94
TIME: Tiempo de ejecución requerido

STOR: Almacenamiento principal requerido

PVOL: Volatilidad de la plataforma

ACAP: Capacidad del análisis

AEXP: Experiencia del analista

PCAP: Capacidad del programador

PEXP: Experiencia en la plataforma del Sistema operativo

LTEX: Experiencia en lenguaje y herramienta

PCON: Continuidad del personal

TOOL: Uso de herramientas de SW

SITE: Desarrollo multitarea

SCED: Esquema de desarrollo programado

A continuación, se tiene la tabla 5.8 con los multiplicadores de esfuerzo seleccionado:

Tabla 5.8. Conductores de costo

Conductores N° Multiplicadores Muy Bajo Nominal Alto Muy Extra
de costos de Esfuerzo Bajo Alto Alto
1 RELY 0,82 0,92 1 1,1 1,26 -
2 DATA - 0,9 1 1,1 1,28 -
PRODUCTO 3 CPLX 0,73 0,87 1 1,2 1,34 -
4 RUSE - 0,95 1 1,1 1,15
5 DOCU 0,81 0,91 1 1,1 1,23 -
PLATAFORMA 6 TYME - - 1 1,1 1,29 -

95
 7 STOR - - 1 1,1 1,17 -
8 PVOL - 0,87 1 1,2 1,3 -
9 ACAP 1,42 1,19 1 0,9 0,71 -
10 PCAP 1,34 1,15 1 0,9 0,76 -
11 PCON 1,29 1,12 1 0,9 0,81 -
PERSONAL
12 AEXP 1,22 1,1 1 0,9 0,81 -
13 PEXP 1,19 1,09 1 0,9 0,85 -
14 LEXP 1,2 1,09 1 0,9 0,84 -
15 TOOL 1,17 1,09 1 0,9 0,78 -
PROYECTO 16 SITE 1,22 1,09 1 0,9 0,86 0,8
17 SCED 1,43 1,14 1 1 1 -
Fuente: COCOMO II, 2009

A continuación, utilizando la ecuación 5.6 hallamos el esfuerzo estimado:

PMEstimado = PMNominal* ∏17

𝑡=1 𝐸𝑀 i

Reemplazando el resultado obtenido de la ecuación 5.4 y los valores seleccionados de la tabla

5.8 en la ecuación 5.6 se tiene:

PMEstimado = 18.85*(1*1*0.73*1*1*1*1*0.87*0.9*0.76*1*1*1*1*1*1*1.14)

PMEstimado = 18.85 * 0.47

PMEstimado = 8,86

Este resultado quiere decir que aproximadamente se necesitan 9 personas trabajando a

jornada completa por un mes para desarrollar el proyecto.

5.4. ESTIMACIONES DE DURACIÓN DE PROYECTO

La ecuación para hallar la duración estimada del proyecto está dada por la ecuación 5.7 que
se muestra a continuación:

96
 𝐷
Destimada = [C * P𝑀𝐸𝑠𝑡𝑖𝑚𝑎𝑑𝑜 ] Ecuación 5.7

Donde:

Destimada: Duración estimada del proyecto

D: Exponente de escalamiento

Con la ecuación 5.8 se determina el exponente de escalamiento:

(D=0.28+0.2*(B-0.91)) Ecuación 5.8

PMEstimado: Esfuerzo estimado del proyecto de software

C: Coeficiente de planificación (C = 3.67)

Mediante el resultado B de la ecuación 5.5 se calculará la ecuación 5.8:

D=0.28+0.2*(B-0.91)

D=0.28+0.2*(0.98-0.91)

D=0.294

A continuación, reemplazamos D en la ecuación 5.7:

𝐷
Destimada = [C * P𝑀𝐸𝑠𝑡𝑖𝑚𝑎𝑑𝑜 ]

Destimada = [3.67 *8.860.294]

Destimada = 6.97[mes]

El resultado nos indica que la duración del desarrollo del proyecto es aproximadamente 7
meses.

5.5. ESTIMACIÓN DEL PERSONAL DEL PROYECTO

La estimación del personal está dada por la ecuación 5.9

97
 𝑃𝑀𝐸𝑠𝑡𝑖𝑚𝑎𝑑𝑜
Pestimado = Ecuación 5.9
𝐷𝑒𝑠𝑡𝑖𝑚𝑎𝑑𝑎

Donde:
Pestimado: Personal estimado para el proyecto
PMEstimado: Esfuerzo estimado para el desarrollo del sistema
Destimada: Duración estimada del proyecto

Reemplazando los resultados obtenidos de la ecuación 5.6 y de la ecuación 5.7 en la ecuación

5.9 se tiene:
𝑃𝑀𝐸𝑠𝑡𝑖𝑚𝑎𝑑𝑜
Pestimado = 𝐷𝑒𝑠𝑡𝑖𝑚𝑎𝑑𝑎

8.86
Pestimado = 6.97

Pestimado = 1.27 [Personas]

Por lo cual se puede concluir que para desarrollar el sistema se necesita solo de 1
programador.

5.6. COSTO DE DESARROLLO

Para calcular el costo de desarrollo del sistema se cuenta con la siguiente ecuación:

CostoDesarrollo = NumeroProgramadores * Destimada * SalarioProgramador Ecuación 5.10

Tomando en cuenta que un programador gana 4200 Bs, por lo tanto, reemplazamos en la
ecuación 5.10 se obtiene:

CostoDesarrollo = 1*7*4200
CostoDesarrollo = 29400 Bs

5.7. COSTO DE IMPLEMENTACIÓN Y ELABORACIÓN

El costo calculado del proyecto incluye la fase de inicio, elaboración, construcción y

transición. Estos costos se aprecian en la tabla 5.9:

98
 Tabla 5.9.
Detalle Costo [Bs]
- Internet 300
- Computadora personal portátil 3500
- Material de escritorio 280
- Servidor Web 850
TOTAL 5430
Costo de implementación y elaboración del proyecto
Fuente: Elaboración Propia

5.8. COSTO TOTAL DE LA ELABORACIÓN DEL PROYECTO

El costo total de la elaboración del proyecto se obtendrá con la ecuación 5.11

CTEProyecto = CostoDesarrollo + CostoImplementación Ecuación 5.11
CTEProyecto = 29400 + 5430
CTEProyecto = 34830 Bs

5.9. CÁLCULO BENEFICIO TIR Y VAN

El VAN y TIR son dos herramientas financieras del mundo de las finanzas muy potentes y
nos dan la posibilidad de evaluar la rentabilidad que nos pueden dar los diferentes proyectos
de inversión. En muchos casos, la inversión en un proyecto no se da como inversión sino
como la posibilidad de poner en marcha otro negocio debido a la rentabilidad (Economía
Finanzas, 2015).

5.9.1. VALOR ACTUAL NETO (VAN)

El valor actual neto (VAN) es un indicador financiero que sirve para determinar la viabilidad
de un proyecto. Si tras medir los flujos de los futuros ingresos y egresos y descontar la
inversión inicial queda alguna ganancia, el proyecto es viable (Molina, 2017).

A continuación, se muestra la interpretación del VAN.

99
VAN > 0; Se recomienda pasar a la siguiente etapa del proyecto.

VAN = 0; Es indiferente realizar la inversión.

VAN < 0; Se recomienda desecharlo o postergarlo.

A continuación, realizamos la caja de flujo en años con una inversión 34830 Bs que se ve en
la tabla 5.10

Tabla 5.10. Flujo de caja por año

Año 0 1 2 3 4 5
(2016) (2017) (2018) (2019) (2020) (2021)
Flujo de
-34830 6000 9000 9500 10000 20000
Cajas (Bs)
Fuente: Elaboración Propia

En la ecuación 5.12 se muestra la fórmula del VAN

𝑛 𝐶𝑖
VAN = - C0 + ∑𝑖=1 Ecuación 5.12
(1+𝑘)𝑖

Donde:
𝐶i: Flujo de caja.
𝐶0: Desembolso inicial o inversión inicial.
k: Tasa de descuento seleccionada.
n: vida útil del proyecto.
i: periodo

A continuación, reemplazamos los datos de la tabla 5.7 a la siguiente ecuación:

100
 VAN = 4448.61 Bs

Observando el resultado del VAN nos indica que el proyecto es aceptable ya que el resultado
es mayor a cero.

5.9.2. TASA DE INTERÉS DE RETORNO (TIR)

La (TIR) o tasa interna de retorno es una herramienta financiera de gran importancia en la

elaboración de proyectos, permite viabilizar el proyecto desde el punto de vista financiero.
Consiste en determinar cuál es la inversión inicial del proyecto, identificar la segmentación
del mercado y usar las herramientas de inteligencia de mercados para obtener un pronóstico
de ventas.

La TIR se determina con los siguientes indicadores relevantes:

TIR > i; El proyecto es rentable.

TIR = i; Es indiferente su realización.

TIR < i; El proyecto no es rentable.

En la ecuación 5.13 se hallará la tasa de interés de retorno:

TIR = 14%
Lo que nos dice que el 14% > 10%, por lo tanto, el proyecto es rentable.

5.10. COSTO BENEFICIO

A continuación, se toma en cuenta la ecuación 5.14

Donde:

101
t: Periodo
n: número de Periodos
Bt: ingresos Generados durante el periodo t
Ct: costos exigidos en el periodo t
X: tasa de descuento correspondiente al periodo t

Costo/beneficio = 1.56 Bs

Por lo tanto, se concluye que por 1 Bs invertidos se tiene una ganancia de 0.56 ctvs., por lo
que se concluye que el proyecto es rentable.

102
 CAPÍTULO VI
CONCLUSIONES Y RECOMENDACIONES

6.1. CONCLUSIONES

Para el objetivo general se logró desarrollar el sistema web de control de compras, ventas e
inventarios para la empresa ELECTROLUX, lo cual mejoro el manejo y la actualización de
datos.

Para los objetivos específicos se tiene:

 El sistema web genera registros de compras, ventas e inventarios.

 Informatización de los procesos de compra, venta, inventario, facturación, control de
personal y reportes, de manera que la información ahora se encuentra a disposición del
personal de trabajo para hacer el control adecuado a dichos procesos.

● El registro de artículos para obtener información correcta y actualizada para la compra

y venta se puede realizar de forma sencilla.
● El administrador o el personal de trabajo puede actualizar información sobre el ingreso
y salida de los artículos en el inventario.
● Se centralizó la información de cada sucursal.
● Se automatizó la información de facturación para el envío por correo de manera que se
pueda reducir costos de papel.
● El sistema web cuenta con el control del personal de trabajo.
● El sistema web realiza un reporte a los clientes de la empresa.

6.2. RECOMENDACIONES

Ahora que se ha implementado la solución desarrollada para la empresa ELECTROLUX, se

tropezaron con ciertos inconvenientes relacionados a las tecnologías.

Esto no fue un obstáculo para el funcionamiento normal de los procesos, ya que son
subsanados con el uso correcto del funcionamiento.

103
En cuanto a la empresa ELECTROLUX en general podemos recomendar que en el área de
ventas se implemente un sistema contable.

Se recomienda la actualización y mantenimiento del sistema implantado, esto para un

correcto funcionamiento y evitar sorpresivas fallas en el presente y futuro.

En el control de personal que genere planillas de salarios y sueldos, cálculo de aportes al

seguro, cotización de cuentas individuales y que se pueda generar una planilla de resúmenes
de cotizaciones.

104
BIBLIOGRAFÍA

Aduviri, P. (2016). Sistema Web de Control de Ventas e Inventarios Caso: Michelline

(Proyecto de Grado). Universidad Mayor de San Andrés, La Paz, Bolivia.
Recuperado de
https://repositorio.umsa.bo/bitstream/handle/123456789/9987/T.3231.pdf?sequence
=1&isAllowed=y

Villca, E. (2018). Aplicación Móvil de Control de Ventas e Inventarios con Alertas

Tempranas Caso: Empresa Importadora y Distribuidora de Alimentos e Insumos para
Mascotas San Gabriel Pet (Proyecto de Grado). Universidad Mayor de San Andrés,
La Paz, Bolivia. Recuperado de
https://repositorio.umsa.bo/bitstream/handle/123456789/17486/T-
3419.pdf?sequence=1&isAllowed=y

Calle, W. (2018). Sistema en Plataforma Mixta para el Control Ventas e Inventarios con
código QR Caso: Importadora L.U.C.E.R. (Proyecto de Grado). Universidad Mayor
de San Andrés, La Paz, Bolivia. Recuperado de
https://repositorio.umsa.bo/bitstream/handle/123456789/17657/T3451.pdf?sequence
=1&isAllowed=y

Ramírez, N. (2015). Metodología de la Investigación (Investigación e Innovación) Parte I.

Elementos Básicos.

Medina, L. (2014). Metodología Open Up. Recuperado de

http://openup3.blogspot.com/2014/02/metodologia-open-up.html

Cruz, K. (2013). Control de Ventas e Inventario para el Monitoreo de Pedidos Caso: Empresa
Distribuidora VMCC (Proyecto de Grado). Universidad Mayor de San Andrés, La
Paz, Bolivia. Recuperado de

105
 https://repositorio.umsa.bo/bitstream/handle/123456789/7782/T.2726.pdf?sequence
=1&isAllowed=y

Robles G, Ferrer J, (2002), Programación Extrema y Software Libre, Universidad Rey Juan
Carlos y Universidad Politécnica de Madrid

Castillo, O., Figueroa, D., & Sevilla, H. (s.f.). Programación Extrema. (en línea) (consulta 5
de enero de 2020)

Gonzales Alvarán, L. F., Reyes Gamboa, A. X., & Vásquez Echavarría, G. H. (2010). Diseño
de Aplicaciones Basadas en Arquitecturas Orientadas a Servicios utilizando WebML.
Antioquía: Instituto Internacional de Informática y Sistemas. (en línea) (consulta 5 de
enero 2020)

Jarquín, P. S. (2015). Ingeniería Web. (en línea) (consulta 5 de enero de 2020).

Laboratorio Nacional de Calidad del Software. (marzo de 2009). INGENIERÍA DEL

SOFTWARE: METODOLOGÍAS Y CICLOS DE VIDA. Madrid, España.
Recuperado el 11 de agosto de 2015

Mestras, J. P. (13 de 11 de 2015). El Patrón Modelo-Vista-Controlador (MVC). Universidad

Complutense de Madrid - Carrera de Informática: (en línea) (consulta 5 de enero de
2020)

Olsina, L. (1999). Metodología Cuantitativa para la Evaluación y la Comparación de la

Calidad de Sitios Web. La Plata. (en línea) (consulta 5 de enero de 2020)

Web Modeling Language. (s.f.). Obtenido de (en línea) (consulta 5 de enero 2020)

106
Anexo A - Árbol de problemas

Retraso en el
Los registros de las trabajo
compras, ventas e
inventarios son realizados de
forma manual Falta de
organización en el
¿Cómo mejorar el cobro de compras
La información de compras, y ventas
control de compras, ventas e inventarios no está
ventas e inventarios centralizada
de la empresa
ELECTROLUX?
La facturación se realiza de
forma manual, no se tiene un
control de personal y no
existe reporte a clientes. Pérdida de tiempo

Anexo B - Árbol de objetivos

Automatizar el trabajo Agilizar el trabajo

manual

Mejorar la
organización en el
Centralizar la cobro de compras y
Contar con un sistema información de las ventas
web para el control de sucursales
compras, ventas e
inventarios

Facturación por correo,

contar con un control de Optimizar el tiempo
personal y realizar reporte de trabajo
a clientes.

107
Anexo C - Marco Lógico

INDICADORES
RESUMEN MEDIOS DE
VERIFICABLES
NARRATIVO DE VERIFICACIÓ SUPUESTOS
OBJETIVAMEN
OBJETIVOS N
TE

FIN DEL
PROYECTO Reducir el trabajo Entrevista con el Instalación del
. manual del gerente de la Sistema.
Controlar las compras, personal. empresa Preparación y/o
ventas e inventarios Reducir el tiempo a Electrolux capacitación de los
realizando registros de la hora de hacer el administrativos y
cada uno de las registro manual de Observación sobre empleados de la
actividades las compras, ventas el control que empresa.
e inventarios. realizan a las Existencia de
Reducir el tiempo actividades de Software y
de la Emisión de compra, venta e Hardware para el
reportes. inventarios. desarrollo del
sistema.

PROPÓSITO DEL Contar con la Observación de Disponibilidad de

PROYECTO posibilidad de tener las actividades que datos de entrada y
Implementar un conexión a internet realizan al hacer el salida.
sistema web de control constante por el llenado manual de
de compras, ventas e usuario en un las actividades de
inventarios tiempo menor. comprar, ventas e
inventarios.

108
COMPONENTES Módulo de registro Carta de
de compras. aceptación por Contar con el apoyo
Diseñar e implementar Módulo de parte de la del gerente,
la base de datos para administración de empresa que avala administrativos y
que el sistema sea usuarios. el sistema empleados.
accesible y funcional Módulo de registro
desde la web. de proveedores. Carta de
Módulo de registro aceptación por
de compras. parte del docente
Módulo de control Tutor.
de inventarios.
Módulo de ventas Documentación
del sistema Web.

ACTIVIDADES Presentación de Disposición de

Hacer el estudio Se prevé establecer documentos de software para la
preliminar reuniendo el tiempo que se estudio realización de la
información actual demorara en cada preliminar. programación.
sobre los procesos que una de las tareas. Presentación de Disposición de
se realiza en la documentos de hardware necesario
empresa. análisis y diseño. para llevar a cabo la
Diseño lógico, físico y Manual de usuario instalación.
documentación. y manual de Contar con recursos
sistema. económicos y
materiales.

109