97167793 arquitectura-de-software

Gestión de Incidencias
Versión: 1.2
Fecha:
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 u201020924
Huanco Flores, Pedro u201014197
Ccori Ugarte, Cristian u201100364
Monterrico, Viernes 13 de abril del 2012
1

Versión: 1.2
Fecha:
21/03/12
1. Resumen
2

Versión: 1.2
Fecha:
21/03/12
Índice de contenidos
1. 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

Versión: 1.2
Fecha:
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

Versión: 1.2
Fecha:
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

Versión: 1.2
Fecha:
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

GerenciaGeneral
Gerenciade
Administración
GerenciaComercial
EESS
Gereneciade
Operacionesy
Servicios
GerenciaIndustria
yMineria
Gerenciade
Servicio
ÁreadeTecnologías
delaInformacióny
Sistemas
CallCenter
TI yMMEE
ÁreaMecanica–
Electrónica
Áreade
Proyectos
Contabilidad Administración
Provincias
Caja Almacén
Ventas
Lima
Ventas
Provincia
Ventas
Corporativas
Versión: 1.2
Fecha:
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

Versión: 1.2
Fecha:
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

Versión: 1.2
Fecha:
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

Versión: 1.2
Fecha:
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

Versión: 1.2
Fecha:
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

Versión: 1.2
Fecha:
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

Versión: 1.2
Fecha:
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

Versión: 1.2
Fecha:
21/03/12
Diagrama de actores:
2.3.2 Diagrama de Paquetes.
14

Versión: 1.2
Fecha:
21/03/12
2.3.3 Diagrama de casos de uso por paquete.
Seguridad:
Mantenimiento:
15

Versión: 1.2
Fecha:
21/03/12
Gestión de Incidencias:
Logistica:
16

Versión: 1.2
Fecha:
21/03/12
Reportes:
17

Versión: 1.2
Fecha:
21/03/12
2.4 Especificación de casos de uso de alto nivel
Caso de uso: Registrar Incidencia
Actor(es): Asistente de Servicio Técnico
Propó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 asociado
Resumen: 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 incidencias
Actor(es): Supervisor TI
Propósito: Realizar asignación de incidencia a un Técnico de Sistemas
Caso 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 incidencia
Actor(es): Supervisor de TI, Técnico de Sistemas y Asistente de
Servicio Técnico
Propó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

Versión: 1.2
Fecha:
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.
Caso de uso: Registrar actividad
Actor(es): Técnico de sistemas
Propósito: Registrar las actividades desarrolladas por cada técnico
durante la resolución de alguna incidencia.
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 equipo
Actor(es): Técnico de Sistemas
Propósito: Realizar registro de solicitud de HW
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 pedido
Actor(es): Asistente de Servicio Técnico
Propósito: Gestionar la solicitud de hardware del técnico de sistemas
para que pueda atender alguna incidencia.
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

Versión: 1.2
Fecha:
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.
Caso de uso: Generar guía de remisión
Actor(es): Almacenero
Propósito: Crear la Guía de Remisión con la que se transporte los
requerimientos de hardware que se requiere para
solucionar una Incidencia.
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 actividades
Actor(es): Supervidor de TI
Propósito: Monitorear las actividades realizadas por cada técnico
respecto a las incidencias asignadas.
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 incidencias
Actor(es): Supervisor de TI
Propósito: Generar reportes mensuales de las incidencias reportadas
(atendidas, pendientes de atención).
Resumen: El caso de uso comienza cuando el Supervisor de TI desea
conocer el Reporte General de Incidencias. Se muestra la
20

Versión: 1.2
Fecha:
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.
Gestion de Seguridad:
Caso de uso: Iniciar sesión
Actor(es): Usuario
Propósito: Iniciar sesión en el sistema
Caso 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ña
Actor(es): Usuario
Propósito: Cambiar la contraseña para iniciar sesión
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 perfiles
Actor(es): Seguridad
Propósito: Mantener actualizados los datos de los perfiles utilizados en
el sistema
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

Versión: 1.2
Fecha:
21/03/12
Caso de uso: Realizar backup
Propósito: Realizar copia de respaldo del sistema
“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 acceso
Propósito: Registrar accesos de los usuarios al sistema
“Registrar acceso” según su requerimiento.
El caso de uso termina cuando el acceso del usuario al
sistema queda registrado.
Mantenimiento:
Caso de uso: Gestionar clientes
Actor(es): Administrador
Propósito: Realizar el mantenimiento de los clientes
Caso 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
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 servicio
Propósito: Realizar el registro de las estaciones de servicio
Caso de uso
asociado:
"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

Versión: 1.2
Fecha:
21/03/12
Caso de uso: Gestionar usuarios
Propósito: Realizar el mantenimiento de los usuarios
Caso de uso
asociado:
"Gestionar Usuarios" según su requerimiento, en esta se
actualización y eliminación de un usuario. El caso de uso
termina cuando se registra, actualiza o elimina un cliente.
23

