Análisis, Diseño e Implementación de un prototipo Web para la gestión de eventos de la Sociedad Colombiana de Ortodoncia

(1)

ANÁLISIS, DISEÑO E IMPLEMENTACIÓN DE UN PROTOTIPO WEB PARA LA GESTIÓN DE EVENTOS DE LA SOCIEDAD COLOMBIANA DE ORTODONCIA

MANUEL ALEJANDRO BARRAGÁN VELÁSQUEZ JOHAN ANDRÉS BUSTOS AMAYA

UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDAS FACULTAD DE INGENIERÍA

INGENIERÍA DE SISTEMAS BOGOTÁ D.C.

(2)

ANÁLISIS, DISEÑO E IMPLEMENTACIÓN DE UN PROTOTIPO WEB PARA LA GESTIÓN DE EVENTOS DE LA SOCIEDAD COLOMBIANA DE ORTODONCIA

MANUEL ALEJANDRO BARRAGÁN VELÁSQUEZ JOHAN ANDRÉS BUSTOS AMAYA

Proyecto de grado para optar al título de Ingeniería de Sistemas

Director

Prof. Sandro Javier Bolaños Castro

UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDAS FACULTAD DE INGENIERÍA

INGENIERÍA DE SISTEMAS BOGOTÁ D.C.

(3)

3

DEDICATORIA

“Este proyecto está dedicado a mis padres, quienes desde muy pequeño buscaron darme la mejor educación y los valores necesarios para salir adelante; a mi hermano quien en muchos momentos fue una ayuda para crecer como futuro ingeniero; además a mi novia quien siempre ha tenido una voz de aliento en los momentos más difíciles; también a mis amigos y compañeros con quienes pude liberar mi mente en momentos tensos y finalmente a mi compañero de trabajo de grado, quién me ha acompañado en este arduo camino de finalizar la carrera de Ingeniería de Sistemas.’’ Manuel Alejandro Barragán Velásquez

(4)

4

TABLA DE CONTENIDO

DEDICATORIA ... 3

INTRODUCCIÓN ... 10

1. PLANTEAMIENTO DEL PROBLEMA ... 12

1.1 DESCRIPCIÓNDELPROBLEMA ... 12

1.2 FORMULACIÓNDELPROBLEMA ... 13

1.3 HIPÓTESIS ... 13

2. OBJETIVOS ... 14

2.1 OBJETIVOGENERAL ... 14

2.2 OBJETIVOSESPECÍFICOS ... 14

3. JUSTIFICACIÓN ... 15

4. MARCO REFERENCIAL ... 16

4.1 MARCOHISTORICO ... 16

4.2 MARCOTEÓRICO ... 18

4.2.1 Gestión de eventos: ... 18

4.2.2 Sociedad Colombiana de Ortodoncia: ... 20

4.2.3 Eventos de la Sociedad Colombiana de Ortodoncia: ... 21

4.2.4 Gestión de los eventos de la SCO: ... 21

4.2.5 Software Libre: ... 21

4.2.6 Ingeniería de Software:... 22

4.2.7 Arquitectura de Software: ... 22

4.2.8 Arquitectura Empresarial: ... 22

4.2.9 Archimate: ... 23

4.2.15 Metodologías Ágiles: ... 25

4.2.16 Scrum: ... 26

5. ALCANCES Y LIMITACIONES ... 29

(5)

5

5.2 LIMITACIONES ... 30

6. DISEÑO DE LA INVESTIGACIÓN ... 31

6.1 TIPODEESTUDIO ... 31

6.2 PARTICIPANTES ... 31

6.3 INSTRUMENTOSYEQUIPOS ... 31

7. METODOLOGÍA DE LA INGENIERÍA DEL PROYECTO ... 33

7.1 METODOLOGÍADELPROYECTO ... 33

8. CONSTRUCCIÓN DEL PROTOTIPO ... 37

8.1 ANÁLISIS ... 37

8.1.1 Arquitectura Empresarial ... 37

8.1.2 Requerimientos Funcionales ... 42

8.1.3 Requerimientos No Funcionales ... 43

8.2 DISEÑO ... 44

8.2.1 Diagrama de Contexto ... 44

8.2.2 Diagramas de Casos de Uso ... 45

8.2.3 Historias de Usuario ... 49

8.2.4 Diagramas de Actividades ... 59

8.2.5 Modelo Relacional ... 64

8.3 IMPLEMENTACIÓN ... 65

8.3.1 Modelo Arquitectónico ... 65

8.3.2 Diagrama de Clases ... 67

8.3.3 Mapa de Navegación ... 70

8.3.4 Usuarios del Sistema ... 72

8.3.5 Seguridad y control de acceso... 73

8.3.6 Diagramas de Secuencias ... 74

8.3.7 Repositorio Fuentes Versionadas ... 81

8.3.8 Prototipo Web ... 82

8.4 PLANDEPRUEBASFUNCIONALES ... 83

8.4.3 Casos de Prueba ... 83

9. CONCLUSIONES ... 100

10. RECOMENDACIONES ... 102

11. BIBLIOGRAFÍA ... 103

12. ANEXOS ... 105

(6)

6

ANEXOB:ESTÁNDAR BASE DE DATOS ... 106

ANEXOC:DICCIONARIO DE DATOS ... 107

ANEXOD:TABLERO DE TAREAS SCRUM ... 112

(7)

7

LISTA DE TABLAS

Tabla 1: Roles SCRUM de los integrantes ... 34

Tabla 2: Requerimientos Funcionales ... 42

Tabla 3: Requerimientos No Funcionales ... 43

Tabla 4: Historia de Usuario Iniciar Aplicación ... 49

Tabla 5: Historia de Usuario Gestionar Evento ... 50

Tabla 6: Historia de Usuario Gestionar Asistente ... 52

Tabla 7: Historia de Usuario Imprimir Escarapela ... 55

Tabla 8: Historia de Usuario Generar Reporte ... 57

Tabla 9: Modelo Arquitectónico... 65

Tabla 10: Usuarios y Privilegios del Sistema ... 72

(8)

8

LISTA DE FIGURAS

Figura 1: Esquema de proceso básico de SCRUM ... 28

Figura 2: Modelado Archimate – Punto de Vista de la Organización ... 37

Figura 3: Modelado Archimate – Punto de Vista de la Función de Negocio ... 38

Figura 4: Modelado Archimate – Punto de Vista de los Procesos ... 39

Figura 5: Modelado Archimate – Punto de Vista del Producto ... 40

Figura 6: Modelado Archimate – Comportamiento de la Aplicación ... 41

Figura 7: Diagrama de Contexto del Sistema... 44

Figura 8: Diagrama General de Casos de Uso ... 45

Figura 9: Diagrama Caso de Uso Iniciar Aplicación ... 46

Figura 10: Diagrama Caso de Uso Gestionar Evento ... 46

Figura 11: Diagrama Caso de Uso Gestionar Asistente ... 47

Figura 12: Diagrama Caso de Uso Registrar Asistente ... 47

Figura 13: Diagrama Caso de Uso Imprimir Escarapela ... 48

Figura 14: Diagrama de Caso de Uso Generar Reporte ... 48

Figura 15: Diagrama de Actividades Iniciar Aplicación ... 59

Figura 16: Diagrama de Actividades Gestionar Evento ... 60

Figura 17: Diagrama de Actividades Registrar Asistente ... 61

Figura 18: Diagrama de Actividades Imprimir Escarapela ... 62

Figura 19: Diagrama de Actividades Generar Reporte ... 63

Figura 20: Modelo Relacional Base de Datos ... 64

Figura 21: Diagrama de Clases – Contexto Usuario ... 67

