DESARROLLO DE UNA APLICACIÓN WEB PARA EL SEGUIMIENTO …

DESARROLLO DE UNA APLICACIÓN WEB PARA EL SEGUIMIENTO DEL SOPORTE TÉCNICO EN EMPRESAS DE OUTSOURCING DE IMPRESIÓN

DANIEL ALBERTO OCHOA GARCÍA DAVID ELÍAS CORREAL SÁNCHEZ

UNIVERSIDAD PILOTO DE COLOMBIA ESCUELA TIC

INGENIERÍA DE SISTEMAS BOGOTÁ D.C.

2018

DESARROLLO DE UNA APLICACIÓN WEB PARA EL SEGUIMIENTO DEL SOPORTE TÉCNICO EN EMPRESAS DE OUTSOURCING DE IMPRESIÓN

DANIEL ALBERTO OCHOA GARCÍA DAVID ELÍAS CORREAL SÁNCHEZ

TRABAJO DE GRADO

TUTOR: JUAN CARLOS NAVARRO BELTRÁN

UNIVERSIDAD PILOTO DE COLOMBIA ESCUELA TIC

INGENIERÍA DE SISTEMAS BOGOTÁ D.C.

2018

NOTA ACEPTACIÓN

CONTENIDO

INTRODUCCIÓN 3

1 ANTEPROYECTO...................................................................................... 4

1.1 DESCRIPCIÓN DEL PROBLEMA .................................................................. 4

1.2 PREGUNTA PROBLEMA ............................................................................... 5

1.3 JUSTIFICACIÓN ............................................................................................. 5

1.4 OBJETIVOS ................................................................................................... 7

1.4.1 OBJETIVO GENERAL .............................................................................. 7

1.4.2 OBJETIVOS ESPECÍFICOS .................................................................... 7

1.5 DISEÑO METODOLÓGICO ........................................................................... 7

1.5.1 MÉTODO CUANTITATIVO .......................................................................... 8

1.5.2 MÉTODO CUALITATIVO ............................................................................ 8

2 INVESTIGACIÓN, ANALISIS DE ARQUITECTURA Y METODOLOGÍA PARA EL DESARROLLO DE LA APLICACIÓN WEB ................................ 10

2.1 LENGUAJE DE PROGRAMACIÓN .............................................................. 10

2.1.1 ELECCIÓN DE LENGUAJE DE PROGRAMACIÓN............................... 15

2.2 FRAMEWORK .............................................................................................. 20

2.2.1 FRAMEWORKS DEL LADO DEL SERVIDOR ....................................... 21

2.2.2 FRAMEWORKS DEL LADO DEL CLIENTE ........................................... 23

2.2.3 ELECCIÓN DE FRAMEWORK DEL LADO DEL SERVIDOR ................ 24

2.2.4 ELECCIÓN DE FRAMEWORK DEL LADO DEL CLIENTE .................... 26

2.3 ARQUITECTURA ......................................................................................... 28

2.4 METODOLOGÍA DE DESARROLLO ............................................................ 30

3 IDENTIFICACIÓN DE PROBLEMÁTICAS ............................................... 34

3.1. PROBLEMÁTICAS SEGÚN CLIENTE ........................................................ 34

3.2 PROBLEMÁTICAS SEGÚN PROVEEDOR .................................................. 36

3.3 PROBLEMÁTICAS SEGÚN TÉCNICO ........................................................ 38

3.4 APLICACIONES SEMEJANTES .................................................................. 39

4 ESPECIFICACIÓN DE REQUISITOS DEL SISTEMA ............................. 43

4.1 INTRODUCCIÓN .......................................................................................... 43

4.1.2 Propósito ................................................................................................ 43

4.2 DESCRIPCIÓN GENERAL ........................................................................... 43

4.2.1. Perspectiva del Producto ....................................................................... 43

4.2.2. Funciones del Producto ......................................................................... 43

4.2.3. Características de los Usuarios ............................................................. 44

4.2.4. Restricciones ......................................................................................... 45

4.2.5. Suposiciones y Dependencias .............................................................. 45

4.3 ANALISIS DE REQUERIMIENTOS .............................................................. 46

4.3 REQUERIMIENTOS FUNCIONALES ........................................................... 47

4.4 REQUERIMIENTOS NO FUNCIONALES .................................................... 49

5 DISEÑO DETALLADO DEL SISTEMA..................................................... 53

5.1 DIAGRAMA DE CASOS DE USO ................................................................ 53

5.2 DIAGRAMAS DE ESTADOS ........................................................................ 54

5.2.1 Diagrama estados del técnico ................................................................ 54

5.2.2 Diagrama estados del usuario (Cliente, Técnico) ................................... 55

5.2.3 Diagrama de estados de la solicitud de soporte técnico ......................... 55

5.2.4 Diagrama estados del artículo ................................................................ 56

5.3 DIAGRAMAS DE SECUENCIAS .................................................................. 57

5.4 DIAGRAMA DE CLASES ............................................................................. 58

5.5 DIAGRAMA DE ENTIDAD RELACIÓN ......................................................... 59

5.6 DIAGRAMA DE ARQUITECTURA ............................................................... 61

5.7 DIAGRAMACIÓN DE LA APLICACIÓN (MOCKUPS) .................................. 61

6 DESARROLLO DE LA APLICACIÓN WEB .............................................. 62

6.1 APLICACIÓN DESARROLLADA VS APLICACIONES INVESTIGADAS ..... 62

6.2 CHECKLIST ................................................................................................. 67

6.3 HERRAMIENTAS DE DESARROLLO .......................................................... 67

6.5 BASE DE DATOS ......................................................................................... 71

6.6 GITHUB ........................................................................................................ 74

6.7 HOSTING ..................................................................................................... 75

7 PRUEBAS DE LA APLICACIÓN .............................................................. 76

7.1 CASOS DE PRUEBA ................................................................................... 76

7.2 PRUEBAS ADUITS DE GOOGLE ................................................................ 78

TRABAJO FUTURO .................................................................................... 85

CONCLUSIONES ............................................................................................... 86

10 BIBLIOGRAFÍA ...................................................................................... 89

LISTA DE FIGURAS

Figura 1. Comparación de tendencias entre PHP, Java, Perl, ASP.NET, CFML en TODO EL MUNDO ................................................................................................. 16 Figura 2. Comparación de tendencias entre PHP, Java, Perl, ASP.NET, CFML en COLOMBIA ............................................................................................................ 16 Figura 3. Comparación de tendencias entre PHP, Python, JavaScript, ASP.NET, Java en TODO EL MUNDO ................................................................................... 17

Figura 4. Comparación de tendencias entre PHP, Python, JavaScript, ASP.NET, Java en COLOMBIA .............................................................................................. 17

Figura 5. Porcentaje de sitios web usando lenguajes de programación al lado del servidor .................................................................................................................. 19 Figura 6 . Cuadro comparativo de frameworks contra aprendizaje fácil, velocidad, popularidad acorde a Google ................................................................................. 24 Figura 7. Numero de descargas de los frameworks ............................................... 25 Figura 8. Comparación de tendencias entre Bootstrap, Foundation, Skeleton, Topcoat, Uikit en COLOMBIA ................................................................................ 27 Figura 9. Comparación de tendencias entre Bootstrap, Foundation, Skeleton, Topcoat, Uikit en TODO EL MUNDO ..................................................................... 27 Figura 10. Arquitectura Cliente-Servidor Multinivel en tres capas.......................... 29

Figura 11. Modelo en cascada ............................................................................... 31 Figura 12. Diagrama de Casos de Uso .................................................................. 53

Figura 13. Diagrama estados del técnico ............................................................... 54 Figura 14. Diagrama de estados del usuario (Cliente, Técnico) ............................ 55 Figura 15. Diagrama de estados de la solicitud de soporte técnico ....................... 56

Figura 16. Diagrama estados del artículo .............................................................. 57 Figura 17. Diagrama de clases .............................................................................. 58 Figura 18. Diagrama entidad-relación .................................................................... 59

Figura 19. Diagrama arquitectura .......................................................................... 61

Figura 20. Esquema general de la arquitectura de la aplicación ........................... 68 Figura 21. Carpeta controladores .......................................................................... 69 Figura 22. Carpetas modelos ................................................................................. 69 Figura 23. Carpetas de vistas ................................................................................ 69 Figura 24. Carpeta assets ...................................................................................... 70

Figura 25.Carpeta config ....................................................................................... 71 Figura 26. Monitor de ClearDB - Heroku ................................................................ 73 Figura 27. Backup a la base de datos .................................................................... 73 Figura 28. Formato de casos de prueba ................................................................ 77 Figura 29. Resultados evaluación de los casos de prueba .................................... 78

Figura 30.Resultados auditoria .............................................................................. 79

Figura 31. Resultados rendimiento ........................................................................ 79

Figura 32. Oportunidades de mejora de rendimiento ............................................. 80 Figura 33. Auditorias aprobadas de rendimiento ................................................... 80

Figura 34. Auditoria de aceptación de HTTPS ....................................................... 81 Figura 35. Auditorias fallidas web progresiva......................................................... 81 Figura 36. Accesibilidad Auditorias fallidas ............................................................ 82 Figura 37. Auditorias aprobadas de accesibilidad.................................................. 83

Figura 38. Auditorias fallidas de mejores prácticas en el código............................ 83 Figura 39. Auditorias aprobadas de mejores prácticas de código.......................... 83 Figura 40. Auditorias fallidas de SEO .................................................................... 84 Figura 41. Auditorias aprobadas de SEO .............................................................. 84

LISTA DE TABLAS

Tabla 1. Ejemplo de tiempos establecidos en los SLA por cada ciudad .................. 6

Tabla 2. Descripción y funciones de los usuarios del sistema ............................... 44 Tabla 3. Requerimientos a desarrollar ................................................................... 46 Tabla 4. Requerimientos para desarrollo futuro ..................................................... 46 Tabla 5. Requerimientos funcionales de la aplicación. .......................................... 47 Tabla 6. RNF001 Portabilidad ................................................................................ 50

Tabla 7. RNF002 Mantenibilidad............................................................................ 50

Tabla 8.RNF003 Disponibilidad ............................................................................. 51 Tabla 9. RNF005 Seguridad .................................................................................. 51

Tabla 10. Usabilidad .............................................................................................. 52 Tabla 11. Lista de chequeo del 11 de mayo .......................................................... 67 Tabla 12. Herramientas utilizadas en el sistema.................................................... 68

TABLA DE CUADROS Cuadro 1. Cuadro comparativo entre PHP, ASP.NET, JSP, PERL, COLDFUSION y PYTHON ............................................................................................................. 18

Cuadro 2. Funcionalidades vs aplicaciones similares ............................................ 41 Cuadro 3. Recopilación de requerimientos encontrados ....................................... 42

TABLA DE ANEXOS

ANEXO A. Encuesta Profamilia Andrés Riaño ANEXO B. Encuesta Proveedor Andrés Delgado Abka ANEXO C. Encuesta Técnico Abka ANEXO D. Requerimientos Funcionales ANEXO E. Casos de Prueba ANEXO F. Diccionario de datos ANEXO G. Diagramas de secuencia ANEXO H. Diseño - Mockup de la aplicación ANEXO I. Manual de Usuario-Capturas de la aplicación ANEXO J. CheckList casos de uso - diseño – desarrollo ANEXO K. Manual de instalación

3

INTRODUCCIÓN Cada día los servicios de tercerización o mejor conocidos como outsourcing, están aumentando en las empresas, los cuales pueden implementarse en las áreas de recursos humanos, contabilidad y finanzas, logística, servicios de TI (Tecnología de la Información), entre otras, con el fin de reducir costos en la operación, tener disponible personal especializado para la ejecución de sus procesos y poder así, enfocarse completamente a la actividad principal que genera ganancias. En los últimos años se ha trabajado con empresas de outsourcing de impresión, en las cuales se han notado falencias en el préstamo de sus servicios, en este documento se describirán las falencias observadas que se están presentado en estos servicios y la investigación realizada para el levantamiento de información, a través de entrevistas a personal que trabaja en las empresas de outsourcing, como también al cliente de una de estas empresas. Por lo anterior es necesario crear una aplicación web, que cumpla con la mayoría de los requerimientos encontrados y con esto se pueda aprobar o no, la hipótesis planteada en el diseño metodológico. Durante el documento, también se describe el proceso que se realizó para escoger el lenguaje de programación, el framework del lado del servidor y del cliente, la metodología de desarrollo, la arquitectura, que se acogiera a las necesidades del proyecto y las exigencias de los requerimientos. Posteriormente se describirá el diseño de la aplicación, con sus respectivos diagramas UML (Lenguaje Unificado de Modelado), con el fin de mostrar en forma clara, lo que se pretende desarrollar, para que en el siguiente capítulo de desarrollo se pueda mostrar la aplicación funcionando y con las pruebas respectivas. En el último capítulo, se describirá los resultados de la hipótesis, para determinar si esta hipótesis se aprueba o no, según las investigaciones realizadas a lo largo del documento.

4

1 ANTEPROYECTO Este capítulo describe el problema identificado, la justificación, los objetivos y el diseño metodológico para la realización del proyecto.

1.1 DESCRIPCIÓN DEL PROBLEMA

Cada día los servicios de tercerización están creciendo en diferentes áreas de una empresa, con el fin de dedicarse a su actividad principal, según la revista Dinero, “Colombia en los últimos 5 años ha presentado un aumento de cerca de un 60% en la contratación de estos, como un fenómeno que ha convertido a la industria en un sector más productivo y menos derrochador, gracias al valor agregado que ofrece este tipo de servicios”1. Tomando un caso de estudio aplicado a los servicios de outsourcing de impresión. Por ejemplo, el modelo de negocio que maneja Ricoh y Abka, estos modelos están enfocados en los préstamos de impresoras, repuestos y consumibles (tóner, unidad fusora, entre otros), mantenimiento preventivo, soporte técnico en sitio (mantenimiento correctivo).

Con base en la experiencia de los últimos años en empresas prestadoras de servicios de outsourcing de impresión, se han evidenciado falencias en la prestación de estos servicios. Por ejemplo, en el caso cuando una impresora de un cliente está fuera de servicio por un indeterminado tiempo, en muchas ocasiones más de lo establecido en los acuerdos de niveles de servicio SLA (Service Level Agreement), esta falencia está comprometiendo el servicio que presta el cliente en áreas sensibles como lo es: (caja, contabilidad, gerencias, entre otras). Podemos observar que por parte del prestador de los servicios pueden tener acciones legales en contra por el incumplimiento de los SLA, si estos incumplimientos se presentan constantemente, esto puede generar inconformidades en los clientes por consiguiente una mala imagen.

Debido a las falencias de control y gestión que se presentan en los servicios técnicos, han ocasionado que la calidad de los estos servicios no sea la mejor provocando inconformidades por parte de los clientes. En los cuales podemos encontrar las siguientes problemáticas:

1. El Incumplimiento en los tiempos de atención que se acordaron entre el proveedor con el cliente.

2. Información en tiempo real del estado de la solicitud del cliente.

1

REVISTA, Dinero. El servicio de outsourcing o tercerización, Artículo, Revista Dinero, {En línea}. Fecha.

{07/23/2014}. Disponible en: http://www.dinero.com/especiales-comerciales/outsourcing/articulo/servicio-outsourcing-tercerizacion-colombia/199002

http://www.dinero.com/especiales-comerciales/outsourcing/articulo/servicio-outsourcing-tercerizacion-colombia/199002



5

3. Seguimiento de la calidad del servicio de los técnicos. 4. Localización en tiempo real de los técnicos. 5. Optimización de rutas de los técnicos.

1.2 PREGUNTA PROBLEMA

¿Cómo realizar el seguimiento a partir de una aplicación web a procesos del servicio técnico en empresas de outsourcing de impresión, con el fin de evitar incumplimientos en los SLA (Niveles de Acuerdo de Servicio)?.

1.3 JUSTIFICACIÓN

Los motivos que nos llevaron a investigar las problemáticas, en la prestación servicios técnicos en la modalidad de outsourcing impresión, fue la demora en los tiempos de respuesta de los servicios, esto a ocasionando diferentes malestares en las empresas que tiene contratado estos servicios, al evidenciar que al adquirir un servicio el fabricante o el comercializador como (ABKA, RICOH, etc.),está obligado a responder al usuario por cualquier defecto que presente, ya sea dentro de un periodo de garantía o un contrato establecido dentro un periodo de tiempo supliendo por completo su necesidad.

“El outsourcer, además, está obligado a rendir al comitente cuenta detallada y justificada, en los plazos establecidos, de todos los servicios y actividades Subcontratados” 1

