UNIVERSIDAD TECNOLÓGICA DE QUERÉTARO

Transcripción

1 Portada Externa de la memoria Desarrollo de Sistema Bug Tracker Ana Lilia Soto Torres 2011 UNIVERSIDAD TECNOLÓGICA DE QUERÉTARO Desarrollo de Sistema Bug Tracker Memoria Que como parte de los requisitos para obtener el título de Ingeniería en Tecnologías de la Información y Comunicación Ing. Manuel Uribe Presenta Ana Lilia Soto Torres Ing. Luis Rodríguez Santiago de Querétaro, Junio de 2011

2 2

3 Resumen El presente documento redacta el proceso realizado para la elaboración de un sistema de incidencias dentro de una intranet en la empresa Siberline México S.A. de C.V. Un sistema de incidencias o Bug tracking se utiliza para identificar y canalizar inconformidades por parte del cliente, las cuales deben ser tratadas a la brevedad, cuando estas no reciben la atención requerida, se convierten en una no conformidad y estas se traducen como perdidas y mala reputación para la empresa. El proyecto involucra realizar un sistema web al que se puedan conectar los usuarios por medio de una red local (intranet) al que solo tengan permiso de ingresar usuarios autorizados y que a la vez mantenga informados vía correo electrónico a los mismos sobre el levantamiento, estado y cierre de incidencias. Este proyecto comienza desde el análisis de requisitos de la empresa, análisis, diseño, programación, pruebas, capacitación de personal, implementación y puesta en marcha de la aplicación. Los beneficios obtenidos de este proyecto es la agilización y mejora continua de procesos que benefician al cliente y al mismo tiempo esto se refleja como rentabilidad y ganancias para la empresa. (Palabras clave: bug tracking, incidencias, seguimiento de errores) 3

4 Abstract The current document makes out the process to develop a software incidence system in a local network in the company Siberline México. An incidence system or bug tracking system is used to recognize and canalize customer unconformities, these must be treated as soon as possible, because when these don t get the attention needed these become in nonconformity, this action is interpret like financial losses and bad reputation for the company. The project involves realize a web system where the users can connect through a local network (intranet) to which just authorized users can sign in at the same time keep informed via to the users about the creation, status and incidence close. This project begins from the company requirement analysis, design, development, test, staff training and the system implementation. The acquire benefits are the process speed-up and the continuous improvement to favor the customer while this are profitability for the company. 4

5 Índice Resumen... 3 Abstract... 4 Índice... 5 I. Introducción... 7 II. Antecedentes... 9 III. Justificación IV. Objetivos V. Alcances VI. Fundamentación Teórica VII. Plan de Actividades VIII.Recursos Materiales y Humanos IX. Desarrollo del Proyecto Análisis de Requisitos Entrevistas Reunión de Staff Búsqueda de Aplicaciones BugTracking Instalación de Aplicaciones Análisis y Diseño Desarrollo del Sistema Validaciones Permisos Creación de una Incidencia Asignaciones

6 9.5.5 Actualización de una Incidencia Integración de Correos Electrónicos Listado de Casos/Reporte FAQ interno Ayuda Adecuación a Imagen Institucional Pruebas por Módulo Corrección y Adecuaciones Finales Elaboración de Manual de Usuario Presentación y Autorización Implementación sobre el Servidor Configuraciones Bases de Datos Capacitación de Personal Entrega/Puesta en Marcha Seguimiento X. Resultados Obtenidos XI. Análisis de Riesgos XII. Conclusiones XIII. Recomendaciones XIV.Referencias Bibliográficas

7 I. Introducción El siguiente documento tiene la intención de detallar y especificar el proceso involucrado en el análisis y desarrollo de un sistema Bug Tracker. Un sistema o aplicación de bug tracking en un ambiente empresarial nace de la necesidad de las organizaciones al visualizar que algunos procesos o actividades necesitan ser mejorados para poder seguir ofreciendo a sus clientes atención, productos o servicios de alta calidad. Para poder lograr este objetivo es necesario localizar aquellas actividades catalogadas como incidencias y resolverlas a la brevedad por medio de la identificación, canalización del personal y seguimiento de dicha tarea. Una incidencia es considerada como cualquier evento que no forma parte de la operación estándar de un servicio, y que causa o puede causar, una interrupción o una reducción en la calidad del mismo. Las ventajas que se consiguen al implementar un sistema bug tracking para tratar estas incidencias son variadas: a) Mejora de productividad de los usuarios b) Control de procesos c) Canalización de recursos d) Monitoreo de servicios 7

8 e) Mejora de tiempos de respuesta f) Cumplimiento de estándares de calidad g) Mejora de la satisfacción general de los clientes 8

9 II. Antecedentes En la empresa Siberline México S.A. de C.V. ha presentado la necesidad de cubrir y darle un seguimiento a aquellas actividades detectadas como incidencias o no conformidades por parte de sus clientes. Siberline México tiene una cartera de clientes extensa a los cuáles la empresa brinda sus servicios y productos, cuando un cliente no queda conforme con el servicio que ha recibido o recibe productos en mal estado o con defectos el cliente se encarga de levantar una incidencia con el personal a cargo del área de ventas de Siberline México. A su vez el departamento de ventas informa a las áreas involucradas por medio de llamadas telefónicas o correo electrónico, una vez canalizada esta incidencia, el departamento asignado se hace responsable de dicha tarea y ahí termina el proceso. Cuando el cliente vuelve a llamar para verificar el seguimiento de su incidencia, el personal de ventas tiene que volver a canalizar al personal asignado para poder reportar al cliente el resultado. Cuando estas incidencias no son tratadas a tiempo provocan inconformidades o disgustos por parte del cliente, causando mala reputación de la empresa o del producto. Actualmente el área de ventas se encarga de recibir aproximadamente 15 incidencias por semana. 9

10 III. Justificación Con la elaboración un sistema Bug Tracking el personal realizará las acciones correspondientes para resolver no conformidades, mejorando con esto tiempos de respuesta en los procesos de gestión involucrados a través de una herramienta que controle el flujo de las incidencias existentes. Esto trae beneficios para la empresa debido a que al momento de canalizar estas actividades, Siberline México puede identificar áreas de oportunidad, es decir, identificar puntos débiles en el servicio al cliente y mejorarlos, controlar y gestionar operaciones, optimizar o mejorar procesos y lo más importante, mantener a sus clientes y la satisfacción de los mismos. 10

