ISERENATA WEB 2.0. Reporte de Estadía para obtener el Título de Técnico Superior Universitario en Tecnologías de la Información y Comunicación

Transcripción

1 UNIVERSIDAD TECNOLÓGICA DE QUERÉTARO Voluntad. Conocimiento. Servicio ISERENATA WEB 2.0 Reporte de Estadía para obtener el Título de Técnico Superior Universitario en Tecnologías de la Información y Comunicación JAVIER HERNÁNDEZ PINEDA Santiago de Querétaro, Qro. Octubre, 2010.

2 UNIVERSIDAD TECNOLÓGICA DEQUERÉTARO Voluntad. Conocimiento. Servicio ISERENATA WEB 2.0 Reporte de Estadía para obtener el Título de Técnico Superior Universitario en Tecnologías de la Información y Comunicación Asesor de empresa ING. GONZALO ÁLVAREZ ZERECERO Asesor de universidad M. EN C. JORGE LUIS MORALES MONTES Alumno JAVIER HERNÁNDEZ PINEDA Santiago de Querétaro, Qro. Octubre, 2010.

3 ÍNDICE INTRODUCCIÓN iserenata.com, S.A. de C.V Giro de la empresa Misión Visión Organigrama... 6 ISERENATA WEB Análisis de necesidades Plan de trabajo DESARROLLO DEL PROYECTO Selección de la solución ecommerce Comprensión de la arquitectura de la solución ecommerce Detección de los requerimientos necesarios para integrar la solución ecommerce Implementación de los Requerimientos Prueba CONCLUSIONES Dificultades Logros obtenidos Recomendaciones... 28

4 INTRODUCCIÓN: El servicio de iserenata es una manera muy innovadora de sorprender a un ser querido mediante una llamada telefónica conducida por un operador en vivo, que le reproduce un mensaje y una canción. El uso del Internet y las tecnologías de telecomunicaciones, nos permiten ofrecer un regalo creativo y sorprendente para cualquier ocasión y en cualquier lugar del planeta en el día y la hora que el cliente determine. Directo al teléfono. Este documento muestra a grandes rasgos cada una de las etapas efectuadas para la realización de la versión 2.0 del portal de iserenata, se muestra desde la plataforma elegida como base de desarrollo hasta un análisis de necesidades para el nuevo sitio.

5 CAPÍTULO I iserenata.com, S.A. de C.V.

6 1.1 iserenata.com, S.A. de C.V Giro de la empresa Comercio electrónico Misión Ser medio para transmitir sentimientos positivos entre personas Visión Ser el medio predilecto por el cual personas en cualquier parte del mundo transmiten sentimientos positivos a sus seres queridos Organigrama Director General Gerente Operativo Se encarga del manejo y control de los operadores de Contact Center, programando y administrando el número de servicios por Operador y designar los operadores necesarios para cubrir la demanda de servicios Gerente de Mercadotecnia Se encarga de llegar a el mayor número de posibles compradores interactuando y llevando a cabo el Plan de Medios así como realizando las evaluaciones necesarias para ubicar el trabajo de medios. 6

7 Gerente de Contenido Se encarga de mantener y actualizar el inventario de canciones para satisfacer las demandas de nuestros clientes, así como mantener el portal actualizado de acuerdo a los mandos del mercado y desarrollar nuevos productos que mantengan vivo el deseo de recompra de nuestros clientes Gerente Administrativo Se encarga de mantener sana la empresa en los temas fiscales, laborales, administrativos, así como gestionar los presupuestos de las diferentes áreas de negocio Gerente de Atención a Clientes Se encarga, como su nombre lo indica, a atender las demandas, quejas y comentarios de los clientes, y encargarse de llevar a buen término cada una. Llevará a la dirección los comentarios y sugerencias, todo esto para lograr un crecimiento en el servicio y atención a nuestros clientes. Director General G. Contenido G. Operativo G. Mercadotecnia G. Administrativo G. Atención Clientes 7

8 CAPÍTULO II ISERENATA WEB 2.0 8

