Informe Final de Tesis - Luis Guillermo Ramirez Coronado

UNIVERSIDAD NACIONAL DE PIURA
FACULTAD DE INGENIERÍA INDUSTRIAL
ESCUELA PROFESIONAL DE INGENIERÍA INFORMÁTICA
TESIS
“ANÁLISIS COMPARATIVO DEL TIEMPO DE EJECUCIÓN DE UNA

APLICACIÓN WEB DESARROLLADA EN DIFERENTES MARCOS DE
TRABAJO UTILIZADOS EN EL LADO DEL CLIENTE Y EN EL LADO
DEL SERVIDOR”
PRESENTADO POR:
LUIS GUILLERMO RAMÍREZ CORONADO
ASESORADO POR:
Ing. CARMEN ZULEMA, QUITO RODRÍGUEZ
COASESORADO POR:
Dr. MOISÉS DAVID, SAAVEDRA ARANGO
PIURA, 2017
UNIVERSIDAD NACIONAL DE PIURA
FACULTAD DE INGENIERÍA INDUSTRIAL
ESCUELA PROFESIONAL DE INGENIERÍA INFORMÁTICA
TESIS
“ANÁLISIS COMPARATIVO DEL TIEMPO DE EJECUCIÓN DE UNA

APLICACIÓN WEB DESARROLLADA EN DIFERENTES MARCOS DE
TRABAJO UTILIZADOS EN EL LADO DEL CLIENTE Y EN EL LADO
DEL SERVIDOR”
-------------------------------------------------------------------
LUIS GUILLERMO RAMÍREZ CORONADO
TESISTA
-------------------------------------------------------------------
Ing. CARMEN ZULEMA, QUITO RODRÍGUEZ
ASESOR
-------------------------------------------------------------------
Dr. MOISÉS DAVID, SAAVEDRA ARANGO
CO-ASESOR
PIURA, 2017
ÍNDICE
INTRODUCCIÓN ............................................................................................................................................. 1
CAPÍTULO 1. EL PROBLEMA DE INVESTIGACIÓN ........................................................................... 3
1.1. DESCRIPCIÓN Y FORMULACIÓN DEL PROBLEMA DE INVESTIGACIÓN ..............................................3

1.1.1. Descripción de la realidad problemática ........................................................................... 3
1.1.2. Formulación del problema ......................................................................................................... 4
1.2. OBJETIVOS DE LA INVESTIGACIÓN ................................................................................................................4
1.2.1. Objetivo general .............................................................................................................................. 4
1.2.2. Objetivos específicos ................................................................................................................... 4
1.3. JUSTIFICACIÓN DE LA INVESTIGACIÓN .........................................................................................................4
1.4. HIPÓTESIS DE LA INVESTIGACIÓN .................................................................................................................5
1.4.1. Hipótesis general............................................................................................................................ 5
CAPÍTULO 2. MARCO TEÓRICO .............................................................................................................. 6
2.1. ANTECEDENTES DEL ESTUDIO ........................................................................................................................9

2.1.1. Antecedentes internacionales ................................................................................................. 9
2.1.2. Antecedentes nacionales ........................................................................................................ 13
2.2. FRAMEWORK....................................................................................................................................................... 14
2.2.1. Definición .............................................................................................................................................. 14
2.2.2. Clasificación ........................................................................................................................................ 14
2.2.3. Características de los frameworks ........................................................................................ 16
2.2.4. Ventajas de los frameworks ...................................................................................................... 17
2.2.5. Desventajas de los frameworks .............................................................................................. 18
2.2.6. Componentes de un framework .............................................................................................. 20
2.2.7. Patrones y frameworks................................................................................................................. 20
2.3. APLICACIONES WEB ........................................................................................................................................ 21
2.3.1. Concepto de aplicación Web .................................................................................................... 21
2.3.2. Características de las aplicaciones Web ........................................................................... 23
2.4. FRAMEWORK LARAVEL ................................................................................................................................... 24
2.4.1. Introducción......................................................................................................................................... 24
2.4.2. Instalación ............................................................................................................................................ 25
2.4.3. Características .................................................................................................................................. 25
2.4.4. Estructura ............................................................................................................................................. 26
2.4.5. Componentes..................................................................................................................................... 28
2.5. FRAMEWORK SYMFONY ................................................................................................................................. 30
2.5.1. Introducción......................................................................................................................................... 30
2.5.2. Instalación ............................................................................................................................................ 31
2.5.4. Estructura ............................................................................................................................................. 32
2.5.5. Componentes..................................................................................................................................... 33
2.6. FRAMEWORK ANGULARJS ............................................................................................................................ 35
2.6.1. Introducción......................................................................................................................................... 35
2.6.2. Instalación ............................................................................................................................................ 35
2.6.4. Estructura ............................................................................................................................................. 36
2.6.5. Componentes..................................................................................................................................... 38
2.7. FRAMEWORK JQUERY .................................................................................................................................... 41
2.7.1. Introducción......................................................................................................................................... 41
2.7.2. Instalación ............................................................................................................................................ 42
2.7.4. Componentes..................................................................................................................................... 42
CAPÍTULO 3. METODOLOGÍA................................................................................................................. 44
3.1. TIPO DE INVESTIGACIÓN ................................................................................................................................ 44

3.2. TIPOS Y TÉCNICAS DE MUESTREO ............................................................................................................. 44
3.2.1. Universo poblacional ..................................................................................................................... 44
3.2.2. Tamaño de muestra ....................................................................................................................... 44
3.3. TÉCNICAS E INSTRUMENTOS PARA LA RECOLECCIÓN DE DATOS.................................................. 45
3.3.1. Encuesta............................................................................................................................................... 45
3.3.2. Observación. ...................................................................................................................................... 45
3.3.3. Guía de observación. .................................................................................................................... 45
3.3.4. Software para la simulación de operaciones................................................................... 45
3.4. VALIDEZ DE LA ENCUESTA............................................................................................................................. 46
3.5. APLICACIÓN DE ENCUESTA. .......................................................................................................................... 46
3.6. PROCESAMIENTO DE ENCUESTA ................................................................................................................ 47
3.6.1. Determinación del módulo a implementar ......................................................................... 47
3.6.2. Operaciones más frecuentes .................................................................................................... 48
3.7. CRITERIO DE SELECCIÓN DE FRAMEWORKS .......................................................................................... 49
3.8. FRAMEWORKS A UTILIZAR ............................................................................................................................. 49
3.9. CRITERIOS DE COMPARACIÓN ..................................................................................................................... 52
3.10. GENERAR DATA DE PRUEBA ........................................................................................................................ 53
3.11. AMBIENTE PARA EL DESARROLLO Y SIMULACIÓN: .............................................................................. 55
CAPÍTULO 4. CASO DE ESTUDIO: SISTEMA DE TRÁMITE DOCUMENTARIO ...................... 57
4.1. TRÁMITE DOCUMENTARIO. ........................................................................................................................... 57

4.2. OBTENCIÓN DE REQUERIMIENTOS. ........................................................................................................... 59
4.2.1. Requerimientos funcionales ...................................................................................................... 59
4.2.2. Especificaciones de los requerimientos. ............................................................................ 59
4.3. DIAGRAMAS ......................................................................................................................................................... 62
4.3.1. Diagrama de Negocio. .................................................................................................................. 62
4.3.2. Diagramas de Casos de uso..................................................................................................... 63
4.3.3. Diagramas de Secuencia ............................................................................................................ 65
4.3.4. Diagramas de Colaboración .................................................................................................. 69
4.3.5. Diagrama de Clases .................................................................................................................. 73
4.3.6. Diagramas de Componentes ................................................................................................ 75
CAPÍTULO 5. PRESENTACIÓN, ANÁLISIS Y DISCUSIÓN DE RESULTADOS ........................ 77
5.1. PRESENTACIÓN DE RESULTADOS............................................................................................................... 77

5.2. ANÁLISIS DE RESULTADOS ............................................................................................................................ 80
5.3. DISCUSIÓN DE RESULTADOS ........................................................................................................................ 95
5.4. VALIDACIÓN DE HIPÓTESIS ............................................................................................................................ 96
CONCLUSIONES.......................................................................................................................................... 97
RECOMENDACIONES ................................................................................................................................ 99
BIBLIOGRAFÍA .......................................................................................................................................... 100

INTRODUCCIÓN
Cuando se trata de desarrollar aplicaciones Web en lenguaje PHP o JavaScript, la
mayoría de desarrolladores implementan sus proyectos en tecnologías o marcos
de trabajo que tienen mejor conocimiento, sin realizar una investigación previa en
búsqueda de aquellos que se ajustan a sus necesidades y a su vez ofrezca el mejor
rendimiento y escalabilidad.
Un marco de trabajo o framework es el conjunto de componentes físicos y lógicos
estructurados de tal forma que permiten ser reutilizados en el diseño y desarrollo
de nuevos sistemas de información, por lo que, nace la preocupación de la
Ingeniería de Software, una vez recopilado los requisitos del proyecto Web,
estandarizar la búsqueda del marco de trabajo que se acople a las necesidades del
sistema y que permita optimizar los recursos de Hardware y Software.
Este trabajo de investigación busca comparar los tiempos de ejecución de una
aplicación Web que ha sido desarrollada utilizando determinados marcos de trabajo
en el lado del cliente y en el lado del servidor.
Y se divide en los siguientes capítulos:
En el Capítulo 1, se presenta la problemática de la investigación, el planteamiento
del objetivo general y objetivos específicos a llevar a cabo, la justificación de la
investigación y las hipótesis planteados que deberán ser comprobadas al final de
la investigación,
En el Capítulo 2, está relacionado con el marco teórico, el cual contiene los
antecedentes que se relacionan con la presente investigación así como también los
conceptos y definiciones de frameworks, aplicaciones Web y de cada uno de los
frameworks utilizados para llevar cabo esta investigación.
En el Capítulo 3, se presenta la metodología que se empleó para realizar esta
investigación, comprende los materiales, instrumentos, frameworks a utilizar y
criterios de comparación.
En el Capítulo 4, en este capítulo se explica el caso de estudio de esta
investigación, contiene los requerimientos funcionales de la aplicación desarrollada,
el modelado UML de los requerimientos, diagramas de casos de uso, diagramas de
secuencia, diagramas de negocio, diagramas de colaboración, diagramas de clases
y componentes.
En el Capítulo 5, se muestra el análisis y discusión de los resultados obtenidos en
el desarrollo de los objetivos planteados y la validación de la hipótesis planteada
1
en la investigación.
2
Capítulo 1. El Problema de Investigación
1.1. Descripción y formulación del problema de investigación

1.1.1. Descripción de la realidad problemática
Las empresas que se dedican al desarrollo de Software, tienen que lidiar con
los costos y tiempo de desarrollo altos, los cuales son mayores cuando se
tratan de proyectos de Software de mayor envergadura, y a los cuales se les
incluyen los problemas como la gran cantidad de líneas código, tanto para
validación de datos, de formularios, conectividad con la base de datos, etc.
Además, sin importar el tipo de aplicaciones Web a desarrollarse, se requiere
contar, dentro del equipo, con analistas, diseñadores y programadores
quienes deben aplicar elementos de calidad para lograr la aceptación de la
aplicación por parte del cliente.
Por ello, dichas empresas se hacen frecuentemente cuestionamientos como:
¿cuál será la apariencia final de la aplicación?, ¿trabajará con la eficiencia y
eficacia requerida?, ¿tendrá la calidad exigida por el cliente?, ¿el tiempo que
usa la aplicación para ejecutar alguna acción es el adecuado?, entre otras.
Pero actualmente existen herramientas que facilitan el desarrollo de Software
de forma eficaz y eficiente aportando elementos esenciales para su calidad y
mejorando sus tiempos de ejecución. Estas herramientas son conocidas como
marcos de trabajo (frameworks), que hoy en día, su uso es más frecuente
permitiendo a los desarrolladores evitarse los inconvenientes mencionados
anteriormente. Estos se dividen en frameworks para el lado del cliente (se
usan para la programación de aplicaciones que se ejecutan en el computador
local del usuario y se conectan a un servidor cuando es necesario) y
frameworks para el lado del servidor (para la programación de aplicaciones
especialmente útiles en trabajos que se tiene que acceder a información
centralizada, situada en una base de datos en el servidor, y cuando por
razones de seguridad los cálculos no se pueden realizar en la computadora
del usuario).
Pero al existir en el mercado, una diversidad de marcos de trabajo, la pregunta
a realizarse sería ¿cuál de estos marcos de trabajo utilizar?, ¿cuándo
utilizarlos?, ¿en qué tipo de aplicaciones Web son más útiles?, ¿cuál marco
de trabajo es más recomendable utilizar en el lado del cliente y en el lado del
3
servidor?. Esto se debe a que en nuestro medio no existen estudios previos
de comparativas de estas tecnologías que ayuden a los desarrolladores
escoger un marco de trabajo que se adapte a las necesidades o envergadura
de su proyecto. El problema de desarrollar sistemas o aplicaciones sin tomar
criterios de selección de marcos de trabajo o sin tener en cuenta alguna
investigación como base para sus desarrollos de Software, se vería reflejado
en sistemas poco satisfactorios e improductivos en cuanto a su rendimiento y
escalabilidad.
Para satisfacer estos requisitos es necesario saber elegir qué framework
utilizar teniendo como base algún estudio previo de estos. Es por esta razón
que se realizó un estudio comparativo del tiempo de ejecución de una
aplicación Web desarrollada en diferentes marcos de trabajo utilizados en el
lado del cliente y en el lado del servidor.
1.1.2. Formulación del problema
¿Cuál es el tiempo de ejecución de una aplicación Web que ha sido
desarrollada con diferentes marcos de trabajo utilizados en el lado del cliente
y en el lado del servidor?
1.2. Objetivos de la investigación

1.2.1. Objetivo general
Realizar un análisis comparativo del tiempo de ejecución de una aplicación
Web desarrollada en diferentes marcos de trabajo utilizados en el lado del
cliente y en el lado del servidor.
1.2.2. Objetivos específicos
 Describir los conceptos de funcionamiento y arquitectura de cada marco
de trabajo.
 Determinar los requerimientos de las empresas de desarrollo respecto a
la aplicación que se usará en el proceso comparativo.
 Establecer criterios y parámetros de comparación que permitan medir los
tiempos de ejecución de la aplicación.
1.3. Justificación de la investigación

El desarrollo de aplicaciones Web avanza a un ritmo vertiginoso tanto así que
empresas y/o profesionales de esta rama buscan la mejor forma o alternativa
para producir mejores productos, para ello recurren a herramientas o
4
tecnologías que se encuentran en auge denominadas marcos de trabajo
(frameworks). Pero no todas estas herramientas pueden llegar a solucionar o
cubrir las necesidades al momento de emprender un proyecto de desarrollo
de Software, por la sencilla razón que estas tecnologías han sido creadas para
solucionar problemas o situaciones específicas. Entonces al no tener el
conocimiento suficiente y apropiado del uso y beneficios de estas tecnologías
en algunos casos se puede llegar a obtener productos no esperados. Y esto
sucede debido a que no existen estudios o investigaciones que demuestren o
sirvan de base para determinar qué marcos de trabajo son convenientes
emplear para diferentes escenarios.
Este proyecto de investigación se realizó con la finalidad de determinar qué
marcos de trabajo permiten que la aplicación a desarrollar tenga mejores
tiempos de ejecución, debido a que estos deben ser cortos y de gran
velocidad. Además esta investigación es un aporte para aquellas empresas
de desarrollo de Software y desarrolladores, puesto que además de ofrecer
una visión clara y amplia del manejo de estas herramientas, les servirá como
base para futuros proyectos debido a que les resultará más fácil seleccionar
un marco de trabajo de acuerdo a las necesidades y magnitud del proyecto
que desean empezar.
Cabe indicar que en esta investigación solo se abarcarán aspectos de calidad
y no de seguridad de Software. En la parte de calidad se tomó el rendimiento
como factor de calidad para el desarrollo de Software, este factor está definido
en el modelo FURPS (Funcionality, Usability, Reliability, Performance,
Supportability) desarrollado por Hewlett Packard en 1987; además dentro de
este factor se encuentra como atributo el tiempo de ejecución que sirvió como
criterio de comparación de la presente investigación.
1.4. Hipótesis de la investigación

1.4.1. Hipótesis general.
Existe diferencia significativa en el tiempo de ejecución de una
aplicación Web desarrollada en diferentes marcos de trabajo utilizados
en el lado del cliente y en el lado del servidor.
5
Capítulo 2. Marco Teórico
Actualmente empresas desarrollan su Software con tecnologías con las que más
tienen experiencia, pero estas ya no son utilizadas actualmente teniendo de
ejemplo algunos lenguajes de programación tales como Cobol, FoxPro,
PowerBuilder solo por mencionar algunos. Esto ocasiona que las aplicaciones que
estén desarrollando no sean las más rápidas posible, es decir que los tiempos de
ejecución antes, durante y después de ejecutarla sean los más cortos y rápidos
posibles. Para conseguir esto, los sistemas han tenido que migrar del tradicional
escritorio hacia la Web la cual brinda un ambiente similar al de las aplicaciones de
escritorio. Para esto es casi obligado el uso de técnicas como: hojas de estilo, un
marcado HTML, menor refrescamiento de pantalla mediante Ajax y mayor
intervención de programación del lado del cliente con JavaScript, para así poder
cumplir las necesidades suscitadas anteriormente. Es aquí donde surgen
herramientas o tecnologías que permitan que el desarrollo de aplicaciones Web sea
más rápido y eficiente, por consiguiente obtener Software con mejores tiempos de
ejecución. En nuestro entorno estas herramientas son relativamente nuevas,
denominadas marcos de trabajo o en ingles framework, que se define como “un
conjunto de componentes físicos y lógicos estructurados de tal forma que permitan
ser reutilizados en el diseño y desarrollo de nuevos sistemas de información”
(Guerrero & Recaman, 2009). Según Saavedra (2009) “un framework es una
estructura de soporte definida en la cual otro proyecto de Software puede ser
organizado y desarrollado a partir de una estructura Software compuesta de
componentes personalizables e intercambiables para el desarrollo de una
aplicación”. Guerrero & Suarez (2010), indican que “los marcos de trabajo
contienen patrones y buenas prácticas que apoyan el desarrollo de un producto y
un proceso con calidad”. Lo anterior permite vislumbrar la importancia de adoptar
un marco de trabajo y cómo su elección debe ser una de las actividades relevantes
al inicio de todo proceso de desarrollo de Software. Cada uno está orientado a un
tipo de proyecto por lo que elegir el adecuado nos puede ahorrar una gran cantidad
de trabajo. En su Web Ernesto (s.f) indica que:
“Cada tecnología de desarrollo Web o lenguaje de programación tiene

distintos frameworks con los que se pueden crear aplicaciones más
rápidamente. Algunos sistemas como .NET incluyen un framework en su
6
distribución más básica, pero otros lenguajes como PHP tienen diversos
frameworks creados por distintas empresas que se pueden utilizar
opcionalmente. Los frameworks además se pueden encontrar para
programación del lado del cliente y lado del servidor. Los frameworks del lado
del cliente sirven para programar con lenguaje JavaScript de una manera
rápida y compatible con todos los ordenadores. Mientras que los frameworks
para el desarrollo de aplicaciones en el lado del servidor se pueden encontrar
sobre varios lenguajes de programación PHP, .Net, Rubi, etc. (párr.3 ). “
Como se mencionaba anteriormente existen frameworks para la programación del

lado del cliente, según Cobo, Gómez, Pérez, & Rocha, (2005) indican que “la
programación del lado del cliente: los programas residen junto a la página Web en
el servidor pero son transferidos al cliente para que este los ejecute” (p. 16) y para
la programación del lado del servidor, Cobo, at el (2005) indican que “la
programación del lado del servidor: los programas son ejecutados por el servidor y
lo que se envía al cliente es la respuesta o resultado de dicha ejecución” (p.16).
Para el lado del cliente los frameworks están basados en el lenguaje de

programación JavaScript, dentro de ellos se encuentra JQuery que “es un
framework rápido, simple y liviano que cuenta con una API fácil de usar y que
funciona a través de una multitud de navegadores con una combinación de
versatilidad y capacidad de ampliación” (Bermeo Rodriguez, 2014, p. 6). Las
caracteristicas más resaltantes de este framework son: utiliza el paradigma de
programación orientada a prototipos, se enfoca en la manipulación de elementos
DOM, hace posible los efectos y animaciones en una página Web, extensa
comunidad de desarrollo, de fácil aprendizaje e interacción con el servidor a través
de Ajax.
Por otra parte existe AngularJs que es un framework JavaScript basado en MVC y
que se centra en intentar dinamizar documentos HTML y ejecutarse como
aplicación de una sola página. AngularJs cambia el enfoque de dinamización de
documentos HTML estáticos mediante la vinculación de elementos del documento
HTML con el modelo de datos (Data Binding). De este modo, se define un modelo
de datos que se correspondera con determinadas partes del documento HTML y,
siempre que hay cambios en una parte, automáticamente se veran reflejados en la
7
otra, con independencia del árbol DOM de JavaScript. Las caracteristicas más
resaltantes de AngularJs son: sigue el patrón MVC, sencillo y potente sistema Data
Binding, popularización de las aplicaciones, inyección de dependencias y
construcción de dependencias y/o modificación de comportamiento mediante
directivas.
Los frameworks para el lado del servidor basados en el lenguaje de programación

