Análisis, diseño e implementación de un prototipo Web para ... · a mi hermano quien en muchos...

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.

2015

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.

2015

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

“A Dios…A mi madre, que ha hecho posible que hoy pueda alcanzar esta meta,

trabajando sin cansancio para que hoy sea lo que soy… A toda mi familia y

amigos por ser inspiración y motivación…. Y a mi compañero de este proyecto

que nos deja grandes aprendizajes y anécdotas para la vida.”

Johan Andrés Bustos Amaya

4

TABLA DE CONTENIDO

DEDICATORIA .................................................................................................... 3

INTRODUCCIÓN ............................................................................................... 10

1. PLANTEAMIENTO DEL PROBLEMA ......................................................... 12

1.1 DESCRIPCIÓN DEL PROBLEMA ......................................................... 12

1.2 FORMULACIÓN DEL PROBLEMA ....................................................... 13

1.3 HIPÓTESIS .......................................................................................... 13

2. OBJETIVOS ................................................................................................ 14

2.1 OBJETIVO GENERAL .......................................................................... 14

2.2 OBJETIVOS ESPECÍFICOS ................................................................. 14

3. JUSTIFICACIÓN ......................................................................................... 15

4. MARCO REFERENCIAL ............................................................................. 16

4.1 MARCO HISTORICO ............................................................................ 16

4.2 MARCO TEÓ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.10 UML: .............................................................................................. 23

4.2.11 MVC: .............................................................................................. 23

4.2.12 Sistema de Base de Datos: ............................................................ 23

4.2.13 Aplicación Web: ............................................................................. 24

4.2.14 Symfony2: ...................................................................................... 24

4.2.15 Metodologías Ágiles: ...................................................................... 25

4.2.16 Scrum: ............................................................................................ 26

5. ALCANCES Y LIMITACIONES ................................................................... 29

5.1 ALCANCES .......................................................................................... 29

5

5.2 LIMITACIONES .................................................................................... 30

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

6.1 TIPO DE ESTUDIO ............................................................................... 31

6.2 PARTICIPANTES ................................................................................. 31

6.3 INSTRUMENTOS Y EQUIPOS ............................................................. 31

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

7.1 METODOLOGÍA DEL PROYECTO ....................................................... 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 PLAN DE PRUEBAS FUNCIONALES ................................................... 83

8.4.3 Casos de Prueba ............................................................................... 83

9. CONCLUSIONES ..................................................................................... 100

10. RECOMENDACIONES .......................................................................... 102

11. BIBLIOGRAFÍA ...................................................................................... 103

12. ANEXOS ................................................................................................ 105

ANEXO A: CARTA DE AUTORIZACIÓN DE LA SOCIEDAD COLOMBIANA DE

ORTODONCIA. ................................................................................................ 105

6

ANEXO B: ESTÁNDAR BASE DE DATOS ............................................................ 106

ANEXO C: DICCIONARIO DE DATOS ................................................................. 107

ANEXO D: TABLERO DE TAREAS SCRUM ....................................................... 112

ANEXO E: DIAGRAMAS DE SECUENCIA ADICIONALES ........................................ 113

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

Tabla 11: Resultados Casos de Prueba ............................................................. 97

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

Figura 22: Diagrama de Clases – Contexto Evento ........................................... 68

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

Figura 34: Pagina Inicial Prototipo Web ............................................................. 82

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.

La principal finalidad del desarrollo de este proyecto fue la aplicación de los

diferentes conocimientos adquiridos durante la carrera, para la creación de un

prototipo web que sea práctico y útil para una organización o empresa real.

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).

Se entiende que al ser un prototipo, esta será la base o versión inicial de una

aplicación web, desarrollada con el objetivo de garantizar su escalabilidad y

adaptabilidad para solucionar necesidades de otras organizaciones, de tal forma

que el costo de su diversificación sea bastante bajo y permita generar

rentabilidad.

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.

Esta necesidad que presenta la organización, hace que además se afecten los

servicios que se ofrecen a los asociados y que no se puedan tomar decisiones

concretas para buscar oportunidades de mejora para la organización.

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

Los problemas que actualmente posee la SCO para gestionar sus eventos y

obtener información de los mismos para tomar acciones de mejora efectivas, se

solucionarán con el actual sistema web, el cual está en la capacidad de

consolidar la información de los eventos en cada una de sus regionales, ya que

con esto, se tiene una base unificada con la cual podrán realizar su respectivo

análisis, con el objetivo de optimizar tanto económicamente, como en aspectos

de logística, la realización de eventos a futuro.

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.

Explotar las bondades del Framework PHP Symfony2, logrando así poner

todo el foco de atención en los requerimientos funcionales de la SCO.

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.

Además el proyecto permitió la aplicación de los conocimientos aprendidos

durante el pregrado, teniendo en cuenta la Ingeniería de Software y las Bases de

Datos como áreas de conocimiento fundamentales.

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.

Es en ese punto donde se detecta la posibilidad de trabajar en un proyecto que

se convierta en una solución y en una herramienta para esta organización,

visualizando el problema de una forma más global y proyectando la solución

hacia el futuro.

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/).

Quieromievento.

http://www.eventwo.com/

http://www.mitmiapp.com/

http://www.bitsformeetings.com/

http://www.adianteapps.com/

http://www.stagehq.com/

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:

Temática del evento: Como aspecto fundamental en la etapa de

planificación, esta la definición concreta de la temática del evento, ya que

esta a su vez permite establecer anticipadamente el tipo de evento que se

está organizando, los participantes o el publico al cual va dirigido, los

posibles canales de marketing a usar con fines publicitarios, los

suministros y logística que se van a necesitar, y en general va a permitir

establecer los objetivos y metas que se esperan conseguir al finalizar el

evento.

https://www.regonline.com.es/

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.

Ya teniendo establecido un cronograma adecuado, es muy importante

que cuando llegue el momento de la celebración del evento, se respeten

los tiempos y horas establecidos con en dicha agenda, garantizando la

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:

“La Sociedad Colombiana de Ortodoncia ha asociado desde el 25 de octubre de

1945 a los Odontólogos que han cursado y aprobado la especialidad de

ortodoncia en una facultad de Odontología de una universidad pública o privada,

nacional o extranjera, reconocida por el Consejo Asesor de Educación de la

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 marzo de 2014]. Disponible en la web: http://www.sco.com.co/mision.aspx

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:

http://www.amazing.com.co/arquitectura-empresarial.php pág 1

http://www.amazing.com.co/arquitectura-empresarial.php

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

patrón de arquitectura de Software MVC [Citado en 17 Julio de 2015] Disponible en la web: http://eugeniabahit.blogspot.com/2011/07/poo-y-mvc-en-php.html pág 36

http://eugeniabahit.blogspot.com/2011/07/poo-y-mvc-en-php.html

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 8 LUJAN, Sergio. Programación en internet: Clientes Web. Editorial Club Universitario. España, 2004.

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: http://www.scrumsense.com/wp-content/uploads/2012/03/Un-mejor-Scrum-2.pdf p 6,7

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. Versión 1.1, 2009. p 5

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 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

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.

