Sistemas Isabel

INSTITUTO TÉCNICO COMERCIAL INCOS - EL ALTO
CARRERA SISTEMAS INFORMÁTICOS
“SISTEMA DE INFORMACIÓN DE CONTROL DE ALMACÉN,

COMPRA Y VENTA PARA FARMACIA VITAL FARM”
PERFIL DE PROYECTO DE GRADO
PARA OPTAR AL TITULO DE TÉCNICO SUPERIOR EN
ANALISTA DE SISTEMAS INFORMÁTICOS
Postulante: María Isabel Quispe Aduviri
Tutor: Lic. Mary Jeanneth Villamil Peñaloza
Revisor: Ing. Omar Augusto Condori Rivera
El Alto, La Paz – Bolivia
2018
DEDICATORIA
A mi madre Isabel, la mujer que más amo,

quien me apoya y me da fuerza para seguir
adelante y vela para que nunca me falte nada.
A mi hermano Franz a quien quiero mucho
por su cariño y por aguantarme y apoyarme
en esto momentos.
AGRADECIMIENTOS
A DIOS porque gracias a le tengo amigos, amigas y mis estudios, que ellos forman
pilar en mi vida.
A mi familia que sin su apoyo en momentos griticos no hubiese salido adelante, y que
gracias a los consejos de mi madre a ellos principalmente les doy las gracias.
Quiero de gran manera agradecer a la Lic. Mary Jeanneth Villamil Peñaloza por su
paciencia y colaboración en el transcurso de la elaboración del Proyecto de Grado de
igual manera a mi revisor Lic. Omar Augusto Condori Rivera por su apoyo, sugerencias
y observaciones que me ayudaron a superar y alcanzar los objetivos trazados.
Gracias a mis amigos que me apoyaron y de mi parte siempre tendrán alguien

incondicional.
ÍNDICE DE CONTENIDO
Capítulo 1 CAPÍTULO 1 ................................................................................................................................................ 1
1.1. INTRODUCCION.................................................................................................................. 1
1.2. ANTECEDENTES ................................................................................................................ 1
1.2.1. ANTECEDENTES DE LA ENTIDAD................................................................................. 1
1.2.1.1. Visión y Misión de Vital Farm ......................................................................................... 2
1.2.1.2. Organigrama................................................................................................................... 2
1.2.2. ANTECEDENTES DE PROYECTOS AFINES ................................................................. 3
1.3. DESCRIPCIÓN DE OBJETO DE ESTUDIO ....................................................................... 6
1.3.1. Almacén de Productos ...................................................................................................... 6
1.3.2. Venta ................................................................................................................................. 7
1.3.3. Pedido a Laboratorio ......................................................................................................... 9
1.3.4. Compras .......................................................................................................................... 12
1.3.5. Medicamentos ................................................................................................................. 13
1.3.6. Codificación de Medicamentos ....................................................................................... 15
1.4. PLANTEAMIENTO DEL PROBLEMA................................................................................ 15
1.4.1. Problema Principal .......................................................................................................... 16
1.4.2. Problemas Secundarios .................................................................................................. 16
1.5. DEFINICIÓN DE OBJETIVOS ........................................................................................... 17
1.5.1. Objetivo General ............................................................................................................. 17
1.5.2. Objetivos Específicos ...................................................................................................... 17
1.6. JUSTIFICACIÓN ................................................................................................................ 18
1.6.1. Justificación Técnica ....................................................................................................... 18
1.6.2. Justificación Económica .................................................................................................. 18
1.6.3. Justificación Social .......................................................................................................... 18
1.7. ALCANCES Y APORTES .................................................................................................. 19
1.7.1. Alcances .......................................................................................................................... 19
1.7.2. Aportes ............................................................................................................................ 20
1.8. TÉCNICAS, METODOLOGÍAS Y HERRAMIENTAS ........................................................ 20
1.8.1. Técnicas de Investigación ............................................................................................... 20
1.8.1.1. Entrevista ...................................................................................................................... 20
1.8.1.2. Observación ................................................................................................................. 21
1.8.1.3. Documentación ............................................................................................................ 22
1.8.2. METODOLOGÍA DE DESARROLLO ............................................................................. 22
1.8.3. METODOLOGÍA DE INVENTARIO ................................................................................ 23
1.8.4. HERRAMIENTAS DE DESARROLLO ............................................................................ 23
1.8.4.1. Herramienta para la Programación .............................................................................. 23
Capítulo 2 CAPÍTULO 2……….. ...................................................................................................................... ………24
2. INTRODUCCION................................................................................................................... 24
2.1. SISTEMA ............................................................................................................................ 24
2.1.1. SISTEMA DE INFORMACIÓN ........................................................................................ 24
2.1.2 INVENTARIO.................................................................................................................... 25
2.1.3 STOCK ............................................................................................................................. 25
2.1.4. EXISTENCIAS ................................................................................................................. 26
2.1.5. TIPOS DE INVENTARIO ................................................................................................ 26
2.1.6. MÉTODOS DE CONTROL DE INVENTARIOS ............................................................. 28
2.1.7. INGENIERÍA DEL SOFTWARE ...................................................................................... 29
2.2. ANÁLISIS Y DISEÑO ......................................................................................................... 30
2.2.1. ANÁLISIS DEL SISTEMA ............................................................................................... 30
2.2.2. DISEÑO ........................................................................................................................... 30
2.2.3 METODOLOGÍA DE DESARROLLO RATIONAL UNIFIED PROCESS (RUP) ............. 30
2.2.5. HERRAMIENTA LENGUAJE UNIFICADO DE MODELADO (UML) ............................. 37
2.3. BASE DE DATOS............................................................................................................... 46
2.3.1. SISTEMA DE GESTIÓN DE BASE DE DATOS ............................................................. 47
2.3.2. BASE DE DATOS RELACIONAL ................................................................................... 47
2.3.3. SQL SERVER.................................................................................................................. 47
2.3.4. TIPOS DE SENTENCIAS SQL ....................................................................................... 48
2.3.5. TIPOS DE DATOS .......................................................................................................... 48
2.3.6. IDENTIFICADORES........................................................................................................ 48
2.3.7. FUNCIONES PREDEFINIDAS ....................................................................................... 49
2.4. LENGUAJE DE PROGRAMACIÓN VISUAL BASIC ......................................................... 49
2.4.1. APLICACIONES PROCEDURALES............................................................................... 49
2.4.2. APLICACIONES MANEJADAS POR EVENTOS ........................................................... 49
2.5 SEGURIDAD ....................................................................................................................... 50
2.5.1. SEGURIDAD POR CONTRASEÑAS ............................................................................. 51
2.5.1.1 CONCEPTO DE CONTRASEÑA.................................................................................. 51
2.5.1.2 TIPOS DE CONTRASEÑA ........................................................................................... 52
2.5.1.3. ACERCA DE LOS NIVELES DE SEGURIDAD DE CONTRASEÑAS ........................ 53
2.5.2. BACKUP .......................................................................................................................... 53
2.5.2.1. BACKUP EN MEDIOS DE ALMACENAMIENTO MASIVO ........................................ 54
2.5.2.2. BACKUP EN LA NUBE ................................................................................................ 57
2.6. ASPECTO LEGAL .............................................................................................................. 58
2.6.1 DERECHOS DE AUTOR DE DESARROLLO DE SOFTWARE ..................................... 58
Capítulo 3 CAPÍTULO 3 ............................................................................................................................................... 65
3. INTRODUCCIÓN................................................................................................................... 65
3.1. ANÁLISIS............................................................................................................................ 65
3.1.1. ANÁLISIS DE LA SITUACIÓN ACTUAL DEL NEGOCIO .............................................. 65
3.1.2. MODELO DE NEGOCIO ................................................................................................. 66
3.1.2.1. Casos de Uso de Alto Nivel ......................................................................................... 66
3.1.2.2. Diagramas de Caso de Uso ......................................................................................... 70
3.1.2.3. Diagrama de Actividades ............................................................................................. 76
3.1.2.4. Modelo de Objetos ....................................................................................................... 82
3.1.3. MODELO DEL SISTEMA ................................................................................................ 85
3.1.3.1. ANALISIS DE REQUERIMIENTOS ............................................................................. 85
3.1.3.1.1. REQUERIMIENTOS FUNCIONALES GENERAL .................................................... 85
3.1.3.1.2. REQUERIMIENTOS FUNCIONALES ESPECIFICOS ............................................. 86
3.1.3.1.2.1. FUNCIÓN DE ALMACÉN DE PRODUCTOS ........................................................ 86
3.1.3.1.2.2. FUNCIÓN DE VENTA ............................................................................................ 86
3.1.3.1.2.3 .FUNCIÓN DE PEDIDO DE LABORATORIO ........................................................ 87
3.1.3.1.2.4. FUNCIÓN DE COMPRA ........................................................................................ 87
3.1.3.1.2.5 .FUNCIÓN DE CLIENTE......................................................................................... 88
3.1.3.1.2.6 .FUNCIÓN DE CATEGORIA DE PRODUCTOS .................................................... 88
3.1.3.1.2.7. FUNCION DE DEVOLUCION DE PRODUCTOS ................................................. 88
3.1.3.1.3. REQUERIMIENTOS NO FUNCIONALES ................................................................ 89
3.1.4. ACTORES IDENTIFICADOS .......................................................................................... 89
3.1.5. CASOS DE USO DE ALTO NIVEL DEL SISTEMA ....................................................... 91
3.1.6. CASOS DE USO EXPANDIDOS DEL SISTEMA ........................................................... 94
3.1.7. DIAGRAMAS DE CASOS DE USOS EXPANDIDOS DEL SISTEMMA ...................... 101
3.2. DISEÑO ............................................................................................................................ 106
3.2.1. DIAGRAMA DE SECUENCIAS .................................................................................... 106
3.2.2 DIAGRAMAS DE ESTADOS DEL SISTEMA ................................................................ 109
3.2.3. CASOS DE USO REALES............................................................................................ 112
3.2.4. DIAGRAMA DE CLASES .............................................................................................. 120
3.2.5. MODELO ENTIDAD RELACION .................................................................................. 121
3.2.5.1 ESQUEMA DE LA BASE DE DATOS ........................................................................ 122
3.2.5.2. DICCIONARIO DE ENTIDADES ............................................................................... 123
3.3. ANÁLISIS DE COSTOS Y BENEFICIOS ........................................................................ 124
3.3.1. DETERMINACIÓN DE LOS COSTOS ......................................................................... 124
3.3.1.1. COSTO DEL SOFTWARE ......................................................................................... 124
3.3.1.2. COSTO DEL HARDWARE ........................................................................................ 130
3.3.2. ESTIMACIÓN DE BENEFICIOS ................................................................................... 131
3.3.3. ANÁLISIS COSTO BENEFICIOS ................................................................................. 131
3.4. CONCLUSIONES ............................................................................................................. 133
3.5. RECOMENDACIONES .................................................................................................... 134
BIBLIOGRAFIA ........................................................................................................................ 135
ANEXOS .............................................................................................................................. 136
ÍNDICE DE FIGURAS
Figura Nº 1.1: Organigrama ................................................................................................... 2
Figura Nº 1.2: Cuaderno de Registro de Ventas ................................................................... 8
Figura Nº 1.3: Formato de pedido de medicamentos a Laboratorio ..................................... 9
Figura Nº 1.4: Registro de Compras .................................................................................... 12
Figura Nº 1.5: Factura de Compras ..................................................................................... 13
Figura Nº 1.6: Codificación de medicamentos [Fuente: Farmacia Vital Farm] ................... 15
Figura Nº 2.1: Los Casos de Uso integran el trabajo .......................................................... 31
Figura Nº 2.2: Trazabilidad a partir de los Casos de Uso ................................................... 32
Figura Nº 2.3: Evolución de la arquitectura del sistema ...................................................... 33
Figura Nº 2.4: Los modelos se completan, la arquitectura no cambia drásticamente ........ 34
Figura Nº 2.5: Una Iteración RUP ........................................................................................ 35
Figura Nº 2.6: Esfuerzo en actividades según fase del proyecto ........................................ 36
Figura Nº 2.7: Esquema de la clasificación de diagramas .................................................. 42
Figura Nº 3.1: Diagrama de Caso de Uso Almacén de Inventarios .................................... 70
Figura Nº 3.2: Diagramá de Caso de Uso de Ventas .......................................................... 71
Figura Nº 3.3: Diagrama de Caso de Uso de Pedido a Laboratorio ................................... 72
Figura Nº 3.4: Diagrama de Caso de Uso de Compra de Productos a Proveedor ............. 73
Figura Nº 3.5: Diagrama de Caso de Uso Codificación de Productos ................................ 74
Figura Nº 3.6: Diagrama de Caso de Uso Devolución de Productos .................................. 75
Figura Nº 3.7: Diagrama de Actividades de Inventario de Productos en Almacén ............. 76
Figura Nº 3.8: Diagrama de Actividades de Venta de Productos........................................ 77
Figura Nº 3.9: Diagrama de Actividades de Pedido a Laboratorio ...................................... 78
Figura Nº 3.10: Diagrama de Actividades de Compras de Productos ................................ 79
Figura Nº 3.11: Diagrama de Actividades de Categorización de productos por medio de su
codificación ........................................................................................................................... 80
Figura Nº 3.12: Diagramas de Actividades de Devolución de Productos ........................... 81
Figura Nº 3.13: Diagrama de Objetos de Inventario de Almacén de Productos ................. 82
Figura Nº 3.14: Diagrama de Objetos de Venta de Productos ............................................ 82
Figura Nº 3.15: Diagrama de Objetos de Pedido a Laboratorio .......................................... 83
Figura Nº 3.16: Diagrama de Objetos de Compra de Productos ........................................ 83
Figura Nº 3.17: Diagrama de Objetos de Categorización por Medio de Codificación de
Productos .............................................................................................................................. 84
Figura Nº 3.18: Diagrama de Objetos de Devolución de Productos ................................... 84
Figura Nº 3.19: Diagrama de Caso de Uso General ......................................................... 101
Figura Nº 3.20: Diagrama de Caso de Uso de Alto Nivel con Sistema............................. 102
Figura Nº 3.21: Diagrama de Caso de Uso de Venta de Productos de Sistema .............. 103
Figura Nº 3.22: Diagrama de Caso de Uso de Pedido a Laboratorio del Sistema ........... 104
Figura Nº 3.23: Diagrama de Casos de Uso de Compra de Producto de Sistema .......... 105
Figura Nº 3.24: Diagrama de Secuencias de Inventario de Almacén de Productos ........ 106
Figura Nº 3.25: Diagrama de Secuencia de Venta de Productos ..................................... 107
Figura Nº 3.26: Diagrama de Secuencia de Pedido a Laboratorio ................................... 108
Figura Nº 3.27: Diagrama de Secuencias de Compra de Productos ................................ 108
Figura Nº 3.28: Diagrama de Secuencia de Devolución de Productos ............................. 109
Figura Nº 3.29: Diagrama de Estado de Inventario de Almacén ....................................... 110
Figura Nº 3.30: Diagrama de Estado de Venta de Productos ........................................... 110
Figura Nº 3.31: Diagrama de Estado de Pedido a Laboratorio ......................................... 111
Figura Nº 3.32: Diagrama de Estado de Compra de Productos ....................................... 111
Figura Nº 3.33: Ingreso Login ............................................................................................ 113
Figura Nº 3.34: Modulo Almacén de Productos ................................................................. 113
Figura Nº 3.35: Modulo de Venta ....................................................................................... 115
Figura Nº 3.36: Pedido de Laboratorio............................................................................... 117
Figura Nº 3.37: Modulo de Compras.................................................................................. 119
Figura Nº 3.38: Diagrama de Clases ................................................................................. 120
Figura Nº 3.39: Modelo Entidad Relación .......................................................................... 121
ÍNDICE DE TABLAS
Tabla Nº 1.1: Formulario de inventario mensual ................................................................... 7

Tabla Nº 1.2: Lista de proveedores y contactos (responsables) ......................................... 11
Tabla Nº 1.3: Lista de medicamentos más frecuentes ........................................................ 14
Tabla Nº 3.1: Caso de Uso de Alto Nivel Inventarios de Almacén ...................................... 66
Tabla Nº 3.2: Caso de Uso de Alto Nivel Venta de Productos ............................................ 67
Tabla Nº 3.3: Caso de Uso de Alto Nivel Pedido a Laboratorio .......................................... 67
Tabla Nº 3.4: Caso de Uso de Alto Nivel Compra a Proveedor .......................................... 68
Tabla Nº 3.5: Caso de Uso de Alto Nivel Codificación de Medicamentos .......................... 68
Tabla Nº 3.6: Caso de Uso de Devolución de Productos .................................................... 69
Tabla Nº 3.7 : Requerimientos Funcionales General .......................................................... 85
Tabla Nº 3.8: Funciones de Almacén de Productos ............................................................ 86
Tabla Nº 3.9: Función de Ventas ......................................................................................... 86
Tabla Nº 3.10: Función de Pedido de Laboratorio ............................................................... 87
Tabla Nº 3.11: Función de Compra...................................................................................... 87
Tabla Nº 3.12: Función de Cliente ....................................................................................... 88
Tabla Nº 3.13: Función de Productos .................................................................................. 88
Tabla Nº 3.14: Función de Devolución................................................................................. 88
Tabla Nº 3.15: Requerimientos no Funcionales .................................................................. 89
Tabla Nº 3.16: Caso de Uso de Alto Nivel Inventarios de Almacén del Sistema................ 91
Tabla Nº 3.17: Caso de Uso de Alto Nivel Venta de Productos del Sistema...................... 92
Tabla Nº 3.18: Caso de Uso de Alto Nivel Pedido a Laboratorio del Sistema .................... 92
Tabla Nº 3.19: Caso de Uso de Alto Nivel Compra a Proveedor del Sistema .................... 93
Tabla Nº 3.20: Caso de Uso de Alto Nivel Categorización de Productos ........................... 93
Tabla Nº 3.21: Caso de Uso de Devolución de Productos del Sistema.............................. 94
Tabla Nº 3.22: Diagrama de Caso de Uso Expandido de Inventario de Productos en
Almacén ................................................................................................................................ 95
Tabla Nº 3.23: Diagrama de Caso de Uso Expandido de Venta de Productos .................. 96
Tabla Nº 3.24: Diagrama de Caso de Uso Expandido de Pedido a Laboratorio ................ 97
Tabla Nº 3.25: Diagrama de Caso de Uso Expandido de Compra de Productos .............. 98
Tabla Nº 3.26: Diagrama de Caso de Uso Expandido de Categorización de Productos ... 99
Tabla Nº 3.27: Diagrama de Caso de Uso Expandido de Devolución de Productos ....... 100
Tabla Nº 3.28: Diagrama de Caso de Uso Real de Inventario de Productos en Almacén112
Tabla Nº 3.29: Diagrama de Caso de Uso Real de Venta de Productos .......................... 114
Tabla Nº 3.30: Diagrama de Caso de Uso Real de Pedido a Laboratorio: ....................... 116
Tabla Nº 3.31: Diagrama de Caso de Uso Real de Compra de Productos ...................... 118
Tabla Nº 3.32: Diccionario de Entidades ........................................................................... 123
Tabla Nº 3.33: Ajuste de Complejidad de Punto Función ................................................. 125
Tabla Nº 3.34: Calculo de Punto Función Sin Ajustar ....................................................... 126
Tabla Nº 3.35: Conductores de Coste ............................................................................... 127
Tabla Nº 3.3.36: Modelo COCOMO ................................................................................... 127
Tabla Nº 3.37: Costo de Software ...................................................................................... 129
Tabla Nº 3.38: Costo de Hardware .................................................................................... 130
Tabla Nº 3.39: Costo de Investigación ............................................................................... 130
Tabla Nº 3.40:Total Costo de Proyecto.............................................................................. 131
Tabla Nº 3.41. Diagrama de flujo de caja .......................................................................... 132
INTRODUCCIÓN
En la actualidad los sistemas de información han venido evolucionando y la tecnología

ha avanzado más, por lo que se han implementado sistemas computarizados
permitiendo un fácil manejo de datos. Debido a esos avances tecnológicos se realiza
distintos sistemas para darle solución a la demanda de diferentes instituciones.
Los sistemas de información benefician de manera significativa a las pequeñas y

grandes empresas. Con el avance de técnicas de diseño, análisis de sistemas y
lenguajes de programación han permitido la evolución en el desarrollo del software,
mejorando la funcionalidad de estos y la cantidad de operación que realiza.
Las empresas que se dedican a la comercialización de productos farmacéuticos

(compra/venta de medicamentos), llevan a cabo el registro y control de la actividades
comerciales manualmente, pero el tiempo invertido y el recurso humano requerido para
realizar las actividades mencionadas tiene un costo en algunos casos muy elevado, ya
que para realizar el control debe complementar todos los procesos manuales
operativos y administrativos y para ello necesitan:
 Un regente farmacéutico que suministre los productos a los pacientes

 Cajero que cobre por la venta de los fármacos
 Un responsable que generalmente es el propietario que realice las siguientes
funciones:
 Supervise la existencia de ÍTEMS
 Verifique el vencimiento de los productos
 Realice los pedidos al proveedor
 Controle las ventas del personal
 Controle la actualización de los precios de los productos
Por ello el propósito del presente proyecto es apoyar y poner a disposición una
herramienta informática que pueda facilitar y mejorar el trabajo realizado en la farmacia
“VITAL FARM”, de la ciudad de La Paz el cual ayudara al personal que administra
dicha farmacia a realizar en menos tiempo el inventario y control del almacén, ventas
y compras. Optimizando los mismos y poniéndolos a disposición de los clientes en
distintos módulos que representen todos y cada uno de los procesos existentes en una
farmacia, para una correcta toma de decisión.
Capítulo 1 CAPÍTULO 1
GENERALIDADES
1.1. INTRODUCCIÓN
El presente capitulo tiene una breve descripción de los antecedentes de la entidad,

además de la descripción del objeto de estudio donde se detecta los problemas de la
empresa ya sea el principal como también los secundarios.
De acuerdo al estudio y la necesidad de la Farmacia se determina el objetivo principal

como los objetivos secundarios; justificados con la recolección de información, donde
se determina los alcances y aportes que se dará a la empresa.
De acuerdo al estudio y determinación del sistema se describe la metodología que se

usara para la realización del presente proyecto, como solución a los problemas
establecidos.
1.2. ANTECEDENTES
1.2.1. ANTECEDENTES DE LA ENTIDAD
El presente proyecto tiene como fin el estudio a la entidad Farmacia “VITAL FARM“,
que inició sus actividades en agosto del 2016, ubicado en la zona Alto Chijini Av. 9 de
Abril Nro. 829, está a cargo de la Dra. Farmacéutica Cinthya Copa Cossío (propietaria),
quien decidió abrir la misma para ofrecer sus servicios profesionales mediante la
compra y venta de medicamentos al público en general.
La propietaria, se puso en contacto con todos los proveedores necesarios para tener
los productos farmacéuticos y no decepcionar a sus clientes.
Al principio la farmacia debido al poco capital con el que inició sus actividades
comerciales tenia pocos medicamentos como existentes, por lo que fue relativamente
fácil llevar a cabo el registro y control manual de las actividades comerciales de la
misma, en el transcurso de dos años las cantidades de la farmacia fueron creciendo
por existir mucho más movimiento que al principio, por lo que el control de existencias
ya no llego a ser exacto.
1
1.2.1.1. Visión y Misión de Vital Farm
- Visión
Contribuir al bienestar de los ciudadanos creando felicidades y ofreciendo el mejor

servicio farmacéutico con la más alta calidad para el ciudadano de la salud de nuestros
clientes .contando con productos de alta calidad la profesionalidad y amabilidad de
nuestro personal.
- Misión
Ser una institución líder reconocida y distinguida en el mundo farmacéutico de toda

Bolivia por proveer grandes facilidades y compromiso con la satisfacción de nuestros
clientes logrando así la mejor posición en el mercado.
1.2.1.2. Organigrama
Farmacia “VITAL FARM” en su organización interna está formada por propietario
(administrativo) personal de apoyo (auxiliar en enfermería) de dos turnos
correspondientes.
GERENTE /
PROPIETARIO
REGENTE
FARMACÉUTICO
Auxiliar de Auxiliar de
Personal de
Enfermería Enfermería Portero
Limpieza
Turno Mañana Turno Tarde
Figura Nº 1.1: Organigrama
[Fuente: Elaboración Propia]
2
La función de cada una de las áreas es distinta a continuación se describe cada una
de ellas.
1.2.1.2.1. Administración
Está conformada por la propietaria, la cual además cumple como regente farmacéutica
de la farmacia, realiza el control de las ventas, además de los pedidos a laboratorio, a
fin de mes realiza el control de las ventas que se tuvo, los cuales están registrados en
sus cuadernos.
1.2.1.2.2. Auxiliar de enfermería

Se tiene dos auxiliares de distintos turnos, realizan la atención a los clientes, además
de que tienen la función de registrar cada venta que realizan, incluyendo el total de
cada una de las ventas.
También tienen el manejo de caja entonces al final de cada turno deben realizar un
arqueo de las ventas registras.
Realizan un reconteo de los medicamentos, con el fin de hacer notar a administración

cuales de los fármacos ya están por caducar o ya es necesario realizar el pedido a
laboratorio.
1.2.2. ANTECEDENTES DE PROYECTOS AFINES
Después de buscar en la biblioteca de INCOS El Alto, UMSA, UPEA y otras

instituciones de nivel superior se hallaron los siguientes proyectos de grado que serán
referencia para el proyector propuesto:
 TITULO: Sistema de información para control de inventarios de mercadería en

almacenes de la distribuidora “Blusas Charito”
AUTOR: Ximena Poma Sarmiento
INSTITUCIÓN: Incos – El Alto
3
RESUMEN
El sistema consiste en actualizar la información de sus inventarios, realizados

en Visual Basic 2010, en el lenguaje UML este sistema desarrollado mediante
la metodología orientada a objetos, además desarrolla a parte de venta y
compras al proveedor.
SIMILITUD
La similitud es que este sistema se desarrolla en visual Basic, también que se

realiza el control de los almacenes que involucran a compras y ventas.
DIFERENCIA
El sistema es para se desarrolla para un almacén muy amplio lo cual amplia el

conocimiento del uso de sitio web para un control a larga distancia.
 TITULO: Sistema de inventario para el control de microempresa textilera Caso:

“Calofwool”
AUTOR: Juan Carlos Machaca Quenta
INSTITUCIÓN: INCOS – EL ALTO
RESUMEN
Este sistema está realizado en visual Basic, es un sistema de control de

entradas y salidas utilizado un método de inventarios perpetuo con el fin de
controlar las existencias de manera que la microempresa no entre en pérdida.
SIMILITUD
La similitud de este sistema es que el control es dentro de la empresa sin

involucrar rubros afuera además que está realizado en el mismo lenguaje de
programación además que busca la comodidad.
4
DIFERENCIA
La diferencia es que su método de control de inventario es perpetuo el cual este

o lo será ya que debe salir primero los productos de corto vencimiento, además
su base de datos es en Access oldb, el cual lo realizare SQL Server 2008
 TITULO: Sistema web de control de compras, ventas e inventarios caso.

“Comercial Ariana”
AUTOR: Carrillo Cruz Emmi Escaret
INSTITUCIÓN: Universidad Mayor de San Andrés
RESUMEN
A medida que va creciendo la empresa, también crece la cantidad de

información que administra por lo tanto las empresas también requieren tener
control y seguimiento de sus transacciones diarias de forma que puedan tomar
decisiones estratégicas.
El desarrollo del proyecto se basó en las fases propuestas por la metodología

de desarrollo Ágil XP. Lo cual es útil al momento de diseñar las funciones y la
interfaz del usuario. Como herramienta de desarrollo de aplicaciones web se
utilizó el Framework Laravel e su versión 5.4 basado en las normas ISO 9126.
Se desarrolló el inventario de manera sistematizada.
SIMILITUD
La similitud de este sistema es que el control es dentro de la empresa de

inventarios.
DIFERENCIA
La diferencia es que su método de control esta realizado en programación java,

además de que el control está diseñado de manera web lo cual diferencia de
este proyecto ya nuestra área de trabajo es microempresa y aun no requiere de
un servicio vía web.
5
 TITULO: Sistema de control de compra venta e inventarios Caso: “Empresa
Protec”
AUTOR: Sarco Mendoza Mónica
INSTITUCIÓN: UNIVERSIDAD MAYOR DE SAN ANDRÉS
RESUMEN
El proyecto fue desarrollo bajo la metodología Agial XP en sus distintas fases

como son: Planificación diseño desarrollo mediante modelo Web que cuenta
con diversos esquemas para la presentación básica de estos procesos se
realizó bajo el estándar ISO 9126.
SIMILITUD
Este sistema también es aplicable a una empresa en el área de almacenes para

un mejor control óptimo de entradas y salidas de los mismos productos.
DIFERENCIA
La diferencia es que su método de control de inventario se apicara en farmacia

además de que el sistema será realizado en Visual Basic con una base de datos
SQL Server.
1.3. DESCRIPCIÓN DE OBJETO DE ESTUDIO

El estudio del presente proyecto fija su atención en los procesos de manejo de almacén
(inventario), compra, venta de medicamentos los cuales se detallan a continuación:
1.3.1. Almacén de Productos

El control de almacén se la realiza de manera mensual a través de un reconteo físico
de medicamentos existentes, este proceso se respalda por el registro manual (en un
cuaderno) de cada uno de los medicamentos, y está a cargo las auxiliares de farmacia
de ambos turnos tomado en cuenta las fecha de vencimientos de cada uno de los
productos, sin embargo no llega a ser un proceso exacto ya que no está ordenado por
laboratorio y debido a la gran cantidad de medicamentos. Para realizar el reconteo se
cierra la farmacia porque se demora bastante lo cual genera un día menos de ingresos
6
a la farmacia. El formato de inventario de existencias se muestra en la siguiente figura
detallando cada uno de sus campos:
Fecha de
Nro.
vencimiento
Descripción
Laboratorio
Cantidades
Tabla Nº 1.1: Formulario de inventario mensual
[Fuente: Farmacia VITAL FARM]
El personal de la farmacia al realizar el reconteo de medicamentos registra:
 Nro.
 Descripción del mismo especificando su presentación (jarabe, crema, tableta)
 La cantidad que se tiene (enteros, unidades)
 Laboratorio que es el proveedor del medicamento
 Fecha de vencimiento que cuenta, anotando los dos vencimientos más cortos
que el medicamento tiene.
1.3.2. Venta
La venta de medicamentos pues es más accesible para el cliente, ya que la auxiliar le
brinda diferentes opciones en el margen de los precios del medicamento que está
solicitando, una vez realizada la venta se la registra en un cuaderno con el siguiente
detalle.
7
Fecha
Saldo de
caja
Cantidad
Descripción
Total venta
del día
Total venta
Figura Nº 1.2: Cuaderno de Registro de Ventas
[Fuente: Farmacia Vital Farm]
 Fecha del día
 Total caja (venta del día anterior)
 Cantidad vendida
 Descripción del medicamento
 Total en bolivianos
8
 Al final el total de la venta realizada en todo su turno, haciendo un arqueo1 de
todas las ventas.
No llegan a ser exactos los datos que están registrado porque cuando hay mucha
afluencia de clientes no registra por completo de todas las ventas realizadas.
En cobro del total presenta dificultades porque no tiene un precio definido para cada
producto, cuando es en alta cantidad le dificulta sacar el total del cobro, lo cual en
momentos tiene un error al momento de cobro lo que hace variar a su reconteo.
1.3.3. Pedido a Laboratorio
Los pedidos que se realiza a los laboratorios se lo hace de manera escrita tomado solo
prioridad a los medicamentos que se acaba con frecuencia y no asi a los fármacos que
están siendo requeridos en nuevas recetas.
Laboratorio Fecha
Descripción
Especifica
Cantidad ción de
NIT
Figura Nº 1.3: Formato de pedido de medicamentos a Laboratorio
Antes de realizar la lista, primero procede a ver físicamente el stock de cada producto
lo que conlleva la pérdida de tiempo, falta de solicitud de algunos productos.
1 Arqueo de Caja: Es el análisis de las transacciones del efectivo, en un momento

determinado, con el objeto de comprobar si se ha contabilizado todo el efectivo recibido y si el
saldo que arroja esta cuenta corresponde con lo que se encuentra físicamente encaja en
dinero efectivo, cheques o vales.
9
Se realiza el pedido de manera escrita a cada uno de los laboratorios, no especificando
cual es la presentación que se está requiriendo. Lo cual conlleva que traiga de otra
presentación que o estaba siendo solicitada.
Se llama a laboratorio para que este venga por la orden de pedido, la dificultad que
presenta es que a veces pasa por la farmacia para solicitar la orden de compra, y llega
ya a faltar los medicamentos.
Los proveedores con los que se trabaja frecuentemente son los que a continuación se
los mencionara en la siguiente tabla:
LABORATORIOS RESPONSABLES DE PEDIDOS
ALCOS Sr. Juan Vargas
ALFA Dr. Hernán Quispe
ANIL Sr. Miguel Mamani
AMORCA Sr. Angel Perez
APISBOL Sin Proveedor Definido

BAGO Dra. Jimena Andisaval
BIOQUEST Sr. Fernando Copa
BRIMEG Sr. Angel Mendizaval
CHILE Dra. Maria Chirinos

COFAR Sra. Isabel Paye
CRESPAL Dr. Alfredo Pérez

DHOTAR SRL Dra. Janneth Valencia
DELTA No Hay Proveedor Definido
DISMEDIN Dra. Martha Aviles
DISPROMED Sra. Janneth Rodriguez

DROGUERÍA INTI Sr. Adalid Vargas
DULCIFARMA Sr. Ivan Cruz
EL PANAL Dra. Elizabeth Valdez

ESP Dra. Abigail Limachi
FARMACEUTICAS
FARCOS Sr. Omar Fernando Luna
10
FARCOS LTDA. Dra. Ruth Paco
GRAMON Visitador Medico Juan Estrada

HANHEMMAN Dr. Enrique Aliaga
HANSA Visitador Medico Sr.Walter Copa

HIDROFILO BOLIVIA Dra. Paola Romero
IFA Srta. Orieta Quispe
IFARBO Sr. Guillermo Ortiz
IMFAR Dra. Orieta Quisbert

INDACO Sr. Gustavo Mullisaca
LA SANTE Sr. Carlos Villegas
LAFAR Sr Diego Milner
LAQFAGAL Srta. Jimena Mamani
MEDICAL RED Dra.Varinia Blanco
MEGAVIT Sra. Gloria Ecinas Del Pilar
PRODEXA Sr. Angel Cruz
QUIMFA Sr. Franz Torrez
QUIMIZA Sr. Enrique Ortiz
RECALCINE Dra. Isabel Contreras
REINA OBRERA Sr. Adan Mamani

REX Sr.Enrique Perez
SANNEX Dr. Marco Quino
SANT DRUG Dra. Cintia Jimeez
SAVAL Lic. Juan Carlos Mamani
TERBOL Sr.Alberto Quispe
VALENCIA Sr. Antonio Mitma
VIRGEN DE LUJAN Sr. Antonio Paredes
VITA S.A. Srta. Paola Jiménez
Tabla Nº 1.2: Lista de proveedores y contactos (responsables)
11
No tiene un cronograma de pedidos a realizar y además es incierto cuantos
proveedores tiene la farmacia.
1.3.4. Compras
Las compras realizadas a laboratorio son de manera escrita detallada en el anterior
punto el pago dependiendo del laboratorio, siendo algunos con fecha de pago y otros
al contado.
Cada compra es registrada, en cuaderno de compras que detalla la fecha de llegada,

el laboratorio, y el total en bolivianos de la factura
Fecha
Total
en Bs.
Descripción
Figura Nº 1.4: Registro de Compras
La compra a cada laboratorio tiene respaldo su factura la cual llega junto al pedido
realizado.
12
La dificultad de la compra es que no registra cada uno de los medicamentos que
detalla en la factura, cuanto y con qué vencimiento llego cada uno de ellos, solo guarda
una copia de las facturas para poder controlar sus cantidades, no siendo de manera
exacta.
A continuación se muestra una factura de compra a laboratorio:
Figura Nº 1.5: Factura de Compras
1.3.5. Medicamentos
Los medicamentos no están ordenados por presentación ni laboratorio lo cual dificulta
el control de los vencimientos, lo cual genera perdida de los mismos.
No hay un espacio reservado de medicamentos con caducidad próxima, el personal

solo da prioridad a medicamentos con nombre genérico pues ni tiene conocimiento
profundo de los nombres comerciales que los fármacos puedan tener.
La siguiente tabla muestra los medicamentos más frecuentes dentro de la farmacia.
MEDICAMENTOS PRESENTACIÓN
Paracetamol 500mg -1000gm Comprimidos, Jarabe, Unguento
Diclofenaco 50,75,100 Mg. Comprimido, Jarabe, Unguento
Amoxicilina 500 Mg -1 Gr Comprimido Jarabe
13
Carbamazepina 100 Mg Comprimido, Jarabe
Glucovance 500/5 500/2.5 Comprimido
Ambroxol Ad. Ped. Jarabe
Muxol 30 Mg - Ad. - Ped. Comprimido, Jarabe
Novadol Capsula, Ungüento
Colnatur 900gr (Colageno) Polvo
Ampicilina 500 – 1000 Mg Comprimido, Jarabe
Algodón 10-50-100 Gr Insumo
Compresa 5-7-10 Cm Insumo
Caramelos Wira Wira Dulces, Masticables
Dexacofasona Ampolla, Comprimido
Menstisan Ungüento, Jarabe, Pastilla
Nutrilon 400gr- 800gr Polvo
Tabla Nº 1.3: Lista de medicamentos más frecuentes
En el caso de los medicamentos ya caducados, se realiza la devolución a los

laboratorios, bajo el siguiente detalle:
 Si producto vencido es caja entera, el laboratorio hace el cambio del

mismo medicamento con más largo vencimiento siempre y cuando el laboratorio
tenga detallado por convenio.
 Si son unidades las que caducaron el laboratorio realiza la reposición con

distintos medicamentos llegando al costo similar.
 Pero si en su convenio no está la aceptación de devolución, el laboratorio

no repone los mismos, quedando como perdida.
14
1.3.6. Codificación de Medicamentos
La codificación de los medicamentos son realizados en el momento que ingresa

dentro de la farmacia con el siguiente detalle.
 Nombre de la farmacia
 Precio de producto
 Código producto
CFR23
VITAL FARM
23,80
Figura Nº 1.6: Codificación de medicamentos

La codificación realizada es de manera manual, el código de cada producto no

está definido con el código que viene directamente en la factura, además su
precio es modificado, lo cual ya genera desactualización del precio
despachando el producto con el precio codificado.
1.4. PLANTEAMIENTO DEL PROBLEMA

Luego del análisis realizado en la descripción de los procesos que se desarrollan en la
farmacia “VITAL FARM” se pudo identificar el problema central y los problemas
específicos que afectan al manejo de la entidad.
15
La farmacia “VITAL FARM” no tiene un control sistematizado de las compras ventas e
inventarios realiza sus registros de manera manual, además no cuenta con el control
de vencimientos de los productos dicha empresa es nueva en el mercado, lo que
genera que la misma no cuente con un sistema de manejo de sus productos eficiente.
Además, al momento de elaborar sus pedidos, a los respectivos proveedores, llega a
tener un stock elevado de varios medicamentos que son de baja rotación lo que genera
pérdidas monetarias significativas a la entidad, puesto que los mismos caducan
irremediablemente todo aquello debido a que sus existencias son inciertas.
1.4.1. Problema Principal

El control de almacenes de medicamentos en la Farmacia Vita Farm presenta
dificultades debido a que al momento de elaborar los informes de las existencias
disponibles para la venta o para la compra se tiene datos inexactos ya que realizan un
reconteo físico de sus medicamentos mensual con respaldo manual con tendencias a
errores o duplicidad de registros ocasionado pérdida de tiempo ya que a veces es
necesario repetir el reconteo lo cual lleva a pérdida económica ya que se cierran las
puertas al público para realizarlo.
1.4.2. Problemas Secundarios

 Pedidos deficientes lo que conlleva a la falta de medicamentos solicitados o
buscados por los clientes, ya que no tiene un cronograma especifico de días de
pedidos y se desconoce la cantidad exacta de medicamentos faltantes.
 El proceso de registro de compras de medicamentos a los laboratorios es

moroso y en ocasiones no se realiza por la gran cantidad de medicamentos, solo se
mantienen sus las facturas otorgadas por los proveedores, razón por la cual se
desconoce el total de un medicamento.
 El personal no tiene un conocimiento actualizado de los precios de cada

medicamento además de desconocer el hecho de que muchos de los productos
pertenecen a distintos laboratorios generando precios diferentes para un mismo
artículo lo que genera en ocasiones perdidas económicas.
16
 Clientes insatisfechos ya que no cumplen con los requisitos de cada receta
optando a recurrir a otra farmacia, esto genera pérdida económica.
 El personal realiza un arqueo de los ingresos y los gastos que se generan en

un día de trabajo cotidiano, el cual no es exacto ya que no registra todas las ventas
realizadas, lo mismo que genera perdida de información para el control de los
medicamentos.
1.5. DEFINICIÓN DE OBJETIVOS

1.5.1. Objetivo General
Desarrollar e implementar un sistema de información de control de almacén de
medicamentos para la farmacia “VITAL FARM” que brindara información precisa,
evitando la perdida, merma de los medicamentos, además de clientes, así mismo
hacerla más competitiva en el mercado.
1.5.2. Objetivos Específicos

 Diseñar una base de datos para almacenar datos de los productos, pedidos,
ventas, compras, que permita registrar y validar la información.
 Desarrollar un módulo de pedidos de medicamentos de acuerdo a los faltantes

en almacenes, que permita tener el stock de medicamentos a disposición para el
público.
 Desarrollar un módulo de compras que facilite el registro y control de compras

de medicamentos realizadas a los diferentes laboratorios.
 Desarrollar un módulo de almacenes de medicamentos (inventario) que facilite

el control de los datos de cada medicamento, desde su código, nombre, laboratorio,
fecha de vencimiento, así como la cantidad existente para la venta y la cantidad
faltante.
 Desarrollar un módulo de categorías que permita clasificar a cada producto de

acuerdo a su presentación (medicamento, dermatológico, insumos, galénicos, etc.)
 Desarrollar un módulo de ventas que permita agilizar las búsquedas y ventas

de medicamentos.
17
 Brindar reportes oportunos de existencias, faltantes, compras, ventas de
medicamentos a través del desarrollo de un módulo de reportes y consultas.
 Realizar copias de seguridad de la base de datos.
1.6. JUSTIFICACIÓN
1.6.1. Justificación Técnica
La farmacia maneja información de sus compras y ventas plasmadas en un cuaderno
lo cual es sistema permitirá ahorrar tiempo además de que el manejo de mismo solo
abarca una computadora o una laptop, reduce los costos de material de escritorio y
mejora la información de manera actualizada.
El equipo a utilizar es un core i5, tiene una velocidad DMI 2,5 GT/s, es para
ordenadores de escritorio, la cual esta con un Windows 10, el equipo es posible de
soportar el programa a utilizar, no provocara lentitud al software, además que es un
equipo nuevo, no tiene muchas aplicaciones liberando más espacio en la misma.
1.6.2. Justificación Económica

El sistema de información de inventarios pretende efectivizar la administración al
interior de la farmacia , con el fin de disminuir los productos vencidos , además el buen
conocimiento de los mismos para identificar cuáles son de alta, mediana y baja
rotación y asi evitar un exceso en el pedido a proveedores , e invertir capital para
requerimientos innecesarios.
Además se da la solución a la desorganización de los medicamentos, pues la farmacia

sabrá cuando y que cantidad pedir al proveedor el sistema cumplirá con las
expectativas de un buen manejo de almacenes, en el cual se podrá observar el
vencimiento más corto de cada uno de los medicamentos, esto con el control periódico
del responsable de farmacia, también evitado multas de a las autoridades que regula
esta áreas de trabajo
1.6.3. Justificación Social

El uso y empleo adecuado del software propuesto beneficiaria a las personas
comprometidas directa e indirectamente, brindando la comodidad necesaria para
realizar las actividades diarias, llevando a una mejor condición de trabajo ,habiendo
18
que la farmacia eleve su prestigio y resalte entre las demás farmacias a su alrededor,
motivado al uso de los recursos informáticos y capacitándose en los mismos.
1.7. ALCANCES Y APORTES

1.7.1. Alcances
El presente proyecto de grado se basa su estudio en el control de almacenes de
fármacos lo cual está inmerso compra y venta de los mismos.
 En el control de almacenes de medicamentos , se realizara:
- El registro del ingreso a almacén, en el que se incluirán fecha de ingreso, nombre,

descripción, proveedor, cantidad, fecha de caducidad, el código se genera de manera
automática tomado en cuenta el nombre y laboratorio para generar el mismo.
- El registro de salida de almacén, para la venta , en el cual se registra la fecha de

salida, descripción, cantidad, responsable de salida, nombre de cliente a quien se
entrega el fármaco ( la venta del medicamento)
- El módulo de ventas podrá generar reportes para facilitar la facturación manual.
-el modulo permitirá dar listados, búsquedas, estadísticas de los fármacos existentes
dentro la farmacia.
 El proceso de pedido a laboratorio , se realizara:
- El proceso de pedido será mediante un módulo que genera un reporte, el cual se

envía a los laboratorios vía correo electrónico o WhatsApp.
- El pedido involucra mantener un stock dentro la farmacia para o sobrepasar el mismo.
- El pedido a laboratorio se registrara la fecha de compra, código de proveedor,

cantidad, precio unitario, total.
- El pedido podrá ser editado y eliminado por el administrador del sistema.
19
-El módulo de pedido permitirá búsquedas, listados, de pedidos semanales,
mensuales, semestrales para poder realizar un estudio de demanda para el apoyo a
la toma de decisiones.
 En el proceso de ventas , se realizara:
-El realizara el registro de ventas con, fecha de venta, código de medicamento vendido,
cantidad, total, nombre de cliente, NIT o C.I. del cliente.
- La venta podrá ser revisada por el administrador además de que podrá ser modificada
o eliminada.
- El modulo permitirá dar listado búsquedas de las ventas, además de que generara
un reporte de cada venta para poder llenar la factura manual de manera precisa.
1.7.2. Aportes
Además de generar el sistema pues le ayudara a tener un control adecuado de sus
existencias y su registro será muy sencillo.
 El control de almacenes, se aplicara una nueva metodología conocida como

FIFO o PEPS (primeros en entrar primeros en salir) por tratarse de medicamentos que
no deben permanecer almacenados por mucho tiempo.
 En el proceso de ventas, se generara un reporte de cada venta ara asi poder

facturar de manera exacta al cliente.
 Para la implementación del proceso de pedidos a laboratorios, se

proporcionara una nueva modalidad de pedidos los pasos a seguir para evitar errores
en los datos, esto con un manual de funciones el cual especifica el funcionamiento y
el rol del responsable de pedidos.
1.8. TÉCNICAS, METODOLOGÍAS Y HERRAMIENTAS

1.8.1. Técnicas de Investigación
1.8.1.1. Entrevista
En la entrevista se debe generar confianza y comprensión de manera rápida, al mismo
tiempo mantener el control de la entrevista .También al momento se debe vender el
sistema, para lo cual hay que proveer información necesaria al entrevistado.
20
Los pasos a seguir son:
- Informarse de los antecedentes de la entidad.
- Conocer el objeto de estudio el lugar donde se encuentra
- Se estableció preguntas relacionadas al objetivo del sistema
Se aplicó esta técnica de entrevista con la propietaria para asi poder obtener
información y también la confianza de la misma (ver anexo A formato de entrevista).
1.8.1.2. Observación
Esta técnica que consiste en observar atentamente el objeto de estudio , la
observación es un elemento fundamental de todo proceso de investigación; en ella se
apoya el investigador para obtener el mayor número de datos.
Pasos que se debe tener en la observación.
- Determinar objetivo situación o caso que se observa.
- Determinar objetivos de la observación.
- Observar cuidadosa y críticamente.
- Elaborar un informe de la observación realizada.
Informe de observación realizada
A partir de 21 de Abril se inició con la recopilación de información, observado