11 IV. Objetivos Objetivo general Elaborar en un ambiente web un sistema de bug tracking, para el levantamiento de incidencias a nivel local (intranet). Objetivos Específicos a) Análisis de requisitos de la empresa b) Elaboración de un sistema Bug Tracking para la resolución de incidencias, dicho sistema debe cumplir con las siguientes características: - Validación y autenticación al sistema con una cuenta de correo - Asignación de actividades por niveles de permisos de usuario - Asignación de usuarios por incidencia - Creación, modificación o cierre de incidencias de acuerdo permisos de usuarios - Capacidad para adjuntar archivos en una incidencia - Integración de correos electrónicos para la notificación de dichas tareas a usuarios, asegurando así que el reporte de incidencias se cumpla. Estas notificaciones serán lanzadas cuando una incidencia es: creada, modificada, cerrada, reasignada. 11

12 c) Elaboración de manual de usuario y documentación del sistema de acuerdo a la ingeniería de software d) Capacitación de personal e) Implementación/Instalación y configuración local del sistema 12

13 V. Alcances La duración del proyecto será de 3 meses, comenzando desde el día 10 de Enero de 2011 en las instalaciones de la empresa Siberline México S.A de C.V., el tiempo dedicado a cada alcance es especificado en posteriores capítulos. El proyecto está conformado por las siguientes etapas: Análisis de requisitos y planeación Identificación de oportunidades de mejora y resultados esperados, así como la identificación de las operaciones y funciones involucradas en el proceso. De acuerdo a este previo análisis de requisitos se elaborará una arquitectura lógica del sistema. Programación De acuerdo a las actividades anteriores se procederá a la elaboración del sistema, en cuanto a cuestiones de captura y diseño se refiere. Elaboración de documentación y manuales de usuario Se pretende documentar la elaboración del proyecto de acuerdo a la ingeniería de software, es decir, realizar la documentación necesaria sobre la arquitectura de la aplicación (diagramas de casos de uso, de clases, de flujo, de control, etc.). También se elaborará un manual para el uso del sistema por parte de los usuarios. 13

14 Pruebas e implementación sobre el servidor Se realizarán las configuraciones concernientes para la instalación del sistema en los servidores de Siberline, así como las configuraciones del servidor SMTP para la trasferencia de correos. Capacitación de usuarios y puesta en marcha Se pretende realizar una capacitación al personal de las áreas involucradas en el proceso, así como sus respectivos roles y permisos dentro del sistema. 14

15 VI. Justificación teórica Para entender el problema analizado en el presente documento y la solución propuesta, es necesario revisar los siguientes contextos. La bibliografía consultada se ubica como elemento final de éste documento. 6.1 Bug Tracking System Un sistema de seguimiento de errores también conocido como bug tracking system son aplicaciones diseñadas para ayudar a asegurar la calidad de software y asistir a los programadores y otras personas involucradas en el desarrollo y uso de sistemas informáticos en el seguimiento de los defectos de software. El término usado en inglés es Bug Tracking System, y frecuentemente se usa el acrónimo BTS. Puede considerarse como una especie de sistema de seguimiento de incidentes. Son usados intensivamente por cualquier empresa o institución que realice desarrollo de software. Si bien muchos sistemas de seguimiento de errores de software libre permiten que los usuarios directamente den de alta la incidencia detectada, en muchas empresas de desarrollo de software se usan de manera estrictamente interna. Muchos de los sistemas de seguimiento de errores de software se integran frecuentemente con otras herramientas, como pueden ser correo electrónico, control de versiones, y otras herramientas de gestión administrativa. 15

16 6.2 Ambiente/Aplicaciones Web Las aplicaciones desarrolladas para un ambiente web son populares debido a lo práctico del navegador web como cliente ligero, a la independencia del sistema operativo, así como a la facilidad para actualizar y mantener aplicaciones web sin distribuir e instalar software a miles de usuarios potenciales. Es importante mencionar que una página web puede contener elementos que permiten una comunicación activa entre el usuario y la información. Esto permite que el usuario acceda a los datos de modo interactivo, gracias a que la página responderá a cada una de sus acciones, como por ejemplo rellenar y enviar formularios, participar en juegos diversos y acceder a gestores de base de datos de todo tipo. Una ventaja significativa es que las aplicaciones web deberían funcionar igual independientemente de la versión del sistema operativo instalado en el cliente. En vez de crear clientes para Windows, Mac OS X, GNU/Linux y otros sistemas operativos, la aplicación web se escribe una vez y se ejecuta igual en todas partes. Aunque existen muchas variaciones posibles, una aplicación web está normalmente estructurada como una aplicación de tres-capas. En su forma más común, el navegador web ofrece la primera capa y un motor capaz de usar alguna tecnología web dinámica (por ejemplo: PHP, Java Servlets 16

17 o ASP, ASP.NET, CGI, ColdFusion, embperl, Python o Ruby on Rails) constituye la capa de enmedio. Por último, una base de datos constituye la tercera y última capa. El navegador web manda peticiones a la capa de del interior que ofrece servicios valiéndose de consultas y actualizaciones a la base de datos y a su vez proporciona una interfaz de usuario. 6.3 Incidencias en una organización En términos empresariales, la organización es, en esencia, un proceso de combinación de los medios e instrumentos: humanos, materiales, técnicos, informativos, lógicos y tecnológicos con vistas a lograr un objetivo: satisfacer una necesidad o brindar solución a un problema social. Por tanto, la organización es un modelo del sistema de dirección construido sobre la base de los principios y técnicas del enfoque sistémico, cuyo campo de trabajo dentro de los sistemas socioeconómicos es muy amplio y debe estar regulado por los procedimientos correspondientes. Unido a lo anterior, debe señalarse que el desarrollo de la actividad comercial, constituye un reto para todas las entidades en las cuales la calidad de los productos y la atención sistemática al cliente tiene un papel preponderante, atendiendo a lo cual el registro y análisis de todas las situaciones ocurridas que afectan la operación comercial (incidencias), reviste 17

18 una gran importancia para alcanzar la excelencia a partir de dos aspectos fundamentales: a) Permiten determinar los elementos que revelan deficiencias desde el punto de vista organizacional. b) Facilitan la detección de problemas, sobre los cuales, en múltiples ocasiones, es posible accionar durante el proceso, con lo cual se evitan reclamaciones, que además de su impacto económico, tienen asociada una pérdida de imagen, mucho más grave en el largo plazo. En términos prácticos, el empleo de un Sistema de Incidencias que abarque todas las actividades beneficia a toda la empresa, debido a que: a) Permite determinar las fallas operacionales internas de la empresa y sus causas, para su posterior erradicación y con ello incrementar la eficiencia. b) Contribuye a perfeccionar la elaboración de contratos, al negociar e incluir en éstos, de manera conveniente, aquellos aspectos que han sido causas de fallas en el pasado. c) Facilita la elaboración del Plan de Negociación de la empresa con sus Proveedores, a partir de la caracterización de la aceptación de sus productos o servicios así como de la calidad de éstos a través del análisis de las reclamaciones y su impacto financiero en la empresa. 18

