0% encontró este documento útil (0 votos)
20 vistas90 páginas

Final Samuel

El documento presenta un proyecto de grado para el desarrollo de un sistema web de administración y control de ventas para la farmacia 'Ecofarma', elaborado por Samuel Llave Juri bajo la tutoría del Ing. Gustavo Zelaya Alarcón. Incluye una introducción al tema, antecedentes, planteamiento del problema, objetivos, justificación, y una metodología de investigación detallada. Además, se abordan aspectos técnicos como la arquitectura del sistema, requerimientos, pruebas de software y métricas de calidad.

Cargado por

samuelllavejuri
Derechos de autor
© © All Rights Reserved
Nos tomamos en serio los derechos de los contenidos. Si sospechas que se trata de tu contenido, reclámalo aquí.
Formatos disponibles
Descarga como PDF, TXT o lee en línea desde Scribd
0% encontró este documento útil (0 votos)
20 vistas90 páginas

Final Samuel

El documento presenta un proyecto de grado para el desarrollo de un sistema web de administración y control de ventas para la farmacia 'Ecofarma', elaborado por Samuel Llave Juri bajo la tutoría del Ing. Gustavo Zelaya Alarcón. Incluye una introducción al tema, antecedentes, planteamiento del problema, objetivos, justificación, y una metodología de investigación detallada. Además, se abordan aspectos técnicos como la arquitectura del sistema, requerimientos, pruebas de software y métricas de calidad.

Cargado por

samuelllavejuri
Derechos de autor
© © All Rights Reserved
Nos tomamos en serio los derechos de los contenidos. Si sospechas que se trata de tu contenido, reclámalo aquí.
Formatos disponibles
Descarga como PDF, TXT o lee en línea desde Scribd

MINISTERIO DE EDUCACIÓN

VICEMINISTRO DE EDUCACIÓN SUPERIOR DE FORMACIÓN PROFESIONAL

INSTITUTO TÉCNICO “CIPEC”


R.M.Nº023/03 - R.M.Nº099/03 - R.M.Nº735/2019

DESARROLLO DE UN SISTEMA WEB DE


ADMINISTRACIÓN Y CONTROL DE VENTAS PARA LA
FARMACIA "Ecofarma"
Proyecto de Grado presentado para
optar el título de Técnico Superior
en Sistemas Informáticos
POSTULANTE: SAMUEL LLAVE JURI
TUTOR: ING. GUSTAVO ZELAYA ALARCÓN

COCHABAMBA - BOLIVIA
JULIO 2023
DEDICATORIA

A Dios fuente de inspiración, esmero y dedicación. Por ilumíname y acompañarme


en todo momento de mi vida, por llenarme de bendiciones y acompañarme a
transitar este camino que hoy veo realizado.

A mis padres Eugenio y Blanca por su constante e incondicional apoyo y paciencia,


a quienes debo mi respeto, gratitud y admiración.

A mis hermanas Sonia y Eliana por sus palabras de reflexión que me ayudan a
seguir adelante.
AGRADECIMIENTO

El desarrollo del presente proyecto, responde a múltiples esfuerzos, razón por la


cual manifiesto de la forma más sincera, mis agradecimientos:

Al Instituto “CIPEC” por haberme acogido en sus aulas de estudio,


especialmente a la carrera de Sistemas Informáticos por brindarme una
educación de excelencia que impacto mi vida en el ámbito profesional.

A los, docentes y administrativos, por haberme dado la oportunidad de verme hoy


profesional y darme el conocimiento que se refleja en la realización de este
proyecto.

Agradecer al Ing. Gustavo Zelaya Alarcón, mi tutor metodológico, por su experiencia


profesional, quien me brindo su tiempo, su dedicación, su colaboración en la
revisión y en cada momento de consulta en el desarrollo del presente proyecto.
ÍNDICE
CAPITULO I ........................................................................................................................................ 1

1. INTRODUCCION ..................................................................................................................... 1

1.1 TEMA: DESARROLLO DE UN SISTEMA WEB DE ADMINISTRACIÓN Y


CONTROL DE VENTAS PARA LA FARMACIA "Ecofarma" .................................................. 1

1.2 ANTECEDENTES ..................................................................................................................... 2

1.2.1 Antecedentes del trabajo ...................................................................................................... 2

1.3 PLANTEAMIENTO DEL PROBLEMA ......................................................................................... 2

1.3.1 Problema Principal ................................................................................................................ 2

1.3.2 Identificación del problema ................................................................................. 2

1.3.3 Problemas Secundarios ......................................................................................................... 3

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

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

1.4.2 Objetivos Específicos ............................................................................................................. 4

1.5 JUSTIFICACIÓN ...................................................................................................................... 5

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

1.5.2 Justificación Económica ......................................................................................................... 5

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

1.6 ENFOQUE METODOLÓGICO .......................................................................................... 6

1.6.1 Alcances .................................................................................................................. 6

1.6.2 Alcance temático ................................................................................................... 6

1.6.3 Alcance geográfico................................................................................................ 6

1.6.4 Alcance temporal ................................................................................................... 6

1.7 METODOLOGÍA DE INVESTIGACIÓN ............................................................................ 7

1.7.1 Enfoque.................................................................................................................... 7

1.7.2 Método ..................................................................................................................... 7

1.8 METODOLOGÍA...................................................................................................................... 8
1.9 LÍMITES Y ALCANCES .............................................................................................................. 8

1.9.1 Limites ................................................................................................................................... 8

1.9.2 Alcances ................................................................................................................................ 8

[Link]. Módulo de usuarios ....................................................................................................... 8

[Link]. Módulo de Compras....................................................................................................... 9

[Link]. Modulo control de inventarios....................................................................................... 9

[Link]. Módulo de administración de proveedores ................................................................... 9

[Link]. Módulo de ventas y facturación..................................................................................... 9

[Link]. Módulo de consultas, reportes y estadísticas ................................................................ 9

CAPITULO II ......................................................................................................................................10

2. MARCO TEORICO ..................................................................................................................10

2.1. METODOLOGÍA UWE (UML-Based Web Engineering) ...........................................................10

1.1 Figura No. 2 Visión General de los Métodos UWE ................................................................11

2.2. Características de UWE .........................................................................................................11

2.3. Fases de la Metodología UWE ..............................................................................................12

2.3.1. Tipos de Fases de la Metodología UWE ................................................................................12

2.4. Modelos de la Metodología UWE .........................................................................................13

2.5. Modelo de Caso de Uso ........................................................................................................13

1.1 Figura No. 2.1 Diagrama de Casos de Uso UML. ...................................................................13

2.5.1. Modelo Conceptual ..............................................................................................................14

1.2 Figura No. 2.2 Modelo Contenido de la Aplicación UWE ......................................................14

2.6. Modelo de Navegación .........................................................................................................14

1.3 Figura No. 2.3 Modelo de Navegación UWE .........................................................................15

2.7. Modelo de Presentación .......................................................................................................15

1.4 Figura No. 2.4 Modelo de Presentación UWE. ......................................................................16

2.8. Modelo de Procesos .............................................................................................................16


1.5 Figura No. 2.5 Modelo de Procesos UWE. .............................................................................17

2.8.1. Ventajas y Desventajas .........................................................................................................17

2.9. MÉTODOS DE PRUEBA DEL SISTEMA ....................................................................................18

2.9.1. Método de Prueba de Caja Blanca ........................................................................................18

1.6 Figura No. 2.6 A Diagrama de Flujo y B Gráfico de Flujo. ......................................................19

2.10.2. Rutas de Programa Independientes ......................................................................................19

2.11. MÉTRICAS DE CALIDAD DEL SOFTWARE................................................................................19

2.11.1. Métricas de Calidad ..............................................................................................................19

2.11.2. Modelo Normas ISO/IEC 9126 ..............................................................................................20

1.7 Tabla 1 Características de Calidad de Modelo ISO/IEC 9126 .................................................21

2.11.3. Funcionalidad .......................................................................................................................22

2.11.4. Fiabilidad ..............................................................................................................................22

2.11.5. Usabilidad ............................................................................................................................22

2.11.6. Eficiencia ..............................................................................................................................23

2.11.7. Mantenibilidad .....................................................................................................................23

2.11.8. Portabilidad ..........................................................................................................................23

2.12. Métricas Basadas en Función................................................................................................23

1.8 Tabla 2 Factores de Ponderación ..........................................................................................24

2.13. SEGURIDAD DE LA INFORMACION ........................................................................................25

2.13.1. Estándar ISO/IEC 27000 ........................................................................................................25

2.13.3. MODELO VISTA CONTROLADOR (MVC) ................................................................................26

1.9 Figura No. 2.7 Funcionamiento del Modelo Vista Controlador MVC. ....................................26

2.14. HERRAMIENTAS DE DESARROLLO .........................................................................................27

2.14.1. Sistema De Gestor de Base de Datos MariaDB .....................................................................27

[Link]. Ventajas y Desventajas de MariaDB..............................................................................27

2.14.2. Lenguaje de Programación PHP (HYPERTEXT PREPROCESSOR) .............................................27


[Link]. Ventajas y desventajas de PHP .....................................................................................28

2.14.3. Framework BOOTSTRAP .......................................................................................................29

[Link]. Características...............................................................................................................29

[Link]. Ventajas y Desventajas .................................................................................................30

2.14.4. Servidor Web Apache ...........................................................................................................31

1.10 Figura No. 2.8 Esquema de Funcionamiento Apache. ...........................................................31

[Link]. Características...............................................................................................................32

[Link]. Ventajas y Desventajas .................................................................................................32

CAPITULO III .....................................................................................................................................33

3. MARCO PROPOSITIVO.............................................................................................................33

3.1. ANÁLISIS Y DISEÑO ...............................................................................................................33

1.11 Figura No.3 Estructura Modelo Lineal Secuencial. ................................................................34

3.2. LISTA DE REQUERIMIENTOS DEL SISTEMA ............................................................................35

3.2.1. Especificaciones de Requerimientos para la Aplicación ........................................................35

1.12 Tabla 1 Requerimientos del Software para la Aplicación. .....................................................35

3.2.2. Funciones del Sistema ..........................................................................................................36

1.13 Tabla 1.1Funciones del Sistema ............................................................................................36

3.2.3. Requerimientos Funcionales.................................................................................................36

1.14 Tabla 1.2 Requerimientos Funcionales .................................................................................37

3.2.4. Requerimientos No Funcionales ...........................................................................................37

1.15 Tabla 1.3 Requerimientos no Funcionales ............................................................................38

3.3. ANALISIS DE REQUERIMIENTOS ............................................................................................38

3.3.1. Modelos de Caso de Uso.......................................................................................................38

1.16 Figura No. 3.1 Actores del Negocio. ......................................................................................38

1.17 Figura No. 3.2 Trabajadores del Negocio ..............................................................................39

3.3.2. Identificación de Entidades del Negocio ...............................................................................39


1.18 Figura No. 3.3 Entidades del Negocio. ..................................................................................39

Diagrama de Caso de Uso General del Negocio ................................................................................40

Figura No. 3.5 Diagrama de Caso de Uso General del Sistema .........................................................40

Figura No. 3.6 Diagrama de Caso de Uso de Iniciar Sesión. ..............................................................41

1.19 Tabla 1.4 Diccionario de Casos de Uso Iniciar Sesión. ...........................................................41

Figura No. 3.7 Diagrama de Caso de Uso Gestionar Usuarios. ..........................................................42

1.20 Tabla 1.5 Diccionario de Caso de Uso Iniciar Usuario. ...........................................................42

Figura No. 3.8 Diagrama de Caso de Uso Gestionar Venta. ..............................................................43

1.21 Tabla 1.6 Diccionario de Caso de Uso Gestionar Venta. ........................................................43

1.22 Figura No. 3.9 Diagrama de Caso de Uso Gestionar Productos. ............................................45

