PG 3652

UNIVERSIDAD MAYOR DE SAN ANDRÉS
FACULTAD DE CIENCIAS PURAS Y NATURALES

CARRERA DE INFORMÁTICA
PROYECTO DE GRADO
SISTEMA INTEGRADO WEB DE CONTROL DE COMPRA,
VENTA E INVENTARIOS DE MEDICAMENTOS
CASO: “FARMACIA MAYA”
PARA OPTAR AL TÍTULO DE LICENCIATURA EN INFORMÁTICA
MENCIÓN: INGENIERÍA EN SISTEMAS INFORMÁTICOS
POSTULANTE: NELLY MARLENE CONDORI VILLALBA

TUTOR METODOLÓGICO: M. SC. ALDO VALDEZ ALVARADO
ASESOR: PH.D. YOHONI CUENCA SARZURI
LA PAZ – BOLIVIA
2020
LA CARRERA DE INFORMÁTICA DE LA FACULTAD DE CIENCIAS PURAS Y
NATURALES PERTENECIENTE A LA UNIVERSIDAD MAYOR DE SAN ANDRÉS
AUTORIZA EL USO DE LA INFORMACIÓN CONTENIDA EN ESTE
DOCUMENTO SI LOS PROPÓSITOS SON ESTRICTAMENTE ACADÉMICOS.
LICENCIA DE USO
El usuario está autorizado a:
a) visualizar el documento mediante el uso de un ordenador o dispositivo móvil.

b) copiar, almacenar o imprimir si ha de ser de uso exclusivamente personal y privado.
c) copiar textualmente parte(s) de su contenido mencionando la fuente y/o haciendo la
referencia correspondiente respetando normas de redacción e investigación.
El usuario no puede publicar, distribuir o realizar emisión o exhibición alguna de este

material, sin la autorización correspondiente.
TODOS LOS DERECHOS RESERVADOS. EL USO NO AUTORIZADO DE LOS

CONTENIDOS PUBLICADOS EN ESTE SITIO DERIVARA EN EL INICIO DE
ACCIONES LEGALES CONTEMPLADOS EN LA LEY DE DERECHOS DE
AUTOR.
Dedicatoria:
Dedicado con gran amor a mi padre

Dios que es la razón de mi vida, mi
inspiración y mi fortaleza por haberme
permitido llegar a este punto ayudándome a
sobrellevar las adversidades para lograr mis
objetivos con su gran infinito amor y bondad.
A mis queridos padres Elías y Paulina por

todo el amor, paciencia y el apoyo
incondicional que me dieron en todo
momento, quienes me encaminaron a lograr
esta meta profesional.
iii
AGRADECIMIENTOS
Quiero expresar mis más sinceros agradecimientos:
Primeramente, agradezco a mí a Dios por darme la fortaleza para seguir adelante a pesar de
los obstáculos, por guiar mi camino, protegerme y estar a mi lado en todo momento.
A mi familia, que sin su apoyo me hubiese sido muy difícil emprender este camino, gracias
por todo el apoyo y los valores que se me han inculcado.
A mi Docente tutor M.Sc. Aldo Ramiro Valdez Alvarado, quien con su gran calidad de
persona, profesionalismo y experiencia acompaño en el desarrollo del presente proyecto,
gracias por la paciencia y por los consejos que nos brinda.
A mi Docente revisor Ph.D. Yohoni Cuenca Sarzuri, quien con su excelente calidad
profesional realizo el seguimiento a este trabajo, los consejos, observaciones, correcciones
fueron aportes importantes en la elaboración de este proyecto.
A todos los Docentes de la carrera de informática por transmitirnos sus conocimientos y por
todo el desempeño que nos brindan.
Gracias a mis amigas y compañeras que me apoyaron a lo largo de mi vida universitaria, por
los buenos momentos compartidos.
RESUMEN
El desarrollo de un sistema web dio lugar a un desprendimiento de muchas ideas al ver la

tecnología avanzar el incidir a las empresas, no es tarea fácil a menos que sean trabajador o
conocedor exclusivo de la entidad para la obtención y proceso de datos vemos en Bolivia que
las diversas empresas no todas mantienen un desarrollo de uso de tecnologías actualizadas,
pero cabe destacar que van paso a paso por necesidad utilitaria optimizando tiempo con el
uso de las tecnologías.
El presente proyecto tiene como finalidad apoyar a la farmacia MAYA, mediante la

implementación del sistema integrado web que permitirá controlar la compra, venta y los
inventarios de los medicamentos.
Para el desarrollo del proyecto se utilizó la metodología ágil Scrum, que propone un modelo
de proceso incremental, basado en iteración y revisiones continuas. En cada iteración se
utilizó el lenguaje de modelado WebML, que está orientado para el desarrollo de sistemas
web. Después de cada iteración y al culminar el proyecto, se realizó las pruebas
correspondientes para garantizar la seguridad y calidad del sistema web desarrollado.
El software obtenido es un producto de calidad de acuerdo a la metodología de evaluación

de calidad de sistemas WEB-SITE QEM.
Finalmente se puede mostrar en las conclusiones que los objetivos planteados fueron
alcanzados y que el producto desarrollado cumple con los requerimientos, funcionales de la
empresa.
ABSTRACT
The development of a web system resulted in a detachment of many ideas to see technology
advance the impact on companies, it is not an easy task unless they are a worker or exclusive
expert of the entity to obtain and process data we see in Bolivia that the various companies
do not all maintain a development of use of updated technologies, but it should be noted that
they go step by step by utilitarian need optimizing time with the use of technologies.
The purpose of this project is to support the MAYA pharmacy, through the implementation of
the integrated web system that will control the purchase, sale and inventory of medicines.
The Scrum agile methodology was used for the development of the project, which proposes
an incremental process model, based on continuous iteration and revisions. In each iteration
the WebML modeling language was used, which is oriented to the development of web
systems. After each iteration and at the end of the project, the corresponding tests were
carried out to guarantee the safety and quality of the web system developed.
The software obtained is a quality product according to the methodology of quality evaluation
of WEB-SITE QEM systems.
Finally, it can be shown in the conclusions that the proposed objectives were achieved and
that the product developed meets the functional requirements of the company.
INDICE
CAPÍTULO I MARCO INTRODUCTORIO

1.1. INTRODUCCIÓN ....................................................................................................................... 1
1.2. ANTECEDENTES ....................................................................................................................... 2
1.2.1. ANTECEDENTES INSTITUCIONALES................................................................................ 2
1.3. PLANTEAMIENTO DEL PROBLEMA ..................................................................................... 5
1.3.1. PROBLEMA CENTRAL .......................................................................................................... 5
1.3.2. PROBLEMAS SECUNDARIOS .............................................................................................. 6
1.4. DEFINICIÓN DE OBJETIVOS .................................................................................................. 6
1.4.1. OBJETIVO GENERAL ............................................................................................................ 6
1.4.2. OBJETIVOS ESPECÍFICOS .................................................................................................... 6
1.5. JUSTIFICACIÓN ........................................................................................................................ 7
1.5.1. JUSTIFICACIÓN ECONÓMICA ............................................................................................ 7
1.5.2. JUSTIFICACIÓN SOCIAL ...................................................................................................... 7
1.5.3. JUSTIFICACIÓN TECNOLÓGICA ........................................................................................ 8
1.6. ALCANCES Y LÍMITES ............................................................................................................ 8
1.6.1. ALCANCES .............................................................................................................................. 8
1.6.2. LÍMITES ................................................................................................................................... 9
1.7. APORTES .................................................................................................................................. 10
1.7.1. PRÁCTICO ............................................................................................................................. 10
1.7.2. TEÓRICO ............................................................................................................................... 10
1.8. METODOLOGÍA ...................................................................................................................... 10
CAPITULO II MARCO TEÓRICO
2.1. INGENIERÍA DE SOFTWARE ................................................................................................ 12
2.2. METODOLOGÍA DE DESARROLLO ÁGIL .......................................................................... 12
2.3. MODELOS DE PROCESOS DE SOFTWARE ........................................................................ 13
2.3.1. MODELOS TRADICIONALES ............................................................................................. 13
2.3.2. MODELOS EVOLUTIVOS ................................................................................................... 14
2.3.3. MODELOS PARA SISTEMAS ORIENTADOS A OBJETOS ............................................. 14
2.4. METODOLOGÍA SCRUM ....................................................................................................... 15
ii
2.4.1. ELEMENTOS DE SCRUM .................................................................................................... 16
2.4.2. ROLES Y RESPONSABILIDADES ...................................................................................... 16
2.4.2.1. PRODUCT OWNER............................................................................................................ 16
2.4.2.2. SCRUM MASTER ............................................................................................................... 17
2.4.2.3. SCRUM TEAM ................................................................................................................... 17
2.4.3. HERRAMIENTAS DE LA METODOLOGÍA ...................................................................... 17
2.4.3.1. PRODUCT BACKLOG ....................................................................................................... 17
2.4.3.2. SPRINT BACKLOG ............................................................................................................ 18
2.4.4. FASES DEL PROCESO SCRUM .......................................................................................... 19
2.4.4.1. PRE – GAME ....................................................................................................................... 20
2.4.4.2. GAME .................................................................................................................................. 20
2.4.4.3. POST – GAME .................................................................................................................... 21
2.5. INGENIERÍA WEB ................................................................................................................... 21
2.5.1. DEFINICIÓN DE APLICACIÓN WEB ................................................................................. 21
2.5.2. CARACTERÍSTICAS DE APLICACIONES WEB .............................................................. 22
2.5.3. WEBML (WEB MODELING LANGUAJE) ......................................................................... 22
2.5.3.1. DISEÑO EN WEBML ......................................................................................................... 23
2.5.3.2. CARACTERÍSTICAS WEBML.......................................................................................... 27
2.5.3.3. OBJETIVOS PRINCIPALES DE WEBML ........................................................................ 27
2.5.3.4. EL DESARROLLO EN WEBML ....................................................................................... 28
2.6. CONTROL DE VENTAS Y CONTROL DE INVENTARIOS ................................................ 28
2.6.1 INVENTARIO ......................................................................................................................... 28
2.6.2 VENTAS .................................................................................................................................. 29
2.7. TECNOLOGÍA DE SOFTWARE ............................................................................................. 30
2.7.1. SERVIDOR DE BASE DE DATOS “MySQL” ..................................................................... 30
2.7.2. SISTEMA DE GESTIÓN DE BASE DE DATOS (SGBD) ................................................... 30
2.7.3. LENGUAJE DE PROGRAMACIÓN “PHP” ......................................................................... 30
2.7.4. ENTORNO DE DESARROLLO “LARAGON” .................................................................... 31
2.7.5. FRAMEWORKS “LARAVEL” ............................................................................................. 31
CAPÍTULO III MARCO APLICATIVO
3.1. INTRODUCCIÓN ..................................................................................................................... 32
iii
3.2. PRE GAME ................................................................................................................................ 33
3.2.1 RECOPILACIÓN DE REQUERIMIENTOS .......................................................................... 33
3.2.2 PILA DEL PRODUCTO .......................................................................................................... 33
3.2.3 DEFINICIÓN DE CRONOGRAMA DE TRABAJO .............................................................. 35
3.2.4 ANÁLISIS DE RIESGOS ........................................................................................................ 35
3.2.5. HERRAMIENTAS PARA EL DESARROLLO DEL SISTEMA .......................................... 36
3.3 GAME ......................................................................................................................................... 37
3.3.1 PRIMER SPRINT .................................................................................................................... 37
3.3.1.1 HISTORIAS DE USUARIO ................................................................................................. 38
3.3.1.2. MODELO ENTIDAD RELACIÓN ..................................................................................... 45
3.3.1.3. MODELO ESTRUCTURAL ............................................................................................... 46
3.3.1.4. MODELO DE HIPERTEXTO ............................................................................................. 47
3.3.1.5. MODELO DE PRESENTACIÓN ....................................................................................... 48
3.3.16 DESARROLLO DEL PRIMER SPRINT .............................................................................. 50
3.3.2. SEGUNDO SPRINT ............................................................................................................... 52
3.3.2.3 DESARROLLO DEL SEGUNDO SPRINT ......................................................................... 55
3.3.3. TERCER SPRINT ................................................................................................................... 57
3.3.3.3 DESARROLLO DEL TERCER SPRINT ............................................................................. 59
3.4. POSTGAME .............................................................................................................................. 61
3.4.1. ROLES Y RESPONSABILIDADES DE USUARIOS ........................................................... 61
3.5. FASES DE PRUEBAS............................................................................................................... 61
3.5.1 PRUEBAS DE ACEPTACIÓN ............................................................................................... 61
3.5.2 PRUEBA DE STRESS............................................................................................................. 64
CAPÍTULO IV CALIDAD Y SEGURIDAD
4.1. CALIDAD DE SOFTWARE ..................................................................................................... 67
4.2 WEBSITE QEM .......................................................................................................................... 67
4.2.1 ESPECIFICACIÓN DE CARACTERÍSTICAS DE CALIDAD DE QEM ............................. 68
iv
4.2.1.1 USABILIDAD ...................................................................................................................... 68
4.2.1.2 FUNCIONALIDAD .............................................................................................................. 71
4.2.1.3 CONFIABILIDAD................................................................................................................ 73
4.2.1.4 EFICIENCIA ......................................................................................................................... 74
4.3 RESULTADOS ........................................................................................................................... 75
4.4 FACTORES DE SEGURIDAD .................................................................................................. 76
4.4.1 A NIVEL BASE DE DATOS .................................................................................................. 76
4.4.2 SEGURIDAD DE BASE DE DATOS ..................................................................................... 76
4.4.3 SEGURIDAD CON AUTENTIFICACIÓN ............................................................................ 77
4.4.3.1 ALGORITMO MD5 ............................................................................................................. 77
4.4.3.2 APLICACIÓN DE ALGORITMO MD5 .............................................................................. 77
4.5 SEGURIDAD DE LA APLICACIÓN ........................................................................................ 78
4.5.1 CONFIDENCIALIDAD .......................................................................................................... 78
4.5.2 AUTENTICACIÓN Y AUTORIZACIÓN .............................................................................. 78
4.5.3 SEGURIDAD EN FORMULARIOS ....................................................................................... 78
CAPÍTULO V COSTO Y BENEFICIO
5.1 INTRODUCCIÓN ...................................................................................................................... 80
5.1.1 COCOMO II............................................................................................................................. 80
5.2 COSTO DEL SISTEMA ............................................................................................................. 82
5.2.1 COSTO DE DESARROLLO DEL SOFTWARE .................................................................... 82
5.2.2 COSTO DE IMPLEMENTACIÓN.......................................................................................... 85
5.2.3 COSTO DE ELABORACIÓN DEL PROYECTO .................................................................. 85
5.2.4 COSTO TOTAL DEL SOFTWARE ....................................................................................... 85
5.3 VALOR ACTUAL NETO .......................................................................................................... 86
5.4 TASA INTERNA DE RETORNO .............................................................................................. 88
CAPÍTULO VI CONCLUSIONES Y RECOMENDACIONES
6.1 CONCLUSIONES ...................................................................................................................... 90
6.2 RECOMENDACIONES ............................................................................................................. 90
BIBLIOGRAFÍA ............................................................................................................................. 92
ANEXOS .......................................................................................................................................... 95
v
ÍNDICE DE FIGURAS
CAPÍTULO II MARCO TEÓRICO
Figura 2. 1 Producto Backlog de SCRUM ........................................................................................ 18

Figura 2. 2 Sprint Backlog de SCRUM ............................................................................................. 19
Figura 2. 3 WebML conceptos básicos ............................................................................................. 23
Figura 2. 4 WebML: Modelado de Datos.......................................................................................... 24
Figura 2. 5 Modelo de Hipertexto ..................................................................................................... 25
Figura 3. 1 Panificación de implementación del sistema .................................................................. 32

Figura 3. 2 Figura 3. 2 Arquitectura del Sistema .............................................................................. 36
Figura 3. 3 Modelo entidad relación ................................................................................................. 45
Figura 3. 4 Modelo estructural .......................................................................................................... 46
Figura 3. 5 Diagrama de composición - ABM de Medicamentos ..................................................... 47
Figura 3. 6 Diagrama de composición - ABM de Usuarios .............................................................. 47
Figura 3. 7 Modelo de presentación de registro de Medicamento .................................................... 48
Figura 3. 8 Modelo de presentación de inicio de sesión ................................................................... 48
Figura 3. 9 Modelo de presentación de ingreso del Sistema ............................................................. 49
Figura 3. 10 Modelo de presentación de registro de usuarios ........................................................... 49
Figura 3. 11 Inicio se sesión del Sistema .......................................................................................... 50
Figura 3. 12 ABM de Medicamentos ................................................................................................ 51
Figura 3. 13 ABM de usuarios .......................................................................................................... 51
Figura 3. 14 Diagrama de componente - ABM de Proveedor ........................................................... 53
Figura 3. 15 Diagrama de componente - Lista de medicamentos por Sucursal ............................... 53
Figura 3. 16 Modelo de presentación de registro de proveedores ..................................................... 54
Figura 3. 17 Modelo de presentación de registro de sucursales ........................................................ 54
Figura 3. 18 Modelo de presentación de registro de permisos .......................................................... 55
Figura 3. 19 ABM de proveedores .................................................................................................... 55
Figura 3. 20 ABM de Sucursales ...................................................................................................... 56
Figura 3. 21 Registro de permisos ..................................................................................................... 56
Figura 3. 22 Diagrama de componentes – Registro de Venta ........................................................... 58
Figura 3. 23 Diagrama de componentes – Registro de Compra ........................................................ 58
Figura 3. 24 Modelo de registro de facturas ...................................................................................... 59
Figura 3. 25 Registro de facturas ...................................................................................................... 59
Figura 3. 26 Registro de compras al proveedor................................................................................. 60
Figura 3. 27 Stock de Medicamentos ................................................................................................ 60
vi
ÍNDICE DE TABLAS
CAPÍTULO II MARCO TEÓRICO
Tabla 2. 1 Elementos del modelo de hipertexto WebML .................................................................. 27
Tabla 3. 1 Pila del Producto .............................................................................................................. 34

