Uami10173 - 10 10 13

UNIDAD IZTAPALAPA CIENCIAS BASICAS E INGENIERIA
HELP DESK
Proyecto Terminal Licenciatura en Computacin Ingeniera Elctrica
Alumnas:
Alejandra Fernndez Vlez 94317776 Gisela Paredes Sandoval 94319416 Marivel Ortz Martnez
88223243
Asesor:
Albertina Gonzlez Mrquez
Para la obtencin del grado de licenciatura en Computacin Noviembre 2002
Help Desk
Licenciatura en Computacin CBI - Iztapalapa
CONTENIDO
Antecedentes Justificacin Estructura Objetivos
Objetivos Generales Objetivos Especficos
4 5 6 7
Marco Terico
Enfoque Orientado a Objetos Arquitectura de desarrollo Proceso de Ingeniera de software Orientada a Objetos Descripcin de procesos de Ingeniera de software Orientada a Objetos Proceso de Anlisis de Requerimientos Proceso de Anlisis Dinmico Proceso de Anlisis Proceso de Construccin Proceso de Pruebas Herramientas visuales Rational Rose Lenguaje Unificado de Modelado(UML) Power Builder Project
8 8 10 11 12
16
Desarrollo Prctico
Especificacin de Requerimientos Contexto del problema Niveles de usuarios Levantamiento de reportes Modificacin de reportes Consulta de reportes Conclusin de reportes Administracin de reportes Escalamiento de reportes Seguimiento de reportes Bitcora de cambios Acceso a las bitcoras Consultas Mantenimientos preventivos Captura de requerimientos como casos de uso Identificacin de actores y casos de uso Descripcin de actores y casos de uso
Help Desk Proyecto Terminal II
17 19
24
Help Desk
Modelo de Requerimientos Diagrama General de Casos Caso de uso: Control de Reportes Caso de uso: Administracin de Catlogos Modelo de Anlisis Diagrama de General de Clases Caso de uso: Levantamiento de reportes Caso de uso: Administracin de catlogos Modelo de Diseo Caso de uso: Levantamiento de reportes Caso de uso: Administracin de catlogos Modelo de Construccin Caso de uso: Levantamiento de reportes Caso de uso: Administracin de catlogos Caso de uso: Administracin de reportes
27
32
33
34
Conclusiones
35
Bibliografa
36
Anexos
Anexo A: Proceso Personal de Software (PSP) Anexo B: Descripcin de Clases
38 41
Help Desk
ANTECEDENTES
Help Desk forma parte de un proyecto general de Ingeniera de Software, el cual se desarrolla por un convenio entre la Universidad Autnoma Metropolitana, Unidad Iztapalapa y la empresa particular Grupo Yoli. Dicho convenio permitir incrementar los recursos de software y hardware en el Laboratorio de Ingeniera de Software (LIS) del Area de Computacin y Sistemas para beneficio de alumnos que se encuentran en la fase terminal de la Licenciatura en Computacin. En este laboratorio se desarrollan diversos proyectos enfocados al desarrollo de aplicaciones innovadoras, tales como el proyecto de Educacin a Distancia para la Divisin de Ciencias Sociales y Humanidades (CSH). Grupo Yoli es una empresa dedicada al embotellamiento y distribucin de Coca Cola, principalmente. Sus oficinas centrales se encuentran en Acapulco, Guerrero y es la encargada de distribuir el producto en todo el estado. Actualmente tiene tres centros de distribucin, stos son puntos forneos, razn por la cual resulta indispensable su enlace mediante un sistema de informacin, que le permita obtener los datos necesarios para la toma de decisiones en materia de administracin de recursos materiales, humanos y financieros. Es por esta razn que el proyecto consiste en el desarrollo de tres mdulos: Mdulo de atencin a usuarios (Help Desk) Mdulo de inventarios Mdulo de pronsticos de ventas
El presente trabajo se enfocar al desarrollo del Mdulo de atencin a usuarios, el cual permite automatizar los procesos de levantamiento, administracin y atencin de reportes de fallas en todo tipo de equipos con que cuenta la empresa, y notificar (automticamente) a los involucrados sobre cualquier cambio presentado en el estado de atencin al reporte. Dicho mdulo tiene interaccin con el mdulo de inventarios, siendo ste el sistema encargado de proporcionar a Help Desk la informacin referente a todos los equipos a los cuales se les otorga servicio. Help Desk es una herramienta que automatiza las tareas de atencin a usuarios llevadas a cabo principalmente por el rea de informtica, ayudando a agilizar los procesos de solucin de fallas y de determinacin de decisiones. Help Desk automatiza la definicin y resolucin de requerimientos de usuarios (problemas), proporcionando una estructura de fcil y preciso manejo de solicitudes cotidianas requeridas por tcnicos, usuarios y/o administradores. Help Desk permite: Optimizar la interaccin del usuario con el sistema Help Desk Automatizar el soporte del flujo de solicitudes. Simplificar la resolucin y gestin de problemas. Registrar, evaluar, investigar y resolver problemas relacionados a los requerimientos de los usuarios. Monitorear las acciones correctivas para asegurar que los problemas se resuelvan dentro de plazos de tiempo especificados. Monitorear el estado y responsabilidades individuales. Monitorear una base de datos histrica de problemas y soluciones.
Help Desk
JUSTIFICACIN
Nuestro inters se basa en la experiencia de participar en un proyecto real, con requerimientos y alcances reales, lo cual consideramos nos permite conocer de cerca el tipo de proyectos a los que nos enfrentaremos en el campo laboral. Esto nos obliga a poner en prctica una metodologa de vanguardia en la Ingeniera de Software, cumpliendo con las exigencias que en la actualidad se plantean en el desarrollo de sistemas: eficiencia y calidad de los productos generados; siendo el anlisis y diseo, las etapas de la metodologa que ms influyen en dichas caractersticas y que determinan la estructura del sistema. Tambin nos es muy grato poder participar en un proyecto que no slo nos aportar experiencia y conocimientos en el desarrollo de sistemas de informacin, sino que adems nos permitir colaborar en el mejoramiento de la infraestructura y darlo a conocer como una entidad que ofrece soluciones en sistemas de software poniendo en prctica muchos de los conocimientos adquiridos en nuestro desarrollo dentro de la licenciatura.
Help Desk
ESTRUCTURA
El presente trabajo da una visin general del desarrollo del proyecto, presentando de manera ordenada y breve los puntos ms importantes en los cuales consiste el desarrollo del sistema. Hemos estructurado el contenido de este trabajo de la siguiente manera: Objetivos: Plantean de manera clara y precisa las metas generales y especficas que se han pretendido alcanzar en el desarrollo de este proyecto. Marco terico: Hace una breve descripcin de la metodologa, tcnicas y herramientas empleadas en el anlisis y diseo del proyecto. Desarrollo prctico: Este es uno de los apartados ms importantes, contempla cada una de las etapas que se llevan a cabo para el desarrollo del proyecto de Help Desk. Consiste en una descripcin detallada, basada en los diagramas que contempla la metodologa para cada seccin del sistema. Esta parte es complementada con las distintas versiones de los prototipos realizados para este proyecto. En la parte final de nuestro trabajo mencionamos algunas conclusiones basadas en la experiencia de participar en este proyecto y los resultados obtenidos al trmino de la etapa que nos correspondi desarrollar. Tambin se incluyen dos anexos, los cuales consideramos sern de utilidad para el lector interesado en este trabajo.
Help Desk
OBJETIVOS
Mdulo de atencin a usuarios de informtica (Help Desk)
OBJETIVOS GENERALES
El proyecto de Help Desk ser una herramienta que permita: Registrar de manera oportuna y eficiente los reportes de atencin a usuarios que reciba el sistema. Administrar y dar seguimiento a cada reporte registrado hasta su conclusin de una manera oportuna y eficiente. Notificar a los usuarios sobre la atencin que se le esta dando al reporte. Generar informacin que facilite la toma de decisiones. Proporcionar una fcil interfaz con los otros mdulos del Sistema de Informacin del Grupo Yoli. Facilitar su mantenimiento con respecto a cambios en requerimientos y correccin de errores no detectados en fases previas a su utilizacin.
OBJETOS ESPECFICOS
El proyecto de Help Desk cubre los siguientes aspectos: Caracterizar las fallas y sus categoras. Registrar los reportes de usuarios. Relacionar a los usuarios incluidos en un reporte con los equipos o conjuntos de equipos relacionados. Registrar las acciones necesarias para cubrir los reportes Asignar las acciones que los asesores deben llevar cabo para atender los reportes. Registrar resultados de las acciones realizadas. Reasignar actividades a otros asesores. Comunicar a los usuarios cada evento que afecte la atencin de su reporte. Configurar el tipo de notificaciones que deseen recibir los usuarios con respecto a la atencin del reporte. Generar reportes de atencin de usuarios. Registrar encuestas sobre la calidad del servicio.
Help Desk
MARCO TERICO
En este captulo se presenta un panorama general sobre la metodologa, tcnicas y herramientas utilizadas en el anlisis y diseo de este proyecto. En el anlisis y diseo de orientado objetos existen una gran variedad de mtodos que comparten aspectos comunes de arquitectura. Dichos puntos son los procesos definidos por los mtodos y las herramientas utilizadas para el anlisis y diseo; destacando como uno de los rasgos importantes la notacin empleada pues es un estndar con el cual se pretende tener menos variaciones entre las herramientas.
ENFOQUE ORIENTADO A OBJETOS