1.23 Tabla 1.7 Diccionario de Caso de Uso Gestionar Productos ..................................................45

1.24 Figura No. 3.10 Diagrama de Caso de Uso Gestionar Proveedor. ..........................................46

1.25 Tabla 1.8 Diccionario de Caso de Uso Gestionar Proveedor ..................................................46

1.26 Figura No. 3.11Diagrama de Caso de Uso Gestionar Estadísticas. .........................................47

1.27 Tabla 1.8 Diccionario de Caso de Uso Gestionar Estadística..................................................47

3.3.3. MODELO DE CONTENIDO ......................................................................................................48

3.3.4. Modelo de Contenido del Sistema ........................................................................................49

3.3.5. Modelo Físico del Sistema ....................................................................................................50

3.3.6. Modelo de Navegación del Sistema ......................................................................................51

3.3.7. Modelo de Presentación del Sistema ....................................................................................52

[Link]. Modelo de Presentación de Login .................................................................................52

1.28 Figura No. 3.15 Modelo Presentación de Autentificación de Usuario. ..................................52

[Link]. Modelo de Presentación de Menú Principal del Sistema...............................................52

[Link]. Modelo de Presentación de Administrar Usuario..........................................................53

[Link]. Modelo de Presentación de Administrar Cliente ...........................................................53

[Link]. Modelo de Presentación de Administrar Ventas ...........................................................54


[Link]. Modelo de Presentación de Administrar Productos ......................................................54

[Link]. Modelo de Presentación de Administrar Compras ........................................................55

[Link]. Modelo de Presentación de Administrar Pedidos .........................................................55

[Link]. Modelo de Presentación de Administrar Proveedores ..................................................56

3.3.8. PRUEBAS DE SOFTWARE .......................................................................................................56

[Link]. Pruebas de Caja Blanca .................................................................................................56

Figura No. 3.24 Caja Blanca. .............................................................................................................57

[Link]. Pruebas de Caja Negra ..................................................................................................57

1.29 Tabla 1.9 Los valores de límites de inicio de sesión...............................................................58

1.30 Tabla 3.1 Prueba de caja negra de iniciar sesión. ..................................................................58

3.3.9. Prueba de Caja Negra de Registro de Productos ...................................................................58

Figura No. 3.26 Prueba de caja negra registrar productos. ...............................................................58

1.31 Tabla 1.10 Valores límites de registrar producto. .................................................................59

1.32 Tabla 1.11Prueba de caja negra registrar productos. ............................................................59

1.32.1 Pruebas de Funcionalidad .........................................................................................60

1.33 Tabla 1.12 Caso de prueba interfaz de inicio de sesión. ........................................................60

1.34 Tabla 1.13 Caso de prueba gestionar productos. ..................................................................62

1.35 Tabla 1.14 Caso de prueba gestionar productos y pedidos. ..................................................63

1.36 Tabla 1.15 Caso de prueba de clientes, proveedor, categoría y control de productos. .........64

3.3.11 CATÁLOGO DE REQUERIMIENTOS DEL SISTEMA....................................................................65

3.4 METRICAS DE CALIDAD, ESTIMACION DE COSTO Y SEGURIDAD............................................65

1.36.1 Metricas de calidad ...................................................................................................65

1.36.2 Funcionalidad............................................................................................................65

1.36.3 Confiabilidad .............................................................................................................66

1.36.4 Mantenibilidad .........................................................................................................66

1.37 ESTIMACIÓN DE COSTO DEL SOFTWARE ...............................................................................66


1.37.1 Método de Estimación COCOMO II ...........................................................................66

1.38 SISTEMA DE SEGURIDAD DE LA INFORMACIÓN ....................................................................66

3.6.1. Identificación y Autentificación ............................................................................................67

3.6.2. Encriptación..........................................................................................................................67

CONCLUSIONES ................................................................................................................................68

RECOMENDACIONES ........................................................................................................................68

BIBLIOGRAFÍA ..................................................................................................................................69

INDICE DE FIGURAS ..........................................................................................................................70

FIGURA 1: ARBOL DE PROBLEMAS ...................................................................................................70

FIGURA 2: FUNCIONES DE LA FARMACIA .........................................................................................70

FIGURA 3: IDENTIFICACION DE ACTORES .........................................................................................71

FIGURA 4: REGISTRAR USUARIO ......................................................................................................71

FIGURA 5: REGISTRAR PRODUCTO ...................................................................................................72

FIGURA 6: CATEGORIA PRODUCTO ..................................................................................................72

FIGURA 7: REGISTRAR COMPRAS .....................................................................................................73

FIGURA 8: REGISTRAR PROVEEDOR .................................................................................................73

FIGURA 9: REGISTRAR VENTAS.........................................................................................................74

FIGURA 10: ACTIVAR CLIENTE ..........................................................................................................74

FIGURA 11: LISTAR PRODUCTOS ......................................................................................................75

FIGURA 12: CONSULTA REPORTES ...................................................................................................75

FIGURA 13: REGISTRAR REPORTE .....................................................................................................76

FIGURA 14: CONSULTA VENTAS .......................................................................................................76

FIGURA 15: REPORTE DE VENTAS .....................................................................................................77


CAPITULO I
CAPITULO I
1. INTRODUCCION

1.1 TEMA: DESARROLLO DE UN SISTEMA WEB DE ADMINISTRACIÓN Y


CONTROL DE VENTAS PARA LA FARMACIA "Ecofarma"

Hoy en día, la informática en red se ha convertido en un factor importante en la vida


de una empresa la razón principal implica la cantidad de información que
actualmente se maneja, hace que el tratamiento automático de la información sea
realmente útil y necesario. Esto representa una gran ventaja para el usuario,
dado que puede acceder a distintas áreas de su interés desde su equipo y/o
celular.
La farmacia compra y vende los productos, por tal motivo es esencial contar con un
sistema de compra, ventas e inventarios el cual nos permitirá tener un control exacto
y oportuno, además al final de un periodo de tiempo nos brinda información sobre el
actual estado económico real de la empresa.

Actualmente la farmacia, no cuenta con un control de compras ventas e inventarios,


sin acceso de tecnologías de innovación que brinde una información oportuna,
confiable, precisa y de forma automática ya que estos procesos se realizan
manualmente en hojas de archivo, lo que presenta un problema al usuario de la
empresa.

En ese sentido se propone el desarrollo de un sistema de información web para el


control de compras ventas e inventarios, que evitara la demora en la atención de los
clientes y garantizara el buen estado de la misma, el mismo que generara
información confiable y oportuna para la farmacia. De este modo podemos llevar a
cabo una planeación de reabastecimiento y la maximización de las utilidades en la
farmacia.

1
1.2 ANTECEDENTES
1.2.1 Antecedentes del trabajo

La Farmacia "Ecofarma" ubicado en sacaba en la Av. Guayacan y Calle Cardo


Santo, tiene actualmente 5 años de funcionamiento desarrollando sus actividades
desde el 2018, cuenta con NIT y licencia de funcionamiento, administrado por su
propietaria Camila Flores Prado, empezando con un capital de 15.000 $, en la
actualidad casi triplica la inversión inicial, la Farmacia " Ecofarma " se dedica a la
venta de productos farmacéuticos.
El presente trabajo de investigación es importante para la Farmacia "Ecofarma"
porque le ayudara sistemática e informáticamente en la administración de registro y
control de egresos e ingresos de la venta de productos, también le ayudara a
maximizar su productividad y su comercialización.

1.3 PLANTEAMIENTO DEL PROBLEMA

1.3.1 Problema Principal

La Farmacia “Ecofarma”, actualmente realiza de manera manual el proceso de


registro, control de las compras, ventas y los inventarios estos son registrados en
libros diarios lo que resulta insuficiente ante las necesidades de información de la
administración de la farmacia, la generación de consultas, reportes y estadísticas, se
dificulta lo que produce pérdidas en el control de las existencias de los productos, las
ventas y compras.

1.3.2 Identificación del problema

Durante el proceso de observación para la realización de este trabajo se pudo


evidenciar los siguientes problemas:
 La falta de control y registro de ventas de los productos con la que se trabaja
conlleva a que los precios de venta sean erróneos ya que se calculan de

2
forma manual, lo que trae consigo que el registro de ventas se encuentre
incompleto provocando pérdidas económicas.
 Demora en la búsqueda de productos y esto provoca muchos retrasos en la
atención a los clientes.
 No cuenta con un sistema de información de los productos existentes en el
área de ventas, ocasionando malestar hacia sus clientes al no satisfacer sus
demandas.
 La acumulación de informes en papel es tediosa y perjudicial.
 Los datos de las ventas e inventarios no se obtienen de manera rápida y
optima porque no están centralizados en una base de datos.
 También se observa que se tiene un deficiente control del stock y fecha de
vencimiento como consecuencia se tiene pérdidas y desabastecimiento de
productos.

1.3.3 Problemas Secundarios


 La información solicitada a los proveedores para el reabastecimiento es
inexacta, debido a la mala información que hay en la farmacia.
 El control de las compras, son realizadas de forma manual en un libro de
registros, el cual genera demora en el control exacto del inventario ya que al
realizarse las compras deben actualizarse las cantidades de productos.
 Las ventas son registradas de forma manual, no se tiene información
detallada del stock disponible del inventario ya que al realizarse las ventas
deben actualizarse las cantidades de productos.
 El manejo del inventario no se realiza con un modelo de inventario formal
adecuado a la entidad, por lo que la información que se tiene no es
confiable respecto a las existencias y fechas de vencimientos de los
productos.

 Se dificulta la realización de consultas, reportes y estadísticas ya que


requieren bastante tiempo y esfuerzo de parte del personal, esto repercute
en que no se cuenta con información exacta sobre las ventas y compras
realizada en un determinado periodo, lo que no coadyuva a una buena
3
toma de decisiones en la administración de la farmacia.
1.3.4 Formulación del problema:

¿De qué manera se podrá mejorar el inadecuado registro y control de ventas en


inventarios implementando un sistema web de control para maximizar su
productividad y su comercialización
1.4 OBJETIVOS

1.4.1 Objetivo General

Desarrollar un Sistema de Información Web para el control de compras, ventas e


inventarios de productos, que facilite la generación de consultas, reportes y
estadísticas que coadyuven a una mejor toma de decisiones de parte de la
administración de la Farmacia “Ecofarma”.

1.4.2 Objetivos Específicos

 Brindar información exacta de los productos para realizar el pedido a los


proveedores.
 Diseñar una base de datos que almacene la información necesaria de los
productos.
 Desarrollar interfaz fácil para el registro y control de venta de productos.
 Desarrollar un módulo que muestre el control de inventario.
 Desarrollar un módulo de inventario que permita controlar el stock y fecha de
vencimiento de cada producto.
 Generar reportes y consultas para los ingresos y ventas realizadas.
 Facilitar el registro de los productos en el momento del reabastecimiento
para mejorar el proceso de la compra de productos.
 Mostrar información detallada sobre el stock de los productos, las fechas de
vencimiento de cada producto al momento de realizar una venta.

4
1.5 JUSTIFICACIÓN

1.5.1 Justificación Técnica


La farmacia “Ecofarma” actualmente no cuenta con los equipos necesarios para
poder implementar el sistema, ya que la empresa solo realiza sus registros de forma
manual y no con una computadora, el propietario realizará la adquisición de un
equipo de computación, impresora y otros para la implementación del sistema, así
como de una conexión a Internet con algún proveedor de nuestro medio.

1.5.2 Justificación Económica

Con la implementación del Sistema Web se podrá conseguir manejar todo el


inventario de los productos de la Farmacia "Ecofarma", contemplando así la gestión
de proveedores, el manejo de los productos y el manejo de diferentes usuarios.

Logrando con todo esto una optimización en el proceso de ventas y un mayor control
en el flujo de los productos, evitando de esta manera una pérdida de productos por
fallas humanas. Teniendo un conocimiento en tiempo real del estado actual de los
productos que se encuentran en almacenes y brindando un mejor servicio a los
clientes.

