Universidad ORT Uruguay

Facultad de Ingeniería

Sistema SaaS de
Administración y Venta On-Line

Proyecto Integrador
Entregado como requisito para la obtención
del título de Analista Programador

Marcos Tusso – 129196

Miguel Diab – 125415

Tutor: Carlos Soderguit

2010
ABSTRACT

El Sistema SaaS de Administración y Venta On-Line es un sistema Web desarrollado en PHP

con base de datos MySQL, diseñado para facilitar la digitalización de la información de la
Distribuidora Grupo del Este de Maldonado.

El sistema cuenta con dos aplicaciones, por un lado el portal de la distribuidora, que alberga el
sitio institucional de la misma y es donde los clientes podrán realizar compras a través de
Internet, conocido como el “frontend” .

Por otro lado se encuentra el sistema de administración de la distribuidora que los encargados
de la misma utilizarán para ingresar compras, facturar las ventas, emitir listas de precios,
controlar el stock y administrar las cuentas corrientes de los proveedores y clientes, conocido
como el “backend”

El sistema está diseñado para correr sobre un servidor web, utilizando el Framework Symfony
Project sobre PHP del lado del servidor y el framework jQuery sobre JavaScript del lado del
cliente. Se utiliza el sistema de mapeo de objetos relacional Doctrine para la abstracción de
datos.

Si bien el diseño y desarrollo de la aplicación está orientado específicamente al flujo de

negocios de la distribuidora Grupo del Este, el sistema fue ideado con la generalización en
mente, para poder ofrecer el sistema a otras potenciales distribuidoras que deseen aprovechar
las funcionalidades del mismo.

Es así que el proyecto está orientado a un producto que pueda arrendarse por una
subscripción mensual como un servicio, de ahí el nombre SaaS, de las siglas en inglés
Software as a Service o Software como un Servicio.

2
“El Hombre es un experimento, el tiempo dirá si valía la pena”
Mark Twain

“El tiempo no se tiene, se hace”

Anónimo

3
TABLA DE CONTENIDOS
Tabla de Contenidos ................................................................................................................................. 4
1. Introducción ........................................................................................................................................ 6
Extracto .................................................................................................................................................... 6
El Cliente .................................................................................................................................................. 7
Ubicación e Historia ................................................................................................................................. 8
Organigrama y Cargos .............................................................................................................................. 9
Presentación del Problema ..................................................................................................................... 10
Roles y Responsabilidades ..................................................................................................................... 11
2. El Análisis ......................................................................................................................................... 12
Análisis Estratégico ................................................................................................................................ 12
Caso Real ................................................................................................................................................ 13
Lenguajes y Tecnologías ........................................................................................................................ 14
Herramientas y Procesos ........................................................................................................................ 15
Costos y Licencias .................................................................................................................................. 16
Factibilidad Económica .......................................................................................................................... 19
Factibilidad Tecnológica ........................................................................................................................ 20
Factibilidad Legal ................................................................................................................................... 21
3. El Equipo ........................................................................................................................................... 23
Quienes Somos ....................................................................................................................................... 23
Habilidades y Conocimientos ................................................................................................................. 24
Codificación y Mejores Prácticas ........................................................................................................... 25
SQA – Garantía de Calidad .................................................................................................................... 31
SCM – Administración de la Configuración .......................................................................................... 33
4. El Plan del Sistema ......................................................................................................................... 34
Arquitectura del Sistema ........................................................................................................................ 34
Estudio de Alternativas........................................................................................................................... 35
Plan de Proyecto ..................................................................................................................................... 36
Estimación de Tiempos, Desviaciones y Re-planificación ..................................................................... 37
Gestión de Riesgos ................................................................................................................................. 39
5. Historias de Usuario ........................................................................................................................ 43
Ingreso de facturas de compra ................................................................................................................ 43
Facturación a Almacen del Grupo .......................................................................................................... 44
Control de Pagos a Proveedores ............................................................................................................. 45
Recepción de pedidos On-Line............................................................................................................... 46
Facturación a Cliente sobre Pedido On-Line .......................................................................................... 47
Facturación a Cliente sobre Pedido en vivo ........................................................................................... 48
Registro de Usuario Online .................................................................................................................... 49
Reporte de Listas de Precios................................................................................................................... 50
Consulta de Pedido Online ..................................................................................................................... 51
Mantenimiento de Productos .................................................................................................................. 52
Mantenimiento de Clientes ..................................................................................................................... 53
Mantenimiento de Proveedores .............................................................................................................. 54
Mantenimiento de Monedas ................................................................................................................... 55
Mantenimiento de IVAs ......................................................................................................................... 56
Mantenimiento de Categorías ................................................................................................................. 57
Mantenimiento de Ciudades ................................................................................................................... 58
Mantenimiento de Países ........................................................................................................................ 59
6. Ingeniería de Requerimientos ........................................................................................................ 60
Patrones de Diseño ................................................................................................................................. 60
Patrones de Creación ......................................................................................................................... 60
Patrones Estructurales ....................................................................................................................... 61
Patrones de Arquitectura ................................................................................................................... 61
4
 Modelo – Vista – Controlador ................................................................................................................ 62
Diagramas de Deploy ............................................................................................................................. 64
Diagrama de Clases ................................................................................................................................ 65
Diagramas de Paquetes ........................................................................................................................... 66
Diagramas de Secuencia ......................................................................................................................... 68
Agregar Nuevo Cliente ....................................................................................................................... 68
Agregar Nuevo Artículo ...................................................................................................................... 69
Agregar Precio de Artículo.................................................................................................................. 70
Crear Nueva Factura de Compra ........................................................................................................ 71
Crear Nueva Factura de Venta ........................................................................................................... 72
Ingresar un Pedido On-Line ................................................................................................................ 73
Ingresar al Sistema ............................................................................................................................. 74
7. Sistema de Bases de Datos ........................................................................................................... 75
Motor de Bases de Datos ........................................................................................................................ 75
Desventajas ............................................................................................................................................. 76
Modelo Entidad Relación ....................................................................................................................... 77
Diseño de la Base de Datos .................................................................................................................... 78
Mapeo de Objetos Relacional ................................................................................................................. 81
Abstracción y Performance .................................................................................................................... 82
8. El Framework ................................................................................................................................... 83
Symfony Framework .............................................................................................................................. 83
jQuery y AJAX ....................................................................................................................................... 84
Look & Feel y Templates ....................................................................................................................... 85
Estructura de Directorios ........................................................................................................................ 86
9. El Proyecto ....................................................................................................................................... 88
Alcances y Limitaciones......................................................................................................................... 88
Debe Tener ......................................................................................................................................... 89
Sería Bueno Tener .............................................................................................................................. 91
Extras .................................................................................................................................................. 93
Planificación de Tareas........................................................................................................................... 95
Sprint 1 ............................................................................................................................................... 95
Sprint 2 ............................................................................................................................................... 96
Sprint 3 ............................................................................................................................................... 97
Sprint 4 ............................................................................................................................................. 100
Sprint 5 ............................................................................................................................................. 102
Sprint 6 ............................................................................................................................................. 104
Sprint 7 ............................................................................................................................................. 106
Estado Actual del Sistema .................................................................................................................... 108
Sprint 8 ............................................................................................................................................. 108
Evolución del Producto ........................................................................................................................ 109
Sprint 9 ............................................................................................................................................. 109
10. El Producto ................................................................................................................................ 110
Producto Final ...................................................................................................................................... 110
Instalación e Implementación ............................................................................................................... 112
Configuración ....................................................................................................................................... 118
Ayuda y Manual de Usuario ................................................................................................................. 120
Manual del Cliente ........................................................................................................................... 120
Manual del Administrador................................................................................................................ 124
Mantenimiento...................................................................................................................................... 133
Plan de Continuidad de Negocios ......................................................................................................... 134
Mercadeo y Plan de Futuro................................................................................................................... 135
Hosting y Subscripción......................................................................................................................... 135
11. Índice .......................................................................................................................................... 136
12. Anexos y Tablas ....................................................................................................................... 138
Bibliografía ........................................................................................................................................... 138
Referencias ........................................................................................................................................... 139

5
 1. INTRODUCCIÓN

EXTRACTO
El Grupo del Este está compuesto por una pequeña distribuidora y cuatro almacenes en la
ciudad de Maldonado. La distribuidora compra mercadería de múltiples proveedores, tanto en
Maldonado como en Montevideo, y a su vez vende esa mercadería a los almacenes de la
cadena y también hacia otros minoristas (clientes).

Actualmente la administración y el manejo de la información se realiza mediante tres sistemas.

El primero, es un sistema SaaS por subscripción mensual, desarrollado sobre J2EE y Oracle
SQL, que administra las compra/ventas de los almacenes, y el stock de los mismos. El
segundo es un sistema mono-usuario / mono-tarea propietario desarrollado sobre Visual Basic
y Access, para la emisión de facturas y control de stock, con grandes limitantes principalmente
en cuanto a usabilidad y limitantes técnicas (insuficiente cantidad de códigos, descuentos, etc).
Por último, el manejo de Proveedores y Clientes y sus pagos y cuentas corrientes se realiza
mediante una planilla compartida de Google Docs.

El equipo plantea desarrollar un sistema web flexible que opere en una modalidad SaaS
(Software como un Servicio) que logre resolver de manera holística el flujo de trabajo y
necesidades de reporte de la empresa. Para ello se contará con un sistema multiusuario de
venta On-Line disponible 24x365 y a través del nuevo sistema se simplificará
sustancialmente la digitalización de la información, que permitirá a la empresa gestionar sus
stocks, obtener reportes y mediante un control de flujo ordenado, acelerar su proceso de
despacho y ventas y por lo tanto crecer en el mercado local.

6
EL CLIENTE
El Grupo del Este es una agrupación de cuatro almacenes minoristas de Maldonado que
establecieron una alianza para la compra de mercadería dentro y fuera del departamento
para conseguir precios competitivos con las grandes cadenas de supermercados de la zona.

El líder encargado del grupo es Rafael Diab, previamente gerente de la cadena de

supermercados Super Usa de Maldonado, y es quien administra el depósito central junto a
Martha Leyton. Los demás almacenes tienen su encargado principal quien es a su vez el
encargado de compras.

El grupo tiene en sus depósitos principales el almacén de stock con la gran mayoría de los
productos que comercializa, mientras que cada almacén tiene un pequeño depósito propio que
administra localmente.

A su vez, la distribuidora opera con otros clientes, como ser re-vendedores locales de la zona,
tanto en Maldonado Nuevo como de las cercanías (Maldonado, Punta del Este y los barrios y
balnearios aledaños) e incluso otros almacenes y supermercados que realizan los pedidos y
levantan la mercadería de los depósitos centrales.

Esto presenta una dualidad frente a quien es el cliente. Por un lado, tenemos a los
administradores de la Distribuidora Grupo del Este, y por otro lado tenemos a los encargados
de los almacenes que realizan los pedidos junto a los clientes ajenos al grupo.

Durante el enfoque del sistema, debemos tener en cuenta la existencia de estos dos grupos de
clientes y diseñar una solución acorde a ambos, evitando duplicar esfuerzos al diseñar una
lógica que sustente este paradigma.

7
UBICACIÓN E HISTORIA
Actualmente el núcleo de la distribuidora se encuentra en la zona de Maldonado Nuevo, zona
de amplio crecimiento de la capital departamental de Maldonado, a metros de la principal
avenida de la zona, la Avenida de los Gauchos.

Los almacenes que componen al grupo son : el almacén Bartolito, al Sur de la Avenida de los
Gauchos, casi Avenida Aiguá; el almacén Pepe, sobre la zona Noreste de Maldonado Nuevo,
en la calle Caracará; el Semáforo hacia el final Norte de Simón del Pino y el 1ro de Mayo sobre
Manuel Menéndez hacia el Suroeste de Maldonado Nuevo, lo que le otorga al Grupo del Este
una posición especial en una red de almacenes cubriendo gran parte de la zona de expansión
de Maldonado Nuevo.

8
ORGANIGRAMA Y CARGOS

Rafael Diab está encargado de liderar el Grupo del Este, y es el principal interesado en el
sistema y también uno de sus principales usuarios.

Debajo de él se encuetra Martha Leyton, quien junto al equipo de Compras se encargarán de

ingresar las compras a proveedores en el sistema.

Por otro lado se encuetnra el equipo de Logística, quienes ensamblan fisicamente el pedido y
se encargan de facturar los pedidos de los clientes dando así de baja los elementos
despachados.

Como un subgrupo de clientes "especiales" se encuentran los cuatro almacenes del grupo,
quienes pueden encargar mercadería que es despachada automaticamente hacia sus
almacenes, pero que fuera de esa excepción, operan como un cliente corriente, ingresando
pedidos desde el frontend web.

9
PRESENTACIÓN DEL PROBLEMA
La reciente instalación de la distribuidora, hace que su proceso sea ineficiente y que los
sistemas informáticos que están utilizando no sean idóneos para las tareas, facilitando la no-
adopción de los mismos por parte del personal, y avalando el informalismo en las compras y
ventas, especialmente entre los almacenes del grupo.

La distribuidora maneja una lista de artículos del orden de cientos de miles de productos, y
éstos a su vez son adquiridos de casi una centena de proveedores. Cada uno con sus precios
y condiciones particulares que no son contempladas actualmente por el sistema.

También por la naturaleza del grupo, predomina el informalismo en el pedido y retiro de la

mercadería, lo que dificulta el control de stock y ventas por parte de los almacenes del grupo.

Queriendo crecer, para el grupo, es imperativo la existencia de un único sistema informático

que evite agregar complejidad a la digitalización de la información y al mismo tiempo facilite la
adopción del mismo.

Para ello se busca presentar una solución flexible, que de manera rápida y amigable pueda
adaptarse al ciclo de la distribuidora e imitando el proceso actual, lo acelere, permitiendo así,
atender más clientes por hora. Esta también debe ser capaz de emitir reportes y brindar
información a los líderes de la distribuidora, ayudando así a la toma de decisiones.

10
ROLES Y RESPONSABILIDADES
El equipo de trabajo ampliado está formado por una variedad de individuos con diferentes
habilidades y conocimientos, que van desde el diseño de arquitectura hasta las estrategias de
negocios y administración de la logística.

Es por eso un punto clave, determinar los roles y responsabilidades de cada individuo, para
poder rápidamente consultar con la persona indicada frente a una duda o sugerencia.

La tabla debajo intenta explicar brevemente quién es quién y de qué deberían de encargarse.

Nombre Rol Responsabilidades

Miguel Diab Desarrollador • Arquitectura del sistema

• Diseño de base de datos
• Diseño de la interfaz
• Programación del backend
• Programación de mantenimientos

Marcos Tusso Desarrollador • Diseño del frontend

• Diseño del flujo de negocio
• Desarrollo del carrito de compras
• Programación del frontend

Rafael Diab Dueño del • Definir funcionalidades básicas

Producto • Proveer información institucional
• Definir lineamientos del sistema

Marta Leyton Encargado del • Determinar “simpleza” del producto

Sistema • Reportar fallas críticas
• Corregir flujo del sistema

Giselle De Cliente de • Determinar usabilidad del Frontend

Armas Frontend • Reportar fallas de Venta OnLine

Gabriela Barrios Cliente de • Determinar usabilidad del Frontend

Frontend • Reportar fallas de Venta OnLine

Betina de Cliente de • Determinar usabilidad del Frontend

Armas Frontend • Reportar fallas de Venta OnLine

11
 2. EL ANÁLISIS

ESTUDIO DEL PROBLEMA

La distribuidora trabaja actualmente con el sistema Magnus de Compras, Lista de precios,
Facturación y Stock, el cual posee varias desventajas y limitaciones como:

• Es una aplicación pesada mono usuario desarrollado en Visual Basic con base de
datos Access.

• No permite a los almacenes u otros clientes acceder a través de la red.

• No permite dar de alta un producto de forma práctica y rápida durante el ingreso de

una factura al sistema.
Se debe salir de la ventana de facturas, ir al modulo de productos y luego regresar a la
factura.

• No permite ingresar automáticamente el costo del producto durante el alta.

Luego de creado se debe editar manualmente cada lista de precios y asignarle un
valor.

• No permite manejar múltiples listas de precio vinculadas con porcentajes.

Cada lista es única y el costo debe ser reingresado.

• No permite manejar campos extra en las facturas

Ya sean descuentos o aumentos, como por ejemplo gastos de transporte, ni códigos o
campos especiales indexados por los que se pueda hacer una búsqueda rápida.

• Los pedidos se hacen vía telefónica o en persona

Un cliente no puede hacer un pedido si no hay un vendedor de la distribuidora para
atenderlo.
No existe la venta On-Line, ni fuera de hora.

• En las facturas recibidas, el costo de los productos pueden tener IVA discriminado
o no.
En el sistema actual, esto no está contemplado. Actualmente es calculado a mano (con
calculadora) en el caso de los productos con IVA, ítem por ítem.

• El código es cerrado y los desarrolladores no planean agregar funcionalidades o

