SISTEMA DE

COMPRA
ALMACEN
INVENTARIO
 DIRECTIVAS DEL PROYECTO

PROPÓSITO DEL PRODUCTO

Antecedentes

El negocio se llama “COMERCIALIZADORA S.A Es una empresa que lleva el control de sus Bienes
y Servicios. El interés primario es poder hacer que los Bienes se manejen de forma rápida y con el menor
grado de error. Para esto quien maneja la sección de "Bienes y Suministros"
.

Planteamiento del problema

De acuerdo con las entrevistas realizadas al cliente, se han identificado los siguientes
problemas en los procedimientos actuales:

▪ El control de las ventas es ineficiente por que todo lo que venden lo anotan en
una libreta.
▪ En ocasiones apuntan las claves incorrectas del producto, lo que ocasiona que
el contador de negocio dé de baja otro producto.
▪ De vez en cuando olvidan apuntar que vendieran en la libreta y por eso no
saben exactamente lo que tienen en la tienda.
▪ Como no se sabe exactamente lo que se tiene en la tienda, los vendedores
llaman al contador cada que realizan la venta para que les informe la cantidad
existente del producto.

Debido a lo anterior, se tiene un gran problema en el control y la actualización de

información.

Objetivos del proyecto

1. Objetivo general:

Creación de un “Sistema de Compras Almacén e inventario” que permita al

negocio llevar control y mantener actualizados sus registros de adquisiciones,
ventas e inventario de productos en la misma tienda. El sistema estará
instalado en una o varias computadora, donde solo personal autorizado podrá
accederlo. El sistema debe ser concluido en un tiempo no mayor a 1 mes.

Objetivos específicos:

1. Desarrollo del módulo de manejo de compra.

2. Desarrollo del módulo de manejo de almacén de los productos.
3. Desarrollo de módulo de inventariar los productos y básicamente que
necesitara el sistema para llevar a cabo a plenitud las tareas requeridas por los
usuarios.
4. Generar los reportes correspondientes a los módulos.
REQUERIMIENTOS
DEL
SOFTWARE
1. Requerimientos Fundamentales del Software:

1.1. Requisitos Funcionales y No Funcionales:

1.1.1. Requisitos Funcionales

▪ El sistema deberá poder verificar la autenticación de ingreso a este

por parte del(los) usuario(s) autorizado(s).

▪ Gestionamiento de la información de los productos; es decir, el

sistema será capaz de permitir al(los) usuario(s) poder actualizar y/o
eliminar información concerniente a los productos albergados en la
base de datos.

▪ Obtención de toda la información de algún producto mediante la

búsqueda, haciendo uso del “código” perteneciente a este.

▪ El sistema deberá permitir generar un reporte de compras, después

de haber realizado dicha operación.

▪ El sistema debe permitir a los usuarios el registro de nuevos

productos.

▪ Cada vez que el(los) usuario(s) realice(n) una compra, el sistema

deberá ser capaz de aumentar la cantidad comprada de los
productos. Además el sistema permitirá guardar el registro de que
se realizó alguna venta después de haberse realizado esta,
incluyendo la fecha en la que se realizó, para que los usuarios
 Dispongan de una estadística de sus ventas realizadas
semanalmente. El sistema deberá ser capaz de verificar que la
cantidad requerida por los clientes existen en el almacén. Si este no
fuera el caso el sistema deberá emitir un mensaje de alerta dando a
conocer las cantidades actuales de los productos antes solicitados.

▪ El(los) usuario(s) podrán registrar en el sistema los productos

defectuosos para que después el sistema se encargue del inventario
correspondiente por producto

▪ Al final de una venta el sistema deberá ser capaz de generar

reportes.

1.1.2. Requisitos no Funcionales

▪ El sistema no debe tardar mas de 5 segundos en realizar la

búsqueda de algún producto, si esto ocurriese el sistema lanzará un
mensaje de error indicando que no puede conectarse con la base de
datos.

▪ El sistema deberá emitir un reporte cada cierto tiempo dando a

conocer los productos que están por debajo del límite del stock
mínimo establecido por los usuarios.

