UNIVERSIDAD PÚBLICA DE EL ALTO

CARRERA INGENIERÍA DE SISTEMAS

PROYECTO DE GRADO
SISTEMA DE INFORMACIÓN WEB PARA LA GESTIÓN DE COMPRA
Y VENTA E INVENTARIOS DE COMPONENTES ELECTRÓNICOS
CASO: EMPRESA TECHSBOL

Para optar al título de Licenciatura en Ingeniería de Sistemas

MENCIÓN: INFORMÁTICA Y COMUNICACIONES

Postulante: Jeaneth Delicia Bautista Luque

Tutor Metodológico: M.Sc. Marisol Arguedas Balladares

Tutor Especialista: Ing. Ramiro Kantuta Limachi

Tutor Revisor: Lic. Freddy Salgueiro Trujillo

EL ALTO – BOLIVIA

2020
DEDICATORIA
A mi madre, Teodora Luque Layme por brindarme su apoyo
incondicional y confianza, consejos que me inculcó para seguir
en cada etapa de mi vida personal y superarme
profesionalmente, una padre y madre ejemplar para mí.
A mi esposo Martin Yujra y mi hijo Jhoel Mathias, que forman
parte de mi vida y motivo para seguir luchando y superando las
dificultades, que día a día me dieron esas ganas de seguir
adelante.
A mis hermanos/hermanas que supieron aconsejarme para no
rendirme.

ii
AGRADECIMIENTO
Agradecer primeramente a Dios, por iluminar mi camino y darme
la familia tan linda que tengo.

A mis hermanos por la motivación y la confianza que me

brindaron hasta llegar a esta etapa de mi vida.

A mis tutores Metodológico, Especialista y Revisor: M.Sc.

Marisol Arguedas Balladares, Ing. Ramiro Kantuta Limachi,
Lic. Freddy Salgueiro Trujillo, quienes supieron guiarme con
mucha paciencia sus observaciones y sugerencias para el
desarrollo y conclusión del presente proyecto de grado

A mis amigos de carrera por su amistad y apoyo moral durante la

vida universitaria, gracias a todos.

iii
 RESUMEN

Durante en los últimos años los sistemas información se han convertido en una tecnología
fundamental y precisa para el crecimiento de empresas, instituciones públicas y privadas,
proporcionando información que se use como base para el proceso de toma de decisiones.
La web ha evolucionado desde su creación de forma rápida en diferentes aspectos, los sistemas
de información transforman las instituciones y cambia su estructura por lo que permiten
administrar, procesar datos en cualquier parte del mundo sin importar su plataforma de
procesamiento, que hoy en día, resulta casi indiscutible que la información cumple papel
fundamental en toda la empresa para su adecuado funcionamiento.
El presente proyecto de Grado titulado “Sistema de Información Web para la Gestión de
Compra y Venta e Inventarios de componentes Electrónicos” CASO: EMPRESA TECHSBOL.
Esta es una empresa dedicada a ofrecer sus productos de componentes electrónicos en General
y realizan servicios de instalaciones a domicilios.
Los problemas en esta empresa radicaban una gran cantidad de información mal almacenada
que producía una gran pérdida de tiempo al momento de reportes, registrar productos, registrar
ventas, realizar pedidos y actualización de productos manualmente. En el presente documento
se da a conocer la solución que se hizo para este problema para la empresa. Una breve
explicación de las herramientas, metodologías a utilizarse y finalmente la forma en que se hará
uso de estas herramientas y metodologías para lograr un sistema confiable y eficiente. El
resultado de este proyecto de implementación de un sistema, será el de lograr que la empresa y
el área de ventas logre una gran evolución en el ámbito de la información.
En el presente proyecto se usó la metodología UWE (UML-Based Web Engineering, en español
web Basado en UML), está basado en Proceso Unificado para el desarrollo de aplicaciones web.
Se evaluará la calidad del Software con el modelo en cuanto a la seguridad de la información
se recurrió a la norma ISO 27000 y finalmente para la estimación del costo se usó COCOMO
basado en el peso o líneas de código.

En el desarrollo de software se utilizó el lenguaje PHP, servidor de base de datos MariaDB,

FrameWorks Laravel, jQuery y Bootstrap, y en la parte de diseño HTML, JavaScript, y CSS.

iv
 INDICE
1. MARCO PRELIMINAR ........................................................................................................ 1

1.1 Introducción ......................................................................................................................... 1

1.2 Antecedentes......................................................................................................................... 2

1.2.1 Antecedentes Institucionales ............................................................................................. 2

1.2.2. Antecedentes de Trabajos a Fines ................................................................................... 2

1.3 PLANTEAMIENTO DEL PROBLEMA ............................................................................. 3

1.3.1. Problema Principal ........................................................................................................... 3

1.3.2. Problema Secundarios ...................................................................................................... 3

1.4 OBJETIVOS ......................................................................................................................... 4

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

1.4.2. Objetivo Específicos ......................................................................................................... 4

1.5 JUSTIFICACIÓN ................................................................................................................. 4

1.5.1. Justificación Técnica ........................................................................................................ 4

1.5.2. Justificación económica .................................................................................................... 5

1.5.3. Justificación Social ........................................................................................................... 5

1.6 METODOLOGÍA................................................................................................................. 5

1.6.1. Método De Ingeniería ....................................................................................................... 5

1.6.3. Métodos de Estimación de Costos .................................................................................... 7

1.6.4. PRUEBAS DE SOFTWARE ........................................................................................... 7

1.7 HERRAMIENTAS ............................................................................................................... 8

1.8 LÍMITES Y ALCANCES .................................................................................................... 9

1.8.1. Limites ............................................................................................................................. 9

1.8.2. Alcances ........................................................................................................................... 9

1.9 APORTE............................................................................................................................. 10

v
2. MARCO TEORICO ............................................................................................................. 12

2.1 INTRODUCCIÓN .............................................................................................................. 12

2.2 Sistema ............................................................................................................................... 12

2.2.1. Sistemas de Información ................................................................................................ 12

2.2.2. Características de un Sistema de Información ................................................................ 13

2.2.3. Componentes de un sistema de información. ................................................................. 13

2.3 GESTIÓN DE VENTAS .................................................................................................. 13

2.3.1. La venta como proceso ................................................................................................... 14

2.4 GESTIÓN DE COMPRAS................................................................................................. 14

2.4.1. Actividades de Gestión de Compras.............................................................................. 14

2.5 INVENTARIO ................................................................................................................... 15

2.5.1 Tipos De Inventario ......................................................................................................... 15

2.6 TEORÍA DE LOS STOCKS ............................................................................................. 16

2.7 CONCEPTOS RELACIONADOS AL DESARROLLO DEL PROYECTO .................... 17

2.7.1. Diseñar ............................................................................................................................ 17

2.7.2. Desarrollar ...................................................................................................................... 17

2.7.3. Implementar .................................................................................................................... 17

2.7.4. Control ............................................................................................................................ 17

2.8 INGENIERÍA DE SOFTWARE ....................................................................................... 17

2.8.1. ACTIVIDADES EN EL PROCESO DE DESARROLLO DE SOFTWARE ............... 18

2.9 MARCO METODOLÓGICO ........................................................................................... 19

2.9.1. Ingeniería Web .............................................................................................................. 19

2.7.2. Características de la Ingeniería Web .............................................................................. 19

2.9.3 Etapas de la metodología web ......................................................................................... 20

2.10 LENGUAJE UNIFICADO DE MODELADO (UML) .................................................... 22

vi
2.10.1. Diagramas UML ........................................................................................................... 22

2.11 Metodología Uwe (Uml-Based Web Engineering) .......................................................... 28

2.11.1. Características De Metodología UWE ........................................................................ 28

2.11.2 Modelo de Casos de Uso ............................................................................................. 30

2.11.3 Modelos de la Metodología UWE ................................................................................. 30

2.12 HERRAMIENTAS ........................................................................................................... 33

2.12.1. Herramientas para el Desarrollo del Software .............................................................. 33

2.12.2. Herramientas Backend .................................................................................................. 35

2.10.3. Lenguaje de Programación PHP ................................................................................... 37

2.12.4 Métricas de Calidad ....................................................................................................... 39

2.13 Método de estimación de costos COCOMO II................................................................. 39

2.13.1 Modelo De Estimación .................................................................................................. 40

2.13.1. ISO 27000 ..................................................................................................................... 41

3. MARCO APLICATIVO ...................................................................................................... 44

3.1. INTRODUCCIÓN ............................................................................................................ 44

3.1.1. Descripción General De La Empresa TechsBol El Alto-Bolivia ................................... 44

3.2 Captura de Requerimientos ................................................................................................ 44

3.3.1. Definición de Actores .................................................................................................... 45

3.3.2. Requerimientos Funcionales ......................................................................................... 45

3.3.3. Requerimientos No Funcionales .................................................................................... 46

3.4. Modelos de Casos de Uso ................................................................................................. 47

3.4.1. Diagrama de caso de uso general del sistema................................................................. 47

3.5. Diseño conceptual............................................................................................................. 52

3.5.1. Modelo Conceptual........................................................................................................ 52

3.6. Diseño de Navegación ....................................................................................................... 54

vii
3.7 Diseño De Presentación ..................................................................................................... 55

3.8 Implementación del Sistema............................................................................................... 55

3.8.1. Interfaz de inicio de sesión ............................................................................................ 55

3.8.2 Funcionalidad General del sistema .................................................................................. 56

3.8.3 Módulos que integran el Sistema..................................................................................... 57

3.9. Prueba de función de Software ......................................................................................... 71

3.9.1 Pruebas de caja Blanca .................................................................................................... 71

3.9.2 Pruebas de Caja Negra ..................................................................................................... 72

3.9.3 Objetivo de la Prueba ...................................................................................................... 73

4. MÉTRICAS DE CALIDAD Y SEGURIDAD .................................................................... 76

4.1 Métricas de Calidad ............................................................................................................ 76

4.1.1 Funcionalidad .................................................................................................................. 76

4.1.2. Fiabilidad ....................................................................................................................... 79

4.1.3. Usabilidad ...................................................................................................................... 80

4.2 Métricas De Seguridad ....................................................................................................... 80

4.2.1. Seguridad De Información ISO 27001 ........................................................................... 80

5.1 INTRODUCCIÓN .............................................................................................................. 83

5.2 CÁCULO DE COSTOS ..................................................................................................... 83

5.2.1 Método de Estimación de COCOMO.............................................................................. 83

6. CONCLUSIONES Y RECOMENDACIONES ................................................................... 88

6.1. Conclusiones.................................................................................................................... 88

6.2. Recomendaciones ............................................................................................................. 88

BIBLIOGRAFIA .................................................................................................................... 89

viii
 ÍNDICE DE FIGURAS

Figura 2.1 Capas de Ingeniería de software………………………………………………… 17

Figura 2.2 Proceso de la Ingeriría Web ……………………………………………………. 21

Figura 2.3 Diagrama de Clase ……………………………………………………………… 22

Figura 2.4 Diagrama de Distribución de Objetos …………………………………………... 22

Figura 2.5 Elementos de Diagramas de Uso ………………………………………………. 23

Figura 2.6 Diagrama de Caso de Uso ……………………………………………………… 24

Figura 2.7 Diagrama de Secuencias …………………………………………………………24

Figura 2.8 Diagrama De Actividades ………………………………………………………. 25

Figura 2.9 Diagrama de Componentes ………………………………………………………26

Figura 2.10 Diagrama de Distribución ………………………………………………………26

Figura 2.11 Modelo Navegación …………………………………………………………… 31

Figura 2.12 Estereotipos e iconos para el Modelo de Navegación ………………………… 31

Figura 2.13 Modelo de Presentación UWE …………………………………………………32

Figura 2.14 Esquema del Funcionamiento Apache …………………………………………35

Figura 3.1 Diagrama de Casos de Uso General del Sistema ………………………………. 46

Figura 3.2 Descripción de Caso de Uso: Gestión Usuario ………………………………… 47

Figura 3.3 Diagrama de Casos de Uso: Gestión Clientes ……………………….............. 48

Figura 3.4 Diagramas de Casos de Uso: Registrar Producto ……………………………… 49

Figura 3.5 Diagrama de Casos de Uso: Realizar Pedidos …………………………………. 50

Figura 3.6 Diagrama de Casos de Uso: Registrar Venta …………………………………... 51

Figura 3.7 Diagrama de Clase del Sistema …………………………………………………52

Figura 3.8 Diagrama de Navegación ……………………………………………………… 53

Figura 3.9 Inicio de Sesión …………………………………………………………………54

ix
Figura 3.10 Menú Inicio donde se Ingresa Usuario y Contraseña ………………………… 55

Figura 3.11. Funcionalidad General del Sistema …………………………………………55

Figura 3.12 Pantalla Menú Catálogos: Categoría …………………………………………56

Figura 3.13 Formulario para Registrar Categoría …………………………………………56

Figura 3.14 Pantalla de Menú: Artículo …………………………………………………...57

Figura 3.15 Pantalla de productos –Bajas de Productos ………………………………….58

Figura 3.16 Registros de Artículo según categoría ……………………………………….59

Figura 3.17 Módulo de ventas: Pantalla de clientes …………………................................59

Figura 3.18 Registro del Cliente ……………………………………..................................60

Figura 3.19 Pantalla de ventas ………………………………………………………........ 60

Figura 3.20 Formulario de registrar: cliente según venta de Articulo …………………….61

Figura 3.21 Comprobante de ventas de Articulo ………………………………………….61

Figura 3.22 Pantalla de Perdidas ………………………………………………………… 62

Figura 3.23 Registro de pedido por el cliente……………………………………………...62

Figura 3.24 Formulario de venta del Pedido que realiza al Cliente………………………..63

Figura 3.25 Comprobante de la Venta del Articulo del Pedido……………………………63

Figura 3.26 Módulo de Compras: Pantalla de proveedores………………………………..64

Figura 3.27 Registro del Proveedor ……………………………………………………….64

Figura 3.28 Pantalla de Compras por Proveedor ………………………………………….65

Figura 3.29 Registro de Compras según Proveedor……………………………………….65

Figura 3.30 Registro de compra de Proveedor…………………………………………….66

Figura 3.31 Pantalla de Estadísticas de ventas por fecha y Empleados ………………..66

Figura 3.32 Pantalla de estadísticas de Producto Más vendidos …………………….....67

Figura 3.33 Pantalla de Estadísticas de Compra ………………………………………….67

Figura 3.34 Estadísticas de Productos más comprados ……………………………...……68

x
Figura 3.35 Pantalla de Estadísticas Generales……………………………………………68

Figura 3.36 Estadísticas Generales de Cantidad de Productos más vendidos……………69

Figura 3.37 Reportes Generales y Concretos……………………………………………..69

Figura 3.38 Reportes Específicos de ventas y compras…………………………………..70

Figura 3.39 Pantalla de Usuario…………………………………………………………..70

Figura 3.40 Pantalla Historial…………………………………………………………….70

Figura 3.41 Diagrama de Caja Blanca……………………………………………………71

Figura 3.42 Pruebas de caja negra Inicio de Sesión………………………........................73

xi
 INDICE DE TABLAS