corregir las carencias actuales del sistema.

12
CASO REAL
Durante el relevamiento de información, un cliente se presentó a realizar un pedido, con su
"hoja de pedido" en mano, éste fue atendido por personal de la distribuidora y línea a línea se
fue armando su pedido en base a los ítems de los que se disponía stock.
Al mismo tiempo se anotaba del lado de la distribuidora en una factura a mano, la compra de
dicho cliente.

Finalmente, una vez armado el pedido, se controló toda la mercadería y se cargó en su furgón.
Este proceso duró más de una hora, y quedó solamente registrado en papel.

Las desventajas que esto presenta, y las formas propuestas para solucionarlas son :

o El cliente realiza pedido On-Line vs. llegar con hoja en mano de pedido
tentativo.

o El cliente puede ver precios y stocks actuales y cambiar su pedido por

productos alternativos en caso de faltantes o encontrar promociones que
benefician a ambos (el cliente y la distribuidora)

o El cliente puede realizar el pedido 24x365, en el horario que mas cómodo le

quede (no dependiendo del horario o la disponibilidad de la distribuidora)

o La distribuidora puede ordenar, preparar y agrupar el pedido en el tiempo

que quede más cómodo y notificar al cliente al estar listo para ser retirado.

o El cliente no debe esperar el tiempo de armado de su pedido, solo controlar

la mercadería despachada

o La distribuidora factura electrónicamente, agilizando el proceso y

eliminando errores de cálculo, y presentando una imagen mas profesional al
cliente

o El control de Stock se desprende automáticamente del flujo de trabajo. La

mercadería se da de alta y baja, actualizando la información On-Line,
disparando procesos de stock mínimo, Promociones, etc, facilitando a la
distribuidora un flujo del tipo JIT (Just In Time)

Las limitaciones del sistema actual hacen que el sistema sea poco eficiente, y requiera de
gran tiempo y esfuerzo para completar tareas, las cuales se pueden mejorar
considerablemente.

Al agregar funcionalidades clave se va a facilitar la adopción del sistema y evitar la no

utilización del usuario final debido al tiempo requerido para completar estas tareas.

Éste será el foco del proyecto. Los cambios durante el proyecto deben preservar o aumentar el
objetivo de mejora que la empresa busca con el sistema.

13
LENGUAJES Y TECNOLOGÍAS
El núcleo del sistema será desarrollado en PHP 5.2.xx sobre el framework Symfony MVC
v1.4.x. Para la persistencia de datos se utilizará el ORM Doctrine v1.2.x como capa de
abstracción de la bases de datos MySQL v5.1.xx (Community Edition) . El servidor de
presentación correrá sobre el sistema operativo Ubuntu Server corriendo Apache Http Server
2.2.xx .

Todas estas tecnologías son Open Source y sumamente estables, lo que garantiza un TCO
(Coste Total de Propiedad) muy bajo en comparación a sistemas propietarios y una
infraestructura abierta, estable y en continua actualización. El licenciamiento de la aplicación
por lo tanto, se ve reducido solamente a los costes del mantenimiento de la infraestructura y de
los RRHH técnicos que se necesiten para la misma, haciendo de la puesta en marcha del
sistema, un servicio sumamente rentable.

Otro punto para la decisión de los lenguajes y tecnologías, fue la experiencia previa del equipo
en la misma. Habiendo desarrollado productos anteriormente sobre tecnologías PHP y
específicamente el uso del framework Symfony, presenta una ventaja al momento de analizar
los riesgos.

14
HERRAMIENTAS Y PROCESOS
Para el desarrollo del sistema se utilizaran una amplia gama de herramientas informáticas que
ayudan tanto en el desarrollo como en la administración del proyecto.

Principalmente el sistema será desarrollado sobre la IDE NetBeans 6.8 con el módulo
específico para PHP junto al plug-in de Symfony, Esto permite tanto la ejecución del entorno de
desarrollo como la ejecución de comandos de la consola de Symfony y la depuración en tiempo
real del código PHP.

Para el diseño de la base de datos se utilizará el sistema Oracle MySQL Workbench v5.1.xx
junto con los complementos MySQL Query Browser y MySQL Administrator. Todas en sus
versiones Open Source Community Edition.

Al momento de diseñar los diagramas UML necesarios para el sistema, se utilizará la

herramienta libre de diseño BoUML, la misma permite hacer diagramas de secuencia, casos de
uso, diagramas de implementación y análisis de flujo de datos entre otros, que facilitarán a los
desarrolladores la tarea de plasmar las especificaciones del sistema de manera formal.

Como apoyo visual, se utilizarán diagramas de arquitectura y organigramas diseñados por la

aplicación on-line Gliffy, los mismos serán exportados en formato PNG y SVG y versionados
junto a la documentación.

Al momento de gestionar y planificar el proyecto, se optó por una metodología tipo Scrum, con
iteraciones de dos semanas. Para el seguimiento de la misma se utilizó la herramienta de
gestión Trac junto a los plugins de Scrum de Burndown, Iterations y Time Reports

15
COSTOS Y LICENCIAS
Durante el planeamiento de la arquitectura, y considerando la necesidad de implementar el
sistema en producción, con acceso multiusuario desde la red pública, se tuvo especial cuidado
en el estudio del licenciamiento tanto de las herramientas como de los sistemas utilizados para
el desarrollo e implementación de la arquitectura.

Así mismo, sobre las aplicaciones que no se licencien en un formato libre de existir, se
detallarán los costes de las mismas y se estudiaran los términos bajo los cuales es posible
instalarlas, en cuántos servidores, sobre qué número de procesadores, etc.

El servidor de aplicaciones correrá con el software descrito debajo :

Servidor Licencia Costo

Ubuntu Server GNU General Public License 2.0 $0

Apache Web Server Apache License, Version 2.0 $0

MySQL Server GNU General Public License 2.0 $0

Intérprete PHP PHP License v3.01 $0

Total Costos $0

Del lado del servidor, sobre la plataforma PHP, correrá el framework Symfony MVC y del lado
del cliente sobre JavaScript el framework jQuery.

Frameworks Licencia Costo

jQuery MIT License $0

Symfony Framework MIT License $0

Total Costos $0

16
Para el diseño de la base de datos y el MER se utilizará MySQL Workbench y para los
diagramas de clases, de secuencia y la edición de otros elementos UML, se utilizará BoUML.

Herramientas de Diseño Licencia Costo

MySQL Workbench GNU General Public License 2.0 $0

BoUML GNU General Public License 2.0 $0

Total Costos $0

Para la administración, respaldo y mantenimiento de la base de datos se utilizarán los

complementos del servidor MySQL, el Query Browser y el Administrator.

Para la edición y depuración del código, tanto PHP como JavaScript se utilizará la IDE
NetBeans con el plug-in de Symfony y los fuentes de jQuery. Para algunas ediciones menores
y proceso de archivos de texto plano se utilizará Notepad++.

Herramientas de Desarrollo Licencia Costo

MySQL Query Browser GNU General Public License 2.0 $0

MySQL Administrator GNU General Public License 2.0 $0

Common Development and

NetBeans IDE $0
Distribution License (CDDL) v1.0

Notepad++ GNU General Public License 2.0 $0

Total Costos $0

17
Para la administración del proyecto y el seguimiento del plan, se utilizará la herramienta de
gestión de proyectos Trac, con los plug-ins de Scrum. Para el versionado del código y el control
de cambios, la misma tendrá interfaz con un repositorio SVN.

Seguimiento y Administración Licencia Costo

Trac Edgewall BSD License $0

Apache SVN Apache License, Version 2.0 $0

Total Costos $0

18
FACTIBILIDAD ECONÓMICA
El Grupo del Este se encuentra en pleno crecimiento en su posición como distribuidor de
productos de Maldonado. Como tal, sus recursos son limitados y su situación económica está
dada por la voluntad de sus integrantes de hacer crecer al grupo, más que por su posición
consolidada como distribuidora.

Esto plantea un punto delicado en cuanto a la factibilidad económica del proyecto, limitando las
tecnologías y los costes de los sistemas considerablemente. Por ejemplo, es inviable
considerar la implementación del sistema en servidores propios. De la misma manera es poco
probable que se accedan a los costes de un sistema operativo propietario, junto a tecnologías
del tipo, como pueden ser ASP .Net o similares. Es por eso que se enfoca como un
requerimiento no funcional importante, el uso de tecnologías gratuitas Open Source.

El otro punto que fue fundamental en la decisión del Grupo, fue la presentación del sistema en
formato SaaS. Software como un Servicio. Esto les permite por una baja subscripción mensual,
hacer uso de un sistema de gran porte, con sus características y funcionalidades, que de ser
adquiridos en plaza para la infraestructura de la distribuidora, excedería las capacidades del
Grupo como una inversión inicial.

De esta misma manera, para el equipo de trabajo, el planteo de una relación a largo plazo,
brinda una estabilidad y seguridad que permite afianzar al equipo y evolucionar el producto
hasta que sea suficientemente genérico y estable para ser ofrecido en plaza como una
alternativa a los sistemas actuales de administración de ventas.

En resumen, la combinación de la práctica SaaS, el costo cero de licencias y el hosting

tercerizado, hacen de esta empresa, una fórmula idónea tanto para el cliente como para el
equipo de trabajo, ambos con expectativas a futuro, pero sin requerir de una gran inversión
inicial.

19
FACTIBILIDAD T ECNOLÓGICA
El mundo de la informática, y en particular del desarrollo de software, cambia a pasos
agigantados. Tecnologías que son vanguardistas a principio de una década, resultan obsoletas
al final de la misma. Es por eso que hay que ubicar el desarrollo tecnológico en su contexto.
Estar muy bien informado sobre la situación actual, y tomar decisiones concisas, sin
cuestionarse a los meses sobre que tan acertada fue tal o cual elección. Ya que para ese
entonces, esta puede resultar obsoleta.

Al momento de empezar el proyecto, se decidió sobre una infraestructura en PHP/MySQL,

haciendo extensivo uso del framework de Symfony según el modelo MVC que simplifica la
garantía de seguridad y estabilidad del sistema, y del framework jQuery para hacer extenso uso
de tecnologías AJAX para dar una experiencia moderna al usuario.

Esto implica cierta atadura respecto a la arquitectura del sistema, ya que un rediseño de la
misma tendría un coste agregado. Aún así, la decisión se toma a conciencia de que el ahorro
en el diseño y desarrollo actual, en base a la tecnología elegida, supera con amplios márgenes,
el diseño de una solución más abstracta que permita una alternativa a futuro que se
desconoce.

Utilizando tecnologías de última generación, estamos seguros de poder satisfacer las

necesidades del cliente con creces. Sabiendo que un cambio de tecnologías en el futuro
cercano no pondría en peligro la validez del sistema actual.

20
FACTIBILIDAD LEGAL
El sistema que planteamos opera en una modalidad de costeo mensual para la empresa, con
un contrato mínimo de 12 meses de servicio, con dos meses de prueba de garantía. Esto se
encuentra en el contrato formalizado con la empresa según detalle que se muestra a
continuación.

Respecto a los estatutos legales, el sistema está amparado por las normas de derecho de
autor establecidas en la Ley No. 9.739 de 17 de Diciembre de 1937, actualizada en 2003. (Ver
anexos legales).

De la misma manera, la entidad de la empresa está representada por la Sociedad Anónima

Miguel Amyn Diab Romero S.A. RUT 100.52.66.100.14 amparado según el artículo 418 de la
ley 16.170.

PRIMERO: YKI.COM.UY con domicilio en Colonia 2104 Ap. 402, Montevideo, Uruguay (de ahora en
adelante “Yki”) brindará al GRUPO DEL ESTE con domicilio en Ramón Masetti s/n entre Avenida de los
Gauchos e Isla de Flores, Maldonado, Uruguay (de ahora en adelante “El Grupo”) los servicios del
Sistema de Administración y Venta OnLine por Internet a través de la empresa MIGUEL AMYN DIAB
ROMERO S.A.

SEGUNDO: CARACTERÍSTICAS DEL SERVICIO.- Los encargados del sitio recibirán un par de credenciales
compuestas de nombre de usuario y contraseña que les dará acceso a la página de la empresa
GrupoDelEste.Com.Uy, para realizar la administración del sitio desde el “backend”. Yki se obliga a
mantener en funcionamiento las 24 horas del día los 365 días del año los servidores de aplicación como
los sistemas de venta online y de ingreso de usuarios que se indica en este contrato, salvo razones de
fuerza mayor o caso fortuito, no siendo responsables por cortes en los servicios de Internet que por
cualquier causa se puedan producir tanto en el Uruguay como en el exterior.

TERCERO: PROCESO DE REGISTRO.- El sistema de acceso al sitio de compras GrupoDelEste.Com.Uy con

este servicio exige el ingreso de nombre de usuario y contraseña. Una vez verificada la transacción
electrónica, los usuarios recibirán un correo electrónico que les otorgará las claves (código de usuario y
contraseña) para acceder en forma inmediata. Este proceso debería llevar no más de dos horas de
finalizada la transacción. Si por alguna razón esto no ocurre, el usuario tiene una dirección de asistencia
técnica ([email protected]) a la que podrá recurrir.

CUARTO: PRECIO.- El plazo de validez y los términos del contrato de suscripción son de
U$S 999 para el servicio por doce meses o de U$S 96 para el servicio mensual, siendo pagaderos antes

21
de los diez días hábiles corridos una vez firmado el contrato. Para los ciudadanos residentes en Uruguay,
se agregará a este valor el impuesto al valor agregado (IVA) del 22%.

QUINTO: RENOVACIÓN.- Las suscripciones serán renovadas en forma automática sin

que el usuario deba ingresar sus datos nuevamente. Si el usuario no desea renovar
su suscripción, puede desactivar la renovación automática utilizando el comando de
"no renovar" que encontrará en la página "Administración". Sin embargo, el servicio
seguirá disponible hasta el vencimiento del plazo que estaba originalmente
contratado. Por ejemplo si el usuario se afilió el 20 de Noviembre y cancela el día
10 de Diciembre, sus claves de acceso (si cancela por medio del sistema)
continuarán siendo validas hasta el 19 de Diciembre, o sea, válidas por el plazo que
ya está abonado.

SEXTO: PRIVACIDAD Y TARJETAS DE CREDITO.- La información de las tarjetas de crédito se envía por un
canal seguro directamente a los emisores de las tarjetas y queda almacenada ahí. Para total seguridad
del usuario, ni Yki.Com.Uy ni MIGUEL AMYN DIAB ROMERO S.A. tienen acceso a esa información en
ningún momento de la transacción, situación que el usuario reconoce y acepta. La información de los
usuarios no será utilizada para ningún otro fin comercial que no sea el del servicio contratado.

SÉPTIMO: COSTES AFINES.- Los costes generados por el mantenimiento y soporte del sitio, así como el
registro de dominios frente a la entidad pertinente, corren por cuenta de Yki. Así mismo, son de su
propiedad el uso de los mismos, aceptando el cliente el ceder los derechos de los mismos, con la
garantía del contrato y la cláusula de “no competencia” por la que se rige Yki. El uso de los dominios
asociados con un cliente dado, no será utilizado para ningún otro fin comercial que no esté amparado
por los dueños de la respectiva marca.

OCTAVO: NORMATIVA LEGAL.- Si a lo largo de la validez de este acuerdo llegaran a surgir en Uruguay o
en el exterior, limitaciones legales, modificaciones de las leyes de comercio electrónico, nuevos tipos de
cargas impositivas o cualquier otro tipo de reglamentación o legislación que imposibilite a cualquiera de
las dos partes la continuación normal de las transmisiones por Internet, este acuerdo podrá ser
cancelado en forma unilateral por cualquiera de las partes sin responsabilidad para ninguna de ellas.

NOVENO: El presente contrato se regirá por las leyes de la República Oriental del Uruguay.

22
 3. EL EQUIPO

QUIENES SOMOS
El equipo de desarrollo está compuesto por dos entusiastas de la tecnología y la informática.
En este mundo siempre cambiante, luchan para mantenerse al día con los cambios en
metodologías, procesos y paradigmas.

Miguel Diab vivió su infancia en La Barra de Maldonado, después de un año sabático por
Europa se mudó a Montevideo, dónde se dedicó al estudio de Tecnologías de la Información.
Actualmente trabaja para www.betboo.com encargado del diseño y desarrollo para el proyecto
eBingo. Participa ocasionalmente en proyectos freelance o como consultor para diferentes
entidades. Es un apasionado de la fotografía y de todo dispositivo eléctrico más complejo que
un interruptor.

Marcos Tusso nació en Sao Paulo, Brasil, donde vivió hasta los 12 años de edad. Su carrera
en IT se inició en Tiendas Montevideo. Actualmente es encargado del área técnica para el
soporte de Call-Centers de Sabre Holdings en USA, Europa y Uruguay, integrando nuevas
tecnologías entre los diversos equipos de soporte. Es amante del futbol, hincha del Sao Paulo
Futbol Club.