9 2.1 Análisis de necesidades Definición del proyecto La empresa iserenata.com cuenta con un sitio web que ha funcionado muy bien hasta la fecha, pero hay ciertos detalles que lo limitan, por ejemplo, la experiencia del usuario final en el proceso de compra, solamente tiene la posibilidad de comprar una serenata a la vez, esto a la larga es algo tedioso, ya que si el cliente quisiera comprar 3 serenatas, tendría que hacer el proceso 3 veces, un carrito de compra acabaría con este inconveniente. En cuanto a la implementación de nuevas funcionalidades en el sitio actual para que lo haga 100% una solución ecommerce sería toda una odisea, el código es difícil de mantener, se ha utilizado un paradigma estructurado y lo que se busca aquí es la reutilización y facilidad de mantenimiento y extensibilidad. Así que para dado caso, la nueva versión del sitio web iserenata se adaptará una solución ecommerce open-source totalmente orientada a objetos con la finalidad de mejorar aspectos como la seguridad, extensibilidad, mantenimiento y administración Objetivos 1. Implementar una solución ecommerce 2. Mejorar usabilidad 3. Mejorar seguridad 4. Mejorar rentabilidad de la empresa 9

10 2.2 Plan de trabajo Diagrama de Gantt Id. Nombre de tarea Comienzo Fin Duración May 2010 Jun 2010 Jul 2010 Ago 2010 Sep /5 23/5 30/5 6/6 13/6 20/6 27/6 4/7 11/7 18/7 25/7 1/8 8/8 15/8 22/8 29/8 5/9 12/9 19/9 1 Detección Requerimientos 17/05/ /06/ d 2 Implementación 17/06/ /08/ d 3 MIgración 16/08/ /09/ d 4 Integración 07/09/ /09/ d a) Detección de Requerimientos Se identificarán los requerimientos faltantes relacionados con la solución ecommerce elegida. b) Implementación Implementación de los requerimientos en el nuevo marco de trabajo del sistema web. c) Migración Migración de toda la información a la nueva base de datos de la solución ecommerce. d) Integración Vinculación del sistema web con el back office, encargado de la gestión de las serenatas en el call center Especificaciones 1. Selección de la solución ecommerce 10

11 Se seleccionará la plataforma más adecuada para cubrir las necesidades del proyecto, debe contar con una comunidad activa que la respalde, la cantidad de documentación también es un punto importante. 2. Comprensión de la arquitectura de la solución ecommerce Se hará un estudio exhaustivo de la arquitectura de la plataforma a utilizar, el análisis de la documentación y estructura del código fuente entran en juego en esta parte. 3. Detección de los requerimientos necesarios para integrar la solución ecommerce Se detectarán los requerimientos faltantes para completar la solución ecommerce de acuerdo a las necesidades de la empresa iserenata. 3.1 Modificación en el funcionamiento del carrito de compra Se modificarán partes del comportamiento del núcleo del sistema para adecuarlo a las necesidades especificadas. 3.2 Productos especiales Se crearán tipos especiales de productos para poder adaptar las serenatas en el nuevo sistema. 11

12 3.3 Validación Se definirán las reglas de validación para las serenatas. 3.4 Módulos generales Se crearán módulos específicos para la nueva plataforma. 3.5 Cupones Se implementará un sistema de cupones para el pago vía SMS, Tarjeta Prepago, Cupón Prepago y Pasarelas de pago (Dineromail y Banamex) Se instalará un certificado de seguridad SSL para integrar estas pasarelas de pago en la nueva plataforma. 3.7 Modificación de la plantilla Se modificarán las plantillas (archivos tpl), integrando el nuevo diseño del sitio en la plataforma. 3.8 Migración de la información Se migrará toda la información de la antigua base de datos a la nueva, desde usuarios hasta serenatas programadas con anterioridad desde el otro sitio. 12

13 3.9 Integración con el Back Office Se integrará la nueva plataforma con el sistema local que gestiona las serenatas en el call center. 4. Implementación de los Requerimientos Se implementarán los requerimientos antes mencionados 5. Prueba Se harán pruebas de programación de serenatas con clientes frecuentes, contestarán una encuesta para evaluar aspectos como diseño y usabilidad. 13

14 CAPÍTULO III DESARROLLO DEL PROYECTO 14

