Proyecto Facing

Estudiantes

Rodrigo Abel
B.
Andres Brito M.
Patricio Carrasco V.
Hector Cisterna M.
Camila Sanhueza N.
Sebasti
an Teran H.

Profesor de C
atedra

Beatriz Marn Campusano

Ayudante

Nicol
as Rosso Chamorro

Asignatura

Ingeniera de Software

Carrera

Ingeniera Civil en Informatica y Telecomunicaciones

Fecha

16 de junio de 2014

Indice
1. Introducci
on

2. Conformaci
on del equipo de trabajo

2.1. Jefe de proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.2. Analista . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.3. Dise
nador . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.4. Programador . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.5. Documentador . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.6. Quality Assurance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.7. Stakeholder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3. Descripci
on del cliente

3.1. Algunas de las aplicaciones desarrolladas por Skillup . . . . . . . . . . . . . . . . . . .

4. Descripci
on del problema a resolver (BPMN)

5. Objetivos del proyecto

5.1. Objetivo general . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5.2. Objetivos especficos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

6. Alcances del proyecto

7. Descripci
on preliminar de la soluci
on inform
atica (BPMN)

8. Recursos requeridos para la implementaci

on

9. Resultados esperados

10

10.Impactos del proyecto

10

10.1. Positivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

10

10.2. Negativos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

11

11.Listado de requisitos

11

11.1. Requisitos funcionales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

12

11.2. Requisitos no funcionales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

13

12.Diagrama de actividades que muestre el proceso del negocio

14

13.Identificaci
on de los usuarios de la aplicaci
on a construir

14

13.1. Administrador de cuentas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

14

13.2. Observador . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

14

13.3. Administrador de productos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

14

14.Diagrama de casos de uso

15

15.Descripci
on del diagrama de casos de uso

16

15.1. Casos de uso de alto nivel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

16

15.2. Casos de uso expandido . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

20

16.Modelo Conceptual

23

17.Informe del avance del proyecto

24

18.Modelo de clases de la aplicaci

on

27

19.Dise
no de la arquitectura del sistema

28

19.1. Caractersticas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

28

19.2. Elementos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

28

19.3. Ventajas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

28

19.4. Desventajas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

29

20.Dise
no de interfaces gr
aficas

30

21.Planificaci
on de personal y fechas

32

21.1. Desarrollo del proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

32

21.2. Linea de tiempo

34

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

22.Descripci
on de hitos

36

23.Conclusi
on

37

24.Anexo 1: Descripci
on del problema a resolver (BPMN)

38

25.Anexo 1: Descripci
on del problema a resolver (BPMN)

39

26.Anexo 2: Descripci
on preliminar de la solucio
n inform
atica (BPMN)

40

27.Anexo 3: Diagrama de actividades que muestre el proceso del negocio

41

28.Glosario t
ecnico

42

28.1. Proceso de gesti

on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

42

28.2. Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

42

28.3. Estimaci
on de costos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

42

28.4. Planificaci
on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

42

28.5. G
ondola . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

42

28.6. Empresa de retail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

42

28.7. Repositorio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

42

28.8. On demand . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

42

28.9. Stock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

43

28.10.Quiebre de stock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

43

28.11.Reponedor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

43

28.12.Privilegio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
29.Referencias

43
44

1.

Introducci
on
Un proyecto de software es el proceso de gestion para el desarrollo de un Software o Sistema,

que engloba una serie de actividades que deben realizarse a medida que el proyecto transcurre. Estas
actividades son la estimaci
on de costos, la planificacion, la identificacion de recursos a utilizar, objetivos, entre otros. La documentaci
on es algo sumamente importante pues es la forma de detallar los
aspectos y caractersticas del proyecto, tales como las ventajas, desventajas, funcionalidades, costos y
beneficios, y todo lo que implica el desarrollo del proyecto.
En este informe se definir
a el proyecto de software Facing, que se enfoca en la administracion de
datos obtenidos por medio de fotografas periodicas a gondolas ubicadas en las empresas de retail,
todo esto con distintas finalidades.
Tambien se definir
an los objetivos generales y especficos, los alcances, la solucion informatica y los
resultados esperados. Facing es un sistema en desarrollo que trabaja directamente con las empresas
de retail y sus proveedores, para proporcionarles informacion a traves de una aplicacion web y una
aplicaci
on m
ovil para Android. Se basa principalmente en el procesamiento de imagenes periodicas
de las g
ondolas ubicadas en los locales comerciales, para obtener datos sobre los productos que ah se
encuentran.
La principal labor de este grupo de trabajo es realizar la aplicacion web donde se exhibiran los datos
para los clientes, que corresponde a toda la informacion emprica y estadstica recopilada a traves del
procesamiento de las fotografas guardadas en los servidores de Skillup. Esto facilitara la fiscalizaci
on
de los cumplimientos de contratos establecidos entre proveedores y las empresas de retail correspondientes, donde este implementado este sistema.
Se analizar
a paso a paso el planteamiento del problema para tener una vision clara de los recursos que
se necesitar
an. Adem
as, se formular
an los objetivos y alcances, para finalmente tener la capacidad de
crear la descripci
on preliminar de la solucion informatica.
Por u
ltimo, se estudiar
an los impactos positivos y negativos que producira la implantacion del sistema.

2.

Conformaci
on del equipo de trabajo
El equipo de trabajo estar
a conformado por siete personas que realizaran distintos roles y activi-

dades dentro del proyecto. Adem

as, este equipo cuenta con un miembro de la empresa (stakeholder),
que estar
a presente en el desarrollo del software.[1],[2]

2.1.

Jefe de proyecto

Controla, administra y gestiona los recursos asignados a un proyecto, con el proposito de que se
cumpla lo estipulado sin contratiempos, monitoreando las diferentes actividades y eventos. Tambien
posee un amplio conocimiento de los aspectos generales del proyecto, para poder interactuar de manera
efectiva con el cliente y el resto del equipo. Este cargo se le asigno a Sebastian Teran, por su experiencia
en el
ambito laboral, habilidades para el manejo de grupos de trabajo y ademas es quien tiene contacto
directo con el cliente.

2.2.

Analista

Es quien hace la especificaci

on de un problema, transformandolo en subproblemas de menor complejidad. Este trabaja a la par con el cliente para realizar la especificacion y analisis del sistema a

construir y se encarga de que sea precisa y correcta. Este cargo se le asigno a Rodrigo Abel
y Patricio
Carrasco, debido a su capacidad de observacion y pensamiento critico, ademas ambos son detallistas,
por lo que suelen notar peque
nos pormenores que ayudan con el analisis del problema.

2.3.

Dise
nador

