Sistemas Isabel

 

INSTITUTO TÉCNICO COMERCIAL 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 seguir adelante y vela para que nunca me falte nada.  A mi hermano Franz a quien quiero mucho por su cariño 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 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 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 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 2  1.2.1.1. Visión y Misión de Vital Farm ......................................................................................... 2  1.2.1.2. Organigrama................................................................................................................... 2  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 1.8.1.1. Ent revista ................................................ ................................................................................................... ...................................................................... ................... 20 20   1.8.1.2. Observación ................................................................................................................. 21  21  1.8.1.3. Documentación ............................................................................................................ 22  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ítulo2

CAPÍTULO 2……….. ...................................................................................................................... ………24

2. INTRODUCC INTRODUCCION ION............................................ ................................................................................................ ....................................................................... ................... 24 2.1. SISTEMA ............................................................................................................................ 24 24   2.1.1. SISTEMA DE INFORMACIÓN ........................................................................................ 24 2.1.2 INVENTA INVENTARIO RIO............................................... ................................................................................................. ..................................................................... ................... 25 25   2.1.3 STOCK ............................................................................................................................. 25  25  2.1.4. EXISTENCI EXISTENCIAS AS ................................................... ....................................................................................................... .............................................................. .......... 26 26   2.1.5. TIPOS DE INVENTARIO ................................................................................................ 26  26  2.1.6. MÉTODOS DE CONTROL DE INVENTARIOS ............................................................. 28  28  2.1.7. INGENIERÍA DEL SOFTWARE ...................................................................................... 29  29   2.2. ANÁLISIS Y DISEÑO ......................................................................................................... 30 30  2.2.1. ANÁLISIS DEL SISTEMA ............................................................................................... 30  ........................................................................................................ ...................................................................... ................... 30 30   2.2.2. DISEÑO ..................................................... 2.2.3 METODOLOGÍA DE DESARROLLO RATIONAL UNIFIED PROCESS P ROCESS (RUP) ............. ............. 30 30   ....................... ............. ......37 37   2.2.5. HERRAMIENTA LENGUAJE UNIFICADO DE MODELADO (UML) ................ 2.3. BASE DE DATOS............................................................................................................... 46 47   2.3.1. SISTEMA DE GESTIÓN DE BASE DE DATOS ............................................................. 47  2.3.2. BASE DE DATOS RELACIONAL ................................................................................... 47  47  2.3.3. SQL SERVER .................................................... ........................................................................................................ .............................................................. .......... 47 47   48   2.3.4. TIPOS DE SENTENCIAS SQL ....................................................................................... 48 2.3.5. TIPOS DE DATOS .......................................................................................................... 48  48   IDENTIFICADORES DORES ................................................... ........................................................................................................ ..................................................... 48 48   2.3.6. IDENTIFICA 49   2.3.7. FUNCIONES PREDEFINIDAS ....................................................................................... 49 2.4. LENGUAJE DE PROGRAMACIÓN VISUAL BASIC ......................................................... 49 2.4.1. APLICACIONES PROCEDURALES............................................................................... 49 49   2.4.2. APLICACIONES MANEJADAS POR EVENTOS ........................................................... 49 49   2.5 SEGURIDAD ....................................................................................................................... 50 2.5.1. SEGURIDAD POR CONTRASEÑAS ............................................................................. 51  51  2.5.1.1 CONCEPTO DE CONTRASEÑA .................................................................................. 51 51   2.5.1.2 TIPOS DE CONTRASEÑA ........................................................................................... 52  52   SE GURIDAD DE CONTRASEÑAS ....... ............. ............. ........... .... 53 53   2.5.1.3. ACERCA A CERCA DE LOS NIVELES DE SEGURIDAD

 

 

....................................................................................................... ..................................................................... ................... 53 53   2.5.2. BACKUP ..................................................... .............. ............. ............. .............. ............. ......54 54   2.5.2.1. BACKUP EN MEDIOS DE ALMACENAMIENTO MASIVO ....... 2.5.2.2. BACKUP EN LA NUBE ................................................................................................ 57  57  2.6. ASPECTO LEGAL .............................................................................................................. 58 2.6.1 DERECHOS DE AUTOR DE DESARROLLO DE SOFTWARE ............ .................. ............. .............. ............ .....58 58   Capítulo 3

CAPÍTULO 3 ............................................................................................................................................... 65 3. INTRODUCC INTRODUCCIÓN IÓ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 66   3.1.2.2. Diagramas de Caso de Uso ......................................................................................... 70  70  3.1.2.3. Diagrama de Actividades ............................................................................................. 76  76  3.1.2.4. Modelo de Objetos ....................................................................................................... 82  82  3.1.3. MODELO DEL SISTEMA ................................................................................................ 85 85   3.1.3.1. ANALISIS DE REQUERIMIENTOS ............................................................................. 85 3.1.3.1.1. REQUERIMIENTOS FUNCIONALES GENERAL .................................................... 85  85  3.1.3.1.2. REQUERIMIENTOS FUNCIONALES ESPECIFICOS ............................................. 86  86  3.1.3.1.2.1. FUNCIÓN DE ALMACÉN DE PRODUCTOS ........................................................ 86  86  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  87  3.1.3.1.2.4. FUNCIÓN DE COMPRA ........................................................................................ 87  87   3.1.3.1.2.5 .FUNCIÓN DE CLIENTE......................................................................................... 88  88  3.1.3.1.2.6 .FUNCIÓN DE CATEGORIA DE PRODUCTOS .................................................... 88  88   3.1.3.1.2.7. FUNCION DE DEVOLUCION DE PRODUCTOS ................................................. 88  88   89   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  106  3.2.2 DIAGRAMAS DE ESTADOS DEL SISTEMA ................................................................ 109  109  3.2.3. CASOS DE USO REALES ............................................................................................ 112  112  

 

 