Tabla 3. 2. Análisis de riesgos........................................................................................................... 36
Tabla 3. 3 Primera iteración del o primer sprint............................................................................... 38
Tabla 3. 4. Registro de usuarios ........................................................................................................ 39
Tabla 3. 5 Registro de proveedor ...................................................................................................... 39
Tabla 3. 6. Registro de Medicamento ............................................................................................... 39
Tabla 3. 7. Venta de medicamentos .................................................................................................. 40
Tabla 3. 8. Informes de la farmacia ................................................................................................... 40
Tabla 3. 9 Registro de medicamento ................................................................................................. 41
Tabla 3. 10 ABM de los Medicamentos ............................................................................................ 41
Tabla 3. 11 Autentificación de usuario. ............................................................................................ 41
Tabla 3. 12 Administración de Proveedores ..................................................................................... 42
Tabla 3. 13 Registro de ventas .......................................................................................................... 42
Tabla 3. 14 Reporte de ventas ........................................................................................................... 42
Tabla 3. 15 Administración de clientes ............................................................................................. 42
Tabla 3. 16 Registro de compras ....................................................................................................... 43
Tabla 3. 17 Administración de compras sucursales .......................................................................... 43
Tabla 3. 18 Reporte de ventas por sucursales .................................................................................. 43
Tabla 3. 19 Alertas de stock de medicamentos ................................................................................ 44
Tabla 3. 20 Administración de roles ................................................................................................. 44
Tabla 3. 21 Administración de usuarios ............................................................................................ 44
Tabla 3. 22 Tercer iteración del o tercer sprint ............................................................................... 57
Tabla 3. 23 Roles y descripción delos usuarios................................................................................. 61
Tabla 3. 24 Verificación de administración de usuarios ................................................................... 62
Tabla 3. 25 Verificación de administración de ventas ...................................................................... 63
Tabla 3. 26 Verificación de administración de compras ................................................................... 63
Tabla 3. 27 Verificación de administración de medicamentos......................................................... 63
CAPÍTULO IV CALIDAD Y SEGURIDAD

Tabla 4. 1 WebSiteQEM: Evaluación de comprensibilidad .............................................................. 69
vii
Tabla 4. 2 WebSiteQEM: Evaluación de mecanismos de ayuda ...................................................... 70
Tabla 4. 3 WebSiteQEM: Evaluación de aspectos de interfaz .......................................................... 70
Tabla 4. 4 WebSiteQEM: Evaluaciones misceláneas de usabilidad ................................................. 71
Tabla 4. 5 WebSiteQEM: Evaluación total de usabilidad ................................................................. 71
Tabla 4. 6 WebSiteQEM: Evaluación de búsqueda y recuperación .................................................. 72
Tabla 4. 7 WebSiteQEM: Evaluación de aspectos de navegación y exploración ............................. 72
Tabla 4. 8 WebSiteQEM: Evaluación de dominio orientado al Usuario .......................................... 73
Tabla 4. 9 WebSiteQEM: Evaluación total de funcionalidad ........................................................... 73
Tabla 4. 10 WebSiteQEM: Evaluación de confiabilidad ................................................................. 74
Tabla 4. 11 WebSiteQEM: Evaluación de desempeño ..................................................................... 74
Tabla 4. 12 WebSiteQEM: Evaluación de accesibilidad .................................................................. 75
Tabla 4. 13 WebSiteQEM: Evaluación total de eficiencia ................................................................ 75
Tabla 4. 14 WebSiteQEM: Evaluación de total de calidad ............................................................... 75
CAPÍTULO V ANÁLISIS DE COSTOS Y BENEFICIOS

Tabla 5. 1 Coeficiente a y c y los exponentes b y d .......................................................................... 81
Tabla 5. 2 Punto función ................................................................................................................... 82
Tabla 5. 3 Conversión de puntos de función siguiente...................................................................... 83
Tabla 5. 4 Costos de elaboración del Proyecto ................................................................................. 85
Tabla 5. 5 Costo total de producto de software ................................................................................. 86
Tabla 5. 6 Calculo VAN .................................................................................................................... 87
Tabla 5. 7 Interpretación del VAN .................................................................................................... 87
Tabla 5. 8 Calculo de la tasa interna de retorno ................................................................................ 89
viii
CAPÍTULO I
MARCO INTRODUCTORIO
1.1. INTRODUCCIÓN
Hoy en día, la informática se ha convertido en un factor importante de toda empresa, ya sea

mediana o grande por la razón principal que implica la cantidad de información que
actualmente se maneja, hace que el tratamiento automático de la información sea realmente
útil y necesario.
En la actualidad los sistemas de información están basados en computadoras que son objetos
de gran consideración en la toma de decisiones oportunas, confiables y efectivas en cuanto a
técnicas de planificación, programación y administración con el fin de garantizar su éxito,
limitar el riesgo y reducir costos y aumentar las ganancias (Peña, 2007).
Los procesos de compra y venta son realizados de forma manual y con ayuda de herramientas
ofimáticas las cuales resultan insuficientes ante las necesidades de la farmacia. La cantidad
de información sobre las compras mensuales, las ventas diarias y fechas de vencimiento de
medicamentos, es imposible llevar un buen control al respecto y la pérdida de información
se presenta con frecuencia estas situaciones. Es por esta forma de procesar la información,
que la farmacia tiene muchos problemas y dificultades al momento de la toma de decisiones.
Al no contar con información de las ventas totales mensuales, los productos más vendidos o
los productos que ya se agotaron, se retrasaban los pedidos y compras en perjuicio de los
proveedores, ocasionando demoras a las demandas y exigencias de sus clientes. También, en
ocasiones, los medicamentos se extravían y no se tiene control de cuantos medicamentos se
pierde. Asimismo, los procesos de venta son lentos en “horas pico”, es decir, cuando hay
mucha clientela que requiere atención, por el hecho de que no se cuenta con información
instantánea de la disponibilidad de algún medicamento.
Mediante el presente proyecto se dará una solución a los problemas que presenta la farmacia
Maya en el manejo de información de las compras, ventas, inventarios, desarrollando un
sistema integrado de control de compra, venta e inventarios de medicamentos, de manera
que, al momento de realizar la toma de decisiones, el propietario cuente con información
clara, precisa, actualizada e instantánea para, de esta forma, satisfacer la demanda de sus
clientes.
Además, el sistema agiliza la obtención de reportes de ventas mensuales, al mismo tiempo,

el propio proceso de ventas del negocio, brindándose un servicio más ágil al cliente, haciendo
más rápida la verificación de disponibilidad de productos.
1.2. ANTECEDENTES
1.2.1. ANTECEDENTES INSTITUCIONALES

La farmacia Maya, empieza su funcionamiento en la década de noventa a cargo del Dr.
Jimmy Henry Herrera Paredes.
El año 1992 se logra la resolución secretarial de Funcionamiento y apertura por parte del
Ministerio dela resolución que lleva el Nº 0484.
Farmacias Maya fue fundada en primero de junio de 1992, se encuentra ubicada en la Av.
Tiahuanaco N° 70 zona Sagrado Corazón de Jesús en la ciudad de El Alto, además cuenta
con N° NIT 2289620015, es una empresa privada, con patrimonio independiente.
La farmacia además de realizar las ventas de medicamentos, realiza otras actividades extras
como de inyectado y curaciones.
El objetivo principal de la Farmacias Maya es brindar una buena atención a los clientes sin
demora alguna.
La administración de la farmacia Maya depende del uso de herramientas ofimáticas para el

manejo de la información de sus ventas, compras, inventarios por supuesto esto no cubre las
2
necesidades de la empresa pues se lo realiza de manera manual, sin un adecuado control del
ingreso y salida de productos del inventario.
Al momento de hacer compras a sus proveedores, la verificación de la existencia de los

productos implica demora y un arduo trabajo al identificarlos en extensas listas de detalle de
la factura, ya que esto también se realizaba de forma manual (Dr. Herrera, 2019)
MISION Y VISION
MISION. - Garantizar la atención integral, integrada y continua de las necesidades y

problemas de salud de la población, tanto individual como colectiva, teniendo al
medicamento como uno de los elementos esenciales, contribuyendo a su acceso equitativo y
uso racional.
VISION. - Servicios Farmacéuticos, con atención integral e integrada al Sistema de Salud,

comprometidos con el logro de resultados en salud que respondan a las necesidades del
individuo, la familia y la comunidad, promoviendo el acceso, el uso racional de
medicamentos y la promoción recuperación y preservación de la salud.
OBJETIVOS
 Brindar atención primaria la comunidad poblacional y el manejo óptimo, racional y

eficiente de los medicamentos en los servicios de la salud.
 Dispensación y preparación de medicamentos esenciales de calidad eficaces seguros
y de costo de acuerdo al ámbito de los problemas de salud más prevalentes desde el
punto de vista epidemiológico, clínico y terapéutico.
Los servicios ofrecidos por la farmacia, a partir de un diagnóstico adecuado y una

prescripción médica, para lo cual cuenta con medicamentos esenciales genéricos y de marca
nacionales e importados de calidad, seguros incluyendo el uso racional de medicamentos.
3
Las personas auxiliares de apoyo tienen conocimientos de la farmacología, nombres
genéricos, concentraciones, indicaciones sobre la forma de administración.
1.2.2. ANTECEDENTES DE PROYECTOS SIMILARES
En la carrera de Informática de la Universidad Mayor de San Andrés (U.M.S.A.) se verificó

la existencia de proyectos de grado relacionados con el sistema de control de compras, ventas
e inventario, dichos proyectos están orientados a la automatización de los procesos manuales.
Se verificó los siguientes proyectos de grado:
 Título: Sistema web de control de compras, ventas e inventarios y verificación de

temperatura de medicamentos usando RFID y alarmas tempranas caso: “farmacias la
casa de salud”
Autor: Quelca Quispe Vladimir.
Año: 2016.
Institución: Carrera de Informática, UMSA
Descripción: El sistema informatiza los procesos de compra, venta e inventarios y
hace la verificación de temperatura de la Farmacia, brindando un control adecuado
de los procesos. Este proyecto fue realizado con el modelo de desarrollo de
metodología ágil XP, y complementada con el diseño IFML basado en WebML.
 Título: Sistema web de control de inventarios, manufacturación y producto final

para la empresa industrial comercial de alimentos Incadex s.r.l.” caso: Incadex s.r.
autor: Mendoza roque Mónica Carmen.
año: 2016.
institución: carrera de informática, UMSA
descripción: el sistema controla, manufactura proceso de elaboración de materia
prima. este proyecto fue realizado bajo la metodología ágil de SCRUM y la
metodología de diseño web UWE.
4
 Título: Sistema web de control de compra, venta e inventarios, caso: librería de la
asociación cristiana pan de vida.
Autor: Condori Palomeque Raquel.
Año: 2015.
Descripción: El sistema informatiza los procesos de compra, venta e inventarios de
la librería, con adecuado control de procesos. Esté proyecto fue realizado con la
metodología de desarrollo ágil XP, y se complementó con la fase de diseño de IFML
para el diseño de las funciones y la interfaz del usuario.
 Título: Sistema de control de ventas e inventarios para almacenes de aluminios
utilizando dispositivos móviles caso: técnica de aluminio, vidrio y servicios (talviser).
Autor: Gutiérrez Vargas Grover.
Año: 2015.
Descripción: El sistema automatiza los procesos y optimiza los tiempos de
producción de la empresa, este proyecto fue realizado con la metodología SCRUM,
que propone un modelo y aplicación Web.
1.3. PLANTEAMIENTO DEL PROBLEMA
1.3.1. PROBLEMA CENTRAL

En farmacia Maya no cuenta con un sistema de control de procesos de compra, venta e
inventarios de medicamentos, la farmacia maneja gran cantidad de información del registro
del ingreso y salida, los informes se lo realizan de forma manual, lo cual implica pérdida de
tiempo, registro erróneo, lo cual tiene como consecuencia pérdidas económicas y de los
clientes.
¿Cómo agilizar los procesos de compra, venta e inventarios de medicamentos para la

farmacia Maya?
5
1.3.2. PROBLEMAS SECUNDARIOS
 Pérdida de tiempo al hacer la verificación de la existencia del medicamento, el
farmacéutico tiene que verificar si el producto está disponible, esto causa molestias
al cliente por la espera del medicamento solicitado al farmacéutico.
 Retraso en la elaboración de reportes sobre las ventas y compras mensuales, esto
causa malas decisiones para la realización de compras a los proveedores.
 Los informes del inventario son anotados con la ayuda de herramientas ofimáticas,
tarda al momento de imprimir y con errores, esto causa confusión de que
medicamento se debe pedir al proveedor.
 El control manual de las compras a los proveedores es moroso y lento, lo cual causa
demoras en la entrega de medicamentos y errores en los pedidos de medicamento.
 El abastecimiento de medicamentos no es preciso, lo cual causa pérdidas económicas
al farmacéutico al no tener el control del stock de los medicamentos.
 Se emplea mucho tiempo en la consulta de manuales para conocer las características
y funciones de los medicamentos, lo cual puede causar que le dé un medicamento
erróneo al cliente.
1.4. DEFINICIÓN DE OBJETIVOS
1.4.1. OBJETIVO GENERAL

Desarrollar e implementar un sistema integrado web de control de compra, venta e
inventarios de medicamentos, para reducir el tiempo de atención a los clientes y generar
información de los medicamentos, para ayudar en la toma de decisiones para la farmacia
Maya, la cual será dinámica y de fácil uso.
1.4.2. OBJETIVOS ESPECÍFICOS

 Reducir el tiempo de atención al cliente.
 Verificar la existencia de los medicamentos.
 Obtener reportes de las ventas y compras.
6
 Reducir errores en los informes del inventario de medicamentos.
 Controlar compras a los proveedores, así corregir los errores de pedido delos
medicamentos.
 Brindar información del abastecimiento de medicamentos para la toma de decisiones.
 Facilitar el manejo de la administración de datos.
1.5. JUSTIFICACIÓN
1.5.1. JUSTIFICACIÓN ECONÓMICA

El sistema a desarrollar es económicamente justificable, debido a que permitirá al
farmacéutico ejercer mayor control de los procesos de ventas e inventarios, reduciendo de
esta manera el tiempo en procesos sencillos como la búsqueda de medicamentos, lo que
implica un ahorro económico.
En el desarrollo del sistema se empleará herramientas que sustituirán los procesos realizados
con herramientas ofimáticas como ser plantillas en Excel y manuales que generan un costo
innecesario a la farmacia.
A su vez beneficiara al farmacéutico en la mejora de sus actividades cotidianas respecto a la

sistematización de sus inventarios, en la elaboración de plantillas de ventas y control de los
medicamentos.
Se espera que este proyecto permita minimizar el tiempo de trabajo para el farmacéutico de
la empresa mencionada anteriormente, así lograr mayor eficiencia con la incorporación de
tecnologías informáticas actualizadas.
1.5.2. JUSTIFICACIÓN SOCIAL

Al implementar el sistema integrado web permitirá mejorar las tareas de control y ventas,
proveerá al farmacéutico información actualizada de los medicamentos como el stock,
también le ofrecerá un mejor entorno de trabajo, comodidad laboral y podrá realizar sus
actividades con mayor facilidad, en cuanto a los clientes o consumidores serán beneficiados
con una atención sin tanta demora.
7
Este proyecto se justifica socialmente porque brindará una atención mejorada, apropiada y
sistematizada para las personas que vienen a adquirir los medicamentos que se venden en la
farmacia Maya.
1.5.3. JUSTIFICACIÓN TECNOLÓGICA

La tecnología es una herramienta indispensable para las empresas, instituciones o entidades
públicas y privadas, las cuales requieren manejar una gran cantidad de información
importante, para ello una institución debe contar con las herramientas y equipos necesarios.
El proyecto a desarrollar, se lo realizará por las necesidades que tiene la farmacia por no tener
un buen control de los medicamentos, así se optimizara los servicios que presta el mismo.
La farmacia Maya cuenta con dos equipos de computación, para la implementación del
sistema.
El sistema se lo realizara utilizando para la metodología ágil SCRUM y el modelado WebML.
1.6. ALCANCES Y LÍMITES
1.6.1. ALCANCES
El sistema tendrá los siguientes alcances:
 Módulo de compras
 Registros de compras realizadas a los proveedores, cantidad y precio.
 Editar compra.
 Eliminar compra.
 Módulo de ventas
 Cantidad de ventas realizadas
 Verificar disponibilidad del producto.
 emisión de reportes de stock
 Módulo de medicamentos
8
 registro de los medicamentos tomando en cuenta características como: código
de medicamento, nombre
 Eliminar medicamento.
 Editar medicamento.
 Reporte listado detallado de la información de los fármacos y su uso en
formato texto.
 Módulo administración de usuarios
Control de usuarios del sistema informático, permitiendo la asignación según las
prioridades con la que el usuario fue asignado.
 Módulo de proveedor
 Registra nuevo proveedor
 Editar la información del proveedor
 Eliminar proveedor
 Módulo de inventarios
 Tener información de las ventas
 Reportes de medicamentos más vendidos.
1.6.2. LÍMITES
El presente proyecto de grado estará limitado a las siguientes características:
 El sistema será utilizado solo por el personal de la farmacia Maya.

 Las funciones de actualización de datos de los medicamentos, registros de
proveedores, información de las ventas, serán realizadas por la asignación de
permisos a usuarios dados por el administrador.
 El sistema estará conformado por la implementación del proceso de registro, ingreso,
salidas de medicamentos y reportes de stock.
9
1.7. APORTES
1.7.1. PRÁCTICO
El sistema integrado web ayudará a la farmacia a realizar mayor control de ventas de los
medicamentos que salen, para así saber si es necesario realizar más pedidos de los
medicamentos a los proveedores, así también saber qué personas hicieron entrega de los
mismos.
El desarrollo del sistema permitirá cubrir las necesidades para organizar los procesos
rutinarios, como disminuir el tiempo de atención al cliente, ayudar en el control y en el
seguimiento de los medicamentos, generando información que ayude para la fácil y correcta
toma de decisiones en la farmacia.
1.7.2. TEÓRICO
Para el desarrollo de este proyecto se diseñará un sistema web, para la implementación se

acoplarán dos metodologías: Metodología Scrum para el desarrollo del sistema web para
garantizar el desarrollo eficiente del proyecto y se aplicara WebML, que es un lenguaje de
modelado orientado a aplicaciones Web.
El aporte del presente proyecto es utilizar una metodología para brindar servicio, que permita
el seguimiento y control de los movimientos de ventas e inventarios de manera precisa para
la toma de decisiones.
1.8. METODOLOGÍA
En la investigación se trabajará con el enfoque cualitativo para estudiar la realidad en su
contexto natural y para obtener requerimientos del problema mediante la observación directa
de los procesos que se lleva a cabo, entrevistas, reuniones con el personal encargado.
La investigación exploratoria se utilizará para el acercamiento al problema y para la