▪ Los usuarios deben contar con la plataforma Java instalada en su(s)

computador(es).
 ▪ El sistema deberá funcionar correctamente en cualquiera de los
siguientes sistemas Operativos: Windows 7, Windows 8,win 10,
Linux, Mac OS.

▪ Se debe disponer de perifericos disponibles (mouse y teclado) para

un adecuado uso del software.

▪ Para un mejor funcionamiento del sistema se requiere una PC con

una capacidad de RAM de 2GB o mayor, además debe contar con
un procesador que posea mínimamente 2 núcleos, además debe
contar con por lo menos 25GB disponibles para alojar la base de
datos.

1.2. Propiedades Emergentes:

▪ El sistema deberá generar un reporte de compras, después de haber

realizado dicha operación. Se necesitara que tanto el “módulo de
gestión de información de producto” como el “módulo de compras”
trabajen juntos.

▪ El sistema deberá emitir un reporte cada cierto tiempo dando a conocer los
productos que están por debajo del límite del stock mínimo establecido por
los usuarios. El “módulo de reportes” y “módulo de gestión de
información de producto” deberán trabajar juntos para llevar a cabo
el monitoreo de stock de productos.

▪ El(los) usuario(s) podrán registrar en el sistema los productos defectuosos

para que después el sistema se encargue de la actualización de la
cantidad modificada de dicho producto. Para llevar a cabo esta función
se necesitará el “módulo de gestión de información de producto” y el
“módulo de registro de productos defectuosos“.

▪ Cada vez que el(los) usuario(s) realice(n) una venta, el sistema deberá ser
capaz de verificar que la cantidad requerida por los clientes existen en el
almacén. El “módulo de ventas” deberá consultar con “módulo de
gestión de información de producto” para poder obtener la
información necesaria para llevar a cabo este
 ▪ Cada vez que el(los) usuario(s) realice(n) una compra, el sistema deberá
ser capaz de aumentar la cantidad adquirida de los productos. El “módulo
de gestión de información de producto “ deberá consultar con
“módulo de compras” para realizar la actualización en la base de
datos.

1.3. Requerimientos Cuantificables:

▪ El sistema deberá poder verificar la autenticación de ingreso a este por

parte de el(los) usuario(s) autorizado(s).

Este requisito incrementará significativamente la seguridad dentro

de la COMERCIALIZADORA.S.A

EN LA COMPRA
 Recibe las solicitudes de compras de las diferentes áreas de la empresa.
 Quien realiza una solicitud puede ser responsable de uno o varios centros de costos, con la
salvedad de que él como empleado solo está adscrito a uno.
 Una vez diligenciada la solicitud es remitida al área de compras para realizar su correspondiente
cotización.
 Las cotizaciones son realizadas con uno o varios proveedores de los bienes solicitados.
 Cada orden puede tener asociado uno o varios ítems de la solicitud o solicitudes que van a ser
despachadas.
 La orden de compra es aprobada por el Director Financiero para que sea enviada al proveedor
elegido.

EN EL ALMACEN
 Su función principal es la de recepcionar los bienes que llegan de los proveedores y distribuirlos
a las correspondientes áreas que realizaron las solicitudes de compras.
 Cuando llega un proveedor con mercancía, este hace una entrega física de los bienes, los cuales
son comparados con la factura que éste entrega y con la orden de compra correspondiente. Si esta
acción es correcta se registra una entrada de almacén por cada factura relacionada.
 Cuando el almacén decide despachar los bienes a las diferentes áreas solicitantes, registra cada una
de las entregas en Salidas de Almacén.
 Una entrada de almacén puede generar muchas salidas de almacén, por ejemplo: pueden ingresar
500 cajas de papel para impresión, pero como se debe repartir entre varias áreas, cada una requiere
de una salida de almacén.

EN EL INVENTARIO
 Es la encargada de administrar y controlar la ubicación de los bienes dentro de la empresa, por
esto antes de que el bien salga del almacén debe ser codificado a través de un código único que lo
haga identificable dentro de la empresa.
 La ubicación del bien se identifica por la siguiente información: responsable del bien, fecha de
