Sublime Poll Ejemplo

UNIVERSIDAD DE SANTIAGO DE CHILE
FACULTAD DE INGENIERÍA
DEPARTAMENTO DE INGENIERÍA INFORMÁTICA
INFORME PROYECTO SUBLIME POLL SYSTEM

ADMINISTRACIÓN Y GESTIÓN INFORMÁTICA
MATÍAS FUENTES
RICARDO ÁLVAREZ
SEBASTIÁN PINTO-AGÜERO
PABLO CANCINO
DIEGO SUÁREZ
MARÍA JESÚS CAMPOS
BASTIÁN SANTANA ROBLES
SEBASTIÁN REINOSO
Profesor:Vı́ctor Parada
Ayudante: Fabián Gómez
Santiago - Chile
15 de septiembre de 2017
TABLA DE CONTENIDOS
ÍNDICE DE FIGURAS................................................................................................. vi
ÍNDICE DE TABLAS................................................................................................... viii
CAPÍTULO 1. INTRODUCCIÓN ........................................................................... 1

1.1 CONTEXTO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 MISIÓN Y VISIÓN COMO EMPRESA . . . . . . . . . . . . . . . . . 2
1.2.1 Misión . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2.2 Visión . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.3 MOTIVACIÓN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.4 OBJETIVOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.4.1 Objetivos Principales . . . . . . . . . . . . . . . . . . . . . . . . 2
1.4.2 Objetivos Especı́ficos . . . . . . . . . . . . . . . . . . . . . . . . 3
1.5 ESTRUCTURA DEL INFORME . . . . . . . . . . . . . . . . . . . . . 3
CAPÍTULO 2. DEFINICIONES Y ACRÓNIMOS ................................................ 5
CAPÍTULO 3. PLANIFICACIÓN DEL PROYECTO........................................... 7

3.1 Descripción de los equipos de trabajo . . . . . . . . . . . . . . . . . . . . 7
3.2 CARTA GANTT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
CAPÍTULO 4. ANÁLISIS DEL PROYECTO ........................................................ 13

4.1 METODOLOGı́A DE DESARROLLO DE PROYECTOS . . . . . . . . 13
4.1.1 Metodologı́a cascada . . . . . . . . . . . . . . . . . . . . . . . . 13
iii
iv
4.2 METODOLOGı́AS DE DESARROLLO DE SOFTWARE . . . . . . . . 14

4.2.1 Metodologı́as ágiles . . . . . . . . . . . . . . . . . . . . . . . . . 14
4.2.1.1 Metodologı́a Scrum . . . . . . . . . . . . . . . . . . . . . 14
4.3 ESTADO DEL ARTE . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.4 EVALUACIÓN DE EMPRESA . . . . . . . . . . . . . . . . . . . . . . 21
4.4.1 Viabilidad del Proyecto . . . . . . . . . . . . . . . . . . . . . . . 21
4.4.2 Riesgos del Proyecto . . . . . . . . . . . . . . . . . . . . . . . . 21
4.5 OFERTA Y DEMANDA . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.5.1 Oferta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.5.2 Demanda . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.6 ESTUDIO DE MERCADO . . . . . . . . . . . . . . . . . . . . . . . . 31
4.6.1 Tabulación de los resultados . . . . . . . . . . . . . . . . . . . . 34
4.7 COSTOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
CAPÍTULO 5. TECNOLOGı́AS PARA DAR SOLUCIÓN AL PROBLEMA .... 37

5.1 FRAMEWORK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
5.1.1 Laravel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
5.1.1.2 Migraciones . . . . . . . . . . . . . . . . . . . . . . . . . 39
5.1.1.3 Blade . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
5.1.2 CodeIgniter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
5.1.3 Symfony . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
5.2 CUADRO COMPARATIVO . . . . . . . . . . . . . . . . . . . . . . . . 42
5.3 FRAMEWORK FRONT-END . . . . . . . . . . . . . . . . . . . . . . . 42
5.3.1 Bootstrap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
5.3.2 Foundation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
5.3.3 Pure CSS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
5.4 SISTEMA DE GESTIÓN DE BASES DE DATOS . . . . . . . . . . . . 46
5.4.1 PostgreSQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
5.4.2 MySQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
v
5.4.3 MongoDB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
5.5 ELECCIÓN DE TECNOLOGı́AS . . . . . . . . . . . . . . . . . . . . . 51
CAPÍTULO 6. DISEÑO DEL PROYECTO............................................................ 53

6.1 DISEÑO Y CREATIVIDAD . . . . . . . . . . . . . . . . . . . . . . . . 53
6.2 REQUISITOS FUNCIONALES . . . . . . . . . . . . . . . . . . . . . . 55
6.3 REQUISITOS NO FUNCIONALES . . . . . . . . . . . . . . . . . . . 55
6.4 CASOS DE USOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
6.4.1 Prototipos de la aplicación . . . . . . . . . . . . . . . . . . . . . 62
CAPÍTULO 7. IMPLEMENTACIÓN...................................................................... 67
7.1 DIAGRAMAS DE SECUENCIA . . . . . . . . . . . . . . . . . . . . . 67
7.2 DIAGRAMA DE COMPONENTES . . . . . . . . . . . . . . . . . . . 69
7.3 MODELO ENTIDAD-RELACIÓN . . . . . . . . . . . . . . . . . . . . 70
CAPÍTULO 8. CONCLUSIÓN ................................................................................ 71
CAPÍTULO 9. BIBLIOGRAFı́A .............................................................................. 73

ÍNDICE DE FIGURAS
Figura 3-1: Organigrama . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

Figura 3-2: Reuniones. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Figura 3-3: Estado del arte. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Figura 3-4: Costos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Figura 3-5: Planificación 1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Figura 3-6: Planificación 2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Figura 3-7: Implementación 1. . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Figura 4-1: Diagrama de flujo de datos . . . . . . . . . . . . . . . . . . . . . . 20
Figura 4-2: Respuestas de la pregunta 1 . . . . . . . . . . . . . . . . . . . . . 31
Figura 5-1: Frameworks mas usados 2017 . . . . . . . . . . . . . . . . . . . . 37
Figura 6-1: Prototipo de logo 1 . . . . . . . . . . . . . . . . . . . . . . . . . . 54
Figura 6-4: Logo escogido . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
Figura 6-5: Prototipo de aplicación - Creación de encuesta 1 . . . . . . . . . . 62
vi
vii

Figura 6-9: Prototipo de aplicación - Responder encuesta . . . . . . . . . . . . 64
Figura 6-10: Prototipo de aplicación - Comentario o sugerencia . . . . . . . . . 64
Figura 6-11: Prototipo de aplicación - Lista de encuestas creadas . . . . . . . . 64
Figura 6-12: Prototipo de aplicación - Lista de encuestas disponibles . . . . . . 65
Figura 7-1: Diagrama de secuencia - Respondiendo una encuesta en lı́nea . . . 67
Figura 7-2: Diagrama de secuencia - Creando una nueva encuesta . . . . . . . . 68
Figura 7-3: Diagrama de secuencia - Consultando resultados de una encuesta . . 68
Figura 7-4: Diagrama de componentes . . . . . . . . . . . . . . . . . . . . . . 69
Figura 7-5: Modelo Entidad-Relación de la base de datos . . . . . . . . . . . . 70
viii
ÍNDICE DE TABLAS
Tabla 4.1: Descripción riesgos Marketing . . . . . . . . . . . . . . . . . . . . 23

Tabla 4.2: Descripción de riesgos recursos humanos . . . . . . . . . . . . . . . 24
Tabla 4.3: Descripción riesgos QA . . . . . . . . . . . . . . . . . . . . . . . . 25
Tabla 4.4: Descripción riesgos IT . . . . . . . . . . . . . . . . . . . . . . . . . 26
Tabla 4.5: Análisis riesgos - Parte 1 . . . . . . . . . . . . . . . . . . . . . . . . 27
Tabla 4.6: Análisis riesgos - Parte 2 . . . . . . . . . . . . . . . . . . . . . . . . 28
Tabla 4.7: Tabla de riesgos y estrategias . . . . . . . . . . . . . . . . . . . . . 29
Tabla 4.8: Resumen respuestas de la pregunta 7 . . . . . . . . . . . . . . . . . 34
Tabla 4.9: Tabulación de las respuestas . . . . . . . . . . . . . . . . . . . . . . 34
Tabla 4.10: Costos Estimados Proyecto . . . . . . . . . . . . . . . . . . . . . . 35
Tabla 5.1: Comparación Frameworks Laravel, CodeIgniter y Symfony . . . . . 42
Tabla 5.2: Tabla Comparativa entre PostgreSQL, MySQL y MongoDB . . . . . 51
Tabla 6.1: Caso de uso 01 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
Tabla 6.2: Caso de uso 02 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
Tabla 6.3: Caso de uso 03 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
Tabla 6.4: Caso de uso 04 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
Tabla 6.5: Caso de uso 05 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
Tabla 6.6: Caso de uso 06 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
CAPÍTULO 1. INTRODUCCIÓN
En el presente capı́tulo se expone la descripción del problema y se plantean los objetivos
del trabajo y los alcances de éste.
1.1 CONTEXTO
A lo largo de los años, las encuestas se fueron transformando en una herramienta de gran
importancia en la sociedad, ya que de esta se desprende un recurso de gran valor: la infor-
mación.
Se debe tener en cuenta que la información obtenida de una encuesta no es totalmente con-
fiable, ya que, considerando el publico objetivo y el tiempo aplicado en la realización de
la encuesta, no siempre es posible su realización en la totalidad de la población escogida.
Por ello y por variadas razones, puede existir un margen de error en su realización, pero
obteniendo una cantidad de respuestas representativas de la población, y reduciendo la
posibilidad de errores con preguntas simples u otras formas, es posible obtener resultados
válidos, los que representan el pensamiento colectivo del público objetivo.
De las respuestas obtenidas se pueden realizar estudios y predicciones, de esta forma rea-
lizar planificaciones, estrategias y tomar decisiones que pueden ser a nivel de empresarial,
nacional o internacional, e ahı́ la gran importancia de las encuestas.
Las encuestas se pueden clasificar en dos tipos: presenciales o virtuales. Para las encues-
tas presenciales es necesario lugar fı́sico para su realización, lo que dificulta en muchas
situaciones la recolección de información, esto debido al tiempo y a las distancias que
pueden existir, al contrario de las encuestas virtuales, en las que solamente se hace nece-
saria la capacidad de ingresar al software en donde se encuentra la encuesta, lo que reduce
considerablemente los impedimentos para que una persona interesada pueda expresar su
opinión, ası́ se hace posible recolectar más información y de un publico mas variado.
2 CAPÍTULO 1: INTRODUCCIÓN
1.2 MISIÓN Y VISIÓN COMO EMPRESA
1.2.1 Misión
Nuestra misión como empresa es ofrecer el servicio de encuestas con una mirada diferen-
te, utilizando las ventajas que ofrecen las tecnologı́as actuales. Ofrecemos una experiencia
personalizada y cercana con el cliente, donde el software ofrecido se ajusta a las necesida-
des del cliente.
1.2.2 Visión
Nuestra visión es proveer una alternativa confiable a los sistemas de votación en lı́nea,
producir software de calidad y seguro, que genere confianza hacia los usuarios y asegurar
la integridad, privacidad y disponibilidad de la información de tal forma que pueda ser
consultada en cualquier momento.
1.3 MOTIVACIÓN
Debido al bajo numero de participantes en las votaciones para la toma de decisiones y el
interés en la aplicación de encuestas en la Universidad de Santiago de Chile (USACH),
nuestro cliente, Sergio Llanos nos solicita la creación de una plataforma web para la rea-
lización encuestas y votaciones, en la que pueda realizarse este tipo de recopilaciones de
información sobre la comunidad universitaria, tanto de su totalidad, como de un grupo en
especifico, todo esto, manteniendo una completa seguridad en la información recopilada.
1.4 OBJETIVOS
A continuación, se presentan los objetivos generales y especı́ficos del proyecto para di-
mensionar las capacidades y limitaciones que este posee.
1.4.1 Objetivos Principales
El objetivo principal es la creación e implementación de una plataforma web para la
Universidad de Santiago de Chile que permita la realización de votaciones y encuestas
dirigidas a la comunidad universitaria.
CAPÍTULO 1: INTRODUCCIÓN 3
1.4.2 Objetivos Especı́ficos
1. Implementación de un sistema de notificación por correo a los invitados a responder,