recopilación de la información de las condiciones favorables, para luego pasar a la
10
investigación descriptiva para llegar a describir las características internas, externas de los
hechos observados.
En la investigación se trabajará con el enfoque inductivo para la observación de los hechos,

premisas y finalmente llegar a una generalización o conclusión.
Para el desarrollo del proyecto se empleará la metodología ágil de desarrollo de software

SCRUM, porque nos permitirá realizar de manera ordenada la organización de los trabajos,
dividiendo en tareas para que el proyecto pueda terminarse en un determinado tiempo.
Para el modelado se utilizará la metodología web: webML que permitirá modelar la

aplicación Web, webML trabaja con herramientas de UML para esto se utilizará una
herramienta de software como el Enterprise Architect para construir y modelar con mayor
facilidad.
Para la implementación de este proyecto se utilizará las siguientes herramientas tecnológicas:

plataforma Windows, lenguaje de programación PHP, sistema gestor de base de datos
MySQL además de otras herramientas necesarias para el diseño e implementación del
sistema web.
Para el entorno de desarrollo se utilizará LARAGON para trabajar de una manera sencilla y
rápida y con poca configuración.
11
CAPÍTULO II
MARCO TEÓRICO
2.1. INGENIERÍA DE SOFTWARE
El software para muchas personas es solo programas de computadora, sin embargo, nos
comenta que son todos aquellos documentos asociados a la configuración de datos que se
necesitan para hacer que estos programas operen de manera adecuada. Estos productos de
software se desarrollan para algún cliente en particular o para un mercado en general. Para el
diseño y desarrollo de proyectos de software se aplican metodologías, modelos y técnicas
que permiten resolver los problemas. En los años 50 no existían metodologías de desarrollo,
el desarrollo estaba a cargo de los propios programadores. De ahí la importancia de contar
con analistas y diseñadores que permitieran un análisis adecuado de las necesidades que se
deberían de implementar (Sommerville , 2005).
El objetivo principal que busca la ingeniería de software es convertir el desarrollo de software

en un proceso formal, con resultados predecibles, que permitan obtener un producto final de
alta calidad y satisfaga las necesidades y expectativas del cliente. La Ingeniería de Software
es un proceso intensivo de conocimiento, que abarca la captura de requerimientos, diseño,
desarrollo, prueba, implantación y mantenimiento. Generalmente a partir de un complejo
esquema de comunicación en el que interactúan usuarios y desarrolladores, el usuario brinda
una concepción de la funcionalidad esperada y el desarrollador especifica esta funcionalidad
a partir de esta primera concepción mediante aproximaciones sucesivas. Este ambiente de
interacción motiva la búsqueda de estrategias robustas para garantizar que los requisitos del
usuario serán descubiertos con precisión y que además serán expresados en una forma
correcta y sin ambigüedad, que sea verificable, trazable y modificable (Gacitúa, 2003).
2.2. METODOLOGÍA DE DESARROLLO ÁGIL

Los procesos ágiles de desarrollo de software, conocidos anteriormente como metodologías
livianas, intentan evitar los tortuosos y burocráticos caminos de las metodologías
tradicionales enfocándose en la gente y los resultados.
12
El software desarrollado en una unidad de tiempo es llamado una iteración, la cual debe durar
de una a cuatro semanas. Cada iteración del ciclo de vida incluye: planificación, análisis de
requerimientos, diseño, codificación, revisión y documentación. Una iteración no debe
agregar demasiada funcionalidad para justificar el lanzamiento del producto al mercado, pero
la meta es tener un demo (sin errores) al final de cada iteración. Al final de cada iteración el
equipo vuelve a evaluar las prioridades del proyecto (Páez, 2014).
2.3. MODELOS DE PROCESOS DE SOFTWARE
2.3.1. MODELOS TRADICIONALES
El modelo está formado por un conjunto de fases o actividades en las que no tienen en cuenta
la naturaleza evolutiva del software, las cuales son:
a) Ciclo de vida se le conoce como modelo lineal secuencia o modelo en cascada, plantea
un enfoque sistemático, secuencial para el desarrollo de software, que comienza en un nivel
de sistemas y continúa con el análisis, diseño, codificación, pruebas y mantenimiento. Este
modelo comprende una primera actividad como lo es la ingeniería y modelado de sistemas /
información, en el cual se establece el sistema de nivel superior y se deben establecer los
requisitos de la empresa en la que se encuentra. Los requisitos se recogen del sistema con
una pequeña parte de análisis y diseño.
b) Basado en prototipos este paradigma se inicia con la recolección de requerimientos. El

desarrollador y el cliente encuentran y definen los objetivos globales para el software,
identifican los requisitos conocidos y las áreas del esquema en donde es obligatoria más
definición, luego aparece un diseño rápido, el diseño rápido está centrado en una
representación de los aspectos del software que serán visibles para el usuario-cliente, el
diseño rápido lleva a la construcción de un prototipo.
El prototipo lo evalúa el cliente-usuario y lo utiliza para refinar los requisitos del software a
desarrollar. La interacción ocurre cuando el prototipo satisface las necesidades del cliente, a
la vez que permite que el desarrollador comprenda mejor lo que se necesita hacer.
13
c) Modelo DRA el desarrollo rápido de aplicaciones (DRA) es un modelo de proceso del
desarrollo del software lineal secuencial que enfatiza un ciclo de desarrollo extremadamente
corto, el modelo DRA es una adaptación a alta velocidad del modelo lineal secuencial en el
que se logra el desarrollo rápido utilizando un enfoque de construcción basado en
componentes.
2.3.2. MODELOS EVOLUTIVOS
El software al igual que todos los sistemas complejos va evoluciona con el tiempo,
desarrollando versiones cada vez más completas y complejas hasta llegar al objetivo deseado
incluso evolucionar más allá durante la fase de la operación.
Los modelos que se adaptan a la evolución son:
a) Modelo Espiral
b) Evolutivo
c) Incremental n
d) Modelo de desarrollo concurrente
2.3.3. MODELOS PARA SISTEMAS ORIENTADOS A OBJETOS
Es la construcción de modelos de un sistema por medio de la identificación y especificación

de un conjunto de objetos relacionados, que se comportan y colaboran entre sí de acuerdo a
los requerimientos establecidos para el sistema de objetos.
Son modelos con alto grado de interactividad y solapamiento entre fases, como ser:
a) De agrupamiento
b) Fuente
c) Basado en componentes
d) Proceso unificado
14
2.3.4. PROCESOS ÁGILES
Los elementos están compuestos por roles y artefactos quienes darán inicio para la
elaboración del SCRUM. Según el libro (SCRUMstudy, 2013).
Entre las metodologías ágiles identificadas son:
a) Extreme Programming (XP)

b) Scrum
c) Familia de Metodologías Crystal
d) Feature Driven Development
e) Proceso Unificado Rational, una configuración ágil
f) Dynamic Systems Development Method
g) Adaptive Software Development
h) Open Source Software Development
2.4. METODOLOGÍA SCRUM
Scrum es un marco de trabajo de procesos que ha sido usado para gestionar el desarrollo de
productos complejos desde principios de los años 90. Scrum no es un proceso o una técnica
para construir productos; en lugar de eso, es un marco de trabajo dentro del cual se pueden
emplear varias técnicas y procesos. Scrum muestra la eficacia relativa de las prácticas de
gestión de producto y las prácticas de desarrollo, de modo que podamos mejorar. El marco
de trabajo Scrum consiste en los Equipos Scrum, roles, eventos, artefactos y reglas asociadas.
Cada componente dentro del marco de trabajo sirve a un propósito específico y es esencial
para el éxito de Scrum y para su uso. Las reglas de Scrum relacionan los eventos, roles y
artefactos, gobernando las relaciones e interacciones entre ellos (Schwaber y Sutherland,
2013).
Sus principales características son:
a) Equipos auto dirigidos
15
b) Utiliza reglas para crear un entorno ágil de administración de proyectos
c) No prescribe prácticas específicas de ingeniería
d) Los requerimientos se capturan como ítems de la lista Product Backlog
e) El producto se construye en una serie de Sprints de un mes de duración
f) Gestión regular de las expectativas del cliente
2.4.1. ELEMENTOS DE SCRUM
Los elementos están compuestos por roles y artefactos quienes darán inicio para la
elaboración del SCRUM. Según el libro (SCRUMstudy, 2013).
2.4.2. ROLES Y RESPONSABILIDADES
Personas involucradas que tienen diferentes cargos en el momento de desarrollar el SCRUM.
2.4.2.1. PRODUCT OWNER
Según (Henrik Kniberg ,Mattias, 2010),el dueño de producto es el responsable de maximizar

el valor del producto y del trabajo del equipo de desarrollo. El cómo se lleva a cabo esto
podría variar ampliamente entre distintas organizaciones,el dueño de producto es la única
persona responsable de gestionar la lista del producto (Product Backlog). La gestión de la
lista del producto incluye:
 Expresar claramente los elementos de la Lista del Producto;

 Ordenar los elementos en la Lista del Producto para alcanzar los objetivos y misiones
de la mejor manera posible.
 Optimizar el valor del trabajo desempeñado por el Equipo de Desarrollo.
 Asegurar que la Lista del Producto es visible, transparente y clara para todos, y que
muestra aquello en lo que el equipo trabajará a continuación.
 Asegurar que el Equipo de Desarrollo entiende los elementos de la Lista del Producto
al nivel necesario
16
2.4.2.2. SCRUM MASTER
Responsable del proceso SCRUM, de cumplir la meta y resolver los problemas. Así como
también, de asegurarse que el proyecto se lleve a cabo de acuerdo con las prácticas, valores
y reglas de SCRUM y que progrese según lo previsto (Palacios, 2008).
2.4.2.3. SCRUM TEAM

Lo que menciona (Skarin, 2010). El responsable de transformar el Backlog de la iteración en
un incremento de la funcionalidad del software, tiene autoridad para reorganizarse y definir
las acciones necesarias o sugerir remoción de impedimentos.
 Auto-gestionado
 Auto-organizado
 Multi-funcional
2.4.3. HERRAMIENTAS DE LA METODOLOGÍA
2.4.3.1. PRODUCT BACKLOG
Con los requerimientos priorizados y ordenados, armamos el backlog de producto,este es una

forma de registrar y organizar el trabajo pendiente para el producto (actividades y
requerimientos).
Es un documento dinámico que incorpora constantemente las necesidades del sistema. Por lo
tanto, nunca llega a ser una lista completa y definitiva. Se mantiene durante todo el ciclo de
vida (hasta la retirada del Sistema) y es responsabilidad del Product Owner (Schwaber,
Sutherland, 2013).
17
Figura 2. 1 Producto Backlog de SCRUM
Fuente: (Skarin, 2010)
2.4.3.2. SPRINT BACKLOG
El sprint backlog es la lista que descompone las funcionalidades del product backlog en las
tareas necesarias para construir un incremento: una parte completa y operativa del producto.
En el sprint backlog se asigna a cada tarea la persona que la va a llevar a cabo, y se indica el
tiempo de trabajo que se estima, aún falta para terminarla.
Es útil porque descompone el proyecto en tareas de tamaño adecuado para determinar el

avance a diario; e identificar riesgos y problemas sin necesidad de procesos complejos de
gestión. Es también una herramienta de soporte para la comunicación directa del equipo.
Un Sprint es el periodo de tiempo durante el que se desarrolla un incremento de

funcionalidad. Constituye el núcleo de SCRUM, que divide de esta forma el desarrollo de un
proyecto en un conjunto de pequeñas carreras (SCRUMstudy, 2010).
18
Figura 2. 2 Sprint Backlog de SCRUM
Fuente: (SCRUMstudy, 2010)
Duración máxima del Sprint: 30 días.
 Durante el Sprint no se puede modificar el trabajo que se ha acordado en el backlog.

 Sólo es posible cambiar el curso de un Sprint abortándolo, y sólo lo puede hacer el
SCRUM Master si decide que no es viable por alguna de las razones siguientes:
 La tecnología acordada no funciona.
 Las circunstancias del negocio han cambiado.
 El equipo ha tenido interferencias.
2.4.4. FASES DEL PROCESO SCRUM

Según (Palacios, Juan, 2008). Es una metodología ágil, está basada en iteración y revisiones.
El ciclo de vida de SCRUM está compuesto de tres fases que son el pre – Game, Game y el
post – Game.
19
2.4.4.1. PRE – GAME
Las tareas que se realizan en esta primera etapa son:
a) Planeación: Todos los miembros del equipo incluyendo el cliente se reúnen para
determinar el análisis del problema. En este paso se puede dividir las tareas en:
Recopilación: Donde se extrae los requerimientos para conformar el producto backlog,

priorizados de acuerdo al cliente y los usuarios que interactúan con el proyecto.
Análisis de riesgos y controles apropiados para los riesgos, la selección del tipo de
herramienta a trabajar, cálculo y la estimación del costo.
b) Arquitectura: El objetivo de esta etapa es diseñar como los elementos del backlog del
producto serán puestos en ejecución. Se revisa los ítems del backlog, el análisis y el tiempo
aproximado para terminar la tarea.
2.4.4.2. GAME
Una vez realizado el pre – Game se opta por realizar los siguientes puntos:
a) Planeación del Sprint: Antes de comenzar cada sprint, se lleva a cabo reuniones para
refinar y priorizar nuevamente el producto backlog luego pasara a ser un Sprint backlog con
las actividades realizadas, los responsables y la duración de cada actividad.
b) Desarrollo de Sprint: El trabajo generalmente se organiza en iteraciones de 2 a 3

semanas. El sprint es el desarrollo de la nueva funcionalidad del producto, esta fase provee
la siguiente documentación.
c) Revisión del Sprint: Al final de cada iteración se lleva a cabo una reunión de revisión en
donde se encuentra la nueva funcionalidad del producto, las metas incluyendo la información
de las funciones, diseño ventaja, inconvenientes y esfuerzo del equipo.
20
2.4.4.3. POST – GAME
La etapa final, denominada según SCRUM, es el cierre o Post – Game: En esta última etapa
se realiza la preparación operacional, incluyendo la documentación final necesaria para la
prestación.
Realizando las Pruebas de Rendimiento o Esfuerzo del Proyecto, también a esta etapa se debe
realizar dependiendo del tipo de producto las interfaces finales para el usuario y el
entrenamiento del Plantel (usuarios) o el marketing para la venta del nuevo producto.
2.5. INGENIERÍA WEB
La ingeniería web es la aplicación de metodologías sistemáticas, disciplinadas y

cuantificables de desarrollo eficiente, operación y evolución de aplicaciones de alta calidad
en la World Wide Web. La Ingeniería Web es una versión adaptada del enfoque de la
Ingeniería de Software que propone una estructura ágil, pero disciplinada, para construir
sistemas y aplicaciones basados en la web con calidad industrial (Pressman, 2008).
Este concepto implica la aplicación de metodologías sistemáticas, disciplinadas y

cuantificables al desarrollo eficiente de aplicaciones de alta calidad accesibles por Internet,
así como su operación y evolución (Jarquín, 2015).
2.5.1. DEFINICIÓN DE APLICACIÓN WEB
Una Aplicación Web (en lo sucesivo también denominada WebApp) es la forma en que se
denomina a una categoría de software centrada en redes y que agrupa una amplia gama de
aplicaciones diferentes a las conocidas como nativas. Son poco más que un conjunto de
archivos de hipertexto vinculados que presentan información con uso de texto y gráficas
limitadas. Están integradas con bases de datos corporativas y aplicaciones de negocios, desde
cierto punto de vista se considera como un esfuerzo multidisciplinario debido al manejo de
múltiples formatos, siendo susceptible de efectos éticos y legales. (Pressman, 2010).
21
2.5.2. CARACTERÍSTICAS DE APLICACIONES WEB
 Pueden ser ejecutadas en múltiples plataformas ya que no hacen uso del sistema
operat1ivo del terminal o equipo, sino del navegador implementado para su
ejecución.
 No se instalan en el dispositivo y consiguen una experiencia de operación muy similar
a una aplicación nativa, pero requieren conexión constante a Internet.
 La inversión de recursos para su desarrollo se realizará una sola vez para múltiples
plataformas, pero se deberá optimizar en cada una de ellas para obtener el mejor
rendimiento de cada ambiente.
 El diseño de interfaz está condicionado por necesidades de claridad y simplicidad
sobre la de impacto.
 Su funcionalidad puede variar desde navegación/consulta de ABMs hasta complejos
servicios transaccionales de comercio electrónico.
 Al igual que en la Ingeniería de Software, en la Ingeniería Web también se realizan
las denominadas Actividades CGC (de Control y Garantía de la Calidad) como el
establecimiento y supervisión de estándares, revisiones técnicas formales, análisis y
seguimiento/registro de informes, entre otros; sin embargo otros aspectos valorativos
que le son exclusivos están relacionados a criterios de usabilidad, funcionabilidad,
fiabilidad, seguridad, eficiencia y mantenibilidad, en el marco de la escalabilidad
(Olsina,1999)
2.5.3. WEBML (WEB MODELING LANGUAJE)
WebML es un lenguaje modelado de alto nivel para la especificación de aplicaciones web.

En esta aproximación, se propone la especificación de la aplicación Web en base a cuatro
perspectivas: modelo estructural, modelo del hipertexto, modelo de presentación y modelo
de personalización. Define también un proceso iterativo, con las siguientes etapas:
recolección de requisitos, diseño de datos, diseño de hipertexto, diseño de presentación,
diseño de usuarios y grupos y diseño de personalización. (Ceri y Piero, 2000).
22
WebML es un lenguaje de modelado gráfico utilizado para apoyar las actividades del diseño
de sitios Web. Provee gráficos, formalismos, especificaciones y diseño de procesos apoyados
por herramientas gráficas. Define varios tipos de diagramas: de estructura, composición y
navegación. (Carmona, 2008).
2.5.3.1. DISEÑO EN WEBML
El diseño de aplicaciones en WebML consiste en especificar sus características en términos

de varios tipos de abstracciones ortogonales, los cuáles son:
a) El modelo estructural
b) El modelo de hipertexto
c) El modelo de presentación
Una observación importante es el hecho de que WebML no es el mejor enfoque para sitios
Web estáticos (Ceri, 2000). Para entender sobre los modelos de desarrollo ver la figura 2.3.
Figura 2. 3 WebML conceptos básicos