PHP tenemos a Laravel, un framework de código abierto para desarrollar
aplicaciones y servicios Web con PHP5. Su filosofía es desarrollar código PHP en
forma elegante y simple, evitando el ”código espagüeti”, es decir evitar desarrollar
con una estructura de control de flujo compleja e incomprensible. Gran parte de
Laravel está formado por dependencias espcielmente de Symfony. Esto implica que
el desarrollo de Laravel dependa tambien del desarrollo de sus dependencias. Las
caracteristicas más resaltantes de este framework son: sistema de ruteo, motor de
plantillas Blade, peticiones Fluent, Eloquent ORM, basado en Composer y soporte
para MVC.
Otro framework para el lado del servidor es Symfony, un completo framework

diseñado para optimizar el desarrollo de las aplicaciones Web basado en el patrón
MVC. Para empezar, separa la lógica de negocio, la lógica del servidor y la
presentación de la aplicación Web. Proporciona varias herramientas y clases
encaminadas a reducir el tiempo de desarrollo de un aplicación Web compleja.
Además, automatiza las tareas más comunes, permitiendo al desarrollador
dedicarse por completo a los aspectos específicos de cada aplicación. El resultado
de todas estas ventajas es la reutilización de código favorable para el desarrollador
al momento de crear una nueva aplicación Web. Symfony está desarrollado
completamente en PHP5. Ha sido probado en numerosos proyectos reales y se
utiliza en sitios Web de comercio electrónico de primer nivel. Symfony es compatible
con la mayoría de gestores de base de datos, como MySQL, PostgresSQL, Oracle
y Microsoft SQL Server. Se puede ejecutar tanto en plataformas (Unix, Linux, etc.)
como plataformas Windows. Las características más resaltantes de este framework
son: La presentación usa templates y layouts que pueden ser construidos por
diseñadores de HTML que no posean conocimientos del framework, los formularios
soportan la validación automática, lo cual asegura mejor calidad de los datos en las
bases de datos y una mejor experiencia para el usuario, el manejo de caché reduce
8
el uso de banda ancha y la carga del servidor, el enrutamiento y las URLs
inteligentes hacen amigable las direcciones de las páginas de la aplicación y la
interacción con Ajax es mucho más sencilla.
Toda estas herramientas o tecnologías permiten el desarrollo rápido y eficiente de

aplicaciones Web, pero es necesario conocer el rendimiento de cada de uno de
ellos en circunstancias diferentes para asegurarnos que se pueden obtener
Software con la calidad esperada. Girón B. & Arguello P. (2014) en su tesis definen
el rendimiento como “la efectividad o la eficiencia de lograr un resultado de una
tarea, se puede medir el rendimiento tanto de Hardware como de Software y así
poder tener un resultado confiable”, (p.27).
En términos generales de sistemas de información, el rendimiento es considerado

como la reducción de uso de la CPU y la búsqueda de métodos más óptimos para
el sistema. (Nolte, 1995). De igual manera es necesario tener en cuenta aspectos
como throughput o volumen de trabajo o de información que fluye a través del
sistema, así como el tiempo de respuesta, el costo por transacción y medidas de
utilización de recursos, para evaluar el rendimiento de una aplicación (Throuhgput
IBM, 2010).
Bermeo Rodriguez (2014) sostiene que el rendimiento es una caracteristica que

representa la cantidad de recursos utilizados bajo ciertas caracteristicas tales como
comportamiento en el tiempo, que se refiere a los tiempos de ejecución y de
respuesta, procesamiento y ratios de un sistema cuando lleva a cabo sus funciones
bajo condiciones determinadas. Además la utilización de recursos que se refiere a
la cantidad y tipos de recursos utilizados cuando el Software lleva a cabo su función
bajo condiciones determinadas. Y por último la capacidad de operación que se
refiere a la capacidad del producto Software para adaptarse a normas relacionadas
con la eficiencia.
2.1. Antecedentes del estudio

2.1.1. Antecedentes internacionales
Zabala, X. & Ochoa C. (2008) en su tesis “Estudio de Frameworks para PHP
e integración a una herramienta IDE; aplicada al portal Web de la comunidad
Linux Espoch”, con objetivo general estudiar Frameworks PHP5 para
integrarlos a una herramienta IDE y aplicarlos al portal Web, dirigido a la
9
comunidad LINUX de la ESPOCH. Dicha investigación se planteó con el
interés de facilitar la creación de aplicaciones en PHP5 junto con MySQL; y,
con ello el desarrollo de un sitio Web para la Comunidad Linux de la Escuela
Superior Politécnica de Chimborazo. Por otro lado, se pretende indicar que
existen frameworks de PHP que bien pudieran favorecer al programador en
tiempo de desarrollo, empleo de mejores prácticas y uso de estándares para
emprender proyectos de Software con mucho esfuerzo y que sean sobre todo
de calidad.
Para cumplir con la investigación se usó el método de investigación científico,
una serie de información recolectada y luego procesada para incluirla en el
marco teórico, en las comparaciones se usó la tabla de ponderación,
finalmente para el desarrollo de la aplicación para la comunidad Linux de la
ESPOCH fue necesario aplicar la metodología de desarrollo rápido XP.
Los autores concluyeron que mediante un adecuado estudio de los
frameworks se puede obtener una visión mayor de su funcionalidad,
características, arquitectura, portabilidad, etc. Se puede obtener una larga
lista de frameworks para PHP; para seleccionar el más adecuado es necesario
estudiarlo y basarse en opiniones como foros de discusión, y el uso que se le
va a dar. Los frameworks estudiados tienen características diferentes a pesar
de basarse en el modelo MVC; sin embargo, se tomó en consideración sobre
la facilidad de uso en cuanto a acceso a datos, seguridad, plugins, Ajax,
interfaz gráfica. Y por último una de las debilidades de los frameworks es la
falta de documentación y de las continuas liberaciones del Software, ya que
en ocasiones el creador del framework abandona el proyecto.
Este trabajo se relaciona con la investigación planteada, ya que se centra en
estudiar aquellos frameworks para PHP es decir del lado del servidor, con la
finalidad de obtener una visión más amplia de sus características, arquitectura
y funcionalidad para así poder desarrollar la aplicación Web con el framework
que mejor se adapte a las necesidades del proyecto.
Sánchez, E. & Vera, I.(2011) en su tesis “Análisis del rendimiento de
Frameworks PHP para desarrollar aplicaciones Web óptimas. Caso práctico:
Portal Academia Linux Espoch”, donde el objetivo general de la investigación
fue realizar un análisis comparativa del rendimiento de frameworks PHP para
desarrollar aplicaciones Web optimas; trata sobre un estudio y análisis
10
investigativo a fondo del rendimiento de diferentes frameworks para obtener
como resultado el framework más óptimo para el desarrollo de aplicaciones
Web. Esta investigación hace referencia a que la mayoría de desarrolladores
implementan sus proyectos en el framework que tienen más conocimiento, sin
realizar una investigación previa en búsqueda del framework que se ajuste a
las necesidades y a su vez ofrezca el mejor rendimiento y escalabilidad.
Los autores concluyen que mediante un adecuado estudio de los tres
frameworks seleccionados, se puede tener una mejor visión en el marco del
rendimiento. Además el estudio les permitió determinar que el framework más
eficiente para el desarrollo en el rendimiento es CodeIgniter. Y por último el
manejo de la base de datos mediante el uso de frameworks requiere de
utilización de recursos de Hardware y Software al momento de realizar
consultas a base de datos, demostrando que CodeIgniter posee las mejores
librerías para el manejo de base de datos, superando ampliamente a Cake
con un 62% seguido a Zend con un 25% en el manejo de transacciones.
Esta investigación está relacionada con la investigación planteada debido a
que también realiza un comparativo de los frameworks para el lado del
servidor, en este caso del lenguaje de programación PHP. Y además permite
determinar que parámetros se pueden utilizar para realizar este estudio
comparativo.
Espinoza, C. (2012) en su trabajo de monografía “Comparativa de
Frameworks para el desarrollo de aplicaciones con PHP”, cuya investigación
hace referencia a que los desarrolladores eligen frameworks al azar,
generando dificultades al proyecto, es por esa razón que pretende comparar
los frameworks más populares. Su propuesta se basa en escoger la mejor
herramienta, mediante la implementación de un caso práctico, evitando que
los programadores pierdan tiempo identificando tediosos detalles de bajo
nivel, en vez de requerimientos de Software. Para seleccionar estas
herramientas utilizó modelos o métodos de calidad en función del framework
seleccionado generar aplicaciones uniformes que faciliten reutilizar código y
promover buenas prácticas de desarrollo, como el uso de patrones y a su vez
incrementa las ganancias.
La autora concluye que dentro de los modelos o estándar de calidad, el
estándar que se adapta a la evaluación del framework es el ISO IEC 9126 al
11
ser considerado como modelo mixto, en el que su principal característica es
definir factores de calidad más abstractos que sean reutilizados virtualmente
en todos los dominios posibles, facilitando así la comparativa de los
frameworks, además de no ser modelo rígido, facilitando así la comparativa
de los frameworks.
Este trabajo de investigación es pertinente con la investigación planteada,
debido a que también se realiza una comparativa de frameworks para el
desarrollo de aplicaciones con PHP. Además hace énfasis en que al no tener
conocimientos de estos se genera dificultades en los proyectos de desarrollo.
Ponce, S. (2011) en su proyecto “Sistema Web para el Departamento de
Asesoría Jurídica de la dirección Provincial de Educación de IMBABURA SIG-
RRHH, mediante la utilización del Framework Symfony”. El objetivo de este
proyecto fue desarrollar e implementar un sistema Web para el departamento
de Asesoría Jurídica de la Dirección Provincial de Educación de Imbabura,
para mejorar la gestión de los procesos. En su proyecto define qué la correcta
administración y control del recurso humano permite a instituciones agilizar
sus procesos, reducir costos y la consecución de los objetivos de calidad, es
por ello que el desarrollo de un Sistema Web para la gestión de recurso
humano para la Dirección Provincial de Educación de Imbabura, facilitara los
procesos concernientes al Personal, permitiendo realizar actividades para la
manipulación de datos en tiempo real; utilizando herramientas de desarrollo
como PHP y MySQL con utilización del framework Symfony, evitando la
pérdida de la información y agilizando los trámites correspondientes.
El autor concluye que la automatización y seguridad de la información en la
Dirección de Educación de Imbabura reduce gastos por pérdida de
información y agiliza los trámites correspondientes, mejorando la
administración en procesos informáticos. Además al utilizar MVC en el
desarrollo del módulo “Sistema Web para el departamento de Asesoría
Jurídica” nos permite tener la estructura del sistema de una manera ordenada,
permitiendo el buen funcionamiento del aplicativo por parte del área de
informática. Y por último que MySQL es un motor de base de datos que
proporciona solidez, confiablidad, pertinencia, seguridad, integridad,
disponibilidad, relevancia con datos almacenados como: Instituciones
educativas, datos de personas particulares, documentos legales,
12
resoluciones, citas, etc.
Este proyecto tiene relación a la investigación planteada debido a que se
desarrolla una aplicación Web utilizando el framework Symfony, siendo este
uno de los frameworks del lado del servidor que será objeto de estudio en esta
investigación.
2.1.2. Antecedentes nacionales
Calmet, J.(2014) en su tesis “Sistema informático Web de trámite
documentario para la Ugel de Zarumilla – Tumbes utilizando los frameworks
AngularJS y Spring MVC”, presenta una propuesta funcional de un sistema de
información Web desarrollado utilizando dos de los frameworks más
populares hoy en día: AngularJS y Spring MVC, para la gestión de
expedientes en el proceso de tramite documentario de una Unidad de Gestión
Educativa Local, cuyo propósito es mejorar el control y seguimiento de los
expedientes al interior de la institución. Para lograr esto, previo al desarrollo
de la propuesta, se realizó un análisis de la institución, identificando la realidad
problemática y las oportunidades de mejora a través de un sistema de
información Web.
Para el desarrollo de la propuesta se escogió a ICONIX como metodología de
desarrollo lo que permitió realizar el análisis y diseño del sistema haciendo
uso de técnicas como el modelado con Lenguaje Unificado de Modelado
(UML).
De esta manera se procedió a la implementación utilizando un entorno de
desarrollo integrado (IDE) que permitió realizar la correcta integración de los
frameworks seleccionados, llegando a la conclusión que a través del
desarrollo de un sistema de información Web para el proceso de tramite
documentario, se logra capitalizar una oportunidad de mejora en el control y
seguimiento de expedientes al interior de la institución utilizando AngularJS y
Spring MVC como frameworks front-end y back-end respectivamente y una
metodología de desarrollo ágil para acelerar el desarrollo del sistema.
Esta tesis se relaciona con la presente investigación por la razón que uno de
los frameworks utilizados para el desarrollo del sistema informático en esa
tesis será objeto de estudio en la investigación debido a que pertenece a los
frameworks del lado del cliente, AngularJs.
13
2.2. Framework
2.2.1. Definición
Un framework o marco de trabajo es un conjunto de componentes físicos y
lógicos estructurados de tal forma que permiten ser reutilizados en el Diseño
y Desarrollo de nuevos Sistemas de Información. (Minetto, 2007).
Los frameworks son un conjunto de buenas prácticas de desarrollo

representadas en una serie de librerías baja un único esquema de
colaboración que resuelven un problema en particular el cual se puede tomar
como base para resolver nuevos problemas con las mismas características
y así crear aplicaciones de manera rápida.
Los principales objetivos que un framework son: Acelerar el proceso de

desarrollo, reutilizar código ya existente, promover buenas prácticas de
desarrollo como es el uso de patrones, desarrollo estructurado, disminuir el
esfuerzo en el desarrollo y centrarse directamente en la solución del
problema.
Un framework simplifica el desarrollo de las aplicaciones, ya que automatiza

muchos de los patrones para resolver las tareas comunes. Además, una
framework proporciona estructura al código fuente, forzando al desarrollador
a crear código más legible y más fácil de mantener. Por último, un framework
facilita la programación de aplicaciones, ya que encapsula operaciones
complejas en instrucciones sencillas.
En general, con el término framework, nos estamos refiriendo a una

estructura software compuesta de componentes personalizables e
intercambiables para el desarrollo de una aplicación. En otras palabras, un
framework se puede considerar como una aplicación genérica incompleta y
configurable a la que podemos añadirle las últimas piezas para construir una
aplicación concreta (Gutierrez J. J.) .
2.2.2. Clasificación
Un marco de trabajo (framework) se puede clasificar tomando en cuenta el
ámbito en que se desenvuelve:
14
 System infraestructure frameworks: Frameworks para
infraestructura de un sistema. Estos frameworks simplifican el
desarrollo de aplicaciones, ya sea frameworks de comunicaciones,
interfaces de usuario, etc. Este tipo de frameworks son internos de la
organización y no son vendidos a los consumidores directamente.
 Middleware integration frameworks: Frameworks de integración.
Estos frameworks son comúnmente utilizados para integrar
aplicaciones distribuidas y componentes. Son diseñados para mejorar
la habilidad de los desarrolladores de Software de modularizar,
reutilizar y extender la infraestructura de las aplicaciones para trabajar
en ambientes distribuidos. Estos frameworks pueden ser vendidos a
los consumidores, que usualmente son otras organizaciones
dedicadas al desarrollo de Software.
 Enterprise application frameworks: Frameworks para aplicaciones
empresariales. Estos frameworks tratan con muchos dominios de
aplicaciones como telecomunicaciones, aeronáutica, finanzas. En
comparación con los frameworks de infraestructura o integración, son
costosos de desarrollar o de adquirir. Los frameworks empresariales
soportan el desarrollo de aplicaciones directamente, en contraste a
los frameworks de integración e infraestructura, que se enfocan en el
desarrollo interno a una organización (Object-Oriented Application
Frameworks, 2016).
También un marco de trabajo (framework) se puede clasificar según su

extensibilidad en:
 White Box: Frameworks de Caja Blanca o dirigidos por la

arquitectura, poseen las características a la orientación de objetos,
tales como la herencia o la ligadura dinámica. El framework se
extiende por herencia de sus clases base o redefiniendo sus métodos.
Estos frameworks definen interfaces para componentes que pueden
integrarse mediante composición de objetos. Sin embargo, la
dificultad del uso de este tipo de frameworks reside en el hecho de
que requieren un profundo conocimiento y comprensión de las clases
a extender. Otro punto débil, de la herencia en general, es la
15
dependencia entre métodos, redefinir una operación puede requerir
redefinir otra, y así sucesivamente.
 Black Box: Frameworks de Caja Negra o dirigidos por datos, se
estructura utilizando composición de objetos y delegación en lugar de
herencia. Enfatizan las relaciones dinámicas entre los objetos en lugar
de relaciones estáticas entre las clases. Se puede añadir nueva
funcionalidad al framework componiendo objetos existentes de
diferentes formas, para reflejar el comportamiento de la aplicación. El
usuario del framework no tiene que conocer con profundidad los
detalles de éste, sino sólo conocer cómo usar y combinar los objetos
existentes. En general son más fáciles de utilizar que los frameworks
de caja blanca. Por el contrario, los frameworks de caja negra son
más difíciles de construir, porque sus interfaces y puntos de anclaje
deben anticiparse a un conjunto muy amplio de posibilidades.
 Grey Box: Estos frameworks es la combinación de los frameworks de
caja blanca y negra, buscando evitar sus desventajas. Permiten la
extensión mediante la herencia y la ligadura dinámica, y además
tienen la propiedad de ocultar información innecesaria a los usuarios
del framework. Los frameworks de caja gris intentan sacar provecho
de los beneficios de ambos tipos de frameworks, mientras intentan
validar las limitaciones de ambos. Realizando un análisis del ciclo de
vida de los distintos tipos de frameworks, los frameworks de caja
negra representan la etapa de madurez de un framework, pero
muchas veces hay limitaciones tanto de tiempo como de dinero que
impiden alcanzar esta etapa, por lo que el desarrollo del framework
queda “a medio camino” como un framework de caja gris (Fernandez
Silva & Jalil Moreno, 2007).
2.2.3. Características de los frameworks

Principales características que se pueden encontrar en prácticamente todos
los marcos de trabajo existentes.
16
Tabla 1.
Principales características identificadas en los frameworks (marcos de
trabajo).
DESCRIPCIÓN CARACTERÍSTICAS
Abstracción de URLs No es necesario manipular directamente las URLs ni las
sesiones, el marco de trabajo ya se encarga de hacerlo.
Acceso a Datos Incluyen herramientas e interfaces necesarias para
integrarse con herramientas de acceso a datos.
Disponen de conectores a las bases de datos más
conocidas.
Controladores La mayoría de marcos de trabajo e interfaces
implementa una serie de controladores para gestionar
eventos, como una introducción de datos mediante un
formulario o el acceso a una página. Estos controladores
poder ser fácilmente adaptables a las necesidades de un
proyecto en concreto.
Autenticación y Incluye mecanismos para la identificación de usuarios,
control de acceso mediante la solicitud de nombre de usuario y una
contraseña cifrada, para restringir el acceso a
determinados componentes y usuarios.
Formularios Cuenta con herramientas para crear formularios,
permitiendo la aplicación de controles personalizados a
cada uno de los objetos que son utilizados en
formularios.
Código Abierto Reducción de costos en licencias, pues la mayoría de
(OpenSource) componentes reutilizables son de código abierto.
Reducción de Permiten la creación de plantillas para la reutilización de
esfuerzo en el código. Permite la simplificación de problemas comunes
desarrollo en proceso desarrollo, por ende se optimizan los
tiempos de desarrollo.
Solución definida y Satisface requerimientos claramente definidos en un
controlada proyecto.
Fuente: (Guerrero & Recaman, 2009) .
2.2.4. Ventajas de los frameworks

Utilizar frameworks en el desarrollo de un sistema proporciona una serie de
ventajas:
 Reutilización de código: Los frameworks son desarrollados

específicamente para ser usados en una variedad de proyectos, por
lo que una ventaja principal es que el programador que lo usa, está
código que otras personas se tomaron la molestia de diseñar,
codificar y probar.
 Código probado: El framework no sólo es probado por los
desarrolladores que lo codificaron, sino que es probado
continuamente por toda la comunidad de programadores que hace
17
uso de él en situaciones muy variadas. Esto da confianza al
programador para utilizarlo y saber que existe información generada
por otros usuarios que alertan sobre posibles fallos en el framework
y hasta la forma de evadirlos.
 Implantación de mejores prácticas: En el diseño y construcción de
un framework, los desarrolladores se basan en todo su conocimiento
y experiencia adquirida a lo largo de muchos años. El resultado es
que el programador que usa el framework utiliza, a veces sin saberlo,
las mejores prácticas introducidas en él desde el diseño, tanto las que
se usen internamente, como las expuestas en el API para uso y
extensión.
 Definición de arquitectura: Los frameworks definen (total o
parcialmente) la estructura arquitectónica de la aplicación que se
monte sobre ellos. Esto ayuda al arquitecto del sistema a tomar las
decisiones más rápidamente, sobre la forma de organizar los
módulos, componentes y demás recursos que en conjunto forman la
aplicación.
 Acelera el desarrollo de aplicaciones: Al sumar todos los puntos
