Embed Size (px)
Citation preview
1
Título del trabajo: “Sistema web para la gestión de la información y control de
ventas en INPUD”
Tutores del trabajo: Ing. Dianelis García Llerena
MsC. Juan Luis García Mendoza
Autores del trabajo: Elianis López Medina
, Junio,2018
2
Este documento es Propiedad Patrimonial de la Universidad Central “Marta Abreu” de Las Villas, y se
encuentra depositado en los fondos de la Biblioteca Universitaria “Chiqui Gómez Lubian” subordinada
a la Dirección de Información Científico Técnica de la mencionada casa de altos estudios.
Se autoriza su utilización bajo la licencia siguiente:
Atribución- No Comercial- Compartir Igual
Para cualquier información contacte con:
Dirección de Información Científico Técnica. Universidad Central “Marta Abreu” de Las Villas.
Carretera a Camajuaní. Km 5½. Santa Clara. Villa Clara. Cuba. CP. 54 830
Teléfonos.: +53 01 42281503-1419
3
Pensamiento
El hombre debe transformarse al mismo tiempo que la producción
progresa, no realizaríamos una tarea adecuada si fuéramos tan solo
productores de artículos, de materias primas y no fuéramos al
mismo tiempo productores de hombres.
Ernesto Che Guevara
4
Dedicatoria
A mis padres, por su incondicional apoyo y su constante preocupación por mí.
A mi hermano y mi novio, por confiar siempre en mí y apoyarme en todo
momento.
5
Agradecimientos
A toda mi familia, en especial a mis padres, mi hermano, mi novio y mis
abuelas que tanto me han apoyado y se han preocupado por mis estudios.
A Ailin y Yoelvys, por su apoyo durante la realización de la tesis.
A mis tutores Dianelis y Juan Luis, por hacerse responsable de mí y guiarme
en la realización de este trabajo.
A Liana por brindarme siempre su ayuda cada vez que la necesité.
A mis amigos del aula que me ayudaron a lo largo de toda la carrera para
poder llegar hasta aquí.
A todos aquellos que me han apoyado y han permanecido junto a mi durante
toda la carrera.
y han hecho posible que llegara hasta aquí.
6
Resumen
La Industria Nacional Productora de Utensilios Domésticos del municipio de Santa Clara cuenta con 13
unidades empresariales de base y tiene como misión la producción y comercialización de utensilios
domésticos para el hogar. Esta industria actualmente realiza la gestión de la información relacionada con
las ventas de manera manual mediante documentos Excel. Esto trae consigo diversos problemas de
calidad de datos, así como demora en la obtención de reportes relacionados con las ventas que realiza
cada Unidad Básica Empresarial. Además, provoca que la gestión de las ventas no se realice de manera
eficiente. Es por ello que el objetivo del presente trabajo es desarrollar un sitio web para la gestión de la
información y el control de ventas en esta industria utilizando el framework Symfony. Como resultado
principal se obtuvo un sitio web que permitió la gestión de las ventas y elevó la calidad, rapidez y
confiabilidad en el manejo de dicha información disminuyendo los errores que actualmente se cometen.
Entre las principales funcionalidades que tiene el sistema web se encuentra la gestión de los productos
fabricados por la empresa, así como el control de sus ventas.
7
Abstract
The national industry of domestic products of Santa Clara municipality has 13 basic business units
and has as a purpose, the production and commercialization of domestic utensils for the household.
Actually, this industry makes the managing of the information related to manual sales by means of
Excel documents, having as result problems in the data’s quality, as well as delaying in obtaining
reports related to sales in each basic business unit. In addition, it causes that the managing of sales
is not carried out efficiently. For this reason, the objective of this work is to develop a web site for the
managing of the information and the control of sales in the industry using the symfony framework. As
the main result, we obtained a web site that allowed the managing of sales and encreased the quality,
rapidness and reliability in the managing of the information reducing errors that are commonly
committed. Among the principal functions that has the web system is the managing of the
manufactured products by the company; as well as the control of its sales.
8
Tabla de Contenidos
Contenido INTRODUCCIÓN ................................................................................................................................... 1
Capítulo 1: Fundamentación Teórica ....................................................................................................... 5
1.1 Objetivos estratégicos de la empresa ............................................................................................. 5
1.2 Objeto de estudio ........................................................................................................................... 5
1.2.1 Aspectos más significativos sobre el control de ventas. ......................................................... 6
1.2.2 Análisis crítico de la ejecución de los procesos ...................................................................... 8
1.2.3 Procesos objeto de automatización ......................................................................................... 9
1.3 Tendencias y tecnologías actuales ................................................................................................. 9
1.3.1 Metodología de desarrollo Proceso Racional Unificado ........................................................ 9
1.3.2 Software libre ....................................................................................................................... 10
1.3.3 Aplicaciones Web ................................................................................................................. 11
1.3.4 HTML y CCS ....................................................................................................................... 11
1.3.5 JavaScript ............................................................................................................................. 12
1.3.6 Bibliotecas Boostrap y JQuery ............................................................................................. 12
1.3.7 Lenguaje de Programación PHP ........................................................................................... 13
1.3.8 Sistema Gestor de Base de Datos PostgresSQL ................................................................... 14
1.4 Conclusiones parciales ................................................................................................................. 15
Capítulo 2: Modelo del Negocio y Requisitos ....................................................................................... 16
9
2.1 Modelo del negocio actual ........................................................................................................... 16
2.2 Reglas del negocio a considerar ................................................................................................... 16
2.3 Actores del negocio ..................................................................................................................... 17
2.4 Diagrama de casos de uso del negocio ........................................................................................ 17
2.5 Trabajadores del Negocio ............................................................................................................ 18
2.6 Actores del sistema a automatizar ................................................................................................ 18
2.7 Diagrama de Casos de Uso del Sistema ....................................................................................... 19
2.8 Requisitos funcionales ................................................................................................................. 20
2.9 Requisitos no funcionales ............................................................................................................ 21
2.10 Descripción de los casos de uso ................................................................................................. 21
2.11 Planificación de estimación ....................................................................................................... 28
2.12 Conclusiones Parciales ........................................................................................................... 33
Capítulo 3: Descripción de la propuesta de solución ............................................................................. 34
3.1 Diseño de la base de datos ........................................................................................................... 34
3.1.1 Modelo conceptual de datos ................................................................................................. 34
3.1.2 Modelo físico de datos .......................................................................................................... 35
3.2 Arquitectura del sistema ......................................................................................................... 35
3.3 Diagrama de clases de diseño ...................................................................................................... 36
3.4 Diagrama de secuencia ................................................................................................................ 38
3.5 Tratamiento de errores ................................................................................................................. 40
3.6 Diagrama de componentes ........................................................................................................... 42
3.7 Diagrama de despliegue ............................................................................................................... 44
3.8 Sitio Web para la gestión de la información y el control de ventas ............................................. 44
3.9 Conclusiones Parciales................................................................................................................. 47
Capítulo 4: Pruebas de análisis y factibilidad ........................................................................................ 48
4.1 Pruebas de Caja Negra ................................................................................................................. 48
10
4.2 Plan de pruebas de rendimiento ................................................................................................... 53
4.2.1 Prueba de carga ..................................................................................................................... 53
4.2.2 Pruebas de stress ................................................................................................................... 54
4.2.3 Pruebas de resistencia (SOAK) ............................................................................................ 55
4.3 Conclusiones parciales ................................................................................................................. 56
Conclusiones .......................................................................................................................................... 57
Recomendaciones ................................................................................................................................... 58
Referencias bibliográficas ...................................................................................................................... 76
11
Lista de Figuras
Figura 1:Modelo del Negocio Actual. .................................................................................................... 16
Figura 2: Diagrama de Casos de Uso del Negocio. ................................................................................ 18
Figura 3: Diagrama de Casos de Uso del Sistema.................................................................................. 20
Figura 4: Modelo conceptual de datos. ................................................................................................. 35
Figura 5: Modelo físico de datos. ........................................................................................................... 35
Figura 6 : Patrón Modelo-Vista-Controlador (Cosmin, 2016). .............................................................. 36
Figura 7: Diagrama de Clases de Diseño - Gestionar Productos............................................................ 37
Figura 8: Diagrama de Clases de Diseño - Gestionar Ventas por UEB. ................................................. 38
Figura 9 : Diagrama de Secuencia – Gestionar Productos: Adicionar Producto. ................................... 39
Figura 10: Diagrama de Secuencia –Realizar Ventas por UEB : Adicionar Venta. ................................ 40
Figura 11: Formulario para Adicionar-Modificar un Trabajador. ........................................................... 41
Figura 12: Formulario para Adicionar-Modificar un Trabajador. .......................................................... 42
Figura 13: Diagrama de Componentes- Gestionar Ventas por UEB. ..................................................... 43
Figura 14: Diagrama de Componentes- Gestionar Productos. ............................................................... 43
Figura 15: Diagrama de Despliegue. ...................................................................................................... 44
Figura 16: Pantalla Principal .................................................................................................................. 45
Figura 17: Galería con las características principales de cada producto. ............................................... 45
Figura 18: Reporte que muestra las ventas por UEB. ............................................................................ 46
Figura 19: Reporte que muestra las ventas por monedas. ...................................................................... 47
Figura 20: Formulario de Adicionar/Modificar Trabajador. ................................................................... 48
Figura 21: Resultado de la introducción de valores válidos en el formulario Adicionar Trabajador. .... 49
Figura 22: Resultado de la introducción del valor no valido “280” en el campo CI y dejar el campo
Nombre en blanco. ................................................................................................................................. 50
Figura 23: Resultado de la introducción del valor no valido “%dx” en el campo Nombre. .................. 50
Figura 24: Formulario de Adicionar/Modificar Producto. ..................................................................... 51
Figura 25: Resultado de la introducción de valores válidos en el formulario Adicionar Producto. ....... 52
Figura 26: Resultado de la introducción de dejar campos en blanco en el formulario Adicionar
Producto. ................................................................................................................................................ 53
Figura 27: Prueba de Carga .................................................................................................................... 54
Figura 28: Prueba de Stress .................................................................................................................... 55
Figura 29: Prueba de Resistencia ........................................................................................................... 56
12
Lista de Tablas
Tabla 1: Principales productos en RUP (Martínez and Martínez, 2014)................................................ 10
Tabla 2: Actores del negocio .................................................................................................................. 17
Tabla 3: Trabajadores del negocio .......................................................................................................... 18
Tabla 4: Actores del Sistema .................................................................................................................. 19
Tabla 5: Requisitos Funcionales ............................................................................................................. 20
Tabla 6: Descripción del caso de Uso Gestionar Producto..................................................................... 21
Tabla 7: Descripción del Caso de Uso Realizar ventas por UEB ........................................................... 25
Tabla 8: Complejidad de los Actores ...................................................................................................... 29
Tabla 9: Complejidad de los CU ............................................................................................................ 29
Tabla 10: Factores de complejidad técnica ............................................................................................. 30
Tabla 11: Factores de ambiente o entorno .............................................................................................. 31
Tabla 12: Esfuerzo total de desarrollo del proyecto ............................................................................... 32
Tabla 13: Clases para la validación del formulario adicionar trabajador. .............................................. 49
Tabla 14: Ejemplo de valores válidos para el formulario Adicionar Trabajador. ................................... 49
Tabla 15: Clases para la validación del formulario adicionar producto. ................................................ 51
Tabla 16: Ejemplo de valores válidos para el formulario Adicionar Producto. ...................................... 52
1
INTRODUCCIÓN
Las Tecnologías de la Información y la Comunicación (TIC) conforman el conjunto de recursos
necesarios para manipular la información: los ordenadores, los programas informáticos y las redes
necesarias para convertirla, almacenarla, administrarla, transmitirla y encontrarla (RAMOS, 2011).
El impacto que ha tenido en el mundo el uso de las TIC desde su surgimiento en el pasado siglo, ha
marcado un trascendental cambio en la sociedad. Esto ha jugado un papel fundamental en la divulgación
de información lo que ha provocado que esté al alcance de casi todas las personas en el mundo en cuestión
de poco tiempo Con el desarrollo de Internet se ha logrado que las personas puedan acceder a la
información desde sus hogares, centros de trabajo o cualquier parte del mundo. Esto unido a la
digitalización de la información facilita el almacenamiento de la misma de una forma rápida, segura y
compacta (ACN, 2016).
Desde hace varios años nuestro país ha comenzado el proceso de informatización de la sociedad. A fines
de 1962 el entonces Ministro de Industria Ernesto Che Guevara creó un grupo que se encargaría de
investigar sobre los adelantos de la computación en el mundo. A raíz de esto, surge el Centro de
Investigaciones Digitales (CIDID), donde se ensamblaron las computadoras CID 201-A y CID 300, las
cuales se utilizaron en los centros de cálculo y universidades. En la actualidad este proceso de
informatización ha ido en aumento a partir de la utilización de Internet en función del desarrollo social,
involucrando así, los niveles sociales e institucionales del país posibilitando el fácil manejo de la
información de los procesos empresariales (Alonso, 2013). Además, se ha introducido paulatinamente el
uso de las TIC para dar ayuda al cumplimiento de las principales tareas de las organizaciones. Muchas
de las actividades que anteriormente eran realizadas de forma manual, ahora se ven apoyadas o
sustituidas por aplicaciones informáticas (ACN, 2016).
Las tecnologías web son unos de los recursos tecnológicos populares de uso frecuente debido a que
permiten una comunicación activa entre el usuario y la información. Esto propicia que el usuario
acceda a los datos de modo interactivo, gracias a que la página responderá a cada una de sus
acciones (Mark Safronov, J.W., 2014). Las aplicaciones web generan dinámicamente una serie
de páginas en formato estándar HTML o XHTML, que los navegadores web comunes soportan.
Además, se utilizan lenguajes interpretados del lado del cliente, tales como r (Contreras
Castañeda, 2016).
2
Generalmente cada página web se envía al cliente como un documento estático, pero la secuencia de
páginas ofrece al usuario una experiencia interactiva (Eguiluz, 2013). Durante la sesión, el navegador
interpreta y permite presentar pantallas e interactuar con los usuarios a través de los mismos navegadores
que utilizan para acceder a sitios de Internet. El acceso se puede realizar desde cualquier computadora y
sistema operativo, solo es necesario una computadora conectada a la red donde se encuentra instalado el
sistema (Villoria, 2009).
La Empresa Industrial Productora de Utensilios Domésticos en su forma abreviada INPUD perteneciente
al Ministerio de la Industria (MINDUS), fue fundada por el Comandante Ernesto “Che” Guevara el 24
de julio de 1964 marcando junto con otras empresas del país el inicio de la industrialización en nuestra
patria. Esto ha sido posible por las profundas transformaciones económicas, políticas y sociales, que se
crearon después del triunfo revolucionario. La empresa posee un colectivo de trabajadores que garantizan
el crecimiento sostenido de la productividad y la calidad de sus producciones. Además, se encuentra
predestinada por un sistema de orientación y satisfacción al cliente, por lo que el objeto social de la
entidad según la Resolución No. 293/2014 de fecha 20 de marzo de 2014, dictada por el Ministerio de
Economía y Planificación es: “Producir y comercializar artículos domésticos y de uso industrial,
herramentales, equipos electrodomésticos y sus accesorios, envases y artículos plásticos, productos
plásticos desechables, material para instalaciones eléctricas, luminarias, piezas fundidas de metales no
ferrosos, producciones especializadas para la infraestructura y la gastronomía del turismo, así como
piezas de repuestos de sus producciones”. Ubicada en la región central del país, en la ciudad de Santa
Clara, provincia de Villa Clara, ocupando alrededor de 268 mil metros cuadrados en toda su extensión y
de estos 64 mil techados, ha presentado un desarrollo ascendente durante todos estos años (Palacio
Manso, 2010).
En la empresa uno de los procesos fundamentales es el control de las ventas, el cual se realiza a través
de dos procedimientos llamados “Ventas” y “Comunicación y Satisfacción del cliente” que involucra el
llenado de los modelos M(P04-1) y M(P04-2). El procedimiento “Ventas” está compuesto por 14
subprocesos el cuál presenta un gran volumen de información (Yanes, 2017).
Teniendo en cuenta lo antes descrito surge la problemática siguiente:
Actualmente la empresa no posee ningún sistema web informativo que sea capaz de monitorear el estado
las ventas. Estas se registran en un documento Excel lo que provoca un retraso en la gestión de la
información y errores en su manipulación, debido a la complejidad de la misma. De igual manera, se
hace difícil el acceso desde las diferentes oficinas del departamento de Comercial a la información lo
cual dificulta la confiabilidad e integridad de los datos. Debido a lo anterior se hace necesario crear un
3
sitio web que permita una mejor organización del trabajo, mayor rapidez y eficiencia en los procesos que
se llevan a cabo y donde los usuarios pueden interactuar fácilmente con la información empresarial, lo
que influye directamente en el cumplimiento de los objetivos de la empresa.
Para dar solución a la problemática anterior se propone como objetivo general:
Desarrollar un sitio web para la gestión de la información y el control de ventas en el INPUD utilizando
el framework Symfony.
A partir del objetivo general descrito anteriormente, se definen los siguientes objetivos específicos:
1. Definir las funcionalidades del sitio web para la gestión de la información y el control de
ventas.
2. Diseñar la base de datos para que permita el control de la información referente a la empresa.
3. Implementar el sitio web incluyendo cada una de las funcionalidades del sistema.
4. Validar el software mediante pruebas de caja negra y de rendimiento garantizando la
confiabilidad de los resultados.
Justificación
En el INPUD se gestiona la información y monitorea el estado de las ventas de manera manual mediante
un documento Excel lo cual dificulta su manejo. En esta investigación se pretende facilitar la
organización y manejo de la información mediante un sitio web que responda a las necesidades de dicha
empresa.
Estructura de Documento:
El trabajo consta de cuatro capítulos estructurados de la siguiente manera:
En el Capítulo 1 se tratan los aspectos más generales relacionados con el proceso de ventas.
Además, se abordan elementos relacionados con el uso de las tecnologías y herramientas
utilizadas en el desarrollo del sistema.
En el Capítulo 2 se abordan aspectos relacionados al modelado del negocio. Se identifican reglas de
negocio, requisitos funcionales y no funcionales, así como la selección de los Casos de Uso del Negocio
(CUN) más significativos.
En el Capítulo 3 se describe la propuesta de diseño del software y su implementación, que da solución
a los objetivos planteados anteriormente. Además, se muestran diferentes vistas como la arquitectura del
sistema, las clases de diseño y el diseño de la base de datos.
4
En el Capítulo 4 se describe la estrategia de pruebas a realizar y se muestran los resultados de las mismas
aplicadas a la herramienta informática desarrollada, con el objetivo de validar sus funcionalidades.
5
Capítulo 1: Fundamentación Teórica
En el presente capítulo se describe el proceso de ventas así como las tecnologías y herramientas
utilizadas en el desarrollo del sistema.
1.1 Objetivos estratégicos de la empresa
El INPUD tiene como misión producir y comercializar artículos domésticos y de uso industrial,
herramentales, equipos electrodomésticos y sus accesorios, envases y artículos plásticos, productos
plásticos desechables, material para instalaciones eléctricas, luminarias, piezas fundidas de metales no
ferrosos, producciones especializadas para la infraestructura, la gastronomía del turismo y servicios
diversos, así como piezas de repuesto de sus producciones. Esta empresa cuenta con la tecnología y un
personal experimentado que les permita alcanzar estándares de calidad aceptados por el mercado.
Además, en dicho centro se trabaja por afianzar su presencia en el hogar cubano a través de su inserción
en los programas dirigidos a mejorar la calidad de vida de la sociedad, mediante ventas a Tiendas
Recaudadoras de Divisas (TRD) y otros sectores del mercado, impulsando la sustitución de
importaciones y aumentando la competitividad en el mercado nacional y para la exportación.
Hoy en día el INPUD es una empresa ampliamente conocida, que se ha ganado un lugar relevante en los
hogares cubanos. Además, es líder en la producción de artículos domésticos y herramientas especiales
en el país (Yanes, 2017).
1.2 Objeto de estudio
La empresa está estructurada en la actualidad por Unidades Estructurales Básicas (UEB) 7 productivas,
6 de Servicio y 3 Áreas de Regulación y Control que rectoran las distintas actividades de gestión de la
Empresa. Las UEB son: Plantas, Aseguramiento Técnico, Progar, Centro Plástico, Electrodoméstico,
Protur, Bancalux, Servicios Industriales, Electromecánica Escambray, Logística, Mantenimiento,
Servicio a Trabajadores, Operativa y Comercial.
El proceso de ventas está compuesto por dos procedimientos fundamentales los cuales son:
Proceso 1 (P1): “Ventas”
Establece como se determinan los requisitos especificados y no especificados por los clientes,
así como, los legales y reglamentarios aplicables.
Implementa las actividades para realizar las ventas.
Proceso 2 (P2): “Comunicación y Satisfacción del cliente”
Establece la comunicación y retroalimentación con el cliente para la evaluación de su satisfacción.
6
1.2.1 Aspectos más significativos sobre el control de ventas.
Para llevar a cabo un control de ventas es necesario establecer la metodología para la realización de las
mismas, la medición de la satisfacción del cliente y la coordinación de estas actividades en la UEB de
comercial.
Revisión del Contrato
Se realizan acciones sistemáticas efectuadas por el proveedor antes de la firma del contrato para
asegurarse de que los requisitos estén definidos adecuadamente y sin ambigüedad. La revisión del
contrato es responsabilidad del proveedor, pero puede efectuarse en forma conjunta con el cliente. Una
revisión del contrato puede ser repetida en diferentes etapas de su cumplimiento, si fuera necesario.
Responsabilidades
1. El Director de la UEB Comercial es responsable de la implantación y mantenimiento del
presente procedimiento.
2. Los Especialistas y técnicos en compras y ventas del comercio interior y otros funcionarios del
Grupo de Ventas son responsables de la ejecución de este procedimiento.
3. El Comité de Contratación de la Empresa aprobará los contratos.
4. Los contratos son elaborados por los especialistas en compras y ventas del comercio interior y
revisados y aprobados por el director de la UEB Comercial después de ser dictaminado por el
Asesor jurídico.
Detalles
La UEB Comercial de acuerdo a las demandas de los clientes presentadas en la reuniones de Captación
de las demandas hechas en el primer trimestre del año y de acuerdo al marco de importación aprobado
por el OSDE y GESIME y por orientaciones del mismo a mediados de año confecciona una base de
datos, donde se establecen los planes anuales y mensuales basados en el crecimiento lógico planificado
establecido por la dirección de la empresa y los pronósticos de ventas elaborados para el año que se
planifica, estos datos se registran en el DT(P04-1)-1 “Base de datos” que contiene como mínimo la
siguiente información:
Tipo de producto por surtido o servicio.
Entidad demandante
Organismo
Plan anual y mensual.
7
Importe en CUC y MN.
Cantidad de producto que se planifica vender según cronograma de entrega.
Entidad (Cliente), Código REEUP.
Unidad de medida.
Cantidad del plan anterior.
Cantidad demandada y aceptada del año en curso.
UEB productora.
Valor de las ventas en MCUC.
Valor de las ventas en moneda total (MT).
Desglose por trimestre del Importe (CUC y MT).
Aceptación del pedido y elaboración de la oferta
Las informaciones sobre los productos son entregadas o mostradas al cliente mediante la presentación
de muestras representativas (Show room), catálogos u otro material publicitario y el documento
“Características Técnicas” (CT) o Ficha técnica del producto donde se dan aquellos parámetros o
requisitos del producto que, al cumplirse, se satisfacen las necesidades de los clientes.
Elaboración del Contrato
Para poder realizar ventas, el cliente debe firmar un contrato con la empresa elaborado según el
procedimiento P01-7 “Contratación Económica” y las Legislaciones vigentes en esta materia, cuyas Pro-
formas de Contrato de Suministro, Compra-Venta o de Servicios y el "Contrato" final DT(P04) a
suscribir deberán ser revisadas por la Asesora Jurídica de la empresa. Las personas facultadas para firmar
contratos serán determinadas por resolución emitida por el Director General. Los detalles para la
contratación de los servicios y de las prestaciones dados por la UEB “Servicios Industriales”.
Para la firma del Contrato, el cliente debe exhibir los siguientes documentos:
Resolución de creación de la empresa.
Resolución de nombramiento del director de la empresa.
Certificado comercial.
Objeto social.
Licencia para operar en divisas.
Numero de inscripción en el registro central comercial.
8
Número de identificación tributaria. NIT.
Ejecución de las ventas
Cuando se ejecuta una venta es porque anteriormente se ha realizado todos los procesos necesarios, se
ha plasmado a través del contrato y existe un compromiso de entrega por parte de la empresa.
La venta se realiza a través del M(P04-1)-2 “Orden de Despacho”. El jefe del almacén, almacenero o
controlador de la calidad reflejarán en la “Orden de despacho” la identificación del lote que se está
vendiendo, para asegurar que el producto haya pasado satisfactoriamente por todas las actividades de
inspecciones y ensayos establecidos en el SGC de la Empresa. Además, esto sirve para garantizar la
trazabilidad del producto en caso de una reclamación o cualquier otro problema surgido.
Retroalimentación del Cliente
En caso de detección de no conformidades, quejas y reclamaciones de los Clientes por insatisfacciones
con la calidad de los productos, incumplimiento de los plazos de entrega, precios acordados, u otras
causas, se procederá según establece el P01-3 “Acciones Correctivas y Preventivas” tratándose
oficialmente la queja mediante el modelo M(P01-3)-1 “Reporte de No Conformidad”. El Cliente debe
presentar la Factura comercial si es Cliente de un organismo o Cadena de tienda; Certificado de Garantía,
Comprobante de venta y Propiedad del equipo que ampara la compra objeto de reclamación, si es un
Cliente particular.
1.2.1 Flujo Actual de Procesos
El proceso productivo comienza con la llegada de la materia y su distribución a cada UEB, donde los
trabajadores son los encargados de confeccionar los productos. Posteriormente en la UEB pasan a un
área de revisión donde se evalúan, verificando que todos los productos se encuentren en perfecto estado.
Para verificar su completo funcionamiento son trasladados a un laboratorio de control de la calidad donde
son evaluados nuevamente. De encontrase en perfecto estado los mismos son enviados al almacén del
taller en caso de existir para después ser llevados al almacén general de la empresa. Por último, se
distribuyen a los diferentes compradores los cuales ya tienen un contrato con la empresa.
1.2.2 Análisis crítico de la ejecución de los procesos
Partiendo del análisis del flujo actual del proceso son detectados los siguientes problemas que pueden
ocurrir:
La realización de estas tares se realizan con Word y Excel que son herramientas que no ofrecen
agilidad en el proceso y esto se hace manual lo cual lo hace un proceso poco práctico y
exhaustivo.
9
La incorrecta escritura de algunos campos en las ventas realizadas.
No tener los datos en un sistema para su posterior análisis y toma de decisiones.
Debido a las deficiencias, agilidad, seguridad y control de las tareas es que se toma la decisión de elaborar
un software para la gestión de la información y el control de ventas en INPUD.
1.2.3 Procesos objeto de automatización
Los procesos objeto de automatización son el control de ventas de todos los equipos electrodomésticos.
Este proceso es algo complejo debido a que es realizado en un documento Excel conteniendo muchos
datos. Es por ello que se requiere automatizar para una mayor rapidez y eficiencia en este proceso. Así
como gestionar información básica referente a la empresa.
1.3 Tendencias y tecnologías actuales
De generación en generación el hombre ha transmitido la necesidad de expresarse, comunicarse y
conocer todo lo que lo rodea cada vez de formas más novedosas. Las tecnologías de la información y la
comunicación aportan fundamentalmente dos dimensiones en el sistema de comunicación. Por un lado,
modifican en cómo se producen, gestiona, y consumen los contenidos y por otro lado modifican la
manera en cómo se producen, se gestionan y se consumen los procesos de comunicación (González,
2010). La tecnología actual y principalmente la computación, ha contribuido de forma única a la solución
de muchos problemas en diferentes ámbitos y disciplinas, constituyendo hoy en día una fuente de
recursos imprescindibles (Alonso, 2013).
1.3.1 Metodología de desarrollo Proceso Racional Unificado
Para la elaboración de la presente investigación se utilizó la metodología Proceso Racional Unificado
(RUP), ya que constituye la metodología estándar más utilizada para el análisis, diseño, implementación
y documentación de sistemas orientados a objetos (Durango and Academy, 2015). Dicha metodología
emplea para el modelado el lenguaje UML (Durango and Academy, 2015).
Según (Durango and Academy, 2015) como principales características de RUP se pueden destacar
1. Dirigido por casos de uso.
2. Centrado en la arquitectura.
3. Iterativo e Incremental.
RUP para la elaboración del software propone cuatro fases por las que se debe transitar: inicio,
elaboración, construcción y transición (Martínez and Martínez, 2014):
10
En la Tabla 1 se muestra un resumen con los productos que se deben elaborar en cada fase de desarrollo
de un proyecto.
Tabla 1: Principales productos en RUP (Martínez and Martínez, 2014).
Flujo Productos Inicio Elaboración Construcción Transición
Administración
del Proyecto
Plan de desarrollo I R R R
Caso de negocio I
Lista de riesgos I R R R
Requisitos Modelo de casos de uso I R
Visión I R
Especificación adicional I R
Glosario I R
Análisis y Diseño Modelo de Diseño I R
Documentación de la
arquitectura de SW
I
Implementación Modelo de implementación I R R
Test Plan de test I R
Despliegue Plan de despliegue I
Nota: I=Inicio, R=Refinamiento
1.3.2 Software libre
El software libre ofrece la oportunidad de acceder al código fuente y esa es una perspectiva muy
alentadora para nuestro país en general y para nuestra especialidad en particular. Es un tipo particular de
software que le permite al usuario el ejercicio de cuatro libertades básicas (Stallman et al., 2007):
Libertad 0: Libertad de ejecutar y usar el software para cualquier propósito.
Libertad 1: Libertad de estudiar el programa y adaptarlo a sus necesidades.
Libertad 2: Libertad de distribuir copias.
Libertad 3: Libertad de modificar el programa y liberar las modificaciones al público.
11
Para el ejercicio de estas libertades, en especial la 1 y la 3, el usuario necesita disponer del código
fuente del programa. Por lo tanto, será imprescindible que las licencias de software libre contengan,
efectivamente, el compromiso del titular-autor de proporcionar el código fuente a los usuarios; o, al
menos, ponerlo a su disposición. Desde hace muchos años y con el objetivo de proteger la propiedad
intelectual se han empleado diferentes licencias que establecen las reglas bajo las cuales se usa un
software (Davila, 2011). Las licencias de software libre, ponen a disposición de los usuarios el código
fuente del programa permitiéndoles libertad para: ejecutarlo, copiarlo, distribuirlo, estudiarlo y
modificarlo. Aunque esta idea permite unificar la concepción general de las licencias de software
libre, en el año 1998 hubo una separación conceptual en el movimiento. Esta división se formalizó
con la creación de la iniciativa de código fuente abierto (Open Source Initiative, OSI) que estableció
la definición de software de código fuente abierto (Open Source Definition, OSD) (Cuervo, 2005).
1.3.3 Aplicaciones Web
Las tecnologías web poseen una significación preponderante por el papel que está jugando la Internet en
el mundo moderno. Esta plataforma WWW (World Wide Web) ha ido evolucionando paulatinamente
para convertirse en un ambiente donde se implementan potentes aplicaciones cliente/servidor o
arquitecturas de n capas, unido a ello han ido surgiendo nuevas tecnologías que se relacionan con el
desarrollo Web lo que hacen a éste más interactivo e interesante (Villoria, 2009). Las aplicaciones web
se basan en el modelo cliente-servidor (Miguel, 2015) y generalmente está estructurada como una
aplicación de tres-capas. En su forma más común, el navegador web ofrece la primera capa, interpretando
el código. El servidor que ofrece este código y toda la información es la segunda capa. Por último, una
base de datos constituye la tercera y última capa. El navegador web manda peticiones a la capa
intermedia, la cual ofrece servicios valiéndose de consultas y actualizaciones a la base de datos, y, a su
vez, proporciona una interfaz de usuario (Mora, 2001).
1.3.4 HTML y CCS
HTML (siglas de HyperText Markup Language (lenguaje de marcas de hipertexto)), hace referencia al
lenguaje de marcado para la elaboración de páginas web (Gauchat, 2012b). Es un estándar que sirve de
referencia para la elaboración de páginas web en sus diferentes versiones y define una estructura básica
y un código, denominado código HTML, para la definición de contenido de una página web, como texto,
imágenes, videos, entre otros. Al ser un estándar, HTML busca ser un lenguaje que permita que cualquier
página web escrita en una determinada versión, pueda ser interpretada de la misma forma por cualquier
navegador web actualizado. Está a cargo de la W3C, organización dedicada a la estandarización de casi
12
todas las tecnologías ligadas a la web, sobre todo en lo referente a su escritura e interpretación (Mir
Huguet, 2012).
Por otra parte, CSS es un lenguaje que trabaja junto con HTML para proveer estilos visuales a los
elementos del documento, como tamaño, color, fondo, bordes, etc. Cuenta con una sintaxis muy sencilla,
que usa unas cuantas palabras claves para especificar los nombres de varias propiedades de estilo
(Eguíluz Pérez, 2008).
Según (Eguíluz Pérez, 2009) existen tres formas para dar formato a un documento HTML utilizando
CSS:
Estilos en línea.
Estilos embebidos.
Archivos externos.
1.3.5 JavaScript
JavaScript es un lenguaje de programación que se utiliza principalmente para crear páginas web
dinámicas (Gauchat, 2012a). Una página web dinámica es aquella que incorpora efectos como texto que
aparece y desaparece, animaciones, acciones que se activan al pulsar botones y ventanas con mensajes
de aviso al usuario. Técnicamente, JavaScript es un lenguaje de programación interpretado, por lo que
no es necesario compilar el código para ejecutarlo. Además, los programas escritos con JavaScript se
pueden ejecutar directamente en cualquier navegador sin necesidad de procesos intermedios. A pesar de
su nombre, JavaScript no guarda ninguna relación directa con el lenguaje de programación Java (Maza,
2012).
1.3.6 Bibliotecas Boostrap y JQuery
En la actualidad existen un gran número de bibliotecas que facilitan el desarrollo de aplicaciones web.
En la presente investigación se utilizan Boostrap y JQuery, ya que son dos de los más utilizadas en el
mercado gracias a la robustez, calidad y eficiencia brindada a las aplicaciones en que se emplean
(Spurlock, 2013).
1.3.6.1 Boostrap
Bootstrap, es un framework originalmente creado por Twitter (BlogUneWeb, 2016), 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
13
Design o Diseño Adaptativo. Se basa en la simplicidad de sus interfaces, lo cual es una tendencia del
mercado, en las que tiende a diseño plano, botones grandes (BlogUneWeb, 2016).
1.3.6.2 JQuery
Esta es la biblioteca web más popular disponible en los últimos años (Duckett et al., 2014). La biblioteca
jQuery es gratuita y fue diseñada para simplificar la creación de sitios web modernos. Provee una API
sencilla que cualquiera puede aprender y rápidamente aplicar a sus proyectos. Además, facilita la
selección de elementos HTML, la creación de animaciones y efectos, controla eventos y ayuda a
implementar Ajax en las aplicaciones (Castillo, 2017). Esta biblioteca tiene la ventaja de proveer soporte
para viejos navegadores y vuelve simple tareas cotidianas. Puede ser utilizada junto con HTML5 o como
una forma simple de reemplazar funciones de HTML5 en navegadores que no están preparados para esta
tecnología (Castillo, 2017) .
La biblioteca jQuery se encuentra en un archivo pequeño que se puede descargar desde su sitio oficial1
y luego incluir en nuestros documentos usando la etiqueta <script>. Una vez que el archivo provisto por
jQuery es incluido en nuestro documento, se pueden aprovechar los métodos simples incorporados por
la biblioteca y convertir la web estática en una moderna y práctica aplicación (Duckett et al., 2014).
1.3.7 Lenguaje de Programación PHP
PHP es un lenguaje de secuencia de comandos de servidor diseñado específicamente para la Web. Es
un producto de código abierto, por lo que se puede acceder a su código fuente, el cuál puede utilizarse,
modificarse y redistribuirse sin coste alguno. Las siglas PHP equivalían inicialmente a Personal Home
Page (Página de inicio personal) pero se modificaron de acuerdo con la convención de designación
de GNU (del inglés, Gnu's Not Unix, Gnu no es Unix) y ahora equivale a PHP Hipertext Preprocessor
(Preprocesador de hipertexto PHP) (Welling and Thomson, 2005).
Dentro de sus principales características se encuentran que posee bibliotecas de código que permiten
realizar conexiones a servidores de bases de datos como: MySQL, PostgresSQL, Oracle, MS SQL
Server, Sybase, mSQL e Informix (Janev et al., 2015).
1 Sitio Oficial disponible en www.jquery.com
14
Framework de Desarrollo
Un framework PHP hace el desarrollo más rápido. Una de las razones es que no es necesario escribir
consultas complejas para recuperar datos desde una base de datos. Los frameworks PHP proveen
operaciones CRUD (Create, Read, Update, and Delete, o que se traduce como Crear, Leer, Actualizar,
Eliminar)(Mark Safronov, 2014).
Los frameworks permiten a los desarrolladores escalar los sistemas fácilmente.
El mantenimiento del código es más fácil que con PHP puro. El código de la aplicación es más
concisa y fácil de trabajar.
El Modelo Vista Controlador (MVC) asegura un rápido desarrollo.
Los frameworks son mejores en asegurar la aplicación web de amenazas de seguridad
comunes.
El principio de no repetirse a sí mismo (don't repeat yourself (DRY)) asegura que el mínimo
código tenga el máximo impacto (Mark Safronov, 2014).
Entre los framework PHP más populares se encuentran Symfony, Yii y Laravel (López, 2016). Entre los
framework anteriores se escoge Symfony ya que es un framework diseñado para optimizar el desarrollo
de las aplicaciones web basado en el patrón MVC (López, 2016). Además, separa la lógica de negocio,
la lógica de servidor y la presentación de la aplicación web. Este framework proporciona varias
herramientas y clases encaminadas a reducir el tiempo de desarrollo de una aplicación web compleja.
También, automatiza las tareas más comunes, permitiendo al desarrollador dedicarse por completo a los
aspectos específicos de cada aplicación. El resultado de todas estas ventajas es que no se debe reinventar
la rueda cada vez que se crea una nueva aplicación web (Eguíluz Pérez, 2013) .
1.3.8 Sistema Gestor de Base de Datos PostgresSQL
PostgreSQL es un sistema de gestión de bases de datos relacional, orientado a objetos y libre, publicado
bajo la licencia PostgreSQL (Tezer, 2014). Posee un conjunto muy amplio de características que le
otorgan gran flexibilidad y permiten "afinar" el modelo de datos a determinadas necesidades.
PostgresSQL ofrece una potencia adicional al incorporar los siguientes conceptos básicos para que los
usuarios pueden extender fácilmente el sistema: clases, herencias, tipos y funciones (Krosing and
Mlodgenski, 2013). Además, cuentan con otras características que aportan potencia y flexibilidad
adicional como restricciones (Constraints), disparadores (triggers), reglas (rules) y la Integridad
transaccional (Krosing and Mlodgenski, 2013).
15
1.4 Conclusiones parciales
En este capítulo se describieron los principales elementos del proceso de ventas, destacándose como un
importante aspecto a controlar, las ventas que realizan las UEB. Además, se describieron algunas
tecnologías y herramientas que existen para el desarrollo de aplicaciones web. Como resultado se decidió
utilizar RUP como metodología de desarrollo, HTML5, CSS3, JavaScript y la biblioteca Boostrap
tecnologías del lado del cliente. PHP como lenguaje de programación del lado del servidor, PostgresSQL
como gestor de base de datos y Symfony3 como framework de desarrollo.
16
Capítulo 2: Modelo del Negocio y Requisitos
En este capítulo se abordan aspectos relacionados al modelado del negocio incluyendo la descripción de
actores del negocio. Se definen los requisitos funcionales y no funcionales con el objetivo de lograr que
la aplicación sea confiable y fácil de manipular. Además, se identifican los actores que intervienen en el
sistema y se modela el diagrama de casos de uso, así como su descripción para una mayor comprensión
de las funcionalidades del sistema.
2.1 Modelo del negocio actual
En la Figura 1 se muestran los procesos fundamentales en el análisis del negocio.
Figura 1: Modelo del Negocio Actual2.
2.2 Reglas del negocio a considerar
Las reglas del negocio describen las características del dominio en el que se encuadra la organización,
pueden ser requisitos funcionales, restringir los existentes o definir cálculos particulares. Si las reglas
del negocio no se satisfacen, el sistema puede no trabajar de forma satisfactoria (Laguna, 2008).
A continuación, se describen dos reglas del negocio correspondientes al negocio actual:
RN1: Verificar rol del usuario
2 Manual de Calidad del INPUD (2017). Aprobado por Ing. Marisel Montero Lago.
17
Primeramente, para autenticarse en el sistema debe introducir su nombre de usuario y contraseña para
verificar que se encuentra registrado en la base de datos de la empresa, de pertenecer a la misma puede
realizar diferentes operaciones sino solo podrá realizar la operación de listar:
1. WHEN introduce su nombre de usuario y contraseña
2. IF está registrado en la base de datos con el rol Administrador,
Especialista en Ventas o Especialista en Producción
3. THEN realiza las operaciones
4. ELSE no puede ver las operaciones
RN2: Verificar la cantidad
Después de estar autenticado en el sistema si desea realizar una distribución de uno o varios productos
no podrá distribuir más de lo que se tiene almacenado en el almacén:
1. WHEN Está autenticado en el sistema y desea realizar una
distribución:
2. IF distribuye menos o la cantidad almacenada
3. THEN se realiza la venta
4. ELSE no puede distribuir esa cantidad a su cliente
2.3 Actores del negocio
Un actor del negocio es cualquier individuo, grupo, entidad, organización, máquina o sistema de
información externo; con los que el negocio interactúa (Jacobson et al., 2013). En la Tabla 2 se observan
los actores del negocio actual.
Tabla 2: Actores del negocio
Actor del Negocio Descripción
Trabajador en Producción Es el responsable de confeccionar los productos.
Trabajador en Ventas Es el responsable de gestionar la información referente a los
procesos de ventas.
2.4 Diagrama de casos de uso del negocio
Los diagramas de casos de uso del negocio constituyen una representación gráfica de un conjunto de
elementos tales como actores y casos de uso, así como las relaciones y dependencias que se establecen
18
entre ellos (Arias et al., 2016). En la Figura 2 se observa el diagrama de Casos de Uso que identifica al
negocio:
Figura 2: Diagrama de Casos de Uso del Negocio.
2.5 Trabajadores del Negocio
Los trabajadores del negocio representan un rol que juega una persona (o grupo de personas), una
máquina o un sistema automatizado; actuando en el negocio. Son los que realizan las actividades,
interactuando con otros trabajadores del negocio y manipulando entidades (Durango and Academy,
2015). En la Tabla 3 se observa los trabajadores del negocio actual.
Tabla 3: Trabajadores del negocio
Trabajador del Negocio Descripción
Especialista en ventas
Es el encargado de llevar a cabo todo el proceso de ventas de los
productos de la empresa entre otras funcionalidades.
Especialista en producción
Es el encargado de llevar a cabo todo el proceso de producción de
los productos de la empresa.
2.6 Actores del sistema a automatizar
Se le llama actor a toda entidad externa al sistema que guarda una relación con éste y que le demanda
una funcionalidad (Cuervo, 2005). En la Tabla 4 se observa los actores del negocio actual.
19
Tabla 4: Actores del Sistema
Actor del Sistema Descripción
Especialista en ventas
Es quien procesa los datos necesarios para realizar todas las
distribuciones de la empresa.
Administrador Es quien procesa toda la información de la empresa como los
trabajadores, las noticias etc…
Especialista en producción Es quien procesa los datos necesarios para realizar los productos
de la empresa.
2.7 Diagrama de Casos de Uso del Sistema
Un caso de uso describe una interacción entre el sistema y un agente externo que se denomina actor, un
caso de uso capta siempre una función visible para el usuario, logra un objetivo concreto y específico
para el usuario y puede ser algo simple o algo complejo, en este caso se puede formular en función de
otros casos de uso (Drake, 2008 ).
Los casos de uso del sistema son los siguientes:
CU1: Gestionar Noticias.
CU2: Consultar datos de la empresa.
CU3: Gestionar Trabajador.
CU4: Gestionar Productos.
CU5: Gestionar Clientes.
CU6: Gestionar Parte Diario.
CU7: Realizar ventas por taller.
CU8: Realizar ventas en dos monedas.
CU9: Realizar ventas por Organismo.
CU10: Realizar ventas por Productos.
En la Figura 3
20
Figura 3: Diagrama de Casos de Uso del Sistema.
2.8 Requisitos funcionales
Son declaraciones de los servicios que proveerá el sistema, de la manera en que este reaccionará a
entradas particulares y de cómo se comportará en situaciones particulares. Los requisitos funcionales de
un sistema describen la funcionalidad o los servicios que se espera que este proveerá (Braude, 2003). En
la Tabla 5 se muestran la definición de los mismos.
Tabla 5: Requisitos Funcionales
Casos de uso Listar Adicionar Eliminar Modificar Consultas
1. Gestionar Noticias. X X X
2.Consultar datos de la empresa.
-Gestionar Miembros X X X X
-Gestionar Medios X X X X
3.Gestionar Trabajador. X X X X
4.Gestionar Productos. X X X X
5.Gestionar Clientes. X X X X
6.Gestionar Parte Diario. X X X X
7.Realizar ventas por UEB. X X X X
8.Realizar ventas por Organismo. X
9.Realizar ventas por Monedas. X
21
10.Realizar ventas por Productos. X
2.9 Requisitos no funcionales
Los requerimientos no funcionales especifican propiedades del sistema, como pueden ser la seguridad y
la fiabilidad del mismo. Estos requerimientos no solo hacen referencia al sistema que se va a desarrollar,
también consideran algunas restricciones, es decir, se encargan de definir aspectos como, por ejemplo,
que estándares de calidad se deben seguir en el desarrollo del sistema (Palomo and Gil, 2014).
A continuación, se muestra la definición de los mismos.
“Requisitos de Software”:
RNF1: Para poder utilizar la aplicación debe tenerse un servidor Apache, como gestor de bases de datos
PostgreSQL y un navegador.
RNF2: Se tiene que contar con el gestor de bases de datos PostgreSQL.
“Requisitos de portabilidad”:
RFN3: El sistema debe poder ejecutarse en cualquier sistema operativo XP o superior.
“Requisitos de Interfaz”:
RNF4: La interfaz contará con botones y menús desplegables que faciliten su utilización. Esta debe ser
simple de usar por los usuarios.
“Ayuda y documentación”:
RNF5: La aplicación debe proporcionar la ayuda al usuario para comprender fácilmente su modo de uso.
2.10 Descripción de los casos de uso
Un caso de uso es un comportamiento del sistema que produce un resultado de interés para algún actor.
Los casos de uso describen cosas que los actores quieren que el sistema haga. Un caso de uso debe ser
una tarea completa desde el punto de vista del actor, y debe corresponder a una tarea que se realiza en
un tiempo relativamente breve, especialmente si debe ser realizado por múltiples actores (Pantaleo and
Rinaudo, 2015).
Caso de Uso “Gestionar Productos”: El especialista en producción gestiona los nuevos productos
donde su información será modificada de ser necesario y eliminada del almacén al ser distribuidos a los
clientes.
En la Tabla 6 se muestra la descripción de los Casos de Uso del Sistema más significativos.
Tabla 6: Descripción del caso de Uso Gestionar Producto
22
Caso de uso del sistema Gestionar Productos
Actores Especialista en Producción
Propósito Gestionar toda la información relacionada con los productos:
insertar, eliminar o modificar una producción.
Resumen Una vez que el usuario haya introducido correctamente sus datos
selecciona la opción gestionar productos donde le muestra una
nueva página con todos los productos en la que puede insertar,
eliminar, modificar un producto.
Responsabilidades Tiene como responsabilidad realizar la acción que desee el usuario
ya sea insertar, eliminar, modificar un producto.
Casos de uso asociados ……….
Requisitos especiales Usabilidad
Acceso limitado: solo las personas autorizadas pueden acceder a
realizar esta funcionalidad.
Rendimiento:
Tiempo de respuesta de una transacción de información: El tiempo
de respuesta luego de una inserción de un proceso no debe exceder
los cinco segundos
Precondiciones El usuario debe ser técnico en producción.
Descripción
23
En la pantalla principal de la aplicación, le muestra al usuario un formulario para introducir su login y
contraseña, al introducir correctamente los datos se muestra una ventana con diferentes opciones donde
debe escoger productos, y ya en una nueva página se muestran las opciones de insertar, eliminar o
modificar. También se muestra una opción en la que el usuario puede informarse de las noticias del día,
puede dirigirse a diferentes enlaces ofrecidos por el sistema, así como obtener información relacionada
con la empresa.
Flujo normal de los eventos. Sección A: Nuevo Producto
Acción del actor Respuesta del sistema
1.Seleccionar Gestionar Productos.
3. Seleccionar el botón Adicionar
5.El especialista en producción llena
los datos y presiona aceptar.
2. El sistema muestra una tabla con todas las producciones que
existen hasta el momento.
4.El sistema muestra una ventana con la información referente para
ser llenada por el usuario.
24
6.El sistema valida y envía los datos a la base datos.
Flujo alternativo1
8. El especialista en producción
verifica que todos los campos estén
llenos.
7. El sistema muestra un mensaje de error donde indica que algún
campo ha quedado vacío.
Flujo alternativo2
10. El especialista en producción
verifica los datos introducidos.
9. El sistema notifica al especialista en producción de algún error
por datos mal introducidos.
Flujo normal de los eventos. Sección B: Editar Producto
Acción del actor Respuesta del sistema
1. El especialista en producción
hace clic en el ícono “Editar”
3.El especialista en producción
edita los campos del producto.
2.El sistema carga el producto y muestra sus datos en una nueva
ventana.
4.El sistema actualiza los datos del producto en la base de datos.
Flujo alternativo 1
6.El especialista en producción
verifica el formato de la fecha
5.El sistema muestra un mensaje de error donde indica que el formato
de la fecha es incorrecto
Flujo alternativo 2
8.El especialista en producción
verifica que los campos estén
llenos
7.El sistema muestra un mensaje de error donde indica que algún
campo ha quedado vacío
Flujo normal de los eventos. Sección C: Eliminar Producto
25
Acción del actor Respuesta del sistema
1. El especialista en producción
hace clic en el ícono “Eliminar”
del producto que quiere eliminar.
2. El sistema elimina los datos del producto
Post condiciones Luego de realizarse el caso de uso, se obtiene como resultado el envío
correcto de la información. El sistema vuelve a la pantalla principal
dándole la opción al usuario de poder realizar otro tipo de proceso o
realizar otra tarea y actualizándose la tabla con la nueva producción.
La base de datos debe quedar actualizada de acuerdo a las operaciones
realizadas en las secciones A, B y C
Caso de Uso “Realizar Ventas por UEB”: El especialista en ventas debe seleccionar
primeramente la UEB, una vez escogido se muestra una tabla con todos los productos
distribuidos de esa UEB (Tabla 7).
Tabla 7: Descripción del Caso de Uso Realizar ventas por UEB
Caso de uso del sistema Realizar Ventas por UEB
Actores Especialista en Ventas
Propósito Distribuir los diferentes productos de la empresa a los clientes.
Resumen Una vez que el usuario haya introducido correctamente sus datos
selecciona la opción ventas y ahí selecciona Ventas por UEB donde le
muestra una nueva página con todas las distribuciones de una UEB
determinada en la que puede seleccionar la UEB y realizar una nueva
venta, modificarla o eliminarla.
Responsabilidades Tiene como responsabilidad realizar la acción que desee el usuario ya
sea insertar, eliminar, modificar un plan.
Casos de uso asociados ……….
Requisitos especiales Usabilidad
Acceso limitado: solo las personas autorizadas pueden acceder a
realizar esta funcionalidad.
Rendimiento:
26
Tiempo de respuesta de una transacción de información: El tiempo de
respuesta luego de una inserción de un proceso no debe exceder los
cinco segundos
Precondiciones El usuario debe ser especialista en ventas.
Descripción
En la pantalla principal de la aplicación, le muestra al usuario en la parte superior derecha una opción
para autenticarse donde debe introducir su login y contraseña, al introducir correctamente los datos se
muestra una ventana con diferentes opciones donde debe escoger ventas y ahí seleccionar Ventas por
UEB, y ya en una nueva página se muestran las opciones de seleccionar una UEB para después insertar
una venta, modificarla o eliminarla, así como listarlas. También se muestra una opción en la que el
usuario puede informarse de las noticias del día, puede dirigirse a diferentes enlaces ofrecidos por el
sistema, así como obtener información relacionada con la empresa.
Flujo normal de los eventos. Sección B: Adicionar Venta
Acción del actor Respuesta del sistema
1.Seleccionar Ventas.
2.Seleccionar Ventas por UEB
27
4.Seleccionar el botón
Adicionar
6. El especialista en ventas
llena los datos y presiona
aceptar.
3. El sistema muestra una tabla donde muestra todos los datos
necesarios para realizar una venta correctamente, así como la UEB que
realizo la venta.
5.El sistema muestra una ventana con la información referente para ser
llenada por el usuario.
7.El sistema valida y envía los datos a la base datos.
Flujo alternativo1
9. El especialista en ventas
verifica que todos los campos
estén llenos.
8. El sistema muestra un mensaje de error donde indica que algún
campo ha quedado vacío.
Flujo alternativo2
11. El especialista en ventas
verifica los datos introducidos.
10. El sistema notifica al especialista en ventas de algún error por datos
mal introducidos.
Flujo normal de los eventos. Sección B: Editar Ventas
Acción del actor Respuesta del sistema
1. El especialista en ventas hace
clic en el ícono “Editar”
3. El especialista en ventas edita
los campos de la venta.
2. El sistema carga la venta y muestra sus datos en una nueva ventana.
4. El sistema actualiza los datos del producto en la base de datos
Flujo alternativo 1
5. El sistema muestra un mensaje de error donde indica que el formato
introducido es incorrecto
28
6. El técnico de producción
verifica el formato
Flujo alternativo 2
8. El especialista en ventas
verifica que los campos estén
llenos
7. El sistema muestra un mensaje de error donde indica que algún
campo ha quedado vacío
Flujo normal de los eventos. Sección C: Eliminar Ventas
Acción del actor Respuesta del sistema
1. El especialista en ventas hace
clic en el ícono “Eliminar” del
plan que quiere eliminar.
2. El sistema elimina los datos del plan
Post condiciones Luego de realizarse el caso de uso, se obtiene como resultado el envío
correcto de la información. El sistema vuelve a la pantalla principal
dándole la opción al usuario de poder realizar otro tipo de proceso o
realizar otra tarea y actualizándose la tabla con la nueva venta. La base
de datos debe quedar actualizada de acuerdo a las operaciones
realizadas en las secciones A, B y C
2.11 Planificación de estimación
Puntos de caso de uso es un método de estimación de esfuerzo para proyectos de software, a partir de
sus casos de uso. El método utiliza los actores y casos de uso para calcular el esfuerzo que significará
desarrollarlos. A los casos de uso se les asigna una complejidad basada en transacciones, entendidas
como una interacción entre el usuario y el sistema, mientras que a los actores se les asigna una
complejidad basada en su tipo, es decir, si son interfaces con usuarios u otros sistemas. También se
utilizan factores de entorno y de complejidad técnica para ajustar el resultado (Pantaleo and Rinaudo,
2015).
Estimación por Puntos de casos de uso
El tiempo laborable son 8 horas de trabajo, de lunes a viernes y el factor de conversión CF de 10 horas-
hombre:
29
2.11.1 Clasificación de los actores
Este valor se calcula mediante un análisis de la cantidad de Actores presentes en el sistema y la
complejidad de cada uno de ellos. La complejidad de los Actores se establece según se indica en la
siguiente tabla:
Tabla 8: Complejidad de los Actores
Tipo de Actor Descripción Factor de Peso Número de Actores
Simple Otro sistema que interactúa con el sistema
a desarrollar mediante una interfaz de
aplicación.
1 0
Medio Otro sistema que interactúa con el sistema
a desarrollar mediante un protocolo o una
interfaz basada en texto.
2 0
Complejo Una persona que interactúa con el sistema
a desarrollar mediante una interfaz
gráfica.
3 11
Se tienen 3 actores de tipo complejo con un peso de 3.
UAW=3*3=9
Dónde: UAW-Factor de Peso de los Actores sin ajustar.
2.11.2 Clasificación de los casos de uso
Este valor se calcula mediante un análisis de la cantidad de CU presentes en el sistema y la complejidad
de cada uno de ellos. La complejidad de los CU se establece teniendo en cuenta la cantidad de
transacciones efectuadas en el mismo según muestra la Tabla 9:
Tabla 9: Complejidad de los CU
Tipo de CU Descripción Factor de Peso
Simple El CU contiene de 1 a 3 transacciones. 5
Medio El CU contiene de 4 a 7 transacciones. 10
Complejo El CU contiene 8 o más transacciones. 15
Se tienen 34 casos de uso de tipo simple con un peso de 5
UUCW=34*5=170
Dónde: UUCW-Factor de Peso de los Casos de Uso sin ajustar.
30
2.11.3 Calcular puntos de casos de uso sin ajustar
UUCP=UAW+UUCW
UUCP=9+170=179
Dónde: UUCP-Puntos de Casos de Uso sin ajustar.
2.11.4 Determinar los factores de complejidad técnica
Este coeficiente se calcula mediante la cuantificación de un conjunto de 13 factores que determinan la
complejidad de los módulos del sistema. Cada uno de los factores se cuantifica con un valor de 0 a 5,
donde 0 significa un aporte irrelevante y 5 un aporte muy importante.
Tabla 10: Factores de complejidad técnica
Factor Descripción Peso Influencia Resultado
F1 Sistema distribuido 2 0 0
F2 Tiempo de respuesta y desempeño 1 1 1
F3 Eficiencia respecto al usuario final 1 2 2
F4 Procesamiento interno complejo 1 1 1
F5 Código reutilizable en otras aplicaciones 1 1 1
F6 Facilidad en la instalación 0,5 2 1
F7 Usabilidad (Fácil de usar) 0,5 1 0.5
F8 Portabilidad 2 0 0
F9 Facilidad en mantener 1 1 1
F10 Accesos simultáneos (concurrentes) 1 1 1
F11 Incluye objetivos especiales de seguridad 0.5 1 0.5
F12 Provee acceso directo a terceros 1 0 0
F13 Se requiere facilidades especiales de
entrenamiento a usuarios
1 1 1
TCF=0.6+0.01*∑ (Pesoi+Valor Asignadoi)
TCF=0.6+0.01*10
31
TCF=0.7
Dónde: TCF-Factor de complejidad técnica
2.11.5 Determinar los factores de ambiente o entorno
Los factores sobre los cuales se realiza la evaluación son 8 puntos, los que están relacionados con los
conocimientos y habilidades del grupo de persona que se encuentran en el proyecto, lo que produce un
gran impacto en las estimaciones de tiempo.
Tabla 11: Factores de ambiente o entorno Factor Descripción Peso Influencia Resultado
E1 Familiarizado con el proceso de
desarrollo (RUP)
1 3 3
E2 Experiencia en la aplicación 1 4 4
E3 Experiencia en orientación a objetos 1 3 3
E4 Capacidades de análisis 1 4 4
E5 Motivación 1 5 5
E6 Requisitos estables 1 5 5
E7 Trabajadores a tiempo parcial 1 0 0
E8 Lenguaje complejo 1 4 4
EF=1.4-0.03*∑ (Pesoi+Valor Asignadoi)
EF=1.4-0.03*28
EF=0.56
Dónde: EF-Factor de Ambiente
2.11.6 Calcular los puntos de casos de uso ajustados
Para el cálculo de los Casos de Uso ajustado se utilizan las siglas UCP y se obtiene al multiplicar el
UUCP el TCF y el EF quedando de la siguiente forma:
UCP=UUCP*TCF*EF
UCP=179*0.7*0.56
UCP=70.16
32
Dónde: UCP- Puntos de Casos de Uso ajustado
2.11.7 Calcular el esfuerzo
Este cálculo se realiza con el fin de tener una aproximación del esfuerzo, pensando solo en el desarrollo
según las funcionalidades de los Casos de Uso. Para el cálculo del mismo se utiliza la siguiente ecuación:
E=UCP*CF
E=70.1*10
E=701 h/h
Dónde: E- Esfuerzo estimado en horas-hombre
2.11.8 Estimación del esfuerzo del proyecto
En la Tabla 12 se destaca la distribución en porcentaje del esfuerzo total de
desarrollo del proyecto:
Tabla 12: Esfuerzo total de desarrollo del proyecto
Actividad Porcentaje
Análisis 10 %
Diseño 20 %
Implementación 50 %
Pruebas 10 %
Sobrecarga (otras actividades) 10 %
2.11.9 Cálculo del esfuerzo total
Etotal=∑ actividades
Etotal=701 horas/hombres
X = 701*100/70
X = 1000
El esfuerzo total es de 1000 h/hombres
Dónde: ETotal: esfuerzo total 2.11.10 Cálculo del tiempo de desarrollo
TDesarrollo=ETotal/CHTotal/CHTrabajo
TDesarrollo=1000 /1/8*5
33
TDesarrollo= 25 semanas
El tiempo de duración es de aproximadamente 25 semanas con una sola persona en el proyecto.
Dónde:
TDesarrollo: tiempo de desarrollo total en semanas
CHTotal: cantidad total de hombres
CHTrabajo: cantidad de horas de trabajo diario
2.11.11 Cálculo del costo
Se ha tomado como referencia el salario por hora del ingeniero informático de la empresa 3.65
pesos por hora.
CostoTotal=ETotal*CHTotal
CostoTotal= 1000 * 3.65
CostoTotal= 3650
El costo del proyecto es de aproximadamente 3650 pesos.
2.12 Conclusiones Parciales
A partir del análisis del negocio y del proceso de ventas en la empresa INPUD se definieron las
funcionalidades de la aplicación web para la gestión de las mismas. Como parte de estas funcionalidades
se identificaron los casos de usos, actores del negocio y sistema y los requisitos funcionales y
no funcionales. Además, se describieron dos casos de uso del sistema.
34
Capítulo 3: Descripción de la propuesta de solución
En este capítulo se presenta el diseño de la base de datos y se describe la arquitectura del sistema.
Además, se definen los diagramas de clases de diseño y secuencia de los casos de uso significativos
representados en el diagrama de despliegue con los principales componentes del sistema.
3.1 Diseño de la base de datos
El diseño de una base de datos es un proceso complejo que abarca decisiones a distintos niveles. La
complejidad se controla mejor si se descompone el problema en varios problemas y se resuelve cada uno
de estos problemas independientemente, utilizando técnicas específicas. Así, el diseño de una base de
datos se descompone en diseño conceptual, diseño lógico y diseño físico (Paré et al., 2013).
3.1.1 Modelo conceptual de datos
En el diseño conceptual se hace una descripción de alto nivel de la estructura de la base de datos,
independientemente del SGBD (Sistema Gestor de Bases de Datos) que se vaya a utilizar para
manipularla. Su objetivo es describir el contenido de información de la base de datos y no las estructuras
de almacenamiento que se necesitarán para manejar dicha información .Se utiliza para la abstracción de
la base de datos, para construir una descripción para entender en la realidad (Navathe_Elmasri, 2013).
A continuación, la Figura 4 muestra el modelo conceptual de los datos:
35
Figura 4: Modelo conceptual de datos.
3.1.2 Modelo físico de datos
Es una descripción de la implementación de una base de datos en memoria secundaria: las estructuras de
almacenamiento y los métodos utilizados para tener un acceso eficiente a los datos. Por ello, el diseño
físico depende del SGBD concreto y el esquema físico se expresa mediante su lenguaje de definición de
datos(Marqués Andrés, 2011). En la Figura 5 se muestra el modelo físico de los datos:
Figura 5: Modelo físico de datos.
3.2 Arquitectura del sistema
La arquitectura del software es el diseño de más alto nivel de la estructura de un sistema, consiste en un
conjunto de patrones y abstracciones coherentes que proporcionan el marco. Se selecciona y diseña con
base en objetivos (requerimientos) y restricciones definiendo de manera abstracta los componentes que
llevan a cabo alguna tarea, sus interfaces y la comunicación entre ellos (Sierra et al., 2017).
La arquitectura utilizada para la implementación de la aplicación es el patrón MVC ya que es un patrón
de arquitectura del software que separa la lógica de negocio de la interfaz de usuario, facilita la evolución
por separado de ambos aspectos e incrementa reutilización y flexibilidad, permitiendo un vínculo
organizado entre las vistas y los modelos a través del controlador. Logrando organización y calidad en
el sistema (Eguíluz Pérez, 2013).
Según (Martínez and Martínez, 2014) el patrón de diseño MVC es una propuesta de diseño de software
utilizada para implementar sistemas donde se requiere el uso de interfaces de usuario (Figura 6). Surge
de la necesidad de crear software más robusto con un ciclo de vida más adecuado, donde se potencie la
facilidad de mantenimiento, reutilización del código y la separación de conceptos. Su fundamento es la
36
separación del código en tres capas diferentes, acotadas por su responsabilidad, en lo que se llaman
Modelos, Vistas y Controladores.
Modelo: Representa la información con la que trabaja la aplicación, es decir, su lógica de negocio.
Vista: La vista transforma el modelo en una página web que permite al usuario interactuar con ella.
Controlador: El controlador se encarga de procesar las interacciones del usuario y realiza los cambios
apropiados en el modelo o en la vista.
Figura 6 : Patrón Modelo-Vista-Controlador (Cosmin, 2016).
Según (Sierra et al., 2017) cuando el usuario solicita ver la portada del sitio, internamente sucede lo
siguiente :
1. El sistema de enrutamiento determina qué Controlador está asociado con la página de la portada
entonces Symfony ejecuta el Controlador asociado a la portada.
3. El Controlador solicita al Modelo los datos necesarios. El modelo es una clase PHP especializada en
obtener información, normalmente de una base de datos (en este caso, el modelo está formado por las
entidades de Doctrine).
4. Con los datos devueltos por el Modelo, el Controlador solicita a la Vista que cree una página
mediante una plantilla y que inserte los datos del Modelo.
5. El Controlador entrega al servidor la página creada por la Vista (Sierra et al., 2017).
3.3 Diagrama de clases de diseño
Según (Amo et al., 2005) los diagramas de clases representan las clases que serán utilizadas dentro del
sistema y las relaciones que existen entre ellas. Se utiliza para visualizar las relaciones entre las clases
37
que involucran el sistema, las cuales pueden ser asociativas, de herencia, de uso y de convencimiento.
Un diagrama de clases está compuesto por los siguientes elementos: Clase: atributos, métodos y
visibilidad. Relaciones: Herencia, Composición, Agregación, Asociación y Uso (Pressman, 2010).
En la Figura 7 se puede observar el diagrama de clases para el CU Gestionar Producto. Se observa que
la clase controladora construye (build) la vista del listado de productos, esta vista realiza el enlace (link)
hacia la vista de adicionar/modificar productos, esta vista está compuesta por el formulario de datos el
cuál envía (submit) su información hacia la controladora. Finalmente, la controladora es la encargada de
interactuar con la entidad de la base de datos.
Figura 7: Diagrama de Clases de Diseño - Gestionar Productos.
38
En la Figura 8 se puede observar el diagrama de clases para el CU Realizar Ventas por UEB. Se observa
que la clase controladora construye (build) la vista del listado de ventas por UEB, esta vista realiza el
enlace(link) hacia la vista de adicionar/modificar venta, esta vista está compuesta por el formulario de
datos el cuál envía(submit) su información hacia la controladora. Finalmente, la controladora es la
encargada de interactuar con la entidad de la base de datos.
Figura 8: Diagrama de Clases de Diseño - Gestionar Ventas por UEB.
3.4 Diagrama de secuencia
Un diagrama de secuencia muestra una interacción ordenada según la secuencia temporal de eventos
(Pantaleo and Rinaudo, 2015). En particular, muestra los objetos participantes en la interacción y los
mensajes que intercambian ordenados según su secuencia en el tiempo. El eje vertical representa el
tiempo y en el eje horizontal se colocan los objetos y actores participantes en la interacción, sin un orden
prefijado. Cada objeto o actor tiene una línea vertical y los mensajes se representan mediante flechas
entre los distintos objetos(Sommerville, 2005).
En la Figura 9 se puede observar el diagrama de secuencia para el CU Gestionar Producto-Adicionar
Producto. En este CU el actor Especialista en Producción es quien lo inicia cuando selecciona la opción
Productos en la pantalla principal lo que provoca un enlace (link) hacia la controladora. Luego la
39
controladora construye (build) la vista con el listado de los productos y es ahí donde el actor puede
seleccionar la opción adicionar y con ello un enlace (link) hacia la vista de adicionar/modificar que está
compuesta por el formulario de datos, donde el actor introduce los datos que serán enviados a la
controladora. En la controladora está programado el método para adicionar los datos a la base de datos
finalizando el proceso con su inserción satisfactoria.
Figura 9 : Diagrama de Secuencia – Gestionar Productos: Adicionar Producto.
En la Figura 10 se puede observar el diagrama de secuencia para el CU Realizar Ventas por UEB-
Adicionar Venta. En este CU el actor Especialista en Ventas es quien lo inicia cuando selecciona la
opción Ventas por UEB en la pantalla principal lo que provoca un enlace (link) hacia la controladora.
Luego la controladora construye (build) la vista con el listado de las ventas de una UEB y es ahí donde
el actor puede seleccionar la opción adicionar y con ello un enlace (link) hacia la vista de
adicionar/modificar que está compuesta por el formulario de datos, donde el actor introduce los datos
que serán enviados a la controladora. En la controladora está programado el método para adicionar los
datos a la base de datos finalizando el proceso con su inserción
40
Figura 10: Diagrama de Secuencia –Realizar Ventas por UEB : Adicionar Venta.
3.5 Tratamiento de errores
Se trataron los errores mediante la validación de formularios que se puede realizar en el lado del servidor
y/o en el lado del cliente. La validación en el servidor es obligatoria para no corromper la base de datos
con datos incorrectos. La validación en el lado del cliente es opcional, pero mejora enormemente la
experiencia de usuario. La validación en el lado del cliente debe realizarse de forma manual con
JavaScript mostrando mensajes de alerta cuando el tipo de dato introducido es incorrecto o el campo se
encuentra vacío.
En la
41
Figura 11 se muestra un ejemplo de cómo se realizan las validaciones en los campos para no permitir
datos no válidos. El especialista al introducir los datos puede equivocarse en algunos campos, cuando
esto ocurre se le informa con un mensaje solo el tipo de datos que puede utilizar, de esta se evita que el
especialista adicione datos incorrectos tanto al realizar una inserción como una modificación.
Figura 11: Formulario para Adicionar-Modificar un Trabajador.
En la Figura 12 se muestra un ejemplo de cómo se realiza el chequeo para no permitir campos en blanco.
El especialista al introducir algunos datos se le olvida llenar un campo, cuando esto ocurre se muestra
un mensaje informándole que ese campo es obligatorio, de esta manera se evita que al especialista
adicione información incompleta.
42
Figura 12: Formulario para Adicionar-Modificar un Trabajador.
3.6 Diagrama de componentes
Un componente de software individual es un paquete de software, un servicio web o un módulo que
encapsula un conjunto de funciones relacionadas (o de datos). Todos los procesos del sistema son
colocados en componentes separados de tal manera que todos los datos y funciones dentro de cada
componente estén semánticamente relacionados. Debido a este principio, con frecuencia se dice que los
componentes son modulares y cohesivos (Muñoz et al., 2010).
El diagrama de componente que muestra la Figura 13 demuestra cómo está dividido el caso de uso
Realizar Ventas por UEB, dentro de los componentes físicos están incluidos archivos, cabeceras,
bibliotecas compartidas, módulos y ejecutables o paquetes.
43
Figura 13: Diagrama de Componentes- Gestionar Ventas por UEB.
El diagrama de componente que muestra la Figura 14 demuestra cómo está dividido el caso de uso
Gestionar Producto, dentro de los componentes físicos están incluidos archivos, cabeceras, bibliotecas
compartidas, módulos y ejecutables o paquetes.
Figura 14: Diagrama de Componentes- Gestionar Productos.
44
3.7 Diagrama de despliegue
El diagrama de despliegue es un modelo de objetos que describe la distribución física del sistema en
términos de cómo se distribuye la funcionalidad entre los nodos de cómputo. Se utiliza como entrada
fundamental en las actividades de diseño e implementación debido a que la distribuci6n del sistema tiene
una influencia principal en su diseño (Palomo and Gil, 2014). En la Figura 15 se muestra el diagrama de
despliegue del sistema.
La Figura 15 muestra la distribución del sistema de los distintos nodos que entran en la composición de
la herramienta realizada y el reparto de los programas que se ejecutan sobre estos nodos. El diagrama de
despliegue muestra el ambiente de computación, pero no indica de manera explícita los detalles de la
configuración.
Figura 15: Diagrama de Despliegue.
3.8 Sitio Web para la gestión de la información y el control de ventas
El sitio web para la gestión de la información y el control de ventas en el INPUD cuenta con una interfaz
sencilla e interactiva para el desarrollo de cada una de sus funcionalidades (Figura 16).
45
Figura 16: Pantalla Principal
El sitio web cuenta con una galería en la cual se muestran las características de cada uno de los productos
que venden las UEB (Figura 17).
Figura 17: Galería con las características principales de cada producto.
46
Además, genera varios reportes entre los que se encuentran las ventas por UEB (Figura 18) y por cada
moneda (Figura 19) que facilitan el control y gestión de la información.
Figura 18: Reporte que muestra las ventas por UEB.
En el reporte que se muestra en la Figura 18 se puede mostrar de una UEB determinada toda la
información de sus ventas, mientras que en la Figura 19 se puede seleccionar la UEB y el mes obteniendo
el importe de cada producto.
47
Figura 19: Reporte que muestra las ventas por monedas.
3.9 Conclusiones Parciales
En este capítulo se diseñó la base de datos para el almacenamiento de la información de la empresa y las
ventas. Además, se utilizó el patrón MVC para la arquitectura del sistema y se obtuvo el diseño de
diferentes diagramas utilizando la notación UML para una mejor comprensión de la estructura. También
se describieron dos manejos de errores para garantizar la confiabilidad de los resultados.
48
Capítulo 4: Pruebas de análisis y factibilidad
En este capítulo se describe la estrategia de pruebas a realizar y se muestran los resultados de las mismas
aplicadas a la herramienta informática desarrollada, con el objetivo de validar sus funcionalidades.
4.1 Pruebas de Caja Negra
Las pruebas de caja negra permiten obtener un conjunto de condiciones de entrada que comprueben
completamente todos los requisitos funcionales de un programa. En ellas se ignora la estructura de
control, concentrándose en los requisitos funcionales del sistema y comprobándolos. Muchos autores
consideran que estas pruebas de caja negra permiten encontrar funciones incorrectas o ausentes, errores
de interfaz, errores en estructuras de datos o en accesos a las bases de datos externas, errores de
rendimiento y errores de inicialización y terminación (Pantaleo, 2012). En este trabajo se seleccionan los
casos de uso Gestionar Trabajador y Gestionar Productos para la realización de las Pruebas de Caja
Negra.
Pruebas en el formulario Adicionar Trabajador
En la Figura 20 se muestra el formulario Adicionar Trabajador el cual presenta dos campos para
introducir datos, el carnet de identidad y el nombre del trabajador.
Figura 20: Formulario de Adicionar/Modificar Trabajador.
49
En la
Tabla 13 se muestran las clases válidas e inválidas para el formulario de adicionar trabajador.
Tabla 13: Clases para la validación del formulario adicionar trabajador.
En la Tabla 14 se muestra un ejemplo de valores válidos que se introducen en el formulario de
Adicionar Trabajador.
Tabla 14: Ejemplo de valores válidos para el formulario Adicionar Trabajador.
Condición de entrada Casos de Prueba Clases Salida
CI 95111509138 1,5 Inserción
Satisfactoria Nombre Elianis
En la Figura 21 se muestra el resultado de la introducción de los valores válidos anteriores en el
formulario Adicionar Trabajador.
Figura 21: Resultado de la introducción de valores válidos en el formulario Adicionar Trabajador.
En la Figura 22 se muestra el resultado de introducir el valor “280”, que no es válido para el
campo CI y de dejar el campo Nombre en blanco en el formulario Adicionar Trabajador.
Condición de entrada Tipo Clases válidas Clases inválidas
CI Valor específico 1. Número de 11
dígitos
2. En blanco
3. Mas de 11
4. Menos de 11
Nombre Valor específico 5. Solo letras 6. En blanco
7. Números.
8. Caracteres especiales.
50
Figura 22: Resultado de la introducción del valor no valido “280” en el campo CI y dejar el campo
Nombre en blanco.
En la Figura 23 se muestra el resultado de introducir el valor “%dx”, que no es válido para el
campo Nombre del formulario Adicionar Trabajador.
Figura 23: Resultado de la introducción del valor no valido “%dx” en el campo Nombre.
51
Pruebas en el formulario Adicionar Producto
En la
Figura 24 se muestra el formulario de Adicionar Producto el cuál presenta, entre otros, los campos
nombre, garantía y cantidad del producto para introducir los datos.
Figura 24: Formulario de Adicionar/Modificar Producto.
En la Tabla 15 se muestran las clases válidas e inválidas para el formulario de adicionar producto.
Tabla 15: Clases para la validación del formulario adicionar producto.
Condición de entrada Tipo Clases válidas Clases inválidas
Nombre Valor específico 1. Solo letras 2. En blanco
3. Números.
4. Caracteres
especiales.
Garantía Valor específico 5. Números y
Letras
6. En blanco
7. Caracteres
especiales.
Cantidad Valor específico 8. Números
Naturales
9. En blanco.
10. Letras.
11. Caracteres
especiales.
12. Números
decimales.
52
En la se muestra un ejemplo de valores válidos que se introducen en el formulario de Adicionar
Producto.
Tabla 16 se muestra un ejemplo de valores válidos que se introducen en el formulario de Adicionar
Producto.
Tabla 16: Ejemplo de valores válidos para el formulario Adicionar Producto.
Condición de entrada Casos de Prueba Clases Salida
Nombre Ventilador 1,5,8 Inserción
Satisfactoria
Garantía
Cantidad
2 Meses
30
En la Figura 26 se muestra el resultado de la introducción de los valores válidos anteriores en el
formulario Adicionar Producto.
Figura 25: Resultado de la introducción de valores válidos en el formulario Adicionar Producto.
En la Figura 26 se muestra el resultado de no introducir ningún valor en los campos Nombre y
Garantía en el formulario Adicionar Producto.
53
Figura 26: Resultado de la introducción de dejar campos en blanco en el formulario Adicionar Producto.
4.2 Plan de pruebas de rendimiento
Las pruebas de rendimiento se ejecutan tanto para determinar como responde un sistema ante una cierta
carga, como para validar otros atributos relacionados con la calidad, como pueden ser la escalabilidad,
la fiabilidad o el uso de recursos, entre otros. En estas pruebas se medirán la velocidad de procesamiento
y el tiempo de respuesta del sistema. Según (Peño, 2015) existen distintos tipos de pruebas de
rendimiento.
A continuación se muestran los resultados de tres pruebas realizadas al sistema con la herramienta JMeter
las cuales son Carga, Stress y Resistencia. Se utiliza como banco de trabajo un servidor proxy HTTP
mediante el puerto 8080 tomando como controlador objetivo un plan de pruebas utilizando un grupo de
hilos. Para los parámetros de muestra HTTP se seleccionó un cliente tipo HTTP. Además, se realizaron
en una Laptop con procesador Intel(R)Pentium(R) @2.16GHz, una memoria RAM de 4Gb y sistema
operativo Windwos10 de 64bits.
4.2.1 Prueba de carga
Consiste en la medición del comportamiento del sistema para aumentar la carga del mismo. Esta carga
puede ser el número de usuarios esperado en producción o un número de transacciones durante un tiempo
54
determinado. El resultado de esta prueba nos dará el tiempo de respuesta de todas las transacciones
críticas (Peño, 2015).
En la Figura 27 para montar el grupo de hilos se estiman 10 usuarios con una petición por segundo. Se
puede observar en el resultado de la prueba que en la columna Error el sistema tuvo un resultado total de
0.00% teniendo un tiempo de Rendimiento entre 1.1sec y 5.8min, es decir, no presenta errores en su
funcionamiento y presenta un tiempo rápido de respuesta teniendo en cuenta las características de la
Laptop donde se ejecutó.
Figura 27: Prueba de Carga
4.2.2 Pruebas de stress
En estas pruebas se puede observar dónde se rompe el sistema. Son utilizadas normalmente para someter
a la aplicación al límite de su funcionamiento mediante la ejecución de un número de usuarios muy
superior al esperado o bien median la substracción de recursos. Este "test de stress" tiene como finalidad
determinar la robustez de una aplicación cuando la carga es extrema (Rodríguez, 2014).
En la Figura 28 para montar el grupo de hilos estima un usuario con 10 peticiones por segundo para la
prueba de stress. Se puede observar el resultado de la prueba que en la columna Error el sistema tuvo un
resultado total de 0.00% teniendo un tiempo de Rendimiento entre 1.8sec y 7.5min, es decir no presenta
errores en su funcionamiento y presenta un retraso en el tiempo debido a las peticiones por segundo.
55
Figura 28: Prueba de Stress
4.2.3 Pruebas de resistencia (SOAK)
Se realiza para ver cómo se desempeña el sistema luego de una carga duradera por un período largo de
tiempo. El objetivo principal de este tipo de pruebas es verificar que no existen fugas de memoria o
procesos que pierdan rendimiento tras un cierto periodo de tiempo (Rodríguez, 2014).
En la Figura 29 para montar el grupo de hilos se estiman 10 usuarios con 10 peticiones por segundo para
la prueba de resistencia. Se puede observar el resultado de la prueba que en la columna Error el sistema
tuvo un resultado total de 0.00% teniendo un tiempo de Rendimiento entre 5.1sec y 7.3min, es decir no
presenta errores en su funcionamiento y presenta un retraso en el tiempo debido a la carga del sistema
en usuarios y en peticiones por segundo.
56
Figura 29: Prueba de Resistencia
4.3 Conclusiones parciales
En este capítulo se aplicaron pruebas de caja negra al sistema en los casos de uso Adicionar Trabajador
y Adicionar Producto obteniéndose los resultados esperados para datos válidos e inválidos. Además, se
diseñaron pruebas de rendimiento, de carga y de stress obteniendo en cada una de ellas un error de 0.00%
y un tiempo de respuesta pequeño teniendo en cuenta las características de la Laptop donde se ejecutaron.
57
Conclusiones
Se definieron 11 funcionalidades del sitio web para gestionar la información de las ventas en el
INPUD mediante un sitio web.
Se implementó una base de datos relacional en el SGBD PostgreSQL que permite gestionar toda
la información sobre la empresa y sus ventas.
Se desarrolló una herramienta web utilizando Symfony 3.3 como plataforma de desarrollo,
para realizar de forma ágil e interactiva las funcionalidades del sistema.
Se implementaron pruebas de caja negra en dos de los casos de uso principales obteniendo los
resultados esperados, así como pruebas de rendimiento donde el por ciento de error fue 0.00%
y el tiempo de respuesta fue bueno considerando las características de la Laptop en la cual se
realizaron.
58
Recomendaciones Continuar desarrollando la aplicación con nuevas funcionalidades que permitan satisfacer
nuevas necesidades que pueda tener la empresa como un mayor control en las producciones de
la empresa y productos no conformes.
59
Manual de Usuario Esta aplicación cuenta con una interfaz sencilla e interactiva para el desarrollo de cada una de sus
funcionalidades. La vista inicial se muestra en la siguiente figura:
Pantalla Principal
Para el acceso al sistema se debe utilizar un navegador web y cada trabajador debe hacerlo con sus
credenciales de la empresa. Cada usuario posee un rol en el sistema entre los siguientes.
Actor del Sistema Descripción
Especialistas en ventas
Son los usuarios autorizados para gestionar los clientes, realizar
las ventas por UEB, por Organismo, Por Monedas y por
Productos
Administrador Es el encargado de gestionar las noticias, gestionar los datos de
la empresa, gestionar los trabajadores, gestionar los clientes.
Especialistas en producción Son los usuarios autorizados para gestionar los productos.
Una vez autenticados los usuarios podrán realizar las operaciones autorizadas.
60
Formulario para autenticarse
En la ¡Error! No se encuentra el origen de la referencia. figura se muestra la vista “Acerca de” donde
se reflejan los antecedentes de la empresa así como su misión y su visión:
Acerca de
61
En la siguiente figura se muestra la vista “Ubicación Geográfica” donde se especifica donde se encuentra
ubicada la empresa en la provincia de Villa Clara, así como la UEB ubicada en la provincia de Santis
Spiritus:
Ubicación Geográfica
En la siguiente figura se muestra la vista “Video Inauguración” donde se muestran las palabras
pronunciadas por nuestro comandante en la inauguración del centro:
Video Inauguración
62
En la siguiente figura se muestra la vista “Noticias” donde se les informa a los trabajadores sobre las
noticias del centro:
Noticias
En la siguiente figura se muestra la vista “Galería” donde se muestran todas las producciones del centro:
Galería
63
En la siguiente figura se muestra la vista “Consejo de Dirección” donde se muestran todas dirigentes del
centro:
Consejo de Dirección
64
En la siguiente figura se muestra la vista “-Estructura” donde se muestra como se encuentra estructurada
la empresa a nivel de departamentos:
Estructura
En la siguiente figura se muestra la vista “Medios de Comunicación” donde se muestran los teléfonos
fijos ubicados en los diferentes locales y sus extensiones:
Directorio Telefónico
65
En la siguiente figura se muestra la vista “Productos” donde se muestran todas las producciones del
centro, así como sus detalles:
Gestionar Productos
En la siguiente figura se muestra la vista “UEB” donde se muestran todas las 13 UEB que conforman la
empresa como la cantidad de empleados que tiene cada UEB:
Producciones-UEB
En la siguiente figura se muestra la vista “Información” donde se muestra una descripción de los
productos que fabrica cada UEB:
66
Producciones-Información
En la siguiente figura se muestra la vista “Trabajadores” donde se muestra información de cada
trabajador del centro:
Trabajadores
67
En la siguiente figura se muestra la vista “Clientes” donde se muestran los clientes de la empresa, así
como los organismos a los que estos pertenecen:
Clientes
En la se muestra la vista “Parte Diario” donde se muestran los planes que debe cumplir cada UEB
mensualmente:
68
Ventas-Parte Diario
En la siguiente figura se muestra la vista “Ventas por UEB” donde se muestran las ventas que ha tenido
cada UEB, así como realizar una nueva venta:
Ventas-Ventas por UEB
En la siguiente figura se muestra la vista “Ventas por Organismo” donde se muestran los clientes que
tuvo la empresa en un mes determinado:
69
Ventas-Ventas por Organismo
En la siguiente figura se muestra la vista “Ventas por Monedas” donde se muestran los productos
distribuidos de una UEB determinada en un mes específico:
Ventas-Ventas por Monedas
En la siguiente figura se muestra la vista “Ventas por productos” donde se muestran los clientes que
compraron un producto determinado, así como el importe que proporciona a la empresa:
70
Ventas-Ventas por Producto
En la siguiente figura se muestra la vista “Configuración” donde se muestran los usuarios del sistema:
Configuración
En la siguiente figura se muestra la vista “Perfil de Usuario” donde se muestran los datos de los usuarios
del sistema, así como la opción de cambiar la clave para acceder al sitio:
Perfil de Usuario
71
Cambiar Clave
Para Eliminar cualquier elemento en la tabla que desee solo debe presionar el icono donde se
encuentra el elemento que desea eliminar.
En las siguientes figuras se muestran las vistas para “Adicionar/Modificar” un miembro del consejo de
dirección, un medio de comunicación, un trabajador, un producto, un cliente, una venta y un plan:
72
Miembro del Consejo de Dirección
Medio de Comunicación
Productos
73
Trabajadores
74
Clientes
Plan Diario
75
Ventas por UEB
Configuración
76
Referencias bibliográficas ACN. 2016. Cuba avanza en la informatización de la sociedad.
ALONSO, F. A. C. 2013. Los esfuerzos cubanos en la introducción y uso de las TIC en el sistema
nacional de educación.
AMO, F. A., NORMAND, L. M. & PÉREZ, F. J. S. 2005. Introducción a la ingeniería del software,
Delta.
ARIAS, Á., DURANGO, A. & ACADEMY, I. T. C. 2016. Ingeniería y Arquitectura del Software: 2ª
Edición, CreateSpace Independent Publishing Platform.
BLOGUNEWEB. 2016. Cocimientos básicos en Bootstrap. Available from:
http://tecnologiaenvivo.com/cocimientos-basicos-en-bootstrap/.
BRAUDE, E. J. 2003. Ingeniería de software: una perspectiva orientada a objetos, Alfaomega.
CASTILLO, A. A. 2017. Curso de Programación Web: JavaScript, Ajax y jQuery, IT Campus
Academy.
CONTRERAS CASTAÑEDA, M. Á. 2016. Desarrollo de aplicaciones Web multiplataforma,
Ministerio de Educación de España.
COSMIN, P. I. 2016. Patrones de Diseño. MoleQla: revista de Ciencias de la Universidad Pablo de
Olavide, 36.
CUERVO, M. C. 2005. La Ingeniería de Software Libre y sus herramientas aplicadas a proyectos
informáticos. Reportes Técnicos en Ingeniería del Software, 7, 30-35.
DAVILA, M. 2011. GNU/Linux y el software libre y sus múltiples aplicaciones. Bogotá, Colombia:
Universidad Minuto de Dios. Alfaomega Grupo Editor.
DRAKE, J. M. 2008 Análisis de requisitos y especificación de una aplicación.
DUCKETT, J., RUPPERT, G. & MOORE, J. 2014. JavaScript & jQuery: interactive front-end web
development, Wiley.
DURANGO, A. & ACADEMY, I. T. C. 2015. Diseño de Software: 2ª Edición, CreateSpace
Independent Publishing Platform.
EGUILUZ, J. 2013. Desarrollo web
ágil con Symfony2. 618.
EGUÍLUZ PÉREZ, J. 2008. Introducción a CSS.
EGUÍLUZ PÉREZ, J. 2009. CSS Avanzado. Editorial www. librosweb. es.
EGUÍLUZ PÉREZ, J. 2013. Desarrollo web ágil con Symfony2.
GAUCHAT, J. D. 2012a. El gran libro de HTML5 CSS3 y Javascript.
GAUCHAT, J. D. 2012b. El gran libro de HTML5, CSS3 y Javascript, Marcombo.
GONZÁLEZ, M. Á. C. 2010. Evolución tecnológica y cibermedios, Comunicación Social Ediciones y
Publicaciones.
JACOBSON, I., SPENCE, I. & BITTNER, K. 2013. Casos de uso 2.0. La guía para ser exitoso con los
casos de uso.
JANEV, M., DELIPETREV, B. & RISTOVA, S. Performance benchmark of PHP frameworks with
database select methods. IX INTERNATIONAL CONFERENCE FOR YOUNG
RESEARCHERS, 2015. 38-41.
KROSING, H. & MLODGENSKI, J. 2013. PostgreSQL server programming, Packt Publishing Ltd.
LAGUNA, M. A. 2008. Ingeniería del Software I 3º I.T.I.Gestión.
77
LÓPEZ, S. 2016. ¿Por qué utilizar Symfony en lugar de otro framework?
MARK SAFRONOV, J. W. 2014. Web Application Development with Yii 2 and PHP.
MARQUÉS ANDRÉS, M. 2011. Bases de datos, Universitat Jaume I.
MARTÍNEZ, A. & MARTÍNEZ, R. 2014. Guía a rational unified process. Escuela Politécnica
Superior de Albacete–Universidad de Castilla la Mancha.
MAZA, M. Á. S. 2012. Javascript, Innovación y Cualificación, S.L.
MIGUEL, J. T. S. 2015. MF0493_3 - Implantación de aplicaciones web en entorno internet, intranet y
extranet, Paraninfo.
MIR HUGUET, J. 2012. Estudio de los futuros estándares HTML5 y CSS3: propuesta de actualización
del sitio www. mpiua. net.
MORA, S. L. 2001. Programación en Internet : clientes web.
MUÑOZ, C. C., VELTHUIS, M. G. P. & DE LA RUBIA, M. Á. M. 2010. Calidad del producto y
proceso software, Ra-Ma S.A. Editorial y Publicaciones.
NAVATHE_ELMASRI 2013. Fundamentals_of_Database_Systems.
PALACIO MANSO, Y. 2010. Determinación de la Capacidad Productiva de la UEB Centro Plast en
la EINPUD “1ro de Mayo”. Universidad Central" Marta Abreu" de Las Villas.
PALOMO, S. R. G. & GIL, E. M. 2014. Aproximación a la ingeniería del software, Editorial
Universitaria Ramon Areces.
PANTALEO, G. 2012. Calidad en el desarrollo de software, Marcombo.
PANTALEO, G. & RINAUDO, L. 2015. Ingeniería de Software, Alfaomega.
PARÉ, R. C., MORA, O. P., ESCOFET, C. M., GINESTÀ, M. G., COSTA, D. C. & SANTILLÁN, L.
A. C. 2013. Bases de Datos. 460.
PEÑO, J. M. S. 2015. Pruebas de software. Fundamentos y técnicas.
PRESSMAN, R. S. 2010. Ingeniería del software.UN ENFOQUE PRÁCTICO.Séptima edición.
PRIETODÍAZ, V., QUIÑONES LA ROSA, I., RAMÍREZ DURÁN, G., FUENTES GIL, Z.,
LABRADA PAVÓN, T., PÉREZ HECHAVARRÍA, O. & MONTERO VALDÉS, M. 2011.
Impacto de las tecnologías de la información y las comunicaciones en la educación y nuevos
paradigmas del enfoque educativo. Educación Médica Superior, 25, 95-102.
RAMOS, A. 2011. APLICACIONES WEB (NOVEDAD 2011), Paraninfo.
RODRÍGUEZ, F. T. 2014. INTRODUCCIÓN A LAS PRUEBAS DE SISTEMAS DE
INFORMACIÓN.
SIERRA, F., ACOSTA, J., ARIZA, J. & SALAS, M. 2017. Estudio y análisis de los framework en php
basados en el modelo vista controlador para el desarrollo de software orientado a la web.
Revista Investigación y Desarrollo en TIC, 4.
SOMMERVILLE, I. 2005. Ingeniería del software, Madrid, España, Pearson Educación.
SPURLOCK, J. 2013. Bootstrap: Responsive Web Development, " O'Reilly Media, Inc.".
STALLMAN, R. M., PARATCHA, D. S. & LESSIG, L. 2007. Software libre para una sociedad libre,
Traficantes de Sueños.
TEZER, O. 2014. SQLite vs MySQL vs PostgreSQL: A Comparison Of Relational Database
Management Systems. Saatavissa: https://www. digitalocean. com/community/tutorials/sqlite-
vs-mysql-vs-postgresql-a-comparison-of-relational-database-management-systems. Viitattu,
31, 2017.
78
VILLORIA, L. N. 2009. APLICACIONES WEB 2.0 - Google docs, Eduvim - Editorial Universitaria
Villa María.
WELLING, L. & THOMSON, L. 2005. Desarrollo web con php y mysql php 5 y mysqul 4.1 y 5: disco
compacto. Madrid, España: Anaya Multimedia.
YANES, M. C. 2017. EMPRESA NACIONAL PRODUCTORA DE UTENSILIOS DOMESTICOS.