Fuente: (Barraza, s.a)
23
a) Modelado de Estructural
El modelado de datos representa las diferentes tablas de datos y sus relaciones que son
necesarias para una aplicación Web concreta.
En el diagrama de estructura se definen las entidades o contenedores de datos y sus

relaciones, este diagrama expresa el contenido de un sitio Web en términos de entidades y
relaciones relevantes. El elemento fundamental del modelo de estructura son las entidades
(contenedores de datos) y las relaciones (conectores de entidades), las entidades deben tener
atributos con un tipo asociado y las relaciones deben tener una cardinalidad y un rol asociado.
En Imagen 8 se muestra un ejemplo de un diagrama de estructura, el cual consiste de cuatro
entidades Artist, Album, Review, Track y tres relaciones (Carmona, 2008).
Figura 2. 4 WebML: Modelado de Datos

Fuente: (Muñoz, s.a)
b) Modelado de Hipertexto
El modelo de hipertexto especifica el modelo de composición y el de navegación del sitio.

Cada hipertexto describe una vista del sitio.
24
 Modelo de composición: Describe las páginas que componen el hipertexto, y que
constituyen unidades de contenido de una página. La página del sitio Web son los
contenedores de información realmente entregados al lector.
 Modelado de navegación: Del sitio se especifica vínculos pasantes. Los enlaces
pueden ser definidos entre las unidades dentro de una misma página, entre las
unidades colocadas en diferentes páginas y entre las páginas.
Figura 2. 5 Modelo de Hipertexto

Fuente:( Muñoz, s.a.)
A pesar que WebML se creó inicialmente para el diseño de aplicaciones Web intensivas en
datos, esta es, sin duda, una de las metodologías que más esfuerzos de adaptación ha realizado
en la necesidad de dar soporte al desarrollo de aplicaciones orientadas a servicios. WebML
ha sido extendido para dar soporte al desarrollo de aplicaciones que integran, tantos servicios
Web, definiendo nuevas primitivas para la representación de estos en el modelo de hipertexto,
como también procesos de negocios, añadiendo para ello una nueva etapa de análisis de los
procesos y extendiendo el modelo estructural y de hipertexto para la captura de procesos.
(Brambilla y Butti, 2006).
WebML define un lenguaje propio y especifico de dominio para el diseño de aplicaciones

Web, y solo propone la utilización de un modelo de clases UML en la etapa del diseño
25
conceptual. Recientemente se ha definido un perfil UML para WebML, aunque este solo
incluye extensiones para la representación de las primitivas básicas de WebML (Moreno,
2006).
WebML está soportado por la herramienta de desarrollo WebRatio. dicha herramienta

permite el desarrollo dirigido por modelos de aplicación web, utilizando para ello lenguaje
WebML, y la generación de código compatible con la arquitectura J2EE a partir de tales
modelos. Aunque dicha herramienta utiliza principios de MDA, puesto que se basa en el
desarrollo dirigido por modelos y la generación de código automática. (Brambilla y Butti,
2006).
WebML no se define como una aproximación basada en MDA. WebML no distingue entre
modelos independientes o dependientes de plataforma ni tampoco se centra en la definición
de transformaciones entre los modelos que propone. Sin embargo, teniendo en cuenta las
características de los modelos propuestos por WebML se puede decir que estos coinciden
con el nivel independiente de plataforma de MDA (Brambilla y Butti, 2006).
 Elementos del modelo de hipertexto

La siguiente tabla muestra la simbología utilizada por los diseñadores para realizar el
diseño de hipertexto durante el proceso de modelado del sistema.
ELEMENTO DE WEBML DESCRIPCIÓN PROPIEDADES

Conjunto de atributos de la - Nombre
Data Unit Unidad instancia de alguna entidad - Entidad fuente
de Datos - Selector
- Atributos
MultidataUnit Conjunto de atributos de un - Nombre
(unidad de datos conjunto de instancias de - Entidad fuente
múltiple) entidades - Selector
- Atributos incluidos
- Cláusula de orden
IndexUnit Presenta un listado de instancias - Nombre
(Unidad Indice) de entidades a través de algún - Entidad fuente
atributo descriptivo, y permite - Selector
su selección. - Atributos incluidos
26
ScrollerUnit Permite la navegación entre un -Nombre
(unidad de conjunto ordenado de objetos -Entidad fuente
navegacion) -Selector
-Bloque de factores
-Cláusula de orden
Entryunit (Unidad de ingreso) Formulario para recolectar datos -Nombre
del usuario. -Para cada campo
-Entidad fuente
- Selector
-Atributos incluidos
Tabla 2. 1 Elementos del modelo de hipertexto WebML
Fuente: (Elaboración propia)
c) Modelo de presentación
Define como lucirá la vista del sitio. WebML incluye un modelo simple de presentación que
permite colocar contenidos dinámicos en la página además de aplicar estilos distintos para
cada uno.
2.5.3.2. CARACTERÍSTICAS WEBML
Las características según Barraza s.a. son las siguientes:
 Combina técnica de modelado ER con UML

 Se basa en la distribución de nodos en los niveles del hipertexto sobre las páginas del
nivel de presentación.
 Enlaces Intra-page cuando la fuente y destino están en la misma página (Ej.
Un resumen del paper en el primer caso de ejemplo).
 Enlaces Inter-page cuando la fuente y el destino están en diferentes páginas
(Ej. Información detallada del autor y de sus papers).
2.5.3.3. OBJETIVOS PRINCIPALES DE WEBML

Los objetivos según Barraza s.a. son las siguientes:
 Expresar la estructura de una aplicación.
27
 Proveer múltiples vistas del mismo contenido.
 Separar el contenido de la información de su composición en páginas, y navegación.
 Almacenar meta-información.
 Modelar usuarios y comunidades.
 Posibilitar la especificación de operaciones de manipulación de datos.
2.5.3.4. EL DESARROLLO EN WEBML
El ciclo de desarrollo de una aplicación Web se basa en un núcleo sólido de conceptos y

notaciones. El proceso de desarrollo en WebML consiste de diferentes fases incrementales,
que abarcan desde la recolección de requerimientos hasta la implementación, y que son
ejecutadas en forma iterativa. (Barraza, s.a).
2.6. CONTROL DE VENTAS Y CONTROL DE INVENTARIOS

En todas las actividades que traten con economía, el control de ventas e inventarios siempre
van combinados uno del otro, ya que dependen entre ellos.
2.6.1 INVENTARIO
Inventario se refiere a las existencias de un artículo o determinado recurso que está
almacenado y que espera ser usado por la organización. Un sistema de inventario es el
conjunto de políticas y controles que supervisa los niveles de inventario y determina cuáles
son los niveles que deben mantenerse, cuando hay que reabastecer el inventario y de qué
tamaño deben ser los pedidos (Mongua y Sandoval, 2009).
La necesidad de establecer un programa de entrega de materiales para evitar situaciones de

inactividad que repercutan negativamente en los costos de los factores productivos, hace
preciso realizar una discriminación de artículos con el fin de determinar de entre todos ellos
cuáles son los que, por sus características, precisan un control más riguroso. El inventario en
una empresa son las existencias que se destinan a la venta directa o destinada indirectamente
al proceso productivo. Los inventarios pueden ser definidos, como una provisión de
materiales, con el objetivo de facilitar la continuidad del proceso productivo y la facilitación
28
de los pedidos de consumidores y clientes, estos se representan e cualquier organización.
(Hernández, 2010)
En el ámbito comercial, el inventario se representa en un esquema de ventas donde se

registran las operaciones que se producen desde que el cliente efectúa un pedido a las
instalaciones hasta que se realiza su entrega. (Mongua y Sandoval, 2009).
o Se produce el pedido de uno o varios artículos a nuestras instalaciones

o Se verifica el pedido en las instalaciones, caso contrario de no existir, se pide
autorización para buscar en almacén
o Se acepta el pedido
o Se procesa la cancelación de dicho pedido
o Se recepciona el pedido por parte del cliente
En el esquema de aprovisionamiento, se realizan las siguientes operaciones que nos

permitirán abastecernos de material de ventas:
o Al notar la falta de algún material se solicita el abastecimiento al proveedor

o Se recepciona el pedido y se realiza el envío a los centros de venta y almacén
o Se contabiliza la cantidad que ingreso
2.6.2 VENTAS
Tiene múltiples definiciones dependiendo del contexto en el que se maneje. La venta es el

intercambio de servicios y productos. Es a su vez entendida como un contrato donde el sujeto
que actúa como vendedor transmite un derecho, bienes o servicios al comprador a cambio de
una determinada suma de dinero. La venta puede ser tanto un proceso personal como
impersonal donde el comprador puede ser influido por el vendedor. Desde el punto de vista
contable y financiero, la venta es el montón total cobrado por productos o servicios prestados.
En cualquier situación, las ventas son el corazón de cualquier negocio y actividad
fundamental (Arana, 2014).
29
La definición que se tomara es que las ventas es un cambio de productos y servicios por
dinero. Desde el punto de vista legal, se trata de la transferencia del derecho de posesión de
un bien a cambio de dinero.
2.6.2.1 CONTROL DE VENTAS
Este módulo permitirá realizar la gestión correspondiente a cotizaciones, pedidos, remisiones

y facturación de mercancía, venta de productos y servicios en diferentes unidades de medida.
2.7. TECNOLOGÍA DE SOFTWARE
El sistema operativo sobre la cual trabajara el software para poder desarrollar el Sistema Web
son los siguientes:
2.7.1. SERVIDOR DE BASE DE DATOS “MySQL”
Es un sistema de administración de Base de Datos (RDBMS). Entre las múltiples ventajas

que tiene tal vez la más importante es que es gratuito, y se puede destacar estabilidad,
seguridad, escalabilidad, es multiplataforma y sobre todo compatible con varios lenguajes de
programación.
2.7.2. SISTEMA DE GESTIÓN DE BASE DE DATOS (SGBD)
Los Sistemas de Gestión de Base de Datos (SGBD); (en inglés: Databasemanagementsystem,

abreviado DBMS) son un tipo de software muy específico, dedicado a servir de interfaz entre
la base de datos, el usuario y las aplicaciones que la utilizan.
2.7.3. LENGUAJE DE PROGRAMACIÓN “PHP”
PHP es un lenguaje de programación de uso general de script 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
30
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.
2.7.4. ENTORNO DE DESARROLLO “LARAGON”
Es un entorno de desarrollo para PHP que funciona sobre Windows diseñado especialmente
para trabajar con laravel. Similar a otras herramientas como xampp o wampp.
Es un entorno de desarrollo completo incluye PHP, MySQL, Node JS, Python, Java, Go,
Ruby, Apache, Nginx,entre otras tecnologías ,es ideal para crear proyectos con alto
rendimiento, estabilidad, simplicidad, flexibilidad y libertad.
2.7.5. FRAMEWORKS “LARAVEL”

Laravel es un framework de código abierto para desarrollar aplicaciones y servicios web.
31
CAPÍTULO III
MARCO APLICATIVO
3.1. INTRODUCCIÓN
Este capítulo se describirá el análisis y diseño del sistema guiándonos con la metodología de
trabajo SCRUM para el desarrollo del sistema integrado web de control de compra, venta e
inventarios de medicamentos para la farmacia maya, usando los pasos descritos en el marco
teórico.
Por ser el sistema orientado a la web se tomará en cuenta el modelado web, WebML, esto
nos ayudará en el diseño web con los distintos tipos de diagramas que usa, logrando un
entorno amigable y que sobre todo facilitará el trabajo de los usuarios.
Como se conoce estas dos metodologías son ágiles, motivo por lo cual no existen
inconvenientes a la hora del desarrollo del sistema web.
En este documento se incluirá la descripción del ciclo de vida iterativo e incremental del
proyecto, las herramientas o documentos con los que se gestionan las tareas de adquisición y
suministro: requisitos, monitorización y seguimiento del avance, así como las
responsabilidades y compromisos de los participantes en el proyecto.
Figura 3. 1 Panificación de implementación del sistema

Fuente: Elaboración propia
32
En la figura 3.1 se puede observar gráficamente el modelo ya adaptado (metodología Scrum
y WebML) que se utilizara para la implementación.
3.2. PRE GAME
3.2.1 RECOPILACIÓN DE REQUERIMIENTOS
Para la elaboración del backlog del producto, se realizó una entrevista con el cliente donde
se hizo conocer los requerimientos que requiere la farmacia Maya. La lista o pila es
gestionada y creada por el cliente con la ayuda del Scrum Master, quien indicará el costo
estimado para completar un requisito, y será un aporte al valor final del producto.
Las reuniones. La realización de la reunión nos genera el “Spring Backlog” o lista de tareas,
además en ella se definen los requisitos, que en el propuesto del desarrollo pueden
modificarse, incluso agregar algunos requisitos por el cliente.
Requerimientos del sistema. Debemos recordar que la lista de requerimientos evolucionara

durante el desarrollo del sistema web para farmacia Maya, la lista de requerimientos de la
pila del producto esta ordenada por orden de prioridad obtenidas en la reunión con el gerente
de la farmacia.
Dentro de esta fase, al capturar los requerimientos se desarrollan los siguientes artefactos:
 Requisitos del sistema

 El ProductBacklog.
3.2.2 PILA DEL PRODUCTO
Se sabe que en la metodología Scrum, la preferencia por tener documentación en todo

momento es menos estricta, pero si es necesario mantener una comunicación directa con los
equipos, por eso se usara como herramienta el Backlog.
33
En la tabla 3.1 se presenta el backlog del producto, que contiene los requerimientos y
características finales del sistema web para la farmacia Maya.
ID DESCRIPCIÓN PRIORIDAD PRIORIDAD

R1 Planificación del proyecto Alta Terminado
R2 Diseño de base de datos único para el sistema Alta Terminado
web.
R3 Búsqueda de registros mediante filtros. Alta Terminado
R4 Creación de página de inicio de sesión del Alta Terminado
sistema para usuarios de la farmacia Maya
asignado por roles.
R5 Interfaz Amigable para el uso del sistema. Alta Terminado
R6 Desarrollo de una interfaz web para él Alta Terminado
información de los medicamentos de la
farmacia Maya.
R7 Desarrollo de una interfaz web para los Alta Terminado
reportes de ventas.
R8 Desarrollo de una interfaz web para los Alta Terminado
reportes de compras.
R9 Control de stocks de los medicamentos. Alta Terminado
R10 Estadísticas de ventas más vendidos de los Alta Terminado
distintos medicamentos.
R11 Registro adecuado de la venta de los Alta Terminado
medicamentos realizados dentro de la
farmacia Maya.
R12 Registro adecuado de la compra de los Alta Terminado
medicamentos.
R13 Desarrollo de la interfaz de registro adecuado Alta Terminado
de datos de los medicamentos que tiene la
farmacia Maya.
R14 Reportes de compras y ventas Alta Terminado
R15 Desarrollo de la interfaz de registro de Alta Terminado
proveedores además de sus ABM y sus
búsquedas por todos los campos.
Tabla 3. 1 Pila del Producto

34
3.2.3 DEFINICIÓN DE CRONOGRAMA DE TRABAJO
El cronograma de trabajo se definió en base al ciclo de vida de la metodología Scrum, donde

se definen e identifican tres etapas principales, que son el Pre-Game, Game y Post-Game.
3.2.4 ANÁLISIS DE RIESGOS
Un riesgo es una probabilidad de que ocurra algo adverso, existen dos tipos de riesgo.
Riesgo del proyecto. Afecta a la calendarización o recursos del proyecto.
Riesgo del producto. Afecta a la calidad o rendimiento del software que se está
implementando.
RIESGO TIPO DESCRIPCIÓN RESPONSABILIDAD EFECTO ESTRATEGIA
Incumplimiento Proyecto Es probable que Alta Tolerable Realizar un

en las fechas las fechas segundo
establecidas en definidas en el cronograma o
el cronograma diagrama de modificar la
Gantt no se fecha,
cumplan en la obteniendo un
fecha establecida cronograma
flexible
Falta de Proyecto Es probable que Media Tolerable Modificar las

compromiso el cliente no reuniones
del cliente cumpla con las
reuniones.
Cambio de Proyecto Puede existir Media Tolerable Efectuar

requerimientos producto cambio en revisiones
del cliente requerimientos constantemente
de los
requerimientos.
Incumpliendo Producto Los plazos de Media Serio Mantener una

en la entrega entrega son buena
del producto determinado y comunicación
revisados por el respecto a las
gerente dela entregas del
farmacia producto.
35
No existe una Proyecto No cuenta con Alto Tolerable Pedir con
infraestructura muchas anticipación las
para la herramientas herramientas
implementación para el desarrollo para la
del sistema del sistema implementación
del sistema.
Tabla 3. 2. Análisis de riesgos

3.2.5. HERRAMIENTAS PARA EL DESARROLLO DEL SISTEMA
Para el desarrollo del sistema se hace uso de las siguientes herramientas:
 Bootstrap 4, para el diseño del sistema web.

 PHP 8.0, para el desarrollo web
 My SQL 6, como gestor de base de datos.
 Laravel 5.8, como framework para trabajar fácilmente con php de forma elegante.
 Chrome 39, como navegador predeterminado
 Windows 10 Professional, como sistema operativo.
3.2.6. DISEÑO DE LA ARQUITECTURA DEL SISTEMA
Figura 3. 2 Figura 3. 2 Arquitectura del Sistema

36
El diagrama de Arquitectura tiene el objetivo de representar de forma gráfica lo que se quiere
construir y provee de forma una visión simplificada del sistema, como puede apreciarse en
el diagrama se muestran las sucursales interactuando con el sistema a través de la Intranet, el
mismo está alojado localmente.
3.3 GAME
En esta etapa se desarrolla todos los requerimientos de nuestra pila de productos, para esto
se elaboró las pilas de las iteraciones. Se sabe que las pequeñas entregas de estas iteraciones
se realizan en tiempos cortos, pero para el desarrollo del presente documento se tomó en
cuenta tiempos largos para su desarrollo.
Durante esta etapa se desarrolló tres iteraciones, donde se hace corresponder a la plataforma
y contenido. A continuación, se da a conocer las actividades que se realizan en cada una de
las etapas.
3.3.1 PRIMER SPRINT
En esta iteración se realiza el análisis, evaluación e implementación sobre los actores que son
parte del sistema web, posterior mente se implementara el requerimiento de la pila del
producto.
SPRINT INICIO DURACIÓN
1 12/09/2019 12 días
ID TAREA TIPO DIAS DE ESTADO
TRABAJO
R1.1 Realizar la planificación de Planificación 2 terminado
las iteraciones
R1.2 Realizar historias de usuario Planificación 1 Terminado
R1.3 Analizar los requerimientos Planificación 2 Terminado
de backlog del producto
R1.4 Implementar la base de Desarrollo 2 Terminado
datos
R1.5 Implementar el modelo de Desarrollo 2 Terminado
entidad relación de la base
de datos.
37
R1.6 Implementar la página Desarrollo 1 Terminado
iniciar sesión.
R1.7 Construir el modelo Desarrollo 1 Terminado
estructural .
R1.8 Desarrollo del módulo de Desarrollo 3 Terminado
medicamentos ABM del
registro de medicamentos.
R1.9 Construir el modelo de Desarrollo 1 Terminado

