Sistema de Ventas de BODEGA

< Sistema de Ventas de Autopartes “bodega S.C.R.L” >

Versión: <1.2.0>

Especificación de Requerimientos de Software Fecha: <viernes, 12 de octubre de 2012>

Sistema de Ventas de Bodega

“BODEGA S.C.R.L”

Especificación de

Requerimientos de Software (ERS) Versión <1.2.0>

VIERNES, 12 DE OCTUBRE

DE 2012


Versión: <1.2.0>


CICLO DE VIDA ESTRUCTURADO

ETAPA DOCUMENTACION

TAREAS

Definición de Requerimientos

Diagnóstico de la situación y necesidad del sistema

Modelo del Ambiente: Declaración de Propósitos

Diagrama de Contexto

Lista de Eventos o Catálogo de

Requerimientos Glosario

Diagrama de Gantt del proyecto (preliminar)

Detección de objetivos y límites del sistema y su

interacción con el ambiente

En base a entrevistas con usuarios

Análisis

Modelo de Comportamiento Diagrama de Flujo de Datos

Especificación de procesos

Diagrama Entidad Relación

Diccionario de Datos

Diagrama de Transición de

Estados

Diagrama de Gantt del proyecto (actualización)

Formalización de objetivos, independiente de la

naturaleza de la tecnología a aplicar y de cualquier

cuestión de implantación

Determinación de

entidades, con atributos e interrelaciones

Determinación de procesos

Diseño

Modelo del usuario

Modelo del Procesador o Diagrama de hardware o Justificación del entorno

tecnológico

Modelo de Tareas: Diagrama de

Fronteras Modelo de implantación de

programas: Diagrama estructurado

Interfaces de usuario:

Prototipos de pantallas y reportes

Base de datos: estructura

Diagrama de Gantt del proyecto (actualización)

Elección del entorno

tecnológico Establecimiento de la

arquitectura de la aplicación

Diseño de Interfaces de usuarios y procesos

Desarrollo

Normas de programación y

estándares de nomenclatura Esquema definitivo de la Base de

Datos Código fuente (con

documentación incorporada) Diagrama de Gantt del proyecto

(definitivo)

Implementación

Creación base de datos Codificación e integración

de módulos

Testeo e instalación Código fuente definitivo (con documentación incorporada)

Documentación sobre las pruebas realizadas

Manual de Usuario Pautas para migración de datos

Manual de administración y soporte técnico

Descripción general para el

funcionario no informático

Pruebas unitarias Pruebas de Integración

Carga de tablas de configuración

Migración de Datos e instalación

Capacitación si

corresponde


Versión: <1.2.0>


1.1-PARTICIPANTES EN EL PROYECTO

LOS DESARROLLADORES DEL SOFTWARE:

LOZADA CARRAZCO JONATHAN,

GUERRERO MONTERO JOSE MIGUEL

LOS USUARIOS DEL SOFTWARE:

SISTEMA DE VENTAS DE AUTOPARTES “BODEGA S.C.R.L”


Versión: <1.2.0>


1.- DESCRIPCIÓN DEL SISTEMA ACTUAL

SISTEMA DE VENTAS DE BODEGA “BODEGA S.C.R.L”

Cuando nos referimos a ventas y pagos es porque se van emitir facturas o boletas; por las compras que realizaron los cliente. Metimiento es sobre los clientes nuevos, precios nuevos, productos nuevos; al manejar la base datos de nuestro sistema tenemos con la finalidad actualizar entradas y salida de cada productos, clientes estar en contacto siempre la actualización de precios de los productos en nuestra base de datos. En caso de devolución del producto el cliente tiene que acercarse con la boleta correspondiente y el vendedor le devuelve el dinero o efectúa el cambio de producto. Al final de cierre de caja el administrador contabiliza manualmente el dinero de caja, sin tener en cuenta que productos salieron en el día. En caso de falta de productos se realiza una compra a los respectivos proveedores, los proveedores visitan mensualmente la empresa dejando a crédito los productos con un determinado plazo de pago. En caso de vencimiento del producto se realiza una devolución a los proveedores respectivos con la factura correspondiente. Levantamiento de la información: En esta sección se realizaran encuestas a los trabajadores y al administrador de la empresa, de esta forma Se pobra obtener información valiosa para el posterior diseño del sistema.


