DESARROLLO DE UN SISTEMA DE INFORMACION DE SOPORTE A PARTIR DE PATRONES DE DISEÑO UTILIZANDO SYMFONY EN LA EMPRESA ICAD DISEÑO INTELIGENTE, C.A.

Transcripción

1 DESARROLLO DE UN SISTEMA DE INFORMACION DE SOPORTE A PARTIR DE PATRONES DE DISEÑO UTILIZANDO SYMFONY EN LA EMPRESA ICAD DISEÑO INTELIGENTE, C.A. Autor: Noguera, Victoria Municipio San Diego, Calle N 3. Urb. Yuma II (Detrás del Conjunto Residencial Poblado)

2 REPÚBLICA BOLIVARIANA DE VENEZUELA UNIVERSIDAD JOSÉ ANTONIO PÁEZ FACULTAD DE INGENIERÍA ESCUELA DE INGENIERÍA EN COMPUTACIÓN DESARROLLO DE UN SISTEMA DE INFORMACION DE SOPORTE A PARTIR DE PATRONES DE DISEÑO UTILIZANDO SYMFONY EN LA EMPRESA ICAD DISEÑO INTELIGENTE, C.A. Trabajo de grado presentado como requisito para optar al título de INGENIERO DE COMPUTACIÓN Autor: Noguera, Victoria Tutor: Lcdo. José Canache. San Diego, Enero de 2013

3

4

5 ÍNDICE CONTENIDO Pág. INDICE DE CUADROS... vii INDICE DE FIGURAS... viii RESUMEN... ix INTRODUCCIÓN... 1 CAPÍTULO I EL PROBLEMA 1.1 Planteamiento del Problema Formulación del Problema Objetivos de la Investigación Objetivo General Objetivos Específicos Justificación... 5 II MARCO TEÓRICO 2.1 Antecedentes Bases Teóricas Help Desk Scrum Roles Fases Lenguaje de Modelado Unificado Patrones de Diseño Modelo-Vista-Controlador Front Controller Intercepting Filter View Helper Active Record Query Object ORM Doctrine DQL Framework Symfony Definición de Términos... 23

6 III MARCO METODOLÓGICO 3.1 Tipo de Investigación Diseño de la Investigación Nivel de la Investigación Población y Muestra Técnicas e Instrumentos de recolección de datos Análisis de los datos Fases de la Investigación IV RESULTADOS 4.1 Fase I: Planificación Fase II: Diseño Diagrama de Clases Diagrama de Casos de Uso Casos de Uso Narrativos Diagrama del Modelo Relacional Modelos de Interfaces Fase III: Desarrollo Fase IV: Cierre CONCLUSIONES RECOMENDACIONES REFERENCIAS Bibliográficas Electrónicas ANEXOS... 52

7 ÍNDICE DE CUADROS CUADRO Pág. 1 Caso de uso narrativo Crear Contratos Caso de uso narrativo Crear Ticket Caso de uso narrativo Responder Ticket Caso de uso narrativo Cerrar Ticket... 38

8 ÍNDICE DE FIGURAS FIGURA Pág. 1 Diagrama de Clases Diagrama de Casos de Uso Diagrama del Modelo Relacional Interfaz Principal de Módulos Tipo Interfaz Principal de Módulos Tipo Interfaz Principal de Módulo de Administración Vista Genérica de Detalle en Módulo Vista Genérica de Creación en Módulo Vista Genérica de Editar en Modulo Estructura Carpetas en Symfony... 44

9 REPÚBLICA BOLIVARIANA DE VENEZUELA UNIVERSIDAD JOSÉ ANTONIO PÁEZ CARRERA INGENIERÍA FACULTAD DE INGENIERÍA EN COMPUTACIÓN DESARROLLO DE UN SISTEMA DE INFORMACION DE SOPORTE A PARTIR DE PATRONES DE DISEÑO UTILIZANDO SYMFONY EN LA EMPRESA ICAD DISEÑO INTELIGENTE, C.A. Autor: Noguera, Victoria Tutor: José Canache Fecha: Noviembre, 2012 RESUMEN El estudio tiene como objetivo general desarrollar un sistema de información de soporte a partir de patrones de diseño utilizando Symfony con el propósito de automatizar los procesos más importantes en el departamento de soporte en la empresa icad Diseño Inteligente, C.A.. Los sistemas help desk proporcionan herramientas fundamentales para los analistas como lo es la gestión de reportes además de permitir a los usuarios internos (empleados) y externos (clientes) ser beneficiarios de la aplicación En la empresa icad Diseño Inteligente se hace necesario implementar un sistema help desk debido a que no cuenta con ninguno para la gestión de los datos de clientes, y estos deben comunicarse vía telefónica, electrónica o personal para solicitar asistencia. Se escogió la metodología SCRUM con la incorporación de algunos diagramas en Lenguaje de Modelado Unificado (Unified Modeling Language UML) con el objetivo de complementar la documentación del proceso de desarrollo por cuanto SCRUM no proporciona diagramas de este tipo. Para llevar a cabo este proyecto se utilizarán patrones de diseño y un Framework que incorpore esos patrones de diseño más el uso de algunas librerías para facilitar el desarrollo del sistema, en este caso se utilizará el Framework Orientado a Objetos denominado Symfony y se validará que con su correcta aplicación se realizar un sistema help desk. Metodológicamente es un estudio que corresponde al tipo de proyecto factible, descriptivo, no experimental. Las fases de investigación son: planificación, diseño, desarrollo y cierre. Descriptores: SCRUM, patrones de diseño, Symfony

10 INTRODUCCIÓN Hoy en día, el constante mejoramiento y equilibrio en los objetivos de las empresas hace necesaria la incorporación de nuevas tecnologías como los sistemas de información de soporte, que tienen como objetivo gestionar y solucionar de manera rápida y eficiente todas las posibles incidencias y/o requerimientos realizados por los clientes. Las empresas de desarrollo de software usualmente implementan este tipo de sistemas para automatizar los procesos en el departamento de soporte y así brindar mejor calidad de servicio a sus clientes. A pesar de las mejoras en productividad operativa y reducción en costos de soporte que ofrece la implementación de estos sistemas, todavía existen empresas con una gran necesidad de estas tecnologías, y es el caso de la empresa icad Diseño Inteligente, C.A., por ello se hizo necesario estudiar de forma detallada cada uno de los procesos y actividades que se realizan en el departamento de soporte, para poder automatizarlos y solventar los problemas generados. Atendiendo a la situación se realiza la investigación, de manera que al apoyarse en un sistema de información de soporte se logre automatizar y mejorar los procesos que se llevan a cabo en el departamento de soporte de la empresa icad Diseño Inteligente, C.A. El trabajo que se presenta a continuación está estructurado por cuatro capítulos. A continuación se presenta una breve descripción de cada uno de ellos: En el primer capítulo titulado El problema se puede encontrar el planteamiento de la problemática de no contar con procesos automatizados en el departamento de soporte de la empresa icad Diseño Inteligente, C.A., de acuerdo al planteamiento se formula la interrogante Cómo se puede mejorar el soporte a clientes en la empresa icad Diseño Inteligente, C.A.? y en base a esa interrogante se plantea el desarrollo de un sistema de información de soporte a partir de patrones de diseño utilizando el Framework Symfony, y se justifica la investigación, para luego establecer el objetivo general y los objetivos específicos.