14 HUNDERMARK, Peter. Un Mejor Scrum, [en línea]. [citado 26 de marzo de 2014]. Disponible en la web: http://www.scrumsense.com/wp-content/uploads/2012/03/Un-mejor-Scrum-2.pdf p 6,7

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.

Además como se mencionó anteriormente el sistema está en capacidad de

generar algunos reportes, en los que se pueden observar algunos aspectos

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.

Es muy importante el sistema no tiene integración con el software contable que

usa la SCO, lo cual podría ser una posible mejora a futuro, para realizar una

integración en tiempo real.

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.

Además se programaron reuniones con el personal que interviene en el proceso

de la organización de los eventos, así como encuestas periódicas con el fin de

realizar el levantamiento de requerimientos de la organización.

32

También se usaron algunas herramientas de UML y diseño de bases de datos

como Enterprise Architect, Navicat Data y Modeler, Coloso y Cmap Tools. En la

parte de desarrollo se usó el IDE Netbeans para el desarrollo del código y

MySql Workbench para la administración de la base de datos.

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.

Como ya se ha mencionado en el marco teórico de este documento, los roles

principales en SCRUM son el Scrum Master, que mantiene los procesos y

trabaja de forma similar al director del proyecto, el Product Owner, que

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.

Con el fin de determinar los elementos del Product Backlog que corresponden a

cada sprint, se realizaron reuniones denominadas Sprint Planning en las que el

Product Owner, con ayuda del cliente, identificaba los requerimientos que eran

incluidos en el Product Backlog y que se iban desarrollando durante cada sprint;

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.

De esta forma se realizaron las iteraciones con la participación activa de la SCO,

en las cuales se realizó gradualmente la construcción del prototipo web de

36

acuerdo a las necesidades iniciales que tenían y a algunas que fueron surgiendo

a lo largo del desarrollo.

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: Modelado Archimate – Punto de Vista de la Organización


En este diagrama se hace la descripción de los usuarios o roles del sistema,

agrupados o delimitados por el contexto del prototipo web desarrollado. En este

diagrama se observa también la generalización de las funciones más

importantes de cada usuario y la especialización de los usuarios del sistema que

heredan las funcionalidades del usuario general.

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


En este diagrama se pueden evidenciar las principales funcionalidades

disponibles para cada usuario, en donde el administrador realiza las

parametrización general del sistema y el usuario registrador realiza el registro de

los asistentes a los eventos y la impresión de la correspondiente escarapela.

39

Modelado Archimate Punto de Vista de los Procesos

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

Fuente: Elaboración propia

Se hace una descripción por medio de una generalización de los principales

procesos que intervienen en el sistema como los es el registro de asistentes a

los eventos. Además muestra la secuencia de subprocesos que componen el

proceso principal desde el momento de su solicitud hasta el estado final que es

el objetivo del proceso.

40

Modelado Archimate Punto de Vista del Producto

Figura 5: Modelado Archimate – Punto de Vista del Producto


En el diagrama anterior se hace una especificación del objetivo principal del

sistema y como ofrece un valor agregado para la organización con el fin de

mejorar la gestión, disponibilidad, organización e integración de toda la

información que se genera alrededor de la gestión de eventos y el registro de

asistentes a estos. Lo anterior con el fin de servir como apoyo en la toma de

decisiones a futuro.

41

Modelado Archimate Comportamiento de la Aplicación

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


En este diagrama se describe el valor agregado o proceso más importante de la

del sistema como lo es la gestión de eventos que organiza la SCO. Es

importante aclarar que para este prototipo no se hace la implementación del

pago en línea para registro de asistentes, ya que actualmente la organización

tiene un sistema contable que genera un archivo con la información de los

asociados y puede ser cargado al prototipo web de gestión de eventos.

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 Administrador puede consultar las estadísticas asociadas a un evento: costo total, cupo máximo, número de inscripciones, total recaudado.


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

8.2 DISEÑO

8.2.1 Diagrama de Contexto

Figura 7: Diagrama de Contexto del Sistema


45

8.2.2 Diagramas de Casos de Uso

Diagrama General de Casos de Uso

Figura 8: Diagrama General de Casos de Uso


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

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

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

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.

Bosquejo pantalla:

50


Historia de Usuario Gestionar Evento

Tabla 5: Historia de Usuario Gestionar Evento

Historia de Usuario

Número: 2 Usuario: Administrador

Nombre historia: Gestionar Evento





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

organizados por la SCO.

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.

Bosquejo Pantalla:

52


Historia de Usuario Gestionar Asistente

Tabla 6: Historia de Usuario Gestionar Asistente

Historia de Usuario

Número: 3 Usuario: Administrador/Registrador

Nombre historia: Gestionar Asistentes




Desarrollador:

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.

Campos obligatorios: Campos del nombre, documento, fecha de

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.

Bosquejo Pantalla:

55


Historia de Usuario Imprimir Escarapela

Tabla 7: Historia de Usuario Imprimir Escarapela

Historia de Usuario

Número: 4 Usuario: Registrador

Nombre historia: Imprimir Escarapela


Prioridad en negocio: Alta Complejidad en desarrollo: Baja



Precondiciones:

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

Historia de Usuario Generar Reporte

Tabla 8: Historia de Usuario Generar Reporte

Historia de Usuario

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.

- Eventos por tipo: Este informe muestra el número de eventos que se

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

8.2.4 Diagramas de Actividades

Diagrama de Actividades Iniciar Aplicación

Figura 15: Diagrama de Actividades Iniciar Aplicación


60

Diagrama de Actividades Gestionar Evento

Figura 16: Diagrama de Actividades Gestionar Evento


61

Diagrama de Actividades Registrar Asistente

Figura 17: Diagrama de Actividades Registrar Asistente


62

Diagrama de Actividades Imprimir Escarapela

Figura 18: Diagrama de Actividades Imprimir Escarapela


63

Diagrama de Actividades Generar Reporte

Figura 19: Diagrama de Actividades Generar Reporte


64

8.2.5 Modelo Relacional

Figura 20: Modelo Relacional Base de Datos


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:

DOCTRINE (ORM)

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:

MySQL: Para la implementación de la capa de persistencia se decidió

utilizar este motor de base de datos relacional que se ajusta a los

requerimientos del sistema y provee un módulo de Administración y

Seguridad.

67

8.3.2 Diagrama de Clases

Clase Usuario

Figura 21: Diagrama de Clases – Contexto Usuario class Class Model User

Controller

UsuarioController

+ indexAction(Request): var

+ createAction(Request): var

- createCreateForm(Usuario): var

+ newAction(): var

+ showAction(var): var

+ editAction(var): var

- createEditForm(Usuario, var): var

+ updateAction(Request, var): var

+ deleteAction(Request, var): var

- createDeleteForm(var, var): var