hipertexto.
R1.10 Construir modelo de Desarrollo 1 Terminado
presentación
R1.11 Presentación de interfaz Desarrollo 1 Terminado
Tabla 3. 3 Primera iteración del o primer sprint

Las funcionalidades correspondientes al incremento de la primera iteración:

 Base de datos del sistema.
 Páginas de ingreso con acceso a los usuarios.
 Módulo de registros de usuarios.
 Autentificación de usuarios
 Módulo de registro de medicamentos.
3.3.1.1 HISTORIAS DE USUARIO
En esta etapa se realiza un listado de las historias de usuario, que se detalló en la reunión con
el cliente. En las siguientes tablas se describen las historias de usuario del sistema web con
sus respectivas descripciones.
A continuación, se muestra una descripción sobre el registro de usuarios.
HISTORIA DE USUARIO
Historia de usuario Nro.1: Registro de usuarios
Usuario: administrador Nombre: registro de usuarios
Prioridad: Alta
Descripción El administrador podrá realizar ABM de
los usuarios.
38
Observación Previamente el administrador debe estar
registrado en el sistema e ingresar al
módulo de usuario
Tabla 3. 4. Registro de usuarios

A continuación, se muestra una descripción sobre el registro del proveedor

HISTORIA DE USUARIO
Historia de usuario Nro.2: Registro de proveedor
Usuario: gerente Nombre: registro de proveedor
Prioridad: Alta
Descripción El gerente podrá realizar el registro de
proveedor de medicamentos y realizar
ABM del proveedor.
Observación Previamente el gerente debe estar
módulo de proveedor.
Tabla 3. 5 Registro de proveedor

A continuación, se muestra una descripción sobre el registro de medicamentos, el

encargado de realizar esa tarea será el farmacéutico.
HISTORIA DE USUARIO
Historia de usuario Nro.3: Registro de medicamento
Usuario: gerente Nombre: registro de medicamentos
Prioridad: Alta
Descripción El gerente de la farmacia podrá realizar el
registro o ingreso de los medicamentos con
todas los campos como ser nombre, precio,
cantidad.
módulo de medicamentos.
Tabla 3. 6. Registro de Medicamento

A continuación, se muestra una descripción de la venta de medicamentos, el encargado de

realizar esa tarea será el auxiliar de venta.
39
HISTORIA DE USUARIO
Historia de usuario Nro.4: salida o venta de medicamentos
Usuario: Auxiliar de venta Nombre: Salida de medicamentos o venta
Prioridad: Alta
Descripción El auxiliar de venta de la farmacia podrá
realizar el registro de la salida o venta de
medicamentos de acuerdo al stock.
Observación Previamente el auxiliar debe estar
Tabla 3. 7. Venta de medicamentos

A continuación, se muestra una descripción de la generación de reportes de informes de

compra y ventas, listado de medicamentos.
HISTORIA DE USUARIO
Historia de usuario Nro.5: informes, reportes de ventas y compra
Usuario: gerente Nombre: informes
Prioridad: Alta
Descripción El gerente de la farmacia puede evaluar los
reportes de ventas y compra de
medicamentos ,estos se podrá exportar en
varios formatos Excel y pdf
Tabla 3. 8. Informes de la farmacia

A continuación, se muestra una descripción del registro de los medicamentos que serán
realizado por el auxiliar de venta.
HISTORIA DE USUARIO
Historia de usuario Nro.6: Registro de medicamento
Usuario: Auxiliar de venta Nombre: Registro de medicamentos
Prioridad: Alta
El auxiliar de venta de la farmacia podrá
realizar el registro o ingreso de los
medicamentos.
Observación Previamente el auxiliar debe estar
40
Descripción: el Sistema registra los medicamentos asignando, proveedor, precios y
descripción. Además permite modificar y eliminar.
Tabla 3. 9 Registro de medicamento

En esta tabla vemos la descripción de listar el stock y hacer el ABM de los Medicamentos.
HISTORIA DE USUARIO
Historia de usuario Nro.7: ABM de los medicamentos
Prioridad: Alta
Descripción El sistema tiene la opción listar el stock y
tiene la opción de crear, modificar y
eliminar.
Observación Previamente el administrador debe dar
permiso al usuario para las ABM del
medicamento.
Tabla 3. 10 ABM de los Medicamentos

En esta tabla vemos la descripción de autentificación de usuario que lo hace el sistema una
vez que el usuario ya haya sido dado de alta.
HISTORIA DE USUARIO
Historia de usuario Nro.8: Autentificación de usuarios
Prioridad: Media
Descripción Desarrollar la autenticación de usuario de
tal forma que sea seguro el acceso al
sistema web, una vez que el administrador
haya echo la respectiva verificación de la
creación del nuevo usuario para darle de
alta.
Tabla 3. 11 Autentificación de usuario.

En esta tabla vemos la descripción del ABM que tiene el sistema en los registros de los
proveedores.
HISTORIA DE USUARIO
Historia de usuario Nro.9: Administración de proveedores
Prioridad: Alta
41
Descripción El sistema debe tener la opción de
administrar los proveedores.
Tabla 3. 12 Administración de Proveedores

HISTORIA DE USUARIO
Historia de usuario Nro.10: Registro de ventas
Prioridad: Alta
Descripción El sistema registra datos de ventas, el
sistema calcula los precios de los
medicamentos, luego calcula el total y
finalmente se registra la venta.
Tabla 3. 13 Registro de ventas

En esta tabla vemos la descripción del listado de los registros de ventas realizados en una
determinada fecha.
HISTORIA DE USUARIO
Historia de usuario Nro.11: Reporte de ventas
Prioridad: media
Descripción El sistema debe proveer un reporte donde se
puedan visualizar las ventas realizadas por
cada sucursal en un periodo determinado.
Tabla 3. 14 Reporte de ventas

En esta tabla vemos la descripción del ABM de los registros de los clientes.
HISTORIA DE USUARIO
Historia de usuario Nro.12: Administración de clientes.
Prioridad: media
Descripción El sistema debe tener la opción de Crear,
listar, modificar y eliminar registros de
clientes.
Tabla 3. 15 Administración de clientes

42
En esta tabla vemos la descripción del ABM de los registros de las compras de medicamentos
por parte del farmacéutico.
HISTORIA DE USUARIO
Historia de usuario Nro.13: Registro de compras
Prioridad: Alta
Descripción El sistema registra las compras de los
medicamentos. Primero carga una lista de
los medicamentos, luego hace una
verificación de la cantidad la lista en
comparación con la cantidad recibida,
finalmente registra la compra.
Tabla 3. 16 Registro de compras

En la siguiente tabla vemos la descripción del ABM que tiene el sistema en los registros de
las compras en las sucursales.
HISTORIA DE USUARIO
Historia de usuario Nro.14: Administración de compras en las sucursales
Prioridad: Alta
Descripción El sistema debe tener la opción de crear,
listar, modificar y eliminar registros de
compras en las sucursales.
Tabla 3. 17 Administración de compras sucursales

En esta tabla vemos la descripción del listado de los registros de las compras realizados en
una cada sucursal.
HISTORIA DE USUARIO
Historia de usuario Nro.15: Reporte de compras por sucursales
Prioridad: Alta
Descripción El sistema debe proveer un reporte donde se
puedan visualizar las compras realizadas
por cada sucursal.
Tabla 3. 18 Reporte de ventas por sucursales
43
En siguiente tabla vemos la descripción de las alertas de vencimiento de los medicamentos.
HISTORIA DE USUARIO
Historia de usuario Nro.16: alertas de stock de medicamentos
Prioridad: Alta
Descripción El sistema debe tener la opción de mostrar
una lista de los medicamentos por expirar.
Tabla 3. 19 Alertas de stock de medicamentos

En esta tabla vemos la descripción de la administración de los roles de los usuarios.
HISTORIA DE USUARIO
Historia de usuario Nro.17: Administración de roles
Prioridad: Alta
administrar los roles de los usuarios,
limitando así el acceso a los recursos del
sistema, cada usuario puede tener uno o
más roles, al ingresar al sistema
Tabla 3. 20 Administración de roles

Fuente: Elaboración Propia
En esta tabla vemos el ABM de la administración de usuarios que se registraron al sistema.
HISTORIA DE USUARIO
Historia de usuario Nro.17: Administración de usuarios
Prioridad: Media
administrar los usuarios que se registraron
al sistema. Tendrá la opción de listar,
modificar, crear y eliminar usuarios.
Tabla 3. 21 Administración de usuarios

44
3.3.1.2. MODELO ENTIDAD RELACIÓN
El siguiente diagrama nos servirá como una herramienta para el modelado de datos que
permitirá representar nuestras entidades más relevantes de un sistema de información, así
como sus interrelaciones y propiedades o atributos.
Figura 3. 3 Modelo entidad relación

45
3.3.1.3. MODELO ESTRUCTURAL
Según los requisitos de la farmacia maya, se procede al diseño del diagrama de clases, siendo
el modelo estático del sistema. El siguiente diagrama de modelos de contenidos describe la
estructura del sistema por medio de las clases con sus atributos y las relaciones con otras
clases.
Figura 3. 4 Modelo estructural

46
3.3.1.4. MODELO DE HIPERTEXTO
El modelo de Hipertexto de la figura 3.5 especifica la composición del registro de

medicamentos.
Figura 3. 5 Diagrama de composición - ABM de Medicamentos

La siguiente figura 3.6 se muestra el diagrama de composición de usuarios, donde se tiene la

opción de crear un nuevo registro o modificar un registro actual, una vez modificado o
creado, el proceso vuelve a la pantalla de listado de usuarios.
Figura 3. 6 Diagrama de composición - ABM de Usuarios

47
3.3.1.5. MODELO DE PRESENTACIÓN
En la figura 3.7 se muestra el modelo de presentacion de la pagina del registro de

medicamentos.
Figura 3. 7 Modelo de presentación de registro de Medicamento

En la figura 3.8 se muetra el modelo de presentación de incio de sesion del sistema web de
farmacia maya
Figura 3. 8 Modelo de presentación de inicio de sesión

48
En la figura 3.9 se muetra el modelo de presentacion de ingreso del sistema web de farmacia
maya.
Figura 3. 9 Modelo de presentación de ingreso del Sistema

En la figura 3.10 se muestra el modelo de presentación del registro de usuarios del sistema
web de farmacia maya.
Figura 3. 10 Modelo de presentación de registro de usuarios

49
3.3.16 DESARROLLO DEL PRIMER SPRINT
A continuación, se muestran las capturas de pantallas más relevantes, que son el resultado de
la implementación de las tareas del primer sprint.
La siguiente figura muestra el inicio sesión del sistema web donde se debe insertar un email
y un password ya que estos dos campos son previamente verificados por un administrador si
se creó la cuenta de usuario correctamente para así darlo de alta y así el usuario pueda ingresar
al sistema sin ningún problema.
Figura 3. 11 Inicio se sesión del Sistema

La siguiente figura 3.12 muestra el registro, ABM de medicamentos, donde se podrá efectuar
la creación, modificación y eliminación de medicamentos, se tiene en el panel un listado de
los medicamentos que se tienen registrados, se tiene la opción de crea uno nuevo, de
modificar y eliminar.
50
Figura 3. 12 ABM de Medicamentos
La siguiente figura muestra el registro, ABM de usuarios, donde se podrá efectuar la creación,
modificación y eliminación de usuarios, se tiene en el panel un listado de los usuarios que se
tienen registrados, se tiene la opción de crea uno nuevo, de modificar y eliminar.
Figura 3. 13 ABM de usuarios

51
3.3.2. SEGUNDO SPRINT
En esta iteración se desarrollarán las siguientes funcionalidades para el sistema: módulo de

proveedores de medicamentos, sucursales, ABM de registros, es decir la modificación o
eliminación de proveedores y sucursales.
SPRINT INICIO DURACION
2 15/11/2019 14 días
TRABAJO
R2.1 Realizar la planificación Planificación 2 Terminado
de las iteraciones
R2.2 Analizar los Planificación 2 Terminado
requerimientos de
Backlog del producto
R2.3 Realizar el registro de Desarrollo 3 Terminado
proveedores ABM.
hipertexto de
proveedores.

presentación.
R2.6 Desarrollo de la interfaz Desarrollo 1 Terminado
de sucursales.
R2.7 Presentación de interfaz Desarrollo 3 Terminado
R2.8 ABM de roles Desarrollo 3 Terminado
Tabla 3. 22 Segunda iteración del o segundo sprint

En la segunda iteración se desarrollaron las siguientes funcionalidades para el sistema:

 Administración del ABM de proveedores
 Reportes de compras en las sucursales
 Roles
Con el modelo de hipertexto siguiente se podrá describir las visitas del modelo estructural
que estarán publicadas en el sistema.
52
La siguiente figura 3.14 se muestra el diagrama de composición de proveedores, donde se
tiene la opción de crear un nuevo registro o modificar un registro actual, una vez modificado
o creado, el proceso vuelve a la pantalla de listado de proveedores.
Figura 3. 14 Diagrama de componente - ABM de Proveedor

En el siguiente diagrama muestra cómo se filtran las listas de los medicamentos disponibles
por sucursal.
Figura 3. 15 Diagrama de componente - Lista de medicamentos por Sucursal

53
En la figura 3.16 se muestra el modelo de presentacion de la pagina del registro de
proveedores.
Figura 3. 16 Modelo de presentación de registro de proveedores

En la figura 3.17 se muestra el modelo de presentacion de la pagina del registro de Sucursales.
Figura 3. 17 Modelo de presentación de registro de sucursales

Fuente: elaboración propia
54
En la figura 3.18 se muestra el modelo de presentación del registro de permisos del sistema web de
farmacia maya.
Figura 3. 18 Modelo de presentación de registro de permisos

3.3.2.3 DESARROLLO DEL SEGUNDO SPRINT
La siguiente figura 3.19 se muestra el registro, ABM de proveedores , donde se podrá efectuar
la creación, modificación y eliminación de proveedores, se tiene en el panel un listado de los
proveedores que se tienen registrados, se tiene la opción de crea uno nuevo, de modificar y
eliminar.
Figura 3. 19 ABM de proveedores

55
La siguiente figura muestra el registro, ABM de sucursales , donde se podrá efectuar la
creación, modificación y eliminación de sucursales, se tiene en el panel un listado de los
sucursales que se tienen registrados, se tiene la opción de crea uno nuevo, de modificar y
eliminar.
Figura 3. 20 ABM de Sucursales

La siguiente figura muestra el registro de los permisos del sistema web de farmacia maya.
Figura 3. 21 Registro de permisos

56
3.3.3. TERCER SPRINT
En la tercera iteración se desarrollaron el módulo de compras y ventas de medicamentos.
SPRINT INICIO DURACION
3 20/10/2019 12 días
TRABAJO
R3.1 Realizar la planificación Planificación 2 Terminado
de las iteraciones
R3.2 Analizar los Planificación 2 Terminado
requerimientos de
Backlog del producto
R3.3 Desarrollo de control de Desarrollo 3 Terminado
ventas de medicamentos.
R3.4 Registros o reportes de la Desarrollo 1 Terminado
estadísticas de ventas
R3.5 Desarrollo del módulo de Desarrollo 2 Terminado
compras ABM.
R3.6 Avisos de stock Desarrollo 3 Terminado
Tabla 3. 22 Tercer iteración del o tercer sprint

En la tercera iteración se desarrollaron las siguientes funcionalidades para el sistema:

 Alertas de fechas de vencimiento
 Registro de compras
 Reportes de compras en las sucursales
 Registro de ventas
 Reportes de ventas
 Administración de factura

En el siguiente diagrama de componentes muestra el proceso de registro de una venta.
57
Figura 3. 22 Diagrama de componentes – Registro de Venta
El siguiente diagrama muestra la composición del proceso de registro de una compra al

proveedor.
Figura 3. 23 Diagrama de componentes – Registro de Compra

58
En la figura 3.24 se muestra el modelo de presentación del registro de facturas del sistema web de
farmacia maya.
Figura 3. 24 Modelo de registro de facturas

3.3.3.3 DESARROLLO DEL TERCER SPRINT

La siguiente figura muestra el registro de las facturas al realizar la venta de los medicamentos.
Figura 3. 25 Registro de facturas

59
La siguiente figura muestra el registro de las compras de medicamentos al proveedor.
Figura 3. 26 Registro de compras al proveedor

La siguiente figura muestra el stock de los medicamentos.
Figura 3. 27 Stock de Medicamentos

60
3.4. POSTGAME
En la última etapa se realizarán las actividades de prueba de la aplicación web y el diseño de

la ayuda para los usuarios, se propuso con el objetivo de decidir que los requerimientos se
han completado, se verificaran los sprint a entregar.
3.4.1. ROLES Y RESPONSABILIDADES DE USUARIOS
NOMBRE DESCRIPCIÓN
Responsable de la administración de la
Administrador de farmacia Maya , crea usuarios y asigna
farmacia Maya roles a los demás usuarios de la
farmacia, puede eliminar ,cambiar
contraseñas.
Encargado de la gestión y el buen
farmacéutico de funcionamiento del almacén de los
farmacia Maya medicamentos, registra los proveedores,
medicamentos, genera reportes de
compras y ventas, estadísticas de ventas
Auxiliar de ventas Responsable de la las ventas, control y

de farmacia Maya emisión de facturas. Puede registrar las
ventas realizadas
Tabla 3. 23 Roles y descripción delos usuarios

