Anda di halaman 1dari 74

FACULTAD DE INGENIERA DE SISTEMAS

ESCUELA PROFESIONAL DE INGENIERA DE SISTEMAS


ANLISIS Y DISEO DE SISTEMAS
TTULO
APLICACIN ANDROID PARA EL CONTROL DE DISTRIBUCIN
DELIBERY DE GLP DE LA EMPRESA SOLGAS REPSOL
AUTORES
BARRANZUELA CASTILLO, Frankmarco Andr.
YOVERA MOGOLLON, Jonatan Josas.

PROFESOR
EDWIN ARNULFO SAAVEDRA NAVARRO.

PIURA PER
2015

NDICE
I.

INTRODUCCIN........................................................................................ 4
1.1

PROPOSITO......................................................................................... 5

1.2

ALCANCE............................................................................................ 5

1.3

OBJETIVOS DEL PROYECTO.................................................................6

1.4

Proyecto............................................................................................. 6

1.5 Metodologas......................................................................................... 6
1.6

II.

Ciclo de vida del proyecto..................................................................7

1.7

Fase de Definicin...........................................................................7

1.8

Fase de Diseo...............................................................................8

1.9

Construccin y Pruebas....................................................................8

POSICIONAMIENTO DE PROYECTO............................................................8
2.1

OPORTUNIDAD DE NEGOCIO..............................................................8

2.2

SENTENCIAS QUE DEFINEN EL PROBLEMA.......................................9

2.3

SENTENCIAS QUE DEFINEN LA POSICIN DEL PRODUCTO............9

III. ORGANIZACIN DEL PROYECTO.............................................................10


3.1

Participacin en el proyecto.............................................................10

3.2

Interfaces Externas......................................................................10

3.3

Roles y responsabilidades............................................................10

IV. DESCRIPCIN DE LOS REQUERIMIENTOS................................................11


4.1 CICLO DE LA ENTREGA DE PEDIDO......................................................14
4.2 DIAGRAMA DE REQUERIMIENTO..........................................................15
4.3 Sistema.................................................................................................. 1
Registrar Pedido...................................................................................... 1
Crear Pedidos.............................................................................................. 2
Registro de boleta o Factura................................................................3
Creacin del registro de productos (Baln o Regulador).............................4
AGREGAR USUARIOS DEL SISTEMA......................................................5
Seguimiento por GPS.................................................................................. 6
Enviar ubicacin de promotor.....................................................................7
Casos de uso............................................................................................... 8
DIAGRAMAS DE SECUENCIAS.....................................................................11
Diagrama de clases................................................................................... 15
Glosario de Clases..................................................................................... 16
2

Diccionario de datos.................................................................................. 18
INTERFACES............................................................................................... 22

DEDICATORIA
A nuestros padres y maestros por su gran apoyo.

I.

INTRODUCCIN

El siguiente proyecto est basado en una metodologa de Rational Unified


Process (RUP) en la que nicamente se proceder a cumplir con las tres
primeras fases que marca la metodologa, constando nicamente en la
tercera fase de dos iteraciones.
Este proyecto se ha realizado con el fin de solucionar la problemtica de
pedidos de gas de la empresa SOL GAS.
En los ltimos aos se ha producido un crecimiento significativo en las
ventas de dispositivos mviles. Esto es uno de los motivos por el que las
aplicaciones para dispositivos mviles han generado un nuevo mercado con
grandes posibilidades de xito y sobre todo con gran impacto en los
negocios, permitiendo satisfacer necesidades de movilidad y ubicuidad. En
4

particular las empresas de distribucin de productos tienen la necesidad de


registrar pedidos, de consultar en tiempo real el stock de sus productos, y de
obtener una diferencia competitiva en relacin con otras empresas.
Las estrategias empresariales son siempre innovadoras y mucho ms
ligadas las tecnologas, por ello, en esta empresa, se requiere un registro de
pedidos sobre la plataforma Android con la que cuenta una gran variedad de
dispositivos mviles. Las empresas del primer mundo utilizan esta
tecnologa para dar un paso ms all de la competencia; en este caso
permitir agilizar el tiempo que se toma el promotor a la hora de tomar los
pedidos, minimizar los errores de registro, tener ubicacin de los promotores
y otras funciones.
En este documento se incluye el detalle para las fases de Inicio y
Elaboracin,

adicionalmente

se

esbozan

las

fases

posteriores

de

Construccin y Transicin para dar una visin global de todo el proceso.

1.1

PROPOSITO

El propsito de este documento es recoger, analizar y definir las distintas


necesidades de alto nivel y las caractersticas del sistema de gestin de una
empresa de balones de gas en las distintas zonas de Piura.
Este sistema se implementara con la intensin de reducir la prdida de
pedidos, pues estos generalmente son desatendidos debido a su saturacin.

1.2

ALCANCE