Tabla 2.1 Características de la Ingeniería Web ……………………………………………... 20

Tabla 2.2 Frameworks PHP …………………………………………………………………. 42

Tabla 2.3 Detalle de coeficientes de COCOMO II …………………………………………. 45

Tabla 2.4 Ecuaciones del Método COCOMO II ……………………………………............ 46

Tabla 3.1 Tareas para Obtención de Requerimiento ………………………………………... 49

Tabla 3.2 Lista de Actores …………………………………………………………………... 50

Tabla 3.3 Requerimientos Funcionales ……………………………………………………… 51

Tabla 3.4 Requerimientos No Funcionales …………………………………………………. 52

Tabla 3.5 Descripción del Caso de Uso: Gestionar Usuarios ………………………………. 54

Tabla 3.6 Descripción del Caso de Uso: Gestionar Clientes ………………………………... 55

Tabla 3.7 Descripción del Caso de Uso: Registrar Productos ………………………………. 56

Tabla 3.8 Descripción de Caso de Uso: Realizar Pedidos …………………………………... 57

Tabla 3.9 Descripción de Casos Uso: Registrar Ventas …………………………………….. 58

Tabla 3.10 Procedimientos y Descripción de Pruebas de Sistema …………………………… 82

Tabla 4.1 Factor de Ponderación para la Funcionalidad ……………………………………... 85

Tabla 4.2 Ajustes de Complejidad …………………………………………………………… 86

Tabla 4.3 Cálculos de fallos de sistema ……………………………………………………… 88

Tabla 5.1 Aplicación del Modelo Intermedio………………………………………………….83

Tabla 5.2 Ecuaciones del Modelo COCOMO…………………………………………………84

Tabla 5.3 Cálculo de atributos FAE……………………………………………………………85

xii
 CAPITULO I
MARCO PRELIMINAR

xiii
1. MARCO PRELIMINAR

1.1 Introducción

En nuestro país se esfuerzan por tener una mejor participación en el mercado, en donde realiza
el desarrollo de las estrategias a la distribución e implementaciones técnicas de ventas que
refuerzan los objetivos económicos a los negocios, ya que cada producto es encontrado en el
mercado que es de mucha utilidad para el cliente, las ventas son el reflejo de los resultados de
inversión realizada por cada producto.

Lo que ha originado al desarrollo de las aplicaciones, mejoran el control administrativo

mediante un seguimiento preciso de todas las transacciones que realiza dentro de un negocio en
tiempo real, proporcionando reportes detallados de ventas y las compras que se realiza, y de
esta manera permitir una mejor administración de información de la cantidad correcta de cada
producto en el momento adecuado.

Los sistemas de ventas tienen la capacidad de ser personalizados para cumplir las necesidades
específicas en un negocio, por ejemplo, las organizaciones de venta pueden administrar
rápidamente los precios, las entradas, salidas de cada producto, una tienda de componentes
electrónicos puede incluir todos los elementos que ofrece y administrarlos ya sea por la cantidad
de componentes o el precio.

La empresa TECHSBOL brinda la venta de sus productos de componentes electrónicos

informáticos, es una empresa dedicada que ha ido creciendo a través del tiempo y consiguió la
cantidad de información que maneja dentro de su organización, una de las más importantes que
realiza esta empresa es de dar un buen producto al cliente, sus ventas son muy elevadas ya que
a diario el cliente pide diferentes componentes para que pueda realizar su trabajo. Es por esta
razón que se desarrolla un Sistema de información que permita automatizar el proceso de control
de las ventas de producto electrónico, aplicando la metodología RUP, además de herramientas
tecnológicas para el desarrollo del software, este sistema será muy útil y de gran ayuda.
 1.2 Antecedentes

1.2.1 Antecedentes Institucionales

TECHSBOL es una empresa dedicada a realizar las ventas de componentes electrónicos,

también realiza servicios de instalación Cámaras de Seguridad, instalación de redes eléctricas
Sistemas de Automatización desarrollo de software, Domótica, Diseño Gráfico, Capacitación
Robótica y entre otros.

Misión: brinda a los clientes la más amplia gama de productos, servicios, capacitaciones,
soluciones tecnológicas, innovadoras y de calidad en el afán de que les permita optimizar sus
procesos y objetivos, en aumento de la rentabilidad de nuestros clientes y asociados.

Visión: ser una empresa líder en el sector de la tecnología de información, con proyección
nacional e internacional reconocida por brindar soluciones y servicios de excelente calidad.

1.2.2. Antecedentes de Trabajos a Fines

[Arana Quijije Julia Valeria, 2014], “Desarrollo e implantación de un sistema de gestión de venta
de repuestos automotrices en el almacén de automotrices en el almacén de auto repuestos
eléctricos”, el presente proyecto tiene como objetivo, Diseñó de un sistema implementando la
gestión de sistematizar las ventas e inventarios de Almacén, de “Auto Repuestos Eléctricos
Marcos”. Este sistema de información abarca la implementación de módulo de almacén de
ventas. Para el desarrollo del proyecto aplicó la metodología de desarrollo de software RUP,
haciendo uso de las herramientas de lenguaje de programación MySQL, Apache, UML.

[Patricia Evelyn Matta Catacora, 2011], “Sistema web para el control de ventas y facturación
usando agentes inteligentes” Caso: “Importadora de fármacos inteligentes”, cuyo objetivo fue
implementar Sistema Web para el control de ventas y facturación usando agentes inteligentes
que pueda permitió la agilización en el proceso de facturación, registro, cotizaciones de los
productos y generó reportes actualizados de ventas.

[Liz Andrea Ramos Huachi, 2013], “Sistema Web De Administración De Ventas, Basado En
La Gestión De Procesos De Negocio” Caso: Empresa De Muebles Artemobile, Departamento
De Ventas”, cuyo objetivo es: Desarrolló de un sistema web para la administración de ventas,
concentrado e integrando la información de las ventas y realizó un análisis adecuado, logró

2
aumentar la gestión de procesos, usando la metodología Scrum, MySQL, usando herramientas
PHP, HTML, MYSQL.

[Edwin Chambi Gutiérrez, 2017] “sistema de información web para la administración y control
de ventas e inventarios” caso: librería líder”, cuyo objetivo es: desarrolló un sistema de
información y control de ventas e inventarios en la Librería “LÍDER”, utilizó la metodología
UWE, haciendo el uso de las herramientas MAGICDRAW, FRAMEWORK CODEIGNITER,
BOOTSTRAP Y PHP.

1.3 PLANTEAMIENTO DEL PROBLEMA

Se realizó un estudio debido a la empresa de los diferentes procesos y tareas que realizan
diariamente la empresa TECHBOL, se identificó que no cuentan con un registro de ventas y
compras, lo que ocasiona no tener la información centralizada de los procesos que se realiza.
La administración del personal no cuenta con un control adecuada, ya que estos registros se
realizan de forma manual la cual son tediosas y hay pérdida de información.

1.3.1. Problema Principal

Dentro de la empresa TECHSBOL se realiza el control de la venta y compra e inventarios de

los componentes electrónicos de manera manual a través de registros lo que ocasiona gran
demora y generando un control inadecuado de esta información al momento de dotar informes
sobre los componentes electrónicos.

¿Es posible que, con el Diseño de un Sistema Web para la gestión de compra y venta de
componentes electrónicos de la empresa TECHSBOL, ayudara en la administración y control
de la información más adecuado y eficiente en las actividades?

1.3.2. Problema Secundarios

 Falta de un sistema de control de registros y búsqueda de información de los productos.

 El control lo realizan de manera manual de las compras y ventas de los productos lo cual
genera riesgo de pérdida de información y se emplea demasiado tiempo.
 Inexistencia de la actualización periódica del stock mínimo de los productos.
 La atención al cliente demora en la cotización de los productos al no tener la información
actualizada.

3
  No cuentan con un sistema de información de los productos existentes en el área de
inventario o almacén.

1.4 OBJETIVOS

1.4.1 Objetivo General

Desarrollar un Sistema Web para la gestión de compra y venta e inventarios de componentes

electrónicos de la empresa TECHSBOL que coadyuve en la administración y control de la
información más adecuado y eficiente en las actividades.

1.4.2. Objetivo Específicos

 Diagnosticar la situación actual de la empresa sobre compra y venta de los productos

 Diseñar un sistema de información en ventas y compras de productos requeridos
para un control adecuado.
 Desarrollar una base de datos que contenga toda la información necesaria en el área
de ventas y compras.
 Incluir un módulo para la actualización en el stock del almacén para alertar la
existencia mínima de los productos.
 Generar reportes de las ventas y compras, brindado de esa manera la información
precisa y confiable para la empresa.

1.5 JUSTIFICACIÓN

1.5.1. Justificación Técnica

El desarrollo e implementación del presente proyecto se justifica técnicamente porque se

mejorará los métodos y técnicas de acceso de manipulación de datos en la administración de
ventas y compras de la empresa TECHSBOL.

Para el desarrollo e implementación del presente proyecto cuenta actualmente con equipos de
computación para la implementación del sistema propuesto lo que realizara una mejoría en los
resultados así explotar óptimamente el uso de los equipos de computación existentes, lo cual
viabiliza el desarrollo del sistema web propuesto, se utilizara herramientas para la
automatización para mayor control, para la implementación y administración del sistema se
usaran el gestor de MYSQL, y el lenguaje de programación PHP, framework con el sistema
web.

4
1.5.2. Justificación económica

En la empresa “TECHBOL” el sistema propuesto beneficiará a corto y largo plazo dando una
reducción de tiempo y esfuerzo, generará información confiable lo que implica un ahorro
económico al no realizar datos manuales lo que es un gasto de escritorio, logrando beneficios
en la productividad de la empresa.

El sistema ayudará a obtener mejores tiempos de respuestas, suponiendo la mejora en los

procesos de compra y venta, logrando que el beneficio en costos y tiempos en la productividad
de la empresa.

Para el desarrollo del sistema se hará el uso de herramientas de tecnología web que no tienen
costo de licencia, lo que resulta favorable para la empresa.

1.5.3. Justificación Social

La implementación del sistema propuesto beneficiará al personal del área de ventas, la

información necesaria con la facilidad de tener un acceso directo cada vez que lo requieran.

Tendrá acceso y visibilidad únicamente a la información que necesite y beneficiando

directamente al personal, también se mejorará la atención al cliente al agilizar el proceso de
información en la venta de cada producto.

1.6 METODOLOGÍA

La metodología se implementará para el desarrollo del producto de software, es una de las

metodologías ágiles, más utilizadas por los desarrolladores de software y empresas, esta es
UWE Sabed Web Engineering (Ingeniería Web Basada en Uml).

1.6.1. Método De Ingeniería

1.6.1.1 Metodología UWE (UML-BASED WEB ENGINEERRING)

La metodología UWE es una herramienta para modelar aplicaciones web, utilizada en la

ingeniería web, prestando especial atención en sistematización y personalización.

Es una propuesta basada en el proceso unificado y UML, 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.

5
Fases de UWE: Las etapas a utilizar son:

 Captura, análisis y especificaciones de requisitos

Durante esta fase, se adquieren, reúnen y especifican las características funcionales y no
funcionales que deberá cumplir la aplicación web. Para luego representarlos como caso
de uso, que luego da lugar a un diagrama de casos de uso.
 Diseño conceptual
Su objetivo principal es construir un modelo conceptual del dominio de la aplicación
considerando de clases de dominio.

1.6.1.2. Métricas de Calidad

1.6.1.4. Modelo de calidad del software ISO 25010

El modelo de calidad es producto del software que interpreta como el grado en que dicho
producto satisface los requisitos de sus usuarios, determinan sus características para evaluar las
propiedades de un producto de software determinado, compuesta por sus siguientes
características

 Funcionalidad
 Eficiencia de Desempeño
 Compatibilidad
 Usabilidad
 Fiabilidad
 Seguridad
 Mantenimiento
 Portabilidad

1.6.2.2. Modelo de seguridad ISO 27000

La Norma ISO 27000 se encarga de establecer estándares y guías relacionados con sistemas de
Gestión y aplicables a cualquier tipo de organización, con el propósito de facilitar el comercio,
facilitar el intercambio de información y contribuir transparencia de tecnologías, contiene las
mejores prácticas recomendadas en seguridad de la información para desarrollar, implementar,
y mantener especificaciones para los sistemas de gestión de seguridad.

6
1.6.3. Métodos de Estimación de Costos

1.6.3.1 COCOMO II

Según Somerville (2011, pág. 637), COCOMO II es un modelo empírico que se derivó al
recopilar datos a partir de un gran número de proyectos de Software, es un modelo de estimación
bien documentado y no registrado y se basan principalmente en el desarrollo de código original.

COCOMO II toma en cuenta enfoques más modernos para el desarrollo del software, tales como
el desarrollo rápido que usa lenguajes dinámicos y el uso de la programación de base de datos.
(Bohem, 1981).

COCOMO II posee tres modelos:

 Modelo de Composición de Aplicación

 Modelo de Diseño Temprano
 Modelo Post-Arquitectura

Cada uno de estos modelos está orientado a sectores específicos del mercado de desarrollo de
software y a las distintas etapas del desarrollo de software. (Gracia, 7 de febrero de 2012) .

1.6.4. PRUEBAS DE SOFTWARE

1.6.4.1. Pruebas de caja blanca

Esta prueba se orienta al cálculo de las regiones que deben ser consideradas como caminos
independientes del sistema y estableciendo cuáles son las entradas para que se ejecutan cada
una de las regiones, asegurando así que cada región se ejecuta al menos una vez.

1.6.4.2. Pruebas de caja negra

Permiten obtener un conjunto de condiciones de entrada que ejercen los requisitos funcionales
del sistema. Las Pruebas de caja negra no es una alternativa a las técnicas de prueba de caja
blanca, sino un enfoque complementario que intenta descubrir diferentes tipos de errores
encontrados con esta prueba permiten encontrar:

 Funciones incorrectas o ausentes

 Errores de interfaz
 Errores en estructura de datos o en accesos a las bases de datos externas
 Errores de rendimiento

7
  Errores de inicialización y terminación.

1.7 HERRAMIENTAS

Se describe los distintos lenguajes de programación, gestores de base de datos y servid1ores

web que son más utilizados para el desarrollo de proyectos orientada a la web.

 PHP: Es un lenguaje de programación de código abierto, diseñado para la creación de

páginas web dinámicas que incluye entre etiquetas especiales de comienzo y final que nos
permitirán entrar y salir del modo PHP, procesa información de formularios generar páginas
con contenidos dinámicos, enviar y recibir, creaciones de imágenes a partir de datos.
 MariaDB. MySQL: Sistema de Gestión de base datos de código abierto, bajo la Licencia
dual GPL/Licencia comercial por Oracle Corporation y está considerada como la base de
datos (open source) más popular del mundo.
 JAVA SCRIPT: JavaScript es un lenguaje de programación orientado a objetos, diseñado
para el desarrollo de aplicaciones cliente/servidor a través de Internet. JavaScript permite
desarrollar programas que se ejecutan directamente en el navegador (cliente) de manera
que éste pueda ejecutar determinadas operaciones o tomar decisiones sin necesidad de
acceder al servidor. Es uno de los más potentes e importantes lenguajes de programación
en la actualidad, por tres enfoques claros: es útil, práctico y está disponible en cualquier
navegador web.
 HTML: son etiquetas de marcado donde va el código, hace referencia al lenguaje de