El Enfoque Orientado a Objetos es una forma de observar la realidad, de tal manera que la estructura de solucin a un problema se basa principalmente, y como su nombre lo dice, en el concepto de objeto. La estructura de los sistemas desarrollados bajo este esquema se dice entonces que es centrada en la informacin. Un objeto es todo aquello que sea nico y que pueda distinguirse dentro del universo de la aplicacin. Todos los objetos tienen propiedades o estados y la nica forma de afectar esas propiedades es a travs de los comportamientos o mtodos que exhibe el objeto. Dado que al establecer objetos se encontrarn algunos casos que se parecern mucho, por compartir la misma definicin de caractersticas, se determina que esos objetos son realizados por un mismo molde o plantilla, denominada clase. Tal concepto establece tanto las propiedades como los mtodos comunes a todos los objetos que se generen a partir de este. Adems, tambin permite que sea posible asignarle una propiedad a un conjunto de objetos, lo cual simplifica su control y administracin. Dentro de este enfoque, todos los objetos son generados a partir de clases y por lo tanto todo objeto esta asociado a la clase de la que se gener. As pues, a cada objeto generado se le dice que es una instancia de la clase y tendr propiedades y mtodos indicados en la clase, de tal forma que cada instancia tendr valores diferentes. Los objetos tienen una conceptualizacin interesante, solo toma importancia lo que estos puedan realizar y no cmo lo hagan, y menos an, cmo estn constituidos en su interior. A esta propiedad se le conoce como encapsulamiento, que aunada a la modularidad del sistema permite detectar errores con ms facilidad, accediendo a puntos especficos del cdigo. El encapsulamiento contempla lo que otros objetos pueden ver de un objeto dado, por consiguiente, un objeto puede tener los siguientes tipos de visibilidad: Visibilidad Pblica: cualquier funcin de cualquier objeto del sistema puede hacer referencia a la propiedad/funcin de otro objeto. Visibilidad Privada: solamente el objeto mismo puede hacer referencia tanto a las propiedades como a los mtodos. Visibilidad Amiga: solo algunos objetos estn autorizados para hacer referencia a
propiedades o mtodos de un objeto. Visibilidad por Herencia: los objetos que heredan pueden hacer referencia tanto a propiedades como mtodos de la clase padre.
Help Desk
Otros de los aspectos que se presentan en este enfoque es el polimorfismo, consistente en que un objeto utiliza el mtodo de otro objeto sin que ste se tenga que preocupar por la naturaleza del objeto dueo del mtodo. Por otra parte, en la herencia las subclases toman definiciones de la clase principal, caracterstica asociada con la Generalizacin-Especializacin, en donde se establece cierta clase de objetos que puede tener todas las propiedades de la clase genrica, y modificar la funcionalidad heredada o agregar nueva funcionalidad. Este ltimo es un mecanismo que asegura la reutilizacin de componentes. Dentro de la jerarqua de herencia, a las clases que generan directamente objetos se les llama clases concretas, mientras que a las que no generan directamente ningn objeto se les llaman clases abstractas. La herencia se puede dar en estructuras que contemplan varios niveles, proyectando as mismo en cada nivel tal concepto. Dado que no existe un lmite con respecto al nmero de niveles que se pueden tener, tampoco existen limitaciones conceptuales para impedir que hayan especializaciones mltiples. Una especializacin es mltiple cuando una clase puede ser una subclase de dos clases o ms al mismo tiempo. Este tipo de herencia es poco utilizado debido a que puede perderse el control acerca de los atributos que se manejan. La herencia tambin est asociada con la caracterstica de agregacin, explicada ms adelante. Los objetos se relacionan con otros objetos de diferentes formas. Una de las ms frecuentes es a travs de asociaciones estticas, representan un tipo de vnculo entre dos objetos y tiene como caracterstica que su tiempo de duracin es mayor al tiempo que tarda en ejecutarse el cdigo que los vincula. Este tipo de relaciones es de gran utilidad, pues permite la estructuracin de los objetos incorporando reglas de negocio. Adems, se tienen que especificar los niveles mximos y mnimos de vinculacin entre los distintos objetos, denominndosele a esto el termino multiplicidad de la asociacin. La multiplicidad ayuda a validar los requerimientos con los usuarios y hace mas claras las situaciones de ambigedad. Un caso particular de una asociacin esttica, es cuando un objeto no solo esta asociado con otro, sino que adems uno es parte del otro, llamndosele a esta situacin asociacin de agregacin y puede ser establecida por dos tipos: Asociacin por composicin: los objetos y la asociacin se dan simultneamente y por lo tanto, cuando desaparece uno el otro tambin lo hace. Asociacin simple: los objetos pueden crearse en tiempos distintos y la asociacin se da en cualquier momento despus de que existen los dos. Una manera de determinar el tipo de agregacin es revisar la multiplicidad de la asociacin. Si se tiene una multiplicidad de uno a muchos, lo ms seguro es que se tenga agregacin simple, mientras que si se tiene multiplicidad de uno a uno entonces se puede asegurar que existe una agregacin de composicin; significando esto ltimo que el objeto con el que se est relacionado podra ser atributo de la clase.
Help Desk
ARQUITECTURA DEL DESARROLLO

Un factor clave en un sistema de software es su estructura interna. Una buena estructura hace que el sistema sea fcil de comprender, modificar, probar y mantener. La arquitectura de desarrollo debe indicar la filosofa de trabajo; los mtodos, procesos y herramientas que sern utilizados en el desarrollo del sistema, que es representado por la Fig. 3.1.
Herramientas Procesos Mtodo Arquitectura Fig. 1 Componentes de la filosofa de desarrollo.
Un mtodo es un procedimiento planificado por medio del cual se alcanza, paso a paso, un objetivo especfico. Un proceso es la generalizacin de un mtodo. Las herramientas se usan para automatizar un gran nmero de tareas, principalmente aquellas triviales de gran volumen. La arquitectura de desarrollo de software utilizado en el enfoque orientado a objetos es el ciclo de software en espiral. Plantea la forma de trabajo mediante el desarrollo de prototipos, que consiste en tener una serie de versiones a partir de las cuales, la ltima versin ser la que se apegue a los requerimientos del sistema, esto lo muestra la Fig. 3.2. Cada versin ir constituyendo un prototipo del sistema e ir incorporando mayor funcionalidad a ste, consiguiendo adems que el desarrollo de software sea iterativo e incremental. Esta forma de desarrollo de software tiene la ventaja de lograr retroalimentacin entre los desarrolladores y los usuarios potenciales del sistema y disminuir el riesgo (la diferencia entre lo que el usuario espera recibir y lo que se le entrega).
Versin 0 Especificacin Inicial Anlisis Inicial Versin 0.1 Ajustes a la Especificacin Anlisis ... Versin 1 Ajustes a la Especificacin Anlisis
Diseo
Diseo
Diseo
Programacin
Programacin
Programacin
Pruebas Previas a Implantacin
Aceptacin o Rechazo
Aceptacin o Rechazo
...
Aceptacin o Rechazo
Modelo de Generacin de Prototipos
Implantacin
Fig. 2
10
Help Desk
PROCESO DE LA INGENIERA DE SOFTWARE ORIENTADA A OBJETOS

La metodologa de Jacobson se destaca dentro de la Ingeniera de Software Orientada a Objetos (ISOO). Esta metodologa se caracteriza por el levantamiento de requerimientos en el
mbito del usuario, lo cual elimina el problema de una mala especificacin y disminuye en gran parte el riesgo. Esta metodologa como todas las orientadas a objetos se crea a partir de la programacin orientada a objetos, cuando se le incorpora el modelo conceptual y el diseo por bloques.
La fase de levantamiento de requerimientos es la base de las actividades que se involucran en el proceso de desarrollo de software. Los procesos se centran en la elaboracin de modelos del sistema y cada modelo es una forma de visualizar el sistema en distintos momentos del desarrollo y desde distintos puntos de vista. Cada modelo es una descripcin de aspectos relevantes para cada proceso del desarrollo. La ISOO integra los siguientes procesos.
Requerimientos del Usuario Modelo Anlisis Dinmico Proceso de Anlisis
Modelo de Anlisis
Modelo de Requerimientos
Proceso de Construccin
Modelo de Diseo
Modelo de Implantacin
Proceso de Pruebas
Modelo de Pruebas Fig. 3 Procesos de la ISOO
Los valos en la figura se refieren a los procesos, los rectngulos se refieren a los modelos que se generan. Principalmente, se destaca el Modelo de Requerimientos, porque que sirve como entrada para los dems procesos.
Requerimientos del usuario: Es toda aquella informacin escrita, verbal o de cualquier ndole Modelo de Requerimientos: Especifica los requerimientos ms relevantes del sistema. Modelo de Anlisis: Plantea las interacciones bsicas de los objetos que constituirn al sistema. Modelo de Diseo: Plantea en detalle la interaccin de los objetos, incorporando restricciones Modelo de Construccin: Describe la organizacin modular de los componentes del sistema, as
como su implantacin en un lenguaje de programacin. fsicas de la plataforma o bien de los requerimientos. que el usuario hace disponible al equipo de desarrollo.
Los procesos involucrados y modelos generados se describen a continuacin:
11
Help Desk
Modelo de Pruebas:
Establece la estrategia de pruebas de cada elemento del sistema desde un nivel muy particular hasta un nivel muy general de la integracin de los componentes.
DESCRIPCIN DE LOS PROCESOS DE LA INGENIERA DE SOFTWARE ORIENTADA A OBJETOS

Como ya se mencion en la seccin anterior, el desarrollo de la metodologa de ISOO genera distintos procesos y modelos, los cuales trataremos con mayor detalle en esta seccin. El Proceso de anlisis, distingue dos procesos principalmente: Proceso de anlisis de requerimientos y Proceso de anlisis dinmico, representado en la siguiente figura.
Requerimientos de usuario
Proceso de Anlisis de requerimientos Proceso de Anlisis Proceso de Anlisis dinmico
Modelo de Requerimientos Modelo de Anlisis Modelo de Anlisis Dinmico
Fig. 4 Proceso de Anlisis
Proceso de Anlisis de Requerimientos