anteriores, el resultado final del uso de los frameworks apropiados en
una aplicación es que debería recortarse el tiempo necesario para
implementar el desarrollo (Hohman Sandoval, 2014).
2.2.5. Desventajas de los frameworks

 Curva de aprendizaje: Cada framework es muy particular, tiene un
API diferente y formas distintas de hacer las cosas, por lo tanto existe
un tiempo de aprendizaje por el que cada programador que quiere
usar el framework tiene que pasar algo similar al de aprender un
lenguaje nuevo.
El inicio de este aprendizaje suele ser muy lento, durante esta etapa
el programador deber dedicar su tiempo y esfuerzo a conocer la
herramienta, por lo que no es de mucha utilidad para el proyecto.
En una segunda etapa, se acelera el aprendizaje y el programador
puede realizar tareas sencillas en beneficio del proyecto. Esta
experiencia acelera aún más su aprendizaje.
18
Finalmente, en una tercera se denomina el framework, el aprendizaje
deja de ser pronunciado, pero es en este punto en el que se
aprovechan las ventajas del framework aprendido y el programador
puede aportar valor al proyecto.
Lo que esto implica es que un programador que no conoce el
framework no puede comenzar inmediatamente a codificar, sino que
debe dedicar tiempo a conocer la herramienta y eso puede retrasar
un proyecto si no se le toma en cuenta.
 Limitaciones y restricciones del framework: Los frameworks
pueden llegar a ser muy intrusivos en el código de la aplicación ya
que obliga a utilizar la arquitectura que define o a utilizar las clases e
interfaces de las que debe heredar la aplicación. Esto crea un alto
acoplamiento con las interfaces/clases del framework y hacen difícil
quitar o cambiar el framework por otro con características similares.
 Uso de un framework no apropiado: Es posible que se elija usar un
framework no apropiado para el fin que se pretende alcanzar o bajo
las circunstancias en las que se encuentra el proyecto por una
variedad de razones. El framework puede no estar diseñado para el
uso que se pretender dar, no ser compatible con otros frameworks
usados en el proyecto, no estar suficientemente probado y causar
problemas en los que puede ser difícil detectar la causa ya que el
código del framework normalmente es ajeno al programador, puede
no tener un buen soporte de la comunidad. Una comunidad fuerte (en
número de integrantes y participación) es importante proporcionar
soporte a los programadores, pues es común que los problemas con
los que se enfrente una persona al usar el framework, se lo encuentre
otra después. Sí existe falta de documentación, foro de discusión y
otras herramientas, encontrar información útil será muy complicado,
puede no estar lo suficientemente maduro, por lo que puede haber
cambios no compatibles y radicales entre una versión y la siguiente,
lo que puede complicar introducir actualizaciones que corrigen errores
con el framework o agregar mejoras en rendimiento o en su utilización
(Hohman Sandoval, 2014).
19
2.2.6. Componentes de un framework
Según (Pree, 1994), los frameworks están conformados por zonas
congeladas (frozen spots) y zonas calientes (hot spots).
Las partes congeladas definen la arquitectura general de un sistema de
software, es decir, sus componentes básicos y las relaciones entre estos.
Esas partes permanecen inalteradas (congeladas) en cualquier
instanciación del framework.
Las partes calientes representan los puntos en los que los programadores
pueden añadir su propio código para añadir la funcionalidad específica de
su propio proyecto.
2.2.7. Patrones y frameworks

Los frameworks maduros incorporan varios patrones de diseño. Los
patrones ayudan a que la arquitectura del framework sirva para muchas
aplicaciones diferentes sin necesidad de rediseño. Esto implica que entre
mayor conocimiento se tenga de los diferentes tipos de patrones de diseño
se comprenderá mejor un framework. La mayoría de los frameworks utilizan
el patrón de diseño MVC (Modelo – Vista – Controlador).
Cabe recalcar que los frameworks son más que MVC, debido a que “MVC
no es una arquitectura” (Martin, 2011).
El patrón MVC es un patrón de arquitectura de software encargado de

separar la lógica de negocio de la interfaz de usuario y es el más utilizado en
aplicaciones Web, ya que facilita la funcionalidad, mantenibilidad y
escalabilidad del sistema, de forma simple y sencilla, a la vez que permite
“no mezclar lenguajes de programación en el mismo código”.
MVC divide las aplicaciones en tres niveles de abstracción:
 Modelo: representa la lógica de negocios. Es el encargado de

acceder de forma directa a los datos actuando como “intermediario”
con la base de datos.
 Vista: es la encargada de mostrar la información al usuario de forma
gráfica.
20
 Controlador: es el intermediario entre la vista y el modelo. Es quien
controla las interacciones del usuario solicitando los datos al modelo
y entregándolos a la vista para que ésta la presente al usuario.
El diagrama de la Figura 1 muestra el funcionamiento del patrón MVC.
Figura 1. Funcionamiento del Patrón MVC
1) El usuario solicita o realiza un evento en la aplicación.

2) El controlador captura el evento y hace la llamada al modelo
correspondiente.
3) El modelo será encargado de interactuar con la base de datos, ya sea
en forma directa o con una capa de abstracción para ello.
4) El modelo retorna la información al controlador.
5) El controlador procesa y envía la información a la vista.
6) La vista recibe la información y la presenta al usuario mediante
interfaces gráficas.
2.3. Aplicaciones Web

2.3.1. Concepto de aplicación Web
Las aplicaciones Web son aquellas aplicaciones 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
21
se codifica en un lenguaje soportado por los navegadores Web en la que se
confía la ejecución al navegador.
Este tipo de aplicaciones se basan en la arquitectura Cliente-Servidor, y

específicamente en una arquitectura de tres capas tal como se puede
apreciar en la Figura 2.
Figura 2. Arquitectura de tres capas de una aplicación Web

Fuente: (SOURCEFORGE.NET, 2005)
El navegador (capa cliente) accede a una interfaz conformada por páginas

Web, que es visualizada a través de una navegador Web, los clientes se
comunican con el servidor (capa lógica) sobre el cual funciona la aplicación
Web, haciendo uso del protocolo HTTP (protocolo de transferencia de
hipertexto).
En el servidor de aplicaciones se ejecuta el sistema responsable de:
 Generar las interfaces de usuario (páginas Web) que son enviadas a

los clientes.
 Ejecutar la lógica del negocio.
 Comunicarse con la base de datos (capa de persistencia) para
almacenar o recuperar información.
En la capa de persistencia normalmente se encuentra en funcionamiento un

servidor de base de datos responsable de almacenar toda la información
perteneciente al sistema.
22
Es importante mencionar que una página Web puede contener elementos
que permitan una comunicación activa entre los usuarios y la información.
Esto permite que el usuario acceda a los datos de modo interactivo, gracias
a que la página responderá a cada una de sus acciones, como por ejemplo
rellenar y enviar formularios, participar en juegos diversos y acceder a
gestores de base de datos de todo tipo (Amarez Hernández, Campos
Cantero, & Castelo Delgado, 2011).
2.3.2. Características de las aplicaciones Web

Características importantes de las aplicaciones Web.
Tabla 2.
Características de las aplicaciones Web
CARACTERÍSTICA DESCRIPCIÓN
Ahorro de tiempo Se pueden realizar tareas sencillas sin necesidad
de descargar e instalar ningún programa.
Compatibilidad No hace falta crear diferentes clientes en función
de cada sistema operativo. Basta tener un
navegador actualizado para poder utilizarlos.
Espacio No ocupan espacio en el disco duro
Multiplataforma Se puede usar desde cualquier sistema operativo
porque solo es necesario tener un navegador
Fuente: (Amarez Hernández, Campos Cantero, & Castelo Delgado, 2011) .
23
2.4. Framework Laravel
Figura 3. Logo del Framework Laravel

Fuente: (Laravel, 2016)
2.4.1. Introducción
Laravel es un framework Open-Source para desarrollar en PHP, con una
filosofía muy clara enfocada para que el código sea lo más expresivo y
elegante posible, para desarrollar aplicaciones y servicios Web.
En el año 2001, el creador de Laravel Taylor Otewell vio la carencia de

funcionalidades en el framework CodeIgniter, la cual pensó que eran
indispensables en la construcción de aplicaciones Web. Es por eso que para
completar esas características lanzo la primera versión beta de Laravel en
Junio de ese mismo año, aun no siendo MVC, poseía otras funcionalidades
como Eloquent ORM para operaciones en la base de datos, localización,
modelos, sesiones, vistas y mucho más. La versión 2 de Laravel apareció
seis meses después, con una sintaxis limpia y simple para el desarrollo y la
adicción de convertirse en un framework MVC completo. En Febrero del
2012 Laravel 3 fue lanzado enfocándose en la integración de pruebas
unitarias, la interfaz de línea de comandos Artisan, migración de base de
datos, eventos, drivers de sesiones y base de datos. Llegando a la versión 4
denominada Illuminate, presentando una diferente arquitectura del núcleo
del framework. La versión de Laravel 5.0 introduce una estructura nueva
para el proyecto Laravel predeterminado. Esta nueva estructura sirve como
una mejor base para la construcción de una aplicación robusta en Laravel,
así como (PSR-4 Estándar de Auto Carga) que cuenta en toda la aplicación.
24
Laravel 5.1 sigue las mejoras realizadas en Laravel 5.0 mediante la adopción
(PSR-2 Codificación guía de estilo) y la adición de retransmisión de eventos,
parámetros de middleware, las mejoras comandos de Artisan, etc.
Laravel 5.2 incorporó mejoras, mediante la adición de soporte de múltiples

controladores para la autenticación, modelo implícito de unión, grupos de
Middleware, las mejoras de validación de matriz. (Arcos Chalán & Chicaiza
Inguillay, 2016).
2.4.2. Instalación
Para ver como se realiza la instalación de este framework ver Anexo 5.
2.4.3. Características
En la Tabla 3 se muestra las principales características de Laravel:
Tabla 3.
Características de Laravel
CARACTERÍSTICA DESCRIPCIÓN
Modularidad Laravel se ha construido utilizando más de 20 librerías
diferentes, fuertemente integradas con el gestor de
dependencias Composer.
Testeabilidad Laravel tiene varios asistentes (helpers) que ayudan a visitar
las rutas de testeo, navegando por el HTML resultante para
asegurar que los métodos que se llamen desde las diferentes
clases sean correctos.
Enrutamiento Laravel proporciona una extrema flexibilidad en la definición
(routing) de las rutas de la aplicación. Inspirado en la filosofía de los
micro-frameworks Sinatra y Silex. Todavía más, es posible
adjuntar funciones de filtro que se ejecuten en rutas
específicas.
Gestor de Frecuentemente la aplicación se ejecutará en diferentes
configuración entornos, esto quiere decir que tanto la base de datos como
credenciales o dominios serán diferentes si se ejecutan en el
entorno de test o en los servidores de producción. Laravel
permite definir configuraciones separadas para cada uno de
los entornos.
Confeccionador de Cuando se instala Laravel viene con un constructor de
consultas y ORM consultas, este permite lanzar consultas a la base de datos
(Object Relational con una sintaxis PHP de métodos enlazados, en lugar de
Mapper) tener que escribir código SQL. Además proporciona un ORM
y una implementación de Registro Activo (ActiveRecord)
llamado Eloquent, que permite definir modelos
interconectados. Estos componentes son compatibles con
gestores de base de datos tales como PostgreSQL, SQLite,
MySQL y SQL Server.
Confeccionador Inspirado por la filosofía Rails, estas características permiten
esquema, definir un esquema de base de datos dentro de PHP y
mantener un registro de los cambios para así ayudar en la
25
migraciones y migración de base de datos. Las repoblaciones (Seeding)
repoblaciones permiten poblar las tablas seleccionadas de una base de
datos una vez realizada la migración para de esta forma
rellenar con datos las tablas.
Motor de plantillas Laravel viene con Blade, un lenguaje ligero de plantillas con
el cual se pueden crear diseños anidados con bloques
predefinidos en el que el contenido se inserta dinámicamente.
Además Blade guarda en Caché los archivos generados.
Email Con la clase Mail que es un derivado de la librería SwiftMailer,
Laravel proporciona una forma muy sencilla de enviar emails,
con contenido HTML y adjuntos.
Autenticación Laravel viene con las herramientas para crear en toda Web
un formulario de registro, autenticación e incluso envió de
contraseñas a usuarios que no la recuerden.
Fuente: (Orduz Navarrete, 2016).
2.4.4. Estructura
La estructura de aplicaciones predeterminada de Laravel pretende
proporcionar un gran punto de partida para aplicaciones grandes y
pequeñas. (Laravel, 2016).
El diagrama de la Figura 4 muestra la estructura de una aplicación en el

framework Laravel:
26
Figura 4. Estructura de directorios en
Laravel.
Tabla 4.
Estructura de directorios en Laravel
DIRECTORIO PROPÓSITO
app/ Contiene el código principal de la aplicación, todas las clases
de la aplicación estarán en este directorio.
bootstrap/ Contiene archivos que inicializan el framework y configuran
el autoloading. Este directorio contiene un directorio Caché
que contiene archivos generados por el framework para la
optimización del rendimiento, como la ruta y los archivos de
Caché de servicios.
config/ Contiene todos los archivos de configuración de la
aplicación.
database/ Contiene las migraciones de la base de datos y los seedings.
También se puede utilizar este directorio para mantener una
base de datos SQLite.
public/ Contiene el archivo index.php, que es el punto de entrada
para todas las solicitudes que entran a la aplicación. Este
directorio también contiene imágenes, archivos JavaScript y
CSS.
27
resources/ Contiene las vistas de la aplicación, así como recursos
crudos, no compilados, como LESS, SASS o JavaScript.
Este directorio también contiene todos los archivos de
idioma.
routes/ Contiene todas las definiciones de ruta para su aplicación.
De forma predeterminada, se incluyen tres archivos de ruta
con Laravel: Web.php, api.php y consola.php.
storage/ Contiene las plantillas de Blade compiladas, sesiones
basadas en archivos, caches de archivos y otros archivos
generados por el framework.
tests/ Contiene las pruebas automatizadas que se implementen.
vendor/ Contiene las dependencias descargadas e instaladas con
Composer
Fuente: (Laravel, 2016).
Elaboración propia
2.4.5. Componentes
Entre los principales componentes de Laravel se tienen los siguientes:
 Facades: Los facades proporcionan una interfaz “estática” a las

clases que están disponibles en el contenedor de servicio de la
aplicación. Laravel cuenta con muchos facades que proporcionan
acceso a casi todas las características de Laravel. Los facades sirven
como “proxis estáticos” a las clases subyacentes en el contenedor de
servicio, proporcionando el beneficio de una sintaxis concisa y
expresiva mientras se mantiene más testabilidad y flexibilidad que los
métodos estáticos tradicionales.
 Blade: Blade es el motor de plantillas simple, pero potente
proporcionado con Laravel. A diferencia de otros motores de plantillas
PHP populares, Blade no impide usar código PHP simple en las
vistas. De hecho, todas las vistas de Blade se compilan en código
PHP simple y se almacena en caché hasta que se modifican, lo que
significa que Blade añade esencialmente sobrecarga de cero a la
aplicación. Los archivos de vista de Blade utilizan la extensión de
archivo blade.php y normalmente se almacena en el directorio
resources/views.
 Query Builder: El constructor de consultas de base de datos de
Laravel proporciona una interfaz conveniente y fluida para crear y
ejecutar consultas de base de datos. Se puede utilizar para realizar la
mayoría de las operaciones de base de datos en la aplicación y
28
funciona en todos los sistemas de base de datos compatibles. El
generador de consultas de Laravel utiliza el enlace de parámetros
PDO para proteger su aplicación contra los ataques de inyección
SQL. No hay necesidad de limpiar las cadenas que se pasan como
enlaces.
 Migrations: Las migraciones son como el control de versiones para
la base de datos, lo que permite modificar y compartir fácilmente el
esquema de datos de la aplicación. Las migraciones suelen ser
emparejadas con el constructor de esquema de Laravel para crear
fácilmente el esquema de la base de datos de la aplicación.
 Eloquent: Es un ORM (Object Relational Mapper) incluido en Laravel
que proporciona una implementación de ActiveRecord simple y
hermosa para trabajar con la base de datos. Cada tabla de la base de
datos tiene un “Modelo” correspondiente que se utiliza para
interactuar con esa tabla. Los modelos permiten consultas los datos
en las tablas, así como insertar nuevos registros en la tabla.
29
2.5. Framework Symfony
Figura 5. Framework Symfony.

Fuente. (Symfony, 2017)
Symfony es un completo framework diseñado para optimizar, gracias a sus
características, el desarrollo de aplicaciones Web. Para empezar, separa la
lógica de negocio, la lógica de servidor y la presentación de la aplicación
Web. Proporciona varias herramientas y clases encaminadas a reducir el
tiempo de desarrollo de una aplicación Web compleja. Además, automatiza
las tareas más comunes, permitiendo al desarrollador dedicarse por
completo a los aspectos específicos de cada aplicación. El resultado de
todas estas ventajas es que no se debe reinventar la rueda cada vez que se
crea una nueva aplicación Web.
Symfony está desarrollado completamente con PHP y ha sido probado con

éxito en sitios como Yahoo! Answers, Delicioous, DailyMotion y muchos
otros sitios Web de primer nivel. Symfony es compatible con la mayoría de
gestores de bases de datos, como MySQL, PostgresSQL, Oracle y SQL
Server de Microsoft. Se puede ejecutar tanto en plataformas *nix(Unix, Linux,
etc.) como en plataformas Windows.
La primera versión de Symfony fue publicado en Octubre de 2005 por Fabien

Potencier. En el año 2003, Fabien realizó una investigación sobre las
herramientas de Software libre disponibles para el desarrollo de aplicaciones
Web con PHP. Fabien llegó a la conclusión que no existía ninguna
herramienta con esas características. Después del lanzamiento de la versión
5 de PHP, decidió que las herramientas disponibles habían alcanzado su
30
grado de madurez suficiente como para integrarlas en un framework
completo. Fabien empleo un año entero para desarrollar el núcleo de
Symfony, basando su trabajo en el framework Mojavi (que también era un
framework que seguía el funcionamiento MVC), en la herramienta Propel
para el mapeo de objetos a bases de datos (conocido como ORM, de “object-
relational mapping”) y en los helpers empleados por Ruby on Rails en sus
plantillas.
Fabien desarrolló originalmente Symfony para utilizarlos en los proyectos de

su empresa, ya que disponer de un framework efectivo es la mejor ayuda
para el desarrollo eficiente y rápido de las aplicaciones. Además, el
desarrollo Web se hace más intuitivo y las aplicaciones resultantes son más
robustas y más fáciles de mantener. El framework se utilizó por primera vez
en el desarrollo de un sitio de comercio electrónico para un vendedor de
lencería y posteriormente se utilizó en otros proyectos. Después de utilizar
Symfony en algunos proyectos, Fabien decidió publicarlo bajo una licencia
de software libre. Sus razones para liberar el proyecto fueron para donar su
trabajo a la comunidad. (Francois Zaninotoo).
2.5.2. Instalación
Symfony se diseñó para que se ajuste a los siguientes requisitos:
Tabla 5.
Características de Symfony.
ITEM DESCRIPCIÓN
1 Fácil de instalar y configurar en la mayoría de plataformas (y con la
garantía de que funciona correctamente en los sistemas Windows y *nix
estándares).
2 Independiente del sistema de gestor de bases de datos.
3 Basado en la premisa de “convenir en vez de configurar”, en la que el
desarrollador solo debe configurar aquello que no es convencional.
4 Sigue la mayoría de mejores prácticas y patrones de diseño.
Preparada para aplicaciones empresariales y adaptables a las políticas
5 y arquitecturas propias de cada empresa, además de ser lo suficiente
estable para desarrollar aplicaciones a largo plazo.
6 Fácil de extender, lo que permite su integración con librerías
desarrolladas por terceros.
31
7 La capa de presentación utiliza plantillas y layouts que pueden ser
creados por diseñadores HTML sin ningún tipo de conocimiento del
framework.
8 Los formularios incluyen validación automatizada, lo que asegura la
obtención de datos correctos y mejora la experiencia de usuario.
9 La gestión de la Caché reduce el ancho de banda utilizado y la carga del
servidor.
10 La autenticación y la gestión de credenciales simplifican la creación de
secciones restringidas y la gestión de la seguridad de usuario.
El sistema de enrutamiento y las URL limpias permiten considerar a las
11 direcciones de las páginas como parte de la interfaz, además de estar
optimizadas para los buscadores.
Las interacciones con Ajax son muy fáciles de implementar mediante los
12 helpers que permiten encapsular los efectos JavaScript compatibles con
todos los navegadores en una única línea de código.
Fuente: (Francois Zaninotoo).
2.5.4. Estructura
Una vez instalado Symfony, en el proyecto se observa una jerarquía de
directorios. Esta jerarquía es común a todos los proyectos de Symfony y está
compuesta por las carpetas que muestra a continuación la Figura 15:
Figura 6. Estructura de
directorios de una aplicación en
Symfony.
32
Tabla 6.
Estructura de directorios de una aplicación en Symfony.
DIRECTORIO PROPÓSITO
app/ Contiene los archivos de configuración, la caché, los logs y los
recursos globales.
app/config Guarda todos los archivos de configuración de la aplicación.
app/cache Contiene todos los archivos generados por las numerosas
cachés de Symfony (clases, enrutamiento, plantillas, entidades,
validación, etc.). Junto con el directorio app/logs es el único en
el que Symfony debe tener permisos de escritura.
app/logs Contiene los archivos de logs generados por la aplicación en
cualquier entorno de ejecución (desarrollo, producción, tests,
etc.). Junto con el directorio app/cache es el único en el que
Symfony debe tener permisos de escritura.
app/Resources Almacena los recursos que se utilizan globalmente en el
proyecto (como por ejemplo el layout de las plantillas) o
recursos muy especiales que no encajan en ningún otro sitio
(como por ejemplo una librería para comprimir archivos CSS y
JavaScript).
src Guarda todo el código fuente propio del proyecto. Aquí es
donde se crean los bundles de la aplicación
vendor Contiene todo el código fuente de Symfony y todas las librerías
externas.
web El único directorio público del proyecto. Contiene archivos Web
(CSS, JavaScript, e imágenes) y los controladores frontales de
la aplicación (app.php y app_dev.php).
Fuente: (Eguiluz, 2012).
2.5.5. Componentes
Entre los principales componentes de Symfony cabe destacar los siguientes:
Doctrine: Doctrine es un ORM (Object Relational Mapping), es decir un

