97167793 arquitectura-de-software

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


Sección

E74B

Integrantes

Salas Quispe, Sandy u201020924Huanco Flores, Pedro u201014197Ccori Ugarte, Cristian u201100364

Monterrico, Viernes 13 de abril del 2012

1

http://moodle.upc.edu.pe/user/view.php?id=61594&course=1



1. Resumen

2



Í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



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



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



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



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



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



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



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



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



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



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



Diagrama de actores:

2.3.2 Diagrama de Paquetes.

14



2.3.3 Diagrama de casos de uso por paquete.

Seguridad:

Mantenimiento:

15



Gestión de Incidencias :

Logistica:

16



Reportes:

17



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


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



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.


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.


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



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.


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.


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.


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



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.


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.


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.


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.


21



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.


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




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.


23



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


12. Gestionar usuarios


13. Gestionar perfiles


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



Nombre de casos de uso

Registrar Incidencia

Registrar actividad

Generar guía de remisión

25



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



3.2 Realización de los casos de uso para el análisis

3.2.1 Diagrama de clases de análisis.


Asignar Incidencia

27



28



Consultar Incidencia

Registrar Actividad

29



30



Generar Nota de Pedido

Generar Guía de Remisión

31



Generar Reporte de Incidencia

Registro Solicitud de equipo

Generar Reporte de Actividades

32



33



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



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].


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.


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



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].


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



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.


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



3.2.3 Diagrama de interacción de los casos de uso especificados.


38



39



Registrar Actividad

40



Generar Guía de Remisión

41



42



43



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



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



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



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



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



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



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



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



52



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



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



CAPITULO 5 – Diseño detallado

5.1 Diagrama de la base de datos

55



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



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



Siglario

- UML: Unified Modeling Language.

- RUP: Rational Unified Process.

58



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

http://es.wikipedia.org/wiki/Lenguaje_Unificado_de_Modelado

http://www.google.com/

97167793 arquitectura-de-software

Education

Transcript of 97167793 arquitectura-de-software