En este proceso se recolectan todos los requerimientos del usuario, que son aquellas necesidades o problemas que el usuario presenta. Se unifican generando una especificacin bajo ciertos formatos estndares que garanticen que todo el equipo de desarrollo pueda manejar y entender los requerimientos. El proceso de anlisis de requerimientos genera el modelo de requerimientos, representado por tres submodelos: Modelo de casos de uso Modelo de interfaz Modelo del dominio del problema
El Modelo de casos de uso describe el comportamiento funcional del sistema desde el punto de vista del usuario y los procesos ms importantes que constituirn la funcin del sistema. Un caso de uso es una transaccin que se tiene con el sistema, es decir, algo mediante el cual el sistema va a responder de alguna manera. Dentro de este modelo se define un actor, como el elemento externo que interacta con el sistema. Un actor puede ser una persona y tambin puede ser un sistema. Cada caso de uso se compone de una serie de pasos que describe detalladamente la funcionalidad del caso de uso y que son representados mediante un diagrama de casos de uso.
12
Help Desk
El Modelo de Interfaz describe la forma en que el usuario interacta con el sistema. Se representa con un diagrama de estados o pantallas de interfaz entre el sistema y el usuario. El Modelo del Dominio del Problema permite identificar los objetos que constituirn al sistema y las relaciones que tienen entre s. Se utilizan los diagramas de clases que representan la descripcin esttica del sistema. La forma en que se obtiene el diagrama de clases sigue una serie de pasos que se deben llevar a cabo: Identificacin de las clases. Se obtiene seleccionando todos los componentes sustantivos que se encuentran en las estructuras gramaticales del texto que describe en forma genrica el caso normal del caso de uso. Identificacin de atributos bsicos de cada clase. Caractersticas que presentan los objetos. Identificacin de los atributos candidatos para ser llaves relacionales. Son los atributos que constituirn la llave relacional dentro de una base de datos. Identificacin de asociaciones estticas entre clases. Son los vnculos vlidos que cada una de las clases tiene con las dems. Identificacin de la multiplicidad o cardinalidad de las asociaciones. Esto indica las reglas de negocio que la informacin debe cumplir en todo momento para que se guarde la integridad entre los distintos elementos que la componen. Ajuste del modelo de clases. Reemplazar las asociaciones que impliquen los siguientes casos: multiplicidad uno a uno o multiplicidad de muchos a muchos, por asociaciones de uno a muchos. Identificacin de asociaciones de agregacin y/o composicin. Consiste en detectar asociaciones estticas en las que se est caracterizando el todo y sus partes. Esto es una forma de modelar clases que deben ser en realidad atributos de otras clases. Identificacin de los mtodos bsicos de las clases. Consiste en sealar los mtodos que tendrn cada una de las clases, tales como constructores, destructores y otros mtodos que tengan que ver con la interaccin dinmica entre tablas. Identificacin de las estructuras de Generalizacin-Especializacin o de Herencia. La determinacin de estructuras de este tipo no se da en el primer ciclo de anlisis, sino que avanza conforme se establezcan especializaciones sobre los conceptos originales, o bien conceptos ms generales que se generen a partir de los conceptos ya identificados. Determinacin de los niveles de visibilidad de los atributos y mtodos. Consiste en establecer qu tanto se pueden compartir los distintos elementos del modelo. Identificacin de los atributos secundarios. La incorporacin de nuevos atributos est en funcin de la especializacin que se vaya teniendo en los casos y en la estabilidad lograda a lo largo del proceso de requerimientos.
Proceso de Anlisis Dinmico

El Modelo de requerimientos establece el comportamiento externo del sistema a travs de la definicin de las transacciones, identificando con elementos visuales los objetos y sus interacciones. Una vez logrado un equilibrio en este modelo continua el modelo de anlisis. En un nivel conceptual amplio todos los objetos son iguales, sin embargo, pueden establecerse ciertas funciones especficas a los objetos que componen un programa y por lo mismo
Modelo de Anlisis
13
Help Desk
pueden establecerse categoras para los objetos que componen un programa. Estas categoras permiten mejorar los aspectos de calidad interna de los componentes de los programas pues exhiben mejores niveles de cohesin y acoplamiento que son elementos con los que se evala la calidad de un sistema. Distinguen principalmente tres categoras: Objetos de interfaz: Su especializacin es la interaccin con los actores, de tal manera que presentan informacin en formatos cercanos al actor y/o permiten la adquisicin de informacin del actor hacia el sistema realizando las conversiones en formato necesarias. Estos objetos no tratan con aspectos de la aplicacin, tales como reglas del negocio o algoritmos. Objetos de negocio: Estos objetos estn especializados en los servicios referentes a la lgica de la aplicacin y reglas del negocio que tiene que seguirse para la realizacin de la funcionalidad del programa. Estos objetos no tratan con aspectos de interfaz, con los actores ni con las fuentes de datos o de informacin. Objetos de datos: Estos objetos son de servicio, de tal manera que sus decisiones slo se restringen a la forma en que se consultarn o enviarn datos a las fuentes de datos.
Modelo de tres capas Cuando un modelo se estructura bajo la categorizacin anterior se le conoce como Modelo de tres capas (Three tier). Este modelo permite estructurar los programas para lograr la
modularidad reflejndose en la fase de mantenimiento, esto es, si cambia la plataforma de la capa de interfaz, solo ser necesario reescribir los objetos de esa capa para poder darle mantenimiento al sistema. De igual forma, si se cambian las fuentes de datos a las que accede el sistema, nicamente es necesario reescribir los mtodos de los objetos de esa capa para el mantenimiento del programa. Lo anterior cumple cuando se trata de cambios adicionales en los requerimientos funcionales, afecta a los objetos de negocio correspondientes.
Proceso de Anlisis
El proceso de anlisis involucra los procesos anteriores para identificar la categora de los objetos dinmicos del sistema y las relaciones dinmicas que guardan entre s. El proceso establece los objetos dinmicos, su tipo, las relaciones que guardan entre s y las clases de donde se originan. Cmo se estn describiendo objetos dinmicos, se est viendo al sistema a tiempo de ejecucin, lo que implica que es necesario establecer un escenario en ejecucin para el sistema. Un escenario es una instancia de un caso, de tal manera que sigue todos los pasos descritos por el caso de uso, con valores reales de los intercambios de informacin entre el actor y el programa. Los diagramas de colaboracin son ideales para documentar el proceso de anlisis, representando una descripcin grfica de los objetos dinmicos y sus relaciones. Los pasos involucrados en el proceso de anlisis son: Definicin detallada de los escenarios. Identificacin de objetos de interfaz, objetos de negocio y objetos de datos. Realizacin de diagramas de colaboracin. Construccin del modelo de clases dinmicas.
14
Help Desk
El proceso de construccin consiste en detallar el modelo de anlisis dinmico considerando aspectos de implantacin, adems de establecer la estructura de distribucin de los objetos que estarn componiendo al sistema. La estructura de procesos se muestra en la siguiente figura.
Proceso de Diseo Modelo de Diseo Modelo de Componentes Cdigo Fuente de programas
Modelo de Requerimientos
Proceso de Anlisis de Componentes Modelo de Anlisis Dinmico Proceso de Programacin
Modelo de Anlisis
Fig. 5 Proceso de Construccin
Modelo de Construccin
En la figura anterior se observa que el proceso de construccin se alimenta del modelo de anlisis y que est constituido por tres procesos elementales: el proceso de diseo en donde se afina el modelo de anlisis dinmico para dejar un modelo sensible a la implantacin, el proceso de anlisis de componentes donde se identifican agrupamientos de objetos conocidos como componentes de programacin y el proceso que consiste en la programacin de los mtodos de las clases.
Proceso de Pruebas
En la metodologa se emplea prototipos que incrementan la funcionalidad del sistema hasta llegar al producto final. El proceso de pruebas consiste en desarrollar un plan para la revisin de los puntos que determinan el avance del sistema sobre el prototipo que se ha desarrollado, es decir, establece la estrategia de pruebas de cada elemento del sistema, desde un nivel particular hasta uno muy general. Este proceso incluye revisiones y corridas a mano. En resumen, el proceso de pruebas tiene como objetivos principales: Integrar y probar el cdigo desarrollado con el resto del sistema (las entregas previas) Registrar y revisar los resultados de las pruebas. Evaluar los resultados de las pruebas con respecto a los criterios de evaluacin.
15
Help Desk
HERRAMIENTAS VISUALES
Una de las funciones principales que tienen las herramientas es la de apoyar el desarrollo de los sistemas de software. Tres de las que fueron utilizadas en el desarrollo del proyecto son las que a continuacin se mencionan.
Rational Rose
Rational Rose es una herramienta CASE que permite utilizar UML como notacin, permite llevar a cabo el modelado del sistema bajo una arquitectura modelo-diagrama y proporciona soporte para dos elementos esenciales de la moderna Ingeniera de Software: desarrollo basado en componentes y desarrollo iterativo controlado. Mientras que estos aspectos son conceptualmente independientes, su uso en combinacin son ambos naturales y benficos.
Lenguaje Unificado de Modelado (UML)