mapeador de objetos relacional el cual proporciona una capa de persistencia
para objetos PHP, debido a que se sitúa encima del sistema de gestión de
base de datos. Doctrine tiene un lenguaje propio llamado DQL (Doctrine
Query Language) mediante el cual se pueden realizar consultas sobre
objetos, a diferencia de las consultas SQL que se realizan las consultas
sobre las tablas de la base de datos.
Twig: Twig es un motor y lenguaje de plantillas PHP muy rápido y eficiente

en la generación de vistas, creando un código conciso, fácil de leer y escribir.
Además permite la herencia de plantillas lo cual es de gran ayuda para
determinar un esquema base que pueden llevar todas las plantillas de una
determinada sección del sistema. (Niama Astudillo, 2015) .
33
Cache Component: Este componente se utiliza para almacenar en caché el
contenido arbitrario de una aplicación y así mejorar su rendimiento (Symfony,
2017).
34
2.6. Framework AngularJs
Figura 7. Framework AngularJs

Fuente. (AngularJs, 2016)
AngularJs es una tecnología del lado del cliente, una framework JavaScript
OpenSource desarrollado por Google utilizado principalmente para crear
aplicaciones Web de una sola página; funciona con las tecnologías Web más
asentadas a lo largo del tiempo (HTML, CSS y JavaScript) para hacer el
desarrollo de aplicaciones Web fácil y rápido. El código fuente de AngularJs
está disponible gratuitamente en GitHub bajo la licencia MIT. Esto significa
que cualquier persona puede contribuir y ayudar a su desarrollo.
AngularJs permite construir aplicaciones Web modernas e interactivas

mediante el aumento del nivel de abstracción entre el desarrollador y las
tareas de desarrollo de aplicaciones Web más comunes. Extendiendo del
tradicional HTML con etiquetas propias (directivas), se podría decir que
utiliza el patrón MVC (Model View Controller).
Además AngularJs es compatible con todos los navegadores de última

generación (Chrome, Firefox, Safari, Opera, IE9+) y se puede hacer
compatible con IE8 o anterior mediante varios hacks. (Avilés López , 2014)
2.6.2. Instalación
La Tabla 7 muestra las características principales del framework AngularJs.
35
Tabla 7.
Características principales de AngularJs
CARACTERÍSTICAS DESCRIPCIÓN
MVC bien realizado Normalmente en los frameworks MVC se pide al
desarrollador que escriba el código de una cierta forma
para poder funcionar. Esto supone mucho trabajo.
AngularJs sin embargo gestiona los componentes y los
interconecta de una forma muy sencilla y sin
complicaciones.
HTML para la interfaz Se utiliza el HTML con su sistema de etiquetado
tradicional para la definición de la interfaz gráfica de la
aplicación Web. Mucho más sencillo e intuitivo que
tener que definir toda la UI mediante JavaScript.
Modelos de datos En AngularJs los modelos de datos son JavaScript
POJO Objects (POJO) con lo que no requieren las funciones
extras estilo getters y setters. El código queda limpio y
natural.
Directivas con AngularJs permite añadir funcionalidad extra con
comportamientos nuevas etiquetas HTML, se pueden inventar y definir
propios elementos HTML. Esto es extremadamente
potente, reutilizable y escalable.
Flexibilidad con los De una forma eficiente, cómoda y sencilla se puede
filtros formatear los datos o filtrarlos con una sola línea de
código. Son funciones desarrolladas totalmente
independientes que se encargan de transformar los
datos.
Manipular el DOM en Tradicionalmente (por ejemplo con JQuery)
el controlador manipulamos el DOM añadiendo el comportamiento.
Con AngularJs se separa el comportamiento de
manipular del DOM, de hecho en AngularJs se debe
realizar en las directivas y no en la vista.
Sistema de eventos Sencilla comunicación por mensajes mediante eventos.
Comunicando un particular nodo con sus hijos.
Mediante broadcast() se envía a todos sus hijos
y mediante emit() a todos sus padres.
Unit Testing AngularJs tiene un buen mecanismo de testeo en parte
gracias también a su inyección de dependencias.
Fuente: (Rodriguez, 2014).
2.6.4. Estructura
Cuando se empieza a trabajar con AngularJs uno de los problemas que
rápidamente aparece, es como organizar los diferentes directorios. Sobre
todo cuando la aplicación incrementa su tamaño. Para ese problema existen
varios enfoques posibles (Álvarez, 2015):
36
 Patrón Inline: Es la estructura más sencilla y hace referencia a
cuando los servicios, directivas, controllers y filtros están ubicados en
una etiqueta de “script” dentro de la misma página HTML.
Figura 8. Patrón Inline
Este diseño únicamente es válido para pequeñas pruebas de

iniciación con el framework que sirven de base a asentar
conocimientos.
 Patrón Estereotipo: Cuando la aplicación va creciendo de tamaño

hay que comenzar a organizarla y el enfoque de estereotipos es el
primero que aparece. En él cada fichero de JavaScript almacena un
tipo de elemento.
Figura 9. Patrón Estereotipo
 Patrón Específico: Este patrón es una evolución natural del anterior

y se encarga de organizar estos elementos por carpetas manteniendo
la estructura anterior pero ubicando a cada controlador, servicio, etc.,
en su propio fichero js.
37
Figura 10. Patrón Específico
 Patrón Dominio: Cuando la
aplicación que se desarrolla es de gran tamaño aparece este patrón
en el cual los elementos se agrupan en relación con el dominio al que
pertenecen.
Figura 11. Patrón Dominio
2.6.5. Componentes
 Módulos: Son una pieza fundamental en el desarrollo cotidiano,
sirven para organizar el código en librerías. Se puede decir que los
38
módulos son contenedores de diferentes partes de la aplicación
(controllers, services, filters, directives, etc.).
 Scopes: Los Scopes son un núcleo fundamental de cualquier
aplicación de AngularJs. El objeto scope es donde se define la
funcionabilidad de la aplicación, los métodos en los controladores y
las propiedades en las vistas. Los Scopes sirven de nexo de unión
entre el controlador y la vista, estos guardan la información de los
modelos que se representan en la vista y también atributos que se
utilizan para manejar la lógica de la misma.
 Controladores: Los controladores son los encargados de inicializar y
modificar la información que contienen los Scopes en función de las
necesidades de la aplicación, cuando se crea un nuevo controlador
en una página. Angular le une un nuevo Scope, por lo que solo se
tendrá que realizar la función del constructor.
 Directivas: Las directivas son etiquetas en un elemento del DOM (un
atributo, un nombre de elemento, comentario o clase CSS) que
indican al compilador de HTML de AngularJs ($compile) cuál debe ser
su comportamiento.
 Filtros: Los filtros permiten modificar el modo en el que se va a
presentar la información al usuario. AngularJs cuenta con una gran
cantidad de filtros ya creados para su uso directamente y una
funcionalidad increíble para crear filtros.
 Servicios: Es un objeto JavaScript que permite obtener información.
Estos objetos tienen métodos que sirven para mantener los datos en
el ciclo de vida de la aplicación y se comunican a través de los
controladores de una manera consistente.
 Factorías: Las factorías son como contenedores de código que se
puede usar en las aplicaciones. Son un tipo de servicio, “service”
AngularJs, con el que se implementan librerías de funciones o
almacén de datos.
 Promesas: Una promesa es un método para resolver el valor de una
variable de forma asíncrona. Las promesas son objetos que
representan el valor de retorno o la excepción que retorna finalmente
39
una función; son de gran utilidad cuando se trata con objetos remotos.
Se podría ver desde el punto de vista de que fuesen la proxy de estos
objetos.
 Service $Http: Es un servicio básico de AngularJs que facilita la
comunicación con los servidores HTTP remotos a través del objeto
XMLHttpRequest del navegador o mediante JSONP.
40
2.7. Framework JQuery
Figura 12. Framework JQuery

Fuente. (JQuery, 2016)
JQuery es un framework JavaScript libre y OpenSource, del lado del cliente,
que se centra en la interacción entre el DOM, JavaScript, Ajax y HTML. El
objetivo de esta librería JavaScript es simplificar los comandos comunes de
JavaScript. De hecho, el lema de JQuery es “escribir menos para hacer más”
(Write less, do more).
JQuery, al menos en su origen, es obra de una sola persona: John Resig.
Este joven prodigio de JavaScript desarrolló la primera versión de JQuery en
Enero 2006. En aquel momento tenía solo 20 años. Resig continúa siendo
el motor de JQuery, pero ahora le ayuda una comunidad de apasionados.
(Van Lancker, 2014).
JQuery es software libre y de código abierto, posee un doble licenciamiento
bajo la Licencia MIT y la Licencia Pública General de GNU v2, JQuery, al
igual que otras bibliotecas, ofrece una serie de funcionalidades basadas en
JavaScript que de otra manera requerirán de mucho más código, es decir,
con las funciones propias de esta biblioteca se logran grandes resultados en
menos tiempo y espacio. (Bravo Olmos & Enriquez Solís, 2012).
Además la fundación de JQuery cuenta con otros proyectos:
 JQuery User Interface: Conocido como JQuery UI, es una biblioteca de
componentes para el framework JQuery que le añaden un conjunto de
plug-in, así como efectos visuales con el objetivo de crear aplicaciones
Web amigables e impresionantes para el usuario (JQuery User Interface,
s.f.) .
 QUnit JS Unit Testing: QUnit es un marco potente y fácil de usar
pruebas unitarias. Es usado por JQuery, JQuery UI y proyectos JQuery
41
Mobile y es capaz de probar cualquier código JavaScript genérico (QUnit
JS Unit Testing, s.f.).
 JQuery Mobile: Este framework te permite el desarrollo de aplicaciones
para teléfonos móviles (dispositivos táctiles) (JQuery Mobile, s.f.).
2.7.2. Instalación
A continuación se listan las características más resaltantes de este
framework:
 Licenciar MIT y OpenSource, excelente soporte, actualización

constante.
 Compatibilidad con todos los navegadores.
 Tiene versiones JQuery Mobile.
 Accede al documento HTML (DOM = Document Object Model)
 Manipulación de estilos CSS (Compatibilidad con CSS3).
 Soporta HTML5.
 Excelente integración con AJAX.
 Creación de animaciones y efectos visuales.
 Manejo de eventos para los elementos de la página o aplicación
Web.
 Simplificación de tareas o rutinas comunes de JavaScript.
 Manipulación JavaScript Object Notation (JSON).
 Permite agregar plug-ins compatibles.
 Potencializa al lenguaje JavaScript.
 Multiples plataformas: IOS, Android, Blacberry, Symbian, Windows
Mobile, etc.
2.7.4. Componentes
JQuery Tools es una colección de componentes básicos para interfaz de
usuario que se emplea alrededor del mundo (JQuery Tools, 2017). JQuery
Tools fue creado teniendo como propósito mejorar la usabilidad y respuesta
de sitios web, por ello se emplean diversos componentes que usualmente
42
no se encuentran en otras colecciones de interfaz de usuario. Por ello,
JQuery Tools presenta gran valor para todos los desarrolladores web ya que
permite crear páginas web que se vean bien y que presenten información de
manera adecuada.
Tabla 8.
Componentes de JQuery
Componente Descripción
JQuery Tabs Las pestañas son uno de los elementos más empleados en el
desarrollo Web, pues permite mostrar contenido en una misma
página. JQuery Tabs permite crear pestañas horizontales y
acordeones.
JQuery Tooltip Las anotaciones ayudan a crear una interfaz más amigable ya que
permiten que el usuario pueda visualizar consejos para un mejor uso
y una mejor experiencia. JQuery Tooltip te permite crear anotaciones
(con efectos) grandes y pequeñas.
JQuery Overlay Las superposiciones son parte importante del entorno Web ya que
permiten que el usuario se concentre en un solo elemento. Con
JQuery Overlay se puede crear presentaciones de imágenes y
ventanas de diálogo modal.
JQuery Scrollable Otro componente que se emplea ampliamente en el entorno Web,
ayuda a visualizar contenido o imágenes de manera más interactiva.
JQuery Form Este componente ofrece las herramientas esenciales para construir
formularios para cualquier propósito.
Fuente: (JQuery Tools, 2017)
Elaboración propia
43
Capítulo 3. Metodología
3.1. Tipo de Investigación

El presente trabajo se consideró una investigación de tipo aplicada
experimental, debido a que se puso en práctica los conocimientos que se
adquirieron en esta investigación, y se manipularon las variables de estudio
con el propósito de determinar la veracidad de las hipótesis planteadas.
También se consideró una investigación transversal por que la variable

objeto de estudio fue medida varias veces a lo largo de un periodo de tiempo.
3.2. Tipos y técnicas de muestreo

3.2.1. Universo poblacional
La población de estudio estuvo conformada por empresas e instituciones
públicas y privadas de Piura.
3.2.2. Tamaño de muestra

El tamaño de la muestra fue de 11 empresas e instituciones públicas y
privadas de Piura que se dedican al desarrollo de software o tienen un área
de tecnología de la información, las mismas que se muestran en la Tabla 9.
Tabla 9.
Empresas e Instituciones públicas y privadas
Item Empresa o institución pública o privada

1 Unidad de Gestión Educativa Local – Chulucanas
2 Centro de Informática y Telecomunicaciones (CIT) – Universidad Nacional
de Piura
3 Municipalidad Provincial de Morropón – Chulucanas
4 Municipalidad Distrital de Castilla – Piura
5 Caja Municipal de Paita
6 Caja Municipal de Sullana
7 RENIEC – Piura
8 Municipalidad Provincial de Piura
9 Gobierno Regional de Piura
10 Empresa de desarrollo de Software EnterComp SAC – Piura
11 Súper Intendencia de Administración Tributaria (SUNAT) - Piura
Elaboración propia
44
3.3. Técnicas e instrumentos para la recolección de datos.
Los instrumentos y técnicas que se utilizaron en este trabajo de investigación
son:
3.3.1. Encuesta.
El objetivo de la encuesta es obtener información de las empresas e
instituciones de Piura que se utilizará en este trabajo de investigación (ver
Anexo 3).
3.3.2. Observación.
Esta técnica se utilizó para recolectar los datos que se obtuvieron en el
proceso de comparación de tiempos de ejecución en cada escenario de
prueba.
3.3.3. Guía de observación.

La guía de observación en conjunto con la técnica de la observación permitió
recolectar los datos que se originaron en cada prueba que se realizó. Para
la elaboración de la guía de observación se hizo mediante del diseño
trifactorial completo de 2x2x8 con 4 réplicas (128 combinaciones) (ver Anexo
2).
3.3.4. Software para la simulación de operaciones.

El Software que se utilizó para simular las operaciones en las aplicaciones
que se desarrollaron y tomar los tiempos de ejecución de estas, fue Apache
JMeter.
Figura 13. Software Apache JMeter

Fuente: (The Apache Software Foundation, 2017)
45
Apache JMeter es una herramienta de carga para llevar a cabo simulaciones
sobre cualquier recursos Software.
Inicialmente diseñado para pruebas de estrés en aplicaciones Web, hoy en

día, su arquitectura ha evolucionado no sólo para llevar a cabo pruebas en
componentes habilitados en Internet (HTTP), sino además en Base de datos,
programas de Perl, requisiciones FTP y prácticamente cualquier otro medio.
Además posee la capacidad de realizar desde una solicitud sencilla hasta

secuencia de requisiciones que permiten diagnosticar el comportamiento de
una aplicación en condiciones de producción.
En este sentido, simula todas las funcionalidades de un navegador

(“Browser”), o de cualquier otro cliente, siendo capaz de manipular
resultados en determinada requisición y reutilizarlos para ser empleados en
una nueva secuencia (Osmosis Latina, 2017).
3.4. Validez de la encuesta

Para ofrecer un alto nivel de validez a la encuesta, se solicitó el juicio de un
comité de expertos. Este comité estuvo formado por profesionales con
conocimientos en informática y estadística (ver Anexo 4). La labor del comité
de expertos fue evaluar el cuestionario elaborado, esta evaluación sobre el
contenido, coherencia y el diseño del instrumento en relación al proyecto de
investigación. También se le indicó a los expertos a aportar ideas y
sugerencias sobre el cuestionario elaborado.
3.5. Aplicación de encuesta.

El objetivo de la encuesta fue determinar que módulos o aplicaciones Web
se desarrollan o se utilizan con mayor frecuencia en las empresas de Piura
y alrededores, además de las operaciones que se llevan cabo con más
frecuencia en este módulo, con la finalidad de implementarlo haciendo uso
de las tecnologías que se han seleccionado para este trabajo de
investigación.
La encuesta se aplicó al personal que tiene a cargo los equipos de desarrollo

de software, programadores o jefes del área de tecnología de entidades
46
públicas o privadas. Para poder llevar a cabo esta encuesta se realizó un
muestreo por conveniencia.
El muestreo por conveniencia consiste en seleccionar una muestra de la

población por el hecho de que sea accesible. Es decir, los individuos
empleados en la investigación se seleccionan porque están fácilmente
disponibles, no porque hayan sido seleccionados mediante un criterio
estadístico (Ochoa, 2015).
La elección de empresas o instituciones se llevó acabo de esta manera

debido a que la mayoría si permiten el acceso a su información para fines
académicos.
3.6. Procesamiento de encuesta

3.6.1. Determinación del módulo a implementar
La encuesta se aplicó a las 11 diferentes empresas e instituciones (tamaño
de muestra) que se dedican al desarrollo de Software o tienen un área de
tecnología de la información.
Para determinar el módulo que más se desarrolla o utiliza se realizó la

siguiente pregunta: “En la empresa o centro de trabajo ¿Qué módulo o
aplicación Web con mayor frecuencia se usa o solicita para su desarrollo?”
(ver Anexo 3). En la Figura 14 se muestra los resultados del procesamiento
de respuesta a la pregunta realizada.
47
Módulo de
Módulo de Módulo SIAF Finanzas Módulo de
Contabilidad 6% 7% Lógistica
Módulo de 6% 7%
Recaudación
6% Módulo de
Recursos
Módulo Humanos
Académico 19%
6%
Módulo de
Control de
Iventarios
Módulo de 6%
Módulo de
Trámite
Producción y
Documentario
Fabricación
31%
6%
Figura 14. Resultados del módulo más empleado
Elaboración propia
Como se puede observar en la Figura 14, los encuestados indicaron que el

Módulo de Trámite Documentario (31%) es el que más se usa o desarrolla
en las empresas e instituciones de Piura, seguido del Módulo de Recursos
Humanos (19%). Compartiendo el tercer lugar los Módulos de Finanzas y
Logística (7%) y en cuarto lugar los Módulos de Control de Inventarios,
Producción y Fabricación, Académico, Recaudación y Contabilidad (6%).
Cabe resaltar que estos resultados se obtuvieron debido a que las empresas
e instituciones que se encuestaron son entidades públicas lo que facilitó el
acceso.
De los resultados obtenidos el módulo que se escogió para esta

investigación fue el de Trámite Documentario.
3.6.2. Operaciones más frecuentes

Según el módulo que se eligió, también era necesario saber qué operaciones
se realizan con más frecuencia sobre esté, y para ello se realizó la siguiente
pregunta: “Según el módulo seleccionado, ¿Cuál o cuáles son las
operaciones que con mayor frecuencia los usuarios realizan?” (ver anexo
D), los resultados se reflejan en la Figura 15.
48
Inserción
Másiva
Modificaciones 11%
15% Consultas
37%
Registros
37%
Figura 15. Operaciones más frecuentes

Elaboración propia
Como se puede observar en la Figura 15, los encuestados indicaron que las
operaciones de Consultas y Registros (37%) son las más frecuentes sobre
el módulo que eligieron, seguido de las operaciones de Modificaciones (15%)
e Inserción Masiva (11%).
Las operaciones que se eligieron para simular en el módulo que se