Versión: <1.2.0>


1.4 Especificación de Requerimientos de Software

1.5 Propósito

El objeto de esta especificación es definir de manera clara y precisa todas las funcionalidades y restricciones del sistema que queremos construir. El documento va dirigido al equipo de desarrollo, al grupo de calidad, a la dirección de BODEGA “Sistema de Ventas BODEGA”. y a los usuarios finales del sistema. Este documento será el canal de comunicación entre las partes implicadas, tomando parte en su confección miembros de cada parte. Esta especificación está sujeta a revisiones por el grupo de usuarios, que se recogerán por medio de sucesivas versiones del documento, hasta alcanzar su aprobación por parte de la dirección del BODEGA “Sistema de Ventas BODEGA”,

el grupo de calidad y el grupo de usuarios. Una vez aprobado servirá de base al equipo de desarrollo para la construcción del nuevo sistema.

1.6 Ámbito

El motivo por el que se impulsa el desarrollo del sistema es el requerimiento de gestionar más eficientemente el sistema de reservas de Autoparte “Sistema de Ventas bodega”, y de coordinar inmediatamente a los tres grupos de empleados existentes en el Autoparte “Sistema de Ventas bodega”. Actualmente el personal de Autoparte “Sistema de Ventas bodega”. Está utilizando un sistema manual de manera que no existe un sistema informático que automatice la gestión de las ventas. El sistema manual será reemplazado por el

sistema informático. Este futuro sistema recibirá el nombre de SVB. La carga del sistema se puede estimar teniendo en cuenta que el Autoparte “Sistema de Ventas bodega” posee 3 compartimentos para el guardado del productos de Autopartes, en la cual posee mostradores en un número máximo de autopartes de 100 productos en el cada mostrador, este sistema tendrá que ser capaz de mantener una base de datos en el servidor para gestionar datos de distintos productos.


Versión: <1.2.0>


1.7 Definiciones, Acrónimos y Abreviaciones

Definiciones

Atención al cliente Telefónico = Persona encargada de la recogida telefónica de los pedidos de los clientes.

Delivery = persona encargada de llevar el productos pedido por el cliente. Vendedor= Persona encargada de llevar a cabo el pedido del cliente. Caja registradora = Persona encargada donde emiten los pagos del cliente sobre el producto que pidió. Usuario = Persona que accede al sistema, ya sea administrador como el asistente de mostrador como personal de gerencia. Personal de Gerencia = Persona encargada de llevar a cabo tareas de gerencia. Identificador = Palabra de 5 caracteres que identifica de forma exclusiva e in equivoca a un usuario. Passport = Palabra de entre 5 y 8 caracteres. Acrónimos

ERS = Especificación de Requisitos Software SAI = Sistema de Alimentación Ininterrumpida 3 Abreviaturas SVANRPCA = Sistema de Ventas de Autopartes “Negocios Representaciones Piura Centro Aptuner S.C.R.L”

1.8 Referencias

❑ IEEE Recommended Practice for Software Requirements Specification. ANSI/IEEE

std. 830, 1993


Versión: <1.2.0>


1. Descripción General Este documento consta de dos secciones, basándonos en estándar IEEE std.830, 1993. Esta primera sección es la Introducción y proporciona una visión general de la ERS. En la sección siguiente, que corresponde con la sección 3.2 del estándar, se

definen detalladamente los requisitos funcionales que debe satisfacer el sistema.

Interfaces de sistema

El sistema debe interactuar correctamente con el sistema operativo WINDOWS XP, VISTA, 7, sobre el que se desarrollo e implanta.

Limitaciones de memoria

