Requerimientos de un Sistema (usando criterios del swebok)

29
SISTEMA DE COMPRA Y VENTA PARA FERRETERIA

description

Ing. de Software

Transcript of Requerimientos de un Sistema (usando criterios del swebok)

Page 1: Requerimientos de un Sistema (usando criterios del swebok)

SISTEMA DE

COMPRA Y VENTA

PARA

FERRETERIA

Page 2: Requerimientos de un Sistema (usando criterios del swebok)

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.

Page 3: Requerimientos de un Sistema (usando criterios del swebok)

REQUERIMIENTOS DEL

SOFTWARE

Page 4: Requerimientos de un Sistema (usando criterios del swebok)

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

Page 5: Requerimientos de un Sistema (usando criterios del swebok)

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).

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

Page 6: Requerimientos de un Sistema (usando criterios del swebok)

gestion de informacion de producto” para poder obtener la informacion necesaria para llevar a cabo este

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.

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

Page 7: Requerimientos de un Sistema (usando criterios del swebok)

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.

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

Page 8: Requerimientos de un Sistema (usando criterios del swebok)

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 (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.

Page 9: Requerimientos de un Sistema (usando criterios del swebok)

Gracias a las herramientas de apoyo con las que contamos, podemos organizar:

STAKEHOLDERS – PARTICIPANTES:

ACTORES:

Page 10: Requerimientos de un Sistema (usando criterios del swebok)

2.3. APOYO Y ADMINISTRACION DEL PROCESO

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 REQUERIMIENTOSClasificaremos los requerimientos de dos dimensiones; si es funcional o no funcionales; y por prioridad de los requerimientos.

4.1.1. Por Funcionalidad

Requerimientos Funcionales

Page 11: Requerimientos de un Sistema (usando criterios del swebok)

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)

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 CONCEPTUALPara este punto usaremos los diagramas de casos de uso:

Page 12: Requerimientos de un Sistema (usando criterios del swebok)

4.3. DISEÑO ARQUITECTONICO Y ASIGNACION DE REQUERIMIENTOS

(Diagramas del weber)

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 FORMALEstos puntos se especifican mejor con las tareas número 3 de los tópicos 5 y 6.

5. ESPECIFICACIÓN DE REQUISITOS

Page 13: Requerimientos de un Sistema (usando criterios del swebok)

5.1 Requisito Funcional N° 1: LOGUEO DE USUARIOS

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

Page 14: Requerimientos de un Sistema (usando criterios del swebok)

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

Page 15: Requerimientos de un Sistema (usando criterios del swebok)

5.4. Requisito Funcional N° 4: REPORTE DE COMPRAS

Page 16: Requerimientos de un Sistema (usando criterios del swebok)

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

Page 17: Requerimientos de un Sistema (usando criterios del swebok)

5.6. Requisito Funcional N° 6: REPORTE DE VENTAS

Page 18: Requerimientos de un Sistema (usando criterios del swebok)

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

Page 19: Requerimientos de un Sistema (usando criterios del swebok)

5.8. Requisito Funcional N° 8: GENERAR BOLETAS DE PAGO

Page 20: Requerimientos de un Sistema (usando criterios del swebok)

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

6.1. PROTOTIPADO

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

Page 21: Requerimientos de un Sistema (usando criterios del swebok)

UC-001

UC-002

UC-003

Page 22: Requerimientos de un Sistema (usando criterios del swebok)

UC-004

UC-005

UC-006

Page 23: Requerimientos de un Sistema (usando criterios del swebok)

UC-007

UC-008

Page 24: Requerimientos de un Sistema (usando criterios del swebok)

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.

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.

Page 25: Requerimientos de un Sistema (usando criterios del swebok)

Herramientas para la gestión de requisitos.

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.