implementó en esta investigación fueron las operaciones de Consultas y
Registros.
3.7. Criterio de selección de frameworks

El criterio que se tomó en cuenta para seleccionar los frameworks utilizados
en esta investigación, fue el criterio de usabilidad. Este criterio es uno de los
10 criterios que se mencionan para la selección de un buen framework para
el desarrollo de aplicaciones, y se encuentra en la página oficial de Symfony
(Framework PHP): “10 criteria for chossing the correct framework” (Symfony,
2017).
3.8. Frameworks a utilizar

Se realizó una comparación de los frameworks más utilizados actualmente
para el desarrollo de aplicaciones Web en los lenguajes de programación
PHP para el lado del servidor, y JavaScript para el lado del cliente, de esta
manera se pudo determinar cuál de estos permite que la aplicación Web
tenga mejores tiempos de ejecución.
49
Teniendo en cuenta que existen múltiples frameworks del lado del cliente y
del lado del servidor, el proceso de selección se realizó tomando como base
un ranking de los frameworks más utilizados.
A continuación, en la Tabla 10 se muestra los frameworks PHP más

utilizados:
Tabla 10.
Frameworks PHP más utilizados
15 MEJORES FRAMEWORKS PHP UTILIZADOS - 2015

Framework Porcentaje
Laravel 23%
Symfony 15%
CodeIgniter 14%
CakePhp 9%
Zend 8%
Phalcon 8%
Slim 7%
Yii 7%
FatFree 2%
Kohana 2%
FuelPHP 2%
PHP – Mini 1%
Zikuda 0%
Fuente: Irfan Fauzi, 2015
Elaboración propia
Como se puede observar en la Tabla 10 se muestran los 15 mejores

frameworks en el lenguaje de programación PHP, se observa que los
frameworks que ocupan los primeros lugares son Laravel con 23% y
Symfony con 15%, los que se escogieron para esta investigación.
50
En la Tabla 11 se muestra los frameworks JavaScript más utilizados.
Tabla 11.
Frameworks JavaScript más utilizados
FRAMEWORKS JAVASCRIPT MÁS UTILIZADOS

Framework Porcentaje
JQuery 31%
AngularJs 22%
BackBone 16%
NodeJs 14%
ExtJs 6%
Ember 5%
Knockout 4%
RequireJs 2%
Fuente: WebSite Site24x7, 2015.
Elaboración propia
Se observa que en la Tabla 11 muestra los frameworks más utilizados en el

lenguaje de programación JavaScript, donde JQuery y AngularJs ocupan los
primeros lugares con 31% y 22% respectivamente, los que se escogieron
para esta investigación.
También para la elección de los frameworks a utilizar en esta investigación

se tomó como base las búsquedas que se realizan a nivel mundial de los
diferentes frameworks para el desarrollo Web. A continuación se muestran
las índices de búsqueda en el año 2016 a nivel mundial de los frameworks
del lado del cliente y del lado del servidor.
La Figura 16 muestra los índices de búsquedas de los frameworks PHP

conocidos:
Figura 16. Índices de búsquedas de Frameworks PHP

Fuente: (Google Trends, 2016)
51
Como se puede observar en la Figura 16, los frameworks PHP que más se
han buscado en el año 2016 son Laravel y Symfony.
La Figura 17 muestra los índices de búsquedas de los frameworks

JavaScript conocidos:
Figura 17. Índices de búsqueda de Frameworks JavaScript

Fuente: (Google Trends, 2016)
Como se puede observar en la Figura 17, los frameworks JavaScript que

más se han buscado en el año 2016 son AngularJs y JQuery.
3.9. Criterios de comparación

Para determinar el criterio de comparación a utilizar se recurrió a diferentes
bibliografías que guardan relación con la presente investigación.
En la Tabla 12 se mencionan las bibliografías, y los criterios que tomaron en

cuenta para llevar cabo sus investigaciones.
Tabla 12.
Trabajos de investigación y criterios de evaluación
Bibliografía Criterios de Comparación

(Arcos Chalán &  Número de líneas de código
 Tiempo de respuesta del sistema
Chicaiza Inguillay, 2016)
 Manejo de seguridad
 Lenguaje
 Documentación
 Curva de aprendizaje
(Guerrero & Recaman,  Compatibilidad con base de datos
 Validación de datos en el cliente
2009)
 Soporte para AJAX
 Módulos para presentación de datos
 Utilidades gráficas
 General: madurez del framework, soporte y
documentación del framework, tipo de
licenciamiento.
52
 Funcionalidad: definición de metadatos, facilidad de
generación de consultas (Queries), control de
transacciones y concurrencias.
(Suarez Silva, 2011)  Rendimiento: Tiempo de ejecución de operaciones
CRUD (Create, Read, Update y Delete).
 Recursos: Requerimientos de hardware y software
para el desarrollo, costo de desarrollo.
 Facilidades para el desarrollo: curva de aprendizaje,
herramientas de desarrollo.
(Callejas Cuervo,  Tiempo empleado en la ejecución de determinadas
instrucciones.
Peñalosa Parra , &
 Memoria RAM consumida en la ejecución de
Alarcón Aldana, 2011) algunas instrucciones
 Uso de GarbageCollector
 Ingeniería de carga: CPU%, Memoria%.
 Línea base: ancho de banda de subida, ancho de
(Sánchez Osejo & Vera
banda de bajada.
Cárdenas, 2011)  Carga transaccional: número de peticiones
ejecutadas, tiempo de respuesta.
 Integridad: éxitos y fallos.
Elaboración propia.
De las bibliografías anteriores se puede determinar que el criterio de

comparación que se utilizó con mayor frecuencia es el “tiempo de ejecución”.
En la Tabla 13 se muestra el criterio y unidades seleccionado para la
evaluación.
Tabla 13.
Criterio de comparación y unidades seleccionadas para la evaluación.
Criterio Unidades
Tiempo empleado en la ejecución de determinadas Milisegundos
instrucciones
Elaboración propia
3.10. Generar data de prueba

Para generar datos de prueba que simularon el comportamiento de las
aplicaciones desarrolladas, fue necesario recurrir a instituciones que
brindaran la información necesaria de los datos que se generan en el
Sistema de Trámite Documentario en un determinado año. La institución que
brindó la información requerida fue la Municipalidad Provincial de Paita en
coordinación con la Sub Gerencia de Informática y Sistemas, la información
que se obtuvo se presenta a continuación en la Tabla 14.
53
Tabla 14.
Resumen de Expedientes Internos y Externos registrados en el año 2016.
MUNICIPALIDAD PROVINCIAL DE PAITA

(Sub Gerencia de Informática y Sistemas)
CUADRO RESUMEN DE LOS EXPEDIENTES INTERNOS Y EXTERNOS REGISTRADOS EN
EL AÑO 2016
Expedientes Externos Expedientes Internos
MES CANTIDAD MES CANTIDAD
Enero 1876 Enero 1374
Febrero 2087 Febrero 1501
Marzo 2463 Marzo 1829
Abril 2352 Abril 1481
Mayo 2607 Mayo 1618
Junio 2259 Junio 1564
Julio 2221 Julio 1532
Agosto 2856 Agosto 1513
Septiembre 2047 Septiembre 1595
Octubre 2434 Octubre 1319
Noviembre 2367 Noviembre 1469
Diciembre 2125 Diciembre 1681
Total 27694 Total 18476
Fuente: Sub Gerencia de Informática y Sistema - Municipalidad Provincial de Paita
En la Tabla 14 se muestran los expedientes internos y externos registrados

en el año 2016 distribuidos por mes. A partir de esta información se generó
los datos que se utilizaron para simular las operaciones de consultas y
registros en las aplicaciones desarrolladas.
En la Tabla 15 se muestran los meses en que se registraron la mayor

cantidad de trámites internos y externos en los días laborables, esto permitió
obtener la cantidad de trámites registrados diariamente y así generar data
de prueba.
Tabla 15.
Meses que tienen la mayor cantidad de expedientes internos y externos
registrados – Año 2016.
EXPEDIENTES REGISTRADOS
TIPO DE MES CANTIDAD DIAS CANTIDAD DE
EXPEDIENTES LABORABLES EXPEDIENTES DIARIOS
Externos Agosto 2856 22 129

Internos Marzo 1829 24 76
Fuente: Sub Gerencia de Informática y Sistema de la Municipalidad Provincial de Paita
54
Cabe señalar que para realizar la simulación en esta investigación, se
generaron datos para los 12 meses del año 2017 repartidos solo para las
bandejas (recibidos, enviados, recepcionados, finalizados) en las diferentes
unidades (Informática y Sistemas, Mesa de Partes, Rentas, Logística,
Catastro, Gerencia, Contabilidad, Administración, Almacén, Imagen
Institucional, Registro Civil, Obras, Recursos Humanos y Patrimonio), en la
Tabla 16 se muestra las cantidades de datos generados.
Tabla 16.
Cantidades de datos generados para la simulación.
Mes Días Externos Total Internos Total Total de

Laborables Externos Internos Trámites
Enero 22 129 2838 76 1672 4510
Febrero 20 129 2580 76 1520 4100
Marzo 23 129 2967 76 1748 4715
Abril 20 129 2580 76 1520 4100
Mayo 23 129 2967 76 1748 4715
Junio 22 129 2838 76 1672 4510
Julio 22 129 2838 76 1672 4510
Agosto 23 129 2967 76 1748 4715
Setiembre 21 129 2709 76 1596 4305
Octubre 22 129 2838 76 1672 4510
Noviembre 22 129 2838 76 1672 4510
Diciembre 21 129 2709 76 1596 4305
Total 53505
Fuente: Elaboración propia
Para el llenado de la base de datos se utilizó se utilizó una herramienta

llamada Faker. Faker es una librería de PHP que genera datos de prueba,
ya sea que se necesite inicializar una base de datos, crear documentos XML,
etc. Faker está inspirado en Data::Faker de Perl y en el Faker de Ruby
(GitHub, s.f.).
3.11. Ambiente para el desarrollo y simulación:

En la Tabla 17 se muestra los recursos que se utilizaron durante el proceso
de desarrollo y simulación de las aplicaciones desarrolladas.
55
Tabla 17.
Recursos para el desarrollo y simulación de operaciones de las aplicaciones
desarrolladas.
Procesos HARDWARE SOFTWARE

1 Laptop HP Pavilion g4 IDE Sublime Text 3
1084la XAMPP v5.6.24
Procesador Intel(R) MySQL
Desarrollo de Core(TM) i3-2310M CPU Framework Laravel
aplicaciones 2.10GHz Framework Symfony
Memoria RAM 3GB Framework AngularJs
Sistema Operativo Framework JQuery
Windows 7 Home Basic 64 GitKraken
bits Google Chrome
ConEmu (x64)
1 Laptop HP Pavilion g4
Simulación 1084la
de Procesador Intel(R) XAMPP v5.6.24
operaciones Core(TM) i3-2310M CPU Apache JMeter (3.1 r1770033)
y toma de 2.10GHz
tiempos Memoria RAM 3GB
Sistema Operativo
Windows 8 64 bits
Elaboración propia
56
Capítulo 4. Caso de estudio: Sistema de Trámite Documentario
Para llevar a cabo esta investigación se realizó el desarrollo del módulo de
Trámite Documentario, el cual según la encuesta realizada es el más
empleado o desarrollado por las empresas de Piura, además solo se
implementaron las operaciones más frecuentes resultantes en la encuesta
aplicada.
4.1. Trámite Documentario.

Trámite Documentario es un aplicación que permite a las organizaciones
tener el control de la ubicación física y estatus, actual y pasado de la
documentación que llega, fluye y se genera dentro de ellas; y en base a estos
datos mostrar estadísticas que permitan analizar pasos repetitivos o que no
agreguen valor y los cuellos de botella para mejorar los flujos de los
documentos dentro de la organización (Santa Maria Loza, 2010).
La Figura 18 muestra el proceso que se realiza para tramitar un documento

en una organización.
57
Figura 18. Proceso de trámite documentario en una organización
Fuente: (Calmet Izquierdo, 2014)
58
4.2. Obtención de requerimientos.
4.2.1. Requerimientos funcionales
A continuación en la Tabla 18 se detallan los requerimientos
asociados al proceso de trámite documentario.
Tabla 18.
Requerimientos funcionales
ITEM REQUERIMIENTOS
RF01 El sistema permitirá a los usuarios consultar la bandeja de
expedientes enviados.
expedientes recibidos.
expedientes recepcionados.
expedientes finalizados.
RF05 El sistema permitirá a los usuarios ver los movimientos de un
expediente mediante el número de expediente y tipo de trámite.
RF06 El sistema permitirá al solicitante consultar el movimiento de sus
expedientes mediante el número de expediente.
RF07 El sistema permitirá generar un reporte diario de los expedientes
externos recepcionados por mesa de partes.
RF08 El sistema permitirá a los usuarios registrar un trámite ya sea de
tipo externo o interno.
Elaboración propia
4.2.2. Especificaciones de los requerimientos.

Tabla 19.
Especificación del requerimiento RF01
Consulta de bandeja de expedientes enviados

Actor Mesa de Parte, Jefe de Unidad
Descripción El sistema permite a los usuarios consultas los
expedientes enviados.
Flujo básico Los usuarios ingresan a la opción bandeja de enviados, se
muestra una pantalla donde se listan los expedientes
enviados.
Flujos No se han registrado trámites
alternos El sistema muestra en pantalla un mensaje indicando que
no hay expedientes enviados.
Pre- Los usuarios deben haber ingresado a la opción bandeja
condiciones enviados.
Post- El sistema muestra una lista de los expedientes enviados
condiciones por la oficina.
Elaboración propia
59
Tabla 20.
Consulta de bandeja de expedientes recibidos

Descripción El sistema permite a los usuarios consultas los
expedientes recibidos.
Flujo básico Los usuarios ingresan a la opción bandeja de recibidos, se
recibidos.
Flujos No se han derivados trámites
no hay expedientes recibidos.
condiciones recibidos.
Post- El sistema muestra una lista de los expedientes recibidos.
condiciones
Elaboración propia
Tabla 21.
Consulta de bandeja de expedientes recepcionados

Descripción El sistema permite a los usuarios consultar los
expedientes recepcionados.
Flujo básico Los usuarios ingresan a la opción bandeja de recibidos, se
recibidos.
Flujos No se han recepcionado expedientes
no hay expedientes recepcionados.
condiciones recepcionados. El usuario debe haber recepcionado
expedientes.
Post- El sistema muestra una lista de los expedientes
condiciones recepcionados.
Elaboración propia
Tabla 22.
Consulta de bandeja de expedientes finalizados

Descripción El sistema permite a los usuarios consultar los
expedientes finalizados.
Flujo básico Los usuarios ingresan a la opción bandeja de finalizados,
se muestra una pantalla donde se listan los expedientes
finalizados.
Flujos No se han finalizado expedientes
no hay expedientes finalizados.
60
condiciones finalizados. El usuario debe haber finalizado expedientes.
Post- El sistema muestra una lista de los expedientes
condiciones finalizados.
Elaboración propia
Tabla 23.
Especificación de requerimiento RF05
Consultar movimientos de un expediente interno

Descripción El sistema permite a los usuarios ver los movimientos de
un determinado expediente de tipo interno o externo.
Flujo básico El solicitante ingresa a la opción ver movimientos. Se
muestra una pantalla donde indica que ingrese el número
de expediente y tipo de trámite, el usuario ingresa los
datos y presiona el botón buscar.
Flujos No se encuentra registrado el número de expediente
alternos El sistema muestra en pantallas un mensaje indicando
que el expediente buscado con el número de expediente
ingresado o tipo de trámite no se encuentra.
Pre- Los usuarios deben haber accedido a la opción ver
condiciones movimientos.
Post- El sistema debe mostrar los movimientos del expediente
condiciones buscado.
Elaboración propia
Tabla 24.
Consultar los movimientos de un expediente externo

Actor Solicitante
Descripción El sistema permite al solicitante o remitente ver los
movimientos de un determinado expediente.
Flujo básico El solicitante ingresa a la página de consultas de
expedientes. Se muestra una pantalla donde indica que
ingrese el número de expediente, el solicitante ingresa los
datos y presiona el botón buscar.
Flujos No se encuentra registrado el número de expediente
alternos El sistema muestra en pantallas un mensaje indicando
que el expediente buscado con el número de expediente
ingresado no se encuentra.
Pre- El solicitante debe haber accedido a la página de
condiciones consultas de expediente.
Post- El sistema debe mostrar los movimientos del expediente
condiciones buscado.
Elaboración propia
61
Tabla 25.
Reporte diario de los expedientes externos recepcionados

Actor Mesa de Parte
Descripción El sistema permite generar un reporte diario de los
expediente de tipo externo que se han registrado.
Flujo básico El usuario ingresa a la opción reporte diario, se muestra
en pantallas un listado de los trámites de tipo externo
registrados en el día, el usuario presiona el botón de
exportar.
Flujos No hay tramites registrados
alternos El sistema muestra en pantalla que no se han registrado
trámites.
Pre- El usuario debe haber accedido a la opción reporte diario.
condiciones
Post- Se genera satisfactoriamente un reporte en formato
condiciones específico.
Elaboración propia
Tabla 26.
Registrar tramite
Actor Mesa de parte, Jefe de Unidad
Descripción El sistema permitirá registrar un trámite ya se de tipo
externo o interno.
Flujo básico Los usuarios acceden a la opción registrar tramite,
se muestra una pantalla donde sebe indicar el tipo
de trámite, remitente o solicitante, folios, asunto,
acción, unidad y prioridad. El usuario llena todos los
datos y presiona el botón de registrar.
Flujos Solicitante o remitente no se encuentra
alternos registrado
El sistema muestra un mensaje indicando que no se
encuentra el solicitante buscado.
Pre- El usuario debe haber accedido a la opción registrar
condiciones expediente.
Post- El sistema debe mostrar de confirmación indicando
condiciones que el trámite se ha registrado correctamente.
Elaboración propia
4.3. Diagramas
4.3.1. Diagrama de Negocio.
Un modelo de negocio describe los procesos del negocio en términos
de casos de uso y actores que corresponden a procesos del negocio
62
y trabajadores. A continuación en la Figura 19 muestra el modelo de
negocio correspondiente al proceso de trámite documentario.
Figura 19. Modelo de caso de uso de negocio

Fuente: Elaboración propia
4.3.1.1. Actores de Negocio.

A continuación se describen los actores de negocio
encontrados en la Figura 19.
Tabla 27.
Actores de negocio
Nombre Descripción
Solicitante Persona natural o jurídica, que se acerca a la
entidad a realizar cualquier trámite. Del mismo
modo, las unidades pueden comportarse como
solicitante al emitir un pedido a otra unidad, a esto
se le considera trámite interno.
Mesa de Usuario encargado de la recepción, registro y
Partes derivación de expediente.
Jefe de Usuario de gestionar los expedientes que recibe en
Unidad su unidad.
Elaboración propia
4.3.2. Diagramas de Casos de uso

Los casos de uso son la descripción de los pasos o actividades que
deberían realizarse para llevar a cabo algún proceso. Teniendo en
cuenta el modelo de negocio de la Figura 19, se ha elaborado los
casos de uso siendo estos divididos entre dos procesos o escenarios
principales:
 Gestión de expedientes.
 Control y monitoreo de expedientes.
63
 Gestión de expedientes
Figura 20. Caso de Uso de Gestión de Expedientes.

Elaboración Propia
 Control y monitoreo de expedientes
Figura 21. Caso de Uso de Control y Monitoreo de expedientes.

Elaboración propia
64
4.3.3. Diagramas de Secuencia
 Gestión de expedientes
1. Registrar tramite
Figura 22. Diagrama de Secuencia - Registrar trámite


1. Consultar bandeja expedientes enviados
Figura 23. Diagrama de Secuencia - Bandeja expedientes enviados

Elaboración propia
65
2. Consultar bandeja expedientes recibidos
Figura 24. Diagrama de Secuencia - Bandeja expedientes recibidos

Elaboración propia
3. Consultar bandeja expedientes recepcionados
Figura 25. Diagrama de secuencia - Bandeja expedientes recepcionados

Elaboración propia
66
4. Consultar bandeja expedientes finalizados
Figura 26. Diagrama de Secuencia - Bandeja expedientes finalizados

Elaboración propia
5. Consultar movimientos de expediente
Figura 27. Diagrama de Secuencia - Consultar movimientos de expediente

Elaboración propia
67
6. Consultar movimientos de expedientes del solicitante
Figura 28. Diagrama de Secuencia - Consultar movimientos de expedientes del solicitante

Elaboración propia
7. Generar reporte diario
Figura 29. Diagrama de Secuencia - Generar reporte diario

Elaboración propia
68
4.3.4. Diagramas de Colaboración
Los diagramas de colaboración son un tipo de diagrama de
interacción cuyo objetivo es describir el comportamiento dinámico del
sistema de información mostrando cómo interactúan los objetos entre
sí, es decir, con que otros objetivos tienen vínculos o intercambia
mensajes un determinado objeto.
 Gestión de expedientes