19 6.4 Intranet Las intranets son redes privadas que se han creado utilizando las normas y protocolos de Internet. Aportan la interfaz de exploración del World Wide Web (www) a la información y servicios almacenados en una red de área local (LAN) corporativa. Las intranets son atractivas por que disminuyen el costo de mantenimiento de una red interna y, al mismo tiempo, aumenta la productividad, ya que ofrece a los usuarios acceso más eficaz a la información y a los servicios que necesitan. Con el enorme crecimiento de Internet, un gran número de personas en las empresas usan Internet para comunicarse con el mundo exterior, para reunir información, y para hacer negocios. A la gente no le lleva mucho tiempo reconocer que los componentes que funcionan tan bien en Internet serían del mismo modo valioso en el interior de sus empresas y esa es la razón por la que las Intranets se están haciendo tan populares. La Intranet está basada en los estándares y protocolos abiertos desarrollados en Internet. Estos estándares abiertos soportan aplicaciones y servicios como correo electrónico ( ), trabajo en grupo (work group), servicio de directorio, seguridad, acceso a bases de datos, compartición de información y administración de sistema. La Intranet se beneficia del esfuerzo de la industria entera y no de un solo fabricante. 19

20 Las aplicaciones que permiten a los distintos departamentos empresariales enviar información, y a los empleados rellenar formularios de la empresa y utilizar la información corporativa financiera, son muy populares. Las Intranets también se pueden utilizar para permitir a las empresas llevar a cabo transacciones de negocio a negocio como: hacer pedidos, enviar facturas, y efectuar pagos. Para mayor seguridad, estas transacciones de Intranet a Intranet no necesitan nunca salir a Internet, pero pueden viajar por líneas alquiladas privadas. Son un sistema poderoso para permitir a una compañía hacer negocios en línea, por ejemplo, permitir que alguien en Internet pida productos. Cuál es la diferencia entre Internet e Intranet? Básicamente, la localización de la Información y quién accede a ella. Internet es público, global, abierto a cualquiera que tenga una conexión. Las Intranet están restringidas a aquellas personas que están conectadas a la red privada de la empresa. Además de eso, ambas funcionan esencialmente de la misma manera, con la misma tecnología TCP/IP para regular el tráfico de datos. Del mismo modo, desde el punto de vista de las aplicaciones ( , newsgroups y transferencia de archivos FTP, además del Web), no existe ninguna diferencia entre Internet e Intranet. 20

21 VII. Plan de actividades En la imagen de abajo se muestra el plan de actividades contemplado para la elaboración del proyecto. Imagen 7.1 Planeación de tareas contempladas para el proyecto 21

22 Imagen Diagrama de Gantt para la planeación de acuerdo al proyecto Se contempla comenzar el día lunes 10 de Enero en un horario de lunes a viernes de 9:00 a 18:30 horas, con una fecha aproximada de entrega del martes 12 de abril del presente año. Para cada actividad está contemplado un día de holgura para efectos de cualquier modificación que se necesaria. 22

23 VIII. Recursos humanos y materiales Para el desarrollo del proyecto se utilizaron los siguientes recursos humanos y materiales, necesarios para el sustento del proyecto. Humanos a) Asesores de empresa y de estadía: se debe mantener un contacto con ambos asesores para recibir a través de ellos información que se traducirá como beneficios para el proyecto. Materiales a) Materiales bibliográficos / conexión a internet b) Espacio físico para el desarrollo del proyecto c) Un equipo de cómputo Para el desarrollo y pruebas a) Entorno de desarrollo Eclipse para PHP b) Un servidor web vía TCP/IP c) Un servidor SMTP, POP para soporte y envío de correos d) MySQLDatabase Server e) PHP versión 5 o superior que cuente con las siguientes extensiones: f) Conexión a red local (intranet) 23

24 IX. Desarrollo del proyecto 9.1 Análisis de requisitos Para el análisis de requisitos se acordó realizar una entrevista con el gerente general y también se solicitó realizar una reunión con el personal involucrado en el levantamiento de una incidencia. El motivo de estas reuniones con el personal es conocer desde la perspectiva del usuario todo el procedimiento, recepción, canalización y evaluación de una incidencia, así mismo este tipo de reuniones permite conocer más acerca de las perspectivas a futuro del usuario entrevistas. Se realizó una entrevista con el Ingeniero Luis Rodríguez gerente general de Siberline México para conocer el proceso, las áreas y el personal involucrados. De esta entrevista se pudo extraer el proceso principal, así como las funciones primordiales del sistema. También se realizó una entrevista al Ingeniero Alfredo Arévalo encargado del área de calidad de producción de Siberline México, su participación en el proyecto es de suma importancia puesto que él es usuario principal y el encargado de revisar y controlar todas las incidencias que arroje el sistema. 24

25 Los 2 formularios de levantamiento de cuestionarios que se obtuvieron son los siguientes: Imagen Formulario de cuestionario número 1. 25

26 Imagen Formulario de cuestionario número reunión de staff En una de las reuniones del staff de Siberline México se reunieron los jefes de área involucrados en el proceso (ventas, almacén, logística, departamento técnico, producción, calidad) los cuales abordaron el tema sobre las incidencias y el seguimiento estandarizado que estas tendrían, ellos hablaron sobre el proceso actual y sobre el proceso que les gustaría 26

27 que fuera, establecieron también que tipo de inconformidades eran aquellas que se reportarían o se tendrían en cuenta, y además aportaron ideas para facilitar el manejo de dichas inconformidades. Realizado el análisis de requisitos, se obtuvo el proceso por el cual es tratado cualquier incidencia, el ámbito completo de sistema de incidencias y el diagrama de flujo se muestran a continuación: Imagen Ámbito del sistema de incidencias. 27

28 Imagen Ámbito del sistema de incidencias. 28

29 9.2 Búsqueda de aplicaciones bug tracking De acuerdo a los datos adquiridos, se procedió a buscar información sobre sistemas de bug tracking que existieran en el mercado o que contaran con licencias GNU (General Public LIcense) debido a que estos pueden ser modificados o utilizados, esto se hizo para facilitar y agilizar el desarrollo de dicha aplicación. Se realizó una búsqueda de la cual se obtuvieron los siguientes sistemas bugtracking: a) adefhelpdesk: Sistema open source desarrollado en ASP.NET, comúnmente utilizado para dar soporte help desk. b) BATTS: Sistema utilizado para ayudar en las tareas de help desk, elaborado bajo sistema Linux/Unix, el cual incluye modulo de integración de s. c) HelpDesk Issue Manager: desarrollado en PHP con PostgreSQL, permite crear y manejar tareas, no incluye modulo de envío de correo. d) Liberum HelpDesk: elaborado en ASP con VBScript y Access, permite la integración de correo electrónico, reportes y actualizaciones. e) Sinergia: escrito en.net con C# es utilizado comúnmente para help desk y tratamiento de problemas, incluye modulo de llamadas. De acuerdo al análisis realizado, y al idealizar que algunos de los requisitos que pidió el personal de Siberline México no cuenta con las 29