Versión: 1.2
Fecha:
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
12. Gestionar
usuarios
13. Gestionar
perfiles
14. Registrar
acceso
Opcional Def Baja Ciclo 2
15. Iniciar sesión Opcional Def Baja Ciclo 2
16. Cambiar
contraseña
17. Realizar
backup
2.6 Lista de casos de uso que impactan en la arquitectura
24

Versión: 1.2
Fecha:
21/03/12
Nombre de casos de uso
 Registrar Incidencia
 Registrar actividad
 Generar guía de remisión
25

Versión: 1.2
Fecha:
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 Servicio
+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..*
Actividad
+codigo_incidencia
+codigo_tecnico
+problema
+trabajo_realizado
+fecha_inicio
+fecha_fin
Cliente
+codigo
+nombre
+razon_social
+direccion
+telefono
+contacto
1
1..*
26

Versión: 1.2
Fecha:
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

Versión: 1.2
Fecha:
21/03/12
28

Versión: 1.2
Fecha:
21/03/12
Consultar Incidencia
Registrar Actividad
29

Versión: 1.2
Fecha:
21/03/12
30

Versión: 1.2
Fecha:
21/03/12
Generar Nota de Pedido
Generar Guía de Remisión
31

Versión: 1.2
Fecha:
21/03/12
Generar Reporte de Incidencia
Registro Solicitud de equipo
Generar Reporte de Actividades
32

Versión: 1.2
Fecha:
21/03/12
33

Versión: 1.2
Fecha:
21/03/12
3.2.2 Especificación detallada o historias de usuario de los casos de
uso que impactan en la arquitectura.
Nombre del
caso de uso
CU01- Registrar Incidencia
Tipo Esencial y primario
Actores Asistente de Servicio Técnico
Descripció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ón
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.
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 Eventos
1.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

Versión: 1.2
Fecha:
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 alternativos
Flujo alternativo 1: Valida información ingresada
Si 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
Actores Técnico de sistemas
Descripció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.
35

Versión: 1.2
Fecha:
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 alternativos
Flujo 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 Solucionada
Si 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álida
Si 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
Actores Almacenero
Descripción El caso de uso comienza cuando el actor desea crear una Guía
36

Versión: 1.2
Fecha:
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ón
Reglas 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.
1.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

Versión: 1.2
Fecha:
21/03/12
3.2.3 Diagrama de interacción de los casos de uso especificados.
Registrar Incidencia
38

Versión: 1.2
Fecha:
21/03/12
39

Versión: 1.2
Fecha:
21/03/12
Registrar Actividad
40

Versión: 1.2
Fecha:
21/03/12
Generar Guía de Remisión
41

Versión: 1.2
Fecha:
21/03/12
42

Versión: 1.2
Fecha:
21/03/12
43

Versión: 1.2
Fecha:
21/03/12
3.3 Diagramas de máquinas de estado
DME-INCIDENCIA
Nuevo
entry/Ingresar informacion
Registrar incidencia en el sistema
En Atencion
Registrar Actividades
Solucionado
En Observacion
entry/Verifica tiempo reparacion
exit/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

Versión: 1.2
Fecha:
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

Versión: 1.2
Fecha:
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 Definiciones, 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

Versión: 1.2
Fecha:
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
Ingenieros
de Software
Rendimiento,
Disponibilidad,
Tolerancia a Fallas
Integradores
=VP + Escalabilidad,
Entrega e Instalación
Ingenieros
de Sistemas
Comprensión y Uso

Versión: 1.2
Fecha:
21/03/12
Los requerimientos no funcionales que constituyen las metas y restricciones
de la arquitectura son:
Requerimientos No Funcionales
Código Descripción
Requerimientos de Capacidad de Uso
RNF01 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 Confiabilidad
RNF04 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 Rendimiento
RNF08 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 Soporte
RNF10 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ño
RNF11 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ón
RNF12 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

Versión: 1.2
Fecha:
21/03/12
Requerimientos No Funcionales
Código Descripción
RNF15 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.
RNF01
RNF02
RNF05
 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

Versión: 1.2
Fecha:
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
RNF04
RNF06
RNF12
 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

Versión: 1.2
Fecha:
21/03/12
4.4 Vista de los casos de uso
4.4.1Diagrama de los casos de uso que impactan en la arquitectura
Generarguia
deremision
Registrar
incidencia
Registrar
actividad
TecnicodeSistemas
Almacenero
AsistentedeServicioTecnico
CasosdeUsoImpactanArquitectura
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

Versión: 1.2
Fecha:
21/03/12
52

Versión: 1.2
Fecha:
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

Versión: 1.2
Fecha:
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

Versión: 1.2
Fecha:
21/03/12
CAPITULO 5 – Diseño detallado
5.1 Diagrama de la base de datos
55

Versión: 1.2
Fecha:
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

Versión: 1.2
Fecha:
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

Versión: 1.2
Fecha:
21/03/12
Siglario
- UML: Unified Modeling Language.
- RUP: Rational Unified Process.
58

Versión: 1.2
Fecha:
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

97167793 arquitectura-de-software

Más contenido relacionado

La actualidad más candente

Similar a 97167793 arquitectura-de-software

Último

97167793 arquitectura-de-software