+ cambiarContrasenaAction(): var

+ detalleUsuarioActualAction(): var

+ editarDatosActualAction(): var

+ actualizarDatosActualAction(Request): var

+ registroCambiosAction(var): var

AdvancedUserInterface

Usuario

- id: var

- nombreUsuario: var

- contrasena: var

- codificadorContrasena: var

- nombres: var

- apellidos: var

- documento: var

- tipoDocumento: var

- email: var

- telefono: var

- celular: var

- fechaNacimiento: var

- edad: var

- cargoSco: var

- sexo: var

- estado: var = true

- ciudad: var

- rol: var

+ setId(var): var

+ getId(): var

+ setNombreUsuario(var): var

+ getNombreUsuario(): var

+ setContrasena(var): var

+ getContrasena(): var

+ setCodificadorContrasena(var): var

+ getCodificadorContrasena(): var

+ setNombres(var): var

+ getNombres(): var

+ setApellidos(var): var

+ getApellidos(): var

+ setDocumento(var): var

+ getDocumento(): var

+ setTipoDocumento(var): var

+ getTipoDocumento(): var

+ setEmail(var): var

+ getEmail(): var

+ setTelefono(var): var

+ getTelefono(): var

+ setCelular(var): var

+ getCelular(): var

+ setFechaNacimiento(var): var

+ getFechaNacimiento(): var

+ setEdad(var): var

+ getEdad(): var

+ setCargoSco(var): var

+ getCargoSco(): var

+ setSexo(var): var

+ getSexo(): var

+ setEstado(var): var

+ getEstado(): var

+ setCiudad(\EventosSCO\PrincipalBundle\Entity\Ciudad): var

+ getCiudad(): var

+ setRol(\EventosSCO\PrincipalBundle\Entity\Rol): var

+ getRol(): var

+ eraseCredentials(): var

+ getPassword(): var

+ getRoles(): var

+ getSalt(): var

+ getUsername(): var

+ isAccountNonExpired(): var

+ isAccountNonLocked(): var

+ isCredentialsNonExpired(): var

+ isEnabled(): var

AbstractType

UsuarioType

+ buildForm(FormBuilderInterface, array): var

+ setDefaultOptions(OptionsResolverInterface): var

+ getName(): var

EventSubscriberInterface

AddDepartamentoSubscriber

- factory: var

+ __construct(FormFactoryInterface): var

+ getSubscribedEvents(): var

- addDepartamentoForm(var, var, var): var

+ preSetData(FormEvent): var

+ preBind(FormEvent): var


AddCiudadSubscriber

- factory: var



- addCiudadForm(var, var): var




AddPaisSubscriber

- factory: var



- addPaisForm(var, var): var



Ciudad

- id: var

- nombreCiudad: var


- departamento: var

+ setId(var): var

+ getId(): var

+ setNombreCiudad(var): var

+ getNombreCiudad(): var


+ getEstado(): var

+ setDepartamento(\EventosSCO\PrincipalBundle\Entity\Departamento): var

+ getDepartamento(): var

+ __toString(): var

Departamento

- id: var

- nombreDepartamento: var


- pais: var

+ setId(var): var

+ getId(): var

+ setNombreDepartamento(var): var

+ getNombreDepartamento(): var


+ getEstado(): var

+ setPais(\EventosSCO\PrincipalBundle\Entity\Pais): var

+ getPais(): var

+ __toString(): var

Pais

- id: var

- nombrePais: var


+ setId(var): var

+ getId(): var

+ setNombrePais(var): var

+ getNombrePais(): var


+ getEstado(): var

+ __toString(): var

EventSubscriber

AuditsSubscriber

# container: var

+ __construct(ContainerInterface): var


+ preUpdate(LifecycleEventArgs): var

+ index(LifecycleEventArgs): var

Control

- id: var

- nombreTabla: var

- padreId: var

- nombreCampo: var

- fechaHoraModificacion: var

- valorAntesCadena: var

- valorDespuesCadena: var

- valorAntesTexto: var

- valorDespuesTexto: var

- usuario: var

+ getId(): var

+ setNombreTabla(var): var

+ getNombreTabla(): var

+ setPadreId(var): var

+ getPadreId(): var

+ setNombreCampo(var): var

+ getNombreCampo(): var

+ setFechaHoraModificacion(var): var

+ getFechaHoraModificacion(): var

+ setValorAntesCadena(var): var

+ getValorAntesCadena(): var

+ setValorDespuesCadena(var): var

+ getValorDespuesCadena(): var

+ setValorAntesTexto(var): var

+ getValorAntesTexto(): var

+ setValorDespuesTexto(var): var

+ getValorDespuesTexto(): var

+ setUsuario(\EventosSCO\PrincipalBundle\Entity\Usuario): var

+ getUsuario(): var

0..*

1

11

«use»

0..*

1


68

Clase Evento

Figura 22: Diagrama de Clases – Contexto Evento class Class Model Ev ento

Controller

Controller::EventoController



- createCreateForm(Evento): var

+ newAction(): var



- createEditForm(Evento): 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

Entity::Evento

- id: var

- codigoEvento: var

- nombreEvento: var

- estadoEvento: var

- fechaInicioEvento: var

- fechaFinEvento: var

- numeroMaxParticipantes: var

- valorInscripcion: var

- descripcion: var


- tipoEvento: var

- sucursalOrganiza: var

- ubicacion: var

- conferencista: var

- asistente: var

+ __construct(): var

+ getId(): var

+ setCodigoEvento(var): var

+ getCodigoEvento(): var

+ setNombreEvento(var): var

+ getNombreEvento(): var

+ setEstadoEvento(var): var

+ getEstadoEvento(): var

+ setFechaInicioEvento(var): var

+ getFechaInicioEvento(): var

+ setFechaFinEvento(var): var

+ getFechaFinEvento(): var

+ setNumeroMaxParticipantes(var): var

+ getNumeroMaxParticipantes(): var

+ setValorInscripcion(var): var

+ getValorInscripcion(): var

+ setDescripcion(var): var

+ getDescripcion(): var


+ getEstado(): var

+ setTipoEvento(\EventosSCO\PrincipalBundle\Entity\TipoEvento): var

+ getTipoEvento(): var

+ setSucursalOrganiza(\EventosSCO\PrincipalBundle\Entity\Seccional): var

+ getSucursalOrganiza(): var

+ setUbicacion(\EventosSCO\PrincipalBundle\Entity\Ubicacion): var

+ getUbicacion(): var

+ addConferencistum(\EventosSCO\PrincipalBundle\Entity\Conferencista): var

+ removeConferencistum(\EventosSCO\PrincipalBundle\Entity\Conferencista): var

+ getConferencista(): var

+ addAsistente(\EventosSCO\PrincipalBundle\Entity\Asistente): var

+ removeAsistente(\EventosSCO\PrincipalBundle\Entity\Asistente): var

+ getAsistente(): var

AbstractType

Form::EventoType



+ getName(): var

Entity::Ubicacion