detenidamente el orden de los medicamentos, el proceso de atención al cliente.
Además de escuchar con atención los precio de cada uno de ellos, si los mismos eran
estándar.
Se pudo observar que cuando realiza la venta y hay mucha afluencia de personas no
registra del todo todas sus vetas no siendo exacto sus datos de ingresos a la farmacia.
Al momento de realizar la solicitud a los proveedores se observó que se le dicta de

manera verbal donde ellos anotan e una hoja de pedido no garantizan su llegada
21
pronta de los medicamentos, el pedido es a crédito no se paga e el momento se queda
en una fecha de pago
Llegando a la conclusión que, la mayor de la dificultades es el control de cuanto

realmente tiene en la farmacia y como evitar su exceso con alguno medicamentos de
baja rotación. (Ver Anexo B Recopilación de Imágenes).
1.8.1.3. Documentación
Consiste en la recopilación de antecedentes informático del objeto de estudio, la
información que la misma maneja la que fundamenta y complementa la investigación.
Se aplicó la recopilación de inventario de los fármacos realizándolos de manera

manual además a obteniendo los recursos que se utilizan.
Se realizó un inventario de la farmacia para asi obtener realmente con cuantos

proveedores se está trabajado y cuantos medicamentos con pronto vencimientos tiene
(ver Anexo C Inventario de Farmacia “Vital Farm”).
1.8.2. METODOLOGÍA DE DESARROLLO

Para guiarnos en el proceso de desarrollo del presente proyecto , será basándose en
la METODOLOGÍA RUP, esta metodología se caracteriza por ser iterativo e
incremental , estar centrado en la arquitectura y guiado por los casos de uso y los
roles.
Principales características:
 Forma disciplina de asignar tareas y responsabilidades
 Pretende implementar las mejores prácticas de ingeniería de software.
 Desarrollo iterativo
 Administración de requisitos
 Uso de arquitectura basada en componentes
 Control de cambios
 Modelo visual del software
22
 Verificación de la calidad del software.
El UML se trata de un estándar que se adoptado, para especificar o para describir

métodos o procesos. Se utiliza para definir un sistema y para detallar los artefactos en
el sistema y para documentar y construir.
1.8.3. METODOLOGÍA DE INVENTARIO

La metodología para el control de inventarios en caso de fármacos será método PEPS
(Primeros en entrar primeros en salir) esta consiste en dar salida los primeros que
ingresaron a la farmacia ya que sus vencimiento son más cortos que el los fármacos
comprados recientemente.
La metodología de aplicación para la programación es el método POO (programación

orientada a objetos), es un paradigma de programación que se usa en sus iteraciones
para diseñar aplicaciones de programas informáticos. Está basado en varias técnicas
incluyendo herencia, cohesión, abstracción, polimorfismo, acopamiento y
encapsulamiento.
1.8.4. HERRAMIENTAS DE DESARROLLO

1.8.4.1. Herramienta para la Programación
Para el desarrollo del sistema se empleara:
 Software de base : Windows 10 de 64 bits
 Software de desarrollo: Visual Basic. NET 2010
 Software de manejo de base de datos : SQL 2008
 Para generar reporte se trabajara con Reporitng Servicies, basada en un

servidor que se incluye con Visual Basic.
23
MARCO REFERENCIAL O CONCEPTUAL
2. INTRODUCCIÓN
En este capítulo podemos resaltar los conceptos más relevantes sobre las
metodologías, métodos y herramientas utilizadas para el desarrollo del presente
proyecto de grado,
2.1. SISTEMA
El sistema es un conjunto de partes o elementos organizados y relacionados que
interactúan entre sí para lograr un objetivo. Cabe aclarar que las cosas o partes que
componen al sistema, no se refieren al campo físico (objetos), sino más bien al
funcional. De este modo las cosas o partes pasan a ser funciones básicas realizadas
por el sistema.
Los sistemas reciben (entrada) como ser datos, (proceso) es lo que transforma una
entrada en salida y (salida) son los resultados que se obtienen a procesar las entradas,
es decir información. (Bertalanffy, 1979).
2.1.1. SISTEMA DE INFORMACIÓN

Un sistema es un conjunto de componentes que interaccionan entre si para lograr un
objetivo común. Aunque existe una gran variedad de sistema la mayoría de ellos
pueden representarse a través de un modelo formando por cinco bloques básicos:
Elementos de entrada, elementos de salida, sección de transformación, mecanismos
de control y objetivos. Los recursos acceden a sistema a través de los elementos de
entrada para ser modificados en la sección de trasformación. Este proceso es
controlado por el mecanismo de control con el fin de lograr el objetivo marcado. Una
vez se ha llevado a cabo la transformación, el resultado sale del sistema a través de
los elementos de salida. (Alarcon, 2006)
Un sistema de información (SI) es un conjunto de elementos organizados y

relacionados y coordinados entre si, encargados de facilitar el funcionamiento global
de una empresa o de cualquier otra actividad humana para conseguir sus objetivos.
(Lopez, 2010)
24
- Entrada de Información: Es el proceso mediante el cual el sistema de información
toma os datos que requiere para procesar la información. Las entradas pueden ser
manuales o automáticas. Las manuales son aquellas que se proporcionan en forma
directa por el usuario, mientras que las automáticas son dato o información que
provienen o son tomaos de otros sistemas o módulos. Este último se denomina
interfaces automáticas. (Pressman, 2007)
Las unidades típicas de entrada de datos a las computadoras son las terminales, las
cintas magnéticas, las unidades de diskette, los códigos de barras, los escáner, la voz,
los monitores sensibles al tacto, el teclado y el mouse, entre otras. (Pressman, 2007)
2.1.2 INVENTARIO
El inventario, es la verificación y control de los materiales o bienes patrimoniales de la
empresa que realizamos para regularizarla cuenta de existencias, para calcular si
hemos tenido pérdidas o ganancias. (Coalla, 2017)
La base fundamental del inventario es el proveer a la empresa de materiales

necesarios, para su continuo y regulas desenvolvimiento, es decir, el inventario tiene
un papel vital para el funcionamiento acorde y coherente dentro del proceso de
producción y de esta forma afrontar la demanda.
En contabilidad, el termino inventario significa una existencia de bienes con propósitos

específicos según la naturaleza de la empresa.
Un inventario puede ser algo tan elemental como una botella de limpiador de vidrios
empleada como parte del programa de mantenimiento de un edificio, o algo más
complejo, como una combinación de materias primas y sub ensamblajes que forman
parte de un proceso de manufactura. (Fernando M. , 2010)
2.1.3 STOCK
Es una acumulación de material y/o de producto final para su posterior venta al cliente.
La gestión del Stock debe ser óptima para que el aprovisionamiento sea efectivo; las
inversiones en stocks inmovilizan unos recursos económicos durante un cierto tiempo,
por lo que en todo momento tenemos que tener en cuenta que la rotación de dichos
productos debe ser efectiva. (Coalla, 2017)
25
2.1.4. EXISTENCIAS
Las existencias son aquellos productos que la empresa tiene en sus instalaciones para
ser vendidas al cliente final o aquellos productos que se van a necesitar en algún
momento en su proceso productivo. (Coalla, 2017)
2.1.5. TIPOS DE INVENTARIO

El siguiente inventario de acuerdo al periodo en que se realice se puede clasificar de
la siguiente forma:
INVENTARIO INICIAL. Es el inventario realizado al inicio de un periodo de producción,

donde se registra todos los bienes de la empresa. Este se realiza al inicio del año fiscal
el 1 de enero. El inventario inicial refleja el saldo de la empresa antes de que inicie las
compras, la producción o antes de que se venda el inventario existente .este se calcula
con la información de los registros contables de la empresa. Con su realización, se
puede determinar luego del inventario final cuales fueron las ganancias o pérdidas de
la empresa. (Serrano, Tecnicas de Almacen, 2015)
INVENTARIO PERIÓDICO .es el inventario que se lleva a cabo cada determinado

tiempo llevando un conteo físico para conocer con claridad la cantidad de inventario
que la empresa posee en un periodo determinado . Con este conteo físico la empresa
conoce el costo de venta y el inventario exacto que posee. Se lleva a cabo al término
de cada periodo ya sea mensual, semestral o anual .El costo de venta que se generó
en un periodo se calcula realizando un juego de inventario, donde se suman las
compras al inventario inicial y liego se resta el inventario final y las devoluciones en
compras una de las desventajas de este inventario es la pérdida del inventario por falta
de control constante. (Serrano, Tecnicas de Almacen, 2015)
- INVENTARIO FINAL. Es el inventario realizado al final o cierre del ejercicio

económico, por lo general se realiza el último día de año fiscal; y sirve para determinar
la nueva situación del capital. Con este se realiza un inventario físico de las
mercaderías o productos con su correspondiente valoración. (Serrano, Tecnicas de
Almacen, 2015)
26
- INVENTARIO PERPETUO. Es el inventario que de manera actualizada demuestra la
cantidad de artículos existente en el almacén de manera detallada. Este lleva un
registro de mercancías en existencia y de las que han sido vendidas con su respectivo
valor, por lo tanto lleva un control de salidas y entradas de mercancías .Este inventario
es muy empleado al momento de realizar balances, provisionales, mensuales o
trimestrales. (Serrano, Tecnicas de Almacen, 2015)
-INVENTARIO INTERMITENTE. Es le inventario realizado varia veces al año.
Inventario Físico. Es el inventario real, que consiste en el conteo, peso y medida de

todos y cada uno de los artículos existentes en almacén. Este conteo puede ser de
materias primas a transportar para su transformación, o de productos para la venta .Se
efectuá como una lista bien detallada de las existencias; tiene como finalidad dar a
conocer a los auditores, que el inventario realizado es del valor activo principal que
muestra el número de mercancías o productos que están en el almacén. Se debe llevar
como mínimo una vez al año. (Serrano, Tecnicas de Almacen, 2015)
- PROCESO DEL INVENTARIO FÍSICO
El inventario físico se hace mediante inspección ocular y recuento de los artículos

almacenados anotando el número de unidades, lotes, referencias, etc., que existen en
el momento del recuento
El inventario es un trabajo de equipo que debe estar organizado por un responsable o

jefe que sepa las tareas que hay que realizar, que prepare con tiempo suficiente el
procedimiento a seguir, material paralas anotaciones y designe los empleados que
realizaran el recuento. (Serrano, 2015)
2.1.4. CONTROL DE INVENTARIOS
Las empresas dedicadas a la compra y venta de mercancías, por ser esta su principal
función y la que dará origen a todas las restantes operaciones, necesitaran de una
constante información resumida y analizada sobre su inventario, lo cual obliga a la
apertura de una serie de cuentas principales y auxiliares relacionadas a esos controles.
Entre estas cuentas podemos nombrar las siguientes: (Pressman, 2007)
27
 Inventario (inicial)
 Compras
 Devoluciones
 Gastos
 Inventario (final )
2.1.6. MÉTODOS DE CONTROL DE INVENTARIOS

Existen numerosa técnicas de valoración de inventarios, sin embargo las comúnmente
utilizadas por las organizaciones dada su utilidad son:
Identificación especifica
- Primeros en Entrar Primeros en Salir
- Últimos en Entrar Primeros en Salir
- Costo promedio o promedio ponderado
Dado que la identificación especifica consiste en la identificación individual de cada

uno de los artículos lo cual incrementa su grado de certeza en igual proporción al grado
de complejidad de su aplicación. (Salazar, 2016)
2.1.6.1 MÉTODO DEL COSTO PRIMERAS EN ENTRADAS, PRIMERAS SALIDAS

(PEPS- FIFO)
El método también llamado “PEPS”, se basa en el supuesto de los primeros artículos
que ingresas en el almacén son los primeros en salir de él.
Bajo el método de primeras entradas, primeras salidas, la entidad debe llevar el

registro del costo de cada unidad utilizando para calcular el costo de los materiales,
bajo PEPS los primeros costos que entran al inventario son los primeros en salir, a eso
se debe el nombre de PEPS, el inventario final se basa en los costos de las compras
más recientes.
La ventaja de aplicar esta técnica consiste en que los inventarios están valorados con
los costos más recientes, dado que los costos más antiguos son los que van
28
conformando a su medida los primeros costos de ventas o producción (costos de
salidas). (Salazar, 2016)
FIFO FÍSICO
Desde el punto de vista de la cadena de suministro que se concentra en el flujo real

de los productos.
Generalmente se considera una buena práctica enviar los productos que se compraron
primero. Al implementar este proceso, las empresas generalmente logran mitigar la
mayoría de las perdidas por vencimientos, siempre que no haya stock excedente de
los bienes. Esta práctica también puede limitar la obsolescencia menor de los
productos asociada con periodos de almacenamiento prolongados. (Lokad, 2007)
ANÁLISIS FIFO
A diferencia del FIFO físico, el análisis FIFO adopta una perspectiva teórica del
inventario, suponiendo que las unidades que se han comprado primero se envían
primero, independientemente del flujo físico real de productos. La perspectiva FIFO
simplifica enormemente el análisis financiero del inventario. (Lokad, 2007)
En la práctica, esto es lo que se necesita para realizar un análisis FIFO:
 los niveles de stock actuales,
 el historial de pedidos de compra con fechas de entrega.
Sobre la base de estos datos, el análisis FIFO proporciona una manera de calcular lo
siguiente:
 valoración de inventario, teniendo en cuenta los precios de compra variables;
 margen bruto esperado, que depende de los precios de compra;
 antigüedad promedio del inventario (y también extremos). (Lokad, 2007)
2.1.7. INGENIERÍA DEL SOFTWARE

La ingeniería del software es una tecnología con varias capas, cualquier enfoque de
ingeniería (incluso la de software) debe basarse en un compromiso organizacional con
la calidad. La administración total de la calidad, Six Sigma y otras filosofías similares
29
alimentan la mejora de la cultura, y esta cultura se lleva en última instancia el desarrollo
de enfoques cada vez más eficaces de la ingeniería de software. El fundamento en el
que se apoya la ingeniería del software es el compromiso con la calidad.
El fundamento para la ingeniería de software es la capa del proceso. El proceso de

ingeniería de software es el aglutinante que une las capas de la tecnología y permite
el desarrollo racional y oportuno del software de cómputo. El proceso define una
estructura que debe establecerse para la obtención eficaz de tecnología de ingeniería
de software y establece el contexto en el que se aplican métodos técnicos, se generan
productos del trabajo (modelos, documentos, datos, reportes, formatos, etc.), se
establecen puntos de referencia, se asegura la calidad y se administra el cambio de
manera apropiada. (Pressman, 2007)
2.2. ANÁLISIS Y DISEÑO

2.2.1. ANÁLISIS DEL SISTEMA
El análisis del sistema constituye una de las actividades primordiales en el desarrollo
de cualquier proyecto de sistemas. Es en esta actividad donde se elaboran todas las
consideraciones técnicas, económicas y legales de un proyecto asi como la
comprensión y solución del problema que se plantea. (Morales, 2005)
2.2.2. DISEÑO
Consiste en planear y desarrollar un nuevo sistema que solucione los problemas
detectados en el sistema actual y los supere ventajosamente. El nuevo sistema puede
limitarse a remendar el sistema actual, pero también puede ser un cambio de grandes
dimensiones. (Morales, 2005)
2.2.3 METODOLOGÍA DE DESARROLLO RATIONAL UNIFIED PROCESS (RUP)

- CARACTERÍSTICAS ESENCIALES
Los autores de RUP destacan que el proceso de software propuesto por RUP tiene
tres características esenciales: está dirigido por los Casos de Uso, está centrado en la
arquitectura, y es iterativo e incremental. (Leteiler, 2007)
30
- PROCESO DIRIGIDO POR CASOS DE USO
Los Casos de Uso son una técnica de captura de requisitos que fuerza a pensar en
términos de importancia para el usuario y no sólo en términos de funciones que sería
bueno contemplar. Se define un Caso de Uso como un fragmento de funcionalidad del
sistema que proporciona al usuario un valor añadido. Los Casos de Uso representan
los requisitos funcionales del sistema.
En RUP los Casos de Uso no son sólo una herramienta para especificar los requisitos
del sistema. También guían su diseño, implementación y prueba. Los Casos de Uso
constituyen un elemento integrador y una guía del trabajo como se muestra en la
Figura 2.
Figura Nº 2.1: Los Casos de Uso integran el trabajo
[FUENTE: Letelier, 200]
Los Casos de Uso no sólo inician el proceso de desarrollo sino que proporcionan un
hilo conductor, permitiendo establecer trazabilidad entre los artefactos que son
generados en las diferentes actividades del proceso de desarrollo.
Como se muestra en la Figura 3, basándose en los Casos de Uso se crean los modelos
de análisis y diseño, luego la implementación que los lleva a cabo, y se verifica que
efectivamente el producto implemente adecuadamente cada Caso de Uso. Todos los
modelos deben estar sincronizados con el modelo de Casos de Uso. (Leteiler, 2007)
31
Figura Nº 2.2: Trazabilidad a partir de los Casos de Uso
[FUENTE: Letelier, 2007]
- PROCESO CENTRADO EN LA ARQUITECTURA
La arquitectura de un sistema es la organización o estructura de sus partes más

relevantes, lo que permite tener una visión común entre todos los involucrados
(desarrolladores y usuarios) y una perspectiva clara del sistema completo, necesaria
para controlar el desarrollo
La arquitectura involucra los aspectos estáticos y dinámicos más significativos del

sistema, está relacionada con la toma de decisiones que indican cómo tiene que ser
construido el sistema y ayuda a determinar en qué orden. Además la definición de la
arquitectura debe tomar en consideración elementos de calidad del sistema,
rendimiento, reutilización y capacidad de evolución por lo que debe ser flexible durante
todo el proceso de desarrollo. La arquitectura se ve influenciada por la plataforma
software, sistema operativo, gestor de bases de datos, protocolos, consideraciones de
desarrollo como sistemas heredados. Muchas de estas restricciones constituyen
requisitos no funcionales del sistema. En el caso de RUP además de utilizar los Casos
de Uso para guiar el proceso se presta especial atención al establecimiento temprano
de una buena arquitectura que no se vea fuertemente impactada ante cambios
posteriores durante la construcción y el mantenimiento.
Cada producto tiene tanto una función como una forma. La función corresponde a la
funcionalidad reflejada en los Casos de Uso y la forma la proporciona la arquitectura.
Existe una interacción entre los Casos de Uso y la arquitectura, los Casos de Uso
32
deben encajar en la arquitectura cuando se llevan a cabo y la arquitectura debe permitir
el desarrollo de todos los Casos de Uso requeridos, actualmente y en el futuro. Esto
provoca que tanto arquitectura como Casos de Uso deban evolucionar en paralelo
durante todo el proceso de desarrollo de software.
Se ilustra la evolución de la arquitectura durante las fases de RUP. Se tiene una

arquitectura más robusta en las fases finales del proyecto. En las fases iniciales lo que
se hace es ir consolidando la arquitectura por medio de baselines y se va modificando
dependiendo de las necesidades del proyecto.
Inception Elaboration Construction Transition
Architecture
tiempo
Figura Nº 2.3: Evolución de la arquitectura del sistema
[FUENTE: (Leteiler, 2007)]
Es conveniente ver el sistema desde diferentes perspectivas para comprender mejor

el diseño por lo que la arquitectura se representa mediante varias vistas que se centran
en aspectos concretos del sistema, abstrayéndose de los demás. Para RUP, todas las
vistas juntas forman el llamado modelo 4+1 de la arquitectura, el cual recibe este
nombre porque lo forman las vistas lógica, de implementación, de proceso y de
despliegue, más la de Casos de Uso que es la que da cohesión a todas. (Leteiler,
2007)
33
Figura Nº 2.4: Los modelos se completan, la arquitectura no cambia drásticamente
Al final de la fase de elaboración se obtiene una baseline2 de la arquitectura donde

fueron seleccionados una serie de Casos de Uso arquitectónicamente relevantes
(aquellos que ayudan a mitigar los riesgos más importantes, aquellos que son los más
importantes para el usuario y aquellos que cubran las funcionalidades significativas)
Como se observa en la Figura , durante la construcción los diversos modelos van
desarrollándose hasta completarse (según se muestra con las formas rellenas en la
esquina superior derecha). La descripción de la arquitectura sin embargo, no debería
cambiar significativamente (abajo a la derecha) debido a que la mayor parte de la
arquitectura se decidió durante la elaboración. Se incorporan pocos cambios a la
arquitectura (indicados con mayor densidad de puntos en la figura inferior derecha)
(Leteiler, 2007).
2 Una baseline es una instantánea del estado de todos los artefactos del proyecto, registrada para
efectos de gestión de configuración y control de cambios.
34
-PROCESO ITERATIVO E INCREMENTAL
El equilibrio correcto entre los Casos de Uso y la arquitectura es algo muy parecido al
equilibrio de la forma y la función en el desarrollo del producto, lo cual se consigue con
el tiempo. Para esto, la estrategia que se propone en RUP es tener un proceso iterativo
e incremental en donde el trabajo se divide en partes más pequeñas o mini proyectos.
Permitiendo que el equilibrio entre Casos de Uso y arquitectura se vaya logrando
durante cada mini proyecto, así durante todo el proceso de desarrollo. Cada mini
proyecto se puede ver como una iteración (un recorrido más o menos completo a lo
largo de todos los flujos de trabajo fundamentales) del cual se obtiene un incremento
que produce un crecimiento en el producto.
Una iteración puede realizarse por medio de una cascada como se muestra en la
Figura 6. Se pasa por los flujos fundamentales (Requisitos, Análisis, Diseño,
Implementación y Pruebas), también existe una planificación de la iteración, un análisis
de la iteración y algunas actividades específicas de la iteración. Al finalizar se realiza
una integración de los resultados con lo obtenido de las iteraciones anteriores.
Figura Nº 2.5: Una Iteración RUP
El proceso iterativo e incremental consta de una secuencia de iteraciones. Cada

iteración aborda una parte de la funcionalidad total, pasando por todos los flujos de
trabajo relevantes y refinando la arquitectura. Cada iteración se analiza cuando
termina. Se puede determinar si han aparecido nuevos requisitos o han cambiado los
existentes, afectando a las iteraciones siguientes. Durante la planificación de los
detalles de la siguiente iteración, el equipo también examina cómo afectarán los
35
riesgos que aún quedan al trabajo en curso. Toda la retroalimentación de la iteración
pasada permite reajustar los objetivos para las siguientes iteraciones. Se continúa con
esta dinámica hasta que se haya finalizado por completo con la versión actual del
producto.
RUP divide el proceso en cuatro fases, dentro de las cuales se realizan varias
iteraciones en número variable según el proyecto y en las que se hace un mayor o
menor hincapié en los distintas actividades. En la Figura 7 se muestra cómo varía el
esfuerzo asociado a las disciplinas según la fase en la que se encuentre el proyecto
RUP.
Figura Nº 2.6: Esfuerzo en actividades según fase del proyecto
Las primeras iteraciones (en las fases de Inicio y Elaboración) se enfocan hacia la
comprensión del problema y la tecnología, la delimitación del ámbito del proyecto, la
eliminación de los riesgos críticos, y al establecimiento de una baseline de la
arquitectura.
Durante la fase de inicio las iteraciones hacen ponen mayor énfasis en actividades
modelado del negocio y de requisitos.
En la fase de elaboración, las iteraciones se orientan al desarrollo de la baseline de la

arquitectura, abarcan más los flujos de trabajo de requerimientos, modelo de negocios
36
(refinamiento), análisis, diseño y una parte de implementación orientado a la baseline
de la arquitectura. (Leteiler, 2007)
En la fase de construcción, se lleva a cabo la construcción del producto por medio de

una serie de iteraciones.
Para cada iteración se selecciona algunos Casos de Uso, se refina su análisis y diseño
y se procede a su implementación y pruebas. Se realiza una pequeña cascada para
cada ciclo. Se realizan tantas iteraciones hasta que se termine la implementación de
la nueva versión del producto.
En la fase de transición se pretende garantizar que se tiene un producto preparado