UML es una notacin estndar para la visualizacin, especificacin, construccin y documentacin de elementos de un sistema, puede utilizarse por todo proceso a lo largo del ciclo de vida del desarrollo y con diferentes tecnologas de implantacin. Apoya los procesos de anlisis, diseo, construccin y pruebas. Adems, permite construir modelos a partir de conceptos planteados en las metodologas orientadas a objetos tales como clases, interfaces, colaboraciones, componentes, generalizaciones y asociaciones. Adems de incorporar lo mejor de: Conceptos de modelado de datos (Diagramas E-R) Modelado de negocio (Work flow) Modelado de objetos y de componentes
Power Builder
Power Builder es una herramienta con un entorno de programacin visual orientado a objetos que dispone de caractersticas importantes tales como herencia, sobrecarga de funciones, polimorfismo, as como ocultacin de informacin y encapsulacin. Adems, permite la utilizacin de desarrollo iterativo o por fases, por medio de la cual se disea y se construye una aplicacin gradualmente en cada paso logrando crear la aplicacin en fases reducidas desde el principio hasta el fin; mientras se prueba y realiza una fase, la fase siguiente empieza.
Project
Project es una herramienta orientada a la administracin de proyectos. Permite llevar a cabo tanto la organizacin como el control y seguimiento de los proyectos. Mediante este programa es posible definir tareas y sus responsables as como los tiempos o plazos estimados de ejecucin para las mismas, aspectos de lo ms indispensables en la planeacin de proyectos.
16
Help Desk
DESARROLLO PRCTICO
En este captulo se describe paso a paso el desarrollo del sistema siguiendo la metodologa descrita en el marco terico. El trabajo realizado corresponde a desarrollar los dos primeros puntos del sistema que se listan a continuacin: Control de reportes Administracin de catlogos Administracin de reportes Consultas Administracin de cambios El seguimiento y desarrollo del resto del sistema ser retomado por un nuevo equipo. Inicialmente, la planeacin del proyecto es uno de los aspectos ms importantes a considerar en el desarrollo de cualquier proyecto. Consiste en registrar todos los procesos o tareas involucrados, dependencias entre estos, as como el tiempo estimado en realizarlos, registrando tambin las personas encargadas de esos mismos. El siguiente diagrama representa el plan de trabajo a llevar durante el desarrollo del proyecto.
Id 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 Actividad Mdulo de HelpDesk Anlisis de Requerimientos Prototipo 1 Ajustes al Modelo de Requerimientos Anlisis y Diseo Construccin del Prototipo Pruebas Unitarias Pruebas del Prototipo Evaluacin del Prototipo Prototipo 2 Ajustes al Modelo de Requerimientos Anlisis y Diseo Construccin del Prototipo Pruebas Unitarias Pruebas del Prototipo Evaluacin del Prototipo Prototipo 3 Ajustes al Modelo de Requerimientos Anlisis y Diseo Construccin del Prototipo Pruebas Unitarias Pruebas del Prototipo Evaluacin del Prototipo Prototipo Final Ajustes al Modelo de Requerimientos Anlisis y Diseo Construccin del Prototipo Pruebas Unitarias Pruebas del Prototipo Evaluacin del P t ti Elaboracin de Documentacin de usuario ndice Manual de instalacin Manual de usuario Revisiones Entrega de la Documentacin P1,P2 P1,P2 P1,P2 P1,P2 P1,P2 P1,P2 P1,P2 P1,P2 P1,P2 P1,P2 P1,P2 P1,P2 P1,P2 P1,P2 P1,P2 P1,P2 P1,P2 P1,P2 P1,P2 P1,P2 P1,P2 P1,P2 P1,P2 P1,P2 ptiembre octubre noviembre diciembre enero 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 1 2 P1,P2 3 4 febrero 5 6 7 8 marzo abril 9 10 11 12 13 14 15 16
Fig. 6 Planeacin del Proyecto Help Desk Proyecto Terminal II
17
Help Desk
Este diagrama contempla como primer punto el Anlisis de Requerimientos, el cual define la informacin que debe ser utilizada como base del anlisis y construccin de las etapas de que consiste cada Prototipo, esto se puede ver del lado izquierdo del diagrama. En la parte superior del lado derecho, se puede ver la fecha en que inicia y termina el proyecto, as como cada actividad en particular; adems tambin se puede observar la dependencia entre las tareas y su orden de ejecucin. Dentro del plan de trabajo se tiene considerado que los prototipos 1 y 2 incluyan los mdulos correspondientes a Control de reportes y Administracin de catlogos, realizando las respectivas actividades definidas en el plan de trabajo y que se detallan posteriormente dentro de este documento. Es importante sealar ..... que quienes continen el desarrollo del sistema Help Desk habrn de partir de la documentacin que aqu se incluye como complemento de informacin, as como un disco con los archivos del ltimo prototipo entregado, la aplicacin en Power Builder 7.1 y el archivo del anlisis y diseo del sistema.
18
Help Desk
ESPECIFICACIN DE REQUERIMIENTOS
Esta seccin describe los requerimientos del usuario presentados al equipo de desarrollo del sistema Help Desk por el lder de proyecto, quien se encarg de levantar los requerimientos directamente del usuario para los tres mdulos del proyecto.
Contexto del problema

El proyecto consiste bsicamente en llevar a cabo el manejo de reportes, administracin y consultas de reportes as como la administracin de catlogos requeridos por el sistema. El manejo de reportes contempla que en un principio se pueda registrar el reporte en todas sus caractersticas e identificar perfectamente al usuario y equipo que se est reportando con una situacin tcnica que no le permita al usuario desarrollar su trabajo. Tambin se requieren operaciones que permitan la modificacin de datos de reporte, consultas a reportes as como de la operacin que permita concluir reportes, indicando que la atencin de los reportes ha llegado a su etapa final. La administracin de los catlogos consiste en todas aquellos elementos que se requieren para el adecuado funcionamiento del sistema. La administracin de los reportes esta orientada especficamente a dar seguimiento referente a la atencin de reportes; permitiendo administrar en su totalidad las actividades que se han estado realizando para atender los reportes. Adems, controlar el estado de los reportes en cada una de las actividades llevadas a cabo, lo que permitir hacer notificaciones a los usuarios con respecto al avance que tiene su reporte. Las consultas permitirn en un momento dado, la toma de decisiones con respecto al desarrollo de la empresa.
Niveles de Usuarios
Principalmente se consideran los papeles de los usuarios que estarn relacionados con el sistema, los cuales son los siguientes: Administrador: Help Desk: Asesor: Usuario final: Gerente: Define nuevas categoras de fallas y en general le da mantenimiento a los catlogos. Registra los datos del problema tcnico que presenta el usuario. Tiene asignados los reportes de los usuarios, los atiende, les da seguimiento y los soluciona, agregando la solucin a la base de conocimiento de soluciones. Indica el problema que se le presenta y puede levantar su reporte directamente en el sistema. Consulta los indicadores de incidencia y atencin de reportes para influir en la toma de decisiones.
19
Help Desk
Control de Reportes
Agregar/Levantamiento del Reporte Consiste bsicamente en registrar el reporte dentro del sistema y podr llevarse a cabo de dos maneras: Por registro del Help Desk, va telefnica. Directamente por el usuario, a travs de la intranet.
El primer punto considera que Help Desk se encargue de solicitar los datos necesarios para caracterizar el reporte. Para esto, es importante saber nombre del usuario y clave de equipo que presenta el problema tcnico indicando el tipo del reporte, as como las descripciones que detallaran el problema y tambin el impacto y prioridad que tendr asociado. Adems debe contemplar la opcin de que el usuario pueda configurar el tipo de notificaciones que desea recibir acerca de la atencin que se dar al reporte. Una vez que se registra el reporte tendr como estado inicial el valor de Pendiente de atender, ser generada una primera accin a realizar y ser asignado automticamente un asesor el cual estar inicialmente a cargo del reporte. La asignacin se basar en la calificacin de su especializacin (excelente, bueno, regular, malo) y a la disponibilidad que tenga en un momento dado. Modificacin del reporte Esta operacin permite realizar los cambios necesarios para tener un registro actualizado del reporte. Consulta del reporte Operacin que esta relacionada con la consulta de los datos de registro de un reporte y de su estado en un momento dado. Conclusin del reporte Una vez que el usuario encontr una solucin satisfactoria, debe indicrselo al sistema directamente o por va telefnica. Adems se solicitaran los comentarios del usuario con respecto a la calidad del servicio que recibi.
Administracin de Reportes
Se refiere al proceso que sigue un reporte desde el momento en que es registrado dentro del sistema Help Desk hasta que es eliminado de la bitcora de reportes ya resueltos. La especificacin de requerimientos para la administracin de un reporte est organizada en cinco puntos principales: Atencin de un reporte Conclusin de una accin Cierre de un reporte Notificacin de cambios de estado del reporte Reasignacin de acciones
20
Help Desk
Atencin de un reporte El Asesor asignado a la primera Accin de un Reporte debe indicar que est comenzando a atenderla, en este momento el estado del reporte y el estado de la accin deben cambiar a En Proceso. En este momento indicar la opcin de solucin que piensa realizar y el nmero de horas que planea utilizar en desarrollar la accin. Cuando el Asesor hace la atencin del Reporte realizando la Evaluacin, detecta los problemas asociados y los registra de forma que incluya categora (descripcin del sistema), subcategora (descripcin del subsistema), subsubcategora (descripcin de la falla) y descripcin del problema. Cada problema identificado debe tener una o varias acciones asociadas para su solucin, las cuales sern determinadas por el propio asesor despus de haber realizado la evaluacin del problema, registrando dichas acciones en el sistema de la forma indicada anteriormente. Cada Accin se asigna automticamente al mismo Asesor, pero este puede reasignarlas a otro Asesor. Las acciones y los problemas tendrn en este momento el estado de Pendiente de atender. Las acciones son atendidas por los asesores y stos cuando las comienzan a realizar deben indicar el nmero de minutos que planean emplear y entonces las acciones cambian su estado a En Proceso. Conclusin de una accin
dedicado a realizar la accin y en qu porcentaje la accin resolvi el problema asociado. Cierre de un reporte
Porcentaje de Avance. Si el porcentaje de avance es el 100% el Asesor debe indicar el tiempo real
El Asesor puede indicar el avance que tiene la realizacin de una Accin a travs de un
El usuario ligado al Reporte una vez que se encontr una solucin satisfactoria debe dar su visto bueno directamente a tal solucin a travs del sistema o del actor Help Desk, y en ese momento el estado del reporte debe cambiar a Cerrado. En esta opcin se recogern los comentarios (catlogo de preguntas) del usuario con respecto a la calidad del servicio que percibi. Tambin el actor Help Desk puede cerrar reportes indicando las consideraciones (tiempo transcurrido del reporte en estado de Terminado) realizadas para cerrar el reporte. Para el cierre de reporte Help Desk toma en cuenta que todos los problemas estn concluidos (un problema est concluido cuando tiene asociado un porcentaje de resolucin de 100 %), en ese momento el Reporte debe pasar a estado de Terminado y entonces el actor Help Desk tiene la posibilidad de cambiar el estado del reporte a Cerrado. Notificacin de cambios de estado del reporte Con el levantamiento de un reporte puede configurarse a quin deben notificrsele los cambios de estado, preestableciendo notificaciones por usuario, tipo de falla, equipo y valor del estado.
21
Help Desk
Puede haber varios usuarios a quin notificar, as como varios tipos de notificaciones (por falla, por equipo, por cambio de estado) para cada actor involucrado. Esto depende de la configuracin que realice el usuario al levantar el reporte. Se debe notificar al usuario del reporte cada vez que hay un cambio en el estado. El usuario puede configurar sobre qu cambios de estado desea recibir la notificacin. Por otro lado, el asesor debe ser notificado de cualquier asignacin o cambio de asignacin que lo involucre. Reasignacin de acciones La asignacin primaria de acciones debe ser automtica, es decir, ninguna accin estar sin asignacin de asesor. Las acciones de un reporte pueden reasignarse a otro asesor de manera manual por el asesor que est asignado a la accin o bien por el Help Desk. Este ltimo har la reasignacin manualmente cuando un asesor no pueda cumplirla.
Escalamiento de Reportes
Un reporte ser escalado en su prioridad con base al tiempo pendiente de resolucin y complejidad. La escala de prioridad se piensa sea del 1 al 10, tomando como valor por default la ms baja (0,cero) sin embargo por el momento se considerar solo los tipos de prioridades: baja o alta. Posteriormente el administrador podr asignar un nuevo valor de prioridad basado en el usuario del equipo y en lo ya mencionado. El tiempo mximo de atencin de un reporte ser de 99 das.
Seguimiento de Reportes
Deben existir mecanismos para darle seguimiento a un reporte para todos los actores. Puede considerarse que en el caso del Administrador ser el Gerente el que haga el seguimiento de los reportes, por lo cual el Administrador no tendr acceso a consultas de seguimiento de reportes.
Bitcora de Cambios
Todo cambio en un reporte debe estar registrado en una bitcora. El cambio registrado en la bitcora debe contener nombre del usuario que modific el reporte, fecha y hora, identificador de reporte involucrado y tipo de modificacin que realiz. No se podrn eliminar y/o modificar registros de la bitcora. La bitcora debe purgarse peridicamente slo de reportes ya resueltos. Inicialmente la bitcora ser purgada una vez por ao y el encargado de hacerlo ser el Administrador.
Acceso a las Bitcoras