- id: var

- nombreUbicacion: var

- direccion: var


- seccional: var

+ setId(var): var

+ getId(): var

+ setNombreUbicacion(var): var

+ getNombreUbicacion(): var

+ setDireccion(var): var

+ getDireccion(): var


+ getEstado(): var

+ setSeccional(\EventosSCO\PrincipalBundle\Entity\Seccional): var

+ getSeccional(): var

Entity::Asistente

- alDia: var

- fechaIngreso: var

- saldoAnualidad: var

- id: var

- evento: var


+ setAlDia(var): var

+ getAlDia(): var

+ setFechaIngreso(var): var

+ getFechaIngreso(): var

+ setSaldoAnualidad(var): var

+ getSaldoAnualidad(): var

+ setId(\EventosSCO\PrincipalBundle\Entity\Persona): var

+ getId(): var

+ getEventosscoPrincipalbundlePersona(): var

+ setEventosscoPrincipalbundlePersona(\EventosSCO\PrincipalBundle\Entity\Persona): var

Entity::Conferencista

- especialidad: var

- id: var


+ setEspecialidad(var): var

+ getEspecialidad(): var


+ getId(): var



EventSubscriber

EventListener::AuditsSubscriber

# container: var





Entity::Control

- id: var

- nombreTabla: var

- padreId: var

- nombreCampo: var






- usuario: var

+ getId(): var




+ getPadreId(): var














+ getUsuario(): var

Entity::TipoEvento

- id: var = ''

- nombreTipoEvento: var


+ getId(): var

+ setId(var): var

+ setNombreTipoEvento(var): var

+ getNombreTipoEvento(): var


+ getEstado(): var

0..* 1..*

1 0..*

1..*0..*

«use»

10..*


69

Clase Asistente

Figura 23: Diagrama de Clases – Contexto Asistente

class Class Model Asistente

Entity::Asistente

- alDia: var

- fechaIngreso: var

- saldoAnualidad: var

- id: var

- evento: var


+ setAlDia(var): var

+ getAlDia(): var

+ setFechaIngreso(var): var

+ getFechaIngreso(): var

+ setSaldoAnualidad(var): var

+ getSaldoAnualidad(): var


+ getId(): var



Entity::Persona

- id: var

- primerNombre: var

- segundoNombre: var

- primerApellido: var

- segundoApellido: var

- tipoDocumento: var

- documento: var

- email: var

- telefono: var

- celular: var

- edad: var

- fechaNacimiento: var

- ocupacionActual: var

- institucionEgresado: var

- sexo: var

- nivelEducativo: var


- ciudad: var

+ setId(var): var

+ getId(): var

+ setPrimerNombre(var): var

+ getPrimerNombre(): var

+ setSegundoNombre(var): var

+ getSegundoNombre(): var

+ setPrimerApellido(var): var

+ getPrimerApellido(): var

+ setSegundoApellido(var): var

+ getSegundoApellido(): var

+ setTipoDocumento(var): var

+ getTipoDocumento(): var

+ setDocumento(var): var

+ getDocumento(): var

+ setEmail(var): var

+ getEmail(): var

+ setTelefono(var): var

+ getTelefono(): var

+ setCelular(var): var

+ getCelular(): var

+ setEdad(var): var

+ getEdad(): var

+ setFechaNacimiento(var): var

+ getFechaNacimiento(): var

+ setOcupacionActual(var): var

+ getOcupacionActual(): var

+ setInstitucionEgresado(var): var

+ getInstitucionEgresado(): var

+ setSexo(var): var

+ getSexo(): var

+ setNivelEducativo(var): var

+ getNivelEducativo(): var


+ getEstado(): var

+ setCiudad(\EventosSCO\PrincipalBundle\Entity\Ciudad): var

+ getCiudad(): var

Entity::Ciudad

- id: var

- nombreCiudad: var


- departamento: var

+ setId(var): var

+ getId(): var

+ setNombreCiudad(var): var

+ getNombreCiudad(): var


+ getEstado(): var

+ setDepartamento(\EventosSCO\PrincipalBundle\Entity\Departamento): var

+ getDepartamento(): var

+ __toString(): var

Controller

Controller::AsistenteController

+ verAsistentesMasivoAction(): var

+ cargarMasivoAction(): var

+ reporteMasivoAction(): var



- createCreateForm(Asistente): var

+ newAction(): var



- createEditForm(Asistente): var



- createDeleteForm(var): var

- crearFiltros(var): var

EventSubscriber

EventListener::AuditsSubscriber

# container: var





AbstractType

Form::AsistenteType



+ getName(): var


EventListener::

AddDepartamentoSubscriber

- factory: var



- addDepartamentoForm(var, var, var): var




EventListener::AddCiudadSubscriber

- factory: var



- addCiudadForm(var, var): var




EventListener::AddPaisSubscriber

- factory: var



- addPaisForm(var, var): var



Entity::Departamento

- id: var

- nombreDepartamento: var


- pais: var

+ setId(var): var

+ getId(): var

+ setNombreDepartamento(var): var

+ getNombreDepartamento(): var


+ getEstado(): var

+ setPais(\EventosSCO\PrincipalBundle\Entity\Pais): var

+ getPais(): var

+ __toString(): var

Entity::Pais

- id: var

- nombrePais: var


+ setId(var): var

+ getId(): var

+ setNombrePais(var): var

+ getNombrePais(): var


+ getEstado(): var

+ __toString(): var

Entity::Evento

- id: var

- codigoEvento: var

- nombreEvento: var

- estadoEvento: var

- fechaInicioEvento: var

- fechaFinEvento: var

- numeroMaxParticipantes: var

- valorInscripcion: var

- descripcion: var


- tipoEvento: var

- sucursalOrganiza: var

- ubicacion: var

- conferencista: var

- asistente: var


+ getId(): var

+ setCodigoEvento(var): var

+ getCodigoEvento(): var

+ setNombreEvento(var): var

+ getNombreEvento(): var

+ setEstadoEvento(var): var

+ getEstadoEvento(): var

+ setFechaInicioEvento(var): var

+ getFechaInicioEvento(): var

+ setFechaFinEvento(var): var

+ getFechaFinEvento(): var

+ setNumeroMaxParticipantes(var): var

+ getNumeroMaxParticipantes(): var

+ setValorInscripcion(var): var

+ getValorInscripcion(): var

+ setDescripcion(var): var

+ getDescripcion(): var


+ getEstado(): var

+ setTipoEvento(\EventosSCO\PrincipalBundle\Entity\TipoEvento): var

+ getTipoEvento(): var

+ setSucursalOrganiza(\EventosSCO\PrincipalBundle\Entity\Seccional): var

+ getSucursalOrganiza(): var

+ setUbicacion(\EventosSCO\PrincipalBundle\Entity\Ubicacion): var

+ getUbicacion(): var

+ addConferencistum(\EventosSCO\PrincipalBundle\Entity\Conferencista): var