Siendo que el sistema facilitará y optimizará muchos trabajos de la Farmacia.

1.5.3 Justificación Social


En cuanto al ámbito social se busca mejorar la calidad de venta de productos hacia
los clientes mediante el uso del sistema web para registrar las compras, ventas e
inventario de productos, utilizando este sistema como una herramienta para que la
venta sea de manera más eficiente.

En el momento de la compra se entregará una factura de todos los productos


adquiridos por el cliente y esto beneficiará a los clientes eliminando molestias por la
tardanza de tiempo.

5
1.6 ENFOQUE METODOLÓGICO
1.6.1 Alcances
 El sistema web de administración podrá generar la búsqueda de un
producto y mostrar una lista detallada.
 El sistema web de administración podrá realizar informes diarios dentrada
y salida de productos.
 El sistema web de administración podrá notificar si algún producto sterminó
o caduco.
 Se realizara un interfaz gráfico amigable, para que elpueda realizar el
almacenamiento de datos fácilmente.

1.6.2 Alcance temático

El presente proyecto se basará en conceptos relacionados con la carrera de


sistemas informáticos como ser:

 RUP (Proceso Racional Unificado)


 Lenguaje Unificado de Modelado (UML)
 PHP (Paginas Preprocesador de Hipertexto)
 HTML/CSS (Lenguaje de Marcado de Hipertexto/)
 Diagrama de casos de uso

1.6.3 Alcance geográfico

El presente trabajo de investigación se realizará en ambientes de la Farmacia


"Ecofarma" en el área de inventario y ventas.

1.6.4 Alcance temporal

El presente proyecto se elaborará durante un periodo de dos meses.

6
1.7 METODOLOGÍA DE INVESTIGACIÓN

1.7.1 Enfoque

El enfoque de investigación utilizado en el presente proyecto es mixto:

 Cuantitativo

El presente proyecto de trabajo para el desarrollo del sistema de control de ventas


se utilizará cálculos matemáticos, algoritmos para el desarrollo específico del
sistema.

 Cualitativo

El presente proyecto de trabajo de investigación se realizó la entrevista


correspondiente al dueño con respecto a los problemas que presenta y observación
al manejo de ventas de la Farmacia "Ecofarma".

1.7.2 Método

En el presente trabajo se aplica el método deductivo porque se parte de un


conocimiento general lo cual nos lleva a conocer elementos específicos.

1.7.3 Tipo de estudio

Se realizará un estudio analítico-propositivo ya que se empezará realizando un


análisis sobre la información de la empresa para identificar las causas y efectos para
la formulación del problema y propositivo porque se pretende dar solución al
problema.

1.7.4 Técnicas de recolección de información

Las técnicas de investigación que se utilizaran en el presente proyecto es la


observación utilizando como herramienta la ficha de observación para conocer la
situación actual de la empresa, y también se realizaran entrevistas al personal que

7
forma parte de la empresa, para conocer las fortalezas, oportunidades y debilidades
y amenazas.

1.8 METODOLOGÍA

1.8.1 Metodología UWE (UML-BASED WEB ENGINEERING)

UWE es un proceso del desarrollo para aplicaciones Web enfocado sobre el diseño
sistemático, la personalización y la generación semiautomática de escenarios que
guíen el proceso de desarrollo de una aplicación Web. UWE es una herramienta que
nos permitirá modelar aplicaciones web, utilizada en la ingeniería web, prestando
especial atención en sistematización y personalización (sistemas adaptativos). UWE
es una propuesta basada en el proceso unificado y UML, pero adaptados a la web.
En requisitos separa las fases de captura, definición y validación. Hace además una
clasificación y un tratamiento especial dependiendo del carácter de cada requisito.

1.9 LÍMITES Y ALCANCES

1.9.1 Limites

El sistema diseñado solo podrá registrar los datos de los productos, las actividades
del negocio, como ser ventas, compra de productos, a su vez presentará reportes de
las mismas. El sistema no podrá realizar atención médica, tampoco realizará pedidos
de productos desde la aplicación, tampoco realizará ventas de productos desde la
aplicación, no tendrá acceso desde otro sistema.

1.9.2 Alcances
El sistema de información web para el control de compras ventas e inventarios
ofrece los siguientes módulos:

[Link]. Módulo de usuarios


El módulo usuario podrá hacer control de los usuarios que tendrán acceso al
sistema, como ser administrador, vendedor.
8
[Link]. Módulo de Compras
El módulo de compras realizara una información detallada de todos los productos al
momento de hacer una compra a los proveedores.

[Link]. Modulo control de inventarios


Permite administrar los productos existentes en la farmacia en donde se pueden
buscar, agregar, modificar productos. Las transacciones registradas en este módulo
descuentan las cantidades de stock disponible en el inventario.

[Link]. Módulo de administración de proveedores

Permite al usuario buscar, agregar, modificar y eliminar productos.

[Link]. Módulo de ventas y facturación

Permite administrar las facturas en donde se pueden buscar, agregar, modificar y


eliminar facturas de ventas. Las transacciones registradas en este módulo
descuentan las cantidades de stock disponible el inventario.

[Link]. Módulo de consultas, reportes y estadísticas

Permite la generación de los reportes, tanto de ventas como de abastecimientos,


filtrándolos viendo por fechas de ventas e el usuario que realizara el registro de
compras y ventas.
1.10 APORTES
El resultado del sistema de información de compras ventas e inventarios le permitirá
al administrador saber la ubicación de productos en un corto tiempo si en caso que
no existe o que no tengan el producto le llegará un mensaje al administrador
abastezca su stock con los productos faltantes.

9
CAPITULO II
CAPITULO II
2. MARCO TEORICO

2.1. METODOLOGÍA UWE (UML-Based Web Engineering)

UWE (UML-Based Enginnering), es una metodología de ingeniería de software para


el desarrollo de aplicaciones web basados en UML. Cualquier tipo de diagrama UML
puede ser usado, porque UWE es una expresión de UML. Es una herramienta que
nos permite modelar aplicaciones Web, utilizada en la ingeniería Web. Prestando
atención en sistematización y personalización.
UWE es un proceso del desarrollo para aplicaciones Web enfocado sobre el diseño
sistemático, la personalización y la generación semiautomática de escenarios que
guíen el proceso de desarrollo de una aplicación Web. UWE describe una
metodología de diseño sistemática, basada en las técnicas de UML, la notación de
UML y los mecanismos de extensión de UML. Es una herramienta que nos permitirá
modelar aplicaciones web, utilizada en la ingeniería web, prestando especial atención
en sistematización y personalización (sistemas adaptativos). UWE es una propuesta
basada en el proceso unificado y UML, pero adaptados a la web. En requisitos
separa las fases de captura, definición y validación. (Nora Koch, 2008)
UWE es una metodología esencial para el desarrollo de aplicaciones web, la
metodología se base en faces de inicio, desarrollo y presentación de productos, es
una metodología iterativa a medida que vas desarrollando se puede modificar cada
uno de las fases de acuerdo al requerimiento deseado.
Es un lenguaje gráfico para visualizar, especificar, construir y documentar un
sistema. 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.

10
1.1 Figura No. 2 Visión General de los Métodos UWE

Fuente: Propia

UWE cubre todo el siclo de vida de las aplicaciones Web, su proceso de desarrollo se
basa en tres principales que son:

 Captura de requisitos
 Análisis y diseño
 Implementación
2.2. Características de UWE

La metodología UWE define vistas especiales representadas gráficamente por


diagramas UML, tales como el análisis de requerimientos, diseño conceptual, modelo
de navegación y modelo de representación. UWE no limita el número de diagramas
posibles de una aplicación.
 Es una metodología orientada a objetos, iterativa e incremental basada en
UML.
 Se basa también en el proceso de desarrollo software unificado.
 Proporciona un diseño sistemático y una generación semiautomática en
las aplicaciones Web a través de un framework de publicación XML.
UWE define su propio perfil UML en el cual se definen todos los elementos
necesarios para modelar los diferentes aspectos de una aplicación Web que son la
presentación y la navegación entre otros.

11
2.3. Fases de la Metodología UWE

UWE cubre todo el siglo de vida de este tipo de aplicaciones centrado además su
atención en aplicaciones personalizadas o adaptativas.
2.3.1. Tipos de Fases de la Metodología UWE

 Fase de Análisis y requerimiento. La aplicación web para reflejarlos en un


modelo de casos de uso. Se adquieren, reúnen y especifican las
características funcionales y no funcionales que deberá cumplir la aplicación
web. Trata de diferente forma las necesidades de información, las
necesidades de navegación, las necesidades de adaptación y las de interfaz
de usuario, así como algunos requisitos adicionales.

 Fase de Diseño del Sistemas. Se basa en la especificación de requisitos


producido por el análisis de los requerimientos (fase de análisis), el diseño
define cómo estos requisitos se cumplirán, la estructura que debe darse a la
aplicación web.
 Fase de Codificación del Software. Durante esta etapa se realizan la
programación, que consiste, esencialmente, en llevar a código fuente, en el
lenguaje de programación elegido, todo lo diseñado en la fase anterior.
 Fase de Pruebas. Las pruebas se utilizan para asegurar el correcto
funcionamiento de secciones de código.
 Fase de Implementación. Es el proceso por el cual los programas
desarrollados son transferidos apropiadamente al computador destino,
inicializados, y, eventualmente, configurados, con el propósito de ser ya
utilizados por el usuario final.
 Fase de Mantenimiento. Es el proceso de control, mejora y optimización del
software ya desarrollado e instalado, que también incluye depuración de
errores y defectos que puedan haberse filtrado de la fase de pruebas de
control.

12
2.4. Modelos de la Metodología UWE

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


conceptual, el modelo navegación y el modelo de presentación. A estos modelos se
pueden sumar otros modelos como lo son el modelo de interacción y la visualización
de escenarios Web.

 Modelo de casos de uso. Modelo para capturar los requisitos de sistema.


 Modelo conceptual. Es un modelo para desarrollar el contenido.
 Modelo de navegación. Se muestra la navegación y flujo del sistema.
 Modelo de presentación. Muestra la forma que se va presentar frente al
usuario.

2.5. Modelo de Caso de Uso

Un diagrama de casos de uso muestra la relación entre los actores y los casos del
sistema. Representa la funcionalidad que ofrece el sistema en lo que se refiere a su
interacción externa.
A través del modelo de casos de uso se realiza la especificación de requerimientos del
sistema que se está realizando.

1.1 Figura No. 2.1 Diagrama de Casos de Uso UML.

Fuente:Propia

13
2.5.1. Modelo Conceptual

El modelo conceptual visualiza el dominio de información relevante para el sistema


Web que incluye principalmente el contenido de la aplicación web. En nuestro
ejemplo la información es proporcionada por la clase álbum, artista y canción un
diagrama de clases UML se utilizan para modelar el contenido.
El modelo conceptual es donde se presentan los modelos lógicos de cómo van a
interactuar estos variables dentro del sistema que se está realizando.

1.2 Figura No. 2.2 Modelo Contenido de la Aplicación UWE

Fuente: Propia
2.6. Modelo de Navegación

Este diseño especifica que objetos pueden ser visitados a través de la aplicación web,
tales como vista del modelo conceptual es necesaria para la aplicación y cuáles serán
los caminos de navegación requeridos para el aseguramiento de la funcionalidad.
La navegación está fuertemente simplificada y se define principalmente para
demostrar el uso de los elementos del modelo para lo cual se utiliza estereotipos e
iconos se describen en la siguiente.

El modelo de navegación es el orden de la estructura de los datos de cómo van a


aparecer en la página cual van a ser los primero variables que se van a necesitar
para el desarrollo del sistema hasta terminar las salidas que son necesarios por el
sistema.

14
1.3 Figura No. 2.3 Modelo de Navegación UWE

Figura: Propia

2.7. Modelo de Presentación

Describe dónde y cómo los objetos de navegación y accesos primitivos serán


presentados al usuario, es decir, una presentación esquemática de los objetos
visibles al usuario.

El Modelo de Navegación detalla cuáles son las clases de navegación y de proceso


que pertenecen a una página Web. Se puede usar un Diagrama de Presentación, con
el fin de proveer esta información.

15
Estos diagramas permitieron especificar dónde y cómo los objetos de navegación
serán presentados al usuario, es decir, una representación esquemática de los
objetos visibles al usuario. Para el modelo de presentación se utiliza los siguientes
estereotipos e iconos como se detalla en el siguiente cuadro.

Una vez corrida los modelos de navegación definido los roles de cada usuario y las
variables que se van a desarrollar se presenta una fase final con los resultados del
sistema que se está diseñando y mostrar al usuario.

1.4 Figura No. 2.4 Modelo de Presentación UWE.

Fuente: Propia

2.8. Modelo de Procesos

El modelo de tareas o procesos integra los procesos de negocios al modelo de UWE,


especificando los comportamientos de cada proceso y de las interfaces que permiten
manejar a cada uno de ellos. Este modelo representa la parte dinámica de la
aplicación Web, especificando la funcionalidad de las transacciones y de los flujos de
trabajo complejos de las actividades.

16
1.5 Figura No. 2.5 Modelo de Procesos UWE.

Fuente: Propia

2.8.1. Ventajas y Desventajas

Las principales razones para el uso de los mecanismos de extensión de UML en


lugar de una técnica de modelado de propiedad es la aceptación del UML en el
desarrollo de sistemas de software, la flexibilidad para la definición de un lenguaje de
modelado específico de dominio Web: el llamado perfil UML, y amplio apoyo de

17
modelado visual por herramientas CASE UML existentes.

UWE utiliza "puro" notación UML y tipos de diagramas UML siempre que sea posible
para el análisis y diseño de aplicaciones Web, es decir, sin las extensiones de
cualquier tipo.
Por las características Web, como nodos y enlaces de la estructura de hipertexto, el
perfil UWE incluye estereotipos, valores etiquetados y restricciones definidas para los
elementos de modelado. La extensión UWE cubre la navegación, la presentación, los
procesos de negocio y los aspectos de adaptación.

2.9. MÉTODOS DE PRUEBA DEL SISTEMA

2.9.1. Método de Prueba de Caja Blanca

La prueba de caja blanca, en ocasiones llamada prueba de caja de vidrio, es una


filosofía de diseño de casos de prueba que usa la estructura de control descrita como
parte del diseño a nivel de componentes para derivar casos de prueba.
Al usar los métodos de prueba de caja blanca, puede derivar casos de prueba que:

 Garanticen que todas las rutas independientes dentro de un módulo se


revisaron al menos una vez.
 Revisen todas las decisiones lógicas en sus lados verdadero y falso.
 Ejecuten todos los bucles en sus fronteras y dentro de sus fronteras
operativas.
 Revisen estructuras de datos internas para garantizar su validez.
Las pruebas de caja blanca intentan garantizar que se ejecuten al menos una
vez todos los caminos independientes de cada módulo se utilizan las decisiones
en su parte verdadera y falsa que se ejecuten todos los bucles en sus límites.

18
1.6 Figura No. 2.6 A Diagrama de Flujo y B Gráfico de Flujo.

Fuente: Propia
2.10.2. Rutas de Programa Independientes

Una ruta independiente es cualquiera que introduce al menos un nuevo conjunto de


enunciados de procesamiento. Cuando se establece como un gráfico de flujo, una
ruta independiente debe moverse a lo largo de al menos una arista que no se haya
recorrido antes de definir la ruta.
No se considera como independiente porque simplemente es una combinación de
rutas ya especificadas y no recorre alguna arista nueva. Es decir, si se pueden diseñar
pruebas para forzar la ejecución de estas rutas, todo enunciado en el programa
tendrá garantizada su ejecución al menos una vez, y cada condición se ejecutará en
sus lados verdadero y falso.

2.11. MÉTRICAS DE CALIDAD DEL SOFTWARE

2.11.1. Métricas de Calidad

En la mayoría de los desafíos técnicos, las métricas nos ayudan a entender tanto el
proceso técnico que se utiliza para desarrollar un producto, como el propio producto.
El principio, podría parecer que la necesidad de la medición es algo evidente
después de todo lo que nos permite cuantificar y por consiguiente gestionar de forma
más efectiva.

19
 Para identificar la calidad del producto.
 Para evaluar la productividad de la gente que desarrolla.
 Para evaluar los beneficios en términos de productividad y de calidad,
derivados de uso de nuevos métodos y herramientas de la ingeniería de
software.

 Para establecer una línea de base para la estimación.

La medición del mundo físico puede englobarse en dos categorías: medidas directas
y medidas indirectas.

La métrica de calidad del software implica la utilización de metodologías o


procedimientos para el análisis del diseño de programación y prueba del software
que permitan uniformar el trabajo, para lograr una confiabilidad, mantenibilidad y
facilidad de prueba y a si elevar la productividad de la empresa como el de la calidad
de software.
 Medidas directas. en el proceso se encuentran el costo y el esfuerzo
aplicado. Las líneas de códigos producidas, velocidad de ejecución el
tamaño de memoria y los defectos observados en un determinado periodo
de tiempo.
 Medidas Indirectas. Se encuentra la funcionalidad, calidad, complejidad,
fiabilidad facilidad de mantenimiento, entre otros.

2.11.2. Modelo Normas ISO/IEC 9126

La norma ISO 9126 o ISO/IEC 9126 en un conjunto de características y


subcaracterísticas definidas que permiten conocer el nivel de la calidad del software a
través de un proceso de evaluación de acuerdo a las métricas o indicadores que
presenta el modelo de calidad. Según Modelo de Calidad de Software es un modelo
de calidad estándar para productos de software, donde se describen las diferentes
características y sub características que debe cumplir un sistema de software para que
pueda ser considerado como un sistema de calidad. ISO es una organización
internacional de normalización que es encargado del desarrollo de normas
20
internacionales de fabricación, comercio y comunicación para todas las ramas
industriales.

IEC es una comisión electrónica internacional es una organización de normalización


en campos eléctricos, electrónico y tecnologías relacionadas. Estas entidades
trabajan en colaboración con otras organizaciones conformando comités técnicos por
el cual se han desarrollado estándares como ISO/IEC 9126.

1.7 Tabla 1 Características de Calidad de Modelo ISO/IEC 9126


CARACTERÍSTICAS SUBCARACTERISTICAS
Funcionabilidad  Adecuación
 Exactitud
 Interoperabilidad
 Seguridad
Confiabilidad  Madurez
 Tolerancia a Fallas
 Recuperabilidad
Usabilidad  Entendibilidad
 Capacidad de aprendizaje
 Operabilidad
Eficiencia  Comportamiento de Tiempo
 Comportamiento de recursos
Mantenibilidad  Analizabilidad
 Estabilidad compatibilidad de pruebas
Portabilidad  Adaptabilidad
 Instalabilidad
 Reemplazabilidad
Nota: Fue creada para la evaluación extensiva de la calidad que sirve como elemento central en un proceso
deevaluación del software.

21
2.11.3. Funcionalidad

Se refiere a un conjunto de funciones y propiedades que tratan de satisfacer las


necesidades. Sus atributos son: adecuación, exactitud, interoperabilidad, seguridad
y cumplimiento funcional. Los puntos de función se describen como medidas básicas
desde donde se calculan métricas de productividad.
 Exactitud. Evalúa el resultado final que obtiene el software y si tiene
consistencia a lo que se espera de él.
 Interoperabilidad. Consiste en revisar si el sistema puede interactuar con
otro sistema independiente.
 Seguridad. Verifica si el sistema puede impedir el acceso a personal no
autorizado.

2.11.4. Fiabilidad

Se refiere a un conjunto de atributos que miden la capacidad que tiene el software


para mantener un nivel de rendimiento óptimo, bajo determinadas condiciones y
durante un periodo de tiempo determinado. Sus atributos son madurez, tolerancia a
fallos, Conformidad y la capacidad de recuperación ante un fallo. Para que un sistema
sea fiable, se debe garantizar un nivel de seguridad. La seguridad se subdivide a su
vez en confidencialidad, autenticación, control de acceso, integridad de los datos y
responsabilidad de los usuarios.

Es la capacidad para mantener un nivel específico de funcionamiento cuando se está


utilizando bajo condiciones específicos.

2.11.5. Usabilidad

Se refiere a un conjunto de atributos que miden el esfuerzo cognitivo necesario que


deben realizar los usuarios para utilizar el sistema de software. Sus atributos son
compresión, curva de aprendizaje y operatividad.

22
2.11.6. Eficiencia

Se refiere a un conjunto de atributos que miden la relación entre el rendimiento del


software y la cantidad de recursos utilizados, dad una situación determinada. Sus
atributos son tiempo de respuesta y recursos utilizados.
La eficiencia se entiende como la capacidad del sistema para proporcionar tiempos
de respuesta, tiempos de proceso y potencia apropiados bajo condiciones
determinadas.

2.11.7. Mantenibilidad

Se refiere a un conjunto de atributos relacionados con el esfuerzo necesario para


realizar determinadas modificaciones en el producto.
Sus a tributos son la capacidad de ser analizado, capacidad para ser modificado,
estabilidad y capacidad para ser probado.
Capacidad del producto de software para ser modificada. Las modificaciones incluir
correcciones, mejoras o adaptación del software a cambios en el entorno y
especificaciones de requerimientos funcionales.

2.11.8. Portabilidad

Son atributos con la capacidad del software de ser transferido de un entorno a otro.
Sus atributos son adaptabilidad, capacidad de instalación, coexistencia y capacidad
de reemplazamiento es utilizando la métrica de conformidad, adaptabilidad,
Reemplazabilidad, conformidad de transportabilidad.

2.12. Métricas Basadas en Función

La métrica punto función (PF) se usa de manera efectiva como medio para medir la
funcionalidad que entrega un sistema.
PF se deriva empleando una relación empírica basada en medidas contables del
dominio de la información del software y la complejidad de este.
23
1.8 Tabla 2 Factores de Ponderación

Parámetros de medición Factores de Ponderación Total


Cuenta
Simple Medio Complejo
1 nro. De Entradas de usuario X 3 4 6
2 nro. De Salidas de usuario X 4 5 7
3 nro. De Peticiones Usuario X 3 4 6
4 nro. De Archivos X 7 10 15
5 nro. De Interfaces externas X 5 7 10

Cuenta Total

Nota: Las métricas de calidad de software permiten monitorizar un producto para determinar su nivel de
calidad.

 Número de entradas de usuarios. Se cuenta cada entrada del usuario que


proporcione al software diferentes datos aplicados a la aplicación. Las entradas
deben ser distinguidasde las peticiones que se contabilizan por separado.
 Número de salidas de usuarios. Se encuentra cada salida que proporciona
al usuario información orientada a la aplicación. En este contexto se requiere
informes, pantallas,mensajes de error.
 Número de peticiones al usuario. Una petición está definida como una
entrada interactiva que resulta de la generación de algún tipo de respuesta
en forma de salidainteractiva se cuenta cada petición por separado.
 Número de archivos. Se cuenta cada archivo maestro lógico es decir una
agrupación lógica de datos que puede ser una parte de la base de datos o un
archivo independiente.
 Número de interfaces extremas. Se cuentan todas las interfaces legibles
por la máquina, por ejemplo: archivo de datos, en cintas o discos que son
utilizados para transmitir información a otro sistema.

24
2.13. SEGURIDAD DE LA INFORMACION

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 en el software y hacer que falle el sistema completo.
Si se pueden identificar pronto los riesgos en el proceso de ingeniería del software
podrán especificarse las características del diseño del software que permitan eliminar
o controlar los riesgos potenciales.

2.13.1. Estándar ISO/IEC 27000

La familia ISO/IEC 27000 se la conoce como serie ISO 27000, se desarrolla y publica
por la Organización Internacional de Normalización (ISO) y la Comisión
Electrotécnica Internacional (IEC).
La familia ISO 27000 contiene un conjunto de buenas prácticas para el
establecimiento, implementación, mantenimiento y mejora de Sistemas de Gestión
de la Seguridad de la información. (ISO/IEC 27000, 2018)
De acuerdo con SGSI , La seguridad de la información es de mucha importancia para
todas las empresas.

2.13.2. ISO 27002

La ISO 27002 proporciona las mejores prácticas de la gestión de seguridad de


información a todos los interesados en iniciar, implantar o mantener sistemas de
gestión de la seguridad de la información.
La seguridad de la información se define en el estándar como la prevención de la
confidencialidad que solo quienes estén autorizados puedan acceder a la
información, integridad que la información y sus métodos de proceso son exactos y
completos y disponibilidad que los usuarios autorizados tienen acceso a la
información del sistema cuando lo requieran. (ISO/IEC 27002, 2018).

25
2.13.3. MODELO VISTA CONTROLADOR (MVC)

El patrón MVC es un patrón de arquitectura de software encargado de separar la


lógica de negocio de la interfaz del usuario y es el más utilizado en aplicaciones Web,
ya que facilita la funcionalidad, mantenibilidad y escalabilidad del sistema, de forma
simple y sencilla, a la vez que permite "no mezclar lenguajes de programación en el
mismo código". La arquitectura Modelo Vista Controlados divide la aplicación en tres
capas.

Es un patrón de arquitectura de software que separa los datos y la lógica de negocio


de una aplicación de la interfaz de usuario y el módulo encargado de gestionar los
eventos y las comunicaciones.

 Modelo. Es donde se procesa y obtiene los datos desde la base de datos.


 Vista. presentan los datos en pantalla, es donde va el código HTML.
 Controlador. Obtiene los datos del modelo, los procesa y se los pasa a la
vista.

1.9 Figura No. 2.7 Funcionamiento del Modelo Vista Controlador MVC.

Fuente: (Propia)

26
2.14. HERRAMIENTAS DE DESARROLLO

2.14.1. Sistema De Gestor de Base de Datos MariaDB

Es un sistema de gestión de bases de datos derivado de MySQL con licencia GPL.


Es desarrollado por Michael (Monty) Widenius (fundador de MySQL) y la comunidad
de desarrolladores de software libre. Introduce dos motores de almacenamiento
nuevos, uno llamado Aria -que reemplaza con ventajas a MyISAM- y otro llamado
XtraDB -en sustitución de InnoDB.

MariaDB es un sistema gestor de bases de datos totalmente de código abierto,


desarrollado a partir de un fork de MySQL, por tanto, se trata del mismo software, o
mejor dicho, dos softwares con una misma raíz, porque lo cierto es que hoy los dos
motores de bases de datos han distanciado un tanto sus líneas de desarrollo.
MariaDB es totalmente libre. Dispone de una única licencia, por lo que no aquellas
personas que apoyan el software libre se suelen sentir más inclinados a usar este
motor de bases de datos.

[Link]. Ventajas y Desventajas de MariaDB


 Al ser MariaDB compatible con MySQL, la migración a MariaDB es simple y
directa, no hay que adaptar el código ni nada.
 Mejoras de velocidad sobre todo en consultas complejas cuando se usa el
motor de almacenamiento Aria, ya que Aria cachea los datos de tablas
temporales en memoria, lo que supone un rendimiento frente al uso del disco
duro (que es lo que emplea MyISAM).
 Estadísticas extendidas para el usuario nuevo.
 Especificación en motor de almacenamiento.

2.14.2. Lenguaje de Programación PHP (HYPERTEXT PREPROCESSOR)


PHP (Hypertext Preprocessor) es un lenguaje de código abierto muy popular
especialmente adecuado para el desarrollo web y que puede ser incrustado en

27
HTML. Lo mejor de utilizar PHP es su extrema simplicidad para el principiante, pero a
su vez ofrece muchas características avanzadas para los programadores
profesionales. El código es interpretado por un servidor web con un módulo de
procesador de PHP que genera la página web resultante. PHP ha evolucionado por lo
que ahora incluye también una interfaz de línea de comandos que puede ser usada
en aplicaciones gráficas independientes. Puede ser usado en la mayoría de los
servidores web al igual que en casi todos los sistemas operativos y plataformas sin
ningún costo. Se considera uno de los lenguajes más flexibles, potentes y de alto
rendimiento conocidos hasta el día de hoy. Lo que ha traído el interés de múltiples
sitios con gran demanda de tráfico como Facebook, para optar php como tecnología
de servidor.
PHP es un lenguaje de programación de uso general de código del lado del servidor
originalmente diseñado para el desarrollo web de contenido dinámico. Fue uno de los
primeros lenguajes de programación del lado del servidor que se podían incorporar
directamente en el documento HTML en lugar de llamar un archivo externo que
procese los datos.

[Link]. Ventajas y desventajas de PHP


Ventajas
 Alto rendimiento.
 Bajo coste.
 Interfaces para una gran cantidad de sistemas de base de datos.
 Facilidad de aprendizaje y uso.
 Portabilidad.
 Acceso al código abierto.
 Gran variedad de funciones integradas.

Desventajas
 Como es un lenguaje que se interpreta en ejecución para ciertos usos puede
resultar un inconveniente que el código fuente no pueda ser ocultado. La
ofuscación es una técnica que puede dificultar la lectura del código, pero no
la impide y, en ciertos casos, representa un costo en tiempos de ejecución.
28
 El lugar más seguro para ejecutar una aplicación es en un servidor propio,
por lo cual, si un cliente o usuario requiere su código en su pc, tendríamos
que dejar su código, sin manera de ocultarlo, aunque hay muchas
aplicaciones que nos ayuda aencriptar el código fuente.
 Debes saber cuándo menos HTML para poder hacer un trabajo
medianamente funcional.
 Si no lo configuras correctamente dejas abiertas muchas brechas de
seguridad.
 Se necesita instalar un servidor web.

2.14.3. Framework BOOTSTRAP

Bootstrap, es un framework originalmente creado por Twitter, que permite crear


interfaces web con CSS y JavaScript, cuya particularidad es la de adaptar la interfaz
del sitio web al tamaño del dispositivo en que se visualice. Es decir, el sitio web se
adapta automáticamente al tamaño de una PC, una Tablet u otro dispositivo. Esta
técnica de diseño y desarrollo se conoce como “responsive design” o diseño
adaptativo.
El beneficio de usar responsive design en un sitio web, es principalmente que el sitio
web se adapta automáticamente al dispositivo desde donde se acceda.
Lo que se usa con más frecuencia, es el uso de media queries, que es un módulo de
CSS3 que permite la representación de contenido para adaptarse a condiciones
como la resolución de la pantalla y si trabajas las dimensiones de tu contenido en
porcentajes, puedes tener una web muy fluida capaz de adaptarse a casi cualquier
tamaño de forma automática.
Bootstrap se ha caracterizado por tratarse de una excelente herramienta para crear
interfaces de usuarios limpias y totalmente adaptables a cualquier tipo de dispositivo y
pantalla, independientemente de su tamaño.

[Link]. Características

Bootstrap se ha convertido en una de las herramientas más utilizadas hoy en día a la


29
hora de realizar cualquier diseño web. Esto es debido a algunas de sus principales
características, que lo han hecho muy atractivo a los ojos de los desarrolladores.
 Fácil e intuitivo. su aprendizaje es muy rápido, mucho mas para
aquellas personas que tengan conocimientos de diseño web.
 Compatibles con todos los navegadores. Uno de los principales
problemas a la hora de diseñar un portal web es hacer que éste se vea
de forma similar en cualquier navegador web del mercado. Bootstrap es
compatible con la mayoría de navegadores web del mercado.
 Optimizado para dispositivos móviles. gracias a su adaptabilidad y
diseño responsivo, Bootstrap se visualiza en también en dispositivos
móviles.

[Link]. Ventajas y Desventajas

Ventajas
 Mantenimiento y actualización realizados por Twitter.
 Paquete de elementos web personalizables.
 Utiliza componentes vitales para los desarrolladores (HTML5,
CSS3, jQuery o GitHub, entre otros).
 De sencilla adaptación responsive.
 Incluye Grid system para maquetar por columnas.
 Integración a librerías JavaScript.
 Usa Less, ágil y sencillo.
Desventajas
 Aprendizaje: Es necesario adaptarse a su forma de trabajo, si bien su curva
de aprendizaje es liviana, deberás comprender y familiarizarte con su
estructura y nomenclatura.

 Adaptación: Debes adaptar tu diseño a un grid de 12 columnas, que se


modifican según el dispositivo. Aquí empiezan los problemas, Bootstrap por

30
defecto te trae anchos, márgenes y altos de línea, y realizar cambios
específicos es por decir, un poco tedioso.
 Mantenimiento: Es complicado, cambiar de versión si has realizado
modificaciones profundas sobre el Core.
 Ampliar componentes: Si necesitas añadir componentes que no existen,
debes hacerlos tú mismo en CSS y cuidar de que mantenga coherencia con tu
diseño y cuidando el Responsive.

2.14.4. Servidor Web Apache

Apache Web Server, es un servidor de páginas Web desarrollado por la Apache


Software Fundation, organización formada por miles de voluntarios que colaboran
para la creación de software de libre distribución. Es uno de los servidores más
utilizados en Internet ya que se trata de un servidor muy potente, flexible, rápido,
eficiente y que siempre está adaptado a nuevos protocolos http. Apache se
encuentra disponible para varias plataformas, desde Debian, hasta Windows XP y se
le puede incrustar nuevos módulos que le permitirán ejecutar código Script como son
JSP, PHP, etc.

1.10 Figura No. 2.8 Esquema de Funcionamiento Apache.

Fuente: Propia

31
[Link]. Características

Entre las principales características de Apache, se encuentran las siguientes:


 Soporte de seguridad SSL y TLS.
 Puede realizar autentificación de datos utilizando SGDB.
 Puede dar soporte a diferentes lenguajes, como Perl, PHP, Python y tcl.
Apache es utilizado principalmente, para realizar servicio a páginas web, ya sean
estáticas o dinámicas.
Este estupendo servidor se integra a la perfección con otras aplicaciones, creando el
famoso paquete XAMP con Perl, Python, MySQL y PHP, junto a cualquier sistema
operativo, que por lo general es Linux, Windows o Mac OS.

[Link]. Ventajas y Desventajas

Ventajas

 Modular.
 Open source.
 Multi-plataforma.
 Extensible Gratuito.

Desventajas
 Posee Formatos de configuración no estándar.
 No posee buena administración.
 Este servidor no es multiplataforma, sólo funciona bajo Windows.
 Posee limitaciones en las versiones que no son de la familia “Server”. Posee
vulnerabilidades.

32
CAPITULO III
CAPITULO III
3. MARCO PROPOSITIVO

En este capítulo se presenta el desarrollo del proyecto, las faces correspondientes a


la conceptualización análisis, diseño, implementación, prueba, análisis de datos y
resultados obtenidos del sistema, de acuerdo a la metodología UWE, que permite
evolucionar adecuadamente en el diseño del sistema, aplicando los puntos
mencionados en el marco teórico y siguiendo el respectivo plan de desarrollo de
software.

3.1. ANÁLISIS Y DISEÑO

Para el proyecto se ha determinado utilizar el Modelo Lineal Secuencial como


paradigma de análisis y diseño.
Este modelo es llamado también ciclo de Vida Clásico o Modelo en Cascada, el cual
sugiere un enfoque sistemático secuencial para el desarrollo del software, consta de
las siguientes actividades:

3.1.1. Análisis. -Esta etapa consiste en recabar toda la información posible y


los requerimientos del proyecto para transformarla en especificaciones
estructuradas, es decir, en diagramas de flujo de datos, diagramas entidad -
relación, etc.

3.1.2. Diseño. - La actividad de diseño se ocupa de la transformación de


modelos de datos entidad relación en un diseño de base de datos. En esta
etapa se diseña toda la interfaz que tendrá el software con el usuario,
mediante una descripción del formato de la secuencia de entrada de
datos, es decir, el diseño de pantallas y el diálogo entre el usuario y la
computadora.

3.1.3. Codificación. - Esta etapa consiste en traducir a un lenguaje máquina


33
todo el diseño realizado anteriormente, generando el código del sistema o
software analizado.

3.1.4. Prueba. - Esta etapa consiste en probar todo el código generado. Estas
pruebas sirven para detectar de errores y determinar que las entradas
definidas producen los resultadosesperados.

3.1.5. Mantenimiento. - El software desarrollado una vez entregado puede


tener correcciones debido a cambios en el entorno, como ser: cambios en
el sistema operativo o dispositivos periféricos nuevos, o porque el usuario
necesita mejoras funcionales o de rendimiento.

1.11 Figura No.3 Estructura Modelo Lineal Secuencial.

Fuente: (Fuente propia)

34
3.2. LISTA DE REQUERIMIENTOS DEL SISTEMA

3.2.1. Especificaciones de Requerimientos para la Aplicación

De acuerdo a lo establecido en el capítulo 2, donde se hace una referencia puntual a


la especificación de requerimientos para el diseño y desarrollo del Software, que
utiliza el estándar IEEE-STD-830-1998: Especificaciones de los Requisitos del
Software, a continuación, se presenta un análisis de los requerimientos identificados
en las visitas al lugar de estudio, en conversaciones, entrevistas y observación directa
de los problemas.

Haciendo un análisis de la especificación de requerimientos del software con el uso


del estándar IEEE- 830 se ha podido identificar los requisitos del usuario para el
desarrollo del producto software y la disponibilidad de los mismos.

1.12 Tabla 1 Requerimientos del Software para la Aplicación.

TIPO NOMBRE FASE DE UTILIZACIÓN

Lenguaje de Programación PHP Etapa de implementación, en el desarrollo

de la aplicación.

Gestor de Base de Datos MariaDB Funcionamiento de la aplicación.

Editor de texto de desarrollo Sublime text Etapa de implementación, en el desarrollo

multiplataforma de la aplicación.

Diseño Grafico PhotoShop Etapa de implementación, en el desarrollo

de la aplicación.

Nota: Especificaciones de los Requisitos del Software

35
3.2.2. Funciones del Sistema

Las funciones del sistema son sus características o dimensiones, como ser:
facilidad de uso, tiempo de respuesta, metáfora de interfaz, tolerancia a fallas,
plataforma.

1.13 Tabla 1.1Funciones del Sistema

FUNCIONES DETALLES Y RESTRICCIONES


Facilidad de uso Cuando de ingresa al sistema el usuario tendrá un menú de
opciones

distintas, de acuerdo al rol del usuario.


Tiempo de respuesta Cuando se registre, actualice y proceda con la opción de proceso que
desee

realizar los datos del proceso aparecerán en 3 segundos como máximo.


Metáfora de interface La interface será orientada en una forma adaptativo a cualquier tamaño
de

pantalla e intuitivo al usuario con mensajes en las acciones que se realicen.


Tolerancia de falla Muestra mensajes de error cuando no se encuentre cualquier tipo
de

producto o productos faltantes en el almacén.


Plataforma del sistema Linux, Windows, Pentium D para adelante.

operativo
Nota: Las funciones del sistema son sus características o dimensiones. Fuente: (Elaboración propia)

3.2.3. Requerimientos Funcionales

Un requisito funcional define una función del sistema de software o sus


componentes.
Una función es descrita como conjunto de entradas, comportamientos y salidas.

36
Los requerimientos funcionales pueden ser cálculos, detalles técnicos, manipulación
de datos y otras funcionalidades específicas que se supone, un sistema debe
cumplir.
Los requerimientos de comportamiento para cada requerimiento funcional se
muestran en los casos de uso. Son complementados por los requisitos no
funcionales, que se enfocan en cambio en el diseño o la implementación

1.14 Tabla 1.2 Requerimientos Funcionales

Ref. Función Categoría


R1 Acceder al sistema por tipos de usuario (Administrador, Farmacéutico). Evidente

R2 Registrar a los usuarios en el sistema Evidente

R3 Registro de parámetros Evidente

R4 Registro de formulario compras. Evidente

R5 Registro de informe de registros fijos. Evidente

R6 Registro de formulario ventas. Evidente

R7 Generar reportes de productos fijos, ubicaciones, precios. Evidente

R8 Registro de proveedor. Evidente

R9 Inicio de sesión introduciendo los datos de usuario para la Evidente


autentificación.
Nota: Los requerimientos funcionales para el modelo se detallan en esta tabla.

3.2.4. Requerimientos No Funcionales

Los requerimientos no funcionales son las limitaciones que puede tener el sistema,
como el rendimiento en tiempo y espacio, interfaces de usuario, fiabilidad robustez del
sistema, disponibilidad de equipo, mantenimiento y seguridad.

37
1.15 Tabla 1.3 Requerimientos no Funcionales

REF. FUNCIÓN CATEGORÍA

R1 El Sistema debe funcionar en cualquier tipo de computadora. Evidente

R2 El Sistema debe mostrar todos los informes necesarios. Evidente

R3 El Sistema no debe tardar más de 3 segundos para mostrar resultados. Evidente

Nota: Los requerimientos funcionales para el modelo se detallan en esta tabla.


3.3. ANALISIS DE REQUERIMIENTOS

En análisis de requerimientos se plasma los requerimientos del sistema mediante el


diseño del Diagrama de Caso de Uso Comercial el cual describe el comportamiento
de la Farmacia “Ecofarma” y el Diagrama de Caso de Uso el mismo que describe el
comportamiento del sistema frente a las acciones de los actores del mismo, así como
las funcionalidades del sistema.

3.3.1. Modelos de Caso de Uso

En el presente numeral se plasman el análisis de requerimientos del sistema


mediante el diseño de caso de uso, mismo expresado en el comportamiento del
sistema frente a las acciones de los actores del mismo, funcionalidades del sistema y
además elementos que permiten la abstracción del problema.

Identificación Actores del Actores: Cliente, Proveedor.


1.16 Figura No. 3.1 Actores del Negocio.

Fuente: (Elaboración propia)

38
1.17 Figura No. 3.2 Trabajadores del Negocio

Fuente: (Elaboración propia)

3.3.2. Identificación de Entidades del Negocio

Entidades: Compra de Productos, Administración de Reportes, Venta de


productos, Entrega de Productos, Generar factura, Entrega de factura, Realiza Cobro.

1.18 Figura No. 3.3 Entidades del Negocio.

Fuente: (Elaboración propia)

39
Diagrama de Caso de Uso General del Negocio
Figura No. 3.4 Diagrama de Caso de Uso General del Negocio.

Fuente: (Elaboración propia)

Figura No. 3.5 Diagrama de Caso de Uso General del Sistema

Fuente: (Elaboración propia)

40
Figura No. 3.6 Diagrama de Caso de Uso de Iniciar Sesión.

Fuente: (Elaboración propia)

1.19 Tabla 1.4 Diccionario de Casos de Uso Iniciar Sesión.

Caso de uso: Iniciar sesión


Actores: Administrador, farmacéutico
Permitir el acceso al sistema, autenticándose con el nombre
de usuario y contraseña, y así poder realizar acciones de
Propósito:
acuerdo a los requerimientos en el sistema.

- Estar registrado en el sistema

Precondición: - Ser administrador o farmacéutico.

- Contar con el nombre de usuario y contraseña

Post condición: Realizar alguna acción dentro del sistema de acuerdo a los

privilegios que tenga el usuario.


Flujo Básico
Actor Respuesta Sistema
1. El administrador o farmacéutico ingresa al 2. Entran al sistema Filtra información en
sistema por la ventana iniciar sesión (login), En la base de datos para mostrar al usuario
donde debe ingresar su nombre del usuario, su Si existe y si puede ingresar
Contraseña y el tipo de usuario. 3. Observa el sistema de compras, ventas
y facturación de acuerdo a los privilegios
de Usuario.

41
Figura No. 3.7 Diagrama de Caso de Uso Gestionar Usuarios.

Fuente: (Elaboración propia)


1.20 Tabla 1.5 Diccionario de Caso de Uso Iniciar Usuario.

Caso de uso: Gestionar Usuarios


Actores: Administrador
Permitir poder gestionar a los usuarios, registrando, modificando y
Propósito: eliminando los datos de los usuarios que tienen o tendrán
interacción con el sistema.

Precondición: Estar registrado como administrador en el sistema.


Elegir una opción como ser:
-Buscar usuarios
-Insertar usuarios
Post condición: -Editar usuarios

Flujo Básico
Actor Respuesta Sistema
1. El administrador ingresa al sistema y elige 3. El sistema muestra la venta de gestionar
opción de gestionar usuarios. usuarios, el cual le da varias opciones que
2. Elige una opción de gestionar usuarios, realiza, buscar, insertar, modificar
dependiendo la Acción que desee realizar. usuarios.

1. Si el usuario no es administrador no podrá realizar el ingreso a la ventana de gestionar usuarios.


2. Muestra opciones para poder gestionar usuarios.
3. Opción nuevo usuario requiere llenar datos del usuario.

42
2. El sistema realiza la búsqueda del usuario para poder registrarlo o rechazar la inserción del
usuario en la base de datos.
3. Opción modificar usuario requiere llenar el campo de nombre del usuario.

4. El sistema realiza una búsqueda del nombre del usuario en la base de datos, para verificar su
existencia y así poder modificarla.
5. El sistema muestra las casillas activas para modificar sus datos.

6. Pulsando el botón aceptar, realiza las modificaciones del usuario en la base de datos.

7. Opción eliminar usuario requiere seleccionar el nombre del usuario en la base de datos y
verificar
8. El sistema actualiza la base de datos al hacer algún cambio gestionar usuario.

Nota: Diccionario de caso de uso iniciar usuario. Fuente: (elaboración propia)

Figura No. 3.8 Diagrama de Caso de Uso Gestionar Venta.

Fuente: (Elaboración propia)

1.21 Tabla 1.6 Diccionario de Caso de Uso Gestionar Venta.

Caso de uso: Gestionar Venta


Actores: Administrador, Farmacéutico
Propósito: Permitir el acceso al sistema y poder gestionar las ventas,
de acuerdo a que privilegios tiene el usuario podrá realizar
las diferentes acciones en el sistema

43
Precondición: Estar dentro del sistema como administrador, farmacéutico
El usuario podrá elegir una opción como ser:

- Buscar producto.

- Insertar y Modificar producto.


Post condición:
Flujo Básico
Actor Respuesta Sistema
1. El administrador o farmacéutico ingresa al 3. El sistema muestra la venta de gestionar
sistema y elige la opción de gestionar ventas ventas el cual le muestra las opciones que
2. Elige una opción en la ventana de gestionar puede realizar
ventas, dependiendo a la acción que desee realizar 4. Muestra las opciones que puede realizar
como de ingresar, modificar y buscar.

Flujo de sistema
1. Si el usuario no es administrador o farmacéutico no podrá realizar el ingreso a la ventana de

gestionar ventas ni podrá realizar ninguna acción dentro del sistema.

2. Muestra opciones de gestionar ventas.

3. En la ventana de ventas se verá toda la lista en la base de datos los productos existentes en el
sistema.
4. El sistema realiza una búsqueda del nombre del producto en la base de datos, para verificar su
existencia y así poder insertar en la lista de ventas.
5. En el sistema no existe el nombre de dicho producto saltara a ventana no existe producto.

6. Opción agregar, inserta el producto a la lista de ventas.

7. El sistema muestra los productos activos en la lista de ventas, también podrá quitar producto no
requeridos de la lista de ventas.
8. Opción aceptar ventas requiere llenar el campo de nombre, C.I., teléfono y NIT de cliente,
luego generar la factura correspondiente de dicha venta.
9. El sistema también podrá realiza una búsqueda del nombre del cliente en la base de datos.
Nota: Diccionario de caso de uso gestionar ventas. Fuente: (Elaboración propia)

44
1.22 Figura No. 3.9 Diagrama de Caso de Uso Gestionar Productos.

Fuente: (Elaboración propia)

1.23 Tabla 1.7 Diccionario de Caso de Uso Gestionar Productos

j Gestionar Productos
Actores: Administrador
Permitir al administrador poder administrar productos la
cantidad de productos existentes en la base de datos, para
Propósito:
así poder hacer el pedido, compra de los productos
faltantes al
proveedor.
Estar registrado como administrador en el sistema para
Precondición: hacer

las siguientes acciones.

45
1.24 Figura No. 3.10 Diagrama de Caso de Uso Gestionar Proveedor.

Fuente: (Elaboración propia)

1.25 Tabla 1.8 Diccionario de Caso de Uso Gestionar Proveedor

Caso de uso: Gestionar Proveedor


Actores: Administrador

Propósito: Permitir al administrador poder gestionar a los proveedores


existentes en la base de datos, para así poder hacer el pedido de
productos faltantes en el sistema.

Precondición: Estar registrado como administrador en el sistema.


Flujo Básico
Actor Respuesta Sistema
1. El administrador ingresa al sistema y elige la 3. El sistema muestra la venta de gestionar
opción de gestionar proveedores. proveedores, el cual le da varias opciones que
2. Elige una opción en la ventana de gestionar puede realizar, buscar proveedores, insertar
proveedores, dependiendo a la acción que desee proveedores y modificar proveedores
realizar. 4. Muestra los diferentes parámetros de la
opción elegida.
5. Registra y acciona la opción requerida por

el administrador.

46
1.26 Figura No. 3.11Diagrama de Caso de Uso Gestionar Estadísticas.

Fuente: (elaboración propia)

1.27 Tabla 1.8 Diccionario de Caso de Uso Gestionar Estadística

Caso de uso: Gestionar Estadísticas


Actores: Administrador

Propósito: Permitir el acceso al sistema y poder gestionar las gráficas


de las estadísticas de los productos más salientes, menos
salientes.

Precondición: Estar dentro del sistema como administrador


Flujo Básico

Actor Respuesta Sistema

47
1. El administrador ingresa al sistema y elige la 3. El sistema muestra la venta de

opción de gestionar estadísticas. estadísticas donde puede observar la opción


de estadísticas.
2. Elige alguna opción de estadísticas de acuerdo a las
4. El sistema mostrara los graficas de
consultas requeridas por el administrador.
estadísticas, compras y ventas de
productos más vendidos.

Flujo de sistema

1. Si el usuario no es administrador o farmacéutico no podrá realizar el ingreso a gestionar

estadísticas.

2. El sistema muestra opciones para poder gestionar estadísticas.

3. Opción generar estadísticas requiere llenar datos por fecha de compras o ventas.

4. El sistema busca por fechas de ventas, compras para poder graficar los datos de estadísticas
productos.
5. El sistema mandara la opción de poder exportas las gráficas en un documento.

6. El sistema actualizara la base de datos.

Nota: Diccionario de caso de uso gestionar estadística. Fuente: (Elaboración propia)

3.3.3. MODELO DE CONTENIDO

El diagrama de contenido tiene por propósito mostrar las relaciones entre las
entidades y la estructura de los datos que se encuentran alojadas en el sistema el
modelo de contenido contiene la información relevante almacenada en el sistema
como se muestra y como se relacionan.

48
3.3.4. Modelo de Contenido del Sistema

Figura No. 3.12 Modelo del Contenido del Sistema.

Fuente: (elaboración propia)

49
3.3.5. Modelo Físico del Sistema
Figura No. 3.13 Diagrama de Clases.

Fuente: (elaboración propia)

50
3.3.6. Modelo de Navegación del Sistema

Figura No. 3.15 Modelo de Navegación del Sistema.

Fuente: (elaboración propia)

51
3.3.7. Modelo de Presentación del Sistema

[Link]. Modelo de Presentación de Login

1.28 Figura No. 3.15 Modelo Presentación de Autentificación de Usuario.

Fuente: (Elaboración propia)

[Link]. Modelo de Presentación de Menú Principal del Sistema


Figura No. 3.16 Modelo Presentación del Menú Principal del Sistema.

Fuente: (Elaboración propia)

52
[Link]. Modelo de Presentación de Administrar Usuario
Figura No. 3.17 Modelo Presentación Administrar Usuario.

Fuente: (Elaboración propia)


[Link]. Modelo de Presentación de Administrar Cliente

Figura No. 3.18 Modelo Presentación de Administrar Cliente.

Fuente: (Elaboración propia)

53
[Link]. Modelo de Presentación de Administrar Ventas
Figura No. 3.19 Modelo de Presentación de Administrar Ventas.

Fuente: (Elaboración propia)


[Link]. Modelo de Presentación de Administrar Productos
Figura No. 3.20 Modelo de Presentación de Administrar Productos.

Fuente: (elaboración propia)

54
[Link]. Modelo de Presentación de Administrar Compras

Figura No. 3.21 Modelo de Presentación de Administrar Pedidos.

Fuente: (elaboración propia)


[Link]. Modelo de Presentación de Administrar Pedidos

Figura No. 3.22 Modelo de Presentación de Administrar Pedidos.

Fuente: (elaboración propia)

55
[Link]. Modelo de Presentación de Administrar Proveedores

Figura No. 3.23 Modelo de Presentación Administrar Proveedor.

Fuente: (elaboración propia)

3.3.8. PRUEBAS DE SOFTWARE

Para las pruebas de software se utiliza el método de pruebas de caja negra el cual
evalúa las entradas introducidas por los usuarios y analiza el resultado devuelto por
el sistema además de la prueba de funcionalidad.

[Link]. Pruebas de Caja Blanca

Esta prueba se orienta al cálculo de las regiones que deben ser consideradas como
partes independientes del sistema, y estableciendo las entradas y se ejecutan cada
una de las regiones, asegurando así que cada región se ejecuta al menos una vez.
De forma general, se debe emplear el diseño del sistema para elaborar el grafo del
programa.

56
Figura No. 3.24 Caja Blanca.

Fuente: (Elaboración propia)


Donde:
 Inicio del sistema (1)
 Menú principal (2)
 Módulo de productos (3)
 Módulo de ventas (4)
 Módulo de estadísticas (5)

[Link]. Pruebas de Caja Negra

Las pruebas de caja negra o también conocidas como pruebas de comportamiento


se centran en los requisitos funcionales del software. Para realizar la prueba de caja
negra se realiza las pruebas a la interfaz mostrada a continuación.

Figura No. 3.25 Prueba de caja negra Inicio sesión

57
1.29 Tabla 1.9 Los valores de límites de inicio de sesión.

Campos Entrada Valida Entrada Invalida


Usuario Cadena de texto Caracteres especiales, espacios en blanco.

Contraseña Cadena de texto Caracteres especiales, espacios en blanco.


Nota: Muestra las limitaciones de inicio de sesión.

1.30 Tabla 3.1 Prueba de caja negra de iniciar sesión.

Entradas Salida Resultado


Usuario Contraseña “ingrese el usuario y El sistema valida que no se

contraseña” ingresen datos en blanco

Administrador yessica “Bienvenido al sistema Al introducir datos validos


yessica Inventarios” el sistema concede al
acceso.
Nota: La interfaz de inicio se sesión cumple con la función programada para que el usuario se identifique al
empezar el sistema.
3.3.9. Prueba de Caja Negra de Registro de Productos
En el proceso de registrar productos cumple con la función de ingresar los datos del
producto al sistema, de esta forma podrá ser utilizado para las ventas, posterior
orden de compra, pedidos y salidas de la farmacia.

Figura No. 3.26 Prueba de caja negra registrar productos.

58
1.31 Tabla 1.10 Valores límites de registrar producto.

Campo Entrada Valida Entrada Invalida


Código primario Características especiales, espacio en
Cadena de texto
Código de secundario blanco
Nombre de producto Cadena de texto Caracteres especiales, espacio en blanco
Código de producto Cadena de texto Caracteres especiales, espacio en blanco

Descripción Cadena de texto Caracteres especiales, espacio en blanco


Precio Cadena numérica Caracteres especiales, iniciando en 0
Cantidad existente Cadena numérica Caracteres especiales, iniciando en 0

Ubicación deposito Cadena de texto Caracteres especiales, espacio en blanco


Fecha de vencimiento Fecha Caracteres especiales, día-mes-año
Código de categoría Selección Caracteres especiales, espacio de selección
Nota: Valores de límites de registrar producto. Fuente: (Elaboración propia)

1.32 Tabla 1.11Prueba de caja negra registrar productos.

Código de Producto Descripción


Entradas Nombre del producto Septiquin F

Ubicación deposito Estante 21


Precio 8,50
Cantidad existente 6
Salida Ingrese los datos del producto Datos del producto se han

registrado con éxito.


Resultado El sistema valida las condiciones para llenar Cuando el usuario ingresa
los campos que son obligatorios y los que no
datos validos el sistema registra la
son opcional el llenado de los datos.
información en la base de datos.
Nota: Una vez realizado la prueba de caja negra a la interfaz de registro de producto se evidencia que la
misma cumple con la función de registro del producto, obligando al usuario a registrar los campos
obligatorios

59
1.32.1 Pruebas de Funcionalidad

Una vez finalizado el desarrollo de las primeras cuatro etapas de abrir se realiza las
pruebas para garantizar el funcionamiento del sistema, tomando en cuenta los casos
de uso representativos del mismo. El uso de las pruebas funcionales es para asegurar
correcto trabajo de entrada de datos, la navegación en el sistema, procedimientos y
obtención de resultados.

1.33 Tabla 1.12 Caso de prueba interfaz de inicio de sesión.

PROCEDIMIENTO DESCRIPCIÓN VALOR


Prueba Requerida Registro de Usuario Si
Usuario Administrador, ingeniero,

Asistente, Farmacéutico
SECUENCIA DE PRUEBA
Procedimientos Resultados Clasificación de
Funcionalidad
Para ingresar al sistema debes El sistema valida los datos una vez Si
ingresar los datos de nombre de validado los datos si son correctos
usuario y la contraseña. ingresa y si no el sistema le mandara un
mensaje datos incorrectos.

Fallas Encontradas Descripción Gravedad


Ninguna Ninguna -
N° Pasos de Prueba Resultados Esperados Pos. Neg.

1 Desde la pantalla de login ingresa al El usuario ingresara al sistema si Si

sistema con un nombre de usuario y los datos son correctos, y según el


contraseña. grado de privilegios quetenga.

60
2 Una vez que se ingresa de forma El usuario debe tener acceso a Si
autentificada se comprueba que tenga cada uno de las áreas según su
acceso a todas las áreas que puede realizar privilegio.
según sus privilegios.

3 El usuario ingresa a gestionar usuario. En gestionar usuario puede Si

cambiar si contraseña y usuario.

4 El administrador puede registrar a un El administrador debe tener Si


nuevo usuario. acceso a la modificación de datos
del personal de usuario del
sistema.

Comentario a la Prueba Realizada

Las pruebas de ingreso al sistema y a gestión de usuario se efectuaron con normalidad. Se obtuvo
el resultado esperado en cuanto a validación de usuario y contraseña, se mostraron mensajes de
alerta al ingresar con usuarios no registrados.

Procedimiento Descripción Valor

Prueba requerida Autentificado y con privilegios para el ingreso