1. Registrar trámite
Figura 30. Diagrama de Colaboración - Registrar trámite

Elaboración propia

1. Consultar bandeja expedientes enviados
Figura 31. Diagrama de Colaboración - Consultar bandeja expedientes enviados

Elaboración propia
69
2. Consultar bandeja expedientes recibidos
Figura 32. Diagrama de Colaboración - Consultar bandeja de expedientes recibidos

Elaboración propia
3. Consultar bandeja expedientes recepcionados
Figura 33. Diagrama de Colaboración – Consulta bandeja de expedientes recepcionados

Elaboración propia
70
4. Consultar bandeja expedientes finalizados
Figura 34. Diagrama de Colaboración - Consultar bandeja de expedientes finalizados

Elaboración propia
5. Consultar movimientos de expediente
Figura 35. Diagrama de Colaboración - Consultar movimientos de expediente

Elaboración propia
71
6. Consultar movimientos de expedientes del solicitante
Figura 36. Diagrama de Colaboración - Consultar movimientos de expedientes del solicitante

Elaboración propia
7. Generar reporte diario
Figura 37. Diagrama de Colaboración - Generar reporte diario

Elaboración propia
72
4.3.5. Diagrama de Clases
Los diagramas de clases son diagramas de estructura estática que
muestran las clases del sistema y sus interrelaciones (incluyendo
herencia, agregación, asociación, etc.). Los diagramas de clases son
el pilar básico del modelado UML, siendo utilizados tanto para mostrar
lo que el sistema puede hacer (análisis), como para mostrar cómo
puede ser construido (diseño). El diagrama de clases de más alto
nivel, será lógicamente un dibujo de los paquetes que componen el
sistema. Las clases se documentan con una descripción de lo que
hacen, sus métodos y sus atributos. Las relaciones entre clases se
documentan con una descripción de su propósito, sus objetivos que
intervienen en la relación y su opcionalidad.
73
Figura 38. Diagrama de Clases
Elaboración propia
74
4.3.6. Diagramas de Componentes
Los Diagramas de Componentes ilustran las piezas del software,
controladores embebidos, etc., que conformarán un sistema. Un
Diagrama de Componentes tiene un nivel más alto de abstracción que
un diagrama de clases, usualmente un componentes se implementa
por una o más clases (u objetos) en tiempo de ejecución. Estos son
bloques de construcción, como eventualmente un componente puede
comprender una gran porción de un sistema.
Figura 39. Diagrama de Componentes - Laravel y AngularJs

Elaboración propia
Figura 40. Diagrama de Componentes - Laravel y JQuery

Elaboración propia
75
Figura 42. Diagrama de Componente - Symfony y AngularJS
Elaboración propia
Figura 41. Diagrama de Componente - Symfony y JQuery

Elaboración propia
76
Capítulo 5. Presentación, análisis y discusión de resultados
5.1. Presentación de resultados

A continuación se muestran los resultados de los tiempos de ejecución obtenidos
en la simulación de las aplicaciones desarrolladas en los diferentes marcos de
trabajo del lado del cliente y del lado del servidor seleccionados para esta
investigación.
Cabe señalar que la cantidad de datos con que se realizó cada prueba, son aquellos
que se distribuyeron para cada unidad.
En la Tabla 28 se muestran los tiempos promedios de ejecución obtenidos en cada

prueba ejecutada.
77
Tabla 28.
Tiempos promedios de ejecución obtenidos en cada prueba ejecutada.
Lado del Cliente (JavaScript)
AngularJs JQuery
MARCOS Operaciones Operaciones

DE
TRABAJO Consultas Consultas
(FRAMEWOR Expedientes Reporte Registro Expedientes Reporte Registro
KS) Bandeja (Trámites) Bandeja (Trámites)
(Movimientos) (Trámites) (Movimientos) (Trámites)
Recepciona Reporte Recepciona Reporte
Enviados Finalizados Recibidos Interno Externo Enviados Finalizados Recibidos Interno Externo
dos Diario Trámite dos Diario Trámite
(256) (1405) (1605) (5) (5) (256) (1405) (1605) (5) (5)
(556) (129) (556) (129)
2164 3900 5944 9300 2838 1145 5349 1409 9002 18619 25756 48400 1140 906 4716 1322
Laravel
Lado del Servidor
2267 4250 5804 9376 1044 920 4828 1162 9011 18275 26392 42618 616 600 4546 561
2337 4288 5388 9207 946 776 4985 941 8530 18044 26145 41780 639 567 4283 492
(PHP)
2300 4290 5660 8674 967 838 4836 1222 8443 18516 26006 42466 687 560 4224 566
4978 7353 8793 20098 4471 4094 6106 4103 5182 7540 8787 21275 4102 3957 5054 3352
Symfony
5132 7338 8781 11640 3906 4086 5131 3846 5168 7014 8702 12105 3666 3711 4909 3198
5107 7009 8666 12164 3798 3684 5099 3698 5345 7692 8689 11827 3854 3766 4729 3056
5284 6911 8568 11569 4064 3663 4884 3696 5704 7490 8683 11739 3499 3743 5128 3135
Elaboración propia
 Guía de observación. Diseño Trifactorial de 2x2x8 – N° de réplicas: 4 (128 combinaciones).

 Variable de respuesta: Tiempo de ejecución (milisegundos).
 Factores: Frameworks (Lado del Cliente y Lado del Servidor), Operaciones.
78
La cantidad de usuarios para realizar las pruebas y simulación de operaciones del
sistema de trámite documentario fue de 14, que representan a los jefes de las 14
unidades empleadas para la simulación. Además el resultado en cada prueba o
combinación es el promedio de los tiempos de ejecución de los 14 usuarios, este
dato lo provee el software Apache JMeter cuando se realizaron las pruebas.
79
5.2. Análisis de resultados
El análisis estadístico de los resultados obtenidos se llevó a cabo empleando el
análisis de varianza de dos factores con varias muestras por grupo para cada
operación que se realizó en las pruebas de simulación del sistema desarrollado.
Datos para el análisis: La Tabla 28 muestra los datos que se utilizaron para llevar
a cabo el análisis estadístico de los resultados obtenidos de los promedios de los
tiempos de ejecución de cada operación que se simularon para el sistema
desarrollado.
Tabla 29.
Datos para el análisis estadístico de resultados.
Item Descripción
Factor A: Frameworks para el lado del servidor.
Factor B: Frameworks para el lado del cliente.
Variable respuesta o Variable dependiente Tiempo de ejecución de cada operación.
(Efecto):
N° de réplicas o repeticiones de la prueba: n=4
N° de niveles del factor A: a=2
N° de niveles del factor B: b=2
N° total de observaciones realizadas: N= 16
Diseño experimental utilizado para el análisis: Diseño Bifactorial 2x2
Nivel de Significancia (alfa): 5%
Elaboración propia
Prueba de Hipótesis: En las Tablas 30 y 31 se muestran las pruebas de hipótesis

que se utilizaron para el análisis estadístico de los resultados obtenidos.
Tabla 30.
Prueba de Hipótesis respecto al efecto de los factores principales
RESPECTO AL EFECTO DE LOS FACTORES PRINCIPALES

Factores Hipótesis
H0: No existe diferencia significativa en el TIEMPO DE EJECUCION
DE CADA OPERACIÓN ocasionada por el TIPO DE FRAMEWORK
PARA EL LADO DEL SERVIDOR UTILIZADO, es decir, su efecto es
Factor A: Frameworks para el
igual a cero.
lado del servidor H1: Existe diferencia significativa en el TIEMPO DE EJECUCION DE
CADA OPERACIÓN ocasionada por el TIPO DE FRAMEWORK PARA
EL LADO DEL SERVIDOR UTILIZADO, es decir, su efecto es diferente
a cero.
80
DE LA OPERACIÓN ocasionada por el TIPO DE FRAMEWORK PARA
EL LADO DEL CLIENTE UTILIZADO, es decir, su efecto es igual a
Factor B: Frameworks para el
cero.
lado del cliente H1: Existe diferencia significativa en el TIEMPO DE EJECUCION DE
CADA OPERACIÓN ocasionada por el TIPO DE FRAMEWORK PARA
EL LADO DEL CLIENTE UTILIZADO, es decir, su efecto es diferente
a cero.
Elaboración propia
Tabla 31.
Prueba de Hipótesis respecto a la interacción de los factores principales.
RESPECTO A LA INTERACCIÓN DE LOS FACTORES PRINCIPALES

Interacción Hipótesis
DE CADA OPERACIÓN ocasionada por la interacción de los Factores
FRAMEWORKS PARA EL LADO DEL SERVIDOR y
FRAMEWORKS PARA EL LADO DEL CLIENTE, es decir, cuando los
Interacción AB dos factores actúan de forma conjunta su efecto es igual a cero.
H1: Existe diferencia significativa en el TIEMPO DE EJECUCION DE
CADA OPERACIÓN ocasionada por la interacción de los Factores
FRAMEWORKS PARA EL LADO DEL SERVIDOR y
FRAMEWORKS PARA EL LADO DEL CLIENTE, es decir, cuando los
dos factores actúan de forma conjunta su efecto es diferente a cero.
Elaboración propia
Conclusión: Cuando el valor de “F Calculado” es mayor que el valor de “F DE

Tabla”, se rechaza H0.
81
A continuación se muestra el análisis varianza (ANOVA) por cada operación
simulada en la aplicación Web desarrollada:
 Operación 1: Consultar bandeja de documentos enviados – Cantidad de

registros: 256
Tabla 32.
Tiempos promedio de ejecución – Operación 1.
Lado del Cliente

Frameworks
Angular JS JQuery
2164 9002
Laravel 2267 9011
2337 8530
Lado del 2300 8443
Servidor 4978 5182
Symfony 5132 5168
5107 5345
5284 5704
Elaboración propia
Fuente: Guía de observación
Tabla 33.
Análisis de Varianza de los tiempos de ejecución para la Operación 1.
FUENTE DE VARIACIÓN SC GL MC F F TABLA Conclusión

CALCULADO ALFA = 5%
Factor A: Framework 289982.25 1 289 982.25 6.631 4.747 Rechaza Ho
del lado del servidor
Factor B: Framework 44943616 1 44 943 616 1027.724 4.747 Rechaza Ho
del lado del cliente
Interacción AB 39125025 1 39125025 894.670 4.747 Rechaza Ho
ERROR 524774.5 12 43731.20833

TOTAL 84883397.75 15
Elaboración propia
Fuente: Análisis de Varianza (ANOVA)
En la Tabla 33 se muestra el análisis de varianza para la operación 1, donde se

busca demostrar si los frameworks del lado del servidor y los del lado del cliente
afectan significativamente sobre el tiempo de ejecución de la operación que se está
evaluando.
En dicha tabla se observa que el framework del lado del cliente produce una mayor
variabilidad en el tiempo de ejecución (2=44 943 616). Además se comprueba que
al 5% de nivel de significancia, tanto el framework del lado del servidor (Fc=6.631)
y el framework del lado del cliente (Fc=1027.724), actuando de manera
independiente, afectan significativamente al tiempo de ejecución de la operación 1,
y lo mismo sucede con la interacción de ambos factores (Fc=894.670), cuyo mayor
82
aporte en dicha variabilidad lo tienen los frameworks del lado del cliente; con lo que
se concluye que se rechazan las Hipótesis nulas formuladas en las tablas 30 y 31.
 Operación 2: Consulta - bandeja de documentos recepcionados –

Cantidad de registros 556.
Tabla 34.
Lado del Cliente

Frameworks
Angular JS JQuery
3900 18619
Laravel 4250 18275
4288 18044
Lado del 4290 18516
Servidor 7353 7540
Symfony 7338 7014
7009 7692
6911 7490
Tabla 35.
Análisis de Varianza de los tiempos de ejecución para la Operación 2.

CALCULADO ALFA = 5%
Factor A: Framework 63341701.56 1 63341701.56 1061.062 4.747 Rechaza Ho
Factor B: Framework 209171137.6 1 209171137.6 3503.910 4.747 Rechaza Ho
Interacción AB 193216950.1 1 193216950.1 3236.655 4.747 Rechaza Ho
ERROR 716357.75 12 59696.47917

TOTAL 466446146.9 15
Elaboración propia

busca demostrar que si los frameworks del lado del cliente y frameworks del lado
del servidor afectan significativamente al tiempo de ejecución de la operación que
se está evaluando.
Se observa que en dicha tabla los frameworks del lado del cliente ocasionan una
mayor variabilidad en el tiempo de ejecución (2=209171137.6). Además se
comprueba que al 5% de nivel de significancia, tantos los frameworks del lado del
servidor (Fc=1061.062) y frameworks del lado del cliente (Fc=3503.910), actuando
de manera independiente, afectan significativamente al tiempo de ejecución de la
operación 2, y lo mismo sucede en la interacción de ambos factores (Fc=3236.655)
83
cuyo mayor aporte en dicha variabilidad lo produce los frameworks del lado del
cliente; con lo que se concluye que se rechazan las Hipótesis nulas formuladas en
las tablas 30 y 31.
 Operación 3: Consulta - bandeja de documentos finalizados – Cantidad de

registros: 1405
Tabla 36.
Tiempos promedio de ejecución – Operación 3
Lado del Cliente

Frameworks
Angular JS JQuery
5944 25756
Laravel 5804 26392
5388 26145
Lado del 5660 26006
Servidor 8793 8787
Symfony 8781 8702
8666 8689
8568 8683
Elaboración propia
Tabla 37.
Análisis de Varianza de los tiempos de ejecución para la Operación 3

CALCULADO ALFA = 5%
Factor B: Framework 415711321 1 415711321 11820.348 4.747 Rechaza Ho
Interacción AB 414631406.3 1 414631406.3 11789.642 4.747 Rechaza Ho
ERROR 422029.5 12 35169.125

TOTAL 1036873849 15
Elaboración propia

se está evaluando.
Se observa que en dicha tabla los frameworks del lado del cliente ocasionan una
mayor variabilidad en el tiempo de ejecución (2=415711321). Además se
servidor (Fc=5860.512) y los frameworks del lado del cliente (Fc=11820.348),
84
actuando de manera independiente, afectan significativamente al tiempo de
ejecución de la operación 3, y lo mismo sucede en la interacción de ambos factores
(Fc=11789.642) cuyo mayor aporte en dicha variabilidad lo produce los frameworks
del lado del cliente; con lo que se concluye que se rechazan las Hipótesis nulas
formuladas en las tablas 30 y 31.
 Operación 4: Consultar bandeja de trámites recibidos – Cantidad de

registros: 1605.
Tabla 38.
Lado del Cliente

Frameworks
Angular JS JQuery
9300 48400
Laravel 9376 42618
9207 41780
Lado del 8674 42466
Servidor 20098 21275
Symfony 11640 12105
12164 11827
11569 11739
Elaboración propia
Tabla 39.
FUENTE DE SC GL MC F F TABLA Conclusión

VARIACIÓN CALCULADO ALFA = 5%
Factor A: 617572201 1 617572201 50.478 4.747 Rechaza Ho
Framework del
lado del servidor
Factor B: 1228187070 1 1228187070 100.388 4.747 Rechaza Ho
Framework del
lado del cliente
Interacción AB 1177038864 1 1177038864 96.207 4.747 Rechaza Ho
ERROR 146811867 12 12234322.2

TOTAL 3169610002 15
Elaboración propia

se está evaluando.
85
Se observa que en dicha tabla los frameworks del lado del cliente provocan una
mayor variabilidad en el tiempo de ejecución (2=1228187070). Además se
servidor (Fc=50.448) y los frameworks del lado del cliente (Fc=100.388), actuando
de manera independiente, afectan significativamente al tiempo de ejecución de la
operación 4, y lo mismo sucede en la interacción de ambos factores (F c=96.207)
cuyo mayor aporte en dicha variabilidad lo produce los frameworks del lado del
cliente; con lo que se concluye que se rechazan las Hipótesis nulas formuladas en
las tablas 30 y 31.
 Operación 5: Consulta – Movimientos de documento interno – Cantidad de

registros: 5 (cantidad de movimientos por documento).
Tabla 40.
Lado del Cliente

Frameworks
Angular JS JQuery
985 647
Laravel 966 616
946 639
Lado del 967 687
Servidor 4471 4102
Symfony 3906 3666
3798 3854
4064 3499
Elaboración propia
Tabla 41.

Factor A: 38772415.562 1 38772415.56 998.859 4.747 Rechaza Ho
Framework del
lado del servidor
Factor B: 357903.062 1 357903.06 9.220 4.747 Rechaza Ho
Framework del
lado del cliente
Interacción AB 1540.562 1 1540.56 0.039 4.747 Acepta Ho
ERROR 465800.25 12 38816.68

TOTAL 39597659.437 15
Elaboración propia

86
se está evaluando.
Se observa que en dicha tabla los frameworks del lado del servidor ocasionan una
servidor (Fc=998.859) y los frameworks del lado del cliente (Fc=9.220), actuando de
manera independiente, afectan significativamente al tiempo de ejecución de la
operación 5, esto no sucede en la interacción de ambos factores (Fc=0.039); con lo
que se concluye que se rechaza la Hipótesis nula formulada en la tabla 30 pero se
acepta la Hipótesis nula formulada en la tabla 31.
 Operación 6: Consulta – Movimientos de documento externo - Cantidad de

registros: 5 (cantidad de movimientos por trámite).
Tabla 42.
Lado del Cliente

Frameworks
Angular JS JQuery
844 906
Laravel 920 600
776 567
Lado del 838 560
Servidor 4094 3957
Symfony 4086 3711
3684 3766
3663 3743
Elaboración propia
Tabla 43.

Factor A: 38109015.56 1 38109015.56 1505.515 4.747 Rechaza Ho
Framework del lado
del servidor
Factor B: 74939.06 1 74939.06 2.960 4.747 Acepta Ho
Framework del lado
del cliente
ERROR 303755.25 12 25312.93

TOTAL 38497461.43 15
Elaboración propia
87
se está evaluando.
Se observa que en dicha tabla los frameworks del lado del servidor ocasionan una
comprueba que al 5% de nivel de significancia, solo los frameworks del lado del
servidor (Fc=1505.515), actuando de manera independiente, afectan
significativamente al tiempo de ejecución de la operación 6, lo que no sucede con
los frameworks del lado del cliente (Fc=2.960) y en la interacción de ambos factores
(Fc=0.385); con lo que se concluye que para los frameworks del lado del servidor
se rechaza la Hipótesis nula formulada en la tabla 30, para los frameworks del lado
del cliente se acepta la Hipótesis nula formulada en la tabla 30 y para la interacción
de ambos factores se acepta la Hipótesis nula formulada en la tabla 31.
 Operación 7: Reporte diario de trámites externos – Cantidad de registros:

129
Tabla 44.
Lado del Cliente

Frameworks
Angular JS JQuery
5349 4716
Laravel 4828 4546
4985 4283
Lado del 4836 4224
Servidor 6106 5054
Symfony 5131 4909
5099 4729
4884 5128
Elaboración propia
Tabla 45.

CALCULADO ALFA = 5%
Factora A: Framework 669533.063 1 669533.063 6.078 4.747 Rechaza Ho
Factora B: Framework 823102.563 1 823102.563 7.473 4.747 Rechaza Ho
88
ERROR 1321677.75 12 110139.813
TOTAL 2857265.94 15
Elaboración propia

evaluando.
En dicha tabla se observa que los frameworks del lado del cliente ocasionan una
comprueba que al 5% de nivel de significancia, tanto los frameworks del lado del
servidor (Fc=6.078) y los frameworks del lado del cliente (Fc=7.473), actuando de
manera independiente, afectan significativamente al tiempo de ejecución de la
operación 7, lo que no sucede con la interacción de ambos factores (Fc=0.389); con
lo que se concluye que se rechaza la Hipótesis nula formulada en la tabla 30 y se
acepta la Hipótesis nula formulada en la tabla 31.
 Operación 8: Registro – Registrar trámite

Tabla 46.
Lado del Cliente

Frameworks
Angular JS JQuery
1409 539
Laravel 1162 561
1264 492
Lado del 1222 566
Servidor 4103 3352
Symfony 3846 3198
3698 3056
3696 3135
Elaboración propia
Tabla 47.

CALCULADO ALFA = 5%
Factor B: Framework 1891312.562 1 1891312.56 117.081 4.747 Rechaza Ho
89
ERROR 193845.25 12 16153.770
TOTAL 29310368.437 15
Elaboración propia