+ removeConferencistum(\EventosSCO\PrincipalBundle\Entity\Conferencista): var

+ getConferencista(): var

+ addAsistente(\EventosSCO\PrincipalBundle\Entity\Asistente): var

+ removeAsistente(\EventosSCO\PrincipalBundle\Entity\Asistente): var

+ getAsistente(): var

Entity::Control

- id: var

- nombreTabla: var

- padreId: var

- nombreCampo: var






- usuario: var

+ getId(): var




+ getPadreId(): var














+ getUsuario(): var

0..*1..*

1 1

1 1

0..*

1

0..*

1

«use»


70

8.3.3 Mapa de Navegación

Mapa de Navegación Primera Parte

Figura 24: Mapa de Navegación Primera Parte


71

Mapa de Navegación Segunda Parte

Figura 25: Mapa de Navegación Segunda Parte


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

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.

Registrador: Tiene acceso al CRUD de asistentes y registrar los mismos

los diferentes eventos. Además es aquel que imprime las escarapelas de

asistencia a un evento específico para una persona.

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

EntityManagerrouting MySql

Listado EventosListado Eventos

Otra acciónOtra 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

Diagrama de Secuencia Crear Asistente

Figura 27: Diagrama de Secuencia Crear Asistentes

sd Crear asistentes

app.php EntityManagerrouting MySql


Registrador

AsistenteController

Listado AsistentesListado 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

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 AsistentesExcel Asistentes


render()

Persist(Asistente)

«Insert»

cargarMasivoAction()

«Muestra Reporte de Subida»

«TWIG»

Clic:Cargar()

«Subir Excel»

flush()

request(asistente_masivo_cargar)


77

Diagrama de Secuencia Registrar Asistente a Evento

Figura 29: Diagrama de Secuencia Registrar Asistente a Evento

sd Registrar Asistente a Ev ento

Registrador

Detalle EventoDetalle Evento

app.php routing

Ev entoController

EntityManager Repository MySql


persist(Inscripcion)

Clck:Seleccionar()

«Buscar Asistentes»

«Response»

«Result»

request(buscar_asistentes)

«insert»

«Mostrar Listado Asistentes»

«Seleccionar Asistentes»

«TWIG»

flush()

Clic:Seleccionar()

«Select»

getRepository(PrincipalBundle:Asistente)

buscarAsistentesAction(record)

return(new Response)

insertarAsistentesAction(request, record)

«Arreglo Asistentes»

render()

find(arrayFilters)

«Actualiza Listado Asistentes

al Evento»

request(agregar_asistentes)

«Repository»


78

Diagrama de Secuencia Imprimir Escarapela

Figura 30: Diagrama de Secuencia Imprimir Escarapela

sd Imprimir Escarapela

Registrador


app.php routing

Ev entoController

EntityManager Repository MySql

PDF EscarapelaPDF Escarapela

verEscarapelaAction(request, id)

«result»

«Asistente»

findById(id)

«repository»

Clic:Imprimir()

«result»

request

(paginar_asistentes_evento)

request(abrir_imprimir_escarapela)

«TWIG»

«select»

«Abrir Popup Impresion»

«select»

paginarAsistentesAction(request, id)

«TWIG»

«Acualiza Listado Asistentes»

findBy(arrayDocumento)

Clic:Imprimir Escarapela()

«Repository»


«Escribe documento»

render()


window.print()

Clic:Buscar()



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 InformesListado Informes


render()

request(informe_grafico)

«Arreglo Entidades»

«Result»

createQuery(dql)

Clic:Grafico()

«Manager»

generarArregloSeries(row)

«Mostrar Tabla»

«TWIG»

«Select»

getManager()

informeGraficoAction(request)


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 MySqlHighChart

Listado InformesListado 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

8.3.7 Repositorio Fuentes Versionadas

Figura 33: Tortoise - Versionamiento Fuentes del Proyecto


82

8.3.8 Prototipo Web

Figura 34: Pagina Inicial Prototipo Web


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.

En caso contrario el sistema re direccionará a la persona a

la página de inicio de sesión indicando el error de

autenticación.

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:

La persona que desee realizar esta acción debe tener el

rol de Administrador.

85

o Procedimiento de la prueba:

El usuario con el rol de administrador despliega la pestaña

“EVENTOS” y pulsa el enlace “Evento”.

El sistema direcciona la aplicación al listado de los eventos

creados en el sistema.

Luego el administrador pulsa sobre el botón “Nuevo”.

A continuación el sistema muestra el formulario de

creación de eventos.

Cuando la persona termina de diligenciar el formulario, da

clic en el botón “Crear”.

Si la información es correcta, el sistema guarda en base de

datos el evento y muestra al usuario el detalle del mismo.

Caso de Prueba Editar Evento (CP-004):

o Entradas:

El administrador requiere cambiar la información del evento.

Para esto debe seleccionar un evento creado y actualizar su

información.

o Resultado:

El sistema realiza el cambio de la información previa por la

actual.

o Condiciones:

El usuario debe tener el rol de administrador.

El evento debe existir en el sistema.




86



Después el usuario filtra los eventos si así lo requiere

ingresando la información y dando clic en “Buscar”.

Al encontrar el evento requerido, el administrador pulsa sobre

el lápiz que está en la columna de “Acciones” en el evento que

se va a modificar.

A continuación el sistema muestra el formulario de edición con

la información actual del evento.

Cuando la persona termina de actualizar la información del

formulario, da clic en el botón “Actualizar”.

Si la información es correcta, el sistema sobrescribe la

información del evento almacenada en base de datos y

muestra al usuario el detalle del mismo.

Caso de Prueba Inactivar Evento (CP-005):

o Entradas:

El administrador requiere inactivar temporal o definitivamente

un evento.

o Resultado:

El sistema realiza la inactivación del evento.

o Condiciones:

El usuario debe tener el rol de administrador.

El evento debe existir en el sistema.




87






la hoja con una lupa que está en la columna de “Acciones” o

sobre el código del evento que se requiere inactivar.

Gracias a esto, el sistema direcciona la aplicación a la página

de detalle del evento.

Bajo el nombre del evento, hay un botón con una flecha

apuntando hacia abajo, del cual se despliega la opción de

“Eliminar”; se debe pulsar sobre esta.

El sistema inactiva el evento, realizando una eliminación lógica

y lo oculta del listado estándar de eventos.

Finalmente se direcciona al usuario a la página del listado de

eventos.

Caso de Prueba Crear Asistente (CP-006):

o Entradas:

El registrador tiene la información del nuevo asistente, entre

los cuales el nombre del asistente, el documento, tipo de

documento, etc.

Se diligencia y envía el formulario.

o Resultado:

Si la información es correcta, el sistema crea el asistente y

muestra el detalle de la información ingresada.

88

o Condiciones:

La persona que desee realizar esta acción debe tener el rol de

Registrador.

o Procedimiento de la prueba:


“ASISTENTES” y pulsa el enlace “Asistente”.