Actualmente muchas de estas empresas de outsourcing están adaptando la medición de tiempos por medio de SLA (Niveles de acuerdos de servicios), que consiste en dar un tiempo determinado en el cual será atendido los requerimientos de los clientes, esto va ligado por medio de un contrato firmado por ambas partes, los cuales tienen cláusulas de incumplimiento afectando económicamente la empresa prestadora de estos servicios, además de generar pérdidas de clientes potenciales.

“La prestación del servicio, lo cual lleva aparejados unos deberes de diligencia, ciertos mecanismos de control establecidos contractualmente y sanciones económicas ante posibles deficiencias en el mismo.”1

1 MERY NICOLASA MARTÍNEZ SUÁREZ, EL CONTRATO DE OUTSOURCING EN LA LEGISLACIÓN COLOMBIANA ,Universidad de la Costa, 2013, p. 110

6

A continuación, relacionaremos un ejemplo de documento de cumplimiento de los SLA incluidos dentro de un contrato de outsourcing de impresión por el contratista:

EQUIPOS, UBICACIONES Y TIEMPOS DE RESPUESTA. El CONTRATISTA deberá cumplir con los ANS descritos a continuación:

SLA: Tiempo de Respuesta promedio en días hábiles (Lunes a Viernes de 8:00 am a 5:30 pm y Sábados 8AM a 12M)

Las solicitudes o requerimientos relacionados con: Instalación, movimientos, adiciones o retiros de equipos usados, deberán realizarse con 5 días hábiles de anticipación.

Tabla 1. Ejemplo de tiempos establecidos en los SLA por cada ciudad

Como podemos observar en la Tabla 1, vemos que cada ciudad tiene unos niveles de acuerdo de servicio "SLA", los cuales por diferentes motivos no se están cumpliendo. Los canales de comunicación que actualmente tienen proveedores como ABKA y RICOH son por medio telefónico y correo electrónico en el cual no se puede hacer un seguimiento a cada requerimiento en tiempo real haciendo difícil la comunicación entre cliente y proveedor. Con la investigación se buscará determinar porque muchos de estos tiempos no se cumplen, cuáles son los factores causantes de estos retrasos, cuáles son los SLA que más se incumplen con el fin de mejorar estos procesos de soporte técnico.

La medición de la calidad del servicio de cada técnico se maneja actualmente con encuestas lo que en realidad no es tan exacta, debido a que puede que haya retrasos justificados para la demora de una solución a un requerimiento, como también hay demoras que no son justificadas, estas justificaciones son difíciles de establecer debido a que la empresa no tiene mucho contacto con el técnico, debido que no es posible tener una localización real de donde se encuentra el técnico.

Ítem Modelo Ciudad Serial

SLA ON-SITE (Tiempo de

Respuesta-Horas Hábiles)

SLA SUMINISTRO (Tiempo de

entrega-Días Hábiles)

SLA PARTES (Tiempo de

Entrega-Días Hábiles)

1 SP5200S Bogotá S9029#### 8 3 días 3 días

2 SP5200S Popayán S9029#### 16 5 días 5 días

3 SP5200S Florencia S9029#### 24 5 días 5 días

4 SP5200S Quibdó S9029#### 32 5 días 5 días

5 SP5200S Apartadó S9029#### 24 6 días 6 días

Fuente autores

7

Con la aplicación web se buscará corregir estos fallos, la motivación principal que se tiene para realizar este proyecto es adquirir experiencia sobre el tema de investigación que es aplicaciones web, en el cual se aplicará temas vistos en diferentes materias las cuales en los últimos años sean inscrito en la Universidad Piloto de Colombia adicionalmente lo investigado durante la elaboración del proyecto.

Otra motivación es que, si se obtiene una buena investigación tanto de las problemáticas en los acuerdos de servicio y del tema de investigación, adicionalmente si se logra mejorar las problemáticas presentadas anteriormente descritas, el proyecto puede ser una oportunidad de negocio, debido a que se puede vender a Ricoh, Abka o cualquier otra empresa de outsourcing de impresión. 1.4 OBJETIVOS A continuación se presentan los objetivos a desarrollar durante el proyecto.

1.4.1 OBJETIVO GENERAL Desarrollar una aplicación WEB que permita realizar el seguimiento de los procesos de soporte técnico en empresas de outsourcing de impresión (Caso de estudio Ricoh y Abka).

1.4.2 OBJETIVOS ESPECÍFICOS

Investigar sobre el desarrollo de aplicaciones web, con el fin determinar la arquitectura y la metodología más apropiada para el desarrollo de la aplicación.

Identificar las problemáticas de las empresas prestadoras de servicios de impresión con respecto a los SLA.

Analizar todos los requerimientos tanto funcionales y no funcionales de la aplicación de acuerdo a las problemáticas identificadas en los acuerdos de servicio (SLA), en empresas outsourcing de impresión como Ricoh y Abka.

Diseñar una aplicación web que cumpla con los requerimientos analizados y la arquitectura escogidos.

Realizar la aplicación WEB acorde al diseño planteado. 1.5 DISEÑO METODOLÓGICO El método a utilizar durante la ejecución del proyecto será mixto, debido a que se utilizará el método cuantitativo y cualitativo, para utilizar las fortalezas de ambos tipos de investigación, tratando de minimizar sus de debilidades, al terminar el

8

levantamiento de información, el análisis e interpretación de resultados, se procederá a la comprobación de la hipótesis, para aprobarla o desaprobarla, estos resultados se describen en el capítulo resultados e impacto esperados.

1.5.1 MÉTODO CUANTITATIVO Formulación de la hipótesis: Es posible mejorar los procesos del servicio técnico en empresas de outsourcing de impresión, con el fin de evitar incumplimientos en los SLA (Niveles de Acuerdo de Servicio), a partir de una aplicación web.

Levantamiento de información: Con el proceso de investigación cuantitativo se pretende levantar la mayor cantidad de información de la siguiente manera, con el fin de obtener un mejor resultado en la siguiente etapa que es el análisis e interpretación de resultados.

Entrevistas con José Andrés Riaño, director de TI de Profamilia-Colombia.

Entrevista con Andrés Delgado, gerente Abka-Colombia

Entrevista con Hoovert Andrés Toro, técnico de Soporte Abka. Para investigar las problemáticas prestadas en el servicio técnico por parte de la empresa Abka.

Observaciones que se realizan en la empresa Profamilia-Colombia por parte de Daniel Ochoa.

Análisis e interpretación de resultados: Con la información obtenida en la anterior etapa, se buscará de establecer cuáles son las grandes falencias que hay en el soporte técnico prestado por Ricoh y Abka, esto nos permite diseñar una mejor aplicación web. Cuantitativamente permite comprender lo siguiente:

Con que frecuencia se incumple cada acuerdo de servicio (SLA).

Cuál es el beneficio de implementar el proyecto en una empresa de outsourcing de impresión.

A cuantas empresas podría beneficiar el proyecto.

Medir la calidad en la prestación del servicio técnico.

Comprobación de la hipótesis: Según el análisis e interpretación de los datos se comprobará o desaprobará la hipótesis planteada. Difusión de resultados: Se presentará y se divulgaran los resultados por medio de la presentación y documento del proyecto de grado.

1.5.2 MÉTODO CUALITATIVO

9

Trabajo de campo Se recopilará información documental como:

Leyes o decretos en Colombia que regulen las inconformidades que un cliente tenga con el servicio de un proveedor.

Artículos de prensa donde muestren estadísticas o porcentajes de demandas o fallos en la prestación de servicios en outsourcing.

Información recogida a través de los RAI, o libros, tesis y artículos de referencia.

Identificación de patrones culturales Cualitativamente permite comprender:

Establecer cuál es la necesidad de la solución de la aplicación WEB en el mejoramiento de los procesos de soporte técnico en las empresas de outsourcing de impresión:

Determinar cómo se puede mejorar los procesos de soporte a través de la aplicación WEB.

Cuales SLA son más costosos al momento incumplirlos de acuerdo a las leyes o contrato establecido.

Como se puede mejorar la experiencia del cliente que tiene con el servicio técnico.

10

2 INVESTIGACIÓN, ANALISIS DE ARQUITECTURA Y METODOLOGÍA PARA EL DESARROLLO DE LA APLICACIÓN WEB

En este capítulo, se describe las ventajas y desventajas de algunos lenguajes de programación web, frameworks del lado del servidor y frameworks del lado del cliente, posteriormente, se analizará cada uno de estos lenguajes y frameworks, con el fin de identificar cuales se ajustan a las necesidades del proyecto, entre las necesidades más importantes que tenemos al escoger esto, es la curva de aprendizaje y una amplia documentación debido al corto tiempo en que se debe desarrollar el proyecto, posteriormente se describirá el análisis de la arquitectura y metodología de desarrollo.

2.1 LENGUAJE DE PROGRAMACIÓN Es un lenguaje artificial normalmente en inglés, para definir una secuencia de comandos, el cual una persona con conocimientos en programación puede comprender al momento de leer o escribir, al compilar se convierten en código binario interpretable por maquinas como computadores o servidores. Estos lenguajes de programación están estructurados por símbolos, palabras reservadas, reglas sintácticas y semánticas, propias de cada lenguaje. PHP: Según Ángel Cobo “es un lenguaje interpretado del lado del servidor que surge dentro de la corriente denominada código abierto (open source). Se caracteriza por su potencia, versatilidad, robustez y modularidad”1, Es ampliamente usado (cerca de 20 millones de sitios web) y diseñado especialmente para desarrollo web, según Luiggi Santa Maria2, entre sus principales características se encuentran:

Es un lenguaje multiplataforma, tiene la facilidad de ejecutarse en todos los principales sistemas operativos como Windows, Mac OS, Linux y variantes de UNIX. Se puede usar con todos los principales Servidores web.

Capacidad de conexión a múltiples motores de bases de datos las cuales se destacan MongoDB, MySQL, SQLite, SQLServer, PostgreSQL, entre otros.

Se puede expandir su potencial utilizando una gran cantidad de extensiones o módulos en su mayoría gratuitos creados por una amplia cantidad de colaboradores.

1 ÁNGEL COBO, PATRICIA GÓMEZ., PHP y MySQL. Tecnologías para el desarrollo de aplicaciones, Díaz de

Santos 2015 2 SANTA MARIA, Luiggi. PHP vs. ASP/ASP.NET, 12 Ventajas de la Programación PHP que Debes

Saber, Artículo, {En línea}. Fecha. {24/07/2014}. Disponible en: http://www.staffcreativa.pe/blog/ventajas-programacion-php/

11

Si se tiene conocimientos en C y Java, se puede desarrollar fácilmente en PHP. Este lenguaje es mucho más simple que el resto así que los resultados son excelentes.

Posee una amplia documentación desde un su página principal, con explicación y ejemplos.

Permite aplicar programación orientada a objetos (en su última versión PHP7)

En libre, lo cual es de fácil acceso para todos.

Sean desarrollado múltiples Frameworks que utilizan patrones de diseño como Modelo Vista Controlador, y facilitar el desarrollo de páginas web con PHP.

Los principales enfoques de los usuarios a elegir PHP son su estabilidad, flexibilidad y Velocidad.

Aunque PHP es extremadamente fácil de aprender para alguien que no conoce el lenguaje, también ofrece características avanzadas para programadores profesionales. ASP.NET (Active Server Pages): Sucesor de ASP, mejorado por Microsoft y potenciado para desarrollar aplicaciones web, cabe destacar que ASP.NET no es un lenguaje de programación, ni un servidor web, es una plataforma, esta trabaja de la mano con .NET framework, heredando todas las características, como cualquier aplicación .NET (Aplicación de escritorio, aplicación móvil con Xamarin, entre otras). Según Ángel Arias1, la ventaja de ASP.NET es que un código puede ser escrito en varios lenguajes de programación como C#, C+, Visual Basic .NET, reutilizando código entre estos lenguajes, esta quizás es la mayor diferencia entre ASP y ASP.NET., ya que ASP solo puede estar escrito en VBScript adicionalmente ASP no es orientado a objetos. Si se quiere trabajar con ASP.net e IIS, se debe contemplar un costo para adquirir una licencia de un servidor Microsoft Windows y Microsoft SQL Server y futuras actualizaciones. Los costos de licencia para Microsoft pueden aumentar progresivamente, si la aplicación web obtiene buen posicionamiento en la web y existe la necesidad de ejecutar la aplicación en múltiples servidores o requiere características del servidor como por ejemplo el clúster de servidores, modo de espera activo y el equilibrio de carga. Java: Según Ángel Arias2, este lenguaje tiene como propósito poderse ejecutar en cualquier plataforma o dispositivo, ya sea computadores, servidores, Smartphone, televisores, microondas, neveras, etc. Gracias a su JVM (Java Virtual Machine) la

1 ARIAS, Ángel. Aprende a Programar ASP.NET y C#, 2ª Edición, Editorial desconocida, 2008.

2 ARIAS, Ángel. Aprende a programar con Java, 1ª edición, Editorial desconocida, 2007.

12

cual funciona como traductor de instrucciones entre la aplicación Java y el sistema operativo. Java esta subdividido en tres grandes distribuciones: .

J2SE o Java SE (Java 2 Standard Edition), orientada a un entorno de desarrollo de aplicaciones cliente – servidor, la cual funciona como base de la tecnología J2EE y de los servicios web en Java.

J2EE (Java 2 Enterprise Edition), la cual no es un producto sino un conjunto de especificaciones para un desarrollo profesional de aplicaciones empresariales, distribuidas en una arquitectura multicapa que se ejecuta en un servidor, está basado en estándares modulares y reusables como el EJB.

J2ME (Java 2 Micro Edition) está dedicado solo a dispositivos pequeños como teléfonos móviles, tarjetas inteligentes, neveras, etc.

Con la tecnología J2EE y J2SE se permite realizar aplicaciones para web, aunque puede ser un poco complicado desarrollar si no se utiliza algún framework como Spring MVC, Struts 2, Hibernate, entre otros, que permiten hacer un poco más fácil el desarrollo, integrando seguridad, modularidad, acoplamiento flexible, inyección de dependencias. JSP (Java Server Pages): Es el componente de leguaje de script del estándar J2EE, permite crear páginas web dinámicas basadas en HTML y XML, es similar a PHP pero usa el lenguaje de programación Java con lo cual hereda algunas de sus ventajas como por ejemplo:

Java es un lenguaje dinámico y fácil de portar a otros sistemas operativos.

Se puede utilizar el manejo de excepciones de Java.

Puede tener acceso a todas las API de Java, incluso tiene acceso a JNDI, JDBC, EJB y otros componentes de Java.

JSP también puede incluir conexiones a la base de datos.

Se puede compartir información entre páginas utilizando objetos de solicitud y respuesta.

Permite separar la capa de presentación con la capa de lógica de negocio, para implementar fácilmente Modelo Vista Controlador, lo cual lo hace fácil de mantener.

Perl (Practical Extraction and Report Language): Según Natsys1, es un lenguaje que permite manipular y navegar fácilmente por archivos de texto de manera eficiente, sin embargo este lenguaje ha evolucionado tanto que hoy se

1 Natsys, Introducción a la programación en Perl, CGI y JavaScript: Con código fuente de ejemplo y

ejercicios. 1ª edición, editorial desconocida, 2018.

13

considera como una herramienta de programación en internet, administración de sistemas y redes UNIX. Su sintaxis de código es tan similar a Shell, Sed, AWK o C, que cuenta con herramientas para traducir código Sed y AWK a Perl de manera automática, se puede conseguir una enorme cantidad de módulos para incluir en las nuevas aplicaciones si dificultad, además contando que Perl esa protegido por una licencia artística, lo cual permite su libre distribución, sin costo alguno. ColdFusion: Según Ben Forta1, es un servidor de aplicaciones conformado por varios componentes de software (aplicaciones en Windows, daemons en Linux, Solaris y HP-UX), este servidor analiza lee, compila y procesa las instrucciones dadas por el desarrollador, estas instrucciones están escritas en un lenguaje propio de ColdFusion denominado ColdFusion Markup Language (CFML), el cual amplia el lenguaje HTML agregando etiquetas con las siguientes capacidades:

Leer datos y actualizar datos en bases de datos y tablas

Crear páginas dinámicas impulsadas por datos

Realizar procesamiento condicional

Rellenar formularios con datos en vivo

Envíos de formularios de proceso

Leer y escribir cookies del lado del cliente

Entre otros, dentro de ColdFusion se encuentra un servidor completo de J2EE (Java 2 Enterprise Edition) que potencializa el procesamiento, pero no es necesario saber Java para desarrollar en ColdFusion, debido a que utiliza es la plataforma y no el lenguaje de programación, la plataforma Java provee los medios necesarios para:

Crear aplicaciones robustas y altamente escalables