evaluando.
En dicha tabla se observa que los frameworks del lado del servidor ocasionan una
comprueba que al 5% de nivel de significancia, tanto los frameworks del lado del
servidor (Fc=1685.036) y los frameworks del lado del cliente (Fc=117.081),
actuando de manera independiente, afectan significativamente al tiempo de
ejecución de la operación 8, lo que no sucede con la interacción de ambos factores
(Fc=0.341); con lo que se concluye que se rechaza la Hipótesis nula formulada en
la tabla 30 y se acepta la Hipótesis nula formulada en la tabla 31.
90
Después de haber realizado el análisis estadístico de los tiempos promedio de
ejecución por cada operación, se realizó un resumen de las conclusiones que se
obtuvieron en cada operación por cada factor e interacción entre ellos, las cuales
se muestran a continuación en la Tabla 48.
Tabla 48.
Resumen del análisis estadístico de los tiempos promedio en cada operación.
OPERACIONES
1 2 3 4 5 6 7 8
Factor A: Frameworks Rechaza Rechaza Rechaza Rechaza Rechaza Rechaza Rechaz Rechaza Conclusió
del lado del servidor H0 H0 H0 H0 H0 H0 a H0 H0
n de
Factor B: Frameworks Rechaza Rechaza Rechaza Rechaza Rechaza Acepta Rechaz Rechaza
Hipótesis
del lado del cliente H0 H0 H0 H0 H0 H0 a H0 H0 H0
Rechaza Rechaza Rechaza Rechaza Acepta Acepta Acepta Acepta
Interacción A y B H0 H0 H0 H0 H0 H0 H0 H0
Elaboración propia
En la Tabla 48, se pudo determinar que para los frameworks del lado del servidor,
de las operaciones analizadas, en el 100% se concluyó que si existe diferencia
significativa en el tiempo de ejecución de la aplicación, ocasionada por el tipo de
framework para el lado del servidor. Además para los frameworks del lado del
cliente, de las operaciones analizadas, en el 90% se concluyó que también existe
diferencia significativa en el tiempo de ejecución de la aplicación, ocasionada por
el tipo de framework para el lado del cliente. Por último, en la interacción de ambos
factores se concluyó según el análisis de las operaciones, en el 50% indican que la
interacción de frameworks del lado del cliente y frameworks del lado del servidor
ocasionan una variación significativa en el tiempo de ejecución de la aplicación, y
el otro 50% indican que la interacción de frameworks del lado del cliente y
frameworks del lado del servidor no producen variaciones significativas en el tiempo
de ejecución de la aplicación; esto se debe por la cantidad de información que se
trabajó en cada operación.
91
Para determinar cuáles son los frameworks que ocasiona la diferencia significativa
en el tiempo de ejecución en las operaciones de la aplicación desarrollada tanto
para el lado del cliente y lado del servidor, se realizó el análisis de modelo lineal
general univariante.
Con el modelo lineal general se pueden contrastar hipótesis nulas sobre los efectos
de otras variables en las medias de varias agrupaciones de una única variable
dependiente. Se pueden investigar las interacciones entre los factores así como los
efectos de los factores individuales, algunos de los cuales pueden ser aleatorios
(MLG Análisis Univariante: IBM Knowledge Center, 2017).
Resultados del análisis lineal general univariante
 Medias marginales
Tabla 49.
Tiempo promedio de ejecución para frameworks del lado del servidor
Variable dependiente: TIEMPO_DE EJECUCIÓN

Intervalo de confianza 95%
LADO_SERVIDOR Media
Límite inferior Límite superior
Laravel 8290,594 7979,655 8601,532
Symfony 6461,266 6150,327 6772,204
Fuente: IBM SPSS Statistics 21
En la Tabla 49 se puede determinar que el framework Laravel tiene una

media ( 8290,594) superior a la del framework Symfony
( 6461,266); concluyendo así, que para los frameworks del lado del
servidor actuando independientemente, Laravel ocasiona tiempos de
ejecución mayores.
Tabla 50.
Tiempo promedio de ejecución para frameworks del lado del cliente
Variable dependiente: TIEMPO_DE EJECUCIÓN

Intervalo de confianza 95%
LADO_CLIENTE Media
Límite inferior Límite superior
AngularJS 5080,719 4769,780 5391,657
JQuery 9671,141 9360,202 9982,079
En la Tabla 50 se puede determinar que el framework JQuery tiene una

media ( 9671,141) superior a la del framework AngularJs
( 5080,719); concluyendo así, que para los frameworks del lado del
92
cliente actuando independientemente, JQuery ocasiona tiempos de
ejecución mayores.
Tabla 51.
Tiempo promedio de ejecución - frameworks lado del cliente y lado del
servidor
Variable dependiente: TIEMPO_DE_EJECUCIÓN

LADO SERVIDOR Intervalo de confianza 95%
Media
LADO_CLIENTE Límite inferior Límite superior
Laravel AngularJS 3670,187 3230,454 4109,921
JQuery 12911,000 12471,266 13350,734
Symfony AngularJS 6491,250 6051,516 6930,984
JQuery 6431,281 5991,548 6871,015
En la Tabla 51 se puede observar que la interacción del framework

Laravel con el framework JQuery tienen una media ( 9671,141)
superior a las demás interacciones; concluyendo así que Laravel y
JQuery interactuando producen tiempos de ejecución mayores en la
aplicación.
Tabla 52.
Tiempo promedio de tiempo de ejecución - framework lado del servidor
y operaciones

LADO_SERVIDOR Intervalo de confianza 95%
Media
OPERACIONES Límite inferior Límite superior
Laravel C1 5506,750 4627,283 6386,217
C2 11272,750 10393,283 12152,217
C3 15886,875 15007,408 16766,342
C4 26477,625 25598,158 27357,092
C5 806,625 -72,842 1686,092
C6 751,375 -128,092 1630,842
C7 4720,875 3841,408 5600,342
C8 901,875 22,408 1781,342
Symfony C1 5237,500 4358,033 6116,967
C2 7293,375 6413,908 8172,842
C3 8708,625 7829,158 9588,092
C4 14052,125 13172,658 14931,592
C5 3920,000 3040,533 4799,467
C6 3838,000 2958,533 4717,467
C7 5130,000 4250,533 6009,467
C8 3510,500 2631,033 4389,967
En la Tabla 52 se puede determinar que el tiempo promedio de ejecución

de las operaciones realizadas utilizando el framework del lado del
93
servidor Symfony, son menores con respecto a los tiempos de ejecución
de las mismas operaciones utilizando el framework Laravel.
Tabla 53.
Tiempos promedio de ejecución - framework lado del cliente y
operaciones

LADO_CLIENTE Intervalo de confianza 95%
Media
OPERACIONES Límite inferior Límite superior
AngularJS C1 3696,125 2816,658 4575,592
C2 5667,375 4787,908 6546,842
C3 7200,500 6321,033 8079,967
C4 11503,500 10624,033 12382,967
C5 2512,875 1633,408 3392,242
C6 2363,125 1483,658 3242,592
C7 5152,250 4272,783 6031,717
C8 2550,000 1670,533 3429,467
JQuery C1 7048,125 6168,658 7927,592
C2 12898,750 12019,283 13778,217
C3 17395,000 16515,533 18274,467
C4 29026,250 28146,783 29905,717
C5 2213,750 1334,283 3093,217
C6 2226,250 1346,783 3105,717
C7 4698,625 3819,158 5578,092
C8 1862,375 982,908 2741,842
En la Tabla 53 se puede determinar que el tiempo promedio de ejecución

de las operaciones realizadas utilizando el framework del lado del cliente
AngularJs, son menores con respecto a los tiempos de ejecución de las
mismas operaciones utilizando el framework JQuery.
94
5.3. Discusión de resultados
Después de haber realizado el análisis estadístico de los tiempos de ejecución de
la aplicación desarrollada y el análisis de modelo lineal general univariante
obtuvieron los siguientes resultados:
El framework del lado del cliente que mejores tiempos de ejecución ofreció en la
aplicación web desarrollada fue AngularJs. Esto se debe que posee en su núcleo
un componente llamado $http del cual se menciona en el marco teórico. Este
componente permite hacer peticiones AJAX al servidor, es realmente como el
objeto XMLHttpRequest o el método ajax() de JQuery(). La diferencia con estos dos
últimos es que está integrado a AngularJs como un servicio y pero lo más
importante que actualiza la vista o interfaz gráfica de manera instantánea al
producirse algún cambio en el modelo de JavaScript (Curso de AngularJs y REST:
Servicio $Http, 2017). Además, este servicio trabaja con almacenamiento en caché
lo que le permite almacenar los datos de peticiones realizadas y usarse cuando se
vuelva a realizar la misma petición, lo que favorece al tiempo de ejecución de la
aplicación, puesto que la petición ya no se realiza directamente al servidor sino al
espacio donde está almacenada la información solicitada que es la caché
(Coderwall, 2017), en consecuencia la información solicitada por un usuario se le
mostrará de forma más rápida.
El framework del lado del servidor, que mejores tiempos de ejecución ofreció en la
aplicación Web desarrollada fue Symfony. El rendimiento y rapidez de Symfony se
debe al sistema de caché, lo que le permite a Symfony almacenar los archivos PHP
compilados para así evitar tener que volver a compilar ellos para cada solicitud o
petición. Además usa una caché interna para almacenar el resultado de la
asignación de rutas de archivos a sus rutas de archivos reales y absolutos, esto
aumenta el rendimiento de las aplicaciones donde se abren muchos archivos PHP,
especialmente en los sistemas Windows (Symfony, 2017). Una comparación
realizada por (Bowman, 2017), en la cual se pusieron a prueba 6 frameworks PHP
dentro de los cuales estaban Symfony y Laravel, el ambiente en que se llevó a cabo
esta comparativa fue en un servidor Digital Ocean Ubuntu 16.04 x64 2Gb, uno de
los parámetros de comparación fue el tiempo de ejecución, los resultados que
obtuvo para este parámetro fue que Symfony era mucho más rápido que Laravel al
momento de realizar las peticiones.
95
Además, en la interacción de los frameworks del lado del cliente y del servidor
resultó que los frameworks del lado del servidor trabajando junto con AngularJs en
la aplicación desarrollada, los tiempos de ejecución de está eran mejores a
comparación que trabajando con JQuery. No existen trabajos de investigación
donde se realice comparativas donde interactúen frameworks PHP y JavaScript, lo
más cercano a ello son solo comparaciones entre frameworks PHP o frameworks
JavaScript. Entonces se puede decir que estos resultados obtenidos es un aporte
en cuanto al desarrollo de aplicaciones Web.
5.4. Validación de hipótesis

De la hipótesis planteada en la investigación: “Existe diferencia significativa en el
tiempo de ejecución de una aplicación Web desarrollada en diferentes marcos de
trabajo utilizados en el lado del cliente y en el lado del servidor”, se pudo demostrar,
que según los resultados obtenidos la hipótesis planteada se aceptó con un nivel
de significancia del 5%, pues según el tipo de framework utilizado para desarrollar
la aplicación sí hubo diferencias significativas en el tiempo de ejecución de esta.
96
Conclusiones
1. Se pudo determinar que en los frameworks del lado del servidor: Laravel y
Symfony, tienen una estructura compuesta por diez (10) y cinco (4) carpetas
principales, respectivamente. En cuanto a los componentes, Symfony posee
solo tres (3) componentes principales y Laravel tiene cinco (5). Para los
frameworks del lado del cliente, la estructura de AngularJs varía según el
proyecto y desarrollador pero existen patrones que se pueden seguir y
emplear, la cantidad de componentes principales para este es de nueve (9);
y para el caso de JQuery no existe una estructura definida y su cantidad de
componentes principales es de cinco (5).
2. El módulo más desarrollado o utilizado, según la encuesta aplicada, por las
empresas de la región Piura es el de trámite documentario, siendo las
operaciones que más se realizan para este módulo las de consulta y registro.
Además los requerimientos funcionales para la aplicación que se desarrolló,
los cuales fueron: Consultar bandeja de expedientes enviados, consultar
bandeja de expedientes recepcionados, consultar bandeja de expedientes
finalizados, consultar bandeja de expedientes recibidos, consulta de
movimientos de expediente interno y de expediente externo, reporte diario
de expedientes externos recepcionados por mesa de partes y registro de
trámite.
3. Se demostró que sí existe diferencia significativa en los tiempos de ejecución
de la aplicación Web desarrollada utilizando frameworks para el lado del
cliente, en donde en el 90% de las operaciones evaluadas, si existe
diferencia en el tiempo de ejecución cuando se utiliza el Framework
AngularJs y JQuery, siendo JQuery quien ocasiona tiempos de ejecución
mayores que AngularJs. De acuerdo al análisis estadístico también se
determinó que si existe diferencias significativas en los tiempos de ejecución
de la aplicación Web desarrollada utilizando frameworks del lado del
servidor, según el análisis el 100% de las operaciones indican que hay una
diferencia en los tiempos de ejecución entre Laravel y Symfony, donde
Laravel presenta tiempos de ejecución superiores a Symfony. Y en cuanto a
la combinación de frameworks del lado del cliente y lado del servidor, según
el análisis lineal univarante se concluyó que AngularJs utilizado en conjunto
97
con algún framework del lado del servidor provee tiempos de ejecución
favorables en una aplicación Web.
98
Recomendaciones
1. Para complementar el estudio realizado sería beneficioso extender el
análisis de estos frameworks en cuanto al nivel de seguridad y curva de
aprendizaje, pues también son factores importantes en el desarrollo de
software.
2. En cuanto a los frameworks del lado del servidor, se recomienda realizar un
análisis para determinar cuál de ellos presenta mayor compatibilidad al
momento de interactuar con la capa de acceso a datos de los Sistemas
Gestores de Base de Datos más utilizados.
3. Realizar un estudio similar aplicando la misma metodología, pero con
versiones posteriores de los frameworks involucrados en esta investigación,
para comparar y validar los resultados obtenidos en versiones superiores.
99
Bibliografía
 Álvarez, C. (2015). Genbeta:dev. Obtenido de
https://www.genbetadev.com/desarrollo-web/angular-js-modulos-y-
arquitectura
 Amarez Hernández, J. M., Campos Cantero, P., & Castelo Delgado, T.

(2011). Desarrollo de una aplicación Web para la gestión de Entornos
Virtuales. Madrid, España.
 AngularJs. (2016). Obtenido de https://angularjs.org/
 Arcos Chalán , J. S., & Chicaiza Inguillay, D. E. (2016). Análisis Comparativo

de los Frameworks Laravel y CodeIgniter para la implementación del
Sistema de Gestión de Concursos de Méritos y Oposición en la Universidad
Nacional de Chimborazo. Riobamba, Ecuador.
 Arora, S. (07 de 03 de 2017). noeticforce: The Best 10 Modern Web

Development. Obtenido de noeticforce: http://noeticforce.com/best-php-
frameworks-for-modern-web-development
 Avilés López , F. J. (8 de Octubre de 2014). Desarrollo de una aplicación

Web para compartir medio de transporte con AngularJs. 21. Cartagena,
España.
 Bahit, E. (2012). Scrum y eXtremeProgramming para programadores.

Argentina: SafeCreative.
 Bermeo Rodriguez, L. I. (2014). Análisis comparativo de frameworks

JavaScript: Jquery Mootols, para la implementación de aplicaciones Web en
la empresa Sofya. Aplicación de un caso de estudio. Sangolqui, Ecuador.
 Bowman, W. (01 de 06 de 2017). Medium. Obtenido de Medium:

https://medium.com/@asked_io/php-mvc-framework-showdown-7-0-
performance-ba0ed09c1f54
 Bravo Olmos, A., & Enriquez Solís, A. A. (2012). Portal del Laboratorio de
Geomática y Especialidades Cviles. Mexico.
 Callejas Cuervo, M., Peñalosa Parra , D. I., & Alarcón Aldana, A. C. (2011).
Evaluación y análisis de rendimiento de los frameworks de persistencia
Hibernate y Eclipselink. Colombia.
 Calmet Izquierdo, J. P. (2014). Sistema informático Web de trámite

documentario para la UGEL de Zarumilla-Tumbes utilizando los frameworks
AngularJs y Srping MVC. Trujillo, Perú.
100
 Cobo, Á., Gómez, P., Pérez, D., & Rocha, R. (2005). PHP y MySQL
Tecnologías para el desarrollo de aplicaciones Web. Ediciones Díaz de
Santos.
 Coderwall. (02 de 06 de 2017). Obtenido de Coderwall: Power up Angular's

$http service with caching: https://coderwall.com/p/40axlq/power-up-
angular-s-http-service-with-caching
 Curso de AngularJs y REST: Servicio $Http. (02 de 06 de 2017). Obtenido

de Curso de AngularJs y REST:
http://www.cursoangularjs.es/doku.php?id=unidades:03_servicios:02_http
 Eguiluz, J. (2012). Desarrollo Web ágil con Symfony2.
 Ernesto , S. (s.f.). desarrolloweb.com. Recuperado el 16 de 12 de 2015, de

http://www.desarrolloweb.com/wiki/framework.html
 Espinoza Aguirre, C. B. (2012). Comparativa de Frameworks para el

desarrollo de aplicaciones con PHP. Trabajo de Monografía. Universidad del
Azuay. Cuencua, Ecuador.
 Fernandez Silva, I. A., & Jalil Moreno, J. G. (2007). Análisis de Patrones de

Software y su aplicación en un Framework de Desarrollo utilizado en .Net.
Sangolquí, Ecuador.
 Francois Zaninotoo, F. P. (s.f.). Symfony 1.4. La Guía definitiva. (J. Eguiluz,

Trad.)
 Girón Bonilla, M., & Arguello Pazmiño, V. (2014). Análisis de rendimiento de

frameworks para interfaces Prism y MVVVM Light aplicada a la empresa
Cybertronic. Chimborazo, Ecuador.
 GitHub. (s.f.). Obtenido de https://github.com/fzaninotto/Faker
 Google Trends. (2016). Obtenido de www.google.com.pre/trends.
 Guerrero , A., & Suarez, J. (2010). Patrones de diseño para el desarrollo de

aplicaciones Web. Desarrollando Software con buenas prácticas.
Bucaramanga, Colombia: Editorial Ltda.
 Guerrero, C., & Recaman, H. (2009). Marcos de Trabajo (Framework) para

soportar el desarrollo de aplicaciones Web de código abierto. Bucaramanga,
Colombia: Ltda.
 Gutierrez, J. (s.f.). Obtenido de

www.lsi.us.es/~javierj/investigacion_ficheros/Framework.pdf
 Gutierrez, J. J. (s.f.). ¿Qué es un framework Web? Obtenido de

www.lsi.us.es/~javierj/investigacion_ficheros/Framework.pdf
101
 Hohman Sandoval, C. (2014). Creación de Frameworks con patrones de
diseño para el desarrollo de aplicaciones empresariales. Ciudad
Universitaria, Mexico.
 JQuery. (2016). Obtenido de https://jquery.com/
 JQuery Mobile. (s.f.). Obtenido de http://jquerymobile.com/
 JQuery Tools. (27 de 02 de 2017). Obtenido de http://jquerytools.github.io/
 JQuery User Interface. (s.f.). Obtenido de https://jqueryui.com/
 Laravel. (2016). Obtenido de

https://laravel.com/docs/5.3/structure#introduction
 Laravel. (2016). Obtenido de https://laravel.com/docs/5.3/structure
 Laravel. (2016). Obtenido de https://laravel.com/docs/5.3#installation
 Laravel. (s.f.). Laravel - The PHP Framework For Web Artisans. Obtenido de
http://laravel.com/docs/5.1/eloquent
 Laravel. (s.f.). Laravel Blade. Obtenido de http://laravel.com/docs/5.1/blade
 Martin, R. C. (2011). Architecture the Lost Years. Obtenido de

https://www.youtube.com/watch?v=WpkDN78P884
 Minetto, E. L. (2007). Frameworks para desenvolvimiento en PHP. Brasil:

NOVATEC.
 MLG Análisis Univariante: IBM Knowledge Center. (30 de 05 de 2017).

Obtenido de IBM Knowledge Center:
https://www.ibm.com/support/knowledgecenter/es/SSLVMB_22.0.0/com.ib
m.spss.statistics.help/spss/base/idh_glmu.htm
 Niama Astudillo, P. F. (2015). SISTEMA DE GESTIÓN DE HISTORIAS

CLÍNICAS PARA LA CLÍNICA PANAMERICANA – CEDITEM UTILIZANDO
EL FRAMEWORK SYMFONY2. Riobamba, Ecuador.
 Nolte, J. (1995). Towards a Persistence Framework for High Performance

Computing Systems. Pennsylvania, USA.
 Object-Oriented Application Frameworks. (2016). Recuperado el 28 de 11 de

2016, de Object-Oriented Application Frameworks:
http://www.cs.wustl.edu/~schmidt/CACM-frameworks.html
 Ochoa, C. (2015). netquest. Obtenido de

https://www.netquest.com/blog/es/blog/es/muestreo-por-conveniencia
102
 Orduz Navarrete, Y. (2016). Análisis, Diseño e Implementación de un
Sistema de Información para la Gestión de Alquiler y Mantenimiento de
Vehículos. 30-33. Bogotá, Colombia.
 Osmosis Latina. (01 de 03 de 2017). Obtenido de

https://www.osmosislatina.com/jmeter/basico.htm
 Pavón Mestras, J. (s.f.). Estructura de las Aplicaciones Orientadas a Objetos.

El patrón Modelo-Vista-Controlador (MVC). Dep. Ingeniería del Software e
Inteligencia Artificial.Universidad Complutense Madrid. Madrid, España.
 Ponce Guama, S. S. (2011). Sistema Web para el departamento de asesoría

jurídica de la dirección provincial de educación de Imbabura, mediante la
utilización del framework Symfony. Proyecto. Universidad Técnica del Norte.
Ibarra, Ecuador.
 Pree, W. (1994). Meta Patterns-A Means For Capturing the Essentials of