Genera una dise

no estructurado y detallado del sistema, esto se realizara a costas de los requisitos
especificados por el analista. Este cargo se le asigno a Camila Sanhueza y Andres Brito, debido a sus
capacidades creativas, adem
as de ser personas sumamente ingeniosas. Adicionalmente son capaces de
interpretar lo definido en el an
alisis previo para presentarselo a los programadores.

2.4.

Programador

Convierten las especificaciones del sistema, en codigo fuente ejecutable y operable en uno o m
as
lenguajes de programaci
on, de misma forma las herramientas de software que lo apoyan. Este cargo se

le asigno a Patricio Carrasco, Camila Sanhueza y Rodrigo Abel,

por su capacidad de pasar facilmente
a c
odigo las soluciones previamente dise
nadas.

2.5.

Documentador

Este genera la documentaci

on del proyecto, debe encontrarse en el repositorio del proyecto. Uno
de sus objetivos es dar a conocer la historia, manuales, entre otros. Este cargo se le asigno a Hector
Cisterna y Andres Brito, pues son ordenados, tienen buena gramatica, ortografa, son coherentes al
escribir y su escritura es cohesionada.

2.6.

Quality Assurance

Revisa y corrobora el buen funcionamiento de los codigos programados. Esto

se realiza de manera
sistem
atica, ya que posee una basta experiencia en programacion. Para realizar esta tarea de manera
correcta, se tiene que tener una buena comunicacion con lo programadores. Este cargo se le asigno a
Sebasti
an Ter
an y Hector Cisterna, pues son detallista, conocen el proyecto a profundidad y abordan
los problemas desde muchos puntos de vista. Ademas Sebastian ha trabajado durante un largo tiempo
como QA en una empresa de desarrollo de software.

2.7.

Stakeholder

Es un conjunto de personas o entes interesados en un proyecto, que tiene influencia o poder de

modificar positiva o negativamente los resultados del proyecto. Esta actividad es realizada por Crstian
Rosas (Jefe de Proyectos SKILLUP Chile).

3.

Descripci
on del cliente
Skillup Chile[3] inicia sus operaciones en el a
no 2006 en el area de soluciones informaticas para

el retail. Luego de cuatro a

nos de intenso desarrollo colaborativo, principalmente enfocado a la investigaci
on y desarrollo de tecnologas, Skillup Chile se une a su par de Japon (SkillupJapan[4] ) para
adaptar las tecnologas desarrolladas en el mercado asiatico al mercado sudamericano. En julio del
2010 se crea Skillup Chile de JACH Technology S.A. (Japanese-Chilean Technology), una compa
na
enfocada al desarrollo de nuevas plataformas de distribucion de video, publicidad y analisis inteligente
para el retail.
Debido a esta colaboraci
on, la empresa cuenta con una excelente red de ingenieros de nivel internacional, los cuales pueden acceder f
acilmente a las mas avanzadas tecnologas utilizadas en Tokio,
promoviendo y potenciando el desarrollo tecnico e innovacion en toda la region sudamericana.
La empresa cuenta con servicios de inteligencia de negocios, extraccion de informacion demografica,
an
alisis de publicidad en medios, entre otros. Tambien cuenta con una de las mas avanzadas plataformas de gesti
on de video online en Asia, la cual incluso esta siendo utilizada por grandes cadenas
como Warner Brothers, Fuji Tv y Nippon Tv.
Otro de los objetivos de la empresa es lograr ser lderes a nivel sudamericano, no solo en las plataformas
de administraci
on que provee, sino que tambien en soluciones de inteligencia.

3.1.

Algunas de las aplicaciones desarrolladas por Skillup

FollowUp: Es un sistema para uso en el retail, que permite facilmente evaluar el negocio desde el
punto de vista del cliente y no de la venta. Integra los datos del comportamiento de los clientes
con la informaci
on de la venta para dar una breve descripcion del negocio y de la transacci
on
realizada.
MovTv: Es una aplicaci
on que se encuentra disponible en distintas plataformas, que distribuye
videos On Demand y canales en vivo. Contiene distintas categoras para distintos p
ublicos.

Qori: Es un servidor para anuncios de publicidad. Soporta una variedad significativa de formatos
y transmite y publica a traves de sitios web, moviles, smartTV y tablets.

4.

Descripci
on del problema a resolver (BPMN)
Actualmente las empresas utilizan reponedores e inspectores para manejar el movimiento de sus

mercancas en los locales comerciales. Como se muestra en el primer BPMN el reponedor tiene que
revisar las g
ondolas verificando cu
ales son los productos que necesita poner, luego en el caso de que
necesite reponer alguno, se dirige a la bodega a buscarlos. En la bodega tiene que comprobar si es que
los productos se encuentran disponibles para su reposicion. Finalmente se dirige con los productos al
pasillo correspondiente y procede a acomodar los productos.
En el caso que no este la mercanca en bodega, se debe de comunicar a la empresa(proveedor).
Por otro lado tenemos el proceso que utiliza la empresa para controlar el movimiento de sus productos,
la verificaci
on de contratos y la forma de obtener informacion con respecto de la competencia. Todo
esto lo realiza un inspector que tiene un itinerario de locales en donde debe revisar todo lo mencionado
anteriormente, esto est
a explicado en un segundo BPMN que se denomino .Estudio de mercado, en
este estudio la empresa o cliente pide que se haga un estudio del comportamiento de sus productos y
para esto enva a un inspector distintos locales comerciales donde se encuentran sus productos. Este
inspector redacta un informe con lo recopilado despues de haber terminado con todos los locales que
se le asignaron. Finalmente los reportes son enviados a la empresa (Ver anexo 1)[5] .

5.

Objetivos del proyecto

5.1.

Objetivo general

Obtener datos empricos de los productos ubicados en las gondolas, generando informacion estadstica en relaci
on al flujo producido por el consumo de estos.

5.2.

Objetivos especficos
Controlar el cumplimiento de los acuerdos estipulados entre las marcas proveedoras y los locales
de autoservicio, en relaci
on a los espacios utilizados en las gondolas, lugar de posicionamiento,
cantidad de productos, entre otros.
Obtener datos sobre puntos estrategicos de los productos del proveedor dentro de las gondolas.
Comparar el movimiento de diferentes mercaderas en distintas sucursales del retail.
Analizar la venta de un mismo producto entre distintas marcas, con el fin de ver la competencia
que existe entre estos.
Identificar cuando los productos que corresponden a una marca en especfico fueron cambiados
a una g
ondolas que no les corresponde.
Entregar un an
alisis panor
amico al cliente de sus productos en relacion a la competencia.

6.

Alcances del proyecto