23
HABILIDADES Y CONOCIMIENTOS
Los integrantes del equipo de desarrollo han sido capacitados en diversas áreas de la
ingeniería de software. Ambos poseen un excelente nivel académico logrado en la Universidad
ORT de Montevideo, Uruguay.

Complementando la formación académica, ambos integrantes trabajan en el ámbito informático

y han recabado a lo largo de los años una amplia trayectoria rica en experiencias, que les
permite un manejo sumamente calificado al momento de diseñar, desarrollar, implementar y
administrar un sistema de estas características.

24
CODIFICACIÓN Y MEJORES PRÁCTICAS
Para la mayor claridad y legibilidad del código, se respetarán los siguientes estándares de
programación y documentación. Poniendo especial énfasis en el tabulado y en la nomenclatura
de los métodos y variables, para facilitar la nemotecnia al momento de mantener el código.

Término Descripción

Una palabra con la primera letra en minúsculas, y la primera letra de

cada una de las palabras subsecuentes en mayúsculas.
Camel Case

Ejemplo: customerName

Una palabra con la primera letra en mayúsculas, y la primera letra de

cada palabra subsecuente también en mayúsculas.
Pascal Case

Ejemplo: CustomerName

Comienzan con una o mas letras en minúscula que denotan el tipo de

la variable
Hungarian Notation

Ejemplo: strVariable

Indica palabras separadas con infraguión.

Underscore Separated
Ejemplo: CUSTOMER_DETAIL

En esta sección se incluye un breve resumen de los principales estándares descriptos a los
largo de este documento. Estas tablas no son detalladas en sus descripciones, pero brindan
una rápida referencia a los elementos.

25
Convenciones de Nomenclatura

c Camel case

P Pascal case

_ Prefijo con infraguión (underscore)

No aplica

Identificador Public Protected Internal Private Notas

Archivo de proyecto P Debe corresponder al

Assembly y al Namespace.

Archivo del código fuente P Debe corresponder con la

clase que contiene. En el caso
que el archivo contenga más
de una clase, se deberá tomar
el nombre de aquella más
representativa o bien un
nombre que simbolice
claramente su función.

Otros archivos y carpetas P

Namespace P Sicac.DataAccess

Class o Struct P P P P Ejemplo: Customer

Interface P P P P Debe tener el prefijo “I”.

Ejemplo: IDeriv–able

Exception class P P P P Siempre debe tener el sufijo

“Exception” luego del nombre.

Ejemplo:
CustomerModuleException

26
Convenciones de Nomenclatura (cont)

Identificador Public Protected Internal Private Notas

Method P P P P Utilizar verbo o verbo-

objeto.

Ejemplo: ToString

Property P P P P No utilizar prefijos. No

utilizar Get / Set como
prefijos.

Ejemplo: BackColor

Atributos P P P _c Utilizar solo Private fields.

No utilizar notación
Húngara (Hungarian
Notation).

Constant P P P _c Ejemplo: _maximunItems

Static field Read-only P P P _c Utilizar sólo atributos

Private.

Ejemplo: _redValue

Enum P P P P Utilizar PascalCase también

para las opciones.

Ejemplo: ErrorLevel

Delegate P P P P

27
Convenciones de Nomenclatura (cont)

Identificador Public Protected Internal Private Notas

Event P P P P Debe nombrarse preceder

al nombre del evento, el
nombre del objeto al que
está suscripto.

Ejemplo:
IdObjeto_ValueChange

MyButton_Click

Inline variable c Evitar caracteres únicos y

tipos enumerados.

Parameter c Ejemplo: typeName

Estilos de Codificación

Código Estilo

Archivo del código fuente Un directorio por Namespace y un archivo por clase.
(Source code)

Llaves {} Siempre en una nueva línea.

Tabulación (Indent) Utilizar siempre tabs de 4 caracteres. No utilizar espacios en blanco.

Comentarios (Comments) Utilizar “//”. No utilizar “/*…*/”.

Variables Una variable por cada declaración.

28
Estilos de Codificación (cont)

Código Estilo

Tipos de datos nativos (Native Priorizar el uso de tipos nativos de C# ante tipos del CTS.
Data Types)
Ejemplo: int en lugar de Int32.

Enumerados (Enums) Evitar cambiar el tipo de dato predeterminado.

Tipos genéricos (Generic types) Utilizar preferiblemente tipos genéricos ante tipos estándar o strong-
typed classes.

Propiedades (Properties) No utilizar prefijos Get / Set.

Métodos (Methods) Utilizar en lo posible un máximo de 7 parámetros para que su lectura no

sea dificultosa.

Base / This Utilizar solo en constructors o dentro de override.

Condiciones ternarias (Ternary

conditions)

For each No modificar tipos enumerados dentro de una sentencia foreach.

Condicionales (Conditionals) Evitar la evaluación de condiciones booleanas contra valores true o false.

Manejos de excepciones No utilizar excepciones para el control de flujo.

(Exception Handling)
Utilizar throw; NO throw e; cuando se redirije.

Sólo utilizar catch cuando es posible manejar la excepción.

Utilizar validaciones para evitar la ocurrencia de excepciones.

Eventos (Events) Siempre debe validarse el valor null antes de la invocación.

Dispose() / Close() Utilizarlo siempre que sea posible.

29
Estilos de Codificación (cont)

Código Estilo

Finalizers Evitar la implementación de estos métodos.

Utilizar la sintaxis del destructor de C#. Ejemplo: ~MyClass() {…}

Nunca debe definirse un método llamado Finalize();

AssemblyVersion Incrementar en forma manual.

ComVisibleAttribute Debe estar con el valor false para todos los assemblies.

30
SQA – GARANTÍA DE CALIDAD
La calidad del proyecto estará dada principalmente por el modelo de trabajo a seguir en el
desarrollo del mismo. Adoptando metodologías Ágiles y mediante el uso de Scrum
particularmente, se podrá hacer un seguimiento del proyecto y un manejo en tiempo real de las
desviaciones y cambios en los requerimientos, garantizando así, un máximo aprovechamiento
del tiempo y satisfacción con el cliente.

La plataforma elegida para esto ha sido el sistema de gestión de proyectos Trac v0.11.x. El
mismo cuenta con funcionalidades de wiki, administración de cambios y reporte de errores.
Opera en una modalidad de Scrum, brindando gráficos de Velocidad, Burndown y reporte de
horas. También posee integración con el sistema de control de cambios SVN, y permite asociar
las historias de usuario y los errores reportados específicamente al cambio de código realizado
para implementar o solucionar el mismo.

La documentación estará disponible 24x365, por un lado dentro del sistema como ayuda
contextual, indicando los pasos a seguir para las funcionalidades clave e independiente en un
formato de tipo wiki (con restricciones de acceso) en la página Trac del proyecto. Otra ventaja
de este sistema, es que se beneficiará de comentarios y agregados tanto de los
desarrolladores como de otros stake-holders, como ser expertos en áreas claves, tutores y
hasta el mismo cliente.

El seguimiento del proyecto se podrá ver a través de la funcion de Timeline, dónde no solo se
registrarán los cambios en el código, sino también los últimos cambios en la documentación, en
el avance de tareas y en la resolución de errores.

31
El servicio de reporte de errores y cambios está orientado hacia una metodología Scrum,
permitiendo definir Requerimientos, Historias de Usuario y Tareas, y estas asociadas a Sprints
y a Milestones, mostrando de una manera minimalista y simple, el avance del proyecto.

Todos los stake-holders tendrán acceso a este sistema, para poder exigir y garantizar la mejor
calidad del producto y la rápida detección y corrección de errores. El uso de Scrum exige tanto
al cliente (o la persona responsable por parte del cliente) como a los desarrolladores, que los
entregables sean probados por ambos y aprobados a cada sprint. Para simplificar la
automatización de los mismos, el equipo del proyecto planea usar tests unitarios
automatizados, que serán expandidos con cada error detectado, para así evitar incurrir dos
veces en el mismo defecto.

32
SCM – ADMINISTRACIÓN DE LA CONFIGURACIÓN
Desarrollando en un ambiente multi-programador y trabajando para un cliente remoto, es
fundamental hacer un claro seguimiento de los cambios en la arquitectura y en la codificación
para poder detectar cambios no deseados y volver atrás en el tiempo en caso de necesitar
funcionalidades anteriores.

El control de cambios y versionado se manejará mediante un Servidor SVN seguro, que guardará
repositorios con el avance del proyecto y los cambios y actualizaciones del mismo.

Al mismo tendrán acceso los desarrolladores del sistema solamente.

33
 4. EL PLAN DEL SISTEMA

ARQUITECTURA DEL SISTEMA

El sistema para Grupo del Este será desarrollado en base a una arquitectura SaaS (Software
como un Servicio) e implementado en una plataforma online 24x365 con alta disponibilidad.

De esta manera los usuarios podrán acceder tanto desde dentro de las instalaciones de la
distribuidora como desde fuera y más importante, los clientes tendrán acceso a realizar pedidos
y verificar información sobre los mismos independientemente del horario de la distribuidora.

El núcleo del sistema correrá sobre el servidor de presentación Web Apache, con el módulo de
pre-interpretación PHP. El mismo utilizará las librerías de cliente de MySQL para conectarse al
servidor de bases de datos.

Los clientes accederán al sistema a través del sitio institucional de la distribuidora. Mientras
que los usuarios tendrán un back-end oculto. Ambos sitios estarán protegidos contra accesos
no validados y guardaran registros de acceso y acciones, en base a lo definido con el cliente.

34
ESTUDIO DE ALTERNATIVAS
El proyecto planteado presenta varias similitudes con ofertas en plaza. Es por lo tanto lógico
cuestionar sobre la validez del diseño e implementación de un nuevo sistema. Para evitar
redundancia de esfuerzos se hizo un estudio sobre posibles alternativas al sistema propuesto.

Entre las alternativas analizadas, se encuentra el sistema SaaS de la empresa ScanTech. El

mismo si bien presenta muchas funcionalidades similares al sistema actual, está enfocado
hacia la venta minorista de supermercados. Teniendo un gran énfasis a la compatibilidad con
cajas registradoras y ventas de momento. El mismo no tiene la capacidad de prever ventas de
clientes en base a históricos, ni de guardar registro de los mismos de manera práctica,
principalmente debido a la alta rotatividad de los clientes.

Otra gran desventaja es la carencia de sistema de venta On-Line o la capacidad de

interconectar sistemas ya existentes con el mismo. El uso de tecnologías propietarias (bases
de dato Oracle) y su solución cerrada, sobre la plataforma J2EE, hacen que la interconexión a
los mismos no se pueda realizar de forma nativa, salvo bajo pedido de cambios a la empresa,
lo que redunda en costos y tiempos de desarrollo para un sistema no personalizado.

De la misma manera existen alternativas de eCommerce o Carritos de Compras para la venta

On-Line, pero nuevamente estas alternativas carecen del manejo de stocks y clientes
requeridos por el Grupo del Este.

Por último, existen en el flujo actual de negocios, ciertas particularidades propias al Grupo del
Este ya como éste está conformado. Por ejemplo la venta directa a un almacén del grupo, pero
manteniendo información sobre stocks y compras generales, entre otros.

Estos casos obligan a la solución SaaS, un enfoque puntual a medida y considerando estas
situaciones como únicas al propio funcionamiento de la distribuidora.

35
PLAN DE PROYECTO

El proyecto será desarrollado siguiendo las metodologías de Scrum y con un enfoque

hacia las prácticas Ágiles.

Según el manifiesto :

Estamos descubriendo formas mejores de desarrollar

software tanto por nuestra propia experiencia como
ayudando a terceros. A través de este trabajo hemos
aprendido a valorar:

Individuos e interacciones sobre procesos y herramientas

Software funcionando sobre documentación extensiva
Colaboración con el cliente sobre negociación contractual
Respuesta ante el cambio sobre seguir un plan

Esto es, aunque valoramos los elementos de la derecha,

valoramos más los de la izquierda.

Como tal, el plan de proyecto presentado más adelante, sufrió y sufrirá una cantidad
de variaciones en pro de la mejora del sistema, de la entrega de un producto más
relevante en el período de tiempo dado, y de enfocarnos a las necesidades reales del
cliente, por sobre las ideologías de los desarrolladores.

Intentamos en el proceso, dejar de lado las idiosincrasias del creador, y adaptarnos al

mundo cambiante que exige velocidad, adaptabilidad y competitividad por sobre todas
las cosas, pero siempre, sin relegar de nuestra formación académica, y
posicionándonos como consultores expertos, intentando brindar un consejo claro al
cliente.

36
ESTIMACIÓN DE TIEMPOS, DESVIACIONES Y RE-PLANIFICACIÓN
La estimación de tiempos definida en el Ante Proyecto fue drásticamente cambiada debido a
diferentes factores que alteraron el proceso de desarrollo.

A continuación, pasaremos a explicar algunos de ellos, no como excusas, sino como lecciones
aprendidas en el transcurso del proyecto, para que sirvan como guía futura de nuevos
emprendimientos.

Sobre-confianza en la tecnología.

El primer y probablemente más grave error al estimar originalmente los tiempos fue la
sobre-confianza en la tecnología a utilizar por el equipo. Habiendo desarrollado
previamente aplicaciones en Symfony v1.1 y v1.2, supusimos dominar el framework
para el desarrollo de este sistema.

Al comenzar el desarrollo, encontramos que la versión v1.1 estaba completamente

deprecada, mientras que la v1.2 se encontraba con solo seis meses más de soporte.
Mientras que la v1.4 se anunciaba como seguidora y con al menos 3 años de soporte
futuro.

Cuando se empezó la codificación en esta nueva versión, muchos formalismos y

modos mas estrictos de programación, exigieron re-aprender a utilizar el framework,
atrasando así el primer sprint y por ende, los sucesivos

Fallo en predicción de tareas finas.

Otro punto grave de error, fue en cuanto a la predicción del tiempo llevado por tareas
finas.

Por ejemplo el tiempo que puede llevar el desarrollo de una función en JavaScript con
librerías jQuery que permitan el cálculo de los totales de una factura en tiempo real,
con ajuste de precios según la lista de precios de cada cliente y la moneda específica
del producto en base a la determinada por el cliente como moneda por defecto.

Tareas como estas o similares, llevaron hasta 4 veces más de las planificadas,
nuevamente retrasando el proyecto.

37
Trabajo sobre tareas no planeadas.

Un punto considerable a tener en cuenta, fue la falta de formalidad del equipo de

desarrollo. Al momento de trabajar, nos encontramos intentando solucionar problemas
en un punto dado, relegando funcionalidades que deberían de ser trabajadas en su
lugar.

Así, se perdieron varias horas intentando solucionar un problema (trivial o no) en lugar
de intentar cumplir con las tareas planeadas

Respeto de los tiempos y plazos

En los Sprints de 14 días, resultó clara la necesidad de respetar los tiempos

establecidos.

La falta de reuniones formales del equipo, como ser una reunión de iteración previo al
comienzo de la misma, ocasionaron que muchos Sprints se comenzaran desfasados,
creando así sobrecargas al planear trabajo de 14 días en menos de la mitad del
tiempo.

38
GESTIÓN DE RIESGOS
En el Análisis Estratégico surgieron varios factores de riesgo a considerar.

Tamaño del producto

El primer factor de riesgo está dado por el mero tamaño del proyecto.

La distribuidora Grupo Del Este necesita un sistema unificado que logre manejar las diferentes
áreas de la misma, interconectando lo que serán "Módulos" independientes del sistema.

En ellos se encuentran el sistema de Gestión de Pedidos On Line, el sistema de Control de

Stock, el sistema de Facturación de Compras y emisión de Remitos, la Administración de
Clientes y Proveedores, el manejo de Listas de Precios, y las varias administraciones y
mantenimientos para la correcta operativa del sistema.

Esto lo convierte en un proyecto muy ambicioso y de gran envergadura para desarrollar en el

corto plazo de seis meses.

Para mitigar este riesgo, la alternativa más clara es reducir el primer alcance del proyecto para
lograr cumplir con los objetivos pactados de manera de mantener la calidad esperada.

El segundo enfoque y complementario del primero, fue el de organizar las tareas según
importancia y necesidad para el cliente. Mediante este enfoque, aún sin lograr el 100% del
producto desarrollado, para una primera instancia se asegura de tener las funcionalidades más
deseadas por el cliente, así como las más críticas para la operación diaria.

39
Seguridad On Line

Al contener información sensible, tanto del cliente, como de los clientes del mismo, el sistema
debe correr sobre una plataforma extremadamente segura y confiable.

Los datos manejados deben mantenerse siempre bajo control del equipo y de la distribuidora y
sumo cuidado debe tenerse en las posibles violaciones de seguridad y acceso.

Para mitigar una posible violación de seguridad, se pondrá gran énfasis en el continuo
explotamiento de posibles vulnerabilidades mediante pruebas automatizados que garanticen
paso a paso, la seguridad y confiabilidad del sistema.