ya sea una encuesta o votación.
2. Posibilidad de realización de filtros dentro de la comunidad universitaria, esto es,

poder seleccionar quien esta facultado para responder la encuesta o votación, ya sea
de un departamento, una carrera, un curso o una sección dentro de la universidad.
3. Creación de una sistema que asegure los datos recopilados, para que no exista la
posibilidad de intrusiones, o problemas de cualquier ı́ndole.
1.5 ESTRUCTURA DEL INFORME

El presente informe contempla la primera fase del proyecto, es decir, todo lo relacionado
con la investigación. análisis y planificación del proyecto.
Primero se establece la planificación del proyecto que incluye organización del equipo,
definición de roles y construcción del plan del proyecto, incluyendo un desglose de acti-
vidades presentado en la Carta Gantt. Se continúa con el análisis del proyecto en el cual
abarca desde las metodologı́as de desarrollo usadas, el estado del arte, las tecnologı́as dis-
ponibles para dar solución al problema, el análisis económico y el interés del mercado.
Luego se proseguirá con el área asociada al diseño del proyecto, donde se encuentra el di-
seño y selección de logotipo, ası́ como la selección de nombre del producto, para continuar
con los requisitos funcionales y no funcionales, los casos de uso del proyecto y los proto-
tipos de diseño. Finalmente se concluye con el grado de logro de los objetivos establecidos.
CAPÍTULO 2. DEFINICIONES Y ACRÓNIMOS
A continuación, se dan a conocer las definiciones y acrónimos relacionados con el proyec-
to, los cuales son necesarios para comprender de mejor manera los contenidos abordados
en este informe.
1. PHP: PHP Hypertext Preprocessor.
2. FTP: Protocolo de transferencia de Archivos.
3. MVC: Arquitectura Modelo-Vista-Controlador.
4. HTML: HyperText Markup Language.
5. CSS: Cascading Style Sheets.
6. PC: Acrónimo de Personal Computer.
7. DB: Acrónimo de DataBase que traducido al español es base de datos.
8. ACID: Atomicity, Consistency, Isolation and Durability.
9. Página web: Es un documento o información electrónica, con capacidad de conte-

ner diversos elementos [Esp17c].
10. Aplicación web: Corresponde los programas informáticos que son ejecutados en-
torno a un navegador [ALE17].
11. Front-end: Programador encargado de la capa de presentación visual para el usuario

[Dia].
12. Back-end: Programador encargado de la programación que interactúa con la base

de datos y gestiona los servidores de la página [Dia].
13. Base de datos: Conjunto de datos almacenados estructuralmente [Esp17a].
14. Hardware: Es el conjunto de elementos fı́sicos que componen una computadora

[Esp17b].
6 CAPÍTULO 2: DEFINICIONES Y ACRÓNIMOS
15. Framework: Es un esquema, patrón, esqueleto, para el desarrollo de software [Gut06].
16. Software: Conjunto de programas y rutinas que permiten a la computadora realizar

determinadas tareas [Esp17e].
17. Prototipo: Maqueta del producto en fase de desarrollo, con propósitos de demostrar
funcionalidades o visualización aproximada del producto final [Esp17d].
18. Casos de uso: Modelo de comportamiento de las funcionalidades de un software

[Cer01].
19. Carta Gantt: Modelo de actividades en una lı́nea de tiempo [gan].
20. Alcance: Alcance o scope, corresponde a los objetivos fijados y los servicios que se
espera brindar al cliente según los requerimientos de este.
21. API: Conocido como Interfaz de Programación de Aplicaciones, es un conjunto de

comandos, ası́ como el formato de estos comandos, que un programa puede enviar
a otro con el propósito de comunicarse [Quo].
CAPÍTULO 3. PLANIFICACIÓN DEL PROYECTO
Se presenta el organigrama presente para esta fase del proyecto, definiendo las áreas y
roles que deben cumplir los miembros del equipo para el proyecto. Para fases posteriores
del proyecto, esta organización de roles puede variar dependiendo de la necesidad que se
presente.
Figura 3-1: Organigrama
3.1. Descripción de los equipos de trabajo

Se definieron cuatro sectores de trabajo, encargados cada uno de un área particular del
proyecto, las que son definidas de la siguiente manera:
Tecnologı́as de la información: Es el área encargada de realizar la investigación

correspondiente a las tecnologı́as que se utilizarán en el desarrollo del proyecto. En
8 CAPÍTULO 3: PLANIFICACIÓN DEL PROYECTO
esta primera etapa los integrantes están destinados a la recopilación de información

sobre las diferentes tecnologı́as usadas para dar solución al problema, esto contem-
pla una investigación de diferentes Frameworks Web, Frameworks Front-end y sobre
los diferentes Sistemas de gestión de bases de datos que pueden ser usados.
Control de calidad (desde ahora QA): Área encargada de verificar la calidad y el

funcionamiento de cada parte del proyecto. En esta primera etapa son los encargados
de la realización de revisiones y de los casos de uso basado en los requerimientos
funcionales.
Marketing: El área de marketing es la encargada de orientar comercialmente el

producto, determinando el modelo de negocios asociado y elaborando la estrategia
comercial a seguir para lograr los ejercicios planteados en el proyecto. En esta pri-
mera fase están encargados de analizar la situación actual del mercado respecto al
producto, considerando a la competencia existente y productos similares, realizando
predicciones del comportamiento del mercado con la elaboración y realización de
encuestas relativas al interés del mercado y el producto.
Recursos Humanos: Encargados de documentar lo relativo a este proyecto, iden-

tificando palabras técnicas y acrónimos para su posterior definición. También es el
encargado de reconocer los posibles riesgos que puedan afectar el desarrollo plani-
ficado del proyecto.
CAPÍTULO 3: PLANIFICACIÓN DEL PROYECTO 9
3.2 CARTA GANTT
Se presenta la Carta Gantt donde se aprecia el desglose de actividades planificadas para

la realización del proyecto.
Figura 3-2: Reuniones.
Figura 3-3: Estado del arte.

10 CAPÍTULO 3: PLANIFICACIÓN DEL PROYECTO
Figura 3-4: Costos.
Figura 3-5: Planificación 1.
Figura 3-6: Planificación 2.

CAPÍTULO 3: PLANIFICACIÓN DEL PROYECTO 11
Figura 3-7: Implementación 1.

CAPÍTULO 4. ANÁLISIS DEL PROYECTO
En este capı́tulo se realiza la selección de metodologı́a a utilizar, análisis de la situación
actual y la factibilidad que presenta el proyecto. Para realizar cualquier clase de decisión,
se debe tener en cuenta las restricciones que está sujeto el proyecto: fecha lı́mite, recursos
disponibles, capacidad del equipo, situación actual del mercado, todos los costos relacio-
nados para la realización y mantención del producto.
4.1 METODOLOGÍA DE DESARROLLO DE PROYECTOS

Los metodologı́as tradicionales para gestionar proyectos son fuertemente estructurados,
ya que cuentan con un plan de desarrollo compuesto por fases bien definidas. General-
mente se componen de cuatro fases o procesos; inicialización, planificación, ejecución,
seguimiento y cierre. Los procesos se desarrollan de manera secuencial y no se acepta
empezar con una fase en particular si la fase anterior no esta finalizada. Los procesos
generales son inmutables, es decir, en un proceso no se pueden realizar actividades que
contemplen otro proceso.
4.1.1 Metodologı́a cascada
La metodologı́a cascada se caracteriza por ser un marco de trabajo lineal, lo cual hace
tener un ciclo de vida unidireccional en donde los alcances del proyecto no se puede
cambiar y deben ser cumplidos, por lo que cualquier modificación que el cliente requiera
a lo largo del proyecto significarı́a modificar el trabajo realizado previamente.
Sus ventajas son:
Es apropiado para proyectos estables, es decir, que no sufran cambios en sus requi-
sitos en sus diferentes etapas de desarrollo.
Cada fase está fuertemente definida, con periodos establecidos y escalonados.
Facilita la gestión y evaluación del proyecto gracias a la organización y documentos

adjuntos en cada fase.
14 CAPÍTULO 4: ANÁLISIS DEL PROYECTO
Por otra parte, existen las siguientes desventajas:
Rara vez en la vida real se logra captar el camino correcto para el desarrollo de
soluciones, entonces, un proyecto se ve vulnerable a cambios constantemente y per-
judica la linealidad del modelo cascada.
No existen entregas del producto hasta que éste se encuentra ya finalizado, por lo
que el cliente no puede ver los avances.
No es recomendable para proyectos de larga duración y complejos, propensos a

constantes cambios.
4.2 METODOLOGÍAS DE DESARROLLO DE SOFTWARE

Las metodologı́as de desarrollo de software, como su nombre sugiere, son un conjunto
de métodos y prácticas que apoyan el desarrollo de un sistema de software, plantando las
bases de este mismo en todos sus ámbitos; captura de requerimientos, análisis, diseño, im-
plementación y evolución. A lo largo de las décadas han existido diversas metodologı́as de
desarrollo de software, también conocidas como “ciclo de vida del software”. De acuerdo
a las caracterı́sticas de la metodologı́a, esta puede ser utilizada durante todo el proyecto o
bien en fases especı́ficas.
4.2.1 Metodologı́as ágiles
Las metodologı́as ágiles se especializan en cubrir el mercado que las tradicionales no
pueden abarcar. Estas metodologı́as son ideales para proyectos de pequeña y mediana en-
vergadura, donde las componentes de tiempo, costos monetarios y capital humano son
reducidas. A pesar de esto, en los últimos años se han empleado experimentalmente me-
todologı́as ágiles para satisfacer proyectos de gran envergadura, ya que el mercado ha
aprendido a confiar en su calidad.
4.2.1.1 Metodologı́a Scrum
Esta metodologı́a es quizás la más revolucionaria de las metodologı́as ágiles, ya que se
caracteriza por entregar un producto en un corto plazo. Scrum tiene por objetivo la entrega
oportuna de un producto de calidad que cumpla con las expectativas del cliente. En esta
CAPÍTULO 4: ANÁLISIS DEL PROYECTO 15
metodologı́a se definen diversos participantes, los cuales permiten el desarrollo de esta

desde diversas aristas:
Dueño del producto: Es quien vela por los intereses del producto. Participa de for-
ma activa en la elaboración del software, cumpliendo el rol de consultor y evaluador
de calidad en cada sprint. El dueño del producto no necesariamente es quién financia
el proyecto, pero si es el intermediario entre el equipo de trabajo, los interesados y
el dueño del negocio.
Facilitador (Scrum Máster): Es el encargado de dirigir el equipo de trabajo. El

facilitador debe ser el miembro del equipo que más conocimientos tenga respecto al
contexto del producto, debe tener mayor cercanı́a con el dueño del producto y es el
encargado de liderar las reuniones de trabajo.
Equipo de trabajo: Es el equipo que se involucran directamente en el desarrollo

del producto. Este equipo considera a los desarrolladores de software, analistas,
examinadores, aseguradores de calidad, el facilitador y el dueño del producto.
Interesados e involucrados: Los interesados e involucrados (en inglés, stakehol-

ders) son quienes presentan interés en el desarrollo o se ven afectados de alguna
forma por el proyecto. Dentro de este grupo de personas se puede considerar a los
demás integrantes del equipo de trabajo. Particularmente se menciona como intere-
sados e involucrados a los inversionistas (quienes perciben beneficio económico),
proveedores (proporcionan material que promueve el desarrollo del producto) y a
los interesados (no perciben beneficio económico, pero de todas formas se interesan
en el desarrollo del producto).
Usuarios: Son los usuarios finales del producto. Toda persona que vaya a utilizar
este producto y que no haya estado involucrada en el desarrollo del software es
considerada un usuario.
Para el desarrollo del Scrum, se hacen uso de diversas herramientas que facilitan la
metodologı́a y le aportan dinamismo.
Iteración: Se utiliza el término Iteración o Sprint para definir un ciclo iterativo con-
sistente en la planificación, desarrollo, análisis, pruebas y entrega de un producto
mı́nimo viable que representa un porcentaje del producto total a desarrollar. Se espe-
ra que a medida que las Iteraciones avanzan, el producto progrese en su terminación
hasta culminar en el producto completo.
Historias de usuario: Las historias de usuario resumen los diversos tipos de interac-
ciones que tienen los diferentes usuarios con el sistema. Estas historias de usuario,
que son propias de la metodologı́a programación extrema, son también adoptadas
por Scrum debido a su simpleza y a que se relacionan directamente con los requeri-
mientos y casos de uso.
Pila del producto: Corresponde al conjunto de requerimientos, historias de usuario

y casos de uso que utiliza el dueño del producto para definir y priorizar lo que espera
y desea del proyecto de software a desarrollar. La prioridad de cada elemento en la
pila de producto se da en orden descendiente, dejando de esta forma en primer lugar
lo que el cliente considera más urgente o vital para su producto.
Pila de la iteración: Es el conjunto priorizado de tareas por realizar, que nacen de

la descomposición de la pila del producto. A diferencia de la pila del producto, la
pila del iteraciones no es priorizada por el dueño del producto, sino que por el mis-
mo equipo de trabajo, usualmente mediante una técnica estimativa de trabajo deno-
minada planificación póquer. Las prioridades se establecen considerando un orden
descendiente de dificultad, dejando como más urgente a las tareas más complejas
para ası́ asegurar la entrega de un producto mı́nimo viable al finalizar el sprint.
Planificación póquer: Es el proceso mediante el cual se asignan grados de difi-

cultad a cada una de las tareas. Como su nombre propone, se realiza mediante un
proceso que intenta imitar un juego de póquer en el cual se plantea una tarea es-
pecı́fica en cada ronda, y donde los miembros del equipo de trabajo, incluyendo
al Facilitador, poseen cartas numeradas con 0, 1/2, 1, 2, 3, 5, 8, 13, 20, 40 y 100,
que representan el grado de dificultad que los miembros estiman que tiene la tarea
en juego. Adicionalmente, existen cartas de interrogación (signo ¿”) que representa
incertidumbre, y una cartas con una taza de café, las cuales invitan a un descanso.
Kanban: Corresponde a un tablero (fı́sico o digital, denominado tablero kanban),

que se compone por zonas que representan estado de una tarea, por ejemplo: pen-
diente, en curso y terminado. En estas zonas se colocan tarjetas que representan cada
una de las tareas a realizar en el sprint. Estas tarjetas pueden ser marcadas con colo-
res, pinches o de otra manera, para que el equipo de trabajo comprenda su contexto,
agruparlas o bien simplemente identificarlas.
La metodologı́a Scrum tiene como elemento fundamental la Iteración, que es la base

sobre la cual se itera para obtener un producto de software. Cada iteración debe cumplir
con tener las siguientes etapas:
Planificación de la iteración: En esta etapa se lleva a cabo la planificación póquer

y se define la pila de la iteración. Usualmente tarda desde un par de horas hasta una
jornada laboral.
Ejecución de la iteración: Es el desarrollo e implementación de las tareas definidas

para la iteración. Usualmente utiliza la mayor parte del iteración.
Reuniones diarias: Estas reuniones tienen como objetivo evaluar el estado del
sprint en asuntos de coordinación y dificultades presentadas en el dı́a. Se estable-
cen medidas operativas para lidiar con las dificultades emergentes en el sprint.
Revisión de la iteración: Se realiza una revisión sobre el estado actual de la ite-

ración. Se hace en cada reunión diaria a modo de sintetizar los estados de avance
y término de las tareas, mediante el reordenamiento de las tarjetas de tareas en el
tablero kanban.
Retrospectiva de la iteración: Es la reunión final de cada Sprint. En esta se hace

un análisis retrospectivo y crı́tico respecto al desarrollo de la iteración y se hacen
los compromisos necesarios para orientar la siguiente iteración.
4.3 ESTADO DEL ARTE

En la actualidad la realización de encuestas dentro de una organización es una necesidad
para tener un manejo apropiado de esta. A pesar de la gran cantidad de alternativas para
la creación de formularios de encuesta, la mayorı́a aún se realiza de manera presencial, lo
que implica inconvenientes con el manejo de la información, esto lleva a pensar que las
actuales herramientas no son lo suficientemente especı́ficas para las organizaciones. Otro
de los inconvenientes para una organización son la fiabilidad y seguridad de la informa-
ción, lo cual no puede asegurarse completamente si esta se encuentra manejada por un
sistema externo. Dentro de las opciones disponibles para realizar encuestas, las de mayor
renombre son:
Formularios de Google Formularios de Google es la herramienta actual más po-

pular para la creación de encuestas, utilizada por los clientes que poseen cuentas de
Google. Actualmente existe la posibilidad de elegir entre nueve diferentes tipos de
preguntas, incluidas las de texto y selección múltiple. Es posible compartir el enla-
ce del formulario en cualquier lugar de la web o enviar una invitación por correo
electrónico directamente desde Formularios de Google, pero no incluye la posibi-
lidad de realizar un seguimiento de quienes responden ni incluir datos adicionales.
Los datos de las encuestas pueden ser visualizados de forma gráfica sin posibilidad
de filtrar los datos, pero pueden ser exportados a una hoja de cálculo de Google.
Formularios de Google es una herramienta gratuita.[Goo]
Online encuestas Online encuestas es una opción gratuita y sin restricciones para
registrarse en el sitio. Se puede crear la encuesta en lı́nea directamente después
de su registro gratuito. Se puede escoger entre una variedad de tipos de preguntas
diferentes, redactar preguntas propias, añadir texto explicativo y añadir imágenes.
Siempre es posible ver una vista previa exacta de las preguntas individuales al igual
que el cuestionario completo. Además, puede modificar el tema de su cuestionario
usando propios colores y logotipos.[enc]
Survey Monkey Survey Monkey se autodenomina la mejor plataforma de encuestas

del mercado, contiene una modalidad gratuita y una suscripción de pago. Dentro de
Survey Monkey se puede elegir entre quince tipos de preguntas, dentro de las cuales
se encuentran las preguntas de opción múltiple, cuadro de texto y comparaciones.
La modalidad gratuita contiene un tope de preguntas y respuestas, mientras que la
modalidad de pago no. En caso de algún problema se ofrece asistencia vı́a correo
electrónico (la modalidad de pago incluye atención telefónica).[Monb]
Ferendum Esta plataforma sirve para crear una votación o encuesta para que luego
sea respondida por medio de un enlace o por medio de la página principal. Cual-
quier persona puede responder, ya que son creadas con privacidad pública. Es una
plataforma gratuita, sin necesidad de registrarse, especializada en prestar servicios
por medio de redes sociales como Twitter oFacebook. Ferendum enfatiza en que
ofrecen un servicio sencillo, seguro y confiable, el cual se ofrece diferentes idiomas
(incluyendo inglés y español). El sito web de Ferendum posee una sección de pre-
guntas frecuentes (FAQ), las cuales ayudan a los usuarios más inexpertos a utilizar
la plataforma.[Fer]
Estas cuatro herramientas son similares en cumplir su rol de creación de encuestas vı́a
web, en comparación con nuestro producto, lo que no incluyen es la capacidad de realizar
votaciones (esto se refiere al hecho o acto de brindarle apoyo a algo o alguien en particular)
se forma segura, confiable y anónima (según corresponda), a su vez el producto de forma
inicial es creado para una muestra especifica de personas (relacionados con la Universidad
de Santiago de Chile), lo cual facilita el almacenamiento de datos y los ingresos debido a
que se maneja previamente la población.
En el siguiente diagrama muestra de forma estandarizada como es el flujo de los datos