11 Del mismo modo, en el segundo capítulo que lleva por nombre Marco Teorico se presentan los fundamentos y basamentos del proyecto, a través de los antecedentes que guardan relación con la investigación, bases teóricas correspondientes a los sistemas help desk, detalles de construcción de un sistema help desk, la metodología SCRUM, los patrones de diseño, el framework a partir de patrones de diseño, Symfony y las definiciones de términos básicos. Igualmente en el tercer capítulo denominado Marco Metodológico se determina el tipo, nivel y diseño de la investigación, los cuales caracterizan a éste proyecto, como también los procesos que se tomaran como población y la muestra que será objeto de estudio, las técnicas utilizadas para la recolección de datos y el análisis de los mismos y las fases metodológicas para el desarrollo del sistema de información de soporte. Finalmente, en el último capitulo designado Resultados se encuentran los resultados de cada fase metodológica para el desarrollo del proyecto. 2

12 CAPÍTULO I EL PROBLEMA 1.1. Planteamiento del problema Con el avance de la tecnología muchas empresas deciden crear su propio sitio web para adquirir muchos de los beneficios que ofrece, en el caso de una empresa, un sitio web significa reducción de costos, así como retroalimentación con el cliente y su imagen. Aun así, crear un sitio web de acuerdo a la finalidad requerida no es tarea fácil, se deben tomar en cuenta muchas variables, como lo son: la actividad de la empresa, a quien estará dirigida la información, que se quiere transmitir con el sitio, entre otras. Existen en la actualidad infinidad de empresas alrededor del mundo que se encargan de desarrollar sistemas y sitios web, su prioridad además de entregar productos de calidad es contar con sistemas para brindar a sus clientes la mejor atención y el control total sobre sus productos y/o servicios. icad Diseño Inteligente, C.A. es una empresa dedicada a diseñar sistemas y sitios web, siendo una de las más reconocidas en el ramo por su calidad de servicio. Gracias a esto, cada uno de sus clientes a nivel nacional deposita su confianza para el desarrollo de sistemas y sitios web de acuerdo a su necesidad. En consecuencia de los avances de la tecnología web, la demanda y la necesidad de los clientes, la empresa icad Diseño Inteligente, C.A. se vio en la necesidad de desarrollar un Content Management System (CMS) innovador como lo es el denominado MiWeb. Mi Web se realizó tomando en cuenta conceptos importantes como lo son la accesibilidad, compatibilidad, usabilidad y el posicionamiento web, con la finalidad de ofrecer sitios web de calidad en el menor tiempo posible, que proporcionen los diferentes beneficios del internet de acuerdo a cada uno de los clientes y sus necesidades, además de proporcionar sitios únicos que minimizan los costos por mantenimiento y actualizaciones. 3

13 En los últimos 9 años, gracias a la gran demanda de sitios y sistemas web, el equipo de la empresa icad Diseño Inteligente, C.A. se ha centrado tanto en la mejora del CMS como en el desarrollo de sistemas especializados para sus clientes, que han descuidado algunos de los departamentos que integran a la empresa, además de la filosofía que radica en la satisfacción de cada uno de ellos, la cual no sólo abarca el desarrollo del sitio, sino también, el contacto con el cliente post-entrega y la atención en general. En consecuencia, el departamento de soporte no cuenta con ningún sistema para la gestión de los datos de clientes, esto conlleva a que cualquier información relacionada con el cliente se guarda en hojas electrónicas que son distribuidas en carpetas con el nombre del cliente y que no poseen respaldo alguno, si el cliente necesita asistencia de alguna u otra manera se debe comunicar vía telefónica o electrónica con el departamento relacionado a su requerimiento y puede ocurrir la pérdida del cliente si no se responde prontamente Formulación del Problema De acuerdo a lo planteado se formula la siguiente interrogante: Cómo se puede mejorar el soporte a clientes en la empresa icad Diseño Inteligente, C.A.? 1.3. Objetivos de la investigación Objetivo General Desarrollar un sistema de información de soporte a partir de patrones de diseño utilizando Symfony en la empresa icad Diseño Inteligente, C.A Objetivos Específicos Diagnosticar los procesos más utilizados en el departamento de soporte de la empresa icad Diseño Inteligente, C.A. Determinar los requerimientos del sistema. Modelar los procesos más utilizados en el departamento de soporte de la empresa icad Diseño Inteligente, C.A. 4

14 Diseñar la arquitectura del sistema que permita implementar los requerimientos definidos. Desarrollar el sistema. Evaluar la funcionalidad de los módulos tanto individualmente como en conjunto para detectar posibles fallas. Documentar el sistema Justificación La automatización de procesos manuales repetitivos ha representado un gran avance para empresas pertenecientes a diferentes ramas alrededor del mundo ya que significa un importante incremento en la productividad de los empleados e influye en la satisfacción del cliente debido a que usualmente son sometidos a tediosos procesos manuales para poder realizar alguna solicitud. Actualmente para contratar algún servicio a cualquier empresa, el consumidor busca la mejor calidad al menor precio, y en esta era tecnológica esa relación de mejor calidad al menor precio es posible gracias a la automatización de procesos y a los sistemas de información con diferentes finalidades, que a menudo son utilizados tanto por clientes como por empleados con el objetivo de alcanzar las metas fijadas por la empresa y para facilitar la interacción con el cliente. Las empresas de desarrollo de software no son la excepción a la regla, son estas las que trabajan de mano con la tecnología y no pueden entregar productos de calidad utilizando procesos manuales, los cuales conllevan a posibles errores u omisiones no deseadas, de estos procesos depende la calidad tanto de productos como servicios que ofrezcan y esto influye en la decisión de los posibles consumidores a contratar sus servicios o no. Para que estas empresas puedan cumplir con las expectativas tanto de clientes actuales como clientes potenciales, es necesario automatizar procesos que en este caso, se hace mediante la implementación de sistemas de información de diferentes tipos para cada uno de los departamentos, estos sistemas a menudo 5

15 mejoran el tiempo de respuesta a los clientes lo cual aumenta proporcionalmente el nivel de satisfacción del mismo. icad Diseño Inteligente, C.A. no es la excepción a la regla, algunos departamentos tienen sistemas implementados, lo que ha automatizado ciertos procesos, pero no se ha realizado totalmente. El almacenamiento de información relacionada con los clientes y el proceso a los que estos tienen que someterse para poder realizar un requerimiento y/o reportar una falla a cualquiera de los departamentos continua siendo comunicarse por teléfono, enviar un correo electrónico o dirigirse a la oficina y es bastante tedioso, en especial, para una empresa que desarrolla tecnología y sistemas que automatizan procesos, esta evidente desventaja influye en la satisfacción del cliente, que con el tiempo disminuye y eventualmente lleva a la terminación de la relación con el mismo. El objetivo principal del desarrollo del sistema de información de soporte a partir de patrones de diseño utilizando Symfony en la empresa icad Diseño Inteligente, C.A es automatizar los procesos en el departamento de soporte permitiendo un mejor control de la información y una mejor administración de los requerimientos realizados por los clientes, lo cual mejoraría considerablemente el tiempo de respuesta por parte de los departamentos e indiscutiblemente la satisfacción y la permanencia del cliente en la empresa. 6

