Embed Size (px)
Citation preview
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
2
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.
3
“El Hombre es un experimento, el tiempo dirá si valía la pena” Mark Twain
“El tiempo no se tiene, se hace” Anónimo
4
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
5
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
6
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.
7
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.
8
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.
9
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.
10
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.
11
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
Producto • Definir funcionalidades básicas • Proveer información institucional • Definir lineamientos del sistema
Marta Leyton Encargado del
Sistema • Determinar “simpleza” del producto • Reportar fallas críticas • Corregir flujo del sistema
Giselle De Armas
Cliente de Frontend
• Determinar usabilidad del Frontend • Reportar fallas de Venta OnLine
Gabriela Barrios Cliente de Frontend
• Determinar usabilidad del Frontend • Reportar fallas de Venta OnLine
Betina de Armas
Cliente de Frontend
• Determinar usabilidad del Frontend • Reportar fallas de Venta OnLine
12
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.
13
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.
14
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.
15
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
16
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
17
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
NetBeans IDE Common Development and Distribution License (CDDL) v1.0
$ 0
Notepad++ GNU General Public License 2.0 $ 0
Total Costos $0
18
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
19
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.
20
FACTIBILIDAD TECNOLÓ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.
21
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
22
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.
23
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.
24
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.
25
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
Camel Case
Una palabra con la primera letra en minúsculas, y la primera letra de
cada una de las palabras subsecuentes en mayúsculas.
Ejemplo: customerName
Pascal Case
Una palabra con la primera letra en mayúsculas, y la primera letra de
cada palabra subsecuente también en mayúsculas.
Ejemplo: CustomerName
Hungarian Notation
Comienzan con una o mas letras en minúscula que denotan el tipo de
la variable
Ejemplo: strVariable
Underscore Separated Indica palabras separadas con infraguión.
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.
26
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
27
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
28
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
(Source code)
Un directorio por Namespace y un archivo por clase.
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.
29
Estilos de Codificación (cont)
Código Estilo
Tipos de datos nativos (Native
Data Types)
Priorizar el uso de tipos nativos de C# ante tipos del CTS.
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
(Exception Handling)
No utilizar excepciones para el control de flujo.
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.
30
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.
31
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.
32
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.
33
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.
34
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.
35
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.
36
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.
37
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.
38
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.
39
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.
40
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.
41
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.
42
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.
43
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.
44
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.
45
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.
46
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.
47
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
48
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
49
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.
50
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.
51
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.
52
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
53
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
54
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
55
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
56
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
57
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
58
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
59
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
60
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.
61
PATRONES ESTRUCTURALES
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
62
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.
63
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.
64
DIAGRAMAS DE DEPLOY
65
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.
66
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.
67
68
DIAGRAMAS DE SECUENCIA
AGREGAR NUEVO CLIENTE
69
AGREGAR NUEVO ARTÍCULO
70
AGREGAR PRECIO DE ARTÍCULO
71
CREAR NUEVA FACTURA DE COMPRA
72
CREAR NUEVA FACTURA DE VENTA
73
INGRESAR UN PEDIDO ON-LINE
74
INGRESAR AL SISTEMA
75
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.
76
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.
77
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.
78
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.
79
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
80
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
81
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.
82
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é.
83
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.
84
JQUERY 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).
85
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/
86
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.
87
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)
88
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”.
89
DEBE TENER
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.
90
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.
91
SERÍA BUENO 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
92
Í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.
93
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
94
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.
95
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.
SPRINT 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.
96
SPRINT 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.
97
SPRINT 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.
98
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
#36 Ingreso al sistema con credenciales seguras marcostusso 8
#37 Mantenimiento Básico de Listas de 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
#1
Emisión de Factura con personalización por Cliente con Listas de Precios, Descuentos, etc. migueldiab 20
#38 Selección de Lista de Precios por Defecto para el cliente marcostusso 8
#39 Ingreso de nuevas facturas de compra migueldiab 20
-- Búsqueda de articulos AJAX migueldiab 8 TOTAL 56
99
Tareas Pendientes
# Tkt Descripción Dueño Estimado Horas
#2 Emisión de Factura en base a un pedido On-Line ingresado
20
#10 Crear Pedido
--
#14 Crear Pedido de Back Order
--
#40 Baja automática al emitir una factura de venta
8
#41 Porcentajes a aplicar en cargos logísticos, descuentos, bonos, etc.
13
#83 Diseño de Backend simple y navegable
20
TOTAL 61
100
SPRINT 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.
101
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
#1
Carga Cotización Moneda automática (usar webservice de cotización o tasa elegida por el cliente) Facturación migueldiab 4 4
#2 Carga Fecha de Hoy Automatica en facturas Facturación migueldiab 1 1
#3
Búsqueda de Articulos AJAX (seleccionar con enter o tab o click, testing, etc) Facturación migueldiab 4 4
#4
JavaScript para creación de n Líneas de facturas (que se auto-agreguen al tabular al final o boton para agregar + líneas) Facturación migueldiab 8 8
#5
JavaScript para suma de Totales de Factura (sumar las n Líneas y calcular sus subtotales correspondientes) Facturación migueldiab 4 5
#6 Guardar Factura nueva y líneas asociadas Facturación migueldiab 8 8
#8 Desde el FE el usuario lista o busca los productos a comprar Venta OnLine MarcosTusso 8 19
Total 37 49
102
SPRINT 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.
103
Plan de Tareas
# Tkt Descripción Módulo Dueño Estimado Total
#7 Sumar Stocks de factura ingresada Stock migueldiab 4 3
#13 Desde el Backend un agente puede ver un pedido realizado Venta OnLine migueldiab 8 8
#14
Desde el BackEnd un agente puede “convertir” un pedido en una factura de venta Venta OnLine migueldiab 8 8
#15 La factura de venta calcula totales generales y por línea (JavaScript) Facturación migueldiab 8 8
#16 Baja automática al emitir una factura de venta Stock migueldiab 8 8
#29 Desde el Backend un agente puede ver una compra ingresada Proveedores migueldiab 4 4
#30 Cambio Schema y Tablas/Campos Clientes migueldiab 8 8
Total 48 47
104
SPRINT 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.
105
Plan de Tareas
# Tkt Descripción Módulo Dueño Estimado Total
#9
Desde el FE el usuario ve los precios
de articulos según su lista asociada Venta OnLine MarcosTusso 8 4
#10
Desde el FE el usuario agrega un
articulo a un pedido online (carrito de
compras) Venta OnLine MarcosTusso - 5
#11
El carrito despliega los totales
calculados según cantidades y precios Venta OnLine MarcosTusso 4 4
#12
Desde el FrontEnd el usuario
confirma la compra de los articulos
en el carrito (ya no es más
modificable) Venta OnLine MarcosTusso 8 10
#24
Registro de Clientes en el portal de la
empresa Clientes MarcosTusso 12 12
#26
Valores por defecto para unidades,
máximos y mínimos Clientes - 12 -
#27
Integración Clientes - Listas de
Precios, automatización de
descuentos, ofertas, porcentajes X,
etc
Lista de
Precios - 24 -
Total 68 35
106
SPRINT 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.
107
Plan de Tareas
# Tkt Descripción Módulo Dueño Estimado Total
#17
Desde una factura, se abre un DIV de
ingreso de proveedor Proveedores migueldiab 8 8
#18
Desde un DIV de ingreso de
proveedor se actualizan los datos del
mismo mediante AJAX Proveedores migueldiab 8 8
#23
Acceso a compras On-Line desde
portal Venta OnLine MarcosTusso 12
#25 Monitoreo de estado del pedido Venta OnLine MarcosTusso 24
#31
Un Admin asigna a un articulo un
porcentaje de recargo particular
Lista de
Precios MarcosTusso 8 4
#32
Un Admin selecciona una lista de
precios como lista por defecto
Lista de
Precios MarcosTusso 4
#33
Al crearse un nuevo cliente se le
asigna la lista elegida por el admin
como lista por defecto Clientes MarcosTusso 4 5
#43
Ver listas de precios y precios
particulares en ingreso de pedido
online
Lista de
Precios MarcosTusso 4
#44
Agregar Links y eliminar links muertos
desde el portal Frontend Venta OnLine migueldiab 4 4
#45
Al procesar un pedido online, mover
a lista de "pedidos procesados" Venta OnLine migueldiab 4 4
#46
Al intentar procesar un pedido
procesado, si el estado <> nuevo,
error Facturación migueldiab 2 2
Total 82 35
108
ESTADO ACTUAL DEL SISTEMA
SPRINT 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
#19
Desde una factura, se abre un DIV de
ingreso de cliente Clientes - 8 -
#20
Desde un DIV de ingreso de cliente se
actualizan los datos del mismo
mediante AJAX Clientes - 8 -
#21
Desde una factura, se abre un DIV de
ingreso de articulo Lista de Precios - 8 -
#22
Desde un DIV de ingreso de articulo
se actualizan los datos del mismo
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 -
#42
Sistema CMS para actualización de
Noticias/Promociones en portada Institucional - 8 -
109
EVOLUCIÓN DEL PRODUCTO
SPRINT 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 -
#35
Emisión parcial de Factura en base a un
pedido On-Line, seleccionando productos
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 -
#41
Control de Stock con Alertas de Stocks
Mínimos y Máximos. Stock - 8 -
110
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.
111
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.
112
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
113
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
114
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/
115
14. Ejecute el instalador
15. Complete la instalación
16. Seleccione para configurar la instalación
116
17. Seleccione el tipo de configuración
18. Configure el motor InnoDB por defecto
19. Configure las sesiones concurrentes y el puerto por defecto
117
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
118
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"
119
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
120
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”.
121
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.
122
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.
123
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.
124
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
125
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
126
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
127
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
128
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
129
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
130
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
131
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”.
132
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”.
133
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
134
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.
135
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.
136
11. ÍNDICE
A
administrador, 43, 44, 52, 53, 54, 55, 56, 57, 58, 59,
89
alcance, 39, 88, 96, 110
Anteproyecto, 95
arquitectura, 11, 15, 16, 20, 33, 34, 41, 96, 97
artículo, 10, 21, 43, 57, 79, 82, 89, 90, 93, 109, 111,
130
B
backlog, 88
bonificaciones, 89
Burndown, 15, 31, 97, 100, 102, 104, 108
C
Categoría, 57
Ciudad, 58, 94
Cliente, 6, 7, 11, 39, 47, 48, 53, 58, 59, 68, 80, 89,
90, 91, 92, 93, 98, 103, 105, 107, 108, 109, 120,
132
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
Continuidad de Negocios, 134, 139
cuenta corriente, 91, 93
F
factura, 12, 13, 37, 43, 44, 47, 48, 78, 89, 91, 93, 99,
102, 103, 107, 108, 123
Factura, 71, 72, 79, 89, 93, 98, 99, 101, 109, 139
facturación. See Factura
Facturación. See Factura
facturar. See Factura
facturas, 12, 43, 52, 53, 54, 55, 56, 57, 89, 90, 98,
101, 102
framework, 14, 16, 20, 37, 40, 42, 80, 83, 84, 106
G
Grupo del Este, 6, 7, 8, 19, 34, 35, 75, 82, 84, 88,
89, 91, 104, 110, 134, 135
I
Iterations, 15
IVA, 56, 94
J
jQuery, 16, 17, 20, 37, 42, 84, 106, 139
L
Listas de Precios, 39, 50, 53, 54, 89, 91, 98, 105
Look & Feel, 85, 90
M
mantenimiento, 14, 17, 22, 52, 53, 54, 55, 56, 57,
58, 59, 80, 133, 135
Moneda, 53, 54, 55, 80, 94, 132
O
On-Line, 1, 6, 12, 13, 35, 41, 46, 47, 73, 89, 90, 91,
93, 94, 99, 102, 104, 107, 109, 110
P
País, 59
pedido, 10, 12, 13, 35, 89, 91, 93, 99, 102, 103, 105,
107, 109, 122, 123, 129
PHP, 14, 15, 16, 17, 20, 34, 81, 82, 83, 112, 113,
117, 118, 139
producto, 11, 12, 19, 32, 36, 37, 39, 43, 52, 88, 92,
95, 96, 112, 122, 135
Producto, 46, 52, 90, 92, 108, 132
proveedor, 43, 44, 78, 92, 107, 111
Proveedor, 54, 58, 59, 132
Proveedores, 6, 39, 45, 78, 90, 98, 103, 107, 109
R
recargos, 43, 89
reporte, 6, 10, 31, 32, 47, 48, 91, 92, 93, 111, 133
Requerimientos, 32, 60
S
SaaS, 1, 6, 19, 34, 35
Scrum, 15, 18, 31, 32, 36, 95, 97, 140
Sprint, 95, 96, 97, 100, 102, 104, 106, 108, 109
Sprints, 32, 38, 95, 96, 108
137
SQL, 6, 14, 15, 16, 17, 20, 34, 75, 81, 112, 114, 119,
139
stock, 6, 7, 10, 13, 35, 43, 46, 47, 48, 89, 91, 93
Symfony, 14, 15, 16, 17, 20, 37, 40, 80, 83, 84, 112,
117, 118, 140
T
Tecnología, 20
U
UML, 15, 17, 140
V
venta, 6, 12, 21, 35, 89, 90, 94, 99, 103, 111, 127,
128, 129
138
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
139
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_propiedad
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_justo_a_tiempo
La Factura http://www.derechocomercial.edu.uy/ContCV02.htm
Ley No. 9.739 – Derechos de Autor http://www.parlamento.gub.uy/leyes/AccesoTextoLey.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
140
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/umlDiagrams.htm
Web Service Currency http://www.webservicex.net/CurrencyConvertor.asmx?op=ConversionRate
Zend http://www.zend.com/
![Proyecto Integrador[Tema Microsoft Word 2013]](https://img.pdfslide.net/doc/110x75/55cf986a550346d033978059/proyecto-integradortema-microsoft-word-2013.jpg)
