CAPITULO III

4.1 LA PROPUESTA

Aplicación móvil que facilitara el control y la administración de pedidos

con ayuda de la geolocalización que permitirá a la empresa y clientes
supervisar las rutas de los pedidos.

4.2 Justificación de la propuesta

4.3 Desarrollo de la propuesta

El desarrollo de la propuesta se basa en cada una de las fases para el

desarrollo de una aplicación móvil según la metodología Extreme
Programming (XP) las cuales son: La fase de Planificación en donde se
analiza involucrados y requerimientos de software. La fase de Diseño donde
está toda la parte de diagramación, La fase de Codificación que es
concretamente la fase de programación.

Fase I (Planificación)

Descripción de los Interesados (Stakeholders): En la siguiente matriz se

puede apreciar cuales son los stakeholders o involucrados en el proyecto de
desarrollo de la aplicación, para dispositivos móviles Android para
administrar pedidos y controlar rutas de los vendedores, aplicada a la
empresa Grishakura C.A.

NOMBRE CARGO INSTITUCION RELEVANCIA

PROYECTO (1-5)
 Adm. Carlis Gerente Grishakura C.A. 5
Mejías Administrativo
Ing. Alirio Ingeniero de Grishakura C.A. 5
González Sistemas
Alex Mon Supervisor de Ventas Grishakura C.A. 3
Alejandro Mora Jefe Dto. Crédito y Grishakura C.A. 3
Cobranza
Ines Maldonado Facturadora Grishakura C.A. 2
Juan Carlos Agente Vendedor Grishakura C.A. 3
Ordoñez
Todos cumplen un papel fundamental dentro de la aplicación a
desarrollar pero unos tienen más relevancia que otros, para un mejor
entendimiento de las funciones ver la tabla siguiente.
Cargo o Dto. Descripción Responsabilidad
Gerencia Persona encargada de la parte  Autorizar contratación
Administrativa de la empresa personal
 Tomar decisiones
administrativas de la
empresa
Sistemas Persona encargada de los  Administración Base de
Sistemas existentes de la datos
empresa y de los  Desarrollar
requerimientos de Software requerimientos de
software
Supervisor de Persona encargada de revisar  Revisar cada uno de
los Pedidos y de Controlar y a los pedidos para
Ventas
los diferentes Agentes entrega material
Vendedores publicitario
 Aprobar o desaprobar
pedidos
Facturación Encargada de facturar las  Ingresar manualmente
diferentes órdenes de pedido los pedidos al sistema.
 Facturar el pedido
ingresado.
Ventas Persona que recepta los  Recorrer rutas
pedidos de los clientes asignadas y visitar a
los diferentes clientes
  Receptar los pedidos
de clientes

Requerimientos funcionales del proyecto

La aplicación estará compuesta de 4 partes o módulos en las cuales se
va a detallar cada una de las opciones con las que contara:
1. Pedido
a. Seleccionar Cliente
b. Añadir Articulo por:
i. Catalogo
ii. Código
c. Guardar posición en GPS
d. Detallar Pedido:
i. Seleccionar Dirección Entrega
ii. Adelanto (En caso de haberlo)
iii. Forma de Pago
iv. Descripción
e. Visualizar resumen del Pedido
2. Catalogo
a. Visualizar Tipo
b. Visualizar Marca
c. Visualizar detalle del Articulo seleccionado
3. Modificar Pedido
a. Selección del Pedido
i. Modificar Dirección de Entrega
ii. Modificar Adelanto (En caso de haberlo)
iii. Modificar Forma de Pago
iv. Modificar Descripción
4. Ayuda
a. Visualizar ayuda (Texto HTML)
 En cuanto a la Intranet que usara el supervisor de Ventas constara de
las siguientes opciones:
1. Inicio de Sesión
2. Visualizar en Mapa puntos de referencia
a. Ver Detalle (Movimientos)
b. Ver Mapa (Visualizar Recorrido)
Para un mejor entendimiento podemos revisar más adelante la
interacción de los Usuarios con los diferentes módulos en los Casos de Uso.
Requerimientos No Funcionales de la Aplicación
 Rendimiento de la Aplicación:
 La aplicación ofrecerá respuesta (datos) al usuario en tiempo
real.
 El tiempo de respuesta promedio de la aplicación no debe