16 CAPÍTULO II MARCO TEÓRICO 2.1. Antecedentes Schwaber, Ken (1995), publicó el artículo titulado: Scrum Development Process, para una serie de conferencias dictadas por el creador de Scrum Jeff Sutherland. El articulo describe el proceso de desarrollo con Scrum, y explica detalladamente que las metodologías en cascada, espiral o iterativas no responden adecuadamente al desarrollo de un sistema pues son bastante lineales y suponen que todo sale como se planea y que los requerimientos no cambian, ninguna de ellas dejan espacio para cambios no programados. Scrum tiene un alto grado de flexibilidad lo que quiere decir que tiene un alto grado de tolerancia para cambios y esto se convierte en el factor más importante para determinar las probabilidades de éxito al momento de desarrollar un sistema. Este articulo proporciona lo relacionado a la metodología SCRUM, los roles de las personas que interactúan en el desarrollo, a que se dedican cada una de esas personas dentro un de proceso de desarrollo, las fases de la metodología y lo que se debe hacer en cada fase. Así como, Sutherland, Jeff (2001) publicó un artículo titulado Agile Can Scale: Inventing and Reinventing Scrum in Five Companies que relata cómo se adaptó su metodología SCRUM a diferentes compañías para desarrollar distintos proyectos, los resultados que se obtuvieron verifican que la metodología funciona y da mejores resultados que las metodologías en cascada, espiral o iterativas. El articulo aporta una premisa a una de las interrogantes que surgen durante este proyecto, es válido SCRUM para desarrollar un sistema de información de soporte a partir de patrones de diseño utilizando Symfony en la empresa icad Diseño Inteligente, C.A.? ya que indica cómo se adapta la metodología a diferentes compañías pertenecientes a distintos ramos. 7

17 De igual forma, Luces, Elio (2011), presentó un trabajo de grado con el título de: Desarrollo de un sistema help desk para el control y gestión de operaciones, realizadas por la división de Telemática de la Dirección de Ciencia y Tecnología en la Gobernación del estado Monagas, para obtener el título de Ingeniero en Sistemas. Este trabajo plantea una solución automatizada para la administración y gestión de operaciones en la división de telemática de la dirección de ciencia y tecnología de la gobernación del estado Monagas. La metodología aplicada es una mezcla de Checkland con el Proceso Unificado (Unified Process - UP) y contiene elementos del Lenguaje de Modelado Unificado (Unified Modeling Language - UML). La investigación referida representa un aporte para dar de manera asertiva con algunos de los procesos que se tienen que mejorar, reconociendo cuales son exactamente los más importantes para la institución. De la misma manera permitió conocer el uso de los diferentes diagramas del lenguaje unificado para el modelado y documentación del sistema Bases Teóricas Help Desk Es un conjunto de servicios, que de manera integral a través de uno o varios medios de contacto ofrece la posibilidad de gestionar y solucionar de forma ordenada, rápida y eficiente todas las posibles incidencias o requerimientos realizados por clientes logrando mayor productividad corporativa y la consecuente reducción de costos de soporte Un sistema Help Desk proporciona herramientas fundamentales para los responsables de solución (analistas) como lo son la gestión de reportes y estadísticas además de permitir a los usuarios internos (empleados) y externos (clientes) ser beneficiarios de la aplicación al conseguir una eficaz solución real de los problemas a 8

18 tiempo, llevando registros, reasignaciones y seguimientos del usuario reportado hasta la satisfactoria solución del problema. La ventaja de contar con un sistema Help Desk es simple, incrementa la productividad y aumenta la satisfacción de los usuarios internos. Estos sistemas están diseñados para apoyar la labor productiva de los usuarios, garantizando la explotación eficiente de las aplicaciones, buscando a su vez la manera más eficiente y rentable de realizar esta labor. Broome, Streitwieser (2002), resume los beneficios de contar con un sistema Help Desk a continuación: o Punto único de contacto. Al tener un punto único de contacto, el usuario obtiene asistencia inmediata por parte de personas con los conocimientos apropiados y la disposición para atenderlo. o Registro y seguimiento de problemas. Cuando se reciben peticiones por problemas técnicos por parte de los usuarios, generalmente no se cuenta con los mecanismos y herramientas tecnológicas apropiadas para registrarlos constantemente, por lo que el registro y su seguimiento se hacen, con el tiempo, una tarea muy difícil de controlar. Con la gestión del Help Desk, se pretende crear estos mecanismos de forma automatizada para llevar un control preciso de todas las peticiones que se reciben, con la finalidad de generar, en un determinado lapso de tiempo, mediciones que permitan conocer la razón de las llamadas y las soluciones propuestas. o Capacidad de Respuesta. Mejoran la capacidad de respuesta y la resolución de problemas. Los Servicios de Gestión Help Desk reducen el tiempo de respuesta entre la solicitud de asistencia y la prestación del servicio gracias a la utilización de bases de datos de conocimiento automatizadas, acceso remoto y herramientas de diagnóstico. Si se 9

19 puede solucionar una incidencia a distancia, se elimina el tiempo de espera a la llegada de un técnico de campo. o Productividad. Este beneficio es, en la mayoría de los casos, uno de los más difíciles de demostrar a toda compañía que esté interesada en la función del Help Desk, aunque prácticamente es el más importante. Generalmente, cuando al usuario se le presenta un problema en la utilización de la tecnología, esto hace que su trabajo se detenga temporalmente hasta que el problema sea solucionado. Dependiendo de la magnitud del problema, esta temporalidad puede, a veces, convertirse en horas y días de interrupción de su trabajo, lo que hace que los resultados que se esperan por la función de dicho usuario, se retrasen. Lo anterior conlleva a que los costos involucrados en la operación de la organización se vean incrementados por estos tiempos caídos. o Auto ayuda para usuarios. Los usuarios pueden acceder a bases de conocimiento, probablemente a las mismas que usan sus analistas, para encontrar las soluciones a sus problemas. o Mecanismos de comunicación. Son aquellos que otorgan a los usuarios una alternativa al teléfono; una alternativa que algunos usuarios pueden encontrar más confortable o conveniente. Estos métodos tienen el beneficio adicional de preservar la entera interacción escrita, permitiendo a sus usuarios la capacidad de referirse a sus instrucciones tantas veces como sea necesario. Los sistemas de información Help Desk consisten en un conjunto de componentes interrelacionados que permiten capturar, procesar, almacenar y distribuir información, además de proveer un punto único de contacto donde los usuarios reciben ayuda mediante un sistema de rastreo de tickets. Cada ticket posee un número único de rastreo, intervenciones tanto del cliente como del analista que atiende la solicitud de ayuda así un nivel de prioridad y una categoría. 10

20 Para construir un sistema de información Help Desk se necesita definir el objetivo que se desea cumplir con el sistema, formular las estrategias para satisfacer los objetivos planteados, determinar los recursos a emplear, establecer el plan de trabajo para la construcción, diseñar las entradas y salidas del sistema en base a la interpretación de los requerimientos (objetivos) y la base de datos, definir los procesos (arquitectura del sistema), elegir el lenguaje y herramientas (si aplica) de programación a utilizar, codificar en el lenguaje elegido, compilar y depurar el sistema y realizar las pruebas correspondientes para finalmente lanzar el programa al mercado. Todos estos pasos están comprendidos dentro de las metodologías de desarrollo de software las cuales son un marco de trabajo utilizado para estructurar, planificar y controlar el proceso de desarrollo de sistemas de información de cualquier tipo Scrum. Scrum es una metodología iterativa e incremental de desarrollo ágil de software para la gestión de proyectos, productos o desarrollo de aplicaciones. Es un proceso de gerencia y control que implementa técnicas de control de procesos, se considera un conjunto de patrones organizacionales Roles. Scrum define seis roles: o Facilitador. Interactúa con el cliente y el equipo. Es responsable de asegurarse de que el proyecto se lleve a cabo de acuerdo con las prácticas, valores y reglas de Scrum y que progrese según lo previsto. Coordina los encuentros diarios, formula las tres preguntas canónicas Qué logré ayer?, Qué voy a hacer hoy?, Qué obstáculos están impidiendo mi progreso? y además, se encarga de eliminar eventuales obstáculos. Debe ser miembro del equipo y trabajar a la par. 11