No se establecen limitaciones en cuanto a la cantidad de memoria, tanto secundaria como primaria que el sistema deba utilizar.

Operaciones

Modos de operación de los distintos grupos de usuarios

El tipo de usuarios es único. Se establece dos modos de operación:

De tipo interactivo y gráfico para la herramienta de configuración.

El resto de operaciones se realizan automáticamente con la invocación del programa.

Funciones respaldo del procesamiento de datos

No se utilizan, cualquier tratamiento ulterior de los datos generados corre por cuenta del usuario.

Aspectos Globales y de Seguridad

Para el ingreso al sistema cada usuario debe identificarse con el nombre de usuario y contraseña. A cada usuario le corresponde un rol.


Versión: <1.2.0>


Aspectos de rendimiento y tamaño

- Se espera que el tiempo de respuesta en el momento de presionar un botón para -

continuar con el flujo de la información que no supere los 5 segundos. - Se espera mantener la escalabilidad del sistema en relación a la concurrencia de

usuarios. (Cantidad de usuarios entre 2 y 3 concurrentes) - El sistema deberá liberar a todos los recursos de memoria al momento de cerrar una

ventana y finalizar una funcionalidad.

Datos o secuencias de inicialización específicos de cualquier lugar, modo de operación.

El sistema de ficheros debe soportar nombre de al menos siete caracteres y al menos una extensión.

Los requerimientos de memoria y disco del programa se estiman relativamente modestos a fecha actual 2012. En plataformas antiguas se debe verificar.

Características de usuario

La aplicación va dirigida a personal del AUTOPARTE “Negocios Representaciones Piura Centro Aptuner S.C.R.L”. Por tanto, se encamina a un usuario con alto nivel de capacitación y de un grado de experiencia alto.

Restricciones

El sistema debe basarse en la aplicación original, en su esquema, parámetros tratados, etc. Recordar que estamos ante un proyecto de reutilización.

Requisitos para futuras versiones del sistema

Se omite para futuras versiones la construcción de un interfaz gráfico completo que permite realizar trabajo interactivo con la aplicación.

De la misma manera, se sugiere la utilización de un sistema experto u otras técnicas apropiadas de inteligencia artificial para la toma de decisiones.


Versión: <1.2.0>


2.1 Especificación de Funcionalidades

En este apartado se presentan los requisitos funcionales que deberán ser satisfechos por el sistema. Todos los requisitos aquí expuestos son ESENCIALES, es decir, no sería aceptable un sistema que no satisfaga alguno de los requisitos aquí presentados. Estos requisitos se han especificado

teniendo en cuenta, entre otros, el criterio de “estabilidad”: dado un requisito, debería ser fácilmente demostrable si es satisfecho o no por el sistema.

2.2. Supuestos y Dependencias

Los requerimientos se asumen para cualquiera de los sistemas operativos, obteniendo los resultados en un tiempo razonable. No existen requerimientos de tiempo de respuesta, limitaciones de memoria, etc.

2.3. Acuerdos con el Cliente para la Administración de

Requerimientos

[En esta sección se define como se tratarán los cambios de los requerimientos. Normalmente en la Orden de Servicio se define un porcentaje como cota para realizar posibles cambios en los requerimientos. Este impacto se mide en la cantidad de horas/hombre que requiera esta modificación.]


Versión: <1.2.0>


3 Especificación de Requerimientos

Aquí se presenta una descripción del negocio, y en

particular el proceso de negocio más importante. Este capítulo provee el contexto y determina el alcance del resto

del documento.

Primeramente se describe el Sistema de Gestión Hotelera,

marco del Subsistema de Reservas.

Luego se presenta una descripción de éste identificando los

procesos de negocio críticos.

< Sistema de Ventas de Autopartes “Negocios Representaciones Piura Centro Aptuner S.C.R.L” >

Versión: <1.2.0>


3.1.- DIAGARAMA DE CLASES DE SISTEMA FACTURACION.

vendedores

+cod_ven+vendedor+dni+telefono+ruc+ventas+comision