Acceder a todo tipo de bases de datos

Interactuar con sistemas heredados

Dar Soporte de dispositivos móviles

Con estas características, ColdFusion permite crear sitios altamente interactivos y ricos en datos, a continuación estas son algunas de sus ventajas:

Es rápido, gracias a su arquitectura escalable, múltiple y basada en el servicio.

Se construye en la arquitectura java estándar de la industria, y apoya todas las principales normas e iniciativas.

1 FORTA, Ben. Introducing ColdFusion, {En línea}. {29 febrero de 2018} disponible en:

http://www.adobepress.com/articles/article.asp?p=31062&seqNum=4

14

Viene con todos los ganchos necesarios para enlaces con casi cualquier aplicación de base de datos y cualquier otro sistema externo.

Python: según Eugenia Bahit1, es un lenguaje de programación interpretado, su mayor fortaleza está en la escritura de código debido a que es fácil de entender porque es cercano al lenguaje natural, semejante a un pseudocódigo. Es multiparadigma lo cual quiere decir que soporte programación imperativa, orientada a objetos y funcional, esto será de gran ayuda al momento de realizar un mantenimiento futuro a la aplicación, por lo fácil de aprender y si se aplican bien los conceptos el bajo acoplamiento. Es multiplataforma como Windows, Mac, diferentes distribuciones de Linux, entre otras Utilizando frameworks especializados como Django, TurboGears, web2py entre otros, se puede desarrollar de manera rápida un sitio web tradicional utilizando un patrón arquitectónico como MVC (Modelo – Vista - Controlador), sin embargo para crear aplicaciones Python con estos frameworks se debe tener en cuenta: “• Para crear aplicaciones escalables y mantenibles, que guarden un diseño arquitectónico coherente, es imprescindible tener un excelente dominio de la programación orientada a objetos y amplios conocimientos sobre patrones arquitectónicos y patrones de diseño. • Como todo marco de trabajo, poseen sus propios métodos así como una sintaxis y pseudo-lenguaje propios, los cuales demandan invertir un tiempo considerable en aprender a utilizarlos.”2 JavaScript: Según Preston Prescott3, es utilizado frecuentemente en el lado del cliente, es útil práctico y está disponible en la mayoría de navegadores web en sistemas operativos como Windows, Linux o Mac, con el fin de desarrollar aplicaciones o sitios web más interactivos y dinámicos con mayor capacidad de respuesta. También para controlar el navegador, permitir una comunicación asíncrona con el servidor, modificar el contenido de la página web de forma dinámica, JavaScript puede ser utilizado también para el desarrollo de video juegos, aplicaciones móviles y aplicaciones de escritorio. Las funciones que permite este leguaje son:

Crear variables y arreglos para almacenar datos.

Realizar operaciones lógicas y matemáticas.

Crear funciones.

Guardar y recuperar cookies.

1 BAHIT, Eugenia. Curso: Python para Principiantes, 1ª edición, PYTHON, sefeCREATIVE, 2012,

136p 2 BAHIT, Eugenia. Curso: Python para Principiantes, 1ª edición, PYTHON, sefeCREATIVE, 2012,

136p. 3 PRESCOTT, Preston. La programación JavaScript, 1ª edición, País desconocido, Babelcube,

Inc., 2016, 110p.

15

Hacer uso práctico de la programación orientada a objetos, ya que es estructurado.

Es interpretado, no se compila para poder ejecutarse. JavaScript es un lenguaje que permite desarrollar aplicaciones grandes, como google docs., Facebook, twitter e incluso se puede ejecutar al lado del servidor con un framework por ejemplo NodeJS. JavaScript parece ser el único lenguaje en su campo, complementándose con leguajes como JQuery o Ajax para el manejo de datos e interacción con la interfaz gráfica, tan abundante en frameworks como en documentación.

2.1.1 ELECCIÓN DE LENGUAJE DE PROGRAMACIÓN Según el análisis de tendencias realizado en Google Trends la cual es una herramienta que permite comparar las búsquedas o tendencias durante cierto periodo de tiempo, tanto en las figuras 1,2,3 y 4, podemos evidenciar como en estos últimos cinco años, las personas están buscando información sobre los lenguajes de programación, en los cuales se destacan dos, PHP y JavaScript, estos dos lenguajes de programación muy conocidos en el desarrollo de aplicaciones web, con grandes características y funcionalidades, se puede usar los dos lenguajes en conjunto, obteniendo buenos resultados en el desarrollo de la aplicación.

16

Figura 1. Comparación de tendencias entre PHP, Java, Perl, ASP.NET, CFML en TODO EL MUNDO

Figura 2. Comparación de tendencias entre PHP, Java, Perl, ASP.NET, CFML en COLOMBIA

Fuente Figura generada con Google Trends 17/02/2018

Fuente Figura generada a partir de Google Trends 17/02/2018

17

Figura 3. Comparación de tendencias entre PHP, Python, JavaScript, ASP.NET, Java en TODO EL MUNDO


Figura 4. Comparación de tendencias entre PHP, Python, JavaScript, ASP.NET, Java en COLOMBIA

Fuente Figura generada con Google Trends 17/02/2018

18

El Cuadro 1, compara los lenguajes de programación web PHP, ASP.NET, JSP, PERL, COLDFUSION y PYTHON descritos anteriormente, de este cuadro se puede evidenciar que: En la curva de aprendizaje, PHP y ASP.NET se destaca porque tienen un corto tiempo para aprender sobre los demás lenguajes, debido a que se cuenta con conocimientos en Java y el IDE Visual Studio. La documentación en la mayoría de lenguajes es alta, pero en ColdFusion tomo mucho tiempo, al momento de encontrar información y características del lenguaje. En el alojamiento web PHP y PERL son compatibles con casi todos los servidores de alojamiento incluyendo Heroku, mientras los demás se debe buscar un hosting con ciertas características especiales, esto puede incurrir en un aumento de costos. El soporte de MySQL al tenerlo nativo no se necesita agregar más librerías o clases para integrar PHP, PERL o COLDFUSION con MySQL, esto puede evitar gastar tiempo en la integración de estos dos componentes (Lenguaje de programación y base de datos).

Cuadro 1. Cuadro comparativo entre PHP, ASP.NET, JSP, PERL, COLDFUSION y PYTHON

De acuerdo a la Figura 6, se observa que el lenguaje PHP es utilizado por el 81.7% de todos los sitios web, comparándolo con otros leguajes del lado del servidor como ASP.NET, java, ColdFusion, Perl, JavaScript, entre otros.

CARACTERÍSTICA PHP ASP.NET JSP PERL COLDFUSION PYTHON

Curva de aprendizajeBaja, sintaxis

semejante a C++ o Java

Baja, si se tiene

conocimientos en el

IDE Visual Studio

Media si se tiene

conocimientos en Java

y programación

orientada a objetos

Alta Alta

Media si se tiene

conocimientos en la

sintaxis, y programación

orientada a objetos

Documentación Alta ALTA ALTA ALTA

MEDIA, Fue difícil conseguir

las características desde otro

sitio que no fuera la pagina

principal de adobe

ALTA

Alojamiento web

Compatible con la

mayoría de los

servidores de

alojamiento,

incluyendo Heroku

Se requiere servidor

dedicado, o que

tengan las

características que

soporten la aplicación


dedicado, o que tengan

las características que


Compatible con la

mayoría de los

servidores de

alojamiento,

incluyendo Heroku

con plugin adicional


dedicado, o que tengan las

características que soporten

la aplicación


dedicado, o que tengan las

características que


Soporte MySQL

Nativo, sin necesidad

de controladores

adicionales

Se necesita importar

librerías


libreríasNativo Nativo


librerías

Fuente autores 28/03/2018

19

Figura 5. Porcentaje de sitios web usando lenguajes de programación al lado del servidor

Según el resultado de la investigación y las restricciones de tiempo para el desarrollo de este proyecto de grado, se ha decido escoger el lenguaje PHP, ya que el 81.7% de las páginas web actualmente están creadas en PHP, esto un buen respaldo y referencia de que se puede realizar aplicaciones de gran tamaño, estables con un gran número de usuarios que las consultan todos los días, además en los últimos cinco años JavaScript y PHP, según las estadísticas de Google Trends, se ha posicionado como los lenguajes más populares, lo cual nos garantiza que se encontrara buena documentación y soporte,

En comparación de PHP con los demás lenguajes de programación podemos ver lo siguiente.

PHP vs ASP.NET: Una de las diferencias es que PHP es de código abierto y se puede ver que hay publicada mucha más información y manuales que en ASP.NET. Adicionalmente también encontramos numerosas librerías y recursos que crean los usuarios de PHP que se pueden utilizar para facilitar la programación. Los costos para desarrollar aplicaciones en ASP.NET pueden ser más elevados, por ejemplo en el IDE de Visual Studio o el servidor hosting puede ser más costoso debido a que se debe buscar que el sistema operativo sea Windows.

PHP vs Java: PHP contiene un lenguaje de tipado débil lo cual lo hace más flexible y fácil de entender y programar en comparación con Java, encontramos que es un lenguaje de tipado fuerte, lo cual requiere declaraciones explícitas para funcionar y respaldado por el compilador. Si estas declaraciones no se cumplen, el

Fuente ScienceDirect, Analysis and Practical Application of PHP Frameworks in Development of Web Information Systems. Porcentaje de sitios web usando

lenguajes de programación al lado del servidor

20

compilador fallará y el programa no funcionará hasta que se resuelvan todos los errores, lo cual lo hace más demorado para programar.

PHP vs Perl: Perl es un buen lenguaje de programación para web, quizás es el mayor rival para PHP, lo cual encontrar una buena diferencia es difícil, ya que su sintaxis es semejante, pero viendo las tendencias de los últimos años en búsquedas como se ve en las Figuras 1 y 2, PHP tiene un alto nivel de búsqueda lo cual puede garantizar que se encuentre documentación actualizada, foros y comunidades que resuelvan dudas.

PHP vs ColdFusion: ColdFusion a pesar de tener buenas características no tiene buena documentación lo cual hará la curva de aprendizaje difícil, por ejemplo fue difícil encontrar las características del lenguaje en un buen sitio, solamente se encontró la información desde su sitio web del creador Adobe, si lo comparamos con PHP el cual cuenta con gran cantidad de documentación y de colaboradores lo cual nos garantiza un buen soporte y una curva de aprendizaje fácil y rápida.

PHP vs Python: Python al igual que Java su tipado es fuerte y quiere amplios conocimientos en patrones arquitectónicos y de diseño, los cuales demandan tiempo en aprender a utilizarlos, y sacarle el máximo provecho.

PHP vs JSP: JSP requiere utilizar JEE2 (Java Enterprise Edition) que es un estándar de Java y se requeriría aprender del estándar, al igual que su tipado fuerte de Java.

2.2 FRAMEWORK Puede definirse como un marco de trabajo, su objetivo principal es facilitar el desarrollo de la aplicación, el framework contiene una estructura de módulos, que ayudan a desarrollar la aplicación web un poco más organizada y mantenible, debido a que normalmente estos frameworks están basados en algún patrón de desarrollo como MVC. Estos frameworks contienen librerías que se pueden utilizar y evitar así crear desde cero la funcionalidad, por ejemplo librerías de sesión para la seguridad de acceso a la aplicación y manejar perfiles de usuario, librerías para enviar correos electrónicos, plantillas de ejemplo que se pueden utilizar para desarrollar la interfaz de usuario un poco más rápido y fácil. Debido a la necesidad de agilizar el desarrollo de la página web se tuvo en cuenta la implementación de un framework, que nos garantizará un desarrollo más rápido y estructurado, de tal manera que sea seguro y óptimo.

21

2.2.1 FRAMEWORKS DEL LADO DEL SERVIDOR Teniendo en cuenta el lenguaje de programación PHP, seleccionado anteriormente, ahora se procederá a describir los frameworks de dicho lenguaje, los criterios de selección de este framework será también la documentación y la curva de aprendizaje, debido al corto tiempo en que se debe desarrollar el proyecto, adicionalmente desde el punto de ingeniería a tener en cuenta es que tenga soporte de del patrón de desarrollo MVC, seguridad, simple de entender (claro y limpio de código “basura”).

Codeigniter: Según F. Sierra, J. Acosta, J. Ariza Y M. Salas1, es un framework de aplicaciones web de código abierto, programación base PHP, que escribir código desde cero. Ofreciendo un amplio conjunto de bibliotecas para variedad de tareas, brindándonos una interfaz sencilla y la estructura lógica de acceso a estas bibliotecas. El patrón de desarrollo MVC (Modelo-Vista-Controlador) es el utilizado por Codeigniter y también se destaca por su velocidad en comparación con otros frameworks PHP. También podemos encontrar una serie de librerías cuya función es ayudar en el desarrollo de aplicaciones web y proponiendo una manera de desarrollarlas que se debe seguir para obtener buenos resultados de la aplicación. Esto es beneficioso para determinar una manera específica de codificar las páginas web y clasificar sus diferentes scripts, obteniendo un código organizado y sea más fácil de crear y mantener. Se relacionan las siguientes características:

Sistema basado patrón de desarrollo MVC (Modelo-Vista-Controlador).

Peso ligero.

Clases de base de datos con todas las funciones con soporte para varias plataformas.

Ajax.

Seguridad y Filtrado XSS.

Gestión de la sesión.

Email, Apoyar los accesorios, HTML / Texto email, múltiples protocolos

Marcos de seguridad.

Marcos de plantilla.

Formulario marcos de validación.

Manipulación de imágenes Library, Soporta GD, ImageMagick y NetPBM.

1 F. SIERRA, J. ACOSTA, J. ARIZA Y M. SALAS, Estudio y análisis de los framework en PHP

basados en el modelo vista controlador para el desarrollo de software orientado a la web. Barranquilla, Colombia, 2013, 13p. Artículo investigación, Revista Universidad Simón Bolívar.

22

Perfiles de aplicaciones. Laravel: Fue creado por Taylor Otwell. Su primera versión fue lanzada en junio de 2011 y su versión más reciente fue lanzada el 30 de agosto de 2017. Utiliza un marco basado en patrón de desarrollo MVC (Modelo-Vista-Controlador).Durante sus versiones fueron mejoradas varias características. Según Ummi Khaira Latif, y Tien Fabrianti Kusumasari1 En su versión 5 tiene algunas características principales las cuales son:

Modularidad: Tiene su construcción sobre más de 20 bibliotecas diferentes contando con una división en módulos individuales. Utiliza Composer que se usa para la administración de dependencias y cuenta con actualizaciones.

Testabilidad: Cuenta con componentes que le permiten hacer pruebas de la aplicación como rastrear el HTML resultante, puede también pasar por usuarios autenticados para asegurarse de que el código este correcto y se ejecute correctamente.

Enrutamiento: Cuenta con flexibilidad para las diferentes rutas definidas de la aplicación.

Gestión de la configuración: Tiene un enfoque coherente para manejar la configuración que se pueden aplicar en diferentes entornos mediante el uso de un archivo .env, que contiene configuraciones únicas para ese entorno.

Generador de consultas y ORM: Se realiza mediante él envió con un generador de consultas optimizado. Además, de utilizar tecnologías como ORM (Object Relational Mapper) y ActiveRecord.

Generador de esquemas, migración y siembra: con característica nos permite definir un esquema de base de datos con código PHP y realizar un seguimiento de cualquier cambio con la ayuda de la migración de la base de datos.

YII: Según la documentación oficial de YII2, es un framework de PHP de alto rendimiento, que nos ayuda desarrollar aplicaciones web modernas en poco tiempo. El origen de su nombre Yii significa "simple y evolutivo”. También se puede considerar como un acrónimo de Yes It Is (en español Sí, eso es). Es gratuito y de código abierto escrito en PHP5 y sus características principales son:

Promueve el diseño limpio y fomenta el desarrollo rápido.

1 UMMI KHAIRA LATIF, TIEN FABRIANTI KUSUMASARI, Performance Comparison of Executing

Large Data in Yii2 and Laravel Framework. Indonesia, 2017, 6p. artículo científico. Telkom University. Department of Industrial Engineerin. 2 Documentación YII, Yii2 Framework - ¿Qué es Yii?, {En línea}. {22 Marzo de 2018} disponible en:

https://yii2-framework.readthedocs.io/en/stable/guide-es/intro-yii/

23

Garantizar desarrollos eficientes, extensibles y mantenibles.

Está basado patrón de desarrollo MVC (Modelo-Vista-Controlador).

Cuenta con soporte de almacenamiento en caché de gran alcance.

Funciona de manera eficiente con AJAX.

En la parte de seguridad maneja la validación de entradas, filtrado de salida, la prevención de inyección de SQL y de Cross-site scripting.