El sistema direcciona la aplicación al listado de los asistentes


Luego el registrador pulsa sobre el botón “Nuevo”.

A continuación el sistema muestra el formulario de creación de

asistentes.

Cuando la persona termina de diligenciar el formulario, da clic

en el botón “Crear”.

Si la información es correcta, el sistema guarda en base de

datos el asistente y muestra al usuario el detalle del mismo.

Caso de Prueba Editar Asistente (CP-007):

o Entradas:

El administrador requiere cambiar la información del asistente.

Para esto debe seleccionar un asistente creado y actualizar su

información.

o Resultado:

El sistema realiza el cambio de la información previa por la

actual.

o Condiciones:

El usuario debe tener el rol de registrador.

El asistente debe existir en el sistema.

89






Después el usuario filtra los asistentes si así lo requiere


Al encontrar el evento requerido, el registrador pulsa sobre el

lápiz que está en la columna de “Acciones” en el evento que

se va a modificar.

A continuación el sistema muestra el formulario de edición con

la información actual del asistente.

Cuando la persona termina de actualizar la información del

formulario, da clic en el botón “Actualizar”.

Si la información es correcta, el sistema sobrescribe la

información del asistente almacenada en base de datos y

muestra al usuario el detalle del mismo.

Caso de Prueba Inactivar Asistente (CP-008):

o Entradas:

El registrador requiere inactivar temporal o definitivamente un

asistente.

o Resultado:

El sistema inactiva al asistente.

o Condiciones:


El asistente debe existir en el sistema.

90






Después el usuario filtra los asistentes si así lo requiere




sobre el nombre del asistente que se requiere inactivar.

Gracias a esto, el sistema direcciona la aplicación a la página

de detalle del asistente.

Bajo el nombre del asistente, hay un botón con una flecha

apuntando hacia abajo, del cual se despliega la opción de

“Eliminar”; se debe pulsar sobre esta.

El sistema inactiva el asistente, realizando una eliminación

lógica y lo oculta del listado estándar de asistentes.

Finalmente se direcciona al usuario a la página del listado de

asistentes.

Caso de Prueba Cargar Asistentes Masivo (CP-009):

o Entradas:

Archivo Excel con la información de los asistentes.

o Resultado:

Cargue masivo de asistentes en el sistema

o Condiciones:

Usuario con rol Administrador.

91

Información en archivo Excel que cumpla las validaciones del

sistema.


El Administrador hace clic en el menú Asistentes.

El sistema despliega las opciones Asistente y Asistente

Masivo.

El usuario hace clic en la opción Asistente Masivo

El sistema despliega el modulo de Cargue Masivo de

Asistentes con el archivo ejemplo para el cargue, los datos de

ayuda, el campo para seleccionar el archivo y el botón Cargar.

El usuario descarga el archivo ejemplo y completa la

información de los asistentes que desea cargar.

El usuario accede a los datos de ayuda para completar la

información del archivo Excel que va a ser cargado.

El usuario guarda el archivo en su equipo.

El usuario hace clic en el botón Seleccionar Archivo.

El sistema abre la ventana de navegación para que el usuario

seleccione el archivo.

El usuario selecciona el archivo que desea cargar.

El usuario hace clic en el botón Cargar.

El sistema hace las validaciones correspondientes y si estas

son correctas entonces persiste la información de los

asistentes en la base de datos.

El sistema genera un log con el resultado del cargue.

El usuario abre el log del cargue realizado.

92

Caso de Prueba Registrar Asistentes a un Evento (CP-010):

o Entradas:

El registrador requiere registrar los asistentes que estarán en

un evento.

o Resultado:

Se podrá ver el registro de los asistentes debajo del detalle del

evento.

o Condiciones:

Los asistentes y el evento deben estar creados en el sistema.



El registrador despliega la pestaña “EVENTOS” y pulsa el

enlace “Evento”.







sobre el código del evento al que se van a añadir asistentes.

Estando en el detalle del evento, se busca la sección de

asistentes y se da clic en “Seleccionar”.

Luego de esto el sistema mostrará un listado de los asistentes

registrados en el sistema.

El registrador podrá escoger uno o varios asistentes

seleccionando en las casillas y al pulsar en el botón

“Seleccionar”.

93

Inmediatamente el sistema almacenará la relación entre los

asistentes y el evento y actualizará el listado que se tenía

inicialmente.

Caso de Prueba Imprimir Escarapela (CP-011):

o Entradas:

El asistente al evento necesita su escarapela, por lo cual el

registrador tendrá que generársela.

o Resultado:

Se generará la ventana de impresión de la escarapela para

entregársela al asistente.

o Condiciones:

El evento debe estar creado.

El asistente debe estar creado y registrado en el evento.

El usuario debe tener rol de Registrador.


El registrador despliega la pestaña “EVENTOS” y pulsa el

enlace “Evento”.







sobre el código del evento.

Estando en el evento se puede buscar al asistente a quien se

imprimirá la escarapela digitando su documento o alguna

coincidencia y dando clic en el botón “Buscar”.

94

El sistema mostrará el listado en base al documento que se

buscó.

Luego el dará clic en el enlace “Imprimir” en el registro del

asistente que se está buscando.

Se abrirá un popup con la opción de imprimir la escarapela.

El sistema enviará a la persona a la pantalla para imprimir la

escarapela.

El registrador la imprimirá y se la entregará al asistente.

Caso de Prueba Generar Informe Tabla (CP-012):

o Entradas:

El administrador requiere ver información detallada de los

datos que están registrados en el sistema, ya sea de eventos,

asistentes, etc.

o Resultado:

Una tabla con la información detallada que requiere el

administrador.

o Condiciones:

El usuario debe estar registrado como administrador.


El administrador pulsa sobre la pestaña “INFORMES”.

El sistema direcciona la aplicación al listado de los informes

que hay en el sistema.

Después el usuario filtra los informes si así lo requiere

ingresando el nombre requerido y dando clic en “Buscar”.

95


la tabla que está en la columna de “Acciones” o sobre el

nombre del informe en caso que aplique.

El informe despliega la tabla del informe.

Si el administrador requiere, puede filtrar la información que se

muestra en el informe de acuerdo a los filtros que ofrece el

sistema.

Caso de Prueba Generar Informe Gráfica (CP-013):

o Entradas:

El administrador requiere ver de forma consolidada y

entendible alguna información que está registrada en el

sistema, ya sea de eventos, asistentes, etc.

o Resultado:

Una gráfica que consolida la información que el administrador

desea ver.

o Condiciones:

El usuario debe estar registrado como administrador.


El administrador pulsa sobre la pestaña “INFORMES”.

El sistema direcciona la aplicación al listado de los informes

que hay en el sistema.

Después el usuario filtra los informes si así lo requiere

ingresando el nombre requerido y dando clic en “Buscar”.


la gráfica de barras que está en la columna de “Acciones” o

sobre el nombre del informe en caso que aplique.

96

El informe despliega el gráfico del informe que más aplique a