Es un sistema experto disponible a todos los asesores para acceder a la bitcora slo para efectos de consulta.
22
Help Desk
Consultas
Consultas de Usuarios. Todos aquellos reportes que permitirn al usuario revisar los reportes que han levantado y ver si han sido atendidos por el servicio que presta la empresa. Consultas de Asesores. Son aquellos reportes a los cuales podrn acceder lo asesores y en los que estn involucrados directamente logrando de esta forma realizar de mejor manera su trabajos. Consultas Gerenciales. Sern aquellas que muestren consultas de estadstica de reportes, consultas de asesores as como el desempeo otorgado y consultas de usuario que han demandado en mayor proporcin el servicio, entre otras; de tal forma que permitan determinar la direccin de la empresa en un momento dado.
Mantenimientos Preventivos
La informacin de mantenimiento preventivo debe generarse por evento de manera peridica, la informacin debe ser: equipo, tipo de acciones que deben realizarse, fecha programada, ubicacin del equipo, configuracin registrada del equipo, estado = ASIGNADO, campaa del mantenimiento preventivo, asesor asignado. La informacin base debe obtenerse de la informacin de inventario de equipos de cmputo. Cada reporte por mantenimiento preventivo, debe procesarse como los descritos por mantenimiento correctivo.
23
Help Desk
CAPTURA DE REQUERIMIENTOS COMO CASOS DE USO

Una vez entendidos los requerimientos del usuario, procedemos a su captura como casos de uso, que es de donde partiremos para el anlisis y diseo del sistema. En esta seccin empleamos parte de la metodologa descrita por Jacobson, Booch y Rumbaugh en su obra The Unified Software Development Process, la cual es citada en la bibliografa de este trabajo.
Identificacin de Actores y Casos de Uso Actores:

Administrador Help Desk Asesor Usuario Final Gerente Sistemas externos tomados como actores: Inventario Recursos Humanos
Casos de Uso:

Control de Reportes Administracin de Catlogos Administracin de Reportes Consultas Bitcora de Cambios
Descripcin de Actores y Casos de Uso Actores:

Administrador Help Desk Asesor Asigna permisos, define nuevas categoras y en general le da mantenimiento a los catlogos. Recibe los reportes, va telefnica o va internet, de problemas por parte de los usuarios y los registra en el sistema. Tiene asignados reportes de usuarios, los atiende, les da seguimiento y los soluciona, agregando la solucin a la base de conocimiento de soluciones. Levanta los reportes directamente en el sistema o a travs del actor Help Desk, les da seguimiento a sus reportes o a los de su grupo de trabajo y tiene acceso a la base de conocimiento de soluciones. Consulta los indicadores de la incidencia y atencin de los reportes para apoyar la toma de decisiones.
Usuario Final
Gerente
24
Help Desk
Recursos H. Inventario
Sistema que se encarga de proporcionar todos los datos referentes a los empleados registrados dentro del sistema. Sistema que se encarga de proporcionar todos los datos referentes a los equipos registrados dentro del sistema.
Casos de Uso:
Control de Reportes. Caso donde se incluyen las diferentes operaciones para dar mantenimiento a los reportes registrados en el sistema, esto solo para datos de definicin del reporte.
Levantamiento de reporte. Transaccin en la cual se describen las actividades que se llevan a cabo para registrar e identificar el reporte en todas sus caractersticas e identificar perfectamente al usuario y equipo que se est reportando con una situacin tcnica que no le permita al usuario trabajar. As mismo en esta transaccin el sistema asigna inicialmente una accin a seguir y un asesor que atienda y solucione dicha situacin.
(correcto) del reporte. reportes. reporte.
Modificacin de reporte. Transaccin que permite tener un registro actualizado Consulta de reporte. Operacin que permite mostrar los datos de registro de los Conclusin de reporte. Operacin donde se registra el termino de vida de un
Administracin de Catlogos: En esta transaccin se llevan a cabo las actividades referentes al mantenimiento de los distintos tipos de catlogos usados por el sistema (catlogo de fallas, catlogo de sistemas, catlogo de subsistemas), as como la asignacin de permisos y la definicin de nuevas categoras. Dichas actividades sern realizadas por el actor Administrador dentro del sistema. Administracin de Reportes: Esta subtransacciones siguientes: transaccin puede desglosarse en las
Atencin de un Reporte: En esta transaccin se llevan a cabo las actividades relacionadas con la atencin de un reporte, la cual realiza inicialmente el asesor asignado por el sistema a la primera accin y ste debe indicar que est comenzando a atenderla, el nmero de horas que planea utilizar y la solucin que piensa utilizar. Si detecta ms problemas los agregar al reporte y el sistema los asignar automticamente al mismo asesor, pero ste puede reasignarlas a otro asesor. Las acciones y los problemas tendrn inicialmente un estado de Pendiente y cuando los asesores las comienzan a tender tendrn un estado de En Proceso.
25
Help Desk
Conclusin de una Accin: Es la transaccin a travs de la cual se registran datos importantes al concluir una accin, tales como % de Avance en la accin, tiempo real dedicado a realizar la accin y en qu porcentaje la accin resolvi el problema asociado. Notificacin de Cambio de Estado del Reporte: Esta transaccin lleva a cabo las actividades referentes a los diferentes tipos de notificaciones que se deben hacer a usuarios y asesores que estn relacionados con el reporte, tomando en cuenta lo configurado al respecto en la transaccin de Levantamiento de Reporte. Reasignacin de Acciones: En esta transaccin se realizan las actividades que corresponden a la reasignacin de una accin, la cual puede hacer manualmente el asesor que est asignado a la accin, o bien por el actor Help Desk. En cualquier caso se registrar cualquier cambio de asignacin en el sistema. Reasignacin de Reporte: Esta transaccin describe la reasignacin de un reporte a un nuevo asesor cuando el asesor que ha sido asignado no puede atender el reporte. Esta reasignacin de reporte es realizada manualmente por el actor Help Desk.
Consultas: Esta transaccin se encarga de presentar la informacin referente a los reportes con los que estn involucrados los distintos actores teniendo el sistema distintos tipos de consultas para distintos actores restringidos por el sistema. Presenta informacin oportuna y precisa que sirva de apoyo en la toma de decisiones. Registro de Cambios: En esta transaccin se lleva a cabo el registro de todo cambio realizado en un reporte (Nombre del usuario que modific el reporte, fecha y hora, identificador del reporte involucrado, y tipo de modificacin que realiz), registrando dichos cambios en una Bitcora de Cambios en la cual no se pueden eliminar modificar registros. La bitcora deber purgarse peridicamente slo de reportes ya resueltos. La bitcora de cambios estar disponible a todos los asesores slo para efectos de consulta.
Especficamente se han clasificado los casos de uso que necesitarn ser desarrollados en primeras iteraciones y los cuales podran ser desarrollados en posteriores. Casos de uso que necesitan ser desarrollados en tempranas iteraciones: Control de Reportes Administracin de Catlogos Casos de uso que pueden ser desarrollados en iteraciones posteriores: Administracin de Reportes Consultas Registro de Cambios
26
Help Desk
MODELO DE REQUERIMIENTOS
De acuerdo a la metodologa que se est siguiendo, el modelo de requerimientos est formado por el modelo de casos, modelo de interfaz y modelo de dominio del problema. Para tener una mayor claridad de este modelo en general, lo presentaremos desarrollado por casos de uso.
Diagrama General de Casos de Uso