para su entrega a la comunidad de usuarios.
Como se puede observar en cada fase participan todas las disciplinas, pero que
dependiendo de la fase el esfuerzo dedicado a una disciplina varía. (Leteiler, 2007)
2.2.5. HERRAMIENTA LENGUAJE UNIFICADO DE MODELADO (UML)
El lenguaje unificado de modelado (UML, por sus siglas en inglés, Unified Modeling
Language) es el lenguaje de modelado de sistemas de software más conocido y
utilizado en la actualidad; está respaldado por el Object Management Group (OMG).
Es un lenguaje gráfico para visualizar, especificar, construir y documentar un sistema.

UML ofrece un estándar para describir un "plano" del sistema (modelo), incluyendo
aspectos conceptuales tales como procesos, funciones del sistema, y aspectos
concretos como expresiones de lenguajes de programación, esquemas de bases de
datos y compuestos reciclados.
Es importante remarcar que UML es un "lenguaje de modelado" para especificar o para

describir métodos o procesos. Se utiliza para definir un sistema, para detallar los
artefactos en el sistema y para documentar y construir. En otras palabras, es el
lenguaje en el que está descrito el modelo.
37
Se puede aplicar en el desarrollo de software gran variedad de formas para dar soporte
a una metodología de desarrollo de software (tal como el Proceso Unificado Racional,
Rational Unified Process o RUP), pero no especifica en sí mismo qué metodología o
proceso usar. (Erick, 2010)
UML no puede compararse con la programación estructurada, pues UML significa

Lenguaje Unificado de Modelado, no es programación, solo se diagrama la realidad de
una utilización en un requerimiento. Mientras que programación estructurada es una
forma de programar como lo es la orientación a objetos, la programación orientada a
objetos viene siendo un complemento perfecto de UML, pero no por eso se toma UML
solo para lenguajes orientados a objetos.
UML cuenta con varios tipos de diagramas, los cuales muestran diferentes aspectos
de las entidades representadas. (Erick, 2010)
2.2.5.1. CARACTERÍSTICAS DE UML

 UML es una especificación de notación orientada a objetos. Se basa en las
anteriores especificaciones BOOCH, RUMBAUGH y COAD-YOURDON. Divide
cada proyecto en un número de diagramas que representan las diferentes vistas
del proyecto. Estos diagramas juntos son los que representa la arquitectura del
proyecto.
 UML permite describir un sistema en diferentes niveles de abstracción,
simplificando la complejidad sin perder información, para que tanto usuarios,
líderes y desarrolladores puedan comprender claramente las características de la
aplicación.
 UML se quiere convertir en un lenguaje estándar con el que sea posible modelar
todos los componentes del proceso de desarrollo de aplicaciones. Sin embargo,
hay que tener en cuenta un aspecto importante del modelo: no pretende definir un
modelo estándar de desarrollo, sino únicamente un lenguaje de modelado. Otros
métodos de modelaje como OMT (Object Modeling Technique) o Booch sí definen
procesos concretos. En UML los procesos de desarrollo son diferentes según los
distintos dominios de trabajo; no puede ser el mismo el proceso para crear una
38
aplicación en tiempo real, que el proceso de desarrollo de una aplicación orientada
a gestión, por poner un ejemplo.
 El método del UML recomienda utilizar los procesos que otras metodologías tienen
definidos. (kendall & Fowler, 1999)
2.2.5.2. MODELO
El UML es una técnica de modelado de objetos y como tal supone una abstracción de
un sistema para llegar a construirlo en términos concretos. El modelado no es más que
la construcción de un modelo a partir de una especificación. Un modelo es una
abstracción de algo, que se elabora para comprender ese algo antes de construirlo. El
modelo omite detalles que no resultan esenciales para la comprensión del original y
por lo tanto facilita dicha comprensión. Los modelos se utilizan en muchas actividades
de la vida humana: antes de construir una casa el arquitecto utiliza un plano, los
músicos representan la música en forma de notas musicales, los artistas pintan sobre
el lienzo con carboncillos antes de empezar a utilizar los óleos, etc. Unos y otros
abstraen una realidad compleja sobre unos bocetos, modelos al fin y al cabo. La OMT,
por ejemplo, intenta abstraer la realidad utilizando tres clases de modelos OO: el
modelo de objetos, que describe la estructura estática; el modelo dinámico, con el que
describe las relaciones temporales entre objetos; y el modelo funcional que describe
las relaciones funcionales entre valores. Mediante estas tres fases de construcción de
modelos, se consigue una abstracción de la realidad que tiene en sí misma información
sobre las principales características de ésta.
Los modelos además, al no ser una representación que incluya todos los detalles de
los originales, permiten probar más fácilmente los sistemas que modelan y determinar
los errores. Según se indica en la Metodología OMT (Rumbaugh), los modelos
permiten una mejor comunicación con el cliente por distintas razones:
 Es posible enseñar al cliente una posible aproximación de lo que será el

producto final.
 Proporcionan una primera aproximación al problema que permite visualizar
cómo quedará el resultado.
39
 Reducen la complejidad del original en subconjuntos que son fácilmente
tratables por separado.
Se consigue un modelo completo de la realidad cuando el modelo captura los aspectos
importantes del problema y omite el resto. Los lenguajes de programación que
estamos acostumbrados a utilizar no son adecuados para realizar modelos completos
de sistemas reales porque necesitan una especificación total con detalles que no son
importantes para el algoritmo que están implementando.
Con la creación del UML se persigue obtener un lenguaje que sea capaz de abstraer
cualquier tipo de sistema, sea informático o no, mediante los diagramas, es decir,
mediante representaciones gráficas que contienen toda la información relevante del
sistema. Un diagrama es una representación gráfica de una colección de elementos
del modelo, que habitualmente toma forma de grafo donde los arcos que conectan sus
vértices son las relaciones entre los objetos y los vértices se corresponden con los
elementos del modelo. Los distintos puntos de vista de un sistema real que se quieren
representar para obtener el modelo se dibuja dé forma que se resaltan los detalles
necesarios para entender el sistema. (kendall & Fowler, 1999)
2.2.5.3. DIAGRAMAS
En todos los ámbitos de la ingeniería se construyen modelos, en realidad,
simplificaciones de la realidad, para comprender mejor el sistema que vamos a
desarrollar: los arquitectos utilizan y construyen planos (modelos) de los edificios, los
grandes diseñadores de coches preparan modelos en sistemas CAD/CAM con todos
los detalles y los ingenieros de software deberían igualmente construir modelos de los
sistemas software.
Para la construcción de modelos, hay que centrarse en los detalles relevantes mientras
se ignoran los demás, por lo cual con un único modelo no tenemos bastante. Varios
modelos aportan diferentes vistas de un sistema los cuales nos ayudan a
comprenderlo desde varios frentes. Así, UML recomienda la utilización de nueve
diagramas para representar las distintas vistas de un sistema.
Los diagramas de UML son los siguientes:
40
 Diagrama de Casos de Uso: modela la funcionalidad del sistema agrupándola
en descripciones de acciones ejecutadas por un sistema para obtener un
resultado.
Se utiliza para entender el uso del sistema
Muestra el conjunto de casos de uso y actores (Un actor puede ser tanto un sistema
como una persona) y sus relaciones: es decir, muestra quien puede hacer qué y las
relaciones que existen entre acciones (casos de uso). Son muy importantes para
modelar y organizar el comportamiento del sistema.
 Diagrama de Clases: muestra las clases (descripciones de objetos que

comparten características comunes) que componen el sistema y cómo se
relacionan entre sí.
 Diagrama de Objetos: muestra una serie de objetos (instancias de las clases) y

sus relaciones. A diferencia de los diagramas anteriores, estos diagramas se
enfocan en la perspectiva de casos reales o prototipos. Es un diagrama de
instancias de las clases mostradas en el diagrama de clases.
 Diagrama de Secuencia: enfatiza la interacción entre los objetos y los mensajes

que intercambian entre sí junto con el orden temporal de los mismos.
 Diagrama de Colaboración: igualmente, muestra la interacción entre los objetos

resaltando la organización estructural de los objetos en lugar del orden de los
mensajes intercambiados.
El diagrama de secuencia y el diagrama de colaboración: muestran a los diferentes

objetos y las relaciones que pueden tener entre ellos, los mensajes que se envían
entre ellos. Son dos diagramas diferentes, que se puede pasar de uno a otro sin
pérdida de información, pero que nos dan puntos de vista diferentes del sistema. En
resumen, cualquiera de los dos es un Diagrama de Interacción.
 Diagrama de Estados: Se utiliza para analizar los cambios de estado de los

objetos. Muestra los estados, eventos, transiciones y actividades de los diferentes
objetos. Son útiles en sistemas que reaccionen a eventos.
41
 Diagrama de Actividades: Es un caso especial del diagrama de estados,
simplifica el diagrama de estados modelando el comportamiento mediante flujos de
actividades. Muestra el flujo entre los objetos. Se utilizan para modelar el
funcionamiento del sistema y el flujo de control entre objetos.
 Diagrama de Componentes: muestra la organización y las dependencias entre un

conjunto de componentes. Se usan para agrupar clases en componentes o
módulos.
 Diagrama de Despliegue (o implementación): muestra los dispositivos que se

encuentran en un sistema y su distribución en el mismo. Se utiliza para identificar
Sistemas de Cooperación: Durante el proceso de desarrollo el equipo averiguará
de qué sistemas dependerá el nuevo sistema y que otros sistemas dependerán de
él. (kendall & Fowler, 1999)
2.2.5.4. Clasificación de Diagramas

Se dispone de dos tipos diferentes de diagramas los que dan una vista estática del
sistema y los que dan una visión dinámica.
Figura Nº 2.7: Esquema de la clasificación de diagramas
La práctica de crear diagramas para visualizar sistemas desde perspectivas o vistas

diferentes no está limitado a la industria de la construcción. En el contexto del software,
existen cinco vistas complementarias que son las más importantes para visualizar,
especificar, construir y documentar la arquitectura del software. En el UML las vistas
existentes son:
42
1. Vista casos de uso: se forma con los diagramas de casos de uso, colaboración,
estados y actividades.
2. Vista de diseño: se forma con los diagramas de clases, objetos, colaboración,
3. Vista de procesos: se forma con los diagramas de la vista de diseño. Recalcando
las clases y objetos referentes a procesos.
4. Vista de implementación: se forma con los diagramas de componentes,
colaboración, estados y actividades.
5. Vista de despliegue: se forma con los diagramas de despliegue, interacción,
UML está pensado para el modelado tanto de pequeños sistemas como de sistemas
complejos, y debemos tener en cuenta que los sistemas complejos pueden estar
compuestos por millones de líneas de código y ser realizados por equipos de
centenares de programadores.
En la práctica todos los diagramas son bidimensionales, pero el UML permite crear
diagramas en tres dimensiones como en modelos donde se puede "entrar" al modelo
para poderlo visualizar por dentro.
Con UML nos debemos olvidar del protagonismo excesivo que se le da al diagrama de
clases, este representa una parte importante del sistema, pero solo representa una
vista estática, es decir muestra al sistema parado. Sabemos su estructura pero no
sabemos que le sucede a sus diferentes partes cuando el sistema empieza a funcionar.
(kendall & Fowler, 1999)
2.2.5.5. Diagrama de Casos de Usos

Se emplea para visualizar el comportamiento del sistema, una parte de él o de una
sola clase; y como se relaciona con su entorno. De ésta forma se puede conocer cómo
responde ésa parte del sistema ante un estímulo del ambiente. El diagrama de uso es
muy útil para definir cómo debería ser el comportamiento de una parte del sistema, ya
43
que solo especifica cómo deben comportarse y no como están implementadas las
partes que define.
Un caso de uso especifica un requerimiento funcional.
- Elementos
Un diagrama de casos de uso consta de los siguientes elementos:
 Actor
Un actor es un rol que tiene un usuario con respecto al sistema. Es decir, sería un
usuario del sistema. Es importante destacar el uso de la palabra “rol”, ya que esto
especifica que un actor no necesariamente representa a una persona en particular, si
no la labor que realiza frente al sistema.
 Caso de Uso
Es una operación o tarea específica que se realiza tras una orden o estímulo de un
agente externo, puede ser un actor o desde la invocación desde otro caso de uso.
 Asociación
Es el tipo de relación más básica, indica la invocación desde un actor o caso de uso a
otra operación (caso de uso). Dicha relación se denota con una flecha simple.
Dependencia o Instanciación
Es una forma muy particular de relación entre clases, en la cual una clase depende de
otra, es decir, se instancia (se crea). Dicha relación se denota con una flecha punteada.
Generalización
Este tipo de relación es una de las más utilizadas, cumple una doble función
dependiendo de su estereotipo, que puede ser de Uso (<<uses>>) o de Herencia
(<<extends>>). Este tipo de relación está orientado exclusivamente para casos de uso.
extends: se recomienda utilizar cuando un caso de uso es similar a otro (en
características). Uses: se recomienda utilizar cuando se tiene un conjunto de
características que son similares en más de un caso de uso y no se desea mantener
copiada la descripción de la característica. (Gonzalo, 2009)
44
2.2.5.6. Diagrama de Secuencia
Este diagrama (también llamado diagrama de interacción) muestra las interacciones
entre un conjunto de objetos (clases, actores), ordenadas según el tiempo en que
tienen lugar. Es decir, muestra el orden de las llamadas en el sistema. Se utiliza un
diagrama para cada llamada a representar. Es imposible representar en un solo
diagrama la secuencia de todas las llamadas posibles del sistema, es por ello que se
escoge un punto de partida. El diagrama se compone con los objetos que forman parte
de la secuencia, estos se sitúan en la parte superior de la pantalla, normalmente a la
izquierda se sitúa el que inicia la acción. De estos objetos sale una línea que indica su
vida en el sistema. Esta línea simple se convierte en una línea gruesa cuando
representa que el objeto tiene el foco del sistema, es decir cuando él esta activo.El
objeto puede existir sólo durante la ejecución de la interacción, se puede crear o puede
ser destruido durante la ejecución de la interacción.
En este tipo de diagramas también intervienen los mensajes, que son la forma en que
se comunican los objetos: el objeto origen solicita (llama a) una operación del objeto
destino. El diagrama de secuencia puede ser obtenido de dos partes, desde el
Diagrama Estático de Clases o desde el de Casos de Usos.
- ELEMENTOS
Los componentes de un diagrama de interacción son:
.Línea de vida
Un objeto (o actor) se representa como una línea vertical punteada con un rectángulo
de encabezado y con rectángulos a través de la línea principal que denotan la
ejecución de métodos (activación). El rectángulo de encabezado contiene el nombre
del objeto y el de su clase.
Activación
Muestra el periodo de tiempo en el cual el objeto se encuentra desarrollando alguna
operación, bien sea por sí mismo o por medio de delegación a alguno de sus atributos.
Se denota como un rectángulo delgado sobre la línea de vida del objeto.
45
Mensajes
El envío de mensajes entre objetos se denota mediante una línea sólida dirigida, desde
el objeto que emite el mensaje hacia el objeto que lo ejecuta. Representa la llamada
de un método (operación) de un objeto en particular. También es posible visualizar
llamadas a métodos desde el mismo objeto en estudio.
El presente diagrama es útil para observar la vida de los objetos en el sistema,
identificar llamadas a realizar o posibles errores del modelo estático, que imposibiliten
el flujo de información o de llamadas entre los componentes del sistema. (Gonzalo,
2009)
2.2.5.7. Diagrama de actividad

Son similares a los diagramas de flujos de otras metodologías OO. En realidad se
corresponden con un caso especial de los diagramas de estado donde los estados son
estados de acción (estados con una acción interna y una o más transiciones que
suceden al finalizar esta acción, o lo que es lo mismo, un paso en la ejecución de lo
que será un procedimiento) y las transiciones vienen provocadas por la finalización de
las acciones que tienen lugar en los estados de origen. Siempre van unidos a una clase
o a la implementación de un caso de uso o de un método (que tiene el mismo
significado que en cualquier otra metodología OO). Los diagramas de actividad se
utilizan para mostrar el flujo de operaciones que se desencadenan en un procedimiento
interno del sistema. (kendall & Fowler, 1999)
2.3. BASE DE DATOS

Una base de datos está constituida por un conjunto de información relevante para la
empresa o entidad y los procedimientos para almacenar, controlar, gestionar y
administrar esa información.
Además la información contenida de una base de datos cumple una serie de requisitos
o características.
 Los datos están relacionados, sin redundancias innecesarias.

 Los datos son independientes de los programas que los usan.
 Se emplean métodos determinados para incluir datos nuevos y para borrar,
modificar o recuperar los datos almacenados. (Garcia, 2011)
46
2.3.1. SISTEMA DE GESTIÓN DE BASE DE DATOS
Un sistema de gestión de base de datos es una aplicación comercial que permite
construir y gestionar base de datos, proporcionando al usuario de la base de datos las
herramientas necesarias para realizar, al menos, las siguientes tareas:
 Definir las estructuras de los datos.

 Manipular los datos. Es decir insertar nuevos datos, así como modificar, borrar y
consultar los datos existentes.
 Mantener la integridad de la información
 Proporcionar control de la privacidad y seguridad delos datos de la base de datos,
permitiendo el acceso a los mismos a los usuarios autorizados. (Garcia, 2011)
2.3.2. BASE DE DATOS RELACIONAL

Es una entidad en la cual se puede almacenar datos de manera estructurada, con la
menor redundancia posible. Es un sistema que almacena datos que están
relacionados.
Se define como un conjunto de datos que se encuentran organizados y relacionados

entre sí, con el fin de satisfacer tratamientos de información implicados en las
actividades de una empresa (Garcia, 2011)
2.3.3. SQL SERVER

Todos los principales Sistemas de Gestión de Base de Datos, incorporan un motor
SQL en el servidor de base de datos, así como herramientas de cliente que permiten
enviar comandos SQL para que sean procesadas por el motor del servidor. De esta
forma todas las tareas de gestión de la base de datos (BD) pueden realizarse utilizando
sentencias SQL. (Albert, 2010)
 Consultar datos de la base de datos

 Insertar modificar y borrar datos.
 Crear, modificar y borrar objetos de la base de datos.
 Controlar el acceso a la información
 Garantizar la consistencia de los datos.
47
2.3.4. TIPOS DE SENTENCIAS SQL
Entre los trabajos que se pueden realizar en una base de datos podemos distinguir
dos tipos definición y manipulación de datos por ello se distinguen dos tipos de
sentencias SQL.
-Sentencia de manipulación de datos (Lenguaje de Manipulación de Datos DML) se

utiliza ara:
 Recuperar ( SELECT )
 Actualizar la información
 Añadir filas (INSERT)
 Eliminar filas (DELETE)
 Modificar Filas (UPDATE)
Sentencia de definición de datos (Lenguaje de definición de Datos DDL ), se utiliza

para:
 Crear objetos de base de datos

 Eliminar objetos de lavase de datos
 Modificar objetos de la base de datos
2.3.5. TIPOS DE DATOS

Las columnas de la base de datos almacenan valores que pueden de diversos tipos:
numérico, carácter, fecha, etc.
La mayoría delos productos incluyen tipos de datos extendidos e incluso algunos

productos ofrecen la posibilidad de que el usuario defina sus propios tipos. Todos estos
tipos y posibilidades aparecen documentados en las especificaciones del producto.
(Albert, 2010)
2.3.6. IDENTIFICADORES
Son nombres que sirven para identificar objetos de la base de datos: Usuarios, tablas,
columnas. El estándar define que pueden tener hasta 18 caracteres empezando con
un carácter alfabético y continuando con caracteres numéricos y alfabéticos.
48
En la práctica algunos productos no permiten nombres de usuario de más de ocho
caracteres, pudiendo incluir hasta 30 o más en los nombres de las tablas y columnas.
(Albert, 2010)
2.3.7. FUNCIONES PREDEFINIDAS

En SQL disponemos de funciones predefinidas que devuelven un valor en función de
un argumento que pasa en la llamada. Algunas de estas funciones no se pueden usar
en Access o se llaman de otra manera, la función no modifica el argumento sino que
devuelve un valor creado a partir del argumento que se lo pasa en la llamada. (Albert,
2010)
2.4. LENGUAJE DE PROGRAMACIÓN VISUAL BASIC

Visual Basic es un ambiente grafico de desarrollo de aplicaciones para el sistema
operativo Microsoft Windows .Las aplicaciones creadas en Visual Basic están basadas
en objetos y son manejadas por eventos , se deriva del lenguaje Basic ,el cual es un
lenguaje de programación estructurado , son embargo visual Basic emplea un modelo
de programación manejada por eventos.
2.4.1. APLICACIONES PROCEDURALES

En las aplicaciones tradicionales o procedurales, es la aplicación que controla
proporciones de código se ejecuta, y la secuencia en que esta se ejecuta. La
ejecución de la aplicación se inicia con la primera línea de código, y sigue una
ruta predefinida a través de la aplicación, llamando procedimientos según sea
necesario. (Garcia, 2011)
2.4.2. APLICACIONES MANEJADAS POR EVENTOS

En las aplicaciones manejadas por eventos, la ejecución no sigue una ruta
predefinida. En vez de esto, se ejecutan diferentes secciones de código en respuesta
a eventos. Los eventos se desencadenan por acciones del usuario, por mensajes del
sistema o de otras aplicaciones. La secuencia de eventos determina la secuencia en
el código que se ejecuta. Es por eso que la ruta que sigue el código de la aplicación
es diferente cada vez que se ejecuta el programa.
49
- Métodos
Los métodos son un conjunto de procedimientos que permiten que un objeto ejecute
una acción o tarea sobre sí mismo.
- Eventos
Un evento es una acción que es reconocida por el objeto. Un evento ocurre (se dispara)
como resultado de la interacción del usuario con el objeto. También puede dispararse
debido a la ejecución de código (sentencias) o como resultado de la interacción de otro
objeto con el objeto de poseedor del evento.
- El Entorno Integrado de Desarrollo (IDE)
Cuando se inicia Visual Basic, se crea un proyecto nuevo con un formulario. El IDE de
Visual Basic consta de los siguientes elementos:
Barra de Menús y Barra de Herramientas
Diseñador de formularios
Explorador de Proyectos
Cuadro de Herramientas
Ventana de Código
Ventana de Propiedades (Garcia, 2011)
2.5 SEGURIDAD
La seguridad del software es una actividad de garantía de calidad, que se centra en la
identificación y evaluación de los riesgos potenciales que pueden producir un impacto
negativo y evaluación delos riegos potenciales que pueden producir un impacto
negativo en el software y hacer que falle el sistema completo. Si se pueden identificar
pronto los riesgos en el proceso de ingeniería de software podrán especificarse las
características del diseño del software que permiten eliminar o controlar los riegos
potenciales.
50
El incremento masivo e la utilización pública de sistemas distribuidos han dado lugar
a algunos problemas con la seguridad.
2.5.1. SEGURIDAD POR CONTRASEÑAS

2.5.1.1 CONCEPTO DE CONTRASEÑA
Es una forma de autentificación que utiliza información secreta para controlar el acceso
hacia un recurso. La contraseña debe mantenerse en secreto ante aquellos a quien no
se le permite el acceso. A aquellos que desean acceder la información se les solicita
una clave, conocen o no conocen la contraseña, se concede o se niega el acceso a la
información según sea el caso.
El uso de contraseñas se remonta a la antigüedad: los centinelas que vigilaban una

posición solicitaban el «santo y seña» al que quisiera pasar. Solamente le permiten el
acceso a aquella persona que conoce la seña. En la era tecnológica, las contraseñas
son usadas comúnmente para controlar el acceso a sistemas operativos de
computadoras protegidas, teléfonos celulares, decodificadores de TV por cable,
cajeros automáticos de efectivo, etc. Un típico ordenador puede hacer uso de
contraseñas para diferentes propósitos, incluyendo conexiones a cuentas de usuario,
accediendo al correo electrónico de los servidores, accediendo a bases de datos,
redes, y páginas web, e incluso para leer noticias en los periódicos (diarios)
electrónicos.
En la lengua inglesa se tienen dos denominaciones distintivas para las contraseñas:

password (palabra de acceso) y pass code (código de acceso), donde la primera no
implica necesariamente usar alguna palabra existente (sin embargo, es normal
emplear alguna palabra familiar o de fácil memorización por parte del usuario), la
primera suele asociarse también al uso de códigos alfanuméricos (también llamado
PIT- Personal Identification Text), mientras que la segunda frecuentemente se liga a la
utilización de algún código numérico (asimismo llamado PIN - Personal Identification
Number). (Eduardo, 2018)
51
2.5.1.2 TIPOS DE CONTRASEÑA
- Cadenas de caracteres
En el nivel más básico, las contraseñas son cadenas de caracteres, números y

símbolos. Tener acceso a un teclado proporciona un método para introducir este tipo
de passwords. Las contraseñas pueden ir de las más sencillas, como los tres números
para acceder a ciertas plazas de garaje, hasta las más complicadas combinaciones de
caracteres, números y símbolos que se recomienda emplear para proteger la
información más sensible.
- Cadenas de caracteres más un token
En el siguiente nivel, los passwords requieren una cadena de caracteres, números y

símbolos más un token o ficha de algún tipo. Un ejemplo típico es el de los cajeros
automáticos. Para acceder a éstos se necesita una tarjeta y un número personal
identificativo o PIN. Se consideran más robustos ya que si pierdes u olvidas alguno de
los dos requerimientos tu acceso será denegado.
- Passwords biométricos
El tercer nivel de complejidad son los passwords biométricos. Consisten en utilizar

alguna característica física no reproducible, como las huellas digitales o el aspecto de
la cara, para permitir el acceso. Un ejemplo es el escáner de retina en el cual el interior
del ojo se fotografía para la posterior identificación del sujeto. La retina contiene un
patrón único de distribución de vasos sanguíneos fácilmente apreciable y que se puede
utilizar para la identificación del individuo. Los passwords biométricos son los que se
consideran más sofisticados y más seguros de todos los passwords. Sin embargo, un
password que se pueda transportar en el dedo o en el ojo no tiene porqué ser más
seguro que uno transportado en la cabeza si el software está bien configurado
52
2.5.1.3. ACERCA DE LOS NIVELES DE SEGURIDAD DE CONTRASEÑAS
-Baja: cada contraseña debe tener un mínimo de 5 caracteres. Este es el nivel de

seguridad predeterminado.
-Mediana: cada contraseña debe tener un mínimo de 6 caracteres y cumplir con los
siguientes requisitos:
 Incluir números y letras en mayúsculas y minúsculas

 Incluir un carácter especial que no sea una letra o un número
-Alta: cada contraseña debe tener un mínimo de 6 caracteres y cumplir con los
siguientes requisitos:
 Incluir números y letras en mayúsculas y minúsculas

 Incluir un carácter especial que no sea una letra o un número
 La contraseña vence después de 90 días y la nueva contraseña debe ser
diferente a las 5 contraseñas anteriores
-Personalizada (Professional y Enterprise): cada contraseña debe cumplir los

requisitos que usted ha establecido. Entre las opciones, puede establecer el periodo
antes de que venza la contraseña. Este nivel de seguridad solo está a disposición de
los agentes y administradores.
2.5.2. BACKUP
Copia de seguridad de los archivos, aplicaciones y/o bases de datos disponibles en un
soporte magnético( generalmente discos extraíbles, unidades de cinta), con el fin de
poder recuperar la información en caso de un daño, borrado accidental o un accidente
imprevisto. Es conveniente realizar copias de seguridad y verificación de las mismas a
intervalos temporales fijos, en función al trabajo y la importancia de los datos
manejados
Los respaldos tienen dos propósitos diferentes, el primer propósito es la recuperación

de datos después de su perdida ya sea por la eliminación o corrupción de datos puede
53
ser una experiencia común de los usuarios de computadoras , el segundo propósito
de las copias de seguridad es la recuperación de datos de una época anterior , de
acuerdo con una política de retención de datos definidos por el usuario que por lo
general es configurado en una aplicación de copia de seguridad de cómo se requieren
largos copias de los datos aunque las copias de seguridad representan popularmente
una forma simple de recuperación de desastres y deben formar parte de una plan de
recuperación .
 RECUPERACIÓN DE UN BACKUP INCREMENTAL
–Los ficheros que se han modificado después del último Backus se guardan.
–Se realizan un número menor de copias de ficheros, que requieren una menor
capacidad de almacenamiento y Backus más rápidos.
–Mayor tiempo de recuperación porque resulta necesario deshacer el Backus completo

y todos los incrementales.
 RECUPERACIÓN DE UN BACKUP DIFERENCIAL
–Se copian más ficheros, por lo tanto el Backus lleva más tiempo y usa más espacio
de almacenamiento.
–Las recuperaciones son mucho más rápidas porque sólo conllevan recuperar el
Backus completo y el último de los diferenciales.
2.5.2.1. BACKUP EN MEDIOS DE ALMACENAMIENTO MASIVO
En algún momento, los dispositivos de cintas eran los únicos dispositivos de media de
respaldo que se podían utilizar razonablemente para propósitos de respaldos. Sin
embargo, esto ha cambiado. En seguidas describe los almacenamientos masivos más
comunes.
- Cintas
Las cintas fueron el primer tipo de media removible disponible como medio de
almacenamiento. Tiene los beneficios de bajos costos y una capacidad de
almacenamiento razonablemente buena. Sin embargo, las cintas tienen algunas
54
desventajas - es susceptible a desgastarse y el acceso a los datos en una cinta es por
naturaleza secuencial.
Estos factores implican que es necesario hacer un seguimiento del uso de las cintas
(retirando las cintas una vez que hayan alcanzado el final de su vida útil) y que las
búsquedas de un archivo en cinta pueden ser una tarea bastante lenta.
Por otro lado, las cintas son uno de los medios de almacenamiento masivo menos
costosos disponibles y tienen una larga historia de confiabilidad. Esto significa que
construir una biblioteca de cintas de un buen tamaño no necesita consumir una gran
parte de su presupuesto, y puede contar con poderla utilizar ahora y en un futuro.
- Disco
En años pasados, las unidades de disco nunca se utilizaban como medio para
respaldos. Sin embargo, los precios se han reducido tanto que, en algunos casos, el
uso de discos duros como unidades de respaldo, tiene sentido.
La razón principal para el uso de unidades de disco como medio para respaldos sería
su velocidad. No hay un medio de almacenamiento masivo más rápido disponible. La
velocidad puede ser un factor crítico cuando la ventana para hacer el respaldo de su
centro de datos es corta y la cantidad de datos a copiar es grande.
Pero por varias razones el almacenamiento en disco no es el medio ideal para

respaldos.
Normalmente los discos duros no son removibles. Un factor clave para una estrategia
de respaldo efectiva es que se pueda retirar la media de su centro de datos y en algún
tipo de almacenamiento fuera del sitio. Un respaldo de la base de datos de producción
sentada en un disco duro medio metro más allá de la base de datos misma no es un
respaldo; es una copia. Y las copias no son muy útiles si los datos del centro de datos
y sus contenidos (incluyendo las copias) son dañados o destruidos por algún tipo de
evento desafortunado.
Las unidades de disco duro son costosas (a las menos comparadas con otros tipos de
media). Hay situaciones donde el dinero realmente no es un problema, pero en todos
55
los demás casos, los costos asociados con el uso de discos duros para respaldos
significan que el número de copias de respaldo se debe mantener bajo para así
mantener bajos los costos generales. Menos copias de seguridad significan menos
redundancia si por alguna razón uno de los respaldos no se puede leer.
Los discos duros son frágiles. Aún si hace el gasto adicional de comprar discos
removibles, su fragilidad puede ser un problema. Si se le cae un disco, usted perdió el
respaldo. Es posible comprar estuches especiales que pueden reducir (pero no
eliminar completamente) este peligro, pero esto hace una propuesta costosa aún más
costosa.
Las unidades de disco no son media para archivado. Asumiendo que pueda superar
todos los otros problemas asociados con la realización de respaldos a unidades de
disco, debería considerar lo siguiente. La mayoría de las organizaciones tienen varios
requerimientos legales para mantener los registros disponibles por cierto tiempo. Las
posibilidades de obtener data utilizable desde una cinta de 20 años son mucho más
grandes que las posibilidades de hacerlo desde un disco de 20 años.
- Red
Por sí misma, una red no puede actuar como una media de respaldo. Pero combinada
con tecnologías de almacenamiento masivo, puede hacerlo muy bien. Por ejemplo,
combinando un enlace de red de gran velocidad a un centro de datos remoto
conteniendo grandes cantidades de almacenamiento en disco, repentinamente las
desventajas sobre el respaldo a discos mencionados anteriormente, dejan de ser
desventajas.
Al hacer respaldos sobre la red, las unidades de disco ya se encuentran en otra

ubicación, fuera del sitio, por lo que no es necesario transportar unidades de discos
frágiles a otro lado. Con suficiente ancho de banda, se mantiene la ventaja de la
velocidad que puede obtener por hacer los respaldos a discos.
Sin embargo, este enfoque todavía no soluciona el problema del almacenamiento de

los archivo (aunque se puede utilizar el mismo enfoque de copiar a las cintas luego de
hacer el respaldo, como se mencionó anteriormente). Además, los costos de un centro
56
de datos remoto con un enlace de alta velocidad al centro de datos principal hace esta
solución extremadamente costosa. Pero para los tipos de organización que necesitan
el tipo de funcionalidades que esta solución ofrece, es un costo que pagarían con
gusto. (Fernando A. , 2010)
2.5.2.2. BACKUP EN LA NUBE

El almacenamiento en la nube es un modelo de informática en la nube que almacena
datos en Internet a través de un proveedor de informática en la nube que administra y
opera el almacenamiento en la nube como un servicio. Se ofrece bajo demanda con
capacidad y costo oportunos, y elimina la necesidad de tener que comprar y
administrar su propia infraestructura de almacenamiento de datos. Esto le otorga
agilidad, escala global y durabilidad con acceso a los datos en cualquier momento y
lugar. (Fernando A. , 2010)
- FUNCIONAMIENTO DEL ALMACENAMIENTO EN LA NUBE
El almacenamiento en la nube se compra a un proveedor de la nube externo que posee

y opera capacidad de almacenamiento de datos y la distribuye a través de Internet con
un modelo de pago por uso. Estos proveedores de almacenamiento en la nube
administran la capacidad, la seguridad y la durabilidad para lograr que sus aplicaciones
de todo el mundo tengan acceso a los datos.
Las aplicaciones obtienen acceso al almacenamiento en la nube mediante protocolos

de almacenamiento tradicionales o directamente mediante una API. Muchos
proveedores ofrecen servicios complementarios diseñados para ayudar a recopilar,
administrar, proteger y analizar datos a gran escala. (Fernando A. , 2010)
- TIPOS DE ALMACENAMIENTO EN LA NUBE
Existen tres tipos de almacenamiento de datos en la nube: almacenamiento de objetos,

de archivos y en bloque. Cada uno ofrece sus propios beneficios y casos de uso:
1. Almacenamiento de objetos: Con frecuencia, las aplicaciones desarrolladas en la

nube aprovechan la gran escalabilidad y las características de metadatos del
almacenamiento de objetos.
57
2. Almacenamiento de archivos: algunas aplicaciones necesitan obtener acceso a
archivos compartidos y requieren un sistema de archivos. A menudo, este tipo de
almacenamiento cuenta con un servidor de almacenamiento conectado a la red (NAS).
3. Almacenamiento en bloque: otras aplicaciones empresariales, como bases de

datos o sistemas de planificación de recursos empresariales (ERP), a menudo
requieren almacenamiento dedicado y de baja latencia para cada host. Esto es similar
al almacenamiento conectado directamente (DAS) o una red de área de
almacenamiento (SAN). Las soluciones de almacenamiento en la nube basadas en
bloques. (Fernando A. , 2010)
2.6. ASPECTO LEGAL

2.6.1 DERECHOS DE AUTOR DE DESARROLLO DE SOFTWARE
- LICENCIA PÚBLICA GENERAL
(De Consideraciones y Registro de Software Libre en Bolivia (LPG-Bolivia))
Introducción
Esta licencia está basada en la Licencia Pública General GNU (GNU GPL) de la
Fundación para el Software Libre (www.fsf.org), la cual ha sido adaptada por la
Agencia para el Desarrollo de la Sociedad de la Información en Bolivia (ADSIB) a la
normativa legal vigente en Bolivia, enmarcada en la Ley General de
Telecomunicaciones, Tecnologías de Información y Comunicación, Ley No. 164 de 8
de agosto de 2011 y el Reglamento para el Desarrollo de Tecnologías de Información
y Comunicación aprobado por el Decreto Supremo No. 1793 de 13 de noviembre de
2013. Ésta no constituye una traducción oficial de la GNU GPL al español. No ha sido
publicada por la Fundación para el Software Libre, y no establece legalmente las
condiciones de distribución para el software que usa la GNU GPL –estas condiciones
se establecen solamente por el texto original de la GNU GPL de la Fundación para el
Software Libre (www.fsf.org).Esta licencia se aplica conforme a la legislación vigente
y en orden de prelación normativa dando prioridad a lo normativa superior y sin
vulnerar cualquier derecho consagrado por la Constitución y las Leyes del Estado
58
Plurinacional de Bolivia. Esta licencia se basa en la traducción elaborada por Gonzalo
Abella, Javier Aguirre, Héctor J. Macho Borja Menéndez, Javier Moset, Ángel Torrado.
Preámbulo
La Licencia Pública General Bolivia (LPG - Bolivia) es una licencia libre para software
y otro tipo de obras.
(1) Las licencias para la mayoría del software y otras obras de carácter práctico están
diseñadas para privarle de la libertad de compartir y modificar las obras. Por el
contrario, esta Licencia Pública General pretende garantizar su libertad de compartir y
modificar todas las versiones de un programa –para cerciorar que permanece como
software libre para todos sus usuarios. Cuando hablamos de software libre, nos
referimos a libertad de acción, no de precio. La LPG - Bolivia está diseñada para
garantizar la libertad de distribuir copias de software libre (y cobrar por ello si quiere),
de recibir el código fuente o poder conseguirlo si así lo desea, de modificar el software
o usar parte del mismo en nuevos programas libres, y a saber que puede hacer estas
cosas. Para proteger sus derechos, necesitamos evitar que otros le nieguen esos
derechos o le pidan renunciar a ellos. Por lo tanto, usted tiene ciertas
responsabilidades cuando distribuye copias del software, o si lo modifica:
responsabilidades que persiguen respetar la libertad de otros. Si distribuye copias de
un programa, bien sea gratis o por una tasa, debe transferirles a los que lo reciban las
mismas libertades que usted recibió. Debe asegurarse que ellos, también, reciben o
pueden obtener el código fuente. Y debe mostrarles estos términos para que ellos
puedan conocer sus derechos.
Los desarrolladores que usan la LPG-Bolivia protegen tus derechos con dos pasos: (1)
haciendo valer el derecho de propiedad intelectual en el software y (2) le ofrecen esta
Licencia que le da el permiso legal para copiarlo, distribuirlo y/o modificarlo. Para la
protección de autores y desarrolladores, la LPG-Bolivia explica claramente que no hay
garantía para este software libre. Por el bien de usuarios como de autores o titulares,
la LPG Bolivia establece que las versiones modificadas sean identificadas como tales,
de forma que sus problemas no puedan ser atribuidos de forma errónea a autores de
versiones previas. Algunos dispositivos están diseñados para denegar a los usuarios
59
el acceso a instalar o ejecutar versiones modificadas del software en su interior, a
pesar de que el fabricante puede hacerlo. Esto es fundamentalmente incompatible con
el objetivo de proteger la libertad de los usuarios de modificar el software. Este tipo de
abuso sistemático ocurre en el ámbito de los productos de uso personal, que es
precisamente donde es más inaceptable. Por consiguiente, hemos diseñado esta
versión de la LPG-Bolivia para prohibir estas prácticas en esos productos. Finalmente,
todo programa está constantemente amenazado por las patentes de software. El
Estado buscará los medios más idóneos para evitar el especial peligro que suponen
las patentes, que aplicadas a un programa libre puedan hacerlo propietario en la
práctica. Para prevenir eso, la LPG-Bolivia establece que las patentes no pueden
usarse para convertir un programa en no-libre. Los términos exactos y las condiciones
para la copia, distribución y modificación se exponen a continuación.
1. Código Fuente
El "código fuente" de una obra es el formato preferido de la misma para realizar

modificaciones sobre ella. "Código objeto" se refiere a cualquier formato de la obra que
no sea código fuente. Una "Interfaz Estándar" se refiere a una interfaz que sea un
estándar oficial definido por una institución de estándares reconocida, o bien, en el
caso de interfaces específicas para un determinado lenguaje de programación, una
cuyo uso esté generalizado entre los desarrolladores que trabajan con ese lenguaje.
Las “Bibliotecas del Sistema” de una obra ejecutable incluyen cualquier cosa, diferente
de la obra como un todo, que (a) está incluida en la forma normal de empaquetado de
un Componente Importante, pero que no forme parte de ese Componente Importante,
y (b) sirve solo para habilitar el uso de la obra con ese Componente Importante, o para
implementar una Interfaz Estándar para la cual una implementación está disponible
para el público en forma de código fuente. Un “Componente Importante”, en este
contexto, significa un componente importante esencial (kernel, sistema de ventanas,
etcétera) del sistema operativo en concreto (si hubiese) en el cual el ejecutable
funciona o un compilador utilizado para producir la obra, o un intérprete de código
objeto utilizado para hacerla funcionar.
60
La “Fuente Correspondiente” de una obra en forma de código objeto significa todo el
código fuente necesario para generar, instalar, y (para una obra ejecutable) hacer
funcionar el código objeto y modificar la obra, incluyendo los scripts o guiones o
archivos de órdenes para controlar dichas actividades. Sin embargo, ello no incluye la
obra de las Bibliotecas del Sistema o herramientas de propósito general o programas
de libre disponibilidad general, los cuales son usados sin modificaciones para la
realización de dichas actividades, pero que no son parte de la obra. Por ejemplo, la
Fuente Correspondiente incluye ficheros de definición de interfaces asociados a los
ficheros fuente para la obra, y el código fuente para bibliotecas compartidas y
subprogramas enlazados dinámicamente que la obra requiere específicamente por
diseño, tales como la comunicación de datos intrínseca o flujo de control entre aquellos
subprogramas y otras partes de la obra.
La Fuente Correspondiente no incluye necesariamente aquello que los usuarios

pueden regenerar automáticamente a partir de otras partes de la Fuente
Correspondiente.
La Fuente Correspondiente de una obra en forma de código fuente es la obra en sí.
2. Permisos Básicos
Todos los derechos concedidos bajo esta Licencia se conceden durante la duración
de los derechos de autor (“copyright”) del Programa, y son irrevocables siempre que
se cumplan las condiciones establecidas. Esta Licencia afirma explícitamente su
permiso ilimitado para ejecutar el Programa sin modificar. El resultado de la ejecución
de una obra amparada está cubierta por esta Licencia solo si el mismo, dado su
contenido, constituye una obra amparada. Esta Licencia reconoce sus derechos de
uso razonable u otro equivalente, según lo establecido por la ley de derechos de autor
(“copyright”). Usted podrá realizar, ejecutar y difundir obras amparadas que usted no
transmita sin condición alguna, siempre y cuando la Licencia vigente no establezca
otra cosa. Podrá transmitir obras amparadas a terceros con el único propósito de que
ellos hagan modificaciones exclusivamente para usted, o proporcionarle ayuda para
ejecutar estas obras, siempre y cuando cumpla con los términos de esta Licencia en
la transmisión de todo el material del cual usted no controle los derechos de autor
61
(“copyright”). Aquellos que realicen o ejecuten las obras amparadas para usted, deben
hacerlo exclusivamente en su nombre, bajo su dirección y control, en términos que
prohíban realizar ninguna copia de su materia registrado bajo derechos de autor
(“copyright”) fuera de la relación con usted. La transmisión bajo otras circunstancias se
permite únicamente bajo las condiciones establecidas más abajo. No está permitido
sublicenciar; la cláusula 10 lo hace innecesario. (ADSIB, 2014)
3. Protección de Derechos Legales de los Usuarios Frente a Leyes Anti-Evasión.
Ninguna obra amparada debe considerarse parte de una medida tecnológica efectiva,
a tenor de lo establecido en cualquier ley aplicable que cumpla las obligaciones
establecidas en el artículo 11 del tratado de derechos de autor (“copyright”) de WIPO
adoptado el 20 de diciembre de 1996, por el hoy Estado Plurinacional de Bolivia o leyes
similares que prohíban o restrinjan la evasión de tales medidas. Cuando transmita una
obra amparada, renuncia a cualquier poder legal para prohibir la evasión de medidas
tecnológicas, mientras tales evasiones se realicen en ejercicio de derechos amparados
por esta Licencia respecto a la obra amparada; además, usted renuncia a cualquier
intención de limitar el uso o modificación de la obra con el objetivo de imponer, en
contra de los usuarios de la obra, sus derechos legales o los de terceros para prohibir
la evasión de medidas tecnológicas (ADSIB, 2014)
7. Condiciones adicionales
Los “Permisos adicionales” son condiciones que complementan los términos de esta
Licencia haciendo excepciones de una o más de una de sus condiciones. Los permisos
adicionales que son aplicables al Programa entero deberán ser tratados como si
estuvieran incluidos en esta Licencia, hasta los límites de validez impuestos por las
leyes aplicables. Si los permisos adicionales sólo son aplicables a parte del Programa,
esa parte debe ser usada por separado bajo esos permisos, pero el Programa
completo queda bajo la autoridad de esta Licencia sin considerar los permisos
adicionales. Cuando transmita una copia de una obra amparada, puede opcionalmente
quitar cualesquiera permisos adicionales de esa copia, o de cualquier parte de ella.
(Los permisos adicionales pueden ser escritos para requerir su propia eliminación bajo
ciertos casos cuando se modifica la obra.) Puede incorporar permisos adicionales a
62
material añadido por usted a una obra amparada, sobre el cual usted tiene o puede
establecer los permisos de derechos de autor (“copyright”) correspondientes.
Sin contravenir cualquier otra disposición de esta Licencia, para el material que añada
a una obra cubierta por la misma, usted puede (si está autorizado por los titulares de
los derechos de autor (“copyright”) del material) complementar los términos de esta
Licencia en los siguientes términos:
a) Declarando la ausencia de garantía o limitación de responsabilidad en forma
diferente a la de los términos establecidos en las cláusulas 14 y 15 de esta Licencia;
b) Requiriendo la obligación de mantener determinados avisos legales razonables o
atribuciones de autoría en el material o en los Avisos Legales Apropiados mostrados
por las obras que lo contengan.
c) Prohibir la tergiversación del origen del material o requerir que las versiones
modificadas del material se señalen de manera razonable como diferentes de la
versión original; o
d) Limitar la utilización de los nombres de los autores o licenciantes del material con
fines publicitarios o comerciales; o
e) Negarse a ofrecer derechos bajo leyes de registro para el uso de algunos nombres
comerciales, marcas registradas o marcas de servicio; o
f) Exigir la compensación de los licenciantes y autores de ese material por cualquiera
que distribuya el material (o versiones modificadas del mismo) estableciendo
obligaciones contractuales de responsabilidad sobre el destinatario, por cualquier
responsabilidad que estas obligaciones contractuales impongan directamente sobre
los licenciantes y autores. Cualesquiera otras condiciones adicionales no-permisivas
son consideradas "restricciones adicionales" en el contexto de la cláusula 10. Si el
Programa, tal cual lo recibió, o cualquier parte del mismo, contienen un aviso indicando
que está amparado por esta Licencia junto a una cláusula de restricción adicional,
usted podrá suprimir esa cláusula. Si un documento de licencia contiene una
restricción de este tipo pero permite modificar la Licencia o la transmisión de la obra
en virtud de la presente Licencia, puede añadir material regido por esa licencia a una
obra amparada, siempre que dicha restricción no se mantenga tras la modificación de
la licencia o la transmisión. Si se añaden términos a una obra amparada de acuerdo
63
con los términos de esta sección, debe colocar, en los archivos fuente involucrados,
una declaración de los términos adicionales aplicables a esos archivos, o un aviso
indicando donde encontrar los términos aplicables. Las condiciones adicionales,
permisivas o no, deben aparecer por escrito como licencias separadas o figurar como
excepciones; de todas formas, los requisitos anteriores se aplican igualmente.
64
PROPUESTA DE INNOVACIÓN O SOLUCIÓN DEL PROBLEMA
3. INTRODUCCIÓN
En el presente capítulo se describe el análisis y diseño del sistema propuesto, con la
metodología RUP en sus cuatro fases, utilizando el UML como herramienta de
modelado como se describe en el capítulo anterior (marco teórico).
3.1. ANÁLISIS
3.1.1. ANÁLISIS DE LA SITUACIÓN ACTUAL DEL NEGOCIO
El área de estudio es Farmacia Vital Farm, dedicada a la venta de medicamentos,
cuenta con personal para sus dos turnos mañana y tarde, la propietaria como regente
farmacéutica.
Cada personal se encarga de realizar los pedidos a los proveedores en un formato de