21 o Propietario del Proyecto. Es el responsable oficial del proyecto, gestión, control y visibilidad de la lista de acumulación o lista de retraso del producto (backlog). Es elegido por el Scrum master, el cliente y los ejecutivos a cargo. Toma las decisiones finales de las tareas asignadas al registro y convierte sus elementos en rasgos a desarrollar. o Equipo de Scrum. Tiene autoridad para reorganizarse y definir las acciones necesarias o sugerir remoción de impedimentos. o Cliente. Participa en las tareas relacionadas con los ítems del registro. o Administrador. Está a cargo de las decisiones fundamentales y participa en la definición de los objetivos y requerimientos. Por ejemplo, selecciona al Dueño del Producto, evalúa el progreso y reduce el registro de acumulación junto con el Scrum master. o Usuario. La dimensión del equipo total de Scrum no debería ser superior a diez ingenieros. El número ideal es siete, más o menos dos, una cifra canónica en ciencia cognitiva. Si hay más, lo más recomendable es formar varios equipos. No hay una técnica oficial para coordinar equipos múltiples Fases: Scrum tiene las siguientes fases: o Planificación. Consiste en conceptualizar y analizar lo que se va a realizar en el proyecto. o Arquitectura/Diseño de Alto Nivel. Se diseña como se implementaran los elementos del backlog. Esta fase incluye modificación de la arquitectura del sistema y diseño de alto nivel. o Desarrollo (Sprint). Desarrollo de las funcionalidades para cada avance o entrega, tomando en cuenta las variables de tiempo, requerimientos, costo y calidad. o Cierre. Preparación para entrega final, incluye la documentación, las pruebas y la liberación al mercado. 12

22 Scrum a pesar de ser una metodología de desarrollo ágil comúnmente utilizada para software, no especifica que documentación se debe entregar al en la etapa de cierre, esta documentación debe realizarse en la etapa de arquitectura y diseño de alto nivel, para complementar la documentación y diagramación del sistema se utilizara UML (Unified Modeling Language) Lenguaje de Modelado Unificado (Unified Modeling Language - Language) Es un lenguaje gráfico para visualizar, especificar, construir y documentar un sistema que ofrece un estándar para describir un "plano" del sistema (modelo), incluyendo aspectos conceptuales tales como procesos y funciones del sistema, aspectos como expresiones de lenguajes de programación, esquemas de bases de datos y compuestos reciclados, además cuenta con varios tipos de diagramas los cuales muestran diferentes aspectos de las entidades representadas y se puede aplicar al desarrollo de software en gran variedad de formas para dar soporte a una metodología de desarrollo de software (en este caso SCRUM) Patrones de Diseño. Alexander, Christopher (1997) define un patrón de diseño como: El patrón describe un problema que se produce una y otra vez en nuestro medio, y luego describe el núcleo de la solución a ese problema, de tal manera que se puede utilizar la solución un millón de veces más, sin tener que hacerlo de la misma manera, luego Gamma, Helm, Johnson y Vlissides (2000) especifican que Las soluciones se expresan en términos de objetos y de interfaces en lugar de muros y puertas, pero el centro de los dos tipos de patrones es una solución a un problema en un contexto. Gamma, et al (2000) describen los elementos esenciales de un patrón de diseño de esta manera: o El nombre del patrón. Es una variable que podemos utilizar para describir un problema de diseño, sus soluciones y consecuencias en una o dos palabras. 13

23 o El problema. Describe cuándo aplicar el patrón. En él se explica el problema y su contexto. Podría describir los problemas específicos de diseño tales como la forma para representar algoritmos como objetos. Podría describir la clase de objeto o estructuras que son sintomáticos de un diseño inflexible. A veces, el problema incluirá una lista de condiciones que deben cumplirse antes de que tenga sentido aplicar el patrón. o La solución. Se describen los elementos que componen el diseño, sus relaciones, responsabilidades y colaboraciones. La solución no describe un diseño concreto particular o implementación, porque un patrón es como una plantilla que puede ser aplicado en muchas situaciones diferentes. En cambio, el patrón proporciona una descripción abstracta de un problema de diseño y cómo una disposición general de elementos (clases y objetos en nuestro caso) lo resuelve. o Las consecuencias. Son los resultados y compensaciones de la aplicación del patrón. Aunque las consecuencias no son tomadas en cuenta cuando se describen las decisiones de diseño, son fundamentales para la evaluación de alternativas de diseño y para la comprensión de los costes y beneficios de aplicar el patrón. Las consecuencias para el software a menudo son preocupación por espacio y el tiempo de respuesta. Pueden existir problemas de idioma y de implementación también. Dado que la reutilización es a menudo un factor en diseño orientado a objetos, las consecuencias de un patrón incluyen su impacto en la flexibilidad de un sistema, extensibilidad, o la portabilidad. Añadir las consecuencias explícitamente ayuda a entender y evaluar los patrones. 14

24 Modelo-Vista-Controlador Se comenzará con uno de los patrones de diseño más utilizados como lo es el Modelo-Vista-Controlador (Model-View-Controller MVC). McArthur, Kevin (2008) lo define como un patrón de diseño que simplifica el desarrollo y mantenimiento de aplicaciones. Esto se logra mediante la separación de la aplicación en tres componentes lógicos: o Modelo. El modelo es el responsable de la lógica de negocio de una aplicación. Se va a encapsular el acceso a la base de datos y proporcionará una biblioteca de clases reutilizables. Típicamente, en el modelo, se encuentran las instalaciones para la abstracción de la base de datos, entrega de correo electrónico, y la validación y autenticación. o Vista. Es lo que normalmente se consideraría el diseño web o las plantillas. Controla el aspecto y la sensación de datos y proporciona facilidades para recopilar datos del usuario. o Controlador. Es el de pegamento, fusiona el estilo de la vista con la funcionalidad del modelo. Es responsable de recoger de datos de entrada de la vista y decidir la ejecución del programa. El controlador llamará a los modelos e interpretará los datos que regresan de manera que se puedan representar por la vista. También es responsable de todas las excepciones de la aplicación y el control de flujo. Fowler, Martin (2002) continúa describiendo algunos de los patrones de diseño utilizados en el framework Symfony a continuación: Front Controller Es un controlador que se encarga de manejar todas las peticiones a un sitio web. En estos sitios generalmente se pueden encontrar muchos controladores que deben realizar varias tareas cuando reciben una petición, estas peticiones incluyen seguridad, internacionalización y cargar vistas diferentes dependiendo del tipo de usuario y si existen varios controladores de entrada ese comportamiento puede 15