Entrega datos empricos y estadsticos de la cantidad de productos en la gondola.
No se entregan decisiones ni soluciones referentes a los datos empricos y estadsticos.
No se entregan datos sobre la venta de los productos.
El software debe ser utilizable para una variedad de usuarios, tales como los reponedores, los
jefes de local, etc. En otras palabras, debe ser autonomo, y no debe depender de un usuario en
especfico.
El software debe permitir la utilizacion de distintos tipos de privilegios para presentar la informaci
on, para as poder entregar a los usuarios la informacion que les corresponde.
La utilizaci
on del software ser
a, en el mejor de los casos, con camaras estacionarias funcionando
de manera peri
odica. En el peor de los casos seran fotografas tomadas por un empleado de
forma presencial.
La soluci
on est
a dise
nada inicialmente para su uso en el territorio chileno.

7.

Descripci
on preliminar de la soluci
on inform
atica (BPMN)
Para la soluci
on del problema se utilizaran camaras que sacaran fotos de las gondolas, las que ser
an

procesadas para obtener informaci

on relevante como cantidad de productos y n
umero de quiebres.
Esta informaci
on ser
a enviada a los servidores administrados por Skillup donde sera almacenada para
luego poder generar estadsticas sobre los productos en base a los datos, para finalmente almacenar lo
generado. Por otro lado est
a la aplicaci
on web y movil, esta permitira al usuario solicitar informaci
on
sobre los productos, teniendo acceso a los servidores donde este almacenada esa informacion. Se
generar
a un registro de acceso que ser
a guardado en la base de datos. Luego se mostrara al usuario
los datos solicitados, estadsticas y gr
aficos, de una forma entendible y clara. Cada usuario podra ver
cierto tipo de informaci
on en especfico dependiendo de los privilegios que tenga su cuenta, en el caso
de solicitar informaci
on no permitida se mostrara un mensaje indicando que no tiene los permisos
suficientes (Ver Anexo 2)

8.

[5]

Recursos requeridos para la implementaci

on

1. Se utilizar
an dos servidores (VPS) para poder manejar de forma independiente el procesamiento
de los datos por el software y los datos obtenidos. De esta manera se podran optimizar los
tiempos de respuesta y la seguridad de datos.
Las especificaciones para estos servidores son las siguientes:
Procesador de 7 n
ucleos
Espacio en disco duro de 250 Gb.
Memoria RAM de 5120 Mb.
9

SO Ubuntu Server (Linux)

Motor de bases de datos MySQL
2. Dispositivos Android con Sistema operativo Android 4.0 o superior. Este es un requerimiento
explcito de la empresa Skillup.
Los dispositivos deben tener una camara de por lo menos 5 megapxeles, pues las fotografas
deben ser tomadas con esta resolucion.
3. C
amara IP Allround M24M con una resolucion de 2048x1536.
La c
amara IP ser
a utilizada en el mejor de los escenarios, de no ser as se utilizaran los dispositivos
Android.

9.

Resultados esperados
Que no hayan quiebre, o bien minimizar quiebres.
Optimizar el tiempo de reposici
on.
Que hayan productos todo el tiempo en las gondolas.
Reconocer cuando hayan quiebres.
Informar cuanto fue el tiempo de quiebre.
Reconocer los espacios utilizados por la competencia.
Saber cual es el local que vende mas productos de una determinada marca.

10.

Impactos del proyecto

Los impactos del proyecto se pueden separar en dos grupos y estos son los siguientes:

10.1.

Positivos

Fiscalizaci
on de la marcas: los proveedores tendran acceso a la base de datos de lo que hubo y
cuando se corrigi
o el stock, por ende podran corroborar que se esten cumpliendo los contratos
de cantidad y posicionamiento de sus productos en las gondolas, facilitando la fiscalizacion y
haciendola m
as expedita.
Optimizaci
on de reposici
on: el sistema notificara en el momento que sea necesaria una reposicion,
por ende los tiempos entre falta de producto y reposicion seran minimizados y optimizados.
Uso eficiente del personal contratado: los pocos reponedores que habran, optimizaran su tiempo
de trabajo pues el sistema les avisara cuando hayan problemas de stock, por ende no perder
an
tiempo revisando las g
ondolas.

10

Mejor an
alisis de puntos de ventas: la estadstica obtenida de los datos empricos permitira analizar cuales son las mejores ubicaciones para vender productos, lo que ayuda a las marcas a
tomar mejores decisiones a la hora de alquilar un lugar en la gondola.
Permite acceso remoto a los datos: se podra acceder a la base de datos a traves de una aplicaci
on
web, permitiendo un acceso desde cualquier lugar con un punto de conexion.

10.2.

Negativos

Reducci
on del personal (reponedores): debido a que las camaras estaran chequeando constantemente las g
ondolas, no se necesitara tener personal en los pasillos para revisar si faltan o no
productos. En lugar de esto, los reponedores seran notificados cuando se necesite reponer, disminuyendo considerablemente el personal dedicado a esto. En otras palabras, los reponedores
perder
an sus empleos.
Fuerte impacto financiero por implantacion inicial del sistema: debido a que se requiere de un
sistema de c
amaras para implementar el sistema, este tendra un costo elevado y tendra un fuerte
impacto econ
omico para la empresa en su etapa inicial.
Aplicaci
on poco adaptable para sistemas moviles: solo sera apto para moviles Android, haciendolo poco flexible, sin poder operar en IOS ni Windows Phone, entre otros.
Capacitaci
on y resistencia al cambio: mientras se implanta el sistema, se debe capacitar al
personal, y en el peor de los casos podra presentarse una resistencia al cambio, esto quiere decir
que el personal se negara a cambiar la forma de trabajo, impidiendo un correcto desempe
no del
sistema.

11.

Listado de requisitos

Su principal caracterstica es la de definir que es lo que esperan los usuarios del software, y con esto,
ayudar al equipo a entender de manera mucho mas clara lo que se esta pidiendo. Los requerimientos se
definen en funcionales, y no funcionales. Los primeros, definen el comportamiento del software, como
por ejemplo, el procesamiento de los datos, los ingresos al sistema, entre otras funciones especficas
y que son necesarias para el funcionamiento del software, en cambio, los no funcionales definen las
caractersticas de calidad del software, es decir, el dise
no e implementacion del software.

11

11.1.

Requisitos funcionales

ID

Nombre

RF00

Ingresar

al

Prioridad

Categora

Descripcion

Alta

Evidente

Los usuarios deben entrar al sistema pa-

sistema

ra poder visualizar la informacion y/o

realizar una accion.

RF01

Procesamiento Alta

Oculto

de datos

Se toman los datos obtenidos al analizar