superar los 10 segundos.
 Seguridad
 Requisito de conexión. (Debe verificar que sea un usuario
creado para la aplicación por lo que consulta directamente en la
Base de Datos para acceder a la aplicación.). Este caso aplica
tanto para la Aplicación como para la Intranet.
 Disponibilidad
 La aplicación estará disponible el 100% del tiempo, ya que se
trata de una aplicación nativa que se instalara en el dispositivo
móvil.
 En cuanto a la Intranet esta también estará siempre disponible
ya sea localmente en la empresa o fuera de ella ya que esta
publicada al internet para acceder mediante la página web de la
empresa.
 La aplicación dependerá de una conexión a internet o plan de
datos solo para el envío de información. En caso de no tener
conexión a internet la misma se guardara en la aplicación
 (localmente) y se reenviara una vez que tenga conexión a
internet.
 La aplicación por ahora no será cargada al Google Play Store
de Android ya que al ser una aplicación para una empresa
privada se limitara a que solo el personal encargado lo instale
en los respectivos dispositivos de los usuarios de la aplicación.
 Mantenibilidad
 El sistema estará en constante mantenimiento ya que se podría
agregar nuevas funcionalidades o realizar modificaciones o
correcciones.
 Portabilidad
 Compatibilidad con plataformas: En el sistema desarrollado
ofrece compatibilidad con otras plataformas Android desde la
versión 4.0. ya sea en una Tablet o en un Smarthphone.
 La intranet es compatible con todos los navegadores pero se
recomienda el uso de Internet Explorer desde la Versión 8.
Para una mejor visualización, también se recomienda actualizar
a la última versión del navegador.
 Operabilidad
 La aplicación solo podrá ser operada por un empleado de la
empresa Grishakura C.A. y que tenga su debido usuario y
contraseña, de igual forma para el ingreso a la Intranet.
Restricciones
El dispositivo móvil en donde se ejecutara la aplicación para su correcto
funcionamiento deberá tener los siguientes requisitos mínimos, debido a que
necesitamos velocidad de procesamiento al manejar una gran cantidad de
información, además necesitaremos almacenamiento para la base de datos
local donde se almacenara la información descargada.
 Procesador: 1 Ghz Dual Core.
 Memoria RAM: 1GB.
  Almacenamiento: 30 MB disponibles.
 Pantalla de 7’’ pulgadas en adelante.
 Sistema operativo. Android 4.0 o superior.
 GPS con soporte A-GPS
Se ha considerado la versión de Android 4.0 Ice Cream Sandwich o
superior ya que la aplicación será programada con el API 15 como mínima,
correspondiente a esta versión.
Para poder enviar los pedidos y posteriormente se grabe en la base de
datos en el dispositivo móvil se necesita de una conexión a Internet ya sea
Wifi o Plan de Datos móviles.
Si por alguna razón no se tendría conexión a internet, la información se
graba localmente (en el dispositivo) y se enviara una vez que se tenga
conexión.
Para la parte de la Intranet y los requisitos mínimos serian:
 Computador Dual Core o superior.
 Memoria 1GB RAM, 120 GB Disco Duro o superior.
 Navegador Internet Explorer 8 o superior.
 Conexión a la intranet de la empresa (red interna).
Todas las restricciones descritas y analizadas anteriormente es solo
una sugerencia para el óptimo funcionamiento de la aplicación es decir que
sea rápida y tenga una buena visualización, y no quita o restringe que la
aplicación pueda funcionar en dispositivos de menor gama o incluso en
Smarthphone que tiene la pantalla más pequeña.

Fase de Diseño

Se elaboraran diseños breves que sirven de referencia para la

implementación. Otra práctica fundamental de la metodología de
Programación Extrema es utilizar diseños tan simples como sea posible. El
principio es utilizar el diseño más sencillo que consiga que todo funcione
evitando diseñar características extra y que tomaran demasiado tiempo. Para
esta fase se implementara el modelado UML ya que se puede usar para
modelar distintos tipos de sistemas: sistemas de software, sistemas de
hardware, y organizaciones del mundo real. UML ofrece varios diagramas en
los cuales modelar sistemas.
En este caso se ha optado en la realización de los Diagramas más
relevantes los cuales son:
 Diagramas de Casos de Uso.
 Diagramar de Clases.
 Diagramas de Secuencia.
A parte de los modelados UML vamos a complementar el diseño con
modelos como el Arquitectónico con el objetivo de ofrecer una visión
simplificada del sistema, de forma que una persona pueda mirar el diagrama
y entender de una pasada lo que se quiere conseguir o desarrollar. Y el de
Navegación el cual nos ayudara en la comprensión del orden de
presentación de las pantallas de nuestra aplicación con los contenidos y los
vínculos que existen en cada una de ellas.

Diagrama de Casos de Uso

Identificación de los Actores.
Actores de la Aplicación de Pedidos
Agente Vendedor Usar la aplicación, Realizar pedidos.
Supervisor Ventas Ingresar Intranet empresa, Revisión pedidos
ingresados, asignar material publicitario.
Jefe Cartera Ingresar Intranet empresa, Aprobar o Rechazar
pedidos de acuerdo a la cartera del cliente.
Casos de uso general de la aplicación de pedidos.

Interacción del Agente Vendedor en el escenario de la aplicación de

pedidos.

Caso de uso número 1:

Aplicación de Pedidos

Ingresar a la aplicación

Consulta de Catálogo

Crear Pedidos
Agente
Vendedor

Modificar Pedidos

Especificación de Casos de Uso:

CASO DE USO NUMERO 1
Nombre Ingresar a la Aplicación.
Descripción Identificar al usuario para el uso de la Aplicación.
Actores Agente Vendedor.
Precondición  Conexión a la base de datos satisfactoria.
 Tener un usuario registrado por el administrador.
 Que la aplicación se haya ejecutado.
 Flujo de Sistema Paso Acción
1 La aplicación despliega ventana de inicio de Sesión.
2 El agente vendedor ingresa su respectivo usuario y
contraseña.
3 La aplicación valida los datos ingresados en la base
de datos.
4 La aplicación muestra la interfaz gráfica para el
usuario.
Post Condición  Si el agente vendedor digital mal su contraseña
varias veces el usuario ingresado se bloquea.

Caso de uso número 2:

Crear Pedido
Seleccionar Consultar
Nombre
Cliente Cliente
Datos del
Cliente
Detallar
Agregar artículos
Pedido
Al pedido

Enviar Sincronizar
Agente Pedido Datos Pedido Información
Vendedor

CASO DE USO NÚMERO 2

Nombre Crear pedido.
Descripción Crear pedido en la aplicación.
Actores Agente Vendedor.
Precondición  Estar conectado a una red Wifi o de datos
 Iniciar sesión correctamente
 Sincronizar la información correctamente

Paso Acción
1 El agente vendedor elige la opción de Pedido en el
Flujo de Sistema Menú.
 2 La aplicación le pide que seleccione “Cliente”.

3 El agente vendedor selecciona el cliente.

4 La aplicación pide que seleccione los Artículos ya

sea por catálogo o ingresa por código.
5 El agente vendedor selecciona los artículos que
desea comprar el cliente.
6 La aplicación guarda la posición en GPS
automáticamente.
7 La aplicación pide que seleccione “Dirección de
entrega, así como el adelanto y la forma de pago”.
8 El agente vendedor selecciona o modifica Dirección
de Entrega, así como el adelanto y la forma de pago.
9 La aplicación muestra el Detalle del pedido
generado.
10 El agente vendedor graba el pedido realizado.

Post Condición  Si la aplicación detecta conexión a internet envía el

Pedido caso contrario lo almacena localmente.

Caso de uso número 3:

CASO DE USO NÚMERO 3

Nombre Consultar Catálogo.
Descripción Mostrar artículos disponibles debidamente organizados.
Actores Agente Vendedor.
Precondición  Estar conectado a una red Wifi o de datos
 Iniciar sesión correctamente
 Sincronizar la información correctamente

Paso Acción
1 El agente vendedor elige la opción de Catálogo en el
Menú.
Flujo de Sistema 2 La aplicación muestra los artículos organizados por
Tipo y Marca.
 3 El agente vendedor visualiza los artículos existentes
con sus características.
Post Condición  El agente vendedor puede ver el Catálogo existente o
puede regresar al Menú Principal.

Caso de uso número 4:

El caso de uso número 4 de Modificar Pedido viene siendo casi lo

mismo que el caso de uso número 1 de Crear Pedido, con la única diferencia
que el Pedido ya estará creado y para poder Modificarlo el agente vendedor
lo seleccionara previamente.

Caso de uso número 5:

Intranet
Empresa
Ingresar al
Sistema

Aprobar o Jefe de
Desaprobar
Cartera

Supervisar Agregar
Pedidos Material

Revisar Ruta
Agente Visualizar
De
Recorrido
Vendedor