SYMFONY: Según EduZRO1, Symfony es considerado como uno de los frameworks de PHP con buena flexibilidad y escalabilidad que existen para el desarrollo de las aplicaciones web. Utiliza el patrón de desarrollo MVC (Modelo-Vista-Controlador). El cual pueden implementarse variedad de componentes para PHP que nos sirven para ser utilizados como:

Form Config, para la gestión de formularios.

Translación, para la gestión de traducciones.

Templating para la gestión de los temas y Security.

Se distribuye por medio de Composer mediante paquetes modulares. Symfony nos ayuda a que el desarrollo de aplicaciones web sea más sencillo y rápido, Blindando una la facilidad con respecto a la mantenibilidad, que es importante para el desarrollo de aplicaciones web.

2.2.2 FRAMEWORKS DEL LADO DEL CLIENTE Foundation: Es un framework desarrollado por ZURB, este framework facilita el diseño de sitios o aplicaciones web, sin importar el tamaño del dispositivo que se esté ejecutando la aplicación, este framework es legible, flexible y completamente personalizable, con el fin de mejorar el diseño de la aplicación, utiliza lenguajes como HTML, CSS y JavaScript, se puede desarrollar o personalizar las vistas por capas, cada capa es el tamaño de pantalla de un dispositivo (móvil, computador, Tablet), con el fin de personalizar la vista al gusto del programador o diseñador, en su página principal, foundation.zurb.com, tiene desde cursos básicos, a hasta cursos avanzados, para aprender sobre la implementación, automatizar tareas, desarrollo, entre otros. Estos cursos, algunos tienen certificación y tienen costo. Bootstrap: Es un framework creado por el equipo de desarrollo de la red social Twitter, Permite la elaboración de sitios web de forma rápida, proporcionado una visualización óptima y experiencia de navegación fácil sin importar el tamaño de pantalla (Computador, Tablet, Móvil), basado en su filosofía responsiva. Entre sus características esta:

1 EduZRO, Los 16 mejores Frameworks de PHP, {En línea}. {20 Marzo de 2018} disponible en:

https://www.neoguias.com/mejores-frameworks-gratuitos-de-php/

http://es.wikipedia.org/wiki/Cross-site_scripting

https://www.neoguias.com/author/neeonez/

http://symfony.com/

24

La rapidez, solo basta descargar el tema o témplate que más se adapte a la necesidad del diseño de la aplicación web y ver cómo funciona el framework para empezarlo a utilizar.

Comodidad: la mayoría de frameworks traen muchos componentes adicionales en forma de plugins de JavaScript, permitiéndolas implementar sin necesidad de desarrollarlas uno mismo.

Soporte: cuenta con una gran comunidad online, por lo que será fácil encontrar la respuesta a las dudas publicándola o buscándola en un foro, o en la amplia documentación.

Precio: algunos temas son gratis, pero los más robustos tienen un costo aunque no es muy alto por lo general 15 dólares.

Consigo trae sus desventajas, debido a que trae mucho código y funcionalidades “de fábrica”, el exceso de código puede ser importante, porque hay varias funcionalidades que no se necesitan, y puede disminuir el rendimiento de la aplicación, aunque a partir de la versión 3 de Bootstrap se puede elegir que componentes se desean descargar.

2.2.3 ELECCIÓN DE FRAMEWORK DEL LADO DEL SERVIDOR En la siguiente comparativa veremos los siguientes tres ítems a evaluar:

1. Fácil Aprendizaje 2. Velocidad 3. Popularidad según google

Figura 6 . Cuadro comparativo de frameworks contra aprendizaje fácil, velocidad, popularidad acorde a Google

25

Según los resultados obtenidos en la figura 6, podemos observar que el framework más popular actualmente es Laravel, ya que cuenta con una buena documentación y tiene características que facilitan el desarrollo web. Tiene buena rapidez, pero no cuenta un fácil aprendizaje lo que indica que a los principiantes les constara un poco aprender a usarlo, si nos fijamos en la rapidez podremos observar que Phalcon se destaca gracias a que está desarrollado en el lenguaje C y C++ obteniendo un mejor rendimiento, también es fácil de aprender lo cual es un factor muy importante. Pero debido a que no lleva mucho en el mercado no cuenta con una amplia documentación ni un gran grupo de desarrolladores que puedan aportar. Si bien Symfony es uno de los frameworks más usados, no cuenta con un fácil aprendizaje por ende para realizar proyectos pequeños de rápidos desarrollos tomaría más tiempo de lo planeado. El framework que en un promedio general, tiene buenos resultados es Codeigniter, ya que es liviano, de fácil aprendizaje y es el segundo más rápido y más popular, es un frameworks que reúne grandes características lo que facilita el desarrollo, consiguiendo buenos resultados en poco tiempo.

Figura 7. Numero de descargas de los frameworks

Fuente WebHostFace Blog, Most popular PHP frameworks for 2017

Fuente WebHostFace Blog, Most popular PHP frameworks for 2017

26

En esta grafica de la Figura 7 podemos observar que unos frameworks que más descargas tiene es Symfony, gracias a su popularidad tiene un gran número de desarrolladores, que también aportan e otros proyectos con la llegada de nuevos frameworks como Lavarel que está basado en Symfony, como lo vimos en la Figura 6, Laravel es el más popular hasta el momento, pero en descargas ocupo el cuarto lugar. Codelgniter ocupo el segundo lugar con más descargas gracias a ser de fácil instalación y uso, en un tercer lugar se encuentra Zend que a pesar de ser de difícil aprendizaje, es popular en los desarrollos cuando se trata de software empresarial, en los demás puestos se encuentran YII, Phalcon, CakePHP.

Según el análisis sobre el framework a utilizar podemos destacar las siguientes características:

Es destacado, ya que es uno de los frameworks más rápidos del mercado y su configuración es muy fácil y rápida.

Es el segundo framework más popular según los resultados de google Es el segundo framework con más descargas, lo que significa que hay una

gran comunidad desarrolladores y una buena documentación.

2.2.4 ELECCIÓN DE FRAMEWORK DEL LADO DEL CLIENTE

Utilizaremos el framework Bootstrap, debido a que cuenta con una buena documentación y soporte, se posiciona como el más popular y utilizado actualmente. Adicionalmente se cuenta con conocimiento previo sobre esta herramienta que nos facilitara un óptimo desarrollo. Como se puede apreciar en las Figuras 8 y 9 de Google Trends, tiene una gran tendencia sobre los otros frameworks en el mercado, durante el último año además tanto en Colombia como en todo el mundo.

27

Figura 8. Comparación de tendencias entre Bootstrap, Foundation, Skeleton, Topcoat, Uikit en COLOMBIA

Figura 9. Comparación de tendencias entre Bootstrap, Foundation, Skeleton, Topcoat, Uikit en TODO EL MUNDO



28

2.3 ARQUITECTURA Para describir el modelo de arquitectura a utilizar primero se tiene que tener en cuenta el sistema distribuido, según Ian Sommerville1, implica numerosos servidores, en contraste a con los sistemas centralizados se ejecutan en un solo computador o servidor, Tanenbaum y Van Steen (2007) definen un sistema distribuido como: “una colección de computadoras independientes que aparecen al usuario como un solo sistema coherente”. Las ventajas de utilizar un sistema distribuido son las siguientes:

Apertura: Por lo general son sistemas abiertos, lo que significa que están diseñados en torno a protocolos estándar que permite la combinación de equipo y software de diferentes proveedores.

Concurrencia: Grandes procesos pueden ejecutarse al mismo tiempo con servidores independientes.

Escalabilidad: En cuanto a las capacidades del sistema Tamaño de disco duro, RAM, numero de procesadores, pueden aumentarse al agregar nuevos recursos para enfrentar nuevas demandas del sistema.

Tolerancia a fallas: La disponibilidad de muchos servidores y el potencial de reproducir información significa que pueden tolerar algunas fallas de hardware y software, según como este desarrollado el software y el proveedor de los servidores estén configurados para evitar la pérdida completa del servicio.

Según Ian Sommerville, los sistemas distribuidos a los que generalmente se accede por internet se organizan normalmente como sistemas cliente-servidor, donde pueden interactuar desde dos hasta n-capas (multinivel). El problema fundamental de un enfoque cliente-servidor de dos niveles, es que las capas lógicas del sistema (presentación, procesamiento de aplicación, gestión de datos y base de datos) se ejecutan en solo dos equipos (el cliente y el servidor), esto implica que cualquiera de los dos se sobrecargue de procesos, por consiguiente el tiempo de respuesta se reduzca en solicitud de grandes volúmenes de información, para evitar esto se plantea una arquitectura Cliente-Servidor Multinivel. Las capas de esta arquitectura son: Capa de presentación, la cual se ejecuta en el equipo del cliente:

Recoge la información del usuario y la envía al servidor web.

Genera la presentación.

Visualiza la presentación al usuario.

Capa de proceso, la cual se ejecuta en el servidor web:

1 SOMMERVILLE, Ian. Ingeniería de software. 9ª edición. México: Pearson, 2011, 792p

29

Recibe la información de la capa de presentación.

Interactúa con la capa de datos para realizar operaciones.

Manda los resultados procesados a la capa de presentación.

Capa de datos, la cual se ejecuta en el servidor de base de datos:

Almacena los datos.

Consulta datos.

Mantiene los datos.

Asegura la integridad de los datos.

Figura 10. Arquitectura Cliente-Servidor Multinivel en tres capas

Teniendo en cuenta la arquitectura escogida y el framework, el patrón de desarrollo será MVC (Modelo Vista Controlador), para agilizar el desarrollo de la aplicación utilizaremos el framework Codeigniter que utiliza este patrón MVC, ya que gracias a su rapidez y su fácil configuración, lograremos tener resultados satisfactorios en muy poco tiempo. Es necesario destacar que este framework es de fácil aprendizaje lo cual nos facilitara el desarrollo de la aplicación y se podrá cumplir con los objetivos planteados anteriormente.

Modelo Vista Controlador se define de la siguiente manera:

Modelo: Es la capa de datos, normalmente en esta capa se realiza las consultas a la base de datos, insertar, actualizar y eliminar información.

Vista: es la forma es que se le presenta la información al cliente o usuario, normalmente esta vista se presenta en una página web HTML, pero también con Codeigniter se puede presentar en fragmentos de páginas como encabezados o pie de página y también RSS.

Controlador: Funciona como intermediario entre el modelo y la vista. Normalmente la vista solicita información, el controlador recibe esta petición y solicita al modelo para que retorne los datos necesarios, el controlador recibe la información, la organiza y la envía a la vista.

Fuente Ingeniería de software Pearson. Arquitectura de tres niveles para un sistema de banca por Internet

30

Adicionalmente a lo anterior, Codeigniter1 se ha planteado unas metas arquitectónicas el cual es máximo rendimiento, simplicidad, capacidad y flexibilidad en el paquete más pequeño y liviano posible. Esto se logrará a partir de los siguientes objetivos:

Instanciación dinámica: Los componentes y las rutinas de Codeigniter se ejecutan solo cuando se requiera, lo hace que el sistema sea más ligero por defecto. Los eventos, según lo desencadenado por la solicitud HTTP, y los controladores y vistas que diseña determinarán qué se invoca

Bajo acoplamiento: el objetivo es mantener bajo acoplamiento en los componentes del software, cuanto menos componentes dependan unos de otros el software será más reutilizable y flexible.

Singularidad del componente: Cada clase y sus funciones son altamente autónomas para permitir la máxima utilidad. Esto también hace referencia a alta cohesión donde cada componente tiene un propósito estrechamente enfocado.

2.4 METODOLOGÍA DE DESARROLLO Teniendo en cuenta los múltiples modelos de proceso de software (desarrollo incremental, cascada, proceso evolutivo) o metodologías agiles de desarrollo (Scrum, Programación extrema), se ha escogido el modelo en cascada debido a su simplicidad, pero sobre todo lo que la diferencia con los modelos y metodologías anteriormente mencionadas, es que no requiere retroalimentación con el cliente debido a que está basado en documentación, además teniendo en cuenta que es un producto nuevo no se tiene un cliente como tal que pueda evaluar el software cada cierto tiempo, sino se tiene unos posibles clientes (Ricoh y Abka), los cuales podrán aportar al proyecto a través de entrevistas realizadas en la etapa de Análisis y definición de requerimientos. Según Ian Sommerville2, El modelo en cascada es dirigido por un plan, el cual es dirigido por un plan, el cual se debe elaborar al principio de cada actividad redactándolo en un documento en este caso lo capítulos del proyecto. Las principales etapas del modelo son las siguientes:

1. Análisis y definición de requerimientos: Como su nombre lo indica en esta etapa se analizan todos los requerimientos tanto funcionales como no funcionales, los servicios, las restricciones y las metas del sistema, esto se

1 Documentación oficial de Codeigniter, {En línea}. {05 abril de 2018} disponible en:

https://www.codeigniter.com/user_guide/ 2 SOMMERVILLE, Ian. Ingeniería de software. 9ª edición. México: Pearson, 2011, 792p

31

logra a través de la consulta a usuarios en el contexto del proyecto encuestas a usuarios de Profamilia, Ricoh y Abka. Posteriormente esta información recolectada se define con detalle, por lo general se redacta en un documento llamado “Especificación de Requisitos del Sistema (ERS)”.

2. Diseño del sistema y del software: Teniendo en cuenta la información recolectada en la etapa anterior, se realiza el diseño de: arquitectura del sistema global, estructura de los datos, detalle de los procesos y la interfaz gráfica. Con estos diseños realizados se redactan en un documento llamado “Documento de Diseño del Software (SDD)”.

3. Implementación y prueba de unidad: Se realiza el desarrollo del software según el diseño plasmado en la etapa anterior. La prueba de unidad consiste en verificar que cada módulo cumple con sus especificaciones diseñadas.

4. Integración y pruebas de sistema: la aplicación debe estar terminada e integrada con cada módulo, en esta etapa se realiza las pruebas necesarias para verificar que el software funcione sin errores, garantizando que se cumplan lo establecido en los requerimientos del software, después de detectar y corregir errores este software se entrega al cliente.

5. Operación y mantenimiento: Esta es la etapa más larga del ciclo de vida, donde el sistema se instala al cliente y este lo opera, el mantenimiento incluye corregir errores que no se detectaron en las etapas anteriores. Además mejorar la implementación de las unidades del sistema y e incrementar los servicios de acuerdo a lo que solicite el cliente o se descubra la necesidad.

La figura 11 ilustra el modelo en cascada:

Figura 11. Modelo en cascada

Cada etapa no debe iniciar si la que la antecede no ha finalizado, pero es muy probable que los documentos generados en cada etapa deban modificarse

Fuente Ingeniería de software Pearson. El modelo en cascada

32

para reflejar los cambios que se realizan, el proceso de software no es un simple modelo lineal, cada etapa necesita de retroalimentación debido a que se pueden encontrar más requerimientos, detección de un requerimiento mal descrito o el diseño tenga alguna falencia, por lo cual estos errores se pueden detectar en cualquier etapa. Teniendo en cuenta lo anterior las ventajas y desventajas de este modelo son las siguientes: Ventajas:

Es un modelo fácil de entender e implementar.

Está orientado a documentos, y de acuerdo a estos se realiza la evaluación del progreso, en comparación con Scrum que requiere reuniones constantes con el cliente.

Promueve una metodología de trabajo efectiva: definir antes de diseñar, y diseñar antes de codificar.

Desventajas:

El proceso de creación del software tarda mucho tiempo, debido a que es la tercera etapa.

Cualquier error en el diseño detectado en cualquier etapa conducen necesariamente al rediseño, es por esto que debe haber una constante retroalimentación durante todas las etapas.

Una etapa determinada no se puede llevar acabo, sino se ha terminado la etapa inmediatamente anterior.

Para tener en cuenta, en este modelo cascada tiene cinco etapas y el proyecto solo va a ir hasta el desarrollo, por lo cual no se realizará la etapa de la etapa de “operación y mantenimiento”. En los siguientes capítulos se pondrá en ejecución la metodología de desarrollo:

La etapa análisis y definición de requerimientos se desarrolla en el capítulo 4 - especificación de requisitos del sistema.

La etapa diseño del sistema y del software se desarrolla en el capítulo 5 diseño detallado del sistema.

La etapa implementación y prueba de unidad en el capítulo 6 desarrollo de la aplicación web.

La etapa Integración y pruebas de sistema en el capítulo 7 pruebas del sistema.

34