las fotos y se calculan datos estadsticos.

RF02

Obtenci
on
de

Alta

Oculto

datos

datos para rescatar los datos y presen-

almacenados
RF03

Solicitar re-

La aplicacion se conecta con la base de

tarlos.

Media

Evidente

porte

Despues de ya haber ingresado a la aplicacion, el usuario solicita que se le entregue un reporte.

RF04

Generar

re-

Alta

Oculto

porte
RF05

Entregar re-

crea un reporte de productos.

Alta

Evidente

porte
RF06

Crear usuaModificar

Alta

Evidente

Eliminar

Baja

Evidente

Agregar pro-

Media

Evidente

Modificar

Alta

Evidente

Baja

Evidente

Eliminar
Agregar

Media

Evidente

Modificar lo-

Alta

Evidente

Eliminar lo-

El usuario ingresa un nuevos locales al

sistema.

Baja

Evidente

cales
RF14

El usuario con privilegios puede eliminar un producto.

locales
RF13

El usuario con privilegios puede cambiar las caractersticas de un producto.

producto
RF12

El usuario ingresa nuevos productos a

la lista de productos.

producto
RF11

El Administrador de usuarios puede eliminar un usuario.

ducto
RF10

Se permite editar o cambiar los datos

del usuario.

usuario
RF09

El administrador puede insertar nuevos

usuarios.

usuario
RF08

Se muestra el reporte generado en pantalla.

rio
RF07

Con las estadsticas almacenadas, se

El usuario con privilegios puede cambiar las caractersticas de un local.

Media

Evidente

cales

El usuario con privilegios puede eliminar un local.

12

11.2.
ID

Requisitos no funcionales
Nombre

RNF00 Modificar

Prioridad

Caracteristica

Subcaracteristica

Descripcion

Baja

Funcionabilidad

Adecuacion,

Alterar el tiempo que

tiem-

con-

formidad

transcurre entre capturas.

Comprensibilidad,

Habilitar

cambio

atractividad,

cambiar entre diferentes

entre

operabilidad

gr
aficos

conformidad

pos

de

muestreo
RNF01 Habilitar

RNF02 Imprimir

Alta

Alta

Usabilidad

Funcionabilidad

informe

Adecuacion,

con-

formidad

opcion

para

tipos de graficos.
Permitir la generaci
on de
un archivo (tentativamente PDF) para prop
ositos
de impresion.

RNF03 Permitir

Baja

Usabilidad

Comprensibilidad

Habilitar boton para cam-

cambio

biar el idioma de visuali-

de idioma

zacion de la pagina .

RNF04 B
usqueda

Alta

Funcionalidad

de

Adecuacion,

Con-

formidad

producto

El usuario ingresa una palabra que desea buscar en

el sitio para mostrarlo por
pantalla.

RNF05 Mapa del

Baja

Usabilidad

sitio
RNF06 Descargar

Alta

Funcionalidad

reporte

Comprensibilidad,

Pagina que muestra to-

aprendibilidad,

dos los contenidos del sitio

conformidad

web.

Interoparatibilidad,

El usuario solicita un re-

Conformidad

porte con los productos,

gondolas y locales seleccionados.

RNF07 Realizar

Alta

Usabilidad

filtros

Comprensibilidad,

El usuario selecciona los

conformidad

objetos especficos (Local,

gondola, productos) que
desea ver.

RNF08 Productos
con

Alta

Funcionabilidad

Conformidad

mas

que han obtenido mas

quiebres
RNF09 Mostrar
foto

Un listado de productos
quiebre de una semana.

Media

Funcionabilidad

Conformidad

del

Se muestra una imagen del

producto en la aplicaci
on.

producto
RNF10 Exportar

Alta

Portabilidad

reportes

13

Adaptabilidad, co-

El usuario solicita la infor-

existencia, confor-

macion en diferentes pla-

midad.

taformas.

12.

Diagrama de actividades que muestre el proceso del negocio

Este diagrama su utiliza para entregar una vision simplificada de lo que ocurre en el proceso, este
muestra la interacci
on entre la aplicaci
on Facing y el usuario, esto se inicia, luego se recibe la fotografa
de los productos en sus respectivas gondolas, la aplicacion identifica los productos, notificando si es
necesaria la reposici
on y/o guarda los datos. Luego el usuario observa, la informacion entregada,
permitiendole escoger 3 caminos que serian: aplicar filtros a los datos, realizar un analisis a los quiebre
o solicitar reporte, luego el usuario decide si es necesario continuar en la aplicacion o no. (Ver anexo
3)[6] .

13.
13.1.

Identificaci
on de los usuarios de la aplicaci
on a construir
Administrador de cuentas

Se encarga de administrar las cuentas de usuario, entre las cuales hay 2 tipos, una denominada
Observador y otra llamada Administrador de productos. Esta cuenta seria utilizada por personal de
Skillup.

13.2.

Observador

Esta cuanta permite al usuario poder observar toda la informacion que esta en el sistema de la
aplicaci
on Facing, pudiendo solicitar reportes y obtener datos estadsticos.

13.3.

Administrador de productos

Este usuario puede realizar lo mismo que el Observador, paro ademas puede modificar los productos, g
ondolas y locales que se encuentran dentro del sistema. De este modo puede agregar, modificar
o eliminar lo que sea necesario para la empresa.

14

14.

Diagrama de casos de uso

Figura 1: Diagrama de casos de uso

15

15.

Descripci
on del diagrama de casos de uso

Para la soluci
on es necesario contar con 4 actores, Tomador de fotografa, Observador, Administrador de cuentas y el Administrador de productos.
Tomador de fotografa: puede ser una persona o un dispositivo encargado de captar la fotografa,
la persona toma la foto en caso de que no se implanten las camaras en frente de cada gondola,
en caso contrario, los dispositivos (camara ip fija en la gondola) seran los encargados de tomar
la fotografa para posteriormente ser procesada.
Observador: Es el cliente, que luego de iniciar sesion podra navegar por la aplicacion ingresando
a los locales y productos que el seleccione. Ademas tendra la opcion de solicitar un reporte de
los datos solicitados.
Administrador de productos: Luego de iniciar sesion, podra gestionar los productos que se encuentran dentro del sistema.
Administrador de cuentas: tiene todos los privilegios del sistema, puede gestionar a los usuarios
(crear nuevo usuario, eliminar usuario, otorgando y quitando permisos, etc). Puede ver todos
los locales asociados, ver que productos se encuentran en cierta gondola, y tambien administrar
que usuarios son los que deben tener acceso a esa informacion y cuales no.

15.1.

Casos de uso de alto nivel

ID

F02