y los diferentes procesos que tienen los servicios ya mencionados.
Figura 4-1: Diagrama de flujo de datos

4.4 EVALUACIÓN DE EMPRESA

Como departamento de Análisis de la empresa, se debe identificar los componentes más
importantes del trabajo realizado, entre ellos la viabilidad, además de todos los riesgos
asociados que pueden determinar el éxito o fracaso del proyecto. A continuación se desta-
can los dos puntos anteriormente mencionados en un análisis cuantioso que permite tener
un mejor panorama del escenario al que se enfrenta.
4.4.1 Viabilidad del Proyecto
La viabilidad del proyecto está determinada por múltiples factores, entre ellos se encuen-
tran los requisitos que solicita el cliente, las tecnologı́as a implementar, además de un
análisis comercial y económico. Dado estos antecedentes debe realizarse un estudio que
permita encontrar un balance de utilidad, y ası́ ver dentro de todos los parámetros posibles
si la idea es viable o no. Por ejemplo, y a modo de analogı́a en comparación con el estado
de arte, las aplicaciones y plataformas existentes de encuestas y votación cumplen con
muchos de los criterios solicitados por el cliente, pero el hecho que la información sea de
primera fuente, tener control sobre los encuestados y el estado de las encuestas hace que
sea un proyecto atractivo.
4.4.2 Riesgos del Proyecto
Entiéndase como riesgo del proyecto todos aquellos elementos o acciones que pueden
perjudicar la elaboración del producto, o producir un contratiempo entre los periodos esta-
blecidos. Dentro de los posibles riesgos se puede destacar los riesgos de tipo económico,
fortuitos o de entidades externas. Los riesgos económicos dentro de este tipo de riesgos se
encuentran todos aquellos relacionados directamente a las economı́as que rodean al pro-
yecto, ya que juegan un papel preponderante en su estructuración y ejecución, ası́ como
en el éxito o fracaso que éste pueda tener. Todo proyecto pretende responder de manera
eficiente a las necesidades de un determinado grupo social y como tal, su fracaso afectarı́a
de manera directa no solo a quienes va dirigido, sino también a aquellos agentes que se
hayan involucrado en el proyecto. En ese sentido, diferentes factores económicos, ya sean
internos o externos, pueden afectar el desarrollo normal del proyecto y su posterior explo-
tación, por lo que los riesgos económicos son consecuencia de las decisiones de inversión
en el proyecto.
Inflación: En perı́odos de inflación el dinero pierde su valor, provocando que la

situación financiera de la organización se vea afectada por causa del aumento cons-
tante de los precios de la mayor parte de los productos y servicios. Si posee pocos
recursos propios, su continuidad serı́a difı́cil, además al aumentar el costo de las ma-
terias primas, se eleva el valor de los inventarios, por lo tanto el proyecto requiere
de una mayor financiación. En estos casos es conveniente para la organización au-
mentar el plazo de pago a proveedores y reducir los plazos de cobro, pues conforme
sean más bajas las cuentas por cobrar menor será la pérdida monetaria.
Malgasto de recursos: A pesar de adquirir los recursos necesarios para la realiza-

ción del proyecto, una mala distribución de estos podrı́a provocar una escasez en
ciertas áreas del desarrollo del proyecto, imposibilitando la continuidad del desarro-
llo de este. Se deben tener claros los requerimientos del producto que a desarrollar
para no provocar gastos innecesarios, ya que mientras más caracterı́sticas se cam-
bian en el transcurso del proyecto, mayor es la cantidad de dinero gastado. Para
evitar estos problemas es importante una buena etapa de análisis del proyecto.
Escasez de Herramientas para el desarrollo del proyecto: El proyecto puede no

contar con las herramientas necesarias para la realización de éste, por lo que es
necesario invertir en esta área. Para no incurrir en gastos se deben buscar software y
hardware que cumplan las mismas funciones pero que tengan un carácter gratuito,
para ası́ invertir una cantidad menor que la prevista.
Pocas ganancias: Las ganancias obtenidas no igualan o superan los costos totales
calculados, es decir, el proyecto incurre en más gastos de los que se puedan manejar,
por lo que no se podrı́a considerar como proyecto exitoso. En este caso, se debe
replantear el presupuesto y hacer correcciones para generar mayores ganancias.
En las siguientes tablas se encuentran los riesgos de mayor importancia detectados con
su descripción correspondiente.
Tabla 4.1: Descripción riesgos Marketing

Tabla 4.2: Descripción de riesgos recursos humanos

Tabla 4.3: Descripción riesgos QA

Tabla 4.4: Descripción riesgos IT
En las siguientes tablas se analiza la probabilidad de ocurrencia y el nivel de impacto

en el desarrollo del proyecto.
Tabla 4.5: Análisis riesgos - Parte 1

Tabla 4.6: Análisis riesgos - Parte 2

También se plantea una estrategia para enfrentar estos riesgos como se aprecia en la
siguiente tabla.
Tabla 4.7: Tabla de riesgos y estrategias

4.5 OFERTA Y DEMANDA
4.5.1 Oferta
La oferta en el mercado corresponde a todos los sistemas de encuesta y votación en
lı́nea, es decir la competencia directa que tiene nuestro proyecto. Dentro de los principales
competidores se encuentran:
Formularios de Google
Monkey Survey
Ferendum
Strawpoll
Nicequest
Encuestas de Facebook
Estos sistemas están disponibles en internet y permiten crear y responder encuestas.

Dentro de los más populares se encuentran Formularios de Google y Encuestas de Face-
book. Formularios de Google permite la creación de encuestas de forma rápida y fácil,
solo es necesario poseer una cuenta Google. El creador puede dejar la encuesta habilita-
da de tal forma que cualquiera pueda responder, o bien limitar el acceso a un grupo de
usuarios (por ejemplo, usuarios que tengan el mismo correo institucional que el creador).
Nicequest tiene la particularidad que todos los que respondan sus encuestas pueden ga-
nar premios por participar, siendo un sistema más enfocado a grandes corporaciones que
premian la participación para ası́ obtener una mayor cantidad de resultados. Las encuestas
de Facebook son utilizadas en la red social en grupos y páginas, pero no es un sistema de
votación confidencial ya que cualquiera puede ver los resultados y no es posible asegu-
rar que todos los miembros en un mismo grupo hayan contestado la encuesta. Otras redes
sociales, como Twitter, ofrecen el mismo sistema de votación y tienen el mismo problema.
4.5.2 Demanda
Los sistemas de votación en lı́nea cada vez tienen más usuarios y se han hecho populares
recientemente gracias a su existencia en redes sociales y a lo fácil que es crear y difundir
encuestas mediante formularios de Google, ası́ como algunos sistemas que ofrecen recom-
pensas por contestar encuestas atraen a un gran número de usuarios. Lamentablemente,
estos sistemas no son confiables para la toma de decisiones dentro de una organización
ya que depender de un sistema de terceros no permite tener un control sobre la informa-
ción. El uso de un sistema de votación y encuesta privado permite tener control sobre la
información y asegurarse que los todos los miembros de una organización contesten la
encuesta.
4.6 ESTUDIO DE MERCADO

El estudio de mercado realizado se enfoca principalmente en personas que han utilizado
por lo menos una vez un sistema de votación o encuesta en lı́nea. Se evalúan aspectos
como la usabilidad y seguridad del sistema, ası́ como la confianza que los usuarios tienen
respecto a este tipo de sistemas. Es por esto que se ha realizado una encuesta en la cual
han participado un total de 266 personas.
Figura 4-2: Respuestas de la pregunta 1



Tabla 4.8: Resumen respuestas de la pregunta 7
4.6.1 Tabulación de los resultados
Una vez obtenidos los resultados de la encuesta, se procede a tabularlos con el fin de
observar mejor las respuestas.
Tabla 4.9: Tabulación de las respuestas
Se puede observar que Formularios de Google es la opción más popular. Una de las
respuestas que más destaca es que la gente cree que las votaciones en lı́nea pueden ser ma-
nipuladas y también la preocupación que existe respecto a estos sistemas. Destaca también
la falta de confianza en ellos, pero que aun ası́, más de la mitad de los encuestados prefiere
un sistema de votación WEB. Esto indica que para el proyecto es importante la seguridad
de la información y elaborar un sistema confiable para los usuarios, ya que existe interés
y entusiasmo por los sistemas de votación en lı́nea.
4.7 COSTOS
Se procede a realizar una estimación de los costos asociados al desarrollo del proyecto
considerando un adicional de un 15 % en caso de imprevistos [Cec].
Tabla 4.10: Costos Estimados Proyecto

CAPÍTULO 5. TECNOLOGÍAS PARA DAR SOLUCIÓN AL
PROBLEMA
5.1 FRAMEWORK
Un framework o entorno de trabajo, en el ámbito de desarrollo de software, es una es-
tructura o un esquema para el desarrollo y para la implementación de una aplicación que
puede incluir soporte de programas, bibliotecas y múltiples herramientas. Los entornos
de trabajo hacen que el desarrollo del software sea mucho más simple en comparación al
desarrollo framework.
Figura 5-1: Frameworks mas usados 2017
Como se puede observar en la figura sobre los entornos de trabajos orientados al desa-
rrollo de aplicaciones web basados en PHP más utilizados, el primer lugar lo ocupa Lara-
vel, siendo una gran preferencia por los desarrolladores y equipos de trabajo. Laravel es
seguido por CodeIgniter y Symfony.
38 CAPÍTULO 5: TECNOLOGÍAS PARA DAR SOLUCIÓN AL PROBLEMA
5.1.1 Laravel
Laravel es un framework de código abierto para el desarrollo de aplicaciones web en PHP,
creado en 2011 por Taylor Otwell, inspirándose en Ruby on Rails y Symfony, de los cuales
ha adoptado sus principales ventajas.
Laravel se ha encargado de facilitar el desarrollo de tareas comunes en el proceso
de desarrollo de paginas web, tales como la autenticación de usuario, el enrutamiento de
páginas y la gestión de sesiones de usuario. Algunas de las caracterı́sticas y ventajas de
Laravel son[Pal]:
Permite un desarrollo de aplicaciones de forma rápida y cuenta con un alto nivel de

abstracción.
Permite la gestión de bases de datos y la manipulación de tablas desde el código,

manteniendo un control de versiones mediante el sistema de migraciones incorpo-
rado.
Cuenta con amplia documentación, en caso de dudas y consultas que pudieran surgir
al momento de desarrollar.
Uso de sistema de plantillas llamado Blade, lo que hace uso de la cache para darle
mayor velocidad, además, Blade facilita la creación de vistas mediante el uso de
layouts, herencia y secciones.
Incorpora un comando llamado Artisan que ayuda a implementar tareas comunes en