25 terminar duplicándose. Su finalidad es consolidar todas las peticiones y canalizarlas a un único manejador de objetos, el cual se encarga a su vez de enviar las diferentes respuestas a las peticiones que recibió. El Front Controller consiste en dos partes, la primera el manejador web y la segunda una jerarquía de comandos, el manejador web es el objeto que recibe las peticiones y extrae suficiente información tanto de la URL como de la petición para posteriormente decidir qué acción iniciar y luego delega a un comando para ejecutar esa acción Intercepting Filter Alur, D., Crupi, J., Malks, D. (2001) explican que el problema por el cual nace este patrón es El mecanismo de manipulación de solicitudes de presentación recibe muchos tipos diferentes de peticiones, que requieren diversos tipos de procesamiento. Algunas peticiones son simplemente remitidas al de controlador adecuado, mientras que las demás solicitudes deben ser modificadas, controladas o descomprimidas antes de ser procesadas. Es decir, se requiere un pre y un post procesamiento de la petición de un cliente, algunas de las comprobaciones necesarias son pruebas que resultan en una respuesta dicotómica cerrada que determinan si el proceso continúa o no. La solución clásica consiste en una serie de comprobaciones condicionales, con cualquiera comprobación fallida se aborta la solicitud. Declaraciones anidadas if / else son una estrategia estándar, pero esta solución conduce a la fragilidad de código y un estilo de copiar y pegar en la programación, porque el flujo de la filtración y la acción de los filtros se compila en la aplicación. Entonces, la clave para resolver este problema de una manera flexible y discreta es tener un mecanismo simple para añadir y eliminar componentes de procesamiento, en el que cada componente realiza una acción de filtrado específico. Crear filtros portátiles para procesar servicios comunes de manera estándar sin requerir cambios en el código de procesamiento central petición. Los filtros interceptar las peticiones entrantes y las respuestas salientes, lo que permite preproceso y postproceso. Estos filtros son 16

26 componentes que son independientes del código de la aplicación principal, y que se puedan añadir o eliminar de forma declarativa. Por ejemplo, un archivo de configuración de despliegue puede modificarse para establecer una cadena de filtros. El mismo archivo de configuración puede incluir un mapeo de URL específicas para esta cadena de filtros. Cuando un cliente solicita un recurso que coincida con esta asignación de dirección URL configurado, los filtros de la cadena son procesados en orden antes de que el recurso solicitado se invoque. Tanto Intercepting Filter como Front Controller, describen maneras de centralizar el control de ciertos tipos de procesamiento, sugieriendo diferentes maneras de afrontar el problema View Helper Alur, et al. (2001) describen el problema detrás del nacimiento del patrón como Los cambios a nivel de presentación se producen con frecuencia, son difíciles de desarrollar y manteniendo la lógica de negocio de acceso a datos y la lógica de formateo de la presentación ya que están entrelazados. Este enlace hace que el sistema sea menos flexible, menos reutilizable, y generalmente menos resistente al cambio. Entremezcla el negocio y la lógica de los sistemas con el procesamiento con la vista reduce modularidad y también proporciona una pobre separación de funciones entre la producción web y los equipos de desarrollo de software. Es decir, su finalidad es fomentar la separación de código de la lógica de negocio. Para implementarlo se sugiere el uso de componentes auxiliares para encapsular la lógica relacionada con iniciar la recuperación de contenido, validación y adaptación y formato del modelo. La Vista se deja entonces para encapsular el formato de la presentación. Componentes auxiliares suelen delegar en las actividades empresariales a través de un Business Delegate, mientras que una vista puede estar compuesta de varios subcomponentes para crear su plantilla. El patrón Front Controller, en conjunto con View Helper, describen como separar la lógica de negocio de la vista y como proveer un punto de control y 17

27 despacho central. La lógica de flujo es un factor dentro del controlador y el código para manejar datos se mueve a los componentes auxiliares Active Record Fowler (2002) lo define como Un objeto que envuelve una fila en una tabla de base de datos o vista, encapsula el acceso a la base de datos y anade lógica de dominio a la data. Un objeto lleva datos y comportamiento, muchos de estos datos son persistentes y se necesitan almacenar en una base de datos. Active Record utiliza el enfoque más obvio, coloca lógica de acceso a la data en el objeto de dominio, de esta manera las personas saben cómo leer y escribir su data a la base de datos y viceversa. La esencia de un Active Record es un modelo de dominio en la que las clases coinciden muy de cerca a la estructura de una base de datos subyacente. Cada Active Record es responsable de guardar y cargar a la base de datos y también para cualquier lógica de dominio que actúe sobre los datos. Esto puede ser toda la lógica de dominio en la aplicación, o bien se puede encontrar que una cierta lógica de dominio se encontrará en Scripts de transacción con el código común y orientado a datos en el Active Record. La estructura de datos del Active Record debe coincidir exactamente con la de la base de datos: un campo en la clase para cada columna de la tabla. La clase Active Record típicamente tiene métodos que hacen lo siguiente: o Construir una instancia de Active Record desde una fila del conjunto de resultados SQL o Construir una nueva instancia para una inserción posterior en la tabla o Actualizar la base de datos e insertar en él los datos en el Active Record. o Obtener y establecer los campos o Poner en práctica algunas piezas de la lógica de negocio Los métodos de obtención y de establecimiento pueden hacer algunas cosas inteligente, tales como convertir de SQL orientadas tipos que son mejores en 18

28 memoria. Además, si se pide una tabla relacionada, el método de obtener puede devolver el adecuado Active Record, incluso si usted no está usando el campo de identidad en la estructura de datos. En este patrón, las clases son convenientes, pero no ocultan el hecho de que una base de datos relacional está presente. Como resultado se suelen ver menos de los patrones de mapeo objeto-relacional cuando se utiliza Active Record Query Object Gamma, et al (2000) lo definen como un intérprete, es decir, una estructura de objetos que pueden formarse en un consulta SQL. Esta consulta se puede crear haciendo referencia a las clases y los campos en lugar de tablas y columnas. De esta manera, los que escriben consultas pueden hacerlo independientemente del esquema de base de datos y los cambios en el esquema pueden ser localizados en un solo lugar. Una característica común de Query Objects es que puede representar consultas en el lenguaje de los objetos en memoria, es decir, en lugar del esquema de base de datos. Eso significa que, en lugar de utilizar nombres de tabla y de columna, puede utilizar el objeto y nombres de camp, aunque esto no es importante si los objetos y la estructura de base de datos es la misma pero puede ser bastante provechoso si se tienen variaciones entre los dos. Para realizar este cambio, el Query Object necesita saber cómo se mapea la estructura de base de datos a la estructura del objeto, una capacidad que realmente necesita Mapeo de metadatos. Un uso particularmente sofisticado del Query Object es eliminar consultas redundantes a la base de datos o incluso uno más sofisticado aun, permite detectar si una consulta es un caso particular de una consulta realizada anteriormente ORM Las bases de datos son relacionales. Con el fin de acceder a la base de datos en una forma orientada a objetos, una interfaz que traduzca la lógica de los objetos a la lógica relacional es requerida. Esta interfaz se denomina mapeo objeto-relacional, 19

29 u ORM. Un ORM se compone de objetos que permiten acceder a los datos y mantener las reglas de negocios en sí mismos. Uno de los beneficios de una capa de abstracción de objetos / relacional es que no le permite usar un sintaxis específica a una base de datos dada. Se traducen automáticamente las llamadas a los objetos del modelo a las consultas SQL optimizadas para la base de datos actual, esto significa que el cambio a otro sistema de base de datos en el medio de un proyecto es fácil. Una capa de abstracción encapsula la lógica de los datos. El resto de la aplicación no necesita saber acerca de las consultas SQL y el SQL que accede a la base de datos es fácil de encontrar. La utilización de objetos en vez de registros y clases en vez de tablas, presenta la ventaja de poder añadir nuevos accesos a las tablas Doctrine Es un mapeador objetorelacional (ORM) para PHP que proporciona persistencia transparente de objetos PHP. Se sitúa en la parte superior de una poderosa capa de abstracción de base de datos (DBAL por DataBase Abstraction Layer). La principal tarea de los asignadores objetorelacionales es la traducción transparente entre objetos (PHP) y las filas relacionales de la base de datos. Una de las características clave de Doctrine es la opción de escribir las consultas de base de datos en un dialecto SQL propio orientado a objetos llamado Lenguaje de Consulta Doctrine (DQL por Doctrine Query Language), inspirado en Hibernates HQL. Además DQL difiere ligeramente de SQL en que abstrae considerablemente la asignación entre las filas de la base de datos y objetos, permitiendo a los desarrolladores escribir poderosas consultas de una manera sencilla y flexible DQL DQL significa Lenguaje de consulta de Doctrine y es un derivado del objeto Query Language que es muy similar al lenguaje de consulta de Hibernate (HQL) o el 20