Como complemento se utilizará la infraestructura del framework de Symfony junto a los plugins
desarrollados para garantizar la seguridad del sistema.

Por último se hará una minuciosa restricción del sistema de producción, dónde la opción por
defecto será la revocación de permisos, y luego excepciones serán agregadas para permitir el
correcto funcionamiento de la aplicación.

40
Alta Disponibilidad

El sistema no solo será el frente de administración de la distribuidora, también será tanto el sitio
institucional como el acceso On-Line a los clientes registrados a realizar pedidos y consultar los
mismos.

Por lo tanto, el sistema debe encontrarse disponible y con un nivel de respuesta aceptable que
exige un servidor de aplicaciones confiable que corra en un entorno veloz y con redundancia.

Para confiar en la arquitectura seleccionada, el sistema será regularmente sometido a una

serie de pruebas de stress y capacidad. Pruebas de acceso concurrentes, transaccionalidad y
carga forzada serán garantizados mediante estas pruebas.

Como complemento, un hosting tercerizado será contratado para el albergue del sistema,
teniendo en cuenta antes de la contratación las garantías de disponibilidad del mismo, y se
tendrá para casos de emergencia un sistema local redundante que permitirá continuar con las
tareas normalmente, aún en situación de desastre.

41
Compatibilidad

Los sistemas Web, están pensados para correr sobre una infinidad de sistemas y plataformas,
accesibles desde los dispositivos mas disimiles. Mientras es posible controlar desde dónde y
cómo accederán los usuarios, no es posible garantizar lo mismo de los clientes. Por lo tanto el
sistema debe contemplar la mayor cantidad de plataformas posibles, para maximizar la
experiencia del cliente final con el sistema.

El sistema será probado en las siguientes plataformas y en sus varias combinaciones :

o Sistema Operativos
Windows 98, Windows XP, Windows 7, Linux, Symbian OS (móvil), Mac OS X

o Navegadores
Ms Internet Explorer 6, 7 y 8, FireFox 2, 3 y 3.5, Chrome, Opera, Ópera Mini,
Konqueror

o Resoluciones
Aspecto 4:3 : 800x600 / 1024x768 / 1280x1024
Aspecto 16:9 : 1024x640 / 1280x720 / 1680x1050

Adicionalmente, el desarrollo será llevado a cabo según el framework jQuery que permite el
uso de Javascript en modo compatibilidad según los navegadores seleccionados, quitando la
responsabilidad del programador sobre los estándares tan dispares que ofrecen los diferentes
navegadores en diferentes plataformas.

42
 5. HISTORIAS DE USUARIO

INGRESO DE FACTURAS DE COMPRA

Un administrador recibe una hoja de factura de compra a un proveedor, e ingresa la misma al

sistema.

Al ingresar los datos del proveedor, debe buscar automáticamente en la lista de proveedores
del sistema. De no existir, debe poder ingresarlo desde la ventana de factura, sin necesidad de
navegar fuera de la factura, ni perder los datos que ya haya ingresado en la misma.

Para ingresar la línea de la factura, puede buscar el articulo por texto de descripción o código
de la distribuidora, código de barras o código del proveedor, siendo indiferente para el sistema
cuál utilice.

De encontrar una única coincidencia, debe cargar los datos de este articulo, de tener más de
una coincidencia, debe mostrar una lista de sugerencias para que el administrador seleccione
una.

De no encontrar el artículo buscado, puede agregarlo desde la factura de compra, sin

necesidad de navegar fuera de la factura, ni perder los datos que ya haya ingresado en la
misma.

Una vez seleccionado el producto, agrega la cantidad del mismo.

El costo del producto es calculado en base al costo base del mismo y los descuentos o
recargos que correspondan a la lista de precios del proveedor seleccionado.

En cualquier momento el administrador puede ingresar los porcentajes de descuento o recargo

logísticos, ya sea para la factura general o para cada uno de los artículos.

De la misma manera puede seleccionar la moneda en que es emitida la factura, y los precios
deben actualizarse acorde.

Una vez aceptada el ingreso de la mercadería mediante la factura de compra, se suman las
cantidades correspondientes al stock.

También se actualizan los valores estadísticos de compras del proveedor.

43
FACTURACIÓN A ALMACEN DEL GRUPO

Cuando el 100% del contenido de una factura está destinado a un almacén del grupo, se puede
seguir este proceso, para evitar duplicar el trabajo.

Un administrador recibe una hoja de factura de compra a un proveedor, e ingresa la misma al

sistema, según la historia anterior.

En las opciones de la factura selecciona “Enviar a Almacén del Grupo” y selecciona de la lista
de almacenes el que corresponda.

Al finalizar la factura, los contenidos se cargan a la cuenta del proveedor, y del almacén
seleccionado, pero no surgen modificaciones de stock.

44
CONTROL DE PAGOS A PROVEEDORES

Desde la vista de proveedores, se puede ver el listado de facturas ingresadas al mismo.

Se puede seleccionar cada factura, e ingresar los detalles del pago de la misma.

Sobre las facturas que no fueron pagas todavía, se suman los totales y se muestra como la
“deuda” que se mantiene con el proveedor.

45
RECEPCIÓN DE PEDIDOS ON-LINE

Nota: El proceso de esta historia se detalla de manera puntual debido a la naturaleza del
mismo.

1. El cliente ingresa al sitio institucional

2. Se autentica con sus credenciales

3. Navega por la lista de Categorías / Productos

o En pantalla aparece el precio según su lista de precios asignada

o En pantalla aparece el stock actual aproximado (permite compras de stock

cero)

4. Agrega al Carrito de Compras las cantidades solicitadas.

5. Ingresa información de retiro (hora/día)

6. Envía la orden de compra

o El sistema encola la orden para el agente de ventas

o El sistema envía una copia por email al cliente

o El sistema notifica de stocks mínimos o productos en cero que han sido

pedidos.

46
FACTURACIÓN A CLIENTE SOBRE PEDIDO ON-LINE

1. El encargado recibe un Pedido On-Line

2. Selecciona la opción de procesar

Nota : Una factura de venta se crea con la información del pedido

3. Verifica los datos de cliente, stock y precios

4. Emite la factura

o Da de baja al stock, actualizando la información de los reportes

o Actualiza la información de ventas al cliente

47
FACTURACIÓN A CLIENTE SOBRE PEDIDO EN VIVO

1. El usuario crea una nueva factura

2. Selecciona el cliente a facturar

3. Ingresa los artículos solicitados por el cliente

4. Verifica los datos de cliente, stock y precios

5. Emite la factura

o Da de baja al stock, actualizando la información de los reportes

o Actualiza la información de ventas al cliente

48
REGISTRO DE USUARIO ONLINE

Desde el portal institucional de la empresa, un cliente puede ingresar al mismo, y solicitar la

creación de una cuenta para realizar compras.

El formulario le solicita todos los datos requeridos para el alta de un cliente.

Una vez finalizado, el sistema le envía un correo electrónico de verificación.

Al cliente se le asigna la lista de precios por defecto.

Una vez verificada la cuenta, el usuario puede ingresar al sistema a realizar pedidos.

49
REPORTE DE LISTAS DE PRECIOS

Desde el backend del sistema un encargado puede listar todas las listas de precios por
nombre.

De la lista, selecciona una en particular.

El sistema genera los precios según los porcentajes y excepciones registrados en la misma, la
moneda y el tipo de cambio actual.

Despliega la lista completa en pantalla, y opcionalmente permite enviar la salida a la impresora.

50
CONSULTA DE PEDIDO ONLINE

Desde el portal institucional de la empresa, un cliente puede ingresar al mismo, y consultar el

estado de los pedidos realizados.

El sistema mostrará información respecto al estado actual, y de ser relevante, el vendedor

encargado de procesar el mismo.

51
MANTENIMIENTO DE PRODUCTOS
Crear Nuevo Producto

Un administrador registrado puede ingresar a mantenimiento de productos y crear un nuevo

producto.

En el mismo se deben poder ingresar la cantidad de códigos que el usuario considere

necesarios, siendo eventualmente posible una búsqueda por los mismos

El producto debe tener información del tipo de Moneda en que se comercializa, el tipo de
impuesto que lleva y la categoría a la cuál pertenece.

Durante el ingreso se puede agregar información del Precio base y la cantidad de Stock
disponible en la distribuidora.

Modificar un Producto

Un usuario registrado puede ingresar a mantenimiento de productos y modificar un producto

existente.

Los cambios en este producto no deben afectar a compras pasadas, facturas, pedidos, etc.

Borrar un Producto

Un usuario registrado puede ingresar a mantenimiento de productos y borrar un producto

existente.

Este producto no puede ser eliminado de existir compras, facturas o pedidos con ese producto.

Desactivar un Producto

Un usuario registrado puede ingresar a mantenimiento de productos y desactivar un producto

existente.

Este producto no podrá ser usado en futuras compras, facturas o pedidos.

La información histórica del producto debe mantenerse

52
MANTENIMIENTO DE CLIENTES
Crear Nuevo Cliente

Un administrador registrado puede ingresar a mantenimiento de clientes y crear un nuevo

cliente.

El cliente debe tener información de contacto, si paga IVA, etc.

Modificar un Cliente

Un usuario registrado puede ingresar a mantenimiento de clientes y modificar un cliente

existente.

Los cambios en este cliente deben afectar a compras pasadas, facturas, pedidos solamente en
la información de nombre y contacto. Cambios en Monedas, Listas de Precios, Descuentos,
etc. no deben ser retroactivos.

Borrar un Cliente

Un usuario registrado puede ingresar a mantenimiento de clientes y borrar un cliente existente.

Este cliente no puede ser eliminado de existir compras, facturas o pedidos con ese cliente.

Desactivar un Cliente

Un usuario registrado puede ingresar a mantenimiento de clientes y desactivar un cliente

existente.

Este cliente no podrá ser usado en futuras compras, facturas o pedidos, ni entrar al sistema a
realizar pedidos.

La información histórica del cliente debe mantenerse

53
MANTENIMIENTO DE PROVEEDORES
Crear Nuevo Proveedor

Un administrador registrado puede ingresar a mantenimiento de Proveedores y crear un nuevo

Proveedor.

El Proveedor debe tener información de contacto, si paga IVA, etc.

Modificar un Proveedor

Un usuario registrado puede ingresar a mantenimiento de Proveedores y modificar un

Proveedor existente.

Los cambios en este Proveedor deben afectar a compras pasadas, facturas, pedidos
solamente en la información de nombre y contacto. Cambios en Monedas, Listas de Precios,
Descuentos, etc. no deben ser retroactivos.

Borrar un Proveedor

Un usuario registrado puede ingresar a mantenimiento de Proveedores y borrar un Proveedor

existente.

Este Proveedor no puede ser eliminado de existir compras, facturas o pedidos con ese
Proveedor.

Desactivar un Proveedor

Un usuario registrado puede ingresar a mantenimiento de Proveedores y desactivar un

Proveedor existente.

Este Proveedor no podrá ser usado en futuras compras, facturas o pedidos

La información histórica del Proveedor debe mantenerse

54
MANTENIMIENTO DE MONEDAS
Crear Nueva Moneda

Un administrador registrado puede ingresar a mantenimiento de Monedas y crear una nueva

Moneda.

Modificar una Moneda

Un usuario registrado puede ingresar a mantenimiento de Monedas y modificar una Moneda

existente.

Los cambios en esta Moneda deben afectar a compras, facturas y pedidos solamente a futuro
solamente

Borrar una Moneda

Un usuario registrado puede ingresar a mantenimiento de Monedas y borrar una Moneda

existente.

Esta Moneda no puede ser eliminada de existir compras, facturas o pedidos con esa Moneda.

Desactivar un Moneda

Un usuario registrado puede ingresar a mantenimiento de Monedas y desactivar una Moneda

existente.

Esta Moneda no podrá ser usada en futuras compras, facturas o pedidos

La información histórica de la Moneda debe mantenerse

55
MANTENIMIENTO DE IVAS
Crear Nuevo IVA

Un administrador registrado puede ingresar a mantenimiento de IVAs y crear un nuevo IVA.

Modificar un IVA

Un usuario registrado puede ingresar a mantenimiento de IVAs y modificar un IVA existente.

Los cambios en este IVA deben afectar a compras, facturas y pedidos solamente a futuro.

Borrar un IVA

Un usuario registrado puede ingresar a mantenimiento de IVAs y borrar un IVA existente.

Este IVA no puede ser eliminado de existir compras, facturas o pedidos con ese IVA.

Desactivar un IVA

Un usuario registrado puede ingresar a mantenimiento de IVAs y desactivar un IVA existente.

Este IVA no podrá ser usado en futuras compras, facturas o pedidos.

La información histórica del IVA debe mantenerse

56
MANTENIMIENTO DE CATEGORÍAS
Crear Nuevo Categoría

Un administrador registrado puede ingresar a mantenimiento de Categorías y crear una nueva

Categoría.

La Categoría puede o no, ser Sub Categoría de una categoría existente

Modificar un Categoría

Un usuario registrado puede ingresar a mantenimiento de Categorías y modificar una Categoría

existente.

Los cambios en esta Categoría deben afectar a compras, facturas y pedidos solamente a
futuro.

Borrar un Categoría

Un usuario registrado puede ingresar a mantenimiento de Categorías y borrar una Categoría

existente.

Este Categoría no puede ser eliminada de existir artículos con esa Categoría, o de tener Sub
Categorías asociadas a ellas

Desactivar un Categoría

Un usuario registrado puede ingresar a mantenimiento de Categorías y desactivar una

Categoría existente.

Esta Categoría no podrá ser usada en futuros artículos.

La información histórica del Categoría debe mantenerse

57
MANTENIMIENTO DE CIUDADES
Crear Nuevo Ciudad

Un administrador registrado puede ingresar a mantenimiento de Ciudades y crear una nueva

Ciudad.

La ciudad debe pertenecer a un País

Modificar un Ciudad

Un usuario registrado puede ingresar a mantenimiento de Ciudades y modificar una Ciudad

existente.

Borrar un Ciudad

Un usuario registrado puede ingresar a mantenimiento de Ciudades y borrar una Ciudad

existente.

Este Ciudad no puede ser eliminada de existir Clientes o Proveedores pertenecientes a esa
Ciudad.

Desactivar un Ciudad

Un usuario registrado puede ingresar a mantenimiento de Ciudades y desactivar una Ciudad

existente.

Esta Ciudad no podrá ser usada en futuros registros de Clientes o Proveedores

La información histórica del Ciudad debe mantenerse

58
MANTENIMIENTO DE PAÍSES
Crear Nuevo País

Un administrador registrado puede ingresar a mantenimiento de países y crear un nuevo país.

El país debe tener una moneda por defecto asociada

Modificar un País

Un usuario registrado puede ingresar a mantenimiento de países y modificar un país existente.

Borrar un País

Un usuario registrado puede ingresar a mantenimiento de países y borrar un país existente.

Este país no puede ser eliminado de existir Clientes o Proveedores pertenecientes a ese país.

Desactivar un País

Un usuario registrado puede ingresar a mantenimiento de países y desactivar un país

existente.

Este país no podrá ser usado en futuras Clientes o Proveedores.

La información histórica del país debe mantenerse

59
 6. INGENIERÍA DE REQUERIMIENTOS

PATRONES DE DISEÑO
El Sistema SaaS de Administración y Venta On-Line se apoya fuertemente en varios patrones
de diseño para simplificar y formalizar su código y ayudar el entendimiento y mantenimiento del
mismo.

Explicaremos algunos de los patrones utilizados debajo, la lista no resulta extensiva, ni intenta
ser en exceso explicativo del patrón, en cambio, intentará explicar el funcionamiento de
algunos puntos clave del sistema.

PATRONES DE CREACIÓN
Prototype

El patrón de diseño Prototype o Prototipo es utilizado ampliamente en el acceso a datos y

principalmente por el modelado de Doctrine ORM que basa en el diseño de prototipos comunes
para las funciones básicas de seleccionar, insertar, actualizar y eliminar elementos de una tabla
de la base de datos, independientemente de la estructura del mismo.

El beneficio inmediato del uso de este patrón es la simplificación de tareas redundantes que
agregan poco valor al diseño del sistema, mediante el uso de un método común a ellas.

Singleton

El patrón de diseño Singleton aparece en la llamada de acceso al sistema, en dónde existe un

único punto de acceso a cada aplicación, y desde ahí se invoca para cada usuario una única
aplicación de Symfony con su framework subyacente.

El beneficio inmediato del uso de este patrón es la simplificación al momento de asegurar el

sistema, ya que todas las llamadas al mismo son realizables solamente a través de esta
instancia única, además en el momento de depurar el código, el punto de acceso único
simplifica el entendimiento del mismo.

60
PATRONES E STRUCTURALES

Decorator

El patrón Decorator o Decorador es fuertemente utilizado en las vistas de Symfony y en la

seguridad del sitio, en dónde las acciones y métodos se benefician de los “decorados” que le
definen características comunes, como ser restricción por tipo de usuario, o definición de hojas
de estilos comunes, o declaración de métodos como Web Services.