+nuevo vendedor()+guardar vendedor()+modifica vendedor()+Eliminar vendedor()

usuario

+cod_usu+apnom+login+password+nivel+activo

+agregar usuario()+nuevo usario()+modificar usuario()+elimnar usuario()+salir de sistema()

facturas

+mun_fac+fecha_fac+cod_cli+cod_ven+igv+total+cod_usu

+nuevo facturas()+grabar facturas()+consultas general de factura()

item_facturas

+num_fac+cod_pro+cant+p_vta

+nuevas ventas()+eliminr ventas()

productos

-cod_pro+productos+stock+p_cos+p_lis+cod_lin+importado+stk_max+stk_min+indicacion

+Modificar Productos()+guardar Productos()+nuevo Productos()+eliminar productos()

boletas

+mun_bol+fecha_bol+cod_cli+cod_ven+cod_pro+total+n°ventas_pro

+guardar ventas()+guardar factura()+guardar boleta()

clientes

+cod_cli+cliente+direccion+telefono+ruc+fax+extrajero+refer+icredito+feching

+nuevo cliente()+guardar cliente()+modificar cliente()+eliminar cliente()

*

1

< Sistema de Ventas de Bodegas “Negocios Representaciones Piura Centro Aptuner S.C.R.L” >

Versión: <1.2.0>


3.2 Reportes de Casos de Uso

Nombre Gestionar los usuarios del sistema (CU1)

Actores USUARIO

Actividades El sistema deberá almacenar información correspondiente a

Cada usuario que se registre.

Autores JOSE G.MONTERO JONATHAN L.CARRAZCO

Datos Específicos

1. Nombre de usuario (CU3/CU6).

2. -Datos personales (Nombre y apellidos)

3. -Contraseña

Nombre GESTION DE LOS PRODUCTOS (CU2)

Actores USUARIO

Actividades NUEVO,GUARDAR,MODIFICAR,ELIMINAR PRODUCTOS

Descripción El caso de uso comienza cuando al Crear NUEVO, GUARDAR, MODIFICAR, ELIMINAR PRODUCTOS los datos se producirán algunos

cambios como nuevos productos. Datos Que verifica disponibilidad. En caso de éxito se registra los cambios y se confirma la base de datos

Datos Específicos

1. Nuevos productos ingresados.

2. Guardar productos nuevos que son traídos por el proveedor (CU7).

3. Modificar productos por operaciones del cambio de precio.

4. Eliminar Producto que ya no está en venta.


Versión: <1.2.0>


Nombre LA GESTION DE LOS VENDEDORES (CU3)

Actores USUARIO

Actividades NUEVO,GUARDAR,MODIFICAR,ELIMINAR VENDEDORES

Descripción Este caso de uso comienza cuando los vendedores son registrados sus datos se producirá algunos cambios como nuevos productos. Datos Que verifica disponibilidad. En caso de éxito se registra los cambios y se

confirma la base de datos

Datos Específicos

1. Nuevos vendedores ingresados.

2. Guardar vendedores (CU7).

3. Modificar vendedores.

4. Eliminar vendedores.

Nombre GESTION DE LOS CLIENTES (CU4)

Actores USUARIO

Actividades NUEVO,GUARDAR,MODIFICAR,ELIMINAR CLIENTES

Descripción Este caso de uso comienza cuando los clientes son registrados sus datos se producirá algunos cambios como nuevos productos. Datos Que verifica disponibilidad. En caso de éxito se registra los cambios y se confirmar en la base de datos.

Datos Específicos

1. Nuevos clientes ingresados.

2. Guardar clientes (CU7) (CU6).

3. Modificar cliente.

4. Eliminar cliente.


Versión: <1.2.0>


Nombre GESTION DE LA BOLETAS (CU5)

Actores USUARIO

Actividades GUARDAR BOLETA ,GUARDAR VENTAS emisión de facturación

Descripción Este caso de uso se va generar una factura para que el cliente tenga un comprante de lo que ha pagado de los productos obtenidos.