la información que se quiere obtener.

Si el administrador requiere, puede filtrar la información que se

muestra en el informe de acuerdo a los filtros que ofrece el

sistema.

97

8.4.4 Resultados Casos de Prueba

Tabla 11: Resultados Casos de Prueba

Caso Prueba Resultado Esperado

Resultado Obtenido

Observaciones

CP-001 El usuario tendrá acceso a toda la funcionalidad del sistema y verá los módulos de acuerdo a su rol.

Luego de realizar la prueba, el usuario inició sesión correctamente y tiene los accesos que su rol debe tener.

OK.

CP-002 Luego de que el usuario pulse en cerrar sesión, el sistema cerrará la misma y mostrará el formulario de conexión.

Luego de realizar la prueba todo funcionó correctamente, luego de esto el usuario no pudo acceder a los módulos del sistema hasta que volvió a iniciar sesión.

OK.

CP-003 Se espera que al finalizar este caso de prueba, haya un evento creado en el sistema y que la información que se ingresó en la creación esté completa,

Efectivamente se guardó el evento y no hubo pérdida de algún valor ingresado en el formulario de creación.

OK.

CP-004 Al final de esta prueba se espera que se hayan realizado los cambios en el formulario a cada uno de los campos del mismo.

Ocurrió un pequeño inconveniente, el sistema actualizaba toda la información, a excepción del estado del evento.

Se realizaron los respectivos ajustes y se solucionó el inconveniente, se realizó otra prueba y todo funcionó correctamente.

CP-005 Se espera que el evento no aparezca en la lista por defecto de los eventos, lo cual indica que está inactivo.

El proceso se realizó de forma exitosa y para poder buscar de nuevo el evento, se tuvo que filtrar por inactivos.

OK.

CP-006 Se espera que al finalizar este caso de prueba, se debe tener un asistente nuevo en el sistema con la información ingresada.

Todo salió como se esperaba, el asistente estaba creado y listo para ser registrado en eventos,

OK.

CP-007 Al finalizar, se deben Se realizó la prueba y OK.

98

evidenciar los cambios realizados al asistente que se seleccionó.

todo salió tal como se esperaba.

CP-008 El asistente que se escogió para la prueba no debería aparecer en el listado de los que se encuentran activos.

Se realizó la prueba y todo el proceso se ejecutó de acuerdo a las expectativas, sin embargo se encontró un problema en el listado de los asistentes y por lo tanto el asistente aparecía a pesar de estar inactivo.

Se ajustó la consulta que mostraba los asistentes y el asistente inactivado, dejó de aparecer en la lista, tal como tenía que suceder.

CP-009 Al finalizar el proceso se debe evidenciar el cargue masivo de los asistentes a la aplicación por medio del archivo Excel.

El sistema permite cargar los asistentes de forma masiva por medio de un archivo Excel que contiene la información de los asistentes.

OK.

CP-010 Al finalizar el proceso se debe tener que los asistentes que se seleccionaron, deben aparecer en el listado que aparece bajo el detalle del evento.

La prueba con un solo asistente funcionó correctamente, sin embargo cuando eran varios solo agregaba al primero en orden.

Se revisó la funcionalidad y se encontró el problema. Se analizó en equipo y se encontró la forma de solucionarlo; al ejecutar de nuevo el caso, funcionó correctamente.

CP-011 Se espera obtener como resultado la ventana de impresión del navegador, con la escarapela del evento específico.

Se realizó el proceso correctamente y la escarapela se generó tal como se requería

OK.

CP-012 Luego de realizar el proceso, se debe tener una tabla con los resultados consolidados de la información almacenada en el sistema; los filtros deben acomodar los resultados de acuerdo a lo que se ingrese en estos.

La tabla se generó sin inconveniente con la información requerida y los filtros funcionaban correctamente.

OK.

CP-013 El usuario podrá ver Aunque el gráfico El equipo realizó los

99

una gráfica que consolide la información que este requiere; los filtros deberán cambiar los valores en la gráfica de acuerdo a lo que se tiene almacenado en el sistema.

generaba la información requerida, los filtros no estaban funcionando bien.

respectivos ajustes; se probó y se corrigió el inconveniente con los filtros.


100

9. CONCLUSIONES

A la hora de levantar los requerimientos con los clientes, fue clave realizar

las reuniones periódicas; ya que si esto no se hubiese hecho, se pudo

haber perdido tiempo realizando desarrollos que se hubiesen tenido que

revertir modificaciones para adaptar el sistema a un requerimiento nuevo o

algún ajuste a uno existente por parte de la SCO.

Para el desarrollo del proyecto fue de vital importancia estar en contacto

constante con la SCO, dando en lo posible entregas funcionales con el

objetivo que se detecten a tiempo errores en la interpretación de un

requerimiento, evitando así, que estos afecten otras funcionalidades

futuras.

Al usar como metodología de desarrollo a Scrum, se pudo enfocar la fuerza

de trabajo de los desarrolladores en implementar el prototipo y no se invirtió

mucho tiempo en documentación; además ayudó a cumplir eficaz y

eficientemente con las expectativas de la SCO con respecto a la

plataforma.

Aunque actualmente puede no son muy evidentes, cuando transcurra un

tiempo con el sistema en producción, se podrán notar las ventajas que se

generaron a causa de realizar el diseño de la base de datos cumpliendo las

normas de la normalización, ya que se ahorrará bastante espacio de

almacenamiento y la aplicación funcionará de una forma mucho más

óptima.

101

En la actualidad, es fundamental usar un Framework para el desarrollo de

aplicaciones (especialmente WEB) que nos permita ahorrar el tiempo que

se invierte diseñando la arquitectura de la aplicación del sistema y dar

prioridad a la comprensión e implementación de los requerimientos de los

clientes.

El uso de un framework MVC como Symfony2, fue fundamental, dado que

evitó pensar la arquitectura del código, además nos brindó herramientas

para generar los CRUDs de las tablas, generar servicios internos en el

sistema, agregar o quitar librerías y paquetes externos, entre otros

aspectos.

102

10. RECOMENDACIONES

El proyecto dejó múltiples posibilidades de implementar nuevas funcionalidades;

por ejemplo, es claro que con algunos ajustes se puede estandarizar la

herramienta para que esta no aplique únicamente para el caso específico de la

Sociedad Colombiana de Ortodoncia.

También se puede crear una interfaz que permita importar por archivos planos o

un Web Service la información de los pagos realizados por cada uno de los

asistentes registrados en la plataforma y de igual manera exportar los datos de las

cuotas canceladas de los eventos para así alimentar la contabilidad; es preferible

que esta actualización de la información sea en tiempo real.

Además una funcionalidad que se propuso pero que se rechazó en la SCO es la

posibilidad de implementar un módulo de atención externa a los asociados en el

cual ellos puedan ingresar sus observaciones acerca de los resultados de un

evento específico.

En base a lo anterior también es aplicable el uso de encuestas de satisfacción de

los asistentes cuando se dé el cierre de un evento, con el cual la SCO tendrá la

posibilidad de cuantificar las opiniones de quienes presenciaron el evento, en pro

de una mejor planificación para eventos futuros.

103

11. BIBLIOGRAFÍA

DATE, C.J. Introducción a los sistemas de bases de datos. Séptima Edición.

Pearson Educación. México, 2004. 960 p.

LUJAN, Sergio. Programación en internet: Clientes Web. Editorial Club

Universitario. España, 2004.

DEEMER, Peter, BENEFIELD, Gabrielle, LARMAN, Craig, VODDE, Bas.

INFORMACIÓN BÁSICA DE SCRUM. Versión 1.1, 2009.

KNIBERG, Henrik. SCRUM Y XP DESDE LAS TRINCHERAS. Cómo

hacemos Scrum. Primera edición. Estados Unidos: InfoQ, 2007.

HUNDERMARK, Peter. Un Mejor Scrum, [en línea]. [citado 26 de marzo de

2014]. Disponible en la web: http://www.scrumsense.com/wp-

content/uploads/2012/03/Un-mejor-Scrum-2.pdf

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_GONZALE

Z.pdf

INSTITUTO COLOMBIANO DE NORMAS TÉCNICAS Y CERTIFICACION.

Trabajos escritos: presentación y referencias bibliográficas. Sexta

actualización. Bogotá: ICONTEC, 2008. 110 p.

PRESSMAN, Roger S. Ingeniería del Software: Un Enfoque Práctico.

Quinta Edición. Mc Graw Hill. México, 2002. 601 p.

SOMMERVILLE, Ian. Ingeniería del Software. Séptima Edición. Pearson.

Madrid, 2005. 687p.

THE OPEN GROUP. A Pocket Guide to Archimate 2.0. The open Group.

Berkshire, 2012, 96p.

104

BAHIT, Eugenia. POO y MVC en PHP: El paradigma de la Programación

Orientada a Objetos en PHP y el patrón de arquitectura de Software MVC

[Citado en 17 Julio de 2015] Disponible en la web:


AMAZING TM. Arquitectura Empresarial [Citado en 20 Julio de 2015]

Disponible en la web: http://www.amazing.com.co/arquitectura-

empresarial.php

SOCIEDAD COLOMBIANA DE ORTODONCIA. Página principal [Citado en

10 Julio de 2015]. Disponible en la web: http://www.sco.com.co


105

12. ANEXOS

ANEXO A: Carta de autorización de la Sociedad Colombiana de Ortodoncia.

106

ANEXO B: Estándar Base de Datos

La información en base de datos se rige por algunas reglas básicas que ayudan a

las personas a entender más fácilmente la estructura de la información y además

permiten al framework Doctrine, interpretar la misma de una forma más clara:

• El nombre de las tablas está escrito en mayúsculas sostenidas.

- Ejemplo: USUARIO.

• Los nombres de los atributos se escriben en minúsculas.

- Ejemplo: fecha_nacimiento

• Todas las llaves primarias de las tablas deben iniciar ser “id”, a excepción

de las que tienen llaves compuestas.

• Todos los atributos que estén compuestos por más de una palabra, se

separan con el carácter “_”.

- Ejemplo: nombre_evento.

• Todas las llaves foráneas llevan el nombre de la tabla a la que referencian,

acompañado de la partícula “_id”.

- Ejemplo: usuario_id.

• Las tablas de rompimiento no necesariamente llevan el nombre de las dos

tablas a las que se relacionan, se usan nombres más reales para dar un

significado mayor a la misma.

- Ejemplo: INSCRIPCION; haciendo referencia a la relación entre el

asistente y el evento

107

ANEXO C: Diccionario de Datos

112

ANEXO D: Tablero de Tareas SCRUM

113

ANEXO E: Diagramas de Secuencia Adicionales

Diagrama de Secuencia Iniciar Aplicación

sd Iniciar Aplicación

Usuario general

app.php

SecurityController

SecurityContextRouting

Cierra navegadorCierra navegador

logoutAction()

Cerrar sesión()

redirect(login)

request(logout)

redirect(home_page)

autenticate(nombre_usuario, contrasena)

remove(session)

Muestra index()

request(login)

Muestra login()

loginAction(request)

sesion()

Inicia sesión()

url:SCO/web/index()

«Muestra Form Login»

114

Diagrama de Secuencia Listar Eventos

sd Listar Ev entos

Usuario general

app.php

Sesión iniciadaSesión iniciada

Ev entoController

EntityManager MySqlrouting Repository


Clic:Eventos()

«Muestra Lista Eventos»

«TWIG»

find(arrayFilters)

«repository»

indexAction(request)

«select»

request(evento)

render()

getRepository(PrincipalBundle:Evento)

«result»

«Arreglo Eventos»

115

Diagrama de Secuencia Editar Evento

sd Editar ev entos

Administrador

app.php

Ev entoController




request(evento_edit)

request(evento_update)

updateAction(request)

Clic:Editar()

«TWIG»

«Muestra Detalle Evento»

Clic:Crear(Info Evento)

render()

editAction(request)

«update»

flush()

«TWIG»

render()

persist(Evento)

«Muestra Formulario Edición»

116

Diagrama de Secuencia Eliminar Evento

sd Eliminar Ev entos

Administrador

app.php

Ev entoController




Ev ento

persist(Evento)

setEstado(false)

flush()

render()

Clic:Eliminar()

«update»

«Mostrar Listado Eventos»

request(evento_delete)

«TWIG»

deleteAction(request)

117

Diagrama de Secuencia Listar Asistentes

sd Listar Asistentes

Usuario general

app.php

Sesión iniciadaSesión iniciada

EntityManager MySqlrouting Repository


AsistenteController

«Muestra Lista Asistentes»

indexAction(request)

«result»

Clic:Asistentes()

«select»

«repository»


request(asistente)

render()

find(arrayFilters)

«TWIG»


118

Diagrama de Secuencia Editar Asistente

sd Editar asistentes



AsistenteController

Detalle AsistenteDetalle Asistente

Registrador

render()

«Muestra Detalle Asistente»

persist(Asistente)

flush()

«TWIG»

render()

request(asistente_edit)

Clic:Crear(Info Asistente)

editAction(request)

request(asistente_update)

«TWIG»

«update»

updateAction(request)

Clic:Editar()

«Muestra Formulario Edición»

119

Diagrama de Secuencia Eliminar Asistente

sd Eliminar Asistentes



AsistenteAsistenteController

Detalle AsistenteDetalle Asistente

Registrador

flush()

request(asistente_delete)

persist(Asistente)

«Mostrar Listado Asistentes»

Clic:Eliminar()

render()

deleteAction(request)

«update»

setEstado(false)

«TWIG»

Análisis, diseño e implementación de un prototipo Web para ... · a mi hermano quien en muchos...

Documents

Transcript of Análisis, diseño e implementación de un prototipo Web para ... · a mi hermano quien en muchos...