El documento ocupa, como ya se ha apuntado, el sistema de gestin de una


empresa dedicada a la distribucin de artculos de venta de GLP (Gas
Licuado de Petrleo).
Dicho sistema ser modelado y desarrollado por el grupo del 4t ciclo de
Anlisis y diseo de sistemas
El sistema permitir a los encargados de la empresa controlar todo lo
relativo a la distribucin de los artculos (gestin de stock, gestin de
pedidos, gestin de clientes, etc.).
Adems, tambin permitir a los promotores y otros empleados realizar
consultas a la base de datos para ver que clientes hicieron ms pedidos en
el mes y que sean beneficiados de alguna manera que crea conveniente la
empresa, Tambin se ha implementado un seguimiento a sus pedidos en el
rea de distribucin, etc.
1.3

OBJETIVOS DEL PROYECTO

Objetivos General

Desarrollar un sistema para el control de distribucin de la empresa Solgas


Repsol, el cual permitir una mayor eficiencia en los procesos de distribucin
y control tanto del producto como del personal encargado de dicho proceso.

Objetivos Especficos

Almacenar eficientemente los pedidos y clientes en una base de datos para


su posterior evaluacin.
Asignar al personal cada una de las tareas a realizar de manera ms rpida
y controlada.
Controlar el proceso de distribucin en cada una de sus etapas desde la
recepcin del pedido hasta la entrega del mismo al cliente final.

1 Proyecto
Un proyecto se define como un esfuerzo temporal que se lleva a cabo para
crear un producto, servicio o resultado nico (PMI, 2008). Los proyectos
6

poseen siempre una fecha de inicio y una fecha de fin, esto no significa que
sean de corta duracin, existen proyectos de semanas de duracin, as como
otros de aos de duracin.
Los proyectos generan un resultado nico, esto significa que, aunque existan
otros productos con caractersticas similares, cada uno es individual y fue
generado por un proyecto diferente. Por ejemplo, la construccin de un
edificio es un proyecto, aunque una empresa construya el mismo tipo de
edificio siempre, cada uno es nico, se construy en un momento diferente,
su dueo es otro, la ubicacin es diferente, etc.
Los proyectos se realizan de manera gradual, esto significa que se desarrolla
en pasos y aumenta mediante incrementos (PMI, 2008)

1.5 Metodologas
Las metodologas de gestin de proyectos comenzaron a gestarse en los
aos 50, en el ejrcito estadounidense, para intentar reducir el volumen de
proyectos que se descontrolaban y ayudar a solventar problemas comunes
que se haban identificado relativos a:

Exceso de carga de trabajo planificada o en proceso.


Costes que superan el presupuesto inicial.
Problemas en la calidad, valor o utilidad del resultado final.

Actualmente, la metodologa gil ms popular para la gestin de proyectos


es Scrum. Se presenta como contrapunto a PMBOK y PRINCE2, siendo
utilizada tanto para desarrollo de software como para otro tipo de productos.
Por otra parte, tambin se disponen de metodologas especficas para el
desarrollo de software que pretenden ser alternativas a estndares
como ISO/IEC 15504, ISO/IEC 12207y CMMI. Por ejemplo:

Dynamic Systems Development Method (DSDM): Metodologa gil


ms veterana y la que ms se aproxima a los mtodos
tradicionales, su implantacin incluso permitira alcanzar un nivel
2 de madurez segn CMMI.

Extreme Programming (XP): La metodologa gil ms radical y


popular. XP se centra en el ciclo de vida del desarrollo de software.

Agile Modeling: Metodologa para el modelado y la generacin de


documentacin que se encuentra alineado con los principios del
desarrollo gil y que puede ser utilizado como substituto del UML
estndar.

Feature Driven Development (FCC): Metodologa de desarrollo de


software orientada a la generacin de valor para el cliente.

1 Ciclo de vida del proyecto


Los proyectos se dividen en fases con objeto de facilitar su gestin, mejorar
el control, y mantener el proyecto alineado con los objetivos. Cada una de
las fases del proyecto culmina con la realizacin de uno o varios entregables
(plan de negocio, especificacin, documento de diseo preliminar, plan de
pruebas, etc.) Las fases suelen tomar el nombre de alguno de sus
entregables (por ejemplo, fase de diseo, fase de ensayos). Adems, cada
una de las fases puede considerarse como un subproyecto en s mismo con
fases especficas diferenciadas. El fin de cada fase viene acompaado de un
proceso de revisin cuyo objeto es:

Revisar los entregables obtenidos en la fase antes de proceder a su


aceptacin por el sponsor o cliente.
Evaluar el rendimiento del proyecto hasta la fecha prediciendo su
actuacin futura.
Determinar si el proyecto debe proceder o no a la fase siguiente. Para
ello ser necesario en muchos casos revisar el plan de negocio del
proyecto.
Revisin del plan de proyecto.
1.7 Fase de Definicin