entrega, dirección del bien (ubicación).

Los anteriores requisitos disminuirán el índice de “problemas”

existentes (compras fantasma, productos perdidos) haciendo más
efectivo los procesos de compra, además la gestión de la empresa
aumentará significativamente puesto que todos los movimientos que
realice la empresa estarán completamente monitoreados por EL
usuario de inventarios.
1.4. Requerimientos de Software y Requisitos del Sistema:

1.4.1. Requerimientos del Sistema

▪ El sistema deberá emitir un reporte cada cierto tiempo dando a

conocer los productos que están por debajo del límite del stock
mínimo establecido por los usuarios.

▪ Cada vez que el(los) usuario(s) realice(n) una compra, el sistema

deberá ser capaz de verificar que la cantidad requerida por los
clientes existen en el almacen. Si este no fuera el caso el sistema
deberá emitir un mensaje de alerta dando a conocer las cantidades
actuales de los productos antes solicitados.

▪ Cada vez que el(los) usuario(s) realice(n) una compra, el sistema

deberá ser capaz de aumentar la cantidad comprada de los
productos.

▪ El sistema guardará automáticamente el registro de que se realizó

alguna venta después de haberse realizado esta, incluyendo la
fecha en la que se realizó, para que los usuarios dispongan de una
estadística de sus compras realizadas semanalmente.

1.4.2. Requerimientos del Software

▪ El sistema deberá poder verificar la autenticación de ingreso a este

por parte de el(los) usuario(s) autorizado(s).

▪ Gestiona miento de la información de los productos; es decir, el

sistema será capaz de permitir al(los) usuario(s) poder actualizar y/o
eliminar información concerniente a los productos albergados en la
base de datos.
 ▪ Obtención de toda la información de algún producto mediante la búsqueda,
haciendo uso del “código” perteneciente a este.

▪ El sistema deberá permitir generar un reporte de compras, después de haber

realizado dicha operación.

▪ El sistema debe permitir a los usuarios el registro de nuevos productos.

▪ El(los) usuario(s) podrán registrar en el sistema los productos defectuosos para

que después el sistema se encargue de la actualización de la cantidad modificada
de dicho producto.

▪ Al momento de la compra compra el sistema deberá ser capaz de generar una

orden de compra para ser registrado en el sistema.

2. PROCESO DE REQUERIMIENTOS:

2.1. MODELO DEL PROCESO:

El software estará desarrollado según el proceso RUP, dejando en claro los principios
clave en los que se basa:

 ADAPTAR EL PROCESO: adaptar a las necesidades del cliente, para lo cual

previamente se debe establecer dichas necesidades y sus prioridades. Dicha lista de
necesidades se especificará en el contrato en el apéndice NECESIDADES Y
PRIORIDADES PROPIAS DEL CLIENTE.
 EQUILIBRAR PRIORIDADES: en caso de haber contradicciones o diferencias entre
los usuarios del sistema, se buscará la manera de llegar a un acuerdo, el mismo que
estará en la sección RESTRICCIONES Y LÍMITES del archivo general.

 DEMOSTRAR VALOR ITERATIVAMENTE: Para ello se planea un cronograma para

la presentación de prototipos, según los cuales se identificará la validación y permiso
para continuar con la implementación. Dicho cronograma se encontrará en la sección
CRONOGRAMA del archivo general.

 COLABORACION ENTRE EQUIPOS: Dado que el desarrollo del software estará a

cargo de un equipo conformado por 1 integrante (véase STAKEHOLDERS)

 ELEVAR EL NIVEL DE ABSTRACCION: Para ello se contará con diversos modelos

con los cuales se obtendrá el nivel de abstracción deseado antes de empezar a
programar el software. Herramientas tales como Rational Rose pueden ser útiles para
estos fines.
  ENFOCARSE EN LA CALIDAD: Para enfocarse en la calidad, el equipo de
desarrolladores tiene en mente, que en cada parte se haga una “observación grupal”
sobre aspectos de calidad y rendimiento que puedan mejorarse, generando así un
feedback entre el grupo y el(los) encargado(s) antes de aceptarlo como posible
entregable al cliente.