Si
al sistema.

Usuario Administrador y el encargado o farmacéutico.

Nota: Prueba de la interfaz de iniciar sesión para ingresar al sistema. Fuente: (Elaboración propia)

61
1.34 Tabla 1.13 Caso de prueba gestionar productos.

SECUENCIA DE PRUEBA

Procedimientos Resultados Clasificación

Registrar datos de nuevo


El sistema registra los datos añadidos o
producto y/o modificar datos de
modificados. Si
producto.

Fallas Encontradas Descripción Gravedad

Ninguna Ninguna -

Pasos de Prueba Resultados Pos. Neg.

1 Se prueba el registro de un nuevo Se ingresa correctamente y se actualiza en Si

producto la lista de productos.

2 Se elige un producto existentepara Una vez cambiando los datos muestra un Si


luego editar los datos del mensaje de confirmación que los campos
producto registrado. se han editado correctamente.

3 Eliminar un producto. Muestra un mensaje de confirmación se Si

eliminó correctamente el producto.

Comentario de la Prueba Realizada

Las pruebas de gestionar productos se efectuaron con normalidad. Se obtuvo el resultado esperado
en cuanto al registrar y modificar el producto, se mostraron mensajes de alertas correspondientes de
modificar o agregar un muevo producto.

Nota: las pruebas de gestionar productos tienen las respuestas esperados. Fuente (Elaboración prop

62
1.35 Tabla 1.14 Caso de prueba gestionar productos y pedidos.

PROCEDIMIENTO DESCRIPCION VALOR


Prueba requerida Autentificado y con los Si
privilegios correspondientes.
Usuario

Secuencia de Prueba
Procedimientos Resultados Clasificación de
Funcionalidad
Gestión de orden de compra y El sistema debe registrar los Si
emisión de reportes de orden de datos de nuevo de gestionar de
compra. compra, pedidos.
Fallas Encontrados Descripción Gravedad
Ninguna Ninguna -
Pasos de Prueba Resultados Pos. Neg.
1 Se prueba el registro de un nuevo Se debe registrar una nueva compra, Si
orden de compras y pedidos. pedidos y el informe de que la operaciónse
realizó con éxito.
2 Reporte de orden de compra y Se muestra el reporte de gestionar Si
pedidos. compras y pedidos en formato pdf.
Comentario de la Prueba Realizado
Las pruebas de registro de nuevo gestionar compra, pedidos que realiza el administrador o
farmacéutico se va directamente hacia a los proveedores quien el administrados entrega un
formulario en donde va el día de envió del producto a pedir y la entrada al administrador verificando
los productos en estado normal obteniendo el resultado esperado mostraron alertas de las acciones
registradas en la base de datos.

Procedimiento Descripción Valor


Prueba requerida Autentificación con los Si
privilegios correspondientes.
Usuario Administrador o farmacéutico.

Nota: las pruebas de gestionar pedidos y compras tiene las respuestas esperados. Fuente: (Elaboración
propia)

63
1.36 Tabla 1.15 Caso de prueba de clientes, proveedor, categoría y control de
productos.

PROCEDIMIENTO DESCRIPCION VALOR


Prueba requerida. Autentificado con privilegios Si
respectivos.

Secuencia de Prueba
Procedimientos Resultados Clasificación
Registrar datos de nuevo cliente, editar, El sistema registra los datos Si
eliminar. registrar proveedor de nuevo añadidos o/a modificar.
proveedor, editar, datos de categoría,
registrar nueva categoría y productos.

Fallas Encontrados Descripción Gravedad


Ninguna Ninguna -
Pasos de Prueba Resultados Pos. Neg.
1 Se prueba el registro de un nuevo Se debe registrar un nuevo cliente, Si
cliente, proveedor, categoría y proveedor, categoría y productos el
productos. informe de que la operación se realizó
con éxito.

2 Se elige un registro de cliente, Posteriormente al cambio los datos son Si


proveedor, categoría y productos cambiado, y muestra un mensaje de se
existente y se procede a editarlos. editó correctamente los datos.

3 Reporte de datos de clientes, Lista de clientes, proveedores, categoría Si


Proveedores, categoría y productos. y productos completa oportuna.

Comentarios de la Prueba Realizada


Las pruebas de clientes, proveedores, categoría y productos se efectuaron con normalidad. Se
obtuvo el resultado esperado en cuanto al registro y modificación, se mostraron mensajes de alertas
de respuestas al modificar o agregar un muevo registro de categoría, proveedor, cliente y productos.

Nota: Las pruebas de clientes, proveedores y categorías tienen respuestas esperados

64
3.3.11 CATÁLOGO DE REQUERIMIENTOS DEL SISTEMA

Un proyecto no puede ser exitoso sin una especificación correcta y exhaustiva de


los requerimientos, donde describe las necesidades o deseos de un producto.

 Registro de las solicitudes, entrantes y salientes de medicamentos a


Almacén.
 Verificación rápida de la existencia de medicamentos.
 Realizar el seguimiento y control de la compra de medicamentos.
 Conocer cuales son los proveedores y clientes de compra y venta de
medicamentos.
 Realizar reportes de movimiento de inventario.
 Realizar comprobantes de ingreso y salida de medicamentos para las
Unidades Solicitantes.

3.4 METRICAS DE CALIDAD, ESTIMACION DE COSTO Y SEGURIDAD

1.36.1 Metricas de calidad

Las Métricas de Calidad proporcionan una medición de calidad de software con el


uso de ISO 9126, que establece cualquier componente de la calidad de software se
clasifica en un conjunto estructurado de características y subcaracterísticas las
cuales son:

1.36.2 Funcionalidad

 El software desarrollado satisface las necesidades expresadas por el


usuario, como ser a administración de la Farmacia “Ecofarma” La
funcionalidad de un software se puede medir de acuerdo a la complejidad
del sistema, para realizar la medida indirecta del software se toma la métrica
de punto de función, el cual se usa como medio para medir la
funcionabilidad de entrega del sistema.
 Punto función. Para el cálculo de punto función se toma en cuenta cinco
65
características, el dominio de información, como son números de entrada,
salida, condiciones, archivos e interfaz externa. Luego se realiza el cálculo
de punto de función hallando la suma de estas características, parámetros
de medición y el factor de ponderación también llamado punto medio de
ponderación.

1.36.3 Confiabilidad

La confiabilidad del sistema tiene la probabilidad de operación libre de fallos de


un programa de computadora. La confiabilidad del sistema se define como la
probabilidad de operación libre de fallos de un programa de computadora.

1.36.4 Mantenibilidad

El mantenimiento se desarrolla para mejorar el sistema en respuesta a los nuevos


requerimientos que la Farmacia” Ecofarma” desee implementar para su uso posterior.
1.37 ESTIMACIÓN DE COSTO DEL SOFTWARE

Existen distintos métodos para la estimación de costes de desarrollo de software,


estos métodos no son otra cosa que establecer una relación matemática entre el
esfuerzo y el tiempo de desarrollo.

1.37.1 Método de Estimación COCOMO II

En el método de estimación de costos COCOMO II, la estimación de costos del


sistema ha sido desarrollada bajo KLDC (Kilo-Líneas de código) como de detalle a
continuación.
El siguiente sistema de información web de compras ventas e inventarios se
implementó con Líneas de código en el lenguaje PHP.
1.38 SISTEMA DE SEGURIDAD DE LA INFORMACIÓN

La ISO-27002 evalúa y rectifica la implementación mediante el cumplimiento de las


normas, así como la mejora continua de un conjunto de controles que permiten

66
reducir el riesgo de sufrir incidentes de seguridad en el funcionamiento de la
institución en cuanto a la seguridad de la información, para lo cual se tomó los
siguientes tipos de seguridad.

3.6.1. Identificación y Autentificación

Permite prevenir el ingreso de personas que no son usuarios, para ello el sistema
cuenta con un control estricto en el ingreso con un Usuario y una contraseña
estrictamente controlada.
3.6.2. Encriptación

Es uno de los algoritmos de cifrado más utilizados y seguros para la encriptación de


contraseña, es uno del dato de suma importancia para el ingreso al sistema. de este
modo se está utilizando lo que es el algoritmo de AES una encriptación de seguridad
para el sistema.

67
CONCLUSIONES

Se concluye con los objetivos planteados habiendo realizado un estudio del sistema
actual en el proceso de registro de información con algunas irregularidades que
existía tomando en cuenta que con el presente proyecto se logró centralizar la
información y efectuar un control de inventarios y facturación en la farmacia así
coadyuvando en una mejor administración y control de información en la Farmacia
“Ecofarma”.

Para la estimación de costos del proyecto se usó el modelo de COCOMO II tomando


en cuenta el diseño anticipado, por medio de puntos de función lo cual permitió
determinar el esfuerzo, costo y tiempo de desarrollo.
Logrando todos los objetivos específicos se concluye con el DESARROLLO DE UN
SISTEMA WEB DE ADMINISTRACIÓN Y CONTROL DE VENTAS PARA LA
FARMACIA "Ecofarma", por lo que es un aporte tecnológico ya que se redujo el
tiempo de registros, consultas, búsquedas de la información perteneciente a la
Farmacia, el manejo de esta información se realiza de forma segura y confiable.

RECOMENDACIONES

En base a la seguridad propuesta y las observaciones realizadas durante las pruebas


y posterior a la implementación se elaboran las siguientes recomendaciones.

 Capacitar a los usuarios para poder operar el sistema de forma correcta.

 Para resguardar la información, el administrador del sistema debe


realizar copias de seguridad de la base de datos.
 Se recomienda mucha discreción en el manejo de sus usuarios y
contraseñas ya queel sistema contiene información importante.
 Mantener un control acerca del equipo que hace de servidor física.

68
BIBLIOGRAFÍA

Horizonte. (2020). Framework Bootstrap Ventajas y Desventajas.


[Link]
Desarrollo Web. (2020). Gestor de Base de Datos MariaBD.
[Link]

Patricia Lopez, Francisco Ruiz. (2006). El Lenguaje Unificado de Modelado.

[Link]

HubSpot. (2022). Que es boosttrap y como funciona en el diseño web.

[Link]
bootstrap#:~:text=Bootstrap%20es%20una%20biblioteca%20de,a%20diferentes%2
0formatos%20de%20navegaci%C3%B3n.
Definicion.D (2016). Ingenieria de Software I. Recuperado de
[Link]
Fuente,MariaBd. (2022). Gestor de Base de Datos MariaDB.
[Link]

ISO/IEC 27000. (2005).

[Link]
ISO/IEC 27002. (2016).
[Link]

SAID STELLER. (2016). Diseño y desarrollo de una base de datos Sql y aplicaciones web .

[Link]
%20Dise%C3%B1o%20y%20desarrollo%20de%20una%20base%20de%20datos%20SQL%20
y%20aplicaci%C3%B3n%20web%20para%20la%20gesti%C3%[Link]?sequence=1
AXARNET. (2012). PHP y MySQL.
[Link]

69
INDICE DE FIGURAS

FIGURA 1: ARBOL DE PROBLEMAS

FIGURA 2: FUNCIONES DE LA FARMACIA

70
FIGURA 3: IDENTIFICACION DE ACTORES

FIGURA 4: REGISTRAR USUARIO

71
FIGURA 5: REGISTRAR PRODUCTO

FIGURA 6: CATEGORIA PRODUCTO

72
FIGURA 7: REGISTRAR COMPRAS

FIGURA 8: REGISTRAR PROVEEDOR

73
FIGURA 9: REGISTRAR VENTAS

FIGURA 10: ACTIVAR CLIENTE

74
FIGURA 11: LISTAR PRODUCTOS

FIGURA 12: CONSULTA REPORTES

75
FIGURA 13: REGISTRAR REPORTE

FIGURA 14: CONSULTA VENTAS

76
FIGURA 15: REPORTE DE VENTAS

77

También podría gustarte