Excel, para luego registrarlo en un cuaderno la fecha del pedido y el proveedor, mas
sin embargo no logran registrar todos los pedidos, lo cual dificulta el control de pedidos
que debe realizar; el control de su existencia la realiza cada mes por lo cual
proporciona una información inexacta al momento de realizar sus pedidos y genera
pérdida de tiempo porque tiene que volver a revisar.
La propietaria realiza las compras al proveedor registrando el total de compra en el

cuaderno de compras, así también si son cuentas por pagar o canceladas al momento
de que el proveedor trae del pedido realizado.
Las auxiliares de farmacia de ambos turnos realizan la venta, registran cada venta en
el cuaderno de ventas, detallando la fecha, producto, total en bolivianos, pero no
especifican de qué laboratorio se vendió, eso genera pérdida de información. También
realizan los inventarios delos productos una vez al mes en hojas de formato realizados
en hojas de cálculo donde registran el nombre del producto, cantidad en enteros y
unidades, fecha de vencimiento, en el momento de la realización de inventario se
65
encuentran productos vencidos, los cuales la propietaria registra en un cuaderno para
ver si tiene devolución a su proveedor para un cambio o simplemente llega a ser
perdida.
Una vez terminado el inventario las auxiliares entregan el inventario a la propietaria, la

cual unifica los datos repetidos y asi poder tener una referencia inexacta para realizar
los pedidos, debido a datos faltantes.
3.1.2. MODELO DE NEGOCIO

3.1.2.1. Casos de Uso de Alto Nivel
- INVENTARIO DE PRODUCTOS EN ALMACÉN
CASO DE USO: INVENTARIO DE PRODUCTOS EN ALMACÉN

ACTOR: DUEÑO , AUXILIAR
TIPO: PRIMARIO
DESCRIPCIÓN: Este caso de uso comienza cuando, la dueña requiere una
lista de los productos a fin de mes para esto pide a la auxiliar
realizar sus inventarios mensuales , para saber más o
menos cuanto va a pedir a laboratorio. La auxiliar de cada
turno realiza el reconteo de sus respectivos laboratorios
registrándolos en un cuaderno con los siguientes detalles
(nro. , descripción , cantidad enteros y sueltos, laboratorio ,
fecha de vencimiento), contando su depósito de vitrina
,realizando a la ves su respectiva limpieza; cuando se
encuentra medicamentos con corto vencimiento procede a
colocarlo en una gaveta, al finalizar el reconteo de los
medicamentos la auxiliar entrega a la propietaria los
registros. Este caso de uso termina cuando la dueña de
acuerdo a lo registrado en el cuaderno realiza el pedido a
laboratorio.
Tabla Nº 3.1: Caso de Uso de Alto Nivel Inventarios de Almacén
66
- VENTA DE PRODUCTOS
CASO DE USO: VENTA DE PRODUCTOS
ACTOR: AUXILIAR, CLIENTE
TIPO: PRIMARIO
DESCRIPCIÓN: Este caso de uso comienza cuando, el cliente pide un
producto a la farmacia para comprar un medicamentos, la
auxiliar pregunta si tiene receta o talves un malestar en
general, el cliente pide lo que necesita, sino hay en la
farmacia el cliente se retira y si hay la auxiliar le dice los
precios de todos los similares que existen , el cliente
selecciona entre uno de esos , la auxiliar le indica cuanto
debe en total , registra el total de la venta realizada en el
cuaderno Este caso de uso termina cuando el cliente se retira
satisfecho con compra realizada
Tabla Nº 3.2: Caso de Uso de Alto Nivel Venta de Productos
- PEDIDO A LABORATORIO
CASO DE USO: PEDIDO A LABORATORIO

ACTOR: PROPIETARIO , PROVEEDOR
TIPO: PRIMARIO
DESCRIPCIÓN: Este caso de uso comienza cuando, la propietaria verifica el
cuaderno donde se registró los productos faltantes,
selecciona los medicamentos que va a pedir, los registra en
un cuaderno, verifica el laboratorio, realiza el pedido
mediante correo electrónico o una llamada telefónica al
laboratorio, el laboratorio recibe el pedido y le indica cuando
le hará llegar, Este caso de uso termina cuando el laboratorio
hace llegar el pedido
Tabla Nº 3.3: Caso de Uso de Alto Nivel Pedido a Laboratorio
67
- COMPRAS DE PRODUCTOS A PROVEEDOR
CASO DE USO: COMPRAS DE PRODUCTOS A PROVEEDOR
ACTOR: PROPIETARIO O AUXILIAR , PROVEEDOR
TIPO: PRIMARIO
DESCRIPCIÓN: Este caso de uso comienza cuando, la propietaria o la
auxiliar recepcionan el pedido, terminada la recepción
verifica su pedido con lo que llego de laboratorio, una vez
concluido, el laboratorio realiza un recibo de cancelado o
bien si es a crédito anota cuando será el pago, luego de esto
la responsable registra en el cuaderno de compras el total de
la compra y si se canceló o no, Este caso de uso termina
acomoda los medicamentos.
Tabla Nº 3.4: Caso de Uso de Alto Nivel Compra a Proveedor
- CATEGORIZACIÓN DE PRODUCTOS
CASO DE USO: CATEGORIZAR PRODUCTOS
ACTOR AUXILIAR
PROPÓSITO: SEPARAR POR CATEGORÍAS LOS PRODUCTOS
RESUMEN: La auxiliar codifica los medicamentos de mostrador ya sea
cepillos, biberones, desodorantes y medicamentos, de
acuerdo a la categoría; en el timbre está el precio el cual
es un cálculo prorrateado sin sobrepasar los límites que
en ley están puestos y en algunos está el código de cada
medicamento y vuelve a poner es su lugar.
Tabla Nº 3.5: Caso de Uso de Alto Nivel Codificación de Medicamentos
68
- DEVOLUCION DE PRODUCTOS
CASO DE USO: DEVOLUCION DE PRODUCTOS

ACTOR AUXILIAR, PROPIETARIA, PROVEEDOR
PROPÓSITO: DEVOLVER LOS PRODUCTOS
RESUMEN: Este caso de uso comienza cuando la auxiliar revisa los
productos, selecciona los que están en mal estado o están
a punto de vencer, esta revisión también se la hace al
momento de recepcionar los productos del proveedor si
encuentra al momento le entrega antes de finalizar la
recepción para que pueda cambiar el producto, si se
encontró después de la recepción la auxiliar entrega a la
propietaria. Este caso de uso termina cuando la propietaria
proceda a la devolución al proveedor para que le pueda
hacer el respectivo cambio.
Tabla Nº 3.6: Caso de Uso de Devolución de Productos
69
3.1.2.2. Diagramas de Caso de Uso
- INVENTARIO DE ALMACÉN DE PRODUCTOS
Figura Nº 3.1: Diagrama de Caso de Uso Almacén de Inventarios
70
-VENTA DE PRODUCTOS
uc DIAGRAMAS DE CASO DE USO VENTAS
VENTA DE PRODUCTOS
INGRE SA A LA
PREGUNTA LA FARMACIA
NECES IDAD
SOLICITA
RECETA PIDE PRODUCTO
MEDICA
CLIE NTE
VENDEDOR LE OFRE CE
PRODUCTOS DELA
PREGUNTA DE
MISMA COMPOS ICION
CUANTOS PRE CIOS
PERO DE DISTINAS
TIENE
MARCAS
LE DICE EL
TOTAL CANCELA EL
TOTAL
AUXILIAR TURNO AUXILIAR TURNO

TARDE MAÑANA
LE ENTREGA LOS
PRODUCTOS
REGISTRA LA
VENTA EN EL
CUADERNO DE
VENTAS SE RETIRA
Figura Nº 3.2: Diagramá de Caso de Uso de Ventas
71
Figura Nº 3.3: Diagrama de Caso de Uso de Pedido a Laboratorio
72
-COMPRA DE PRODUCTOS A PROVEEDOR
Figura Nº 3.4: Diagrama de Caso de Uso de Compra de Productos a Proveedor
73
- CODIFICACIÓN DE PRODUCTOS
Figura Nº 3.5: Diagrama de Caso de Uso Codificación de Productos
74
-DEVOLUCIÓN DE PRODUCTOS
Figura Nº 3.6: Diagrama de Caso de Uso Devolución de Productos
75
3.1.2.3. Diagrama de Actividades
Figura Nº 3.7: Diagrama de Actividades de Inventario de Productos en Almacén
76
Figura Nº 3.8: Diagrama de Actividades de Venta de Productos
77
-PEDIDO A LABORATORIO
Figura Nº 3.9: Diagrama de Actividades de Pedido a Laboratorio
78
-COMPRA DE PRODUCTOS
Figura Nº 3.10: Diagrama de Actividades de Compras de Productos
79
-CATEGORIZACIÓN DE PRODUCTOS POR MEDIO DE SU CODIFICACIÓN
Figura Nº 3.11: Diagrama de Actividades de Categorización de productos por medio de su codificación
80
Figura Nº 3.12: Diagramas de Actividades de Devolución de Productos
81
3.1.2.4. Modelo de Objetos
-INVENTARIO DE ALMACÉN DE PRODUCTOS
obj ect ALMACEN DE MEDICAMENTOS
PRODUCT O
AUXILIAR
PROPIE TARIO
INVENT ARIO MANUAL

LLENO
INVENT ARIO MANUAL

PEDIDO A LABORAT ORI O (VACIO )
Figura Nº 3.13: Diagrama de Objetos de Inventario de Almacén de Productos
-VENTA
obj ect VENTADE PRODUCTOS
CLIE NTE
AUXILIAR
RECETA MEDICA
CUADERNO DE FALTANTES
EN VENTA
PRODUCTO
REGISTRO DE CUADERNO DE
VENTAS
FACTURA DE VENTA
Figura Nº 3.14: Diagrama de Objetos de Venta de Productos
82
-PEDIDO A LABORATORIO
obj ect PEDIDO A LABORATORIO
LABORATORIO PRODUCTO
AUXILIAR
CUADERNO DE EXISTENCIAS
HOJA DE PEDIDO (LLENA)
CUADERNO DE PEDIDO
(LISTA DE LABORATORIOS)
HOJA DE PEDIDO (VACIA)
Figura Nº 3.15: Diagrama de Objetos de Pedido a Laboratorio
obj ect COMPRAS
PRODUCTO
LABORATORIO AUXILIAR
CUADERO DE COMPRAS(
FACTURA DE PEDIDO REGISTRO DE PAGO LISTA DE LABORATORIOS)
HOJA DE PEDIDO
RECIBO DE PAGO
Figura Nº 3.16: Diagrama de Objetos de Compra de Productos
83
-CATEGORIZACIÓN DE PRODUCTOS POR MEDIO DE SU CODIFICACIÓN DE
PRODUCTO
obj ect DIAGRAMA DE OBJETOS codificacion
auxiliar
producto T IMBRE
FACT URA
Figura Nº 3.17: Diagrama de Objetos de Categorización por Medio de Codificación de Productos

obj ect DIAGRAMA DE OBJETOS dev olucion
AUXILIAR PROPIETARIA LABORATORIO
PRODUCT O PRODUCT O NUEVO
Figura Nº 3.18: Diagrama de Objetos de Devolución de Productos
84
3.1.3. MODELO DEL SISTEMA
3.1.3.1. ANALISIS DE REQUERIMIENTOS
En esta primera etapa del presente proyecto introduce en su etapa de inicio, el
comportamiento del sistema, se identifica los actores que interactúan y principalmente
los requerimientos del sistema. Primero se centra en el modelo de negocio y
posteriormente se establece los casos de uso de la farmacia.
3.1.3.1.1. REQUERIMIENTOS FUNCIONALES GENERAL

A continuación se detalla los requerimientos funcionales en general que tendrá el
sistema de acuerdo al estudio realizado.
FUNCIÓN
RF 1.1 El sistema validara el ingreso del usuario al sistema.
La encargada así como el personal de trabajo deberá tener un código así
RF 1.2
como una contraseña para poder ingresar a su módulo correspondiente
El sistema permitirá ingresar la información de los productos en la base de
RF 1.3
datos.
El sistema permitirá ingresar la información de los proveedores en la base
RF 1.4
de datos
RF 1.5 El sistema registrara el movimiento de los productos.
RF 1.6 El responsable podrá introducir el medicamento a buscar.
RF 1.7 El sistema mostrara el medicamento que se quiere vender
RF 1.8 El sistema registrara el detalle de la venta de productos
RF 1.9 El sistema permitirá verificar la existencia de los productos.
RF 1.10 El sistema permitirá registrar a solicitud de productos.
RF 1. 11 El sistema permitirá registrar la compra de los medicamentos
RF 1. 12 Podrá actualizar el inventario actual de la farmacia.
El sistema deberá mostrar el precio de compra y de venta de cada
RF 1.13
producto.
RF 1.14 Permitirá actualizar los precios, además del nombre de cada producto.
Permitirá alertar que productos están con corto vencimiento para su venta
RF 1.15
más próxima.
RF 1.16 El sistema mostrara en la ventana cada consulta requerida.
RF 1.17 Generará reportes de las consultas requeridas
RF1.18 El sistema dará alerta de stock mínimo de medicamentos más vendidos.
Tabla Nº 3.7 : Requerimientos Funcionales General
[FUENTE: Elaboración Propia]
85
3.1.3.1.2. REQUERIMIENTOS FUNCIONALES ESPECIFICOS
A continuación se describen los requerimientos funcionales
3.1.3.1.2.1. FUNCIÓN DE ALMACÉN DE PRODUCTOS

Ref. 2 FUNCIÓN
RF 2.1 El usuario podrá generar el ingreso y salida de medicamentos.
RF 2.2 El sistema generara un informe de todos los datos que requiere el
usuario, ya sea de compra, ventas, e inventario.
RF 2.3 El usuario podrá actualizar los vencimientos de los productos
RF 2.4 Es sistema permitirá la edición de los productos.
RF 2. 5 El sistema deberá mostrar a detalle el movimiento de cada producto.
RF 2.6 El sistema deberá manejar un mecanismo de almacenamiento
continuo.
RF 2.7 El usuario podrá imprimir los reportes para el control de inventario
toma de decisiones.
RF 2.8. El sistema permitirá modificar las características de los productos.
Tabla Nº 3.8: Funciones de Almacén de Productos
3.1.3.1.2.2. FUNCIÓN DE VENTA

Ref. 3 FUNCIÓN
RF 3.1 El usuario maneja la existencia actual delos medicamentos, para
poder hacer la búsqueda requerida.
RF 3.2 El sistema buscara el producto requerido, si tiene o no existencia.
RF 3.3 El sistema mostrara la información del producto, incluyendo el precio
de venta la cantidad existente.
RF 3.4 El usuario podrá introducir datos para realizar a venta.
RF 3.5 El sistema guardara cada registro de venta (ID de cliente, apellido,
total venta, fecha de venta).
RF 3.6 Calculara el total de cada venta realizada.
RF 3.7 El sistema generara el reporte de cada venta para así poder detallar
la factura manual.
RF 3.8 El sistema deberá reducir la existencia delos productos vendidos,
para tener una existencia actual
RF 3.9 El sistema mostrara los productos en existencia cero como faltantes
en venta.
RF 3.0 El sistema mostrara los productos con stock cero
Tabla Nº 3.9: Función de Ventas
86
3.1.3.1.2.3 .FUNCIÓN DE PEDIDO DE LABORATORIO
Ref. 4 FUNCIÓN
RF 4.1 El usuario tiene los datos de las existencias, faltantes productos.
RF 4.2 El sistema deberá generar el reporte de la información requerida.
RF 4.3 El sistema mostrara, en un tiempo de intervalo dado del movimiento
de los productos para poder realizar el pedido
( mensual, semanal, trimestral)
RF 4.4 El sistema tendrá la posibilidad poder introducir mínimos y máximos
de cada producto, para no sobrepasar su stock.
RF 4.5 El usuario podrá realizar un pedido de acuerdo a el laboratorio
solicitado
RF 4.6 El sistema guardara el registro de los pedidos realizados
RF 4.7 El sistema generara el reporte del pedidos realizado asignando un
numero de pedido
RF 4.8 El sistema deberá efectivizar la reposición de los productos a partir
de las facturas que le llegan del pedido a los diferentes laboratorios
(proveedores).
Tabla Nº 3.10: Función de Pedido de Laboratorio
[FUENTE, Elaboracion Propia]
3.1.3.1.2.4. FUNCIÓN DE COMPRA
Ref. 5 FUNCIÓN
RF 5.1 El usuario tiene el registro de los pedidos, los laboratorios
(proveedores).
RF 5.2 El sistema deberá almacenar la información de los proveedores
RF 5.3 El usuario podrá ingresar cada productos de manera opcional los
vencimientos de los mismos
RF 5.4 El sistema deberá guardar el ingreso de los productos.
RF 5.5 El sistema generara un reporte de los ingresos realizados.
RF 5.6 El sistema actualizara el inventario de manera continua.
Tabla Nº 3.11: Función de Compra
87
3.1.3.1.2.5 .FUNCIÓN DE CLIENTE
Ref. 6 FUNCIÓN
RF 6.1 El usuario tiene los datos de clientes continuos a la farmacia
RF 6.2. El sistema deberá guardar el CI, o NIT de cada cliente.
RF 6.3 El usuario podrá obtener los datos del cliente para poder realizar
su factura manual y saber si los mismos tienen descuentos
especiales.
Tabla Nº 3.12: Función de Cliente
3.1.3.1.2.6 .FUNCIÓN DE CATEGORÍA DE PRODUCTOS
Ref. 7 FUNCIÓN
RF 7.1. El usuario tiene conocimiento de los medicamentos los cuales son
con receta obligatoria
RF 7.2. El sistema deberá clasificar los sistema psicotrópicos y los
estándares para su mayor control
RF 7.3. El sistema generara un código para cada producto de acuerdo al
nombre y su proveedor e caso de que el proveedor no tenga su
propio código.
El sistema permitirá el cambio de las características de los productos.
RF 7.4. El usuario podrá realizar la búsqueda de los mismos de manera fácil.
Tabla Nº 3.13: Función de Productos
[FUENTE: Elaboracion Propia]
3.1.3.1.2.7. FUNCION DE DEVOLUCION DE PRODUCTOS

Ref. 8 FUNCIÓN
RF 8.1. El usuario revisa de manera física los producto
RF 8.2. El sistema tendrá la opción de sacar del sistema ciertos productos
RF 8.3. El sistema tendrá la opción de devolución de productos por
vencimiento a proveedor, por mal estado o por merma.
RF 8.4. El usuario podrá generar un reporte de todas las devoluciones
Tabla Nº 3.14: Función de Devolución
[FUENTE: Elaboracion Propia]
88
3.1.3.1.3. REQUERIMIENTOS NO FUNCIONALES
A continuación se describe los requerimientos no funcionales del presente proyecto,
que muestra los aportes que tendrá para la farmacia, para mejor uso del sistema.
Ref. # FUNCIÓN
RNF- 1 El sistema deberá ser instalado en la unidad principal del disco duro.
RNF- 2 El sistema presentara portabilidad, que quiere decir puede ser
instalado en otro equipo
RNF- 3 El sistema debe estar desarrollado en plataforma Windows para su
fácil uso
RNF- 4 Se utilizara iconos estándares para su fácil manipulación
RNF- 5 El diseño y la presentación deberá ser amigable para su fácil manejo
del usuario
RNF- 6 Mostrará una alerta de medicamentos con recetas obligatorios
RNF- 7 Es sistema contara con un registro de usuarios realizado por el
administrador para limitar el acceso de los mismos.
RNF -8 El sistema tendrá un manual de usuario para su mejor comprensión
RNF- 9 Generará reportes para que permitan tener una mejor toma de
decisiones.
RNF- 10 El sistema realizara una copia de seguridad en la base de datos.
Tabla Nº 3.15: Requerimientos no Funcionales
[FUENTE, Elaboracion Propia]
3.1.4. ACTORES IDENTIFICADOS
Una vez realizada el estudio preliminar y determinada la situación de la farmacia, se

observó e identifico los posibles actores. La identificación de actores en términos
generales son usuarios del sistema los cuales interactúan, aportan y reciben
información del sistema para coadyuvar a sus tareas cotidianas o necesidades
demandadas. A continuación se describen los actores o usuarios identificados.
- Regente Farmacéutica (Propietaria)
La regente farmacéutica, es quien conoce a profundidad del movimiento de la

farmacia, sus funciones son:
 Selecciona a sus proveedores

 Solicita los inventarios mensuales para a toma de decisiones
89
 Controla la existencia física juntamente con el inventario realizado
 Asigna funciones a cada una de las auxiliares
 Realiza la solicitud de compra de los productos
 Registra cada compra realizada
 Realiza el pago a sus proveedores
- Auxiliar de Farmacia (Turno Mañana)
Se encarga de realiza el control de los productos década laboratorio que se le asigno,

sus funciones son:
 Controla el estado los productos.

 Registra los pedidos que llegan a la farmacia.
 Realiza pedido de ciertos productos
 Realiza la venta de los medicamentos
 Registra la venta realizada al igual que el total cancelado
 Registra los productos faltantes dentro de la farmacia
 Realiza el inventario de los laboratorios asignados por la propietaria.
 Controla los vencimientos
 Registra el total en bolivianos de sus ventas en su turno.
- Auxiliar de Farmacia (Turno Tarde)
Se encarga de realiza el control de los productos década laboratorio que se le asigno,

sus funciones son:
 Controla el estado los productos.

 Registra los pedidos que llegan a la farmacia.
 Realiza pedido de ciertos productos
 Realiza la venta de los medicamentos
 Registra la venta realizada al igual que el total cancelado
 Registra los productos faltantes dentro de la farmacia
 Realiza el inventario de los laboratorios asignados por la propietaria.
 Controla los vencimientos
 Registra el total en bolivianos de sus ventas en su turno.
90
- Proveedor (Laboratorio)
 Encargados de proveer productos a la farmacia

 Emite facturas o notas de entrega
 Entrega lista de nuevos medicamentos
- Cliente
 Ingresa para solicitar productos dentro de la farmacia

 Solicita factura
 Cancela el total de su compra
3.1.5. CASOS DE USO DE ALTO NIVEL DEL SISTEMA

Los casos de uso nos ayudan a capturar los requisitos adecuados. Cada usuario
necesita que haga alguna función y los casos de uso representan los modos de utilizar
el sistema.

CASO DE USO: INVENTARIO DE PRODUCTOS
ACTOR: DUEÑO , AUXILIAR
TIPO: PRIMARIO
DESCRIPCIÓN: La dueña requiere una lista de los productos a fin de me, la
auxiliar realiza sus inventarios mensuales, para saber más o
menos cuanto va a pedir a laboratorio. La auxiliar de cada
turno realiza el reconteo de sus respectivos laboratorios con el
reporte de inventarios, contando su depósito de vitrina,
realizando a la ves su respectiva limpieza; cuando se
encuentra medicamentos con corto vencimiento procede a
colocarlo en una gaveta, al finalizar el reconteo de los
medicamentos la auxiliar entrega a la propietaria los registros.,
quien verifica con sistema y procede a realizar los pedidos.
Tabla Nº 3.16: Caso de Uso de Alto Nivel Inventarios de Almacén del Sistema
91
ACTOR: AUXILIAR, CLIENTE
TIPO: PRIMARIO
DESCRIPCIÓN: Este caso de uso comienza cuando, el cliente pide un
producto a la farmacia, la auxiliar verifica la existencia, sino
hay en la farmacia el cliente se retira y si hay la auxiliar revisa
los precios de las distintas opciones, el cliente selecciona
entre uno de esos, la auxiliar calcula el total e indica cuanto
debe cancelar, registra el total de la venta realizada. Este
caso de uso termina cuando el cliente se retira satisfecho con
compra realizada
Tabla Nº 3.17: Caso de Uso de Alto Nivel Venta de Productos del Sistema