Reusable ObjectOriented Design", Proceedings of the 8th European
Conference on Object-Oriented.
 Pressman, R. (2010). Ingeniería de Software. Un enfoque práctico (Vol.

Séptima Edicción).
 Quito, C., & León, T. (2013). Guía de Investigación. Departamento de

Investigación de Operaciones. Facultad de Ingeniería Industrial. Universidad
Nacional de Piura. Piura, Perú.
 QUnit JS Unit Testing. (s.f.). Obtenido de https://qunitjs.com/
 Rodriguez, E. (2014). BookAngular. Obtenido de

https://eladrodriguez.gitbooks.io/angularjs/content/1-introduccion-
angularjs/1-2-pq-angularjs.html#
 Saavedra Arango, M. (2010). Programación Web dinámica. Piura: J.D.D &

Service.
 Saavedra, E. (2009). Grails: Framework para el desarrollo de aplicaciones

Web. Revista de Software Libre ATIX, 32-41. Recuperado el 15 de 12 de
2015, de http://osl.ugr.es/descargas/atix08.pdf
 Sánchez Osejo, E. R., & Vera Cárdenas, I. E. (2011). Ánalisis del rendimiento
de framework PHP para desarrollar aplicaciones Web óptimas. Caso
práctico: portal academia Linux Espoch. (Tesis de Grado). Escuela Superior
Politécnica de Chimborazo. Riobamba, Ecuador.
 Santa Maria Loza, L. D. (01 de Abril de 2010). DSMGroup. Obtenido de

http://www.dsmgroupsac.com/in-the-news/tramitedocumentario
103
 SOURCEFORGE.NET. (2005). Obtenido de
http://oness.sourceforge.net/proyecto/html/ch03s02.html
 Suarez Silva, E. A. (2011). Análisis comparativo de los frameworks EJB3 y

ADO.net Entity Framework para el desarrollo de aplicaciones empresariales.
Ecuador.
 Symfony. (s.f.). Recuperado el 20 de 12 de 2016, de

https://symfony.com/doc/current/setup.html
 Symfony. (24 de Febrero de 2017). Obtenido de 10 criteria for choosing the

correct framework: http://symfony.com/ten-criteria
 The Apache Software Foundation. (01 de 03 de 2017). Obtenido de

http://jmeter.apache.org/
 Thibaud, C. (2006). MySQL 5 Instalación Implementación Administracion

Programación. Barcelona: Editions ENI.
 Throuhgput IBM. (2010). Measurements of performance. IBM Corporation.
 Van Lancker, L. (2014). JQuery. El framwework JavaScript de la Web 2.0.

Editions ENI.
 Zabala Hidalgo, X. L., & Ochoa Iglesias, C. L. (2008). Estudio de Frameworks

para PHP e integración a una herramienta IDE; aplicado al portal Web de la
comunidad Linux de la Espoch. Tesis de Grado. Escuela Superior
Politécnica de Chimborazo. Riobamba, Ecuador.
104
ANEXOS
ANEXO 1. Matriz de Consistencia
Problema Objetivo Hipótesis Variables Indicadores Índices Método Técnica Instrumentos
Problema Objetivo Hipótesis Variable Cliente: Lenguaje Tipo de Encuestas a Guía de

Principal General General Independiente de programación investigación empresas observación
¿Cuál es el Realizar un Existe diferencia Tipos de JavaScript aplicada
tiempo de análisis significativa en el marcos de experimental, Observación de SPSS Statistics
ejecución de comparativo de tiempo de Marcos de trabajo trabajo Servidor: Lenguaje transversal los resultados 21
una aplicación los tiempos de ejecución de una (frameworks) de programación
Web que ha ejecución de una aplicación Web PHP Modelo teórico Análisis de Microsoft Excel
sido aplicación Web desarrollada en Diseño de la resultados
desarrollada desarrollada en diferentes investigación Apache JMeter
con diferentes diferentes marcos marcos de trabajo experimental puro Modelamiento
marcos de de trabajo utilizados en el (UML )
trabajos utilizados en el lado del cliente y Población
utilizados en el lado del cliente y en el lado del Empresas y
lado del cliente en el lado del servidor. entidades públicas y
y en el lado del servidor. privadas de Piura
servidor?
Muestra
El tamaño de la
muestra fue de 11
Tiempo de petición empresas e
Variable instituciones
Dependiente Tiempo de públicas y privadas
ejecución de Piura que se
Tiempo de dedican al desarrollo
ejecución Tiempo de de software o tienen
respuesta una área de
tecnología de la
información
105
ANEXO 2. Guía de observación (Diseño Trifactorial).
Lado del Cliente (JavaScript)
AngularJs JQuery
Operaciones Operaciones
MARCOS DE
TRABAJO Consultas Consultas
(FRAMEWOR Registro Registro
KS) Expedientes Reporte Expedientes Reporte
Bandeja (Trámites) Bandeja (Trámites)
(Movimientos) (Trámites) (Movimientos) (Trámites)
Recepciona Reporte Recepciona Reporte

Enviados Finalizados Recibidos Interno Externo Trámite Enviados Finalizados Recibidos Interno Externo Expediente
dos Diario dos Diario
Laravel
Lado del Servidor (PHP)
Symfony
Tabla 54. Guía de Observación (Diseño trifactorial de 2x2x8) - 4 réplicas (128 combinaciones).
 Variable de respuesta: Tiempo de ejecución (milisegundos).

 Factores: Frameworks (Lado del Cliente y Lado del Servidor).
106
ANEXO 3. Encuesta para determinar el módulo o aplicación Web que se
desarrolla o utiliza con mayor frecuencia.
ENCUESTA
Apellidos y nombres: ________________________________________________
Empresa donde labora: ______________________________________________
Cargo: ____________________________________________________________
INTRODUCCION
Esta encuesta va dirigida a Jefes de Áreas de desarrollo de Software y/o

programadores que se dedican al desarrollo de aplicaciones Web en las empresas
de la región Piura, con el objetivo de determinar que módulo o aplicación Web se
desarrolla o utilizan con mayor frecuencia, así como también identificar el grado de
conocimiento y utilización de marcos de trabajo (frameworks). La información
recopilada se empleará para llevar a cabo la tesis denominada “Análisis
comparativo del tiempo de ejecución de una aplicación Web desarrollada en
diferentes marcos de trabajo utilizados en el lado del cliente y en el lado del
servidor.”
INSTRUCCIONES
La mayoría de preguntas han sido realizadas lo más breves posibles para una
respuesta rápida, también existen preguntas que pueden o no contestarse de
acuerdo a respuestas anteriores, se le aconseja leer detenidamente las preguntas
y responder lo más veraz posible.
PREGUNTAS
1. En la empresa donde labora, que utilizan para desarrollar

¿Qué tipo de Software aplicaciones Web?
desarrollan con mayor ( ) PHP
frecuencia? ( ) Java Script
( ) Web ( ) Java
( ) Escritorio ( ) ASP.NET
( ) Web ( ) Ruby
2. ¿Cuál o cuáles son los ( ) Python
lenguajes de programación ( ) Visual FoxPro
107
( ) Otros. Especificar: ( ) Módulo de Recursos
________________________ Humanos
________________________ ( ) Módulo de Control de
3. ¿Ha escuchado o utilizado Inventarios
tecnologías de desarrollo ( ) Módulo de Producción y
denominadas marcos de fabricación
trabajo (frameworks)? ( ) Otros. Especificar:
( ) Sí ________________________
( ) No. (Pasar a la pregunta N° 6) ________________________
4. ¿Qué marcos de trabajo 7. Según la respuesta anterior,
(frameworks) del lado del ¿Qué tan complejo es el
servidor ha utilizado para desarrollo del módulo o
desarrollar aplicaciones Web? aplicaciones Web en relación a
( ) Spring las funciones o interacciones
( ) Struts que realiza? Por ejemplo:
( ) Laravel requiere de gran cantidad de
( ) CodeIgniter componentes para su
( ) Symfony desarrollo, el rendimiento y
( ) Yii velocidad de las operaciones
( ) Zend son adecuados, requiere de
( ) Phalcon gran cantidad de recursos
( ) Otros. Especificar: software, brinda la información
________________________ necesaria, etc.
________________________ ( ) Muy complejo
5. ¿Qué marcos de trabajo ( ) Complejo
(frameworks) del lado del ( ) No precisa
cliente ha utilizado para ( ) Sencillo
desarrollar aplicaciones Web? ( ) Muy Sencillo
( ) AngularJS
( ) JQuery Breve explicación de su
( ) EmberJS respuesta:
( ) Sencha ExtJS ________________________
( ) Otros. Especificar: ________________________
________________________ ________________________
________________________ ________________________
6. En la empresa o centro de ________________________
trabajo, ¿Qué módulo o
aplicación Web con mayor 8. ¿Qué tipos o niveles de
frecuencia se usa o solicita usuario suelen tener los
para su desarrollo? módulos desarrollados?
( ) Módulo de Finanzas ( ) Usuario normal.
( ) Módulo de Compra/Venta ( ) Administrador
( ) Módulo de Logística ( ) Superadministrador.
( ) Tester
108
( ) Otros. Especificar: ________________________
________________________ ________________________
________________________ ________________________
9. Según el módulo seleccionado, 12. Marque las dificultades e

¿Cuál o cuáles son las inconvenientes al momento de
operaciones que con mayor desarrollar e implantar el
frecuencia los usuarios módulo.
realizan? ( ) Interfaces pocos
( ) Consultas amigables para el usuario.
( ) Registros ( ) Demora en las consultas en
( ) Modificaciones la base datos.
( ) Inserción Masiva ( ) Reportes que no presentan
( ) Otra. Especificar: la información requerida.
________________________ ( ) El usuario tenía dificultades
________________________ para realizar ciertas
operaciones.
10. ¿Cuál es el número ( ) Otras. Especificar:
aproximado de usuarios que ________________________
realizan aquella operación? ________________________
________________________ ________________________
________________________
11. Mencione brevemente las

operaciones o funciones de
mayor complejidad al momento
de desarrollar el módulo o
aplicación Web.
________________________
________________________
109
ANEXO 4. Validación de encuesta para determinar el módulo o aplicación Web
que se desarrolla o utiliza con mayor frecuencia.
Figura 43. Validación de encuesta - Estadístico
110
Figura 44. Validación de encuesta - Ingeniero Informático
111
Figura 45. Validación de encuesta - Ingeniero Informático
112
ANEXO 5. Instalación del Framework Laravel
Para la instalación de un proyecto de Laravel se puede realizar mediante dos

maneras (Laravel, 2016).
1) Vía Instalador de Laravel. Primero, descargar el instalador de

Laravel usando Composer:
Figura 46. Descargando el instalador de Laravel

Figura
Fuente:47.
(Laravel, 2016)
Asegúrese de colocar el directorio $HOME/.composer/vendor/bin (o el
directorio equivalente para su Sistema Operativo) en su “PATH” para
que el sistema ejecute el archivo ejecutable Laravel.
Una vez instalado, el comando “laravel new” creará una nueva

instalación de Laravel en el directorio que especifique. Por ejemplo,
“laravel new blog” creara una nueva instalación de Laravel con todas
las dependencias de Laravel ya instaladas:
Figura 48. Comando para crear una nueva instancia de

Laravel
2) Vía Composer “Create-Project”. Alternativamente, también puede

instalar Laravel mediante el comando de Composer “create-project”
en la terminal.
Figura 49. Comando para instalar Laravel

Si tiene PHP instalado localmente y desea utilizar el servidor de

desarrollo integrado de PHP para desplegar la aplicación, puede
utilizar el comando de Artisan “serve”. Este comando iniciará un
servidor de desarrollo en http://localhost:8000.
113
Figura 50. Comando de Artisan para desplegar la aplicación
Una vez instalado Laravel se puede desplegar la aplicación para cerciorarse

que está correcto.
Figura 51. Desplegando la aplicación de Laravel en forma local

Elaboración propia
114
ANEXO 6. Instalación del Framework Symfony
Para la instalación de un proyecto de Symfony se puede realizar mediante dos

maneras (Symfony, s.f.).
1) Symfony proporciona una aplicación dedicada llamada Symfony

Installer para facilitar la creación de aplicaciones Symfony. Este
instalador es un ejecutable compatible con PHP 5.4 que necesita
instalarse en su sistema solo una vez.
Figura 52. Instalar Symfony mediante su ejecutable.

Fuente: (Symfony, 2017)
Una vez que Symfony Installer se ha ejecutado correctamente, se

puede crear una aplicación Symfony con el comando new.
Figura 53. Crear una aplicación Symfony mediante comandos.

Este comando crea un nuevo directorio llamado my_project_name/

que contiene un proyectos vacío basado en la versión Symfony
estable más reciente disponible. Además, el instalador comprueba si
su sistema cumple con los requisitos técnicos para ejecutar
aplicaciones Symfony. Si no es así, vera la lista de cambios
necesarios para cumplir esos requisitos.
2) Se puede instalar Symfony con Composer, el gestor de dependencias

utilizados por las modernas aplicaciones PHP. Si no se tiene instalado
Composer, comience instalando Composer globalmente. A
continuación, ejecute el comando create-project para crear una
aplicación Symfony basado en su última versión estable.
Figura 54. Instalar Symfony mediante Composer.

115
Después de instalar Symfony, se puede desplegar en forma local pare cerciorarse
que se instaló correctamente
Figura 55. Desplegando el proyecto Symfony de manera local.

Elaboración propia
116
ANEXO 7. Instalación del Framework AngularJS
AngularJs está conformado por archivos JavaScript, existen dos maneras de

agregarlo a un proyecto:
1. Descargar AngularJs desde su página oficial, aquí se muestra la

última versión, pero se puede descargar la versión que mejor se
adapte a los proyectos a realizar.
Figura 56. Descargando AngularJs

Fuente: (AngularJs, 2016)
Después de descargar AngularJs, se copia y descomprime el archivo

en el proyecto, luego en el archivo index.html se agrega la referencia
donde se encuentra el archivo.
Figura 57. Agregando AngularJs al proyecto.

Elaboración propia
117
2. Incluir directamente AngularJs mediante su CDN (Content Delivery
Network), para esta forma de incluir AngularJs se debe tener acceso
a internet para que funcione correctamente.
Figura 58. CDN de AngularJs

Fuente: (AngularJs, 2016)
De igual forma, en el archivo index.html se incluye la referencia de

JQuery, en este caso su CDN.
Figura 59. Incluir CDN de AngularJs al proyecto

Elaboración propia
118
ANEXO 8. Instalación del Framework JQuery
JQuery no es más que un archivo de JavaScript y por lo tanto se incluye en el

documento HTML.
Hay dos maneras de incluir JQuery en un proyecto.
1. Descargar JQuery desde su página oficial: https://jquery.com/ , aquí

se muestra la última versión, pero se puede descargar la versión que
mejor se adapte a los proyectos.
Figura 60. Página oficial de JQuery

Fuente: (JQuery, 2016)
Después de descargar JQuery, se copia y descomprime el archivo

proyecto, luego en el archivo index.html se agrega la referencia de
este.
Figura 61. Incluir la referencia de JQuery al proyecto

Elaboración propia
119
2. Incluir directamente JQuery mediante su CDN (Content Delivery
Network), cabe aclarar que el framework funcionará siempre y cuando
se tenga acceso a internet.
Figura 62. Página oficial de JQuery (CDN)

Fuente: (JQuery, 2016)
De igual forma, en el archivo index.html se incluye la referencia de

JQuery, en este caso el CDN.
Figura 64.
Figura 63. Incluir la referencia de JQuery (CDN).

Elaboración propia
120
ANEXO 9. Capturas de pantalla de la aplicación Web desarrollada (Sistema de
Trámite Documentario).
Figura 65. Inicio de Sesión

Fuente: Aplicación desarrollada.
Figura 66. Dashboard de la aplicación

121
Figura 67. Bandeja de trámites enviados
Figura 68. Bandeja de trámites recepcionados

122
Figura 69. Bandeja de trámites finalizados
Figura 70. Bandeja de trámites recibidos

123
Figura 71. Registrar trámite
Figura 72. Reporte diario

124
Figura 73. Consulta de un expediente o documento internamente
Figura 74. Consulta externa de un expediente o documento

125
ANEXO 10. ApacheJMeter
Figura 75. Pantalla principal de Apache JMeter

Fuente: Software Apache JMeter.
Figura 76. Pantalla de configuración para las pruebas

126
Figura 77. Pantallas de resultados de una prueba.
127
ANEXO 11. Gráficos de perfil obtenidos del análisis lineal general univariante
Figura 78. Medias marginales estimadas de tiempo de ejecución-frameworks del lado del cliente.
Figura 79. Medias marginales estimadas de tiempo de ejecución-frameworks del lado del servidor
128
Figura 80. Medias marginales de tiempo de ejecución-frameworks del lado del cliente y operaciones
Figura 81. Medias marginales estimados de tiempo de ejecución-frameworks del lado del servidor
y operaciones
129
Figura 82. Medias marginales estimadas de tiempo de ejecución-frameworks del lado del cliente y
lado del servidor
130

Informe Final de Tesis - Luis Guillermo Ramirez Coronado

Cargado por

Copyright:

Formatos disponibles

Informe Final de Tesis - Luis Guillermo Ramirez Coronado

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Informe Final de Tesis - Luis Guillermo Ramirez Coronado

Cargado por

Copyright:

Formatos disponibles

UNIVERSIDAD NACIONAL DE PIURA

FACULTAD DE INGENIERÍA INDUSTRIAL

ESCUELA PROFESIONAL DE INGENIERÍA INFORMÁTICA

“ANÁLISIS COMPARATIVO DEL TIEMPO DE EJECUCIÓN DE UNA

FACULTAD DE INGENIERÍA INDUSTRIAL

ESCUELA PROFESIONAL DE INGENIERÍA INFORMÁTICA

“ANÁLISIS COMPARATIVO DEL TIEMPO DE EJECUCIÓN DE UNA

CAPÍTULO 1. EL PROBLEMA DE INVESTIGACIÓN ........................................................................... 3

1.1. DESCRIPCIÓN Y FORMULACIÓN DEL PROBLEMA DE INVESTIGACIÓN ..............................................3

2.1. ANTECEDENTES DEL ESTUDIO ........................................................................................................................9

3.1. TIPO DE INVESTIGACIÓN ................................................................................................................................ 44

4.1. TRÁMITE DOCUMENTARIO. ........................................................................................................................... 57

5.1. PRESENTACIÓN DE RESULTADOS............................................................................................................... 77

BIBLIOGRAFÍA .......................................................................................................................................... 100

1.1. Descripción y formulación del problema de investigación

1.2. Objetivos de la investigación

1.3. Justificación de la investigación

1.4. Hipótesis de la investigación

“Cada tecnología de desarrollo Web o lenguaje de programación tiene

Como se mencionaba anteriormente existen frameworks para la programación del

Para el lado del cliente los frameworks están basados en el lenguaje de

Los frameworks para el lado del servidor basados en el lenguaje de programación

Otro framework para el lado del servidor es Symfony, un completo framework

Toda estas herramientas o tecnologías permiten el desarrollo rápido y eficiente de

En términos generales de sistemas de información, el rendimiento es considerado

Bermeo Rodriguez (2014) sostiene que el rendimiento es una caracteristica que

2.1. Antecedentes del estudio

Los frameworks son un conjunto de buenas prácticas de desarrollo

Los principales objetivos que un framework son: Acelerar el proceso de

Un framework simplifica el desarrollo de las aplicaciones, ya que automatiza

En general, con el término framework, nos estamos refiriendo a una

También un marco de trabajo (framework) se puede clasificar según su

 White Box: Frameworks de Caja Blanca o dirigidos por la

2.2.3. Características de los frameworks

2.2.4. Ventajas de los frameworks

 Reutilización de código: Los frameworks son desarrollados

2.2.5. Desventajas de los frameworks

2.2.7. Patrones y frameworks

El patrón MVC es un patrón de arquitectura de software encargado de

MVC divide las aplicaciones en tres niveles de abstracción:

 Modelo: representa la lógica de negocios. Es el encargado de

El diagrama de la Figura 1 muestra el funcionamiento del patrón MVC.

Figura 1. Funcionamiento del Patrón MVC

1) El usuario solicita o realiza un evento en la aplicación.

2.3. Aplicaciones Web

Este tipo de aplicaciones se basan en la arquitectura Cliente-Servidor, y

Figura 2. Arquitectura de tres capas de una aplicación Web

El navegador (capa cliente) accede a una interfaz conformada por páginas

En el servidor de aplicaciones se ejecuta el sistema responsable de:

 Generar las interfaces de usuario (páginas Web) que son enviadas a

En la capa de persistencia normalmente se encuentra en funcionamiento un

2.3.2. Características de las aplicaciones Web

Figura 3. Logo del Framework Laravel

En el año 2001, el creador de Laravel Taylor Otewell vio la carencia de

Laravel 5.2 incorporó mejoras, mediante la adición de soporte de múltiples

El diagrama de la Figura 4 muestra la estructura de una aplicación en el

 Facades: Los facades proporcionan una interfaz “estática” a las

Figura 5. Framework Symfony.

Symfony está desarrollado completamente con PHP y ha sido probado con

La primera versión de Symfony fue publicado en Octubre de 2005 por Fabien