15 3.1. Selección de la solución ecommerce Se encontraron varias soluciones ecommerce que a continuación se hace referencia junto con una descripción. Fig oscommerce al inicio fue la solución a utilizar al contar con una gran comunidad y gran cantidad de recursos, la desventaja fue la codificación, con un código sumamente acoplado, en pocas palabras iba a ser un dolor de cabeza realizar cambios en el sistema. Fig Zencart es el hijito mejorado de oscommerce, cuenta con una mejor estructura del código ya que utiliza el patrón de diseño compuesto MVC (Modelo Vista Controlador), pero hay todavía algunas fallas al romper con ciertas reglas de implementación que lo hacen difícil de mantener. Fig

16 Magento es una solución muy robusta que tiene poco tiempo en el mercado, construido a partir del Zend Framework, una de las desventajas es que es muy pesado en su ejecución tanto así, que se necesitaría una servidor dedicado, también al utilizar Zend Framework la curva de aprendizaje es larga para entender en su totalidad la arquitectura y poder hacer cambios en su implementación. Fig Prestashop es una solución ecommerce desarrollada por estudiantes franceses, su diseño es muy atractivo, tiene poco tiempo en el mercado al igual que magento, esta solución está pobremente documentada, por lo que no fue una solución viable, pero es una gran opción si se pretende iniciar un negocio. Fig Opencart fue encontrada por casualidad, pero fue una bendición, ya que es una maravilla, lo que más asombra es la claridad en su código, esta bellamente codificada, es una tienda 100% orientada a objetos, está construida a partir de un 16

17 framework que es de autoría del desarrollador que se basa en el patrón MVC, tiene todo tan bien estructurado que es muy fácil hacer cambios. Debido a que ya se había trabajado con algunos frameworks de PHP como code igniter, con el cual se encontraron muchas semejanzas, conciso, claro y va al grano. Por todos estos detalles y más, se eligió esta solución como la ideal para la realización del sitio iserenata versión Comprensión de la arquitectura de la solución ecommerce OpenCart utiliza MVC, a continuación se entrará en más detalle. Modelo Vista Controlador (MVC) es un estilo de arquitectura de software que separa los datos de una aplicación, la interfaz de usuario, y la lógica de control en tres componentes distintos. El estilo de llamada y retorno MVC (según CMU), se ve frecuentemente en aplicaciones web, donde la vista es la página HTML y el código que provee de datos dinámicos a la página. El modelo es el Sistema de Gestión de Base de Datos y la Lógica de negocio, y el controlador es el responsable de recibir los eventos de entrada desde la vista. 17

18 Un diagrama sencillo que muestra la relación entre el modelo, la vista y el controlador. Nota: las líneas sólidas indican una asociación directa, y las punteadas una indirecta (por ejemplo, patrón Observer). Descripción del patrón Modelo: Esta es la representación específica de la información con la cual el sistema opera. En resumen, el modelo se limita a lo relativo de la vista y su controlador facilitando las presentaciones visuales complejas. El sistema también puede operar con más datos no relativos a la presentación, haciendo uso integrado de otras lógicas de negocio y de datos afines con el sistema modelado. Vista: Este presenta el modelo en un formato adecuado para interactuar, usualmente la interfaz de usuario. Controlador: Este responde a eventos, usualmente acciones del usuario, e invoca peticiones al modelo y, probablemente, a la vista. Muchos sistemas informáticos utilizan un Sistema de Gestión de Base de Datos para gestionar los datos: en líneas generales del MVC corresponde al modelo. La unión entre capa de presentación y capa de negocio conocido en el paradigma de la Programación por capas representaría la integración entre Vista y su correspondiente Controlador de eventos y acceso a datos, 18