3.2.4. DIAGRAMA DE CLASES .............................................................................................. 120  120  3.2.5. MODELO ENTIDAD RELACION .................................................................................. 121  121  3.2.5.1 ESQUEMA DE LA BASE DE DATOS ........................................................................ 122  122   3.2.5.2. DICCIONARIO DE ENTIDADES ............................................................................... 123  123  3.3. ANÁLISIS DE COSTOS Y BENEFICIOS ........................................................................ 124 3.3.1. DETERMINACIÓN DE LOS COSTOS ......................................................................... 124  124   3.3.1.1. COSTO DEL SOFTWARE ......................................................................................... 124  124  130   3.3.1.2. COSTO DEL HARDWARE ........................................................................................ 130 3.3.2. ESTIMACIÓN DE BENEFICIOS ................................................................................... 131  131   3.3.3. ANÁLISIS COSTO BENEFICIOS ................................................................................. 131  131   3.4. CONCLUS CONCLUSIONES IONES ..................................................................................................... ................................................. ............................................................ ........ 133 3.5. RECOMENDACIONES .................................................................................................... 134 BIBLIOGRAFIA BIBLIO GRAFIA ..................................................... ....................................................................................................... ................................................................... ................. 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: Fo Formato rmato de pedido de medicamentos a La Laboratorio boratorio .............. .................... ............. .............. .......... ... 9 Figura Nº 1.4: Registro de Compras .................................................................................... 12 Figura Nº 1.5: Factura de Compras ..................................................................................... 13 Figura Nº 1.6: Codificación de med medicamentos icamentos [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: 2 .4: Los m modelos odelos se ccompletan, ompletan, la arquitectura no cambia drásticamente ....... ......... 34 Figura Nº 2.5: Una Iteración RUP ........................................................................................ 35 Figura Nº 2 2.6: .6: Es Esfuerzo fuerzo e en n actividades según fase del proyecto ............. .................... ............. ............. .............. ....... 36 Figura Nº 2.7: Esquema de la cclasificación lasificación de diagramas ....... .............. .............. ............. ............. .............. .............. ......... .. 42 Figura Nº 3.1: Diagram Diagrama a 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: 3 .4: Diagrama de Caso de Uso de Compra de Productos a Proveedor ...... ............. ....... 73 Figura Nº 3.5: Diagram Diagrama a de Caso de Uso Cod Codificación ificación de Productos ....... .............. .............. ............. ........... ..... 74 Figura Nº 3 3.6: .6: Diagram Diagrama a de Caso de Uso Devolución de Productos ....... .............. ............. ............. .............. ....... 75 Figura Nº 3.7: Diagrama de Actividades de Inventario de Pro Productos ductos en Almacén ...... ............. ....... 76 Figura Nº 3.8: Diagram Diagrama a de Actividades de Venta de Productos....... Productos.............. .............. ............. ............. ............. ...... 77 Figura Nº 3 3.9: .9: Diagram Diagrama a 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 d de e Venta de Productos....... .............. ............. ............. .............. .............. .......... ... 82 Figura Nº 3 3.15: .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 Produ ctos ........................................................................................................ .................................................... .......................................................................... ...................... 84 Figura Nº 3.18: Diagrama d de e 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: 3 .21: Diagrama de Caso de Uso d de e Venta de Productos de Sistema ....... .............. .......103 Figura Nº 3.22: Diagrama de Caso de Uso de Pedido a Labora Laboratorio torio 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 d de e 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 3.27: .27: Diagrama de Secuencias de Compra d de eP Productos roductos ....... .............. ............. ............. ............ ..... 108 Figura Nº 3 3.28: .28: Diagrama de Secuencia de Devolución d de e Productos ...... ............. .............. ............. ......... ... 109 Figura Nº 3.29: Diagrama de Estado de Inventario d de e Almacén....... .............. .............. ............. ............. ............ ..... 110 Figura Nº 3 3.30: .30: Diagrama de Estado d de e Venta de Productos ....... ............. ............. .............. .............. .............. ......... .. 110 Figura Nº 3 3.31: .31: Diagrama de Estado d de e 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 .................................. mensual ................................................................... ................................. 7 Tabla Nº 1.2: Lista de pr proveedores oveedores y contactos (responsables)  (responsables) ......................................... ......................................... 11 11 Tabla Nº 1.3: Lista de medicamentos frecuentes ........................................................ 14 med icamentos más frecuentes ........................................................ Tabla Nº 3.1: Caso de Uso de Alto Nivel Inventarios de Almacén ...................................... Almacén  ...................................... 66 Productos ............................................  ............................................ 67 Tabla Nº 3.2: Caso de Uso de Alto Nivel Venta de Productos Tabla Nº 3.3: Caso de Uso de Alto Nivel Pedido a Laboratorio .......................................... 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 .......................... Medicamentos  .......................... 68 Tabla Nº 3.6: Caso de Uso de Devolución de Productos .................................................... Productos  .................................................... 69 General ..............................................  .......................................................... ............ 85 Tabla Nº 3.7 : Requerimientos Funcionales General Tabla Nº 3.8: Funciones de Almacén de Productos ............................................................ Productos ............................................................ 86 Tabla Nº 3.9: Función de Ventas .................................................................. ....................... 86 Ventas ......................................................................................... Laboratorio  ................................................................ .................................................. ............ 87 Tabla Nº 3.10: Función de Pedido de Laboratorio Tabla Nº 3.11: Función de Compra Compra  ...................................................................................... ................................................ ...................................... 87 Cliente ................................................................  ....................................................................................... ....................... 88 Tabla Nº 3.12: Función de Cliente Productos .............................................................................  .................................................................................. ..... 88 Tabla Nº 3.13: Función de Productos Tabla Nº 3.14: Función de Devolución Devolución.................................................. ................................................................................. ............................... 88 Tabla Nº 3.15: Requerimientos no Funcionales Funcionales ......................................................  .................................................................. ............ 89 Tabla Nº 3.16: Caso de Uso de Sistema................ 91 d e Alto Nivel Inventarios de Almacén del Sistema................ Sistema ...................... 92 Tabla Nº 3.17: Caso de Uso de Alto Nivel Venta de Productos del Sistema  Tabla Nº 3.18: Caso de Uso de Alto Nivel Pedido a Laboratorio del Sistema Sistema  .................... 92 Tabla Nº 3.19: Caso de Uso de Alto Nivel Compra a Proveedor del Sistema  Sistema .................... 93 Tabla Nº 3.20: Caso de Uso de Productos  ........................... 93 d e Alto Nivel Categorización de Productos ........................... Sistema.............................. 94 Tabla Nº 3.21: Caso de Uso de Devolución de Productos del Sistema.............................. Tabla Nº 3.22: Diagrama de Caso de Uso Expandido de Inventario de Productos en  Almacén  ...........................................................................................................  Almacén ..................................................... .......................................................................... ...................... 95 Productos  .................. 96 Tabla Nº 3.23: Diagrama de Caso de Uso Expandido de Venta de Productos .................. Laboratorio ................  ................ 97 Tabla Nº 3.24: Diagrama de Caso de Uso Expandido de Pedido a Laboratorio ..... 98 Tabla Nº 3.25: Diagrama de Caso de Uso Expandido de Compra de Productos ......... Productos  .............. Tabla Nº 3.26: Diagrama de Caso de Uso Expandido de Categorización de Productos Productos ...  ... 99 Tabla Nº 3.27: Diagrama de Caso de Uso Expandido de Devolución de Productos  Productos .......100

 

 

Tabla Nº 3.28: Diagrama de Caso de Uso Real de Inventario de Productos en Almacén112 Almacén 112 Tabla Nº 3.29: Diagrama de Caso de Uso Real de Venta de Productos  Productos .......................... 114 Laboratorio:  ....................... 116 Tabla Nº 3.30: Diagrama de Caso de Uso Real de Pedido a Laboratorio: ....................... Productos ...................... 118 Tabla Nº 3.31: Diagrama de Caso de Uso Real de Compra de Productos ...................... ........... 123 Tabla Nº 3.32: Diccionario de Entidades ................................................................ Entidades ........................................................................... Función ................................................. Tabla Nº 3.33: Ajuste de Complejidad de Punto Función ..................................... ............ 125 Tabla Nº 3.34: Calculo de Punto Función Sin Ajustar  .......................................................  ....................................................... 126 Coste ...........................................................  ............................................................................... .................... 127 Tabla Nº 3.35: Conductores de Coste COCOMO  ................................................................................... Tabla Nº 3.3.36: Modelo COCOMO  ............................................... .................................... 127 Tabla Nº 3.37: Costo de Software Software  ....................................................................................... ................................................. .................................... 129 Tabla Nº 3.38: Costo de Hardware Hardware ................................................................  .................................................................................... .................... 130 Investigación  ................................................................................ ................................................. ............................. 130 Tabla Nº 3.39: Costo de Investigación Tabla Nº 3.40:Total Costo de Proyecto................................................. Proyecto .............................................................................. ............................. 131 Tabla Nº 3.41. Diagrama de flujo de caja ................................................................ .......... 132 caja ..........................................................................

 

 

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 los productos a los pacientes



  Cajero que cobre por la la venta de los fármacos



  Un responsable que generalmente es el propietario que que realice 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 ENT IDAD

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. Dra. Farmacéutica Cinthya Copa Cossío Cossío (propietaria), (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 ciudada no 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 Enfermería Turno Mañana

Auxiliar de Enfermería Turno Tarde

Portero

Figura Nº 1.1: Organigrama [Fuente: Elaboración Propia]

2

Personal de Limpieza

 

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. Admi Administración nistración

Está conformada por la propietaria, la cual además ade má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 h acer 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 pro yectos 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: Cas o:



“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” 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 u na 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 car go 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 proc eso 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 vencimiento

Nro.

Descripción Laboratorio

Cantidades

Tabla Nº 1.1: Formulario de inventario mensual [Fuente: Farmacia VITAL FARM]

El personal de la farmacia al realizar e ell 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 arqueo 1 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 escr ita tomado solo prioridad a los medicamentos que se acaba con frecuencia fr ecuencia y no asi a los fármacos que están siendo requeridos en nuevas recetas. Laboratorio

Fecha

Descripción

Especifica ción de NIT

Cantidad

Figura Nº 1.3: Formato de pedido de medicamentos a Laboratorio [Fuente: Farmacia Vital Farm]

 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  A rqu rqueo eo de C aja:   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 arrojacheques esta cuenta corresponde con lo que se encuentra físicamente en caja  en dinero que efectivo, 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 DROG UER A INTI 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 PRODEXA

Sra. Gloria Ecinas Del Pilar 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) [Fuente: Farmacia Vital Farm]

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 [Fuente: Farmacia Vital Farm]

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 [Fuente: Farmacia Vital Farm]

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 [Fuente: Farmacia Vital Farm]

En el caso de los medicamentos ya caducados, se realiza la devolución a los laboratorios, laboratorio s, 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 laboratori laboratorio o

no repone los mismos, mism os, 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

Figura Nº 1.6: Codificación de medicamentos [Fuente: Farmacia Vital Farm]

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 despachand o el producto con el precio codificado c odificado.. 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 res pectivos 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 liberan do 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 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 ad emá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 (v er anexo A formato de entrevista). entrev ista).