Esta fase comienza a partir de la identificacin de una idea que tiene el


potencial de convertirse en una nueva actividad o proyecto dentro de la
organizacin. Esta idea puede ser una necesidad, una solucin original para
resolver un problema, una oportunidad o amenaza del entorno, una nueva
regulacin que es preciso implantar, el desarrollo de una tecnologa que
pueda dar lugar a una ventaja competitiva, etc. Si alguien con autoridad
dentro de la organizacin ejecutante piensa que la idea planteada merece
consideracin preliminar como proyecto y debe ser analizada ms en detalle
(no emplear mucho esfuerzo en esta decisin ya que la decisin de

acometer el proyecto se tomar en un instante posterior) la organizacin


ejecutante nombrar a un responsable de fase.

1.8 Fase de Diseo


Una vez tomada la decisin de acometer el proyecto la primera actividad
que debe realizar el director de proyecto es constituir el equipo de proyecto.
En el caso de grandes proyectos esta actividad comenzar en la fase de
definicin anterior, ya que el trabajo a realizar puede ser considerable
debido a la dimensin del proyecto, constituyendo la fase de definicin o
viabilidad un proyecto en s misma.
1.9 Construccin y Pruebas
El objetivo fundamental de esta fase es demostrar que el producto cumple
con los requisitos de cliente para as alcanzar los objetivos del proyecto. Para
ello ser preciso:

Fabricar, construir, o integrar el producto de acuerdo al diseo de la


fase anterior y de manera que ste no pierda sus caractersticas
debido a una fabricacin defectuosa.

Elaborar el plan de pruebas de acuerdo a la estrategia definida en la


fase anterior.

Validar y depurar el diseo modificando el mismo si fuera necesario a


la vista de los resultados de las pruebas. En algunos proyectos, se
distingue entre:
o

Pruebas de diseo cuyo objeto es validar el enfoque de diseo


realizado utilizando prototipos o modelos de ingeniera.

Pruebas de calificacin cuyo objetivo es demostrar que el


producto cumple con los requisitos de cliente plasmados en una

especificacin utilizando prototipos o modelos de calificacin.


Gestionar la fase de acuerdo al plan de proyecto dentro del coste
y plazo asignado.

II.

POSICIONAMIENTO DE PROYECTO
II.1

OPORTUNIDAD DE NEGOCIO

Este sistema permitir a la empresa informatizar el control de todas sus


actividades en el rea de distribucin (gestin de stock en cada agencia,
gestin de pedidos, etc.), lo cual supondr un acceso rpido y sencillo a los
datos, gracias a interfaces grficas sencillas y amigables.
Adems, los datos accedidos estarn siempre actualizados, lo cual es un
factor muy importante para poder llevar un control centralizado de las
distintas agencias para poder realizar el pedido.
Cada usuario del sistema podr realizar consultas de los pedidos registrados
las veces necesarias.

II.2

SENTENCIAS QUE DEFINEN EL PROBLEMA.


Gestionar las rdenes de pedidos realizadas por
El problema de
los clientes.
Gestionar la facturacin del pedido.
Afecta a

rea de distribucin.
Departamento de contabilidad/facturacin

El impacto asociado es

Reducir los despilfarros de tiempo en el rea de


distribucin de la empresa Sol Gas REPSOL.
Almacenar toda la informacin referente a los
almacenes, pedidos y rdenes de compra
recibidas, y que esta informacin este al instante
accesible y actualizada en lugares fsicamente
muy distantes es un proceso prcticamente
imposible de realizar en el caso de que no est
informatizado.

Una solucin adecuada


sera

Informatizar el proceso, usando Internet con una


base de datos accesible por los usuarios
registrados en la aplicacin. Esta posee un
interfaz amigable y amigable y sencillas por las
que acceder con las que acceder a dicha base de
datos.
10

II.3

SENTENCIAS QUE DEFINEN LA POSICIN DEL PRODUCTO.

Para

Jefe de almacn
Promotores de venta
Agencias distribuidora
Departamento
contabilidad/facturacin

de

Quienes

Controlan
los
pedidos,
los
almacenes (stock), las ordenes de
pedido y la facturacin.

El nombre del producto

Es una herramienta de software

Que

Almacene informacin necesaria


para gestionar una empresa de
distribucin

No como

El sistema actual

Nuestro producto

Permite gestionar las distintas


actividades de la empresa mediante
interfaces
graficas
amigables.
Adems proporciona un acceso
rpido
y
actualizado
a
la
informacin desde cualquier punto
que tenga acceso a la base de
datos.

III.

ORGANIZACIN DEL PROYECTO


III.1