mercado para la elaboración de páginas web. Es un estándar que sirve de referencia del
software que conecta con la elaboración de páginas web en sus diferentes versiones, define
una estructura básica y un código (denominado código HTML) para la definición de
contenido de una página web, como texto, imágenes, videos, juegos, entre otros.
 CSS: son hojas de estilo en cascada, tecnología que permite crear páginas web de manera
más exacta, aplica estilos (colores, formas, márgenes, etc.)

A uno o varios documentos (generalmente documentos HTML) forma masiva.

CSS utiliza el concepto de separación y presentación de contenidos, intentando que los

documentos HTML incluyan información y datos relativos al significado de la información
a transmitir.

8
 LARAGON: Es una herramienta para equipos técnicos que permite crear diferentes
entornos de desarrollo facilitando el trabajo con la aplicación. Laragon trabaja
especialmente con LARAVEL en una suit de desarrollo para PHP.
 FRAMEWORK LARAVEL: Es de código abierto para desarrollar aplicaciones y
servicios web con PHP. Laravel tiene como objetivo ser un framework que permita el uso
de una sintaxis elegante expresiva para crear código de forma sencilla y permitiendo
multitud de funcionalidades.
Intenta aprovechar lo mejor de otros frameworks y aprovechar las características de las
últimas versiones de PHP.

1.8 LÍMITES Y ALCANCES

1.8.1. Limites

En presente proyecto es para gestionar la información de venta, registro de inventarios y ayudar

con consultas de información de productos y reportes acorde a las necesidades de los
administradores.

También el proyecto contemplara con las siguientes limitaciones:

 El sistema no verificara los pagos por internet.

 No se podrá cancelar los servicios con tarjera de crédito.

1.8.2. Alcances

El sistema de ventas y compras de componentes electrónicos abarca los siguientes alcances:

 Tener una base de datos actualizada donde se realizan los registro y almacenamiento de
la información
 El sistema realizará actualización para adquirir nuevos pedidos, según sea necesario.
 El sistema podrá hacer búsquedas, registro y modificaciones de los registros de ventas
 El sistema podrá hacer búsquedas, registro y modificaciones de los registros de compras
 Consulta de stock de los productos vendidos.
 El sistema de información utilizará métodos y herramientas de desarrollo web.
 Módulo de administración de usuario: el sistema podrá mostrar interfaces distintas según
el tipo de usuario.

9
  Módulo de Productos: Registrar productos y artículos, estadísticas de compras y ventas
de productos, cada producto debe tener una imagen de diferencia y pertenecer a una
categoría. Registrar, actualizar, consultar y baja categoría en los reportes.
 Módulo de compras: el sistema realizará notificaciones para la realización de compras
y las compras de proveedores.

 Módulo de ventas: el sistema podrá registrar todas las ventas realizadas, además de un
control de esta, registrar a los clientes, registrar pedido.
 Módulo de Reportes: se podrá generar toda la información requerida por la empresa tales
como: registro de ventas mensuales y anuales, Stock de productos disponibles en
almacenes, categorías, registro de clientes, proveedores, ventas, compras.
 Módulo Estadísticas: se mostrará las diferencias entre compras y ventas, cantidad de
productos, total de compras por Proveedor, productos más comprados, las Ventas por
empleado, producto más vendido por fechas.

1.9 APORTE

El sistema desarrolló en la atención a los requerimientos de la institución, que permite cubrir las
necesidades de un mejor control de seguimiento en el registro de cada Artículo y que diferentes
módulos permitan gestionar todo reporte seguro y emite buenos resultados, más rápido y
completo.

10
 CAPÍTULO II
MARCO TEÓRICO

11
2. MARCO TEORICO

2.1 INTRODUCCIÓN

En el presente capítulo se revisa las diferentes definiciones y conceptos empleados para el

desarrollo del presente proyecto.

2.2 Sistema

Un sistema es un módulo ordenado de elementos que se encuentran Interrelacionados y que

interactúan entre sí. El concepto se utiliza tanto para definir a un conjunto de conceptos como a
objetos reales dotados de organización, también puede mencionarse la noción del sistema
informático, muy común en las sociedades modernas. Este tipo de sistemas denominan al
conjunto de hardware, software y soporte humano que forman parte de una empresa u
organización. Incluyen ordenadores con los programas necesarios para procesar datos y las
personas encargadas en su manejo.

Un sistema es un conjunto de elementos interrelacionados entre sí con un propósito en común,

cada elemento desempeña funciones específicas. [Daniela Rojas, 2018].

2.2.1. Sistemas de Información

Un sistema de información es un conjunto de componentes que interaccionan entre sí para

alcanzar un fin determinado, el cual es satisfacer las necesidades de información de dicha
organización, es decir un sistema de información es un conjunto de elementos que interactúan
entre sí con el fin de apoyar las actividades de una empresa o negocio. El objetivo primordial
de un sistema de información es apoyar la toma de decisiones y controlar todo lo que ocurre en
ella. Es importante señalar que existen dos tipos de sistemas de información, los formales y los
informales; los primeros utilizan como medio para llevarse estructuras solidas como
ordenadores, los segundos son más artesanales y usan medios más antiguos como el papel y
lápiz. Cabe resaltar que el concepto de sistema de información suele ser utilizada como
sinónimo de sistema de información informático, pero no son lo mismo. Este último pertenece
al campo de estudios de la tecnología de la información y puede formar parte de un sistema de
información como recurso material, (Perez Julian, 2018).

12
2.2.2. Características de un Sistema de Información

Un sistema de información se caracteriza principalmente por la eficiencia que procesa los datos
en relación con el área de acción. Los sistemas de información se alimentan de los procesos y
herramientas de estadística, probabilidad, inteligencia de negocio, producción, marketing, entre
otros para llegar a la mejor solución.

Un sistema de información se destaca por su diseño, facilidad de uso, flexibilidad,

mantenimiento automático de los registros, apoyo en toma de decisiones críticas y mantener el
anonimato en informaciones no relevantes.

2.2.3. Componentes de un sistema de información.

Los componentes que forman un sistema de información son:

La entrada: Es el proceso mediante el cual el sistema de información toma los datos que
requiere para procesar la información.

El proceso: Es la capacidad del sistema de información para efectuar cálculos de acuerdo con
una secuencia de operaciones preestablecida. Estos cálculos pueden efectuarse con datos
introducidos recientemente en el sistema o bien con datos que están almacenados.

Almacenamiento: Es una de las actividades o capacidades más importantes que tiene una
computadora, ya que a través de esta propiedad el sistema puede recordar la información
guardada en la sesión o proceso anterior.

La salida: Es la capacidad del sistema de información para efectuar cálculos de acuerdo con
una secuencia de operaciones preestablecida. Estos cálculos pueden efectuarse con datos
introducidos recientemente en el sistema o bien con datos que están ya almacenados.

2.3 GESTIÓN DE VENTAS

Las ventas son las actividades más pretendidas por la empresa, o personas que ofrecen los
Productos, Servicios u otros, en su mercado, debido a que su éxito dependa de la cantidad de
veces que realice las ventas.

Dentro de las ventas se puede encontrar pasos claves, para las interacciones de ventas exitosas
que pueden realizar en la empresa realizar su proceso de venta.

13
  Prospección: localizar a personas, clientes u organizaciones para poder comprar
productos.
 Contacto inicial: podrá generar que la empresa entra al contacto para poder entrar en
relación con la otra organización o clientes.
 Presentación de ventas: conocer las necesidades presentes y futuras del cliente y
realizar una propuesta formal, clara, detallada de los productos y soluciones.
 Seguimiento y Servicio de la venta: Después de prestar el servicio producto es
importante evaluar el grado de satisfacción del cliente y estar atento a cualquier
retroalimentación del cliente con el fin de poder resolverla y que el cliente quede
satisfecho por la venta de producto.

2.3.1. La venta como proceso

Las ventas que se realiza a cada cliente son muy beneficiadas ya que el cliente podrá hacer su
pedido del producto que quiera, así el cliente generará confianza a la empresa. La empresa
identifica las necesidades del consumidor o los problemas que pueda tener en la venta. Se ofrece
servicios después de la venta que permita establecer relaciones duraderas con el cliente.

2.4 GESTIÓN DE COMPRAS

La compra es aquella operación que involucra todo el proceso de ubicación del proveedor, las
compras comprenden un proceso complejo que va más allá de la negociación, con una buena
gestión de compras la empresa consigue ahorrar costes, satisfacer al cliente, en tiempo y
cantidad, y obtener beneficios empresariales directos, pues en la gestión de compras son
decisivas para la empresa tenga éxito o fracaso. Los consumidores clientes, pueden segmentarse
en términos de estilos de compra.

La gestión de compras es el conjunto de actividades que realiza la empresa para satisfacer sus
necesidades del mejor modo, al mínimo costo con la calidad adecuada y en el momento
oportuno.

2.4.1. Actividades de Gestión de Compras

 Gestión de la distribución Física: integración de los flujos de materiales y de las

tecnologías de la información que hacen posible que un producto se fabrique y llegue al
consumidor.

14
  Gestión de los proveedores: procesos de vigilancia, búsqueda, identificación,
selección, evolución y seguimiento de los procesos para el desarrollo del producto.
 Procesos de compra: definir el tipo de producto que quiera el proveedor y poder logar
la compra muy satisfactoria.

La empresa identifica estas funciones de gestión porque tienen implicaciones en el diseño del
producto, la determinación del pedido de cada producto.

2.5 INVENTARIO

El término “inventario” tiene dos definiciones (Real Academia Española, 2015), la primera
como “asientos de los bienes y demás y cosas pertenecientes a una persona o comunidad, hecho
con orden y precisión” y la segunda referida a “papel o documento en que están escritas dichas
cosas”, significado entonces el conjunto de bienes (en este caso de una empresa) que se
encuentra sometido diferentes procedimientos de registros para su adecuado control.

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

las operaciones que se producen desde que el cliente efectúa un pedido a las instalaciones hasta
que se realiza su entrega:

- Se produce el pedido de uno o varios artículos a nuestras instalaciones.

- Se verifica el pedido en las instalaciones, caso contrario de no existir, se pide
autorización para buscar en el almacén.
- Se acepta pedido.
- Se procesa la cancelación de dicho pedido.
- Se recepciona el pedido por parte del cliente.

2.5.1 Tipos De Inventario

Existen diferentes tipos de inventario que se pueden realizar en un determinado tiempo y en una
determinación ocasión.

 Inventarios finales: se realizan cada vez que se cierra periodo fiscal, habitualmente el
31 de diciembre.
 Inventarios periódicos: se realizan cada determinado tiempo dentro de una empresa.

15
  Inventarios iniciales: se registran todos los bienes de la empresa; solo se documentan
los bienes existentes en el o en los días de elaboración. Por lo general se elabora al
inicio del periodo contable, que suele ser de 1 de enero.
 Inventarios de liquidación legal y política en su proceso.
 Inventarios de productos en procesos de fabricación: incluyen los bienes que ha
adquirido una empresa de tipo manufacturera o industrial y están en proceso aún de
manufactura; se cuantifican a través de la cantidad de materiales, de la mano de obra o
de los gastos de fabricación, aplicables a la fecha del cierre.

2.6 TEORÍA DE LOS STOCKS

 Inventario o Stock: es la existencia de un artículo o recurso que se usa en la

organización.
 Sistemas de inventarios: son el conjunto de políticas y controles de supervisa los
niveles de inventario.
 Demanda: es la tasa de consumo de un artículo/tiempo, puede ser determinística o
estocástica. Se nombra dos tipos de demanda:
 Demanda Independiente: cuando las demandas de los diferentes artículos no
están relacionadas entre sí.
 Demanda dependiente: cuando la necesidad de cualquier producto es el
resultado directo de la necesidad de otro artículo.
 Agotamiento o Faltante: se da cuando la demanda excede el stock disponible, es
accidentalmente o planeadas.
 Tiempo d adelanto: es el tiempo que transcurre entre el momento en que se decide la
compra y la llegada de la mercadería.
 Políticas de Pedidos: es la manera de realizar los pedidos y se clasifican por: Modelo
de cantidad fija de pedido, se pide la misma cantidad cuando el inventario llega a un
nivel. Modelo de periodo de tiempo fijó revisión periódica (modelo P) se realiza
intervalos fijos de tiempo lo que hace falta para llegar al nivel deseado de stock.

16
2.7 CONCEPTOS RELACIONADOS AL DESARROLLO DEL PROYECTO

2.7.1. Diseñar

El diseño de sistemas es el proceso de la arquitectura, módulos, interfaces y datos de un sistema

para satisfacer los requisitos q se pide específicamente, Diseñar un sistema puede verse como
la aplicación de teoría de sistemas al desarrollo de un nuevo producto.

2.7.2. Desarrollar

Desarrollar el sistema para el proceso que consiste en dos etapas principales de análisis y diseño
de sistemas; se comienza cuando la gerencia o en algunas ocasiones el personal de desarrollo
de sistemas, se da cuenta de cierto sistema del negocio necesita mejorar.

2.7.3. Implementar

Se pone en funcionamiento aplicando métodos, medidas, etc., se implementa un sistema de

gestión de ventas y compras para logar el crecimiento del negocio de la empresa, ofreciendo sus
productos y servicios de gran calidad, así implementar con éxito el sistema de gestión ventas ya
que la empresa está dirigida por un líder y se encarga del funcionamiento.

2.7.4. Control

El sistema de control de las ventas y compras y la facturación realiza la impresión de etiquetas

con el código de barras y la gestión de los clientes, así como también a los proveedores, envíos
de correos electrónicos, gestiona los pagos y de los servicios, se obtiene reportes diarios de las
ventas, monitorear el inventario en tiempo real, centraliza la información.

2.8 INGENIERÍA DE SOFTWARE

La ingeniería de software es una disciplina formada por un conjunto de métodos, herramientas

y técnicas que se utilizan en el desarrollo de los programas informáticos es decir en el desarrollo
del software de calidad, el cual debe cumplir con las necesidades por el cual fue diseñado, bebe
ser fácil de usar, proveer el rendimiento adecuado, debe ser capaz de ser trasferido de un entorno
a otro. (Pressman, 2010).

La ingeniería de software, por lo tanto, incluye el análisis previo de la situación, el diseño del
proyecto, el desarrollo del software, las pruebas necesarias para confirmar su correcto

17
funcionamiento y la implementación del sistema. El proceso debe tener una organización
sistemática y bien definida.

Figura 2.1 Capas de Ingeriría de Software

Fuente: (Pressman R., 2010)

2.8.1. ACTIVIDADES EN EL PROCESO DE DESARROLLO DE SOFTWARE

 Análisis de requerimientos: es una actividad requerida en cualquier modelo, se extraen

los requisitos de un producto de software es la primera etapa para crearlo.

Especificación: Puede ser informal, semiformal o formal, la especificación formal

permite verificación, en algunos modelos sustituye al diseño, describe el “qué” y no el
“cómo

 Diseño: Se enriquece la descripción del análisis incorporando aspectos de la plataforma