30 Lenguaje Java Persistence Query (JPQL). En esencia, DQL proporciona potentes capacidades de consulta a través de su modelo de objetos. Todos sus objetos por almacenados en algún sitio (como una base de datos de objetos). Al escribir consultas DQL, piense en consultar que el almacenamiento para elegir un determinado subconjunto de los objetos. Se suele confundir DQL con una forma de SQL, y tratar de usar los nombres de tabla y nombres de columna arbitrarios o unir tablas en una consulta. Se piensa en DQL como un lenguaje de consulta para un modelo de objetos, no para el esquema relacional Framework Potencier, F., Zaninotto F. (2007) consideran que un framework: simplifica el desarrollo de aplicaciones mediante la automatización de muchos de los patrones de diseño empleados para un propósito dado. Un framework se suma a la estructura de código, lo que incita al desarrollador a escribir un código mejor, más legible y más mantenible. En última instancia, un framework facilita la programación, ya que empaqueta operaciones complejas en instrucciones sencillas. En aplicaciones Web un Framework es diseñado para apoyar el desarrollo de sitios web dinámicos, aplicaciones y/o servicios web. Este tipo de frameworks proporcionan bibliotecas para acceder a bases de datos, estructuras para plantillas, gestión de sesiones y con frecuencia facilitan la reutilización de código Symfony Symfony es un Framework el cual es descrito por Potencier, et al (2007) como un framework completo diseñado para optimizar el desarrollo de aplicaciones web por medio de varias características clave. Symfony separa las reglas de negocio, la lógica del servidor y las vistas de presentación. Contiene numerosas herramientas y clases dirigidas a acortar el tiempo de desarrollo de una aplicación web compleja. Además, automatiza las tareas comunes para que el desarrollador pueda centrarse exclusivamente en los aspectos específicos de una aplicación. El resultado final de 21

31 estas ventajas significa que no hay necesidad de reinventar la rueda cada vez que se genera una nueva aplicación web. Symfony está escrito completamente en PHP 5 y se ha probado a fondo en diversos proyectos del mundo real proyectos, y está actualmente en uso para la alta demanda de comercio electrónico sitios web. Es compatible con los la mayoría de los motores de bases de datos disponibles, incluyendo MySQL, PostgreSQL, Oracle y Microsoft SQL Server. El sistema de soporte (help desk) ofrecerá un punto único de contacto, el registro y seguimiento de problemas, una capacidad de respuesta adecuada, incrementará la productividad, aumentará la satisfacción de los usuarios internos y externos y proporcionará la automatización de los procesos del departamento de soporte luego de modelarlos. Para su desarrollo se utilizará la metodología SCRUM la cual es una metodología iterativa e incremental utilizada para el desarrollo ágil de software que implementa técnicas de control de procesos; la planificación, la arquitectura o diseño de nivel, el desarrollo y el cierre son sus fases principales, cada una subdivida en varios puntos, pero a pesar de las ventajas y el control que representa frente a otras metodologías de desarrollo de software, SCRUM no suministra la documentación necesaria que debe tener un sistema de información de soporte, es por eso que para complementar SCRUM y poder documentar el sistema se harán uso de algunos diagramas UML. Finalmente, se empleará el Framework Symfony que proporciona una estructura básica de librerías que hacen más fácil el desarrollo de aplicaciones complejas y que se basa en patrones de diseño que son soluciones expresadas en términos de objetos e interfaces a un problema determinado. Para simplificar el desarrollo y mantenimiento del sistema se emplearán los patrones de diseño Modelo-Vista-Controlador, Front Controller, Intercepting Filter, View Helper, Active Record, Query Object entre otros, contenidos dentro de Symfony. 22

32 2.3 Definición de Términos Básicos Automatización: Se refiere a la ejecución automática de tareas industriales, administrativas o científicas haciendo más rápido y efectivo el trabajo ayudando de este modo al ser humano. Framework: Es una estructura conceptual y tecnológica de soporte definido, normalmente con artefactos o módulos definidos siendo utilizados como base para desarrollar otro proyecto de software mas fácil y organizadamente. Típicamente incluye librerías y un lenguaje interpretado. Gestión de Contenido: Servicio que consiste en contratar a una empresa para mantener actualizado a un sitio web o en su defecto, cargar el contenido a uno. Hospedaje de Páginas Web: Consiste en proporcionar un espacio para cargar archivos con extensiones legibles para un navegador, generalmente tanto el espacio proporcionado como la duración del contrato por este, son limitados. HTML: Significa HyperText Markup Language, que en español se traduce a lenguaje de marcas de hipertexto. Los documentos HTML son ficheros de texto plano que usan la extensión.htm o.html. MySQL: Es un sistema de gestión de bases de datos relacional. NetBeans: Es un entorno de desarrollo integrado libre, hecho principalmente para el lenguaje de programación Java aunque también soporta otros lenguajes. Existe además un número importante de módulos para extenderlo. NetBeans IDE es un producto libre y gratuito sin restricciones de uso. NetBeans permite crear aplicaciones Web con PHP 5, un potente debugger integrado y además viene con soporte para Symfony un gran framework MVC escrito en php. Mapeo Objeto-Relacional (Object-Relational-Mapping ORM): Es una técnica de programación para convertir datos entre el sistema de tipos utilizado en un lenguaje de programación orientado a objetos y el utilizado en una base de datos relacional, utilizando un motor de persistencia. Esto crea una base de datos orientada a objetos virtual, sobre la base de datos relacional. Esto posibilita el uso 23

33 de las características propias de la orientación a objetos (básicamente herencia y polimorfismo). Patrón de Diseño: Se considera un patrón de diseño a una solución a un problema en contexto que tiende a repetirse pero esta puede o no ser aplicada de la misma manera las veces que sea necesaria. Patrón de Diseño Decorador (Decorator): Permite no tener que crear sucesivas clases que hereden de la primera incorporando la nueva funcionalidad, sino que otras la implementan y se asocian a la primera. Es decir, responde a la necesidad de añadir dinámicamente funcionalidad a un Objeto. Patrón de Diseño Fabrica (Factory Method): Consiste en utilizar una clase constructora abstracta con unos cuantos métodos definidos y otro(s) abstracto(s): el dedicado a la construcción de objetos de un subtipo de un tipo determinado Patrón de Diseño Iterador (Iterator): Es una interfaz que declara los métodos necesarios para acceder secuencialmente a un grupo de objetos de una colección. Patrón de Diseño Instancia Única (Singleton): Está diseñado para restringir la creación de objetos pertenecientes a una clase o el valor de un tipo a un único objeto. Su intención consiste en garantizar que una clase sólo tenga una instancia y proporcionar un punto de acceso global a ella. PHP: Acrónimo de "PHP: Hypertext Preprocessor", es un lenguaje interpretado usado para la creación de aplicaciones que corren del lado del servidor. PhpMyAdmin: Es una herramienta escrita en PHP con la intención de manejar la administración de MySQL a través de páginas web, utilizando Internet. Soporte Técnico Web: Servicio contratado generalmente por horas-hombre para asistir a un individuo o empresa en el manejo de un sitio web y/o en servicios asociados a éste, pudiendo prestarse de manera presencial o remota. Ticket de Soporte: Instrumento a través del cual el cliente participa a la empresa inquietudes y/o problemas para recibir la asistencia correspondiente que tiene 24