19 MVC no pretende discriminar entre capa de negocio y capa de presentación pero si pretende separar la capa visual gráfica de su correspondiente programación y acceso a datos, algo que mejora el desarrollo y mantenimiento de la Vista y el Controlador en paralelo, ya que ambos cumplen ciclos de vida muy distintos entre sí. Aunque se pueden encontrar diferentes implementaciones de MVC, el flujo que sigue el control generalmente es el siguiente: El usuario interactúa con la interfaz de usuario de alguna forma (por ejemplo, el usuario pulsa un botón, enlace, etc.) El controlador recibe (por parte de los objetos de la interfazvista) la notificación de la acción solicitada por el usuario. El controlador gestiona el evento que llega, frecuentemente a través de un gestor de eventos (handler) o callback. El controlador accede al modelo, actualizándolo, posiblemente modificándolo de forma adecuada a la acción solicitada por el usuario (por ejemplo, el controlador actualiza el carro de la compra del usuario). Los controladores complejos están a menudo estructurados usando un patrón de comando que encapsula las acciones y simplifica su extensión. El controlador delega a los objetos de la vista la tarea de desplegar la interfaz de usuario. La vista obtiene los datos del modelo para generar la interfaz apropiada para el usuario donde se reflejan los cambios en el modelo (por ejemplo, produce un listado del contenido del carro de la compra). El modelo no debe tener conocimiento directo sobre la vista. Sin embargo, se podría utilizar el patrón Observador para proveer 19

20 cierta indirección entre el modelo y la vista, permitiendo al modelo notificar a los interesados de cualquier cambio. Un objeto vista puede registrarse con el modelo y esperar a los cambios, pero aun así el modelo en sí mismo sigue sin saber nada de la vista. El controlador no pasa objetos de dominio (el modelo) a la vista aunque puede dar la orden a la vista para que se actualice. Nota: En algunas implementaciones la vista no tiene acceso directo al modelo, dejando que el controlador envíe los datos del modelo a la vista. La interfaz de usuario espera nuevas interacciones del usuario, comenzando el ciclo nuevamente. Opencart utiliza este patrón pero con una ligera diferencia el cual llama MVC(+L), la L se refiere al lenguaje, desacopla la parte de los lenguajes, para poder integrar en el sitio infinidad de idiomas sin que esto conlleve grandes cambios en el código. Primeramente, el directorio donde esta alojado OpenCart luce como esto: Admin El directorio admin es la ruta de todo el código de la parte administratriva, esta separada del área del catálogo que es la parte que ve el cliente, y esta carpeta se puede guardar inclusive en otro servidor si así se prefiere. Catalog El directorio catálogo aloja todo el código del sitio público, aquí es donde acceden los clientes. 20

21 Image El directorio imagen es donde se guardan todas la imagines de los productos. Download El directorio descarga es donde se alojan los archivos de descarga del sitio. System El directorio sistema contiene todas las librerías comunes y el motor del sitio. El directorio admin y el catálogo dependen de esta carpeta para su correcto funcionamiento, si se aloja el directorio admin en otro servidor se tendrá que copiar también el contendido de esa carpeta. En los directorios admin y catálogo, se encuentra la siguiente estructura de directorios: Model Capa de Base de Datos Todas las llamadas a la base de datos se hacen aquí, el controlador hace uso del modelo para la obtención de los datos. View - Plantillas Es donde se encuentra el HTML y toda la parte de diseño es hecha en los archivos tpl. Controller Controlador Principal Gestiona las peticiones de los usuarios, se encuentra toda la lógica del negocio. Language - Lenguajes Es donde se especifica que constantes se traducen a texto, por ejemplo títulos de cabecera, ligas, textos, etc. 21

22 Entonces por ejemplo, para la página de productos en la parte del cliente, hay 4 archivos principales: M: \catalog\model\catalog\product.php V: \catalog\view\theme\default\template\product\product.tpl C: \catalog\controller\product\product.php L: \catalog\language\english\product\product.php De manera similar en el administrador del sitio: M: \admin\model\catalog\product.php V: \admin\view\template\catalog\product_form.tpl C: \admin\controller\catalog\product.php L: \admin\language\english\catalog\product.php Esto muestra a grandes rasgos la estructura del código, lo cual lo hace fácil de mantener, y aquí lo más importante es seguir el principio KISS (Manténgalo breve y simple) Detección de los requerimientos necesarios para integrar la solución ecommerce Durante el desarrollo del sitio se integraron nuevas funcionalidades en las que se destacan las siguientes: Modificación en el funcionamiento del carrito de compra 22

