View
9
Download
0
Category
Preview:
Citation preview
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.
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.
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
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
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
Fuente: Elaboración propia.
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
Fuente: Elaboración propia.
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
Fuente: Elaboración propia.
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
Fuente: Elaboración propia.
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.
Fuente: Elaboración propia.
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.
Fuente: Elaboración propia.
44
8.2 DISEÑO
8.2.1 Diagrama de Contexto
Figura 7: Diagrama de Contexto del Sistema
Fuente: Elaboración propia.
45
8.2.2 Diagramas de Casos de Uso
Diagrama General de Casos de Uso
Figura 8: Diagrama General de Casos de Uso
Fuente: Elaboración propia.
46
Diagrama Caso de Uso Iniciar Aplicación
Figura 9: Diagrama Caso de Uso Iniciar Aplicación
Fuente: Elaboración propia
Diagrama Caso de Uso Gestionar Evento
Figura 10: Diagrama Caso de Uso Gestionar Evento
Fuente: Elaboración propia
47
Diagrama Caso de Uso Gestionar Asistente
Figura 11: Diagrama Caso de Uso Gestionar Asistente
Fuente: Elaboración propia
Diagrama Caso de Uso Registrar Asistente
Figura 12: Diagrama Caso de Uso Registrar Asistente
Fuente: Elaboración propia.
48
Diagrama Caso de Uso Imprimir Escarapela
Figura 13: Diagrama Caso de Uso Imprimir Escarapela
Fuente: Elaboración propia.
Diagrama Caso de Uso Generar Reporte
Figura 14: Diagrama de Caso de Uso Generar Reporte
Fuente: Elaboración propia
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
Fuente: Elaboración propia
Historia de Usuario Gestionar Evento
Tabla 5: Historia de Usuario Gestionar Evento
Historia de Usuario
Número: 2 Usuario: Administrador
Nombre historia: Gestionar Evento
Tipo historia de usuario :
Prioridad en negocio: Alta Complejidad en desarrollo: Media
Horas Estimadas: 45 Iteración asignada:1
Desarrollador: Desarrollador 1
Precondiciones:
Sesión iniciada con usuario perfil Administrador
Descripción:
Se requiere que el sistema permita la gestión o parametrización de un evento, es
decir; la creación, lectura, actualización e inactivación de los eventos
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.
Criterios de Aceptación:
- El sistema debe permitir el CRUD de los eventos organizados por la SCO.
- El sistema debe garantizar todas las validaciones mencionadas.
Bosquejo Pantalla:
52
Fuente: Elaboración propia
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
Tipo historia de usuario :
Prioridad en negocio: Alta Complejidad en desarrollo: Media
Horas Estimadas: 60 Iteración asignada:1
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.
Criterios de Aceptación:
- 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
Fuente: Elaboración propia
Historia de Usuario Imprimir Escarapela
Tabla 7: Historia de Usuario Imprimir Escarapela
Historia de Usuario
Número: 4 Usuario: Registrador
Nombre historia: Imprimir Escarapela
Tipo historia de usuario :
Prioridad en negocio: Alta Complejidad en desarrollo: Baja
Horas Estimadas: 45 Iteración asignada:1
Desarrollador: Desarrollador 1
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.
Criterios de Aceptación:
- 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:
Fuente: Elaboración propia
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
Prioridad en negocio: Alta Complejidad en desarrollo: Media
Horas Estimadas: 145 Iteración asignada:1
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.
Criterios de Aceptación:
- El usuario Administrador es el único usuario con permisos para generar
reportes
- El usuario puede generar reportes Grafico, Tabla o Excel.
Bosquejo pantalla:
Fuente: Elaboración propia
59
8.2.4 Diagramas de Actividades
Diagrama de Actividades Iniciar Aplicación
Figura 15: Diagrama de Actividades Iniciar Aplicación
Fuente: Elaboración propia
60
Diagrama de Actividades Gestionar Evento
Figura 16: Diagrama de Actividades Gestionar Evento
Fuente: Elaboración propia
61
Diagrama de Actividades Registrar Asistente
Figura 17: Diagrama de Actividades Registrar Asistente
Fuente: Elaboración propia
62
Diagrama de Actividades Imprimir Escarapela
Figura 18: Diagrama de Actividades Imprimir Escarapela
Fuente: Elaboración propia.
63
Diagrama de Actividades Generar Reporte
Figura 19: Diagrama de Actividades Generar Reporte
Fuente: Elaboración propia
64
8.2.5 Modelo Relacional
Figura 20: Modelo Relacional Base de Datos
Fuente: Elaboración propia
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
Fuente: Elaboración propia
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
EventSubscriberInterface
AddCiudadSubscriber
- factory: var
+ __construct(FormFactoryInterface): var
+ getSubscribedEvents(): var
- addCiudadForm(var, var): var
+ preSetData(FormEvent): var
+ preBind(FormEvent): var
EventSubscriberInterface
AddPaisSubscriber
- factory: var
+ __construct(FormFactoryInterface): var
+ getSubscribedEvents(): var
- addPaisForm(var, var): var
+ preSetData(FormEvent): var
+ preBind(FormEvent): var
Ciudad
- id: var
- nombreCiudad: var
- estado: var = true
- departamento: var
+ setId(var): var
+ getId(): var
+ setNombreCiudad(var): var
+ getNombreCiudad(): var
+ setEstado(var): var
+ getEstado(): var
+ setDepartamento(\EventosSCO\PrincipalBundle\Entity\Departamento): var
+ getDepartamento(): var
+ __toString(): var
Departamento
- id: var
- nombreDepartamento: var
- estado: var = true
- pais: var
+ setId(var): var
+ getId(): var
+ setNombreDepartamento(var): var
+ getNombreDepartamento(): var
+ setEstado(var): var
+ getEstado(): var
+ setPais(\EventosSCO\PrincipalBundle\Entity\Pais): var
+ getPais(): var
+ __toString(): var
Pais
- id: var
- nombrePais: var
- estado: var = true
+ setId(var): var
+ getId(): var
+ setNombrePais(var): var
+ getNombrePais(): var
+ setEstado(var): var
+ getEstado(): var
+ __toString(): var
EventSubscriber
AuditsSubscriber
# container: var
+ __construct(ContainerInterface): var
+ getSubscribedEvents(): 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
Fuente: Elaboración propia
68
Clase Evento
Figura 22: Diagrama de Clases – Contexto Evento class Class Model Ev ento
Controller
Controller::EventoController
+ indexAction(Request): var
+ createAction(Request): var
- createCreateForm(Evento): var
+ newAction(): var
+ showAction(var): var
+ editAction(var): var
- createEditForm(Evento): var
+ updateAction(Request, var): var
+ deleteAction(Request, var): var
- createDeleteForm(var): var
+ buscaAsistentesAction(var): var
+ insertarAsistentesAction(Request, var): var
+ importarAsistentesAction(): var
+ subirAsistentesAction(Request): var
+ verAyudaMasivoAction(): var
+ cargarAsistentesMasivoAction(): var
+ quitarAsistentesAction(Request, var): var
+ paginarAsistentesAction(Request, var): var
+ buscaConferencistasAction(Request): var
+ verEscarapelaAction(var): var
+ actualizarCronogramaAction(Request, var): var
- crearFiltros(var): var
Entity::Evento
- id: var
- codigoEvento: var
- nombreEvento: var
- estadoEvento: var
- fechaInicioEvento: var
- fechaFinEvento: var
- numeroMaxParticipantes: var
- valorInscripcion: var
- descripcion: var
- estado: var = true
- 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
+ setEstado(var): 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
+ buildForm(FormBuilderInterface, array): var
+ setDefaultOptions(OptionsResolverInterface): var
+ getName(): var
Entity::Ubicacion
- id: var
- nombreUbicacion: var
- direccion: var
- estado: var = true
- seccional: var
+ setId(var): var
+ getId(): var
+ setNombreUbicacion(var): var
+ getNombreUbicacion(): var
+ setDireccion(var): var
+ getDireccion(): var
+ setEstado(var): var
+ getEstado(): var
+ setSeccional(\EventosSCO\PrincipalBundle\Entity\Seccional): var
+ getSeccional(): var
Entity::Asistente
- alDia: var
- fechaIngreso: var
- saldoAnualidad: var
- id: var
- evento: var
+ __construct(): 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
+ __construct(): var
+ setEspecialidad(var): var
+ getEspecialidad(): var
+ setId(\EventosSCO\PrincipalBundle\Entity\Persona): var
+ getId(): var
+ getEventosscoPrincipalbundlePersona(): var
+ setEventosscoPrincipalbundlePersona(\EventosSCO\PrincipalBundle\Entity\Persona): var
EventSubscriber
EventListener::AuditsSubscriber
# container: var
+ __construct(ContainerInterface): var
+ getSubscribedEvents(): var
+ preUpdate(LifecycleEventArgs): var
+ index(LifecycleEventArgs): var
Entity::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
Entity::TipoEvento
- id: var = ''
- nombreTipoEvento: var
- estado: var = true
+ getId(): var
+ setId(var): var
+ setNombreTipoEvento(var): var
+ getNombreTipoEvento(): var
+ setEstado(var): var
+ getEstado(): var
0..* 1..*
1 0..*
1..*0..*
«use»
10..*
Fuente: Elaboración propia
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
+ __construct(): 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::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
- estado: var = true
- 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
+ setEstado(var): var
+ getEstado(): var
+ setCiudad(\EventosSCO\PrincipalBundle\Entity\Ciudad): var
+ getCiudad(): var
Entity::Ciudad
- id: var
- nombreCiudad: var
- estado: var = true
- departamento: var
+ setId(var): var
+ getId(): var
+ setNombreCiudad(var): var
+ getNombreCiudad(): var
+ setEstado(var): var
+ getEstado(): var
+ setDepartamento(\EventosSCO\PrincipalBundle\Entity\Departamento): var
+ getDepartamento(): var
+ __toString(): var
Controller
Controller::AsistenteController
+ verAsistentesMasivoAction(): var
+ cargarMasivoAction(): var
+ reporteMasivoAction(): var
+ indexAction(Request): var
+ createAction(Request): var
- createCreateForm(Asistente): var
+ newAction(): var
+ showAction(var): var
+ editAction(var): var
- createEditForm(Asistente): var
+ updateAction(Request, var): var
+ deleteAction(Request, var): var
- createDeleteForm(var): var
- crearFiltros(var): var
EventSubscriber
EventListener::AuditsSubscriber
# container: var
+ __construct(ContainerInterface): var
+ getSubscribedEvents(): var
+ preUpdate(LifecycleEventArgs): var
+ index(LifecycleEventArgs): var
AbstractType
Form::AsistenteType
+ buildForm(FormBuilderInterface, array): var
+ setDefaultOptions(OptionsResolverInterface): var
+ getName(): var
EventSubscriberInterface
EventListener::
AddDepartamentoSubscriber
- factory: var
+ __construct(FormFactoryInterface): var
+ getSubscribedEvents(): var
- addDepartamentoForm(var, var, var): var
+ preSetData(FormEvent): var
+ preBind(FormEvent): var
EventSubscriberInterface
EventListener::AddCiudadSubscriber
- factory: var
+ __construct(FormFactoryInterface): var
+ getSubscribedEvents(): var
- addCiudadForm(var, var): var
+ preSetData(FormEvent): var
+ preBind(FormEvent): var
EventSubscriberInterface
EventListener::AddPaisSubscriber
- factory: var
+ __construct(FormFactoryInterface): var
+ getSubscribedEvents(): var
- addPaisForm(var, var): var
+ preSetData(FormEvent): var
+ preBind(FormEvent): var
Entity::Departamento
- id: var
- nombreDepartamento: var
- estado: var = true
- pais: var
+ setId(var): var
+ getId(): var
+ setNombreDepartamento(var): var
+ getNombreDepartamento(): var
+ setEstado(var): var
+ getEstado(): var
+ setPais(\EventosSCO\PrincipalBundle\Entity\Pais): var
+ getPais(): var
+ __toString(): var
Entity::Pais
- id: var
- nombrePais: var
- estado: var = true
+ setId(var): var
+ getId(): var
+ setNombrePais(var): var
+ getNombrePais(): var
+ setEstado(var): 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
- estado: var = true
- 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
+ setEstado(var): 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
- 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..*
1 1
1 1
0..*
1
0..*
1
«use»
Fuente: Elaboración propia
70
8.3.3 Mapa de Navegación
Mapa de Navegación Primera Parte
Figura 24: Mapa de Navegación Primera Parte
Fuente: Elaboración propia
71
Mapa de Navegación Segunda Parte
Figura 25: Mapa de Navegación Segunda Parte
Fuente: Elaboración propia
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.
Fuente: Elaboración propia
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()
Fuente: Elaboración propia
75
Diagrama de Secuencia Crear Asistente
Figura 27: Diagrama de Secuencia Crear Asistentes
sd Crear asistentes
app.php EntityManagerrouting MySql
Otra acciónOtra acción
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»
Fuente: Elaboración propia
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
Otra acciónOtra acción
render()
Persist(Asistente)
«Insert»
cargarMasivoAction()
«Muestra Reporte de Subida»
«TWIG»
Clic:Cargar()
«Subir Excel»
flush()
request(asistente_masivo_cargar)
Fuente: Elaboración propia
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
Otra acciónOtra acción
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»
Fuente: Elaboración propia
78
Diagrama de Secuencia Imprimir Escarapela
Figura 30: Diagrama de Secuencia Imprimir Escarapela
sd Imprimir Escarapela
Registrador
Detalle EventoDetalle Evento
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»
getRepository(PrincipalBundle:Asistente)
«Escribe documento»
render()
«Arreglo Asistentes»
window.print()
Clic:Buscar()
getRepository(PrincipalBundle:Asistente)
Fuente: Elaboración propia
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
Otra acciónOtra acción
render()
request(informe_grafico)
«Arreglo Entidades»
«Result»
createQuery(dql)
Clic:Grafico()
«Manager»
generarArregloSeries(row)
«Mostrar Tabla»
«TWIG»
«Select»
getManager()
informeGraficoAction(request)
Fuente: Elaboración propia
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
Otra acciónOtra acción
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»
Fuente: Elaboración propia
81
8.3.7 Repositorio Fuentes Versionadas
Figura 33: Tortoise - Versionamiento Fuentes del Proyecto
Fuente: Elaboración propia
82
8.3.8 Prototipo Web
Figura 34: Pagina Inicial Prototipo Web
Fuente: Elaboración propia
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.
o Procedimiento de Prueba:
El usuario con el rol de administrador despliega la pestaña
“EVENTOS” y pulsa el enlace “Evento”.
86
El sistema direcciona la aplicación al listado de los eventos
creados en el sistema.
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.
o Procedimiento de Prueba:
El usuario con el rol de administrador despliega la pestaña
“EVENTOS” y pulsa el enlace “Evento”.
87
El sistema direcciona la aplicación al listado de los eventos
creados en el sistema.
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
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:
El usuario con el rol de administrador despliega la pestaña
“ASISTENTES” y pulsa el enlace “Asistente”.
El sistema direcciona la aplicación al listado de los asistentes
creados en el sistema.
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
o Procedimiento de Prueba:
El usuario con el rol de administrador despliega la pestaña
“ASISTENTES” y pulsa el enlace “Asistente”.
El sistema direcciona la aplicación al listado de los eventos
creados en el sistema.
Después el usuario filtra los asistentes si así lo requiere
ingresando la información y dando clic en “Buscar”.
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 usuario debe tener el rol de registrador.
El asistente debe existir en el sistema.
90
o Procedimiento de Prueba:
El usuario con el rol de administrador despliega la pestaña
“ASISTENTES” y pulsa el enlace “Asistente”.
El sistema direcciona la aplicación al listado de los eventos
creados en el sistema.
Después el usuario filtra los asistentes si así lo requiere
ingresando la información y dando clic en “Buscar”.
Al encontrar el evento requerido, el administrador pulsa sobre
la hoja con una lupa que está en la columna de “Acciones” o
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.
o Procedimiento de Prueba:
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 usuario debe tener el rol de registrador.
o Procedimiento de Prueba:
El registrador 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.
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
la hoja con una lupa que está en la columna de “Acciones” o
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.
o Procedimiento de Prueba:
El registrador 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.
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
la hoja con una lupa que está en la columna de “Acciones” o
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.
o Procedimiento de Prueba:
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
Al encontrar el evento requerido, el administrador pulsa sobre
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.
o Procedimiento de Prueba:
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”.
Al encontrar el evento requerido, el administrador pulsa sobre
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.
Fuente: Elaboración propia
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:
http://eugeniabahit.blogspot.com/2011/07/poo-y-mvc-en-php.html
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
108
109
110
111
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
Otra acciónOtra acción
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
EntityManagerrouting MySql
Otra acciónOtra acción
Detalle EventoDetalle Evento
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
EntityManagerrouting MySql
Detalle EventoDetalle Evento
Otra acciónOtra acción
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
Otra acciónOtra acción
AsistenteController
«Muestra Lista Asistentes»
indexAction(request)
«result»
Clic:Asistentes()
«select»
«repository»
«Arreglo Asistentes»
request(asistente)
render()
find(arrayFilters)
«TWIG»
getRepository(PrincipalBundle:Asistente)
118
Diagrama de Secuencia Editar Asistente
sd Editar asistentes
app.php EntityManagerrouting MySql
Otra acciónOtra acción
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
app.php EntityManagerrouting MySql
Otra acciónOtra acción
AsistenteAsistenteController
Detalle AsistenteDetalle Asistente
Registrador
flush()
request(asistente_delete)
persist(Asistente)
«Mostrar Listado Asistentes»
Clic:Eliminar()
render()
deleteAction(request)
«update»
setEstado(false)
«TWIG»
Recommended