Caso de Uso

Crear usuario

Actores

Administrador de cuentas

Descripci
on

El administrador de cuentas genera nuevas credenciales para usuarios que no se encuentran en la lista
actual de usuarios.

Tipo

Principal

ID

F03

Caso de Uso

Eliminar usuario

Actores

Administrador de cuentas

Descripci
on

El administrador de cuentas borra credenciales de

acceso al sistema que ya no son necesarias.

Tipo

Principal

16

ID

F04

Caso de Uso

Eliminar permisos

Actores

Administrador de cuentas

Descripci
on

El administrador de cuentas elimina los permisos

otorgados al usuario.

Tipo

Prinicipal

ID

F05

Caso de Uso

Gestionar permisos

Actores

Administrador de cuentas

Descripci
on

Le permite al Administrador de cuentas entrar a una

pantalla en la cual se vera una lista de permisos (cada
uno con un boton de modificar y de eliminar permisos) y un boton de crear nuevo permiso.

Tipo

Principal

ID

F06

Caso de Uso

Crear permisos

Actores

Administrador de cuentas

Descripci
on

El administrador de cuentas permite crear nuevos

permisos para asignarle a los usuarios.

Tipo

Principal

ID

F07

Caso de Uso

Modificar permisos

Actores

Administrador de cuentas

Descripci
on

El administrador de cuentas modifica los permisos

existentes.

Tipo

Principal

ID

F08

Caso de Uso

Enviar fotografia

Actores

Tomador de Fotografa

Descripci
on

Enva los datos (cantidad de productos y quiebres)

de la fotografia al sistema para ser analizados.

Tipo

Principal

ID

F09

Caso de Uso

Iniciar sesion en el sistema

Actores

Observador, Administrador de productos

Descripci
on

Permite al usuario ingresar al sistema.

Tipo

Principal

17

ID

F10

Caso de Uso

Desplegar reporte

Actores

Observador

Descripci
on

Se muestra el reporte solicitado al usuario.

Tipo

Principal

ID

F11

Caso de Uso

Insertar nuevo producto

Actores

Administrador de productos

Descripci
on

Se le muestra al usuario un formulario para ingresar

nuevos productos a la lista de productos.

Tipo

Principal

ID

F12

Caso de Uso

Modificar producto

Actores

Administrador de productos

Descripci
on

Cambiar caractersticas de un producto existente en

la lista.

Tipo

Principal

ID

F14

Caso de Uso

Eliminar producto

Actores

Administrador de productos

Descripci
on

El usuario borra un producto de la lista de productos.

Tipo

Principal

ID

F16

Caso de Uso

Administrar locales

Actores

Administrador de cuentas

Descripci
on

Le permite al Administrador de cuentas entrar a una

pantalla en la cual se vera una lista de locales (cada
uno con un boton de modificar y de eliminar locales)
y un boton de crear nuevo local.

Tipo

Principal

ID

F17

Caso de Uso

Crear local

Actores

Administrador de cuentas

Descripci
on

El administrador de cuentas crea nuevos locales para

asignarle productos.

Tipo

Principal

18

ID

F18

Caso de Uso

Modificar local

Actores

Administrador de cuentas

Descripci
on

El administrador de cuentas modifica los locales existentes.

Tipo

Principal

ID

F19

Caso de Uso

Eliminar local

Actores

Administrador de cuentas

Descripci
on

El administrador de cuentas suprime locales que ya

no son necesarios.

Tipo

Principal

19

15.2.

Casos de uso expandido

ID

F01

Caso de Uso

Gestionar usuarios

Actores

Administrador de cuentas

Prop
osito

Poder modificar, crear y eliminar caractersticas de

los usuario.

Resumen

Le permite al Administrador de cuentas entrar a una

pantalla en la cual se vera una lista de usuarios (cada
uno con un boton de gestionar permisos y de eliminar
usuario) y un boton de crear nuevo usuario.

Tipo

Principal

Referencias cruzadas

F02, F03, F05 , F16, RF06, RF07, RF08

Secci
on principal

Accion de los actores

Respuesta del sistema

1.

administrador

2. Redirige a la subsec-

de cuentas del sistema

cion de creacion de usua-

aprieta el boton de crear

rio (F02), a la subsec-

usuario (subflujo F02),

cion de modificar permi-

o uno de los botones

sos (F04) o muestra una

de

permisos

ventana esperando con-

(subflujo F04) o eliminar

firmacion para eliminar a

usuario (subflujo F03).

un usuario (F03).

Flujo normal de eventos

El

gestionar

Flujos alternativos
Cuadro 1: Caso de uso extendido

20

ID

F13

Caso de Uso

Pedir reporte

Actores

Observador

Prop
osito

Obtener un reporte o informe sobre el o los productos

solicitados.

Resumen

El Usuario solicita al software los datos que fueron

filtrados, para obtener un documento que contenga
esa informacion.

Tipo

Principal

Referencias cruzadas

F10,RF03

Secci
on principal

Accion de los actores

Respuesta del sistema

1. El usuario elige las ca-

2. El sistema procesa

ractersticas (filtros) ha

y obtiene la informacion

desplegar.

deseada.

Flujo normal de eventos

3. El usuario oprime desplegar reporte (subflujo

F10).

Flujos alternativos

Lnea 2. El sistema no puede crear el archivo. Devuelve al usuario a la pantalla anterior.

Cuadro 2: Caso de uso extendido

21

ID

F15

Caso de Uso

Gestionar Productos

Actores

Administrador de productos

Prop
osito

Modificar caractersticas de los productos.

Resumen

Muestra un men
u para modificar, eliminar o agregar
productos o caractersticas.

Tipo

Principal

Referencias cruzadas

F11,F12,F14, RF09, RF10, RF11

Secci
on principal

Accion de los actores

Respuesta del sistema

1. El usuario selecciona

2. El sistema redirige a la

el boton Insertar nuevo

pagina correspondiente

Flujo normal de eventos

producto(subflujo F11),
o los botones Modificar producto(subflujo
F12), o Eliminar producto(subflujo F14) de
un determinado producto.

Flujos alternativos
Cuadro 3: Caso de uso extendido

22

16.

Modelo Conceptual