Participacin en el proyecto
Jefe de Proyecto Frankmarco Andr Barranzuela Castillo con
una buena experiencia en el negocio de distribucin de GLP,
estudios en administracin, adems con una experiencia
modesta en metodologas de programacin, manejo de
Android Studio y el proceso de desarrollo RUP.
Analista de Sistemas. Jonathan Josas Yovera Mogolln, con
conocimientos de programacin en java, manejo de Eclipse,
11

estudiante de ingeniera de sistemas y manejo de lenguajes


de programacin.
Analistas - Programadores. Frankmarco Andr Barranzuela
Castillo y Jonatan Josas Yovera Mogolln, con experiencia en el
entorno de desarrollo.
Ingeniero de software: Frankmarco Andr Barranzuela
Castillo y Jonatan Josas Yovera Mogolln, con experiencia en
gestin de requisitos

Ingeniero

de

Software:

Arquitecto

de

Software,

Implantador,

Documentador.
III.2

Interfaces Externas
Roberto Len Mulanovich.

III.3

Roles y responsabilidades

Puesto

Responsabilidad
Asignar los recursos, gestiona las prioridades, coordina
las interacciones con los clientes y usuarios, y mantiene
al equipo del proyecto enfocado en los objetivos.

Jefe de
Proyecto

Establecer un conjunto de prcticas que aseguran la


integridad y calidad de los artefactos del proyecto.
Se encarga de supervisar el establecimiento de la
arquitectura del sistema. Gestin de riesgos. Planificacin
y control del proyecto.

Analista de
Sistemas

Captura,

especificacin

validacin

de

requisitos,

interactuando con el cliente y los usuarios mediante


entrevistas. Elaboracin del Modelo de Anlisis y Diseo.
12

Colaboracin en la elaboracin de las pruebas funcionales


y el modelo de datos.
Construccin
Programador

de

prototipos.

Colaboracin

en

la

elaboracin de las pruebas funcionales, modelo de datos


y en las validaciones con el usuario
Gestin

Ingeniero de
Software

de

requisitos,

gestin

de

configuracin

cambios, elaboracin del modelo de datos, preparacin


de

las

pruebas

funcionales,

elaboracin

de

la

documentacin. Elaborar modelos de implementacin y


despliegue.

IV.

DESCRIPCIN DE LOS REQUERIMIENTOS


Se nos plantea la realizacin de un sistema de software basado en
el sistema operativo Android (APK) que sirva para controlar el rea de
distribucin (Sistema delibery) de una empresa de venta de GLP: SOL
GAS, en la que en la actualidad existen una serie de usuarios
(empleados) que se comunican va celular para transmitir los pedidos
de boca en boca hasta llegar a los promotores, estos ltimos son los
encargados de la entrega del producto al cliente destino
Especficamente se requiere aprovechar las ventajas de las nuevas
tecnologas para reducir los tiempos en la distribucin y tener un
registro de los pedidos que se efectan a diario, semanal y mensual
por cada promotor y agencia de distribucin, as tambin estadsticos
sobre estos pedidos (si se lograron realizar con xito o hubo alguna
complicacin o rechazo y cul fue su causa).
Se requiere un sistema capaz de agregar usuarios y conectarlos a un
servidor donde estarn almacenados los pedidos.
Se deben poder agregar los usuarios a travs una interfaz web que
ser implementada en la pgina web ya existente en la empresa o
13

tambin se podr agregar usuarios a travs del administrador.


En la empresa podemos encontrar 4 cargos

para los cuales la

aplicacin deber moldearse pues las funciones son diferentes, los


cargos son los siguientes:

Administrador: Ser capaz de realizar cualquier modificacin


en

el

sistema

(Como

agregar

usuarios,

eliminarlos,

modificarlos, etc.), asimismo del registro de los pedidos


ingresados en la base de datos del sistema.

SAC: (Servicio de atencin al cliente) Son las personas


encargadas de la recepcin de pedidos va telfono para
luego

transmitirlos

va

la

aplicacin

la

agencia

correspondiente a la zona de destino del pedido.

Agencia distribuidora: Existen varias agencias ubicadas en


puntos estratgicos en la ciudad, en las cuales hay un
encargado por cada agencia, estos sern los que reciban los
pedidos a travs del aplicativo para luego reenviarlo al
promotor dependiendo de donde se encuentre (gracias a la
opcin de ubicacin va GPS que poseer cada promotor en su
aplicativo).

Promotor de ventas: Es el encargado de la entrega del pedido


y del trato directo con el cliente destino, l recibir los
pedidos que son enviados por su respectiva Agencia.

Se requiere que cada usuario deber contar con una cuenta de


usuario para poder tener un control sobre los pedidos en los
cuales intervendr.
Se debe tener constancia

en

qu momento la aplicacin se

encuentra ejecutndose.
El sistema tambin ha de ser capaz de enviar a los usuarios
14

mensajes de aviso ante una situacin de error, como por ejemplo,