30 características de los anteriores sistemas, se concluyó que se realizaría un nuevo sistema de incidencias. Se decidió tomar como base uno de estos sistemas, ya que al ser GNU puede ser copiado, redistribuido, modificado e incluso vendido siempre y cuando el material se mantenga bajo los términos de esta misma licencia. Se decidió tomar uno de estos sistemas como base debido a que permitirá un tiempo de entrega más corto que el que se tenía contemplado. El sistema que se eligió es conocido como Eventum y fue elegido por tener características que se asemejaban a los requisitos que necesitaba Siberline México. Eventum es un sistema para la gestión de tareas y seguimiento de errores desarrollado por MySQL, el cual es utilizado comúnmente en los departamentos de soporte técnico para manejar solicitudes técnicas por parte de los usuarios, también es utilizado por empresas de desarrollo de software para reportar y organizar todo tipo de errores de código, posee características como creación de proyectos, creación de tareas, envío de correos electrónicos y administración de los mismos, se encuentra desarrollado en PHP, JavaScript y MySQL. 9.3 Instalación de aplicaciones Para la elaboración del proyecto y para trabajar en base con eventum, se contempló utilizar las siguientes herramientas con las que se trabajó durante 30

31 todo el trascurso del proyecto, y las cuales deberán ir correctamente configuradas en el servidor: a) PHP: este lenguaje de programación fue elegido debido a que puede ser montado en la mayoría de los sistemas operativos de cualquier servidor sin ningún costo alguno, además PHP permite manejar páginas dinámicas y transacciones con bases de datos sin tanta dificultad, facilitando las tareas de programación. b) JDK: debido a que se trabaja con JavaScript es necesario tener instalado el JDK de java, JavaScript es un lenguaje de programación que se eligió debido a que tiene la característica de permitir hacer sitios dinámicos, es decir, el contenido de la aplicación se genera a partir de lo que el usuario captura, además JavaScript tampoco tiene costo alguno. c) Smarty: la idea de utilizar Smarty se derivó del concepto de realizar un sistema que cumpliera con una arquitectura correcta para su desarrollo, es decir, que cumpliera con una lógica de negocio. Smarty es un motor de plantillas Open Source para PHP, el cual permite realizar aplicaciones web de calidad separando el código PHP de la presentación (HTML/CSS). d) Xampp: se decidió utilizar esta herramienta debido a que es una aplicación Open Source además de que permite integrar varios servicios 31

32 web necesarios para el desarrollo del proyecto (Apache, MySQL, PHP) facilitando la gestión de un servidor local. Para obtener el resultado esperado es necesario también definir la infraestructura tecnológica del cliente, es decir, la infraestructura con la que deben contar los usuarios finales. a) Hardware: en cuestiones de hardware del equipo no se necesitará ninguna especificación en particular. Contar con una conexión a internet que pertenezca a la intranet de Siberline México. b) Software: se necesita un explorador web de preferencia el más actual en su versión (Internet Explorer, Mozilla, Google Chrome, Safari, Netscape). En el caso de los usuarios que se encuentran en almacén y en la oficina de ventas de Culiacán, es necesario que estos se conecten a través de una VPN (Vitual Private Network), esto es debido a algunas cuestiones de telecomunicaciones temporales en la planta de Siberline México. 9.4 Análisis y diseño Como se mencionada anteriormente, uno de los propósitos de este proyecto es utilizar e implementar una lógica de negocio que separe los datos de una aplicación, la interfaz de usuario, y la lógica de control en tres componentes distintos, a esto se le conoce comúnmente como Modelo Vista Controlador (MVC). Estas son categorizadas dentro del sistema de la siguiente manera: 32

33 a) Modelo: corresponde a la representación específica de la información con la cual el sistema de incidencias será controlado, comúnmente conocido como sistema de gestión de base de datos, En el desarrollo del proyecto se utilizó como gestor PHPMyadmin, el cual es brindado por el servicio de Xampp. b) Vista: la vista representa el modelo en un formato adecuado para interactuar, es decir la interfaz de usuario. Las interfaces del sistema de incidencias utilizarán Smarty, este motor se encargará de gestionar los scripts web que se generen, a la vez de que los asociará a la parte de proceso del sistema. Es fácil identificar un template generado por Smarty debido a que estos terminan en extensión tpl.html. c) Controlador: el controlador es la parte del sistema que se encarga de responder eventos o acciones generadas por el usuario, también se encarga de invocar peticiones al segmento de Modelo y Vista. En el sistema de incidencias estas actividades son realizadas por los scripts en PHP y JavaScript, ellos se encargan de invocar y asociar tanto la base de datos como los templates al sistema. Las ventajas de utilizar una lógica de negocio son sencillas y claras, implementando un MVC el sistema será flexible y utilizará una estructuración de código completa permitiendo reutilizar componentes y al mismo tiempo realizar prototipos más rápidos. 33

34 Metodología de desarrollo de software La metodología que se decidió utilizar fue la de prototipos, las ventajas de utilizar estas metodologías en el desarrollo de software las aclara el autor Steven Mikes (1992): La necesidad de los prototipos está clara: debe existir una buena idea de cómo se verá el producto acabado antes de comprometer recursos de desarrollo. Los prototipos ayudan a eliminar falsos comienzos y proporcionan una metodología para refinar los productos acabados antes de que estos se construyan. Otra razón para los prototipos es puramente técnica: los programadores pueden chequear cómo aparecerán los componentes y lo bien que funcionarán, antes de comenzar el núcleo de aplicación. (pp. 95). Se utilizará esta metodología de prototipos con la finalidad de comunicar, discutir y definir las ideas entre las partes responsables. Para construir un sistema que siga esta metodología se pasó por el siguiente proceso en general: a) Se evaluó la petición del software y se determinó si el programa a desarrollar era un buen candidato para construir en base a prototipos. 34