La entidad Administrador de cuentas tiene como atributos nombre y clave, este puede gestionar las
cuentas de usuario. La entidad Usuario posee Nombre, Clave y Privilegios, que son los que definen a
que tipo de informaci
on puede acceder este usuario. La relacion entre estas dos entidades es de uno es a
varios respectivamente, pues en este modelo solo habra un administrador el cual gestionara desde una
(usuario con todos los privilegios para este mismo administrador), hasta muchas cuentas de usuario.
Luego la entidad Usuario tiene una relacion de gestion con las entidades Local, Gondola y Producto,
pues dependiendo de los privilegios que esta tenga puede modificar a estas entidades mencionadas
anteriormente, en estos 3 casos la relaci
on es que muchos usuarios (por lo menos uno) pueden gestionar
muchos productos.
Los atributos de la entidad Local son Direccion, ID Local y Jefe de local. Por su parte la entidad
G
ondola tiene como atributos Pasillo y Ubicacion. Las fotos tiene de atributos ID Camara, Fecha
y Descripcon C
amara. En el caso de los productos sus atributos son Nombre, Codigo Identificador,
Estado, Precio, Descripci
on.
Por su parte la entidad Local contiene a la entidad Gondola, la que a su vez contiene a la entidad
Foto y Producto. La relaci
on de estas entidades es que un local tiene una o mas gondolas, una gondola
tiene cero o muchas fotos y una o m
as gondolas tienen cero o muchos productos.
Adicionalmente la entidad Usuario tiene una relacion de solicitud con la entidad Reporte, esta contiene
la entidad Productos con la que se relaciona con la entidad Gondola y Local de la forma anteriormente
descrita. La relaci
on es que un usuario solicita cero o muchos reportes, los reportes tienen informaci
on
requerida por el usuario por lo que cero o mas reportes tienen cero o muchos productos.
Finalmente los atributos de la entidad Reporte son ID Reporte, Fecha, Proveedor, Media, Elasticidad,
Desviaci
on Est
andar y N
umero de Quiebres.

Figura 2: Modelo Conceptual

23

17.

Informe del avance del proyecto

Primera reuni
on
Fecha: 16/04/2014
Protagonistas: Camila Sanhueza, Sebastian Teran, Ciro Oyarz
un y Cristian Rosas
Contenido de la reuni
on: se comento sobre el tipo de proyecto que se requera para el curso de
Ingeniera de Software, donde la empresa Skillup ofrecio la realizacion del proyecto Facing,
que consiste en una aplicaci
on m
ovil y/o web, que servira para monitorear el comportamiento
de productos en una tienda de retail. Esto se realizara mediante el reconocimiento de imagenes,
con c
amaras estacionarias ubicadas en los pasillos. Con los datos almacenados gracias al reconocimiento de im
agenes se podr
an analizar las estadsticas sobre estos productos en la tienda,
dando la libertad para elegir de que forma se podran ver representados estos datos, tales como
en gr
aficos, comparaciones, entre otros. Tambien se realizaron preguntas sobre el funcionamiento
de esta futura aplicaci
on, para poder comprender de mejor manera el problema a abordar.
Conclusi
on: En esta reuni
on, se hablo sobre el problema y las principales caractersticas que
deba poseer este proyecto, as transando los pilares que se deben abordar a la hora de crear una
soluci
on.
Segunda reuni
on
Fecha: 24/04/2014

Protagonistas: Rodrigo Abel,

Patricio Carrasco, Hector Cisterna, Camila Sanhueza, Sebasti
an
Ter
an, Ciro Oyarz
un y Cristian Rosas
Contenido de la reuni
on: se consulto la manera en la que se obtendran los datos y donde se
almacenaran (base de datos) de forma mas especfica, los supuestos en ese entonces fueron
que con la aplicaci
on se obtendra la cantidad de productos por gondola, es decir, que tantas
veces se repeta el mismo producto en la foto, y para distintos productos seran separados por
categora y marca. Se habl
o de los proveedores, los cuales buscan mejorar su posicionamiento
en el mercado con respecto a su competencia. Las empresas de retail no pueden dar reportes
de las distintas marcas que no sean de los mismos proveedores, es decir, no se debe ofrecer
la informaci
on de las dem
as empresas. Se deba cambiar el enfoque, en lugar de preocuparse
del supermercado como se hizo en un comienzo, se pidio que se centrara mas la atencion a los
proveedores, los cuales se veran mucho mas beneficiados que los supermercados. Lo que haya
que reponer, lo ve el proveedor. Tambien se comentaron brevemente los requisitos: enfocarse
en que producto se vende m
as seg
un categora: el algoritmo identificara dos cosas, que haya
quiebre o no. Adem
as el proveedor sera mucho mas interesado en cuantos quiebres tiene la
competencia (lo cual s tendr
a acceso el proveedor, pero sin ning
un tipo de mencion de marca),
tambien la idea de que haya siempre una camara disponible en el supermercado captando todo.
Con la implementaci
on del software, el personal tendra un trabajo mucho mas eficiente, ya que
no estar
an todo el da buscando por toda la tienda para reponer productos. En cuanto a los
24

BPMN, el primero tuvo una muy buena aceptacion por parte de Skillup, no as el segundo. Se
solicit
o dejar al supermercado fuera, es decir, que no se hable de la ruta de los productos dentro
del supermercado, de revisar los productos en stock, etc. Lo u
nico que poda ver el supermercado,
es que los reponedores hagan su trabajo y que los precios esten bien puestos. En el u
ltimo BPMN
se solicit
o el cambio de los siguientes puntos: que todo cliente tenga una base de datos propia,
que un servidor tenga el manejo de los datos, e idear un tipo de reporte y con esto modelar la
base de datos. De acuerdo con algunas marcas que se les presento la idea del proyecto y que
estuvieron muy interesados en el, fueron Kimberly, Nestle, Carozzi, y Johnsons, los cuales se
comprometieron a solicitar e implementar el software cuando estuviese listo. Finalmente, para
los reportes se solicit
o una interfaz grafica, y una pagina (dashboard), se comentaron algunas
p
aginas de ayuda sobre reportera (google analitics y quick view), cosas de interes para el cliente,
por ejemplo, el precio de mis productos en comparacion a la competencia, si los proveedores est
an
haciendo su trabajo, y por supuesto, los tiempos de quiebre, cuanto tiempo estuvo en quiebre,
relacionar con la competencia, por local, que pasillo tuvo mas flujo, etc.
Conclusi
on: En esta reuni
on, principalmente se aclararon puntos muy importantes para el equipo,
como el enfoque que haba que darle al desarrollo del software, de que manera se obtendran los
datos, que busca el proveedor con el software, entre otros, puntos que son realmente necesarios
para poder avanzar en las distintas etapas de desarrollo del proyecto de manera eficaz y correcta.
Tambien se aclar
o que haba que cambiar y elaborar para la proxima reunion, puntos clave como
los distintos tipos de reporte que se presentaran y dise
no de pagina, etc. En s, lo mas importante
en esta reuni
on fue el hecho de que fue la gran mayora de los integrantes del equipo y tuvimos la
posibilidad de hacer todas nuestras consultas y aclarar las dudas que se tenan en un comienzo,
terminando con un enfoque hacia la misma idea de desarrollo.
Tercera reuni
on:
Fecha: 14/05/2014