PATRONES DE ARQUITECTURA

Model View Controller

Ver capitulo siguiente

61
MODELO – VISTA – CONTROLADOR

El framework Symfony está basado fuertemente en el patrón de diseño MVC de la siglas en

inglés Model View Controller. El mismo, permite una separación de intereses para independizar
la presentación de la información, de la lógica sobre la que opera el negocio, del acceso a
datos.

Debajo, explicaremos brevemente el fundamento del patrón, y cómo aplica particularmente al

proyecto.

El Modelo

La clases del Modelo de Symfony se encuentran en el directorio /lib/model. Usando el método

de meta-programación de scaffolding, se pueden crear clases del dominio basadas en el ORM
Doctrine. Usando la descripción de la base de datos, esta genera las clases para los objetos y
de ella hereda bases para los formularios, y filtros.

Doctrine también genera las sentencias SQL para las operaciones más comunes con la base
de datos, y nombra métodos que soportan las mismas.

La configuración de la base de datos se puede hacer desde la línea de comandos de la consola

de Symfony o editando un archivo de configuración. Además de su configuración, también es
posible hacer la inyección inicial de datos, gracias a los archivos de datos YML.

La Vista

De forma predeterminada, la capa de la Vista de la arquitectura MVC utiliza archivos PHP

planos como plantillas o templates. Éstos se encuentran dentro del paquete
/apps/{aplicación}/modules/{módulo}/templates

Los archivos en él, deben respetar la siguiente nomenclatura :

• {acción}Success.php
Es la plantilla invocada al ejecutar desde el controlador el método execute{acción}, si
no se detecta ningún error o excepción.

• {acción}Error.php
Es la plantilla invocada al dispararse una excepción en el método execute{acción}

• _{parciales}
Son plantillas simples, independientes del decorado, para ser reutilizadas dentro de
otras plantillas mediante la llamada include_partial o include_component. Siendo la
diferencia entre estas la llamada a un método en el component del mismo nombre para
las segundas.

Las plantillas pueden utilizar “helpers” para tareas recurrentes como crear una URL o un campo
de datos. Una plantilla puede ser decorada por un Layout propio, o heredar del genérico de la
aplicación, según la definición del archivo de configuración view.yml.

El pre-proceso de las plantillas y la generación de HTML estático utiliza el caché de Symfony y

puede ser configurado a nivel general, de acción, partials o componentes. O deshabilitarlo
completamente.

62
El Controlador

Finalmente el Controlador es dónde reside la lógica del sistema y es quién solicita datos del
Modelo y los prepara para que la Vista los despliegue. Los mismos se encuentran en el
paquete /apps/{aplicación}/modules/{módulo}/actions y generalmente se encuentran en
actions.class.php o components.class.php.

Desde el primero, se pueden llamar métodos del nombre execute{acción}, que de completar su
curso normal, enviarán la información procesada a la plantilla de nombre {acción} Success.php.
Éstos, mediante el framework de ruteo de Symfony, responden a las llamadas de la URL
http://proyecto.symfony.com/{aplicación}/{módulo}/{acción}. Siendo aplicación el nombre de la
aplicación elegida (frontend o backend en nuestro caso).

El procesado de las plantillas puede alterarse de su curso normal, mediante llamadas a

métodos de redirect que permiten, aún de completar exitosamente el método, redirigir la vista
hacia la plantilla deseada.

Ejemplo: Los métodos de envío de correo electrónico, procesan la plantilla como cuerpo del
mensaje, pero luego de enviado, redirigen la presentación a una nueva planilla que confirme el
éxito del envío, en lugar de mostrar el correo enviado en pantalla.

Nota: Symfony define automáticamente el frontend como acción por defecto, por lo que las
llamadas http://proyecto.symfony.com/frontend/{módulo}/{acción} y
http://proyecto.symfony.com/{módulo}/{acción} son análogas.

Para simplificar la implementación de servicios web, Symfony soporta Web Services XML de
sus métodos y la serialización de sus modelos en forma nativa.

63
DIAGRAMAS DE DEPLOY

64
DIAGRAMA DE CLASES
La naturaleza del uso del framework Symfony hace que el diagrama de clases básico se
extienda, en lo que a primera vista resultaría complejo en exceso.

El modelo debajo, muestra principalmente las clases del Modelo para entender las relaciones
con sus semejantes, pero el diagrama de paquetes probablemente explique mejor el
funcionamiento del sistema.

65
DIAGRAMAS DE PAQUETES
El diagrama de paquetes, muestra la fuerte relación del paradigma MVC con el sistema.

Por un lado tenemos las clases del modelo definidas en /lib/model, /lib/filter y /lib/form, siendo la
primera las clases del modelo de negocios, la segunda los filtros definidos para la obtención de
datos, y la tercera las clases que definen los formularios de los objetos del modelo y sus
propiedades particulares (el uso de un calendario para los campos Date por ejemplo).

Por otro lado tenemos las acciones que definen el flujo del negocio y las funcionalidades
disponibles en la aplicación, y fuertemente relacionadas las plantillas de diseño que se
encargan de presentar la información al usuario y la interacción con el mismo.

Por último, tenemos la configuración propia del framework, definida por los archivos YML,
capaz de determinar de manera simple los permisos de usuario, el uso de hojas de estilo de
presentación, el auto modelado de los formularios, etc.

66
67
DIAGRAMAS DE SECUENCIA
AGREGAR NUEVO CLIENTE

68
AGREGAR NUEVO ARTÍCULO

69
AGREGAR PRECIO DE ARTÍCULO

70
CREAR N UEVA FACTURA DE COMPRA

71
CREAR N UEVA FACTURA DE VENTA

72
I NGRESAR UN PEDIDO ON-LINE

73
I NGRESAR AL SISTEMA

74
 7. SISTEMA DE BASES DE DATOS

MOTOR DE BASES DE DATOS

El sistema de gestión de Grupo del Este requiere de acceso a datos en tiempo real de alta
disponibilidad. Siendo el sistema, un sistema multi-usuario, dónde clientes y trabajadores del
grupo accederán a los mismos datos, necesitamos garantizar no sólo la disponibilidad
inmediata de los mismos, sino la sincronía y transaccionalidad de los datos.

Para ello, elegimos el sistema de base de datos relacional MySQL con InnoDB como el motor
de transacciones.

Entre otras opciones, la elección fue tomada debido a la capacidad de InnoDB de “retrasar” la
escritura de datos en disco, manteniendo un caché en memoria para acelerar pedidos
frecuentes junto a su gran capacidad de recuperar datos perdidos debido a una base de datos
dañada, lo que aumenta las garantías de recuperación de desastre.

75
DESVENTAJAS
Las desventajas del uso de InnoDB son principalmente la falta de compresión de datos, lo que
genera un mayor consumo de disco, razón secundaria debido al cada vez menor coste del
almacenamiento en medios magnéticos.

En un servidor de bases de datos estándar con discos simples (sin sistemas RAID), el motor es
capaz de realizar hasta 200 transacciones en disco simultáneas por segundo. Esto aumenta
considerablemente al utilizar discos en RAID o discos de estado sólido (SSD), pero debido al
bajo uso del sistema actual, no presenta una restricción limitante.

76
MODELO ENTIDAD RELACIÓN
El diagrama siguiente muestra a cierto grado de abstracción el diseño de la base de datos en lo
que concierne e las relaciones de cada una de las tablas. Para facilitar su comprensión, el
mismo se encuentra dividido en secciones según el área del sistema al que pertenecen.
Siguiendo el modelo debajo, se encuentra el diseño de la base de datos, en dónde se muestran
en mayor detalle cada una de las entidades y sus propiedades básicas.

77
DISEÑO DE LA BASE DE DATOS
El diseño de la base de datos fue divido según el tipo de datos afectados para simplificar su
lectura.

La región Compra almacena las tres tablas principales relacionadas al sistema de proceso de
órdenes de compras a proveedores. En ellas se encuentran las Facturas de Compras
compuesta por factura_compra y sus línea_factura_compra y los contactos de los Proveedores
en proveedor

La región Stock guarda la información de los Artículos, junto a sus colecciones de Códigos. Los
mismos están divididos en un árbol de categorías. El manejo de lista de precios se realiza en
base al precio de cada Articulo, el porcentaje de aumento o descuento definido en cada lista
particular o en las excepciones almacenadas en precio_articulo.

78
Pedidos Online y Factura son tablas análogas. La primera guarda los pedidos realizados por
los clientes o encargados de compras de los almacenes, estos están asociados a un estado
particular. Al ser procesadas, se convierten en Facturas de Venta, ya sean crédito o contado.
Ambas poseen una colección de artículos que generan el cuerpo de la misma

79
Cliente guarda la información de los usuarios del sistema que operan desde el frontend de la
aplicación, mientras que SF Guard es la estructura definida por el sistema de autenticación y
control de usuarios del framework de Symfony.

La información genérica guarda los datos de mantenimiento de la aplicación, como ser las
Monedas, tasas de impuestos, listas de países y ciudades, tipos de unidades y una tabla del
tipo Clave->Valor que guarda información general

80
MAPEO DE OBJETOS RELACIONAL
Sobre la base de datos MySQL para abstraer la comunicación con el sistema PHP, se utilizará
el sistema de mapeo de objetos relacional de Doctrine.

Éste permite acceder a los datos de una manera orientada a objetos, siguiendo el patrón Active
Record. Entre otros beneficios, Doctrine le otorga a la aplicación, soporte de datos jerárquicos
(estructura de árbol), cacheo de transacciones, transparencia en el soporte ACID (Atomicidad,
Consistencia Aislamiento, Durabilidad) de InnoDB, y por sobre todo, agrega una capa de
abstracción del motor particular utilizado, permitiendo ,de ser necesario, la migración a un
nuevo motor de bases de datos con un cambio mínimo en la configuración y en el código del a
aplicación.

Doctrine define implementaciones de Setters y Getters según la estructura de la base de datos,

y a cada objeto le agrega un método save() que permite persistir los cambios, ya sea
insertando un nuevo elemento o actualizando el existente.

De la misma manera, crea objetos que son una colección de los anteriores, con métodos para
obtenerlos según diversos criterios, simplificando la obtención de datos y el manejo de objetos
y colecciones relativos a las tablas en dónde se almacenan.

81
ABSTRACCIÓN Y PERFORMANCE
Una de las preocupaciones del uso de Doctrine, era la sobrecarga que puede ocasionar los
encabezados y la abstracción propia del modelo. Debido al uso de la aplicación por los clientes
del Grupo del Este, era imperativo lograr una excelente performance al momento de obtener
datos, incluso cuando esto significara los miles de artículos que maneja el grupo.

Para ello se hicieron pruebas de rendimiento y ajustes de performance a la configuración base

de Doctrine. Especialmente se utilizó la versión compilada de Doctrine, que reduce a un único
archivo las funcionalidades mas utilizadas del mismo (vs. 12+ archivos durante el desarrollo).
Este paquete es utilizado en los servidores de producción y permite reducir el acceso a disco,
especialmente los tiempos de latencia y el spin medio al acceder a cada archivo
individualmente.

Por último fue habilitado el paquete APC (Caché PHP Alternativo) que es utilizado de forma
nativa por el sistema Doctrine acelerando así las consultas, pre-compilando los archivos PHP
en memoria y manteniendo los más usados en caché.

82
 8. EL FRAMEWORK

SYMFONY FRAMEWORK
Según la página del sitio el Symfony Framework es :

“Symfony es un framework PHP que facilita el desarrollo de las aplicaciones web. Symfony se encarga de
todos los aspectos comunes y aburridos de las aplicaciones web, dejando que el programador se
dedique a aportar valor desarrollando las características únicas de cada proyecto.”

Desarrollado en PHP y distribuido como un paquete PEAR (PHP Extension and Application
Repository), Symfony Framework intenta simplificar las tareas comunes del desarrollo de
aplicaciones web. Brindando una separación de capas MVC, un sistema centralizado de
autenticación y control de acceso por usuarios, un modo de depuración extendido y una
extensa API que simplifica tareas frecuentes, Symfony ofrece un entorno amigable para
desarrolladores enfocados en la productividad.

Por sobre las funcionalidades básicas del framework, Symfony ofrece complementos como ser
la simplificación de envío de correo electrónico, el caché de páginas PHP, la
internacionalización de las aplicaciones, el registro de logs y más funcionalidades.

También proporciona acceso a un sistema de testeo unitario para desarrollar pruebas

automatizadas, y carga de datos mediante el formato YML.

Finalmente, existe una gran documentación respecto a la aplicación y su API y siendo

soportado por una gran comunidad, existen cientos de sitios dedicados a compartir información
y a citar ejemplos o código real, que ayudan al momento de incursionar en características no
documentadas.

83
J QUERY Y AJAX
Según la página del sitio el Symfony Framework es :

“jQuery es una rápida y concisa librería de JavaScript que simplifica el acceso de documentos
HTML, manejo de eventos, animación e interacciones AJAX para desarrollo de aplicaciones
web. jQuery está diseñado para cambiar la manera en que se escriben aplicaciones web”

El desarrollo de la aplicación para el Grupo del Este se ha fortalecido con un extensivo uso de
jQuery Core y jQuery UI, lo que le permite garantizar interacciones AJAX en diferentes
navegadores, y al mismo tiempo mantener la compatibilidad del sistema.

Otra de las responsabilidades delegadas al framework jQuery, es la de interpretar los objetos

JSON (Java Script Object Notation) y hacer uso de ellos para poder desplegar listas dinámicas
inteligentes, controles de acceso a datos fluídos, etc.

La idea de Web 2.0 ha sido introducida en el uso común de la gente, y el desarrollo de una
aplicación estática no resulta factible si se considera al usuario y su interacción con la misma
como un punto importante del desarrollo.

Entra entonces en juego la simpleza del manejo de métodos AJAX, de animaciones y

modelado de presentación que brinda jQuery para garantizarle al usuario una experiencia
interactiva y al mismo tiempo reduciendo la carga de datos (por lo tanto los tiempos de espera).

84
LOOK & FEEL Y TEMPLATES
El diseño del template de la aplicación de Front End es utilizado según la licencia Crative
Commons del template The Island de http://www.freecsstemplates.org

El diseño del template de la aplicación de Back End es utilizado según la autorización explícita
del autor en http://www.bloganje.com/

85
ESTRUCTURA DE DIRECTORIOS
Para facilitar la navegación y el entendimiento del código, se ofrece a continuación una breve
descripción de la estructura de directorios del proyecto. Esta no es exhaustiva o absoluta,
pudiendo existir excepciones a lo mencionado debajo

Las aplicaciones se encuentran definidas dentro del directorio (apps). Ahí podemos encontrar
tanto el (backend) como el (frontend) del sistema. Dentro de cada carpeta encontramos una
carpeta de configuración general (config), una carpeta para los archivos de internacionalización
(i18n), las librerías (lib) y plantillas (templates) genéricos de la aplicación y una carpeta para
cada módulo (modules).

La carpeta modules a su vez contiene una nueva carpeta con el nombre de cada módulo, y
dentro de cada una de ellas cuatro carpetas.

La primera (actions) contiene el código que guía la lógica de la capa de presentación

especialmente mediante las clases actions.class.php y components.class.php que tienen
definidos métodos cuya nomenclatura se relaciona con el ruteo URL de la aplicación.
Directamente relacionados a estos se encuentran los archivos de la cuarta carpeta (tempaltes)
que definen la presentación en sí en código HTML. Para un método executeMetodo
generalmente le corresponde una plantilla de nombre metodoSuccess.

La segunda (config) guarda la configuración propia de cada módulo, como ser definiciones de
control de acceso para la seguridad, vistas y otros meta-datos. La tercer carpeta (lib) guarda
librerías propias de cada módulo.

En (config) encontramos la configuración general del sistema, como ser la configuración de la

base de datos, la definición de servidores de producción, desarrollo y prueba, etc.

86
En (data) se encuentran los archivos de creación para la base de datos e información en
formato YML para al precargado de las mismas. En (doc) se almacena la documentación del
sistema, mientras que (lib) guarda librerías concernientes al sistema en general, como ser las
clases del dominio dentro de (model), la estrucutra de formularios y filtros para las mismas en
(form) y (filter) respectivamente, y las tareas programadas en (task).

(nbproject) es una carpeta de metadatos para la IDE NetBeans.

(plugins) almacena el repositorio de complementos de symfony usados por la aplicación.

(test) es el lugar para desarrollar las pruebas automatizadas, según el tipo (bootstrap) para
pruebas de inicio, (functional) para pruebas funcionales y (unit) para pruebas unitarias.

Por último el directorio (web) guarda los SPOE (Single Point of Entry) de ambas aplicaciones, y
es el único directorio “visible” para el servidor web de aplicaciones. Dentro de él se encuentran
los archivos de hojas de estilos (css), las imágenes de la aplicación (images), los archivos de
JavaScript (js) y las cargas realizadas mediante la aplicación (uploads)