Datos Específicos

1. GUARDAR BOLETA.- Se identificar con su número de boleta quien fue el vendedor y el productos y sus características.

2. GUARDAR VENTAS

Nombre GESTION DE LA ITEM_FACTURAS (CU6)

Actores USUARIO

Actividades NUEVAS VENTAS , ELIMINAR VENTAS emisión de facturación

Descripción Este caso de uso sirve para ver los detalles de las compras de productos

Datos Específicos

1. NUEVAS VENTAS.- son casi todos los detalles de ventas obtenidas generadas por primera vez.

2. ELIMINAR VENTAS


Versión: <1.2.0>


Nombre GESTION DE LA FACTURAS (CU7)

Actores USUARIO

Actividades NUEVAS FACTURAS , GRABAR FACTURAS,CONSULATA GENERAL DE LAS

FACTURAS emisión de facturación

Descripción Este caso de uso sirve para ver una factura completa que emita los sistemas.

Datos Específicos

1. NUEVAS FACTURAS

2. GRABAR FACTURAS

3. CONSULTA GENERAL DE LAS FACTURAS.


Versión: <1.2.0>


3.3 Requerimientos Funcionales

1.- Captura de código de barras mediante pistola láser.

La captura debe ser de esta forma, porque es la más segura. Un ingreso del código en forma manual requiere un tiempo mucho mayor, la incomodidad de leerlo en el producto, haciendo los acomodos dentro del carro de transporte y esforzando la vista. Aparte que los errores en el ingreso de datos serían enormes. 2.- El recepcionista (el usuario) debe tener, aparte de la pistola láser, un Computador con pantalla y teclado donde ingresar las características que Contenga cada lote (por producto de bodega.). Este computador es necesario para registrar los ingresos de autopartes de forma agrupada. Como los pedidos por producto son generalmente grandes, sería sumamente agotador ingresarlos al sistema uno por uno. Así, se registra el lote una sola vez, leyendo el código de barras de un artículo de cada producto, o bien, de la caja. Luego, se digita en el computador la cantidad y la fecha de vencimiento. 3.- El sistema deberá ser capaz de ingresar cada nuevo pedido de un producto indicando fecha de ingreso, fecha de vencimiento y la cantidad de artículos. La justificación para la cantidad de artículos es la misma que la del requerimiento anterior. El ingreso de la fecha de vencimiento tiene que ver con varios requerimientos adicionales con el fin de generar un función que permita al administrador crear “packs” de productos, registrando en caja sólo un artículo, pero contando la totalidad (requerimiento funcional N° 13). Esto es fundamental para que no se vendan artículos sin contar y estropear nuestro sistema. La fecha de ingreso tiene que ver un requerimiento no funcional, que es determinar cuánto se demora en llegar un pedido desde que se necesita. 4.- Se deberá ir registrando continuamente las mermas de cada producto (Autopartes fuera de su sitio o sin pagar dentro del local o rotos), tanto en la bodega. como en sala de ventas. Esto es para no alterar el conteo de artículos cuando salen de la autoparte o salen por caja, porque, en caso contrario, el sistema los va a mostrar en la diferencia, y al momento del inventario físico van tener que ser buscados inútilmente como “extraviados”.


Versión: <1.2.0>


5.- Cada vez que se realice un inventario físico, el software deberá calcular la Diferencia entre las bodega. que han ingresado (reposiciones) y salido (ventas, mermas y vencimientos) de la sala de ventas, para cada producto, tomando en cuenta los registros llevados hasta ese momento. El mismo proceso para bodega. Esta diferencia es la que es crucial obtener, a la

hora de llevar cabo el inventario físico. Así se conoce la cantidad de artículos que no aparecen en le sistema y que el inventario físico debe buscar dentro del local para saber si todavía existen o declararlos como pérdida. 6.- La base de datos deberá tener la opción de ser actualizada, en el caso de la salida de un nuevo producto al mercado, o el retiro de alguno. Esto es porque, se podría pretender llevar el registro de ingresos y salidas de un producto que ya no existe, o bien, ingresar y vender un producto nuevo que el sistema no va a reconocer. 7.- Cada vez que se ingrese un nuevo producto, deberá leerse el código de Barras, ingresar detalle y sección.

Importante, para que al momento que el sistema indique cantidad de productos vencidos, por ejemplo, el administrador sepa de qué producto se trata (no tener que estar viendo después, en una larga lista, a qué producto corresponde un código). 8.- Cuando se ingresen los datos del punto 7, deberá asignarse automáticamente al nuevo producto un código interno del supermercado, que servirá para identificarlo más fácilmente. Esto, porque la empresa que efectúa el inventario físico (Rebuss), entrega sus datos clasificados mediante este código interno, también llamado SKU. 9.- La cantidad de los por producto en la bodega y sala de ventas deberá ser actualizada cada vez que se lleve a cabo un inventario físico, con los datos que éste arroje. No debe ocurrir lo mismo con estadísticas de ventas, promedios de tiempo de demora en llegada de pedidos y vencimientos. Se deben “resetear” las cantidades de artículos debido a que el objetivo de nuestro software es generar un respaldo al inventario físico. Si se llega a la conclusión de que faltan artículos, el inventario físico es el que va determinar su paradero, por lo que una vez terminado, el sistema debe partir a contar desde cero, sin mostrar diferencias entre los conteos (porque ya se han confirmado).


Versión: <1.2.0>


10.- Se deberá ir registrando continuamente los productos que ya estén vencidos en sala de ventas, por producto y con fecha.

Este requerimiento tiene la misma importancia que el que exige el registro de las mermas, para que no se retiren sin contar y estropeen el conteo de salida por caja. También, este requerimiento es necesario para que se cumpla uno no funcional (entregar a fin de mes el porcentaje de artículos por producto que han vencido en sala de ventas, con respecto al total de ingresados). 11.- Cada vez que se saquen productos de autopartes, para reponer en sala de ventas, se deberá descontar de los pedidos más antiguos.

Esto, porque los artículos se almacenan en bodega de tal forma, que los pedidos más antiguos son los primeros que se venden. Así, se lleva un conteo correcto de los artículos por pedido que quedan en autopartes, si los pedidos más antiguos se han terminado, y en caso de que esto no haya ocurrido, determinar la cantidad de unidades próximas a vencer. 12.- Si de un pedido registrado, aún quedan productos y quedan 15 días para que venzan, se deberá avisar al final del día, indicando producto y cantidad que queda del pedido. Este plazo se debe a que los productos no se pueden vender en una fecha más cercana a su vencimiento, debido a que muchos de los compradores son dueños de almacenes que los vuelven a vender, y se los vienen a comprar varios días después de adquirirlos en el supermercado mayorista. Este aviso se debe generar para que el administrador del local haga ofertas con dicho producto y lo saque a sala de ventas, para que se acabe pronto. 13.- El administrador debe poder ordenarle al sistema que, cada vez que se venda un producto por caja, descontar de sala de ventas dos o más artículos de éste. Esta función se llamará “registrar pack”, y deberá pedirle al usuario que ingrese el código de producto, cantidad total de las autopartes que se venderán como “packs” y cuántos artículos contendrán un “pack”.

Esta función se debe crear para considerar este tipo de ofertas que realizan los supermercados, y de esta forma, no alterar el correcto conteo de artículos por producto una vez que pasen por caja. En caso contrario, se va a contar sólo una unidad, cuando en realidad salieron más de una. Este tipo de ofertas las realizan los supermercados cuando los productos de autopartes llevan mucho


Versión: <1.2.0>


3.4 Requerimientos no Funcionales

El software debe funcionar en un PC compatible Pentium dual core i

5 de 3.5 GHz y 200 GB O 600 GB de capacidad en disco duro, 2

gb de memoria RAM. El cliente debe demostrar su producto válido de la empresa

mostrando un código de barra es para establecer el precio del productos.

El sistema debe poseer un tiempo de respuesta breve ya que es

utilizado en varios puestos de trabajo. Se entenderá máximo 10 persona en cada ventanilla o caja. En caso de producirse retraso en la emisión de su boleta o factura

usted puede ir a dar las quejas informar de la situación del problemas.

Una vez se actualizarán los datos de las ventas establecidas desde

el servidor “homewar” (servidor que mantiene la base de datos de la empresa Aptuner).

Como identificación de usuario del vendedor válido se pedirá el DNI

para acreditar un carnet de trabajo. Ingresar en la base de datos la cantidad establecida para cada producto

en autopartes (stock completo). Es necesario conocer este valor, para así

poder aplicarle el porcentaje bajo el cual se necesita un nuevo pedido.

Impresión al final del día, de un listado de todos los productos que hayan

traspasado el porcentaje bajo el cual es necesario hacer un nuevo pedido,

indicando la cantidad que debe tener. Esto le permite al administrador tener

con claridad la nómina de productos que requieren pedidos y no tener que

revisar miles de productos, uno por uno, viendo si los necesitan.


Versión: <1.2.0>


Las reposiciones de productos a la sala de ventas deberán indicar: fecha,

hora y cantidad. Con estos datos, se fija la remuneración a cada uno de los

Reponedores.

Cada mes, el último día, se le deberá entregar al administrador un listado

de todos los productos, indicando la cantidad de pedidos que se han

hecho de cada uno de ellos.

Se deberá mantener un registro, para cada producto, de la cantidad de

días que se demora en llegar un pedido a los productos de autopartes ,

desde que se necesita, más dos días por eventuales atrasos. Esta

información se obtendrá promediando la información actualizada descrita

en el punto 3.


Versión: <1.2.0>


4 Administración de Requerimientos

4.1. Restricciones

En este capítulo se presentan las restricciones normativas, de estándares y de tecnológicas, a las Cuales está sujeto tanto el proceso de desarrollo como el producto desarrollado, incluidas en las Categorías soporte, implementación, interfaces y legalidad de FURPS+. 4.1 Normativas Existen restricciones normativas, dictadas por organizaciones gubernamentales y no gubernamentales, Que determinan algunas decisiones del producto desarrollado. Licenciamiento Existe regulación de licenciamiento para aplicaciones en PIURA donde radicada la empresa de Autopartes. El licenciamiento del producto pesará totalmente sobre la aplicación back-end. Por esta razón el producto no debe limitar la cantidad de usuarios simultáneos que permite la Aplicación. Formas de pago En Piura donde Autopartes está instalada no permite el pago de servicios por Utilizando tarjetas de crédito. De esta forma no puede debitarse de tarjetas de crédito de los Clientes los servicios brindados si no es en forma presencial. Por esta razón el mecanismo de pago No será controlado directamente por el Sistema de Ventas de Autopartes. Registro Impositivo

Toda transacción comercial en Piura de residencia de las bodegas debe ser registrada y Comunicada a la Dirección General Impositiva siguiendo los procedimientos y formatos provista Por ésta. Existe un software que lleva adelante este trabajo y por lo tanto será utilizado Directamente dentro del Sistema de Ventas de Autopartes.


Versión: <1.2.0>


4.2 Estándares Lenguaje de Modelado Todo artefacto utilizado para comunicación y documentación, tanto entre miembros del equipo De desarrollo como con los clientes y usuarios, está basado en UML [UML07]. 4.3 Tecnología El desarrollo del Sistema debe estar realizado utilizando la última versión disponible de java netbeans 7.1. 4.4 Sistemas Existentes Sistema de Facturación La bodega ha adquirido un módulo de software que gestiona las cuentas de clientes, los Pagos y el registro de venta de servicios y productos. Este módulo respeta la regulación Impositiva presente en la región Piura. 4.5 Soporte El Sistema de venta bodegas tendrá mantenimiento evolutivo permanente orientado principalmente al desarrollo de nuevos módulos para cubrir nuevos servicios brindados por productos de autopartes de autos. El Subsistema de Reservas tendrá mantenimiento adaptativo, mejorando la interacción usuario máquina Mediante la adaptación de los casos de uso del subsistema. 5 Atributos de Calidad

Este capítulo describe los requisitos no-funcionales del sistema dentro de las categorías usabilidad, confiabilidad y performance descritas en FURPS+.


Versión: <1.2.0>


5.1 Usabilidad La documentación de usuario está anexada a la interfaz propiamente. En cada lugar donde se encuentre el usuario tendrá disponible una opción de ayuda (haciendo clic sobre el ícono que se muestra a la derecha) que le indicará en qué contexto se encuentra, qué información está viendo, qué Información debe proveer y cuál será la actividad que realizará el sistema una vez provista dicha información. No se proveerá documentación de usuario impresa. El Sistema de Ventas de bodegas será utilizado por clientes de todo el mundo. Adicionalmente, la Organización Pro-Turismo exige que para anunciar servicios en su portal, éstos deben ser provistos en español, inglés y portugués. Estos tres idiomas son soportados por el producto desarrollado (el usuario puede alternar entre idiomas usando el ícono a la derecha). El sistema detectará el origen del usuario para proveerle el idioma que mejor se adapte a él. 5.2 Confiabilidad El Subsistema de Reserva no debe fallar en los procesos de Hacer Reserva o Tomar Reserva. Éstos Son críticos para las bodegas. El resto de los procesos debe tener baja frecuencia de fallas, siendo más tolerante para los Procesos batch Procesar No Presentados (CU5) y Remover productos Caducas (CU6). 5.3 Performance El Subsistema de Reservas tiene fuertes restricciones de performance al momento de realizar los Cambios de guarda (CU1) y de tomar una reserva (CU4). En el caso de Hacer Reserva (CU1), estando el cliente registrado, el curso típico de eventos debe Llevar a lo sumo 5 segundos una vez que el cliente indica los detalles de su productos.


Versión: <1.2.0>


10.-Interfaces de usuario

Se especifican con prototipos de las interfaces de usuario y reportes. Éstas pueden consistir en dibujos o bocetos que muestren cómo van a ser las interfaces, aun cuando luego estos sean modificados luego. A continuación hay un prototipo de pantalla:


Versión: <1.2.0>


Cronograma de Especificación de Requerimientos del Sistema

Nº DESCRIPCION FECHA DURACIÓN

0 Versión 1.2.0 09/10/2012 ¼ de hora

1 Se ha añadido la portada 09/10/2012 ¼ de hora

2 Se ha añadido la lista de cambios 09/10/2012 ¼ de hora

3 Se ha añadido el índice de tablas y figuras 09/10/2012 ½ hora

4 Se han añadido los requisitos de información. 10/10/2012 3 horas

5 Se han añadido los casos de uso. 10/10/2012 4 horas

6 Se han añadido los requisitos no funcionales y la matriz de

rastreabilidad 11/10/2012 2 día

7 Se presento el documento de Requerimiento 14/10/2012 3 hora


Versión: <1.2.0>


Cronograma del Sistema De Ventas Autopartes “Autopartes Negocios Representaciones Piura Centro S.C.R.L”

Nº ACTIVIDAD TIEMPO CONTROL SEPTIEMBRE OCTUBRE NOVIEMBRE DICIEMBRE

1 Marco Teórico 1 E

R

2 Especificación Del Sistema 1 E

R

3 Recopilar Datos 3 E

R

4 Estructura Del Sistema 3 E

R

5 Creación De Los Módulos 4

E

R

6 Creación Del Sistema De Ventas

5 E

R

7 Elaboración De Reportes 1 E

R

8 Pruebas Al Sistema 2 E

R

9 Presentación Del Sistema

Terminado

1 E

R

E=Tiempo Estimado en Semanas R=Tiempo Real en Semanas

Sistema de Ventas de BODEGA

Documents

Transcript of Sistema de Ventas de BODEGA