cuando no haya conexin a internet o su cuenta se haya cerrado
inesperadamente.
As

mismo

el

administrador debe poder enviar

mensajes

de

informacin general (a travs del sistema) sobre algn cambio


realizado en el sistema o simplemente un comunicado.

15

4.1 CICLO DE LA ENTREGA DE PEDIDO

CLIENTE
MOVILIDAD

TELEFONO O CELULAR

PROMOTOR
DE VENTAS

APLICACN

SAC

AGENCIA
DISTRIBUIDO
RA

APLICACIN

4.2 DIAGRAMA DE REQUERIMIENTO


ADMINISTRADOR
AGENCIA

ASIGNAR

SAC

AGENCIA 1
REGISTRO DE

AGENCIA 2

REGISTRO DE
PEDIDOS POR DA

REENVIAR
AGENCIA 3,
REENVIAR PEDIDO

ESTADSTICO

CUENTA

CONSULTA DE

ESTADSTICO

APLICACIN

CUENTA

NUEVO

APLICACIN
SERVIDOR

APLICACIN
REGISTRO DE PEDIDOS DIARIOS

AGREGA
CALCULAR
PROMOTOR
DEPSITO DE
4.3 Sistema

MODIFICA
RAZN

ELIMINA

CONSULTA DE PEDIDOS ANTIGUOS

CUENTA
NUEVO PEDIDO

NO

ATENDIDO

ESTADSTICOS

N BOLETA
O FACTURA

Registrar Pedido
Numero de requerimientos: F1
Categora: Funcional
Descripcin corta: Agrega un pedido a la base de datos
Descripcin detallada:
Eventos ACTOR
Eventos SISTEMA

El
SAC,
agencia
distribuidora
y/o
promotor introduce los
datos del pedido en el
sistema aplicativo.

Si la direccin del pedido ya


existe, presenta los datos de
la pantalla para crear pedido.

Se grabarn los datos y se


validarn
los
datos
introducidos
- Direccin
- Familia
- Tipo de baln
- Referencia
- Medio de pago y si tiene
sencillo.
-Nmero de contacto

En caso de no existir el
Pedido, el sistema presentara
un mensaje indicando tal
circunstancia.
Observaciones: Existe la posibilidad de que un cliente manifieste
que realizar un pedido a una direccin nueva, entonces se
proceder directamente a registrar el nuevo pedido.
Trminos: personal
Prioridad: Alta
Documento: No Existe

Numero de requerimientos: F2
Autor y Fecha: Grupo de anlisis, 28/04/2015

Categora: Funcional
Descripcin corta: Aade pedidos a la base de datos.
Descripcin detallada:
Eventos ACTOR
Eventos SISTEMA

El personal SAC crea o


modifica los datos del
pedido.
Si
solo
se
pretenda
consultar el pedido, el
personal o administrador
puede
abandonar
la
pantalla.
El administrador y el
personal pueden tambin
eliminar
el
pedido
indicando la razn por la
cual se elimin.

Se grabarn los datos y se


validarn todos los datos
introducidos
- Direccin
- Familia
- Tipo de baln
- Referencia
- Medio de pago y si tiene
sencillo.
- Nmero de contacto
- Nmero de RUC (opcional)

Si se han seleccionado las


opciones de grabar o borrar,
el sistema se reposiciona en la
pantalla Ingresar Pedido
El sistema actualizar la base
de datos de pedidos (en
funcin
de
la
opcin
seleccionada, grabar o borrar)
Observaciones: Existe la posibilidad de que un cliente cambie de
domicilio y el personal acepte dicha peticin para llevar un control del
cliente.
Existe la posibilidad de que un cliente quiera cambiar Fecha Factura
(fecha de entrega) y el personal acepte dicha peticin.
Trminos: personal
Prioridad: Alta
Documento: No Existe
Autor y Fecha: Grupo de anlisis, 28/04/2015

Crear Pedidos

Numero de requerimientos: F3
Categora: Funcional
Descripcin corta: Registro de comprobante realizado por el
promotor sobre el pedido atendido.

Descripcin detallada:

Eventos ACTOR

El
promotor
debe
seleccionar en el sistema el
pedido a quien corresponde
la boleta o factura e
ingresar los mismos datos
del comprobante fsico.

Eventos SISTEMA

El sistema comprueba que


la boleta sea de un
determinado pedido que
no
tenga
ningn
comprobante registrado. Y
presentar los datos del
pedido, incluido el costo
calculado y sus detalles,
en forma de informe,
permitiendo registrar el
nmero de comprobante
(ya sea boleta o factura)
para luego ser almacenado
en el registro de pedidos
diarios del promotor y de
la agencia distribuidora