de desarrollo, se desarrolla la arquitectura del sistema, se desarrollan los componentes
(algoritmos, representación de datos, etc.)
 Programación: Reducir un diseño a código puede ser la parte más obvia del trabajo de
ingeniería de software, pero no necesariamente es la que demanda mayor trabajo y ni la
más complicada. La complejidad y la duración de esta etapa está íntimamente
relacionada al o a los lenguajes de programación utilizados, así como al diseño
previamente realizado.
 Prueba: Consiste en comprobar que el software realice correctamente las tareas
indicadas en la especificación del problema. Una técnica de prueba es probar por

18
 separado cada módulo del software, y luego probarlo de forma integral, para así llegar
al objetivo.
 Documentación: Todo lo concerniente a la documentación del propio desarrollo del
software y de la gestión del proyecto, pasando por modelaciones; todo con el propósito
de eventuales correcciones, usabilidad, mantenimiento futuro y ampliaciones al sistema.
 Mantenimiento: Mantener y mejorar el software para corregir errores descubiertos e
incorporar nuevos requisitos. Esto puede llevar más tiempo incluso que el desarrollo del
software inicial.

2.9 MARCO METODOLÓGICO

2.9.1. Ingeniería Web

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

al desarrollo eficiente, operación y evolución de aplicaciones de alta calidad en la World Wide
Web o red informática mundial.

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.

Entonces la ingeniería de la Web es la aplicación de metodologías sistemáticas, disciplinadas y

cuantificables al desarrollo eficiente, operación y evolución de aplicaciones de alta calidad en
la World Wide Web. En este sentido, la ingeniería de la Web hace referencia a las metodologías,
técnicas y herramientas que se utilizan en el desarrollo de aplicaciones Web complejas y de gran
dimensión en las que se apoya la evaluación, diseño, desarrollo, implementación y evolución
de dichas aplicaciones, (Jennifer & Lopez, 8 de Dicembre, 2010).

2.7.2. Características de la Ingeniería Web

Características Explicación
Intensivas de red Esta utiliza una red y da servicio a la
comunidad de clientes.

19
 El tiempo que tarda en comercializar un
Inmediatez sistema web es mucho más rápido que otro
tipo de software.

A diferencia de una aplicación de escritorio

Evolución continua (que utilizan actualizaciones planificadas),
estas tienen actualizaciones a cada hora (en
algunos casos).

Este realiza mucho uso de contenido

Controlada por el contenido hipermedia, para mostrar textos, imágenes,
videos, etc.

Seguridad Por la disponibilidad a una gran cantidad de

usuarios, existe una.

Estática Es parte de su atractivo la apariencia e

interacción.

Tabla 2.1 Característica de la Ingenier

Fuente: (Elaboracion propia)
Proceso de ingeniería web tiene sus características como inmediatez y transformación y el
crecimiento continuo, que posibilita que el usuario se involucre, facilitando el desarrollo de
productos que se ajustan mucho lo que éste busca y necesita.

Los pasos más resaltantes del proceso de la ingeniería web: enunciación, planificación análisis,
modelización, generación de páginas, test y evaluación del cliente.

2.9.3 Etapas de la metodología web

 Formulación: Consiste en identificar las metas y los objetivos del sistema, constituyendo
de esta manera el motivo del progreso del sistema su importancia y los usuarios
potenciales.
 Planificación: Consiste en el cálculo del costo integral del proyecto y se determinan las
amenazas que se relacionan con el impulso del desarrollo además se determina un plan
muy detallado y progresos de la aplicación.

20
 Análisis: Consiste en establecer los requerimientos tecnológicos y de diseño y el
reconocimiento de los fundamentos del contenido que se van a agregar. Esta etapa consta
de cuatro análisis diferentes:

 Análisis del contenido

 Análisis de la interacción
 Análisis funcional
 Análisis de la configuración

 Ingeniería: Esta etapa consiste en la realización de diseños tanto del tema como el de
fabricación, en paralelo con los diseños arquitectónicos, navegación e interfaz. (Diseño
arquitectónico, navegación y de interfaz para la elaboración de web dinámica).
 Pruebas: Esta etapa sirve para encontrar las fallas y permite garantizar que la aplicación
web perfectamente en distintos campos, utilizando tácticas y tecnologías que son
sugeridas para otro sistema.
 Evaluación del Cliente: En este punto, se efectúan todas las modificaciones y
variaciones que se encontraron en la etapa de pruebas y se incorporan al sistema para
el siguiente incremento, de tal modo que se asegure la satisfacción por parte del cliente,
según los requerimientos solicitados.

Figura 2.2 Proceso de la Ingeriría Web

Fuente: (Pressman R., 2010)

21
2.10 LENGUAJE UNIFICADO DE MODELADO (UML)

El modelado unificado (UML), es procede en el lenguaje de gráfico para visualizar, especificar,

construir y documentar un sistema. UML ofrece un estándar para describir un "plano" del
sistema (modelo), incluyendo aspectos conceptuales tales como procesos, funciones del
sistema, y aspectos concretos como expresiones de lenguajes de programación, esquemas de
bases de datos y compuestos reciclados, (Pressman R. , 2015).

2.10.1. Diagramas UML

Estos diagramas de UML son representaciones gráficas que muestran de forma parcial un
sistema de información, bien esté siendo desarrollado o ya lo haya sido. Suelen estar
acompañados de documentación que les sirve de apoyo, adoptando estas múltiples formas.
Además, UML no excluye la posibilidad de mezclar diagramas, algo que, de hecho, suele ser
bastante común.

2.10.1.1. Diagramas de Clases

Es el bloque de construcción principal de cualquier solución orientada a objetos, muestra clases

en un sistema, atributos y operaciones de cada clase y la relación entre cada clase, tiene tres
partes, Nombre en la parte superior, Atributos en el centro, y Operaciones o Métodos en la parte
inferior.

Figura 2.3 Diagrama de Clases

Fuente: (Diagramas UML, Carlos León)

22
2.10.1.2. Diagramas de Objetos

A estos también se los denomina Diagrama de Instancia, muestran relación entre objetos, pero
usan ejemplos del mundo real, se utiliza para mostrar cómo se verá un sistema en un momento
dado.

comprobante

Figura 2.4 Diagramas de destrucción de Objetos

Fuente: (Diagramas UML, Kaled Garrido, 2013)

2.10.1.3. Diagramas de Caso Uso

Describe un conjunto de acciones (casos de uso) que algunos sistemas o sistemas(sujetos) deben
o pueden realizar en colaboración con uno o más usuarios externos del sistema (actores) para
proporcionar resultados observables y valiosos a los actores u otros interesados del sistema.

Figura 2.5 Elementos de Diagramas de Casos de Uso

Fuente: (UML y Patrones. Craig Larman. 2da Edición. Capítulos 6.)

23
 Fuente: (UML y Patrones. Craig Larman. 2da Edición. Capítulos 6.)

Figura 2.6 Diagrama de Casos de Uso