1.8.1.2. Observación  Observación   Esta técnica que consiste en observar atentamente el objeto de estudio , la observación es un elemento fundamental de todo proceso pr oceso 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 proc eso 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 d e 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 co mplementa 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 pr onto 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 art efactos 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 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

 

Capítulo 2

CAPÍTULO 2 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, disk ette, 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 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 p ara 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: F IFO:   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 desarro llo 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] 

L A ARQUITECTURA - PROCESO CENTRADO EN LA 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 considera ciones 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 deb e 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 arq uitectura por medio de baselines y se va v a modificando dependiendo de las necesidades del proyecto.

Ince Incept ptio ion n

El Elab abor orat atio ion n

Co Cons nstr truc ucti tion on

 

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, c ompletan, la arquitectura no cambia drásticamente  [FUENTE: (Leteiler, 2007)]  

 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 d ivide en partes más pequeñas o mini proyectos. pr oyectos. 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 [FUENTE:  (Leteiler, 2007)] 

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 c ontinú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 [FUENTE:  (Leteiler, 2007)] 

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 el Object  Object Management Group (OMG). Es un lenguaje gráfico para visualizar, especificar, construir y documentar docu mentar 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 el Proceso Unificado Racional,  Racional,   Rational Unified Process o RUP) 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,  estructurada,  pues UML significa Lenguaje Unificado de Modelado, no es programación, solo se diagrama diagra ma 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 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 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 es e 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 activ idades 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 estr uctura 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 q ue 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 posible enseñar al cliente 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 constr uir 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 co mportamiento 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 te mporal 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 entr e 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 clas ificación de diagramas [FUENTE: (Leteiler, 2007)]

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 los diagramas de casos de de uso, colaboración, estados y actividades. 2. Vista de diseño: se forma con los los diagramas de clases, objetos, colaboración, estados y actividades. 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, estados y actividades.

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 () o de Herencia (). 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 s e 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 es tados 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 v ienen provocadas por la finalización de las acciones que tienen lugar en los estados es tados 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 proc edimiento 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 independientes de los los programas que los usan.



  Se emplean métodos determinados para 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 los datos. datos, así como modificar, borrar y   Manipular los datos. Es decir insertar nuevos datos, consultar los datos existentes.  

Mantener la integridad integridad de de la información

 

Proporcionar control de la privacidad y seguridad delos datos de la base 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 p ueden realizarse utilizando sentencias SQL. (Albert, 2010)  

Consultar datos de la base de datos

 

Insertar modificar y borrar datos.

 

Crear, modificar modificar y borrar objetos de la base de datos.

 

Controlar el acceso a la información

 

Garantizar la consistencia de los 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 pro pios 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 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,  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 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 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 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 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 co mo las huellas digitales o el aspecto de la cara, para permitir el acceso. Un ejemplo es el escáner 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 d atos 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 d ispositivos 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 ci nta 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 otr os 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 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 e l mismo enfoque de copiar a las cintas luego de hacer el respaldo, como se mencionó anteriormente). Además, Ade má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 pr oveedor 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 L A NUBE El almacenamiento en la nube se compra a un proveedor de d e 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 ALMACENA ALMACENAMIENTO MIENTO EN LA L A 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 p ara 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 SARROLLO 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 Des arrollo de la Sociedad de d e la Información en Bolivia (ADSIB) (A DSIB) 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 co n 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. hace rlo. 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 expone n 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 c ualquier 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 derec hos 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 lo s 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 ho y 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 d e 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

 

Capítulo 3

CAPÍTULO 3 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.  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 comienza cuando, la dueña 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 [Fuente: Elaboración Propia] 

66

 

- VENTA DE PRODUCTOS  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 [Fuente: Elaboración Propia]

- 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 c uando el laboratorio hace llegar el pedido Tabla Nº 3.3: Caso de Uso de Alto Nivel Pedido a Laboratorio [Fuente: Elaboración Propia]

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 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 [Fuente: Elaboración Propia]

- 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 [Fuente: Elaboración Propia]

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 [Fuente: Elaboración Propia]

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 [Fuente: Elaboración Propia]

70

 

-VENTA DE PRODUCTOS uc DIAGRAMAS DE CASO DE DE USO VENTAS

VENTA DE PRODUCTOS

INGRESA A LA PREGUNTA LA

FARMACIA

NECESIDAD

SOLICITA PIDE PRODUCTO

RECETA MEDICA

CLIENTE LE OFRECE

VENDEDOR

PRODUCTOS DELA MISMA COMPOSICION PERO DE DISTIN DISTINAS AS

PREGUNTA DE CUANTOS CUANT OS PRE CIOS TIENE

MARCAS

LE DICE EL TOTAL

CANCELA EL TOTAL

AUXILIAR TU TURNO RNO TARDE

AUXILIAR TURNO TURNO

MAÑANA

LE ENTREGA LOS PRODUCTOS

REGISTRA LA VENTA EN EL CUADERNO CUADERNO DE VENTAS

SE R ETIRA ETIRA

Figura Nº 3.2: Diagramá de Caso de Uso de Ventas [Fuente: Elaboración Propia] 

71

 

- PEDIDO A LABORATORIO

Figura Nº 3.3: Diagrama de Caso de Uso de Pedido a Laboratorio [Fuente: Elaboración Propia] 

72

 

-COMPRA DE PRODUCTOS A PROVEEDOR

Figura Nº 3.4: Diagrama de Caso de Uso de Compra de Productos a Proveedor   [Fuente: Elaboración Propia] 

73

 

- CODIFICACIÓN DE PRODUCTOS

Figura Nº 3.5: Diagrama de Caso de Uso Codificación de Productos [Fuente: Elaboración Propia] 

74

 

-DEVOLUCIÓN DE PRODUCTOS

Figura Nº 3.6: Diagrama de Caso de Uso Devolución de Productos [Fuente: Elaboración Propia] 

75

 

3.1.2.3. Diagrama de Actividades - INVENTARIO DE PRODUCTOS EN ALMACÉN  

Figura Nº 3.7: Diagrama de Actividades de Inventario de Productos en Almacén [Fuente: Elaboración Propia]

76

 

- VENTA DE PRODUCTOS

Figura Nº 3.8: Diagrama de Actividades de Venta de Productos [Fuente: Elaboración Propia] 

77

 

-PEDIDO A LABORATORIO

  Figura Nº 3.9: Diagrama de Actividades de Pedido a Laboratorio [Fuente: Elaboración Propia] 

78

 

-COMPRA DE PRODUCTOS

Figura Nº 3.10: Diagrama de Actividades de Compras de Productos [Fuente: Elaboración Propia] 

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  [Fuente: Elaboración Propia] 

80

 

-DEVOLUCIÓN DE PRODUCTOS

Figura Nº 3.12: Diagramas de Actividades de Devolución de Productos [Fuente: Elaboración Propia] 

81

 

3.1.2.4. Modelo de Objetos -INVENTARIO DE ALMACÉN DE PRODUCTOS ct ALMACEN DE MEDICAMENTOS

PRODUCTO AUXILIAR PROPIE TARIO

INVENTARIO MANUAL LLENO

INVENTARIO MANUAL (VACIO )

EDIDO A LABORATORI O

Figura Nº 3.13: Diagrama de Objetos de Inventario de Almacén de Productos  [Fuente: Elaboración Propia]    -VENTA DE PRODUCTOS

CLIENTE  AUXILIA R RECETA MEDICA

CUADERNO CUAD ERNO DE FALTA NTES EN VENTA PRODUCTO

REGISTRO DE CUADERNO DE VENTAS

FACTURA FACTUR A DE V ENTA

Figura Nº 3.14: Diagrama de Objetos de Venta de Productos [Fuente: Elaboración Propia] 

82

 

-PEDIDO A LABORATORIO

PRODUCTO

LABORATORIO

 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  [Fuente: Elaboración Propia]

-COMPRA DE PRODUCTOS  

PRODUCTO LABORATORIO

FACTURA DE PEDIDO

 AUXILIAR

HOJA DE PEDIDO

REGISTRO DE PAGO

CUADERO CUADER O DE COMP RAS( LISTA DE LABORATORIOS)

RECIBO DE PAGO

Figura Nº 3.16: Diagrama de Objetos de Compra de Productos  Productos  [Fuente: Elaboración Propia] 

83

 

-CATEGORIZACIÓN DE PRODUCTOS POR MEDIO DE SU CODIFICACIÓN DE PRODUCTO

auxiliar 

p ro d u ct o

T I M BRE

FACTURA

Figura Nº 3.17: Diagrama de Objetos de Categorización por Medio de Codificación de Productos [Fuente: Elaboración Propia]   

-DEVOLUCIÓN DE PRODUCTOS

AUXILIAR

LABORATORIO

PROPIETARIA

PRODUCTO

PRODUCTO NUEVO

Figura Nº 3.18: Diagrama de Objetos de Devolución de Productos  Productos  [Fuente: Elaboración Propia] 

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.

RF 1.1 RF 1.2 RF 1.3 RF 1.4 RF 1.5 RF 1.6 RF 1.7 RF 1.8 RF 1.9 RF 1.10 RF 1. 11 RF 1. 12 RF 1.13 RF 1.14 RF 1.15 RF 1.16 RF 1.17 RF1.18

FUNCIÓN El sistema validara el ingreso del usuario al sistema. La encargada así como el personal de trabajo deberá tener un código así como una contraseña para poder ingresar a su módulo correspondiente El sistema permitirá ingresar la información de los productos pro ductos en la base de datos. El sistema permitirá ingresar la información de los proveedores en la base de datos El sistema registrara el movimiento de los productos. El responsable podrá introducir el medicamento a buscar. El sistema mostrara el medicamento que se quiere vender El sistema registrara el detalle de la venta de productos El sistema permitirá verificar la existencia de los productos. El sistema permitirá registrar a solicitud de productos. El sistema permitirá registrar la compra de los medicamentos Podrá actualizar el inventario actual de la farmacia. El sistema deberá mostrar el precio de compra y de venta de cada producto. Permitirá actualizar los precios, además del nombre de cada producto. Permitirá alertar que productos están con corto vencimiento para su venta más próxima. El sistema mostrara en la ventana cada consulta requerida. Generará reportes de las consultas requeridas 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 funcionales

3.1.3.1.2.1. FUNCIÓN DE ALMACÉN DE PRODUCTOS Ref. 2

FUN FU NCI N

RF RF 2.1 2.2 RF 2.3

El generar el ingreso salidalos dedatos medicamentos. El usuario sistemapodrá generara un informe de ytodos que requiere el usuario, ya sea de compra, ventas, e inventario. El usuario podrá actualizar los vencimientos de los productos

RF 2.4

Es sistema permitirá la edición de los productos.

RF 2. 5 RF 2.6

El sistema deberá mostrar a detalle el movimiento de cada producto. El sistema deberá manejar un mecanismo de almacenamiento continuo. El usuario podrá imprimir los reportes para el control de inventario toma de decisiones. El sistema permitirá modificar las características de los productos.

RF 2.7 RF 2.8.

Tabla Nº 3.8: Funciones de Almacén de Productos [FUENTE: Elaboración Propia]

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.

3.4 RF 3.5

introducir datos para a venta. El usuario sistemapodrá guardara cada registro de realizar venta (ID de cliente, apellido, total venta, fecha de venta). Calculara el total de cada venta realizada. El sistema generara el reporte de cada venta para así poder detallar la factura manual. El sistema deberá reducir la existencia delos productos vendidos, para tener una existencia actual El sistema mostrara los productos en existencia cero como faltantes en venta. El sistema mostrara los productos con stock cero

RF 3.6 RF 3.7 RF 3.8 RF 3.9 RF 3.0

Tabla Nº 3.9: Función de Ventas [FUENTE: Elaboración Propia]

86

 

3.1.3.1.2.3 .FUNCIÓN DE PEDIDO DE LABORATORIO L ABORATORIO Ref. 4 RF 4.1 RF 4.2

FUNCIÓN El usuario tiene los datos de las existencias, faltantes productos. El sistema deberá generar el reporte de la información requerida.

RF 4.3

El los sistema mostrara, un tiempo de productos paraen poder realizardeelintervalo pedido dado del movimiento ( mensual, semanal, trimestral) El sistema tendrá la posibilidad poder introducir mínimos y máximos de cada producto, para no sobrepasar su stock. El usuario podrá realizar un pedido de acuerdo a el laboratorio solicitado El sistema guardara el registro de los pedidos realizados El sistema generara el reporte del pedidos realizado asignando un numero de pedido 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).

RF 4.4 RF 4.5 RF 4.6 RF 4.7 RF 4.8

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 RF 5.3 RF 5.4

El sistema deberá almacenar la información de los proveedores El usuario podrá ingresar cada productos de manera opcional los vencimientos de los mismos 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 [FUENTE: Elaboración Propia]

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. RF 6.3

El sistema deberá guardar el CI, o NIT de cada cliente. 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 [FUENTE: Elaboración Propia]

3.1.3.1.2.6 .FUNCIÓN DE CATEGORÍA DE PRODUCTOS Ref. 7

FUNCIÓN

RF 7.1.

RF 7.3.

El usuario tiene conocimiento de los medicamentos los cuales son con receta obligatoria El sistema deberá clasificar los sistema psicotrópicos y los estándares para su mayor control 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.

RF 7.2.

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. El usuario podrá generar un reporte de todas las devoluciones

RF 8.4.

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. # RNF- 1 RNF- 2 RNF- 3 RNF- 4 RNF- 5 RNF- 6 RNF- 7 RNF -8 RNF- 9 RNF- 10

FUNCIÓN El sistema deberá ser instalado en la unidad principal del disco duro. El sistema presentara portabilidad, que quiere decir puede ser instalado en otro equipo El sistema debe estar desarrollado en plataforma Windows para su fácil uso Se utilizara iconos estándares para su fácil manipulación El diseño y la presentación deberá ser amigable para su fácil manejo del usuario Mostrará una alerta de medicamentos con recetas obligatorios Es sistema contara con un registro de usuarios realizado por el administrador para limitar el acceso de los mismos. El sistema tendrá un manual de usuario para su mejor comprensión Generará para que permitan tener una mejor toma de decisiones.reportes para El sistema realizara una copia de seguridad en la base base de datos. 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 toma de decisiones

89

 

 

Controla la la existencia física juntamente juntamente con el inventario realizado

 

Asigna funciones a cada una de las las auxiliares

 

Realiza la solicitud solicitud de compra de los productos

 

Registra cada compra realizada

 

Realiza el pago a sus proveedores

- Auxiliar de Farmacia (Turno Mañana) M añ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 llegan a la farmacia. farmacia. 

 

Realiza pedido de ciertos productos



  Realiza la venta de de los medicamentos medicamentos Registra la venta realizada al igual que el total total cancelado

   

Registra los productos faltantes dentro de la la farmacia

 

Realiza el inventario de los los laboratorios asignados 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 llegan a la farmacia. farmacia. 

 

Realiza pedido de ciertos productos

 

Realiza la venta de de los medicamentos medicamentos

 

Registra la venta realizada al igual que el total total cancelado

 

Registra los productos faltantes dentro de la la farmacia

 

Realiza el inventario de los los laboratorios asignados 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 la farmacia farmacia

 

Emite facturas o notas de entrega

 

Entrega lista de nuevos medicamentos medicamentos

- Cliente  

Ingresa para solicitar solicitar productos dentro de la farmacia 

 

Solicita factura

 

Cancela el total 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. - INVENTARIO DE PRODUCTOS EN ALMACÉN 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 [Fuente: Elaboración Propia]

91

 

PRODUCTOS  - 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, la auxiliar verifica la existencia, sino hay en la farmacia el cliente se retira y si hay la auxiliar revisa rev isa 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 s atisfecho con compra realizada Tabla Nº 3.17: Caso de Uso de Alto Nivel Venta de Productos del Sistema [Fuente: Elaboración Propia]

- PEDIDO A LABORATORIO

CASO DE USO: PEDIDO A LABORATORIO  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 [Fuente: Elaboración Propia]

92

 

- COMPRAS DE PRODUCTOS A PROVEEDOR CASO DE USO: COMPRAS DE PRODUCTOS A PROVEEDOR  ACTOR: PROPIETARIO O AUXILIAR , LABORATORIO LABORATORIO TIPO:

PRIMARIO

DESCRIPCIÓN: Este caso de uso comienza comienza cuando, la propietaria 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 [Fuente: Elaboración Propia]

- 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 [Fuente: Elaboración Propia]

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 [Fuente: Elaboración Propia]

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 n ormal 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 caso s de uso expandidos de los procesos reflejados en los diagramas de casos de uso de alto nivel.

94

 

CASO DE USO:

INVENTAR INV ENTARIO IO DE PROD PRODUCTOS UCTOS DE ALMA ALMAC C N

 ACTORES:

PROPIETARIO PROPIETARI O , AUXILIAR AUXILIAR

PROP SITO SITO::

REALIZAR REAL IZAR EL CONTE CONTEO O F SIC SICO O Y COM COMPARAR PARAR CON SIS SISTEMA TEMA 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 REFERENCIA S 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 s us 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 c on 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 [Fuente: Elaboración Propia]

95

 

CASO DE USO:

VENTA DE PRODUCTOS

 ACTORES:

AUXILIAR , CLIENTE CLIENTE

PROP SITO SITO::

Registrar Regist rar la salida de medi medicamen camentos tos

RESUMEN:

La auxiliar atiende al cliente realizando la venta de uno o varios productos, que se registran en el sistema.

TIPO:

PRIMARIO, ESENCIA ESENCIAL L

REFERENCIAS REFERENCIA S 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

CURSO NORMAL DE LOS EVENTOS  ACCIÓN DEL ACTOR ACTOR

RESPUESTA DEL SISTEMA

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

5. Verifica las existencias y sus s us vencimientos.

con los siguientes campos

6. El cliente realiza la solicitud a la auxiliar

 

Código de producto

 

Descripción

 

Cantidad existente

 

Precio unitario

 

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 11. Entrega los productos solicitados por el cliente c liente

10.El sistema registra los datos del cliente grabándolos

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 [Fuente: Elaboración Propia]

96

 

CASO DE USO:

PEDIDO A LABORATORIO

 ACTORES:

PROPIETARIA PROPIETARI A , AUXILIAR AUXILIAR , PROVEEDOR PROVEEDOR

PROP SITO SITO::

Registrar Regist rar las soli solicitude citudess de produ productos ctos a los prove proveedore edoress 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.

TIPO:

PRIMARIO, ESENCIAL

REFERENCIAS REFERENCIA S CRUZADAS:

RF 4.1, RF 4.2, RF 4.3, RF 4.5, RF 4.6, RF 4.7

CURSO NORMAL DE LOS EVENTOS  ACCI N DEL ACTOR

RESPUESTA DEL SISTEMA

1. Verifica la cantidad de existencia , con c on el reporte de faltantes 2.Elije el proveedor para realizar la solicitud s olicitud 3.Realiza el pedido

4. Genera reporte de faltantes

5. Graba el pedido realizado r ealizado 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 [Fuente: Elaboración Propia]

97

 

CASO DE USO:

COMPRA DE PRODUCTOS

 ACTORES:

PROPIETARIA PROPIETARI A , AUXILIAR AUXILIAR , PROVEEDOR PROVEEDOR (LABORATORIO)

PROP SITO SITO::

Registrar Regist rar las compr compras as realiz realizadas adas de los proveed proveedores. ores.

RESUMEN:

El laboratorio hace llegar el pedido, el usuario compara con el reporte de pedidos recepciona, el proveedor prov eedor 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.

TIPO:

PRIMARIO, ESENCIAL

REFERENCIAS REFERENCIA S CRUZADAS:

RF 5.2, RF 5.3, RF 5.4., RF 5.5

CURSO NORMAL DE LOS EVENTOS  ACCI N DEL ACTOR

RESPUESTA DEL SISTEMA

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. 10.Graba ingreso de productos

9. Sistema acepta el 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 [Fuente: Elaboración Propia]

98

 

CASO DE USO CASO USO::

CATEGO CAT EGORIZ RIZACI ACI N POR MED MEDIO IO DE COD CODIFI IFICA CACI CI N DE PRODUCTOS

 ACTORES:

AUXILIAR AUXILI AR

PROP SITO SITO::

Codificar Codif icar los produc productos tos de acuer acuerdo do al código de fact factura, ura, adem además á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.

TIPO:

PRIMARIO, ESENCIAL

REFERENCIAS REFERENCIA S CRUZADAS: CURSO NORMAL DE LOS EVENTOS  ACCI N DEL ACTOR

RESPUESTA DEL SISTEMA

1. Auxiliar determina tipo de categoría a la que pertenece el producto 2.ingresa al módulo de categoría para crear c rear 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 8. Pone timbre el producto done se encuentra el

7. Guarda categoría

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 [Fuente: Elaboración Propia]

99

 

CASO DE USO:

DEVOLUCI DEVO LUCI N DE PRODU PRODUCTOS CTOS

 ACTORES:

PROPIETARIA PROPIETARI A , AUXILIAR AUXILIAR , PROVEEDOR PROVEEDOR

PROP SITO SITO::

Sacar del sistem sistema a existe existencia ncia de produ producto cto que o se encuen encuentra tra 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.

TIPO:

PRIMARIO, ESENCIAL

REFERENCIAS REFERENCIA S CRUZADAS:

RF.8.1 , RF.8.2 , RF 8.3 ,RF.8.4

CURSO NORMAL DE LOS EVENTOS  ACCI N DEL ACTOR

RESPUESTA DEL SISTEMA

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. devoluc ió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 [Fuente: Elaboración Propia]

100

 

3.1.7. DIAGRAMAS DE CASOS DE USOS EXPANDIDOS DEL SISTEMA

Figura Nº 3.19: Diagrama de Caso de Uso General  [Fuente: Elaboración Propia]

101

 

-INVENTARIO DE ALMACÉN DE SISTEMA

Figura Nº 3.20: Diagrama de Caso de Uso de Alto Nivel con Sistema [Fuente: Elaboración Propia]

102

 

-VENTAS DE PRODUCTOS

Figura Nº 3.21: Diagrama de Caso de Uso de Venta de Productos de Sistema [Fuente: Elaboración Propia]

103

 

- PEDIDO A LABORATORIO

Figura Nº 3.22: Diagrama de Caso de Uso de Pedido a Laboratorio del Sistema [Fuente: Elaboración Propia]

104

 

-COMPRA DE PRODUCTOS

Figura Nº 3.23: Diagrama de Casos de Uso de Compra de Producto de Sistema [Fuente: Elaboración Propia] 

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  Productos  [Fuente: Elaboración Propia]

106

 

-DIAGRAMA DE SECUENCIA DE VENTA DE PRODUCTOS

Figura Nº 3.25: Diagrama de Secuencia de Venta de Productos [Fuente: Elaboración Propia]

107

 

-DIAGRAMA DE SECUENCIA DE PEDIDO A LABORATORIO

Figura Nº 3.26: Diagrama de Secuencia de Pedido a Laboratorio  [Fuente: Elaboración Propia]

-DIAGRAMA DE SECUENCIA DE COMPRA DE PRODUCTOS

Figura Nº 3.27: Diagrama de Secuencias de Compra de Productos

[Fuente: Elaboración Propia]

108

 

-DIAGRAMA DE SECUENCIA DE DEVOLUCIÓN DE PRODUCTO

Figura Nº 3.28: Diagrama de Secuencia de Devolución de Productos  [Fuente: Elaboración Propia]

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 [Fuente: Elaboración Propia]

-DIAGRAMA DE ESTADO DE VENTA DE PRODUCTOS

Figura Nº 3.30: Diagrama de Estado de Venta de Productos  [Fuente: Elaboración Propia]

110

 

- DIAGRAMA DE ESTADO DE PEDIDO A LABORATORIO

Figura Nº 3.31: Diagrama de Estado de Pedido a Laboratorio  [Fuente: Elaboración Propia]

-DIAGRAMA DE ESTADO DE COMPRA DE PRODUCTOS

Figura Nº 3.32: Diagrama de Estado de Compra de Productos [Fuente: Elaboración Propia]

 

111

 

3.2.3. CASOS DE USO REALES CASO DE USO:

INVENTAR INV ENTARIO IO DE PROD PRODUCTOS UCTOS DE ALMA ALMAC C N

 ACTORES:

PROPIETARIO PROPIETARI O , AUXILIAR AUXILIAR

PROP SITO SITO::

REALIZAR REAL IZAR EL CONTE CONTEO O F SIC SICO O Y COM COMPARAR PARAR CON SIS SISTEMA TEMA 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 REFERENCIA S 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

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 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. F.   Solicita el movimiento de cada producto en C. C.   Imprime reportes de existencias para la toma de 13. Verifica las existencias si comparan con c on sistema

decisiones en D

Tabla Nº 3.28: Diagrama de Caso de Uso Real de Inventario de Productos en Almacén [Fuente: Elaboración Propia]

112

 

A

B

Figura Nº 3.33: Ingreso Login [Fuente: Elaboración Propia]

C E   D

F

G  

Figura Nº 3.34: Modulo Almacén de Productos [Fuente: Elaboración Propia]

113

 

CASO DE USO:

VENTA DE PRODUCTOS

 ACTORES:

AUXILIAR , CLIENTE CLIENTE

PROP SITO SITO::

Registrar Regist rar la salida de medi medicamen camentos tos

RESUMEN:

La auxiliar atiende al cliente realizando la venta de uno o varios productos, que se s e registran en el sistema.

TIPO:

PRIMARIO, ESENCIA ESENCIAL L

REFERENCIAS REFERENCIA S 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

CURSO NORMAL DE LOS EVENTOS  ACCI N DEL ACTOR

RESPUESTA DEL SISTEMA

 Auxiliar atiende la solicitud del cliente Ingresa al módulo de ventas Figura 3.35. A. 3.35. A.   Realiza el control de las existencias.

El sistema muestra información del producto buscado

Verifica las existencias y sus vencimientos B

con los siguientes campos B 

El cliente realiza la solicitud a la auxiliar

 

Código de producto

 

Descripción

 

Cantidad existente

 

Precio

 

Marca

 Auxiliar solicita datos del cliente 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 grabándolos  C

Entrega los productos solicitados por el cliente c liente El cliente se retira Cuando no hay existencias la auxiliar registra los productos faltantes F 

Genera un reporte de la venta o salida de los productos E  El sistema reduce el Stock del inventario. inv entario.

Tabla Nº 3.29: Diagrama de Caso de Uso Real de Venta de Productos [Fuente: Elaboración Propia]

114

 

A

C

B

D

G

F

E

H

Figura Nº 3.35: Modulo de Venta [Fuente: Elaboración Propia]

115

 

CASO DE USO:

PEDIDO A LABORATORIO

 ACTORES:

PROPIETARIA PROPIETARI A , AUXILIAR AUXILIAR , PROVEEDOR PROVEEDOR (LABORATORIO)

PROP SITO SITO::

Registrar Regist rar las soli solicitude citudess de produ productos ctos a los prove proveedore edoress 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.

TIPO:

PRIMARIO, ESENCIAL

REFERENCIAS CRUZADAS:

RF 4.1, RF 4.2, RF 4.3, RF 4.5, RF 4.6, RF 4.7

CURSO NORMAL DE LOS EVENTOS  ACCI N DEL ACTOR

RESPUESTA DEL SISTEMA

1. Verifica la cantidad de existencia , con c on el reporte de faltantes 2.Elije el proveedor para realizar la solicitud s olicitud B 3.Realiza el pedido A 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. pedido.F 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:  Laboratorio:  [Fuente: Elaboración Propia]

116

 

A

B

D

C

E

F

Figura Nº 3.36: Pedido de Laboratorio [Fuente: Elaboración Propia]

117

 

CASO DE USO:

COMPRA DE PRODUCTOS

 ACTORES:

PROPIETARIA PROPIETARI A , AUXILIAR AUXILIAR , PROVEEDOR PROVEEDOR (LABORATORIO)

PROP SITO SITO::

Registrar Regist rar las compr compras as realiz realizadas adas de los proveed proveedores. ores.

RESUMEN:

El laboratorio hace llegar el pedido, el usuario compara con el reporte de pedidos recepciona, el proveedor prov eedor 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.

TIPO:

PRIMARIO, ESENCIAL

REFERENCIAS REFERENCIA S CRUZADAS:

RF 5.2, RF 5.3, RF 5.4., RF 5.5

CURSO NORMAL DE LOS EVENTOS  ACCI N DEL ACTOR

RESPUESTA DEL SISTEMA

1.ingresa a ventana de ingreso de productos (compra)

2.Sistema muestra ventana de ingreso A 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 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 [Fuente: Elaboración Propia]

118

 

A B C

D

E

F

Figura Nº 3.37: Modulo de Compras [Fuente: Elaboración Propia]

119

 

3.2.4. DIAGRAMA DE CLASES class DIAGRAMAS DE CASO DE USO

PRODUCTOS PROVEEDOR

COD_MED: int +/ COD_PROVEEDOR: int + FECHA_DE_INGR FECHA_DE_INGRESO: ESO: char  DETALLE DE VENTA

+ + +/ -

CANTIDAD_ENTEROS: int CANTIDAD_UNIDADES: CANTIDAD_UN IDADES: int COD_MED: int COD_VENTA: int

+ +

consultas()) : boolean consultas( grabar detall e() : boolean

1 . .*

1

1

+ + + + + + + +

FECHA_DE_VENC: float NOMBRE_DE_PRODUCTO: NOMBRE_DE_PRODU CTO: char  PRECIO_COST O_ENTERO: int PRECIO_COST O_UNITARIO: int 1 PRECIO_VENTA _ENTEROS: int PRECIO_VEN PREC IO_VENTA_UNIT: TA_UNIT: int STOCK_ENTEROS: STOCK_EN TEROS: int STOCK_UNIDADES: int

+ + + +

ALTAS() : void BAJAS() : void BAJAS() MODIFICACIONES() : void REPORTES() : void

1..*

+

CELULAR: int

-+ + + +

COD_PROVEEDOR : int CORREO_ELECTRONICO: CORR EO_ELECTRONICO: char  DIRECCION: char  NOMBRE: char  TELEFONO:: int TELEFONO

+ + + +

ADICIONAR() ADICIONAR () : void ELIMINAR() : void MODIFICAR() : void REPORTES() REPO RTES() : void

1..*

1..* 1

1

VENTAS

+/ + -/ + +

COD_VENTA: int COD_VENTA: FECHA_VENTA: int ID_CLIENTE: ID_C LIENTE: int ID_VENDEDOR: ID_VENDED OR: int NRO_FAC NR O_FACT: T: int PRECIO_TOTAL: int

+ + +

ALTAS() : void BAJAS() : void BAJAS() REPORTES() REPO RTES() : void 1..*

PEDIDO

+ +

DETALLE_DE_COMPRA

0..*

+ CANTIDAD: int +/ COD_MED: int COD_PEDIDO: int ADICIONA() : void REPORTES () () : void

1..*

+ + +/ + +

CANTIDAD_ENTEROS: int CANTIDAD_UNIDADES: CANTIDAD_UN IDADES: int COD_MED: int NRO_DE_COMPRA: int PRECIO_ENTERO: int PRECIO_UNITARIO: int

+ + +

ADICIONA() : void MODIFICA() : void MODIFICA() REPORTES() : void 1..*

1..* CLIENTE

+

CI_CLIENTE: int CI_CLIENTE: NOMBRE_APELLIDO: char 

+ + + +

ADICIONA() : void CONSULTAS() : void CONSULTAS() ELIMINA() : void MODIFICA() : void

1 COMPRAS

1 VENDEDOR

USUARIOS

+ + + +

ACTIVO: int NIVEL _USUARIO: char  1 NUM_USUARIOS: int PASSWORD: char  USUARIO: USUAR IO: char 

+ +

ACTIVA()) : void ACTIVA( DESACTIVA() : void DESACTIVA()

1

+ + +/ +

FECHA_IGRESO: char  ID_VENDEDOR: ID_VENDED OR: int NOMBRE: char  NUM_USUARIO: int TELEFONO/CELULAR: int

+ + +

ADICIONAR() ADICIONAR () : void ELIMINAR() : void MODIFICAR() : void

+ + +/

ESTADO DECOMPRA: char  FAC_PROV: FAC _PROV: int FECHA_DE COMPRA: char  NRO_DE_COMPRA: int

+ + +

ADICIONA() : void CONSULTAS() : void CONSULTAS() MODIFICACION() : void

1..*

1 PRIVILEGIOS

+ -

DESCRIPCION: char  NIVEL: int

+

ACTIVA()) : void ACTIVA(

Figura Nº 3.38: Diagrama de Clases [Fuente: Elaboración Propia]

120

 

3.2.5. MODELO ENTIDAD RELACIÓN

Figura Nº 3.39: Modelo Entidad Relación [Fuente: Elaboración Propia]

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 Far m

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, PROVEEDOR: 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

DETALLE_VENTA

cliente. 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é cad cada a compra ingresando producto por producto además de la fecha de compra

Tabla Nº 3.32: Diccionario de Entidades  [Fuente: Elaboración Propia]

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 e n 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: l ia

ESCALA

o ar

S p

M nI

mi

1

2

3

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?

Tabla Nº 3.33: Ajuste de Complejidad de Punto Función [Fuente: Roger S. Pressman]

e

n s n gi

E S

1.- El sistema requiere copias de seguridad y de recuperación fiables? 2.- Se requiere comunicación de datos?

NIVEL DE INFLUENCIA (∑ Fi)

fi M

o c

c

ai

e d

er o

ci

a d

e m

r

l

oi

e at

ni

vi t

d n

n

0

o

at c

40

4

5

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. PARÁMETRO DE MEDIDA

CUENTA

Número de entradas

FACTO FA CTOR R DE DE PON PONDE DERA RACI CI N

TOTAL

SIMPLE

MEDIO

COMPLEJO

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 [Fuente: Elaboración Propia]

Para el cálculo de puntos de función (PF), ( 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: VAL VA LOR ORA ACI N O

O

J

CONDUCTORES DE COSTE

T L

A B

L A O

Y U

O

L

A M

T

Y A

M

R J B

N

A A

M O

R

O X

L

T U

T E

A

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

-

-

0.87 1.19

1.00  1.00 

1.07 0.88

1.15 0.71

-

Tiempo de respuesta del ordenador Capacidad del analista

1.48

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 e mpleado por mes se o realiza de acuerdo acuer do 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  Costo del Software

VERSI N 

COSTO  $us 1200

Licencia de Windows

Windows 10

$us 50.28

Licencia de visual Studio

(Visual Studio Professional $us 100 2012

Licencia de SQL SERVE SERVER R

Server 2008

$us 50.35

Total en $us.

$us 1400.63 

Total en Bs.

Bs. 9748.38 Tabla Nº 3.37: Costo de Software

[Fuente: Elaboración Propia]

129

 

3.3.1.2. COSTO DEL HARDWARE 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 Procesador Core Intel I5

Costo $us / Bs.

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

Impresora

2.19 Gb

500 $us

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

[Fuente: Elaboración Propia]

130

 

SUMA TOTAL DE COSTOS COSTOS

TOTALES

COSTO DE SOFTWARE DE LICENCIAS COSTO DE HARDWARE

BS. 1400.63 Bs.69600

COSTO COS TO DE INV INVEST ESTIGA IGACI CI N

Bs. 676

TOTAL EN BOLIVIANOS

Bs.71676.63

TOTA TO TAL L EN EN D LA LARE RES S

$us. 1098.36 Tabla Nº 3.40: Total Costo de Proyecto [Fuente: Elaboración Propia]

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 =  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 [Fuente: Elaboración Propia]

Se ha llegado a lla a conclusión de que se recuperara según el detalle en tabla 3.41 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 m meses eses $ 110.93 por cada mes.

132

 

3.4. CONCLUSIONES Luego de haber reali realizado zado el análisis y diseño del sistema de información de control de almacén, compra y venta para farmaci farmacia a VITAL FARM FARM,, se logró obtener las si siguientes guientes conclusiones  

Se logró acortar el titiempo empo 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 venci vencimientos. mientos.

 

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 iintegrar ntegrar debería contar co con n un área contable, contable, pero masa importante aún.  

Como usuarios del sistema deben ser consecuentes al momento de procesar información ya que de el ello lo depende la veracidad del sistema.

 

En función a lla a automatización de los procesos de la farmacia se debe de reasignar funciones para un mejor desempeño del mismo.

 

Debe realizar realizar copias de seguridad de la base de datos cada mes.

 

Implementar políticas dirigido dirigido al personal de la 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 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 http:/www.lenguajesql.com  ALTO, I. E. (s.f.). Biblioteca 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 d e 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 vencimientos

Carencia de una aplicación para el control de sus existencias

Pérdida de tiempo en la realización de inventarios

Falta una aplicación información de almacén, compra y venta para la farmacia

Falta de orden en la realización de pedidos

Falta de organización en el trabajo

Farmacia con solo dos años de vida

 

 

ÁRBOL DE OBJETIVOS Realizar copias de seguridad ‘de  la

Brindar reportes oportunos de existencias,

Desarrollar módulos para cada un de las

base de datos.

faltantes, compras,   ventas de medicamentos

áreas , 

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 almacenar datos de los medicamentos 

Elaborar manual de usuario 

El cliente estará satisfecho con el software 

 

 

ANEXO B CRONOGRAMA DE ACTIVIDADES PERFIL DE PROYECTO DE GRADO MARZO

Nº

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 SEPTIEMBRE

Nº

ACTIVIDADES 1

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

2

3

4

OCTUBRE

1 2

3

NOVIEMBRE

4 1

2

3

4

DICIEMBRE

1

2

3

4

 

 

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

¿cuánto tiempo está en funcionamiento la farmacia? ¿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