3 IDENTIFICACIÓN DE PROBLEMÁTICAS En este capítulo, se identificaran las problemáticas que hay en los servicios de outsourcing de impresión, dichas problemáticas se identificaran a través de entrevistas realizadas proveedores, clientes y personal técnico, posteriormente, se procederá a describir las aplicaciones semejantes encontradas durante la investigación, con el fin de ver las funcionalidades que tienen actualmente, adicionalmente, ver que requerimientos se pueden obtener de estas aplicaciones, y que podemos mejorar.

3.1. PROBLEMÁTICAS SEGÚN CLIENTE Se realizó una entrevista al Coordinador de TI de Profamilia Andrés Riaño, con el fin de evaluar las problemáticas que Profamilia tenía con los proveedores de servicios de impresión Ricoh y Abka, debido que Profamilia lleva 5 años trabajando con Ricoh y cerca de 8 años con Abka. Profamilia al igual que otros clientes de Ricoh y Abka buscan mejorar los procesos, reducir costos, mantener sus impresoras en un perfecto funcionamiento, como lo menciona Andrés Riaño al contratar el servicio de impresión busca - “que esté disponible para la operación de Profamilia, para que la operación lleve a cabo de la mejor forma, no que nos toque como en algunas sedes, que nos ha tocado salir con una memoria USB a imprimir a un café internet, sino que el servicio siempre esté disponible 24/7 en lo posible”. A lo largo de estos años se han presentado falencias relevantes y constantes de parte de Ricoh y Abka como “el incumplimiento, en tiempos, en tiempo de entrega de tóner, tiempo de partes, digamos RICOH como tal, cuando es una importación se puede demorar hasta tres semanas, no hay una impresora backup en algunos centros, entonces esto afecta la operación”, falencias como solicitar varias veces el mismo servicio técnico “hemos tenido que pedir el mismo servicio, muchas veces una maquina vienen la revisan y el mismo día vuelve a fallar por la misma causa”, han habido máquinas que se han demorado hasta mes y medio en el servicio. Al preguntarle su experiencia en general con el soporte técnico de Ricoh, Andrés relato que empezó bastante mal con apenas 26 máquinas las cuales están distribuidas en diferentes sitios de Colombia, las cuales empezaron a fallar siendo nuevas, “se pedía soporte técnico, no llegaban, la verdad tocó traerlas al centro del país, a Bogotá Neiva Ibagué porque el servicio no era bueno”, hasta tal punto que pensaron en terminar con el contrato. Durante la entrevista se preguntó sobre cómo se solicitaba el soporte técnico el cual Andrés respondió “lo realiza por medio de teléfono, correo electrónico, ¿Qué tan fácil es? Pues la verdad en si un correo electrónico o una llamada, no es la mejor herramienta para pedir servicios, puede ser fácil pero el control se vuelve difícil.”

35

En las reparaciones o mantenimientos que agendan “La verdad no conocemos muchas veces cuando van a ir, sería bueno hacer un seguimiento, por lo menos estar informado y la persona que coordina toda la parte de impresión este enterado que van a ir y a veces llegan a las sedes y el propio administrador no sabe que van a ir a arreglar la máquina, lo dejan entrar simplemente porque saben que la maquina está dañada, cuando el administrador es estricto llama al departamento de tecnología pues a solicitar una autorización, entonces sí debería mejorarse ese proceso”, “el momento no tenemos control sobre ese tiempo del técnico y muchas veces nos toca llamar y preguntar tanto en Ricoh y Abka donde viene el técnico cuando tenemos una impresora fuera de servicio tenemos que llamar varias veces, entonces es bastante limitada esa opción“, muchas veces el servicio técnico se realiza, pero la persona que está administrando la impresoras no se entera que el soporte se realizó, por lo tanto no tienen los soportes del mantenimiento, las hojas de vida quedan desactualizadas. Por lo anterior, se puede destacar que tanto Ricoh como Abka carecen de una buena gestión de soporte, la siguiente lista son requerimientos que se obtuvieron de la entrevista.

Registrar las solicitudes: de tóner o suministros, daños de impresoras, mantenimientos preventivos, ver la fecha máxima de los SLA acordados con el proveedor.

Seguimiento detallado por impresora con el fin de saber cuáles errores han tenido, que técnicos han reparado la impresora, para llevar una trazabilidad y saber qué es lo que está fallando evitando así que las fallas reincidan constantemente.

Gestión de su inventario para que cada cliente tenga la información exacta con que repuestos, impresoras, tóner, cuenta y realizar la solicitud del repuesto o tóner que se esté agotando a tiempo, y evitar contratiempos por importaciones que deba realizar el proveedor.

“Descargar la hoja de vida de cada una las impresoras, todos los servicios que se han realizado, solicitud de tóner, cambio de partes, mantenimientos preventivos”,

Visualizar el estado del soporte, cuando realizan el soporte, la hora exacta que el técnico llega a la sede para que los administradores le permitan el acceso sin problemas.

Este nuevo sistema, debe mejorar el cumplimiento de los SLA, como Andrés confirma “En todo momento, siempre han incumplido con los tiempos de SLA” y debido a estos incumplimientos han pensado en cambiar de proveedor “hemos considerado varios proveedores entre ellos Carvajal, Lexmark, bueno hemos hecho un trabajo de levantamiento de información con varios proveedores”

(ANEXO A. Encuesta Profamilia Andrés Riaño) Para ver la entrevista completa.

36

3.2 PROBLEMÁTICAS SEGÚN PROVEEDOR La entrevista al proveedor se realizó al gerente regional de Abka en Colombia Andrés Delgado, el lleva trabajando 14 años en esta empresa, lo cual es una gran experiencia y conoce en detalle las falencias de la empresa, las aplicaciones con las que han trabajado en este tiempo Abka. Desde la parte administrativa, tienen alrededor de 40 indicadores, Andrés nos muestra los indicadores que mensualmente monitorean, los cuales sirven para ver la calidad de sus servicios y saber en qué está fallando, posteriormente tomar las correcciones oportunas:

1. Logística y Cobertura: a. Logística inversa recogidas ciudades no principales b. Daños y reclamaciones por averías en envíos a ciudades no

principales c. Presencia directa de servicio técnico ciudades no principales d. Disponibilidad insumos o repuestos On-Site en ciudades no

principales e. Presencia directa de servicio técnico ciudades principales f. Logística inversa recogidas ciudades principales g. Otras

2. Servicio: a. Incumplimiento SLA ciudades no principales b. Incumplimiento SLA ciudades principales c. Servicios técnicos no prestados d. Otros

3. Conocimiento y disponibilidad del personal: a. Quejas por disponibilidad personal externo b. Quejas por conocimiento técnico personal externo c. Quejas por conocimiento técnico personal interno d. Quejas por disponibilidad personal Interno

4. Facturación: a. Toma de contadores b. Errores de facturación c. Facturación radicada en otros lugares o a destiempo d. Otros

5. Disponibilidad de repuestos: a. Ciudades principales b. Ciudades no principales

Los anteriores indicadores son los más importantes para Abka, y deben estar siendo monitoreados constantemente, podemos resaltar que de acuerdo a nuestro

37

objetivo que es realizar seguimiento de soporte técnico, los indicadores relevantes para nuestro proyecto serian: el indicador de servicio (incumplimiento de los SLA), el indicador de conocimiento (Quejas por conocimiento) y disponibilidad de repuestos.

Abka en los últimos meses está implementando un software ERP, el cual es un desarrollo propio, entre sus módulos menciona Andrés que contiene “contabilidad, facturación, cartera, cuentas por pagar, gestión documental, análisis inteligente de negocios, mantenimiento, contratos, inspección, riesgo, administración, clientes, servicio técnico, business intelligence, etc.”, para manejar la solicitud de tickets que realiza el cliente se realiza por medio de una aplicación móvil. El software anteriormente mencionado, está en desarrollo e inicio pruebas de los módulos mencionados, instalando la aplicación móvil en algunos clientes para la solicitud de servicio, teniendo en cuenta esto y la experiencia de Andrés, nos describe algunas generalidades de funciones valiosas para el que debe tener la aplicación de servicio técnico:

1. Gestión de clientes 2. Gestión de equipos (Hardware, Software) 3. Gestión de personal

a. Perfiles de usuarios, administrador, supervisor… b. Control de rutas GPS, RFID c. KPI

4. Gestión de tickets a. Recepción b. Programación c. Ejecución d. Cierre

5. Administración 6. Reportes personalizados

a. Tiempos de desplazamiento b. Tiempos de servicio c. Efectividad d. Trazabilidad e. Etc.

7. Automatización de procesos (Programación, Supervisión, Control, Alarmas, etc.)

8. Control y gestión de servicio técnico a. Servicio Predictivo b. Servicio Preventivo c. Servicio Correctivo d. Control de Pólizas e. Administración de Contratos

9. Análisis de inteligente personalizable. 10. Disponibilidad WEB con todas sus ventajas

38

En esta lista que menciona Andrés y los indicadores presentados, se pueden observar nuevos requerimientos, los cuales se deben evaluar en siguiente capítulo, si se pueden realizar o no debido a su complejidad y el tiempo de desarrollo del proyecto, los nuevos requerimientos identificados en la entrevista son:

Control y gestión de servicio técnico.

Seguimiento del cumplimiento de los SLA.

Conocimiento y disponibilidad del personal (Base de conocimientos).

Administración de repuestos y equipos.

Gestión de usuarios.

Análisis de inteligente personalizable.

Automatización de procesos.

Automatización de procesos.

Disponibilidad web.

(Ver ANEXO B. Encuesta Proveedor Andrés Delgado Abka) Para ver la entrevista completa.

3.3 PROBLEMÁTICAS SEGÚN TÉCNICO En la entrevista del técnico, se contactó a Hoovert Andrés Toro, el lleva trabajando con Abka 2 años y 6 meses, donde ha adquirido experiencia en el soporte técnico, a pesar de que antes de ingresar a la empresa ya tenía conocimiento previo, Hoovert al igual que Andrés Delgado hablo sobre la aplicación que está comenzando a implementar Abka, en algunos clientes, esta aplicación se pudo extraer funcionalidades como:

Mesa de ayuda para solicitar los requerimientos o soporte técnicos, sobre el servicio de impresión.

Por medio de la aplicación están informados de los servicios que deben realizar cada día, donde deben reportar diariamente que servicios se han realizado en el fin de controlar la ruta.

Solicitud de repuestos.

Pero, según lo relatado por Hoovert, son aplicaciones independientes, por ejemplo la aplicación de mesa de ayuda no está conectada a la misma base de datos de la aplicación, para asignar y reportar requerimientos, esta aplicación la están

39

mejorando poco a poco, además porque es un desarrollo propio de la empresa Abka. Faltan funcionalidades ya identificadas en este proyecto, como Base de conocimientos debido a que ellos, muchas veces no saben por qué se presenta un daño, al consultar la solución esta base de conocimientos se podría mejorar los tiempos de repuesta, ya que para Hoovert “mejorar el tiempo de respuesta es complicado ya que uno no sabe cuánto se demora en arreglar algunas máquinas por el daño que tenga.”, claro está que Abka, capacita a sus trabajadores a través de cursos y capacitaciones, pero aun así es difícil abarcar todos los posibles errores que puede tener una empresa, esto se logra a través de la experiencia, la cual se puede ver reflejada en alimentar una base de conocimientos, para compartirla con los colegas que recién ingresan a la compañía, como los que ya llevan varios años. La entrevista con Hoovert fue corta, pero dejo ver que las funcionalidades que se están desarrollando en el proyecto son necesarias:

Solicitud de repuestos.

Gestión de soporte.

Base de conocimientos.

Seguimiento de localización del técnico.

Una base de datos completa donde se centralice estas funcionalidades que ellos tienen en una sola aplicación.

Adicionalmente se aclara que una de las falencias comunes en el soporte técnico son tiempos de respuesta al corregir la falla de los equipos. (Ver ANEXO C. Encuesta Técnico Abka) Para ver la entrevista completa.

3.4 APLICACIONES SEMEJANTES Durante la investigación, se encontraron varias aplicaciones similares a la que se quiere desarrollar en el proyecto, se escojieron solamente cuatro APPSAT, Gestion De Servicio Técnico, ESEAFORMS, Manage-Engine, estas son son las mejores debido a que tienen más funcionalidades o caracteristicas, y son utiles tanto para la empresa que toma el servicio como el proveedor del servicio. La tecnologia implementada por estas cuatro aplicaciones, son aplicaciones web, y aplicaciones moviles, con la cual se complementa una con la otra, para que cada actor en el sistema se pueda comunicar, actualizar ordenes, localizar al tecnico entre otras funcionalidades que se explicaran a continuación.

40

Funcionalidades y caracteristicas: Gestión ticket: crear, modificar, actualizar, cancelar un ticket. Almacenamiento de datos - Inventario Stock: guardar información de los productos o equipos que estan distribuidos en las empresas de los diferentes clientes, adicionalmente de los repuestos disponibles. Notificaciones correo y SMS: para mantener informado a los tecnicos, usuarios y proveedores, se envian notificaciones al correo y SMS acerca del estado del os tickets, cambios de estado etc. Base de conocimientos: se trata de una lista donde el técnico o cliente puede encontrar la solución del error, ingresar o editar una solucion a un error, con paso a paso con imágenes para ser mas claro en la solución, busquedas mediane palabras clave. Informes: informes como el rendimiento de los técnicos con el cumplimient de los SLA, costos en repuestos, requerimientos atendidos en el mes, poblemas más frecuentes, clientes más frecuentes, informes sobre las encuestas realizadas a los clientes, etc. Encuestas a usuarios: para conocer el nivel de satisfacción de los clientes, en la cual se puede configurar preguntas, los niveles de satisfacción, en fin. Acuerdos de niveles de servicio: Crear acuerdos de niveles de servicio SLA, con gestión de SLA intuitiva, para garantizar el cumplimiento de sus SLA. Portal autoservicio: en el cual se envian solicitudes de servicio y reportar insidentes. Tambien pueden buscar soluciones en la base de conocimientos con el fin de reducir la carga de solicitudes. Gestion de incidentes planficacion y agenda: asignacion de un técnico a un insidente de acuerdo a su carga laboral, priorización de trabajos cumpliendo los SLA. Gestión de contratos: mantiene un regitro de las fechas de vencimiento de los contratos, con la funcionalidad de notificaiones automáticas de alerta para la renovacián de contratos, copia de los contratos reales. Localización de operarios o tecnicos: con geolocalización integracion del GPS de google maps, muestra el mapa para llegar desde el punto actual del tecnico al lugar de reparación.

41

Gestion de usuarios: crear, eliminar usuarios como tecnicos, proveedores, clientes en el sistema para que puedan acceder y manejar la aplicación, adicionalmente actualizar la informaion de cada usurio, telefono, direccion, etc. Gestion de vacaciones: crea o reporta los dias en que el usuario no este disponible con el fin de evitar asignarle por equiocacione algun soporte tecnico. Matriz comparativa de las cuatro aplicaciones:

Cuadro 2. Funcionalidades vs aplicaciones similares

De las entrevistas y las aplicaciones semejantes se obtuvo la siguiente lista de requerimientos (funcionales y no funcionales), los cuales se evaluaran en el siguiente capítulo para desarrollar o no en el proyecto, también se evalúan cuáles de estos requerimientos son informes.


42

Cuadro 3. Recopilación de requerimientos encontrados


43

4 ESPECIFICACIÓN DE REQUISITOS DEL SISTEMA

4.1 INTRODUCCIÓN En este capítulo está basado en la estructura según el estándar Especificación de Requisitos de Software (ERS) de IEEE 830, además se inicia con la metodología de desarrollo en cascada con la primera etapa DEFINICION DE REQUERIMIENTOS, para el desarrollo de una aplicación web para el seguimiento del soporte técnico en empresas de outsourcing de impresión, donde se dará claridad y detalle de los requerimientos de la aplicación web, teniendo en cuenta la información recogida en el capítulo anterior de IDENTIFICACIÓN DE PROBLEMÁTICAS. 4.1.2 Propósito El propósito de este capítulo, es establecer una descripción detallada de los requerimientos necesarios para la construcción de una aplicación web, para el seguimiento del soporte técnico en empresas de outsourcing de impresión, teniendo en cuenta la investigación realizada en el capítulo anterior, donde se realizaron las encuestas a tres personas, estas personas actualmente tienen en su cargo los diferentes roles que tendrá la aplicación (CLIENTE, TÉCNICO, PROVEEDOR), por lo siguiente saben y tienen experiencia sobre las falencias del servicio de outsourcing.

4.2 DESCRIPCIÓN GENERAL 4.2.1. Perspectiva del Producto La aplicación web planteada en el documento es independiente, lo que significa que no dependerá de otros sistemas para recolectar información, solamente los usuarios que manejan la aplicación web podrán alimentarla, a través de los formularios que tiene la aplicación en cada módulo. 4.2.2. Funciones del Producto Los principales módulos que tendrá la aplicación son los siguientes:

Gestión de Ticket Gestión de Usuarios Stock de Inventario Base de conocimientos Encuestas a usuarios Gestión de contratos Reportes

44

4.2.3. Características de los Usuarios Los usuarios o actores proveedor y cliente, no debe tener conocimientos técnicos sobre sistemas, básicamente necesita una capacitación previa para utilizar el sistema, al analizar los requisitos y diseñar la aplicación se espera que la aplicación web sea fácil de utilizar. El actor administrador si debe tener conocimientos profundos sobre la aplicación web y conocimientos técnicos en el lenguaje de programación PHP, JavaScript, lenguajes de etiquetas como HTML, bases de datos SQL, los framework Bootstrap y Codeigniter, con el fin de dar soporte técnico a la herramienta.

Tabla 2. Descripción y funciones de los usuarios del sistema

Actor Descripción Funciones

Administrador

Este usuario presta soporte técnico a la aplicación en caso de fallos, reportes o nuevas funcionalidades que se requieran para la aplicación.

Tiene acceso a todas las funciones y permisos necesarios para el uso de la herramienta, además crea al usuario proveedor en el sistema.

Proveedor

Este usuario representa la empresa prestadora de los servicios de outsourcing de impresión, el cual cumple funciones de logística asigna los técnicos, está pendiente que la calidad del servicio se cumpla adecuadamente.

- gestionar usuarios - asignar técnico al soporte - visualizar estado del soporte - ver localización del técnico - cancelar soporte - gestionar artículos (impresora, tóner, repuesto) - dar de baja a artículos - asignar articulo - gestionar contratos - ingresar vacaciones o inasistencias de los técnicos - ver resultados encuestas - Ver el cumplimiento de los SLA - Buscar solución en la base de conocimientos

Cliente

Este usuario representa la empresa que adquiere los servicios de outsourcing de impresión, por lo general solicita servicios para las impresoras alquiladas con el proveedor con el fin que estas estén en correcto funcionamiento.

- solicitar soporte - visualizar estado de soporte - llenar encuesta - confirmar cierre soporte - cancelar soporte - buscar solución auto servicio - solicitar articulo(tóner) - ver localización del técnico

45

Técnico

Este usuario representa la empresa prestadora de los servicios de outsourcing de impresión, gestiona el servicio y debe cumplir con la ruta programada por el usuario proveedor para satisfacer los requerimientos del usuario cliente.

- gestionar base de conocimientos - realizar soporte - cerrar soporte - buscar solución autoservicio - solicitar articulo(impresora, tóner, repuesto)

4.2.4. Restricciones

Para acceder a la aplicación solamente se realiza con conexión a internet.

El usuario técnico debe otorgar permisos al navegador para la ubicación, (Localización en tiempo real y ruta optima).

Funcionalidad de la aplicación web en los navegadores Google Chrome, Mozilla y Edge.

Para él envió de la localización del técnico, la API de Google Maps tiene un máximo de 20.000 registros, lo cual se debe limitar la sincronización de la ubicación del técnico a cada 5 minutos.

4.2.5. Suposiciones y Dependencias Suposiciones:

Para acceder a la aplicación, se debe realizar desde los navegadores web Google Chrome y Mozilla Firefox, tanto en versiones de computador como en Smartphone.

La aplicación solamente es funcional si se tiene una conexión a internet.

La aplicación solo puede ser utilizada por el proveedor que adquirió el software y sus respectivos clientes.

El usuario solamente puede estar conectado en un dispositivo a la vez.

Dependencias:

Para las funcionalidades de mapas como localizar técnico y ver la ruta optima al servicio, dependen del api y servidores de Google Maps.

El desempeño de la aplicación web al cargar informes, mapas, formularios, listas, entre otros, depende de la velocidad de conexión a Internet.

La base de datos y la aplicación, están alojadas en Heroku por lo tanto la disponibilidad del servicio depende de la calidad y disponibilidad de los servidores de Heroku.

Fuente autores

46

4.3 ANALISIS DE REQUERIMIENTOS En el capítulo anterior (identificación de problemáticas), se obtuvo una lista de todos los requerimientos obtenidos de las entrevistas y las aplicaciones semejantes (ver Cuadro 3.), en dicha lista (Tabla 3) están los requerimientos que se platean desarrollar, debido a su importancia para la recolección de información y cumplir con el objetivo general.

Tabla 3. Requerimientos a desarrollar

Estos requerimientos no solo son importantes para cumplir el objetivo general, sino que también son la base para desarrollar nuevas funcionalidades detectadas durante la investigación, estas nuevas funcionalidades se enlistan en la Tabla 4:

Tabla 4. Requerimientos para desarrollo futuro

Los requerimientos que aparecen en la Tabla 4, con la etiqueta (Opcional), se desarrollaran pero no en su totalidad, debido a que se necesitan API de Google Maps y Google Forms, lo cual implica conocimientos del api en implementación con el Framework Codeigniter.

REQUERIMIENTO FUNCIONAL NO FUNCIONAL

Gestión de servicio técnico X

Gestión de inventario (repuestos y equipos) X

Visualizar el estado del soporte X

Seguimiento del cumplimiento de los SLA X

Gestión de base de conocimientos X

Gestión de usuarios X

Gestión de contratos X

Gestión de vacaciones del técnico X

Una base de datos completa X

Facilidad de uso (usabilidad) X

Disponibilidad web X

REQUERIMIENTO FUNCIONAL NO FUNCIONAL INFORME

Seguimiento detallado por impresora X

Descargar la hoja de vida X

Análisis de datos inteligente personalizable X

Automatización de procesos X

Reportes personalizados X

Notificaciones correo y SMS X

Gestión de incidentes planificación y agenda X

Seguimiento de localización del técnico (Opcional) X

Encuestas a usuarios - (Opcional) X

Fuente autores

Fuente autores

47

4.3 REQUERIMIENTOS FUNCIONALES En la Tabla 5, muestra la cabecera de descripción de los casos de uso, estos casos de uso o requerimientos son características que debe cumplir la aplicación web, puesto que son las funcionalidades investigadas en capítulos anteriores, por lo tanto son vitales para el funcionamiento y que debe cumplir la aplicación. Para ver completamente la descripción de los siguientes requerimientos – ver ANEXO D. Requerimientos Funcionales.

Tabla 5. Requerimientos funcionales de la aplicación.

ID Nombre Actores

Involucrados Descripción

CU01

Solicitar Soporte

Cliente

Cuando el cliente tiene una falla o solicitud con respecto al servicio prestado de impresión, el cliente debe ingresar a esta opción del sistema, llenar la información solicitada, para obtener ayuda en su requerimiento esto se verá reflejado en el usuario proveedor para asignar el técnico CU03, la aplicación asigna una prioridad a al soporte según el estado de la impresora.

CU02 Realizar Soporte

Técnico

En este caso de uso el técnico se dispone a realizar el soporte, buscándolo inicialmente en su lista de Tickets Asignados, desde esta opción el técnico puede ver la base de conocimientos, el técnico puede ver la ruta más corta para llegar al servicio, posteriormente solicitar artículos o repuestos para solucionar el soporte, si se ingresan artículos se deja en estado pendiente mientras llegan los repuestos, al finalizar el soporte este cambia el estado ha CERRADO.

CU03 Asignar Técnico

Proveedor

Cuando hay una solicitud de servicio de un cliente, está llega a una lista de pendientes por asignar técnico, el proveedor abre esta solicitud para asignar un técnico de acuerdo a su prioridad y disponibilidad. Este proceso de Asignar Técnico se debe realizar de forma rápida debido a que el tiempo de cumplimiento de los SLA comienza a correr a partir de que el usuario crea el servicio dentro de horas laborales.

CU04 Confirmar

Cierre Soporte Cliente

El cliente confirma el cierre del soporte, de acuerdo si la solución suministrada por el técnico, es conforme a lo solicitado. Posteriormente el sistema abre una encuesta (esto está especificado en el CU17).

48

CU05 Visualizar Estado Del

Soporte

Cliente, Proveedor,

Técnico

Tanto el cliente como el proveedor tienen la opción de visualizar el estado del soporte, dentro de una lista de soportes, acá pueden visualizar el estado del soporte, agregar una observación a la solicitud de soporte.

CU06 Cancelar Soporte

Proveedor, Cliente

Tanto el proveedor como el cliente, pueden cancelar el soporte siempre y cuando el soporte este en estado ABIERTO o PROGRAMADO, al cancelar el soporte este finaliza, no podrá ser abierto de nuevo.

CU07 Localización del técnico

Proveedor, cliente

Actualización de la ubicación del técnico en tiempo real, desde el punto de inicio hasta llegar a la ubicación del servicio, esto se muestra únicamente cuando el técnico inicia el soporte (ver CU02), la ubicación la puede ver el Proveedor y el cliente.

CU08 Crear Usuario Proveedor El proveedor registra la creación de nuevos usuarios dentro del sistema, tanto de Técnicos o Clientes nuevos.

CU09 Actualizar-Eliminar Usuario

Proveedor

El proveedor selecciona esta opción para actualizar datos de un usuario ya sea técnico o cliente, también puede cambiar el estado del usuario (activo (1) o desactivado (0)), cambiando el estado simula eliminación del usuario y este no podrá ingresar al sistema.

CU10 Ingresar

ausentismo de técnico

Proveedor

El proveedor ingresa a esta opción cuando el técnico tenga un ausentismo, ya sea por vacaciones o inasistencias. Con el fin de que el sistema no lo muestre en la lista de asignar técnico (CU02)

CU11 Crear artículo o

equipo Proveedor

Cuando hay un nuevo artículo comprado por parte del proveedor, se registra en el sistema con su respectiva información para posteriormente ser asignarlo (CU13)

CU12 Editar articulo o

equipo Proveedor

Este requerimiento se ejecuta cuando el proveedor necesite cambiar alguna información del articulo

CU13 Asignar artículo

o equipo Proveedor

El proveedor asigna un artículo (impresora, tóner, repuesto, entre otro) a un cliente.

CU14 Dar de baja

artículo Proveedor

Cuando un artículo este dañado y no se pueda reparar o este obsoleto, el proveedor da de baja artículo.

CU15 Solicitar artículo

Cliente, Técnico

Este Caso de Uso inicia cuando un técnico necesita un repuesto, o un artículo para solucionar un soporte, también cuando un cliente ve necesario solicitar un artículo (tóner) para que no se agote de su inventario.

49

CU16 Crear encuesta Proveedor El proveedor puede realizar encuestas, para aplicarlas a los clientes, cuando el cliente confirma la solución del problema y cierra el soporte.

CU17 Llenar

encuesta Cliente

Cuando el cliente cierra un soporte CU04, automáticamente de despliega está en cuesta la cual debe ser diligenciada con el fin de medir la calidad de los servicios

CU18 Ver resultados

encuesta Proveedor

Muestra informe de los resultados de las encuestas realizadas a los clientes (CU17), con esta encuesta pueden medir el nivel del servicio que se está prestando y tomar así decisiones para mejorar el proceso.

CU19 Gestionar base

de conocimientos

Técnico

En esta función tanto el técnico como el proveedor, pueden agregar una nueva solución a un soporte, con el fin, de que otros usuarios puedan ver cómo se soluciona dicho requerimiento y no tengan demoras en solucionar un soporte mientras investigan la solución.

CU20 Buscar

solución-autoservicio

Técnico, Proveedor

Tanto el técnico como el proveedor pueden visualizar la información de la base de conocimientos, con el fin de buscar las soluciones para el arreglo de una impresora

CU21 Gestionar contratos

Proveedor

Este caso de uso es un formulario donde se ingresa las fechas de vencimiento de los contratos, creación de la empresa cliente con su respectiva sede, usuarios nuevos, a futuro este requerimiento alertará a los proveedores cuando este cerca de vencerse un contrato y ellos tener tiempo para desarrollar una buena oferta para el cliente.

CU22 Ver

cumplimiento de SLA´s

Proveedor

Este caso de uso se muestran los servicios o tickets, indicando si cumplió o no los tiempos acordados para el soporte técnico indicado en los SLA

4.4 REQUERIMIENTOS NO FUNCIONALES Los siguientes requerimientos evalúan la operación de la aplicación, es decir la calidad, no son visibles fácilmente por el usuario, pero al faltar uno de estos requerimientos puede generar inconformidades al usuario con la aplicación. Las siguientes tablas muestran los requerimientos no funcionales planteados para la aplicación y los posibles daños si no se aplican en el proyecto.

Fuente autores

50

Tabla 6. RNF001 Portabilidad

Código Nombre Fecha Prioridad

RNF001 Portabilidad 4/03/2018 Alta

Descripción

La aplicación se debe poder ejecutar desde diferentes sistemas operativos, Windows, Linux, Android, IOS con el fin de abarcar la mayor cantidad de dispositivos compatibles con la aplicación y no restringir al cliente que debe cambiar sus computadores o servidores y a cierta versión de sistema operativo.

Daños

Restringir al cliente al uso de un sistema operativo determinado, para utilizar la aplicación puede acarrear gastos elevados en la actualización o compra de equipos, por consiguiente no compren la aplicación

Tabla 7. RNF002 Mantenibilidad


RNF002 Mantenibilidad 4/03/2018 Alta

Descripción

Después de que la aplicación este en producción, se seguirá actualizando con nuevas funcionalidades, las personas que realizan las nuevas funcionalidades deben entender el código y la arquitectura, fácilmente, sin una tediosa curva de aprendizaje, por eso el uso de un Framework como Codeigniter que asegure la implementación del patrón de desarrollo MVC, utilizar estándares de código como comentarios, declaración de variables.

Daños Retrasos en las entregas de nuevas funcionalidades, por consiguiente inconformidades de los proveedores

Fuente autores

Fuente autores

51

Tabla 8.RNF003 Disponibilidad


RNF003 Disponibilidad 4/03/2018 Alta

Descripción

El sistema debe estar altamente disponible, por lo menos de lunes a sábados, los domingos podría realizarse actualizaciones o mantenimientos para mejorar continuamente el servicio, este horario se termina de acuerdo a la operación de las empresas. También se debe asegurar en alojar la aplicación en un buen hosting al pasar la aplicación a producción.

Daños La caída continua del servicio puede generar inconformismos en el cliente, ya que no podrían ejercer su trabajo fluidamente y en el horario laboral.

Tabla 9. RNF005 Seguridad


RNF005 Seguridad 4/03/2018 Alta

Descripción

La información debe enviarse por protocolos seguros como HTTPS, encriptar contraseñas de usuario con MD5 para que no sea visible en ningún momento durante el flujo de datos, el usuario solo podrá interactuar por páginas autorizadas según el rol. Realizar copias de seguridad a la base de datos cuando ocurra un cambio.

Daños Como ética profesional se debe mantener al máximo la integridad de los datos.

Fuente autores

Fuente autores

52

Tabla 10. Usabilidad


RNF006 Usabilidad 4/03/2018 Alta

Descripción

La aplicación debe ser intuitiva, fácil de usar, el usuario no debe navegar entre muchas opciones para llegar al formulario que

necesita. Hoy en día se necesita tener encuentra que la aplicación se ajuste al tamaño de los dispositivos como Smartphone, Tablet,

computadores, etc. para que se pueda ver la información clara y completa de los formularios mostrados por la aplicación.

Daños Los usuarios podrían perderse dentro de la aplicación buscando la

opción que buscan, esto podía generar inconformidades de la aplicación y por consiguiente los proveedores opten por no utilizarla.

Fuente autores

53

5 DISEÑO DETALLADO DEL SISTEMA Este capítulo, continua la metodología de desarrollo en cascada con la segunda etapa DISEÑO DEL SISTEMA Y SOFTWARE, de acuerdo al documento de DISEÑO DETALLADO DEL SISTEMA (SDD) para el desarrollo de una aplicación web de seguimiento del soporte técnico en empresas de outsourcing de impresión, donde se dará claridad y detalle con diagramas UML (Lenguaje de Modelado Unificado) el cual es un estándar mu conocido para la elaboración del diagrama de Casos de Uso, Diagramas de Estados, Diagramas de Secuencias, Diagrama de Clases, Diagrama de Entidad Relación, Diagrama de Arquitectura y Diagramación de la aplicación. Estos diagramas se mostrarán a continuación. 5.1 DIAGRAMA DE CASOS DE USO En el siguiente diagrama muestra cómo interactúan los actores Cliente, Técnico, Proveedor y Administrador, con el sistema (SoluSoporte).

Figura 12. Diagrama de Casos de Uso

54

5.2 DIAGRAMAS DE ESTADOS Este diagrama muestra los diferentes estados que puede tener: el técnico, los usuarios de la aplicación (cliente, técnico), la solicitud de servicio técnico que realiza el cliente y los artículos; durante la ejecución de la aplicación.