Fuente: (Elaboración Propia

2.10.1.4. Diagramas de Estados

Los diagramas de Estados muestran el conjunto de estados por los cuales pasa un objeto durante
una aplicación en respuesta a eventos (por ejemplo, mensajes recibidos, tiempo rebasado o
errores), junto con sus respuestas y acciones.

2.10.1.5. Diagrama de Secuencias

El diagrama de secuencia es un tipo de diagrama de interacción describe el comportamiento

dinámico del sistema de información haciendo énfasis en la secuencia de los mensajes de
intercambios por los objetos. Normalmente hace relación con mensajes importantes en las
aplicaciones de tiempo real.

24
 Figura 2.7 Diagrama de Secuencia

Fuente:(Diagramas UML-Karla Ceballos)

2.10.1.6. Diagrama de Actividades

En un diagrama de actividades muestra el flujo de actividades en ejecución general entre los

objetos que está ejecutando en un momento dado, gráficamente un diagrama de actividades será
un conjunto de arcos y nodos, muestra también como fluye el control de unas clases a otras
finalidades, básicamente contiene Estados de Actividad, Estados de Acción, Transiciones y
objetos.

25
 Figura 2.8 Diagramas de Actividades

Fuente: (Modelo UML, Douglas Alejandro Toro Salas,2014)

2.10.1.7. Diagrama de Componentes

Es uno de los principales diagramas UML, clasificado como diagrama de estructura y como tal
representa de forma estática el sistema de información, se utiliza después de haber creado el
diagrama de clases, puede ser un componente de software como una base de datos o una interfaz
de usuario.

26
 Comprobante

Figura 2.9 Diagrama de Componentes

Fuente: (Métricav3, Diagramas UML)

2.10.1.8. Diagrama de Distribución

Los diagramas de distribución muestran la disposición física de los distintos nodos que
componen un sistema y el reparto de los componentes sobre dichos nodos, un nodo es un
elemento físico que existe en tiempo de ejecución y representa un recurso computacional, que
generalmente a menudo tiene memoria y la capacidad de procesamiento. Los nodos se utilizan
para modelar la topología del hardware sobre el que se ejecuta el sistema. Se representa un
procesador o un dispositivo sobre lo que desplegar los componentes.

Figura 2.10 Diagrama de Distribución

Fuente: (José Valdez, 2013)

27
2.11 Metodología Uwe (Uml-Based Web Engineering)

UWE (UML - Based Web Engineering). Es una metodología para el diseño de aplicaciones web
basada en UML y en el proceso unificado para modelar aplicaciones web. Esta propuesta
proporciona una notación para especificar el dominio de la aplicación, un proceso de desarrollo
dirigido por modelos.

Es una metodología que permite modelar de mejor manera una aplicación Web, para el proceso
de creación de aplicaciones, con una gran cantidad de definiciones, en el proceso de diseño de
sistemas. Procede de manera iterativa e incremental, coincidiendo con UML incluyendo flujos
de trabajo y puntos de control. (Pressman R. , 2015)

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 UML, 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.11.1. Características De Metodología UWE

Se basa en las siguientes características:

 Notación Estándar: el uso de la metodología UML para todos los modelos.

 Métodos definidos: pasos definidos para la construcción de cada modelo.

 Especificación de restricciones: recomendables de manera escrita, para que la exactitud

en cada modelo aumente.

2.11.1.1 Diferencia entre un modelo y un diagrama en UML

En UML, un modelo es un conjunto de diagramas. Un modelo es una colección de diferentes

tipos de diagramas determinados. Mientras que un diagrama es un dibujo compuesto por iconos
con una semántica bien definida.
2.11.1.2 Actividades de modelado de UWE

Las actividades base de modelado de UWE son el análisis de requerimientos, el modelo

conceptual, el modelo navegación y el modelo de presentación. A estos modelos se pueden

28
sumar otros modelos como lo son el modelo de interacción y la visualización de escenarios
Web.

2.11.1.3 Fases de la Metodología UWE

 Captura, análisis y especificación de requisitos.

En simples palabras y básicamente, durante esta fase, se adquieren, reúnen y especifican las
características funcionales y no funcionales que deberá cumplir la aplicación web.
 Diseño del sistema.
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 debe darse a
la aplicación web.
 Codificación del software.
Durante esta etapa se realizan las tareas que se conocen como programación; que consiste,
esencialmente, en llevar a código fuente, en el lenguaje de programación elegido, todo lo
diseñado en la fase anterior.
 Pruebas.
Las pruebas se utilizan para asegurar el correcto funcionamiento de secciones de código.
 La Instalación o Fase de Implementación.

Es el proceso por el cual los programas desarrollados son transferidos apropiadamente al

computador destino, inicializados y eventualmente configurados; todo ello con el propósito de
ser ya utilizados por el usuario final.

Implementación y Lanzamiento. En la implementación de la Pagina Web es recomendable

utilizar estándares (HTML, XHTML...) para asegurar la futura compatibilidad y escalabilidad
del sitio. Una vez implementada la página web y aprobada su funcionalidad se procede al
lanzamiento del sitio.

 El Mantenimiento.

Es el proceso de control, mejora y optimización del software ya desarrollado e instalado, que

también incluye depuración de errores y defectos que puedan haberse filtrado de la fase de
pruebas de control.

29
- Mantenimiento y Seguimiento. Una vez puesta la Pagina Web a Disposición de los usuarios
hay que ir cambiando datos y mantener este sitio actualizado, ya que esta página no puede
permanecer estática. Los problemas de uso no detectados durante el proceso de desarrollo
pueden descubrirse a través de varios métodos, principalmente a través de los mensajes,
opiniones de los usuarios, el comportamiento y uso del sitio.

2.11.1.4. Actividades del Modelado UWE

Las actividades base de modelado de UWE son el análisis de requerimientos, el modelo

conceptual, el modelo navegación y el modelo de presentación. A estos modelos se pueden
sumar otros modelos como lo son el modelo de interacción y la visualización de escenarios web.
 Análisis de Requerimientos

 Modelo Conceptual

 Modelo de Navegación

 Modelo de Presentación

2.11.2 Modelo de Casos de Uso

Para describir los requerimientos funcionales de una aplicación se puede usar un modelo de
caso de uso. Este describe un trozo de comportamiento de la aplicación sin revelar su estructura
interna. Un caso de uso es una técnica de modelado usada para describir lo que debería hacer
un sistema nuevo o lo que hace un sistema que ya existe. Los componentes primarios de un
modelo de casos de uso (case-use model) son los casos de uso (use cases), los actores y el
sistema modelado.

2.11.3 Modelos de la Metodología UWE

2.11.3.1 Modelos de Caso de Uso

Es una técnica de modelado usada para describir lo que debe hacer un sistema nuevo o un
sistema existente, Los casos de Uso describen bajo la forma de acciones y reacciones al
comportamiento de un sistema desde el punto de vista de un usuario, permiten definir los límites
del sistema y las relaciones entre el sistema y el entorno.

30
2.11.3.2 Modelo Conceptual

Conocido también como modelo de dominio, es la descripción de cómo se relacionan modelo

los conceptos en un problema. El modelo conceptual sirve para representar un problema de
manera gráfica. Este modelo especifica cómo se encuentra relacionados los contenidos del
sistema, es decir define la estructura de los datos que se encuentran alojados en el sitio web.

Su objetivo es construir un modelo conceptual del dominio de la aplicación considerando los

requisitos reflejados en los casos de uso. Da como resultado un diagrama de clases de dominio.

2.11.3.3 Modelo de Navegación

En un sistema para la web es útil saber cómo están enlazadas las páginas. Ello significa que
necesitamos un diagrama conteniendo nodos (nodes) y enlaces (links). Por lo general, el
producto tendrá más de un usuario, y cada usuario puede tener varios objetivos, por lo que el
modelo como este puede ser muy extensa. La creación de un modelo de navegación es también
una oportunidad para revisar cualquier contenido existente que pueda tener la web y entender
el contexto en el que se va a crear la estructura.

Se obtienen el modelo de espacio de navegación y modelo de estructura de navegación, que

muestra cómo navegar a través del espacio de navegación. Se obtienen diagramas de clases que
representan estos modelos.

Figura 2.11 Modelo Navegación

Fuente: (Análisis, Diseño y Construcción del Sistemas, C.Gómez, M.Ron y L.Guerra )

31
 clase de navegación menú

índice pregunta

visita guiada clase de proceso

nodo externo

Figura 2.12 Estereotipos e iconos para el modelo de navegación

Fuente:(Pressman)
2.11.3.4. Modelo de Presentación

Basándose en el modelo anterior y en información adicional recopilada durante el análisis de

requerimientos se elabora el modelo de presentación, cuyo propósito es el diseño abstracto de
interfaces de usuario.

Se obtienen el modelo de espacio de navegación y modelo de estructura de navegación, que

muestra cómo navegar a través del espacio de navegación. Se obtienen diagramas de clases que
representan estos modelos.

Figura 2.13 Modelo de presentación de UWE

Fuente: (Córdova JR, 2013)

32
2.12 HERRAMIENTAS
2.12.1. Herramientas para el Desarrollo del Software

 PHP: Es un lenguaje de programación de uso general de Código del lado del servidor
originalmente diseñado para el desarrollo web de contenido dinámico.
Fue uno de los primeros lenguajes de programación del lado del servidor que se podían
incorporar directamente en el documento HTML en lugar de llamar a un archivo externo que
procese los datos. El código es interpretado por un servidor web con un módulo de
procesador de PHP que genera la página web resultante. PHP ha evolucionado por lo que
ahora incluye también una interfaz de línea de comandos que puede ser usada en aplicaciones
gráficas independientes. PHP puede ser usado en la mayoría de los servidores web al igual
que en casi todos los sistemas operativos y plataforma sin ningún costo. (AJPDSoft, 2010)
La función de PHP se relaciona con los scripts del lado del servidor. PHP puede realizar
cualquier tarea que cualquier programa, puede hacer y maneja el intercambio de datos entre
el servidor y el software.
 Programación del lado del servidor: esto requiere tres componentes, que son
un analizador PHP, un navegador web y un servidor web. Este último está conectado
con una instalación PHP. El navegador muestra páginas web que se almacenan en
el servidor y se generan con PHP. La programación del lado del servidor es ideal
para webs de prueba antes de publicación Web.
 Programación a través de la línea de comandos: Los scripts PHP pueden ser
creados sin un navegador o servidor. En este caso, sólo necesitaras un analizador
PHP. Estos scripts son adecuados para las tareas regulares que se llevan a cabo en
una web.
¿El código de PHP está encerrado entre etiquetas especiales de comienzo y final <?
php y?> que permiten entrar y salir del modo PHP.

 HTML: es un lenguaje de marcado que se utiliza para el desarrollo de páginas de

Internet. Se trata de la sigla que corresponde a Hipertexto Markup Language, es decir, Lenguaje
de Marcas de Hipertexto, que podría ser traducido como Lenguaje de Formato de Documentos
para Hipertexto.

33
EL HTML se encarga de desarrollar una descripción sobre los contenidos que aparecen como
textos y sobre su estructura, complementando dicho texto con diversos objetos (como
fotografías, animaciones, etc.).

Es un lenguaje muy simple y general que sirve para definir otros lenguajes que tienen que ver
con el formato de los documentos. El texto en él se crea a partir de etiquetas, también llamadas
tags, que permiten interconectar diversos conceptos y formatos.

Para la escritura de este lenguaje, se crean etiquetas que aparecen especificadas a través de
corchetes o paréntesis angulares: < y >. Entre sus componentes, los elementos dan forma a la
estructura esencial del lenguaje, ya que tienen dos propiedades (el contenido en sí mismo y sus
atributos).

Por otra parte, cabe destacar que el HTML permite ciertos códigos que se conocen como scripts,
los cuales brindan instrucciones específicas a los navegadores que se encargan de procesar el
lenguaje. Entre los scripts que pueden agregarse, los más conocidos y utilizados son JavaScript
y PHP.

Para conocer el código HTML que utiliza una página web, hay que seleccionar Ver código
fuente en nuestro navegador (como Internet Explorer o Mozilla Firefox). Al elegir esta opción,
se abrirá el editor de texto con el código HTML de la página que se está visualizando. [Juan
Diego Gauchat, 2012]

 JavaScript: JavaScript es un lenguaje de scripting multiplataforma y orientado a

objetos. Es un lenguaje pequeño y liviano. Dentro de un ambiente de host, JavaScript puede
conectarse a los objetos de su ambiente y proporcionar control programático sobre ellos. [Juan
Diego Gauchat, 2012].
 CSS: Son hojas de estilo en cascada (Cascading Style Sheets), es un mecanismo simple
que describe cómo se va a mostrar un documento en la pantalla o como se va a imprimir o
incluso como va a ser pronunciada la información presente en ese documento a través de un
dispositivo de lectura. Esta forma de descripción de estilos ofrece a los desarrolladores el control
total sobre estilo y formato de sus documentos. [Juan Diego Gauchat, 2012].
 jQuery: JQuery es una biblioteca de JavaScript liviana, "escribe menos, haz más".

34
El propósito de jQuery es hacer que sea mucho más fácil usar JavaScript en su sitio web. JQuery
toma muchas tareas comunes que requieren muchas líneas de código JavaScript para lograrlo,
y las envuelve en métodos que puede llamar con una sola línea de código.

La biblioteca jQuery contiene las siguientes características:

 Manipulación HTML / DOM

 Manipulación de CSS

 Métodos de eventos HTML

 Efectos y animaciones.

 AJAX

 Utilidades

 Framework-Bootstrap: Es un Frameworks de CSS y JavaScript. Fue ideado por

Twitter para simplificar la creación de interfaces limpias y con diseño responsive, y ofrece una
amplia gama de herramientas y funciones que permiten a los usuarios dar vida a web sites y
apps 100% adaptables para cualquier tipo de dispositivos. Puede descargarse de manera gratuita
y brinda variedad de plugins de JavaScript y tutoriales para su utilización. Utiliza componentes
vitales para los desarrolladores tales como HTML5, CSS3, jQuery o GitHub, entre otros. Se
integra con librerías JavaScript y utiliza Less, lenguaje de las hojas de estilo CSS preparado
para enriquecer los estilos del website. [Solís, Johanny, 2014].

2.12.2. Herramientas Backend

 Servidor web Apache: “Es un programa especialmente diseñado para transferir datos
de hipertexto, es decir, páginas web con todos sus elementos (textos, widgets, banners, etc.).
Estos servidores web utilizan el protocolo Http://.
Es un servidor web HTTP de código abierto para la creación de páginas y servicios web. Es un
servidor multiplataforma, una de las ventajas más grandes de Apache es que es un servidor web
multiplataforma, gratuito muy robusto y que descarta por su seguridad y rendimiento” [(Robert
McCool. 1995].

35
 Figura 2.14 (Esquema de funcionamiento de Apache)

Fuente (Pressman, 2010)

 MySQL: es un sistema de gestión de bases de datos relacionales de código abierto

(RDBMS, por sus siglas en inglés) con un modelo cliente-servidor. RDBMS es un software
o servicio utilizado para crear y administrar bases de datos basadas en un modelo relacional.
(Perez, 2007)
Características del MySQL:
 Arquitectura Cliente y Servidor
 Compatibilidad con SQL
 Vistas
 Procedimientos almacenados
 Desencadenantes
 Transacciones

 PHPyAdmin: Herramienta web para controlar y manejar bases de datos MySQL corre
bajo lenguaje de programación PHP. Actualmente puede crear y eliminar Bases de Datos,
crear, eliminar y alterar tablas, borrar, editar y añadir campos administrar privilegios,
exportar datos en varios formatos y está disponible en 50 idiomas.

36
  MAGICDRAW: Es una herramienta CASE desarrollada por No Magic. Es compatible
con el estándar UML, desarrollo de código para diversos lenguajes de programación (Java,
C++, C#, entre otros) así como modelar dato. Cuenta con capacidad para trabajar en equipo
y es compatible con varios entornos de desarrollo (IDEs).

2.10.3. Lenguaje de Programación PHP

Utilizamos PHP para el desarrollo del software, el cual es un lenguaje de programación de

código abierto, diseñado originalmente para la creación de páginas web dinámicas. Es usado
principalmente en interpretación del lado del servidor (server-side scripting) pero actualmente
puede ser utilizado desde una interfaz de línea de comandos o en la creación de otros tipos de
programas incluyendo aplicaciones con interfaz gráfica.

Lo que distingue a PHP de la tecnología JavaScript, la cual se ejecuta en la máquina cliente, es

que el código PHP es ejecutado en el servidor. El servidor web puede ser configurado incluso
para que procese todos los ficheros HTML con PHP, el cliente solamente recibiría el resultado
de su ejecución en el servidor, sin ninguna posibilidad de determinar que código ha producido
el resultado recibido.

Framework-Laravel
Otras opciones de Frameworks PHP son:

FRAMEWORK CARACTERÍSTICAS PRINCIPALES

CodeIgniter -Utiliza un Frameworks ligero, hecho pensando en el rendimiento. -Comienza

rápidamente, gracias a la simplicidad del Frameworks y la excelente
documentación.
Symfony -Utiliza un Frameworks altamente flexible que te permite configurar componentes
individuales.
-Aprovecha la funcionalidad de prueba incorporada en el Frameworks
Zend -Utiliza un framework PHP orientado a objetos con una arquitectura MVC.
-Reutiliza tu código gracias al diseño de la plataforma.

37
 Phalcon -Usa un framework PHP basado en C.
-Aprovecha el fantástico rendimiento de Phalcon y la reduce sobrecarga de
recursos.
-Utiliza solo los módulos y bibliotecas que necesitas.
Tabla 2.2 Frameworks de PHP
Fuente: (Elaboración propia)

Laravel es un nuevo y poderoso Framework PHP desarrollado en 2011 por Taylor Orwell, que
promete llevar al lenguaje PHP a un nuevo nivel. Desarrollar aplicaciones usando Laravel es
muy sencillo, fundamentalmente debido a su expresiva sintaxis, sus generadores de código, y
su ORM incluido de paquetes llamado Eloquent ORM. Laravel, propone una forma de
desarrollar aplicaciones web de un modo mucho más ágil. Por ejemplo, en Laravel
opcionalmente podemos usar el patrón de diseño MVC (Modelo-Vista-Controlador) tradicional,
donde al igual que otros Frameworks PHP, el controlador es programado como una clase. Por
lo tanto, un Controlador es una clase PHP que dispone de métodos públicos que son el punto de
entrada final de una petición HTTP (Request PHP) a nuestra aplicación. Pero, Lavarel propone
además una forma distinta y más directa de responder a la solicitud HTTP.

Ventajas de Laravel en el desarrollo web

 Reducción de costos y tiempos en el desarrollo y posterior mantenimiento de la

aplicación creada.
 Curva de aprendizaje relativamente baja si se compara con otros frameworks de PHP
 Flexible y adaptable no solo al uso del sistema MVC tradicional, sino que para reducir
las líneas de código propone lo que denomina “Routes whith Clousures”
 Modular y con un amplio sistema de paquetes y drivers con el que se puede extender las
funcionalidades de forma sencilla, robusta y segura
 Sencillez a la hora de utilizar los datos mediante Eloquent, se trata de un ORN cuya
interacción con las bases de datos es totalmente orientada a objetos, siendo compatible
con la gran mayoría de bases de datos del mercado.
 Facilita manejo de las rutas de nuestra aplicación, así como la generación de URLS
amigable a mejorar el posicionamiento web.

38
2.12.4 Métricas de Calidad

La ingeniería del software se diferencia de otras áreas, al no estar basada en leyes cuantitativas
básicas, en su lugar se realiza un conjunto de medidas conocidas como métricas, las cuales
proporcionan una referencia de la calidad algún producto de software (Pressman R. , Ingeniería
del software Un enfoque práctico, 2010).

Para valorar la calidad de los productos de software o sistemas que se desarrollan se

proporcionan información adecuada sobre los datos referentes de la misma a la calidad del
producto, permitiendo una visión más profunda sobre el cumplimiento de los objetivos del
proyecto (Pressman R. , Ingeniería del software Un enfoque práctico, 2010).

2.13 Método de estimación de costos COCOMO II

COCOMO (COnstructive COst Model) es un modelo que permite estimar el coste, esfuerzo y
tiempo cuando se planifica una nueva actividad de desarrollo software. Está asociado a los
ciclos de vida modernos. El modelo original COCOMO ha tenido mucho éxito, pero no puede
emplearse con las prácticas de desarrollo software más recientes tan bien como las prácticas
tradicionales. COCOMO II apunta hacia los proyectos software más recientes tan bien como
con las prácticas tradicionales. COCOMO II apunta hacia los proyectos software de los 90 y de
la primera década del 2000, y continuará evolucionado durante los próximos años. Sus objetivos
son:

 Estimar el tiempo y el coste del software de acuerdo con los ciclos de vida utilizados
en los 90 y en la primera década del 2000.
 Proporcionar un marco analítico cuantitativo y un conjunto de herramientas y técnicas
para la evaluación de los efectos de la mejora tecnológica del software en costes y
tiempo del ciclo de vida software.

COCOMO II posee tres modelos:

 Composición de aplicación: se emplea en desarrollo de software durante la etapa del
prototipado.
 Diseño Temprano: Se utiliza en las primeras etapas del desarrollo en las cuales se
evalúan la alternativa de hardware y software de un proyecto.

39
  Post-Arquitectura: Se aplica en la etapa de desarrollo, después de definir la
arquitectura del sistema, y en la etapa de mantenimiento.

Cada uno d estos modelos está orientado a sectores específicos del mercado de desarrollo de
software y a las distintas etapas del desarrollo de software.

2.13.1 Modelo De Estimación

En la estimación del tamaño de software, COCOMO II utiliza tres técnicas:

 Puntos de objeto
 Puntos fusión no ajustados y ajustados
 Línea de código fuente

Además, se emplean otros parámetros relativos al tamaño que contemplan aspectos tales como:
reúso, reingeniería, conversión y mantenimiento.

BÁSICO INTERMEDIO

MODO a b c d A B C D
Orgánico 2,1 1,05 2,5 0,38 3,2 1,05 2,5 0,34

Semi – 3,0 1,12 2,5 0,35 3,0 1,12 2,5 0,35

orgánico
Empotrado 3,6 1,20 2,5 0,32 2,8 1,20 2,5 0,32

Tabla 2.3 Detalle de Coeficiente de COCOMO

Fuente: (Roger Pressman, 2010)
Por otro lado, existen diferentes modelos que define COCOMO y son las siguientes:

 Modelo básico: Se basa exclusivamente en el tamaño expresado en LDC.

 Modelo intermedio: Además del tamaño del programa incluye un conjunto de medidas
subjetivas llamadas conductores de costes.
 Modelo avanzado: Incluye todo lo del modelo intermedio además del impacto de cada
conductor de coste en las distintas fases de desarrollo.

40
Para la realización del COCOMO previamente necesitamos conocer el número de líneas de
código, posteriormente para poder realizar los cálculos del método de estimación usamos las
siguientes ecuaciones.

Variable Ecuación Tipo/Unidad

Esfuerzo 𝐸 = 𝑎 (𝐾𝐿𝐶𝐷)𝑏 ∗ 𝐹𝐴𝐸 Personas/mes

Tiempo 𝑇 = 𝑐 (𝐸)𝑑 Meses

Número de personas E Personas

T 𝑁𝑃 =

Costo total CT = NP x T x sueldo mes $us.

Costo por líneas de código $us.

Tabla 2.4 Ecuaciones de Método de COCOMO

Fuente: (Calibrado, 1981)

Para el presente proyecto tomaremos como métrica d calidad el modelo de seguridad la ISO
27000.

2.13.1. ISO 27000

Las normas ISO 27000 una familia de estándares para sistemas de gestión de seguridad de la
información que proporciona el marco de seguridad.
Define requisitos para un sistema de gestión de la seguridad de la información (SGSI), con el
fin de garantizar la selección de controles de seguridad adecuados y proporcionales, protegiendo
así la información, es recomendable para cualquier grande o pequeña empresa.
2.13.1.1 Características de la Norma ISO 27000

 Confidencialidad: la propiedad que da esta información esté disponible y no sea

divulgada a personas, entidades o procesos no autorizados.

 Seguridad De Información: preservación de la confidencialidad, integridad,

disponibilidad, no-repudio y confiabilidad.

41
 Sistema De Gestión De La Seguridad De La Información: esa parte del sistema
gerencial general, basada en un enfoque de riesgo comercial; para establecer,
implementar, monitorear, revisar, mantener y mejorar la seguridad de información.

42
 CAPITULO III
MARCO APLICATIVO

43
3. MARCO APLICATIVO

3.1. INTRODUCCIÓN
En este capítulo se desarrolla las etapas y modelos correspondientes a la fase de obtención de
requerimientos, diseño del sistema, codificación, pruebas y la fase de implementación,
siguiendo el proceso de desarrollo de la metodología UWE detalladas que ese encuentra en el
capítulo II.
3.1.1. Descripción General De La Empresa TechsBol El Alto-Bolivia

TECHSBOL es una empresa dedicada a las ventas de productos de componentes electrónicos,

también realiza servicios de instalaciones de cámaras de seguridad, realizan servicios
tecnológicos, innovadoras y de calidad, que permiten optimizar sus procesos y cumplir sus
objetivos, para aumentar la rentabilidad de sus clientes, la empresa tiene un gran equipo que es
comprometido al trabajo que realizan, porque demuestran fidelidad, confidencialidad y sentido
de pertenencia hacia los clientes.
3.2 Captura de Requerimientos
Las tareas de ingeniería de requerimientos son fundamental para que un sistema sea exitoso, en
el presente proyecto se indica las actividades realizadas.
TAREA CARACTERÍSTICAS

Se realizaron entrevistas con:

 Administrador
Entrevista  Vendedor
 Cliente

Observación En la empresa TECHSBOL Se presentan dificultades en el área de

administración porque en la mayoría es controlado manualmente todos
los procesos desarrollados.
Documentación Se obtuvo la documentación física

Tabla 3.1 Tareas para Obtención de Requerimientos

Fuente: (Elaboración Propia)

44
3.3.1. Definición de Actores

En la definición de actores nos permitió conocer a las personas involucradas que realizan el
proceso de la administración de los productos.

ACTOR DESCRIPCION

Este actor es el que está técnicamente informado bien informado,

conoce y puede realizar todos los niveles de tareas, es la persona
ADMINISTRADOR que tiene la responsabilidad de tener un control y seguimiento de
las actividades de la institución.

Se encarga de realizar el registro de cada producto en venta,

VENDEDOR

CLIENTE
Se encarga la compra de producto, del pedido del catálogo que
ofrece la empresa.

Tabla 3.2 Lista de Actores

Fuente: (Elaboración Propia)

3.3.2. Requerimientos Funcionales

Los requerimientos funcionales en la siguiente tabla muestran las características que necesita el
sistema a partir de la información obtenida como parte de las tareas de obtención de requisitos.

ROL FUNCION CATEGORIA

R1 El sistema debe tener seguridad en el acceso a la información del Evidente

sistema.

R2 Gestión de usuarios (administrador, vendedor y cliente). Evidente

45
 R3 Gestión de compras de productos Evidente

R4 Reporte de datos de Producto Evidente

R5 Registro de datos de clientes Evidente

R6 Reportes estadísticos de pedidos de cada producto Evidente

R7 Registro de ventas de productos Evidente

R8 Registrar ventas realizadas

R9 Generar Reportes estadísticos de pedidos que realizan los clientes. Evidente

R10 Cerrar sesión del sistema Oculto

Tabla 3.3 Requerimientos Funcionales

Fuente: (Elaboración propia)
3.3.3. Requerimientos No Funcionales

En la siguiente tabla se muestra los requisitos no funcionales:

ROL FUNCION CATEGORIA

R1 El sistema debe visualizarse y funcionar correctamente en cualquier Evidente

navegador como ser internet Explorer, Mozilla, Chrome, etc.

R2 Soporte y mantenimiento periódico para asegurar el buen rendimiento Evidente

del sistema.

R3 El sistema debe tener un entorno amigable al usuario, para poder Evidente

tener un entendimiento de las funcionalidades y operaciones que
puede realizar el sistema.
Evidente
R4 Respaldo energético del servidor, para asegurar la disponibilidad del
sistema.

Tabla 3.4 Requerimiento No Funcionales

Fuente: (Elaboración Propia)

46
3.4. Modelos de Casos de Uso
Mostramos el punto de análisis de Requerimientos del sistema mediante el diseño de casos de
uso, que describe el comportamiento del sistema frente a las acciones de los actores de este, así
como el funcionamiento del sistema y además elementos que permiten la abstracción del
problema.
3.4.1. Diagrama de caso de uso general del sistema

A continuación, se hace el modelado donde se puede apreciar en la figura 3.1 cómo interactúan
los actores sobre los casos del sistema.

Figura 3.1 Diagrama de Casos de Uso General del Sistema

Fuente: (Elaboración Propia)

47
 Figura 3.2 Descripción del Caso de Uso: Gestión Usuarios

Fuente: (Elaboración Propia)

CASO DE USO: GESTIONAR USUARIO

Actor Administrador

Tipo Primario Esencial

El administrador registra y designa el rol de cada usuario en base a

Descripción las funciones que desempeñan estos para ingresar al sistema.

Tabla 3.5 Descripción del Caso de Uso: Gestionar Usuario

Fuente: (Elaboración Propia)

48
 Figura 3.3 Diagrama de Casos de Uso: Gestionar Clientes

Fuente: (Elaboración Propia)

CASO DE USO: GESTIONAR CLIENTES

Actor Vendedor

Tipo Primario Esencial

El vendedor registra, según los requerimientos del cliente. No será

necesario registrar nuevamente los datos de los clientes frecuentes.
Descripción Además, que permitirá modificar e eliminar los datos del cliente si es
necesario.

Tabla 3.6 Descripción del Caso de Uso: Gestionar clientes

Fuente: (Elaboración Propia)

49
 Figura 3.4 Diagrama de Caso de Uso: registrar Producto

Fuente: (Elaboración Propia)

CASO DE USO: REGISTRAR PRODUCTOS

Actor Administrador

Tipo Primario Esencial

El administrador registra los productos que ofrece a los clientes de

cada Artículo. También asigna los respectivos precios a cada
Descripción producto para luego ponerlos a venta.
Además, permite actualizar y eliminar los productos cuando sea
necesario de cada Artículo que se encuentra en el catálogo.

Tabla 3.7 Descripción de Caso de Uso: Registrar Productos

Fuente: (Elaboración Propia)

50
 Figura 3.5 Diagramas de Caso de Uso: Realizar Pedidos

Fuente: (Elaboración Propia)

CASO DE USO: REALIZAR PEDIDOS

ACTOR Cliente

TIPO Secundario

Una vez realizado el pago por el producto, se hará visible las

DESCRIPCIÓN características del servicio solicitado, y según los requerimientos del
cliente se procederá el pedido de productos del artículo confirmando
las condiciones de este.
Tabla 3.8 Descripción del Caso de Uso: Realizar Producto
Fuente:(Elaboración Propia)

51
 Figura 3.6 Diagrama de Casos de Uso: Registrar Ventas

Fuente: (Elaboracion Propia)

CASO DE USO: REGISTRAR VENTAS

Vendedor
ACTOR

Secundario
TIPO

Una vez registrado el producto, se hará visible las características

del producto solicitado y comprobado y según los requerimientos
del cliente se procederá el pedido de productos del artículo
DESCRIPCIÓN confirmando las condiciones del mismo y venderlo.

Tabla 3.9 Descripción Registrar Ventas

Fuente (Elaboracion Propia)
3.5. Diseño conceptual
3.5.1. Modelo Conceptual

A continuación, se muestra o visualiza las relaciones entre las clases que involucran el sistema.

52
Figura 3.7 Diagrama de Clase

Fuente (Elaboración propia)

53
3.6. Diseño de Navegación
A continuación, se hace el modelado donde se aprecia la interactuación de los usuarios en la
navegación del sistema.

Figure 3.8 Diagrama De Navegación: Administrador

fuente: (Elaboración propia)

Figure 3.8.1 Diagrama de navegación Clientes

54
3.7 Diseño De Presentación
Los modelos de presentación según UWE proponen para la construcción de páginas en forma
de bosquejos, donde se muestra como los usuarios podrán acceder al sistema mostrando los
menús correspondientes según el tipo de usuario.
3.8 Implementación del Sistema
Ingresar a su navegador teclee la siguiente dirección:
 http://techsbol.test/login
3.8.1. Interfaz de inicio de sesión

Figura 3.9 Inicio De Sesión

Fuente: (Elaboración Propia)

El sistema verifica al usuario y clave ingresado de ser correcta la verificación, el usuario ingresa
al sistema y podrá acceder a las opciones según su rol asignado. En caso de insertar los datos
erróneos el sistema muestra un mensaje, como se ve la siguiente imagen.

55
 Figure 3.10 Menú Inicio donde se ingresa el Usuario y contraseña

Fuente: (Elaboración propia)

3.8.2 Funcionalidad General del sistema

En la ventana de Inicio se puede observar en la parte inferior las estadísticas generadas por los
datos introducidos en la Base de Datos.

Figure 3.11 Funcionalidad General del Sistema

Fuente (Elaboración Propia)

56
3.8.3 Módulos que integran el Sistema

En esta sección se muestra las capturas de todos los módulos que contiene el sistema (Ver 3.13)

Figure 3.12 Pantalla del Menú Catálogos: Categoría

Fuente: (Elaboración Propia)

Figure 3.13 Formulario para registrar categoría

Fuente: (Elaboración Propia)

57
 Figure 3.14 Pantalla de Menú Artículo

Fuente: (Elaboración Propia)

Figure 3.15 Pantalla de Productos-Baja de los artículos

Fuente: (Elaboración Propia)

58
 Figure 3.16 Registro de Artículos según Categoría

Fuente: (Elaboración Propia)

Figure 3.17 Modulo de Ventas: Pantalla de clientes

Fuente: (Elaboración Propia)

59
Figure 3.18 Registro de Cliente

Fuente: (Elaboración Propia)

Figure 3.19 Pantalla de Ventas

Fuente (Elaboración Propia)

60
Figure 3.20 Formulario de Registrar Cliente Según venta de Articulo
Fuente: (Elaboración propia)

Figure 3.21 Comprobante de Venta de Articulo

Fuente: (Elaboración Propia)

61
 Figure 3.22 Pantalla de Pedidos

Fuente: (Elaboración Propia)

Figure 3.23 Registro de Pedido por el Cliente

Fuente : (Elaborcacion Propia )

62
 Figure 3.24 Formulario de Venta del Pedido que realizó el Cliente

Fuente: (Elaboración Propia )

Figure 3.25 Comprobante de la venta de artículo del pedido que realizo el cliente

Fuente: (Elaboración Propia)

63
Figure 3.26 Módulo Compras: Pantalla de Proveedores

Fuente: (Elaboración Propia)

Figure 3.27 Registro de Proveedor

Fuente: (Elaboración Propia)

64
Figure 3.28 Pantalla de compras por proveedor

Fuente: (Elaboración Propia)

Figure 3.27 Pantalla Menú de Compras

Figure 3.29 Registro de Compras según Proveedor

Fuente (Elaboración Propia

65
 Figure 3.30 Registro de Compra de Proveedor

Fuente: (Elaboración Propia)

Figure 3.29 Datos de la Compra del Proveedor

Figure 3.31 Pantalla de Estadísticas de Ventas por Fechas y Empleados

Fuente: (Elaboración Propia)

66
Figure 3.32 Pantalla De Estadística De Productos Más Vendidos

Fuente: (Elaboración Propia)

Figure 3.33 Pantalla de Estadísticas de Compras

Fuente: (Elaboración Propia

67
Figure 3.34 Estadística de Productos Más Comprados

Fuente: (Elaboración Propia)

Figure 3.35 Pantalla de Estadísticas Generales

Fuente: (Elaboración Propia)

68
Figure 3.36 Estadísticas Generales De Cantidad De Productos Más Vendidos Y Registros
Totales
Fuente: (Elaboración Propia)

Figure 3.37 Reportes Generales y Concretos

Fuente: (Elaboración Propia)

69
Figure 3.38 Reportes Específicos de ventas y compras

Fuente: (Elaboración Propia)

Figure 3.39 Pantalla de Usuarios

Figure 3.40 Pantalla Historial

Fuente: (Elaboración Propia)

70
3.9. Prueba de función de Software
Luego del desarrollo del sistema, procede realizar las pruebas de los procedimientos que se
implementaron. Se tratará de encontrar todo posible error durante un proceso antes que se entre
en aplicación.
3.9.1 Pruebas de caja Blanca

Esta prueba se orienta al cálculo de las regiones que deben ser consideradas como caminos
independientes del sistema y estableciendo cuáles son las entradas para que se ejecutan cada
una de las regiones, asegurando así que cada región se ejecuta al menos una vez. De forma
general, se debe seguir:

Figure 3.41 Diagrama de Caja Blanca

Fuente (Elaboración Propia)

Donde:
 Inicio del Sistema (1)
 Menú de inicio (2)
 Módulo de Catálogos (3)
 Registros de Categoría (4)
 Registro de artículos (5)
 Módulo de Ventas (6)
 Registro de clientes (7)

71
  Registro de ventas (8)
Analizando el grafo generado a partir de las características del sistema, ahora se procede a
determinar la complejidad ciclo matica del grafo mediante:
V (G)= A-N+2 Donde:
A= 22 (Aristas)
B=15 (Nodos)
Por tanto, V (G)= 22-15+2=9
Determinar el conjunto básico de caminos linealmente independientes. Los caminos que
deben ser probados dadas ciertas variables son 9. Estos caminos son los siguientes:
Camino 1: 1-2-3-5-12-14-15
Camino 2: 1-2-3-6-12-14-15
Camino 3: 1-2-3-7-12-14-15
Camino 4: 1-2-3-8-12-14-15
Camino 5: 1-2-3-9-12-14-15
Camino 6: 1-2-4-9-12-14-15
Camino 7: 1-2-4-10-13-14-15
Camino 8: 1-2-4-11-13-14-15
Camino 9: 1-2-4-14-15

3.9.2 Pruebas de Caja Negra

Las pruebas de caja negra o también conocidas como prueba de comportamiento se centran en
los requisitos funcionales del software y la operación en el proceso realizado en la evaluación
fundamental del sistema.

Se procede a realizar una evaluación de acuerdo a los módulos para cotejar los resultados que
entrega el sistema ya sea mediante reportes o interfaces de resultados.

Registro de Usuario
Datos de ingreso: Se ingresa un usuario y una contraseña asignada por el administrador
de sistema en momento otorgado asignación de cargo.
Prueba: Se espera que el sistema realice las respectivas validaciones para el ingreso,
hace su procesamiento.

72
 Resultado: El Sistema no permite el ingreso al personal no autorizado por el
administrador del sistema.
Veremos el inicio de sesión al sistema.

Figure 3.42 Inicio de Sesión

Fuente: (Elaboración Propia)

Datos de ingreso: Se ingresa al módulo inicio.
Prueba: Se espera el procesamiento o que el sistema despliegue la información del sistema
Resultado: El sistema despliega enlaces de todo el menú correspondiente a su privilegio o rol
asignado.
3.9.3 Objetivo de la Prueba

Garantizar la funcionalidad del sistema, en aspectos importantes como el control de proceso,

validaciones, actualizaciones sobre todo la disponibilidad de la información.
PROCEDIMIENTO DESCRIPCIÓN VALOR

Prueba previa requerida Gestión de Usuario Si

Usuario Administrador, encargado de
ventas.
SECUENCIA DE PRUEBA
PROCEDIMIENTOS RESULTADOS CALIFICACIÓN DE
ESPERADOS FUNCIONALIDAD

73
 Ingresa al sistema con el nombre de usuario y Valida el sistema el ingreso SI
contraseña
FALLAS ENCONTRADAS DESCRIPCIÓN VALOR
Ninguna Ninguna
Pasaos de Prueba Resultados esperados Pos. Neg.
1 Desde pantalla login se ingresa al sistema El usuario ingresa al sistema X
con un usuario y contraseña. si los datos son correctos, y
según el grado de privilegios
que tenga
2 Una vez que se ingresa de forma El usuario debe tener acceso a X
autentificada se comprueba que tenga las cada uno de las áreas según su
áreas que puede realizar según sus privilegio.
privilegios.
3 El usuario ingresa a la gestión de cuenta. En la gestión de cuenta X
pueden cambiar su contraseña
y login.

4 El administrador puede registrar a El usuario debe tener X

nuevo vendedor y nuevo usuario. acceso a modificación
de datos del vendedor y
el usuario del sistema
Tabla 3.10 Procedimiento y descripción de pruebas del Sistema
Fuente: (Elaboración Propia)
Las pruebas de ingreso al sistema y de gestión de usuarios se efectuaron con absoluta
normalidad. Se obtuvo el resultado esperado en cuanto a la validación de usuario y contraseña
se mostraron respuestas favorables.

74
 CAPÍTULO IV
MÉTRICAS DE CALIDAD Y
SEGURIDAD

75
4. MÉTRICAS DE CALIDAD Y SEGURIDAD

4.1 Métricas de Calidad

El desarrollar un software de calidad es el objetivo de todo desarrollador, por tanto, se le dedica

muchos esfuerzos, pero también cabe mencionar que no se logra la perfección en el producto
de software, pero se debe tomar en cuenta que todo software debe cumplir y/o superar las
expectativas del cliente. Si cumple esta característica tendrá la dominación de un software de
alta calidad.

En la actualidad existen diversas opciones, los estándares y modelos de evaluación y mejora de

los procesos de software que están relacionados con la calidad, el presente proyecto usara la
norma ISO 25010 (International Standard Organización – Organización Internacional de
Normalización) nos ayudara a medir la calidad del sistema siguiendo criterios planteados
[García, 2010].

4.1.1 Funcionalidad

Mediante la funcionalidad se podrá medir la capacidad del software de cumplir y proveer

funciones que satisfagan las necesidades explicitas e implícitas cuando es utilizado en
condiciones específicas.

 Número de entradas de usuario: se refiere a cada entrada que proporciona datos al

sistema.
 Número de salidas de usuarios: se refiere a cada salida que proporciona el sistema al
usuario, entre estos están: informes, pantallas, mensajes de errores, etc.
 Número de peticiones de usuario: una petición se define como una entrada interactiva
que produce la generación de alguna respuesta del software en forma de salidas
interactivas.
 Número de archivos: se cuenta archivos maestro lógico, estos pueden ser: grupo lógico
de datos, o un archivo independiente.
 Número de interfaces externas: se cuenta las interfaces legibles por la máquina que se
utilizan para transmitir información a otro sistema.

76
La funcionalidad es medida a través del punto función (PF), que proporciona una medida
objetiva, cuantitativa y auditable del tamaño de la aplicación, basada en la visión del usuario de
la aplicación (Pressman R. , Ingeniería del software Un enfoque práctico, 2010).

Para calcular el punto función se utiliza la siguiente relación:

PF = Cuenta Total * (X + Min (Y) * Σ Fi)

Dónde:
PF: Medida de funcionalidad
Cuenta total: es la suma de los siguientes datos (N° De Entradas, N° De Salidas, N°
Peticiones, N° De Archivos, N° De Interfaces Externas).
X: Confiabilidad del proyecto, varía entre 1 a 100%
MIN (Y): Error mínimo aceptable al de la complejidad.
Σ Fi: Son los valores de ajuste de complejidad, donde (1 ≤ i ≤ 14)
En la siguiente tabla muestra la cuenta de los dominios de información establecidos en el sistema
web de acuerdo a los parámetros de medición.
PARÁMETROS DE CUENTA FACTOR DE RESULTADO
ENTRADA COMPLEJIDAD
Número de entradas de 10 6 60
Usuario
Número de salidas de 10 7 70
usuario
Número de peticiones de 30 6 180
usuario
Número de archivos 16 10 160

Número de interfaces 0 10 0
externas
Cuenta Total 470

Tabla 4.1 Factor de ponderación para la funcionalidad

Fuente: (Elaboración Propia)
La tabla 4.2 muestra factores, ajustes de complejidad con sus respectivos valores establecidos.

77
FACTOR DE AJUSTE DE VALOR Peso

1. ¿Requiere el sistema copias de seguridad y de recuperación fiable? 5

2. ¿Se requiere comunicaciones de datos especializadas para transferir información hacia 5

o desde la aplicación?

3. ¿Existe funciones de procesamiento distribuidas? 2

4. ¿es crítico el rendimiento? 5

5. ¿El sistema correrá en un entorno operativo existente enormemente utilizado? 5

6. ¿El sistema requiere entradas de datos en línea? 4

7. ¿La entrada de datos en línea requiere que la transacción de entrada se construya 4

sobre múltiples pantallas u operaciones?

8. ¿Los ALI se actualizan en línea? 5

9. ¿Las entradas, salidas, archivos o consultas son complejos? 3

10. ¿El procesamiento interno es complejo? 3

11. ¿El código se diseña para ser reutilizable? 5

12. ¿La conversión y la instalación se incluye en el diseño? 5

13. ¿El sistema se diseña para instalaciones múltiples en referentes organizaciones? 3

14. ¿La aplicación se diseña para facilitar el cambio y su uso por parte del usuario? 3

Σ Fi 60

Tabla 4.2 Ajustes de Complejidad

Fuente: (Pressman, 2010)
 Para calcular puntos función (PF) SE usa la siguiente relación (Pressman R. , Ingeniería
del software Un enfoque práctico, 2010)

78
 PF = conteo total * (0.65+ (0.01* Σ Fi))
PF = 470 * (0.65+ (0.01*60))
PF =587.5
A continuación, calculamos el ajuste, con sus pesos máximos siendo este:
Σ Fi = 5*14
Σ Fi = 70
De aquí tenemos:
PF ajuste = 587.5 * (0.65+ (0.01 *70))
PF ajuste = 793.125

Con esto podemos calcular la funcionalidad del sistema expresándola en porcentaje:

Funcionalidad = (PF / PF ajuste) * 100

Funcionalidad = (587.5/793.125) * 100
Funcionalidad = 74%
4.1.2. Fiabilidad

Se podrá medir la capacidad del software para asegurar un nivel de funcionamiento adecuado
cuando es utilizado en condiciones específicas, la confiabilidad se amplía a sostener un nivel
especificado y funcionamiento y no una función requerida.
Tiempo de servicio Número de Fallos encontrados Probabilidad de Tiempo medio
peticiones fallo entre falos
8horas 30 0 0 0
16 horas 60 1 0.0166 16
32 horas 100 1 0.01 32
64 horas 190 3 0.0157 21.33

Tabla 4.3 Cálculos de fallos del sistema

Fuente:(Elaboración Propia)

Por lo tanto, el valor promedio de fallas producidas en un tiempo de servicio (PFTS) es la

siguiente:
PFTS = ((0 + 0.0166 + 0.01 + 0.0157) / 4)
PFTS = (0.0423 / 4)
PFTS = 0.010575

79
Lo que se indica que el sistema en promedio presentar 10 fallas de cada 1000 peticiones. El
tiempo promedio de presentarse estas fallas es:
PFT = ((0 + 16 + 32 + 21.33) / 4)
PFT = (69.33 / 4)
PFT = 17.33

Con este resultado obtenido el sistema puede presentar fallas en promedio después de 17.33
horas que se hace uso del mismo. Calculando la fiabilidad, con el valor de PFTS obteniendo y
expresándola en porcentaje se tiene:

Fiabilidad = (1 - 0.010575) * 100

Fiabilidad = 98.9 %

Con el resultado obtenido se puede interpretar: que cada sistema tiene la capacidad de ser
utilizado libre de errores en promedio 99 de cada 100 veces.

4.1.3. Usabilidad

Con la fiabilidad podremos obtener la capacidad del software de ser entendido, aprendido y
usado en forma fácil y atractiva. La usabilidad está determinada por los usuarios finales y los
usuarios de software.

A través de los datos obtenidos en encuesta que se realizó directamente a un grupo determinado
de usuarios finales. Como es siguiente proyecto es para Empresa TechsBol- Venta y compra de
componentes Electrónicos, se tiene los datos por cada usuario y su respectiva población.

4.2 Métricas De Seguridad

4.2.1. Seguridad De Información ISO 27001

La ISO27001 desarrolla los conceptos de “calidad de la seguridad” y “madurez” como

principales parámetros que dan la definición de indicadores y métricas. Los pasos que tienen
que seguir para adoptar un conjunto de métricas son:

 Reconoce los elementos a medir a partir del índice del estándar ISO 1779.
 Define los niveles de madurez para cada elemento medible.

80
  Define los niveles de calidad para cada nivel de madurez de elemento.

Con ello obtendremos los valores de información que dará del nivel de evolución del control y
calidad con la que se lleva a cabo la implementación, valores que pueden ser una imagen real
del nivel de la seguridad de la empresa.

Se implanta de la ISO-27001 las actividades:

 Definición del alcance del sistema de Gestión de Seguridad de la Información.

 Define la política de Seguridad.
 Define los métodos y criterios para la Gestión y evaluación del riesgo.
 Identificación de los riesgos.
 Evaluación de los tratamientos de riesgos posibles.
 Desarrollo de la aplicabilidad de controles y requisitos.

81
 CAPÍTULO V
ANÁLISIS DE COSTOS

82
5.1 INTRODUCCIÓN

Existe distintos métodos para la estimación de costo de software, estos métodos establecen una
relación matemática entre el esfuerzo y el tiempo de desarrollo.

5.2 CÁCULO DE COSTOS

5.2.1 Método de Estimación de COCOMO

La estimación de costos del sistema ha sido desarrollada bajo la KLDC (kilo-líneas de código)
como se detalla a continuación.

Para calcular el esfuerzo, se necesita hallar la variable KLDC. Este proyecto se implementa
8093 Líneas de Código en el lenguaje PHP.

Aplicando las conversiones se tiene:

KLDC=(LDC)/1000

KLDC=8093/1000

KLDC=8,09 KLDC

Es un modelo intermedio y Sistema orgánico la evaluación del sistema ha sido considerada

bajo 8093 KLDC los coeficientes que se usarán serán los valores que detallen en las siguientes
tablas:

PROYECTO SOFTWARE A B C D

Orgánico 3,2 1,5 2,5 0,38

Semiacoplado 3,0 1,12 2,5 0,35

Empotrado 2,8 1,20 2,5 0,32

Tabla 5.1 Aplicación del Modelo Intermedio

Fuente: (S. Pressman, 2010)

A continuación, presentaremos las ecuaciones que permitan realizar el costo total del
software:
83
 VARIABLE ECUACION TIPO/UNIDAD

Esfuerzo requerido por el E=a*(KLDC)^b*FAE Personas/mes

proyecto

Tiempo requerido por el Proyecto T=c*(E)^n meses

Número de personas requeridas NP=E/T personas

para el proyecto

Costo total CT=Sueldo Mes * NP*T $us

Tabla 5.2 Ecuaciones del modelo COCOMO

Fuente: (S. Prentice-Hall, 191)
Para hallar los valores de la FAE, se utilizará la tabla de atributos multiplicadores.

Atributos Valor

Muy Bajo Nominal Alto Muy Extra alto

bajo alto

Atributos de software
Fiabilidad 0,75 0,88 1,00 1,15 1,40

Tamaño de Base de datos 0,94 1,00 1,08 1,16

Complejidad 0,70 0,85 1,00 1,15 1,30 1,65

Atributos de hardware
Restricciones de tiempo de 1,00 1,11 1,30 1,66
ejecución

Restricciones de memoria virtual 1,00 1,06 1,21 1,56

Volatilidad de la máquina virtual 0,87 1,00 1,15 1,30

Tiempo de respuesta 0,87 1,00 1,07 1,15

Atributos de personal
Capacidad de análisis 1,46 1,19 1,00 0,86 0,71

Experiencia en la aplicación 1,29 1,13 1,00 0,91 0,82

Calidad de los programadores 1,42 1,17 1,00 0,86 0,70

84
 Experiencia en la máquina virtual 1,21 1,10 1,00 0,90

Experiencia en el lenguaje 1,14 1,07 1,00 0,95

Atributos del proyecto

Técnicas actualizadas de 1,24 1,10 1,00 0,91 0,82
programación

Utilización de herramientas de software 1,24 1,10 1,00 0,91 0,83

Restricciones de tiempo de 1,22 1,08 1,00 1,04 1,10

desarrollo

Total 0,72
Tabla 5.3 Calculo de Atributos FAE
Fuente: (Elaboración Propia)
Por tanto, el FACTOR de ajusto será:
FAE= 0,72
Aplicando y reemplazando a los valores de la fórmula de esfuerzo, se tiene:

𝐸 = 𝑎 ∗ (𝐾𝐿𝐶𝐷)𝑏 ∗ 𝐹𝐴𝐸 (Personas/Mes)

𝐸 = 3,2 ∗ (8.09)1,05 ∗ 0,72

𝐸 = 20 ,6 (Personas Mes)

Cálculo del Tiempo

𝑇 = 𝑐 ∗ 𝐸𝑠𝑓𝑢𝑒𝑟𝑧𝑜𝑑(Meses)

𝑇 = 2,5 ∗ 210,38

𝑇 = 7.9(Meses)

Calculo de la Productividad

(Meses)

PR= 8093/21(Meses)

85
 𝑃𝑅 = 385.38 (LCD/personas Mes)

Calculo del personal requerido

(Personas)

P= 20.6/7.9(Personas)

𝑃 = 2.60(Personas) equivalente a 3 personas

Costo Total del Proyecto

(Coste Mes) = P* Salario medio entre los programadores y analistas

Costo Persona Mes 350$

Coste Mes= 3*350 = 1050$us en Bs.- 7350

Costo Total= 1050*8 = 8400$us en Bs.-58800

En resumen, se requiere 3 personas estimando un trabajo de 8 meses y con costo

total de 8400$us equivalente en bolivianos 58800 Bs.

86
 CAPÍTULO VI
CONCLUSIÓN Y
RECOMENDACIONES

87
6. CONCLUSIONES Y RECOMENDACIONES

En este capítulo se presenta las conclusiones del proyecto, el cual demuestra el alcance de los
objetivos planteados en el capítulo I. En las recomendaciones se propone el desarrollo de
trabajos que se pueden desarrollar posteriormente.
6.1. Conclusiones

Una vez terminado el proceso de construcción del sistema se concluye que:

 Se recabó toda la información necesaria en cuanto a la administración y organización de

la empresa, ya que todo esto nos ayudó identificar los diferentes problemas con las que
cuenta al brindar la atención al cliente.
 Se obtuvo el registro de cada artículo de producto y pedidos de cada producto para poder
recabar los diferentes datos, que fueron necesarios para desarrollar un Módulo que
realiza Pedidos y Registro de clientes tanto a nuevos y antiguos.

6.2. Recomendaciones

A partir del presente trabajo se propone las siguientes recomendaciones, con el fin de buscar el
mejoramiento del sistema.

 En caso de reutilizar el sistema para las nuevas sucursales, hacer nuevas configuraciones
según los requerimientos de las respectivas sucursales.
 Capacitar a los nuevos usuarios administradores para poder realizar operaciones en el
sistema y así poder administrar correctamente.
 Se recomienda al usuario cambiar continuamente su contraseña para la seguridad del
sistema y proteger el acceso de personas ajenas y malintencionadas al mismo.
 La revisión periódica por cierto periodo de tiempo es recomendable para eficiencia y un
funcionamiento adecuado del sistema.
 Se recomienda a la empresa, tener cuidado al momento de asignar ciertos privilegios a
los roles de los usuarios.
 Cuando se requiera la ampliación y creación de nuevos módulos, se recomienda primero
revisar la documentación para poder tomar una buena decisión, ya que el sistema
presenta elementos reutilizables que podrían ser utilizadas en los nuevos módulos.

88
BIBLIOGRAFIA
 Ceballos, K. (5 De Junio, 2015). UML CASOS DE USO.
 Garcia, C. L. (2010). Guia Tecnica Evaluacion de Software. madrid.
 Gracia, L. (7 de febrero de 2012). Modelos de estimacion: un poco sobre COCOMO II.
 Métricas para la Calidad de Software. (2018). Recuperado de Ecured:
 Jennifer, & Lopez, J. (8 de Dicembre, 2010).
 Castillo, Y (2015). Gestión de Almacenes e inventarios. Recuperado de:
 COCOMO Un Modelo de Estimación de Proyectos Software
 Kendall, K. (1997). Análisis y Diseño de Sistemas.
 Pressman, R. (2010). Ingeniería del software Un enfoque práctico. McGraw-Hill.
 Rojas, D. (2018). En Daniela.
 Manual del framework PHP Laravel, centrándonos en versión Laravel 5 (concretamente
Laravel 5.1), que nos trae diversas mejoras en rendimiento...
 Migani, S. M. silvina. (2011). modelo cocomo II.
 Schmitz, D. S. Daniel, & Urquiza, J. U. juan. (2015). Laravel y angular.
doi:https://leanpub.com/laravel-y-angularjs
 PRESSMAN, R. P. ROGER. (2010). INGENIERÍA DE SOFTWARE (7ª ed.). México,
México: Mc Graw Hill.
 Barrera, J. c. (26 de 09 de 2011). Metodologias para el desarrollo de aplicaciones
WEB. Recuperado el 20 de 04 de 2019, de Aplicaciones WEB:
http://www.slideshare.net/ARCANGEL2032/metodologias-para-eldesarrollo-de-
aplicaciones-Web-9419415#btnNext
 Cordova JR. (2013). Metodología UWE-UML. Recuperado el 10 de Noviembre de
2019, de Enubes: http://www.enubes.com/desarrollo-de-aplicacionesweb.html
 GITBOOK. (2011). Laravel 5. Recuperado el 17 de Noviembre de 2019, de
 Laravel 5: https://ajgallego.gitbooks.io/laravel-5/content/introduccion.html

89
DISPONIBLE EN:

https://www.ecured.cu/Metricas_para_la_calidad_del_software//

http://www.monografias.com/trabajos106/gestion-almacenes-e-inventarios/gestion-
almacenes-e-inventarios.shtml

http://www.monografias.com/trabajos106/gestion-almacenes-e-almacenes-e-inventarios.shtml

https://www.ecured.cu/Metricas_para_la_calidad_del_software

Caterina Chen, 2019, Sistema de Información. Recuperado de

http://www.significados.com/sistema-de-informacion

https://uwe.pst.ifi.lmu.de/toolMagicUWEReferenceV1.3.html

http://www.academia.edu/4853590/UN_MODELO_DE_ESTIMACION_DE_PROYECTOS_
DE_SOFTWARE

90
Anexos

91
 ANEXO A
ÁRBOL DE PROBLEMAS

92
ARBOL DE PROBLEMAS

93
 ANEXO B
ÁRBOL DE OBJETIVOS

94
ÁRBOL DE OBJETIVO

95
 ANEXO C
CUESTIONARIO

96
 CUESTIONARIO

Nombres y apellidos: …………………………………………………………

Nombre de la empresa ……………………………………Cargo: ……………………

Marcar que con una X la puntuación

Tu sinceridad es muy importante en cuanto es tu facilidad de uso del sistema

Puntuación del 1 al 10 %
PREGUNTAS
1 2 3 4 5 6 7 8 9 10

¿Puede ser usado con facilidad el sistema?

¿El diseño le facilita hacer recorrido sobre la

aplicación?
¿El sistema puede ser aprendido con facilidad?

¿El sistema cuenta con interfaz agradable a la vista?

¿Las salidas son entendibles?

¿Le parecen complicadas las funciones del sistema?

¿Las salidas son esperadas y satisfactorias

¿Se produjo errores al manejar el sistema?

¿Es dificultoso manejar el sistema?

¿Los reportes le ayudan en su trabajo?

97
 ANEXO D
DOCUMNETACIÓN
DE RESPALDO

98
99
100
101
102
 MANUAL DE USUARIO
SISTEMA DE INFORMACIÓN WEB
PARA LA GESTIÓN DE COMPRA Y
VENTA E INVENTARIOS DE
COMPONENTES ELECTRÓNICOS

“CASO EMPRESA: TECHSBOL”

JEANETH DELICIA BAUTISTA LUQUE

La Paz-Bolivia

2020

103
1. INTRODUCCIÓN

El “Sistema de Información Web para la Gestión de compra y Venta e Inventarios de

Componentes Electrónicos CASO: EMPRESA TECHSBOL” es un sistema que ayuda a la
administración y control de información más adecuado y eficiente en las actividades que se
realiza en la empresa, para poder tener orden de cada producto en categoría.

Es “Sistema de Información Web para la gestión de compra y venta e inventarios”, el objetivo

es de brindar información relevante de forma ordenada y rápida de productos en el almacén,
teniendo en cuenta los reportes de cada uno de los módulos.

2. OBJETIVO
El objetivo de este manual es para poder acceder y guiar al usuario mediante este documento
para el uso del sistema de forma correcta.
3. FORMAS DE ACCESO

Para acceder al sistema se debe contar con algún navegador web como: Google Chrome, Mozilla
Firefox, Opera, Internet Explorer, etc.

4. INGRESO AL SISTEMA

Ingresar a su navegador teclee la siguiente dirección:

 http://techsbol.test/login

Interfaz de inicio de sesión

Objetivo: autenticarse en el sistema para acceder a cada uno de los módulos correspondientes.

Descripción: Se deberá ingresar con una cuenta un nombre del Usuario y password
proporcionados por el administrador.

104
4.1 INICIO DE SESIÓN

El sistema verifica al usuario y clave ingresado de ser correcta la verificación, el usuario ingresa
al sistema y podrá acceder a las opciones según su rol asignado. En caso de insertar los datos
erróneos el sistema muestra un mensaje, como se ve la siguiente imagen.

5. FUNCIONALIDAD GENERAL DEL SISTEMA PANEL PRIMCIPAL DEL

ADMINISTRADOR

Permite tener control, manipuleo de todos los menús del sistema. Inserción, modificación,
eliminación de los productos y usuarios. Pueden realizar pedidos, reportes.

El sistema se divide 3 zonas las cuales son: Zona de usuario, Zona de Menú y Zona Central o
Zona de trabajo.

105
En la ventana de Inicio se puede observar en la parte inferior las estadísticas generadas por los
datos introducidos en la Base de Datos.

Zona de Usuario

Zona de Menú

6. MÓDULOS QUE INTEGRAN EL SISTEMA

6.1 MENÚ DE CATALOGOS
En esta parte se registran categorías de los Artículos, registra con mucha seguridad, al igual
que se puede eliminar y editar o modificar un catálogo.

En esta sección se muestra las capturas de todos los módulos que contiene el sistema

106
 Se hace un clic en Catálogo, luego se ingresa a menú categorías, realizamos un nuevo registro
de categoría en la cual hacemos clic en (nuevo) ahí se ira registrando los nombres de artículos,
descripción. Aquí se registran categoría del Artículo para realizar tipo de categoría.

1. Nombre de la Catgoria
2. Ubicación donde se encuentra el Articulo de la Categoria
3. Descripcion de la categoria
4. Registramos categoria
7. PANTALLA DE MENÚ CATÁLOGOS: MÓDULO DE ARTÍCULOS

107
 8. REGISTRO DE ARTICULO DESIGNANDO A LA CATEGORIA
QUE PERTENECE

Nombre del articulo

Designar categoría

Seleccionar imagen de Articulo

Descripción del producto

Se registra el nombre del artículo, se designa la Categoria , insertamos el precio de compra, el

precio de venta , el stock y el stock minimo. Se selecciona imagen del producto y luego se hace
la descripcion del producto.

108
3.Se ingresa al boton Ver bajas, se muestra los prodcutos que estan dados de baja , el núnero,
Nombre del artículo, la cantidad, la observación del porque esta dada debaja el producto, quien
le dio de baja (Uusario). En las acciones es donde s epuede editar para corregir el error o
amunentar las observaciones.

9. MÓDULO DE VENTAS DONDE SE INGRESA A CLIENTES

Una vez ingresada a módulo a Ventas, hacer clic en clientes.

2..Se registra a un nuevo cliente haciendo clic (+NUEVO). Registarndo con sus datos
personales.

10. REGISTRAR NUEVO CLIENTE

109
11. MÓDULO DE VENTAS

1. Hacer un clic +Nuevo registro de venta, ingresando aparece una anunciado donde pide
registrar cliente o buscar de un cliente ya registrado en sistema según el cliente informe.

 Viendo la ventanilla se registra a un nuevo cliente

 En antiguo cliente, se referiré que ya está registrada en sistema sus datos personales y
realiza la compras y ventas.

110
  Se registra un Nuevo Cliente, con todo los datos correpondiente
 Ingresar al registro de Antiguo cliente , donde el sistema ya encontrara el nombre del
cliente y hace directamente la venta.
 Hacer click en Agregar Artículos

11. REGISTRO DE VENTAS

En este modulo se realiza el registro de ventas , en la cual se hace el llenado de datos
personales del Cliente se agerga el artículo que desea comprar , cuantos artículos, hay
clientes antifuos en el sistema registardos , como asi tambien ingresan nuevos clientes que
tambien se les registra.

Una vez registrada todos los datos del cliente (Nuevo ó Antiguo) y el ó los artículos agregados
de venta, hacer clic en imprimir, para tener el comprabante de la venta.

En el comprobante se muestra el número de Articículos, el precio del producto, la cantidad , y

subtotal de pago que se debe realizar, la fecha y hora número de comprobante una vez impresa
se muestra.

111
Comprobante de ventas de registro por cliente , en la cual muestra el numero , artículo precio,
cantidad, y subtotal

12. MÓDULO PEDIDOS

112
  Si es nuevo cliente se realiza un regitro con nuevos datos
 Si es cliente antiguo se lo busca en sistema porque ya esta registardo
13. REGISTRO DE PEDIDOS

 En este formulario los registros del cliente antiguo se muestran que estan ya registrados
correctemente.

113
  Una vez que el liente desee hacer la compra del producto de pedidos pasa por la empresa
y al usuario ve el registro de su pedido y hace clic en vender.

 Una vez realizada el pedido se observa el formulario ventas.

 Se muestra el comprobante de oedido de oriducto

114
14. COMPROBANTE DE VENTAS REALIZADAS POR PEDIDO

15. MÓDULO DE COMPRAS: MENÚ DE COMPRAS

 Hacer clic en +NUEVO para registrar compras

115
16. REGISTRO DE COMPRAS

 Hacer clic en +NUEVO , par ingresar Al formulario de REGISTRO DE

PROVEEDORES.

116
17. REGISTRAR NUEVO PROVEEDOR

 Se registra a un nuevo proveedor, llenando sus datos.

18. ESATDISTICAS

117
 MANUAL DE TÉCNICO

SISTEMA DE INFORMACIÓN WEB PARA

LA GESTIÓN DE COMPRA Y VENTA E
INVENTARIOS DE COMPONENTES
ELECTRÓNICOS

“CASO EMPRESA: TECHSBOL”

JEANETH DELICIA BAUTISTA LUQUE

La Paz-Bolivia

2020

118
INTRODUCCIÓN

El manual técnico detalla los pasos adecuados para realizar la instalación del sistema titulado
“Sistema de Información Web para la gestión de compra y venta e inventario de componentes
electrónicos”, CASO: EMPRESA TECHSBOL.

También se hace mención de especificaciones mínimas de hardware y software para la correcta

instalación del software.

Objetivo

Informar y especificar al usuario la instalación del sistema con el fin que puedan hacer soporte
y modificaciones al sistema en general.

Requerimientos mínimos de Hardware

 Computadora personal (teclado, mouse, monitor).

 Memoria RAM 2Gb Gigabytes.
 Disco Duro 500Gb
 Procesador 1.4 GHz.

Requerimientos mínimos de Software

 Sistema operativo (Windows 7 en adelante).

 Conexión a internet
 Navegación (Google Chrome, Opera, Internet Explorer, Etc.).
 Servidor web Apache versión 2.2.43
 Sistema de Gestor de base de Datos PhpAdym
 Para la administración de la base de datos se requiere la instalación laragon.

Pasos para la instalación del Sistema

Paso 1: Ir a la siguiente dirección http://techsbol.test/login

119
120
121