ACTOR: PROPIETARIO , PROVEEDOR
TIPO: PRIMARIO
DESCRIPCIÓN: Este caso de uso comienza cuando, la propietaria consulta
en el sistema los productos faltantes, ingresa al módulo de
pedidos y selecciona los productos a pedir de un
determinado proveedor, guarda el pedido, envía el pedido
mediante correo electrónico, una llamada telefónica al
laboratorio, o mediante WhatsApp el laboratorio recibe el
pedido y le indica cuando le hará llegar, Este caso de uso
termina cuando el laboratorio hace llegar el pedido
Tabla Nº 3.18: Caso de Uso de Alto Nivel Pedido a Laboratorio del Sistema
92
- COMPRAS DE PRODUCTOS A PROVEEDOR
CASO DE USO: COMPRAS DE PRODUCTOS A PROVEEDOR
ACTOR: PROPIETARIO O AUXILIAR , LABORATORIO
TIPO: PRIMARIO
DESCRIPCIÓN: Este caso de uso comienza cuando, la propietaria o la
auxiliar recepcionan el pedido, imprimiendo el reporte de
pedido para comparar si está llegando lo requerido, una vez
concluido, el laboratorio realiza un recibo de cancelado o
bien si es a crédito anota cuando será el pago, luego de
esto la responsable ingresa al sistema los productos llegado
para poder venderlos, Este caso de uso termina acomoda
los medicamentos a sus respectivas vitrinas.
Tabla Nº 3.19: Caso de Uso de Alto Nivel Compra a Proveedor del Sistema
- CATEGORIZACIÓN DE PRODUCTOS
CASO DE USO: CATEGORIZAR PRODUCTOS
ACTOR AUXILIAR
PROPÓSITO: SEPARAR POR CATEGORÍA LOS PRODUCTOS
RESUMEN: La auxiliar codifica los medicamentos de mostrador ya sea
cepillos, biberones, desodorantes y medicamentos, de
acuerdo a la categoría que estos tienen siendo los que
están en mostrador o existen en varias presentaciones; en
el timbre está el precio el cual está en sistema para la venta.
Tabla Nº 3.20: Caso de Uso de Alto Nivel Categorización de Productos
93
- DEVOLUCIÓN DE PRODUCTOS
CASO DE USO: DEVOLUCIÓN DE PRODUCTOS
ACTOR AUXILIAR, PROPIETARIA, PROVEEDOR
PROPÓSITO: DEVOLVER LOS PRODUCTOS
RESUMEN: Este caso de uso comienza cuando la auxiliar revisa

los productos, selecciona los que están en mal estado
o están a punto de vencer, entrega a la propietaria
quien dará de baja en el sistema para su respectivo
cambio. Este caso de uso termina cuando la
propietaria proceda a la devolución al proveedor para
que le pueda hacer el respectivo cambio.
Tabla Nº 3.21: Caso de Uso de Devolución de Productos del Sistema
3.1.6. CASOS DE USO EXPANDIDOS DEL SISTEMA
Los casos de usos expandidos muestran a detalle los procesos antes mencionados,
tienen información que describe el proceso, el curso normal de los eventos que detalla
la interacción de los actores
Se realizara una técnica para comprender los procesos organizados del entorno,
describiré en general términos de los casos de usos y mostrar actores que intervienen
en el sistema.
A continuación se mostraran los casos de uso expandidos de los procesos reflejados

en los diagramas de casos de uso de alto nivel.
94
CASO DE USO: INVENTARIO DE PRODUCTOS DE ALMACÉN
ACTORES: PROPIETARIO , AUXILIAR
PROPÓSITO: REALIZAR EL CONTEO FÍSICO Y COMPARAR CON SISTEMA LAS

EXISTENCIAS PARA LA TOMA DE DECISIONES
RESUMEN: El propietario solicita reporte de existencias, la auxiliar genera el reporte

de existencias realiza los inventarios correspondientes actualiza los
vencimientos en el sistema, entrega reporte a la propietaria quien revisa
y verifica el mismo ajustando las variaciones de las existencias.
TIPO: PRIMARIO, ESENCIAL
REFERENCIAS CRUZADAS: REF 2.1 ,REF 2.2, REF 2.3, REF 2.4, REF 2.6, REF 2.7
CURSO NORMAL DE LOS EVENTOS
ACCIÓN DEL ACTOR RESPUESTA DEL SISTEMA
1. Solicita informe de reportes de inventarios.
2. El sistema genera informe de todos los datos que

requiere el usuario.
3. Realiza el control de las existencias.
4. Verifica las existencias y sus vencimientos.
5.Propietaria ingresa a módulo de productos
7. Actualiza vencimientos.
8. El sistema actualiza los vencimientos que el usuario
registra.
9. El sistema permite la edición de los productos.

10. Guarda las actualizaciones realizadas.
11. Solicita el movimiento de cada producto.

12. El sistema muestra el movimiento de cada
producto.
13. Verifica las existencias si comparan con sistema
14. Imprime reportes de existencias para la toma de

decisiones.
Tabla Nº 3.22: Diagrama de Caso de Uso Expandido de Inventario de Productos en Almacén
95
ACTORES: AUXILIAR , CLIENTE
PROPÓSITO: Registrar la salida de medicamentos
RESUMEN: La auxiliar atiende al cliente realizando la venta de uno o varios

productos, que se registran en el sistema.
REFERENCIAS CRUZADAS: RF 3.1, RF 3.2, RF 3.3, RF 3.4, RF 3.5, RF 3.6 RF 3.7, RF 3.8, RF
3.9, RF 3.0
1. Auxiliar atiende la solicitud del cliente
2. Busca la existencia del producto
3. Realiza el control de las existencias. 4. El sistema muestra información del producto buscado
con los siguientes campos
5. Verifica las existencias y sus vencimientos.
 Código de producto
 Descripción
 Cantidad existente
 Precio unitario
6. El cliente realiza la solicitud a la auxiliar
 Precio por entero
7. Auxiliar solicita datos del cliente
8. Auxiliar realiza el costo total de la venta realiza
9 Realiza la factura manual para entregarla al

cliente
10.El sistema registra los datos del cliente grabándolos
11. Entrega los productos solicitados por el cliente
12. El cliente se retira
13. Cuando no hay existencias la auxiliar registra

los productos faltantes 14. Genera un reporte de la venta o salida de los
productos.
15. El sistema reduce el Stock del inventario
16. El sistema genera reporte de productos en stock cero.
Tabla Nº 3.23: Diagrama de Caso de Uso Expandido de Venta de Productos
96
ACTORES: PROPIETARIA , AUXILIAR , PROVEEDOR
PROPÓSITO: Registrar las solicitudes de productos a los proveedores

correspondiente
RESUMEN: El usuario verifica los faltantes que tiene en ventas, realiza el

pedido correspondiente a laboratorio generando un reporte para
enviarlo al proveedor (laboratorio), luego el mismo envié el
pedido.
REFERENCIAS CRUZADAS: RF 4.1, RF 4.2, RF 4.3, RF 4.5, RF 4.6, RF 4.7
1. Verifica la cantidad de existencia , con el

reporte de faltantes
2.Elije el proveedor para realizar la solicitud
3.Realiza el pedido
4. Genera reporte de faltantes
5. Graba el pedido realizado
6. Muestra un rango de ventas en tiempo de intervalo ,para

realizar el pedido
7. Muestra la ventana de solicitud de pedidos
8. Envía a laboratorio mediante correo o vía

celular
9. El sistema guarda el pedido
10. Genera un reporte del pedido.
Tabla Nº 3.24: Diagrama de Caso de Uso Expandido de Pedido a Laboratorio
97
CASO DE USO: COMPRA DE PRODUCTOS
ACTORES: PROPIETARIA , AUXILIAR , PROVEEDOR (LABORATORIO)
PROPÓSITO: Registrar las compras realizadas de los proveedores.
RESUMEN: El laboratorio hace llegar el pedido, el usuario compara con el

reporte de pedidos recepciona, el proveedor le entrega la factura,
el usuario ingresa los productos a sistema de dicha factura,
procediendo después a codificar los productos y acomodar en sus
vitrinas correspondientes.
REFERENCIAS CRUZADAS: RF 5.2, RF 5.3, RF 5.4., RF 5.5
1. El proveedor hace llegar el pedido.
2. El sistema genera reporte de pedido
3. Auxiliar verifica que sea el pedido correcto
4. Auxiliar recepciona pedido
5. Proveedor entrega pedido.
5. Proveedor entrega factura.
6.Auxiliar ingresa a módulo de compra 7. Sistema muestra la ventana de ingreso
8. Ingresa los productos de la factura entregada

por el proveedor.
9. Sistema acepta el ingreso de productos
10.Graba ingreso de productos
10. genera reporte de ingreso de productos
11. Actualiza las existencias en sistema
Tabla Nº 3.25: Diagrama de Caso de Uso Expandido de Compra de Productos
98
CASO DE USO: CATEGORIZACIÓN POR MEDIO DE CODIFICACIÓN DE
PRODUCTOS
ACTORES: AUXILIAR
PROPÓSITO: Codificar los productos de acuerdo al código de factura, además

del precio estipulado en sistema por la propietaria.
RESUMEN: La auxiliar verifica en sistema la categoría además de su código

más su precio ,para poder realizar la venta mediante sistema, se
utiliza la codificación especialmente en artículos de categoría de
insumos ,biberones cremas ,etc.
REFERENCIAS CRUZADAS:
1. Auxiliar determina tipo de categoría a la que

pertenece el producto
2.ingresa al módulo de categoría para crear o

seleccionar una .categoría
3. Muestra pantalla de categoría
4. Selecciona categoría para producto

5.Sistema muestra la característica de la categoría
6.Crea un nuevo código de nueva categoría
7. Guarda categoría
8. Pone timbre el producto done se encuentra el
código y el precio del mismo
9. guarda el producto en su sitio correspondiente
Tabla Nº 3.26: Diagrama de Caso de Uso Expandido de Categorización de Productos
99
CASO DE USO: DEVOLUCIÓN DE PRODUCTOS
ACTORES: PROPIETARIA , AUXILIAR , PROVEEDOR
PROPÓSITO: Sacar del sistema existencia de producto que o se encuentra en

condiciones para ser vendidos y ofrecer calidad a los clientes.
RESUMEN: La auxiliar revisa la calidad de los productos al momento de

realizar el inventario para ver si estos se encuentran en buen
estado, y también con los vencimientos tiene el control de los
próximos a vencer para devolverlos a laboratorio para obtener un
cambio, la auxiliar entrega los productos de mal estado o con
alguna observación a la propietaria para proceder a la devolución.
REFERENCIAS CRUZADAS: RF.8.1 , RF.8.2 , RF 8.3 ,RF.8.4
1. Auxiliar revisa los productos
2.selecciona los de mal estado y los que se

devolverán a laboratorio
3 Auxiliar entrega a propietaria.
4. Propietaria ingresa a módulo de devolución.

5.Sistema muestra pantalla de devolución
6.Selecciona los productos a sacar del sistema

7.Sistema muestra cantidad de devolución
8. Muestra tipos de devolución
 Mal estado
 Merma
 Vencimiento
9. Escoge motivo de devolución

11. Sistema descuenta producto.
10 guarda la salida de producto
12. Sistema genera reporte de devolución
Tabla Nº 3.27: Diagrama de Caso de Uso Expandido de Devolución de Productos
100
3.1.7. DIAGRAMAS DE CASOS DE USOS EXPANDIDOS DEL SISTEMA
Figura Nº 3.19: Diagrama de Caso de Uso General
101
-INVENTARIO DE ALMACÉN DE SISTEMA
Figura Nº 3.20: Diagrama de Caso de Uso de Alto Nivel con Sistema
102
-VENTAS DE PRODUCTOS
Figura Nº 3.21: Diagrama de Caso de Uso de Venta de Productos de Sistema
103
Figura Nº 3.22: Diagrama de Caso de Uso de Pedido a Laboratorio del Sistema
104
Figura Nº 3.23: Diagrama de Casos de Uso de Compra de Producto de Sistema
105
3.2. DISEÑO
3.2.1. DIAGRAMA DE SECUENCIAS
Modela la interacción entre los objetos y actores de nuestro sistema, identificando de

la comunicación (mensajes) entre los mismos y las operaciones (métodos) de las
clases para resolver un servicio
-DIAGRAMA DE SECUENCIA DE INVENTARIO DE ALMACÉN DE PRODUCTOS
Figura Nº 3.24: Diagrama de Secuencias de Inventario de Almacén de Productos
106
-DIAGRAMA DE SECUENCIA DE VENTA DE PRODUCTOS
Figura Nº 3.25: Diagrama de Secuencia de Venta de Productos
107
-DIAGRAMA DE SECUENCIA DE PEDIDO A LABORATORIO
Figura Nº 3.26: Diagrama de Secuencia de Pedido a Laboratorio
-DIAGRAMA DE SECUENCIA DE COMPRA DE PRODUCTOS
Figura Nº 3.27: Diagrama de Secuencias de Compra de Productos
108
-DIAGRAMA DE SECUENCIA DE DEVOLUCIÓN DE PRODUCTO
Figura Nº 3.28: Diagrama de Secuencia de Devolución de Productos
3.2.2 DIAGRAMAS DE ESTADOS DEL SISTEMA

Describe visualmente los estados y eventos más interesados de un objeto así como
su comportamiento ante un evento
Un diagrama de estado presenta el ciclo de vida de un objeto, los eventos que le

ocurren, sus transiciones y los estados que median entre sus eventos.
Los diagramas de estados correspondientes a los casos de uso son los siguientes.
109
-DIAGRAMA DE ESTADO DE INVENTARIO DE ALMACEN
Figura Nº 3.29: Diagrama de Estado de Inventario de Almacén
-DIAGRAMA DE ESTADO DE VENTA DE PRODUCTOS
Figura Nº 3.30: Diagrama de Estado de Venta de Productos
110
- DIAGRAMA DE ESTADO DE PEDIDO A LABORATORIO
Figura Nº 3.31: Diagrama de Estado de Pedido a Laboratorio
-DIAGRAMA DE ESTADO DE COMPRA DE PRODUCTOS
Figura Nº 3.32: Diagrama de Estado de Compra de Productos
111
3.2.3. CASOS DE USO REALES
CASO DE USO: INVENTARIO DE PRODUCTOS DE ALMACÉN
ACTORES: PROPIETARIO , AUXILIAR
PROPÓSITO: REALIZAR EL CONTEO FÍSICO Y COMPARAR CON SISTEMA LAS

EXISTENCIAS PARA LA TOMA DE DECISIONES
RESUMEN: El propietario solicita reporte de existencias, la auxiliar genera el reporte

de existencias realiza los inventarios correspondientes actualiza los
vencimientos en el sistema, entrega reporte a la propietaria quien revisa
y verifica el mismo ajustando las variaciones de las existencias.
REFERENCIAS CRUZADAS: REF 2.1 ,REF 2.2, REF 2.3, REF 2.4, REF 2.6, REF 2.7
Solicita informe de reportes de inventarios. Como se

muestra en la figura N°3.33 y 3.34
El sistema genera C de informe de todos los datos que
requiere el usuario; oprimiendo D.
Propietaria ingresa a módulo de productos A

Introduce su contraseña en B
Actualiza vencimientos en E
El sistema actualiza los vencimientos que el usuario
registra.
El sistema permite la edición de los productos. En E
Guarda las actualizaciones realizadas en F.
Solicita el movimiento de cada producto en C.
Imprime reportes de existencias para la toma de

decisiones en D
13. Verifica las existencias si comparan con sistema
Tabla Nº 3.28: Diagrama de Caso de Uso Real de Inventario de Productos en Almacén
112
A
Figura Nº 3.33: Ingreso Login
C
E
B
D
G
B
Figura Nº 3.34: Modulo Almacén de Productos
113
ACTORES: AUXILIAR , CLIENTE
PROPÓSITO: Registrar la salida de medicamentos
RESUMEN: La auxiliar atiende al cliente realizando la venta de uno

o varios productos, que se registran en el sistema.
REFERENCIAS CRUZADAS: RF 3.1, RF 3.2, RF 3.3, RF 3.4, RF 3.5, RF 3.6 RF 3.7,

RF 3.8, RF 3.9, RF 3.0
Auxiliar atiende la solicitud del cliente
Ingresa al módulo de ventas Figura 3.35. A.
Realiza el control de las existencias. El sistema muestra información del producto buscado
con los siguientes campos B
Verifica las existencias y sus vencimientos B
 Código de producto
 Descripción
 Cantidad existente
 Precio
El cliente realiza la solicitud a la auxiliar
 Marca
Auxiliar solicita datos del cliente
Auxiliar realiza el costo total de la venta realiza
Realiza la factura manual para entregarla al cliente

El sistema registra los datos del cliente grabándolos C
Entrega los productos solicitados por el cliente
El cliente se retira
Cuando no hay existencias la auxiliar registra los

Genera un reporte de la venta o salida de los productos
productos faltantes F
E
El sistema reduce el Stock del inventario.
Tabla Nº 3.29: Diagrama de Caso de Uso Real de Venta de Productos
114
A
C B
G F E
Figura Nº 3.35: Modulo de Venta
115
PROPÓSITO: Registrar las solicitudes de productos a los proveedores

correspondiente
RESUMEN: El usuario verifica los faltantes que tiene en ventas, realiza el

pedido correspondiente a laboratorio generando un reporte para
enviarlo al proveedor (laboratorio), luego el mismo envié el
pedido.
REFERENCIAS CRUZADAS: RF 4.1, RF 4.2, RF 4.3, RF 4.5, RF 4.6, RF 4.7
1. Verifica la cantidad de existencia , con el

reporte de faltantes
2.Elije el proveedor para realizar la solicitud B
3.Realiza el pedido A
6. Muestra un rango de ventas en tiempo de intervalo ,para
realizar el pedido C
4. Elige a cantidad a pedir D 7. Muestra la ventana de solicitud de pedidos B
5. Graba el pedido realizado E
9. El sistema guarda el pedido E
10. Genera un reporte del pedido.F
8. Envía a laboratorio mediante correo o vía

celular
Tabla Nº 3.30: Diagrama de Caso de Uso Real de Pedido a Laboratorio:
116
A
E C
Figura Nº 3.36: Pedido de Laboratorio
117
CASO DE USO: COMPRA DE PRODUCTOS
PROPÓSITO: Registrar las compras realizadas de los proveedores.
RESUMEN: El laboratorio hace llegar el pedido, el usuario compara con el

reporte de pedidos recepciona, el proveedor le entrega la factura,
el usuario ingresa los productos a sistema de dicha factura,
procediendo después a codificar los productos y acomodar en sus
vitrinas correspondientes.
REFERENCIAS CRUZADAS: RF 5.2, RF 5.3, RF 5.4., RF 5.5
1.ingresa a ventana de ingreso de productos

(compra)
2.Sistema muestra ventana de ingreso A
3.Selecciona proveedor B
4.Digita los productos a ingresar C

5. Sistema muestra en una listalos productos a ingresar D
7. Muestra los datos de cada producto E

6.Introduce Datos de producto
8. Graba la compra realizada

El sistema introduce actualiza cantidad de los productos
ingresados F
Linea :7 Se muestra la cantidad, fecha de vencimiento, precio
Linea 9: Al grabar la compra el sistema restringe el ingreso de numero de factura repetida
Tabla Nº 3.31: Diagrama de Caso de Uso Real de Compra de Productos
118
A
B
C D
Figura Nº 3.37: Modulo de Compras
119
3.2.4. DIAGRAMA DE CLASES
class DIAGRAMAS DE CASO DE USO
PRODUCTOS
- COD_MED: int PROVE EDOR

+/ COD_PROVEEDOR: int
+ CELULAR: int
+ FECHA_DE_INGRESO: char
DETALLE DE VENTA - COD_PROVEEDOR: int
+ FECHA_DE_VENC: float
+ CORREO_ELECT RONICO: char
+ CANT IDAD_ENT EROS: int + NOMBRE_DE_PRODUCT O: char
+ DIRECCION: char
+ CANT IDAD_UNIDADES: int + PRECIO_COST O_ENT ERO: int
+ NOMBRE: char
+/ COD_MED: int + PRECIO_COST O_UNIT ARIO: int 1 1. .* + T ELEFONO: int
- COD_VENT A: int + PRECIO_VENT A_ENT EROS: int
1. .* 1 + PRECIO_VENT A_UNIT : int
+ ADICIONAR() : void
+ consultas() : boolean + ST OCK_ENT EROS: int
+ ELIMINAR() : void
+ grabar detall e() : boolean + ST OCK_UNIDADES: int
+ MODIFICAR() : void
+ REPORT ES() : void
+ ALT AS() : void
+ BAJAS() : void
1
+ MODIFICACIONES() : void 1. .*
+ REPORT ES() : void
1. .*
1
1
VENTAS
PEDIDO
+/ COD_VENT A: int DETALLE_DE_COMPRA
+ CANT IDAD: int 0..*
+ FECHA_VENT A: int
-/ ID_CLIENT E: int +/ COD_MED: int + CANT IDAD_ENT EROS: int
+ ID_VENDEDOR: int - COD_PEDIDO: int + CANT IDAD_UNIDADES: int
- NRO_FACT : int +/ COD_MED: int
+ PRECIO_T OT AL: int + ADICIONA() : void - NRO_DE_COMPRA: int
+ REPORT ES () : void + PRECIO_ENT ERO: int
+ ALT AS() : void + PRECIO_UNIT ARIO: int
+ BAJAS() : void
+ REPORT ES() : void + ADICIONA() : void
+ MODIFICA() : void
1. .* 1. .* + REPORT ES() : void
1. .*
1. .*
CLIE NTE
- CI_CLIENT E: int
1
+ NOMBRE_APELLIDO: char
+ ADICIONA() : void COMP RAS

+ CONSULT AS () : void 1 + EST ADO DECOMPRA: char
+ ELIMINA() : void - FAC_PROV: int
+ MODIFICA() : void VENDEDOR + FECHA_DE COMPRA: char
+/ NRO_DE_COMPRA: int
+ FECHA_IGRESO: char
- ID_VENDEDOR: int + ADICIONA() : void
+ NOMBRE: char + CONSULT AS () : void
+/ NUM_USUARIO: int + MODIFICACIO N() : void
USUARIOS + T ELEFONO/CELULAR: int
+ ACT IVO: int + ADICIONAR() : void

+ NIVEL _USUARIO: char 1 1 + ELIMINAR() : void
- NUM_USUARIOS: int + MODIFICAR() : void
+ PASSWORD: char
+ USUARIO: char
+ ACT IVA() : void