5.2.1 Diagrama estados del técnico El técnico puede tener dos estados, disponible o no disponible, al estar en estado disponible, este técnico es cargado en la lista de técnicos viables que pueden ser asignados para solucionar un requerimiento de un cliente, al estar en estado no disponible no se carga en esta lista. Lo anterior se especifica en la Figura 13.

Figura 13. Diagrama estados del técnico

55

5.2.2 Diagrama estados del usuario (Cliente, Técnico) Los usuarios del sistema (cliente y técnico) pueden tener dos estados, el primero es activo, el cual es el estado por defecto cuando se crea el usuario, en este estado el usuario puede acceder al sistema y realizar sus respectivas funciones, al pasar el usuario a desactivado este usuario no puede ingresar al sistema por medio del login. La Figura 14 ilustra lo anterior descrito.

Figura 14. Diagrama de estados del usuario (Cliente, Técnico)

5.2.3 Diagrama de estados de la solicitud de soporte técnico Esta solicitud de soporte técnico, la realiza el cliente cuando se presenta un fallo en el servicio y crea un soporte técnico en la aplicación, después de esto el soporte técnico puede tener seis estados:

Abierto: cuando el usuario crea la solicitud de soporte.

Programado: cuando el proveedor asigna un técnico para solucionar la solicitud.

Cancelado: únicamente el soporte puede pasar a este estado, cuando el estado del soporte está en programado o abierto, esto lo puede realizar el cliente o el proveedor.

Pre-cerrado: cuando el técnico cierra el soporte indicado que la solicitud esta solucionada.

Cerrado cuando el cliente confirma que su solicitud ha sido resuelta.

Pendiente: cuando el técnico indica que necesita repuestos para solucionar el soporte, o cuando el cliente indica que no sea solucionado su requerimiento.

La Figura 15 ilustra lo anterior descrito.

56

Figura 15. Diagrama de estados de la solicitud de soporte técnico

5.2.4 Diagrama estados del artículo Los artículos son las impresoras, tóner, unidad fusor, rodillos, entre otros repuestos o equipos. Los artículos pueden tener cuatro estados:

Sin asignar: este es el estado inicial del artículo por defecto cuando se registra en la aplicación.

Asignado: cuando el artículo es entregado a un cliente y se registra en la aplicación.

Dañado: cuando presenta un fallo el artículo y la reparación puede durar más de un día.

Dado de baja: cuando es obsoleto o no tiene reparación. La Figura 16 representa lo anterior descrito.

57

Figura 16. Diagrama estados del artículo

5.3 DIAGRAMAS DE SECUENCIAS Estos diagramas muestran muestra el flujo normal de eventos de los casos de uso indicados en la Figura 12, las diferentes interacciones que tiene los usuarios con los componentes de la aplicación como lo son: vista, controlador, modelo y base de datos, en algunas ocasiones interactúa también con API’s adicionales como Google Forms y Google Maps los cuales suministran información o funcionalidades adicionales. Todos los diagramas de secuencia se encuentran en ANEXO G. Diagramas de secuencia.

58

5.4 DIAGRAMA DE CLASES Este diagrama representa la distribución de las clases creadas con PHP con sus respectivos métodos, en el modelo-vista-controlador dentro del framework Codeigniter.

Figura 17. Diagrama de clases

59

5.5 DIAGRAMA DE ENTIDAD RELACIÓN Muestra cómo se relacionan las veinticinco entidades creadas en la base de datos entre sí. Cada entidad contiene una llave primaria y varios campos, cada campo se describe el tipo de dato, tamaño y foreign key. En amarillo se muestran las vistas creadas para facilitar las consultas a las tablas de servicios, artículos y usuarios.

Figura 18. Diagrama entidad-relación

Para ampliar más información sobre la descripción de cada tabla o campo, ver ANEXO F. Diccionario de datos

61

5.6 DIAGRAMA DE ARQUITECTURA El siguiente diagrama muestra, el patrón de desarrollo modelo-vista-controlador en una arquitectura cliente-servidor multinivel, donde inicialmente se ven los dispositivos finales de los usuarios (Computadores, Tablet, Smartphone, etc.), navegando en la aplicación con el framework Bootstrap y el lenguaje de etiquetas HTML, esta parte se conecta a través de JavaScript y Ajax, con un servidor que aloja la aplicación web, la cual está desarrollada con el framework Codeigniter de PHP, este framework contiene las clases representadas en la Figura 17 las clases contenidas en el modelo permiten realizar consultas a la base de datos MySQL alojada en Heroku con el add-on ClearDB.

Figura 19. Diagrama arquitectura

5.7 DIAGRAMACIÓN DE LA APLICACIÓN (MOCKUPS) La diagramación de la aplicación, muestra el diseño de cada interfaz de usuario, de acuerdo a los requerimientos funcionales, esta diagramación fue diseñada con la herramienta Balsamiq, el objetivo es mostrar las vistas que tiene el usuario Cliente, Técnico y Proveedor en cada uno de sus módulos. Ver ANEXO H. Diseño - Mockup de la aplicación

62

6 DESARROLLO DE LA APLICACIÓN WEB Este capítulo, describe las herramientas que se utilizaron para el desarrollo de la aplicación web, continuando así con la tercera etapa de la metodología de desarrollo en cascada, IMPLEMENTACIÓN Y PRUEBA DE UNIDAD. Para realizar esta etapa, se debe tener en cuenta, el lenguaje de programación, framework del lado cliente, framework del lado servidor, arquitectura y metodología seleccionadas en el capítulo 2 (investigación, análisis de arquitectura y metodología para el desarrollo de la aplicación web), los requerimientos funcionales y no funcionales escogidos en el capítulo 4 (especificación de requisitos del sistema), finalmente cumplir con el diseño realizado en el capítulo 3 (diseño detallado del sistema). Se diseñó un manual de usuario el cual tiene todas las vistas de la aplicación y explicando cada una de ellas (ver ANEXO I. Manual de Usuario-Capturas de la aplicación), también se elaboró un manual de instalación donde está el paso a paso para poder ejecutar la aplicación web de manera local (ver ANEXO K. Manual de instalación).

6.1 APLICACIÓN DESARROLLADA VS APLICACIONES INVESTIGADAS A continuación se compra las aplicaciones investigadas en el capítulo 3 de identificación de problemáticas contra la aplicación desarrollada en ese proyecto, con el fin de demostrar el potencial que tiene nuestra aplicación en usabilidad, lo cual se pretendía mejorar, y enfocándolo muy bien en la parte de soporte de outsourcing de impresión.

Aplicación desarrollada

63

Aplicación (Appsat.net)

Análisis comparativo

Se evidencia una interface muy similar, pero en la aplicación desarrollada se tiene el menú de opciones dentro de la misma página evitando salirse de la misma y poder realizar todas las acciones

requeridas por el usuario.

64


Aplicación (Gestión de servicios)

Análisis Comparativo (Usabilidad)

En la aplicación desarrollada se evidencia una interfaz gráfica más limpia, más llamativa y con un menú de opciones que siempre esta visible para el usuario.

65


Aplicación (Eseaforms)

Análisis comparativo

Se encuentran que las interfaces graficas tiene una estructura similar pero la aplicación desarrollada cuenta con el manejo de alertas informativas sobre la acción realizada por el usuario. Como podemos evidenciar en el Cuadro 2. (Matriz comparativa), eseafroms no ofrece muchas funcionalidades respecto a las otras aplicaciones y la aplicación desarrollada.

66


Aplicación (Gestión de servicios)

Análisis Comparativo (Usabilidad)

En la aplicación desarrollada se evidencia una interfaz gráfica más limpia, más llamativa y con un menú de opciones que siempre esta visible para usuario.

67

6.2 CHECKLIST Este CheckList, se ejecutó desde el 20 de abril del 2018, hasta el 11 de mayo del 2018, con el fin de evaluar una vez por semana el avance del proyecto, donde se estuviera cumpliendo con los requerimientos funcionales obtenidos en el capítulo 4, con los casos de uso, con los diagramas y Mockups diseñados en el capítulo 3. Este es el último Check realizado el 11 de mayo, donde se evidencia que los casos de Uso CU07 y CU16 los cuales son opcionales, no fueron desarrollados en su totalidad (ver Tabla 11).

CU07 Localización del técnico: se tiene un prototipo funcional, pero no se encuentra integrado con la aplicación.

CU16 Crear encuesta: Se está realizando la instigación de la integración del framework Codeigniter con el API de Google Forms.

Para ver los CheckList realizados, ver ANEXO J. CheckList casos de uso - diseño – desarrollo.

Tabla 11. Lista de chequeo del 11 de mayo

6.3 HERRAMIENTAS DE DESARROLLO Para el desarrollo del proyecto se utilizaron las siguientes herramientas enlistadas en la Tabla.

68

Tabla 12. Herramientas utilizadas en el sistema

6.4 ESTRUCTURA DE LA APLICACIÓN La estructura se encuentra predeterminada dentro el framework Codeigniter, en la cual podemos observar el patrón de diseño (modelo, vista controlador), adicionalmente carpetas de configuración y librerías nativas.

Figura 20. Esquema general de la arquitectura de la aplicación

69

Controlador: En el controlador se encuentra todas las clases que interactúa con el modelo y con la vista (ver Figura 20).

Figura 21. Carpeta controladores

Modelo: En el modelo se encuentra las clases que reciben los parámetros enviados desde el controlador y realiza sentencias SQL (Create, Read, Update, Delete).

Figura 22. Carpetas modelos

Vista: En la vista se encuentran todas las paginas HTML. Se dividen en carpetas para facilitar su identificación y uso.

Figura 23. Carpetas de vistas

70

Esta creada una carpeta con nombre assets, en la cual se guarda todo el contenido de bootstrap y archivos javascript.

Figura 24. Carpeta assets

En la carpeta config, se encuentran los archivos de configuración para el uso del frameworks dentro de los cuales se encuentra el archivo database.php, donde se registra todo los datos de conexión de la base de datos los datos.

71

Figura 25.Carpeta config

6.5 BASE DE DATOS La base de datos está realizada con el motor de base de datos de MySQL, utilizando el editor Workbench de MySQL, y siguiendo el modelo de Entidad relación de la Figura 18, el siguiente esquema de cómo esta implementada la base de datos, con todas las tablas y vistas.

72

La base de datos está alojada en el servidor de Heroku, utilizando el add-ons de ClearDB, el cual se encarga de administrar la base de datos, tanto en verificar el peso de la base de datos, estabilizar la carga del procesador y la memoria en la ejecución de las consultas, como se muestra en la Figura 26. También ofrece certificado SSL para encriptar la información que viaja por HTTPS

Vistas: son consultas a varias tablas de la base de datos, con el fin de no sobre cargar de consultas, la aplicación, esta aplicación web solo realice la consulta a la base de datos, y muestre la información.

73

Figura 26. Monitor de ClearDB - Heroku

ClearDB se encarga también de realizar backup a la base de datos todos los días entre 6:30AM a 7:30AM, asegurando así el requerimiento no funcional RNF05 de seguridad e integridad de la información.

Figura 27. Backup a la base de datos

74

6.6 GITHUB Esta herramienta se utilizó para almacenar los reportorios de la aplicación, con la ayuda de GIT se realizaron commits, para manejar el versionado del proyecto, solamente se utilizó la rama master, la lista de commits es la siguiente.

75

6.7 HOSTING La aplicación se subió al hosting ConexcolCloud, con el dominio avadadesing.com, con el fin de que sea visible desde cualquier lugar, por los evaluadores del proyecto, así dar una idea como estaría la aplicación funcionando al implementarla en el cliente, el link de ingreso desde cualquier lugar al servidor hosting de la aplicación es http://www.avadadesing.com/solusoporte1/ Este hosting cuenta con certificado SSL, el cual permite cifrar la información que viaja por HTTPS con SHA-2 de 2048, garantizando la seguridad de los datos. En este link se encuentra la aplicación para acceder al servidor con https https://www.avadadesing.com/solusoporte1/

En esta imagen se ve la estructura de archivos, alojados en el servidor de ConexcolCloud.

http://www.avadadesing.com/solusoporte1/

76

7 PRUEBAS DE LA APLICACIÓN En este capítulo se realizan las pruebas a la aplicación web, este capítulo corresponde a la etapa Integración y pruebas de sistema de la metodología en cascada. Las pruebas a realizar son: Casos de prueba y pruebas con aduits de google crome.

7.1 CASOS DE PRUEBA Como pruebas unitarias, se realizó los casos de prueba, los cuales evalúan la aplicación web con respecto a los casos de uso, siguiendo el flujo normal de eventos, estos eventos se deben ver reflejados en la aplicación web, al frente de cada paso hay una celda para ingresar los resultados del paso, y comprobar así si el caso de uso está completamente implementado en la aplicación web. Finalizado el caso de prueba se debe escribir las observaciones adicionales y marcar con una (X) si aprueba o se rechaza el caso de prueba. El siguiente es el formato establecido para realizar los casos de prueba.

77

Figura 28. Formato de casos de prueba

Usuarios para realizar los casos de prueba. Proveedor:

Usuario: [email protected] Contraseña: abka12345

Cliente:

Usuario: [email protected] Contraseña: profamilia12345 Usuario: [email protected] Contraseña: decameron12345

Técnico:

Usuario: [email protected] Contraseña: holamundo123

La lista de los casos de prueba es la siguiente:

mailto:[email protected]

78

Figura 29. Resultados evaluación de los casos de prueba

7.2 PRUEBAS ADUITS DE GOOGLE Se realizaron pruebas con la herramienta de google audits en la cual se evalúan los siguientes ítems:

Rendimiento

¿Cuánto tiempo lleva esta aplicación para mostrar contenido y ser utilizable?

Aplicación web progresiva

¿Cumple esta página el estándar de una aplicación web progresiva?

Mejores prácticas

¿Esta página sigue las mejores prácticas para el desarrollo web moderno?

Accesibilidad

¿Es esta página utilizable por personas con discapacidades o discapacidades?

SEO

Esta página está optimizada para el ranking de resultados de los motores de búsqueda

79

A continuación se mostraran los resultados por cada ítem en los cuales no muestran cuantas pruebas pasaron y cuantas fallaron en la auditoria de la aplicación.

Resultados de cada auditoria:

Figura 30.Resultados auditoria

Rendimiento (Performance):

Figura 31. Resultados rendimiento

80

Oportunidades de mejora y diagnóstico.

Auditoria aprobadas

Figura 32. Oportunidades de mejora de rendimiento

Figura 33. Auditorias aprobadas de rendimiento

81

Aplicación web progresiva (Progressive Web App):

Auditoria aprobadas

Auditorias Fallidas:

Figura 34. Auditoria de aceptación de HTTPS

Figura 35. Auditoria fallida web progresiva

82

Figura 36. Accesibilidad Auditorias fallidas

Accesibilidad (Accessibility):


Auditorias Aprobadas:

83

Figura 37. Auditorias aprobadas de accesibilidad

Mejores prácticas (Best Practices):



Figura 38. Auditorias fallidas de mejores prácticas en el código

Figura 39. Auditorias aprobadas de mejores prácticas de código

84

SEO

Auditorias fallidas.


Figura 41. Auditorias aprobadas de SEO

Figura 40. Auditorias fallidas de SEO

85

TRABAJO FUTURO Durante la investigación se realizó un listado de requerimientos, los cuales se analizaron en la en tapa de análisis de requerimientos, en esta etapa se enlistaron unos requerimientos funcionales que son importantes implementar a futuro. Estos requerimientos son:

Cuadro 4 Requerimientos a futuro.

Dos de estos requerimientos son informes solicitados por el cliente entrevistado, (Seguimiento detallado por impresora y Descargar hoja de vida), estos pueden ser desarrollados con la información y estructura de la base de datos generada en el proyecto. Los requerimientos funcionales planteados en la lista, (Análisis de datos inteligente personalizable y automatización de procesos), se puede manejar con inteligencia artificial, elaborando así automáticamente alertas de falencias en el servicio, buscar una solución a un servicio automáticamente para el técnico con la base de conocimientos, asignación inteligente de técnicos de acuerdo a su agenda y disponibilidad, esto necesita ser investigado a fondo para implementarlo, teniendo como base este proyecto. Realización de una aplicación móvil es importante es importante para el técnico para tener un localización exacta, y que él pueda reportar de manera rápida la solución a un requerimiento, sin necesidad de disponer internet, a través de una arquitectura móvil que permita manejar el modo offline del celular

86

CONCLUSIONES

