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