Protagonistas: Rodrigo Abel,

Andres Brito, Patricio Carrasco, Hector Cisterna, Camila Sanhueza, Sebasti
an Ter
an, Ciro Oyarz
un y Cristian Rosas
Contenido de la reuni
on: Se comenzo hablando de las api graficas, google char y crossfilter, luego
se coment
o acerca de la base de datos, que debe ver el modelamiento de reportes, seran del tipo
consultas, poder tener las cosas esenciales para poder graficar, tener datos de conteo, entre otros,
y debe ser necesario tener el hist
orico, dejar todo como usuario (contacto, usuario, privilegio)
y que los clientes tengan una base de datos diferente, es decir, no hay id empresa. Los datos
llegar
an en forma de tabla de quiebre, es decir tantos productos tienen tantos quiebres. Los datos
se obtendr
an en bruto en primera instancia, solicitaron que la navegacion de los datos fuese en
la informaci
on en bruto, para que sea mucho mas facil y claro para el usuario ver los datos y
hacer un an
alisis de estos, que hayan tablas y graficos de barra, ademas de la posibilidad de
exportar los datos a pdf y Excel. Tambien en la navegacion se solicito que se haga un filtro por
local, productos, clientes, la posibilidad de comparar diferentes productos, locales, su cantidad
de quiebres, entre otros. Definir el dashboard principal, y ver la posibilidad de enviar mails, pero
25

con la condici
on de que sean mensuales o semanales, para que no se convierta en spam, tambien
que la p
agina permita poner que productos tienen mas quiebres, menos quiebres, un ranking,
interfaz de monitoreo, etc. Y se definieron los requerimientos para la siguiente reunion: Graficos
de cubo (base de datos), google char, base de datos, modo de reportera (relacionado con la base
de datos) y las herramientas a utilizar (Angular(is), ruby(frame)).
Conclusi
on: Fue m
as f
acil entender lo que se solicitaba debido a que ya se tena mas claro
el enfoque, y los requerimientos de las reuniones anteriores, lo cual permitio que no hubieran
atrasos en el entendimiento del desarrollo y se avanza mas en las siguientes etapas del proceso.
Los puntos vistos previamente fueron presentados a Skillup, y aprobados en su mayora por ellos,
finalmente se definieron algunas de las herramientas mas importantes para seguir trabajando
en el proyecto, empezar a construir las plataformas de acceso y los distintos reportes que se les
otorgar
an a los clientes.

26

18.

Modelo de clases de la aplicaci

on

Figura 3: Diagrama de Clases

27

19.

Dise
no de la arquitectura del sistema

Se utilizar
a una arquitectura Cliente-Servidor (4 Capas), por requerimientos de la empresa.

19.1.

Caractersticas

El servidor presenta a todos sus clientes una interfaz u

nica y bien definida.
El cliente no necesita conocer la l
ogica del servidor, solo su interfaz externa.
El cliente no depende de la ubicacion fsica del servidor, ni del tipo de equipo fsico en el que se
encuentra, ni de su sistema operativo.
Los cambios en el servidor implican pocos o ning
un cambio en el cliente.

19.2.

Elementos

Se utilizar
an los siguientes elementos:
Interfaz de usuario, l
ogica de presentacion.
Gesti
on del procesamiento, l
ogica del negocio.
Gesti
on de la base de datos, capa de datos.

19.3.

Ventajas

La utilizaci
on de esta arquitectura otorga las siguientes ventajas:
Aumento de la productividad.
Esto se debe a las siguientes razones:
Se puede utilizar herramientas familiares para los usuarios.
Se pueden construir soluciones que se ajusten a las necesidades del cliente.
La interfaz gr
afica para el usuario agiliza el tiempo de aprendizaje para estos.
Menores costos de operaci
on.
Esto ocurre por los siguientes motivos:
Mejor aprovechamiento de los sistemas existentes.
Proporciona un mejor acceso a los datos.
Al desplazar funciones hacia clientes locales que son maquinas mas peque
nas y por lo tanto
m
as baratas.
Mejora en el rendimiento de la red. Este punto se puede separar en lo siguiente:
Se elimina la necesidad de mover grandes bloques de informacion hacia los computadores
personales para su proceso.
Los servidores son los que controlan los datos, los procesan y luego transfiere los datos
procesados al cliente.
28

19.4.

Desventajas

Las desventajas de ocupar esta arquitectura son las siguientes:

Tener que integrar una gran variedad de productos provoca una alta complejidad tecnologica.
Es m
as difcil asegurar un elevado grado de seguridad en una red de clientes y servidores que en
un sistema con un u
nico ordenador centralizado.
Los problemas de congesti
on de la red pueden reducir el rendimiento del sistema por debajo de
lo que se obtendra con una u
nica maquina.
La interfaz gr
afica de usuario puede ralentizar el funcionamiento de la aplicacion.

29

20.

Dise
no de interfaces gr
aficas

Figura 4: Interfaz grafica del Login

Figura 5: Interfaz grafica del Administrador de usuarios

30

Figura 6: Interfaz grafica de los usuarios

31

21.
21.1.

Planificaci
on de personal y fechas
Desarrollo del proyecto

32

33

21.2.

Linea de tiempo

34

35

22.

Descripci
on de hitos
Reuni
on de asignaci
on de labores y entrega de documentacion:
En esta reuni
on se asign
o el rol de cada integrante dentro del desarrollo del proyecto y se le
entreg
o al jefe de proyectos la documentacion relacionada con el proyecto de parte del cliente.
Revisi
on sistema de almacenamiento y procesamiento:
Se aclararon los puntos referentes al almacenamiento de datos que haban quedado confusos en
la reuni
on anterior. Adem
as se especifico el metodo de procesamiento de datos.
Revisi
on ingreso sistema:
Se revis
o el metodo de ingreso al sistema, ya que al haberse enfocado primero en una visi
on
desde el supermercado y no desde el proveedor, se tena mal entendido este punto.
Pruebas de reportes:
Se realizaron modelos de reporte para el cliente, los cuales luego de que este eligiera uno se
comenz
o a modificar a su gusto.
Pruebas de usuarios:
Se prob
o la conexi
on al sistema de los distintos tipos de usuarios.
Pruebas de productos:
Se probaron las distintas interacciones de los productos, tanto en la creacion, modificacion y
eliminaci
on como en la utilizaci
on de los mismos en los reportes.
Prueba de locales:
Se probaron las distintas interacciones de los locales, tanto en la creacion y eliminacion como en
la utilizaci
on de los mismos en los reportes.
Prueba funcional de todo el sistema:
Se realizaron pruebas de utilizaci
on de todo el sistema, desde la conexion del usuario hasta la
generaci
on de reportes, creando los objetos necesarios para el u
ltimo paso en el proceso.
Prueba de Interfaz gr
afica:
Se realizaron pruebas de interaccion con la interfaz grafica desarrollada para el cliente. Estas
pruebas se realizaron paralelamente a las pruebas funcionales.
Pruebas de interfaz en otros idiomas:
Se realiz
o una prueba de la interaccion del sistema con el idioma ingles como predeterminado,
para verificar que no faltaran palabras por traducir.
Prueba de notificaciones:
Se realizaron pruebas de envo de notificaciones a traves de correo electronico, las cuales se
enviar
an peri
odicamente (en principio mensualmente) a los usuarios relacionados con el local al
que se est
a notificando.