35 Debido a que el usuario principal (área de calidad) interaccionaría con el prototipo en los últimos pasos, era esencial tomar en cuenta su participación en la evaluación y refinamiento de prototipos. b) Se creó un conjunto de especificaciones de diseño para el primer prototipo. Esta etapa corresponde a la planeación del sistema. c) Con toda la planeación realizada se procedió a elaborar la codificación, se realizaron pruebas y realizaron las modificaciones que se consideraron adecuadas. d) Ya que el prototipo del sistema de incidencias ha sido probado, se presenta al gerente general el cual condujo la prueba de la aplicación y sugirió modificaciones. Este paso es el núcleo del método de construcción por prototipos. Es aquí donde el usuario final puede examinar una representación implementada de los requerimientos del programa, sugerir modificaciones que harán al sistema cumplir mejor las necesidades reales. e) Una vez llegada a esta etapa los pasos c y d se repiten iterativamente hasta que todos los requerimientos estén formalizados o hasta que el prototipo del sistema inicial haya evolucionado hacia el verdadero y real sistema de incidencias. 35

36 De todo este análisis de requisitos se obtuvo como resultado los siguientes documentos: - Diagrama Entidad-relación de la BD - Diagrama de clases - Diagrama de casos de uso De estos documentos se muestran los principales diagramas a continuación. 36

37 Diagrama entidad relación de la Base de datos Imagen Diagrama entidad relación de la base de datos de incidencias. 37

38 Clases principales del sistema de incidencias Clase User. Imagen Clase User. 38

39 Clase Issue. Imagen Clase Issue. 39

40 Clase report. Imagen Clase Report.. Clase attachment. Imagen Clase Attachment. 40

41 Clase History. Imagen Clase History. Clase Project. Imagen Clase History 41

42 Diagramas de caso de uso Caso de uso crear incidencia. Imagen Diagrama de caso de uso crear incidencia. Caso de uso actualizar incidencia. Imagen Diagrama de caso de uso actualizar incidencia. 42

43 Caso de uso actualizar incidencia. Imagen Diagrama de caso de uso cerrar incidencia. 9.5 Desarrollo del sistema validaciones. Para ingresar a la aplicación es necesario autentificarse como parte del sistema, para lo que se creó un template para el formulario de ingreso, este formulario esta en código Smarty, a la vez existe un archivo de nombre login.php el cual se encarga de conectar al formulario con los métodos necesarios. Estos métodos se encuentran en un archivo php, en este script se métodos para consultar o ingresar datos a la base de datos. La siguiente imagen muestra el proceso por el que debe pasar una validación. 43

44 Metodos.php Login.php login.tpl.html Imagen Diagrama de Gantt para la planeación de acuerdo al proyecto. La imagen de abajo muestra como luce el formulario para ingresar a la aplicación, el ingreso es a través del correo electrónico de la empresa y el password al comenzar a utilizar el sistema es para todos por default Siberline. Imagen Formulario de ingreso al sistema de incidencias. 44

45 Las validaciones con las que cuenta este formulario son 3 diferentes, una es cuando la dirección del usuario y la contraseña no coinciden, la segunda es cuando no se ha introducido la contraseña y la tercera es cuando la dirección de correo tampoco se ha capturado. Estas validaciones son generadas por un archivo en JavaScript el cual se encarga de todas las validaciones del sistema. Las siguientes imágenes muestran estas validaciones de campos. Imagen Validación para el campo contraseña. Imagen Validación para el campo Dirección de . 45

46 9.5.2 permisos. Los usuarios que ingresen al sistema lo hacen por medio de roles, estos roles les asigna ciertos permisos dentro del sistema. El archivo users es el que se encarga de consultar la base de datos para verificar los permisos que estos tiene, esto es a través del ID del usuario y un ID del rol al que pertenece. Los usuarios que existen son 4: a) Administrador: el administrador es la persona encargada de soporte técnico o de sistemas. Esta persona se encarga de dar de alta usuarios, cambiar contraseñas, realizar modificaciones de integración de correo electrónico y todo lo referente a la administración de usuarios. Este también tiene funciones para manipular. En pocas palabras es el usuario con más alto rango del sistema. b) Usuario Supervisor: este rol es el más alto de todos los roles en cuestiones de manipulación de incidencias. El permiso principal de este usuario es poder visualizar todas las incidencias que han sido creadas inclusive aquellas ya han sido cerradas, también puede visualizar el transcurso y el historial de dicha incidencia. Este rol también posee la característica de que cada vez que se crea una incidencia es notificado vía correo electrónico sin importar a quién se la hayan asignado la incidencia, esto es para estar notificado de las tareas actuales y en caso 46

47 Administrador Usuario Supervisor Usuario de Ventas UsuarioTécnico de ser necesario interferir sin que se le haya sido asignada dicha incidencia. c) Usuario Ventas: este rol es el encargado de levantar incidencias y cerrarlas, cuando se le sean asignadas puede actualizarlas y volverlas a reasignar, este rol recibe una notificación cuando cualquier otro usuario asignado modifica la incidencia. d) Usuario estándar: este rol es el que goza de menos privilegios en el sistema ya que no puede crear ni cerrar incidencias, su único rol es el de contestar aquellas incidencias que se le hayan sido asignadas, este rol también recibe una notificación cuando se le ha sido asignada y cuando esta se es actualizada por cualquier otro usuario. La siguiente imagen muestra en breve los permisos y roles que existen. Incidencias: Crear Cerrar Actualizar Visualizar todas las incidencias (reporte) Administración: Sistema Usuarios FAQ's Incidencias Crear Cerrar Actualizar Visualizar sus asignaciones Visualizar todas las incidencias (reporte) Administración FAQ's Incidencias Crear Cerrar Actualizar Visualizar sus asignaciones Incidencias Actualizar Visualizar sus asignaciones Imagen Roles y permisos de usuarios dentro del sistema. 47

48 Cada rol visualiza un menú principal distinto de la demás, esto es debido a los permisos que posee, las imágenes de abajo son una muestra de ello. Administrador Imagen Menú principal para el rol de Administrador. Usuario Supervisor Imagen Menú principal para el rol de usuario Supervisor. Usuario Ventas Usuario Técnico Imagen Menú principal para el rol de Usuario de Ventas. Imagen Menú principal para el rol de Usuario Estándar. 48

49 9.5.3 creación de una incidencia. Para la creación de una incidencia existen diferentes tipos de datos de entrada, estos datos siempre serán introducidos por el personal de ventas de Siberline México o en su excepción por aquellos usuarios que pertenecen al rol de supervisor. Estos datos son los siguientes: a) Prioridad: la prioridad hace referencia a la urgencia de una incidencia por ser resuelta, existen tres tipos de prioridades alta, media y baja. Este dato es para organizar mejor la incidencia y atender aquellas que merecen mayor prioridad o urgencia primero. b) Asignación: este datos es para asignar un usuario a la incidencia, es decir, este es el medio de canalización por el cual el usuario de ventas asignará un responsable. Este campo desplegará todos los usuarios existentes ya que todos pueden recibir incidencias. c) Fecha de resolución esperada: este dato hace referencia a la fecha en la que se espera que esa incidencia esté resuelta, es decir, que tenga una solución definitiva. El sistema por automático ya genera esta fecha dando por default una semana extra para resolver la incidencia. d) Cliente: el campo de cliente deberá de ser capturado por el personal de ventas con el nombre y/o número de cliente al que hace referencia dicha incidencia. e) Resumen/Asunto: este campo es una breve descripción de la incidencia 49

50 f) Descripción: este campo es una breve descripción de los datos que conforman la incidencia, aquí el personal de ventas debe de explicar los datos necesarios para reportar, levantar y canalizar la incidencia. El sistema automáticamente genera la fecha, la hora y el usuario actual, esto con la finalidad de que cuando se envíe la incidencia g) Agregar archivos: en caso de que sea necesario o de que el personal de ventas cuente con este dato el usuario podrá adjuntar los datos necesarios. El tamaño máximo de una incidencia es de 128 Mb. Imagen Interface para la creación de una incidencia. Para las validaciones de esta interface y para cualquier otra interface se utilizó JavaScript, el cual se manda llamar cuando los campos de prioridad, asignación, asunto o descripción están vacíos, en los campos de fecha de resolución esperada, datos adjuntos y nombre 50

51 de cliente no aplica debido a que es uno de los requisitos del cliente. En caso de no capturar alguno de los campos obligatorios el sistema enviará un pop up de alerta y no dejara continuar hasta que el campo se encuentre lleno. Imagen Validaciones que arroja la interface para la creación de una incidencia asignaciones. La asignación a los usuarios consiste en la canalización de usuarios, es decir, asignar un responsable para que se haga cargo de la incidencia. Si el personal de ventas crea una incidencia y la asigna por ejemplo al departamento técnico, entonces la incidencia le aparecerá automáticamente en el segmento mis asignaciones al usuario de departamento técnico. Cuando este decide contestar la incidencia 51

52 desaparece de la sección de mis asignaciones de departamento técnico y automáticamente aparece nuevamente en el segmento mis asignaciones pero del usuario de ventas. Asignar incidencia Contestar incidencia Usuario de ventas Imagen Asignaciones en el sistema de incidencias. Usuario depto. Técnico En Mis asignaciones el usuario actual podrá visualizar que incidencias tiene asignadas y en qué ha estado se encuentran, esto es controlado por un archivo de nombre view.php, ahí se deciden que columnas y campos mostrar, los datos son tomados de la clase issue.php la cual contiene todos los datos de una incidencia y estos son mostrados de acuerdo al usuario actual. Esta interface cuenta un checkbox manejado por JavaScript el cual cuando está activado oculta las incidencias cerradas al igual que un campo que indica cuantas incidencias se pueden mostrar en el momento. Las incidencias vienen administradas por cuatro diferentes colores que corresponden a los cuatro diferentes estados de una incidencia. Esto es controlado por la clase status.php que determina cuando una incidencia está cerrada o abierta. 52

53 Los estados que existen se utilizan para categorizar la incidencia y son los siguientes: Apertura Una incidencia en apertura es una incidencia nueva, es decir, que acaba de ser creada. Proceso Una incidencia en proceso es aquella que está siendo tratada o se le esta dando solución. Cierre provisional El cierre provisional es para aquellas incidencias que ya han sido tratadas y ya tienen una solución definitiva, por lo tanto se solicita que sea cerrada. Cierre definitivo El cierre definitivo se utiliza para indicar que efectivamente la incidencia ha pasado por un proceso para ser tratada, que se le ha dado solución acertada y que debe ser cerrada. Imagen Asignaciones en el sistema de incidencias. El único estado que tiene un contexto de cierre es la de cierre definitivo, esto significa que cuando el área de ventas decida cerrar una incidencia esta se marcará como solucionada, el cierre provisional no consta de contexto de cierre debido a que tiene una posible solución pero el área de ventas aun no lo aprueba como solución definitiva. 53

54 En la siguiente imagen se muestra la interface de la sección Mis Asignaciones del sistema de incidencias. Imagen Interface Mis asignaciones actuales del usuario ventas actualización de una incidencia. Todos los roles del sistema pueden actualizar una incidencia, el actualizar una incidencia implica dar una solución o notificar al personal de ventas el estado actual de dicha incidencia. Los campos de esta interface se dividen en dos segmentos, los archivos adjuntos y la actualización. Los datos adjuntos son controlados por la clase attachments.php esta es llamada desde el archivo update.php que es el que se encarga de mostrar la interface a través del archivo update.html.php El segundo segmento es el campo de estatus, asignaciones y descripción. El campo de estatus son los estados que ya se mencionaron anteriormente, el usuario debe asignar en que parte del proceso se encuentra dicha incidencia, como se mencionaba anteriormente el campo de cierre definitivo no cuenta con un contexto de cierre por lo tanto no se incluye en este campo. El campo de 54

55 asignaciones lo conforman nuevamente todos los usuarios del sistema a excepción del administrador. El campo de descripción está conformado por un historial de lo que van registrando los usuarios. Cuando se selecciona actualizar incidencia automáticamente el sistema introduce la fecha, la hora y el usuario actual para que sobre esos datos el usuario actual comience a capturar. Las acciones que se pueden realizar a dicha incidencias son cuatro. a) Actualizar: cuenta con las funciones de un botón submit, es decir que las acciones de dicho formulario se envían a la base de datos. b) Cancelar Actualización: este botón una vez activado re direcciona a la página interior. Es decir, cancela la actualización. c) Restablecer: el botón de restablecer cuenta con las funciones de un botón reset, es decir se encarga de limpiar cualquier cambio que haya sido modificado. d) Cerrar caso: esta opción como ya se ha mencionado anteriormente solo está disponible en los roles de usuario supervisor y usuario de ventas. Esta acción coloca la incidencia como cerrada y envía al usuario a un segundo formulario para que este capture la solución definitiva o el motivo por el cual es cerrado la incidencia. Una vez capturado este 55

56 formulario, la incidencia es catalogada como cerrada y nadie podrá modificarla. La siguiente imagen muestra dicho formulario. Imagen Interface de actualizar incidencia en el rol de usuario de ventas. La interface de actualizar incidencia se muestra a continuación: Imagen Interface de actualizar incidencia en el rol de usuario de ventas. 56

57 En cuanto a las validaciones de este formulario existen 3 que corresponden a los 3 campos existentes, la más importante de ellas es la de asignación, ya que si se actualiza una incidencia sin asignación esta se crea en la base de datos pero no se muestra. Imagen Validaciones que arroja la interface para actualizar una incidencia integración de correos. Para la integración de correos fue necesario basarse en la aplicación que ya viene predefinida por la aplicación de eventum, esta aplicación permite él envió de notificaciones por medio de un servidor smtp para lo cual se configura la aplicación con los datos del smtp de Siberline México. Para esto se crea un correo que pertenezca a la empresa, esto es para que a través de él salgan todas las notificaciones para los usuarios, también configura también el nombre del host y el puerto de salida. 57

58 Imagen Configuraciones del SMTP de la aplicación de eventum. Una vez levantados estos datos en la aplicación es necesario levantar un script en php desde consola, Algunos de los parámetros que contiene este script son el nombre de la tabla de donde extrae la información, el peso de las notificaciones, que tipo de notificación envía, de que incidencia y a que usuario le envía dicha información. El proceso para levantar el script manualmente es el siguiente: a) Entrar a la línea de comandos del sistema b) Ingresar a la carpeta de xampp y posteriormente a la carpeta de php c) Una vez dentro de php se teclea la ruta de dirección del archivo process_mail_queue.php que se encuentra dentro de la carpeta crons de eventum, la dirección sería algo como la siguiente línea: php q C:\xampp\htdocs\xampp\carpetadeeventum\crons\process_mail_queue.php Con esto queda levantado manualmente el script, en caso de que no funcione alguna de las configuraciones de la aplicación está mal. 58

59 Imagen Validaciones que arroja la interface para la creación de una incidencia. Para que esta sea una actividad que se repita cada un determinado tiempo es necesario almacenarlo en una tarea programa del sistema operativo. Como el servidor en el que se implementa el sistema de incidencias es un servidor Windows Server 2003 será sencillo programar dicha tarea. Para realizar esta tarea se siguen los siguientes pasos: a) Crear un archivo.bat que se encargue de ejecutar los comandos que se tecleaban anteriormente en consola, para crear un archivo.bat solo se debe de abrir un blog de notas y dentro de este escribir todos los comandos que queremos que se ejecuten tal y como se escribirían en consola. b) Posteriormente crear una tarea programada que ejecute el archivo,bat que se creó anteriormente, este se debe ejecutar cada cinco minutos los 59

60 365 días del año. Esto se hace a través del administrador de tareas programadas de Windows en la siguiente dirección: accesorios>>herramientas del sistema>>tareas programadas c) Una vez aplicados estos cambios, el script se ejecutará de acuerdo a lo programado, de no ser así se debe checar que el archivo.bat está bien escrito y se encuentra correctamente configurado, de lo contrario, se debe checar que xampp se encuentra instalado sobre C y no sobre otra unidad de almacenamiento. La siguiente imagen muestra la tarea programada que ejecuta el script. Imagen Validaciones que arroja la interface para la creación de una incidencia. Cuando se cree una incidencia, esta notificará al usuario asignado, esta notificación llega directamente a la bandeja de correo electrónico del asignado. Esto comprobará que las configuraciones del servidor smtp son correctas. Imagen Validaciones que arroja la interface para la creación de una incidencia. 60

61 El sistema de incidencias maneja tres tipos diferentes de notificaciones; una para cuando se crea un nuevo caso, otra para cuando se actualiza dicha incidencia y una última para cuando se ha cerrado lel caso. Estas notificaciones son archivos tpl.text estos son archivos templates de smarty, así que por lo tanto las variables y las clases se mandan llamar de la misma manera que en un template normal. La siguiente imagen muestra el código del archivo new.tpl.text el cual es una notificación que se envía a las personas asignadas cada vez que se crea una incidencia. Imagen Código del archivo new.tpl.text. La manera en cómo recibe el usuario esta notificación en su bandeja de entrada es la siguiente: 61

62 Imagen notificación electrónica de una nueva incidencia en el sistema listado de casos/reporte. El listado de casos o reporte es un segmento solo visible para los usuarios que pertenecen al rol de usuario supervisor o administrador, las únicas dos personas que son usuario supervisor son dos, el gerente general y el ingeniero de calidad, los demás usuarios no pueden tener estos privilegios. Existen dos tipos de listado de incidencias, casos por usuario asignado y casos abiertos por ventas. 62

63 El primer listado muestra absolutamente todas las incidencias que existen en el sistema ordenados por usuario alfabéticamente, sin importar el estado del caso, por usuario se refiere al personal que precisamente en ese momento tiene la incidencia en su poder, es decir, aquella persona que aún tiene pendiente esa tarea. Imagen Interface de listado de incidencias por usuario asignado. El segundo listado muestra todas aquellas incidencias abiertas ya sean en apertura, proceso o cierre provisional, estas las ordena alfabéticamente y de acuerdo al usuario que las abrió, es decir, solo usuarios de ventas. 63

64 Imagen Interface de listado de incidencias de casos abiertos por ventas. Cuando el usuario da clic sobre alguna de esas incidencias automáticamente el sistema le muestra la interface de visualizar detalles de la incidencia. Imagen Interface visualizar detalles de la incidencia. 64

65 9.5.8 faq interno. El FAQ interno es una sección cuya administración solo se encuentra disponible para usuarios que pertenecen al rol usuario supervisor o administrador, los demás usuarios solo pueden visualizar el contenido de estos. Cuando un usuario supervisor publica una nueva FAQ le aparecerá la siguiente interface o pantalla, en ella se registrará la descripción que se desea publicar. Imagen Interface de administración de FAQ s. Posteriormente todos podrán visualizar en la sección de FAQ s todas aquellas preguntas disponibles, cuando el usuario de clic sobre una de ellas podrá visualizar o que el administrador del FAQ escribió. Las interfaces son las siguientes. 65

66 Imagen Validaciones que arroja la interface para la creación de una incidencia. Imagen Validaciones que arroja la interface para la creación de una incidencia ayuda. La sección de ayuda es una ventana en la cual el usuario puede consultar aquellas preguntas que tengan referencia con el sistema de incidencias. En esa sección vienen las preguntas más comunes, esto con la finalidad de que el usuario no tenga tantos problemas al utilizar la aplicación. Las imágenes siguientes muestran las pequeñas interfaces de esta sección. 66

67 Imagen Validaciones que arroja la interface para la creación de una incidencia. Imagen Validaciones que arroja la interface para la creación de una incidencia. Cuando el usuario crea una incidencia o se encuentra en alguna otra interface que contenga el símbolo de ayuda, podrá dar clic y visualizar la ventana de ayuda en la sección en la que él desea. 67

68 Imagen Validaciones que arroja la interface para la creación de una incidencia adecuaciones a imagen institucional. La adecuación a la imagen institucional consiste en adaptar todo el sistema para que luzca de acuerdo a la imagen de Siberline México. Para esto se utilizaron los colores que hacen alusión a Siberline y además se utilizó la imagen institucional de la empresa. Imagen Validaciones que arroja la interface para la creación de una incidencia. 68