sistemas web, como lo son la creación automática de ciertos componentes de código
(controladores y modelos), trabajos con la base de datos, migraciones, y gestión de
rutas.
Fácil actualización de framework gracias al comando Composer.
Como es el framework de PHP más usado, cuenta con una comunidad muy activa.
CAPÍTULO 5: TECNOLOGÍAS PARA DAR SOLUCIÓN AL PROBLEMA 39
5.1.1.2 Migraciones
Son un sistema de control de versiones para bases de datos, que permiten realizar mo-
dificaciones en ellas manteniendo un registro de los cambios realizados y su estado actual
[Otw].
La forma en que las migraciones funcionan es mediante la creación de un archivo con códi-
go en PHP que describe el nombre y atributos de la tabla a crear y posteriormente, en caso
de querer modificar dicha tabla, agregar una nueva migración (un nuevo archivo PHP) con
las modificaciones deseadas. Artisan incluye comandos para la creación de migraciones,
ejecución de estas o para hacer volver a un estado anterior de la base de datos.
5.1.1.3 Blade
Es un motor de plantillas que permite la creación de páginas web dinámicas y las
conecta con su respectivo controlador, los cuales permiten realizar operaciones con los
datos ingresados por el usuario y entregar la información solicitada. Permite incorporar
elementos dinámicos, plantillas base y manipulación de variables en la misma página, lo
cual facilita la visualización de múltiples datos[Sán17].
5.1.2 CodeIgniter
CodeIgniter es el segundo framework de PHP más usado hoy en dı́a y al igual que cual-
quier otro framework, contiene una serie de librerı́as que ayudan al desarrollo de aplica-
ciones web, también proveen una manera de desarrollo que debemos seguir para sacar
provecho del framework. CodeIgniter implementa la arquitectura MVC (Modelo, Vis-
ta, Controlador), la cual es muy utilizada en la programación de aplicaciones de todo
tipo[Alv09].
Diseñado para proporcionar un uso simple desde la primera vez que se comienza a usar-
lo y de contar con un fácil método de instalación en cualquier servidor, nos ofrece las
siguientes caracterı́sticas[Fon12]:
Define una arquitectura de desarrollo que hará que la programación sea más ordena-
da y que contiene diversas herramientas que ayudan con la versatilidad y seguridad
de las aplicaciones.
La instalación en servidores no es compleja, Lo único que se necesita es una cuenta

FTP (Protocolo de transferencia de Archivos) para subir CodeIgniter al servidor, y
su configuración se realiza solo con la edición de un archivo.
Menos rı́gido que otros framework, CodeIgniter establece una manera de trabajar al
programador, pero en muchos casos no es necesario seguirla. Lo mismo ocurre con
sus reglas de codificación, que muchas veces se pueden saltar para trabajar más a
gusto.
Cuenta con documentación escrita a modo de tutorial, por lo que resulta fácil de
seguir al iniciarse en CodeIgniter.
Facilidad para creación de nuevos módulos, páginas y funcionalidades.
Como podemos ver es un framework orientado a rendimiento y compatibilidad, ayuda con

el orden del código dándole al programador control total de la aplicación, sin embargo no
todo son ventajas. Algunas de sus desventajas son: [Fon12]:
No trabaja con módulos, por lo que separar la aplicación en estos requiere comple-
mentos adicionales, modificación de la estructura básica, o en su defecto, ser muy
ordenados con el código.
Debido a que pretende ser el núcleo de nuestra aplicación, es decir el back-end,

no viene integrado con algún framework de Java Script que permita desarrollar el
Front-end.
En caso de vulnerabilidad del framework se debe descargar la nueva versión y hacer

todo un proceso para que este quede bien configurado, a diferencia de Laravel que
mediante comandos por consola puede ser actualizado.
No provee un ORM (Mapeo Objeto-Relacional), por lo que las operaciones con la

base de datos se realizan mediante consultas SQL (lenguaje de consultas estructura-
da).
5.1.3 Symfony
Symfony es un framework diseñado para optimizar el desarrollo de las aplicaciones web,
basado en el patrón de arquitectura MVC. Proporciona múltiples herramientas y clases
dedicadas a reducir considerablemente el tiempo de desarrollo de una aplicación web
compleja y además, automatiza tareas más comunes, permitiendo mayor dedicación en
asuntos especı́ficos de cada aplicación[Fab]. Ha sido probado en numerosos proyectos
reales y actualmente es utilizado en sitios web de comercio electrónico de primer nivel.
Este framework es compatible con la mayorı́a de los gestores de bases de datos, como
MySQL, PostgreSQL, Oracle y SQL Server. Algunas de sus caracterı́sticas son[Fer16]:
Fácil de instalar y configurar en la mayorı́a de las plataformas, con garantı́a de que

funciona correctamente en sistema operativo Window y Unix.
Es independiente del gestor de Bases de datos.
Automatización de la mayorı́a de los elementos comunes en el desarrollo de siste-

mas web, tal como los formularios que incluyen validación automatizada y relleno
automático de datos, asegurando obtención de datos y mejorando la experiencia del
usuario.
La gestión de la caché reduce el ancho de banda utilizado.
Un código fácil de leer que incluye comentarios de phpDocumentor, permitiendo un

mantenimiento sencillo.
Algunas de sus desventajas son:
Diseñado para desarrollo de páginas web complejas orientadas a la lógica de nego-

cios, área en la cual el framework puede sacar su esplendor.
Curva de aprendizaje empinada.

5.2 CUADRO COMPARATIVO
Tabla 5.1: Comparación Frameworks Laravel, CodeIgniter y Symfony
5.3 FRAMEWORK FRONT-END

Los framework Front-end están orientados a proveer de un conjunto de elementos como
plantillas y componentes predefinidos, con el objetivo de facilitar y agilizar el proceso de
desarrollo web, permitiendo que el desarrollador se enfoque mas en la parte lógica de su
página web [Ger17].
5.3.1 Bootstrap
Este framework Front-end de código abierto fue creado por Twitter y está basado prin-
cipalmente en HTML, CSS y Java Script. Actualmente es de los más populares, esto se
debe a que está enfocado en el desarrollo de aplicaciones web cuyo contenido se adapta al
tamaño de la ventana, lo que permite una visualización correcta del sitio web en dispositi-
vos móviles y equipos de escritorio. Algunas de las principales ventajas de este framework
son[Jos15]:
Diseño adaptativo al tamaño de la ventana del dispositivo en el que se encuentre.
Cuenta con plantillas predefinidas, las cuales tiene un diseño elegante orientado a
entregar una buena usabilidad y pueden ser modificados por el diseñador.
Cuenta con una gran cantidad de componentes con diferentes funcionalidades y va-
riedad de diseño.
Cuenta con un sistema de bloques para el contenido de la página, el cual define una
estructura de maquetado en columnas, que esta orientado al diseño adaptativo.
Tiene amplia compatibilidad con los navegadores más usados actualmente.
Sin embargo debido a la gran cantidad de elementos que contiene, este también cuenta con
algunas desventajas:
Puede ser de difı́cil adaptación y aprendizaje en un principio, ya que cuenta con una
gran cantidad de elementos.
Puede resultar más pesado que otros framework debido a la gran cantidad de ele-
mentos que contiene, en relación a otras tecnologı́as más ligeras.
5.3.2 Foundation
Al igual que el framework anterior, Foundation tiene caracterı́sticas de diseño adaptativo
a la pantalla del dispositivo, basada principalmente en HTML, CSS con acceso a dife-
rentes componentes en textitJava Script. Este framework es creado por la compañı́a Zurb
y también es bastante popular, siendo la mayor competencia de Bootstrap. Por otro lado
este framework también es de código abierto, teniendo una gran cantidad de seguidores en
GitHub. Algunas de las principales ventajas de este framework son[Gar14]:
Al igual que Bootstrap, está orientado al diseño adaptativo a la pantalla del disposi-
tivo.
Está orientado para trabajar con la filosofı́a mobile first, que plantea que el di-
seño inicial de la plataforma web se piensa desde un comienzo para dispositivos
pequeños. Ası́ se prioriza que el diseño tenga los elementos justos y necesarios.
Cuenta con un control modular de componentes Java Script, esto con el objetivo de
controlar el tamaño de la página web y solo usar los elementos necesarios.
Al igual que el framework anterior, Foundation cuenta con una estructura de bloques
orientada al maquetado de la página web.
Cuenta con la caracterı́stica Interchanger, la cual permite seleccionar contenido que

solo se carguen en dispositivos especı́ficos.
Cuenta con buena documentación y una gran comunidad.
Este framework se caracteriza principalmente por ser eficiente, debido a que es po-
sible elegir los elementos con que se desea trabajar, teniendo un entorno de trabajo
más liviano.
Cuenta con plantillas predefinidas y es compatible con la mayorı́a de navegadores

usados actualmente.
Como se puede ver este framework tiene caracterı́sticas similares a las de Bootstrap,
sin embargo también cuenta con sus propias desventajas, las cuales se muestran a conti-
nuación [CSS]:
Tiene una reducida selección de plantillas en comparación a Bootstrap.
Para manejar de manera adecuada este framework se requiere de mayor conocimien-

to y experiencia, lo cual involucra mayor tiempo de aprendizaje.
Se orienta más al desarrollo de páginas simples destinadas a cargas rápidas, pero

para el caso de necesidades más complejas se requiere un mayor conocimiento de
los elementos que componen a esta framework.
5.3.3 Pure CSS

Corresponde a un framework Front-end de código abierto, creado por Yahoo, el cual a di-
ferencia de los mencionados anteriormente se caracteriza por ser muy pequeño y sencillo,
de tal forma que no es tan popular como Bootstrap o Foundation. Se usa principalmente
en proyectos pequeños. A continuación se enumeran las ventajas de usar este framework:
Es bastante sencillo y simple de usar, pues solo contiene los elementos básicos para
desarrollar una plataforma.
Permite que las páginas adapten su diseño de acuerdo al tamaño de la pantalla, lo

que permite una correcta visualización en múltiples dispositivos.
Producto de su sencillez los proyectos se desarrollan más rápidos, además a causa