34 como características principales, un numero único de rastreo, un nivel de prioridad y una categoría. TWIG: Es un motor de plantillas para PHP el cual compila las plantillas para obtener un código PHP optimizado, evalúa las plantillas antes de mostrarlas para evitar código no confiable y permite crear etiquetas propias para facilitar el uso al usuario. YAML: Acrónimo de "YAML Ain't Markup Language es un formato de serialización de datos legibles por humanos su propósito está centrado en los datos más que en el marcado de documentos. 25

35 CAPÍTULO III MARCO METODOLÓGICO 3.1 Tipo de la Investigación Esta investigación se clasifica como factible, ya que el objetivo principal es desarrollar un producto. Según Arias, Fidias (2006), un proyecto factible es una Propuesta de acción para resolver un problema práctico o satisfacer una necesidad. Es indispensable que dicha propuesta se acompañe de la demostración de su factibilidad o posibilidad de realización. 3.2 Diseño de la Investigación Arias, Fidias (2006) define el diseño de investigación como La estrategia que adopta el investigador para responder al problema planteado.. En este caso el diseño de esta investigación, según Hernández (2006), es No Experimental, ya que se realiza sin manipular deliberadamente variables. Es decir, es una investigación donde no hacemos variar intencionalmente las variables independientes. Lo que hacemos en la investigación no experimental es observar fenómenos tal y como se dan en su contexto natural, para después analizarlos ; para esto, se observaran los procesos ya existentes en la empresa y posteriormente se realizara un modelo que permita explicar la realidad de los procesos en estudio, en el que se determinan los actores y las diferentes interacciones de ellos con dichos procesos. 3.3 Nivel de la Investigación Según Arias, Fidias (2006) el nivel de investigación se refiere al Grado de profundidad con que se aborda un objeto o fenómeno. Aquí se indicará si se trata de una investigación exploratoria, descriptiva o explicativa.. En este caso, el nivel de la investigación es descriptiva, y según Arias, Fidias (1999), Los estudios descriptivos miden de forma independiente las variables, y aun cuando no se formulen hipótesis,

36 las primeras aparecerán enunciadas en los objetivos de investigación. ; teniendo en cuenta los procesos actuales del departamento de soporte, se establece así la representación de la necesidad y mejora de los procesos. 3.4 Población y muestra De acuerdo con el criterio Hernández (2006), la población es: el conjunto de todos los casos que concuerdan con una serie de especificaciones. (p. 238). En relación a lo expuesto este conjunto de elementos pueden ser personas, casos, objetos, instituciones y otros, se seleccionan de acuerdo a la naturaleza del problema y los objetivos de la investigación. Para esta investigación la población está constituida por los procesos de la empresa icad Diseño Inteligente, C.A., dado que son los procesos los que no están automatizados y se busca optimizar, además nos proporcionan los requisitos del sistema. Una vez definido el universo de estudio de manera precisa se procedió a seleccionar la muestra, que según Balestrini (2002): es una parte representativa de una población, cuyas características deben reproducirse en ella lo más exactamente posible (p. 142). En lo que se refiere a la muestra para el desarrollo de esta investigación se encontró representada por los procesos que corresponden al departamento de soporte, puesto que es finita y manejable. Hurtado (2007) opina que si: la población, además de ser conocida es accesible, es decir, es posible ubicar a todos los miembros. No vale la pena hacer un muestreo para poblaciones de menos de 100 integrantes, (p. 140). 3.5 Técnicas e Instrumentos de recolección de datos Arias, Fidias (1999) expresa que, las técnicas de recolección de datos son las distintas maneras en que el investigador puede recolectar la información que se usará en su proyecto, mientras que los instrumentos de recolección de datos son las herramientas mediante las cuales el investigador recoge diversos datos para tabular la 27

37 información y luego compararla con los resultados obtenidos de la investigación realizada. En este caso, la técnica de recolección de datos utilizada en la elaboración de este proyecto consta es la observación, con las cuales se obtienen datos de manera informal de las necesidades y requisitos solicitados por los usuarios. 3.6 Análisis de los datos Luego de haber obtenido los datos mediante la observación, se eligieron los procesos más utilizados en el departamento de soporte, los cuales son: almacenar la información relativa a los servicios contratados por los clientes, la asignación de dominios al servidor, creación de cuentas FTP con su respectivo usuario, creación de bases de datos con su respectivo servidor y usuario, hacer llegar al cliente los datos asociados con el dominio y la cuenta en el servidor, responder a inquietudes por parte de los clientes y por último, solucionar problemas relativos al servidor y todos los servicios asociados a él; se tomaron estos procesos como requerimientos para el sistema de información de soporte a partir de patrones de diseño utilizando Symfony en la empresa icad Diseño Inteligente, C.A 3.7 Fases de la investigación La descripción del desarrollo de un sistema de información de soporte a partir de patrones de diseño utilizando Symfony en icad Diseño Inteligente, C.A se llevó a cabo utilizando la metodología de desarrollo ágil SCRUM y diagramas UML. Las fases en la que está dividido el proyecto se contemplan a continuación: FASE I: Planificación. En esta fase: 1. Se diagnosticaron los procesos más utilizados en el departamento de soporte de icad Diseño Inteligente, C.A. 2. Se determinaron los requerimientos del sistema. 28

38 FASE II: Diseño. En esta fase: 1. Se modelaron los procesos más utilizados en el departamento de soporte de icad Diseño Inteligente, C.A. 2. Se diseñó la arquitectura del sistema que permite implementar los requerimientos definidos y los siguientes diagramas UML: Diagrama de Clases Diagrama de Casos de Uso Casos de Uso Narrativos Interfaces FASE III: Desarrollo. En esta fase se desarrolló el sistema. FASE IV: Cierre. En esta fase: 1. Se evaluó la funcionalidad de los módulos tanto individualmente como en conjunto para detectar posibles fallas. 2. Se documentó el sistema. 29

39 CAPÍTULO IV RESULTADOS En este capítulo se exponen los resultados obtenidos en cada fase de la metodología SCRUM. Se utilizaron herramientas y diagramas para apoyar la metodología y se desarrolló el sistema en base a los procesos más destacados del departamento de soporte de la empresa icad Diseño Inteligente, C.A Fase I: Planificación Durante esta fase se realizó una investigación de los procesos más destacados que forman parte del funcionamiento del departamento de soporte de la empresa icad Diseño Inteligente, C.A. para conocer el sistema actual, los procesos y las necesidades por parte del cliente y de los empleados del departamento de soporte Fase II: Diseño En esta fase, en base a los procesos obtenidos en la fase anterior, se modelaron las entidades representadas por un diagrama de clases, partiendo de la interacción de los diferentes tipos de personal con los procesos se realizó un diagrama de casos de uso para cada los involucrados con el sistema (administrador, analista y cliente), se construyeron varios diagramas de caso de uso narrativos para los procesos más importantes del sistema (Gestión de Tickets y Gestión de Contratos), un diagrama del modelo relacional e interfaces adecuadas a cada tipo de personal involucrado. 30