23 La solución ya venía integrada con la implementación básica, pero en este caso se tuvo que realizar modificaciones al núcleo del sistema para poder trabajar con productos que manejen distintos parámetros para su validación Producto especiales Se necesitó integrar productos especiales que se puedan programar de acuerdo a ciertos atributos específicos Validación Se realizó la validación de los atributos específicos como la zona horaria, si esta disponible de acuerdo a la hora seleccionada, reglas de marcación de los países, etc Módulos generales Se realizaron módulos como el de anuncios, invita a un amigo, paquetes, mis contactos son necesarios para la integración del nuevo sitio Cupones Se agregó funcionalidad para la gestión de cupones para el pago de serenatas vía SMS, , Tarjetas de Prepago y Cupones de Prepago Pasarelas de pago (Dineromail y Banamex) Se integraron las pasarelas de pago Dineromail y Banamex, PayPal ya venía preinstalada en el paquete Modificación de la plantilla 23

24 Se realizó el nuevo diseño del sitio y se acopló al nuevo sistema Migración de la información Importación de usuarios, productos, evidencias y contactos a la nueva base de datos Integración con el Back Office Integración del sistema web con el sistema de gestión en el back office. 3.4 Implementación de los requerimientos Durante esta etapa se inicio la implementación de las siguientes tareas: 1. Flujo de compra y agendación de iserenatas 2. Desarrollo de secciones "Informativas" 3. Integración de países/validación teléfono 4. Zonas horarias / módulo validación zonas horarias 5. Módulo de contactos 6. Formas de pago / cupones 7. Componente reproductor canciones 8. Integración de módulo de banners 9. Aplicación de elementos de diseño gráfico (eliminación imágenes muestra) 10. Correcciones y aplicación botones 24

25 11. Módulo chat 12. Módulo grabación mensaje voz 13. Editor HTML en sección mensaje 14. Módulo sube tu canción 15. Instalación en el servidor 16. Módulo invita a un amigo 17. Paypal adecuación y desarrollo Dinero Mail 18. Videos y audios de grupo formula 19. Paquetes de iserenatas 20. Correcciones de configuración Explorer Completar catálogo de canciones / demos / letras 22. Certificado de seguridad 23. Módulos demos 24. Igualar horario servidor Colorado 25. Incorporación SMS a pagos con sms 26. Pasarela de pago de Banamex 27. Integración Asterisk 28. Migración de información Cabe mencionar que para la integración de la pasarela de pago de Banamex se tuvo que instalar un servidor de socket para el envío de datos, una capa de seguridad más para la transferencia de la información. Se trabajó en un esquema 3 Party, esto quiere decir que banamex se encarga de recoger los datos importantes como el número de tarjeta y así procesarlo absolutamente todo desde su 25

26 sitio, esto tiene como desventaja el redireccionamiento al sitio de banamex para la captura de los datos. Se quiso trabajar en un esquema 2 Party para evitar esto pero al parecer esta opción fue descartada al informarnos que ese esquema ya no es válido en México por la cantidad de fraudes que han surgido. 3.5 Prueba Durante esta etapa se definieron distintos segmentos de mercado y se escogieron 20 personas al azar en cada uno, se les envió un correo invitándolos a probar el nuevo sitio, se les dio un cupón gratis para la programación de su serenata y al finalizar el proceso contestaban una encuesta con la finalidad de retroalimentación y así mejorar detalles que se habían pasado por alto. Se pueden ver en el siguiente enlace los resultados: 26

27 CAPÍTULO IV CONCLUSIONES 27

28 4.1 Dificultades Migración de todas las funcionalidades del sitio anterior al nuevo, entendimiento de la arquitectura del sitio anterior y más adelante estudiar el marco de trabajo de la solución ecommerce, para así empezar la integración de las funcionalidades en la nueva plataforma, esto requirió un estudio exhaustivo, el proceso fue largo pero al final valió la pena el resultado. 4.2 Logros obtenidos El sitio ha tenido una buena aceptación por parte de los clientes, y con todas las nuevas funcionalidades se espera un incremento en los clientes y las ventas. El sitio inspira mucho más confianza y seriedad, esto a corto y largo plazo redituará en grandes frutos. 4.3 Recomendaciones Mejorar aspectos del diseño y usabilidad. 28

29 Bibliografía: Opencart, Documentación PHP, 29