El sistema se reposiciona
en Ingresar pedido
Observaciones: El promotor debe ingresar el comprobante luego
de realizar el pedido.
Numero de requerimientos: F4
Posteriormente el informe tiene la opcin cerrar.
Trminos: personal
Prioridad: Alta
Documento: No Existe
Autor y Fecha: Grupo de anlisis, 28/04/2015

Registro de boleta o Factura

Creacin del registro de productos (Baln


o Regulador)

Categora: Funcional
Descripcin corta: Aade un producto a la base de datos.
Descripcin detallada:

Eventos ACTOR

El administrador puede
registrar nuevos tipos de
productos en el sistema,
tambin editar el precio
de cada producto (Baln
o
regulador)
o
simplemente consultar el
producto; en cualquier
caso el administrador
puede
abandonar
la
pantalla si lo requiere.

Eventos SISTEMA

Al grabar los datos se


validarn
los
datos
obligatorios:
- Fecha Entrada
- Descripcin

Si se han seleccionado las


opciones de grabar o borrar,
el sistema se reposiciona en
la el registro de productos.

Observaciones:
Si el administrador introduce el producto se ingresaran los datos
Fecha Entrada y Descripcin. Una vez creado el producto no se
podr modificar indefinidamente.
Trminos: Administrativo
Prioridad: Alta
Documento: No Existe
Autor y Fecha: Grupo de anlisis, 28/04/2015

AGREGAR USUARIOS DEL SISTEMA


Numero de requerimientos: F5
Categora: Funcional
Descripcin corta: Mantenimiento de Personal en la base de
datos (creacin, modificacin, consulta o baja).
Descripcin detallada:
Eventos ACTOR
Eventos SISTEMA

El
administrador
introduce un nombre de
personal.

Si el nombre de personal
ya existe, presenta los
datos de la misma por
pantalla.

El
administrador
introduce o modifica los
datos del personal.
Si
solo
pretenda
consultar el personal el
administrativo
puede
abandonar la pantalla.
El administrador puede
tambin
eliminar
el
personal.

Al grabar los datos se


validaran todos los datos
- Nombre
- Domicilio
- Cargo
- Localidad
- Telfono
- Notas
Si se han seleccionado
las opciones de grabar o
borrar, el sistema se
reposiciona en nombre
de personal.
es el nombre.

Observaciones: El dato identificativo


Trminos: Administrativo
Prioridad: Media
Documento: No Existe
Autor y Fecha: Grupo de anlisis, 18/09/14

Seguimiento por GPS

Numero de requerimiento F6
Categora Funcional
Descripcin corta: Seguimiento del pedido por Sistema GPS
mediante una apk o app desktop
Descripcin detallada
Eventos ACTOR
Eventos SISTEMA

La encargada de la
agencia entra al sistema
y se dirige a asignar
pedidos a los
promotores.
Si solo pretenda
consultar la ubicacin
de los promotores
puede abandonar la
ventana y salir
La encargada de la
agencia introducir la

El sistema muestra un
interfaz para asignar
pedidos a los promotores
donde habr una ventana
con los mapas de google
maps y seguido una
leyenda de la ubicacin de
los promotores.

El sistema mostrara en
pantalla la ubicacin de los

direccin del cliente

promotores y el estado de
los mismos, al seleccionar
el promotor ms adecuado
se mostrar la trayectoria
de la ruta hacia el punto
de la entrega del pedido.
Observaciones: El dato identificativo es el nombre.
Trminos: Administrativo
Prioridad: Media
Documento: No Existe
Autor y Fecha: Grupo de anlisis, 28/04/2015

Enviar ubicacin de promotor


Numero de requerimiento F7
Categora Funcional
Descripcin corta: Envo de ubicacin del promotor
Descripcin detallada
Eventos ACTOR
Eventos SISTEMA

La aplicacin ubicada en el
dispositivo del promotor,
enviara a travs del mismo
las coordenadas al
servidor, y este lo
recepciona, lo guarda en la
base de datos y finalmente
los ubica en el mapa de
google maps.

Una vez recibida la


ubicacin, el sistema
muestra en la pantalla de
la aplicacin la ubicacin
exacta del vehculo.
Observaciones: El dato identificativo es el nombre.
Trminos: Administrativo
Prioridad: Media
Documento: No Existe
Autor y Fecha: Grupo de anlisis, 28/04/2015

Casos de uso

DIAGRAMAS DE SECUENCIAS

Diagrama de clases

Glosario de Clases

USUARIO:
Esta
clase
Usuario
mientras sea de tipo administrador
posee el privilegio de agregar,
modificar, eliminar a otros usuarios, ya
sea promotor, sac, agencia u otro
administrador.
Adems
puede
consultar el total de usuarios o a cada
tipo de ellos, ya sea promotor, sac
encargado de agencia. Si no es de tipo
administrador ser de tipo SAC,
ENCARGADO DE AGENCIA
o
PROMOTOR.

SAC: Es una clase que deriva de la


