Ing. de Software

1. SISTEMA DE
COMPRA Y VENTA
PARA
FERRETERIA

2. DIRECTIVAS DEL PROYECTO
PROPÓSITO DEL PRODUCTO
Antecedentes
El negocio se llama “Colcha’s Family” que esta dedicado escencialmente a la venta (y
compra en un menor grado) de materiales de ferreteria.
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 Compra y Venta para una Ferreteria” 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 3
meses.
Objetivos específicos:
1. Desarrollo del modulo de manejo de ventas.
2. Desarrollo del modulo de manejo de compra.
3. Desarrollo del modulo de manejo y gestion de informacion de los productos.
4. Desarrollo de las funciones complementarias y basicas que necesitara el
sistema para llevar a cabo a plenitud las tareas requeridas por los usuarios.
5. Generar los reportes correspondientes a los módulos.

3. REQUERIMIENTOS
DEL
SOFTWARE

4. 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, despues
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 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 realizó alguna venta después de haberse realizado esta,
incluyendo la fecha en la que se realizó, para que los usuarios

5. 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 de la
actualización de la cantidad modificada de dicho producto.
 Al final de una venta el sistema deberá ser capaz de generar boletas
de pago físicas.
1.1.2. Requisitos no Funcionales
 El sistema no debe tardar mas de 5 segundos en realizar la
búsqueda de algun 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).

6.  El sistema deberá funcionar correctamente en cualquiera de los
siguientes sistemas Operativos: Windows 7, Windows 8, 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 minimamente 2 nucleos, 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, despues de haber
realizado dicha operación.Se necesitara que tanto el “módulo de
gestion de informacion de producto” como el “modulo 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 gestion de
informacion de producto” deberan 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 gestion de informacion de producto” y el
“módulo de registro de productos defecuosos“.
 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
almacen. El “modulo de ventas” debera consultar con “módulo de
gestion de informacion de producto” para poder obtener la
informacion necesaria para llevar a cabo este

7.  Cada vez que el(los) usuario(s) realice(n) una venta, el sistema deberá ser
capaz de descontar la cantidad vendida de los productos. El “módulo de
gestion de informacion de producto “ deberá consultar con “modulo
de ventas” para realizar la actualizacion 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 tienda.
 El sistema debe permitir a los usuarios el registro de nuevos productos.
 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.
 Gestionamiento de la informacion de los productos; es decir, el sistema
será capaz de poder actualizar y/o eliminar información concerniente a los
productos albergados en la base de datos.
 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.
 Obtención de toda la información de algún producto mediante la búsqueda,
haciendo uso del “código” perteneciente a este.
Los anteriores requisitos disminuiran el indice de “problemas”
existentes(ventas fantasma, productos perdidos) haciendo mas
efectivo los procesos de venta y compra, además la gestion de la
empresa aumentará significativamente puesto que todos los
movimientos que realice la empresa estaran completamente
monitoreados por los usuarios.

8. 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 venta, 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 venta, el sistema
deberá ser capaz de descontar la cantidad vendida de los
productos.
 El sistema guardará automaticamente el registro de que se realizo
alguna venta despues de haberse realizado esta, incluyendo la
fecha en la que se realizó, para que los usuarios dispongan de una
estadistica de sus ventas 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).
 Gestionamiento de la informacion 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.

9.  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, despues
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 final de una venta el sistema debera ser capaz de generar
boletas de pago fisicas.
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 5 integrantes
(véase STAKEHOLDERS) se ve útil la utilización de una red social

10. (facebook) para compartir información y mantener comunicación de
manera fluida y disciplinada entre todos los miembros.
• 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)
VENDEDOR(conjunto de empleados encargados de la caja chica en
cada sucursal – de existir esta -, venta atendiendo en mostrador y
demás temas relacionados).
• 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.
• CLIENTE: la empresa a la cual se desarrollará el software.
Gracias a las herramientas de apoyo con las que contamos, podemos
organizar:

11. STAKEHOLDERS – PARTICIPANTES:
ACTORES:
2.3. APOYO Y ADMINISTRACION DEL PROCESO

12. Para esto nos valdremos de diversos software que nos ayuden a
administrar el proceso de desarrollo:
• REM: herramienta con la que inicialmente se desarrolló todo el proceso.
• OPENPROJ: el MS PROJECT de Linux, cuyas funcionales de
diagramas de Gantt y Pert ayudarán en la administración del proyecto.
• LETSREQ: herramienta online propietaria para los requerimientos, su
versión trial nos permite usarlo como límite para 1 proyecto.
2.4.
CALIDAD Y MEJORA DEL PROCESO
La métrica a utilizarse para el cumplimiento de los requerimientos estará
dada por la siguiente fórmula:
(Número de Requerimientos Realizados) / (Total de Requerimientos)
Dicha fórmula nos permitirá obtener un valor porcentual acerca de qué tan
cerca de terminar el producto nos encontramos.
3. Colchonel
4. ANALISIS DE REQUERIMIENTOS
4.1. CLASIFICACION DE REQUERIMIENTOS
Clasificaremos los requerimientos de dos dimensiones; si es funcional o no
funcionales; y por prioridad de los requerimientos.
4.1.1. Por Funcionalidad
Requerimientos Funcionales

13. Requerimientos No Funcionales
4.1.2. Por Prioridad
Muy alta
 UC-001 Logueo de usuarios (Verificado)
 UC-002 Gestión de Productos (Verificado)
 UC-007 Registro de productos defectuosos (Verificado)

14. Alta
 UC-004 Reporte de compras (Pendiente)
 UC-005 Registro de Productos (Pendiente)
 UC-006 Reporte de venta (Pendiente)
Normal
 UC-003 Búsqueda de Productos (Verificado)
 UC-008 Generar Boletas de Pago (Pendiente)
Baja
 Ninguno
Muy baja
 Ninguno
Ninguno
 Ninguno
4.2. MODELADO CONCEPTUAL
Para este punto usaremos los diagramas de casos de uso:
4.3. DISEÑO ARQUITECTONICO Y ASIGNACION DE REQUERIMIENTOS
(Diagramas del weber)

15. 4.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.
4.5. ANÁLISIS FORMAL
Estos puntos se especifican mejor con las tareas número 3 de los tópicos 5
y 6.

16. 5. ESPECIFICACIÓN DE REQUISITOS
5.1 Requisito Funcional N° 1: LOGUEO DE USUARIOS

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

19. 5.3. Requisito Funcional N° 3: BÚSQUEDA DE PRODUCTOS

20. 5.4. Requisito Funcional N° 4: REPORTE DE COMPRAS

21. 5.5. Requisito Funcional N° 5: REGISTRO DE PRODUCTOS NUEVOS

22. 5.6. Requisito Funcional N° 6: REPORTE DE VENTAS

24. 5.7. Requisito Funcional N° 7: REGISTRO DE PRODUCTOS DEFECTUOSOS

25. 5.8. Requisito Funcional N° 8: GENERAR BOLETAS DE PAGO
6. VALIDACION DE REQUERIMIENTOS

26. 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.
6.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

27. UC-004
UC-005

28. UC-006
UC-007
UC-008

29. 6.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.

30. 7. Colchón d mrd
8. HERRAMIENTAS DE REQUERIMIENTOS DE SOFTWARE
Vamos a dividir en dos categorías las herramientas que hemos usado hasta
ahora:
Herramientas para la elaboración de modelos.
• ArgoUML: es una aplicación de diagramado de UML escrita en Java y
publicada bajo la Licencia BSD.
Herramientas para la gestión de requisitos.

31. • OPENPROJ: el MS PROJECT de Linux, cuyas funcionales de diagramas de
Gantt y Pert ayudarán en la administración del proyecto.
• LETSREQ: herramienta online propietaria para los requerimientos, su versión
trial nos permite usarlo como límite para 1 proyecto.