de esto las plataformas diseñadas poseen un buen rendimiento.
Los proyectos diseñados con este framework son fáciles de mantener y extender.
Por otro lado también posee algunas desventajas caracterı́sticas, lo que viene asociado
con su simplicidad, a continuación se enumeran los siguientes:
No posee elementos Java Script, por lo que la forma que las plataformas diseñadas
son poco dinámicas visualmente.
Posee pocas herramientas gráficas respecto a los otros framework, de tal forma que
no es eficiente para proyectos grandes.
5.4 SISTEMA DE GESTIÓN DE BASES DE DATOS
5.4.1 PostgreSQL
PostgreSQL es un sistema de gestión de base de datos relacional orientada a objetos libre
y de código abierto, desarrollado por un grupo liderado por Michael Stonebraker, quien
ayudó a la creación de Ingres Database, del que intentarı́a solucionar las fallas que este
poseı́a en su sucesor. [Pos]. Enfocado en la expansibilidad y en la estandarización, como
base de datos es capaz de almacenar y entregar información a diversas aplicaciones que
realicen peticiones de forma segura, sin importar el tamaño de la aplicación (desde una
aplicación de un solo computador hasta grandes aplicaciones utilizando usuarios concu-
rrentes). Al ser un sistema de gestión de base de datos relacional orientado a objetos, la
forma de almacenamiento de información es similar a la forma convencional, que es la
relacional, pero con una gran diferencia ya que además trabaja bajo el concepto de obje-
tos (forma de representar la información de la misma), unido con el concepto de base de
datos relacional, en donde básicamente la información se guarda en una o más tablas de
filas y columnas en donde cada fila posee una llave que sirve como identificador[dat]. Las
caracterı́sticas más importantes de PostgreSQL son:
Posee un sistema de control de concurrencia mediante versiones múltiples, lo cual

permite realizar cambios a la base de datos en forma concurrente sin generar una
inconsistencia en la información almacenada.
Funciona en sistemas operativos basados en UNIX y Windows.
Posee diversas interfaces de programación nativas para C/C++, Java, .Net, Perl, Pyt-
hon, Ruby, Tcl, ODBC junto a una documentación muy completa.
Es capaz de replicarse, permitiendo realizar consultas de forma eficiente dividiendo

el tráfico a estos nodos replicados.
Indexado de árbol de búsqueda generalizada, sistema avanzado que provee una gran
cantidad de algoritmos de ordenamiento y búsqueda. Además, permite la creación
de tipos de información personalizada junto a diversos métodos de consultas.
Las tablas pueden heredar sus caracterı́sticas de una tabla padre, lo que le da una
forma de crear bases de datos a partir de Modelos de Entidad Relación.
Implementa Triggers, disparadores automáticos que se activan al momento de de-

tectar un evento especı́fico.
Las ventajas que se han encontrado son:
Cumple con el criterio ACID, es decir cumple al 100 % los conceptos de Atomici-
dad (una operación realiza todas las instrucciones o ninguna), Consistencia (ejecuta
todas las instrucciones que no generen problemas en la base de datos), Aislamiento
(una operación no puede afectar a otra) y Durabilidad (el resultado de una operación
es preservado de forma permanente).
Es un software de código abierto y libre.
La velocidad de respuesta de las consultas a la base de datos es constante, no influye

el tamaño de esta misma.
Por otra parte, las desventajas encontradas son:
Consume una gran cantidad de recursos.
La sintaxis utilizada no es intuitiva.
5.4.2 MySQL
MySQL es un sistema de gestión de base de datos relacional de código abierto con ver-
siones gratuitas y de pago, desarrollado por la compañı́a sueca MySQL AB en 1994 consi-
derando como base el sistema de gestión de base de datos SQL. En 2008 la empresa Sun
Microsystems compra MySQL, para que en 2010 esta fuese adquirida por su actual dueño,
Oracle Corporation, quien le integró nuevas tecnologı́as como lo fue InnoDB[MySa]. Co-
mo indica Oracle Corporation, MySQL es una de las bases de datos más populares del
mundo para aplicaciones basadas en la web, de fácil uso, lo que permite crear bases de
datos sin muchas complicaciones y de alto rendimiento, lo que permite su uso en aplica-
ciones de gran tamaño. Su funcionamiento se basa en un modelo relacional, en donde toda
la información es almacenada en forma de tuplas agrupadas en una relación. La forma
más fácil de visualizar este concepto es con tablas, en donde una relación es una tabla
compuesta por filas (tuplas) y columnas (elementos de la tupla). De esta forma, se pueden
almacenar toda la información contenga las mismas caracterı́sticas en una sola tabla, para
después consultar por esta a través de una llave, que es el parámetro que identifica a cada
fila de las demás[MySb].
Algunas caracterı́sticas de este sistema de gestión de bases de datos son:
Ofrece soporte para varios sistemas operativos.
Posee las caracterı́sticas de replicación, triggers y llaves foráneas.
Cumple con el criterio ACID
Existen una gran cantidad de aplicaciones con interfaz gráfica de usuario que inte-
gran MySQL y permiten al usuario trabajar con la base de datos de forma visual.
Algunas de las ventajas que encontraremos al trabajar con MySQL son:
Utiliza pocos recursos para funcionar, lo que permite su funcionamiento en una

variada cantidad de ordenadores.
Por ser tan popular, existe una gran cantidad de documentación y tutoriales sobre
MySQL.
Tiene una gran capacidad de personalización ya que su licencia de código abierto

permite a los programadores modificar el software MySQL para adaptarse a entornos
especı́ficos.
Por su contraparte, algunas de sus desventajas son:

Al tener versiones gratuitas y de pago, los desarrolladores le dan prioridad a la de

pago en caso de que existan errores, provocando que los errores se mantengan por
un tiempo en las versiones gratuitas.
Si no se utiliza InnoDB como mecanismo de almacenamiento, se pueden producir

errores al momento de procesar la base de datos.
5.4.3 MongoDB
MongoDB es un sistema de gestión de base de datos no relacional bajo el concepto de
código abierto y gratis. La compañı́a 10gen inicia su desarrollo en 2007 como una plata-
forma de servicio, pero luego en 2009 esta fue modificada a su forma actual de modelo
de desarrollo, ofreciendo soporte comercial a sus usuarios. Finalmente, en 2013, la com-
pañı́a 10gen cambió su nombre por MongoDB Inc[Mona]. Centrándose en la escalabilidad
y flexibilidad, MongoDB ofrece un estilo de almacenamiento de información distinto a la
forma convencional que utilizan las base de datos relacionales. MongoDB es una base de
datos orientada a documentos, lo que significa que la forma de almacenar la información
es a través de archivos de texto. Este concepto puede parecer similar a un diseño orientado
a objetos, ya que ambos almacenan la información en algo, sin embargo la información
almacenada en un documento puede tener un formato distinto a otro aunque pertenezcan
al mismo tipo, situación no permitida en los objetos. Las principales caracterı́sticas que
nos ofrece MongoDB son:
Permite la técnica de replicación, permitiendo la realización de consultas y modifi-

caciones a la base de datos de forma rápida, puesto que si falla la réplica principal,
actúa una de las réplicas secundarias reemplazando la primaria.
Utiliza la fragmentación para distribuir la información de la base de datos, permi-

tiendo de esta forma un menor tiempo de carga al momento de realizar una acción.
Soporta la búsqueda por campos, consultas de rangos y expresiones regulares. Las

consultas pueden devolver un campo especı́fico del documento, pero también puede
ser una función Java Script definida por el usuario.
Soporta un gran número de lenguajes de programación.
Se encuentra disponible para los sistemas operativos Windows, Linux, MacOS y

Solaris.
Las ventajas de MongoDB son[MC]:
Una alta velocidad de acceso y modificación de la base de datos, logrando que sea
extremadamente útil en aplicaciones donde el usuario realiza muchas operaciones
con la base de datos.
No importa el tamaño de la base de datos a utilizar gracias a las técnicas de frag-

mentación y replicación que posee.
Las estructuras de la base de datos no poseen un esquema definido, por lo que per-
mite una mayor libertad al programador al momento de crearlas y utilizarlas.
Por otra parte sus desventajas son:
Posee un sistema de seguridad normal, lo que permite que cualquier usuario tenga
acceso completo a la base de datos
Al no tener una estructura definida por ser una base de datos no relacional, no exis-
te un estándar de formato para la información, provocando que cada programador
diseñe la base de datos como el quiera, dificultando ası́ el uso de esta misma por
personas externas.
No cumple completamente con el criterio ACID, por lo que pueden existir errores
en el uso de estas bases.
Tabla 5.2: Tabla Comparativa entre PostgreSQL, MySQL y MongoDB
5.5 ELECCIÓN DE TECNOLOGÍAS

Luego de investigar sobre las diferentes herramientas tecnológicas orientadas al desarro-
llo web y base de datos, y analizar sus caracterı́sticas, se concluye que las tecnologı́as
adecuadas para este proyecto son las siguientes:
Back-end: Se ha decidido el uso de Laravel como base para el proyecto, ya que el

equipo de desarrollo posee experiencia previa con este framework, lo que en conjun-
to con la extensa comunidad que posee debido a su popularidad, facilita el desarrollo
de software. Fuera de lo antes mencionado, Laravel es muy completo, con variadas
herramientas para el desarrollo, tal como el motor de plantillas Blade, lo que permite
tener las vistas de la página web bien estructuradas y ordenadas, pudiendo extender
unas vistas de otras. Las migraciones permiten mantener un control sobre los esta-
dos anteriores de la base de datos y también implementar futuras modificaciones en
su estructura.
Front-end: El framework escogido es Bootstrap, debido a que a diferencia de los

otros dos, Bootstrap tiene una gran variedad de plantillas de diseños y componentes,
los cuales entregan los recursos necesarios para crear una plataforma que se ajuste
a los requerimientos del problema. Por otro lado, gracias a la gran comunidad que
hay y a su popularidad, es fácil encontrar diferentes recursos de aprendizaje para la

gran variedad de componentes disponibles.
Gestión de base de datos: Se ha escogido PostgreSQL como gestor de base de datos,

ya que es posible utilizar la gran mayorı́a de las caracterı́sticas de una arquitectura
orientada a objetos, lo cual puede ser de utilidad para representar las diferentes en-
tidades presentes en el problema. Además nos entrega todas las propiedades de una
base de datos relacional, algo que resulta de gran utilidad para almacenar los datos
requeridos para implementar la solución. Se descarta MySQL debido a que requiere
un sistema de pago para disfrutar de todas sus caracterı́sticas, además requiere de
otras herramientas como InnoDB o NDB para evitar errores en las transacciones.
Por otra parte MongoDB no es conveniente para estos casos en las que se requieren
transacciones de forma segura.
CAPÍTULO 6. DISEÑO DEL PROYECTO
6.1 DISEÑO Y CREATIVIDAD