2.2. ACTORES DEL PROCESO:

 USUARIO: personal que operará el sistema, el cual podrá ser:

SECRETARIO (encargado de generar reportes),

GERENTE (responsable de toma de decisiones concerniente a la compra de

mercancías para el negocio)

USUARIO _ALMACEN (empleado encargado de la recepción de productos, compras

del día atendiendo en su oficina.

 DESARROLLADOR: personal que comprende a analistas y desarrolladores que

implementarán y darán mantenimiento al software, de acuerdo a especificaciones
realizadas por el cliente.

 USUARIO INVENTARIO: la empresa a la cual con el sistema gerara un codigo para la

búsqueda con el software.

3. ANALISIS DE REQUERIMIENTOS

3.1. CLASIFICACION DE REQUERIMIENTOS

Clasificaremos los requerimientos de dos dimensiones; si es funcional o

no funcionales; y por prioridad de los requerimientos.

Requerimientos No Funcionales

3.1.1. Por Prioridad

Muy alta

▪ UC-001 Logueo de usuarios (Verificado)

▪ UC-002 Gestión de Productos (Verificado)

▪ UC-007 Registro de productos defectuosos (Verificado)

Alta
▪ UC-004 Reporte de compras (Pendiente)

▪ UC-005 Registro de Productos (Pendiente)

▪ UC-006 Reporte de de almacen(Pendiente)

Normal

▪ UC-003 Búsqueda de Productos (Verificado)

▪ UC-008 Generar código para el inventario (Pendiente)

Baja

▪ Ninguno

Muy baja

▪ Ninguno

Ninguno

▪ Ninguno
3.2. MODELADO CONCEPTUAL

Para este punto usaremos los diagramas de casos de uso:

COMPRA

Usuario_solicitante

Jefe del área o responsable

Proveedor_ganador Orden de compra Firma del director
de

ALMACEN

Producto almacenado

N° orden de compra Oficina_solicitante Productos

despachado
ss

INVENTARIO

Responsable del Fecha de Ubicación del

pedido entrega producto

3.3. DISEÑO ARQUITECTONICO Y ASIGNACION DE REQUERIMIENTOS

3.4. REQUERIMIENTOS DE NEGOCIACION

▪ Los clientes clasifican y discuten los posibles conflictos según su prioridad.

▪ Identificar y analizar los riesgos asociados a cada requisito.

▪ En el proceso se puede eliminar, combinar o modificar requisitos para

conseguir los objetivos planteados.

3.5. ANÁLISIS FORMAL

Estos puntos se especifican mejor con las tareas número 3 de los tópicos 5 y 6.
4. ESPECIFICACIÓN DE REQUISITOS

5.1 Requisito Funcional N° 1: LOGUEO DE USUARIOS

5.2. Requisito Funcional N° 2: GESTIÓN DE PRODUCTOS

UC-002 Gestión de Productos

Versión

El sistema será capaz de permitir al(los ) usuario(s) poder actualizar y/ o eliminar información conce rniente a los productos albergados en la base de dato s.
Descripción

STK-004 Alexande r Richard Zevallos Vizcarra íSOLUSOFT) STK-001 Darlinne Hubert Palo Soto íSOLUSOFT)
STK-002 Alexander Gabriel Luna Choguecota (SOLUSOFT)
Autores STK-003 Miguel Miranda (SOLUSOFT}

Fuentes Ninguno

Objetivos relacionados Nin guno

Re quisitos relacionados Ninguno

ACT-002 Secretar io ACT-003 Gerente ACT-004 Vendedor

Actores

Precondición Haberse logueado correcta mente como usuario autorizado .

Paso Descripción

Loguearse correctamente como usuario autorizado para ingresar al sistema.

S ecuencia normal
Ingresar a la pestaña PRODUCTOS.
3 Seleccionar el producto de la lista emergente.

4 Seleccionar uno de las opciones existente para cada producto: ACTUALIZAR INFORMACIÓN o ELIMINAR PRODUCTO.