3.5. FASES DE PRUEBAS
Esta fase es una de las más importantes, ya que nos permite verificar junto al cliente de la
farmacia Maya si se pudieron cumplir con los requerimientos específicos en las historias de
usuario. También sirve como retroalimentación para ver que historias de usuario fueron
implementadas sin error, o realizar modificaciones necesarias o simplemente descártalas.
3.5.1 PRUEBAS DE ACEPTACIÓN
Este tipo de pruebas fueron realizadas para cada entrega del software en los distintos sprint
que se tuvo.
61
Las siguientes tablas se muestran todas las pruebas de aceptación requeridas por el cliente en
cada historia de usuario, además de la iteración en la cual fueron solucionadas correctamente.
Adición y edición de Usuario. En esta prueba se busca encontrar todo tipo de errores que se
generen en el proceso de registro de un usuario nuevo en el sistema, ya sea en el llenado del
formulario de registro con datos no válidos o también por la falta de datos obligatorios.
PRUEBA DE ACEPTACIÓN
Número: 1 Usuario: Administrador del sistema
Historia de Usuario: Administración de usuarios
Descripción:
 Controlar que el nombre de usuario sea único.
 Controlar que no se permita registrar el formulario de al momento de crear usuario
nuevo, si es que todos los campos están llenados obligatoriamente.
 Validar los campos numéricos para evitar errores en el sistema.
 Mostrar un mensaje de confirmación una vez que se haya el registro correctamente.
Test de Aceptación: Aceptado por el cliente en la primera muestra.
Tabla 3. 24 Verificación de administración de usuarios

Administración de ventas. En esta prueba se busca encontrar todo errores que se generen
durante al momento de realizar las ventas guardado en la base de datos, ya sea para la validez
de los datos almacenados y la edición, si es posible, de algún dato guardado incorrectamente.
Número: 2 Usuario: Farmacéutico
Historia de Usuario: Administración de ventas
Descripción:
 Controlar que cada registro de venta funcione correctamente mostrando todos los
datos de manera correcta.
 Controlar la actualización del stock de cada medicamento vendidos.
 Controlar que los campos obligatorios sean debidamente llenados.
62
Test de Aceptación: Aceptado por el cliente en la segunda muestra
Tabla 3. 25 Verificación de administración de ventas
Administración de compras. En esta prueba se busca encontrar los errores que se generen
durante al momento de realizar las compras. Ya que la compra implica el ingreso de
medicamentos al inventario, se debe tener mucho cuidado con la información que está siendo
ingresada a la base de datos.
Historia de Usuario: Administración de compras
Descripción:
 Verificar el ingreso correcto de los medicamentos comprados al inventario.
 Controlar que los campos sean debidamente llenados, mostrando alertas y señalando
los campos que deben ser ingresados.
Test de Aceptación: Aceptado por el cliente en la tercera muestra
Tabla 3. 26 Verificación de administración de compras
Administración de Productos. Esta prueba busca encontrar los errores que se generen
durante al momento de realizar la administración de medicamentos, ya que con esos datos
serán utilizados al momento de hacer realizar las ventas y compras.
Historia de Usuario: Administración de medicamentos
Descripción:
 Verificar que en la venta el precio sea el correcto.
 Controlar que los campos obligatorios sean debidamente llenados, mostrando alertas
y señalando los campos que deben ser ingresados
 Mostrar un mensaje de confirmación una vez que se haya el registro correctamente
Test de Aceptación: Aceptado por el cliente en la tercera muestra
Tabla 3. 27 Verificación de administración de medicamentos
63
3.5.2 PRUEBA DE STRESS
La prueba de Stress es aquella que fuerza al sistema al máximo punto para poder medir sus
capacidades y las condiciones en las cuales trabaja realizando una calidad definida de
peticiones y de procesos.
Para realizar la prueba de Stress del sistema web se utilizó el software JMeter para analizar
y medir el desempeño. Se llevará a cabo 6 peticiones por usuario, las cuales estaban dadas
en el siguiente orden:
 Lógin del sistema

 Registro de medicamento
 Ver que la venta este registrado en el sistema
 Salir del sistema
 Ver que el proveedor este registrado
 Agregar usuario
Entre cada una de las peticiones se dejaba un tiempo entre 2 a 3 segundos para saturar al
sistema de manera simultánea y para poder dar un poco de realismo a la prueba.
Los usuarios se conectan al mismo tiempo, cada uno en una sesión diferente y se llevan a
cabo estas seis actividades, para lo cual se registraron los tiempos de respuesta y se tomaron
algunos datos estadísticos que proporciona el JMeter. Para encontrar el número correcto de
usuarios después de varias pruebas incrementadas, es decir se comenzó probando para un
número de usuarios reducidos, y se fue aumentando para medir el desempeño del sistema.
Hasta que se encontró que el caso optimo fue con 55 usuarios y el caso crítico con 65. A
pesar de que la diferencia que existe entre estos dos números es muy pequeña. Para 65
usuarios se empieza a reportar errores mínimos pero que si afectan a algunos de los usuarios
que se encuentran utilizando el sistema.
 URL: es la actividad que se desempeña
64
 #Muestras: es la actividad de veces que se realizó la actividad (una vez por cada
usuario)
 Media: el promedio o media aritmética del tiempo en milisegundos.
 Mediana: el tiempo en milisegundos.
 Min: tiempo mínimo de todos los requests de este tipo.
 Max: Tiempo máximo en todos los requests de este tipo.
 Porcentaje de error: en el cual se muestra el porcentaje de los requests fallidos.
 Rendimiento: este medido en requests/segundo.
 KB/Sec: Medida de velocidad en Kilobytes/sec.
Url #Muestras Media Mediana Min Max %Error Rendimiento kb/sec

Login del 65 13796 13835 318 28600 9.65% 11.7/sec 149.80
sistema
Registro de 65 2231 1141 0 8422 0.00% 21.5/sec 107.93
medicamento
Ver registro de 65 9 15 0 48 0.00% 19.6/sec 48.55
venta
Agregar usuario 65 515 16 0 5688 0.00% 18.6/sec 47.58
proveedor
Salir del sistema 65 0 0 0 17 0.00% 21.0/sec 60.11
TOTAL 390 2790 16 0 27500 1.62% 13.3/sec 65.48

Tabla 3. 28 Prueba de Stress de 65 usuarios
Se puede apreciar en la tabla 3.28 que en la actividad autentificación existe un porcentaje de

error de 9.65% este presenta 6 usuarios de los 65 con las que se realizó la prueba. Estos 6
usuarios obtuvieron una página de error al intentarse conectar al sistema crítico, la media
total fue 2790 ms, esto quiere decir que el sistema en promedio se tardó en responder 2.7
segundos.
Porcentaje de error de 9.65%
Tardó en responder 2.7 segundos
65
Este tiempo es bastante bueno tomando en cuenta que son 65 usuarios conectados al mismo
tiempo.
Para el caso óptimo se utiliza usuarios y como se muestra en la tabla no hay porcentaje de
error y es un mejor rendimiento del sistema. Además, se puede apreciar que el porcentaje de
error en todas las peticiones es de 0.00%, esto indica que no fue desplegada ninguna página
de error, puesto que todas las peticiones fueron respondidas de manera adecuada y correcta,
si se toma la medida de la tabla 3.28, que es de 2790 ms, y se compara con la tabla 3.29, que
es de 2470 ms, se puede apreciar que existe una mínima diferencia de 0.32.
segundo lo cual es un poco menos de tiempo. Por lo que se considera como un tiempo de
respuesta muy pequeño, lo que clasifica al sistema de rápido.
Url #Muestras Media Mediana Min Max %Error Rendimiento kb/sec

Login del 55 12915 12640 93 24906 0.00% 10.9/sec 158.10
sistema
Registro de 55 1839 1063 0 6140 0.00% 16.2/sec 63.76
medicamento
venta
Agregar usuario 55 97 16 0 2563 0.00% 19.0/sec 57.82
proveedor
Salir del sistema 55 1 0 0 16 0.00% 21.2/sec 60.50
TOTAL 330 2470 16 0 24906 1.62% 16.3/sec 79.51

Tabla 3. 29 Prueba de Stress de 55 usuarios
66
CAPÍTULO IV
CALIDAD Y SEGURIDAD
4.1. CALIDAD DE SOFTWARE
En todo sistema es necesario conocer la calidad del mismo, debido a que este es un factor
muy importante para el buen funcionamiento del mismo, ya que la calidad de diseño
acompaña a los requisitos, especificaciones y diseño del sistema.
La calidad del sistema se centra principalmente en la implementación, si la implementación

sigue al diseño, entonces cumple con los objetivos de requisitos y de rendimiento, la calidad
de concordancia es alta.
4.2 WEBSITE QEM
Es una Metodología de Evaluación de Calidad de Sitios Web (o, en inglés, Web-site Quality
Evaluation Method, o, metodología Web-site QEM), que propone un enfoque sistemático,
disciplinado y cuantitativo que se adecua a la evaluación, comparación y análisis de calidad
de sistemas de información centrados en la Web, éste mismo está basado en las normas de
calidad de la ISO 9126. En la tarea “Especificando Requerimientos de Calidad para artefactos
Web”, de la ISO 9126, los evaluadores deben especificar las características,
subcaracterísticas y atributos de calidad agrupándolas en un árbol de requerimientos. Estas
características de alto nivel son: usabilidad, funcionalidad, confiabilidad, eficiencia,
portabilidad, y mantenibilidad (Olsina, 1999).
a) FUNCIONALIDAD: Se define como un conjunto de atributos que otorgan la

existencia de un conjunto de funciones y sus propiedades específicas. Las funciones
son aquellas que satisfacen conjuntos de usuarios declarados o implícitos. (ISO9126,
2005).
b) CONFIABILIDAD: Se define como un conjunto de atributos que da la habilidad del
software para mantener las condiciones de establecer su propio nivel de desempeño
por un periodo determinado. (ISO9126, 2005).
67
c) USABILIDAD: Se define como un conjunto de atributos que otorgan el esfuerzo
necesario para su uso, y en la evaluación individual de dicho uso, mediante un
conjunto de usuarios declarados o implícitos. (ISO9126, 2005).
d) EFICIENCIA: Se define como un conjunto de atributos que otorgan la relación entre
el nivel de rendimiento del software y la cantidad de recursos usados por el usuario,
bajo las condiciones establecidas. (ISO9126, 2005).
e) MANTENIBILIDAD: Se define como un conjunto de atributos que otorgan el
esfuerzo necesario para hacer modificaciones específicas. (ISO9126, 2005).
f) PORTABILIDAD: Se define como un conjunto de atributos que otorgan la habilidad
de software para ser transferido de un entorno a otro. (ISO9126, 2005).
4.2.1 ESPECIFICACIÓN DE CARACTERÍSTICAS DE CALIDAD DE QEM
A continuación, se especificarán las características de usabilidad, funcionalidad,

confiabilidad y eficiencia.
4.2.1.1 USABILIDAD
Consiste de un conjunto de atributos que permiten evaluar el esfuerzo necesario que deberá
invertir el usuario para utilizar el sistema web.
Es una característica de calidad de producto de alto nivel, que se la puede medir mediante
cálculo a partir de métricas directas e indirectas. Representa la capacidad o potencialidad del
producto para ser utilizado, comprendido y operado por los usuarios, además de ser atractivo.
El criterio de evaluación es un criterio binario, discreto y absoluto: Sólo se pregunta si está

disponible (1) o si no está disponible (0).
Para evaluar la usabilidad se deben considerar las siguientes características
 Comprensibilidad global del sitio: Es una característica que representa a todas

aquellas facilidades que permiten a la audiencia tener una rápida comprensión, tanto
de la estructura organizativa como del contenido del sitio Web como un todo,
68
facilitando el rápido acceso y recorrido del mismo y sus componentes (tabla 46). Por
tal razón, los atributos y subcaracterísticas se hallan principalmente en la página
principal o en los primeros niveles del sitio.
CARACTERÍSTICA: COMPRENSIBILIDAD GLOBAL DEL SITIO
Nro. Subcaracterística Resultado

1. Esquema de Organización Global 0,70
1.1 Mapa del sitio 1,00
1.2 Tabla de contenidos 1,00
1.3 Índice alfabético 0,85
2. Calidad en el sistema de etiquetado 1,00
3. Visita guiada orientada al usuario 1,00
4. Mapa de imagen 0,00
TOTAL 0,79
Tabla 4. 1 WebSiteQEM: Evaluación de comprensibilidad

 Mecanismos de ayuda y retroalimentación en línea: Este atributo representa a un

conjunto de preguntas (agrupadas y enlazadas) que se realizan con mayor frecuencia,
y que están ya publicadas en el sitio con sus respectivas respuestas. A su vez, las
respuestas pueden estar enlazadas a otros contenidos. Esto favorece al mecanismo de
aprendizaje y/o ayuda, evitando potencialmente la demora cognitiva de los visitantes.
CARACTERÍSTICA: MECANISMOS DE AYUDA Y

RETROALIMENTACIÓN EN LÍNEA
Nro. Subcaracteristica Resultado
1. Calidad de la ayuda 1,00
1.1 Ayuda explicada orientada al usuario 1,00
1.2 Ayuda de la búsqueda 1,00
2. Indicador de última actualización 1,00
2.1 Global 1,00
2.2 Restringido 1,00
3. Directorio de direcciones 1,00
3.1 Directorio email 1,00
3.2 Directorio TE-FAX 1,00
3.3 Directorio correo postal 1,00
4. Facilidad FAQ 0,00
5. Retroalimentación 0,00
5.1 Cuestionario 1,00
69
5.2 Libro de invitados 0,75
5.3 Comentarios/ sugerencias 0,33
TOTAL 0,80
Tabla 4. 2 WebSiteQEM: Evaluación de mecanismos de ayuda
 Aspectos de interfaces y estéticos: Son factores y elementos relativos a la

interacción del usuario, enfocados a un entorno o dispositivo concretos cuyo resultado
es la generación de una percepción positiva o negativa de dicho servicio, producto o
dispositivo. El diseño de los elementos de la interfaz debe facilitar la interacción del
usuario con la funcionalidad, debe generar y formalizar documentos hipermedias
comprensibles, interactivos, navegables y facilitando su visualización.
CARACTERÍSTICA: ASPECTOS DE INTERFACES Y ESTÉTICOS

1. Cohesión al agrupar los objetos de control 1,00
principales
2. Permanencia y estabilidad en la presentación de 1,00
los controles principales
2.1 Permanencia de los controles directos 1,00
2.2 Permanencia de los controles indirectos 1,00
2.3 Estabilidad 1,00
3. Aspectos de estilo 1,00
3.1 Uniformidad en el color de enlaces 1,00
3.2 Uniformidad en el estilo global 1,00
3.3 Guía del estilo global 1,00
4. Preferencia estética 1,00
TOTAL 1,00
Tabla 4. 3 WebSiteQEM: Evaluación de aspectos de interfaz

 Misceláneas: Este atributo modela el número de lenguajes extranjeros soportados por

un sitio (sitios de dominios de aplicación de índole académica, museos, comercio
electrónico y otros). Además, especifica el nivel de soporte para cada lenguaje: Total
(todas las páginas del sitio), parcial (algunos subsitios del sitio), o mínimo (algunas
páginas o documentos de algunos subsitios). No se computa obviamente el lenguaje
nativo del sitio Web, como lenguaje extranjero.
70
CARACTERÍSTICA: MISCELÁNEAS
1. Soporte lenguaje extranjero 0,00
2. Atributo que es lo nuevo 1,00
3. Indicador de resolución de pantalla 1,00
TOTAL 0,66
Tabla 4. 4 WebSiteQEM: Evaluaciones misceláneas de usabilidad
La usabilidad de la aplicación evaluada estará determinada por el promedio de las

características anteriormente mencionadas como muestra la siguiente tabla:
Nro. Criterio Resultado

1. Comprensibilidad global del sitio 0,79
2. Mecanismos de ayuda y retroalimentación en 0,80
línea
3. Aspectos de interfaces y estéticos 1,00
4. Misceláneas 0,66
EVALUACIÓN TOTAL DE USABILIDAD 0,81
Tabla 4. 5 WebSiteQEM: Evaluación total de usabilidad
4.2.1.2 FUNCIONALIDAD
Para determinar la calidad de la funcionalidad de la aplicación se debe analizar la búsqueda

y exploración de contenidos. El criterio de evaluación es un criterio binario, discreto y
absoluto: sólo se pregunta si está disponible (1) o si no está disponible (0).
 Aspectos de búsqueda y recuperación: Es una característica que modela el

mecanismo que permite tener un modo directo de encontrar información.
CARACTERÍSTICA: ASPECTOS DE BÚSQUEDA Y

RECUPERACIÓN
1. Mecanismo de búsqueda en el sitio web 0,50
1.1 Búsqueda restringida 1,00
1.1.1 De medicamentos 1,00
1.1.2 De proveedores 1,00
1.1.3 De sucursales 1,00
1.2 Búsqueda global 0,00
71
2, Mecanismos de recuperación 1,00
2,1 Nivel de personalización 1,00
2.2 Nivel de retroalimentación en la 1,00
recuperación
TOTAL 0,83
Tabla 4. 6 WebSiteQEM: Evaluación de búsqueda y recuperación
 Aspectos de navegación y exploración: Facilidad con la que un usuario puede

desplazarse por todas las páginas que componen un sitio web.
CARACTERÍSTICA: ASPECTOS DE BÚSQUEDA Y

RECUPERACIÓN
1. Navegabilidad 1,00
1.1. Orientación 1,00
1.1.1 Indicador de camino 1,00
1.1.2 Etiqueta de la posición actual 1,00
1.2 Promedio de enlaces por pagina 1,00
2. Objetos de control navegaciones 0,00
2.1 Permanencia y estabilidad en la 1,00
presentación de los controles
contextuales (subsitio)
2.2 Estabilidad 1,00
3. Nivel de desplazamiento 1,00
3.1 Desplazamiento vertical 1,00
3.2 Desplazamiento horizontal 1,00
4. Predicción navegacional 1,00
4.1 Enlace con título (enlace con texto 1,00
explicativo)
4.2 Calidad de la fase de enlace 1,00
TOTAL 0,92
Tabla 4. 7 WebSiteQEM: Evaluación de aspectos de navegación y exploración
 Aspectos de dominio orientados al usuario: Se refieren a la idoneidad

enciclopédica de los temas de los artículos, pero no limitan directamente su
contenido.
CARACTERÍSTICA: ASPECTOS DEL DOMINIO ORIENTADOS AL

