DESARROLLO DE UN PROTOTIPO DE GESTOR DE CONTENIDOS PARA LOS PROCESOS ESTRATÉGICOS DE NEGOCIO DE LA FUNDACIÓN CONEXIÓN BIENESTAR MEDIANTE LA IMPLEMENTACIÓN DE LA ARQUITECTURA MODELO VISTA CONTROLADOR
XENIA VIVIANA CADENA DÍAZ NELSON ARLEY CARANTÓN GALEANO
UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDAS FACULTAD DE INGENIERÍA PROYECTO CURRICULAR DE INGENIERÍA DE SISTEMAS BOGOTA D.C. 2016
DESARROLLO DE UN PROTOTIPO DE GESTOR DE CONTENIDOS PARA LOS PROCESOS ESTRATÉGICOS DE NEGOCIO DE LA FUNDACIÓN CONEXIÓN BIENESTAR MEDIANTE LA IMPLEMENTACIÓN DE LA ARQUITECTURA MODELO VISTA CONTROLADOR
XENIA VIVIANA CADENA DÍAZ 20101020016 NELSON ARLEY CARANTÓN GALEANO 20101020017
Ing. CARLOS ENRIQUE MONTENEGRO MARÍN Director
UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDAS FACULTAD DE INGENIERÍA PROYECTO CURRICULAR DE INGENIERÍA DE SISTEMAS BOGOTA D.C. 2016
Nota de aceptación:
_________________________________ _________________________________ _________________________________ _________________________________ _________________________________ _________________________________ _________________________________
_________________________________ Firma del jurado
Bogotá D.C., Mayo ____ de 2016
3
4
DEDICATORIA “Aléjate de la gente que trata de empequeñecer tus ambiciones. La gente pequeña siempre hace eso, pero la gente realmente grande, te hace sentir que tú también puedes ser grande - Mark Twain” Quiero dedicarle este trabajo primero que todo a Dios, quien me brindo la fortaleza, salud, seguridad y recursos para poder concluir con esta etapa de la mejor forma posible. A mis padres Francisco Cadena Cortés y Carmen Luz Díaz Cleves, quienes confiaron en mí para desarrollar esta etapa de mi vida en esta ciudad y me dieron todos los concejos necesarios para afrontar los inconvenientes en el trayecto. A mis hermanas Lorena, Cristina y Paola, quienes siempre estuvieron dispuestas para escucharme y apoyarme en lo que pudieron. A mis tíos Rosalba, Teo, Rubiela, Helena, Elisabeth, Adolfo, Darío, Toño y mi Madrina Lucy, quienes con sus familias me apoyaron económica y moralmente para sobrevivir en esta ciudad y concluir con mis estudios. A mi novio y compañero de pasantía Arley Carantón, quien sin su ayuda no hubiera podido concluir esta etapa, me apoyo incondicionalmente en todas las adversidades que se presentaron y se convirtió en mi más importante aliado.
XENIA VIVIANA CADENA DÍAZ
5
6
DEDICATORIA Primero a la Universidad Distrital Francisco José de Caldas por haberme aceptado y poder ser parte de ella, así como también a los diferentes docentes que brindaron sus conocimientos y su apoyo para seguir adelante día a día. A mis directores de pasantía, Ingeniero Carlos Montenegro y la Ingeniera Milena Siachoque, por haberme brindado la oportunidad de recurrir a sus conocimientos y experiencia. A Carolina Angarita, directora de la Fundación Conexión Bienestar que nos dio su voto de confianza para que sacaramos este proyecto adelante. Principalmente a mis padres que tuvieron mucha paciencia y sin ellos no sería esto posible. Por último a Viviana Cadena por quien no hubiera preferido otra compañera, amiga y novia.
NELSON ARLEY CARANTÓN GALEANO
7
8
AGRADECIMIENTOS
Agradecemos a nuestros directores de proyecto de grado Milena Siachoque quien veló para que este trabajo fuera realidad y nos contactó con las personas que nos guiaron para el desarrollo de la pasantía y Carlos Montenegro quien nos hizo las correcciones pertinentes y aceptó guiarnos en este proceso. Agradecemos a Carolina Angarita quien nos brindó la oportunidad de desarrollar este proyecto junto al personal de la Fundación Conexión Bienestar y nos hizo parte de esta gran familia. Agradecemos a nuestros amigos quienes nos apoyaron en muchos momentos y nos brindaron apoyo incondicional en el transcurso de la carrera. Agradecemos a la Universidad Distrital Francisco José de Caldas y sus directivos quienes nos brindaron la oportunidad de aprender de sus docentes y personal para culminar esta carrera con sabiduría y éxito.
9
10
TABLA DE CONTENIDO
RESUMEN........................................................................................................................ 18 INTRODUCCIÓN ............................................................................................................. 21 1.
PLANTEAMIENTO DEL PROBLEMA ...................................................................... 22
1.1 DESCRIPCIÓN DEL PROBLEMA ............................................................................... 22 1.2 FORMULACIÓN DEL PROBLEMA ............................................................................ 22 2. JUSTIFICACIÓN........................................................................................................... 23 3. OBJETIVOS .................................................................................................................. 24 3.1 OBJETIVO GENERAL ................................................................................................ 24 3.2 OBJETIVOS ESPECÍFICOS......................................................................................... 24 4. MARCO REFERENCIAL .............................................................................................. 26 4.1 ESTADO DEL ARTE ................................................................................................... 26 4.1.1 WordPress ................................................................................................................. 26 4.1.2 Drupal ....................................................................................................................... 26 4.1.3 Joomla ...................................................................................................................... 26 4.1.4 Typo3 ....................................................................................................................... 26 4.2 MARCO TEÓRICO ..................................................................................................... 27 4.2.1 Arquitectura MVC (U Alicante, 2009)......................................................................... 27 4.2.2 Procesos clave de negocio (Barros, 1994) .................................................................... 28 4.2.3 Webservice................................................................................................................ 28 4.2.4 Pasarela de pagos ....................................................................................................... 29 4.2.5 Base de datos no relacional ......................................................................................... 29 4.2.6 Scrum (Schwaber, Sutherland, 2013)........................................................................... 29 4.2.6.1 Roles Principales..................................................................................................... 30 4.2.6.2 Sprint ..................................................................................................................... 30 4.2.6.3 Reuniones en Scrum ................................................................................................ 30
11
4.2.6.3.1 Daily Scrum ......................................................................................................... 30 4.2.6.3.2 Reunión de Planificación del Sprint ....................................................................... 31 4.2.6.3.3 Reunión de Revisión del Sprint (Sprint Review Meeting) ........................................ 31 4.2.6.4 Trello ..................................................................................................................... 32 4.2.6.5 Hipchat................................................................................................................... 32 4.2.7 GitHub ...................................................................................................................... 32 4.2.8 Rest .......................................................................................................................... 32 4.2.9 Desarrollo guiado por pruebas (TDD).......................................................................... 33 4.2.10 MD5 ....................................................................................................................... 33 4.2.11 3DES ...................................................................................................................... 34 5. RESULTADOS .............................................................................................................. 35 5.1 DESARROLLO DE LA FASE DE PLANEACIÓN ........................................................ 35 5.1.1 Requerimientos .......................................................................................................... 35 5.1.1.1 Definición de Necesidades ....................................................................................... 36 5.1.1.2 Definición de Actores del Proyecto........................................................................... 37 5.1.1.3 Requerimientos ....................................................................................................... 37 5.1.1.4 Historias de Usuario ................................................................................................ 39 5.1.1.5 Especificación de Historias de Usuario ..................................................................... 39 5.1.1.5.1 HU0 - Autenticación de usuarios ........................................................................... 39 5.1.1.5.2 HU1 - Gestión de usuarios .................................................................................... 40 5.1.1.5.3 HU2 - Gestión de menú ........................................................................................ 41 5.1.1.5.4 HU3 - Gestión de carrusel ..................................................................................... 41 5.1.1.5.5 HU4 - Gestión de publicaciones ............................................................................ 42 5.1.1.5.6 CU5 - Gestión de videos ....................................................................................... 42 5.1.1.5.7 CU6 – Donaciones................................................................................................ 43 5.1.1.5.8 HU7 - Interacción con la plataforma ...................................................................... 43 5.1.2 Arquitectura .............................................................................................................. 44 5.1.3 Metodología de desarrollo .......................................................................................... 46
12
5.1.3.1 Planificación de iteraciones ...................................................................................... 46 5.1.3.2 Ejecución de iteraciones .......................................................................................... 47 5.1.3.3 Inspección y Adaptación .......................................................................................... 48 5.1.4 Iteraciones ................................................................................................................. 48 5.2 DISEÑO Y DESARROLLO DE PRUEBAS UNIT ARIAS.............................................. 52 5.2.1 Diseño de pruebas unitarias ........................................................................................ 52 5.2.2 Desarrollo de pruebas unitarias ................................................................................... 53 5.2.3 Aclaraciones de las siguientes fases de pruebas ............................................................ 54 5.3 DESARROLLO DE INTERFAZ GRÁFICA .................................................................. 55 5.3.1 Diseños ..................................................................................................................... 56 5.3.2 Plataforma de usuarios ............................................................................................... 57 5.4 DESARROLLO DE LA PERSISTENCIA DE DATOS................................................... 59 5.4.1 Usuario ..................................................................................................................... 61 5.4.2 Menú ........................................................................................................................ 61 5.4.3 Página ....................................................................................................................... 62 5.4.4 Slider ........................................................................................................................ 63 5.4.5 Colaborador............................................................................................................... 63 5.4.6 Video ........................................................................................................................ 64 5.5 DESARROLLO DE LA FASE DE GESTIÓN DE USUARIOS....................................... 65 5.5.1 CRUD de usuario....................................................................................................... 65 5.5.2 Plantilla de autenticación ............................................................................................ 65 5.5.3 Plantilla de gestión de usuario ..................................................................................... 67 5.5.3.1 Gestión de usuario propio ........................................................................................ 67 5.5.3.2 Gestión de todos los usuarios ................................................................................... 68 5.6 DESARROLLO DE LA FASE DE GESTIÓN DE MENÚ .............................................. 70 5.6.1 CRUD de menú ......................................................................................................... 70 5.7 DESARROLLO DE LA FASE DE GESTIÓN DE CARRUSEL ...................................... 72 5.7.1 CRUD de Slider ......................................................................................................... 72
13
5.8 DESARROLLO DE LA FASE DE GESTIÓN DE PUBLICACIONES ............................ 74 5.8.1 CRUD de página ........................................................................................................ 75 5.9 DESARROLLO DE LA FASE DE GESTIÓN DE VIDEOS ........................................... 77 5.9.1 CRUD de video ......................................................................................................... 77 5.10 DESARROLLO DE LA FASE DE DONACIÓN .......................................................... 79 5.10.1 Donación de Estrellas ............................................................................................... 80 5.10.2 Donación Mixta ....................................................................................................... 80 5.10.2.1 CRUD de colaborador ........................................................................................... 81 5.10.3 Conexión con pasarela de pagos ................................................................................ 81 5.11 DESARROLLO DE LA FASE DE GESTIÓN DE BÚSQUEDA ................................... 84 5.12 DESARROLLO DE LA FASE DE CONTACTO ......................................................... 85 6. CONCLUSIONES.......................................................................................................... 86 7. RECOMENDACIONES ................................................................................................. 88 7.1 INTERPRETACIÓN DEL CÓDIGO ............................................................................. 88 7.2 INSTALACIÓN DE MOTORES ................................................................................... 88 7.2.1 Instalación de GitHub................................................................................................. 89 7.2.2 Instalación de NodeJS ................................................................................................ 90 7.2.3 Instalación de MongoDB ............................................................................................ 90 8. SOPORTES TÉCNICOS ................................................................................................ 91 8.1 BIBLIOGRAFÍA .......................................................................................................... 91 8.2 CIBERGRAFÍA ........................................................................................................... 92 ANEXOS .......................................................................................................................... 94
14
LISTA DE FIGURAS Figura 1. Arquitectura general del proyecto ....................................................................44 Figura 2. Diseño Arquitectural del proyecto ...................................................................45 Figura 3. Tableros de funcionamiento de Trello .............................................................46 Figura 4. Ejemplo de uso de Hipchat ..............................................................................47 Figura 5. Iteraciones y actividades ..................................................................................48 Figura 6. Actividades Diseño de pruebas y diseño de interfaz ........................................49 Figura 7. Actividades persistencia de datos y gestión de usuarios ..................................49 Figura 8. Actividades de gestión de menú, carrusel y publicaciones ..............................50 Figura 9. Actividades de gestión de videos y donación de estrellas................................50 Figura 10. Actividades de donación mixta y gestión de búsqueda ..................................51 Figura 11. Actividades de gestión de contacto, refactorización y pruebas ......................51 Figura 12. Pruebas unitarias de usuario y menú ..............................................................53 Figura 13. Pruebas unitarias de Carrusel, Publicaciones, videos y donación ..................54 Figura 14. Página inicial desarrollada .............................................................................58 Figura 15. Diagrama BD .................................................................................................60 Figura 16. Plantilla de autenticación ...............................................................................66 Figura 17. Vista Recuperar Contraseña ...........................................................................66 Figura 18. Vista de menú administrador .........................................................................67 Figura 19. Vista de edición de usuario propio .................................................................68 Figura 20. Vista gestionar usuarios. ................................................................................69 Figura 21. Imagen Menú principal ..................................................................................70 Figura 22. Imagen Menús adicionales .............................................................................70 Figura 23. Vista Create Menú..........................................................................................71 Figura 24. Vista Read y Update Menú ............................................................................71 Figura 25. Vista Carrusel .................................................................................................72 Figura 26. Vista Gestionar Slider ....................................................................................73 Figura 27. Vista publicaciones ........................................................................................74 Figura 28. Vista Read y Delete Página ............................................................................75 Figura 29. Vista Create o Update Página ........................................................................76 Figura 30. Vista videos ....................................................................................................77
15
Figura 31. Vista Gestionar Video ....................................................................................78 Figura 32. Accesos a donaciones.....................................................................................79 Figura 33. Vista Donación de Estrellas ...........................................................................80 Figura 34. Vista Donación Mixta ....................................................................................80 Figura 35. Vista Gestión Colaborador .............................................................................81 Figura 36. Vista Búsqueda...............................................................................................84 Figura 37. Vista Contacto ................................................................................................85
16
LISTA DE TABLAS
Tabla 1. Necesidades del proyecto. .................................................................................36 Tabla 2. Actores del Proyecto..........................................................................................37 Tabla 3. Requerimientos del software. ............................................................................37 Tabla 4. Historias de Usuario ..........................................................................................39 Tabla 5. HU0 ...................................................................................................................39 Tabla 6. HU1 ...................................................................................................................40 Tabla 7. HU2 ...................................................................................................................41 Tabla 8. HU3 ...................................................................................................................41 Tabla 9. HU4 ...................................................................................................................42 Tabla 10. HU5 .................................................................................................................42 Tabla 11. HU6 .................................................................................................................43 Tabla 12. HU7 .................................................................................................................43 Tabla 13. Grupos definidos de las pruebas unitarias. ......................................................52 Tabla 14. Descripción de mockups..................................................................................55 Tabla 15. Explicación diseños de la fundación ...............................................................56 Tabla 16. Descripción de modelos de la BD ...................................................................59 Tabla 17. Datos de modelo Usuario ................................................................................61 Tabla 18. Datos de modelo Menú....................................................................................61 Tabla 19. Datos de modelo Página ..................................................................................62 Tabla 20. Datos de modelo Slider ...................................................................................63 Tabla 21. Datos del modelo Colaborador ........................................................................63 Tabla 22. Datos de modelo Video ...................................................................................64 Tabla 23. Tabla de campos JSON donación. ...................................................................82
17
LISTA DE ANEXOS ANEXO A. MOCKUPS DE LA PLATAFORMA .........................................................94 ANEXO B. EJEMPLOS DE CÓDIGO ...........................................................................98 ANEXO C. DISEÑOS DE LA FUNDACIÓN PARA LA PLATAFORMA ...............104 ANEXO D. MANUAL DE USUARIO DEL GESTOR DE CONTENIDO.................109 ANEXO E. DOCUMENTACIÓN PARA EL DESARROLLADOR ...........................117
18
RESUMEN A través de este proyecto de grado se desarrolló un prototipo de un software para la gestión del contenido de la página web de la Fundación Conexión Bienestar mediante la implementación de la Arquitectura Modelo, Vista, Controlador. El prototipo está desarrollado para adaptarse al diseño que entregó el cliente y cuenta con los siguientes módulos: ● Módulo de gestión de usuarios: Este módulo sirve para que exista un único administrador
que
apruebe
contenido,
pero
también
existen
usuarios
colaboradores, los cuales podrán editar contenido para la página pero hasta que el usuario principal no lo apruebe, no será publicado. Estos últimos usuarios serán creado por el usuario administrador principal. ● Módulo de gestión de carrusel: Es para administrar las publicaciones principales mostradas en el carrusel de la página inicial. ● Módulo de gestión de menú: Es para administrar los menús y submenús que se muestran para acceso directo en la barra de menús. ● Módulo de gestión de publicaciones: Este sirve para que el administrador y los colaboradores editen publicaciones y éstas al ser aprobadas quedan publicadas en la página adaptándose al diseño de la plataforma. ● Módulo de gestión de donaciones: Este es para que los usuarios puedan donar dinero u otros elementos, pero no gestiona como tal la donación sino la conexión con la plataforma de pagos contratada por la fundación. ● Módulo de publicación de videos: La fundación cuenta con un canal de YouTube en el cual han ido publicando contenido concerniente a su razón social, en esta sección los editores podrán mostrar en la plataforma dichos videos con solo agregar el enlace del video. 19
Para el desarrollo de este gestor de contenido se usaron tecnologías modernas como NodeJS para el Back-end, Java Script, Jquery, Html5, Css, Bootstrap, Ckeditor para el Front-end, MongoDB para el almacenamiento de datos y PHP para la conexión con la plataforma de pagos. El objetivo principal del proyecto fue brindarle al cliente un gestor de contenido intuitivo y amigable para la administración de las publicaciones que son por el momento la principal fuente de comunicación con los usuarios de la plataforma de la fundación.
20
INTRODUCCIÓN Conexión Bienestar es una Fundación sin ánimo de lucro que ayuda a que la gente aprenda a vivir mejor, a través de la difusión masiva de conocimiento en Salud Física, Salud Mental o Emocional y Salud Espiritual. De la mano de reconocidos médicos de diversas especialidades, psicólogos, entrenadores, líderes espirituales, y de testimonios reales de supervivencia ante las condiciones y enfermedades más extremas, de superación de toda clase de obstáculos y barreras, y de éxito contra todas las probabilidades, están creando videos cortos y programas completos para ser difundidos en todas las pantallas posibles de canales de televisión, internet, sitios públicos, etc. (Conexión Bienestar, 2015)
El objetivo de la fundación es llegar a cualquier lugar que posea conexión a internet, para esto, la fundación se ha planteado crear una página web que permita no solo socializar su proyecto sino también llegar a todos y cada uno de los habitantes del país y darles mejores herramientas para vivir mejor y saludable. La plataforma pretende mostrar todos los aspectos relacionados con la salud gracias al apoyo de canales de internet como YOUTUBE y BLUEMAT.
Mediante la página mostrarán no solo
contenido de interés sobre salud física, emocional y espiritual, sino que se podrá contactar con los profesionales que trabajan para el proyecto y poder pedir asesoría; además de la facilidad que brinda la página para realizar donaciones a la causa para así poder ampliar el radio de impacto.
21
1. PLANTEAMIENTO DEL PROBLEMA
1.1 DESCRIPCIÓN DEL PROBLEMA En los últimos años se ha visto cómo la web se convierte cada vez más en parte de la cotidianidad, es por esto que la creación de páginas web con diverso contenido ha ido aumentando de manera exponencial desde la creación de la primera página web en 1989; según cifras de la revista El Comercio Mundo en 2014 el número ascendía a los 1000 millones con un crecimiento de 4000 páginas creadas al día. A raíz este fenómeno se han creado diversos gestores de contenido con diferentes funciones para facilitar a las personas que no poseen los conocimientos necesarios la creación de su propia página web con solo hacer algunos clicks. Pero no siempre se puede contar con la herramienta que cumpla con todos los requerimientos de la página web que tiene el usuario. (Souer, Joor, 2010) La fundación Conexión Bienestar necesita un entorno que le permita gestionar sus contenidos fácilmente sin la necesidad de lidiar con gestores poco predecibles y que tenga el diseño único de los 3 colores representativos de la salud física, emocional y espiritual, verde, azul y morado respectivamente. Además con solo las herramientas para administrar las publicaciones, el menú y los usuarios que pueden modificar el contenido de la plataforma. Es aquí donde surge el problema para la fundación, ya que desean un gestor que contenga exactamente su diseño y no posea herramientas que sobren y no utilicen en el presente o futuro de la página.
1.2 FORMULACIÓN DEL PROBLEMA ¿CÓMO ADMINISTRAR LOS PROCESOS CLAVE DE NEGOCIO DE LA FUNDACIÓN CONEXIÓN BIENESTAR POR MEDIO DE UN GESTOR DE CONTENIDOS?
22
2. JUSTIFICACIÓN Como afirman Giannaccini y Müller (2014) Usar plantillas prefabricadas o gestores de contenido puede conllevar a muchas desventajas o errores al momento de crear una página web, ya que hoy en día esta tarea se ha vuelto muy fácil con estos programas, los cuales permiten generar una página web en tan solo 10 minutos. Pero estas plantillas traen diferentes desventajas que a futuro pueden convertirse en una molestia para el dueño de la página web; algunas de estas desventajas son:
El gestor de contenido no es predecible, las páginas web generadas con estos gestores
terminan
siendo
trabajos
poco
profesionales.
Reducen
el
posicionamiento en buscadores SEO, lo que reduce las visitas a la página.
La seguridad es baja, servicios como los newsletter podría hackearse fácilmente, además del contenido total de la página es vulnerable a los hackers, no se puede modificar completamente la plantilla, son poco accesibles a este tipo de modificaciones; además las convierte en contenedores de “basura”, es decir elementos en la página que el cliente nunca va a utilizar.
Las páginas creadas con estos gestores son más pesadas que las páginas hechas por profesionales, el diseño nunca será único, no es extraño encontrar más de una página web con el mismo diseño, el contenido puede ser editado, pero no es conocido si se realiza de forma segura.
Usar estos servicios no es 100% desventajoso, ya que puede poseer muchas plantillas atractivas para diversos proyectos, pero es evidente que las plataformas desarrolladas por un profesional serán siempre seguras, originales y eficientes (Samper, 2014). La Fundación Conexión Bienestar pretende dar acceso a todo el que tenga acceso a internet de su contenido informativo y educativo; y para esto necesitan poder ingresar contenido informativo cada vez que tienen nuevo material y manipular los menús y publicaciones del slider para poder promocionar los contenidos nuevos, además necesitan tener permisos de acceso al gestor de contenido de su plataforma pero no para un solo usuari, pero que no todos tengan la opción de publicar directamente los contenidos nuevos; es por esto que se creo la necesidad del gestor de contenido de la plataforma, que adapte las publicaciones al diseño de la página. 23
3. OBJETIVOS
3.1 OBJETIVO GENERAL Desarrollar un prototipo de gestor de contenidos que soporte los procesos clave de negocio de la Fundación Conexión Bienestar que implemente la arquitectura de software MVC y haga uso de la metodología SCRUM, consumo de webservice, base de datos no relacional y lenguajes modernos; para facilitar la administración de menús, publicaciones, usuarios e interfaz gráfica.
3.2 OBJETIVOS ESPECÍFICOS ● Planear las etapas de trabajo, mediante la metodología de desarrollo SCRUM para la estructuración y seguimiento del desarrollo del proyecto. ● Especificar y gestionar los requerimientos del cliente, para tener claras las necesidades del usuario y plasmarlas en el desarrollo. ● Diseñar y desarrollar pruebas mediante el uso del desarrollo basado en pruebas, para aprobar el despliegue de cada iteración del proyecto. ● Desarrollar la plantilla base de la página web haciendo uso del diseño otorgado por el cliente, para darle una apariencia inicial a la aplicación. ● Diseñar el modelo de base de datos por medio del uso de base de datos no relacional, para darle a la aplicación un entorno de almacenamiento de datos. ● Crear un módulo de gestión de usuarios mediante el uso del lenguaje Node-JS para darle acceso único de administrador al cliente.
24
● Desarrollar un módulo de gestión de menús mediante el uso de la base de datos y la plantilla para darle a la aplicación uso dinámico del menú.
● Desarrollar un módulo de gestión de carrusel mediante el uso de la base de datos, la plantilla y complementos de creación de sliders, para brindarle al cliente la opción de publicación de novedades. ● Diseñar y desarrollar un módulo de gestión de publicaciones mediante el uso de la base de datos y la plantilla, para dar al cliente la opción de crear publicaciones con sus necesidades sin dañar el diseño de la plantilla. ● Crear un módulo de transferencia de dinero mediante la conexión con el webservice de pasarela de pagos de la fundación para facilitar la concesión de dinero. ● Crear un módulo de transferencia de recursos mediante el uso de la base de datos y un servidor SMTP, para facilitar la concesión de recursos hacia la fundación. ● Desarrollar un módulo de publicación de videos mediante el uso de la plantilla y el canal de YouTube de la fundación, para visualizar en la plataforma las novedades de dicho canal.
25
4. MARCO REFERENCIAL
4.1 ESTADO DEL ARTE Un CMS (Content Management System) es un sistema de gestión de contenidos, es decir, un programa desarrollado para que cualquier usuario pueda administrar y gestionar contenidos de una web con facilidad y sin conocimientos previos de programación Web. (Quinterio, Riveiro, 2014).
Existen cientos de gestores de
contenido web, entre los más utilizados y eficientes están:
4.1.1 WordPress Es uno de los más sencillos de utilizar. Se creó en 2003, en un principio para realizar blogs, pero con el paso del tiempo se ha ido mejorando el producto y añadiendo funciones nuevas. WordPress es un proyecto de código abierto, lo que significa que hay cientos de miles de personas de todo el mundo trabajando con él. (Wordpress, 2010)
4.1.2 Drupal Es un sistema libre, modular multipropósito y muy configurable que permite publicar artículos, imágenes, archivos y servicios añadidos como foros, encuestas, votaciones, blogs y administración de usuarios y permisos. El diseño de Drupal es especialmente idóneo para construir y gestionar comunidades en Internet. (Drupal, 2012)
4.1.3 Joomla Es un sistema que permite desarrollar sitios webs dinámicos e interactivos. Su nombre es una pronunciación fonética para anglófonos de la palabra swahili jumla, que significa “todos juntos” o “como un todo”. (Joomla, 2014)
4.1.4 Typo3 Es un gestor de contenidos enfocado para la creación de portales y sitios más generales, no sólo blogs. Destaca por sus altos niveles de accesibilidad web. (Typo3, 2010)
26
4.2 MARCO TEÓRICO 4.2.1 Arquitectura MVC (U Alicante, 2009) El modelo arquitectural Modelo Vista Controlador (MVC) separa datos, interfaz de usuario y lógica de control de una aplicación en tres componentes; éste ha demostrado validez en muchos tipos de aplicaciones y múltiples lenguajes y plataformas, lo que lo convierte en un modelo maduro. Los tres componentes son:
Modelo: Contiene una representación de los datos que maneja el sistema, su lógica de negocio y sus mecanismos de persistencia. Es responsable de: -
Acceder a la capa de almacenamiento de datos.
-
Definir las reglas de negocio, es decir funcionalidad del sistema.
-
Registro de vistas y controladores del sistema.
Vista: También conocida como la interfaz de usuario, que compone la información enviada al cliente y su interacción con el mismo. Es responsable de: -
Recibir datos del modelo y mostrarlos al usuario.
-
Tener registro de controlador asociado.
-
Brindar servicio de actualización.
Controlador: Es el actor intermediario entre el Modelo y la Vista. Es responsable de: -
Recibe los eventos de una entrada.
-
Contiene reglas de gestión de eventos.
-
Gestionar flujo de información entre el Modelo y la Vista.
27
-
Gestionar transformaciones para adaptar los datos a las necesidades del Modelo y la Vista.
4.2.2 Procesos clave de negocio (Barros, 1994) Todos los procesos de una organización son importantes, pero no todos tienen el mismo nivel de importancia. Existen dentro de la empresa un tipo de procesos que por su impacto en la consecución de los objetivos estratégicos son más trascendentales que otros. Hay tres tipos de procesos de negocio, procesos estratégicos que dan orientación al negocio como la planificación estratégica; los procesos de apoyo vertical u horizontal que dan soporte a los procesos centrales y por último los procesos clave también llamados procesos sustantivos o de generación de valor los cuales contienen los procesos fundamentales o vitales para alcanzar los objetivos estratégicos de la organización. Estos procesos dan el valor al cliente, son la parte principal del negocio.
4.2.3 Webservice Son una forma estandarizada de integrar aplicaciones WEB. Uno de los usos principales es permitir la comunicación entre empresas y entre empresas y sus clientes. Los Webservice permiten a las organizaciones intercambiar datos sin necesidad de conocer los detalles de sus respectivos sistemas de información. A diferencia de los modelos Cliente/Servidor, tales como un servidor de páginas Web, los Webservice no proveen al usuario una interfaz gráfica (GUI). En vez de ello, los Webservice comparten la lógica del negocio, los datos y los procesos, por medio de una interfaz de programas a través de la red. Es decir conectan programas, por tanto son programas que no interactúan directamente con los usuarios. Los desarrolladores pueden por consiguiente agregar a los Webservice la interfaz para usuarios, por ejemplo mediante una página Web o un programa ejecutable, tal de entregarles a los usuarios una funcionalidad específica que provee un determinado Webservice. (Saffirio, 2006).
28
4.2.4 Pasarela de pagos La pasarela de pago es el servicio de un proveedor de servicios de aplicación de comercio electrónico, con el que se autorizan pagos a negocios electrónicos (en línea), ventas en línea al detalle, que normalmente se comunican mediante webservice con las plataformas que utilizan el servicio. Las pasarelas de pago cifran información sensible, como los números de tarjetas de crédito, para garantizar que la información pasa en forma segura entre el cliente y el vendedor. (Sung, Lee, 2011)
4.2.5 Base de datos no relacional No SQL, que abarca una amplia gama de tecnologías y arquitecturas, busca resolver los problemas de escalabilidad y rendimiento de big data que las bases de datos relacionales no fueron diseñadas para abordar. No SQL es especialmente útil cuando una empresa necesita acceder y analizar grandes cantidades de datos no estructurados o datos que se almacenan de forma remota en varios servidores virtuales en la nube.
4.2.6 Scrum (Schwaber, Sutherland, 2013) Es una metodología de desarrollo ágil que se caracteriza por:
Tener estrategias de desarrollo incremental, en lugar de la planificación y ejecución completa del producto.
Anteponer la calidad del resultado y el conocimiento tácito en equipos auto organizados, que en la calidad de los procesos empleados.
Trabajar las diferentes fases del desarrollo paralelamente, en lugar de realizarlas secuencialmente o en cascada.
29
4.2.6.1 Roles Principales
Product Owner: representa la voz del cliente. Se asegura de que el equipo Scrum trabaje de forma adecuada desde la perspectiva del negocio. El Product Owner escribe historias de usuario, las prioriza, y las coloca en el Product Backlog.
Scrum Master: El Scrum es facilitado por un Scrum Master, cuyo trabajo primario es eliminar los obstáculos que impiden que el equipo alcance el objetivo del sprint. El Scrum Master no es el líder del equipo (porque ellos se auto-organizan), sino que actúa como una protección entre el equipo y cualquier influencia que le distraiga. El Scrum Master se asegura de que el proceso Scrum se utiliza como es debido. El Scrum Master es el que hace que las reglas se cumplan.
Equipo de desarrollo: El equipo tiene la responsabilidad de entregar el producto. Es recomendable un pequeño equipo de 2 a 8 personas con las habilidades transversales necesarias para realizar el trabajo (análisis, diseño, desarrollo, pruebas, documentación, etc.).
4.2.6.2 Sprint Es el período en el cual se lleva a cabo cada ciclo en sí. Es recomendado que la duración de los Sprint sea constante y definida por el equipo con base en su propia experiencia. Se puede comenzar con una duración de sprint en particular (2 o 3 semanas) e ir ajustándolo con base en el ritmo del equipo.
4.2.6.3 Reuniones en Scrum 4.2.6.3.1 Daily Scrum Cada día de un sprint, se realiza la reunión sobre el estado de un proyecto. Esto se llama daily standup o Stand-up meeting. El Scrum tiene unas guías específicas:
30
La reunión comienza puntualmente a su hora.
Todos son bienvenidos, pero sólo los involucrados en el proyecto pueden hablar.
La reunión tiene una duración fija de 15 minutos, de forma independiente del tamaño del equipo.
La reunión debe ser a la misma hora todos los días.
Durante la reunión, cada miembro del equipo contesta a tres preguntas: ¿Qué hice ayer? ¿Qué voy hacer mañana? ¿Has tenido algún problema que te haya impedido alcanzar tu objetivo?
4.2.6.3.2 Reunión de Planificación del Sprint
Al inicio de cada ciclo de Sprint (cada 15 o 30 días), se lleva a cabo una reunión de planificación del Sprint. Se pretende:
Seleccionar qué trabajo se hará.
Preparar, con el equipo completo, el Sprint Backlog que detalla el tiempo que llevará hacer el trabajo.
Identificar y comunicar cuánto del trabajo es probable que se realice durante el actual Sprint.
Realizarse esta planificación en ocho horas como tiempo límite.
Al final del ciclo Sprint se hacen la reunión de revisión del Sprint.
4.2.6.3.3 Reunión de Revisión del Sprint (Sprint Review Meeting)
Revisar el trabajo que fue completado y no completado
Presentar el trabajo completado a los interesados (también conocido como demo)
31
El trabajo incompleto no puede ser demostrado
Cuatro horas como límite
4.2.6.4 Trello Trello es un gestor de tareas que permite el trabajo de forma colaborativa mediante tableros (board) compuestos de columnas (llamadas listas) que representan distintos estados. Se basa en el método Kanban para gestión de proyectos, con tarjetas que viajan por diferentes listas en función de su estado, es ideal para metodologías de desarrollo como Scrum. (Schwaber, Sutherland, 2013)
4.2.6.5 Hipchat Es una aplicación que ofrece servicio de chat y posibilidad de compartir archivos diseñados específicamente para tareas profesionales. Una App idónea para empresas o equipos de trabajo. Que integra más de 70 aplicaciones, entre las que se encuentran las principales herramientas para desarrolladores de software. (Schwaber, Sutherland, 2013)
4.2.7 GitHub GitHub es una plataforma de desarrollo colaborativo de software para alojar proyectos utilizando el sistema de control de versiones Git. Aloja repositorios de código y te brinda herramientas muy útiles para el trabajo en equipo, dentro de un proyecto. (Schwaber, Sutherland, 2013)
4.2.8 Rest La Transferencia de Estado Representacional (Representational State Transfer) o REST es un estilo de arquitectura software para sistemas hipermedia distribuidos como la World Wide Web. El término se originó en el año 2000, en una tesis doctoral sobre la web escrita por Roy Fielding, uno de los principales autores de la especificación del 32
protocolo HTTP y ha pasado a ser ampliamente utilizado por la comunidad de desarrollo. (Schwaber, Sutherland, 2013)
4.2.9 Desarrollo guiado por pruebas (TDD) El Desarrollo Dirigido por Tests (Test Driven Development), más conocido como TDD. Es una práctica de ingeniería de software que involucra otras dos prácticas: Escribir las pruebas primero (Test First Development) y Refactorización (Refactoring,
es una
técnica de la ingeniería de software para reestructurar un código fuente, alterando su estructura interna sin cambiar su comportamiento externo.). Para escribir las pruebas generalmente se utilizan las pruebas unitarias (unit test). TDD es una técnica para diseñar software que se centra en tres pilares fundamentales (Schwaber, Sutherland, 2013):
La implementación de las funciones justas que el cliente necesita y no más.
La minimización del número de defectos que llegan al software en fase de producción.
La producción de software modular, altamente reutilizable y preparado para el cambio.
4.2.10 MD5 MD5 (abreviatura de Message-Digest Algorithm 5, Algoritmo de Resumen del Mensaje 5) es un hash que sirve para ver la integridad del software que fue subido a internet por parte del autor del software. Este hash cada día es más utilizado por varios desarrolladores entre ellos Microsoft y Linux. Esto sirve al momento de entregar una nueva versión del software, el autor genera el hash de MD5 y lo publica, al momento de descargar el software y verifica el MD5 y si es idéntico, entonces el software es el original y el que subió el autor. (Redes Zone)
33
4.2.11 3DES Fue emitido por el NIST en 1999 como una versión mejorada de DES. Realiza tres veces el cifrado DES utilizando tres claves. Cuando se descubrió que una clave de 56 bits (utilizada en el DES) no era suficiente para evitar un ataque de fuerza bruta, el 3DES fue elegido para agrandar la clave sin la necesidad de cambiar el algoritmo de cifrado. Con tres claves distintas, 3DES tiene una longitud de clave efectiva de 168 bits aunque también se pueden usar dos claves haciendo K1=K3 (ver figura 4.1.16) con lo que se tiene una longitud de clave efectiva de 112 bits Actualmente el 3DES sigue siendo utilizado pero cada vez más está siendo sustituido por el algoritmo AES que ha demostrado ser muy robusto y más rápido. (UNAM)
34
5. RESULTADOS
Aplicando la metodología de desarrollo Scrum, aplicando conceptos como el desarrollo basado en pruebas y se logró realizar un prototipo de software que satisface los objetivos planteados en el inicio del proyecto. El resultado de la ejecución del proceso de desarrollo del prototipo de software que se llevó a cabo está descrito a continuación. Para poder ver la plataforma se puede ingresar al link www.conexionbienestar.com y explorar los resultados obtenidos de la página para los usuarios, para la parte de gestor de contenidos es necesario tener un usuario y contraseñas de administrador otorgados por los directivos de la fundación.
5.1 DESARROLLO DE LA FASE DE PLANEACIÓN En la fase de planeación se especificaron los requerimientos del proyecto, se definió la metodología para desarrollar el proyecto, se decidió la arquitectura que tendría el proyecto y que se acoplara a las necesidades del mismo, se establecieron las actividades necesarias para el desarrollo del proyecto y por último se establecieron responsables y duración para cada actividad.
5.1.1 Requerimientos En esta fase se siguieron varios pasos que en conjunto retornaron los requerimientos y su importancia en el proyecto, estos pasos definen los siguientes aspectos:
Necesidades
Actores del proyecto
Requerimientos
Historias de usuario
35
5.1.1.1 Definición de Necesidades
Para este paso se realizó la Tabla 1 en donde se puso en evidencia todas las necesidades que el cliente mostro a la hora de realizar su solicitud. Tabla 1. Necesidades del proyecto. ID N1 N2 N3 N4 N5 N6 N7 N8 N9 N10 N11 N12 N13 N14 N15 N16 N17 N18 N19 N20 N21 N22 N23
NECESIDAD La página solo la podrán editar los usuarios registrados en la base de datos. Existirán 3 tipos de usuarios, usuario administrador el cual es único, usuario colaborador el cual solo podrá editar contenido sin publicarlo y usuario colaborador administrador el cual tendrá las mismas funciones que el administrador principal a excepción de la administración de usuarios. El administrador podrá agregar, editar o eliminar datos de los usuarios entre los que está el nombre, nickname, contraseña y rol. El administrador podrá editar sus datos como el nombre de usuario y la contraseña. Adaptar la interfaz al diseño otorgado por el especialista de la fundación. Se podrá agregar, editar o eliminar menús y submenus a la barra de menús de la página sin que se altere el diseño de la misma. Cada menú podrá desplegar o no, una lista de submenús. Se debe poder escoger el color del menú al momento de la edición. Cada menú o submenú podrá redirigir a una página interna o externa a la página web. Se podrá editar el orden en el que aparecerán los menús principales en la barra de menús. Se podrá agregar. Editar o eliminar elementos al carrusel de la página principal de la página sin que esto afecte el diseño de la plataforma. En la edición de cada elemento del carrusel se podrá editar, título, descripción, enlace interno, imagen. El administrador podrá decidir cuáles son públicos. Publicaciones divididas en 4 categorías, salud física, salud espiritual, salud emocional y sin categoría. Cada una de las categorías tendrán un color representativo, salud física color verde, salud espiritual color morado, salud emocional color azul y las que son sin categoría sin color. Se debe poder editar cada publicación y subirle videos, imágenes, enlaces, categoría y contenido con fuente editable. Las publicaciones tienen que ser aprobadas por un único administrador, los usuarios colaboradores solo podrán crear la publicación y guardarla para ser publicada por el administrador. Se podrán editar publicaciones existentes Se podrán eliminar publicaciones existentes, únicamente por el administrador. La plataforma se tiene que conectar con la pasarela de pagos contratada por la fundación, en la que podrá recibir las donaciones concernientes a dinero. El sistema de donación constará de dos modalidades, donación mixta o donación por estrellas, La donación por estrellas son montos de $30.000 por estrella, el donante decide la cantidad. La donación mixta consta de 3 opciones, donación en dinero la cual se conecta a la pasarela de pagos para ser recibida, donación en especie y donación en tiempo para colaboración a la fundación. Estas opciones quedan guardadas en la base de datos.
36
N24 N25 N26 N27 N28 N29
Cuando son donaciones que no contienen dinero, estas son enviadas al correo
[email protected] en donde se pondrán en contacto con el donante. Se podrán agregar enlaces del canal de YouTube de la fundación para mostrar en una vista los videos publicados, Estos enlaces podrán ser editados y eliminados. En la vista de videos se mostrará desde el video más reciente al más antiguo. El usuario que entre a la página podrá interactuar con todo el contenido publicado desde el gestor de contenido. Es necesario un control de errores para que éstos no se presenten en la etapa de producción de la plataforma, ya que esta es inicialmente el principal ente de comunicación con las personas interesadas en la fundación.
Fuente. Autores 5.1.1.2 Definición de Actores del Proyecto En esta parte se contemplaron los actores que participan en la plataforma, se obtuvo lo mostrado en la Tabla 2. Tabla 2. Actores del Proyecto. ID
ACTOR
A1
Administrador
A3
Colaborador Administrador Colaborador
A4
Visitante
A5
Desarrollador
A2
DESCRIPCIÓN Es el principal usuario para el gestor de contenido de la plataforma, es el que autoriza todo el contenido y los usuarios existentes. Este actor puede administrar las publicaciones de la plataforma pero no los usuarios. Este actor puede editar contenido de la plataforma pero no publicarlo. Este actor es el que entra a la plataforma para ver el contenido que ofrece la fundación para guiarse en algún tema, espiritual, emocional o físico. Además podrá realizar donaciones a la fundación y contactarse con los responsables del proyecto. Este actor es temporal, el cual se encarga del desarrollo de la plataforma y el gestor de contenido.
Fuente. Autores
5.1.1.3 Requerimientos Para esta parte se unieron las necesidades relacionadas entre sí y se obtuvo la Tabla 3. Tabla 3. Requerimientos del software. ID
R1
REQUERIMIENTO
Persistencia de datos
NECESIDADES ASOCIADAS N1 - N2 - N3 - N4 - N6 N7 - N8 - N9 - N10 - N11 - N12 - N13 - N14 - N15 N16 - N17 - N18 - N19 N25 - N26 - N27 - N28 N29
DESCRIPCIÓN El sistema contará con un modelo de base de datos que represente todas las entidades participantes en el gestor de contenido y la plataforma web.
37
R2
Gestión de usuarios
N1 - N2 - N3 N4 - N5
R3
Gestión de Menú
N1 - N5 - N6 - N7 - N8 N9 - N10 - N28
R4
Gestión de Carrusel
N1 - N5 - N11 N12 - N13 - N28
R5
Gestión de publicaciones
N1 - N5 - N14 - N15 N16 - N17 - N18 - N19 N28
R6
Donación de estrellas
N5 - N20 N21 - N22 - N28
R7
Donación Mixta
N5 - N20 - N21 - N23 N24 - N28
R8
Gestión de Videos
N1 - N5 - N25 - N26 N27 - N28
R9
Control de errores
N29
El gestor de contenido tendrá un solo administrador con permisos totales de creación de usuarios y aceptación de publicaciones. Contará con usuarios colaboradores que solo podrán generar publicaciones a la espera de ser aprobados y colaboradores administradores que tendrán las mismas funciones del administrador principal a excepción de la gestión de usuarios. El sistema contará con la opción de gestionar los menús y submenus que aparecerán en la barra superior de la página; cada uno de estos contará con la opción de redirigir a una página interna o externa. Los menús tendrán un color asociado el cual será modificable. La cantidad de menús principales no interferir con el diseño de la plataforma. Se podrá gestionar las publicaciones recientes que muestra el carrusel, en las que podrá incluir su imagen, descripción y posible redirección. El sistema contará con la opción de publicar contenido nuevo que se adapte al diseño y además se muestre en las publicaciones recientes en la página inicial. La plataforma se conectará con la pasarela de pagos contratada por la fundación para poder recibir las donaciones de dinero. La plataforma contará con la opción de donar especies o tiempo y guardará esta información en la base de datos y además enviará un correo con estos datos para informar a la directiva de la fundación y éstos se pongan en contacto con el donante. Si la donación es en dinero, la plataforma deberá conectarse con la pasarela de pagos para que se encarguen de la donación. El sistema contará con la opción de publicar los videos del canal de YouTube de la fundación en una vista acoplada al diseño de la plataforma. Se deberá diseñar un módulo de pruebas el cual asegurará que no existan errores en la etapa de producción.
Fuente. Autores
38
5.1.1.4 Historias de Usuario A partir de los requerimientos obtenidos se generaron historias de usuario que especifican los requerimientos principales del cliente en donde se evidencian las características principales necesarias para el desarrollo del gestor y la plataforma. Tabla 4. Historias de Usuario ID HU0 HU1 HU2 HU3 HU4 HU5 HU6 HU7
HISTORIAS DE USUARIO Autenticación de usuarios Gestión de usuarios Gestión de Menú Gestión de Carrusel Gestión de Publicaciones Gestión de Videos Donaciones Interacción con la plataforma
Fuente. Autores
5.1.1.5 Especificación de Historias de Usuario A continuación se detallan las historias de usuarios mencionadas en la tabla 4 para tener claridad sobre dicho procedimiento. Cuando se habla de usuarios en las historias, existen 4 tipos, usuario administrador, usuario colaborador administrador, usuario coalborador y usuario visitante. Cuando se menciona usuario gestionador hace referencia a los usuarios administrador, administrador colaborador y colaborador.
5.1.1.5.1 HU0 - Autenticación de usuarios Tabla 5. HU0 ID FECHA DESCRIPCIÓN DE LA HISTORIA
AUTENTICACIÓN DE USUARIOS HU0 20 de Diciembre de 2015 Como usuario administrador o colaborador deseo poder ingresar al gestor de contenido con mi usuario y contraseña. Como usuario administrador o colaborador deseo poder ver el menú administrador del gestor de contenido con las opciones de gestionar menú, slider, publicaciones, videos y usuario propio.
39
Como usuario administrador deseo poder ver la opción de gestionar los demás usuarios. Como usuario gestionador deseo poder recuperar mi contraseña cuando no la recuerdo. El enlace a la autenticación irá en el pie de página de la plataforma. ANOTACIONES
El ingreso de los datos serán mediante una ventana emergente. La contraseña se puede recuperar con el nickname o el correo registrado en la base de datos.
Fuente. Autores
5.1.1.5.2 HU1 - Gestión de usuarios Tabla 6. HU1 ID FECHA
GESTIÓN DE USUARIOS HU0 20 de Diciembre de 2015 Como usuario administrador deseo ser el único usuario que puede gestionar los usuario colaborador y colaborador administrador. Como usuario administrador deseo poder ver la lista de usuarios creados en la base de datos. Como usuario administrador deseo poder crear nuevos usuarios colaboradores y colaboradores administradores.
DESCRIPCIÓN DE LA HISTORIA
Como usuario administrador deso poder editar los datos de los usuarios existentes. Como usuario administrador deseo poder eliminar usuarios existentes. Como usuario gestionador deseo poder editar mis datos de usuario, incluyendo mi contraseña.
ANOTACIONES
Como usuario gestionador deseo poder eliminar mi usuario del gestor de contenido. El único usuario que no se puede eliminar es el usuario administrador.
Fuente. Autores
40
5.1.1.5.3 HU2 - Gestión de menú Tabla 7. HU2 GESTIÓN DE MENÚ ID FECHA
DESCRIPCIÓN DE LA HISTORIA
HU2 20 de Diciembre de 2015 Como usuario gestionador deseo poder ver la lista de los menús creados para la barra de menú principal. Como usuario gestionador deseo poder agregar un nuevo menú con submenús, enlaces, color, título y posición; a la base de datos. Como usuario gestionador deseo poder editar los menús existentes.
ANOTACIONES
Como usuario gestionador deseo poder eliminar los menús existentes. Cada menú creado debe aparecer en la barra de menú principal sin dañar el diseño de la plataforma.
Fuente. Autores
5.1.1.5.4 HU3 - Gestión de carrusel Tabla 8. HU3 ID FECHA
GESTIÓN DE CARRUSEL HU3 20 de Diciembre de 2015 Como usuario gestionador deseo poder ver la lista de los slider creados para publicar en el carrusel de la página principal. Como usuario gestionador deseo poder agregar un nuevo slider con título, descripción, imagen y enlace; a la base de datos.
DESCRIPCIÓN DE LA HISTORIA
Como usuario gestionador deseo poder editar los slider existentes. Como usuario gestionador deseo poder eliminar los slider existentes.
ANOTACIONES
Como usuario administrador o colaborador administrador, deseo poder publicar o nó los slider creados en la base de datos. Los slider publicados en la página inicial deben aparecer en orden descendente según la facha de edición.
Fuente. Autores
41
5.1.1.5.5 HU4 - Gestión de publicaciones Tabla 9. HU4 ID FECHA
DESCRIPCIÓN DE LA HISTORIA
GESTIÓN DE PUBLICACIONES HU4 20 de Diciembre de 2015 Como usuario gestionador deseo poder ver la lista de las publicaciones creadas. Como usuario gestionador deseo poder agregar una nueva publicación con título, nombre de enlace, descripción, imagen, categoría, video y contenido; a la base de datos. Como usuario gestionador deseo poder editar las publicaciones existentes. Como usuario gestionador deseo poder eliminar las publicaciones existentes. Como usuario administrador o colaborador administrador, deseo poder publicar o nó las publicaciones creadas en la base de datos. Agregar o editar publicaciones deben ir en una vista aparte, ya que contienen más datos que los demás elementos de la plataforma.
ANOTACIONES
El campo de contenido de las publicaciones, debe tener la opción de agregar diferentes contenidos como imágenes, enlaces, videos, emoticones, tablas y cambiar color, tipo y tamaño de letra.
Fuente. Autores
5.1.1.5.6 CU5 - Gestión de videos Tabla 10. HU5 ID FECHA
DESCRIPCIÓN DE LA HISTORIA
GESTIÓN DE VIDEOS HU5 20 de Diciembre de 2015 Como usuario gestionador deseo poder ver la lista de los videos creados para la vista que muestre los videos del canal de YouTube de la fundación. Como usuario gestionador deseo poder agregar un nuevo video con título, enlace de youtube y descripción video; a la base de datos. Como usuario gestionador deseo poder editar los videos existentes.
ANOTACIONES
Como usuario gestionador deseo poder eliminar los videos existentes. El enlace de los videos debe ser el id otorgado por YouTube a los videos.
Fuente. Autores
42
5.1.1.5.7 CU6 – Donaciones Tabla 11. HU6 DONACIONES ID FECHA
HU6 20 de Diciembre de 2015 Como usuario visitante deseo poder encontrar dieferentes accesos para las donaciones. Como usuario visitante deseo poder donar estrella mensuales equivalentes a 30000 cada una.
DESCRIPCIÓN DE LA HISTORIA
Como usuario visitante deseo poder ver la cantidad equivalente en dinero de las estrellas que quiero donar. Como usuario visitante deseo poder donar diferentes cantidades de dinero por una sola vez. Como usuario visitante deseo poder donar tiempo como voluntario.
ANOTACIONES
Como usuario visitante deso poder donar materiales u otros elementos útiles para la fundación. La donación no se hace directamente desde la plataforma, ésta solo se conecta con la pasarela de pagos Mobile Card.
Fuente. Autores
5.1.1.5.8 HU7 - Interacción con la plataforma Tabla 12. HU7 ID FECHA
HU 20 de Diciembre de 2015 Como usuario visitante deseo poder ver las publicaciones creadas y publicadas desde la base de datos con el diseño de la plataforma. Como usuario visitante deseo poder realizar busquedas sobre el contenido de las publicaciones.
DESCRIPCIÓN DE LA HISTORIA
Como usuario visitante deseo poder compartir en redes sociales las publicaciones que veo en la plataforma. Como usuario visitante deseo poder contactarme con los administradores de la fundación.
ANOTACIONES
Como usuario visitante deseo poder ver los términos y condiciones de la fundación. Toda la plataforma se adecua a los diseños otorgados por el cliente.
Fuente. Autores
43
5.1.2 Arquitectura Como se mencionó anteriormente la arquitectura que se manejó en el proyecto es la Arquitectura Modelo Vista Controlador MVC, la cual es la que usa NodeJS que es el lenguaje de programación en el que se desarrolló el proyecto. Esta arquitectura define independientemente el Modelo la Vista y el Controlador, lo que facilita la encapsulación de los datos, la interfaz y la lógica del negocio. En la Figura 1 se puede ver la arquitectura general manejada en el proyecto ya desarrollado: Figura 1. Arquitectura general del proyecto
Fuente. Autores Aquí se evidencian las siguientes carpetas concernientes a la arquitectura MVC: -
Models → Modelos, datos
-
Views → Vistas, interfaz
-
Routes → Controladores, lógica del negocio
En la figura 2 se muestra el diagrama arquitectural del proyecto. Aquí se ve mas claro la división de los componentes del proyecto y su clasificación.
44
Figura 2. Diseño Arquitectural del proyecto
Fuente. Autores 45
5.1.3 Metodología de desarrollo La metodología implementada fue la Metodología SCRUM, la cual tiene varias etapas, planificación de iteraciones, ejecución de iteraciones, inspección y adaptaciones. 5.1.3.1 Planificación de iteraciones , para la planificación de las iteraciones se tuvo en cuenta los siguientes aspectos:
El usuario directo fue la directora de desarrollo de la fundación Milena Siachoque quien actuó como cliente adaptándose a la tabla de requerimientos ya establecida. (Ver Tabla 3. Requerimientos de Software).
El papel de Scrum Master también fue desempeñado por la directora de desarrollo Milena Siachoque.
Se escogió esta metodología por el poco tiempo disponible para la entrega de la plataforma, y así evitar que los requerimientos adicionales atrasen la entrega del mismo.
Se usó la herramienta on-line Trello, la cual permite ver 5 tableros, un ejemplo del mismo se muestra en la Figura 3, en donde se muestra las diferentes actividades planteadas en cada iteración del proyecto. Figura 3. Tableros de funcionamiento de Trello
Fuente. Autores
46
Como se evidencia en la Figura 3, cada proyecto de Trello consta de los siguientes tableros:
Backlog → Contiene las actividades por realizar pendientes, son agregadas por el Scrum Master en común acuerdo con los requerimientos planteados.
To Do → Contiene las actividades a realizar en cada iteración, son agregadas por el Scrum Master en común acuerdo con los desarrolladores, quienes plantean sus propias metas y responsabilidades.
Doing → Contiene las actividades de la iteración que se están desarrollando en el momento por cada desarrollador, son puestas por cada desarrollador.
QA → Contiene las actividades de la iteración finalizadas por cada desarrollador, son puestas por el desarrollador o desarrolladores que trabajaron en la actividad.
Done → Contiene las actividades de la iteración finalizadas que ya fueron revisadas y aprobadas por el Scrum Master. Luego de esto los desarrolladores subían los cambios de desarrollo al repositorio de la fundación en GitHub.
5.1.3.2 Ejecución de iteraciones Esta fase se realizó haciendo uso de la herramienta Hipchat, en donde se creó un grupo en común con los desarrolladores y el Scrum Master. La Figura 4 muestra un ejemplo de cómo se usó la herramienta. Figura 4. Ejemplo de uso de Hipchat
Fuente. Autores Se puede ver que el encabezado del mensaje es Daily, lo que quiere decir que es diario, y se contestan las siguientes preguntas: ¿Qué hice hoy? - ¿Qué voy a hacer mañana? ¿Qué problemas tuve?
47
5.1.3.3 Inspección y Adaptación Esta fase de la metodología se realizó de forma presencial en la oficina de trabajo de la Scrum Master Milena Siachoque en instalaciones de CODETAG. Se realizó al finalizar cada iteración la cual constaba de 2 semanas o más. En esta fase como ya se sabe se hicieron las retrospectivas de cada iteración y la asignación de actividades para las siguientes iteraciones. Una vez aprobada la iteración se subían los cambios realizados a la herramienta GitHub, la cual permitía controlar estos cambios.
5.1.4 Iteraciones Como ya se mencionó se definieron iteraciones basadas en los requerimientos definidos en la Tabla 3. Requerimientos de Software, a las que se les asignaron diferentes actividades, responsables y duración para su finalización. En las Figuras 5 a 11 se muestra lo aquí mencionado. Figura 5. Iteraciones y actividades
Fuente. Autores
48
Figura 6. Actividades Diseño de pruebas y diseño de interfaz
Fuente. Autores Figura 7. Actividades persistencia de datos y gestión de usuarios
Fuente. Autores
49
Figura 8. Actividades de gestión de menú, carrusel y publicaciones
Fuente. Autores Figura 9. Actividades de gestión de videos y donación de estrellas
Fuente. Autores
50
Figura 10. Actividades de donación mixta y gestión de búsqueda
Fuente. Autores Figura 11. Actividades de gestión de contacto, refactorización y pruebas
Fuente. Autores
51
5.2 DISEÑO Y DESARROLLO DE PRUEBAS UNITARIAS Como se nombra en la teoría, la importancia del desarrollo basado en pruebas no es superficial, ya que éste método permite que se sigan todos los requerimientos dados por el cliente y poder darle lo que quiere sin recurrir a realizar operaciones innecesarias para el desarrollo del proyecto. Al realizar estas pruebas se buscó que el desarrollo del proyecto se adecuara a las necesidades del usuario, minimizara la cantidad de errores o defectos de la plataforma, a la hora de la producción y por último pero no menos importante hacer del software un programa modular, reutilizable y flexible. Para este proyecto se planteó el desarrollo de las pruebas en su totalidad e ir desarrollando el proyecto para que cada una de las pruebas pase la evaluación y finalizar con una refactorización del código. Con esto se generaron los siguientes pasos para el desarrollo de las pruebas unitarias:
Definir las pruebas a desarrollar
Desarrollar cada una de las pruebas definidas y comprobar que cada una de las pruebas no pase su evaluación inicial
Desarrollo del proyecto para que las pruebas pasen la evaluación.
Refactorización.
5.2.1 Diseño de pruebas unitarias Para definir las pruebas unitarias a realizar, se hizo un consenso con los requerimientos del proyecto y se unieron en 6 grupos para generalizar todas las relaciones comunes. El resultado es el mostrado en la tabla 13. En el Anexo B se muestra un ejemplo del desarrollo de éstas pruebas. Tabla 13. Grupos definidos de las pruebas unitarias. ID
NOMBRE Pruebas unitarias de GP1 usuario Pruebas unitarias de GP2 menú
DESCRIPCIÓN Pruebas relacionadas a la creación, edición, eliminación y autenticación de usuarios para la administración del contenido de la plataforma. Pruebas relacionadas a la creación, edición, eliminación y ubicación en la interfaz de los menús y submenús.
52
Pruebas unitarias de publicación Pruebas unitarias de GP4 carrusel Pruebas unitarias de GP5 colaborador Pruebas unitarias de GP6 video GP3
Pruebas relacionadas a la creación, edición, eliminación y ubicación en la interfaz de las publicaciones. Pruebas relacionadas a la creación, edición, eliminación y ubicación en la interfaz de las publicaciones del carrusel. Pruebas relacionadas a la creación, edición, eliminación y ubicación en la interfaz de los datos de los donantes. Pruebas relacionadas a la creación, edición, eliminación y ubicación en la interfaz de los videos del canal de YouTube de la fundación.
Fuente. Autores 5.2.2 Desarrollo de pruebas unitarias Las pruebas unitarias se desarrollaron de tal manera que suplieran las necesidades planteadas por el usuario. En las figuras 12 a 23 se muestra la ejecución de las pruebas sin que éstas pasen, ya que se desarrollaron las pruebas unitarias antes del desarrollo del proyecto. En la figura 12 se evidencia la ejecución de las pruebas desarrolladas para crear, leer, modificar y eliminar usuarios y menús. Figura 12. Pruebas unitarias de usuario y menú
Fuente. Autores En la figura 13 se evidencia la ejecución de las pruebas desarrolladas para crear, leer, modificar y eliminar slider, páginas y videos y las pruebas para el envío de donaciones. También se evidencia el número de pruebas que no pasaron.
53
Figura 13. Pruebas unitarias de Carrusel, Publicaciones, videos y donación
Fuente. Autores 5.2.3 Aclaraciones de las siguientes fases de pruebas Las siguientes fases del desarrollo de pruebas se muestran en capítulos adelanta, ya que es necesario mostrar los resultados obtenidos con estos procesos, para poder mostrar que se realizaron.
El desarrollo del proyecto se muestra en los subcapítulos del 5.3 al 5.12.
La fase de culminación se hizo al finalizar el desarrollo y comprende la comprobación de que las pruebas pasaron y la refactorización del código. Para ver la ejecución en consola de estas pruebas ver Anexo B.
54
5.3 DESARROLLO DE INTERFAZ GRÁFICA Como inicio de la plataforma se comenzó por tener un croquis de lo que iba a ser la plataforma según los requerimientos del cliente; para esto se generaron unos mockups que sirvieron como base para el desarrollo de la interfaz gráfica, antes de obtener los diseños. (Ver Anexo A). La tabla 14 muestra la descripción de los mockups diseñados que fueron la base para el inicio del desarrollo gráfico. Estos mockups se realizaron con la herramienta para mockups “Balsamiq Mockups” que facilitó el diseño de los mismos ya que brinda opciones intuitivas que agilizan la producción de dichas maquetas. En resumen ayuda a brindar una primera impresión de lo que será la plataforma, no solo para el cliente sino también para que el desarrollador tenga su base inicial. Tabla 14. Descripción de mockups ID
NOMBRE
M1
Página inicial
M2
Publicaciones
M3
Autenticación
M4
Crear Usuario
M5
Edición de Menú
M6
Lista de publicaciones
M7
Publicación nueva
DESCRIPCIÓN Mockup que describe la página inicial de la plataforma, en donde se mostrará un menú principal en donde aparecerá además el logo de la fundación, un carrusel de imágenes, secciones de contenido a los que se les llamará cards y un pie de página. Mockup que describe la estructura de lo que será la apariencia de las publicaciones realizadas por los administradores, éstas contendrán, título, subtítulo, imagen y texto. Mockup que describe la estructura de la vista de autenticación para los usuarios administradores al ingresar al gestor de contenido. Este pedirá un usuario y una contraseña. Mockup que muestra el formulario para la creación de un nuevo usuario desde el gestor de contenido en donde se muestra el nombre, usuario, correo electrónico, contraseña y confirmación de contraseña. Mockup que describe la estructura de la edición del contenido del menú principal en donde se muestra que se pueden agregar menús y cada menú contiene submenús que también se podrán editar. Los que tendrán una url que re direccionará al menú o submenú. Mockup que describe la vista en donde se muestran las publicaciones creadas en donde se observa que dará la opción de editar, eliminar o publicar, y mostrará en un resumen de cada publicación el título, el usuario creador y la fecha y hora de creación. Mockup que describe el formulario en el que se solicitan los datos para crear o editar una publicación, los datos solicitados son enlace, título, contenido (un editor de contenido html), descripción y las opciones de guardar sin publicar o publicar directamente.
Fuente. Autores
55
5.3.1 Diseños Para el diseño de la plataforma se tomó como base los diseños otorgados por el diseñador de la fundación quien entregó las plantillas necesarias para poder desarrollar lo concerniente a las vistas de interacción con los usuarios del cliente. Estas plantillas son mencionadas y explicadas en la tabla 15, para el diseño del gestor de contenido el cliente no entregó un diseño, pero se desarrolló de tal forma que concordaran con el diseño y los colores de la plataforma. Tabla 15. Explicación diseños de la fundación ID
NOMBRE
D1
Página inicial
D2
Barra de menú
D4
Menú desplegable Logo metálico
D5
Menú lateral
D6
Publicaciones
D7
Resultados de búsqueda
D8
Contacto
D9
Donación de estrellas
D3
D10 Donación mixta
DESCRIPCIÓN Este diseño muestra la página principal de la plataforma, la cual evidencia un carrusel, cards de publicaciones, menú principal, menú lateral y pie de página. Aquí se evidencia el menú principal el cual contendrá submenus que se desplegarán, se muestra también que cada menú tendrá su propio color. Aquí se ve un ejemplo de cómo quieren que se vean los menús desplegables. Logo opcional Aquí se evidencia la posible apariencia y forma de cómo se desplegará el menú lateral. Esta es la apariencia que tendrán todas las publicaciones agregadas por los administradores. Esta es la página que se mostrará en los resultados de las búsquedas realizadas por los usuarios de la plataforma. Esta es la vista que aparecerá para que los usuarios envíen correos de contacto con los directivos de la fundación. Vista que muestra la donación de estrellas, concepto generado por la fundación. Vista de donación en especies, tiempo y cualquier cantidad de dinero.
FIGURA 21 22 23 24 25 26 27 28 29 30
Fuente. Autores En el Anexo C se muestran los diseños otorgados por la fundación para el desarrollo de la interfaz.
56
5.3.2 Plataforma de usuarios
La figura 14 muestra la apariencia actual de la página, la cual se adaptó al diseño otorgado por la fundación y al contenido que tienen hasta el momento. No se ve el carrusel ya que no han publicado contenido para mostrar en dicho contenido, esto se explica en el capítulo de la gestión de carrusel. El botón ingresar fue eliminado ya que por el momento solo se contempla el ingreso de usuarios administradores y el acceso de éste quedó en el pie de página de la plataforma, en su lugar quedó un botón de acceso directo a la donación. El menú lateral quedó con las opciones solicitadas por el usuario, búsqueda, redes sociales y SOS (donación mixta). En los cards se descartaron los colores de las categorías, ya que se acordó que esto no era agradable para la vista del usuario, se añadieron dos cards estáticas que muestran el video que explica qué es la fundación y otro acceso directo a la donación de estrellas. El pie de página quedó con las opciones solicitadas por el usuario sin contener el acceso a la inscripción a newsletter ya que no contrataron éste servicio. La parte del menú principal y su gestión, las publicaciones, videos, donación de estrellas y mixta, autenticación y carrusel se explicarán en los siguientes subcapítulos de los resultados y se podrá ver la apariencia de cada uno. Para el desarrollo de la interfaz gráfica se usaron los siguientes recursos: -
JavaScript
-
Jquery
-
Bootstrap
-
Jade
-
CSS
-
Stylus
Es importante mencionar que a lo largo de los siguientes subcapítulos se podrá evidenciar que no se siguió al pie de la letra los diseños, esto no es porque no se haya logrado sino porque en el transcurso del desarrollo se fueron cambiando detalles los cuales se fueron corrigiendo a petición del cliente; todo esto porque lo permite el
57
desarrollo usando la metodología SCRUM. Pero no cambió la lógica principal mencionada en la fase de planeación. Figura 14. Página inicial desarrollada
Fuente. Autores
58
5.4 DESARROLLO DE LA PERSISTENCIA DE DATOS Para la persistencia de datos se usó MongoDB, la cual maneja bases de datos no relacionales, las cuales son muy útiles para este tipo de proyectos en los que hay modelos que no tienen relación con otros. Para comenzar se aclaró los modelos que tocaba diseñar para la base de datos y se obtuvo lo mostrado en la tabla 16. Tabla 16. Descripción de modelos de la BD ID
NOMBRE
M1
USER
M2
MENU
M3
PAGINA
M4
SLIDER
M5
COLABORADORES
M6
VIDEO
DESCRIPCIÓN Modelo que representa a los usuarios administradores del gestor de contenido. Modelo que representa los menús y submenús que se muestran en la barra de menú principal. Modelo que representa las publicaciones hechas por los administradores de la plataforma. Modelo que representa las imágenes y sus características de las publicaciones del carrusel. Modelo que representa los datos de los donantes. Modelo que representa los videos publicados en la sección videos de la plataforma.
Fuente. Autores El diagrama mostrado en figura 15 describe todos los modelos de la base de datos.
59
Figura 15. Diagrama BD
Fuente. Autores
60
5.4.1 Usuario Este modelo representa los usuarios administradores del gestor de contenido, entre estos existen tres tipos de usuarios, administrador, colaborador administrador y colaborador. En el Anexo B se muestra la estructura del esquema desarrollado en el código para el modelo. La tabla 17 explica cada uno de los datos del modelo usuario. Tabla 17. Datos de modelo Usuario No. NOMBRE 1 2 3 4 5
6
7
DESCRIPCIÓN Este dato no aparece en el esquema, ya que es obligatorio y siempre es asignado Id automáticamente por MongoDB. Nombre Nombre(s) del usuario. Apellido Apellidos del usuario. Nombre del usuario con el que se autenticará en la plataforma para acceder al gestor Nickname de contenido. Password que ingresará junto con el nickname para autenticarse en la plataforma para Contraseña acceder al gestor de contenido. Dato que distingue al tipo de usuario para así mismo acceder a sus opciones de administrador dependiendo de su rol. Si el rol es “Administrador” el usuario tendrá acceso total al gestor de contenido este usuario es único, si el rol es “Colaborador Rol administrador” el usuario podrá gestionar todos los contenidos y autorizarlos, a excepción de la gestión de usuarios; si el rol es “Colaborador” el usuario podrá gestionar contenido sin publicarlo. Correo Email de contacto del usuario.
Fuente. Autores 5.4.2 Menú Modelo que representa el contenido del menú principal el cual contiene los enlaces de redirección y sus submenús si es necesario. Estos menús solo se muestran en la parte superior de la plataforma, en todas las vistas, cada menú o submenú redirecciona a un enlace interno o externo a la plataforma. En el Anexo B. se muestra la estructura del esquema desarrollado en el código para el modelo. La tabla 18 explica cada uno de los datos del modelo menú. Tabla 18. Datos de modelo Menú No.
NOMBRE
1
Id
2
Posición
3
Color
4
Título
DESCRIPCIÓN Este dato no aparece en el esquema, ya que es obligatorio y siempre es asignado automáticamente por MongoDB. Este dato es el que indica la posición en la que aparecerá en la barra superior dicho menú. Este dato es dado en caracteres alfanuméricos que indican un color HTML, este color es el de la barra que aparece sobre el nombre de cada menú y el color de fondo de los submenús desplegados si los posee. Nombre que aparecerá en la barra superior.
61
5
Url Interna
6
Url Externa
7 8
9
Enlace de las publicaciones de la plataforma, este campo no puede existir si ya se llenó el campo de UrlExterna o si el menú contiene al menos un submenú. Enlace de páginas externas de la plataforma con la estructura http://www.ejemplo.com el cual no puede existir si se llenó el campo UrlInterna o si el menú contiene al menos un submenú.
User Es el nickname del último usuario que modificó el menú. Modificacion Fecha Fecha en la que se creó el menú. Creación Este dato es un array que puede ser nulo y no tiene límite en su tamaño, cada uno contiene los datos mostrados a continuación: No. NOMBRE DESCRIPCIÓN Nombre del submenú que aparecerá en el menú 9.1 Titulo desplegable. Submenus Enlace de publicaciones de la plataforma a la 9.2 UrlInterna que redireccionará el submenú. Este campo no puede estar lleno si UrlExterna ya se llenó. Enlace externo a la plataforma con el formato 9.3 UrlExterna http://www.ejemplo.com y no puede estar lleno si UrlInterna ya se llenó.
Fuente. Autores 5.4.3 Página Modelo que representa a cada una de las publicaciones en la plataforma, cada uno de sus campos puede ser editado por todos los usuarios a excepción de los publicados, estas publicaciones son las que contienen la información esencial de la plataforma que es la que va a traer visitantes. En el Anexo B. se muestra la estructura del esquema desarrollado en el código para el modelo. La tabla 19 explica cada uno de los datos del modelo página. Tabla 19. Datos de modelo Página No.
NOMBRE
1
Id
2
Nombre Enlace
3 4 5
Título Descripción Contenido
6
Publicar
7
Fecha Creación
8
Categoría
9
User Modificación
10
Id Video
11
Link Imagen
DESCRIPCIÓN Este dato no aparece en el esquema, ya que es obligatorio y siempre es asignado automáticamente por MongoDB. Este es el nombre del enlace al que se redireccionará la publicación, el que aparece en la barra de navegación. Nombre de la publicación. Descripción breve de lo que contiene la publicación. Contenido de la publicación, información, imágenes, videos, enlaces, etc. Estado de publicación de la página, si es TRUE entonces la página aparece publicada, si es FALSE la página solo será vista en el gestor de contenido. Fecha en la que se creó la publicación. Este campo clasifica la publicación en 4 tipos: Emocional, Espiritual, Físico y Sin Categoría. Último usuario que modificó la publicación. Id de YouTube del video que se muestra en la descripción de la publicación si es que lo tiene. Link donde se encuentra la imagen a subir de la descripción de la publicación.
62
12
Solo Registrados
Este campo es para mostrar solo a usuarios registrados o no.
Fuente. Autores 5.4.4 Slider Modelo que representa cada una de las imágenes que se publican en el carrusel que aparece en la página principal de la plataforma. En el Anexo B. se muestra la estructura del esquema desarrollado en el código para el modelo. La tabla 20 explica cada uno de los datos del modelo slider. Tabla 20. Datos de modelo Slider No.
NOMBRE
1
Id
2 3 4 5
Título Enlace Descripción Link Imagen Fecha Creación
6 7
Publicado
DESCRIPCIÓN Este dato no aparece en el esquema, ya que es obligatorio y siempre es asignado automáticamente por MongoDB. Nombre de la imagen Enlace interno al que redireccionará la imagen. Descripción de la imagen o la publicación a la que redireccionará. Enlace en donde se guardará la imagen de la publicación. Fecha en la que se creó la imagen. Estado de publicación de la imagen. Si es TRUE aparecerá publicado en el carrusel, si es FALSE no aparecerá publicado.
Fuente. Autores 5.4.5 Colaborador Modelo que representa los datos de las personas que donan recursos mixtos a la fundación. En el Anexo B. se muestra la estructura del esquema desarrollado en el código para el modelo. La tabla 21 explica cada uno de los datos del modelo colaborador. Tabla 21. Datos del modelo Colaborador No. NOMBRE 1
Id
2 3 4 5 6 7 8 9 10
Nombre Apellido Teléfono Email Especie Tiempo Dinero Cantidad Fecha
DESCRIPCIÓN Este dato no aparece en el esquema, ya que es obligatorio y siempre es asignado automáticamente por MongoDB. Nombre(s) del donante. Apellidos del donante. Teléfono de contacto del donante. Email de contacto del donante. Describe los datos de las donaciones en especie. Describe los datos de las donaciones en tiempo. Describe los datos de las donaciones en dinero. Contiene la cantidad de dinero a donar, si se donó dinero. Fecha en la que se realizó la donación.
Fuente. Autores
63
5.4.6 Video Modelo que representa cada uno de los videos publicados en la vista VIDEOS de la plataforma, referentes a los videos del canal de YouTube de la fundación. En el Anexo B. se muestra la estructura del esquema desarrollado en el código para el modelo. La tabla 22 explica cada uno de los datos del modelo video. Tabla 22. Datos de modelo Video No.
NOMBRE
1
Id
2 3 4
Título Id Video Descripción Fecha Creación
5 6
Publicado
DESCRIPCIÓN Este dato no aparece en el esquema, ya que es obligatorio y siempre es asignado automáticamente por MongoDB. Nombre del video. Id de YouTube del video. Descripción del contenido del video. Fecha en la que se creó el video en la base de datos. Dato que maneja la publicación, si es TRUE se publica en la vista video, si es FALSE no se publicará en la vista.
Fuente. Autores
64
5.5 DESARROLLO DE LA FASE DE GESTIÓN DE USUARIOS La gestión de usuario comprende todo lo relacionado a los usuarios administradores de la plataforma, estos usuarios son los únicos que pueden gestionar todo el contenido, existe un único usuario administrador que es el encargado de gestionar la creación, edición y eliminación de usuarios colaboradores. Cada usuario también tiene la opción de editar sus datos, como el nombre, apellido, correo, teléfono, nickname y contraseña; lo único que no pueden editar es el rol, si no son el usuario administrador. Esta gestión incluye los procesos para crear, editar y eliminar usuarios, y la validación para poder ingresar a la plataforma con un usuario.
5.5.1 CRUD de usuario El CRUD son las siglas de las acciones que se pueden realizar con un modelo en una base de datos. La creación de usuario es una acción realizada por el administrador principal. La lectura de usuario comprende todo lo relacionado a la selección y búsqueda de datos concernientes al modelo usuario. La actualización de usuarios se puede realizar por todos los usuarios, comprende todo lo relacionado al cambio de datos existentes en el modelo usuario. La eliminación de usuarios es una acción disponible únicamente para el usuario administrador, ya que elimina definitivamente de la base de datos de la plataforma al usuario seleccionado. En el Anexo B. se puede ver el desarrollo de estas acciones.
5.5.2 Plantilla de autenticación Para el ingreso al gestor de contenido de la plataforma es necesario un proceso de autenticación, el cual se hace por medio de la plantilla de autenticación, el acceso a este proceso se encuentra en el pie de página de la plataforma en la opción “ADMINISTRAR CONTENIDO”, la cual va a mostrar la plantilla de autenticación (Ver figura 16) la cual al recibir los datos correctos envía los datos al servidor, el cual crea una sesión mediante la librería “session” de NodeJS.
65
Figura 16. Plantilla de autenticación
Fuente. Autores El desarrollo de la autenticación se muestra en el Anexo B. mediante el método post con enlace “/login”. En esta vista de autenticación se puede observar que se muestra una ventana emergente que solicita el nombre de usuario o nickname y la contraseña, además aparece la opción para recuperar contraseña, la cual redirecciona a la vista mostrada en la figura 17 y al ingresar los datos solicitados envía los datos y la contraseña al correo que tiene registrado el usuario. En el Anexo B se muestra el desarrollo para la recuperación de la contraseña en donde se muestra el proceso SMTP usado para la conexión con el servidor de correo mediante un método post. Figura 17. Vista Recuperar Contraseña
Fuente. Autores Al momento de iniciar sesión, la plataforma redireccionará al usuario a la vista principal del gestor de contenido el cual le muestra las opciones de gestión de la plataforma (Gestionar menú, publicaciones, usuarios, slider, videos). En la figura 18 se muestra la vista que encontrará el administrador. 66
Figura 18. Vista de menú administrador
Fuente. Autores En el momento en el que el usuario termine de gestionar el contenido de la plataforma, deberá cerrar sesión por seguridad, para poder realizar esta acción el usuario podrá ver en el pie de página de la plataforma, la opción “CERRAR SESIÓN” la cual solo aparecerá si hay una sesión abierta.
5.5.3 Plantilla de gestión de usuario
La gestión de usuario se divide en dos partes, la gestión de usuario propio o la gestión de todos los usuarios.
5.5.3.1 Gestión de usuario propio Esta parte es la que permite a cada usuario editar sus datos propios, excepto el dato de rol, el cual puedes ser editado solo por el usuario administrador. En la figura 19 se muestra la vista de esta edición.
67
Figura 19. Vista de edición de usuario propio
Fuente. Autores 5.5.3.2 Gestión de todos los usuarios La edición de todos los usuarios es una opción únicamente para el usuario administrador el cual puede crear, modificar y eliminar usuarios, excepto eliminar su propio usuario. En la figura 20 se muestra la vista inicial que se le muestra al usuario luego de ingresar a la opción gestionar usuarios. Al seleccionar la opción de crear nuevo usuario se despliega una vista como la mostrada en la figura 61 para ingresar los datos y crear el nuevo usuario, en la opción de rol solo aparecerán los dos que se pueden asignar, “Colaborador Administrador” y “Colaborador”. Al crear un usuario, automáticamente se envía un correo al usuario nuevo, confirmándole el uso de sus datos y los datos que se usaron. Para editar un usuario aparece la misma vista de creación de usuario solo que con los campos ya llenos con los guardados en la base de datos del usuario a editar. Al
68
confirmar la edición también se envía un correo al usuario modificado, indicándole los datos corregidos. Para eliminar un usuario solo se selecciona al usuario deseado en esta opción. Figura 20. Vista gestionar usuarios.
Fuente. Autores
69
5.6 DESARROLLO DE LA FASE DE GESTIÓN DE MENÚ Esta gestión es la concerniente al menú principal ubicado en la parte superior de la plataforma, como se observa en la figura 21 el menú tiene colores en su parte superior, que hacen parte del diseño y submenús con ese mismo color. Cuando la cantidad de menús sobrepasan la cantidad permitida para no alterar el diseño, aparece un + como el mostrado en la figura 22 con los otros menús creados. Figura 21. Imagen Menú principal
Fuente. Autores Figura 22. Imagen Menús adicionales
Fuente. Autores 5.6.1 CRUD de menú El CRUD son las siglas de las acciones que se pueden realizar con un modelo en una base de datos. El proceso CRUD del menú se puede realizar por cualquier usuario del gestor, y se accede mediante la opción “GESTIONAR MENÚ”. El usuario podrá crear cuantos menús desee, la figura 23 muestra el formulario que se muestra para un nuevo menú, puede definir que el menú no tenga submenús y redireccione a una url interna o externa a la plataforma, si le agrega submenús éstos también podrán redireccionar a urls internas o externas; podrá seleccionar la posición del menú en la barra superior del menú, podra elegir el color que desea para el diseño. Read Menú, esta acción se evidencia en el momento en el que usuario selecciona la opción “GESTIONAR MENÚ”, la vista (Ver figura 24) muestra la lista de todos los menús creados, junto con 70
sus datos. Update Menú, esta opción se muestra al seleccionar uno de los menús existentes y se despliega un formulario de edición con los datos ya existentes. En la figura 24 se muestra la vista como ejemplo para editar un menú. Delete Menú, para eliminar un menú se muestra la opción al desplegar el panel de edición mostrado en la figura 24. Ejemplos de estos desarrollos son los mostrados en el Anexo B para el modelo User.
Figura 23. Vista Create Menú
Fuente. Autores
Figura 24. Vista Read y Update Menú
Fuente. Autores
71
5.7 DESARROLLO DE LA FASE DE GESTIÓN DE CARRUSEL El carrusel es un visor de imágenes posicionado en la página inicial de la plataforma, en donde se muestran imágenes relacionadas a publicaciones recientes, contienen un enlace interno de redirección y una descripción, además de la imagen. En la figura 25 se muestra un ejemplo del carrusel funcionando. Figura 25. Vista Carrusel
Fuente. Autores 5.7.1 CRUD de Slider El CRUD de slider o carrusel puede ser efectuado por cualquier usuario. La lógica para realizar el CRUD es la misma usada en el CRUD de Menú solo que se cambia el modelo. En la figura 26 se muestra las vistas resultantes para la gestión del carrusel en donde se incluyen todos los 4 procesos del CRUD.
72
Figura 26. Vista Gestionar Slider
Fuente. Autores
73
5.8 DESARROLLO DE LA FASE DE GESTIÓN DE PUBLICACIONES Las publicaciones son las páginas que crean los administradores con información concerniente al objetivo de la fundación, en donde se encuentran 4 categorías de tipo de información; están las publicaciones con categoría “FÍSICO”, “ESPIRITUAL”, “EMOCIONAL” y “SIN CATEGORÍA”, ésta última contiene todo lo relaciona a información administrativa de la fundación. En la figura 27 se muestra un ejemplo de una publicación. Figura 27. Vista publicaciones
Fuente. Autores
74
5.8.1 CRUD de página El modelo página representa las publicaciones, se le llama página porque al crearse se convierte en una página secundaria de la plataforma con su propia dirección de enlace y contenido. La lógica necesaria para el CRUD de página es la misma usada en CRUD de menú, solo que cambia el modelo al que se le realiza la acción. En las figuras 28 y 29 se muestran las vistas resultantes para el proceso de gestión de página en donde se encuentran las 4 operaciones del CRUD. Figura 28. Vista Read y Delete Página
Fuente. Autores
75
Figura 29. Vista Create o Update Página
Fuente. Autores
76
5.9 DESARROLLO DE LA FASE DE GESTIÓN DE VIDEOS Los videos son referencias a los videos publicados en el canal de YouTube de la fundación Conexión Bienestar, el objetivo de esta vista es promocionar estos videos que también son base de información para cumplir con el objetivo de la fundación. La figura 30 muestra una vista ejemplo de como se muestran estos videos en la plataforma al ser creados. Figura 30. Vista videos
Fuente. Autores 5.9.1 CRUD de video La lógica necesaria para realizar CRUD de los videos es la misma usada en el CRUD de menú solo que se cambia el modelo. La figura 31 muestran las vistas resultantes en donde se gestiona el modelo Video para su publicación en la plataforma.
77
Figura 31. Vista Gestionar Video
Fuente. Autores
78
5.10 DESARROLLO DE LA FASE DE DONACIÓN Las donaciones en una fundación son muy importantes para poder velar por su continuidad en el trabajo que realicen; es por esto que en la plataforma existen dos módulos de donación los cuales son los más evidentes en la página inicial de la plataforma. La figura 32 muestra los cuatro lugares en donde se puede acceder a las donaciones, el primero es por medio del menú principal en las opciones “APOYANOS” y “COMPRA TU ESTRELLA”, el segundo es el botón grande llamado DONAR que aparece en la esquina superior derecha de la plataforma, el tercero es la opción “SOS” que se encuentra en el menú lateral de la plataforma seguido de la opción de compartir en redes sociales y el cuarto es el que se ve en el segundo CARD de publicaciones que muestra el mensaje “AYUDANOS A AYUDAR” al lado del mensaje que explica qué es Conexión Bienestar. Las donaciones se dividen en dos tipos, la donación de estrellas y la donación mixta, las cuales le brindan recursos a la fundación en cualquier monto o forma. Figura 32. Accesos a donaciones
Fuente. Autores
79
5.10.1 Donación de Estrellas La donación de estrellas es una modalidad inventada por la fundación para comprometer mensualmente al donante con un monto específico; en la figura 33 se muestra la vista de este tipo de donación en donde le solicitan al usuario la cantidad de estrellas a donar mensualmente, en donde cada estrella tiene un monto específico, en este caso de $30.000. Figura 33. Vista Donación de Estrellas
Fuente. Autores 5.10.2 Donación Mixta La donación mixta consta de 3 modalidades, donación en especie, tiempo y dinero; cuando la donación es en dinero se realiza el proceso mediante la pasarela de pagos y cuando es en especie o tiempo, se guarda en la base de datos para que los administrativos vean estos datos y se pongan en contacot con el donante. En la figura 34 se muestra la vista de esta donación. Figura 34. Vista Donación Mixta
Fuente. Autores
80
5.10.2.1 CRUD de colaborador
Los colaboradores son los datos de los donantes que han ingresado a la plataforma mediante la opción de donación mixta; en el gestor se muestra una lista de los donantes. En este caso estos datos no son editables, entonces el CRUD no se completa, se desecha la opción de Update para éste modelo. Este proceso lo pueden realizar calquiera de los usuarios administradores. La lógica para realizar el CRUD es la misma usada en el CRUD de Menú solo que se cambia el modelo. En la figura 35 se muestra la vista resultante para la gestión del colaborador en donde se incluyen 2 procesos del CRUD (Read y Delete) el proceso de Create se realiza en la gestión de donación mixta. Figura 35. Vista Gestión Colaborador
Fuente. Autores 5.10.3 Conexión con pasarela de pagos La conexión con la pasarela de pagos se refiere al motor contratado por la fundación, para realizar el proceso de donaciones concernientes al dinero. Para realizar esto el servidor de la plataforma tiene que conectarse con el WebService de la pasarela de pagos para enviarle los datos de la donación encriptados. El WebService de MobileCard
81
esta desarrollado en el lenguaje PHP, por lo que se tiene que realizar un proceso de encriptación y codificación para el envío de datos. Los pasos realizados por el servidor son:
Llenar formulario de donación mixta en dinero o donación de estrellas (Ver figura 33 y 34) y enviar post al servidor con estos datos. Armar Certificado Armar JSON con datos de donación. Encriptar y codificar JSON. Generar valores de POST. Enviar valores por POST a pasarela de pagos. Recibir post en dirección de respuesta. Mostrar confirmación.
El certificado es una cadena de caracteres necesaria para armar el JSON de la donación, la cual contiene los datos (moneda, idComercio, idConcepto, code y valor). Esta cadena se encripta con MD5 y se codifica en base 64. El JSON es un tipo de dato que necesita armarse para poder encriptar y ser enviado a la pasarela de pagos. Los datos del JSON que
se necesita armar se muestran en la tabla 23 Tabla 23. Tabla de campos JSON donación. No. NOMBRE 1 idComercio 2
idTipoTransaccion
3 4 5 6 7 8 9 10 11 12 13
pagos idProducto idConcepto concepto valor impuesto valorImpuesto Moneda secureCode certificado urlComercio
14
urlConfimacion
DESCRIPCIÓN Número dado a la fundación por el servicio. El tipo de transacción es de transferencia de dinero por tarjeta crédito o débito, en este caso es 1. Es el número de pagos que se van a dar por ese valor mensualmente. Número dado por el servicio. Donación Donación unica o Donación de estrellas Monto de la donación 16% 0 por tratarse de una Empresa sin ánimo de lucro. COP – Moneda colombiana Código dado por el servicio Cadena formanda y encriptada, ver sección 5.10.3.1 Dirección de la plataforma en este caso http://www.conexionbienestar.com Dirección de la plataforma que va a recibir el post de confirmación de la plataforma.
Fuente. Autores y MobileCard Para encriptar el JSON es necesario para proteger los datos del usuario. El proceso de encriptación del JSON se hace mediante el método 3DES junto con la llave otorgada por MobileCard. Este método encripta el JSON y retorna una cadena de caracteres.
82
Para enviar los datos de la donación se hace mediante un POST a la dirección “https://prod.mobilecard.com.co/AddcelColombiaWeb/login” que recibe dos valores, comercio, el cual es dado por el servicio a la fundación y json que es la cadena de caracteres con el JSON encriptado. Luego de realizar el proceso de donación en la página de la pasarela de pagos, ésta envía un post de confirmación a la dirección escrita en el JSON urlConfirmacion. Y la plataforma le muestra al usuario que la donación fue exitosa. Para ver el ejemplo de éste desarrollo ver Anexo B.
83
5.11 DESARROLLO DE LA FASE DE GESTIÓN DE BÚSQUEDA La búsqueda es el proceso en el que el servidor busca en los contenidos de las publicaciones palabras ingresadas en la sección de búsqueda. En la figura 36 se muestra un ejemplo del resultado de una búsqueda. Figura 36. Vista Búsqueda
Fuente. Autores La búsqueda se realiaza mediante un método similar al LIKE que busca que la palabra ingresada este contenida dentro de un campo determinado, los campos en los que realiza la búsqueda es en el título, descripción y contenido de las publicaciones.
84
5.12 DESARROLLO DE LA FASE DE CONTACTO
El contacto se refiere a la sección que el visitante de la plataforma encuentra en el menú principal opción “CONTACTO” el cual envía un correo a los administrativos de la plataforma para que se pongan el contacto con el visitante y resolver sus dudas, ya sea sobre algun tema que haya visto en las publicaciones o para ser colaborador de la fundación. La figura 88 muestra la vista resultante para el envío del contacto. Figura 37. Vista Contacto
Fuente. Autores
85
6. CONCLUSIONES Menos es Mas (Mies Van Der Rohe), esto se comprobó con el desarrollo de éste gestor de contenido, ya que se demostró que con muy pocas funciones se pudo satisfacer las necesidades de un usuario, sin confundirlo y sin crear herramientas obsoletas para el usuario. Los gestores de contenido modernos son muy útiles para usuarios que quieren páginas en instantes, pero no siempre tienen todo lo que el usuario desea o tienen herramientas que nunca son usadas por el usuario. Cuando se trata de necesidades específicas es bueno desarrollar desde cero como se hizo en este proyecto. Planear las etapas de trabajo del proyecto, mediante la herramienta Trello, permitió distribuir las actividades con los tiempos convenientes para que se entregara a tiempo el producto. El desarrollo basado en pruebas permitió disminuir los errores a la hora del desarrollo y agilizar la entrega de cada etapa del proyecto. Se logró crear un gestor de contenido adaptado a los diseños del cliente ya que se inició el desarrollo desde ceros para no dejar de lado ninguna necesidad del usuario. Se logró generar un modelo de datos que brindará la persistencia deseada de los datos, mediante el uso de MONGODB para poder tener consultas a la base de datos más rápidas y livianas. Algo muy útil para la plataforma ya que maneja modelos no relacionados entre sí, como por ejemplo el menú con las páginas. Desarrollar un módulo de gestión de usuarios permitió brindarle al cliente administrador, la posibilidad de tener ayuda para la edición del contenido y tener sus plataforma lista para el lanzamiento de la fundación. Desarrollar módulos de gestión de menú, publicaciones, carrusel, videos y colaboradores, permitió que el usuario no dependiera tanto del desarrollador para la gestión de su plataforma. Además que desarrollar por módulos volvió el código escalables para futuros cambios y el soporte por parte de los desarrolladores.
86
Implementar una pasarela de pagos profesional, permitió agilizar la actividad más importante para la fundación, la donación de dinero es una actividad que no se puede tomar a la ligera ya que tiene muchos pasos que deben garantizar la seguridad tanto para el donante como para los fondos de la fundación. La conexión con la pasarela de pagos permitió a los desarrolladores interactuar con un WebService profecional y afianzar conocimientos en otro lenguaje (PHP) y los conceptos sobre encriptación y codificación de datos. Trabajar
con nuevas
tecnologías
permitió
ampliar el conocimiento de los
desarrolladores y su experiencia en el ámbito laboral, todo porque se tubo que investigar a fondo el manejo de NODEJS y MONGODB ya que son herramientas nuevas. La conexión de NODEJS y MONGODB brinda grandes oportunidades para los desarrollos de plataformas que manejen gran cantidad de datos sin necesidad de relacionarlos entre sí, un ejemplo además de la plataforma de la fundación son las redes sociales, las cuales usan bases de datos no relacionales y lenguajes modernos para la gestión de sus datos y plataforma. Usar herramientas existentes para el desarrollo como JADE, STYLUS, entre otros, facilitan y agilizan el tiempo de desarrollo, aprender a usarlas es un paso más para ser un buen desarrollador de plataformas web. Las bases de datos no relacionales no sustituyen a las bases de datos tradicionales, sino que las complementan para algunos tipos de aplicaciones como la desarrollada en este proyecto. Las bases de datos como MongoDB se utilizan para multitud de operaciones, principalmente para obtener flexibilidad en la definición de los datos, sencillez a la hora de acceder a éstos, gran rendimiento y posibilidad de crecimiento. El desarrollo con la metodología SCRUM facilitó el proceso del proyecto, ya que se pudeo interactuar con el cliente para corregir errores y disminuir la cantidad de correcciones en la entrega final del producto. El uso del daily permitió que los desarrolladores pudieran cumplir con sus metas o solicitar ayuda para el desarrollo de módulos en los que se encontraban dudas específicas y poder modificar el calendario para cumplir con las entregas.
87
7. RECOMENDACIONES Para poder entender el manejo del gestor de contenido ver el Anexo D. Manual de Usuario del Gestor de Contenido.
7.1 INTERPRETACIÓN DEL CÓDIGO Los fragmentos de código mostrados en el proyecto no representan la totalidad el desarrollo hecho. Es importante guiarnos de la información completa, para esto se puede ver el repositorio del proyecto en el enlace https://github.com/vicadi/PasantiaFundacion. Este es un proyecto desarrollado con software libre y por los autores del libro. Para ver el resultado del proyecto en despliegue se puede ingresar al enlace de la fundación http://www.conexionbienestar.com, la plataforma está desplegada en una máquina de Amazon al igual que el motor de base de datos MongoDB y la base de datos Fundación. Es importante mencionar que para usar el proyecto es importante tener instalado NodeJS y MongoDB. La explicación del código se puede ver en el Anexo E.
7.2 INSTALACIÓN DE MOTORES Es muy importante saber instalar los motores de desarrollo y base de datos ya que de esto depende que se pueda ejecutar un proyecto como éste. Para empezar se usó como sistema operativo a Ubuntu 14.0, se puede usar cualquier distribución de Linux, pero en este caso se uso esta distribución para el desarrollo. También es importante usar un gestor de repositorios para controlar los cambios del desarrollo, en este caso se usó GitHub.
88
7.2.1 Instalación de GitHub El primer paso es crear
una
cuenta
de
GitHub
ingresando
al
enlace
https://github.com/join?source=header-home. Para iniciar la instalación de GitHub, se ingresa primero a la Terminal de Ubuntu. (Tomado de la página principal de GitHub)
Comprobar si ya está instalado GitHub con el comando ‘git --version'
Si no está instala ingresar los siguientes comandos: - ‘sudo apt-get install git’ - ‘sudo apt-get install xclip’
Configurar GitHub con la cuenta que se creó en la página mediante los comandos: - ‘git config --global user.name “nombre de usuario”’ - ‘git config --global user.email “email de usuario”’ Para poder subir repositarios desde el pc donde se desarrolla hay que guardar la llave del pc en GitHub mediante los siguientes pasos: - ‘ssh-keygen’ - Doble Enter - ‘cat ~/.ssh/id_rsa.pub//’ - Copiar contenido mostrado y agregarlo en la sección SSH Keys en GitHub en el enlace ‘add Sshkey’
Para crear repositorio primero toca crearlo desde la cuenta de GitHub en la plataforma web. Después en la terminal: - ‘git init’ - ‘git remote add origin (dirección http o ssh del repositorio)’
Para subir archivos: - ‘git add -A’ para todos los cambios o ‘git add nombreArchivo’ para archivos específicos.
89
- git commit –m ‘comentario’ - git push origin nombreRama
7.2.2 Instalación de NodeJS Para la instalación de NodeJS y sus complementos se usan los siguientes comando:
sudo apt-get update
sudo apt-get install nodejs
sudo apt-get install npm
npm install –g express
Para crear un proyecto se usan los siguientes comandos ubicando la terminal en la ruta donde se quiere el proyecto:
express “nombre carpeta”
sudo npm install
npm start
7.2.3 Instalación de MongoDB Para instalar MongoDB se sugiere visitar su página oficial, ya que posee todos los pasos necesarios para el sistema operativo que se tenga y los complementos que se deseen, para ver los pasos de instalación en ubuntu se puede acceder desde el enlace https://docs.mongodb.org/manual/tutorial/install-mongodb-on-ubuntu/. Para ingresar a la consola del motor solo se usa el comando ‘mongo’ en la terminal, cuando aparece la consola de mongo se puede usar los siguientes comandos:
dbs use nombre_base_datos
db.nombreModelo.find()
db.nombreModelo.insert({})
db.nombreModelo.remove({})
90
8. SOPORTES TÉCNICOS 8.1 BIBLIOGRAFÍA Sara Fioravanti, Simone Mattolini, Fulvio Patara, Enrico Vicario. (2016). Experimental Performance Evaluation of different Data Models for a Reflection Software Architecture over NoSQL Persistence Layers ACM. University of Florence, Florence, Italy. ACM-DL. Khalid Mahmood, Tore Risch, Minpeng Zhu. (2015). Utilizing a NoSQL Data Store for Scalable Log Analysis. Dept. of Information Technology, Uppsala University, Sweden. ACM-DL. Carlos Azaustre. (2015). Ejecuta tu App NodeJS como un Servicio en Linux. CTO & Co-Founder @ Chefly. José Manuel Alarcónel. (2014). Fundamentos de bases de datos NoSQL: MongoDB. Campus MVP. Giannaccini, Müller. (2014). Burckhardtsource.org: Una Biblioteca Digital Semántica. Revista ACM-DL, Articulo N° 6. Samper Zapata. (2014). De la web 1.0 a la Web 4.0: la evolución de la web. Revista ACM-DL, Articulo N° 2. Quinterio, Ribeiro. (2014). Resumen de Django-CMS. Revista ACM-DL, Articulo N°11. Alberto Fernández. (2013). Estrategias de Modelado de Datos en MongoDB. AnalyticaWeb Posicionamiento en buscadores, Desarrollo Web unido al mundo de Internet. Zachary Parker, Scott Poe, Susan V. Vrbsky. (2013). Comparing NoSQL MongoDB to an SQL DB The University of Alabama, Tuscaloosa, The ACM Digital Library.
91
Veronika Abramova, Jorge Bernardino . (2013). NoSQL databases: MongoDB vs cassandra Polytechnic Institute of Coimbra, ISEC - Coimbra Institute of Engineering, Coimbra, Portugal. The ACM Digital Library. Sung, Lee. (2011). Preferencia de los protocolos de pago de débito basadas en Internet. Revista IEEE, 424-427. Michael Abernethy. (2011). ¿Just what is Node.js?. Freelance Programmer, Freelancer. Jurriaan Souer, Dirk-Jan Joor. (2010). Un enfoque para identificar aspectos comunes en ingeniería de aplicaciones web para un sistema de gestión de contenido web. Revista ACM-DL, Articulo N° 8. Universidad de Alicante (2009), Servicio de Informática ASP.NET MVC 3 Framework Stephanie Falla Aroche. (2009). 10 opciones de CMS que debes conocer. Artículo publicado en el Especial de CMS de Comunicación y Pedagogía. Alicia Cañellas Mayor . (2008). CMS, LMS y LCMS. Definición y diferencias. Artículo publicado en el Especial de CMS de Comunicación y Pedagogía. Xavier García Cuerda. (2004). Introducción a los Sistemas de Gestión de Contenidos (CMS) de código abierto - Publicado en Gestión de contenidos, Tecnologías Barros, Oscar (1994). Reingeniería de procesos de negocio. Editorial Dolmen, Chile
8.2 CIBERGRAFÍA
FUNDACIÓN CONEXIÓN BIENESTAR. (2015). Conexión Bienestar Sobre Nosotros. Bogotá D.C. Recuperado de http://www.conexionbienestar.com/SobreNosotros Sistema Gestor de Contenido WordPress. (2010). Que es WordPress. Estados Unidos. Recuperado de www.wordpress.com Sistema Gestor de Contenido Drupal. (2012). Que es Drupal. Bélgica. Recuperado de www.drupal.org
92
Sistema Gestor de Contenido Joomla. (2014). Que es Joomla. Recuperado de www.joomla.org Sistema Gestor de Contenido Typo3. (2010). Que es Typo3. Recuperado de www.typo3.org Saffirio M. (2006). WEBSERVICE Tecnologías de Información y Gestión de Procesos de
Negocios
(BPM).
Colombia.
Recuperado
de
https://msaffirio.wordpress.com/2006/02/05/%C2%BFque-son-los-web-services/ Schwaber, Sutherland. (2013). La Guía Definitiva de Scrum: Las Reglas del Juego. Recuperado de http://www.scrumguides.org/docs/scrumguide/v1/Scrum-Guide-ES.pdf Redes Zone (2010) Funciones Hash. Recuperado de http://www.redeszone.net/ Universidad Nacional Autónoma de México (2008). Principales Algoritmos Simétricos - 3DES o TDES. Recuperado de http://redyseguridad.fi-p.unam.mx/
93
ANEXOS ANEXO A. MOCKUPS DE LA PLATAFORMA Mockup Página inicial
Fuente. Milena Siachoque, Directora Externa del proyecto Mockup Publicaciones
Fuente. Milena Siachoque, Directora Externa del proyecto
94
Mockup Autenticación
Fuente. Milena Siachoque, Directora Externa del proyecto Mockup Crear Usuario
Fuente. Milena Siachoque, Directora Externa del proyecto
95
Mockup Edición de Menú
Fuente. Milena Siachoque, Directora Externa del proyecto Mockup Lista de publicaciones
Fuente. Milena Siachoque, Directora Externa del proyecto
96
Mockup Publicación nueva
Fuente. Milena Siachoque, Directora Externa del proyecto Las siguientes imágenes son los Mockups diseñados por la directora de desarrollo Milena Siachoque, quien planteó estos diseños para iniciar con el croquis de la plataforma web y tener vistas para ir mostrando al cliente.
97
ANEXO B. EJEMPLOS DE CÓDIGO Desarrollo de pruebas unitarias, ejemplo.
Fuente. Autores Comprobación pruebas unitarias de usuario, Menú y Carrusel
Fuente. Autores 98
Comprobación pruebas unitarias de Publicación, Videos y Donación
Fuente. Autores Esquema Usuario y Menú
Fuente. Autores Esquema Página y Slider
Fuente. Autores
99
Esquema Colaborador y Video
Fuente. Autores Desarrollo Create Usuario
Fuente. Autores Desarrollo Read y Delete Usuario
Fuente. Autores
100
Desarrollo Update Usuario
Fuente. Autores Desarrollo de autenticación
Fuente. Autores
101
Desarrollo de Recuperar Contraseña – Parte 1
Fuente. Autores Desarrollo de Recuperar Contraseña – Parte 2
Fuente. Autores Desarrollo Armar Certificado
Fuente. Autores
102
Desarrollo Armado JSON
Fuente. Autores Desarrollo 3DES
Fuente. Autores Desarrollo de generación de valores del POST para la pasarela de pagos
Fuente. Autores
103
ANEXO C. DISEÑOS DE LA FUNDACIÓN PARA LA PLATAFORMA Página inicial
Fuente. Diseñador Fundación Conexión Bienestar
104
Barra de menú
Fuente. Diseñador Fundación Conexión Bienestar Menú desplegable
Fuente. Diseñador Fundación Conexión Bienestar Logo metálico
Fuente. Diseñador Fundación Conexión Bienestar
105
Menú lateral
Fuente. Diseñador Fundación Conexión Bienestar Publicaciones
Fuente. Diseñador Fundación Conexión Bienestar
106
Resultado de búsqueda
Fuente. Diseñador Fundación Conexión Bienestar Contacto
Fuente. Diseñador Fundación Conexión Bienestar
107
Donación de estrellas
Fuente. Diseñador Fundación Conexión Bienestar Donación mixta
Fuente. Diseñador Fundación Conexión Bienestar
108
ANEXO D. MANUAL DE USUARIO DEL GESTOR DE CONTENIDO
CONTENIDO 1. INTRODUCCIÓN 2. PROPÓSITO DEL DOCUMENTO 3. CONCEPTOS IMPORTANTES 4. ACCESO A LA APLICACIÓN 5. GESTIONAR USUARIOS 6. GESTIONAR MI USUARIO 7. GESTIONAR MENÚ 8. GESTIONAR CARRUSEL 9. GESTIONAR PÁGINA 10. GESTIONAR VIDEO 11. GESTIONAR PATROCINADORES
1. INTRODUCCIÓN El gestor de contenido de la plataforma de la Fundación Conexión Bienestar se realizó con el objetivo de administrar las publicaciones de la fundación sin necesidad de un desarrollador; esto porque la principal fuente de información y conección con la fundación es la plataforma mediante contenidos ricos en información útil sobre salud física, emocional y espiritual.
2. PROPÓSITO DEL DOCUMENTO Este documento se realiza con el propósito de ayudar al usuario administrador de la plataforma a usar de forma adecuada el gestor y que éste no le genere inconvenientes a la hora de ingresar contenido informativo. El gestor de contenido se reaizó para que en
109
su mayoria fuera intuitivo y se puedier usar de forma fácil, pero este manual puede ser útil para las dudas que pueden surgir para el usuario a la hora de gestionar la plataforma.
3. CONCEPTOS IMPORTANTES Es importante recordarle al usuario algunos conceptos para que la gestión del contenido sea más cómoda. CMS: Son las siglas de Sistema de gestión de contenido, esto es lo que representa el sistema desarrollado, pero es importante aclararle al usuario que éste es útil unicamente para gestionar las publicaciones, menú, carrusel, videos, colaboradores y usuarios. El contenido no brinda opciones para gestionar otros componentes ni para que el propio usuario sea quien modifique el gestor de contenido. USUARIOS: Los usuarios son los administradores del gestor de contenido para las publicaciones de la plataforma. No hacen parte de éstos los usuarios que ingresan a visitar la plataforma. USUARIO ADMINISTRADOR: Este usuario es único y representa al principal usuario administrador, éstu usuario es el único que tiene acceso total a la gestión del contenido y no se pueden crear más como éste. La contraseña y el nombre de usuario son asignados al momento de la instalación del sistema en el servidor. USUARIO COLABORADOR ADMINISTRADOR: Este usuario es agregado por el usuario administrador principal, tiene permisos de administrador para todo excepto para la gestión de usuarios. USUARIO COLABORADOR: Este usuario es agregado por el usuario administrador principal y tiene permisos para crear contenido mas no para autorizar su publicación. MENÚ: Éste hace referencia a al menú ubicado en la parte superior de la plataforma. SUBMENÚ: Son los menús que se despliegan de un menú principal. PÁGINA: Son las publicaciones con información creadas para los visitantes de la plataforma.
110
CARRUSEL: Es el pasador de imágenes que esta en la página principal de la plataforma en donde se ven las referencias a publicaciones recientes. VIDEOS: Son las referencias a los videos que la fundación publica en su cana de YouTube. COLABORADORES: Son las personas que donan ya sea dinero, tiempo o especies a la fundación.
ACCESO A LA APLICACIÓN Para acceder a la aplicación es necesario ubicarse en la plataforma y dirigirse al pie de página en donde se encontrará un link que dice “ADMINISTRAR CONTENIDO”
Saldrá una ventana emergente en donde se solicitan los datos de usuario y contraseña para poder ingresar al gestor de contenido tiene que ser usuario administrador, colaborador administrador o colaborador.
Al usuario administrador principal le aparecerá el siguiente menú:
111
Al usuario colaborador administrador y colaborador le aperece el mismo menú pero sin la opción de gestionar usuarios.
GESTIONAR USUARIOS La opción de gestionar usuarios se le muestra únicamente al usuario administrador principal.
Aquí puede agregar usuarios nuevos o editar y eliminar los usuarios existentes, excepto su propio usuario.
112
GESTIONAR MI USUARIO Esta opción es para editar los datos personales del usuario que este logueado.
Cuando los datos modificados solo es necesario hacer click en la opción “Actualizar Datos”. La opción “Eliminar mi Usuario” es para dejar de ser administrador o colaborador de la plataforma, al hacer click aquí automáticamente se elimina el usuario y se cierra la sesión, el administrador principal no tiene esta opción. GESTIONAR MENÚ Para gestionar el menú y los submenús que tiene la barra frontal de la la plataforma se encuentra esta opción.
113
Aquí puede, agregar menús nuevos, editar o elimnar los menús existentes. Es importante mencionar que las posiciones que el usuario ingrese se refieren a la ubicación que tendrán en la barra de menú, cuando el número de menús sobrepasen a 5 los menús se agregarán al menú que se despliega del simbolo “+” que se ve al final de la barra de menús. Un menú o submenú puede redireccionar a páginas externas con formato “http://www.ejemplo.com” o páginas internas, las cuales se despliegan para escoger al momento de seleccionar url interna. Cuando un menú tiene redirección a un enlace interno o externo, éste no puede tener submenús y viceversa.
GESTIONAR CARRUSEL Esta opción es para agregar imágenes al carrusel de la página principal de la plataforma, aquí solo aparecerán todos los que esten creados con la opción de publicado si está publicado y si no está publicado no aparecerá con éste estado. También se pueden eliminar. Si el usuario es colaborador únicamente, no le aparecerá la opción para publicar o dejar de publicar una imagen.
114
GESTIONAR PÁGINAS Esta opción es para gestionar las publicaciones de información para la plataforma, se puede agregar nuevas publicaciones y editar o eliminar publicaciones existentes. Cuando el usuario es únicamente colaborador no le aparecerá la opción para pubicar o dejar de publicar las páginas.
GESTIONAR VIDEOS Para gestionar las referencias de los videos del canal de YouTube de la fundació es ésta opción, aquí se pueden agregar referencias nuevas y editar o eliminar existentes. La opción de publicar o dejar de publicar referencias no es mostrada a los usuarios colaboradores.
115
Con respecto al campo Id del Video hace referencia al id que YouTube le asigna al video al momento de ser subido, éste aparece en la dirección de enlace del video.
GESTIONAR COLABORADORES Los colaboradores no se pueden agregar o editar, solo se pueden ver para contactarse con ellos si es necesario.
116
ANEXO E. DOCUMENTACIÓN PARA EL DESARROLLADOR
CONTENIDO 1. Introducción 2. Arquitectura del aplicativo 3. Manual de despliegue 4. Manual de bases de datos 5. Manual de pruebas INTRODUCCIÓN Este documento contiene guías específicas para los futuros desarrolladores del aplicativo web de la Fundación Conexión Bienestar a fin de proporcionar instrucciones para la instalación y configuración del sistema en servidores, así como una vista de la estructura del software y sus componentes. El documento está dirigido al personal que en un futuro le va proporcionar soporte y desarrollar nuevas funcionalidades al aplicativo. ARQUITECTURA DEL APLICATIVO La arquitectura que se manejó en el proyecto es la Arquitectura Modelo Vista Controlador MVC, la cual es la que usa NodeJS que es el lenguaje de programación en el que se desarrolló el proyecto.
117
Arquitectura general del proyecto MANUAL DE DESPLIEGUE Como ya se mencionó antes el proyecto está desarrollado en NodeJS en la parte de backend, por la parte de frontend tenemos Css3, Html5, Javascript y las librerías Bootstrap y JQuery y para base de datos tenemos MongoDB como motor. El aplicativo está desplegado en un servidor Linux Ubuntu 15.10 en una máquina proporcionada por Amazon
en
su
servicio
EC2
(Los
credenciales
de
acceso
se
le
entregarán personalmente a los desarrolladores). Para desplegar el proyecto en otra máquina necesita tener un sistema operativo Linux 14 o superior en el instalar las siguientes líneas de código en el orden que está descrito a continuación.
sudo apt-get install git
cd /..(ruta donde va colocar el proyecto)
git clone https://github.com/ingcaranton/fundacion
sudo apt-get install node
sudo apt-get install mongodb
118
mongo
use Fundacion
npm install express-generator -g
npm start
Ya debería tener corriendo el proyecto en esa máquina.
MANUAL DE BASES DE DATOS El motor de base de datos que se utiliza es MongoDB y el ORM utilizado es Mongoose en
su version 3.8 para ver el API o para mas informacion http://mongoosejs.com.
dominio
por
defecto
es
localhost,
pero
se
puede
modificar
en
El el
archivo Fundacion/models/index.js
MANUAL DE PRUEBAS El motor de las pruebas es un módulo de node js que se llama Mocha, la programación de las pruebas se encuentran en el archivo Fundación/test/test-unit.js
119