Gestión de Incidencias
Versión: 1.2Fecha: 21/03/12
DIVISIÓN DE ESTUDIOS PROFESIONALES PARA EJECUTIVOS
Ingeniería de Sistemas
Curso
ARQUITECTURA DE SOFTWARE
Profesor Estanislao Contreras Chávez
Proyecto
Gestión de Incidencias
Sección
E74B
Integrantes
Salas Quispe, Sandy u201020924Huanco Flores, Pedro u201014197Ccori Ugarte, Cristian u201100364
Monterrico, Viernes 13 de abril del 2012
1
Gestión de Incidencias
Versión: 1.2Fecha: 21/03/12
Índice de contenidos1. Resumen ............................................................................................................................. 2
Índice de contenidos .............................................................................................................. 3
Listas especiales .................................................................................................................... 3
Introducción ............................................................................................................................ 4
Objetivos del proyecto ........................................................................................................... 5
CAPITULO 1 – Modelado de negocio ................................................................................... 6
CAPITULO 2 – Requerimientos .......................................................................................... 10
Asociado a los casos de uso del sistema ................................................................. 10
Usabilidad ................................................................................................................... 10
Confiabilidad ............................................................................................................... 10
Rendimiento ................................................................................................................ 10
Diseño .......................................................................................................................... 11
Plataforma ................................................................................................................... 11
Técnico de Sistemas. ................................................................................................. 13
Asistente de Servicio Técnico. .................................................................................. 13
Supervisor de TI. ......................................................................................................... 13
Administrador. ............................................................................................................ 13
Almacenero. ................................................................................................................ 13
CAPITULO 3 – Análisis ....................................................................................................... 26
CONCLUSIÓN ..................................................................................................................... 56
GLOSARIO DE TÉRMINOS ................................................................................................ 57
Siglario ................................................................................................................................. 58
BIBLIOGRAFIA .................................................................................................................... 59
Listas especiales
3
Gestión de Incidencias
Versión: 1.2Fecha: 21/03/12
Introducción
El presente proyecto muestra la aplicación de las habilidades y conocimientos adquiridos en cada clase del curso de Arquitectura de Software, enfocados al sistema de Gestión de Incidencias de la empresa Importaciones Y Tecnologías. Asimismo plantea una alternativa de mejora al proceso en mención que permitirá optimizar los tiempos y mejorar los resultados del Departamento de Operaciones y Servicios de la mencionada empresa.
Actualmente en el área de Operaciones y Servicios de Imptec se manejan contratos de mantenimiento, cada uno de los cuales tienes sus respectivos informes de ANS. Con cada informe de ANS presenta los datos de las incidencias generadas mensualmente y el porcentaje de eficacia, así tenemos en el informe, incidencias que no cumplen con el tiempo estipulado. Muchas veces dichas incidencias rebasan el tiempo establecido por uno o dos minutos, este tiempo de exceso no siempre está involucrado directamente en la resolución de la incidencia, sino más bien el proceso de asignación de la misma. Este proceso, entre otros, es manual y se realiza de una forma que no es nada óptima.
Con este proyecto se espera proponer una solución a la arquitectura actual del sistema “Gestión de Incidencias” relacionado al Departamento de Operaciones y Servicios.
.
4
Gestión de Incidencias
Versión: 1.2Fecha: 21/03/12
Objetivos del proyecto
Aplicar adecuadamente los lineamientos del curso Arquitectura de Software realizando el diseño de arquitectura utilizando la metodología RUP y la notación UML aplicado al proceso de Gestión de Incidencias de la empresa Importaciones y Tecnologías S.R.L. Para así poder obtener una solución arquitectónica óptima para implementar el sistema.
Mejorar el proceso de Gestión de Incidencias que se aplica en el departamento de Operaciones y servicios.
5
Gestión de Incidencias
Versión: 1.2Fecha: 21/03/12
CAPITULO 1 – Modelado de negocio
1.1 Descripción de la organización objetivo
Importaciones y Tecnologías S.R.L.Empresa vinculada al manejo de combustibles, presenta una cartera de negocios que están constituidos por productos, sistemas y servicios, cuenta con el respaldo de empresas internacionales de reconocido prestigio.
Actualmente cuenta en su cartera de clientes con empresas de la industria Minera, Petrolera, transporte, pesquera, agroindustria, empresas del retail petrolero como estaciones de servicio, grifos, etc.
Misión:
Tiene como misión ofrecer a sus clientes productos, sistemas y soluciones integrales con tecnología avanzada que les permita una gestión eficiente de su negocio, actividades y procesos relacionados a la transferencia, medición y control de combustibles.
Brindar productos y sistemas de calidad, actividades de servicio y soporte técnico que garanticen una óptima instalación y funcionamiento de sus equipos.
Así mismo mantiene un ambiente de trabajo agradable que permite a sus empleados lograr su desarrollo profesional y así poder cumplir con sus expectativas personales y familiares, aspectos fundamentales para mantener la motivación laboral y lograr las mejores relaciones interpersonales con sus clientes.
Visión:
Los negocios debido a un crecimiento sostenido y mejoramiento con sectores que atiende, requieren proveedores con una organización sólida, solvencia profesional y atenta a los cambios en las tecnologías y las necesidades del consumidor final; ese es el objetivo organizacional que compromete a Importaciones y Tecnologías a llevar un crecimiento sostenido y mejoramiento continuo en infraestructura, procesos administrativos y técnicos basados en estándares, permanente capacitación y manteniendo un clima que pueda satisfacer las expectativas del personal.
6
Gerencia General
Gerencia de Administración
Gerencia Comercial EESS
Gerenecia de Operaciones y
Servicios
Gerencia Industria y Mineria
Gerencia deServicio
Área de Tecnologíasde la Información y
Sistemas
Call Center TI y MMEE
Área Mecanica –Electrónica
Área de Proyectos
Contabilidad AdministraciónProvincias
Caja Almacén
VentasLima
VentasProvincia
VentasCorporativas
Gestión de Incidencias
Versión: 1.2Fecha: 21/03/12
Organigrama:
1.2 Descripción del negocio o campo de acción
Departamento de Operaciones y Servicios.
El Departamento de Operaciones y Servicios brinda el soporte a la empresa en cuanto a la instalación de los productos que los clientes adquieren, teniendo en cuenta que el cliente puede adquirir un producto, un sistema o una solución integral, este último puede abarcar una amplia gama de productos y sistemas, todos estos integrados. Para ello el departamento de Operaciones y Servicios toma cada implementación como un proyecto, haciéndose cargo de toda la gestión del proyecto.
Este departamento también brinda el servicio de mantenimiento, sea por el caso de garantía de los productos y/o soluciones, o en el caso que el cliente también haya adquirido un contrato de mantenimiento y soporte. En cuanto al contrato de mantenimiento y soporte, dependiendo del alcance de la solución ofrecida, en el intervienen las áreas de Mecánica Electrónica y Tecnologías de la Información. Es en estos contratos de mantenimiento que entra a tallar el proceso de Gestión de incidentes, necesarios para poder llevar el control de las incidencias y/o requerimientos que generen los clientes sean por temas preventivos o correctivos,
7
Gestión de Incidencias
Versión: 1.2Fecha: 21/03/12
en cuanto a la gestión de incidencias se tomará el caso más representativo que corresponde al día a día del soporte brindado al cliente Repsol.
Todas las incidencias son visualizadas por el personal de Call Center mediante la aplicación HP OpenView Service Desk, en todo momento durante todo el día una asistente del Call Center verifica la aplicación para ver si un nuevo incidente ha sido reportado, de verificar la existencia de una o más incidencias procede al realizar el registro comunicándose telefónicamente con el supervisor de TI, para solicitarle asigne un técnico para la resolución de cada una de las incidencias que se visualice en la consola del HP OpenView, o en su defecto para que indique el comentario de derivación en caso de que la incidencia registrada no se encuentre dentro del ámbito de resolución. Una vez que el supervisor de TI realiza la asignación la asistente del Call Center registra el incidente con el técnico asignado en la aplicación GDOS (Gestión de Operaciones y Servicios), registra datos como el número de incidencia, el cliente, la estación de servicio, el detalle del incidente y el técnico asignado, luego envía un correo electrónico al técnico asignado con el detalle de la incidencia o incidencias, finalmente se comunica telefónicamente con el técnico para informarle de la incidencia asignada.
Una vez que el técnico recibe una incidencia, sea leyendo su correo electrónico o contestando una llamada del Call Center, procede a realizar la atención de la misma, en primera instancia comunicándose telefónicamente con el personal de la estación de servicio (EESS) que genero la incidencia, lo primero que determina es si la incidencia requiere o no de Hardware (HW) para su resolución, de no requerir HW para su resolución solicita conexión remota a la ES y ahí determina si puede resolver el problema remotamente o si tiene que acercarse a la EESS para resolver el inconveniente, en ambos casos el técnico se comunica con la asistente del Call Center para registrar la actividad realizada hasta ese momento. Si soluciona el inconveniente remotamente, solicita la conformidad del personal de la EESS y cierra la incidencia comunicándose con la asistente del Call Center indicándole el comentario de cierre (este registro a veces se realiza mediante el envío de un correo electrónico). Si el problema no puede ser solucionado remotamente, el técnico coordina con la EESS la visita para la resolución del incidente e informa a la asistente del Call Center que acudirá a la EESS. Una vez en la EESS procede a solucionar el inconveniente para luego informar vía telefónica o mediante correo electrónico a la asistente del Call Center el comentario de resolución de la incidencia. De requerirse HW para la resolución de la incidencia el técnico le informa a la asistente de Call Center el equipo que requerirá, la asistente verifica el stock, luego solicita el equipo con la guía de remisión al almacenero, así mismo gestiona la movilidad para que el técnico traslade el equipo a la EESS, la asistente de Call Center le informa al técnico la hora que la movilidad pasara a recogerlo y le proporciona el equipo requerido, el técnico se comunica con la EESS para coordinar
8
Gestión de Incidencias
Versión: 1.2Fecha: 21/03/12
la visita para la resolución de la incidencia y se acerca a la ES según lo pactado, una vez que el técnico resuelve la incidencia le informa la asistente de Call Center el comentario y datos de cierre de la incidencia, mediante un correo electrónico o vía telefónica, así mismo le indica a la asistente del Call Center que en la EESS se deja en custodia el equipo defectuoso reemplazado.
Por cada incidencia que se registra la asistente de Call Center se comunica constantemente por vía telefónica con los técnicos encargados consultándoles el estado del proceso de resolución de la incidencia, el estado consultado es actualizado en el HP OpenView Service Desk y en la aplicación GDOS, una vez que el técnico concluye con la atención de la incidencia la asistente de Call Center registra el comentario de cierre brindado por el técnico, registra además el nombre y cargo de la persona que dio la conformidad por parte de la ES, así como los códigos de problema y desperfecto relacionados a la incidencia, este registro también se realiza en el HP OpenView Service Desk y en la aplicación GDOS, con este registro la asistente del Call Center procede a cerrar la incidencia. Así mismo, cada técnico al finalizar la atención de una incidencia procede a elaborar el parte técnico de la atención, en el registra el número de incidencia, el nombre del cliente, la estación de servicio, el problema reportado, el comentario de atención, los códigos de problema y trabajo realizado, la hora de inicio y la hora de fin de la actividad, y los datos de la persona de contacto que brinda la conformidad de la atención realizada.
Cada fin de mes, el gerente de servicio técnico solicita un informe de incidencias, este informe debe de contener el resultado de incidencias atendidas (cerradas y pendientes). Así mismo, en este informe se deben de identificar las incidencias que no cumplen con el tiempo de resolución, estipulado por el cliente (por ejemplo en el caso de Repsol: 1 hora y 30 minutos). Este informa también debe de presentar la información del número de incidencias por cada estación de servicio. Además de los códigos de problemas y trabajos realizados relacionados a cada incidente reportado. Toda esta información facilitará la generación del informe mensual de ANS.
Por otro lado, actualmente los técnicos no pueden consultar ni actualizar la información de las incidencias que les son asignadas. Se cree conveniente que la información de cada incidencia pueda ser visualizada en línea, por cada técnico, tanto para incidencias asignadas en su momento, como para consultas de incidencias registradas con anterioridad y consultar incidencias por cada estación de servicio. Esto permitiría a cada técnico poder consultar información histórica sobre una incidencia, además de poder visualizar sus tiempos de resolución con cada incidencia.
9
Gestión de Incidencias
Versión: 1.2Fecha: 21/03/12
CAPITULO 2 – Requerimientos
2.2 Especificación de los requerimientos de software
2.2.1 Lista de requerimientos suplementarios o de calidad
A continuación se listaran los requerimientos no funcionales:
Asociado a los casos de uso del sistema El tiempo de registro y asignación de incidencias no deberá exceder los
tres minutos, desde que la asistente de servicio técnico visualiza la incidencia en la aplicación HP OpenView, hasta que el mensaje de asignación es enviado automáticamente al técnico.
El sistema deberá de permitir que cada técnico pueda realizar el registro de las actividades que realiza, en todo momento, el tiempo de registro de una actividad no debería de superar el minuto por actividad.
El proceso de solicitud de HW no debería tomar más de 10 minutos, desde que el técnico registra la solicitud, hasta que la asistente de servicio proporciona la guía de remisión y el equipo al técnico. Esto implica que los procesos de Solicitar HW y Generar Nota de Pedido se realicen en un tiempo máximo de 5 minutos.
Usabilidad La interfaz de usuario deberá ser compatible con los principales
navegadores del mercado (browsers) de tal forma que los usuarios puedan acceder a la aplicación desde cualquier sistema operativo.
Se utilizará un estándar en la denominación y uso de controles y de hipervínculos de manera que el usuario se familiarice rápidamente con el manejo del sistema.
El sistema informará del éxito o fracaso de todas las transacciones realizadas por el usuario a través de la web.
Confiabilidad El sistema deberá de encontrarse disponible las 24 horas del día, los 7 días
de la semana. Un técnico deberá de poder realizar los registros de actividades respectivos
desde cualquier ubicación.
Rendimiento El sistema deberá permitir el acceso concurrente de 20 usuarios en
simultáneo, los cuales deberán de poder acceder a cualquiera de las opciones sin inconvenientes.
El tiempo de respuesta promedio del sistema para la generación de reportes debe ser no mayor a 10 segundos.
El tiempo de respuesta promedio del sistema para la operación de generación de Guía de Remisión debe ser menor a 5 segundos.
10
Gestión de Incidencias
Versión: 1.2Fecha: 21/03/12
El 95 por ciento de las transacciones del sistema no deben exceder los 5 segundos.
Diseño El diseño deberá de alinearse con los colores de la página web de la
empresa. Así mismo, los estilos deberán de ser los mismos. El acceso será vía web o wap desde cualquier computador o móvil que
tenga acceso a la red local o internet.
Plataforma Se deberá acceder de IE v5.0 en adelante y/o firefox v3.5 de Windows o
Linux sin inconvenientes. Se deberá elegir un motor de base de datos que facilite la consulta en
línea.
2.2.2 Lista de reglas de negocio
A continuación se definirán las reglas de negocio:
RN01: La asistente de Call Center monitorea la llegada de incidencias durante todo el día en la consola cliente.
RN02: Solo se registran incidencias reportadas por el aplicativo cliente y correo electrónico.
RN03: El supervisor de TI asigna cada incidencia al técnico responsable.
RN04: El supervisor de TI determina si una incidencia es asignada a un técnico o si esta es derivada a otro grupo de resolución.
RN05: Una vez que se tiene la confirmación de atención de incidencia, la asistente del Call Center realiza el registro en la aplicación GDOS. Los datos a registrar son:• Cliente.• Estación de servicio.• Problema.• Descripción del problema• Técnico asignado.
RN06: El sistema guarda el registro de incidencia asignando el primer estado “Nuevo”.
RN07: Al recibir una incidencia, el técnico se comunica con la ES para determinar:• Si la incidencia se puede resolver remotamente o presencialmente.• Si la incidencia requiere o no HW para su resolución.
11
Gestión de Incidencias
Versión: 1.2Fecha: 21/03/12
RN08: Una vez solucionada una incidencia, el técnico debe de solicitar la conformidad de la resolución al administrador o coordinador de la estación de servicio.
RN09: Si la incidencia requiere de HW para su resolución, la asistente del Call Center se encarga de:• Proporcionar el equipo requerido.• La guía de remisión para su traslado. • Gestionar la modalidad para el traslado del equipo.
RN10: Cada vez que el técnico utilice HW para la resolución de una incidencia, debe de comunicar a la asistente del Call Center si el equipo defectuoso queda en custodia de la estación de servicio.
RN11: Durante la resolución de una incidencia y al finalizar la atención de esta la asistente de Call Center se comunica constantemente con el técnico para consultarle el avance y/o estado del proceso de atención.
RN12: El técnico debe ingresar un detalle de la actividad realizada a cada incidencia reportada.
RN13: Al concluir una atención, el técnico entrega al asistente el parte técnico con los siguientes datos:• Número de incidencia.• Nombre del cliente.• Nombre de la estación de servicio.• Descripción del problema reportado.• Comentario de la labor realizada.• Código de problema relacionado al problema reportado.• Código de trabajo realizado relacionado a la labor realizada.• Fecha y hora de inicio de actividad.• Fecha y hora de fin de actividad.• Nombre y cargo de la persona que brinda la conformidad de la atención.
RN13: No se podrá generar una guía de remisión de equipos hasta que no se genere una nota de pedido del equipo.
RN14: A fin de mes, la asistente de Call Center entrega al gerente de servicio técnico los siguientes informes:• Incidencias atendidas, incluyen todas las incidencias atendidas durante el mes, entre cerradas y pendientes, incluye además los tiempos de atención por cada incidencia.• Cantidad de incidencias por estación de servicio.• Cantidad de incidencias por tipo de problema y trabajo realizado.
12
Gestión de Incidencias
Versión: 1.2Fecha: 21/03/12
RN15: Para la resolución de una incidencia el técnico cuenta con los siguientes tiempos:• Atención remota: 01:30• Atención presencial: traslado – 2:00, resolución – 01:30
RN16: Cada mes se debe de cumplir con el tiempo de resolución estipulado por lo menos para más del 90% de incidencias que se registren, de lo contrario se aplica una penalidad por parte del cliente.
2.3 Modelo de casos de uso
2.3.1Lista y diagrama de actores.
Lista de actores:
Técnico de Sistemas.
Persona que registra las actividades realizadas para la solución de incidencias, registra solicitud de HW en caso de ser necesario, Asimismo genera órdenes de servicio técnico (Parte Técnico).
Asistente de Servicio Técnico.
Persona que registra la incidencia, actualiza la incidencia, consulta stock y genera la nota de pedido para trasladar equipos según el requerimiento de la incidencia.
Supervisor de TI.
Persona que asignara la incidencia al técnico de sistemas para su solución y genera reporte de incidencias diarias y mensuales según el requerimiento solicitado.
Administrador.
Persona que registra toda la información necesaria para poder gestionar las incidencias. Asimismo, gestiona los accesos y perfiles de usuario, encargado de la seguridad y copia de seguridad.
Almacenero.
Persona que genera la guía de remisión para el traslado del equipo.
13
Gestión de Incidencias
Versión: 1.2Fecha: 21/03/12
Diagrama de actores:
2.3.2 Diagrama de Paquetes.
14
Gestión de Incidencias
Versión: 1.2Fecha: 21/03/12
2.3.3 Diagrama de casos de uso por paquete.
Seguridad:
Mantenimiento:
15
Gestión de Incidencias
Versión: 1.2Fecha: 21/03/12
2.4 Especificación de casos de uso de alto nivel
Gestión de Incidencias:
Caso de uso: Registrar IncidenciaActor(es): Asistente de Servicio TécnicoPropósito: Realizar el registro de incidencias con los detalles de la
incidencia reportada vía correo electrónico, aplicativo cliente o teléfono.
Caso de uso asociadoResumen: El caso de uso comienza cuando el Asistente de Servicio
Técnico desea registrar una incidencia. Según su requerimiento el Asistente de servicio técnico, ingresa la descripción detallada de la incidencia reportada y lo asigna al Supervisor de TI como primera opción. El caso de uso termina cuando se genera el registro de incidencia.
Clasificación: Primario
Caso de uso: Asignar incidenciasActor(es): Supervisor TIPropósito: Realizar asignación de incidencia a un Técnico de SistemasCaso de uso asociado: Consultar Incidencia (include)Resumen: El caso de uso comienza cuando el Supervisor de TI indica
"Asignar Incidencia" a un Técnico de sistemas, incluye el caso de uso "Consultar Incidencia" que mostrara las incidencias en estado nuevo. El caso de uso termina cuando se le asigna un técnico de sistemas responsable de la solución de dicha incidencia
Clasificación: Primario
Caso de uso: Consultar incidenciaActor(es): Supervisor de TI, Técnico de Sistemas y Asistente de
Servicio TécnicoPropósito: Obtener un listado de Incidencias que el actor pueda ver su
detalle. La incidencia seleccionada podrá ser usada en la pantalla que la invocó.
Caso de uso asociado:Resumen: El caso de uso comienza cuando el Supervisor de TI o el
Técnico de Sistemas o Asistente de Servicio Técnico desean conocer las incidencias. El sistema mostrará una lista de las incidencias según los filtros seleccionados. Para
18
Gestión de Incidencias
Versión: 1.2Fecha: 21/03/12
los usuarios Técnico de Sistemas o Asistente de Servicio Técnico se mostrará únicamente las incidencias que le hayan sido asignadas; para Supervisor de TI pueden mostrarse todas las incidencias. El caso de uso termina cuando el actor selecciona una incidencia.
Clasificación: Primario
Caso de uso: Registrar actividadActor(es): Técnico de sistemasPropósito: Registrar las actividades desarrolladas por cada técnico
durante la resolución de alguna incidencia.Caso de uso asociado: Consultar Incidencia (include)Resumen: El caso de uso comienza cuando el técnico, al final del día,
visualiza el listado de incidencias que tiene asignadas. El técnico selecciona una y le ingresa las actividades que ha desarrollado para atenderla y/o solucionarla. Una incidencia podría tomar más de un día en ser solucionada. El caso de uso termina cuando todas las actividades son registradas en el sistema.
Clasificación: Primario
Logística:
Caso de uso: Registrar solicitud de equipoActor(es): Técnico de SistemasPropósito: Realizar registro de solicitud de HWCaso de uso asociado: Consultar Incidencia (include)Resumen: El caso de uso comienza cuando el Técnico de Sistemas
requiere de un equipo o hardware para dar solución a la incidencia. El caso de uso termina cuando se registra una Solicitud de HW y se envía la solicitud vía correo al Asistente de Servicio Técnico.
Clasificación: Secundario
Caso de uso: Generar nota de pedidoActor(es): Asistente de Servicio TécnicoPropósito: Gestionar la solicitud de hardware del técnico de sistemas
para que pueda atender alguna incidencia.
Caso de uso asociado: Consultar Incidencia (include)Resumen: El caso de uso comienza cuando el técnico de sistemas
solicita equipo para solucionar alguna incidencia al asistente técnico vía teléfono o email. El asistente verifica el
19
Gestión de Incidencias
Versión: 1.2Fecha: 21/03/12
stock del equipo y genera la nota de pedido para que almacén pueda abastecer al técnico del equipo necesario (repuestos o hardware). El caso de uso termina cuando la nota de pedido es enviada al almacenero.
Clasificación: Secundario
Caso de uso: Generar guía de remisiónActor(es): AlmaceneroPropósito: Crear la Guía de Remisión con la que se transporte los
requerimientos de hardware que se requiere para solucionar una Incidencia.
Caso de uso asociado:Resumen: El caso de uso comienza cuando el actor desea crear una
Guía de Remisión. El sistema mostrará una lista de las notas de Pedidos que aún no poseen guías de remisión. El Actor selecciona una Nota de Pedido para crear la guía asociada a ella. El caso de uso termina cuando el actor crea la Guía de Remisión.
Clasificación: Secundario
Reporte:
Caso de uso: Generar reporte de actividadesActor(es): Supervidor de TIPropósito: Monitorear las actividades realizadas por cada técnico
respecto a las incidencias asignadas.Caso de uso asociado:Resumen: El caso de uso comienza cuando el superviso de TI
requiere conocer el estado de avance de cada incidencia registrada por medio de las actividades relacionadas a ella. Realiza la búsqueda buscando alguna incidencia o técnico. El caso de uso termina cuando exporta el reporte al formato que necesite.
Clasificación: Secundario
Caso de uso: Generar reporte general de incidenciasActor(es): Supervisor de TIPropósito: Generar reportes mensuales de las incidencias reportadas
(atendidas, pendientes de atención).Caso de uso asociado:Resumen: El caso de uso comienza cuando el Supervisor de TI desea
conocer el Reporte General de Incidencias. Se muestra la
20
Gestión de Incidencias
Versión: 1.2Fecha: 21/03/12
pantalla Reporte General de Incidencias (secciones y filtros) y el Supervisor de TI hace clic en el botón Generar Reporte. El caso de uso termina cuando el reporte es enviado vía email al Gerente de Servicio Técnico.
Clasificación: Secundario
Gestion de Seguridad:
Caso de uso: Iniciar sesiónActor(es): UsuarioPropósito: Iniciar sesión en el sistemaCaso de uso asociado: Cambiar la contraseña (extend)Resumen: El caso de uso comienza cuando el Usuario selecciona la
opción “Iniciar Sesión” desde la página de logueo del sistema.El caso de uso termina cuando se muestra la página de inicio del sistema.
Clasificación: Primario
Caso de uso: Cambiar contraseñaActor(es): UsuarioPropósito: Cambiar la contraseña para iniciar sesiónCaso de uso asociado:Resumen: El caso de uso comienza cuando el Usuario indica
“Cambiar Contraseña” según su requerimiento.El caso de uso termina cuando se realiza el cambio de la contraseña.
Clasificación: Secundario
Caso de uso: Gestionar perfilesActor(es): SeguridadPropósito: Mantener actualizados los datos de los perfiles utilizados en
el sistemaCaso de uso asociado:Resumen: El caso de uso comienza cuando el actor Seguridad indica
"Gestionar Perfiles" según su requerimiento, en esta se mostrará un mantenimiento que permita realizar el registro, actualización y eliminación de un perfil. El caso de uso termina cuando se registra, actualiza o elimina un perfil.
Clasificación: Primario
21
Gestión de Incidencias
Versión: 1.2Fecha: 21/03/12
Caso de uso: Realizar backupActor(es): SeguridadPropósito: Realizar copia de respaldo del sistemaCaso de uso asociado:Resumen: El caso de uso comienza cuando el actor Seguridad indica
“Realizar Backup” según su requerimiento.El caso de uso termina cuando la copia de respaldo se realiza exitosamente.
Clasificación: Opcional
Caso de uso: Registrar accesoActor(es): SeguridadPropósito: Registrar accesos de los usuarios al sistemaCaso de uso asociado:Resumen: El caso de uso comienza cuando el actor Seguridad indica
“Registrar acceso” según su requerimiento.El caso de uso termina cuando el acceso del usuario al sistema queda registrado.
Clasificación: SecundarioMantenimiento:
Caso de uso: Gestionar clientesActor(es): AdministradorPropósito: Realizar el mantenimiento de los clientesCaso de uso asociado:
Registrar estación de servicio (extend)
Resumen: El caso de uso comienza cuando el Administrador indica "Gestionar Clientes" según su requerimiento, en esta se mostrará un mantenimiento que permita realizar el registro, actualización y eliminación de un cliente, y extiende al caso de uso Registrar estación de servicios. El caso de uso termina cuando se registra, actualiza o elimina un cliente.
Clasificación: Primario
Caso de uso: Registrar estación de servicioActor(es): AdministradorPropósito: Realizar el registro de las estaciones de servicioCaso de uso asociado:Resumen: El caso de uso comienza cuando el Administrador indica
"Registrar estación de servicio" según su requerimiento. El caso de uso termina cuando se crea el registro de la estación de servicio.
22
Gestión de Incidencias
Versión: 1.2Fecha: 21/03/12
Clasificación: Primario
Caso de uso: Gestionar usuariosActor(es): AdministradorPropósito: Realizar el mantenimiento de los usuariosCaso de uso asociado:Resumen: El caso de uso comienza cuando el Administrador indica
"Gestionar Usuarios" según su requerimiento, en esta se mostrará un mantenimiento que permita realizar el registro, actualización y eliminación de un usuario. El caso de uso termina cuando se registra, actualiza o elimina un cliente.
Clasificación: Primario
23
Gestión de Incidencias
Versión: 1.2Fecha: 21/03/12
2.5 Lista de casos de uso priorizados
Nombre del CUS Complejo Estado Dificultad Responsable Prioridad
1. Registrar Incidencia
Primario Def Alta Sandy Salas Ciclo 0
2. Asignar incidencias
Primario Def Media Sandy Salas Ciclo 0
3. Consultar incidencia
Primario Def Alta Pedro Huanco Ciclo 0
4. Registrar actividad
Primario Def Alta Cristian Ccori Ciclo 0
5. Registrar solicitud de equipo
Primario Def Alta Sandy Salas Ciclo 0
6. Generar nota de pedido
Primario Def Alta Cristian Ccori Ciclo 0
7. Generar guía de remisión
Primario Def Media Pedro Huanco Ciclo 0
8. Generar reporte de actividades
Secundario Def Alta Cristian Ccori Ciclo 1
9. Generar reporte general de incidencias
Secundario Def Media Pedro Huanco Ciclo 1
10. Gestionar clientes
Secundario Def Media Ciclo 1
11. Registrar estación de servicio
Secundario Def Media Ciclo 1
12. Gestionar usuarios
Secundario Def Media Ciclo 1
13. Gestionar perfiles
Secundario Def Media Ciclo 1
14. Registrar acceso
Opcional Def Baja Ciclo 2
15. Iniciar sesión Opcional Def Baja Ciclo 216. Cambiar
contraseñaOpcional Def Baja Ciclo 2
17. Realizar backup
Opcional Def Baja Ciclo 2
2.6 Lista de casos de uso que impactan en la arquitectura
24
Gestión de Incidencias
Versión: 1.2Fecha: 21/03/12
Nombre de casos de uso
Registrar Incidencia
Registrar actividad
Generar guía de remisión
25
Gestión de Incidencias
Versión: 1.2Fecha: 21/03/12
CAPITULO 3 – Análisis
3.1 Modelo del dominio de clases o modelo conceptual
Técnico
+codigo+nombre+apelidos+direccion+fecha_ingreso+celular+telefono
Incidencia
+codigo+codigo_estacion+fecha_asignacion+fecha_resolucion+estado+codigo_tecnico+comentario+fecha_recepcion+horas_asignacion+descripcion+medio_reporte
Nota de Pedido
+codigo+codigo_incidencia+nombre_tecnico+responsable+fecha_solicitud
Equipo
+codigo+nombre+cantidad+fecha_registro
Estacion de Serv icio
+codigo+nombre+direccion+codigo_cliente
Guia de Rem ision
+codigo+codigo_nota_pedido+fecha+origen+destino+descripcion
1 1
10..*
genera
11
requiere
1
0..*
Detalle Nota de Pedido
+codigo_nota_pedido+codigo_equipo+cantidad
1
1..*
10..*
Act iv idad
+codigo_incidencia+codigo_tecnico+problema+trabajo_realizado+fecha_inicio+fecha_fin
Cliente
+codigo+nombre+razon_social+direccion+telefono+contacto
1
1..*
26
Gestión de Incidencias
Versión: 1.2Fecha: 21/03/12
3.2 Realización de los casos de uso para el análisis
3.2.1 Diagrama de clases de análisis.
Registrar Incidencia
Asignar Incidencia
27
Gestión de Incidencias
Versión: 1.2Fecha: 21/03/12
Generar Nota de Pedido
Generar Guía de Remisión
31
Gestión de Incidencias
Versión: 1.2Fecha: 21/03/12
Generar Reporte de Incidencia
Registro Solicitud de equipo
Generar Reporte de Actividades
32
Gestión de Incidencias
Versión: 1.2Fecha: 21/03/12
3.2.2 Especificación detallada o historias de usuario de los casos de uso que impactan en la arquitectura.
Gestión de Incidencias:
Nombre del caso de uso
CU01- Registrar Incidencia
Tipo Esencial y primarioActores Asistente de Servicio TécnicoDescripción El caso de uso comienza cuando el Asistente de Servicio
Técnico desea registrar una incidencia. Según su requerimiento el Asistente de servicio técnico, ingresa la descripción detallada de la incidencia reportada y lo asigna al Supervisor de TI como primera opción. El caso de uso termina cuando se genera el registro de incidencia.
Referencia de requerimientos funcionales asociados
RF01: Registrar la información del servicio solicitado.RF02: Seleccionar un cliente de la lista de clientes.RF03: Seleccionar una estación de servicio de la lista de
estaciones por cliente.RF04: Seleccionar un técnico de la lista de técnicos.
Puntos de inclusión o ExtensiónReglas de Negocio
RN01: La asistente de Call Center monitorea la llegada de incidencias durante todo el día en la consola cliente.
RN02: Solo se registran incidencias reportadas por el aplicativo cliente y correo electrónico.
RN03: El supervisor de TI asigna cada incidencia al técnico responsable.
RN05: Una vez que se tiene la confirmación de atención de incidencia, la asistente del Call Center realiza el registro en la aplicación GDOS.
RN06: El sistema guarda el registro de incidencia asignando el primer estado “Nuevo”.
Precondiciones: Incidencia reportada por cliente vía teléfono, correo o aplicativo cliente.
Poscondiciones: Incidencia (problema o requerimiento) registrada en el sistema para su posterior asignación, atención y solución.
Flujo Básico de Eventos1.1 El Asistente de servicio técnico selecciona la opción "Registrar nueva
Incidencia" del menú de Incidencias.1.2 El sistema muestra el formulario “Registro de incidencia”.1.3 El Asistente de servicio técnico selecciona del combo al cliente que reporto la
34
Gestión de Incidencias
Versión: 1.2Fecha: 21/03/12
incidencia.1.4 El sistema muestra la información del cliente seleccionado.1.5 El Asistente de servicio técnico selecciona del combo la estación de servicio.1.6 El sistema muestra la información de la estación de servicio seleccionado.1.7 El Asistente de servicio técnico ingresa el detalle del problema reportado o
requerimiento solicitado.1.8 El Asistente de servicio técnico asigna la incidencia a quien corresponda
(Supervisor de TI o Técnico responsable).1.9 El Asistente selecciona el botón "Guardar".1.10 El sistema asigna el estado “Nuevo” a la incidencia y lo guarda en la base de
datos.Flujo alternativosFlujo alternativo 1: Valida información ingresadaSi en [1.7] la información ingresada por el Asistente de servicio técnico no es consistente (Tipo de datos ingresados) o no es suficiente el sistema mostrara un mensaje indicando el error. El caso continua en [1.6].
Nombre del caso de uso
CU01- Registrar actividad
Tipo Esencial y primarioActores Técnico de sistemasDescripción El caso de uso comienza cuando el técnico, al final del día,
visualiza el listado de incidencias que tiene asignadas. El técnico selecciona una y le ingresa las actividades que ha desarrollado para atenderla y/o solucionarla. Una incidencia podría tomar más de un día en ser solucionada. El caso de uso termina cuando todas las actividades son registradas en el sistema.
Referencia de requerimientos funcionales asociados
RF01: Registrar la información de la actividad realizada.
RF02: Cambiar a estado solucionado
Puntos de inclusión o Extensión
Consultar Incidencia (Inlcude)
Reglas de Negocio
RN01: El técnico debe ingresar un detalle de la actividad realizada a cada incidencia reportada.
Precondiciones: Se deberán asignar incidencias al técnico que ingresó al sistema para que pueda comenzar a registrar sus actividades.
Poscondiciones: Se registran actividades por cada incidencia hasta que puedan estar solucionadas.
Flujo Básico de Eventos
35
Gestión de Incidencias
Versión: 1.2Fecha: 21/03/12
1.1 El técnico de sistemas ingresa al menú y selecciona la opción “Registrar Actividad”.
1.2 El sistema muestra la pantalla de “Consulta de Incidencias” con filtros de búsqueda.
1.3 El técnico de sistemas realiza la consulta de incidencias. Se desarrolla el caso de uso “Consultar Incidencia”.
1.4 El sistema muestra la lista de incidencias asignadas al técnico de acuerdo a la búsqueda realizada.
1.5 El técnico de sistemas selecciona una incidencia del listado y hace clic en el botón “Registrar Actividades”.
1.6 El sistema muestra el formulario de “Registro de Actividades” para la incidencia elegida y muestra las actividades previamente ingresadas en la grilla de actividades.
1.7 El técnico ingresa las actividades que ha desarrollado durante el día para atender la incidencia seleccionada, escoge un tipo de problema y de trabajo para la incidencia; además, ingresa la información adicional requerida como el tiempo de demora y hace clic en el botón “Agregar”.
1.8 El sistema valida la información requerida y va agregando cada actividad en la grilla de actividades.
1.9 El técnico de sistemas cambia a estado “Solucionado” la incidencia y hace clic en el botón “Grabar”.
1.10 El sistema registra todas las actividades ingresadas para una determinada incidencia en la base de datos.
1.11 El técnico de sistemas hace clic en el botón “Salir”.1.12 El sistema muestra la lista actualizada de incidencias.Flujo alternativosFlujo alternativo 1: Incidencia ya Solucionada.Si en [1.5] la incidencia es se encuentra en estado “Solucionado”, el sistema no permitirá agregar más actividades bloqueando los controles, el caso de uso termina.Flujo alternativo 2: Incidencia aún no SolucionadaSi en [1.7] la incidencia aún no ha sido solucionada por el técnico, se queda en estado “En reparación”, ya que se deberán agregar más actividades. El caso de uso continúa en [1.8].Flujo alternativo 3: Falta información o no válidaSi en [1.8] la información ingresada por el técnico no es suficiente o no es consistente (tipo de datos) el sistemas arroja un mensaje indicando el error específico y no agrega la actividad. El caso de uso continúa en [1.7].
Nombre del caso de uso
CU01- Generar Guía de Remisión
Tipo Esencial y primarioActores AlmaceneroDescripción El caso de uso comienza cuando el actor desea crear una Guía
36
Gestión de Incidencias
Versión: 1.2Fecha: 21/03/12
de Remisión. El sistema mostrará una lista de las notas de Pedidos que aún no poseen guías de remisión. El Actor selecciona una Nota de Pedido para crear la guía asociada a ella. El caso de uso termina cuando el actor crea la Guía de Remisión.
Referencia de requerimientos funcionales asociados
RF01: Seleccionar nota de pedido.
RF02: Generar guía de remisión.
Puntos de inclusión o ExtensiónReglas de Negocio
RN013: No se podrá generar una guía de remisión de equipos hasta que no se genere una nota de pedido del equipo.
Precondiciones: Deberán existir los datos de clientes para que se muestren en los filtros de la pantalla.
Poscondiciones: Se debe encontrar la guía registrada en la base de datos.
Flujo Básico de Eventos1.1 El actor selecciona la opción “Crear Guía de Remisión” del menú principal.1.2 El Sistema muestra la pantalla “Crear Guía de Remisión” con el listado de las
Notas de Pedido que aun no poseen Guía de Remisión.1.3 El actor selecciona una nota de Pedido y hace clic en el botón Generar Guía
de Remisión.1.4 El sistema obtiene los datos y detalle de la nota de Pedido, el detalle de la
nota y del cliente.1.5 El sistema muestra la pantalla Nueva Guía de Remisión con los datos
precargados del cliente como destino, de la empresa, así como el origen, el detalle de los bienes que se transportarán (provienen de la Nota de Pedido).
1.6 El actor ingresa la fecha de envío, el nombre del transportista y la placa del vehículo, hace clic en la opción guardar.
1.7 El sistema almacena en la base de datos la Guía de Remisión y muestra un mensaje de éxito.
37
Gestión de Incidencias
Versión: 1.2Fecha: 21/03/12
3.2.3 Diagrama de interacción de los casos de uso especificados.
Registrar Incidencia
38
Gestión de Incidencias
Versión: 1.2Fecha: 21/03/12
3.3 Diagramas de máquinas de estado
DME-INCIDENCIA
Nuevo
entry/Ingresar informacion
Registrar incidencia en el sistema
En AtencionRegistrar Actividades
SolucionadoEn Observacion
entry/Verifica tiempo reparacionexit/Enviar notificaion
[ No se encontro solucion ]
[ Si se encontro solucion ]
Reparar incidencia : [ Aplica reparacion ]
Asignado
exit/Enviar notificacion
Asisgnar a Técnico de Ssitemas
Actualizar
Descartado[ No aplica reaparacion ]
44
Gestión de Incidencias
Versión: 1.2Fecha: 21/03/12
DME-NOTA PEDIDO
Solicitado
entry/Llamada/correo tecnico sistemas
Solicitar nota de pedido
En Espera
exit/Eviar correo para reponer stock
Llenar nota de pedido
Generado
exit/Envia correo a almacen
En Atencion
do/Verifica stock equipos
[ No hay equipo en stock ]
[ Si hay equipo en stock ]
Abastecer equipo sin stockRegistrar
45
Gestión de Incidencias
Versión: 1.2Fecha: 21/03/12
CAPITULO 4 – Arquitectura
4.1 Introducción
El presente proyecto describe los elementos con los que se forma la estructura del sistema que operará en un entorno WEB. Se han considerado todas las restricciones y los riesgos que afectarían su normal funcionamiento cuando la aplicación esté en producción.
En el documento se presentarán las metas y restricciones de la arquitectura. Asimismo, una descripción detallada de las vistas que la conforman, tomando como base la arquitectura 4+1 de Krutchen.
4.1.1 Propósito
El propósito de este documento es proporcionar una apreciación global de la arquitectura del sistema usando diferentes vistas arquitectónicas.
4.1.2 Alcance
Este documento define los conceptos de la arquitectura de mayor impacto sobre las decisiones de análisis, diseño y posterior implementación.
Para el análisis se han tomado en cuenta:
• Identificación de los mecanismos de análisis.• Definición de la organización de alto nivel de los subsistemas.• Criterios para dar solución a los requerimientos no funcionales.
Y para el diseño:
• Identificación de las capas lógicas y de los subsistemas.• Identificación de las interfaces.• Identificación de los mecanismos de diseño que darán solución a los
requerimientos no funcionales.
4.1.3 Defini ciones, acrónimos y abreviaturas
Una definición completa de los conceptos y de la terminología empleada en el documento se encuentra en el glosario de términos descrito en el informe del proyecto.
46
Gestión de Incidencias
Versión: 1.2Fecha: 21/03/12
4.2 Representación de la arquitectura
Tomando en cuenta el esquema de la ilustración 1, a partir del acápite 4, describiremos cada una de las vistas de la arquitectura del sistema:
i. En la vista de casos de uso seleccionaremos y representaremos los casos de uso primarios, de mayor impacto y que constituyen el núcleo central del sistema
ii. En la vista lógica describiremos como se han agrupado las diferentes clases del sistema en capas y también como dichas capas están relacionadas entre si.
iii. En la vista de componentes o de la implementación describiremos la descomposición del sistema en diferentes subsistemas.
iv. A través de la vista del proceso, representaremos a los componentes del sistema en modo de ejecución
v. Y finalmente, gracias a la vista de distribución representaremos el hardware: procesadores y dispositivos necesarios para la implementación del sistema.
4.3 Metas y restricciones
4.3.1Requerimientos que impactan a la arquitectura
A continuación presentamos un inventario de los requerimientos no funcionales de mayor impacto en la arquitectura así como los mecanismos de análisis y diseño considerados para implementarlos de manera eficiente.
47
Vista de
Componentes
Vista del Proceso Vista de la Distribución
Vista de Casos de Uso
Vista Lógica
Funcionalidad
Usuarios Finales
Admin. de Software, Reuso y Portabilidad
Ingenierosde Software
Rendimiento, Disponibilidad,
Tolerancia a Fallas
Integradores
=VP + Escalabilidad, Entrega e Instalación
Ingenierosde Sistemas
Comprensión y Uso
Gestión de Incidencias
Versión: 1.2Fecha: 21/03/12
Los requerimientos no funcionales que constituyen las metas y restricciones de la arquitectura son:
Requerimientos No FuncionalesCódigo Descripción
Requerimientos de Capacidad de UsoRNF01 La interfaz de usuario deberá ser compatible con los principales
navegadores del mercado (browsers) de tal forma que los usuarios puedan acceder a la aplicación desde cualquier sistema operativo.
RNF02 Se utilizará un estándar en la denominación y uso de controles y de hipervínculos de manera que el usuario se familiarice rápidamente con el manejo del sistema.
RNF03 El sistema informará del éxito o fracaso de todas las transacciones realizadas por el usuario a través de la web.
Requerimientos de ConfiabilidadRNF04 En general el sistema deberá estar disponible las 24 horas del día los 7
días de la semana.RNF05 Si se presentaran interrupciones por errores de la aplicación, problemas
de bases de datos, corte en la comunicación, etc. se deben tener planes de contingencia que permita restaurar la operatividad del software lo más pronto posible.
RNF06 Se utilizarán servicios para garantizar la confiabilidad de la información, el control de transacciones, la concurrencia, el historial de eventos y la recuperación de datos.
RNF07 El sistema deberá garantizar la confidencialidad del manejo de claves de usuarios y el cumplimiento de las políticas de seguridad
Requerimientos de RendimientoRNF08 El sistema deberá permitir el acceso concurrente de 20 usuarios en
simultáneo, los cuales deberán de poder acceder a cualquiera de las opciones sin inconvenientes.
RNF09 El 95 por ciento de las transacciones del sistema no deben exceder los 5 segundos.
Requerimientos de SoporteRNF10 Se debe lograr resolver las preguntas y errores comunes del usuario al
manejar una aplicación Web, como uso del browser y manejo de hipervínculos.
Restricciones de DiseñoRNF11 Se debe utilizar una herramienta case que permita al desarrollador una
mejor comprensión de la forma como debe implementar el sistema.Requerimientos de ImplementaciónRNF12 Se debe efectuar el desarrollo en un lenguaje de programación y motor
de base de datos que permita un desarrollo rápido y posterior puesta en marcha del sistema de manera eficiente.
RNF13 Se debe elegir un motor de base de datos que facilite la consulta en línea de datos históricos de hasta 3 años.
RNF14 Se debe garantizar que no existirá pérdida de datos.
48
Gestión de Incidencias
Versión: 1.2Fecha: 21/03/12
Requerimientos No FuncionalesCódigo DescripciónRNF15 El sistema debe conectar activamente a las áreas de departamento de
servicio técnico y almacén tanto para el caso de las facturas como para el de los pedidos internos.
4.3.2Mecanismos y tácticas de diseño usadas
Los mecanismos constituyen las técnicas que pueden implementar los requerimientos no funcionales relacionados a la arquitectura del sistema.
En esta sección se presentan y describen los mecanismos de análisis y diseño seleccionados, y los requerimientos no funcionales específicos que buscan satisfacer. Además, la solución tecnológica propuesta para resolverlos.
Mecanismos de análisis y sus soluciones a través del diseño y la implementación
Mecanismo Requerimientos No Funcionales
Solución
Manejo de errores: Permite que los errores sean detectados, propagados y notificados.
RNF03 Comprende: El manejo de los errores de datos
que se resolverá en el servidor de base de datos y en las clases que manejan la lógica del negocio.
El soporte a las excepciones a través de componentes especiales de soporte de errores.
Manejo de transacciones:Permite que los resultados de las operaciones sean notificados.
RNF03 A través de ventanas emergentes.
Manejo de interfaz de usuario: Permite que la interfaz de usuario sea fácil de operar.
RNF01RNF02RNF05
El uso del lenguaje de programación Java provee un ambiente de diseño de aplicaciones Web compatibles con la mayoría de los browsers del mercado y también un conjunto de estándares que facilitan el diseño de interfaces web amigables.
49
Gestión de Incidencias
Versión: 1.2Fecha: 21/03/12
Mecanismos de análisis y sus soluciones a través del diseño y la implementación
Mecanismo Requerimientos No Funcionales
Solución
Administración del proceso: Proporciona el soporte para el manejo de los procesos
RNF04RNF06RNF12
Se utilizará un servidor Web que estará operativo las 24 horas del día y que proporcionará servicios para el control de transacciones.
La elección de un servidor de base de datos como SQL Server 2000 permite garantizar tanto la recuperación como el manejo de registro de eventos (log).
Seguridad: Proporciona servicios de protección contra accesos no permitidos a recursos de información.
RNF07 El manejo de la seguridad se efectuará a través de la definición de perfiles con derecho a ciertas opciones del sistema. Los usuarios estarán asociados a un determinado perfil.
Manejo de la ayuda: Proporciona las capacidades de ayuda en línea
RNF10 Dentro del aplicativo se contará con una aplicación especial de ayuda a las principales funciones del sistema y esto se accederá por una opción en cada ventana del sistema.
50
Gestión de Incidencias
Versión: 1.2Fecha: 21/03/12
4.4 Vista de los casos de uso
4.4.1Diagrama de los casos de uso que impactan en la arquitectura
Generar guiade remision
Registrarincidencia
Registraractividad
Tecnico de Sistemas
Almacenero
Asistente de Servicio Tecnico
Casos de Uso Impactan Arquitectura
4.5 Vista lógica
En esta sección se presenta una vista en alto nivel del sistema propuesto.
La siguiente ilustración muestra el diagrama con las capas lógicas del sistema y a continuación describimos la forma de agrupación de las clases del sistema, de acuerdo a su funcionalidad.
4.5.1Diagrama de capas
51
Gestión de Incidencias
Versión: 1.2Fecha: 21/03/12
4.5.2Diagrama de subsistemas
4.6 Vista de implementación
Esta sección presenta la relación y comunicación de los componentes durante la ejecución de la aplicación.
Como se puede apreciar los componentes se han agrupado en concordancia con la división del sistema en capas. A continuación presentamos la relación de cada uno de ellos.
4.6.1Diagrama de implementación
53
Gestión de Incidencias
Versión: 1.2Fecha: 21/03/12
4.6.2Framework y/o patrones de arquitectura usados (opcional)
Para este proyecto se aplicara Struts 2
Se usara el Servidor JBOS.
Se usara Eclipse como ID de desarrollo, como lenguaje de programación JAVA.
4.7 Vista de despliegue
4.7.1Diagrama de despliegue
54
Gestión de Incidencias
Versión: 1.2Fecha: 21/03/12
CAPITULO 5 – Diseño detallado
5.1 Diagrama de la base de datos
55
Gestión de Incidencias
Versión: 1.2Fecha: 21/03/12
CONCLUSIÓN
En este proyecto, se logro realizar el análisis del proceso de gestión de incidencias de la empresa Importaciones y Tecnologías aplicando la metodología RUP y estándares UML..
• Se logro aplicar y reforzar los conceptos aprendidos sobre la metodología RUP y los
estándares UML en el modelado de negocio de la empresa.
• Se logro Identificar los problemas relacionados al actual proceso de gestión de
incidencias.
• Se logro Desarrollar destrezas en el uso de las herramientas Start UML para el
modelado de diagramas.
• Se logro Generar la documentación de modelado de negocios del proceso de gestión
de incidencias de la empresa mencionada.
Finalmente, se ha podido comprobar que la buena aplicación de las disciplinas de RUP, nos permite conocer el que procesos o actividades podemos optimizar.
56
Gestión de Incidencias
Versión: 1.2Fecha: 21/03/12
GLOSARIO DE TÉRMINOS
Hp OpenView Service Desk: solución para la gestión de los servicios de TI desde la perspectiva del cliente. Cuenta con una base de datos de gestión de la configuración unificada, así como con una nueva herramienta de generación de informes y otra de gestión de acuerdos de nivel de servicios (Service Level Manager 5.0), que permiten una rápida y automatizada respuesta de las TI a las necesidades del negocio, así como una mejora del servicio mediante la reducción del tiempo medio de reparación, y una reducción del coste total de propiedad.
EESS: abreviación usada en negocio de retail ligados a la venta de combustible, que hace referencia a una estación de servicio, o comúnmente conocido como grifo.
GDOS: Sistema de gestión de servicios utilizado por el departamento de Operaciones y Servicios de la empresa Importaciones y Tecnologías S.R.L.
57
Gestión de Incidencias
Versión: 1.2Fecha: 21/03/12
Siglario
- UML: Unified Modeling Language.
- RUP: Rational Unified Process.
58
Gestión de Incidencias
Versión: 1.2Fecha: 21/03/12
BIBLIOGRAFIA
• Material de clases del curso.
• Casos de uso de ejemplo desarrollados en clase.
• www.google.com
• http://es.wikipedia.org/wiki/Lenguaje_Unificado_de_Modelado
59
Top Related