Los actores y casos de uso descritos anteriormente son representados en este diagrama y las lneas representan las relaciones entre ellos.
DIAGRAMA GENERAL DE CASOS DE USO
Inventario
Recursos Humanos
Usuario Final Help Desk Control de Reporte
Administracin de Catlogos
Administrador
Administracin de Reporte
Consultas
Gerente
Asesor
Registro de Cambios
Fig. 7 Diagrama general de casos de uso
Como puede observarse en el diagrama, se tienen cinco casos de uso de nivel general: Control de Reportes Administracin de Catlogos Administracin de Reportes Consultas Registro de Cambios (Bitcora)
Estos casos generales sern descompuestos en casos ms simples hasta llegar a un nivel en el que las tareas sean de una sesin de trabajo. Como se mencion anteriormente slo los dos primeros casos de usos generales sern tratados en este trabajo: Control de reportes y, Administracin de catlogos.
27
Help Desk
Caso de Uso: Control de Reportes Diagrama de Casos de Uso para Control de Reportes
DIAGRAMA DE CASOS DE USO PARA CONTROL DE REPORTES
Modificar Reporte
Help Desk
(from Use Case View)
Agregar Reporte
Consultar Reporte
Concluir Reporte
Fig. 8 Diagrama de Casos de Uso: Control de Reportes.
Modelo de Casos Diagrama de Casos de Uso para Agregar Reporte (Levantamiento de Reporte)
Caso de Uso: Levantamiento de Reporte
Recursos Humanos Usuario Final

M
Inventario << Usa >>
Administracin de Catlogos
Help Desk
Levantamiento de Reporte
Reasignacin de Reporte
M
Directamente por el Usuario
Por Registro de Help Desk
Fig. 9 Diagrama de Casos de Uso: Levantamiento de Reportes. Help Desk Proyecto Terminal II
28
Help Desk
Precondicin: El Empleado debe estar registrado como Usuario en el sistema. El Equipo reportado debe estar registrado en el Sistema de Inventarios y estar asociado a dicho Usuario. Postcondicin: El sistema asigna un identificador para el reporte levantado.
Agregar Reporte o Levantamiento de Reporte
1. Help Desk captura el identificador del usuario (ID_Usuario). 2. El sistema verifica su identificador y despliega los datos del usuario as como los equipos que tiene asignados. 3. Help Desk selecciona la clave del equipo (Cve_Eq). 4. El sistema verifica la clave del equipo y despliega los datos correspondientes al equipo seleccionado. 5. Help Desk selecciona el tipo de reporte que se est llevando a cabo (Preventivo, Correctivo, Circunstancial) 6. Help Desk captura la descripcin del problema. 7. Help Desk captura la descripcin del impacto del problema y selecciona la prioridad correspondiente. 8. Help Desk captura el identificador del usuario a notificar (ID_UsuarioNotif) y selecciona el tipo (tipos) de notificacin y el estado(s) del reporte sobre el cual se harn las notificaciones. 9. El sistema asigna automticamente la primera accin a realizar (Evaluacin), el asesor que atender dicha accin y el estado inicial de la accin (Pendiente). 10. El sistema registra los datos del reporte y asigna el estado del reporte Pendiente, as como el identificador del reporte (ID_Rep). 11. El sistema muestra el identificador del reporte y el asesor que han sido asignados.
Levantamiento por Help Desk
Levantamiento por Usuario
1. El usuario introduce el identificador del usuario (ID_Usuario). 2. El sistema verifica el identificador y despliega los datos del usuario, as como los equipos que tiene asignados. 3. El usuario selecciona la clave del equipo (Cve_Eq). 4. El sistema verifica la clave del equipo y despliega los datos correspondientes al equipo seleccionado. 5. El usuario selecciona el tipo de reporte que se est llevando a cabo (Preventivo, Correctivo, Circunstancial) 6. El usuario captura la descripcin del problema. 7. El usuario captura la descripcin del impacto del problema y selecciona la prioridad correspondiente. 8. El usuario captura el identificador del usuario a notificar (ID_UsuarioNotif) y selecciona el tipo (tipos) de notificacin y el estado (estados) del reporte sobre el cual se harn las notificaciones. 9. El sistema asigna automticamente la primera accin a realizar (Evaluacin), el asesor que atender dicha accin y el estado inicial de la accin (Pendiente). 10. El sistema registra los datos del reporte y asigna el estado del reporte (Pendiente) y el identificador del reporte (ID_Rep).
29
Help Desk
11. El sistema muestra el identificador del reporte y el asesor que han sido asignados. Precondicin: El reporte debe estar registrado en el sistema. El equipo reportado debe estar registrado en el Sistema de Inventarios y estar asociado a un usuario. Postcondicin: El sistema guarda los cambios realizados en esta operacin.
Modificar Reporte
Procedimiento:
1. El sistema despliega los datos relacionados con el numero de reporte seleccionado con anterioridad. 2. Help desk se ubica en el dato que desea cambiar hasta que termine de efectuar las modificaciones pertinentes. 3. Help desk selecciona la opcin de guardar. 4. El sistema enva mensaje para preguntar a Help desk si esta seguro de registrar los datos. 5. Help desk selecciona la opcin de estar seguro. 6. El sistema enva mensaje de que los datos se han registrado de manera exitosa.
Precondicin: El reporte debe estar registrado en el sistema.
Consultar Reporte
Procedimiento:
1. El sistema despliega los datos relacionados con el numero de reporte seleccionado con anterioridad. 2. Help desk selecciona la opcin de salir.
Concluir Reporte
Precondicin: El reporte debe estar registrado en el sistema. Postcondicin: El sistema asigna un nuevo estado al reporte.
Procedimiento:
1. El sistema despliega los datos relacionados con el numero de reporte seleccionado con anterioridad. 2. Help desk introduce la descripcin del cierre de reporte, as como especifica la calidad del servicio que se le brindo. 3. Help desk selecciona la opcin de guardar. 4. El sistema enva mensaje para preguntar a Help desk si esta seguro de registrar los datos. 5. Help desk selecciona la opcin de estar seguro. 6. El sistema enva mensaje de que los datos se han registrado de manera exitosa.
30
Help Desk
Caso de Uso: Administracin de Catlogos Diagrama de Casos de Uso para Administracin de Catlogos
DIAGRAM A DE CASOS DE USO PARA ADM INIST RACION DE CAT ALOGOS
Adm inistra do r
Adm inistracin de Catlogos
Control de Reporte
Catalogo de Cam pana Ca tal og o de Ti po d e Re po rte
Catalogo de Sistem a
Catalogo de Preguntas
<< Usa> >
Catalogo de Subsistem a << Usa >>
Catalogo de Fallas
Fig. 10 Diagrama de Casos de Uso: Administracin de Catlogos
31
Help Desk
MODELO DE ANLISIS Diagrama de Clases

El diagrama de clases define todas las clases del sistema y los atributos de cada clase, los cuales son definidos formalmente en paginas posteriores (Fig. 4.4). Tambin define las relaciones entre clases, su navegacin y multiplicidad. Este diagrama define bsicamente la estructura de la base de datos del sistema Help Desk y la forma en que son relacionados los datos dentro de ella.
DIAGRAMA GENERAL DE CLASES Compania id_cia nom_cia 1 1..* Sucursal id_suc id_cia nom_suc HELP DESK
1..*
CentroTrabajo id_centrab desc_centrab
1..*
Empleado id_emp id_suc id_centrab nom_emp Tel_Emp Region_Emp Zona_Emp Subdir_Emp
Campana ID_Campaa Desc_Campaa Fech_Programada
Tipo_de_Cambio ID_TipoCambio Desc_TipoCambio 0..1 1..*
Tipo_de_Reporte ID_TipoRep Nom_TipoRep
Afectacion_de_Reporte Fech_Cambio 1
Confianza id_confianza id_emp
1..* 1 1..* Conjunto Cve_Eq id_confianza Clase_Eq Marca_Eq Desc_Eq 1..* 1..* 0..1 Reporte ID_Rep Desc_corta Stat_Rep Desc_Impacto Prior_Rep ID_Usuario_Notif Tipo_Notif Stat_Notif Desc_Cierre Calidad_Serv
1..*
Usuario id_Usuario id_confianza UserName
1..*
1..*
1..* Asesor id_Asesor id_confianza Nom_Asesor Espec_asesor Calif_asesor 1 Respuesta Respuesta 0..*
Accion ID_Accion Desc_Accion TiempoPlan Stat_Accion TiempoReal Avance Complejidad
0..*
1..* Pregunta ID_Pregunta
Resultado Porc_Resolucion
0..* Sistema 1 ID_Sistema Desc_Sistema 1..* Tipo_de_Falla ID_TipoFalla Desc_TipoFalla 1 1..* Falla ID_Falla Desc_Falla Problema ID_Problema Desc_Problema
0..1
1..*
Fig. 11 Diagrama general de clases
32
Help Desk
MODELO DE DISEO Caso de Uso: Levantamiento de reportes

Caso de Uso: Administracin de Catlogos

MODELO DE CONSTRUCCIN Caso de Uso: Levantamiento de reportes

DIAGRAMA DE TRANSICION LEV ANTA MIE NTO DE
Cancelar
Entrada a HD
Solicita password
Aceptar( ID_Emp )[ Usuario Registrado ] Levantamie nto de Reporte
Salir de HD
Aceptar/InserBD
Aceptar
Muestra ID Reporte
33
Help Desk
Caso de Uso: Administracin de Catlogos

Caso de Uso: Administracin de Reportes