CASO DE USO NÚMERO 5

Nombre Revisar ruta de vendedores.
Descripción Supervisar el recorrido de cada Agente Vendedor mediante
un mapa.
 Actores Supervisor de Ventas.
Precondición Disponer de un computador que tenga algún
navegador instalado.
 Haber ingresado con su respectivo usuario y
contraseña.
 Estar conectado a la red interna de la empresa o
externamente mediante internet.
Paso Acción
1 El actor ingresa a la dirección de la intranet en el
navegador.
2 La aplicación web muestra la ventana para iniciar
sesión.
3 El actor ingresa su debido usuario y contraseña.
4 La página web muestra las operaciones permitidas al
actor.
5 El actor selecciona la operación que desea realizar
Flujo de Sistema en la web.
6 La página web muestra diversos filtros para dibujas
en el mapa.
7 El actor ingresa criterios de búsqueda en el mapa.
8 La página web muestra el recorrido en el mapa
según criterios ingresados, con información
detallada.
9 El actor puede realizar más búsquedas.
Post Condición  El supervisor de ventas puede realizar otras
operaciones en la página web como revisar pedido.

Diagrama de Clases

El diagrama que se mostrara a continuación está directamente

relacionado con las clases que se utilizaran en la aplicación móvil.
 DETALLE_PEDIDO_SUGERIDO
DIRECCION_ENTREGA PEDIDO_SUGERIDO
-ARTCOD
-CLICVE -CLICVE
-ARTDES
-CLDCEN -ARTBOD
-INDMAD
-CLDDIR -DOCCAN
-INDSED
-CLDTE1
-INDSUB
-CLDCOL
-UMECVE
-CLDPOB CLIENTE ARTICULO -ARUFAC
-CODIGO -CODIGO -CLICVE
-CLIRFI -DESCRIPCION -CANTIDAD
FORMA_PAGO -CLCNOM -INDMAD
-CPACVE -CLINOM -INDSED CATALOGO
-CPADES -CLIDIR -INDSUD -ARTCOD PROMOCIONES
-CLIALE -UMECVE -ARTDES
-CLITE1 -ARUFAC -PRTLIN
-INDMAD
-LPRCVE -IMGEST -PRTPRO
CARTERA -INDSED
-SICCVE -CONIVA -PRTART
-CLICVE -INDSUB
-CLIRCR -PRECIO -PRTRN1
-DOCREF -UMECVE
-CPACVE -MAXIMO -PRTRN2
-VALREF -ARUFAC
-MAXDSC getARTCOD () -PRTDCSC
-SALREF -IMGEST
-NUMREF -CLICOL getARTDES () -CONIVA
-FECREF -CLIPOB getINDMAD ()
-VENREF -CLILAT getINDSED ()
-VALRET -CLILON
getARTCOD () INVENTARIO DESCRIPCION_ALM
getARTDES () -ARTCOD -ALMCVE
getINDMAD () -ALMCVE -ALMDES
getINDSED () -EXICAN -Nombre del
-EGRCAN miembro

DETALLE_PEDIDO
CLIENTE_RUTA CABECERA_PEDIDO -DDOCVE CABECERA_LISTA_
-DDOCVE -DOCREF DETALLE_LISTA_PRECIO PRECIO
-CODCL
-RUTV1 -DOCREF -DOCPAR -LPRCVE -LPRCVE
-ERLV1 -DOCDES -ARTCOD -ARTCOD -LPRPRE
-RUTV2 -CLICVE -ALMCVE -LPRPRE
-ERLV2 -LPRCVE -DOCCAN
-RUTV3 -CPACVE -DOCPRE
-ERLV3 -CLDCEN -DOCIDG
-DOCFEC -DOCISN
-DOCUPR -DOCFEC
Diagramas de Secuencia

Diagrama de Secuencia, Inicio de Sesión.

Diagrama de Secuencia, Enviar Pedido.
Diagrama de Secuencias, Interacción con la Internet
Diagrama Arquitectónico
Diagrama de Navegación
El diagrama de Navegación indica o muestra el orden de relación de las
pantallas o componentes del software, y sirve para la comprensión del orden
de presentación de las pantallas, con los contenidos de la aplicación.
Boceto de la pantalla de Inicio de Sesión

Boceto de la pantalla del Menú

Boceto de la Pantalla del Catálogo

Boceto de la Pantalla de Pedido

Boceto de la Pantalla de Ayuda