36

Prueba de sistema completo:

Se realizaron pruebas de integracion del sistema con el cliente para verificar la funcionalidad
completa del software.

23.

Conclusi
on

Despues de analizar todos los puntos de importancia del proyecto Facing, se puede tener una idea
de los efectos que causar
a. Uno de los aspectos positivos es el ahorro de tiempo que se obtendra, y la
mejora en las ventas, pues las g
ondolas pasaran menos tiempo sin productos, as mismo los productos
que esten en distintas g
ondolas, volver
an a su lugar con rapidez. Otro aspecto importante es que las
empresas de retail tendr
an una disminucion en el pago de salarios debido a que no sera necesario tanto
personal encargado de abastecer las g
ondolas, mejorando as el ingreso de estas empresas.
Despues de realizar los BPMN y estudiar los diferentes puntos del proyecto de ingeniera de software
tratados en el transcurso de este informe, se ha podido observar la importancia de seguir paso a paso
esta metodologa de trabajo, pues facilita la comprension del problema y el desarrollo de la solucion.
Adem
as, los proveedores podr
an corroborar que los contratos establecidos con las empresas de retail
se cumplan al pie de la letra y en caso de que no ocurra, tendran el respaldo necesario para poder
protestar. Esto tambien da una ventaja a las empresas, debido a que pueden mostrar a sus proveedores
que cumplen con lo que prometen y generar una mayor confianza entre estos.
Adicionalmente realizando los diagramas de clases, la carta gantt y las interfaces graficas va tomando
m
as forma el software mostrando claramente hacia donde va dirigido.
Ya es sabido que se reducir
a el personal de las empresas de retail ayudando as al bolsillo de estas,
pero por otro lado, se tendr
a que despedir a muchas personas al implantar el proyecto, debido a que
no habr
a necesidad de que deambulen por los pasillos en todo momento para saber si hacen falta o
no productos en las g
ondolas, lo que generara un claro desempleo al comienzo de la implantacion.

37

24.

Anexo 1: Descripci
on del problema a resolver (BPMN)

Figura 7: Reposicion de mercaderia (BPMN)

38

25.

Anexo 1: Descripci
on del problema a resolver (BPMN)

Figura 8: Reposicion de mercaderia (BPMN)

39

26.

Anexo 2: Descripci
on preliminar de la solucio
n inform
atica (BPMN)

Figura 9: Solucion informatica (BPMN)

40

27.

Anexo 3: Diagrama de actividades que muestre el proceso

del negocio

Figura 10: Diagrama de actividad

41

28.

Glosario t
ecnico

28.1.

Proceso de gesti
on

Conjunto de actividades de planeaci

on, control y ejecucion que tiene como proposito establecer los
elementos del procedimiento en una empresa.

28.2.

Software

Equipamiento l
ogico o soporte l
ogico de un sistema informatico que interpreta el conjunto de
componentes l
ogicos necesarios que hacen posible la realizacion de tareas especficas.

28.3.

Estimaci
on de costos

Proceso que consiste en desarrollar una aproximacion de los recursos necesarios para completar las
actividades del proyecto. La estimaci
on de costos es una prediccion basada en la informacion disponible
en un momento dado.

28.4.

Planificaci
on

Fase en la cual se establecen las metas, y se eligen los medios, tecnologas y herramientas para
alcanzar dichas metas.

28.5.

G
ondola

Tipo de mueble el cual est

a situado com
unmente en los pasillos de los supermercados o empresas

de venta del tipo autoservicio. Estas tienen varias repisas, lo que facilita el muestreo de los productos
de manera ordenada, clara y eficiente.

28.6.

Empresa de retail

Sector econ
omico que engloba a las grandes empresas especializadas en la comercializacion masiva
de productos o servicios uniformes a grandes cantidades de clientes.

28.7.

Repositorio

Sitio centralizado donde se almacena y mantiene informacion digital, habitualmente bases de datos
o archivos inform
aticos.

28.8.

On demand

Es un nuevo concepto en el servicio de programacion en la television, en el cual el televidente,

mediante un men
u de pelculas puestas a disposicion por el operador en una base de datos, se suscribe
y paga por recibir esa pelcula en un da y hora elegidos por el televidente.

42

28.9.

Stock

Conjunto de mercancas o productos que se tienen almacenados en espera de su venta o comercializaci

on.

28.10.

Quiebre de stock

Ocurre cuando un producto no es encontrado en la sala de ventas en el lugar habitual, en el tama

no,
variedad y forma deseada.

28.11.

Reponedor

Empleado que tiene por trabajo colocar la mercanca en las gondolas de los supermercados y otros
establecimientos de comercio.

28.12.

Privilegio

Nivel de acceso que tendr

a un usuario y que influira directamente a la cantidad de informaci
on
que podr
a ver.

43

29.

Referencias

1. David Fuller Padilla. Apuntes de Taller de Ingeniera de Software, Captulo 4: Roles en el desarrollo de software. Universidad Catolica del Maule, Chile, 2003.
[ http://www.ganimides.ucm.cl/ygomez/descargas/Sist_inf2/apuntes/2009/Roles_desarrollo_
software.pdf ]
2. Inteligencia de Negocios. Identificar a los Stakeholders (Interesados) en un proyecto de Business
Intelligence. Mexico, 2011.
[ http://inteligenciadenegocio.mx/blog/identificar-a-los-stakeholders-en-un-proyectode-business-intelligence ]
3. SkillUp Chile
[ http://www.skillup.cl/ ]
4. SkillUpJapan
[ http://www.skillupjapan.co.jp/eng/ ]
5. Bizagi Process Modeler. Ver 2.6.
6. Cacoo
[ https://cacoo.com/lang/es/ ]

44