87
 9. EL PROYECTO

ALCANCES Y LIMITACIONES
El tamaño del proyecto solicitado por el Grupo del Este excede ampliamente en la
capacidad del equipo de desarrolladores para los seis meses de proyecto planteados.

Es por eso que una vez definido el alcance general del proyecto, ser limitará el mismo
en tres etapas. Sobre las tareas definidas que no se completen en el tiempo fijado de
antemano, se dejaran en el backlog del producto, lo que permitirá continuar con el
desarrollo del mismo, una vez concluido el tiempo fijado en esta primera instancia.

El Alcance del Proyecto comprende las siguientes funciones, separadas en "Debe

Tener", "Sería Bueno Tener", "Extras".

Se intentará desarrollar el 100% de las funcionalidades del “Debe Tener”, mientras que
se apunta a lograr un 50% de las tareas en “Sería Bueno Tener” y no se establecen
criterios para los “Extras”.

De cualquier manera, se entiende que algunas de estas funcionalidades pueden ser

simples o complejas, independiente de la categoría en que se encuentren. Lo que
pueden llevar a retrasar el desarrollo por una tarea excesivamente compleja en “Debe
Tener” y bajo circunstancias especiales, se puede implementar una tarea rápida de los
“Extras” sin que una cause perjuicio a la otra.

De la misma manera, a veces ciertas tareas “Extras” resultan necesarias para el

diseño de la aplicación o para implementar una funcionalidad X que puede encontrarse
en el “Debe Tener”.

88
D EBE T ENER

Ingreso al sistema con credenciales seguras

Tanto clientes como administradores deben poder ingresar al sistema mediante el uso
de credenciales seguras. Es imperativo lograr una sensación de solidez para los
clientes del Grupo del Este.

Mantenimiento Básico de Listas de Precios

El alta, baja y modificaciones de Listas de Precios, así como el manejo de precios

individuales por artículos es una de las grandes carencias del sistema actual, y uno de
los principales motivos por los que se necesita implementar un nuevo sistema.

Selección de Lista de Precios por Defecto para el cliente

La simplificación de tareas triviales, como la definición de una lista de precios por

defecto, es otro de los puntos a considerar que el sistema actual no logra cubrir. El que
exista una lista de precios por defecto para cada cliente creado es uno de ellos, y debe
estar contemplado desde el inicio.

Ingreso de nuevos pedidos de compra

Actualmente no existe la funcionalidad de pedidos de compra (o compras OnLine) . El

sistema desea simplificar la tarea de los almacenes y clientes en general al momento
de realizar un pedido o una compra, brindando la posibilidad de hacerlo en un régimen
24x7 e independiente de las instalaciones de la distribuidora

Emisión de Factura en base a un pedido On-Line ingresado

Una vez ingresado un pedido On-Line, debe ser posible de manera rápida y simple,
crear una factura en base a ese pedido e imprimir la misma.

Emisión de Factura con personalización por Cliente con Listas de Precios,

Descuentos, etc.

Las facturas emitidas deben, de manera intuitiva, permitir personalizar los datos del
cliente y en base a éste, ajustar la lista de precios y descuentos del mismo.

Baja automática al emitir una factura de venta

Al emitir una factura de venta de mercadería, se debe dar de baja el stock

correspondiente, permitiendo llevar un control centralizado del mismo.

Porcentajes a aplicar en cargos logísticos, descuentos, bonos, etc.

Desde una factura de compra o de venta, se deben poder aplicar diferentes recargos y
bonificaciones de manera porcentual, para la factura en general y para cada artículo
en particular.

89
Administración simplificada de Productos desde cualquier ventana.

Los productos (o artículos) deben poder ingresarse, no solo desde el ABM propio del
sistema, sino de manera rápida desde la emisión de facturas de venta o desde el
ingreso de facturas de compra

Administración simplificada de Clientes desde cualquier ventana.

Idem anterior para Clientes

Administración simplificada de Proveedores desde cualquier ventana.

Idem anterior para Proveedores

Diseño básico de la distribuidora

La distribuidora necesita un “Look & Feel” con el que pueda identificarse. De la misma
manera necesita elaborar un institucional que la distinga de su competencia. Es
responsabilidad del equipo trabajar con el departamento de marketing para lograr el
cometido, respetando la aplicación y homogeneizando el portal de la empresa con el
sistema de compras On-Line

Acceso a compras On-Line desde portal

Derivado del punto anterior, debería ser posible acceder al sistema de compras On-
Line desde el portal, resultando transparente para el usuario final la transición.

90
S ERÍA B UENO TENER

Registro de Clientes en el portal de la empresa

Los clientes del Grupo del Este deberían poder registrarse como tales desde el portal
de la empresa, independizando nuevamente al personal de ventas de una tarea
automatizable.

Monitoreo de estado del pedido.

Un cliente del Grupo debería poder revisar el estado de sus pedidos y estar informado
del proceso del mismo

Emisión de Remito, con mercadería entregada pendiente de pago y manejo de

cuenta corriente de Clientes

El sistema debería poder manejar Cuentas Corrientes de clientes que no realizan

pagos contado, y administrar los remitos emitidos para cada cliente.

Valores por defecto para unidades, máximos y mínimos

Se deberían poder definir máximos y mínimos para los stocks, precios, descuentos,
etc.

Integración Clientes - Listas de Precios, automatización de descuentos, ofertas,

porcentajes X, etc.

Se deberían poder definir descuentos casuales u ofertas, que apliquen en base a

ciertas condiciones/restricciones y que éstos apliquen automáticamente sobre la
factura en base al Cliente o Lista de Precios seleccionada.

Bloqueo de acceso On-Line al cliente

Frente a un cliente no pagador o que abusa del sitio, se debe poder bloquear su
cuenta (sin necesidad de eliminarla).

Reportes Facturación

Se deben poder emitir reportes de facturación en base a condiciones establecidas, con

agrupación de datos pre definidos.

Reportes Stock

Ídem anterior.

Reportes Lista de Precios

Ídem anterior.

Reportes Cambios históricos

91
Ídem anterior.

Reportes Clientes por Lista

Ídem anterior.

Reportes Proveedor por Lista

Ídem anterior.

Reportes Productos Más vendidos

Se debe poder obtener un reporte rápido con la lista de los productos más vendidos
según un período de tiempo determinado

Reportes Productos Menos vendidos

Ídem anterior.

Reportes Productos Históricos de ventas

Se debe poder emitir un listado del histórico de ventas de un producto dado, en un

rango de tiempo determinado.

Reportes Productos Compras por Proveedor

Se debe poder emitir un listado de las compras realizadas a un proveedor dado en un

tiempo determinado

Reportes Productos Ventas por Cliente

Ídem anterior.

92
EXTRAS

Monitoreo de artículos en "Back Order"

Se debe poder monitorear los artículos que fueron solicitados pero al no disponer de
stock, no fueron entregados.

Reporte de compras realizadas

Se debe poder emitir un reporte de las compras realizadas en un rango de fechas

dado.

Emisión parcial de Factura en base a un pedido On-Line, seleccionando

productos para dejar en "Back Order"

Se debe poder emitir una factura parcial en base a un pedido On-Line, dejando
productos de los que no se dispone stock en “Back Order”.

Notas de crédito, con devolución de mercadería y la Nota de Crédito

correspondiente que le adjudique un monto a favor del Cliente.

Se debe poder ingresar una nota de crédito, permitiendo así a un cliente devolver
mercadería, y adjudicarle el monto a la cuenta corriente del mismo para futuras
compras.

Baja tentativa al recibir un pedido On-Line

El stock debe mostrar un segundo nivel de stock con el estimado de ventas, una vez
que sean entregados los productos que fueron solicitados por compras On-Line que no
han sido procesadas todavía.

Control de Stock con Alertas de Stocks Mínimos y Máximos.

Se deberían poder definir máximos y mínimos para los stocks con alertas cuando
éstos sean superados para notificar a los administradores del sistema de posibles
irregularidades.

Reportes diarios de ISC (Identificadores de Situación Crítica)

Se deberían poder definir situaciones críticas (ventas debajo de X, compras por sobre
Y, Cliente J con saldo negativo I, etc) que generen notificaciones a los administradores
del sistema de posibles irregularidades.

Emisión de Listas completas

Se debe generar una lista de precios completas según la lista seleccionada.

Reseteo de Clave

Un cliente debe poder entrar a cambiar y/o restablecer su contraseña

93
Mantenimiento de Monedas

Se deben poder dar de alta, baja y modificaciones a las monedas con las que opera el
sistema.

Mantenimiento de IVAs

Ídem anterior.

Mantenimiento de Ciudades

Ídem anterior.

Sistema CMS para actualización de Noticias/Promociones en portada

Se deben poder actualizar las noticias, promociones del frontend desde el backend

Espacio para venta de publicidad On-Line

Se debe poder asignar un banner aleatorio para la venta de publicidad en la página de

frontend.

94
PLANIFICACIÓN DE TAREAS
En el siguiente punto intentaremos explicar el plan seguido para el desarrollo del producto. El
mismo fue dividido en Sprints para respetar la metodología de Scrum utilizada durante el
proyecto. Cada uno marcaba un plan de proyecto inicial, y según el trabajo final, se replanteaba
a futuro los próximos Sprints pendientes.

S PRINT 1
Fecha de Inicio : 1ro de Abril, 2010

Fecha de Fin : 15 de Abril, 2010

Wiki : http://trac2.xp-dev.com/gde/wiki/SprintUno

Detalle : El primer Sprint se centró principalmente en el diseño y análisis del

Anteproyecto. En el mismo se investigó al cliente, se visitó las
instalaciones de los mismos y se trabajó con ellos para entender el
funcionamiento de la misma.

De esa experiencia logramos extraer información básica de la empresa

y descubrimos los procesos que deseaban cambiar y porqué. Seguido
de eso, pasamos a narrar en breves historias de usuarios las
funcionalidades que deseaban mejorar o las nuevas que deseaban
implementar.

Por último ordenamos todo este trabajo y lo agrupamos en unidades

lógicas que determinaron los módulos del sistema a desarrollar, junto a
las principales características y necesidades de los mismos.

95
S PRINT 2
Fecha de Inicio : 16 de Abril, 2010

Fecha de Fin : 29 de Abril, 2010

Wiki : http://trac2.xp-dev.com/gde/wiki/SprintDos

Entregable : Entrega AnteProyecto.doc

Detalle : El segundo Sprint se intentó formalizar el documento del Ante

Proyecto. Se definió el concepto de la solución a desarrollar y se
trabajó para determinar la arquitectura y la base sobre la cuál se
crearía la aplicación.

En el documento se detalla la introducción al problema, se destaca la

presentación del cliente y se procede a explicar el análisis estratégico
realizado sobre el cliente y su situación actual.

Luego se procede a explicar las tecnologías elegidas para el desarrollo

del sistema y se explica la metodología de trabajo, haciendo hincapié
en cómo se administraran los cambios y como se intentará garantizar la
calidad del producto, estableciendo también la arquitectura del sistema.

Una vez definida la arquitectura, las tecnologías y las metodologías, se

hace un análisis sobre la gestión de riesgos y se intentan aclarar los
puntos críticos que involucran al proyecto.

Finalmente pasan a detallarse las historias de usuarios, junto con el

plan de proyecto a seguir y la delimitación del alcance teórico del
producto, cerrando así el anteproyecto con el plan de trabajo, dividió en
los seis Sprints restantes que serán dedicados casi en exclusividad al
desarrollo de la solución.

96
S PRINT 3
Fecha de Inicio : 30 de Abril, 2010

Fecha de Fin : 13 de Mayo, 2010

Wiki : http://trac2.xp-dev.com/gde/wiki/SprintTres

Revisiones : commit [9] al commit [38] (link)

Detalle : El primer Sprint de desarrollo fue el Sprint 3. Llegado a este Sprint se

había creado la arquitectura sobre la que se administraría el proyecto,
con un servidor de Visual SVN y un sistema de administración de
proyectos, Trac, con el complemento Agilo para metodologías Scrum.

Lamentablemente llegado al final del Sprint, el servidor en donde corría