En esta sección contempla el diseño del proyecto en base a las investigaciones del mer-
cado y requisitos solicitados. Se proporciona un prototipo de la aplicación que soporta
los requerimientos del cliente y se proponen diferentes nombres y logos para identificar
a la empresa, los que deben tener un atractivo comercial y relación con el propósito de la
empresa.
Inicialmente, los nombres escogidos para la empresa son:
Polling Rate
SPS Standard Pool System
Rapid Poll
Poll Organization System
Sistema Encuestas Chile
Encuesta Chile
Encuestas Autoadministrables
Tu Opinión Importa
Sublime Poll
De los nombres propuestos, Rapid Poll se ha descartado porque ya existe, Encuesta

Chile es propiedad del gobierno por lo que no puede ser utilizado y Tu Opinión Importa
es un slogan registrado. Para la elección del nombre se debe considerar que el nombre sea
corto y fácil de aprender, que sea llamativo para la gente y único. Esto es con el objetivo
de que la empresa se distinga del resto. Finalmente, el nombre escogido es Sublime Poll.
El proceso de creación del logo se basa en que este debe ser identificable y representar
qué es lo que ofrece la empresa. A continuación se muestran los prototipos de los logos.
54 CAPÍTULO 6: DISEÑO DEL PROYECTO
Figura 6-1: Prototipo de logo 1
Figura 6-4: Logo escogido
Para el producto el nombre provisorio es Sublime Poll System, el cual es también el

nombre clave del proyecto. Este puede ser modificado posteriormente de acuerdo al juicio
personal del cliente.
CAPÍTULO 6: DISEÑO DEL PROYECTO 55
6.2 REQUISITOS FUNCIONALES

Lista de funcionalidades que el usuario del producto debe poder ser capaz de realizar en
el producto.
El cliente puede crear encuestas.
El cliente puede crear preguntas con distintos campos, ya sea selección única o
selección múltiple.
El cliente puede filtrar las encuestas según estándares definidos por él.
Los usuarios pueden escribir una retroalimentación después de una encuesta.
Los usuarios pueden escribir una retroalimentación directamente en el sitio.
6.3 REQUISITOS NO FUNCIONALES
Lista de capacidades que debe presentar el producto.
El sistema debe ser compatible tanto con dispositivos de escritorio y dispositivos

móviles que soporten navegadores actuales.
El sistema debe mostrar la información de las encuestas mediante diferentes tipos

de gráficos.
El sistema debe informar a los usuarios cuando tienen una encuesta disponible por
correo electrónico.
Los resultados de las encuestas no deben ser visibles para los usuarios finales.
Los resultados de las encuestas deben ser guardados permanentemente.
La interfaz de usuario debe ser en idioma español.
El sistema no soporta preguntas abiertas.

El sistema no analiza las repuestas.
El sistema esta construido en pagina web.
La base de datos esta construido en Postgres.

6.4 CASOS DE USOS
Un caso de uso es una descripción de acciones o pasos que realiza un actor en el

sistema con el objetivo de realizar un procedimiento [MT]. En los siguientes casos de uso
se definen dos actores [Gro]:
Encuestado: Usuario del sistema que tiene acceso a encuestas habilitadas para él.
Solamente puede responder encuestas y enviar comentarios o sugerencias.
Administrador: Usuario con privilegios de uso del sistema web. Puede crear encues-
tas, habilitar y deshabilitar encuestas, filtrar a los usuarios que pueden contestar la
encuesta, revisar resultados y estadı́sticas sobre la encuesta.
Tabla 6.1: Caso de uso 01





6.4.1 Prototipos de la aplicación
Los prototipos presentados corresponden a las principales vistas de la aplicación, que

muestran una idea sobre cómo será el producto final. Los prototipos han sido diseñados de
acuerdo a los requerimientos funcionales y los casos de uso.
Figura 6-5: Prototipo de aplicación - Creación de encuesta 1


Figura 6-9: Prototipo de aplicación - Responder encuesta
Figura 6-10: Prototipo de aplicación - Comentario o sugerencia
Figura 6-11: Prototipo de aplicación - Lista de encuestas creadas

Figura 6-12: Prototipo de aplicación - Lista de encuestas disponibles

CAPÍTULO 7. IMPLEMENTACIÓN
7.1 DIAGRAMAS DE SECUENCIA

Un diagrama de secuencia muestra la interacción entre los objetos de una aplicación y
cómo estos se comunican de acuerdo a la acción del actor. A continuación se presentan tres
diagramas de secuencia, donde cada uno muestra la interacción entre objetos de acuerdo a
las acciones planteadas en los casos de uso principales.
Figura 7-1: Diagrama de secuencia - Respondiendo una encuesta en lı́nea
El diagrama muestra la interacción entre el actor y el sistema de acuerdo a las acciones

descritas en el caso de uso “Respondiendo una encuesta en lı́nea”. El actor escoge que se
muestran las encuestas disponibles para él mediante el navegador web y este se encarga de
solicitarlas al controlador de la aplicación, quien obtiene la información desde la base de
datos. La información es devuelta y la aplicación crea una nueva de instancia de una vista
que muestra una lista con todas las encuestas, la cual es mostrada mediante el navegador
al usuario. El usuario selecciona una de estas y el mensaje es recibido por la aplicación,
quien solicita la información a la base de datos y es devuelta a la aplicación, la cual crea
una instancia de vista que contiene las preguntas y respuestas de la encuesta, y es mostrada
en el navegador al usuario. El usuario ingresa las respuestas en el navegador y se conecta
con la vista y la aplicación para almacenar los resultados en la base de datos. Finalmente,
68 CAPÍTULO 7: IMPLEMENTACIÓN
por el mismo camino, el usuario recibe una vista para escribir comentarios y enviar estos
al sistema.
Figura 7-2: Diagrama de secuencia - Creando una nueva encuesta
Este diagrama muestra la interacción entre el actor y los componentes del sistema de
acuerdo a las acciones descritas en el caso de uso “Creando una nueva encuesta”. El usua-
rio ingresa el nombre y descripción de la encuesta en el navegador, los cuales pasan por
la vista y son enviados al controlador de la aplicación. Como respuesta, la aplicación mo-
difica la vista para que el usuario pueda agregar preguntas con sus respectivas respuestas
y es mostrada mediante el navegador web. El usuario ingresa las preguntas y respuestas
deseadas y las envı́a de vuelta a la aplicación. Finalmente, la aplicación realiza el mismo
camino hacia el usuario para que éste especifique la fecha y hora de inicio y término de
la aplicación. Una vez realizado esto, el usuario envı́a la encuesta a la aplicación, quien la
almacena en la base de datos del sistema.
Figura 7-3: Diagrama de secuencia - Consultando resultados de una encuesta
En el caso de uso “Consultando resultados de una encuesta”, se puede ver cómo el

usuario selecciona una encuesta en el navegador web, cuya selección pasa por la vista que
CAPÍTULO 7: IMPLEMENTACIÓN 69
muestra la lista de encuestas creadas por él y la selección es enviada al controlador de la

aplicación, quien obtiene la información desde la base de datos. El controlador instancia
una nueva vista que es capaz de mostrar los resultados de la encuesta mediante el navega-
dor web, de tal manera que el usuario los pueda ver. El usuario selecciona una pregunta
especı́fica de la encuesta mediante el navegador web y la petición realiza el mismo camino
anterior hasta la base de datos, y luego de vuelta para que la vista se actualice y muestre
estadı́sticas y resultados de la pregunta especı́fica indicada por el usuario. Finalmente, el
usuario puede ver la información por medio del navegador web.
7.2 DIAGRAMA DE COMPONENTES

Un diagrama de componentes sirve para representar la forma en que distintos componen-
tes se unen para formar un componente aún más complejo o bien un sistema de software.
Los componentes son representados por un bloque y las conexiones entre ellos se realizan
mediante interfaces, representadas mediante una lı́nea con un cı́rculo al medio. Las inter-
faces indican que un componente provee los servicios que otro componente requiere[Spa].
Figura 7-4: Diagrama de componentes
En este diagrama se pueden observar tres componentes principales: PC, Servidor web
y Servidor DB. El Servidor web requiere del Servidor DB para proveer la información
solicitada por el componente PC. Dentro de este último componente tenemos al compo-
nente Navegador web , quien es el encargado de mostrar la vista de la aplicación web. El
componente Servidor web posee al componente Aplicación web (y a su vez, todos los sub
70 CAPÍTULO 7: IMPLEMENTACIÓN
componentes necesarios para su funcionamiento) y el componente Servidor DB posee al

componente de la base de datos.
7.3 MODELO ENTIDAD-RELACIÓN
Este modelo describe de forma básica como se organiza la base de datos. Cada encues-
ta pertenece a un cliente que compra el producto. Esta encuesta debe tener por lo menos
una o más preguntas y a su vez puede poseer archivos adjuntos, además de comentarios.
Estos comentarios son dejados por algún usuario del sistema, quien a su vez puede dejarlos
en alguna encuesta en que haya participado.
El modelo entidad-relación propuesto no se encuentra normalizado, debido a que es
una propuesta preliminar.
Figura 7-5: Modelo Entidad-Relación de la base de datos

CAPÍTULO 8. CONCLUSIÓN
En este documento se presenta la planeación, una etapa crucial para poner en marcha el
proyecto, ya que gracias a esta se pueden presupuestar la fecha de término del producto
ası́ como su oferta y demanda. Siguiendo esta planeación, que se puede visualizar a partir
de la carta gantt obtenida, se puede garantizar el producto final con los requerimientos que
el cliente en primera instancia desea.
La planeación parte dejando en claro el rol de cada miembro del equipo dentro del
proyecto, pero cabe destacar que debido al tiempo sumamente escaso estos roles a veces
traspasar el lı́mite de su propia actividad, realizando aporte en otros ámbitos.
Como se define el uso de la metodologı́a cascada para llevar a cabo el proyecto, se
debe ser sumamente riguroso con las fechas lı́mites, ya que al ser una metodologı́a lineal,
el atraso de una tarea puede desencadenar en el atraso del proyecto completo, razón por
la cual se definieron posibles riesgos fortuitos que pueden impedir el correcto avance del
proyecto, ası́ como también el plan a tomar en caso de que estos ocurran. En caso de que se
presente la necesidad de incluir caracterı́sticas nuevas, este documento debe ser analizado
nuevamente incluyendo dichas caracterı́sticas.
Dentro las dificultades quizás la mayor, fue definir en un comienzo el scope del pro-
yecto, lo que llevó al equipo a reunirse en varias ocasiones con el cliente hasta lograr un
consenso con este, esto se logró de manera efectiva y queda plasmado en los casos de
usos realizados y de forma interna para el equipo de trabajo en los diagramas de secuen-
cias. A pesar del tiempo gastado, la correcta definición del scope impide problemas en las
futuras etapas del proyecto y a su vez nos permitió obtener el prototipo de la aplicación
visualizado en el informe.
Finalmente a partir de esta etapa se logró obtener el aprendizaje sobre la evaluación
de un proyecto no solo del punto de vista teórico, sino más bien en un ámbito real ate-
rrizado en un problema particular, ası́ como un entendimiento sobre la importancia de la
organización dentro de un equipo.
CAPÍTULO 9. BIBLIOGRAFÍA
[Cer01] Santiago Ceria. Casos de Uso. 2001. URL: http://www-2.dc.uba.ar/
materias/isoft1/2001_2/apuntes/CasosDeUso.pdf.
[Gut06] Javier J Gutiérrez. ¿Qué es un framework web? 2006. URL : http://www.