clase USUARIO y se refiere a la
persona que se encarga de la
recepcin de pedidos a travs de la
lnea
telefnica.
Puede
agregar,

modificar y eliminar clientes. Adems agregar, modificar y eliminar pedidos pero para estos dos ltimos debe indicar la
RAZN por lo cual lo realizar.
ENCARGADO DE AGENCIA: Es una clase que deriva de la clase USUARIO y se refiere a la persona encargada de
alguna agencia distribuidora que se encuentra ubicada en algn punto de la ciudad. Su funcin es de retransmitir los
pedidos que le enva el SAC, al PROMOTOR. Puede agregar y modificar clientes, si desea eliminar alguno deber
comunicarse directamente con el SAC; tambin puede agregar, modificar o eliminar pedidos pero para estos dos
ltimos puntos debe indicar la RAZN por lo cual lo realizar.
PROMOTOR: Es una clase que deriva de la clase USUARIO y se refiere a la persona que se encarga de la entrega de
pedidos al cliente final, puede agregar y modificar clientes, si desea eliminar alguno deber comunicarse directamente
con el SAC, adems puede agregar, modificar o eliminar pedidos, pero para estos dos ltimos puntos debe indicar la
RAZN por lo cual lo realizar. Posee un atributo para ser ubicado por el ENCARGADO DE AGENCIA a travs del
sistema GPS que posee el dispositivo Android del celular.
AGENCIA: Es la clase que se refiere al lugar donde se almacena el producto y que es administrada por un
ENCARGADO DE AGENCIA, posee una capacidad y un nombre segn la zona donde se ubica.
PRODUCTO: Se refiere al producto que se distribuye, el cual puede ser BALON o REGULADOR. Se puede agregar,
modificar, listar o eliminar productos.
BALON: Se refiere al tipo de producto que es el GAS LICUADO DE PETRLEO, se comercializa en balones de gas de
10kg. Se pueden agregar, modificar, listar o eliminar balones.
REGULADOR: Se refiere al tipo de producto que es el REGULADOR PREMIUN, se comercializa al por menor y consta de
una vlvula de control, manguera y abrazadera para gas. Se pueden agregar, modificar, listar o eliminar reguladores.
PEDIDO: Esta clase hace referencia a los pedidos que se realizan por los clientes, se pueden agregar pedidos,
modificar, listar o eliminar.
CONTROL PEDIDOS: Esta clase se refiere al control de los pedidos para su registro en el sistema, en l se determina
el estado del PEDIDO, que puede ser NO ATENDIDO o ATENDIDO.
CLIENTE: Se refiere a los clientes que realizan los pedidos de BALON o REGULADOR. Se pueden agregar, modificar,
listar o eliminar clientes.
COMPROBANTE: Esta clase se refiere al comprobante de pago que se emite por el PROMOTOR o ENCARGADO DE
AGENCIA. Mientras que la clase sea de tipo FACTURA se requerirn los datos como RUC, precio neto e IGV (estos dos
ltimos son generados por el sistema automticamente).
ESTADISTICAS: Hace referencia a la muestra de los registros de los pedidos que han sido ATENDIDOS
ATENDIDOS. Se pueden mostrar los pedidos a travs de tablas o grficos.

y NO

ESTADISTICA_ADM: Hace referencia a la muestra de los registros de los pedidos que han sido ATENDIDOS y NO
ATENDIDOS de todos los usuarios del sistema o de cada uno de ellos. Se pueden mostrar los pedidos a travs de
tablas o grficos y adems existe la opcin de proyeccin estadstica.
ESTADISTICA_SAC: Hace referencia a la muestra de los registros de los pedidos que han sido ATENDIDOS y NO
ATENDIDOS del SAC o de la AGENCIA DISTRIBUIDORA (ENCARGADO DE AGENCIA). Se pueden mostrar los
pedidos a travs de tablas o grficos.

ESTADISTICA_PROMOTOR: Hace referencia a la muestra de los registros de los pedidos que han sido
NO ATENDIDOS por el promotor. Se pueden mostrar los pedidos a travs de tablas o grficos.

ATENDIDOS y


Diccionario de datos

NOMBRE: Usuario
CDIGO: C1
TIPO: Administrador
ATRIBUTO
Apellidos

String

Contrasea

String

DNI

String

ID

String

Nombre
String
Nivel
String
RESTRICCIONES SOBRE LA CLASE
R03:= La contrasea puede contener minimo 6 caracteres y un mximo de 15 caracteres
R05:= El DNI es nico, no pueden haber 2 personas con el mismo nmero de DNI, adems su longitud es
nicamente igual a 8 caracteres
R07:= El ID contiene un carcter de la inicial de su apellido paterno, los siguientes su DNI ms su da de
nacimiento y es nico

TIPO