DIAGRAMA DE TRANSICION
ADMINISTRACION DE REPORTE
Imprimir Informe Entrada Help Desk Solicitud de password Aceptar( ID_Emp )[ Usuario Registrado ]
Imprimir Listado
Administracin de Reporte
Salir Help Desk Informe Cancelar Aceptar/InserBD
Genera Informes
34
Help Desk
CONCLUSIONES
Con respecto al presente trabajo se pueden concluir los siguientes aspectos: Antes de comenzar a crear cualquier sistema o desarrollar cualquier proyecto, el equipo encargado de desarrollarlo debe tener perfectamente especificados y claros los requerimientos del sistema. Si no existen requerimientos reales o stos no son lo suficientemente especficos y claros, lo nico que podr resultar ser un bosquejo imaginario de proyecto que no se parece en nada a lo que el usuario espera del sistema. Para que un producto resulte eficiente y de calidad, como se pretende actualmente en la Ingeniera de Software, es necesario hacer la eleccin adecuada de los mtodos y herramientas que se aplicarn para desarrollar el proyecto, y desde luego, conocer perfectamente su uso y aplicacin, pero sobre todo, es necesario apegarse a la secuencia planteada por la metodologa elegida. Si se pretende crear un sistema yendo y viniendo de una etapa a otra de la metodologa, lo ms probable es que resulte un producto que no cumple con expectativas de calidad, adems de representar un trabajo extra al tener que repetir, redefinir o rehacer lo que ya se haba realizado, pero que se hizo sin fundamento suficiente en el anlisis y diseo que son las etapas previas a la construccin del sistema. La planeacin y evaluacin para cada iteracin en el desarrollo de cualquier proyecto son actividades muy importantes que deben ser realizadas por el equipo de trabajo que desarrollar el anlisis y diseo del sistema. Si estas actividades no son realizadas de esta manera o simplemente no se realizan no se tendr control de los riesgos porque no se estar controlando el desarrollo del propio sistema. La planeacin que ha sido elaborada por el lder de proyecto del sistema sin participacin del equipo de desarrollo provoca un grave riesgo debido a que no fue el equipo de desarrollo quien hiciera una planeacin tomando en cuenta sus capacidades y sus propios factores de riesgo, de tal forma que pudiera haber gran variacin en las fechas de entrega. An cuando el equipo ya hubiese conocido la fecha de entrega del primer prototipo, si no se tenan bien especificados los requerimientos no se podra cumplir con lo especificado en la entrega. Otro de los aspectos importantes en el desarrollo del proyecto se observo en el levantamiento de requerimientos; al no ser realizado directamente por el equipo de desarrollo provoc en un principio gran cantidad de dudas acerca del funcionamiento del sistema, las cuales fueron aclaradas en lo posible entre los miembros del equipo y el lder de proyecto, implicando tener una muy buena comunicacin, lo cual fue muy difcil de conseguir.
35
Help Desk
BIBLIOGRAFIA
[Brooks 1995] Brooks, Federick The Mythical Man Month, Addison-Wesley, 1995 [Castro 1999] Castro, Luis Fernando Anlisis y Diseo Orientado a Objetos, Universidad Autnoma Metropolitana, Mxico, D.F., 1999. [Gamma-helm-Johnson-Vlissides 1995] Gamma, Erich; Helm, Richard; Johnson, Ralph; Vlissides, John Design Patterns Addison-Wesley, 1995 [Humphrey 1995] Humphrey, Watts S A Discipline for Software Engineering, Addison Wesley, 1995 [Humphrey 1997] Humphrey, Watts S Personal Software Process, Addison Wesley, 1997 [Jacobson 1995] Jacobson, Ivar Object Oriented Software Engineering, Addison-Wesley, 1995 [Jacobson-Booch-Rumbaugh 1999] Jacobson, Ivar; Booch, Grady; Rumbaugh, James. The Unified Software Development Process Addison Wesley, 1999. [Jacobson-Christerson-Jonsson-Overgaard 1992] Jacobson, Ivar; Christerson, Magnus; Jonsson, Patrik; Overgaard, Gunnar Object Oriented Software Engineering, a Use Case Driven Approach, Addison-Wesley, 1992 [Muller 1997] Muller, Pierr-Alan Instant UML, Wrox, Birmingham, Canad, 1997
36
Help Desk
[Silverschatz- Korth- Sudarshan 1998] Silverschatz, Abraham; Korth, Henry F.; Sudarshan, S. Fundamentos de Bases de Datos McGraw-Hill-/Interamericana de Espaa, 1998 [William 1998] William B., Heys. Edicin Especial, Power Builder 6, Prentice Hall, 1998 [Wood 1997] Wood A., Charles. Using Power Builder 5 Prentice Hall, 1997 [Yourdon 1994] Yourdon, Edward Object Oriented Sistem Design, Yourdon Press, 1994 [Yourdon 1994] Yourdon, Edward Object Oriented Analysis and Design with Applications, Benjamin Cummings, 1994 The Unified Modeling Language User Guide, 1998. Universidad Autnoma Metropolitana Iztapalapa, rea de Computacin y Sistemas Diplomado en Calidad de Software. Versin 1.1 , Abril 1999.
37
Help Desk
ANEXO A. PROCESO PERSONAL DE SOFTWARE (PSP)

El Proceso Personal de Software (PSP) se pretendi aplicar durante el desarrollo del sistema Help Desk, y lo cual nos hubiera sido de gran ayuda para el posterior desarrollo de aplicaciones, sin embargo, por falta de tiempo no pudo continuarse con su seguimiento. Presentamos aqu una breve introduccin a lo que es este proceso para aquellos lectores que se interesen en aplicarlo en el desarrollo de sistemas, y para quienes se interesen en profundizar un poco ms a cerca de el PSP, en la bibliografa de este trabajo se cita la fuente de donde se obtuvo lo que aqu se presenta.
1. INTRODUCCIN
Los procesos actuales en la Ingeniera de Software son aceptados a pesar de ser empricos pues son los nicos con los que se cuenta. Aunque en conjunto generan productos grandes de software, los mtodos y tcnicas empleados por los individuos de un equipo de trabajo son muy diversos y adems privados, por lo que la industria aumenta el proceso de prueba, lo cual no es conveniente. Un proceso de software define la lnea de trabajo para aplicar mtodos, herramientas y personas para una tarea de software, mientras que la definicin de proceso identifica roles y especifica tareas. Los procesos son difciles de establecer y por ello es necesario hacerlo paulatinamente. La maduracin de un proceso est dada por cinco niveles: Inicio, Repetible, Definido, Administrado y PSP (Proceso Personal de Software) es un proceso de automejora, slo adecuado para personas que desean hacer mejor su trabajo y mejorar en sus desempeos. No es instantneo y exige trabajo y aos de mejora gradual.
optimizado.
2. ESTRATGIA DEL PSP

Identificar los mtodos y prcticas de software de sistemas grandes que puedan utilizarse a nivel individual. Definir el subconjunto de estos mtodos y prcticas que puedan aplicarse para pequeos programas. Estructurar estas prcticas para que sean gradualmente introducidas. Establecer ejercicios adecuados para practicar los mtodos.
3.
NIVELES DEL PSP
PSP0: El proceso de referencia o de inicio. Incluye algunas medidas y reportes bsicos: Tiempos y defectos. La referencia da un fundamento consistente para medir el proceso y la mejora. Tiene un refinamiento PSP0.1 que agrega: un Estndar de codificacin, una Medida de tamao y una Propuesta de mejora. 38
Help Desk
PSP1: El proceso personal de planeacin. Agrega pasos de planeacin a PSP0: Reporte de pruebas, Estimacin de recursos y Tamao. Tiene un refinamiento PSP1.1 que agrega: Estimacin de tareas y de calendario. Lo que hay detrs de la planeacin es: Establecer relaciones entre tamao y tiempo de desarrollo; Establecer compromisos que puedan cumplirse; Establecer un plan ordenado para trabajar; Establecer una lnea de trabajo para determinar el estado de trabajo.
PSP2: El proceso personal de administracin de calidad. La forma de escribir programas perfectos es que usted sea un programador perfecto y as slo programar naturalmente. PSP2 agrega revisiones sobre PSP1 para detectar errores lo antes posible. PSP2.1 aumenta a PSP2 haciendo revisiones para el diseo. PSP2.1 establece criterios de completes para el diseo y examina varias tcnicas de verificacin de diseo y consistencia.
PSP3: Un proceso personal cclico. Es el proceso que permite escalar a sistemas grandes pues integra el desarrollo por mdulos en donde se utiliz PSP2.
TSP: El proceso de software en equipo. Es el siguiente paso a llegar una vez que se ha accedido al nivel PSP3. Sirve para grandes sistemas y el trabajo en equipo.
4. LOGICA DEL PSP

Los profesionales de software comprenden mejor lo que ellos hacen si ellos definen, miden y dan seguimiento a su trabajo, y tendrn una estructura de procesos definida y criterios de medicin para evaluar y aprender de sus propias experiencias y las de otros. Con este conocimiento y experiencia, pueden seleccionar aquellos mtodos y prcticas que mejor se adecuen a sus tareas y habilidades. Al utilizar un conjunto de prcticas personales configuradas, practicadas consistentemente y de alta calidad, sern miembros ms efectivos de sus equipos de trabajo y proyectos. Principios: Un proceso definido y estructurado puede mejorar la eficiencia del trabajo. Los procesos personales deben ajustarse de manera conveniente a las habilidades y preferencias de cada ingeniero de software. Para que los profesionales estn confortables con un proceso definido, deben estar involucrados en su definicin. Conforme las capacidades y habilidades de los profesionales evolucionan, sus procesos tambin lo deben hacer. La mejora continua de proceso es mejorada por una retroalimentacin rpida y explcita.
39
Help Desk
5. PSP Y LA PRODUCTIVIDAD
Cuando el PSP se comienza a utilizar en pequeos programas, la productividad decrecer, esto debido a que realizar actividades que no llevaba a cabo como son: Planeacin, Medicin y Pasos de anlisis. Las habilidades personales dan diferencias de productividad, pero otros factores pueden establecerse como factores que influyen, tales como conocimiento de la plataforma, experiencia, conocimiento de la aplicacin, conocimiento del lenguaje de programacin empleado, etc.
40
Help Desk
ANEXO B. Descripcin de clases