Se desarrolló una aplicación web acorde a las principales necesidades de los 3 actores que interviene en los servicios de outsourcing de impresión (Cliente, Técnico, Proveedor), permitiendo que se centralice los canales de comunicación en una sola aplicación, donde se evidencia la trazabilidad de los servicios y se controla la gestión y calidad de los mismos.

Los lenguajes de programación escogidos junto con el frameworks, facilitaron el desarrollo de la aplicación permitiendo finalizar el proyecto en el tiempo establecido para la entrega.

Se comprobó que la documentación de PHP y Codeigniter, es bastante amplia permitiendo encontrar soluciones rápidas a los errores presentados durante el desarrollo

Se comprobaron las falencias descritas al principio del documento tales como:

o El Incumplimiento en los tiempos de atención que se acordaron entre

el proveedor con el cliente. o Información en tiempo real del estado de la solicitud del cliente. o Seguimiento de la calidad del servicio de los técnicos. o Localización en tiempo real de los técnicos. o Optimización de rutas de los técnicos.

Están señaladas en las encuestas realizadas a personas que intervienen dentro servicio de outsourcing de impresión (Cliente, Técnico, Proveedor).

Con base en la información recolectada en las entrevistas realizadas, se obtuvieron las problemáticas reales que se están presentado actualmente en las empresas tomadas como caso de estudio (RICOH y ABKA) ,para ser solucionadas a través de la aplicación Web.

Con las problemáticas encontradas en la investigación, se plasmaron en los requerimientos funcionales y no funcionales dando continuidad a la siguiente etapa dentro del modelo de desarrollo en cascada, describiendo detalladamente los casos de uso por cada requerimiento.

Se realizó la priorización de los requerimientos, con el fin de identificar cuales se debe desarrollar, permitiendo cumplir con los objetivos planteados.

87

Se desarrolló el diseño de la aplicación conforme a los requerimientos funcionales y no funcionales planteados.

Con el diseño de los diagramas de secuencia se logró identificar el flujo de datos que se debe presentar dentro de la aplicación.

Con el diseño del diagrama de clase se definió una estructura que nos benefició para el desarrollo de la aplicación.

Se desarrolló la aplicación web cumpliendo todos los requerimientos planteados.

El uso del framework Bootstrap, facilito el desarrollo de la interfaz, permitiendo que la aplicación sea más amigable y fácil de usar.

El uso de las librerías del framework Codeigniter, facilito el manejo y seguridad de los datos.

Con el uso de los casos de prueba se lograron identificar errores presentados dentro la aplicación con el fin de corregirlos.

El uso del CheckList permitió la comprobación de realización de todas las funcionalidades propuestas.

Manteniendo la información actualizada de los servicios solicitados para cada uno de los roles, permite tener una retroalimentación y realizar acciones rápidas a los servicios.

89

10 BIBLIOGRAFÍA

HEURTEL, Oliver. PHP 5.5: Desarrollar un sitio Web dinámico e interactivo, Eni ediciones, 2014, 322p.

LUNA, Fernando. Desarrollo web para dispositivos móviles: herramientas para

diseñar y programar WebApps, Buenos Aires, Dalaga, 2014, 319p. MITCHELL, Lorna Jane. PHP: Web Service, O’Reilly Media, 2016, 320p. CATALÁN, Adrián. Curso Android: Desarrollo de aplicaciones móviles, Maestros

Web, 2011, 360p. PRESSMAN, Roger. Ingeniería del software: un enfoque práctico. 7ª edición.

México: McGraw-Hill, 2010, 777p.

SOMMERVILLE, Ian. Ingeniería de software. 9ª edición. México: Pearson, 2011, 792p

TALLEDO SAN MIGUEL, José. Implantación de aplicaciones web: en entornos

internet, intranet y extranet. 1a edición. España: Paraninfo, 2015, 200p. RAMOS MARTÍN, Alicia y Jesús. Aplicaciones web. 2a edición. Madrid: Paraninfo,

2014. 366p. NUNCIO LIMÓN, Reynaldo. La magia del software: Historia, Fundamentos y

Perspectiva. 1a edición. México: CreateSpace Independent Publishing Platform, 2016, 351p.

PANTALEO, Guillermo. Ingeniería de software. 1ª edición. Bogotá: Alfaomega,

2015, 543p.

DOMÍNGUEZ, Víctor. Análisis en el desarrollo del software. 1ª edición. México: Amazon – ebook, 124p.

BASSO, Diego Martín. TESIS de Maestría en Ingeniería de Sistemas de

Información. Buenos Aires: Escuela de posgrado, 2014, 176p.

SÁNCHEZ, Ricardo. TESIS Maestro en ingeniería, México: Universidad Autónoma de México, 2014, 114p.

MATEU, Carles. Desarrollo de aplicaciones web. 1a edición. Catalunya: UOC

Formación de Posgrado, 2004, 378p.

90

MARTÍNEZ SUÁREZ, Mery Nicolasa. El contrato de outsourcing en la legislación colombiana. {En línea}.Barranquilla, Febrero 20 de 2013, 171p. Trabajo de grado (Abogado). Universidad de la Costa Disponible en: (http://repositorio.cuc.edu.co/xmlui/bitstream/handle/11323/60/30562647.pdf?sequence=1)

RIDAO, Marcela. Uso de patrones en el proceso de construcción de escenarios.

La Plata, 2014, 90p. Tesis (Maestría en ingeniería de sistemas). Universidad Nacional De La Plata. Facultad de Ingeniería.

DÁVILA SILVA, Pablo. Historia del hardware y software. {En línea}. Fecha. {05 de

octubre del 2017}. Disponible en http://www.paginaspersonales.unam.mx/files/490/HISTORIA-HARDWARE_Y_SOFTWARE.pdf

CHÁVEZ, Eder. Historia y evolución del software. {En línea}. Fecha. {06 de

octubre del 2017}. Disponible en https://ederchavezacha.files.wordpress.com/2013/02/historia-y-evolucic3b3n-del-software.pdf

REVISTA, Dinero. El servicio de outsourcing o tercerización, Artículo, Revista

Dinero, {En línea}. Fecha. {07/23/2014}. Disponible en: http://www.dinero.com/especiales-comerciales/outsourcing/articulo/servicio-outsourcing-tercerizacion-colombia/199002

PAGINA, web. Acuerdo de Nivel de Servicio (ANS) o Service Level Agreement (SLA), {En línea}. Fecha. {28/10/2017}. Disponible en: http://tecnologia.elderecho.com/tecnologia/internet_y_tecnologia/Servicio-ANS-Service-Agreement-SLA_0_700875067.html

OKTABA, Hanna. Historia y futuro de la Ingeniería de Software. Visión de Barry

Boehm., {En línea}. Fecha. {28/10/2017}. Disponible en: https://sg.com.mx/revista/9/historia-y-futuro-la-ingenier-software-vision-barry-boehm#.WfeuCWhL_IV

BULLA, José Efraín. Presentación diapositiva: ¿qué es una tesis?, Bogotá D.C.

Universidad Piloto de Colombia, 2017.

BLOG, programacion.net. ¿Por qué elegir PHP?, Artículo, {En línea}. Fecha. {08/03/2015}. Disponible en: http://programacion.net/articulo/por_que_elegir_php_143

BLOG, Arsys. PHP vs. ASP/ASP.NET, ¿qué opción elegir?, Artículo, {En línea}. Fecha. {08/05/2015}. Disponible en:

http://repositorio.cuc.edu.co/xmlui/bitstream/handle/11323/60/30562647.pdf?sequence=1

http://repositorio.cuc.edu.co/xmlui/bitstream/handle/11323/60/30562647.pdf?sequence=1

http://www.paginaspersonales.unam.mx/files/490/HISTORIA-HARDWARE_Y_SOFTWARE.pdf

http://www.paginaspersonales.unam.mx/files/490/HISTORIA-HARDWARE_Y_SOFTWARE.pdf

https://ederchavezacha.files.wordpress.com/2013/02/historia-y-evolucic3b3n-del-software.pdf

https://ederchavezacha.files.wordpress.com/2013/02/historia-y-evolucic3b3n-del-software.pdf




http://tecnologia.elderecho.com/tecnologia/internet_y_tecnologia/Servicio-ANS-Service-Agreement-SLA_0_700875067.html

http://tecnologia.elderecho.com/tecnologia/internet_y_tecnologia/Servicio-ANS-Service-Agreement-SLA_0_700875067.html

http://programacion.net/

http://programacion.net/articulo/por_que_elegir_php_143

http://programacion.net/

91

https://www.arsys.es/blog/programacion/php-o-asp-que-elijo-para-mi-web/

SANTA MARIA, Luiggi. PHP vs. ASP/ASP.NET, 12 Ventajas de la Programación PHP que Debes Saber, Artículo, {En línea}. Fecha. {24/07/2014}. Disponible en: http://www.staffcreativa.pe/blog/ventajas-programacion-php/

BERZAL, Fernando. CORTIJO, Francisco José. CUBERO, Juan Carlos. Desarrollo

profesional de aplicaciones web con ASP.NET, 1ª edición, España: Editorial Desconocida, 2005, 177p.

PROKOFYEVA, Natalya. BOLTUNOVA, Victoria. Analysis and Practical

Application of PHP Frameworks in development of Web Information Systems. {En línea}. Letonia, Diciembre 2016, 6p. Artículo de ScienceDirect Disponible en: (https://www.sciencedirect.com/science/article/pii/S1877050917300601)

MARIÑO URQUIAGA, Jean Carlos. ¿Por qué aprender Python? {En línea}. Fecha. {05 de octubre del 2017}. Disponible en https://devcode.la/blog/por-que-aprender-python/

BAHIT, Eugenia. Curso: Python para Principiantes, 1ª edición, PYTHON,

sefeCREATIVE, 2012, 136p.

PRESCOTT, Preston. La programación JavaScript, 1ª edición, País desconocido, Babelcube, Inc., 2016, 110p.

WEB, php. ¿Qué es PHP? {En línea}. {20 febrero de 2018} disponible en:

http://php.net/manual/es/intro-whatis.php

WEB, ecured. PHP {En línea}. {20 febrero de 2018} disponible en: https://www.ecured.cu/PHP

MAZA, Saray. JAVA Vs PHP: Eterno debate {En línea}. {20 febrero de 2018}

disponible en: https://www.facilcloud.com/noticias/java-vs-php-eterno-debate/

MIKOLUK, Kasia. PHP vs Java: ¿Cuál es el Lenguaje para Desarrollar un Futuro Brillante? {En línea}. {20 febrero de 2018} disponible en: https://blog.udemy.com/php-vs-java-cual-es-el-lenguaje-para-desarrollar-un-futuro-brillante/

TATROE Kevin, MACLNTYRE Peter, LERDORF Rasmus. Programming PHP:

Creating Dynamic Web Pages, 3ª Edición, O´REILLY, 2013

ZURB, Foundation, Introduction to Foundation, {En línea}. {29 marzo de 2018} disponible en: https://zurb.com/university/foundation-intro



http://www.staffcreativa.pe/blog/author/admin/

http://www.staffcreativa.pe/blog/ventajas-programacion-php/

https://www.sciencedirect.com/science/article/pii/S1877050917300601

https://devcode.la/blog/por-que-aprender-python/

https://devcode.la/blog/por-que-aprender-python/

http://php.net/manual/es/intro-whatis.php

https://www.ecured.cu/PHP

https://www.facilcloud.com/noticias/java-vs-php-eterno-debate/

https://blog.udemy.com/php-vs-java-cual-es-el-lenguaje-para-desarrollar-un-futuro-brillante/

https://blog.udemy.com/php-vs-java-cual-es-el-lenguaje-para-desarrollar-un-futuro-brillante/

https://zurb.com/university/foundation-intro

92

ÁNGEL COBO, PATRICIA GÓMEZ., PHP y MySQL. Tecnologías para el desarrollo de aplicaciones, Díaz de Santos 2015

Documentación oficial de Codeigniter, {En línea}. {05 abril de 2018} disponible en:

https://www.codeigniter.com/user_guide/

UMMI KHAIRA LATIF, TIEN FABRIANTI KUSUMASARI, Performance Comparison of Executing Large Data in Yii2 and Laravel Framework. Indonesia, 2017, 6p. artículo científico. Telkom University. Department of Industrial Engineerin.

ARIAS, Ángel. Aprende a Programar ASP.NET y C#, 2ª Edición, Editorial

desconocida, 2008.

ARIAS, Ángel. Aprende a programar con Java, 1ª edición, Editorial desconocida, 2007.

NATALYA PROKOFYEVAA, VICTORIA BOLTUNOVA, Analysis and Practical

Application of PHP Frameworks in Development of Web Information Systems. Riga, Latvia, 2016, 6p. Artículo científico ScienceDirect, Riga Technical University.

Natsys, Introducción a la programación en Perl, CGI y JavaScript: Con código

fuente de ejemplo y ejercicios. 1ª edición, editorial desconocida, 2018.

FORTA, Ben. Introducing ColdFusion, {En línea}. {29 febrero de 2018} disponible en: http://www.adobepress.com/articles/article.asp?p=31062&seqNum=4

BAHIT, Eugenia. Curso: Python para Principiantes, {En línea}. {18 Marzo de 2018}

disponible en: https://www.iaa.csic.es/python/curso-python-para-principiantes.pdf

GRADOS, Julio Giampiere. ¿Qué es JavaScript?, {En línea}. {20 Marzo de 2018} disponible en: https://devcode.la/blog/que-es-javascript/

ARIAS, Miguel A. Webs Responsivas. Responsive Design con Bootstrap, 1ª

edición, IT Campus Academy, 2014.

EduZRO, Los 16 mejores Frameworks de PHP, {En línea}. {20 Marzo de 2018} disponible en: https://www.neoguias.com/mejores-frameworks-gratuitos-de-php/

F. SIERRA, J. ACOSTA, J. ARIZA Y M. SALAS, Estudio y análisis de los

framework en PHP basados en el modelo vista controlador para el desarrollo de software orientado a la web. Barranquilla, Colombia, 2013, 13p. Artículo investigación, Revista Universidad Simón Bolívar.

http://www.adobepress.com/articles/article.asp?p=31062&seqNum=4

https://www.iaa.csic.es/python/curso-python-para-principiantes.pdf

https://devcode.la/blog/que-es-javascript/

https://www.neoguias.com/mejores-frameworks-gratuitos-de-php/

93

GUERRERO, Sandra. Bootstrap 3: ¿Vale La Pena Usar un Framework?, {En línea}. {22 Marzo de 2018} disponible en: http://www.esandra.com/diseno-web-responsive-usar-framework

Administrador del blog, 6 Frameworks PHP Para El Desarrollo Ágil De

Aplicaciones Web, {En línea}. {22 Marzo de 2018} disponible en: http://blog.hostdime.com.co/6-frameworks-php-para-el-desarrollo-agil-de-aplicaciones-web/

Documentación YII, Yii2 Framework - ¿Qué es Yii?, {En línea}. {22 Marzo de 2018}

disponible en: https://yii2-framework.readthedocs.io/en/stable/guide-es/intro-yii/

KITIPOVA, Iva. Best PHP Frameworks of 2017: a Beginner’s Guide, {En línea}. {23 Marzo de 2018} disponible en: https://www.webhostface.com/blog/best-php-frameworks-of-2017/

Aplicaciones semejantes APPSAT.NET https://www.appsat.net/caracteristica/escritorio/, España, Argentina

2016 Gestión Servicio Técnico http: //gestionserviciotecnico.com/. USA, Argentina 2014 Eseaforms http://eseaforms.com/software-de-servicio-tecnico-y-mantenimientos

Madrid, Barcelona, España, 2016 ManageEngine https://www.manageengine.com/latam/service-desk/ USA, Canadá,

Australia, China, ucrania. 2015

http://www.esandra.com/diseno-web-responsive-usar-framework

http://www.esandra.com/diseno-web-responsive-usar-framework

http://blog.hostdime.com.co/6-frameworks-php-para-el-desarrollo-agil-de-aplicaciones-web/

http://blog.hostdime.com.co/6-frameworks-php-para-el-desarrollo-agil-de-aplicaciones-web/

https://yii2-framework.readthedocs.io/en/stable/guide-es/intro-yii/

https://www.webhostface.com/blog/best-php-frameworks-of-2017/

https://www.webhostface.com/blog/best-php-frameworks-of-2017/

https://www.appsat.net/caracteristica/escritorio/



http://gestionserviciotecnico.com/



http://eseaforms.com/software-de-servicio-tecnico-y-mantenimientos



https://www.manageengine.com/latam/service-desk/

DESARROLLO DE UNA APLICACIÓN WEB PARA EL SEGUIMIENTO …

Documents

Transcript of DESARROLLO DE UNA APLICACIÓN WEB PARA EL SEGUIMIENTO …