USUARIO
1. Relevancia de contenido 1,00
72
2. Servicios on-line 1,00
TOTAL 1,00
Tabla 4. 8 WebSiteQEM: Evaluación de dominio orientado al Usuario
La funcionalidad de la aplicación evaluada estará determinada por el promedio de las

características anteriormente mencionadas como muestra la siguiente tabla:

1. Aspectos de búsqueda y recuperación 0,83
2. Aspectos de navegación y exploración 0,92
3. Aspectos del dominio orientados al usuario 1,00
EVALUACIÓN TOTAL DE FUNCIONALIDAD 0,91
Tabla 4. 9 WebSiteQEM: Evaluación total de funcionalidad
4.2.1.3 CONFIABILIDAD
La medición de esta característica está definida por el complemento de los casos de

deficiencia encontrados en la aplicación.
Es un criterio de variable normalizada, continuo y absoluto; en donde si BL = Número de

enlaces rotos encontrados, TL = Número total de enlaces del sitio, la fórmula para computar
la variable será: X = 100 – (BL * 100/TL) * 10; donde, si X < 0 entonces X = 0.
 No deficiencia: Este atributo representa básicamente la ausencia de los enlaces

encontrados que conducen a nodos destinos inaccesibles.
CARACTERÍSTICA: CONFIABILIDAD
1. No deficiencia 1,00
1.1 Errores de enlaces 0,00
1.1.1 Enlaces rotos 0,00
1.1.2 Enlaces inválidos 0,00
1.1.3 Enlaces no implementados 0,00
1.2. Errores o deficiencias varias 0,00
73
1.2.1. Deficiencias o cualidades ausentes 0,00
debido a diferentes navegadores
1.2.2. Deficiencias o resultados inesperados 0,00
1.2.3. Nodos destino en construcción 0,00
1.2.4. Nodos web muertos 0,00
EVALUACIÓN TOTAL DE CONFIABILIDAD 1,00
Tabla 4. 10 WebSiteQEM: Evaluación de confiabilidad
4.2.1.4 EFICIENCIA
Es una característica de calidad de producto de alto nivel – que puede medirse mediante
cálculo a partir de métricas directas e indirectas –, y principalmente representa a la relación
entre el grado de performance del artefacto y la cantidad de recursos (tiempo, espacio, entre
otros) usados bajo ciertas condiciones.
El criterio de evaluación es un criterio binario, discreto y absoluto: Sólo se pregunta si está

disponible (1) o si no está disponible (0).
 Desempeño: Para este atributo, se mide el tamaño de todas las páginas (estáticas) del
sitio web, considerando todos sus componentes gráficos, tabulares y textuales. El
tamaño de cada página se especifica como una función del tiempo de espera y de la
velocidad mínima establecida para una línea de comunicación dada.
CARACTERÍSTICA: DESEMPEÑO
1. Páginas de acceso rápido 1,00
TOTAL 1,00
Tabla 4. 11 WebSiteQEM: Evaluación de desempeño
 Accesibilidad: Este atributo representa la accesibilidad a la información que está en

las páginas. Es de relevancia que el sitio entero sea editado
74
CARACTERÍSTICA: ACCESIBILIDAD
1. Accesibilidad de la información 1,00
1.1 Soporte a versión solo texto 1,00
1.2 Legibilidad al desactivar la propiedad 1,00
imagen del browser
1.2.1 Imagen con titulo 1,00
1.2.2 Legibilidad global 1,00
2. Accesibilidad de ventanas 1,00
2.1 Número de visitas considerando marcos 1,00
2.2 Versión sin marcos 1,00
TOTAL 1,00
Tabla 4. 12 WebSiteQEM: Evaluación de accesibilidad
 La eficiencia de la aplicación evaluada estará determinada por el promedio de las

características anteriormente mencionadas, como muestra la siguiente tabla:

1. Desempeño 1,00
2. Accesibilidad 1,00
EVALUACIÓN TOTAL DE EFICIENCIA 1,00
Tabla 4. 13 WebSiteQEM: Evaluación total de eficiencia
4.3 RESULTADOS
La calidad total de la aplicación web estará determinada por el promedio de las características
de usabilidad, funcionalidad, confiabilidad y fiabilidad como muestra la siguiente tabla:

1. USABILIDAD 0,81
2. FUNCIONALIDAD 0,91
3. CONFIABILIDAD 1,00
4. EFICIENCIA 1,00
EVALUACIÓN DE CALIDAD TOTAL 0,93
Tabla 4. 14 WebSiteQEM: Evaluación de total de calidad
75
Por lo tanto, el nivel de calidad total del “Sistema Integrado Web de Control de Compra,
Venta e Inventarios de Medicamentos” propuesto, es de un 93%.
4.4 FACTORES DE SEGURIDAD
4.4.1 A NIVEL BASE DE DATOS
MySQL implementa seguridad en varios niveles, como ser:
 Protección de los ficheros de la base de datos. Todos los ficheros almacenados en la

base de datos están protegidos contra escritura por cualquier cuenta que no sea la del
superusuario de MySQL.
 Las conexiones de los clientes al servidor de la base de datos están permitidas, por
defecto, únicamente mediante sockets Unix locales y no mediante sockets TCP/IP.
Esto quiere decir que la conexión a la base de datos sólo se hace forma local, por
ejemplo, la aplicación puede usar esta conexión porque está en el mismo servidor; sin
embargo, cualquier otra aplicación externa al servidor que quiera conectarse a la base
de datos mediante sockets TCP/IP no está permitida. En ese caso, los sockets TCP/IP
solo pueden ser usados para conectarse al servidor.
 Solo se tiene un usuario que puede ingresar a la base de datos y tiene el rol de
administrador. La autenticación de MySQL tiene su propio método interno el cual se
hace mediante una solicitud de autenticación que se compara con un código Hash
almacenado localmente.
 Los passwords de los usuarios que pueden ingresar al sistema están almacenados en
forma codificada por el algoritmo MD5.
4.4.2 SEGURIDAD DE BASE DE DATOS
Se usó como base de datos MySQL. En cuanto a la forma de resguardo se realizó los
siguientes puntos:
76
 Cuando una acción del usuario en el sistema requiere o solicita algunos registros de
la base datos, existe una conexión segura para esta acción.
 Para la seguridad de datos del sistema se tienen registrado de nombre de usuario y

contraseña de acceso, según su nivel de acceso pueda realizar actividades en el
sistema.
La información en una empresa es muy valiosa, por tanto, su resguardo es fundamental, la

conexión a la base de datos y el cierre de la conexión es de forma automática.
4.4.3 SEGURIDAD CON AUTENTIFICACIÓN
Este control se refiere al control de sesión o verificación de la autentificación de un usuario

con nombre de usuario y una contraseña. Mientras el usuario ingresa la contraseña, esta no
se puede mostrar en pantalla, también cabe resaltar que la contraseña de cada usuario este
encriptado por el algoritmo md5.
4.4.3.1 ALGORITMO MD5
Este algoritmo fue desarrollado por Ronald Rivest está basado en los algoritmos anteriores
MD y MD4. MD5 comienza rellenando el mensaje una longitud congruente, es decir la
longitud de un mensaje es de 64 bits, el relleno comienza con un 1, seguido de tantos ceros
sean necesarios.
4.4.3.2 APLICACIÓN DE ALGORITMO MD5
El algoritmo MD5 se encuentra en PH3, PH4 y PHP5 como una función de cifrado tipo hash
que acepta una cadena de texto como entrada, y devuelve el numero de 128 bits. Las ventajas
de este algoritmo es la imposibilidad de reconstruir la cadena original a partir del resultado,
para la implementación de un método seguro para la autentificación y asignación de niveles
de acceso y privilegios.
77
4.5 SEGURIDAD DE LA APLICACIÓN
Se desarrolla un módulo de control de acceso al sistema para la restricción del acceso a

usuario no autorizado. Este módulo verifica y autoriza a los usuarios por medio de permisos
que son otorgados por el administrador del sistema. Se realiza el registro del usuario que
modifica la información la base de datos, para esto se registra en cada tabla el identificar del
usuario que modifica la información.
4.5.1 CONFIDENCIALIDAD
Datos privados de gran importancia como es el caso de la contraseña de los usuarios que se
cifra mediante el uso del algoritmo md5 antes de ser almacenado en la base de datos de modo
tal que, aunque algún intruso pudiera acceder a la información contenida en la base no podría
obtener la contraseña del usuario ya que este algoritmo de encriptación no permite realizar el
proceso inverso de decodificación, es decir es de un solo sentido y por lo tanto de gran
efectividad. Adjuntamos una imagen del lugar donde realizamos el proceso de encriptación
empleando el helper de form validation proporcionado por el marco de trabajo de codeigniter.
4.5.2 AUTENTICACIÓN Y AUTORIZACIÓN
El proceso de autenticación se realizó solicitando el nombre de usuario y la contraseña

contrastándolo con la información contenida en la base de datos, esto permite que los usuarios
solo accedan a los lugares del sistema según su nivel de privilegio, establecido en un campo
denominado con el mismo nombre (privilegio), es decir el proceso de autorización. La
información referente al usuario autenticado es almacenada en una cookie que acompaña al
usuario durante todo el tiempo de navegación hasta el momento en que el usuario selecciona
la opción salir para abandonar el sistema como usuario registrado destruyendo la cookie y
regresando a la página de ingreso.
4.5.3 SEGURIDAD EN FORMULARIOS
Todos los formularios presentados a los diferentes usuarios fueron completamente validados
empleando las facilidades que nos brindó el helper de form validation verificando aspectos
78
relevantes como el password solicitándolo no se muestra ,eso para garantizar que la seguridad
también los campos están validados , no permitiendo que se enviaran formularios
incompletos o incorrectamente diligenciados e informando a los usuarios acerca de los
campos faltantes o incorrectos para su oportuna corrección.
79
CAPÍTULO V
COSTO Y BENEFICIO
5.1 INTRODUCCIÓN
La técnica de Análisis de Costo y Beneficio, tiene como objetivo fundamental proporcionar

una medida de la rentabilidad de un proyecto, mediante la comparación de los costos
previstos con los beneficios esperados en la realización del mismo. Esta técnica se debe
utilizar al comparar proyectos para la toma de decisiones.
5.1.1 COCOMO II
En todo proyecto es importante tener una planificación o estimación de costos, no solo de los
requerimientos de hadware, costos de tiempo y esfuerzo; COCOMO II, es un método de
estimación de costos y refuerzos de únicamente proyecto de software, que permite por medio
de los módulos planificados en el software.
El Modelo Constructivo de Costes (COCOMO) es un modelo matemático de base emperica,

utilizando para la estimación de costes de software.
Incluye tres submodelos, cada uno ofrece un nivel de detalle y aproximación, cada vez mayor,
a medida que avanza el proceso de desarrollo del software: básico, intermedio y detallado.
Para calcular el costo del proyecto se lo realizara haciendo uso del modelo COCOMO II. El
modelo COCOMO, tiene una jerarquía de modelos como ser básico, intermedio y avanzado,
la cual se aplica a tres diferentes tipos de software.
 ORGÁNICO: Proyectos relativamente sencillos, menores a 5000 líneas de código,

implica procesamiento de datos, uso de la base de datos se focaliza en transacciones
y recuperación de datos
 SEMIACOPLADO: Proyectos intermedios en complejidad y tamaño. La
experiencia en ese tipo de proyectos es variable y las restricciones intermedias.
80
 EMPOTRADO: Proyectos bastantes complejos, en los que apenas se tiene
experiencia y en un entorno de gran innovación técnica.
La tabla 5.1 muestra los coeficientes del proyecto de software de acuerdo a los tres modos
expuestos anteriormente.
PROYECTO DE SOFTWARE A B c d
Orgánico 2.1 1.01 2.05 0.34
Semi – acoplado 3.0 1.12 2.05 0.35
Empotrado 3.6 1.20 2.5 0.32
Tabla 5. 1 Coeficiente a y c y los exponentes b y d

Fuente: Pressman, 2002
COCOMO II consta con tres modelos de estimación, los mismos se representan en 3 ecuaciones:
𝑬 = 𝒂(𝑲𝑳𝑫𝑪)𝒃 , 𝒑𝒆𝒓𝒔𝒐𝒏𝒂 − 𝒎𝒆𝒔

𝑫 = 𝒄(𝑬)𝒅 , 𝒆𝒏 𝒎𝒆𝒔𝒆𝒔
𝑷 = 𝑬⁄𝑫 , 𝒑𝒆𝒓𝒔𝒐𝒏𝒂𝒔
Dónde:
E: Esfuerzo requerido por el proyecto expresado en persona-mes.
D: Tiempo requerido por el proyecto expresado en meses.
P: Número de personas requeridas para el proyecto.
a, b, c y d: Constantes con valores definidos según cada sub-modelo.
KLDC: Cantidad de líneas de código, en miles.
81
5.2 COSTO DEL SISTEMA
El costo del sistema se lo planteara en tres partes: desarrollo de software, implementación y

elaboración del proyecto.
5.2.1 COSTO DE DESARROLLO DEL SOFTWARE

Para el cálculo del desarrollo del software se tendrá como partida el punto función no
ajustado.
FACTOR DE PONDERACIÓN
Parámetros Cuenta Simple Medio Complejo TOTAL
N° de Entradas de usuario 15 3 4 6 55
N° de salidas usuario 15 4 4 7 100
N° de peticiones de usuario 17 3 5 5 80
N° de archivos 12 7 7 8 90
Nº de interfaces externas 3 5 8 7 20
TOTAL 265
Tabla 5. 2 Punto función

Fuente:Elaboracion propia
Por lo tanto, el Punto Función es 265
Este resultado se debe convertir a KLDC (Kilos de Líneas de Código), para ello se utiliza la
siguiente la tabla 5.3
LENGUAJE NIVEL FACTOR LDC/PF
C 2.5 128
ANSI BASIC 5 6464
JAVA 6 53
PL/I 4 80
82
ANSI COBOL 74 3 107
VISUAL BASIC 7.00 46
ASP 9.00 36
PHP 11.00 29
VISUAL C++ 9.50 34
Tabla 5. 3 Conversión de puntos de función siguiente

Fuente: Pressman,2002
Como el desarrollo del sistema está basado en PHP entonces se tiene

Factor LDC/PF = 29
Con el factor LDC/PF = 29 y reemplazando este dato más el punto función no ajustada se
calcula en la siguiente ecuación:
𝐿𝐷𝐶
𝐿𝐷𝐶 = 𝑃𝐹 ∗ 𝐹𝑎𝑐𝑡𝑜𝑟 = 265 ∗ 29 = 𝟕𝟔𝟖𝟓
𝑃𝐹
𝑳𝑫𝑪 = 𝟕𝟔𝟖𝟓
Para convertirlo a KLDC dividimos LDC entre 1000
𝐾𝐿𝐷𝐶 = 𝐿DC/1000
𝐾𝐿𝐷𝐶 = 7685/1000
𝑲𝑳𝑫𝑪 = 7,685
A continuación, haremos el cálculo del esfuerzo necesario para la programación del sistema,
para ello utilizamos la siguiente ecuación:
𝑬 = 𝒂 ∗ (𝑲𝑳𝑫𝑪)𝒃 , 𝒆𝒏 𝒑𝒆𝒓𝒔𝒐𝒏𝒂⁄𝒎𝒆𝒔
Para hallar el esfuerzo “E” definimos antes el tipo del proyecto que en nuestro caso es
orgánico y utilizamos de los datos de la tabla 5.1. Con esto se reemplaza en la fórmula:
Dónde:
83
𝐸 = 2.1 ∗ (7,685)1,01
𝑬 = 𝟏𝟔, 𝟒𝟕𝟎𝟗𝟖 𝑝𝑒𝑟𝑠𝑜𝑛𝑎 𝑚𝑒𝑠
Ahora para hallar el tiempo del proyecto usamos los datos de la tabla 5.1, recordando que el
proyecto es de tipo orgánico y reemplazando en la siguiente formula:
𝑫 = 𝒄(𝑬)𝒅 𝒆𝒏 𝒎𝒆𝒔𝒆𝒔
𝐷 = 2.05 ∗ (16,47098)0.34
𝐷 = 5,314
De aquí concluimos que el proyecto deberá tener un desarrollo de 5 meses.

Para calcular la cantidad en número de programadores se utiliza la siguiente formula,
reemplazando los datos ya encontrados:
𝑬
𝑷= , 𝒆𝒏 𝒑𝒆𝒓𝒔𝒐𝒏𝒂𝒔
𝑫
Reemplazando los datos ya conocidos se tiene:

16,47098
𝑃= = 3,099
5,314
P = 3 [programadores]
El salario promedio de un programador oscila entre los 200 a 250 $us, en nuestro caso
tomaremos un promedio de 225$us. A partir de este monto podemos calcular el costo total
del desarrollo del software.
Costo mensual de desarrollo = Nro. De programadores * Salario promedio
Costo mensual de desarrollo = 3 * 225
Costo mensual de desarrollo = 675 $us
Como el desarrollo de software se lo estima en 5 meses resultado que se lo vio anteriormente,

se tiene:
Costo total del desarrollo = Costo mensual de desarrollo * Nro. De meses
84
Costo total del desarrollo = 675 * 5
Costo total del desarrollo = 3.375 $us
5.2.2 COSTO DE IMPLEMENTACIÓN
La farmacia no cuenta con un área de sistemas actualmente al corriente del trabajo diario,
pero si cuenta con una actualización anual para el registro de inventarios por lo cual el costo
de implementación que se tendrá será la configuración de la parte del servidor. El mismo
tendrá un costo de 100Sus.
Costo de Implementación = 100$us
5.2.3 COSTO DE ELABORACIÓN DEL PROYECTO
En la tabla 5.4 se muestra el costo del desarrollo del proyecto haciendo referencia a los gastos.
DETALLE IMPORTE ($us)
Análisis y diseño del proyecto 100
Material de escritorio 20
Internet 30
Otros 20
TOTAL COSTO DEL SISTEMA 170

Tabla 5. 4 Costos de elaboración del Proyecto
Costo de Elaboración del Proyecto = 170$us
5.2.4 COSTO TOTAL DEL SOFTWARE
El costo total del software se muestra de forma detallada en la siguiente tabla:
85
DETALLE IMPORTE ($us)
Costo de desarrollo 3.375
Costo de implementación 100
Costo de elaboración del proyecto 170
TOTAL 273,375
Tabla 5. 5 Costo total de producto de software