Nombre de la clase Atributo Compaa Id_Cia Nom_Cia CentroTrabajo Id_CenTrab Desc_CenTrab Sucursal Id_Suc Id_Cia Nom_Suc Empleado Id_Emp Id_Suc Id_CenTrab Nom_Emp Tel_Emp Region_Em Zona_Emp Subdir_Emp Sistema Id_Sistema Desc_Sistema Subsistema Id_Subsistema Id_Sistema Desc_Subsistema Falla ID_Falla ID_TipoFalla Desc_Falla Confianza Id_Confianza Tipo de Cambio Id_TipoCambio Desc_TipoCambio Preguntas Id_Pregunta Desc_Pregunta Resultado Id_Accin Id_Sntoma Porc_Resolucin Asesor
Definicin de la clase o atributo Clase que contiene la informacin de todas las compaas del grupo Identificador de la compaa Nombre de la compaa Contiene la informacin de los centros de trabajo del grupo de compaas. Identificador del centro de trabajo Nombre del centro de trabajo Contiene las sucursales en donde opera el grupo. En una sucursal pueden operar varias compaas Identificador de la sucursal Identificador de la compaa Nombre de la sucursal Persona que trabaja dentro del grupo Identificador del empleado dentro de la compaa y sucursal Identificador de la sucursal en la cual trabaja el empleado Identificador del centro de trabajo del empleado Nombre del empleado en Apellido Paterno, Materno, Nombres, sin que exista separacin por comas. Algunos nombres pueden tener puntos para abreviarlos. Nmero de telfono del hogar del Empleado Regin comercial a la que pertenece el Empleado Zona del empleado Subdireccin comercial a la que pertenece el Empleado Catalogo de sistemas Identificador del sistema Nombre del sistema Catlogo de subsistemas Identificador del subsistema Identificador del sistema Nombre del subsistema Catalogo de Fallas Identificador de la falla Identificador del tipo de falla Nombre de la falla Persona que puede hacer uso del HelpDesk. Hereda los atributos de la clase Empleado Identificador del empleado de confianza Contiene el registro de todos los cambios realizados en un reporte (Bitcora de Cambios) Identificador del tipo de cambio realizado en el Reporte Descripcin del tipo de cambio hecho al reporte Contiene el cuestionario de preguntas diseadas para recoger los comentarios del usuario respecto a lo que percibi del servicio (catlogo de preguntas). Identificador de la pregunta dentro del cuestionario Cuestin a responder por el usuario Clase asociativa que relaciona las clases ACCION y SINTOMA. Contiene el porcentaje en el que la accin resolvi el problema Identificador de la accin Identificador del sntoma Porcentaje en el cual la accin resuelve el problema Empleados que son los asesores que resuelven los problemas descritos en los reportes
41
Help Desk
Id_Asesor Id_Confianza Nom_Asesor Espec_Asesor Calif_Asesor Tipo de Reporte ID_TipoRep Nom_TipoRep Problema Id_Problema ID_Falla Desc_Problema Accion Id_Accion Id_Asesor Id_Rep Desc_Accin TiempoPlan_Acion Stat_Accion TiempoReal_Accion Avance_Accion Conjunto Cve_Eq Id_Confianza Clase_Eq Marca_Eq Desc_Eq AfectacionesReporte Id_TipoCambio Id_Rep Fech_Cambio Campaa Id_Campaa Desc_Campaa Fech_Programada Respuestas Id_Respuesta Id_Pregunta Id_Rep Reporte Id_Rep Cve_Eq Id_TipoRep Id_Usuario Id_Campaa Desc_Corta Stat_Rep Desc_Impacto Prior_Rep
Identificador del asesor Identificador del empleado de confianza Nombre clave con el que se conoce al Asesor Especialidad o especialidades del Asesor Calificacin del Asesor en las especialidades descritas (Excelente, Bueno, Regular; Malo) Describe el tipo de mantenimiento que se le da al equipo reportado: Preventivo, Correctivo o Circunstancial Identificador del tipo de reporte Nombre del Tipo de Reporte Contiene la descripcin de los problemas que presenta el equipo Reportado. Identificador del problema. Es nico para cada problema descrito en cada reporte Identificador de la falla Descripcin corta del problema hecha por el usuario (muy especfica) Contiene varias opciones a seguir para resolver un problema especfico. Identificador de la Accin Identificador del asesor que atiende dicha accin Identificador del reporte con el cual se relaciona dicha accin Descripcin de la accin a seguir para resolver uno o varios problemas detectados Nmero de minutos que el asesor planea utilizar en desarrollar la Accin Indica el estado de realizacin en que se encuentra la accin (Pendiente, En Proceso, Terminado) Nmero de minutos que el asesor empleo en desarrollar la accin Porcentaje de avance que tiene la realizacin de una accin Entidad que describe el agrupamiento de componentes que constituyen un equipo Clave del equipo Identificador del empleado de confianza Clase del equipo Marca del equipo Descripcin del equipo Entidad que asocia las clases Reporte y Tipo de Cambio. Contiene la fecha y hora en la cual se registr el cambio. Identificador del tipo de cambio Identificador del reporte relacionado con el cambio Fecha y hora el la cual se registr el cambio en el reporte Describe el mantenimiento preventivo a travs de eventos programados para todos los equipos en cada campaa. Identificador de campaa Descripcin de la campaa Fecha programada para realizar el evento Entidad que contiene los comentarios del usuario relacionado con el reporte, respecto a la calidad del servicio que l percibi Identificador de la respuesta Identificador de la pregunta a la cual pertenece la respuesta o comentario hecho por el Usuario Identificador del reporte al cual se refieren los comentarios del Usuario Describe el reporte de una situacin tcnica que no le permite trabajar a un usuario Identificador del reporte nico dentro del grupo Clave del equipo reportado Identificador del tipo de reporte Identificador del usuario del equipo Identificador de la campaa en la cual se le realizar un evento al equipo Descripcin corta del problema Estado del reporte (Pendiente, En Proceso, Concluido, Cerrado) Descripcin del impacto del problema Prioridad para atencin del reporte
42
Help Desk
UserName_Notif Tipo_Notif Stat_Notif Desc_Cierre Calidad_Serv Usuario Id_Usuario Id_Confianza UserName_Usuario
Identificador del usuario a notificar sobre el reporte Tipo de notificacin que se debe hacer para el reporte Estado del reporte sobre el cual se hace la notificacin Descripcin del cierre del reporte Descripcin de la calidad del servicio realizado para dicho reporte Empleado de confianza que puede realizar reportes dentro del HelpDesk Identificador del usuario Identificador del empleado de confianza Nombre clave con que se conoce al usuario
43

Uami10173 - 10 10 13

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Uami10173 - 10 10 13

Uploaded by

Copyright:

Available Formats

UNIDAD IZTAPALAPA CIENCIAS BASICAS E INGENIERIA

Albertina Gonzlez Mrquez

Para la obtencin del grado de licenciatura en Computacin Noviembre 2002

Help Desk Proyecto Terminal II

Help Desk Proyecto Terminal II

Help Desk Proyecto Terminal II

Help Desk Proyecto Terminal II

Help Desk Proyecto Terminal II

ENFOQUE ORIENTADO A OBJETOS

Help Desk Proyecto Terminal II

Help Desk Proyecto Terminal II

ARQUITECTURA DEL DESARROLLO

Pruebas Previas a Implantacin

Pruebas Previas a Implantacin

Pruebas Previas a Implantacin

Modelo de Generacin de Prototipos

PROCESO DE LA INGENIERA DE SOFTWARE ORIENTADA A OBJETOS

Modelo de Pruebas Fig. 3 Procesos de la ISOO

Los procesos involucrados y modelos generados se describen a continuacin:

Help Desk Proyecto Terminal II

DESCRIPCIN DE LOS PROCESOS DE LA INGENIERA DE SOFTWARE ORIENTADA A OBJETOS

Proceso de Anlisis de requerimientos Proceso de Anlisis Proceso de Anlisis dinmico

Modelo de Requerimientos Modelo de Anlisis Modelo de Anlisis Dinmico

Fig. 4 Proceso de Anlisis

Proceso de Anlisis de Requerimientos

Help Desk Proyecto Terminal II

Proceso de Anlisis Dinmico

Help Desk Proyecto Terminal II

Proceso de Anlisis de Componentes Modelo de Anlisis Dinmico Proceso de Programacin

Help Desk Proyecto Terminal II

Lenguaje Unificado de Modelado (UML)

Help Desk Proyecto Terminal II

Fig. 6 Planeacin del Proyecto Help Desk Proyecto Terminal II

Help Desk Proyecto Terminal II

Contexto del problema

Help Desk Proyecto Terminal II

Help Desk Proyecto Terminal II

Help Desk Proyecto Terminal II

Acceso a las Bitcoras

Help Desk Proyecto Terminal II

CAPTURA DE REQUERIMIENTOS COMO CASOS DE USO

Identificacin de Actores y Casos de Uso Actores:

Control de Reportes Administracin de Catlogos Administracin de Reportes Consultas Bitcora de Cambios

Descripcin de Actores y Casos de Uso Actores:

Help Desk Proyecto Terminal II

Help Desk Proyecto Terminal II

Help Desk Proyecto Terminal II

Diagrama General de Casos de Uso

Usuario Final Help Desk Control de Reporte

Fig. 7 Diagrama general de casos de uso

Fig. 8 Diagrama de Casos de Uso: Control de Reportes.

Recursos Humanos Usuario Final

Inventario << Usa >>

Directamente por el Usuario

Por Registro de Help Desk

Agregar Reporte o Levantamiento de Reporte

Levantamiento por Help Desk

Levantamiento por Usuario

Precondicin: El reporte debe estar registrado en el sistema.

Help Desk Proyecto Terminal II

Adm inistracin de Catlogos

Catalogo de Cam pana Ca tal og o de Ti po d e Re po rte

<< Usa> >