lsi.us.es/˜javierj/investigacion_ficheros/Framework.
pdf.
[Alv09] Miguel Angel Alvarez. CodeIgniter. 2009. URL: https://desarrolloweb.

com/articulos/codeigniter.html.
[Fon12] Mario Fontán. CodeIgniter, un framework PHP para el desarrollo rápido de

aplicaciones web. 2012. URL: http://www.adwe.es/codigo/codeigniter-
framework-php-desarrollo-aplicaciones-web.
[Gar14] Alberto Garcı́a. Desarrollo de sitios web responsivos con Foundation 5. 2014.
URL : http://nosmoke.cycle-it.com/2014/05/05/desarrollo-
de-sitios-web-responsivos-con-foundation-5/.
[Jos15] Acedo Jose I. ¿Qué es el Framework Bootstrap? 2015. URL : http : / /

programacion.jias.es/2015/05/web- %5C%C2%5C%BFque-
es-el-framework-bootstrap-ventajas-desventajas/.
[Fer16] Javier Fernández. ventajas de Symfony. 2016. URL: https://www.fersacom.

es/ventajas-de-symfony/.
[ALE17] ALEGSA. Definición de aplicación web. 2017. URL: http://www.alegsa.

com.ar/Dic/aplicacion_web.php.
[Esp17a] Real Academia Española. Definición de base de datos. 2017. URL: http :
//dle.rae.es/srv/fetch?id=5ASmP2Z.
[Esp17b] Real Academia Española. Definición de hardware. 2017. URL : http : / /

dle.rae.es/?id=K1Wwkf7.
74 CAPÍTULO 9: BIBLIOGRAFÍA
[Esp17c] Real Academia Española. Definición de página web. 2017. URL : http://
dle.rae.es/?id=RRvUbbP.
[Esp17d] Real Academia Española. Definición de prototipo. 2017. URL: http : / /

dle.rae.es/?id=UTAcBkl.
[Esp17e] Real Academia Española. Definición de software. 2017. URL: http://dle.

rae.es/?id=YErlG2H.
[Ger17] Ivaylo Gerchev. The 5 Most Popular Frontend Frameworks of 2017 Compared.
2017. URL : https://www.sitepoint.com/5- most- popular-
frontend-frameworks-compared/.
[Sán17] Antonio Javier Gallego Sánchez. Laravel 5. 2017. URL: https://ajgallego.

gitbooks.io/laravel-5/content/.
[Cec] Cecowork. Arriendo Oficina de Trabajo. URL : http://www.cecowork.

com/oficinas-y-espacios-de-trabajo/.
[CSS] ZURB Foundation: el framework CSS para interfaces responsivas. 14 Junio

2017. URL: https://www.1and1.es/digitalguide/paginas-
web/desarrollo-web/zurb-foundation-compacto-framework-
ui/.
[dat] The world’s most advanced open source database. 13 septiembre, 2017. URL:
https://www.postgresql.org/about/.
[Dia] Ivan Alvaro Diaz. ¿Que es FrontEnd Y Backend en la programación web?

URL: https : / / serprogramador . es / que - es - frontend - y -
backend-en-la-programacion-web/.
[enc] Online encuestas. Online encuestas. URL: https://www.onlineencuesta.

com/.
CAPÍTULO 9: BIBLIOGRAFÍA 75
[Fab] François Zaninotto Fabien Potencier. Symfony 1.2, la guı́a definitiva. URL :
http://librosweb.es/libro/symfony_1_2/capitulo_1/
symfony_en_pocas_palabras.html.
[Fer] Ferendum. ¿Qué es Ferendum? URL: http : / / www . ferendum . com /

es/.
[gan] Carta Gantt – Asegura el éxito de tus proyectos con un diagrama de gantt.
2017. URL: https://www.cartagantt.com/.
[Goo] Google. Google Forms. URL : https://www.google.com/intl/es-

419_cl/forms/about/.
[Gro] Object Management Group. UML 2.1.2 Superstructure. URL: http://doc.

omg.org/formal/2007-11-02.pdf.
[MT] Methods y Tools. Precise UML Use Cases. URL: http://www.methodsandtools.

com/archive/archive.php?id=8.
[Mona] MongoDB. 11 septiembre, 2017. URL: https://www.mongodb.com/.
[MC] MongoDB y MySQL Compared. 13 septiembre, 2017. URL: https://www.

mongodb.com/compare/mongodb-mysql?jmp=docs.
[Monb] Survey Monkey. En qué es mejor SurveyMonkey que Google Forms. URL :
https://es.surveymonkey.com/mp/surveymonkey-better-
than-google-forms/.
[MySa] MySQL. 12 septiembre, 2017. URL: https://www.mysql.com/.
[MySb] MySQL 5.7 Reference Manual :: 1.3.2 The Main Features of MySQL. 13 sep-
tiembre, 2017. URL: https://dev.mysql.com/doc/refman/5.7/
en/features.html.
[Otw] Taylor Otwell. Documentacion Laravel 5.4, Migraciones. URL : https://

laravel.com/docs/5.4/migrations.
76 CAPÍTULO 9: BIBLIOGRAFÍA
[Pal] Duilio Palacios. Porque elegir Laravel en vez de Codeigniter. URL : https:
//styde.net/porque-elegir-laravel-en-vez-de-codeigniter/.
[Pos] PostgreSQL. 10 septiembre, 2017. URL : https://www.postgresql.

org/.
[Quo] Quora. What is an API? URL: https://www.quora.com/What-is-

an-API-4.
[Spa] Sparxsystems. Diagramas de Componentes. URL: http://www.sparxsystems.

com.ar/resources/tutorial/uml2_componentdiagram.html.

Sublime Poll Ejemplo

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Sublime Poll Ejemplo

Uploaded by

Copyright:

Available Formats

UNIVERSIDAD DE SANTIAGO DE CHILE

INFORME PROYECTO SUBLIME POLL SYSTEM

ÍNDICE DE TABLAS................................................................................................... viii

CAPÍTULO 1. INTRODUCCIÓN ........................................................................... 1

CAPÍTULO 2. DEFINICIONES Y ACRÓNIMOS ................................................ 5

CAPÍTULO 3. PLANIFICACIÓN DEL PROYECTO........................................... 7

CAPÍTULO 4. ANÁLISIS DEL PROYECTO ........................................................ 13

4.2 METODOLOGı́AS DE DESARROLLO DE SOFTWARE . . . . . . . . 14

CAPÍTULO 5. TECNOLOGı́AS PARA DAR SOLUCIÓN AL PROBLEMA .... 37

CAPÍTULO 6. DISEÑO DEL PROYECTO............................................................ 53

CAPÍTULO 8. CONCLUSIÓN ................................................................................ 71

CAPÍTULO 9. BIBLIOGRAFı́A .............................................................................. 73

Figura 3-1: Organigrama . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

Figura 6-6: Prototipo de aplicación - Creación de encuesta 2 . . . . . . . . . . 63

Tabla 4.1: Descripción riesgos Marketing . . . . . . . . . . . . . . . . . . . . 23

1.2 MISIÓN Y VISIÓN COMO EMPRESA

1.4.2 Objetivos Especı́ficos

1. Implementación de un sistema de notificación por correo a los invitados a responder,

2. Posibilidad de realización de filtros dentro de la comunidad universitaria, esto es,

1.5 ESTRUCTURA DEL INFORME

1. PHP: PHP Hypertext Preprocessor.

2. FTP: Protocolo de transferencia de Archivos.

3. MVC: Arquitectura Modelo-Vista-Controlador.

4. HTML: HyperText Markup Language.

5. CSS: Cascading Style Sheets.

6. PC: Acrónimo de Personal Computer.

7. DB: Acrónimo de DataBase que traducido al español es base de datos.

8. ACID: Atomicity, Consistency, Isolation and Durability.

9. Página web: Es un documento o información electrónica, con capacidad de conte-

11. Front-end: Programador encargado de la capa de presentación visual para el usuario

12. Back-end: Programador encargado de la programación que interactúa con la base

13. Base de datos: Conjunto de datos almacenados estructuralmente [Esp17a].

14. Hardware: Es el conjunto de elementos fı́sicos que componen una computadora

15. Framework: Es un esquema, patrón, esqueleto, para el desarrollo de software [Gut06].

16. Software: Conjunto de programas y rutinas que permiten a la computadora realizar

18. Casos de uso: Modelo de comportamiento de las funcionalidades de un software

19. Carta Gantt: Modelo de actividades en una lı́nea de tiempo [gan].

21. API: Conocido como Interfaz de Programación de Aplicaciones, es un conjunto de

Figura 3-1: Organigrama

3.1. Descripción de los equipos de trabajo

Tecnologı́as de la información: Es el área encargada de realizar la investigación

esta primera etapa los integrantes están destinados a la recopilación de información

Control de calidad (desde ahora QA): Área encargada de verificar la calidad y el

Marketing: El área de marketing es la encargada de orientar comercialmente el

Recursos Humanos: Encargados de documentar lo relativo a este proyecto, iden-

3.2 CARTA GANTT

Se presenta la Carta Gantt donde se aprecia el desglose de actividades planificadas para

Figura 3-2: Reuniones.

Figura 3-3: Estado del arte.

Figura 3-4: Costos.

Figura 3-5: Planificación 1.

Figura 3-6: Planificación 2.

Figura 3-7: Implementación 1.

Figura 3-8: Implementación 2.

Figura 3-9: Implementación 3.

4.1 METODOLOGÍA DE DESARROLLO DE PROYECTOS

Cada fase está fuertemente definida, con periodos establecidos y escalonados.

Facilita la gestión y evaluación del proyecto gracias a la organización y documentos

Por otra parte, existen las siguientes desventajas:

No es recomendable para proyectos de larga duración y complejos, propensos a

4.2 METODOLOGÍAS DE DESARROLLO DE SOFTWARE

metodologı́a se definen diversos participantes, los cuales permiten el desarrollo de esta

Facilitador (Scrum Máster): Es el encargado de dirigir el equipo de trabajo. El