5.3 VALOR ACTUAL NETO
El VAN o valor actual neto es un procedimiento que permite calcular el valor presente de un
determinado número de flujos de caja futuros, originados por una inversión. La metodología
consiste en descontar al momento actual (es decir, actualizar mediante una tasa) todos los
flujos de caja futuros del proyecto. A este valor se le resta la inversión inicial, de tal modo
que el valor obtenido es el valor actual neto del proyecto.
La fórmula que utilizaremos para hallar el valor actual neto será:
𝑮𝒂𝒏𝒂𝒏𝒄𝒊𝒂𝒔 𝑪𝒐𝒔𝒕𝒐𝒔
𝑽𝑨𝑵 = ∑ 𝒏
−∑
(𝟏 + 𝑲) (𝟏 + 𝒌)𝒏
Dónde:
VAN: Valor Actual Neto
Ganancias: Ingreso de flujo anual
Costos: Salidas de flujo anual
n: Numero de periodo
k: Tasa de descuento o tasa de interés al préstamo
86
Los gastos y ganancias que se estiman en un lapso de 4 años los mostramos en la tabla 5.6,
para este caso en particular utilizamos una tasa de descuento del 12% ya que es la tasa actual
de interés del préstamo.
Año Costos Ganancias Costos/(𝒌 + 𝟏)𝒏 Ganancias/(𝒌 + 𝟏)𝒏 Resultado
1 273,375 0 8.0808682 0
2 160,675 340,567 179,0989 218,9867 227.94
3 120,9856 420,6745 151.7898 220,556 235.76
4 100,8967 598,6548 100,6746 225,757 321.76
655,92 1359,8963 439,64506 665,2997 170
𝑮𝒂𝒏𝒂𝒏𝒄𝒊𝒂𝒔 𝑪𝒐𝒔𝒕𝒐𝒔 215,375

𝑽𝑨𝑵 = ∑ 𝒏
−∑
(𝟏 + 𝟎. 𝟏𝟐) (𝟏 + 𝟎. 𝟏𝟐)𝒏
Tabla 5. 6 Calculo VAN

Fuente:Elaboracion propia
La tabla 5.6 muestra si un proyecto es rentable y de acuerdo a ciertos criterios más el valor
del VAN concluiremos si es rentable o no.
Valor de VAN INTERPRETACIÓN

VAN > 0 El proyecto es rentable
VAN = 0 El proyecto es rentable porque ya está incorporada
ganancia de la tasa de interés
VAN < 0 El proyecto no es rentable
Tabla 5. 7 Interpretación del VAN
87
De aquí concluimos: considerando que el VAN = 215,375 ≈ 216 y siguiendo los criterios de
la tabla 5.7 se afirma que nuestro proyecto es rentable ya que 216 es mayor a 0.
Como el resultado que obtuvimos es de VAN =215,375 podemos afirmar que nuestro
proyecto es rentable.
5.3.1 COSTO / BENEFICIO
Para hallar el costo/beneficio de un proyecto se aplica la siguiente ecuación:
Costo/Beneficio = ∑ Ganancias / ∑ Costos
De aquí, reemplazando en la ecuación anterior los valores conocidos de la tabla 5.7
Costo/Beneficio = 665,2997 / 439,64506
Costo/Beneficio = 1.52 $.
5.4 TASA INTERNA DE RETORNO
Cuando en la fórmula del VAN el valor de “k” es igual a “0” pasa a llamarse TIR (Tasa
Interna de Retorno). La TIR es la rentabilidad que nos proporciona al proyecto.
La ecuación que utilizaremos es la siguiente:
𝐺𝑎𝑛𝑎𝑛𝑐𝑖𝑎𝑠 − 𝐶𝑜𝑠𝑡𝑜𝑠
𝑇𝐼𝑅 = ∑
(1 − 𝑖)𝑛
Dónde:
TIR: Tasa Interna de Retorno
Ganancias: Flujo de entrada de un periodo
Costos: Flujo de salida de un periodo
i: Tasa de interés al ahorro n: Numero de periodo
La tabla 5.8 muestra una mejor compresión de ecuación TIR y expresando los resultados
encontrados en las misma.
88
AÑO COSTOS GANANCIAS
1 273,375 0 -310,653
2 160,675 340,567 232,298
3 120,9856 420,6745 439,760
4 100,8967 598,6548 830,021
1191,426
Tabla 5. 8 Calculo de la tasa interna de retorno

El proyecto nos dará una rentabilidad de 1191.426 $us.
89
CAPÍTULO VI
CONCLUSIONES Y RECOMENDACIONES
6.1 CONCLUSIONES
Una vez finalizado el proyecto de grado Sistema Integrado Web de Control de Compra, Venta
e Inventarios de Medicamentos para farmacia Maya, se ha logrado alcanzar el objetivo
principal planteado, cumpliendo con las necesidades de la farmacia.
Tomando en cuenta los objetivos planteados se llega a las siguientes conclusiones:
 Se realizó el control de la compra de medicamentos.

 Se logró el control de la disponibilidad de medicamentos en el almacén y en sus
sucursales.
 Se logró desarrollar e implementar un listado detallado que contenga información de
todas las características de los medicamentos y de los proveedores.
 Se logró el control de la venta de medicamentos.
 Se logró realizar los reportes de las ventas y compras.
 Se pudo desarrollar la autentificación de usuarios.
De esta forma, se alcanzó el objetivo general de lograr la informatización de los procesos de

compra, venta e inventario de los medicamentos, de manera que la información ahora se
encuentra a disposición del farmacéutico para hacer el control adecuado a dichos procesos.
Esto se logró mediante la ejecución de las fases propuestas por la metodología ágil Scrum.
6.2 RECOMENDACIONES
A partir del presente trabajo se propone las siguientes recomendaciones, con el fin de
buscar el mejoramiento del sistema:
 Para el mejoramiento de la usabilidad se debería realizar una retroalimentación de las

críticas de usuarios finales.
90
 Realizar un control y seguimiento de los procesos de registro y reportes que brinda el
sistema.
 Se recomienda la utilización de herramientas de programación brindadas por PHP,
debido a la interfaz amigable para el desarrollador.
 La revisión periódica por cierto periodo de tiempo es recomendables para eficiencia
y un funcionamiento adecuado del sistema.
 En cuanto a la farmacia Maya podemos recomendar que en el área de ventas se
implemente un sistema contable.
 Se debe tener cuidad respecto a las claves de acceso al sistema a los usuarios, siempre
mantenerlas seguras y protegidas, también cambiarlas de vez en cuando.
91
BIBLIOGRAFÍA
ARANA, J. 2014 Desarrollo e implementación de un sistema de gestión de ventas de

repuestos automotrices en el almacén de auto repuestos eléctricos marcos en la
parroquia Posorja cantón Guayaquil (tesis de pregrado inédito), Universidad Estatal
Península de Santa Elena Facultad de Sistemas y Telecomunicaciones Escuela de
Informática Carrera de Informática.
BARRERA, G. (2011). Portafolio virtual 6, El Van y el Tir [en línea]. <

https://portafoliovirtual6.wikispaces.com/*Glenda+Lizeth+Barrera+Menjivar*+E
L+VAN+ Y+EL+TIR> [Consulta: 27 de noviembre de 2015].
BARRAZA F, s.a Metodologías de Diseño de Aplicaciones Web Parte B, Maestría en

Ingeniería.
BRAMBILLA M., BUTTI S. (2006). Quince años de desarrollo industrial model-driven de

aplicaciones front-end: desde webml hasta WebRatio e IFML, Politécnico Milano,
Milán Italia
CERI S., (2000). Lenguaje de Modelado Web (WebML): un lenguaje para diseñar sitios
Web,San Francisco Morgan Kauffman Publisher 2000 216p
HERNÁNDEZ J (2010) , Implementación de sistemas de planeación en la producción para

la optimización de inventarios, Ingeniería Industrial, México, Universidad Nacional
Autónoma de México
JARQUÍN, P. S. (2015). Ingeniería Web. [en linea] <http://sevillajarquin.udem.edu.ni/> [

consulta 23 de Mayo 2016].
KNIBERG y SKARIN. (2010). Lo mejor de SCRUM. En Kanbam y SCRUM obteniendo lo

mejor de ambos (123). USA: c4media.
92
MONGUA J., Sandoval H. 2009 Propuesta de un modelo de inventario para la mejora del
ciclo logístico de una distribuidora de confites ubicada en la ciudad de Barcelona,
estado Anzoátegui, Optar al título de Ingeniero de Sistemas, Puerto la Cruz,
Universidad de Oriente.
OLSINA, L. (1999). Metodología Cuantitativa para la Evaluación y la Comparación de la

Calidad de Sitios Web. La Plata. [en línea].
PÁEZ, Nicolás et al. (2014). Construcción de software: una mirada ágil. EDUNTREF.
PALACIO. (2008). “Flexibilidad con SCRUM”. www.lulu.com
PRESSMAN R., (2002), Ingeniería de Software un enfoque práctico, 5ta ed España,

McGraw-Hill, 640 pag.
PRESSMAN R. (2005). Ingeniería de Software, 6ta ed España, McGraw-Hill, 980 pag.

Pressman, R. (2010). Ingeniería de Software. Un enfoque práctico. Mexico: McGraw
Hill. Programación Extrema. [en linea].
SOMMERVILLE, I. (2011). Ingeniería de Software (Novena edición ed.). Mexico.
Tripod. (2015). Programación Extrema. [en linea].
S. MURUGESAN, Y. DESHPANDE, S. Hansen, A. Ginige. “Web Engineering: A New

Discipline for Development of Web-Based Systems.” Lecture Notes in Computer
Science 2016 Springer 2001, pag 3 – 13.
SCHWABER y SUTHERLAND, (2013) “GUIA DE SCRUM” La Guía Definitiva de

SCRUM: La Reglas del Juego.
http://creativecommons.org/licenses/bysa/4.0/legalcode and also described in
summary form at http://creativecommons.org/licenses/by-sa/4.0/.
SCRUMstudy. (2013).” Una guía para el conocimiento de SCRUM (Guía SBOK™)”.

Phoenix, Arizona 85008 USA. Library of Congress Cataloging-in-Publication Data.
93
PROYECTOS DE GRADO
ADUVIRI PEREZ, P. (2016). Sistema web de control de ventas e inventarios caso:

Michelline. L A Paz, Bolivia: Facultad de Ciencias Puras y Naturales.
CACHAGAS VILLEGAS, E. (2017) Sistema web de gestión académica y repositorio virtual

caso: unidad educativa príncipe de luz, La Paz, Bolivia: Facultad de Ciencias Puras
y Naturales.
CARRILLO CRUZ, E. (2017) Sistema web de control de compras, ventas e inventarios caso:
“comercial Ariana”. La Paz, Bolivia: Facultad de Ciencias Puras y Naturales.
CONDORI PALOMEQUE, R. (2015) Sistema web de control de compra, venta e

inventarios, caso: librería de la asociación cristiana pan de vida. La Paz, Bolivia:
Facultad de Ciencias Puras y Naturales.
GUTIERREZ VARGAS, G. (2015) sistema de control de ventas e inventarios para

almacenes de aluminios utilizando dispositivos móviles caso: técnica de aluminio,
vidrio y servicios (talviser). La Paz, Bolivia: Facultad de Ciencias Puras y Naturales.
QUELCA QUISPE, V. (2016) Sistema web de control de compras, ventas e inventarios y

verificación de temperatura de medicamentos usando RFID y alarmas tempranas
caso: “farmacias la casa de salud”. La Paz, Bolivia: Facultad de Ciencias Puras y
Naturales.
QUISBERT MENDOZA, V. (2015) “sistema web de control de ventas e inventarios de

insumos caso: la española. La Paz, Bolivia: Facultad de Ciencias Puras y Naturales
ROJAS LAGUNA, D. (2014) “Sistema web de compras, ventas e inventario caso: empresa
eddymar”.La Paz, Bolivia: Facultad de Ciencias Puras y Natural
94
ANEXOS
95
A1. MARCO LÓGICO
RESUMEN INDICADORES MEDIOS DE SUPUESTOS

NARRATIVO VERIFICACIÓN
FIN Administración Mejoramiento de la El farmacéutico
Implementar un Sistema automatizada en la atención de la interactuará con el
integrado web de control farmacia farmacia sistema para realizar sus
de compras, venta e actividades.
inventarios de
medicamentos para
farmacia Maya
PROPÓSITO - reducción de tiempo - Reportes sobre - Se utilizará un modelo
Mejorar el control de en la realización de existencia de de inventario adecuado a
compra y venta e informes. medicamentos. los requerimientos de la
inventarios, para la - El sistema controlara - toma de decisiones farmacia
ayuda en la toma de el registro y búsqueda con información - que el funcionamiento
decisiones y brindar un de los medicamentos. confiable segura. de la farmacia sea normal
crecimiento económico -Reportes diarios, - La farmacia apruebe el
semanales y software
mensuales emitidos satisfactoriamente.
por el sistema
RESULTADOS - Los inventarios se - Reportes de stock - se cuente con el equipo
- Disminución de tiempo manejan de manera actualizados de computación con el
en la elaboración de más rápida. - reportes de cual sea capaz de
reportes. - los informes que se inventarios, confiable ejecutarse el sistema
- Diseñar una base de emiten reducirán los en un menor tiempo elaborado
datos errores a partir de su - informes y - se cuente con todo el
- Diseñar un modelo de implementación documentos emitidos material de escritorio
inventarios para el por el sistema para emitir los reportes
control de entradas y - La información que brinde el sistema.
salidas de precisa y segura de
medicamentos. las características de
- Diseño de formularios los medicamentos
de seguimiento para los
medicamentos.
- La Creación de la lista
detallada con
información de los
medicamentos.
- Controlar, buscar y
registrar todos los
movimientos de
inventario.
- Realizar un registro de
proveedores para su fácil
ubicación.
96
- Pronosticación el
abastecimiento de
medicamentos.
ACCIONES Recopilación -informes realizados - Recabar datos

- recopilación de Análisis necesarios para poder
información Diseño implementar el software
- análisis Implementación Equipo y así solucionar el
Análisis de datos de computación problema identificado.
Diagnostico - posibilidad de tener
- Diseño acceso a documentos y
Estructurar el sistema informes que permiten su
revisión
A2. ÁRBOL DE PROBLEMAS
97
A3. ÁRBOL DE OBJETIVOS
98
DOCUMENTACIÓN

PG 3652

Cargado por

Copyright:

Formatos disponibles

PG 3652

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

PG 3652

Cargado por

Copyright:

Formatos disponibles

UNIVERSIDAD MAYOR DE SAN ANDRÉS

FACULTAD DE CIENCIAS PURAS Y NATURALES

POSTULANTE: NELLY MARLENE CONDORI VILLALBA

El usuario está autorizado a:

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

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

TODOS LOS DERECHOS RESERVADOS. EL USO NO AUTORIZADO DE LOS

Dedicado con gran amor a mi padre

A mis queridos padres Elías y Paulina por

Quiero expresar mis más sinceros agradecimientos:

El desarrollo de un sistema web dio lugar a un desprendimiento de muchas ideas al ver la

El presente proyecto tiene como finalidad apoyar a la farmacia MAYA, mediante la

El software obtenido es un producto de calidad de acuerdo a la metodología de evaluación

CAPÍTULO I MARCO INTRODUCTORIO

CAPÍTULO II MARCO TEÓRICO

Figura 2. 1 Producto Backlog de SCRUM ........................................................................................ 18

CAPÍTULO III MARCO APLICATIVO

Figura 3. 1 Panificación de implementación del sistema .................................................................. 32

CAPÍTULO II MARCO TEÓRICO

Tabla 2. 1 Elementos del modelo de hipertexto WebML .................................................................. 27

CAPÍTULO III MARCO APLICATIVO

Tabla 3. 1 Pila del Producto .............................................................................................................. 34

CAPÍTULO IV CALIDAD Y SEGURIDAD

CAPÍTULO V ANÁLISIS DE COSTOS Y BENEFICIOS

Hoy en día, la informática se ha convertido en un factor importante de toda empresa, ya sea

Además, el sistema agiliza la obtención de reportes de ventas mensuales, al mismo tiempo,

1.2.1. ANTECEDENTES INSTITUCIONALES

La administración de la farmacia Maya depende del uso de herramientas ofimáticas para el

Al momento de hacer compras a sus proveedores, la verificación de la existencia de los

MISION. - Garantizar la atención integral, integrada y continua de las necesidades y

VISION. - Servicios Farmacéuticos, con atención integral e integrada al Sistema de Salud,

 Brindar atención primaria la comunidad poblacional y el manejo óptimo, racional y

Los servicios ofrecidos por la farmacia, a partir de un diagnóstico adecuado y una

1.2.2. ANTECEDENTES DE PROYECTOS SIMILARES

En la carrera de Informática de la Universidad Mayor de San Andrés (U.M.S.A.) se verificó

Se verificó los siguientes proyectos de grado:

 Título: Sistema web de control de compras, ventas e inventarios y verificación de

 Título: Sistema web de control de inventarios, manufacturación y producto final

1.3. PLANTEAMIENTO DEL PROBLEMA

1.3.1. PROBLEMA CENTRAL

¿Cómo agilizar los procesos de compra, venta e inventarios de medicamentos para la

1.4. DEFINICIÓN DE OBJETIVOS

1.4.1. OBJETIVO GENERAL

1.4.2. OBJETIVOS ESPECÍFICOS

1.5.1. JUSTIFICACIÓN ECONÓMICA

A su vez beneficiara al farmacéutico en la mejora de sus actividades cotidianas respecto a la

1.5.2. JUSTIFICACIÓN SOCIAL

1.5.3. JUSTIFICACIÓN TECNOLÓGICA

El sistema se lo realizara utilizando para la metodología ágil SCRUM y el modelado WebML.

1.6. ALCANCES Y LÍMITES

 El sistema será utilizado solo por el personal de la farmacia Maya.

Para el desarrollo de este proyecto se diseñará un sistema web, para la implementación se

La investigación exploratoria se utilizará para el acercamiento al problema y para la

En la investigación se trabajará con el enfoque inductivo para la observación de los hechos,

Para el desarrollo del proyecto se empleará la metodología ágil de desarrollo de software

Para el modelado se utilizará la metodología web: webML que permitirá modelar la

Para la implementación de este proyecto se utilizará las siguientes herramientas tecnológicas:

2.1. INGENIERÍA DE SOFTWARE

El objetivo principal que busca la ingeniería de software es convertir el desarrollo de software