(9)

9

Figura 23: Diagrama de Clases – Contexto Asistente ... 69

Figura 24: Mapa de Navegación Primera Parte ... 70

Figura 25: Mapa de Navegación Segunda Parte ... 71

Figura 26: Diagrama de Secuencia Crear Evento ... 74

Figura 27: Diagrama de Secuencia Crear Asistentes ... 75

Figura 28: Diagrama de Secuencia Crear Asistentes Masivo ... 76

Figura 29: Diagrama de Secuencia Registrar Asistente a Evento ... 77

Figura 30: Diagrama de Secuencia Imprimir Escarapela ... 78

Figura 31: Diagrama de Secuencia Generar Reporte Tabla ... 79

Figura 32: Diagrama de Secuencia Generar Reporte Grafico ... 80

Figura 33: Tortoise - Versionamiento Fuentes del Proyecto ... 81

(10)

10

INTRODUCCIÓN

Este documento indica cómo se llevó a cabo el proyecto de grado para optar al título de Ingeniería de Sistemas, desarrollando la solución de software que consiste en un prototipo web para la gestión de los eventos organizados por la Sociedad Colombiana de Ortodoncia (SCO).

La motivación para la realización de este proyecto se basó principalmente en la oportunidad que representó la solución de una problemática real de una organización, lo cual permitió plantear una solución informática utilizando las herramientas y conocimientos que la Ingeniería de Sistemas pone a disposición en todas las etapas de la construcción de la aplicación, como son el análisis, diseño, desarrollo y las pruebas del prototipo implementado.

Inicialmente se plantea y describe el problema que tiene una organización como la SCO para la gestión de sus eventos y la necesidad de tener un sistema de información que sirva como herramienta para centralizar la información de los diferentes tipos de eventos realizados a nivel nacional.

Al identificar la problemática mencionada, se realizó una investigación, gracias a la cual se planteó una solución a través del desarrollo de un prototipo de aplicación web que servirá a la organización no solo para la gestión de los eventos, sino para la toma de decisiones en el futuro.

(11)

11

También se puede ver en el documento qué necesidades se buscó solucionar con el desarrollo del prototipo; así como también aspectos que no se llegaron a desarrollar y pueden ser abordados a futuro en otro proyecto.

Además se observa, cómo se aplicaron al desarrollo del proyecto, los conceptos que ofrece la metodología Scrum y las personas que participaron para llevar a cabo el proceso de manera exitosa.

Al usar una metodología ágil no se dio mucha prioridad a la documentación excesiva de cada una de las fases del desarrollo del sistema, razón por la cual, se podrán ver documentados los requerimientos más importantes para la SCO, mostrando así las fases de construcción del prototipo (Análisis, diseño, implementación y pruebas).

(12)

12

1. PLANTEAMIENTO DEL PROBLEMA

1.1 DESCRIPCIÓN DEL PROBLEMA

Como aspecto fundamental para cumplir con su misión, la Sociedad Colombiana de Ortodoncia, organiza una serie de eventos y conferencias con el objetivo principal de dar a conocer a los diferentes profesionales asociados, el progreso que ha tenido esta ciencia, tanto a nivel nacional como internacional.

La Sociedad Colombiana de Ortodoncia actualmente no cuenta con un aplicativo propio para la gestión de sus eventos, ni para la generación de los reportes históricos de estos, ya que actualmente, la SCO terceriza la gestión de los eventos, contratando empresas de logística, que se encargan de prestar todo el servicio para la organización del evento, registro de asistentes, programación de las actividades y al finalizar proporcionan los reportes con la información relevante de cada evento, como el número de asistentes registrados, el monto recaudado, entre otros.

Además, como la organización tiene presencia en gran parte del territorio colombiano, por medio de sus seccionales por departamento, el hecho de contratar diferentes empresas de logística, genera un costo permanente y una dificultad a la hora de integrar y acceder la información de todos los eventos, con lo cual no se tiene la información consolidada y centralizada a nivel nacional.

(13)

13

1.2 FORMULACIÓN DEL PROBLEMA

Con base a lo anterior se planteó la siguiente pregunta de investigación: ¿Cómo poder gestionar de manera eficiente los eventos organizados por la Sociedad Colombiana de Ortodoncia, centralizando la información y obteniéndola de forma consolidada para el apoyo a la toma de decisiones de la organización?

1.3 HIPÓTESIS

(14)

14

2. OBJETIVOS

2.1 OBJETIVO GENERAL

Diseñar y desarrollar un prototipo de software en ambiente web para soportar la creación, gestión y obtención de información de los diferentes eventos creados por la Sociedad Colombiana de Ortodoncia.

2.2 OBJETIVOS ESPECÍFICOS

 Realizar un análisis de la problemática de la gestión de los eventos de la SCO, con el fin de interpretar de manera correcta los requerimientos que tienen y adaptarlos de manera efectiva a la aplicación.

 Utilizar una metodología de desarrollo de software ágil en donde se implementen todas las fases de construcción de un software (análisis, diseño, implementación, pruebas).

 Realizar entregas periódicas a los miembros de la SCO, buscando así la rápida maduración del sistema de acuerdo a las necesidades que presenta actualmente la sociedad.

 Diseñar una base de datos relacional, en la cual se almacenará la información requerida de los eventos, los asistentes y los usuarios del sistema.

(15)

15

3. JUSTIFICACIÓN

La realización de este proyecto de grado se justificó en el deseo y compromiso que tenemos como estudiantes de Ingeniería de Sistemas de la Universidad Distrital Francisco José de Caldas, de dar solución en el ámbito del desarrollo de software a los problemas que puedan tener en un momento determinado diferentes organizaciones, en este caso la Sociedad Colombiana de Ortodoncia.

Para la SCO, la organización de los eventos y obtener información es una de las actividades principales en las que esta organización centra sus esfuerzos, por ese motivo un sistema para la gestión de dichos eventos permitirá una optimización de los procesos y un mejor servicio para sus asociados.

Al tener centralizada en un solo punto toda la información de los eventos realizados, la SCO podrá generar fácilmente reportes, los cuales permitirán realizar una toma de decisiones efectiva.

(16)

16

4. MARCO REFERENCIAL

4.1 MARCO HISTORICO

Hace un par de años, uno de los integrantes de este proyecto de grado, tuvo una experiencia laboral de tipo “freelance” con la Sociedad Colombiana de Ortodoncia, que le permitió trabajar en una aplicación muy sencilla cuyo objetivo principal era la impresión de las escarapelas para los asistentes al Congreso Internacional de Ortodoncia.

En ese momento se pensó en una solución puntual para la impresión de dichas escarapelas pero no se tuvo en cuenta la posibilidad de solucionar otros requerimientos que en su momento tenía la organización con relación a la gestión de los diferentes eventos. Es decir que la solución planteada se quedó corta frente a las necesidades de la organización, lo que hizo que la aplicación quedara obsoleta en ese momento.

La aplicación de ese entonces se centró únicamente en la funcionalidad de la impresión de escarapelas para ese evento puntual, pero no tuvo en cuenta la gestión de otros eventos, o la consolidación de la información en un solo aplicativo web que sirviera como herramienta para el apoyo en la toma de decisiones.

(17)

17

Entonces se decidió plantear este proyecto, en el cual no solo se implementara un sistema para la impresión de las escarapelas de los asistentes a los diferentes eventos, sino que también permita la organización de los eventos y la obtención de información relevante y consolidada que sirva como apoyo en la toma de decisiones de la SCO.

Sobre el estado del arte:

A nivel comercial existen diferentes aplicaciones de uso personal y otras de uso corporativo que permiten la organización de eventos, incluso muchas son aplicaciones móviles que usando las cuentas de las personas en las redes sociales, permiten enviar invitaciones y tener un control general del evento que se organiza.

Estas son algunas de las aplicaciones comerciales que sirven para organizar eventos:

 EvenTwo (http://www.eventwo.com/): Permite organizar conferencias, congresos personalizando la aplicación.

 Mitmi (http://www.mitmiapp.com/): De uso personal, para crear eventos con amigos.

 B4M – Bits for meetings (http://www.bitsformeetings.com/): Permite crear aplicaciones personalizadas para gestionar eventos.

 Adiante Apps (http://www.adianteapps.com/): Conferencias, eventos, ferias, seminarios y congresos pueden tener su propias aplicaciones móviles.

 Amiando.

 Ticketea.

 Eventioz.

 StageHQ (http://www.stagehq.com/).

(18)

18

 Doattend.

 RegOnline (ver https://www.regonline.com.es/).

 Eventools (aplicación colombiana http://www.eventools.com.co/).

4.2 MARCO TEÓRICO

4.2.1 Gestión de eventos:

Desde el punto de vista administrativo la organización de eventos es el proceso de planificar y coordinar todos los recursos disponibles, humanos, materiales y financieros, con el fin de conseguir unos objetivos establecidos con máxima eficiencia y al menor costo posible. La organización de eventos lleva consigo cuatro etapas fundamentales:

 Planificación: Previsión y planeación.

 Organización: Integración y coordinación.

 Ejecución: Puesta en marcha y dirección.

 Control: Evaluación y resultados.

Dentro de esas etapas generales que aparecen en la organización de un evento, se pueden establecer actividades puntuales, que se especifican a continuación:

(19)

19

 Tipo de evento: Al tener definida la temática del evento se hace posible establecer el tipo de evento que se busca organizar, lo que a futuro permite encontrar factores comunes o diferenciales entre eventos organizados en el pasado y así realizar correcciones frente a posibles errores cometidos.

 Objetivos del evento: Es importante tener claro desde el principio, cuales son los objetivos y resultados que se esperan alcanzar, y garantizar que en todas las etapas propias de la gestión del evento como la planificación, organización e implementación del este se trabaje en busca de conseguir esos resultados esperados.

 Lugar del evento: Seleccionar el lugar adecuado para la celebración de un evento es un factor importante para conseguir los objetivos que esperan ser logrados. Esta selección del lugar, está relacionada con el alcance o dimensión que se espera del evento, teniendo en cuenta el número de participantes que se esperan y las actividades a realizar durante el evento. Es conveniente tener varias alternativas con el fin de seleccionar la opción más adecuada, teniendo en cuenta la ubicación geográfica del lugar, los servicios ofrecidos, el nivel de estos, el ambiente y los precios.

 Agenda o cronograma del evento: Cuando se tiene experiencia en organización de eventos de diferentes tipos, y se conoce el tipo de participantes, es fundamental plantear una agenda dinámica y que garantice el interés de los asistentes, sin llegarlos a sobrecargar.

(20)

20

puntualidad de las actividades, lo que va a generar credibilidad por parte de los asistentes hacia los organizadores del evento.

 Fecha del evento: La selección de una fecha adecuada para la celebración de un evento, busca que los posibles participantes en general no vayan a tener el impedimento de asistir por otras actividades que se crucen con la fecha de celebración del evento.

Según el tipo de evento y conociendo lo que le puede llegar a interesar a los participantes, se puede seleccionar una fecha que garantice la asistencia de la mayor parte de invitados.

 Evaluación y control: Generalmente se comete el error de pensar que con la culminación, cierre o clausura de un determinado evento, del mismo modo se terminan las actividades que realizan los organizadores del evento, y se olvida la importancia de realizar un balance y una evaluación final de las actividades realizadas, que permita determinar si se cumplieron o no los objetivos y resultados que esperaban ser obtenidos.

Esta evaluación final con el paso del tiempo y la organización de mayor numero de eventos, permitirá generar una retroalimentación constante que garantice una mejora continua en la gestión de eventos.

4.2.2 Sociedad Colombiana de Ortodoncia:

(21)

21

Sociedad -CESCO-, cuyo programa académico cumpla además con los requisitos vigentes del ente gubernamental o estatal encargado de establecer la reglamentación de educación de posgrado.”1

4.2.3 Eventos de la Sociedad Colombiana de Ortodoncia:

“La Sociedad Colombiana de Ortodoncia realiza actividades gremiales, científicas y académicas, que junto con un amplio portafolio de servicios y de iniciativas comerciales, permite la generación sostenida de valor para sus grupos de interés y el mejoramiento continúo en la práctica de la Ortodoncia.”2

Uno de los eventos más importantes que organiza la Sociedad Colombiana de Ortodoncia es el Congreso Internacional de Ortodoncia, al que asisten conferencistas de diferentes países y donde se reúnen asociados, estudiantes y personas interesadas del ámbito de la ortodoncia de todo el país.

4.2.4 Gestión de los eventos de la SCO:

Actualmente la Sociedad Colombiana de Ortodoncia realiza la gestión de los eventos que organiza por medio de la contratación de empresas de logística.

4.2.5 Software Libre:

Se refiere al tipo de licencias de software que garantiza la libertad de los usuarios para ejecutar, copiar, distribuir, estudiar, cambiar y mejorar el software.

1_{SOCIEDAD COLOMBIANA DE ORTODONCIA – Acerca de SCO, [en línea]. [citado 25 de marzo de 2014].}

Disponible en la web: http://www.sco.com.co/nosotros.aspx

2_{SOCIEDAD COLOMBIANA DE ORTODONCIA. Misión, Visión y Objetivos de la SCO, [en línea]. [citado 25 de}

(22)

22

4.2.6 Ingeniería de Software:

Es la disciplina que busca aplicar diferentes teorías, métodos y herramientas en todo el proceso de desarrollo del software, desde el análisis hasta el mantenimiento del mismo, buscando siempre la mejor opción; esta no se enfoca meramente en la parte técnica del proceso, sino también en las actividades de gestión de la fuerza de trabajo para obtener un producto de calidad y el costo más bajo posible.3

4.2.7 Arquitectura de Software:

Es la representación del software independientemente del leguaje y algoritmos usados; permite ver el sistema como una serie de componentes visibles externamente, jerarquizados y relacionados entre sí que ayudan a los ingenieros a reducir los riesgos asociados al desarrollo del software, mirando así la efectividad del diseño para cumplir los objetivos trazados.4

4.2.8 Arquitectura Empresarial:

Es una metodología que busca estructurar gráficamente, desde una visión integral, todos los componentes y requerimientos de una organización, enfocada en cuatro dimensiones principales, las cuales son: negocios, información aplicaciones y tecnología.5

.

3_{PRESSMAN, Roger S. Ingeniería del Software: Un Enfoque Práctivo. Quinta Edición. Mc Graw Hill. México,}

2002. pag. 14

4_{PRESSMAN, Roger S. Ingeniería del Software: Un Enfoque Práctivo. Quinta Edición. Mc Graw Hill. México,}

2002. pag. 238

5 _{AMAZING TM. Arquitectura Empresarial [Citado en 20 Julio de 2015] Disponible en la web:}

(23)

23

4.2.9 Archimate:

Es un lenguaje de modelado de arquitectura, que brinda un estándar para describir de forma gráfica las relaciones entre los dominios de negocio de una compañía .

4.2.10 UML:

El lenguaje unificado de modelado es un estándar para describir gráficamente los componentes de un software abordado desde distintos ángulos. Varias

empresas importantes en el campo del desarrollo de software han participado en el perfeccionamiento de este lenguaje, que actualmente se encuentra en la versión 2.

4.2.11 MVC:

Es un patrón arquitectónico que busca separar la visualización de los datos de su procesamiento. Es el más utilizado en el desarrollo de aplicaciones WEB, ya que facilita la escalabilidad y la mantenibilidad del sistema, evitando así combinar diferentes lenguajes de programación en un mismo archivo de código.6

4.2.12 Sistema de Base de Datos:

“Un sistema de base de datos es básicamente un sistema computarizado para guardar registros; es decir es un sistema computarizado cuya finalidad general

6_{BAHIT, Eugenia. POO y MVC en PHP: El paradigma de la Programación Orientada a Objetos en PHP y el}

(24)

24

es almacenar información y permitir a los usuarios recuperar y actualizar esa información con base en peticiones”7_.

4.2.13 Aplicación Web:

“En la ingeniería de software se denomina aplicación web a aquellas herramientas que los usuarios pueden utilizar accediendo a un servidor web a través de Internet o de una intranet mediante un navegador. En otras palabras, es una aplicación software que se codifica en un lenguaje soportado por los navegadores web en la que se confía la ejecución al navegador”8_.

4.2.14 Symfony2:

Es un framework PHP basado en la arquitectura MVC, que se basa en un controlador normal que dirige todas las peticiones a los distintos controladores en base a unas rutas previamente establecidas. Symfony2 está compuesto por las siguientes tecnologías:

 Twig: Es el motor de plantillas PHP que usa el Framework para mostrar la información al usuario; está compuesto por unas etiquetas generalmente {% %} y {{ }}, en base a las cuales se pueden generar ciclos, condicionales, importaciones de otras plantillas, visualización de información, etc.

 Doctrine2: Es un framework ORM, que se encarga de realizar la comunicación entre el sistema y la base de datos, permitiendo gestionar el almacenamiento y consulta de información sin que el usuario tenga que

7 _{DATE, C.J. Introducción a los sistemas de bases de datos. ¿Qué es un sistema de base de datos? Séptima}

Edición. Pearson Educación. México, 2004. pag. 5

(25)

25

generar consultas SQL. Está compuesto de métodos que permiten obtener fácilmente información almacenada en base de datos.

 YAML: Es un lenguaje de marcado con el cual el framework almacena gran parte de la configuración del sistema, el cual busca emular la funcionalidad de los archivos XML, pero de forma mucho más legible.

4.2.15 Metodologías Ágiles:

En el año 2001 un grupo de expertos, se reunió con el fin de discutir y llegar a un consenso acerca de las formas en las cuales cada uno hacía su trabajo. En esta reunión se llamaron a sí mismos “La Alianza Ágil” y definieron doce principios, los cuales dieron vida al manifiesto ágil.

En estos doce principios se indica que lo más importante es realizar liberaciones tempranas al cliente, con las cuales se podrá recibir frecuentemente una retroalimentación de lo realizado hasta el momento y que además, darán un valor agregado al producto; por lo cual se debe dar prioridad a la funcionalidad del software antes que a una documentación extensiva. Para lograr esto es necesaria una comunicación constante y cara a cara con el cliente, con lo cual se podrá evaluar el cumplimiento de los requerimientos o la posible generación de unos nuevos.

Igualmente se requiere un equipo auto organizado, motivado y comprometido con el proyecto, el cual deberá encontrar la manera más simple y efectiva de realizar lo esperado, buscando realizar las tareas con excelencia en todos los aspectos, ya que esto va en pro de la agilidad. Además de manera regular el equipo deberá reflexionar de lo que se ha realizado y cómo se ha realizado, para así ajustar el funcionamiento del mismo.9

9_{HUNDERMARK, Peter. Un Mejor Scrum, [en línea]. [citado 26 de marzo de 2014]. Disponible en la web:}

(26)

26

4.2.16 Scrum:

“Scrum es un marco de trabajo iterativo e incremental para el desarrollo de proyectos, productos y aplicaciones”10_{, además hace parte de las llamadas}

metodologías ágiles de desarrollo de software.

 Sprint: Un Sprint es una iteración de Scrum, la cual debe tener una duración entre 2 y 4 semanas. En este se traza una meta, la cual debe representar un valor agregado para el cliente, para lograr esto se proponen unas tareas a desarrollar; estas normalmente son de 8 horas, no deben cambiarse a lo largo del Sprint e idealmente se deben completar todas.

 Roles en Scrum:

o Product Owner: El “dueño del producto” es aquel que identifica las funcionalidades que proveerá el producto (Product Backlog) y las ordena por prioridad y periódicamente las reorganiza. En algunos casos el dueño de producto puede ser el cliente.

o Scrum Master: Es aquel que trabaja en pro de establecer las condiciones ideales para que el Scrum Team desarrolle su trabajo. Además es el encargado de velar por la buena aplicación de Scrum durante el desarrollo. Normalmente es el director de proyectos.

o Scrum Team: El Scrum Team es aquel que va a desarrollar el proyecto, con lo cual se comprometen a entregar incrementos funcionales de software con calidad de producción, para lo cual debe determinar los ítems de backlog que se incluirán en el mismo. Es el

10_{DEEMER, Peter, BENEFIELD, Gabrielle, LARMAN, Craig, VODDE, Bas. INFORMACIÓN BÁSICA DE SCRUM.}

(27)

27

encargado de gestionarse a sí mismo para lograr cumplir con los objetivos trazados.11

 Product Backlog: Es una lista priorizada que realiza el product owner con posible colaboración del cliente, en la cual se consignan de una manera priorizada todas las funcionalidades que se van a incluir en el producto.12

 Reuniones en Scrum:

o Sprint Planning: Es una reunión en la cual se toman algunos ítems del product backlog en orden de prioridad, los cuales son los que se van a desarrollar durante el sprint; igualmente se define en esta un objetivo a cumplir con el desarrollo del sprint.13

o Scrum Daily: Es una corta reunión diaria que realiza el scrum team, en la cual se lleva un control del avance de las tareas de cada integrante del equipo, igualmente se discuten soluciones a problemas que van apareciendo. No debería durar más de 15 minutos y normalmente se realiza al iniciar la jornada.

o Sprint Review: Es una reunión que no debería durar más de 4 horas en la cual se realiza una revisión del trabajo de lo que se terminó y faltó si es el caso del sprint; igualmente el equipo hace una demostración al product owner y demás interesados en el producto todo el trabajo completado.

11_{DEEMER, Peter, BENEFIELD, Gabrielle, LARMAN, Craig, VODDE, Bas. INFORMACIÓN BÁSICA DE SCRUM.}

Versión 1.1, 2009. p 5

12_{GONZÁLEZ RODRÍGUEZ, PILAR. Tesis de Máster. Estudio de la aplicación de metodologías ágiles para la}

evolución de productos de software, [en línea]. [citado 26 de marzo de 2014]. Disponible en la web: http://oa.upm.es/1939/1/TESIS_MASTER_PILAR_RODRIGUEZ_GONZALEZ.pdf p. 32

13_{GONZÁLEZ RODRÍGUEZ, PILAR. Tesis de Máster. Estudio de la aplicación de metodologías ágiles para la}

(28)

28

o Sprint Retrospective: En esta reunión, cada uno de los integrantes del equipo, brinda su opinión del rumbo que tomó el desarrollo del sprint, identificando cosas buenas, malas y proponiendo mejoras para el sprint siguiente. El principal objetivo de esta retrospectiva es asegurar una mejor aplicación de la metodología en cada sprint. Luego de esto se procede a planear el siguiente sprint. 14

A continuación se muestra una imagen, que ilustra brevemente el proceso que se utiliza en la metodología Scrum.

Figura 1: Esquema de proceso básico de SCRUM

Fuente: Elaboración propia.

(29)

29

5. ALCANCES Y LIMITACIONES

5.1 ALCANCES

Es muy importante aclarar que el sistema es un prototipo, que se desarrolló para una necesidad particular de la SCO, sin embargo se desarrolló de tal forma que se puedan realizar modificaciones y agregar nuevas funcionalidades para adaptarlo a cualquier otra compañía.

Además el sistema tendrá únicamente versión web para equipos de cómputo, ya sea computadores portátiles u ordenadores de escritorio.

En cuanto a funcionalidad, el sistema permite crear nuevos eventos, de los cuales se podrán especificar sus características principales (algunas son el nombre, fechas de inscripción y realización, conferencistas, ubicación, entre otros), además de postergarlos o cancelarlos. Igualmente los asistentes a un evento específico, se podrán registrar inicialmente a la aplicación y además buscar y realizar la inscripción a un evento y recibir una escarapela impresa por la asistencia a este.

Igualmente la aplicación tiene algo fundamental para cualquier software, el control de usuarios; estos tienen diferentes roles en la aplicación, que se pueden definir básicamente en administrador de eventos (aquel que se encarga de gestión de los eventos y de revisar los reportes) y el rol de registrador, que es aquel que ingresa los asistentes, los inscribe a los eventos y les genera la escarapela de asistencia.

(30)

30

importantes como los ingresos obtenidos por la sociedad (a un evento en particular o a todos los que se han realizado), el número de asistentes, entre otros. Esto para apoyar la toma de decisiones de la SCO.

5.2 LIMITACIONES

La principal limitante fue el tiempo, dado que los integrantes pudieron dedicarle aproximadamente 2 horas diarias entre semana, 4 la mayor los sábados y 6 en varios domingos, lo cual dilató el desarrollo del proyecto un poco más de lo que se esperaba.

También en algunos casos se tuvo en espera el inicio del sprint, dado que también se dependía de la disponibilidad de las personas de la SCO, quienes en algunas temporadas estuvieron bastante ocupados y se dejaba pasar un tiempo importante sin realizar la retroalimentación de los requerimientos solicitados.

(31)

31

6. DISEÑO DE LA INVESTIGACIÓN

6.1 TIPO DE ESTUDIO

El proyecto realizado fue de tipo desarrollo tecnológico, ya que el resultado final fue una aplicación web para la gestión de los eventos organizados por la Sociedad Colombiana de Ortodoncia.

6.2 PARTICIPANTES

Para la realización del proyecto, se tuvo el apoyo del docente Sandro Bolaños quien actuó como director del trabajo de grado y estuvo dispuesto a dar sus aportes en pro de la exitosa finalización del desarrollo y la documentación.

Además se estuvo en contacto frecuente con los encargados de la gestión de los eventos en la SCO, con quienes se realizaron reuniones al iniciar cada sprint para confrontar los avances del proyecto con las expectativas que tenían con respecto a la aplicación.

6.3 INSTRUMENTOS Y EQUIPOS

Para la elaboración de la documentación y el sistema web, se tuvieron a disposición los computadores personales de los estudiantes que desarrollaron el proyecto.

(32)

32

(33)

33

7. METODOLOGÍA DE LA INGENIERÍA DEL PROYECTO

7.1 METODOLOGÍA DEL PROYECTO

Para el desarrollo del prototipo web de Gestión de Eventos de la Sociedad Colombiana de Ortodoncia, se hizo uso de la metodología ágil SCRUM, ya que dadas las características del proyecto, esta metodología permitió una interacción directa con el cliente, de tal forma que este se comprometió con el proyecto y así pudo ver su evolución con cada iteración.

Además, el cliente pudo ir redefiniendo ciertas características del prototipo web, según iban cambiando las necesidades de la organización, ya que pudo introducir cambios funcionales, que no afectaban el enfoque principal del proyecto y así se fue dando prioridad al desarrollo de las funcionalidades que más se necesitaban.

A continuación se mencionan los principales beneficios que se obtuvieron del uso de la metodología SCRUM que se adoptó para el desarrollo de este proyecto:

 Flexibilidad a cambios.

 Reducción de riesgos.

 Predicciones de tiempos.

 Mayor calidad del software.

 Cumplimiento de expectativas.

(34)

34

representa a los stakeholders (clientes externos o internos), y el Development Team que incluye a los desarrolladores.

A continuación se muestran los roles desempeñados por los integrantes del equipo:

Tabla 1: Roles SCRUM de los integrantes

ROL SCRUM

PERSONA Product Owner Scrum Master

Development

Team

Manuel Alejandro Barragán Velázquez

Johan Andrés Bustos Amaya

Fuente: Elaboracion propia.

Durante cada sprint de la metodología, los cuales se llevaron a cabo en períodos aproximados de entre dos y cuatro semanas dependiendo de los requerimientos, se hicieron entregas incrementales del prototipo, que eran liberadas para pruebas de los usuarios finales y con las que se pudo realizar una retroalimentación constante de las necesidades y así se presento una interacción constante entre el cliente y el equipo con un fin en común que era este prototipo web.

El conjunto de características que forma parte de cada sprint se estableció por medio del Product Backlog, que es el conjunto de requerimientos organizados por prioridad y que permitió definir el trabajo a realizar durante cada sprint.

(35)

35

esos requerimientos eran analizados por los integrantes del equipo con el fin de determinar los entregables para cada sprint.

Antes de iniciar cada sprint, se elaboró un documento llamado Sprint Backlog

en donde se describía como se hará la implementación de los requerimientos durante el siguiente sprint. Las tareas se dividieron en horas con ninguna tarea con duración mayor a 16 horas.

A lo largo del desarrollo del proyecto se tuvo en cuenta que una de las principales características de la metodología SCRUM es el reconocimiento de que en cualquier momento del desarrollo del proyecto el cliente, en este caso la Sociedad Colombiana de Ortodoncia, realizó cambios en los requerimientos, teniendo en cuenta los alcances y limitaciones establecidos antes de iniciar el proyecto.

Durante cada sprint se realizó una reunión aproximadamente cada tres días (dada la disponibilidad) llamada Daily Scrum, en la cual los integrantes del equipo de desarrollo socializaban acerca del estado general de la implementación del sistema y de las tareas que se han estado desarrollando, con el fin de dar solución a los problemas que se fueron generando durante el proceso.

Luego, al finalizar cada sprint se hizo la reunión denominada Sprint Review

Meeting, en la cual se evaluaron las tareas del Sprint Backlog, revisando lo

que se realizó con éxito, lo que se tenía que ajustar y lo que no se realizó y pasaba al siguiente sprint.

(36)

36

(37)

37

8. CONSTRUCCIÓN DEL PROTOTIPO

8.1 ANÁLISIS

8.1.1 Arquitectura Empresarial

 Modelado Archimate Punto de Vista de la Organización

Figura 2: ModeladoArchimate – Punto de Vista de la Organización

(38)

38

 Modelado Archimate Punto de Vista de la Función de Negocio

Figura 3: Modelado Archimate – Punto de Vista de la Función de Negocio

(39)

39

 Modelado Archimate Punto de Vista de los Procesos

Figura 4: Modelado Archimate – Punto de Vista de los Procesos

Fuente: Elaboración propia

(40)

40

 Modelado Archimate Punto de Vista del Producto

Figura 5: Modelado Archimate – Punto de Vista del Producto

(41)

41

 Modelado Archimate Comportamiento de la Aplicación

Figura 6: Modelado Archimate – Comportamiento de la Aplicación

(42)

42

8.1.2 Requerimientos Funcionales

Tabla 2: Requerimientos Funcionales

Requerimiento Código Prioridad Descripción

Autenticar Usuario RF - 001 Alta Cada usuario tiene un nombre de usuario y una contraseña que debe ingresar al iniciar la aplicación y que es validado por la base de datos para permitir el inicio de sesión y acceder a las funcionalidades del sistema. CRUD Usuario RF - 002 Alta El Súper Usuario crea, obtiene, actualiza e

inactiva los usuarios del sistema.

CRUD Proveedor RF - 003 Media El Administrador crea, obtiene, actualiza e inactiva los proveedores.

CRUD Servicio

Proveedor RF - 004 Media El Administrador crea, obtiene, actualiza e inactiva los servicios que ofrece un proveedor para un evento.

CRUD Cuenta

Proveedor RF - 005 Media El Administrador crea, obtiene, actualiza e inactiva las cuentas bancarias de los proveedores.

CRUD Seccional RF - 006 Alta El Administrador crea, obtiene, actualiza e inactiva las seccionales de la SCO.

CRUD Tipo Evento RF - 007 Alta El Administrador crea, obtiene, actualiza e inactiva los tipos de evento organizados por la SCO.

CRUD Evento RF - 008 Alta El Administrador crea, obtiene, actualiza e inactiva los eventos organizados por la SCO. Cargue Masivo

Posibles Asistentes RF - 010 El Administrador hace un cargue masivo inicial de posibles asistentes a un evento. Registrar Inscripción RF - 011 Alta El Registrador realiza la inscripción de un

asistente a un evento.

Eliminar Inscripción RF – 012 Alta El Registrador cancela una inscripción a un evento previamente registrada.

Imprimir Escarapela El Registrador imprime la escarapela de una asistente registrado en un evento.

Listar Inscripción RF – 013 Alta El Administrador puede listar una inscripción determinada.

Listar Eventos RF – 014 Alta El Administrador y/o el Registrador pueden listar los eventos según su estado: abierto, cerrado, cancelado, finalizado, activo.

Listar Inscripciones

Evento RF – 015 Alta El Administrador puede listar las inscripciones de un evento dadas algunas características del evento.

Cerrar Evento RF – 016 Alta El Administrador hace el cierre o liquidación de un evento.

Consultar

Estadísticas Evento RF – 017 Alta El estadísticas asociadas a un evento: costo Administrador puede consultar las total, cupo máximo, número de inscripciones, total recaudado.

(43)

43

8.1.3 Requerimientos No Funcionales

Tabla 3: Requerimientos No Funcionales

Requerimiento Código Descripción

Seguridad RNF - 001 Garantizar la confiabilidad, la seguridad y el desempeño del sistema a los diferentes usuarios.

Disponibilidad RNF – 002 El sistema debe estar en capacidad de dar respuesta al acceso de todos los usuarios.

Disponibilidad RNF – 003 La aplicación debe estar disponible en todo momento.

Usabilidad RNF – 004 La aplicación debe operar de igual forma para todos los usuarios.

Metodología de Desarrollo

RNF – 005 El sistema debe ser construido sobre la base de un desarrollo evolutivo e incremental.

Escalabilidad RNF – 006 El sistema debe estar en capacidad de permitir en el futuro el desarrollo de nuevas funcionalidades, modificar o eliminar funcionalidades después de su construcción y puesta en marcha inicial.

Mantenimiento RNF – 007 El sistema debe estar en capacidad de permitir en el futuro su fácil mantenimiento con respecto a los posibles errores que se puedan presentar durante la operación del sistema.

(44)

44

8.2 DISEÑO

8.2.1 Diagrama de Contexto

Figura 7: Diagrama de Contexto del Sistema

(45)

45

8.2.2 Diagramas de Casos de Uso

 Diagrama General de Casos de Uso

Figura 8: Diagrama General de Casos de Uso

(46)

46

 Diagrama Caso de Uso Iniciar Aplicación

Figura 9: Diagrama Caso de Uso Iniciar Aplicación

 Diagrama Caso de Uso Gestionar Evento

Figura 10: Diagrama Caso de Uso Gestionar Evento

(47)

47

 Diagrama Caso de Uso Gestionar Asistente

Figura 11: Diagrama Caso de Uso Gestionar Asistente

 Diagrama Caso de Uso Registrar Asistente

Figura 12: Diagrama Caso de Uso Registrar Asistente

(48)

48

 Diagrama Caso de Uso Imprimir Escarapela

Figura 13: Diagrama Caso de Uso Imprimir Escarapela

 Diagrama Caso de Uso Generar Reporte

Figura 14: Diagrama de Caso de Uso Generar Reporte

(49)

49

8.2.3 Historias de Usuario

 Historia de Usuario Iniciar Aplicación

Tabla 4: Historia de Usuario Iniciar Aplicación

Historia de Usuario

Número: 1 Usuario: Usuario General

Nombre historia: Iniciar Aplicación

Tipo historia de usuario :

Prioridad en negocio: Alta Complejidad en desarrollo: Media

Horas Estimadas: 45 Iteración asignada:1

Desarrollador: Desarrollador 2

Precondiciones:

 URL de acceso al prototipo web Descripción:

Se requiere que el sistema pueda ser accedido vía web, mediante una URL que direcciones a una página de inicio de sesión, en donde se ingrese un nombre de usuario y una contraseña y el sistema haga la validación correspondiente para que un usuario pueda loquearse en la aplicación.

Criterios de Aceptación:

- El nombre de usuario debe ser único para cada usuario del sistema.

- No se debe permitir el ingreso a una URL del sistema si no se ha realizado el inicio de sesión.

- Después de cierto tiempo de inactividad en el sistema, este debe cerrar la

sesión del usuario.

(50)

50

 Historia de Usuario Gestionar Evento

Tabla 5: Historia de Usuario Gestionar Evento

Número: 2 Usuario: Administrador

Nombre historia: Gestionar Evento

Desarrollador: Desarrollador 1

Precondiciones:

 Sesión iniciada con usuario perfil Administrador

Descripción:

Se requiere que el sistema permita la gestión o parametrización de un evento, es decir; la creación, lectura, actualización e inactivación de los eventos

(51)

51

Datos solicitados:

 Nombre del evento

 Fecha inicio

 Fecha fin

 Ciudad

 Lugar del Evento

 Estado

 Observaciones

Validaciones:

 Unicidad: No se debe permitir el ingreso de un evento con un nombre ya registrado.

 Campos obligatorios: Nombre, fecha inicio, fecha fin, ciudad, lugar, estado.

 Campos alfanuméricos: Nombre, lugar.

 Campos combos selección: ciudad, estado.

- El sistema debe permitir el CRUD de los eventos organizados por la SCO.

- El sistema debe garantizar todas las validaciones mencionadas.

(52)

52

 Historia de Usuario Gestionar Asistente

Tabla 6: Historia de Usuario Gestionar Asistente

Número: 3 Usuario: Administrador/Registrador

Nombre historia: Gestionar Asistentes

(53)

53

Precondiciones:

 Sesión iniciada con usuario Administrador/Registrador

 Se requiere tener un evento creado.

Descripción:

El sistema debe permitir la gestión de los asistentes, es decir que el usuario del sistema puede crear, ver, editar, y eliminar los posibles asistentes a un evento.

El sistema debe ofrecer al usuario la posibilidad de inscribir los asistentes (nuevos o ya existentes en el sistema) a un evento.

Datos solicitados:

 Nombre completo del asistente

 Tipo de identificación

 Documento de identidad

 Fecha de nacimiento

 Edad

 Ocupación

 Institución en la que se desempeña (trabajando o estudiando)

 Nivel de educación

 Teléfono

 Correo electrónico

Validaciones:

 Unicidad: No se debe permitir el ingreso de un asistente con un documento ya existente en el sistema.

(54)

54

nacimiento, nivel de educación, correo electrónico.

 Campos alfanuméricos: Campos del nombre, institución, correo electrónico.

 Campos combos selección: Ocupación, nivel educativo.

 Campos numéricos: Documento, Edad, Teléfono

 Campos de fecha: Fecha de nacimiento.

- El sistema debe permitir el CRUD de los asistentes a los eventos.

- El sistema debe garantizar todas las validaciones mencionadas.

- El sistema debe permitir generar un registro histórico de las asistencias a

los eventos de un asociado.

(55)

55

 Historia de Usuario Imprimir Escarapela

Tabla 7: Historia de Usuario Imprimir Escarapela

Número: 4 Usuario: Registrador

Nombre historia: Imprimir Escarapela

Prioridad en negocio: Alta Complejidad en desarrollo: Baja

Horas Estimadas: 45 Iteración asignada:1 Desarrollador: Desarrollador 1

(56)

56

 El usuario que solicita debe estar inscrito al evento y haber realizado el pago (si lo requiere).

Descripción:

El funcionario de la SCO confirma que el asistente realizó el pago y le imprime su respectiva escarapela.

Validaciones:

 Solo se pueden imprimir escarapelas durante el(los) día(s) del evento.

- Solo se podrán imprimir escarapelas a quienes hayan realizado el pago del ingreso.

- El sistema deberá generar automáticamente el formato de la escarapela

con la información requerida.

Bosquejo Pantalla:

(57)

57

 Historia de Usuario Generar Reporte

Tabla 8: Historia de Usuario Generar Reporte

Número: Usuario: Administrador

Nombre historia: Generar Reporte

Tipo historia de usuario : 5

Desarrollador: Desarrollador2

Precondiciones:

 Sesión iniciada con usuario Administrador

Descripción:

Se requiere que el sistema tenga un modulo de reportes que permita generar reportes de los siguientes tipos:

- Tabla

- Excel

- Gráfico

El usuario Administrador ingresa a un modulo de reportes en el que encuentra una lista de reportes que puede generar, ya sea una Tabla en pantalla, un archivo Excel o un una Grafica (barras, torta, etc).

La lista de reportes a generar en este modulo es la siguiente:

- Asistentes a un evento (Excel): Este informe permite generar un excel

con los datos de las personas que asisten a un determinado evento

- Eventos por asistente: Este informe muestra el número de eventos a los que ha ido cada asistente.

(58)

58 han realizado de cada tipo.

- Total asistentes por evento: Este informe muestra el número total de

asistentes por cada evento.

- Total recaudado por evento: Este informe muestra la cantidad de dinero

que se recaudó en el evento.

- Total de asistentes por tipo de evento: Tipos de evento en los cuales asistieron más personas.

- Conferencistas por evento: Listado de los conferencistas participantes

de un evento.

- El usuario Administrador es el único usuario con permisos para generar

reportes

- El usuario puede generar reportes Grafico, Tabla o Excel.

Bosquejo pantalla:

(59)

59

8.2.4 Diagramas de Actividades

 Diagrama de Actividades Iniciar Aplicación

Figura 15: Diagrama de Actividades Iniciar Aplicación

(60)

60

 Diagrama de Actividades Gestionar Evento

Figura 16: Diagrama de Actividades Gestionar Evento

(61)

61

 Diagrama de Actividades Registrar Asistente

Figura 17: Diagrama de Actividades Registrar Asistente

(62)

62

 Diagrama de Actividades Imprimir Escarapela

Figura 18: Diagrama de Actividades Imprimir Escarapela

(63)

63

 Diagrama de Actividades Generar Reporte

Figura 19: Diagrama de Actividades Generar Reporte

(64)

64

8.2.5 Modelo Relacional

Figura 20: Modelo Relacional Base de Datos

(65)

65

8.3 IMPLEMENTACIÓN

8.3.1 Modelo Arquitectónico

Para la implementación del Prototipo Web Gestión Eventos SCO se utilizó un modelo arquitectónico de tres capas (presentación, negocio y datos). A continuación se hace un análisis de las principales características de cada capa y las herramientas utilizadas en cada una de estas para el correcto desarrollo de este proyecto.

Tabla 9: Modelo Arquitectónico

Capa Presentación Capa Negocio Capa Datos

Herramientas:

 HTML / Twig

 Javascript / Jquery

Herramientas:

 PHP / Symfony2

Herramientas:

 MySQL

Capa de Presentación: Para la implementación de la capa de presentación se utilizaran las siguientes herramientas:

 HTML / Twig: Se utilizó el motor de plantillas twig desarrollado por Sensio Labs para el manejo de la interfaz gráfica de usuario (GUI), el cual consiste en código HTML con algunas etiquetas especiales para representar variables, condicionales, ciclos, extensión de plantillas, etc.

Capa de Negocio: Para la implementación de la capa de lógica del negocio se utilizaran las siguientes herramientas:

(66)

66

 Symfony2: Para la implementación de la capa de negocio se utilizó el framework de PHP Symfony, ya que facilita el uso del patrón MVC, lo cual se ajusta al objetivo del sistema.

 Doctrine2: Esta será la herramienta a utilizar como mapeador objeto-relacional (ORM) entre la capa de negocio y la capa de datos, la cual se integra muy bien con Symfony2.

Capa de Datos: Para la implementación de la capa de datos se utilizaran las siguientes herramientas:

(67)

67

8.3.2 Diagrama de Clases

 Clase Usuario

Figura 21: Diagrama de Clases – Contexto Usuario

class Class Model User - createEditForm(Usuario, var): var + updateAction(Request, var): var + deleteAction(Request, var): var - createDeleteForm(var, var): var + cambiarContrasenaAction(): var

+ buildForm(FormBuilderInterface, array): var + setDefaultOptions(OptionsResolverInterface): var - addDepartamentoForm(var, var, var): var + preSetData(FormEvent): var - addCiudadForm(var, var): var + preSetData(FormEvent): var - addPaisForm(var, var): var + preSetData(FormEvent): var

(68)

68

 Clase Evento

Figura 22: Diagrama de Clases – Contexto Evento

class Class Model Ev ento

Controller + updateAction(Request, var): var + deleteAction(Request, var): var - createDeleteForm(var): var + buscaAsistentesAction(var): var + insertarAsistentesAction(Request, var): var + importarAsistentesAction(): var + subirAsistentesAction(Request): var + verAyudaMasivoAction(): var + cargarAsistentesMasivoAction(): var + quitarAsistentesAction(Request, var): var + paginarAsistentesAction(Request, var): var + buscaConferencistasAction(Request): var + verEscarapelaAction(var): var + actualizarCronogramaAction(Request, var): var - crearFiltros(var): var + buildForm(FormBuilderInterface, array): var + setDefaultOptions(OptionsResolverInterface): var

(69)

69

 Clase Asistente

Figura 23: Diagrama de Clases – Contexto Asistente

class Class Model Asistente + updateAction(Request, var): var + deleteAction(Request, var): var - createDeleteForm(var): var

+ buildForm(FormBuilderInterface, array): var + setDefaultOptions(OptionsResolverInterface): var - addDepartamentoForm(var, var, var): var + preSetData(FormEvent): var - addCiudadForm(var, var): var + preSetData(FormEvent): var - addPaisForm(var, var): var + preSetData(FormEvent): var

(70)

70

8.3.3 Mapa de Navegación

 Mapa de Navegación Primera Parte

Figura 24: Mapa de Navegación Primera Parte

(71)

71

 Mapa de Navegación Segunda Parte

Figura 25: Mapa de Navegación Segunda Parte

(72)

72

8.3.4 Usuarios del Sistema

Tabla 10: Usuarios y Privilegios del Sistema

Rol Descripción/Privilegios

Usuario General

Es un usuario/rol abstracto, ya que no es un usuario real para el sistema, pero que representa las funcionalidades generales del resto de usuarios como son:

 Iniciar aplicación

 Iniciar sesión

 Cerrar sesión

 Cerrar aplicación

Todos los otros usuarios heredan estas funcionalidades del Usuario General.

Súper Usuario  CRUD de usuarios

Administrador Encargado de todas las funciones relacionadas con la parametrización y con la gestión de los eventos:

 CRUD de proveedor.

 CRUD de conferencista

 CRUD de seccional.

 CRUD de tipo de evento.

 CRUD de evento.

Realiza las funciones de consultas:

 Listar Eventos según estado

 Listar inscripciones de un evento

 Consultar estadísticas de un evento

- Número de Inscripciones, Total Recaudado, Conferencistas Contratados, Cantidad de Eventos

Registrador Realiza todas las funciones relacionadas con el registro de inscripciones a los eventos.

 Registrar inscripción de un asistente a un evento.

 Eliminar inscripción de un asistente a un evento.

 Imprimir escarapela de asistente.

(73)

73

8.3.5 Seguridad y control de acceso

En el sistema, se tienen en cuenta cuatro roles de acceso, los cuales van a restringir la información a la que tiene acceso cada una de las personas.

 Usuario general: Es un rol abstracto, del cual extienden los demás usuarios y representa la capacidad de acceder a la aplicación y realizar cambios en su información personal registrada en el sistema.

 Súper Administrador: Es aquel que tiene acceso a todas las funcionalidades del sistema; este rol se aplicó para las personas que participaron en el desarrollo de la herramienta, para poder realizar pruebas a la misma.

 Administrador: Este rol permite al usuario realizar las mismas funcionalidades que el rol anterior, a diferencia que él no registra a los asistentes a los eventos.

(74)

74

8.3.6 Diagramas de Secuencias

 Diagrama de Secuencia Crear Evento

Figura 26: Diagrama de Secuencia Crear Evento

sd Crear ev entos

Administrador

app.php

Ev entoController

EntityManager

routing MySql

Listado Eventos Listado Eventos

Otra acción Otra acción

«Muestra Formulario Creación»

«insert» «TWIG»

render() createAction(request)

«TWIG» request(evento_new)

request(evento_create)

persist(Evento) render()

Clic:Crear(Info Evento) Clic:Nuevo()

«Muestra Detalle Evento»

newAction(request)

flush()

(75)

75

 Diagrama de Secuencia Crear Asistente

Figura 27: Diagrama de Secuencia Crear Asistentes

sd Crear asistentes

app.php routing EntityManager MySql

Registrador

AsistenteController

Listado Asistentes Listado Asistentes

«TWIG» «TWIG» Clic:Nuevo()

request(asistente_new)

render()

createAction(request)

«insert» persist(Asistente)

«Muestra Detalle Asistente» Clic:Crear(Info Asistente)

newAction(request)

flush() request(asistente_create)

render() «Muestra Formulario Creación»

(76)

76

 Diagrama de Secuencia Crear Asistentes Masivo

Figura 28: Diagrama de Secuencia Crear Asistentes Masivo

sd Ingreso Masiv o Asistentes

Registrador

app.php routing

AsistenteController

EntityManager MySql

loop

Excel Asistentes Excel Asistentes

render() Persist(Asistente)

«Insert» cargarMasivoAction()

«Muestra Reporte de Subida»

«TWIG» Clic:Cargar()

«Subir Excel»

flush() request(asistente_masivo_cargar)

(77)

77

 Diagrama de Secuencia Registrar Asistente a Evento

Figura 29: Diagrama de Secuencia Registrar Asistente a Evento

sd Registrar Asistente a Ev ento

Registrador

(78)

78

 Diagrama de Secuencia Imprimir Escarapela

Figura 30: Diagrama de Secuencia Imprimir Escarapela

sd Imprimir Escarapela

(79)

79

 Diagrama de Secuencia Generar Reporte Tabla

Figura 31: Diagrama de Secuencia Generar Reporte Tabla

sd Tabla Informe

Administrador

app.php Routing

InformeController

EntityManager Query MySql

Listado Informes Listado Informes

render() request(informe_grafico)

«Arreglo Entidades»

«Result» createQuery(dql)

Clic:Grafico()

«Manager»

generarArregloSeries(row)

«Mostrar Tabla»

«TWIG»

«Select» getManager()

informeGraficoAction(request)

(80)

80

 Diagrama de Secuencia Generar Reporte Gráfico

Figura 32: Diagrama de Secuencia Generar Reporte Grafico

sd Grafico Informe

Administrador

app.php Routing

InformeController

EntityManager Query HighChart MySql

Listado Informes Listado Informes

generarArregloSeries(row) «Arreglo Entidades» «Manager»

informeGraficoAction(request)

«TWIG» Clic:Grafico()

render(highChart)

«Result»

series(row) createQuery(dql) request(informe_grafico)

getManager()

«Mostrar Gráfico»

«Select»

(81)

81

8.3.7 Repositorio Fuentes Versionadas

Figura 33: Tortoise - Versionamiento Fuentes del Proyecto

(82)

82

8.3.8 Prototipo Web

Figura 34: Pagina Inicial Prototipo Web

(83)

83

8.4 PLAN DE PRUEBAS FUNCIONALES

8.4.3 Casos de Prueba

 Caso de Prueba Iniciar Sesión (CP-001):

o Entradas:

 Para el inicio de sesión, el usuario necesita tener su nombre de usuario y de contraseña, los cuales recibió por correo.

 El usuario diligencia el formulario y realiza el envío del formulario.

o Resultado:

 Si la autenticación se realiza correctamente, el sistema debe dirigir al usuario a la página de inicio.

o Condiciones:

 El usuario que va a ingresar, debe estar activo en el sistema.

o Procedimiento de Prueba:

 El usuario digita en el navegador la dirección del prototipo web para poder acceder al aplicativo.

 Luego ingresa los datos de nombre de usuario y contraseña y da clic en “Ingresar”.

 Después el sistema autentica la información.

 Si la información coincide con la almacenada en BD, el sistema redirige a la persona a la página de inicio.

(84)

84

 Caso de Prueba Cerrar Sesión (CP-002):

o Entradas:

 Una sesión activa en el sistema.

o Resultado:

 Si el cierre resulta correcto, el sistema finaliza la sesión y envía a la persona a la página de conexión.

o Condiciones:

 El usuario que va a cerrar sesión debe haberse conectado anteriormente.

o Procedimiento de prueba:

 El usuario busca la parte superior izquierda de la aplicación y pulsa en el enlace que dice “Cerrar sesión”.

 Luego se finalizará la conexión del usuario y se mostrará al usuario la pantalla de inicio de sesión.

 Caso de Prueba Crear Evento (CP-003):

o Entradas:

 El administrador tiene la información del nuevo evento, entre los cuales están el rango de fechas, el nombre del evento, la sucursal, tipos de evento, etc.

 Se diligencia y envía el formulario.

o Resultado:

 Si la información es correcta, el sistema crea el evento y muestra el detalle de la información ingresada.

o Condiciones: