< Sistema VIERNES, 12 de Ventas de Autopartes “Negocios Piura Centro Aptuner S.C.R.L” > DE Representaciones OCTUBRE Especificación de Requerimientos de Software DE 2012
Versión:
<1.2.0>
Fecha:
Sistema de Ventas de Autopartes “Negocios
Representaciones Piura Centro Aptuner “S.C.R.L”
Especificación de
< Sistema de Ventas de Autopartes “Negocios Representaciones Piura Centro Aptuner S.C.R.L” > Especificación de Requerimientos de Software
Versión:
<1.2.0>
Fecha:
Índice 1. Introducción …………………………………………………………………….. 3 1.1 Participantes del software ………………………………………………...4 1.2. Descripción del sistema actual …………………………………………...5 1.3. Objetivo de la investigación ……………………………………………..6 1.3.1. Objetivo general………………………………………………….. general…………………………………………………. . 1.3.2 objetivos específicos ………………………………………………..
1.4 Especificación de Requerimientos de Software…………………………………7 1.5 Propósito……………………………………………………………………………………….. 1.6 Ámbito…………………………………………………………………………………………… 1.7 Definiciones, Acrónimos y Abreviaciones……………………………………..8 1.8 Referencias……………………………………………………………………………………..
2. Descripción General ……………………………………………………… ....9 ....9 2.1. Especificación de Funcionalidades…………………………………………… ..11 2.2. Supuestos y Dependencias………………………………………………………… 2.3. Acuerdos con el Cliente para la Administración de…………………….. Requerimientos 3. Especificación de Requerimientos ……………………..……………………..12 3.1. Reportes de Casos de Uso……………………………………………………………. 3.2. Requerimientos Funcionales……………………………………………………….16 3.3. Requerimientos no Funcionales………………………………………………….19 4. Administración de Requerimientos……………………………………………….21
< Sistema de Ventas de Autopartes “Negocios Representaciones Piura Centro Aptuner S.C.R.L” > Especificación de Requerimientos de Software
Versión:
<1.2.0>
Fecha:
1. Introducción Con el desarrollo de este proyecto se generara un cambio mayor que agilizara los procesos de autopartes en la emisión de facturas y boletas; en venta y pago de los productos como los repuesto de autos, motos, etc. Tiene el ofrecimiento y/o antojo de los clientes, tenemos los mejores productos y precios cómodos al alcance de los clientes, además se obtendrá facilidad, eficacia y confiabilidad al momento de realizar las operaciones correspondientes; manipular el sistema con la finalidad de que los procesos como la emisión de facturas y boletas sean rápido satisfactorios para que el cliente este satisfecho del proceso de cómo se maneja este sistema. Este sistema permite una facilidad a la hora de ser manipulado que la interacción con el usuario o administrador son muy especificadas. Este proyecto nos intereso por varias razones porque vimos la necesidad de diseñar programar un sistema que va dirigido al mercado de autopartes la región Piura hay empresas con rubro de autopartes la cual muchas de estas empresas no cuentan con el sistema adecuado e/u otras empresas no tienen sistemas. Bueno este proyecto nos costó
< Sistema de Ventas de Autopartes “Negocios Representaciones Piura Centro Aptuner S.C.R.L” > Especificación de Requerimientos de Software
Versión:
<1.2.0>
Fecha:
1.1-PARTICIPANTES EN EL PROYECTO
LOS DESARROLLADORES DEL SOFTWARE: LOZADA CARRAZCO JONATHAN,
< Sistema de Ventas de Autopartes “Negocios Representaciones Piura Centro Aptuner S.C.R.L” > Especificación de Requerimientos de Software
Versión:
<1.2.0>
Fecha:
1.2.-DESCRIPCIÓN DEL SISTEMA ACTUAL SISTEMA
DE
VENTAS
DE
AUTOPARTES
REPRESENTACIONES PIURA CENTRO APTUNER S.C.R.L ”
“ NEGOCIOS
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
< Sistema de Ventas de Autopartes “Negocios Representaciones Piura Centro Aptuner S.C.R.L” > Especificación de Requerimientos de Software
Versión:
<1.2.0>
Fecha:
1.3.- OBJETIVO DE LA INVESTIGACIÓN 1.3.1.- OBJETIVO GENERAL
sistema de ventas de autopartes representaciones Piura centro Aptuner s.c.r.l ” Desarrollar
un
“negocios
1.3.2.- OBJETIVOS ESPECÍFICOS
Recopilar de información. Analizar el sistema ventas de autopartes “Negocios Representaciones Piura centro Aptuner s.c.r.l” Diseñar el
sistema ventas de autopartes “Negocios Representaciones Piura
< Sistema de Ventas de Autopartes “Negocios Representaciones Piura Centro Aptuner S.C.R.L” > Especificación de Requerimientos de Software
Versión:
<1.2.0>
Fecha:
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 Autoparte “Sistema de Ventas Autopartes”. 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 Autoparte “Sistema de Ventas Autopartes” , 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 Autopartes” , y de coordinar inmediatamente a los tres grupos de empleados existentes en el Autoparte “Sistema de Ventas Autopartes”. Actualmente el personal de Autoparte “Sistema de Ventas Autopartes”. Está
< Sistema de Ventas de Autopartes “Negocios Representaciones Piura Centro Aptuner S.C.R.L” > Especificación de Requerimientos de Software
Versión:
<1.2.0>
Fecha:
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
< Sistema de Ventas de Autopartes “Negocios Representaciones Piura Centro Aptuner S.C.R.L” > Especificación de Requerimientos de Software
Versión:
<1.2.0>
Fecha:
2. 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.
< Sistema de Ventas de Autopartes “Negocios Representaciones Piura Centro Aptuner S.C.R.L” > Especificación de Requerimientos de Software
Versión:
<1.2.0>
Fecha:
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 se gundos.
-
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
< Sistema de Ventas de Autopartes “Negocios Representaciones Piura Centro Aptuner S.C.R.L” > Especificación de Requerimientos de Software
Versión:
<1.2.0>
Fecha:
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
< Sistema de Ventas de Autopartes “Negocios Representaciones Piura Centro Aptuner S.C.R.L” > Especificación de Requerimientos de Software
Versión:
<1.2.0>
Fecha:
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.
3.1 Reportes de Casos de Uso Nombre
Gestionar los usuarios del sistema (CU1)
Actores Actividades
USUARIO
Autores Datos Específicos
El sistema deberá almacenar información correspondiente a Cada usuario que se registre. JOSE G.MONTERO JONATHAN L.CARRAZCO
1. Nombre de usuario (CU3/CU6).
< Sistema de Ventas de Autopartes “Negocios Representaciones Piura Centro Aptuner S.C.R.L” > Especificación de Requerimientos de Software
Versión:
<1.2.0>
Fecha:
Nombre
GESTION DE LOS PRODUCTOS (CU2)
Actores Actividades
USUARIO NUEVO,GUARDAR,MODIFICAR,ELIMINAR PRODUCTOS 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
Descripción
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.
Nombre
LA GESTION DE LOS VENDEDORES (CU3)
Actores Actividades
USUARIO NUEVO,GUARDAR,MODIFICAR,ELIMINAR VENDEDORES 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
Descripción
< Sistema de Ventas de Autopartes “Negocios Representaciones Piura Centro Aptuner S.C.R.L” > Especificación de Requerimientos de Software
Versión:
<1.2.0>
Fecha:
Nombre
GESTION DE LOS CLIENTES (CU4)
Actores Actividades
USUARIO NUEVO,GUARDAR,MODIFICAR,ELIMINAR CLIENTES 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.
Descripción
Datos Específicos 1. Nuevos clientes ingresados. 2. Guardar clientes (CU7) (CU6). 3. Modificar cliente. 4. Eliminar cliente.
Nombre
GESTION DE LA BOLETAS (CU5)
Actores
USUARIO
Actividades
GUARDAR BOLETA ,GUARDAR VENTAS emisión de facturación
< Sistema de Ventas de Autopartes “Negocios Representaciones Piura Centro Aptuner S.C.R.L” > Especificación de Requerimientos de Software
Versión:
<1.2.0>
Fecha:
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
Nombre
GESTION DE LA FACTURAS (CU7)
Actores Actividades
USUARIO
Descripción
Este caso de uso sirve para ver una factura completa que emita los
NUEVAS FACTURAS , GRABAR FACTURAS,CONSULATA GENERAL DE LAS FACTURAS emisión de facturación
< Sistema de Ventas de Autopartes “Negocios Representaciones Piura Centro Aptuner S.C.R.L” > Especificación de Requerimientos de Software
Versión:
<1.2.0>
Fecha:
3.2 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 autopartes). 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
< Sistema de Ventas de Autopartes “Negocios Representaciones Piura Centro Aptuner S.C.R.L” > Especificación de Requerimientos de Software
Versión:
<1.2.0>
Fecha:
5.- Cada vez que se realice un inventario físico, el software deberá calcular la
Diferencia entre las autopartes 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 AUTOPARTE. 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,
< Sistema de Ventas de Autopartes “Negocios Representaciones Piura Centro Aptuner S.C.R.L” > Especificación de Requerimientos de Software
Versión:
<1.2.0>
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.
< Sistema de Ventas de Autopartes “Negocios Representaciones Piura Centro Aptuner S.C.R.L” > Especificación de Requerimientos de Software
Versión:
<1.2.0>
Fecha:
3.3 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).
< Sistema de Ventas de Autopartes “Negocios Representaciones Piura Centro Aptuner S.C.R.L” > Especificación de Requerimientos de Software
Versión:
<1.2.0>
Fecha:
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.
< Sistema de Ventas de Autopartes “Negocios Representaciones Piura Centro Aptuner S.C.R.L” > Especificación de Requerimientos de Software 4
Versión:
<1.2.0>
Fecha:
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 Autopartes debe ser registrada y
< Sistema de Ventas de Autopartes “Negocios Representaciones Piura Centro Aptuner S.C.R.L” > Especificación de Requerimientos de Software
Versión:
<1.2.0>
Fecha:
4.4 Sistemas Existentes
Sistema de Facturación La cadena Autopartes 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 Autoparte 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+. 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 Autopartes será utilizado por clientes de todo el mundo.
< Sistema de Ventas de Autopartes “Negocios Representaciones Piura Centro Aptuner S.C.R.L ” > Especificación de Requerimientos de Software
Versión:
<1.2.0>
Fecha:
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
< Sistema de Ventas de Autopartes “Negocios Representaciones Piura Centro Aptuner S.C.R.L ” > Especificación de Requerimientos de Software
Versión:
<1.2.0>
Fecha:
Cronograma del Sistema De Ventas Autopartes “Autopartes Negocios Representaciones Piura Centro S.C.R.L”
Nº
ACTIVIDAD
1
Marco Teórico
2
Especificación Del Sistema
3
Recopilar Datos
4
Estructura Del Sistema
5
Creación De Los Módulos
6
Creación Del Sistema De Ventas
7
Elaboración De Reportes
8
Pruebas Al Sistema
9
Presentación Del Sistema Terminado
E=Tiempo Estimado en Semanas R=Tiempo Real en Semanas
TIEMPO CONTROL 1 E R 1 E R 3 E R 3 E R 4 E R 5 E R 1 E R 2 E R 1 E R
SEPTIEMBRE
OCTUBRE
NOVIEMBRE
DICIEMBRE