69 9.6 Pruebas por módulo Se realizaron diferentes pruebas al sistema la mayoría de ellas por módulo, las cuales fueron de suma importancia ya que de esto dependía el lanzamiento de la aplicación sobre el servidor. Todas se realizaron sobre el servidor local para cualquier prueba de fallo y error, posteriormente se hicieron pruebas en el servidor con una base de datos ficticia, con esta base se enviaron correos para corroborar que efectivamente él envió de correos electrónicos era automático. 9.7 Correcciones y adecuaciones finales Se realizaron adecuaciones finales de acuerdo a los deseos del gerente general, estas fueron con la finalidad de automatizar y mejorar algunos detalles, esto se hizo directamente sobre el código del sistema, ya que la mayoría de sus peticiones lo requerían. También este lapso de tiempo sirvió para realizar más pruebas de correo electrónico debido a que la configuración no era la adecuada. 9.8 Elaboración de manual de usuario Una vez finalizadas todas las etapas anteriores se procedió a realizar el manual de usuario, el cual resultó más fácil de elaborar una vez que todo el sistema ya se encontraba implementado. El resultado fue un archivo PDF el cual consta aproximadamente de 30 páginas, este archivo los usuarios pueden 69

70 descargarlo directamente de la página de ayuda del sistema de incidencias. Es importante mencionar que el manual se encuentra en su versión 1.0 ya que es la versión inicial de dicho sistema. Imagen Página de ayuda del sistema de incidencias 9.9 Presentación y autorización Una vez finalizada la aplicación se programaron citas con el gerente general de Siberline México, con la finalidad de que el pudiera evaluar y pedir cualquier tipo de modificación sobre el sistema. Esta actividad se realizó un par de veces más con la finalidad de que cada reunión sirviera como retroalimentación para ambas partes. Finalmente cuando los prototipos 70

71 cumplieron la expectativa del gerente general fue autorizado el arranque y la puesta en marcha Implementación en el servidor Para implementación en el servidor se decidió montar el servidor local dentro del servidor, todos los usuarios se podrán conectar al servidor por medio de intranet, por lo que no será necesario subirlo al servicio de hosting de la empresa. El servicio de xampp se instaló dentro de un file server que tiene acceso a internet. Esta dirección en un futuro se piensa modificar a una dirección IP fija, por el momento la dirección que pertenece a la red y a la que todos los usuarios se conectan es: Imagen Dirección del navegador hacia el sistema de incidencias. La siguiente imagen muestra la arquitectura actual de servidores donde se implementó el sistema de incidencias. Normalmente el usuario se conecta a través de un navegador web a internet con la dirección del file server , el servidor local Apache del file server automáticamente le desplegará al usuario el sistema de incidencias el cual funciona extrae los datos 71

72 de la base de datos de MySQL y envía notificaciones por medio del smtp de la empresa. Imagen Arquitectura de servidores actuales configuraciones Las configuraciones que se tienen que realizar en el servidor hacen referencia a configurar el envío de correo electrónico, estas configuraciones ya se vieron anteriormente en este documento en la sección de integración de correo base de datos Se debe asegurar que la configuración de la base de datos realmente funcione con el sistema, para esto se realizan pruebas sobre el servidor, es decir, levantar incidencias en el sistema para verificar que todo anda 72

73 bien. Para poder hacer estas pruebas y volver a reinicializar los ID s de las tablas de la base de datos es necesario realizar el siguiente query: ALTER TABLE incidencias AUTO_INCREMENT = 1; 9.11 Capacitación del personal Para que el personal de Siberline México pudiera aprender a manejar el sistema de incidencias se acordó una reunión de aproximadamente una hora de duración en la cual el área de sistemas y calidad pudieron dar a conocer los detalles de la aplicación. A esta reunión acudió el personal de las siguientes áreas: - Ventas - Compras - Almacén - Logística - Calidad - Crédito y Cobranza - Depto. Técnico - Dirección comercial - Dirección de operaciones Para el personal que se encuentra en la oficina de ventas de Culiacán, la capacitación al área ce ventas se realizó en tiempo real a través de video llamada y el resto del personal se capacitó vía telefónica. 73

74 9.12 Entrega/puesta en marcha Una vez realizados todos los pasos anteriores el área de ventas comenzó a levantar incidencias el día martes 12 de abril del presente año, con esto se dio por concluido la implementación del sistema de incidencias Seguimiento Para concluir con el proceso de todo el sistema finalmente se decidió dar un seguimiento de las acciones que se realizan a través del sistema, es decir, que todo transcurra con normalidad. También se realizaron respaldo de la base de datos y se aseguró que el envío de correos efectivamente se esté realizando a la fecha y horas programadas. 74

75 X. Resultados obtenidos De este proyecto se pudo obtener exitosamente un sistema de incidencias elaborado para trabajar en un explorador web, el cual cada vez que se crea o se actualiza una incidencia notifica vía correo electrónico a los usuarios asignados de que existe una incidencia y que debe ser atendida. La aplicación actualmente está trabajando sobre uno de los servidores de Siberline México brindando el servicio al personal que labora en la sucursal planta y en la oficina de ventas de Culiacán, todo esto a través de una intranet. a) Análisis de requisitos de la empresa: se obtuvieron los diagramas y los documentos necesarios para poder construir una arquitectura que vaya de la mano de una metodología y un modelado de negocio. b) Elaboración de un sistema Bug Tracking para la resolución de incidencias: se obtuvo exitosamente un sistema que mantiene un registro de las incidencias actuales de la empresa Siberline y además notifica a sus usuarios de que estas deben ser atendidas a la brevedad. c) Elaboración de manual de usuario y documentación del sistema de acuerdo a la ingeniería de software: se obtuvo la primer versión del manual la cual consta aproximadamente de 30 páginas y explica al usuario de manera sencilla la utilización del sistema. d) Capacitación de personal: se logró capacitar en su totalidad al personal de Siberline México que se encontraba involucrado en el proceso, se 75

76 capacitó al personal de almacén, al de planta y al personal de oficinas de Culiacán vía remota. e) Implementación/Instalación y configuración local del sistema: En un file server con salida a internet se logró configurar y montar la aplicación de incidencias con el fin de que los usuarios pudieran utilizarlo, los usuarios pueden ingresar fácilmente al sistema debido a que no necesitan hacer instalaciones previas, solo deben tener un explorador y pertenecer a la red local de Siberline México. 76

77 XI. Análisis de riesgos En la tabla número 1 se muestran los posibles riesgos a los que se puede enfrentar durante el proyecto, se especifican los planes de acción, los responsables y el tiempo disponible para darle seguimiento a dicha tarea. 77

78 Tabla 1 Análisis de Riesgos para el Desarrollo de Sistema BugTracking 78