Académique Documents
Professionnel Documents
Culture Documents
1. Introducción
El punto de partida para el desarrollo del sistema de punto de ventas, es la definición de lo que se
necesita implementar, el planteamiento de un sistema que permita la eficacia de facilitar la
administración de los productos en la empresa y las ventas que genere el establecimiento.
El nivel de complejidad aceptado por la infraestructura y los requisitos obtenidos, guarda directa
relación con el tiempo de costos de implementación deseados por la empresa para los distintos
requisitos que se proporcionaron. Este sistema nos permite unificar criterios y clases
implementadas al diseño del sistema, es necesario conocer que es una necesidad de implementar
un sistema de puto de ventas del cual debe ser abordado de la mejor forma más efectiva posible.
1.1 Propósito
El proceso de diseño se inicia a partir de un análisis con el dueño de la empresa definido con los
criterios que se proporcionó al líder del proyecto y al programador, en el cual se establecen los
servicios y espacios físicos en el sistema para el establecimiento del sistema de punto de ventas.
Este programa típicamente indica los servicios y áreas funcionales y las dimensiones deseadas en
acorde con lo que se necesita en la empresa.
Adicionalmente los sistemas de punto de venta se integra más fácilmente con numerosas ventas y
pedidos al sistema incluyendo los pedidos via mail u online que se unen con las ventas hechas
personalmente.
1.2 Alcance
El alcance de este sistema de punto de venta es el manejo de inventario, implementando a las ventas
un código de barras para identificar la recepción, el rastreo y la venta de elementos del inventario.
El sistema de punto de venta podrá automatizar mucho del proceso de manejo y monitoreo del
inventario. El sistema de punto de venta también podrá monitorear el costo de los productos
vendidos, el precio de las compras, el precio de las ventas y los márgenes de ganancia, permitiendo
que los usuarios extraer reportes y determinar cuándo hacer un ajuste del precio al cliente.
1.3 Definiciones, Acrónimos y Abreviaturas
Término Definición
2. Descripción general
El sistema de inicio con un punto de venta vasado en notas de remisión, cosa que limito los alcances
del personal en habilidades ya que se debía genera un reporte semanal para controlar ingresos, lo
que implico jornadas más largas, pues cotejar el dinero de la, venta con el reporte es una actividad
que se realiza con cautela y no se tiene la certeza que sea real pues el factor humano puede hacer
vulnerable.
Los nuevos modelos de negocio deben garantizar la buena canalización de recursos para el rápido
crecimiento de las empresas dentro de su mercado estandarizado, los sistemas que se utilizan
capacitando al personal y brindando seguimiento y satisfacción a los clientes finales.
Componentes
El plan de pruebas unitarias
Reporte de pruebas unitarias
Justificación de las decisiones de la construcción.
El sistema que se diseñó está basado en facilitar el registro de ventas, además de complementar
algunos otros aspectos que sean importantes para la empresa, por ejemplo, el registro de los
clientes para poder dar crédito incluyendo a los proveedores, la cantidad de ventas que se realizan,
entre otros aspectos que el cliente nos especificó. La programación está diseñada para
complementar otros datos que resulten importantes para la empresa, pudiendo controlar la base
de datos del mismo sistema.
3. Componentes
Componentes necesarios para la construcción del sistema.
1. Interfaz de productos
a. Productos que tengan código de barras y aquellos que carezcan de código de barras.
b. Productos que se venden en diferentes unidades de medida: Por Unidad, Por
Volumen, Por peso.
c. El editor de productos permite agregar productos, eliminar productos, modificar
existentes, así como todos sus parámetros, precios, impuestos, etc.
2. Control de Caja
a. conocer el flujo de caja y el dinero en ella en cada momento.
b. Registrar ventas efectuadas con diferentes métodos de pago:
Efectivo, o crédito.
3. Control de Transacciones Particulares:
a. Devoluciones de dinero
b. Retiros por el Dueño
c. Mermas
d. Retiros por consumo interno
e. Descuentos
4. Control de Stock:
a. Conozca en cada momento el stock de sus productos, saber cuánto es necesario
realizar compras, Evitara posibles pérdidas.
5. Cajeros múltiples
a. Permite la utilización por varios cajeros, y controlar el rendimiento de cada uno por
separado.
6. Multi Usuario
a. Las funciones multiusuario le permitirán tener varios cajeros funcionando en un
mismo local:
b. Llevar un control por separado de sus funciones
c. Tener cajeros con privilegios adicionales, para realizar funciones administrativas
específicas.
d. Usuarios Administradores
7. Registro de Gastos:
a. Pago de Cuentas
b. Sueldos
c. Pago de Servicios y Compras.
8. Ingreso de Facturas:
a. El programa le permitirá ingresar directamente sus facturas, y llevar un listado de
clientes y proveedores.
9. Factura y Boleta Electrónica.
a. podrá imprimir directamente en el software las facturas y boletas autorizadas por
SII.
10. Informes y Estadísticas:
a. Toda la información ingresada en el software quedará almacenada, para su
posterior revisión y análisis, y así poder optimizar costos y procedimientos.
11. Códigos de barras
a. imprimir códigos de barras (u otros métodos de etiquetado) para que pueda
mantener cada uno de sus productos perfectamente etiquetado y rastreable.
12. Base de datos de clientes de búsqueda
a. Búsqueda de un cliente cada vez que llamen a alguien. Adjuntarán la venta al
nombre del cliente.
13. Propiedades personalizadas
a. permiten decidir qué datos se desea que se ingresen sobre sus clientes. Las
propiedades comunes incluyen números de teléfonos, correos o direcciones.
3.1 A implementar
1. Servicio FTP:
2. Servidor FTP:
Para el desarrollo y la apropiada aplicación del sistema punto de ventas HERFRAN LUP no es
necesario que se contrate un servicio de FTP, el cual varia los costos ya que estos dependen de las
necesidades de cada usuario, para este caso no se requiere un servidor completo con capacidades
extremas, debido a que el sistema es aplicado en un negocio que se encuentra en crecimiento y que
cuanta con un solo servidor.
3.2 A modificar
1. Escáneres:
2. Impresora de recibos:
3. Interfaz gráfica:
Se requiere un tester para probar el sistema de manera manual ya que no se cuenta con un sistema
para automatizarlo, además de que al programar el software no se orientó a las pruebas o a objetos
simulados(mocks).
Se utilizará la herramienta de Junit que viene como plugin con Netbeans en el cual se desarrolló el
sistema.
4.3 Estrategia de las pruebas
Las pruebas unitarias o unit testing son una forma de comprobar que un fragmento de código
funciona correctamente. Es un procedimiento más de los que se llevan a cabo dentro de una
metodología ágil de trabajo.
Las pruebas unitarias consisten en aislar una parte del código y comprobar que funciona a la
perfección. Son pequeños tests que validan el comportamiento de un objeto y la lógica.
El unit testing suele realizarse durante la fase de desarrollo de aplicaciones de software o móviles.
Para el desarrollo del punto de ventas se realizaron pruebas unitarias priorizando el login, nuestro
código no fue enfocado a pruebas sin embargo por medio de la herramienta Junit se realizaron las
pruebas.
Las demás pruebas se realizarán de manera manual como se menciona anterior mente donde se
simularán las acciones del usuario, por medio de ellas se detectan la mayor parte de los defectos y
de esta forma se logra estabilizar el sistema que se está probando.
4.3.1 Objetivo
Realizar pruebas unitarias en parte del código del login, como se menciono anterior mente el código
del sistema no fue enfocado a pruebas, se tomó la sección de Usuarios la cual se nos facilito el uso
de la herramienta Junit como dependencia para poder trabajar, nos crea una estructura que debe
de contener 3 partes arrange, act, v assert.
Arrange (organizar). Es el primer paso de las pruebas unitarias. En esta parte se definen los
requisitos que debe cumplir el código.
Act (actuar). Es el paso intermedio de las pruebas, el momento de ejecutar el test que dará
lugar a los resultados que deberás analizar.
Assert (afirmar). En el último paso, es el momento de comprobar si los resultados obtenidos
son los que se esperaban. Si es así, se valida y se sigue adelante. Si no, se corrige el error
hasta que desaparezca.
4.3.2 Técnica
Velicamos la correcta implementación de las unidades internas Conexión e Encriptar, las estructuras
y sus relaciones, al implementar las pruebas de caja blanca hicimos énfasis en la reducción de
errores internos.
Los métodos de caja blanca o estructurales no permitieron derivar casos de prueba que garanticen
que todas las rutas independientes dentro del módulo se ejecuten al menos una vez, ejecuten los
lados verdadero y falso de todas las decisiones lógicas, ejecuten todos los ciclos dentro y en sus
límites operacionales, ejerciten las estructuras de datos internas para asegurar su validez
4.4 Herramientas
JUnit
Es un conjunto de bibliotecas creadas por Erich Gamma y Kent Beck que son utilizadas en
programación para hacer pruebas unitarias de aplicaciones Java.
Es un conjunto de clases (framework) que permite realizar la ejecución de clases Java de manera
controlada, para poder evaluar si el funcionamiento de cada uno de los métodos de la clase se
comporta como se espera. Es decir, en función de algún valor de entrada se evalúa el valor de
retorno esperado; si la clase cumple con la especificación, entonces JUnit devolverá que el método
de la clase pasó exitosamente la prueba; en caso de que el valor esperado sea diferente al que
regresó el método durante la ejecución, JUnit devolverá un fallo en el método correspondiente.
JUnit es también un medio de controlar las pruebas de regresión, necesarias cuando una parte del
código ha sido modificado y se desea ver que el nuevo código cumple con los requerimientos
anteriores y que no se ha alterado su funcionalidad después de la nueva modificación.
El propio framework incluye formas de ver los resultados (runners) que pueden ser en modo texto,
gráfico (AWT o Swing) o como tarea en Ant.
En la actualidad las herramientas de desarrollo como NetBeans y Eclipse cuentan con plug-ins que
permiten que la generación de las plantillas necesarias para la creación de las pruebas de una clase
Java se realice de manera automática, facilitando al programador enfocarse en la prueba y el
resultado esperado, y dejando a la herramienta la creación de las clases que permiten coordinar las
pruebas.
4.5 Recursos
1. Diseño de las pruebas. Esto es, identificación de la técnica o técnicas de pruebas que se
utilizarán para probar el software. Distintas técnicas de prueba ejercitan diferentes criterios
como guía para realizar las pruebas. Seguidamente veremos algunas de estas técnicas.
2. Generación de los casos de prueba. Los casos de prueba representan los datos que se
utilizarán como entrada para ejecutar el software a probar. Más concretamente los casos
de prueba determinan un conjunto de entradas, condiciones de ejecución y resultados
esperados para un objetivo particular.
3. Cobertura de Sentencias: Se escriben casos de prueba suficientes para que cada
sentencia en el programa se ejecute, al menos, una vez.
4. - Cobertura de Decisión: Se escriben casos de prueba suficientes para que cada decisión en
el programa se ejecute una vez con resultado verdadero y otra con el falso.
5. - Cobertura de Condiciones: Se escriben casos de prueba suficientes para que cada
condición en una decisión tenga una vez resultado verdadero y otro falso.
6. - Cobertura Decisión/Condición: Se escriben casos de prueba suficientes para que cada
condición en una decisión tome todas las posibles salidas, al menos una vez, y cada decisión
tome todas las posibles salidas, al menos una vez.
7. - Cobertura de Condición Múltiple: Se escriben casos de prueba suficientes para que todas
las combinaciones posibles de resultados de cada condición se invoquen al menos una vez.
8. - Cobertura de Caminos: Se escriben casos de prueba suficientes para que se ejecuten todos
los caminos de un programa. Entendiendo camino como una secuencia de sentencias
encadenadas desde la entrada del programa hasta su salida.
1. Conexion
2. Encriptar
4.6.1.2
<clases diseñadas para la seguridad, tales como métodos de cifrado de contraseñas y conexiones
de la base de datos. >
< no se detectaron
< String >: <cadena de
<String>: < secuencia errores ocasionados
<Conexion> número y letras
ordenada de elementos > durante la ejecución
encriptadas>
>
Método Recibe Regresa Excepción
< no se detectaron
< bytes >: <cadena de
<String>: < secuencia errores ocasionados
<Encriptar> número y letras
ordenada de elementos > durante la ejecución
encriptadas>
>
< no se detectaron
< byte >: < es un entero <String >: <cadena te
errores ocasionados
<descyptt> de 8 bits complemento a texto con la contraseña
durante la ejecución
dos. > desencriptada >
>
Para cada tipo de usuario registrado, de determino mediante las pruebas realizadas que las
funciones, datos y transacciones funcionan como se esperaba sin ningún tipo de exención.
En las pruebas de caja negra, nos enfocamos solamente en las entradas y salidas del sistema, sin
preocuparnos en tener conocimiento de la estructura interna del programa de software. Para
obtener el detalle de cuáles deben ser esas entradas y salidas, nos basamos en los requerimientos
de software y especificaciones funcionales.
La técnica de prueba de caja blanca, al contrario de las pruebas de caja negra, consiste en verificar
la estructura interna de un programa.
Ya que el método de pruebas de caja negra, para encontrar todo los errores del programa sería muy
complejo, generando un caso de prueba para cada entrada, el numero de casos de prueba que
tenemos que utilizar seria muy elevado y no seria productivo, llevándonos a un retraso de la entrega
del programa al cliente.