+ DESACT IVA () : void
1. .*
PRIVIL EGIOS
+ DESCRIPCION: char
- NIVEL: int
+ ACT IVA() : void
Figura Nº 3.38: Diagrama de Clases
120
3.2.5. MODELO ENTIDAD RELACIÓN
Figura Nº 3.39: Modelo Entidad Relación
121
3.2.5.1 ESQUEMA DE LA BASE DE DATOS
Se detalla los atributos de cada entidad de la base de datos para Vital Farm
PRODUCTOS:(cod_med,nombre_de_producto,fecha_de_ingreso,stock_enteros,
stock_unidades,precio_costo_enteros,precio_costo_unitario,precio_venta_enteros,
precio_venta_unitario,fecha_de_venc_1, fecha_de_venc_2,cod_proveedor )
PROVEEDOR: (Cod_Proveedor, Nombre, Telefono , Celular ,Dirección,

Correo_Electronico)
VENDEDOR: (Id_Vendedor , Nombre, Fecha_Ingreso ,Telefono , Celular)
VENTAS:(Nro_Factura, Fecha_Venta,Precio_Total,Id_Vendedor,Ci_Cliente,
Cod_Venta )
CLIENTES: ( Ci_Cliente , Nombre_Apellido)
DETALLE_VENTA:(Cod_Venta,Cantidad_Enteros,Cantidad_Unidades,Cod_Med )
PEDIDO: ( Nro_Pedido,Cantidad,Cod_Med)
COMPRA: (Fac_Pro,Fecha_Compra,Total_Compra,Estado_Compra,Nro_Compra)
DETALLE_DE_COMPRA:(Nro_Compra,Cantidad_Enteros,Cantidad_Unidades,
Precio_Entero,Precio_Unitario,Descuento,Cod_Med )
122
3.2.5.2. DICCIONARIO DE ENTIDADES
ENTIDAD DESCRIPCION
PRODUCTOS Es la entidad donde se crea el nombre del producto su
código el precio y demás detalles del producto.
PROVEEDOR Entidad donde se registra la descripción del proveedor
que se tiene
VENDEDOR Entidad donde se registra a los usuario que utilizaran el
sistema
VENTAS Entidad donde se registra cada venta realizada de cada
vendedor hacia un cliente
CLIENTES Entidad donde se registra los datos importantes del
cliente.
DETALLE_VENTA Entidad donde se registra el detalle de cada venta de
un vendedor hacia un cliente de los diferentes
productos , se registra la fecha venta, la cantidad
PEDIDO Entidad donde se realiza el pedido a los diferentes
proveedores
COMPRA Entidad donde se registra las compras realizadas a los
proveedores , además se registra la fecha de pago
DETALLE_DE_COMPRA Entidad donde se registra el detalle dé cada compra

ingresando producto por producto además de la fecha
de compra
Tabla Nº 3.32: Diccionario de Entidades
123
3.3. ANÁLISIS DE COSTOS Y BENEFICIOS
3.3.1. DETERMINACIÓN DE LOS COSTOS
Para el análisis de costos y beneficios del presente proyecto se utiliza el método
COCOMO, que presenta un detalle de los costos, la estimación de los beneficios y el
posterior análisis costo-beneficio.
3.3.1.1. COSTO DEL SOFTWARE

Para realizar el análisis del costo del software, se emplea el modelo empírico de
estimación de costos COCOMO (Constructive cost Model-Modelo Constructivo de
Costo), el cual fue desarrollado por Barry Boehm.
El modelo COCOMO clasifica los proyectos en tres tipos de proyecto de software que
son:
- Proyectos orgánicos. Son relativamente pequeños con proyectos de software

sencillos en los que el equipo tiene mucha experiencia y tiene pocos requisitos
escritos.
- Proyectos medios. Son intermedios (en tamaño y complejidad), proyectos de

software en los que los miembros del equipo no tiene la misma experiencia. Hay
requisitos intermedios rígidos.
- Proyectos empotrados. Son proyectos software que se deben desarrollar con

requisitos de hardware, software y de operación.
Este proyecto se categoriza dentro del tipo de software de modo orgánico. Pues para
realizar el análisis de costo de software se emplea la aplicación de técnicas de puntos
de función (pf) y el modelo COCOMO. Para el desarrollo de la determinación de costos
existen diferentes modelos que define COCOMO.
- Modelo básico. Que esta basado exclusivamente en el tamaño expresado en

LDC (líneas de codigo)
- Modelo intermedio. Que además de basarse en el tamaño del programa

incluye un conjunto de medidas subjetivas llamadas conductores de costes.
124
- Modelo avanzado. Que incluye todo del modelo intermedio además de impacto
de cada conductor de coste en las distintas fases del desarrollo.
En este caso el modelo intermedio será el que se usara, pues realiza las
estimaciones con aproximaciones al coste de punto función:
Significativo
importancia
Incremental
Moderado
Esencial
ESCALA
Medio
Sin
0 1 2 3 4 5
1.- El sistema requiere copias de seguridad y de
recuperación fiables?
2.- Se requiere comunicación de datos?
3.- Existen funciones de proceso distribuido?
4.- Es critico el rendimiento?
5.-Sera ejecutado el sistema en un sistema operativo

existente?
6.- Requiere el sistema de entrada interactiva?
7.- Requiere el sistema de entrada de datos interactivos

sobre múltiples ventanas?
8.- Se actualizan los archivos maestros de manera
interactiva?
9.- Son complejas las entradas, salidas, archivos o
peticiones?
10.- Es complejo el procesamiento interno?
11.- Se ha diseñado el código para ser reutilizable?
12.- Están incluidas en el diseño la conversión y la

instalación?
13.- Se ha diseñado el sistema para soportar múltiples
instalaciones?
14,- Se ha diseñado la aplicación para facilitar los cambios
y para ser fácilmente utilizada por el usuario?
NIVEL DE INFLUENCIA (∑ Fi) 40
Tabla Nº 3.33: Ajuste de Complejidad de Punto Función
[Fuente: Roger S. Pressman]
125
Ahora podemos calcular el factor de ponderación del software basada en la
contabilización de cinco parámetros los cuales se desarrollan a continuación:
Números de entradas de usuarios, contando cada entrada de usuario que

proporciona al software os diferentes datos orientaos a la aplicación.
Número de salidas del usuario, referidas a informes, mensajes de error, es decir

salida que proporcionen al usuario información orientada a la aplicación.
Número de peticiones de usuario definido como una entrada interactiva que resulta
de la generación de algún tipo de respuesta en forma de salida.
Numero de archivos existentes en la base de datos, en tablas utilizadas por el

usuario, ficheros de procesamiento e índices de referencia.
FACTOR DE PONDERACIÓN
PARÁMETRO DE MEDIDA CUENTA TOTAL
SIMPLE MEDIO COMPLEJO
Número de entradas 3 3 2 6 9
Número de salidas de usuario 3 2 2 8 6
Número de peticiones de usuario 7 3 2 10 21
Numero de archivos 8 7 10 15 56
Numero de interfaces externas - - - - -

Total 92
Tabla Nº 3.34: Calculo de Punto Función Sin Ajustar
Para el cálculo de puntos de función (PF), se utiliza la siguiente ecuación:
PF = Cuenta total * (0.65 + 0.001 * (∑ Fi))
Remplazamos los datos que obtuvimos anteriormente tenemos.
PF =92*(0.65 + 0.001*40)
PF = 63.48
126
Hallamos la variable FAE (conductores de coste) que obtienen mediante la
multiplicación de los valores evaluados en los diferentes 15 conductores que se
observan en la siguiente tabla:
VALORACIÓN
MUY BAJO
MUY ALTO
CONDUCTORES DE COSTE
NORMAL
EXTRA
BAJO
ALTO
ALTO
Fiabilidad requerida del software 0.75 0.88 1.00 1.00 0.75 0.30
Tamaño de la base de datos 0.90 0.50 0.70 0.50 0.25 -
Complejidad del producto 0.70 0.85 1.00 1.15 1.30 1.65
Restricciones de tiempo de ejecución - - 0.75 0.80 0.85 1.65
Restricciones del almacenamiento principal - - 1.00 1.06 1.21 1.56
Volatilidad de la máquina virtual - 0.87 1.00 1.15 1.30 -
Tiempo de respuesta del ordenador - 0.87 1.00 1.07 1.15 -
Capacidad del analista 1.48 1.19 1.00 0.88 0.71 -
Experiencia en la aplicación 1.29 1.13 1.00 0.92 0.82 -
Capacidad de los programadores 1.42 1.17 1.00 0.85 0.70 -
Experiencia del S.O. utilizado 1.21 1.10 1.00 0.92 - -
Experiencias en lenguaje de programación 1.14 1.07 1.00 0.85 - -
Prácticas de programación modernas 1.24 1.10 1.00 0.90 0.82 -
Utilización de herramientas de software 1.24 1.10 1.00 0.81 0.83 -
Limitaciones de planificación de proyectos 1.23 1.09 1.00 1.04 1.10 -
Tabla Nº 3.35: Conductores de Coste
[Fuente:www.wikipedia.es/COCOMO]
FAE = 1*0.94*1.15*1*1*0.87*1*1*1*1*1*1*1*1*1
FAE = 0.94
COEFICIENTES
Proyecto de Software a B c D
Orgánico 3.20 1.05 2.50 0.38
Medio 3.00 1.12 2.50 0.95
Empotrado 2.80 1.20 2.50 0.32
Tabla Nº 3.3.36: Modelo COCOMO
[Fuente: COCOMO]
127
E = Esfuerzo aplicado en el personal por mes
T = Tiempo de desarrollo en meses cronológicos
KLCD = Número estimado de líneas de código
FAE = Conductor de costes
P = Número de personas
a,b,c,d = parámetros según detalle de la tabla
El cálculo para el esfuerzo del empleado por mes se o realiza de acuerdo a la siguiente
formula:
Remplazando la formula resulta:
Calculo para el tiempo de desarrollo de manera cronológica se lo realiza de acuerdo a

la siguiente formula:
T = c*𝐸𝑑
Remplazando datos, el resultado obtenido es:
El cálculo para obtener el número de personas se realiza de la siguiente manera
Remplazando la formula nos resulta:
128
Redondeando resulta como a dos personas para realizar el sistema
Ahora calculamos el costo promedio del software:
Reemplazando la formula resulta:
PROYECTO =1* 6* 200

PROYECTO= 1200 $us
Observando el resultado se obtiene que el costo del proyecto será de $us 1200
Ahora se agrega el costo delas licencias del software:
- COSTO DE LICENCIA
NOMBRE VERSIÓN COSTO

Costo del Software $us 1200
Licencia de Windows Windows 10 $us 50.28
Licencia de visual Studio (Visual Studio Professional $us 100
2012
Licencia de SQL SERVER Server 2008 $us 50.35
Total en $us. $us 1400.63

Total en Bs. Bs. 9748.38
Tabla Nº 3.37: Costo de Software
129
3.3.1.2. COSTO DEL HARDWARE
La estimación del costo del hardware, se describe en la tabla en función de los
dispositivos de hardware que se utilizaran en la institución, tomando en cuenta los
precios del mercado.
Requisitos Descripción Costo $us / Bs.
Procesador Core Intel I5
Memoria RAM DDR3 8 GB
Disco Duro De 500 Gb
15’6 de Diagonal Hd Brightview Con Luz De
Latop HP Core I5 Fondo WLED (1366 X 768 )
NVIDIA Geforce 820 Con 2gb DDR3
4 Celdas
HDMI 3.0 Network (Rj-45
Windows 10 En Español
2.19 Gb 500 $us
Impresora L220 500 $us
Costo Total De Hardware 10000 $us
Costo En Bolivianos 69600 Bs.
Tabla Nº 3.38: Costo de Hardware
[Fuente: Elaboración Propia
COSTO DE INVESTIGACIÓN
La estimación de costos de investigación para la elaboración del documento del

sistema se describe en la siguiente tabla
MATERIAL COSTO
Papelería Bs. 56
Pasajes Bs. 35
Fotocopias Bs. 25
Impresiones Bs. 200
Encuadernado Bs. 210
Otros Bs. 150
TOTAL Bs. 676
Tabla Nº 3.39: Costo de Investigación
130
SUMA TOTAL DE COSTOS
COSTOS TOTALES
COSTO DE SOFTWARE DE LICENCIAS BS. 1400.63
COSTO DE HARDWARE Bs.69600
COSTO DE INVESTIGACIÓN Bs. 676
TOTAL EN BOLIVIANOS Bs.71676.63
TOTAL EN DÓLARES $us. 1098.36
Tabla Nº 3.40: Total Costo de Proyecto
Podemos concluir que el costo del proyecto según el modelo COCOMO es un total de
Bs. 71676.63 y su equivalente en dólares $us. 1098.36
3.3.2. ESTIMACIÓN DE BENEFICIOS
Según los datos referenciales proporcionados por la propietaria de la Farmacia el

monto de pérdidas de manera mensual a causa de la falta de información y manejo
inadecuado de las mismas llega Bs. 780 y una vez implementado el sistema reducirá
a un 70% .
3.3.3. ANÁLISIS COSTO BENEFICIOS

El análisis de costo beneficio es el proceso donde se manejan cifras en unidades
monetarias de diferentes costos y beneficios de la actividad se pretende determinar el
factor de recuperación del capital de inversión de Bs. 6551.38 a una tasa de interés al
2% en un tiempo de 12 meses.
Fórmula para calcular la recuperación del capital:
i(1+i)n
A= P [ (1+ i)n -1 ]
131
El cálculo remplazando la fórmula es:
0.02(1 + 0.02)12
𝐴 = 1328.48 ∗ [ ]
(1 + 0.02)12 − 1
A= 1098.36 * 0.101
A= 110.93 $us.
i= 3%
A=110.93 $us A=110.93 $us A=110.93 $us
P=1098.36
Tabla Nº 3.41. Diagrama de flujo de caja
Se ha llegado a la conclusión de que se recuperara según el detalle en tabla 3.41

Diagrama de flujo de caja con la tasa de interés del 3% se puede recuperar el capital
en un plazo de 12 meses $ 110.93 por cada mes.
132
3.4. CONCLUSIONES
Luego de haber realizado el análisis y diseño del sistema de información de control de
almacén, compra y venta para farmacia VITAL FARM, se logró obtener las siguientes
conclusiones
 Se logró acortar el tiempo de búsqueda de productos dentro de la farmacia para la
dispensación del mismo.
 Permite mejor control de los productos a partir de sus vencimientos.
 Se realiza el control del stock mínimo de los productos dentro de la farmacia.
 Información precisa y confiable.
 Interfaz amigable para el usuario compresible y de fácil manejo.
133
3.5. RECOMENDACIONES
Las recomendaciones que son de común acuerdo entre el cliente y el programador del sistema
es que el sistema para ser integrar debería contar con un área contable, pero masa
importante aún.
 Como usuarios del sistema deben ser consecuentes al momento de procesar
información ya que de ello depende la veracidad del sistema.
 En función a la automatización de los procesos de la farmacia se debe de reasignar
funciones para un mejor desempeño del mismo.
 Debe realizar copias de seguridad de la base de datos cada mes.
 Implementar políticas dirigido al personal de la farmacia para el buen manejo e higiene
de equipo de computación que tenga instalado el sistema
 Gracias a la automatización de los procesos de venta, compra, inventario de
medicamentos en la farmacia los usuarios deberán proponerse enfrentar cambios y
apoyar el mismo y estar dispuestos a su mayor rendimiento.
134
BIBLIOGRAFÍA
ADSIB. (2014). Ley Publica General. La Paz Bolivia.
Alarcon, V. F. (2006). Desarrolo de unsistema de informacion. Barcelona: UPC.
Albert, P. (2010). lenguaje sql. Obtenido de http:/www.lenguajesql.com
ALTO, I. E. (s.f.). Biblioteca .
Bertalanffy, L. v. (1979). Perspectivas en la teoria general de sistemas. Austria:

Alianza,1979.
Coalla, M. P. (2017). Gestion de Inventarios. España,Madrid: Parainfo S. A.
Eduardo, S. (2018). wikipedia. Obtenido de wikipedia: www.wikipedia.es
Erick. (6 de 07 de 2010). wikipedia. Obtenido de www.wikipedia.org
Fernando, A. (2010).
Fernando, M. (2010). .: Derechos Reservados.
FUENTE. (Elaboracion Propia).
Garcia, A. (2011). la web del programador. Obtenido de

www.lawebdelprogramador.com
Gonzalo, M. (2009). UML BASICO. Mexico: editex S.A. .
kendall, S., & Fowler, M. (1999). UML gota a gota. Mexico: Pearson.
Leteiler, P. (2007). wikipedia. Obtenido de www.wikipedia.org
Lokad. (2007). Obtenido de www.lokad.com
Lopez, A. (2010). Seguridad Informatica . Madrid: Editex S.A.
Morales, R. C. (2005). Introduccion al analisis de sistemas y la ingenieria de

software. Costa Rica: Universidad estatal a distancia.
135
Pressman, R. S. (2007). ingenieria de software. mexico: Mc Graw Hill.
Salazar, B. (2016). ingenieria industrial. Obtenido de commons atribucion:

www.metododevaloraciondeinventarios.com
Serrano, J. E. (2015). Tecnicas de Almacen. Madrid. España: parainfo S.A.
Serrano, J. E. (2015). Tecnicas de Almacen. Madrid, España: parainfo S.A.
ANEXOS
136
ANEXO A
ÁRBOL DE PROBLEMAS
Falta de control de Carencia de una aplicación para Pérdida de tiempo en la

vencimientos el control de sus existencias realización de inventarios
Falta una aplicación información de almacén, compra y venta

para la farmacia
Falta de orden en la Falta de organización Farmacia con solo dos

realización de pedidos en el trabajo años de vida
ÁRBOL DE OBJETIVOS
Realizar copias de Brindar reportes Desarrollar módulos

seguridad ‘de la oportunos de existencias, para cada un de las
faltantes, compras, áreas ,
base de datos. ventas de medicamentos
Desarrollar e implementar un sistema de información de almacén de

medicamentos para la farmacia ,que brindara información precisa, evitando
la perdida, merma de los medicamentos, además de clientes, así mismo
hacerla más competitiva en el mercado.
Diseñar una base de

datos para Elaborar manual de El cliente estará satisfecho
almacenar datos de usuario con el software
los medicamentos
ANEXO B
CRONOGRAMA DE ACTIVIDADES PERFIL DE PROYECTO DE GRADO
Nº MARZO ABRIL MAYO JUNIO
ACTIVIDADES
1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4
1 Solicitud de la aceptación de
tema
2 Elaboración del perfil de

proyecto de grado
3 Introducción
4 Antecedentes
5 Descripción del objeto de

estudio.
6 Planteamiento del problema
7 Definición de objetivos
8 Justificaciones
9 Alcances y aportes
10 Técnicas y metodologías
11 Seguimiento del tutor del

proyecto de grado
12 Defensa del perfil de grado

CRONOGRAMA DE ACTIVIDADES DEFENSA DE PROYECTO DE GRADO
Nº SEPTIEMBRE OCTUBRE NOVIEMBRE DICIEMBRE

ACTIVIDADES
1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4
13 Desarrollo del Capítulo III
14 Entrega de documentos del

capítulo I al III
15 Recojo de proyectos
corregido
16 Entrega de proyecto con

Correcciones subsanadas
las observaciones
17 Defensa de Prototipo
18 Entrega del capítulo III

Sin observaciones
19 Entrega de instaladores del

sistema manuales y
documentos sin
observaciones
20 Defensa de Proyecto de
Grado
ANEXO C
FORMATO DE ENTREVISTA
Formato de entrevista
Buenas tardes. Soy estudiante de la carrera de Sistemas Informáticos, le solicito dela

manera más atenta pueda responder esta breve encuesta para la elaboración del
proyecto, le agradezco su colaboración y paciencia.
Antecedentes de la entidad
1. ¿Cuándo inicio o como se presentó la oportunidad de apertura su

farmacia?
2. ¿cuánto tiempo está en funcionamiento la farmacia?
3. ¿Cómo realiza el control de sus existencias?
4. ¿qué dificultades se le presento?
5. ¿conoce de manera real cuales son los medicamentos que está cerca
de su caducidad?
6. ¿Cómo realiza la solicitud a sus proveedores?
7. ¿cree usted que la farmacia necesita un mejor control en el tema de sus
almacenes?
8. ¿Cuáles son sus necesidades para un mejor control?
9. ¿Cómo considera usted poder implementar un sistema de información?
10. ¿Qué es lo que desea mejorar de la farmacia?
11. ¿tiene un buen control de sus existencias?
12. Después de la propuesta de implementación del sistema ¿usted cree
que un sistema de información le ayudaría a un mejor control?
13. ¿Cuál es su opinión respecto al sistema propuesto?
14. ¿Qué desea obtener con el sistema?
ANEXO D
RECOPILACIÓN DE IMÁGENES
INTERIORES DE FARMACIA
VENTA DE PRODUCTOS
UBICACIÓN DE LA FARMACIA
PUNTO DE ATENCIÓN
Capítulo 2

Sistemas Isabel

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Sistemas Isabel

Загружено:

Авторское право:

Доступные форматы

INSTITUTO TÉCNICO COMERCIAL INCOS - EL ALTO

CARRERA SISTEMAS INFORMÁTICOS

“SISTEMA DE INFORMACIÓN DE CONTROL DE ALMACÉN,

PERFIL DE PROYECTO DE GRADO

PARA OPTAR AL TITULO DE TÉCNICO SUPERIOR EN

ANALISTA DE SISTEMAS INFORMÁTICOS

Postulante: María Isabel Quispe Aduviri

Tutor: Lic. Mary Jeanneth Villamil Peñaloza

Revisor: Ing. Omar Augusto Condori Rivera

El Alto, La Paz – Bolivia

A mi madre Isabel, la mujer que más amo,

Gracias a mis amigos que me apoyaron y de mi parte siempre tendrán alguien

Tabla Nº 1.1: Formulario de inventario mensual ................................................................... 7

En la actualidad los sistemas de información han venido evolucionando y la tecnología

Los sistemas de información benefician de manera significativa a las pequeñas y

Las empresas que se dedican a la comercialización de productos farmacéuticos

 Un regente farmacéutico que suministre los productos a los pacientes

El presente capitulo tiene una breve descripción de los antecedentes de la entidad,

De acuerdo al estudio y la necesidad de la Farmacia se determina el objetivo principal

De acuerdo al estudio y determinación del sistema se describe la metodología que se

Contribuir al bienestar de los ciudadanos creando felicidades y ofreciendo el mejor

Ser una institución líder reconocida y distinguida en el mundo farmacéutico de toda

Figura Nº 1.1: Organigrama

[Fuente: Elaboración Propia]

1.2.1.2.2. Auxiliar de enfermería

Realizan un reconteo de los medicamentos, con el fin de hacer notar a administración

1.2.2. ANTECEDENTES DE PROYECTOS AFINES

Después de buscar en la biblioteca de INCOS El Alto, UMSA, UPEA y otras

 TITULO: Sistema de información para control de inventarios de mercadería en

AUTOR: Ximena Poma Sarmiento

INSTITUCIÓN: Incos – El Alto

El sistema consiste en actualizar la información de sus inventarios, realizados

La similitud es que este sistema se desarrolla en visual Basic, también que se

El sistema es para se desarrolla para un almacén muy amplio lo cual amplia el

 TITULO: Sistema de inventario para el control de microempresa textilera Caso:

AUTOR: Juan Carlos Machaca Quenta

INSTITUCIÓN: INCOS – EL ALTO

Este sistema está realizado en visual Basic, es un sistema de control de

La similitud de este sistema es que el control es dentro de la empresa sin

La diferencia es que su método de control de inventario es perpetuo el cual este

 TITULO: Sistema web de control de compras, ventas e inventarios caso.

AUTOR: Carrillo Cruz Emmi Escaret

INSTITUCIÓN: Universidad Mayor de San Andrés

A medida que va creciendo la empresa, también crece la cantidad de

El desarrollo del proyecto se basó en las fases propuestas por la metodología

La similitud de este sistema es que el control es dentro de la empresa de

La diferencia es que su método de control esta realizado en programación java,

AUTOR: Sarco Mendoza Mónica

INSTITUCIÓN: UNIVERSIDAD MAYOR DE SAN ANDRÉS

El proyecto fue desarrollo bajo la metodología Agial XP en sus distintas fases

Este sistema también es aplicable a una empresa en el área de almacenes para

La diferencia es que su método de control de inventario se apicara en farmacia

1.3. DESCRIPCIÓN DE OBJETO DE ESTUDIO

1.3.1. Almacén de Productos

Tabla Nº 1.1: Formulario de inventario mensual

[Fuente: Farmacia VITAL FARM]

El personal de la farmacia al realizar el reconteo de medicamentos registra:

 Descripción del mismo especificando su presentación (jarabe, crema, tableta)

 La cantidad que se tiene (enteros, unidades)

 Laboratorio que es el proveedor del medicamento

Figura Nº 1.2: Cuaderno de Registro de Ventas

[Fuente: Farmacia Vital Farm]

 Fecha del día

 Total caja (venta del día anterior)