este sistema comenzó a fallar, lo que obligó al equipo de desarrollo a
moverlo a un servidor tercerizado (http://www.xp-dev.com).

Esto no solo ocasiono retrasos inesperados en el desarrollo del Sprint,

sino que imposibilitó la migración de datos recabados durante el
transcurso del mismo. En la gráfica de Burndown, se puede notar la
tendencia inversa de progreso, debido principalmente a una mala
organización del primer Sprint, junto a los retrasos ocasionados por la
falla de los sistemas y la mala administración por parte del equipo.

97
Debajo se pueden ver las tareas completadas en un 100%, las tareas parcialmente
completadas, y las tareas planeadas que no llegaron a comenzarse.

Tareas Completas

# Tkt Descripción Dueño Estimado Horas

#43 Diseño de Base de Datos (MER) migueldiab 8

Ingreso al sistema con credenciales
#36 seguras marcostusso 8
Mantenimiento Básico de Listas de
#37 Precios marcostusso 8
Widget AJAX para seleccionar
-- fecha migueldiab 4
#37 Listado de Proveedores migueldiab 8
-- JS para suma de facturas migueldiab 8
Diseño básico frontend/backend migueldiab 8
TOTAL 52

Tareas Parciales

# Tkt Descripción Dueño Estimado Horas

Emisión de Factura con

personalización por Cliente con
#1 Listas de Precios, Descuentos, etc. migueldiab 20
Selección de Lista de Precios por
#38 Defecto para el cliente marcostusso 8
Ingreso de nuevas facturas de
#39 compra migueldiab 20
-- Búsqueda de articulos AJAX migueldiab 8
TOTAL 56

98
Tareas Pendientes

# Tkt Descripción Dueño Estimado Horas

Emisión de Factura en base a un

#2 pedido On-Line ingresado 20
#10 Crear Pedido --
#14 Crear Pedido de Back Order --
Baja automática al emitir una
#40 factura de venta 8
Porcentajes a aplicar en cargos
#41 logísticos, descuentos, bonos, etc. 13
Diseño de Backend simple y
#83 navegable 20
TOTAL 61

99
S PRINT 4
Fecha de Inicio : 14 de Mayo, 2010

Fecha de Fin : 27 de Mayo, 2010

Wiki : http://trac2.xp-dev.com/gde/wiki/SprintCuatro

Revisiones : commit [39] al commit [55] (link)

Detalle : El segundo Sprint de desarrollo comenzó con la puesta en marcha del

nuevo sitio para la administración del proyecto (http://www.xp-
dev.com).

Una vez creado el nuevo sitio, se procedió a cargar las historias

pertinentes para el Sprint 4. Debido a la carga pendiente del Sprint
anterior, se centró el desarrollo en completar los módulos pendientes
de la misma, e intentar ponerse al día.

La gráfica de Burndown muestra la asignación tardía de tareas el día

dos, junto con un trabajo sostenido hasta el día 10. Luego la caída se
debe a la re planificación de tareas pendientes para el siguiente Sprint.

100
Debajo se pueden ver las tareas completadas en un 100%, según el formato del nuevo sistema
de administración del proyecto.

Plan de Tareas

# Tkt Descripción Módulo Dueño Estimado Total

Carga Cotización Moneda automática

(usar webservice de cotización o tasa
#1 elegida por el cliente) Facturación migueldiab 4 4
Carga Fecha de Hoy Automatica en
#2 facturas Facturación migueldiab 1 1
Búsqueda de Articulos AJAX
(seleccionar con enter o tab o click,
#3 testing, etc) Facturación migueldiab 4 4
JavaScript para creación de n Líneas
de facturas (que se auto-agreguen al
tabular al final o boton para agregar +
#4 líneas) Facturación migueldiab 8 8
JavaScript para suma de Totales de
Factura (sumar las n Líneas y calcular
#5 sus subtotales correspondientes) Facturación migueldiab 4 5
Guardar Factura nueva y líneas
#6 asociadas Facturación migueldiab 8 8
Desde el FE el usuario lista o busca los
#8 productos a comprar Venta OnLine MarcosTusso 8 19
Total 37 49

101
S PRINT 5
Fecha de Inicio : 28 de Mayo, 2010

Fecha de Fin : 10 de Junio, 2010

Wiki : http://trac2.xp-dev.com/gde/wiki/SprintCinco

Revisiones : commit [56] al commit [85] (link)

Detalle : El tercer Sprint de desarrollo se centró en la administración de Stocks,

la alta y baja automática de los mismos desde las facturas, etc.
También se puso énfasis en la automatización de los pedidos On-Line
y de cómo se resuelve el flujo desde que el cliente crea un nuevo
pedido, mientras es procesado y convertido en una factura por personal
de la distribuidora, y finalmente cuando es retirado por el cliente.

Para poder llevar a cabo el flujo deseado, surgieron cambios en el

diseño de la base de datos que impactaron sobre las clases del
dominio y sobre la persistencia de los datos.

La gráfica de Burndown muestra nuevamente una asignación tardía de

tareas el día dos, junto con un trabajo sostenido hasta el día 10. Luego
la caída se debe a la re planificación de tareas pendientes para el
siguiente Sprint.

102
Plan de Tareas

# Tkt Descripción Módulo Dueño Estimado Total

#7 Sumar Stocks de factura ingresada Stock migueldiab 4 3

Desde el Backend un agente puede
#13 ver un pedido realizado Venta OnLine migueldiab 8 8
Desde el BackEnd un agente puede
“convertir” un pedido en una factura
#14 de venta Venta OnLine migueldiab 8 8
La factura de venta calcula totales
#15 generales y por línea (JavaScript) Facturación migueldiab 8 8
Baja automática al emitir una factura
#16 de venta Stock migueldiab 8 8
Desde el Backend un agente puede
#29 ver una compra ingresada Proveedores migueldiab 4 4
#30 Cambio Schema y Tablas/Campos Clientes migueldiab 8 8
Total 48 47

103
S PRINT 6
Fecha de Inicio : 11 de Junio, 2010

Fecha de Fin : 24 de Junio, 2010

Wiki : http://trac2.xp-dev.com/gde/wiki/SprintCinco

Revisiones : commit [86] al commit [91] (link)

Detalle : El Sprint 6 se centró en el frontend de la aplicación y la interacción de

los clientes del Grupo del Este con la misma.

Se desarrollo el sistema de compras que permite al cliente hacer

pedidos On-Line, se creó el sistema de registro de usuarios con
credenciales y se implementaron las funcionalidades de Lista de
Precios y valores por defecto al sistema.

La gráfica de Burndown muestra una iteración de solamente 5 días,

debido a retrasos para comenzar esta nueva iteración en fecha.

104
Plan de Tareas

# Tkt Descripción Módulo Dueño Estimado Total

Desde el FE el usuario ve los precios

#9 de articulos según su lista asociada Venta OnLine MarcosTusso 8 4

Desde el FE el usuario agrega un

articulo a un pedido online (carrito de
#10 compras) Venta OnLine MarcosTusso - 5

El carrito despliega los totales

#11 calculados según cantidades y precios Venta OnLine MarcosTusso 4 4

Desde el FrontEnd el usuario

confirma la compra de los articulos
en el carrito (ya no es más
#12 modificable) Venta OnLine MarcosTusso 8 10

Registro de Clientes en el portal de la

#24 empresa Clientes MarcosTusso 12 12

Valores por defecto para unidades,

#26 máximos y mínimos Clientes - 12 -

Integración Clientes - Listas de

Precios, automatización de
descuentos, ofertas, porcentajes X, Lista de
#27 etc Precios - 24 -

Total 68 35

105
S PRINT 7
Fecha de Inicio : 25 de Junio, 2010

Fecha de Fin : 8 de Julio, 2010

Wiki : http://trac2.xp-dev.com/gde/wiki/SprintSiete

Revisiones : commit [92] al commit [107] (link)

Detalle : El Sprint 7 se centró en la usabilidad del sistema. Uno de los puntos

principales era poder desarrollar un sistema amigable y simple de usar
que respete la operativa actual de la distribuidora, sin interferir en el
flujo del negocio diario.

Mediante el uso de tecnologías AJAX y del framework jQuery, se

intenta dar al usuario una sensación de interacción y continuidad en su
trabajo, haciendo de la experiencia del uso del software, lo mas
amigable posible.

Nuevamente se comenzó con una iteración retrasada, lo que dejó

solamente 9 días de trabajo para la misma. Como toda iteración cerca
del final del proyecto, se percibió una fuerte carga de tareas, y se
avanzó mucho en el desarrollo del sistema, a costa de horas hombre.

106
Plan de Tareas

# Tkt Descripción Módulo Dueño Estimado Total

Desde una factura, se abre un DIV de

#17 ingreso de proveedor Proveedores migueldiab 8 8

Desde un DIV de ingreso de

proveedor se actualizan los datos del
#18 mismo mediante AJAX Proveedores migueldiab 8 8

Acceso a compras On-Line desde

#23 portal Venta OnLine MarcosTusso 12

#25 Monitoreo de estado del pedido Venta OnLine MarcosTusso 24

Un Admin asigna a un articulo un Lista de

#31 porcentaje de recargo particular Precios MarcosTusso 8 4

Un Admin selecciona una lista de Lista de

#32 precios como lista por defecto Precios MarcosTusso 4

Al crearse un nuevo cliente se le

asigna la lista elegida por el admin
#33 como lista por defecto Clientes MarcosTusso 4 5

Ver listas de precios y precios

particulares en ingreso de pedido Lista de
#43 online Precios MarcosTusso 4

Agregar Links y eliminar links muertos

#44 desde el portal Frontend Venta OnLine migueldiab 4 4

Al procesar un pedido online, mover

#45 a lista de "pedidos procesados" Venta OnLine migueldiab 4 4

Al intentar procesar un pedido

procesado, si el estado <> nuevo,
#46 error Facturación migueldiab 2 2

Total 82 35

107
ESTADO ACTUAL DEL SISTEMA
S PRINT 8
Fecha de Inicio : 9 de Julio, 2010

Fecha de Fin : 22 de Julio, 2010

Wiki : http://trac2.xp-dev.com/gde/wiki/SprintOcho

Revisiones : commit [108] al commit [actual] (link)

Detalle : El último Sprint intentará pulir los módulos y componentes

desarrollados a lo largo de los 5 Sprints anteriores, mientras se prepara
este documento del sistema.

La gráfica de Burndown estará disponible en la página del Sprint una

vez el mismo haya sido finalizado. Las tareas a cubrir son las que se
detallan debajo, y se centran principalmente en cerrar esta etapa de
desarrollo, dejando el sistema listo para la continuación del mismo.

Plan de Tareas

# Tkt Descripción Módulo Dueño Estimado Total

Desde una factura, se abre un DIV de

#19 ingreso de cliente Clientes - 8 -

Desde un DIV de ingreso de cliente se

actualizan los datos del mismo
#20 mediante AJAX Clientes - 8 -

Desde una factura, se abre un DIV de

#21 ingreso de articulo Lista de Precios - 8 -

Desde un DIV de ingreso de articulo

se actualizan los datos del mismo
#22 mediante AJAX Lista de Precios - 8 -

#28 Reportes Facturación Facturación - 8 -

#37 Reportes Lista de Precios Lista de Precios - 4 -

#40 Reportes Productos Mas vendidos Facturación - 4 -

Sistema CMS para actualización de

#42 Noticias/Promociones en portada Institucional - 8 -

108
EVOLUCIÓN DEL PRODUCTO
S PRINT 9
Fecha de Inicio : 1 de Agosto, 2010

Fecha de Fin : 20 de Agosto, 2010

Wiki : http://trac2.xp-dev.com/gde/wiki/SprintNueve

Detalle : El Sprint 9 será el primer Sprint en producción del cliente. Si bien hay
una lista de tareas pendientes que se intentarán introducir en
producción lo antes posible, se entiende que este Sprint genere
muchas tareas ad-hoc, y requieran de modificaciones y correcciones de
bugs de manera inmediata.

Plan de Tareas

# Tkt Descripción Módulo Dueño Estimado Total

#34 Monitoreo de artículos en "Back Order" Stock - 8 -

Emisión parcial de Factura en base a un

pedido On-Line, seleccionando productos
#35 para dejar en "Back Order" Facturación - 16 -

#36 Reportes Stock Stock - 4 -

#38 Reportes Clientes por Lista Clientes - 4 -

#39 Reportes Proveedor por Lista Proveedores - 4 -

Control de Stock con Alertas de Stocks

#41 Mínimos y Máximos. Stock - 8 -

109
 10. EL PRODUCTO

PRODUCTO FINAL
El Sistema de Administración y Venta On-Line para grupo del este, tal como el nombre lo
indica, son dos sistemas que operan conjuntamente.

Por un lado nos encontramos con un sitio institucional para la distribuidora (conocido como
frontend), que les permite a sus clientes informarse acerca de la misma, junto con la
funcionalidad de realizar pedidos en línea, evitando así demoras en la distribuidora, y ayudando
a la misma al proceso de digitalización de la información.

Haciendo uso del alcance de internet y el acceso a una computadora, la Distribuidora es capaz
de presentar un puesto de ventas 24 horas al día, 365 días al año, con un costo ínfimo, en
comparación al horario reducido en que opera la misma, junto al costo hora de un empleado
dedicado a la atención de cada cliente.

Este sistema permite también al cliente, informarse sobre descuentos, promociones y más, lo
que resulta en un beneficio mutuo. El cliente está mejor informado sobre posibles
oportunidades para su empresa, mientras que el Grupo del Este de manera sencilla y
económica, logra informar a sus clientes sobre beneficios, excedentes, etc.

110
Del otro lado del sistema, se encuentra el sistema de administración o backend. Desde aquí y
de manera central, la distribuidora puede organizar tanto sus compras de mercadería a
proveedores y mayoristas, como la venta a sus propios almacenes y clientes.

Junto con esto, le permite obtener una serie de reportes e información en tiempo real, que en
un sistema manual resulta impracticable o casi imposible. Pudiendo hacer un minucioso
análisis de las compras y ventas, de la fluctuación de los precios y de las demandas por
temporada, fecha y más.

Por sobre eso, el sistema resuelve de manera simple el manejo de cientos de artículos de
diferentes proveedores, cada uno con su código particular, su nomenclatura propia etc. Para el
sistema, se encuentran todos unificados y bajo un sistema común.

Añadida a esta función, se encuentra la disponibilidad de listas de precios, personalizables y

adaptables a las necesidades del Grupo, pudiendo llegar a un nivel de detalle minucioso, ya
sea por cliente o por proveedor, asegurando así, la máxima competitividad y el mejor manejo
de las ganancias.

111
INSTALACIÓN E IMPLEMENTACIÓN
Nota: Para simplificar el proceso de instalación, se entrega con el producto un DVD con una
máquina virtual de Sun VirtualBox y el instalador para Windows 32 de la misma. Con solamente
instalar VirtualBox, se puede importar un servicio virtualizado, y seleccionar el contenido del
DVD (copiado a un disco escribible). Independientemente puede seguir las instrucciones
debajo para obtener un sistema 100% funcional.

Para instalar el sistema de grupo del este, se necesita instalar primero el Apache Web Server,
seguido del módulo PHP, la base de datos MySQL y el framewok Symfony.

Una vez instalado, se deben configurar las conexiones entre los sistemas, y validar el entorno.

Debajo encontrará una guía paso a paso de cómo dejar el sistema en funcionamiento dentro de
un entorno Windows.

1. Descargue el servidor Apache HTTP Server v2.2

http://httpd.apache.org/download.cgi

2. Ejecute el instalador

3. Configure el servidor con el dominio adecuado

112
4. Complete la instalación

5. Descargue el intérprete PHP v5.2.xx

http://www.php.net/get/php-5.2.13-win32-installer.msi/from/a/mirror

6. Ejecute el instalador

7. Seleccione el servidor Apache v2.2.x

113
8. Seleccione el directorio de configuración del Apache

9. Seleccione las opciones de PDO, PDO/MySQL, OpenSSL y PEAR

10. Finalice la instalación

11. Descargue el Framework Zend Minimal 1.10.x

http://www.zend.com/en/community/downloads

12. Descomprima en un directorio propio

13. Descargue el manejador de base de datos MySQL v5.1.xx

http://www.mysql.com/downloads/mysql/

114
14. Ejecute el instalador

15. Complete la instalación

16. Seleccione para configurar la instalación

115
17. Seleccione el tipo de configuración

18. Configure el motor InnoDB por defecto

19. Configure las sesiones concurrentes y el puerto por defecto

116
20. Por último seleccione el mapa de caracteres y el modo de ejecución

21. Cree una nueva contraseña de root

22. Finalice la configuración

23. Copie el archivo libmySQL.dll del directorio raiz de PHP al directorio System32 de
Windows

24. Descargue Symfony Framework v1.4.x

http://www.symfony-project.org/installation/1_4

25. Descomprima los contenidos en un directorio propio

117
CONFIGURACIÓN
Una vez instaladas las aplicaciones base del servidor, debe pasar a configurar las mismas.
Debajo se muestra una guía paso a paso de cómo configurar la aplicación.

1. Copie el contenido de la carpeta redist\grupodeleste a un directorio propio

Nota: Idealmente, éste no debe estar bajo el directorio de publicación del servidor Web
por motivos de seguridad.

2. Edite el archivo ProjectConfiguration.class.php dentro de la carpeta config y

verifique que apunte al directorio en dónde descomprimió Symfony (ver instalación)

3. Configure el Directorio Virtual del Apache en el archivo httpd.conf dentro de la carpeta

conf del directorio del Apache

NameVirtualHost *:80

<VirtualHost *:80>
ServerName dominio.com
DocumentRoot "Directorio Aplicación\web"
DirectoryIndex index.php
Alias /sf "Directorio Symfony\sf"
<Directory " Directorio Aplicación\web">
AllowOverride All
Order allow,deny
Allow from All
</Directory>
</VirtualHost>

4. De no tener un dominio calificado, edite el archivo hosts.ini y agregue una linea que
corresponda a dominio.com

5. Habilite el módulo rewrite en el archivo httpd.conf de Apache

LoadModule rewrite_module modules/mod_rewrite.so

6. Habilite la ruta de Zend en el archivo php.ini de PHP

include_path=".;C:\Directorio Zend\library"

118
7. Desde la consola de MySQL cree un nuevo schema
Nota: Puede utilizar la herramienta MySQL Administrator y MySQL Query Browser
para realizar la configuración de la base de datos desde un entorno Point & Click

8. Desde la consola de MySQL cree un nuevo usuario

9. Asigne todos los privilegios a ese usuario sobre el schema creado

10. Edite el archivo databases.yml e ingrese la información del schema y

usuario/contraseña creado
Nota: Por motivos obvios de seguridad, este archivo no debe ser visible desde fuera
del servidor, ni tener permisos de lectura/escritura por usuarios no Administradores o
de Sistema

11. Ejecute el script de creación de base create_schema.sql desde \data\sql

12. Ejecute el script de creación de base datos_incio.sql desde \data\sql

119
AYUDA Y MANUAL DE USUARIO
El siguiente, intenta dar una guía básica de cómo acceder al sistema y realizar las operaciones
más comunes. Dada la naturaleza de la aplicación Web, la mayoría de la ayuda contextual se
encuentra en el sistema mismo.

De la misma manera, en la Wiki del proyecto hay información detallada sobre las diferentes
funcionalidades, y por sobre eso, la misma puede ser expandida con las experiencias y
comentarios de los propios usuarios de la aplicación.

MANUAL DEL CLIENTE

Registro de Usuario

Nota : Debe estar registrado para poder hacer pedidos online.

1. Seleccione Registrarse del menú de acciones.

2. Complete el formulario.

3. Seleccione Crear mi cuenta

Luego de aplicar a una cuenta, recibirá un correo electrónico a la dirección ingresada que ;e
permitirá verificar su cuenta.

Luego de esa verificación, su cuenta quedara habilitada, y usted ya quedara ingresado en el

sistema para ingresar sus pedidos en línea.

De no encontrar el mail, verifique que en su carpeta de “Spam”.

120
Ingreso

1. Seleccione Acceder del menú de acciones

2. Escriba su usuario y clave

3. Haga click en Aceptar

Nota : De no recordar sus datos, puede seleccionar Olvidaste tu clave e ingresando su casilla
de correo recibirá la información de cómo recuperar su usuario y clave.

121
Pedido Online

1. Ingrese al sistema con sus credenciales

2. Seleccione Mis Pedidos del menú de acciones

3. Seleccione Nuevo Pedido

4. Seleccione la Categoría del producto deseado

5. Seleccione el producto de la lista

6. Seleccione Agregar

7. Ingrese la cantidad deseada

8. Seleccione Actualizar Cantidades

Nota : Opcionalmente puede seleccionar para borrar un articulo, o seguir agregando al

carrito

9. Una vez finalizado, seleccione Enviar Pedido

Modificar Pedido

Mientras el pedido no esté procesado, podrá modificar las cantidades y los productos del
mismo

Cancelar Pedido

Para cancelar un pedido, deberá ir a la lista de pedidos, seleccionar el pedido y luego

seleccionar Cancelar Pedido.

Nota: Solo puede cancelar un pedido que no fue procesado.

122
Estados de pedidos

Los pedidos respetan el flujo de negocio, y se pueden encontrar en uno de los siguientes
estados :

1. Nuevo
El pedido aun no ha sido enviado, puede ser modificado.

2. Pendiente
El pedido ha sido enviado para su proceso, cuando la factura ha sido emitida, su
estado cambiara a procesado. Un pedido enviado no podrá ser modificado ni
cancelado.

3. Procesado
El pedido está siendo procesado por el personal de la distribuidora

4. Completo
El pedido se encuentra listo para ser retirado

5. Cerrado
El pedido fue retirado de la distribuidora y entregado al cliente.

123
MANUAL DEL ADMINISTRADOR

El siguiente intenta ser una guía básica del backend del sistema, como referencia y a modo
explicativo. La mayoría de la ayuda, se encontrará en el menú de Ayuda Rápida sobre el panel
de acciones a la derecha del sistema.

Ingreso al sistema

Nota : Para acceder al menú de usuario, se requiere de permisos específicos, en caso de no

poder acceder, consulte con algún administrador.

1. Abra un browser en la URL del sitio indicada

2. Ingrese sus credenciales segura

3. Presione Aceptar

124
Facturas de Compras

En el menú de Factura Compras podrá ingresar una boleta de compras, para agregar al stock
actual. En la página principal de Factura Compras podrá:

• Seleccionar una factura del listado para ver su detalle.

• Buscar una factura en base a criterios específicos.

• Crear una nueva factura.

Ingreso de Nueva Factura

1. Ingrese al sistema con sus credenciales seguras

2. Seleccione el menú de Facturación

3. Seleccione la opción Factura Compras

4. Seleccione la opción de Nuevo

Nota : Alternativamente puede usar el método abreviado Nueva Compra en las

opciones del panel de acceso rápido

5. Ingrese el Número de Factura

125
6. Escriba el nombre del proveedor. Una lista contextual mostrará los proveedores que
coincidan con su búsqueda.

a. Para ingresar un proveedor nuevo, presione en el botón a la derecha campo

proveedor. Se abrirá el formulario de ingreso de Proveedor, donde podrá crear
un nuevo proveedor y seleccionarlo de la lista

7. Fecha – Ingrese la fecha de compra de la factura. El ícono de la derecha provee

acceso a un calendario para simplificar la tarea

8. Moneda – Cotización – Ingrese la moneda deseada y ajuste la cotización del día de ser
requerido.

9. Dto 1 al 3 – Ingrese los descuentos generales de la factura si aplican

10. % Log – Ingrese el sobrecargo logístico de la factura si aplica

11. Ingrese el nombre o algún código de articulo. Una lista se desplegará con las
coincidencias para seleccionarlo de la misma

a. Para ingresar un articulo nuevo, presione en el botón a la derecha campo

código de articulo. Se abrirá el formulario de ingreso de Artículo, donde podrá
crear un nuevo artículo y seleccionarlo de la lista

12. Podrá editar de forma manual el Costo, la Cantidad y el descuento particular del
Articulo ingresado.

13. Al llegar al final de la factura, se agregarán líneas automáticamente a la misma.

Nota : Las líneas en blanco no se registran en la factura

126
Facturas Ventas

En el menú de Factura Venta podrá ingresar una boleta de venta, de forma manual.

En la página principal de Factura Venta podrá:

• Seleccionar una factura del listado para ver su detalle.

• Buscar una factura en base a criterios específicos.

• Crear una nueva factura.

Crear Nueva Factura

1. Ingrese al sistema con sus credenciales seguras

2. Seleccione el menú de Facturación

3. Seleccione la opción Factura Ventas

4. Seleccione la opción de Nuevo

Nota : Alternativamente puede usar el método abreviado Nueva Venta en las opciones
del panel de acceso rápido

5. Ingrese el Número de Factura

6. Escriba el nombre del cliente. Una lista contextual mostrará los clientes que coincidan
con su búsqueda.

a. Para ingresar un cliente nuevo, presione en el botón a la derecha campo

proveedor. Se abrirá el formulario de ingreso de Cliente, donde podrá crear un
nuevo cliente y seleccionarlo de la lista

127
7. Fecha – Ingrese la fecha de venta de la factura. El ícono de la derecha provee acceso
a un calendario para simplificar la tarea.

8. Moneda – Cotización – Ingrese la moneda deseada y ajuste la cotización del día de ser
requerido.

9. Dto – Ingrese el descuento general de la factura si aplica

10. Seleccione el tipo de factura CONTADO o CRÉDITO

11. Ingrese el nombre o algún código de articulo. Una lista se desplegará con las
coincidencias para seleccionarlo de la misma

a. Para ingresar un articulo nuevo, presione en el botón a la derecha campo

código de articulo. Se abrirá el formulario de ingreso de Artículo, donde podrá
crear un nuevo artículo y seleccionarlo de la lista

12. Podrá editar de forma manual el Costo, la Cantidad y el descuento particular del
Articulo ingresado.

13. Al llegar al final de la factura, se agregarán líneas automáticamente a la misma.

Nota : Las líneas en blanco no se registran en la factura

128
Procesar Pedidos Online

En la página principal de Factura – Pedidos Online podrá:

• Seleccionar un pedido del listado para ver su detalle.

• Buscar un pedido en base a criterios específicos.

• Crear una nueva factura en base a un pedido online.

Procesar Pedido Online

1. Ingrese al sistema con sus credenciales seguras

2. Seleccione el menú de Facturación

3. Seleccione la opción Pedidos Online

Nota : Alternativamente puede usar el método abreviado Pedidos Online en las

opciones del panel de acceso rápido

4. Seleccione al pedido a procesar haciendo click en el estado del mismo.

Nota : Al procesar un pedido, una nueva factura de venta se creará con los datos del
mismo pre completados. En ese momento el estado del pedido online cambiará a
Procesado

129
Listas de Precio

En el menú de listas de precio, podrá:

• Ver los precios de los artículos de cada lista de precios.

• Administrar las listas asi como su porcentaje.

• Modificar de forma manual el precio de algún producto en particular para una lista de
precios especifica.

Emitir Lista Completa

1. Ingrese al sistema con sus credenciales seguras

2. Seleccione el menú de Lista de Precios

3. Seleccione la opción Listas de Precios

4. Seleccione la lista del cuadro de dialogo

5. Presione el botón Listar

Administración de listas de precio

1. Ingrese al sistema con sus credenciales seguras

2. Seleccione el menú de Lista de Precios

3. Seleccione la opción Administración de Listas de Precios

a. Para eliminar una lista, presione el botón junto a la misma

b. Para editar una lista, presione el botón junto a la misma

c. Para crear una nueva lista, presione el botón de Nuevo

130
Porcentajes Manuales

Usted podrá Agregar, eliminar o modificar de forma manual el valor de productos en alguna de
las listas de precio. El valor del producto será el de Porcentajes Manuales. De no existir un
valor determinado de forma manual, el valor del producto será el determinado por el valor del
articulo mas el porcentaje de la lista de precio.

Para agregar

Seleccione “New”, llene los campos requeridos y seleccione “Save”.

Si desea ingresar mas de una precio manual puede seleccionar “Save and add”.

Para eliminar

Seleccione el checkbox correspondiente al precio que desea eliminar, y en “Choose an action”,

seleccione “Delete”, seguido de “Go”.

Para modificar

Seleccione el numero de Id del precio manual que desea modificar.

Debera modificar los campos deseados y luego apretar en “Save”.

131
Mantenimiento

Desde Mantenimiento podrá administrar:

• Clientes

• Proveedores

• Monedas

• Productos

• IVA

• Categorias

• Ciudad

• Pais

• Clientes:

Usted podrá Agregar, eliminar o modificar los clientes ingresados en el sistema. Note que si
desea que el cliente pueda ingresar pedidos de forma online, deberá crear un Usuario y allí
llenar los datos.

Para agregar

Seleccione “New”, llene los campos requeridos y seleccione “Save”.

Si desea ingresar mas de un Cliente puede seleccionar “Save and add”.

Para eliminar

Seleccione el checkbox correspondiente al cliente que desea eliminar, y en “Choose an action”,

seleccione “Delete”, seguido de “Go”.

Para modificar

Seleccione el numero de Id del cliente que desea modificar.

Debera modificar los campos deseados y luego apretar en “Save”.

132
MANTENIMIENTO
El proyecto se encuentra en fuerte desarrollo. La primer etapa del sistema ha sido completada
y está en beta para ser utilizado en producción.

Esto no implica que el sistema esté carente de defectos, por lo que existe un fuerte control del
sistema y mantenimiento del mismo.

Para ello, se trabaja en conjunto con los administradores del sistema que utilizan a diario el
mismo. Cuando se encuentra un error o defecto, el mismo debe ser reportado mediante el
sistema de manejo de errores.

Para crear un nuevo reporte de errores, basta con acceder a la URL debajo, y llenar los
campos Summary, Description y opcionalmente Component y Priority

http://trac2.xp-dev.com/gde/newticket

133
PLAN DE CONTINUIDAD DE NEGOCIOS
La información es uno de los activos más importantes para las organizaciones, donde los
sistemas de información y disponibilidad de estos juegan un rol preponderante para la
continuidad de un negocio.

Para eso se desarrolla lo que se conoce como BCP (de las siglas en Inglés Business Continuity
Plan) y DR (Disaster Recovery) con el objetivo de mantener la funcionalidad del sistema, a un
nivel mínimo aceptable durante una contingencia.

Para ello, el sistema de Grupo del Este, cuenta independiente de sus servidores tercerizados
con sus propios mecanismos de BCP, con un respaldo diario de la base de datos, que se
realiza a la medianoche, y es transferido a los sistemas locales de la empresa.

En caso de desastre, como ser la caída del servicio de alojamiento web o del enlace a internet,
y sea imposible seguir operando desde ese servicio, existe un mecanismo por el cual se puede
levantar un servidor local (mediante una máquina virtual) para operar en forma local, con la
información respaldada la noche anterior, o en su defecto, levantar en un alojamiento local
mediante un DNS Dinámico.

Éste proveerá un sistema con funcionalidades reducidas y a velocidades mucho menores, pero
mantendrá vivo el sitio, evitando así, una pérdida total del servicio.

134
MERCADEO Y PLAN DE FUTURO

HOSTING Y SUBSCRIPCIÓN
El mantenimiento a futuro del sistema del Grupo del Este, involucra los costos mensuales
asociados al hosting, sumados al dominio registrado. Actualmente el hosting se terceriza a la
empresa estadounidense A2 Hosting. El mismo tiene un cósto de U$S 4.77 por més en su plan
de 36 meses. El dominio se realizó a través de AntelData, y el dominio grupodeleste.com.uy
conlleva un costo anual de $ 485.

Con la página en producción, surge la oportunidad de elaborar un plan de mercado sobre el

producto, siendo ésta prueba piloto una carta de presentación del mismo.

En la página principal del sistema, se encontrará un link con la información de contacto de los
proveedores del sistema, y sobre este sitio, se detallarán las funcionalidades del sistema, el
costo del mismo y el plan de soporte y mantenimiento.

Junto a eso, se tendrá acceso a un “sandbox” con las funcionalidades en pleno desarrollo que
le permitirá a un usuario no registrado, entrar a jugar con el sistema como si fuera un sistema
real.

Agregado a eso, el sistema en versiones futuras tendrá la capacidad de desplegar información

publicitaria de auspiciantes, y mediante la misma, costear los servicios de hosting y
mantenimiento. Esta funcionalidad se encuentra actualmente en desarrollo.

135
 11. ÍNDICE

A IVA, 56, 94

administrador, 43, 44, 52, 53, 54, 55, 56, 57, 58, 59, J
89
alcance, 39, 88, 96, 110 jQuery, 16, 17, 20, 37, 42, 84, 106, 139
Anteproyecto, 95
arquitectura, 11, 15, 16, 20, 33, 34, 41, 96, 97 L
artículo, 10, 21, 43, 57, 79, 82, 89, 90, 93, 109, 111,
130 Listas de Precios, 39, 50, 53, 54, 89, 91, 98, 105
Look & Feel, 85, 90

B
M
backlog, 88
bonificaciones, 89 mantenimiento, 14, 17, 22, 52, 53, 54, 55, 56, 57,
Burndown, 15, 31, 97, 100, 102, 104, 108 58, 59, 80, 133, 135
Moneda, 53, 54, 55, 80, 94, 132

C
O
Categoría, 57
Ciudad, 58, 94 On-Line, 1, 6, 12, 13, 35, 41, 46, 47, 73, 89, 90, 91,
Cliente, 6, 7, 11, 39, 47, 48, 53, 58, 59, 68, 80, 89, 93, 94, 99, 102, 104, 107, 109, 110
90, 91, 92, 93, 98, 103, 105, 107, 108, 109, 120,
132 P
compra, 7, 10, 11, 21, 35, 43, 46, 52, 53, 54, 55, 56,
57, 78, 79, 89, 90, 92, 93, 104, 105, 107, 111, 125 País, 59
Continuidad de Negocios, 134, 139 pedido, 10, 12, 13, 35, 89, 91, 93, 99, 102, 103, 105,
cuenta corriente, 91, 93 107, 109, 122, 123, 129
PHP, 14, 15, 16, 17, 20, 34, 81, 82, 83, 112, 113,
117, 118, 139
F producto, 11, 12, 19, 32, 36, 37, 39, 43, 52, 88, 92,
factura, 12, 13, 37, 43, 44, 47, 48, 78, 89, 91, 93, 99, 95, 96, 112, 122, 135
102, 103, 107, 108, 123 Producto, 46, 52, 90, 92, 108, 132
Factura, 71, 72, 79, 89, 93, 98, 99, 101, 109, 139 proveedor, 43, 44, 78, 92, 107, 111
facturación. See Factura Proveedor, 54, 58, 59, 132
Facturación. See Factura Proveedores, 6, 39, 45, 78, 90, 98, 103, 107, 109
facturar. See Factura
facturas, 12, 43, 52, 53, 54, 55, 56, 57, 89, 90, 98, R
101, 102
framework, 14, 16, 20, 37, 40, 42, 80, 83, 84, 106 recargos, 43, 89
reporte, 6, 10, 31, 32, 47, 48, 91, 92, 93, 111, 133
Requerimientos, 32, 60
G
Grupo del Este, 6, 7, 8, 19, 34, 35, 75, 82, 84, 88, S
89, 91, 104, 110, 134, 135
SaaS, 1, 6, 19, 34, 35
Scrum, 15, 18, 31, 32, 36, 95, 97, 140
I Sprint, 95, 96, 97, 100, 102, 104, 106, 108, 109
Iterations, 15 Sprints, 32, 38, 95, 96, 108

136
SQL, 6, 14, 15, 16, 17, 20, 34, 75, 81, 112, 114, 119, U
139
stock, 6, 7, 10, 13, 35, 43, 46, 47, 48, 89, 91, 93 UML, 15, 17, 140
Symfony, 14, 15, 16, 17, 20, 37, 40, 80, 83, 84, 112,
117, 118, 140 V
venta, 6, 12, 21, 35, 89, 90, 94, 99, 103, 111, 127,
T
128, 129
Tecnología, 20

137
 12. ANEXOS Y TABLAS
BIBLIOGRAFÍA
Google (2010). La Internet

Wikipedia (2010). La Internet

PALACIO, Juan (2007). Flexibilidad con Scrum.

ELMASRI, Ramez (2006). Fundamentos de Bases de Datos. Addison-Wesley

AMBLER, Scott William (2004). The Object Primer: Agile Model Driven Development with UML 2.
Cambridge University Press.

POTENCIER, Fabien (2007). The Definitive Guide to symfony. Apress

WELLING, Luke - THOMSON, Laura (2008). PHP and MySQL Web Development. Addison-Wesley
Professional

138
REFERENCIAS
A2 Hosting http://www.a2hosting.com

Agile Manifesto http://agilemanifesto.org/

Antel Data DNS https://nic.anteldata.com.uy/dns/

Apache Web Server http://httpd.apache.org/

Blog Anje http://www.bloganje.com/

BoUML http://bouml.free.fr/

Coste Total de Propiedad http://es.wikipedia.org/wiki/Coste_total_de_p

ropiedad

DGI Remitos e Información de Facturación http://www.dgi.gub.uy/gxpsites/hgxpp001?4,

6,21,O,S,0,PAG;CONC;7;2;D;1706;1;PAG;,

Doctrine ORM http://www.doctrine-project.org/

Free CSS Templates http://www.freecsstemplates.org

Gliffy http://www.gliffy.com

jQuery http://jquery.org/

Just In Time http://es.wikipedia.org/wiki/M%C3%A9todo_j

usto_a_tiempo

La Factura http://www.derechocomercial.edu.uy/ContCV
02.htm

Ley No. 9.739 – Derechos de Autor http://www.parlamento.gub.uy/leyes/Acceso

TextoLey.asp?Ley=09739&Anchor=

MySQL http://mysql.com/

MySQL Workbench http://wb.mysql.com/

Notepad++ http://notepad-plus-plus.org/

NetBeans http://netbeans.org/

PHP http://php.net/

Plan de Continuidad de Negocios http://estrategiaynegocios.net/vernoticia.asp

139
 x?option=24843

Scrum http://www.scrum.org/

SubVersion http://subversion.apache.org/

Symfony Project http://www.symfony-project.org/

Trac http://trac.edgewall.org/

UML 2.0 http://www.agilemodeling.com/essays/umlDi

agrams.htm

Web Service Currency http://www.webservicex.net/CurrencyConvert

or.asmx?op=ConversionRate

Zend http://www.zend.com/

140