REGLAS DE NEGOCIO
R01:= No nulo
R02:= No nulo
R03:= >5 & <=15
R04:= No nulo
R05:= ==8
R06:= No nulo
R07:= ==11
R08:= No nulo
R09:= No nulo

NOMBRE: Promotor
CDIGO: C2

TIPO: Usuario
ATRIBUTO

Agencia
Estado

TIPO

Agencia
String

Licencia
String
ubicacin
String
Unidad_Movil
String
RESTRICCIONES SOBRE LA CLASE
Ningun valor podra ser nulo

REGLAS DE
NEGOCIO
R10:= No nulo
R11:= Disponible
R12:= No
disponible
R13:= Ocupado
R14:= No nulo
R15:= No nulo
R16:= No nulo

NOMBRE: Encargado de agencia


CDIGO: C3

TIPO: Agencia
ATRIBUTO

TIPO

Agencia
String
RESTRICCIONES SOBRE LA CLASE

REGLAS DE
NEGOCIO
R17:= No nulo

R17:= No nulo

NOMBRE: Agencia
CDIGO: C4
TIPO: Agencia
ATRIBUTO

TIPO

REGLAS DE
NEGOCIO
R18:<=20
R19:= 4
caracteres
R20:= No nulo
R21:= No nulo

Capacidad
Cod_Agencia

Nombre
String

Ubicacin
String

RESTRICCIONES SOBRE LA CLASE


R18:= La capacidad de la agencia es de 20 balones
R19:= El cdigo de la agencia est conformado por las 2 primeras
letras de su ubicacin y las 2 ltimas por el nmero de casa

Int
String

NOMBRE: SAC
CDIGO: C5
TIPO: Usuario
ATRIBUTO

TIPO

Cod_SAC

RESTRICCIONES SOBRE LA CLASE


R23:= El cdigo del SAC est conformado por los 4 primeros nmeros

String

REGLAS DE
NEGOCIO
R22:= 4
caracteres

de su nmero de DNI

NOMBRE: Producto
CDIGO: C6
TIPO: Producto
ATRIBUTO

TIPO

REGLAS DE
NEGOCIO
Estado
Boolean
R23:= Disponible
R24:= No
disponible
NOMBRE:
Regulador Float
Precio
R25:= No nulo
CDIGO: C7
R26:>=0
Stock Producto
Int
R27:>=100
TIPO:
RESTRICCIONES SOBRE LA CLASE
REGLAS DE
ATRIBUTO
TIPO
R23:= El producto puede estar no disponible cuando tiene
alguna
NEGOCIO

R28:=
Normal
falla o esta vacio
Tipo_Regulador
Bolean
R26:= El precio de los productos en algunas ocasiones
es cero,
ya que
R29:=
Premium
N_Serie
String
R30:= 9
la empresa algunas veces tiene
promociones
caracteres
RESTRICCIONES SOBRE LA CLASE:
R19:= El nmero de serie se ingresara por teclado y ser de nueve
caracteres (nmeros)
NOMBRE: Baln
CDIGO: C8
TIPO: Producto
REGLAS DE
ATRIBUTO
TIPO
NEGOCIO
R31:= Normal
Tipo_balon
Bolean
R32:= Premium
RESTRICCIONES SOBRE LA CLASE:
R31, R32:= Los valores no pueden ser nulos

NOMBRE: Detallle
CDIGO: C9
TIPO: Detalle
NOMBRE:
Pedido

ATRIBUTO
CDIGO: C10
TIPO: Pedido
Cantidad
ATRIBUTO

Int

TIPO

TIPO

Producto
Producto
Direccion
String
Tipo_Producto
Boolean
Familia
String
Cambio_soles
Int
RESTRICCIONES SOBRE LA CLASE:
R26:= Se debe seleccionar Baln
y/o regulador.
Cambio_dolares
Float
Razon
String
Referencia
String
RESTRICCIONES SOBRE LA CLASE:
La razon puede ser nula
NOMBRE: Cliente
CDIGO: C15
TIPO: Cliente
ATRIBUTO

REGLAS DE
NEGOCIO
R33:=>0
REGLAS DE
R34:= Regulador
NEGOCIO
R35:=
R38:=Balon
No Nulo
R36:=
Normal
R39:=No
Nulo
R37:=
Premium
R40: >=40
&<=200
R41: >=2.00 &
<=4.00

R42:= No Nulo

TIPO

Nombre
String
Apellidos
String
Direccion
String
Ubicacin
String
Telefono
String
RESTRICCIONES SOBRE LA CLASE:
R31:=No debe de haber

REGLAS DE
NEGOCIO
R27:= No Nulo
R28:= No Nulo
R29:= No Nulo
R30:=No Nulo
R31:= No Nulo

INTERFACES

SAC

AGENCIA DISTRIBUIDORA

PROMOTOR

Anda mungkin juga menyukai