40 4.2.1 Diagrama de Clases Figura 1 Diagrama de clases. Fuente: Victoria Noguera (2012) Diagrama de Casos de Uso Los modelos casos de uso tienen como función mostrar las diferentes elecciones que tienen los actores (Administrador, analista y cliente) dentro del sistema. Seguidamente se muestran algunos de los casos de uso del sistema. 31

41 Figura 2 Diagrama de caso de uso. Fuente: Victoria Noguera (2012) 32

42 4.2.3 Casos de uso narrativos: Cuadro 1. Caso de uso narrativo Crear Contratos. Caso de Uso Crear Contratos ID_REF Elaborado por Victoria Noguera SAU-01 Fecha Elaboración Objetivo Asociar a los clientes los servicios contratados con la empresa Entradas Servicios y clientes en el sistema. Precondiciones Servicios y clientes existentes en base de datos. Salidas Contrato Creado. Post-condición éxito Contrato Creado. Post-condición fallo Se despliega un mensaje de error Mens-02 si el contrato ya se encuentra asociado con el cliente. Rol Responsable Super Administrador Otros Actores Sistema 33

43 Actor / Secuencia normal Super Administrador Super Administrador Super Administrador Super Administrador 1. Ingresa al módulo Administración o al módulo servicios 2. Hace clic en Contratos 3. Selecciona el servicio y el cliente a asociar. 4. Hace clic en Crear Sistema 5. Verifica la inexistencia de la asociación Si existe la asociación Servicio-Cliente: Se despliega Mens-01 Paso 6 Si no existe la asociación Servicio-Cliente: Se despliega Mens-02 Paso 6 Sistema 6. Fin. Mens-01 Contrato Registrado con Éxito. Mens-02 Error: El contrato ya está registrada, por favor intente de nuevo. Fuente: Victoria Noguera (2012) 34

44 Cuadro 2. Caso de uso narrativo Crear Ticket. Caso de Uso Crear Ticket ID_REF Elaborado por Victoria Noguera SAU-02 Fecha Elaboración Objetivo Crear un ticket Entradas Información proporcionada por el cliente. Precondiciones No Aplica Salidas Ticket creado. Post-condición éxito Ticket creado. Post-condición fallo Se despliega un mensaje de error Mens-03 si no se completan los campos obligatorios. Rol Responsable Cliente Otros Actores Sistema 35

45 Actor / Secuencia normal Cliente 1. Ingresa al módulo tickets. Cliente 2. Hace clic en Crear Nuevo Ticket Cliente 3. Selecciona la categoría a la que pertenece el ticket Cliente 4. Selecciona la prioridad del ticket Cliente 5. Ingresa Información sobre el requerimiento Cliente 6. Hace clic en Crear Sistema 7. Si se registró el ticket en base de datos: Se despliega Mens-04 Paso 8 Si no se registró el ticket en base de datos: Se despliega Mens-03 Paso 8 Sistema 8. Fin. Mens-03 Error: Por favor complete todos los campos e intente nuevamente. Mens-04 Ticket Creado con Éxito. Fuente: Victoria Noguera (2012) 36

46 Cuadro 3. Caso de uso narrativo Responder Ticket. Caso de Uso Responder Ticket ID_REF Elaborado por Victoria Noguera SAU-03 Fecha Elaboración Objetivo Se añade una respuesta a un ticket Entradas Información proporcionada por el cliente o el analista. Precondiciones Ticket abierto. Salidas Respuesta enviada. Post-condición éxito Respuesta enviada. Post-condición fallo Se despliega un mensaje de error Mens-03 si no se completan los campos obligatorios. Rol Responsable Cliente, Analista Otros Actores Sistema Actor / Secuencia normal Cliente/Analista 1. Ingresa al módulo tickets. Cliente/Analista 2. Hace clic en el número de ticket al cual se desea responder. 37

47 Cliente/Analista 3. Ingresa respuesta Cliente/Analista 4. Hace clic en Enviar Sistema 5. Si se registró la respuesta en base de datos: Se despliega Mens-05 Paso 6 Si no se registró la respuesta en base de datos: Se despliega Mens-03 Paso 6 Sistema 6. Fin. Mens-03 Error: Por favor complete todos los campos e intente nuevamente. Mens-05 Respuesta enviada con éxito. Fuente: Victoria Noguera (2012) Cuadro 4. Caso de uso narrativo Cerrar Ticket. Caso de Uso Cerrar Ticket ID_REF Elaborado por Victoria Noguera SAU-04 Fecha Elaboración Objetivo Se cierra un ticket abierto Entradas N/A Precondiciones Ticket abierto. Salidas Ticket cerrado. 38

48 Post-condición éxito Ticket cerrado. Post-condición fallo N/A Rol Responsable Cliente, Super Admininistrador Otros Actores Sistema Actor / Secuencia normal Cliente/Super Admininistrador Cliente/Super Admininistrador 1. Ingresa al módulo tickets. 2. Hace clic en el número de ticket el cual se desea cerrar. Cliente/Super Admininistrador 3. Hace clic en Cerrar Sistema 4. Si se registró el cierre de ticket en base de datos: Se despliega Mens-06 Paso 5 Si no se registró el cierre de ticket en base de datos: Se despliega Mens-07 Paso 5 Sistema 5. Fin. Mens-06 Ticket cerrado con éxito. Mens-07 Error: El ticket ya se encuentra cerrado. Fuente: Victoria Noguera (2012) 39

49 4.2.4 Diagrama del Modelo Relacional: Figura 3 Diagrama del Modelo Relacional. Fuente: Victoria Noguera (2012) 40

50 4.2.5 Diseño de Interfaces: Se utilizaron varios diseños para las interfaces apoyados en el diseño de web modular, el cual facilitó el desarrollo y visualización del sistema. Existen variaciones respecto a los diseños, algunos módulos necesitaban la implementación de una barra lateral para acceder a los maestros asociados a él o en su defecto a otros módulos relacionados, otros tienen incorporado un campo de búsqueda. Figura 4 Interfaz Principal de Módulos Tipo 1 Fuente: Victoria Noguera (2012) Figura 5 Interfaz Principal de Módulos Tipo 2 Fuente: Victoria Noguera (2012) 41

51 Figura 6 Interfaz Principal de Módulo de Administración Fuente: Victoria Noguera (2012) Figura 7 Vista Genérica de Detalle en modulo. Fuente: Victoria Noguera (2012) 42

52 Figura 8 Vista Genérica de Creación en modulo. Fuente: Victoria Noguera (2012) Figura 9 Vista Genérica de Editar en Modulo. Fuente: Victoria Noguera (2012) 43

53 4.3. Fase III: Desarrollo En esta fase se consolida toda la información recaudada por las fases anteriores, está aplicación fue realizada utilizando el framework Symfony versión que a su vez tiene integrado el manejador de plantillas Twig versión , el ORM Doctine entre otras librerías para el manejo de s y seguridad. Se configuro utilizando la herramienta XAMPP version 1.8.1, que a su vez está integrado por el servidor Apache versión 2.4.3, MySQL versión , phpmyadmin versión , PHP versión 5.4 entre otros componentes no utilizados en el desarrollo de la aplicación, fue necesario instalar la extensión intl requerida por Symfony. La estructura de archivos de Symfony está constituida de la siguiente manera: Figura 10 Estructura Carpetas en Symfony. Fuente: Victoria Noguera (2012) 44