5 Finalmente aceptar los cambio realizados .

Paso Tiempo
Tie mpo

Postcondición Ninguno

PasoDescripción
Legue incorrecto por parte de los usuarios.
Secuencia de excepciones

No aceptar la petición para guardar algún cambio realizado. El sistema lanzara un mensaje de alerta para verificar su decision.
2

Prioridad Mu y alta

Urgencia Muy alta

Estabilidad Alta

Estado Verificado

Comentarios Ninguno

P aquete Ninguno
5.3. Requisito Funcional N° 3: BÚSQUEDA DE PRODUCTOS
5.4. Requisito Funcional N° 4: REPORTE DE COMPRAS
5.5. Requisito Funcional N° 5: REGISTRO DE PRODUCTOS NUEVOS
 5.6.
5.7.
5.8. Requisito Funcional N° 6: REPORTE DE COMPRA

UC-006 Reporte de
compcompra Compras
Versión

= Cada vez que el(los) usuario(s) realice(n) una venta. el sistema deberá ser capaz de descontar la cantidad vendida de los productos .
Además el sistema permitirá guardar el registro de que se realizo alguna venta después de haberse realizad o esta, incluy endo la fecha
=
en la que se realizó, para que los usuarios dispongan de una estadística de sus ventas realizadas semanalmente . Cada vez que el(los)
Descripción usuario{s) realice(n) una venta, el sistema deberá ser capaz de descontar la cantidad vendida de los productos. Además el sistema permitirá guardar el registro de que se

STK-001 Darlinne Hubert Palo Soto fSOLUSOFTI

STK-002 Alexander Gabriel Luna Choquecota íSOLUSOFT} STK-003 Miguel Miranda íSOLUSOFT}
Autores
STK-004 Alexander Richard Zevallos Vizcarra íSOLUSOFT}

Fuentes Ninguno

Objetivos relacionados Ninguno

Requisitos relacionados UC-002 Gestión de Productos

ACT-002 Secretario ACT-003 Gerente ACT-004 Vendedor

Actores

Precondición Ninguno

Desc ripción
Pas o

Secuencia normal Logueo correcto como usuario autorizado.

2 Ingresar al modulo de VENTAS y registrar todos los productos requeridos para la venta.

3 Guardar el reporte de venta para actualizar la información en la base de datos.

P ::i crn Ti m nn

Guardar el reporte de venta para actualizarla información en la base de datos.

Paso Tiempo
Tiempo

Postcondición Ninguno

Descripción
P aso
Se cuencia de excepciones Logueo incorrect o.

No guardar el registro de venta, el sistema emitirá un mensaje de alerta indicando el problema.

P rio ridad Muy alta

Urgencia Muy alta

Estabilidad Alta

Estad o Pendiente

Comentarios Ninguno

P aquete Ninguno

5.9. Requisito Funcional N° 8: GENERAR UNA ORDEN DE COMPRA

5.8 VALIDACION DE REQUERIMIENTOS
Para asegurarnos que el cliente y los desarrolladores estén ambos conformes con lo que se
va a construir, nos vemos en la necesidad de coordinar una reunión con ellos y mostrarles
allí un documento de requerimientos sin especificaciones del tipo “utilizar determinada
librería” y demás especificaciones técnicas, apoyados por interfaces y “pantallazos” de lo
que el usuario verá y será capaz de hacer mediante el software, para así poder despejar
dudas y además hacer observaciones sobre malentendidos que podrían haber surgido de
no haberles mostrado previamente la interfaz.

4.1. PROTOTIPADO

Pasamos a crear interfaces para su aprobación por parte del cliente, tomando en cuenta
los requerimientos funcionales:

UC-001

UC-002

UC-003
UC-004

UC-005
 4.2. VALIDACION DEL MODELO

Para la validación de las interfaces, se creó un documento donde se guardaron las

“observaciones” por parte del cliente hacia la interfaz, y un agregado en done podrían
consultar alguna duda sobre el producto. Dicho proceso planeamos hacerlo hasta que las
observaciones de carácter crítico se hayan terminado.
.