Herramienta de gesti n de incidencias · incidencias) de cara a que pueda ser usada por todo el mundo pero que solo los usuarios avanzados tengan la capacidad de modificar las incidencias

PROYECTO FIN DE CARRERA

HERRAMIENTA DE GESTIÓN DE INCIDENCIAS

AUTOR: ANTONIO MATA TRILLO MADRID, SEPTIEMBRE 2007

UNIVERSIDAD PONTIFICIA COMILLAS

ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)

INGENIERO TÉCNICO EN INFORMÁTICA DE GESTIÓN

II

RESUMEN.

Una de las actividades fundamentales dentro de una empresa es la resolución de

las incidencias que pueden ir surgiendo, ya que una incidencia que mantenga a los

usuarios sin poder trabajar mucho tiempo podría llegar a costar mucho dinero.

El objetivo del proyecto es crear una herramienta de gestión de incidencias de

manera que resulte más cómoda y efectiva la resolución de las mismas, pero

diferenciando dicha herramienta de las ya existentes en tanto en cuanto que haga

participe a los usuarios de manera que estos puedan gestionar y ver la evolución de sus

incidencias.

Las herramientas que existen actualmente no permiten que los usuarios puedan

ir viendo la evolución de sus incidencias ya que una vez ha sido dada de alta pasa por

los departamentos correspondientes sin que el usuario tenga conocimiento sobre la

resolución de la misma. También se da el problema de que son herramientas muy

complejas haciendo que para un usuario sin demasiados conocimientos informáticos

(como de un departamento bancario) le fuera muy difícil de utilizar y, al fin y al cabo,

en una empresa interesa hacer lo más cómodo y fácil que sea posible el trabajo a sus

empleados en lugar de complicárselo.

Con motivo de querer cambiar esta situación se pretender crear una herramienta

que sea lo más fácil de usar en la cual se van a diferenciar claramente dos perfiles

(usuarios estándar y usuarios avanzados que serán los encargados de resolver las

incidencias) de cara a que pueda ser usada por todo el mundo pero que solo los usuarios

avanzados tengan la capacidad de modificar las incidencias. Con esta herramienta se da

la posibilidad a todos los usuarios a que sean ellos mismos los que den de alta sus

incidencias sin necesidad de llamar por teléfono al S.A.U. (Servicio de Atención al

Usuario) y, además, pueda ir revisando el estado de sus incidencias así como diversa

información como que departamento la esta resolviendo o los comentarios que se van

añadiendo. También mejorará el trabajo de los usuarios avanzados ya que actualmente

III

las herramientas para la gestión de incidencias se basan en una serie de buzones de

manera que cada departamento puede ver las incidencias de su buzón pero no la de los

demás sin embargo en la nueva herramienta todas los usuarios podrán ver las

incidencias independientemente de que departamento este encargándose de resolverla.

Debido a que la aplicación va a funcionar como una página web se han utilizado

“sesiones” para mejorar la seguridad ya que un usuario estándar si pusiera la url exacta

de la página de un usuario avanzado podría entrar sin problemas y modificar incidencias

si no se usarán las sesiones. Una sesión lo que va a hacer es que una vez un usuario se

ha validado como un usuario estándar se va guarda el perfil durante todo el tiempo que

esté conectado a la aplicación impidiendo cualquier fallo de seguridad.

A parte de funcionalidad también se ha buscado durante el desarrollo que la

aplicación funcione holgadamente en cualquier PC ya que los únicos requisitos

necesarios serán un servidor de páginas Web como Internet Explorer, el gestor de bases

de datos Access que viene incluido en el paquete de Office y prácticamente todos los

PC lo tienen instalado y la Java Virtual Machine.

La aplicación ofrecerá servicio las 24 horas los 365 días del año ya que en una

empresa funciona las 24 horas del día y no sería viable pensar que en ciertas horas no

pueden ocurrir incidencias.

En conclusión, se ha pretendido desarrollar una aplicación que consiga

simplificar y agilizar todos los procesos que ocurren desde que se da de alta una

incidencia hasta que se resuelve, haciendo además al usuario participe durante la gestión

de las mismas pudiendo consultar su estado y consiguiendo así que éste se sienta más

seguro y atendido por parte de los demás departamentos sin que tenga que realizar un

esfuerzo en tener que aprender a utilizar una herramienta muy compleja.

IV

ABSTRACT.

One of the main activities in a company is the resolution of any incidences that

may occur, as a poor efficency of such resolutions may result in major economic losses.

The object of this proyect is the creation of a incidences tool that makes this

management as easy and as accurate as possible. The difference between the solutions

already in the market is the capability of this tool to interact with the users keeping track

of them. These solutions do not allow the users to currently check their status as when

the incidence has been entered goes through all the relevant departments and the users

do not participate in the proccess. They are also very complex tools making it

impossible to understand for a user without the necessary knowledge. This is a major

handicap as any company wishes to make things easier to all their employees.

This problem makes necessary the creation of a easy tool with two separate

profiles (standard users and advanced users, in charge of the resolution of the incidences

in order to make it possible to use by any user but only advanced user may modify the

incidences. This tool enables the possibility to every user to enter the incidence

eliminating thus the need of contacting with the SAU (hotline). This also allows to keep

track of them, along with a lot of information such as the department involved in the

resolution or checking the comments log. It will also improve the efficiency of

advanced users as at the moment, the current similar tools available are based in a series

of incoming boxes so that each department checks its own mailbox but not the other

departments. However, with this new tool, all incidences become visible to all the users

no matter the department involved in the resolution.

As it will function as a web page, different accounts have been created for major

security, as an standard user introducing the correct URL could log in any advanced

user account and modify the incidences if these accounts were not used. Once a

validated user has been logged in as an standard user, the profile is saved during the

whole session blocking any security issue.

V

Funcionality and efficiency have been taken into account and the tool works

smoothly in any type of PC. The only technical requirements are a web browser such as

Internet Explorer, MS ACCESS included in any MS Office pack, already installed in

most of the PCs, and the Java virtual machine. This tool will be operational on a 24 hour

basis, all year round, as a company works 24 hours a day and may generate incidences

at any time.

The main intention of this tool is to simplify and minimize the time and efforts

between the creation of a new incidence and its resolution. It also allows the user to

modify their status and to keep track of the incidences. This results in a better service

from every department without the effort of learning a new complex tool.

VI

INDICE

INTRODUCCIÓN........................................................................................................ 12

IDENTIFICACIÓN DE NECESIDADES.................................................................. 16

OBJETIVOS DEL SISTEMA : .......................................................................................... 17

ALCANCE DEL SISTEMA : ............................................................................................ 18

TIPOLOGÍA DE LOS USUARIOS : .................................................................................. 19

RESTRICCIONES: ........................................................................................................ 19

ANTECEDENTES: ........................................................................................................ 21

ANÁLISIS DE REQUISITOS.................................................................................... 22

2.1 RECONOCIMIENTO DEL PROBLEMA ..................................................................... 23

2.1.1 Ámbito........................................................................................................... 23

2.1.2 Contexto general........................................................................................... 23

2.2 L ISTA DE REQUISITOS ........................................................................................... 25

2.3 MODELO LÓGICO DEL NUEVO SISTEMA ............................................................... 31

2.3.1 Procesos del usuario estándar...................................................................... 31

2.3.1 Procesos del usuario de departamento informático.................................... 32

2.4 DIAGRAMACIÓN . .................................................................................................. 34

Contexto de usuarios estándar.............................................................................. 35

Contexto usuarios de departamento informático................................................. 36

2.4.1 Conceptual.................................................................................................... 37

2.4.1.1 Explosión Gestión información usuario estándar. .................................. 38

4.1.2 Explosión Gestión información usuario avanzado..................................... 39

BASES DE DATOS......................................................................................................... 40

Entidades necesarias............................................................................................. 40

2.5 DIAGRAMA M.E.R. .......................................................................................... 42

2.5.1 RELACIONES........................................................................................... 42

VII

2.5.2 DIAGRAMA............................................................................................... 44

2.5.3 PROPAGACIÓN RELACIONES............................................................... 44

2.5.4 DIAGRAMA RESULTANTE...................................................................... 47

2.5.4 BASES DE DATOS RELACIONADAS..................................................... 48

ESTUDIO DE LA ARQUITECTURA ....................................................................... 49

ESPECIFICACIÓN DE LAS ALTERNATIVAS .................................................. 50

3.1.1.1 Tecnología de comunicaciones............................................................. 50

3.1.1.1.1 Alquiler de servidor............................................................................... 50

3.1.1.1.2 Ventajas.................................................................................................. 50

3.1.1.1.3 Otras ventajas........................................................................................ 51

3.1.1.1.4 Inconvenientes....................................................................................... 51

3.1.1.1.5 Servicios................................................................................................. 51

3.1.1.1.6 Características....................................................................................... 52

3.1.1.2 Alquiler servicios................................................................................... 52

3.1.1.2.1 Ventajas.................................................................................................. 52

3.1.1.2.2 Otras ventajas........................................................................................ 53

3.1.1.2.3 Inconvenientes....................................................................................... 53

3.1.1.2.4 Especificaciones técnicas...................................................................... 53

3.1.1.2.5 Servicios................................................................................................. 54

3.1.1.3 Compra de un servidor propio............................................................... 54

3.1.1.3.1 Ventajas.................................................................................................. 54

3.1.1.3.2 Inconvenientes....................................................................................... 55

3.1.1.3.3 Especificaciones técnicas...................................................................... 55

3.1.1.3.4 Precio..................................................................................................... 55

3.1.1.4 Elección de una alternativa................................................................... 56

3.1.1.2 Servidor WEB........................................................................................ 56

3.1.1.3 Apache Tomcat...................................................................................... 56

3.1.1.4 IIS. .......................................................................................................... 57

3.1.1.5 Sun´s Java Web Sever........................................................................... 57

3.1.2 Sistemas Gestores de Bases de Datos........................................................ 57

VIII

3.1.2.2 Microsoft SQL Server........................................................................... 57

3.1.3.2 Access..................................................................................................... 57

3.1.3.3 Mysql...................................................................................................... 57

3.1.3.4 IBM DB2. ............................................................................................... 58

3.1.3.5 Oracle..................................................................................................... 58

3.1.4 Herramientas de desarrollo....................................................................... 58

3.1.4.1 Java Servlets............................................................................................. 58

3.1.4.2 HTML. .................................................................................................... 58

3.1.4.3 Java JSP................................................................................................. 59

3.1.4.4 Middleware............................................................................................. 59

3.1.4.4.1 Llamada a procedimiento remoto......................................................... 59

3.1. 4.4.2 Acceso remoto........................................................................................ 59

3.1.4.4.3 Conversacional...................................................................................... 60

3.1.5 Arquitectura.................................................................................................. 61

3.1.5.1 Elección de la arquitectura................................................................... 61

3.1.5.2 Niveles.................................................................................................... 61

3.1.5.2.1 Datos....................................................................................................... 61

3.1.5.2.2 Aplicación.............................................................................................. 62

3.1.5.2.3 Presentación........................................................................................... 62

3.1.5.3 Modelos de la arquitectura cliente-servidor......................................... 64

3.1.5.3.1 Presentación local.................................................................................. 64

3.1.5.3.2 Presentación distribuida........................................................................ 64

3.1.5.3.3 Aplicación local..................................................................................... 64

3.1.5.3.4 Aplicación distribuida............................................................................ 65

3.1.5.3.5 Gestión de datos distribuida.................................................................. 65

3.1.6 Otros servidores......................................................................................... 65

3.1.6.1 Servidores de bases datos...................................................................... 65

3.1.6.2 Servidor de correo.................................................................................. 65

3.1.6.3 Servidor DNS......................................................................................... 65

3.1.7 Alternativas................................................................................................ 66

IX

EVALUACIÓN DE LAS ALTERNATIVAS ......................................................... 67

3.2.1 Evaluación económica.............................................................................. 67

3.2.2 Evaluación técnica.................................................................................... 67

SELECCIÓN DE UNA ALTERNATIVA .............................................................. 68

DISEÑO EXTERNO.................................................................................................... 69

ENTORNO OPERATIVO DEL SISTEMA........................................................... 70

4.1.1 Entrada, salida y recogida de datos.......................................................... 70

4.1.2 Mantenimiento de ficheros........................................................................ 72

4.1.3 Generación de informes............................................................................ 72

4.1.4 Control de información y seguridad del sistema..................................... 72

4.1.4.1 Condiciones iniciales............................................................................. 73

4.1.4.1.1 A nivel preventivo.................................................................................. 73

4.1.4.1.2 A nivel correctivo................................................................................... 73

4.1.4.2 Encriptación de Datos........................................................................... 74

4.1.4.3 Ataque y defensa (Web seguro)............................................................. 75

4.1.4.4 Conclusión............................................................................................. 76

4.1.5 Rendimiento del sistema y escalabilidad................................................... 77

4.1.6 Forma de implantación............................................................................. 78

4.2 CONFIGURACIÓN HARDWARE -SOFTWARE. ...................................................78

4.2.1 Especificaciones hardware del sistema..................................................... 80

4.2.2 Especificaciones software del sistema....................................................... 80

4.3 DESARROLLO DEL MODELO FÍSICO NUEVO ................................................... 81

4.3.1 Fronteras de mecanización....................................................................... 81

4.3.2 Diseño de entradas..................................................................................... 86

4.3.2.1 Subsistema de validación....................................................................... 86

4.3.2.2 Dar de alta incidencias.......................................................................... 86

4.3.2.3 Modificar incidencias............................................................................ 86

4.3.2.4 Consulta incidencias.............................................................................. 86

4.3.2.5 Cerrar incidencia................................................................................... 86

4.3.3 Diseño de salidas....................................................................................... 87

X

4.3.4 Modelo físico del nuevo sistema................................................................ 90

4.3.4.1 Cuaderno de carga de los diagramas de flujo...................................... 94

4.3.4.1.1 Diagrama de contexto............................................................................ 94

4.3.4.1.1.1 Entidades externas............................................................................. 94

4.3.4.1.1.2 Procesos............................................................................................. 95

4.3.4.1.2 Diagrama conceptual............................................................................ 95

4.3.4.1.3 Diagramas Nivel 2................................................................................. 96

4.4 MODELO LÓGICO DE DATOS . ......................................................................... 97

4.5 ESTUDIO DE LOS PLANES................................................................................ 98

4.5.1 Plan de pruebas funcionales..................................................................... 98

4.5.2 Plan de pruebas de prestaciones............................................................... 99

DISEÑO INTERNO ................................................................................................... 100

5.1 SUBSISTEMA BATCH. ................................................................................. 101

5.1.1 Función batch de backup........................................................................ 101

5.1.2 Función batch de recuperación.............................................................. 102

5.2 MODELO FÍSICO DE DATOS . ......................................................................... 103

5.3 SUBSISTEMA ON_LINE .................................................................................. 105

5.3.1 Principal................................................................................................... 105

5.3.2 Menú principal usuario estándar............................................................ 106

5.3.3 Menú principal usuario avanzado.......................................................... 107

5.3.4 Alta incidencia......................................................................................... 108

5.3.5 Consulta de incidencia............................................................................ 109

5.3.6 Modificar incidencias.............................................................................. 110

5.3.7 Cerrar incidencia..................................................................................... 111

XI

PROGRAMACIÓN.................................................................................................... 112

6.1 MENÚ PRINCIPAL . ........................................................................................ 113

6.1.1 Código de página de menú principal....................................................... 113

6.1.2 Código que recogerá los datos de la pagina web para validarlos.......... 115

6.1.3 Código de la consulta a la base de datos de usuarios............................. 119

6.1.4 Código del constructor de usuarios......................................................... 121

6.1.5 Código de la clase control de usuarios................................................... 123

6.2 MENÚ DE USUARIO. ...................................................................................... 123

6.2.1 Código pagina web menú usuario........................................................... 124

6.2.2 Código pagina web alta de incidencia.................................................... 125

6.2.3 Código pagina web selección de criterio para la búsqueda................... 126

6.2.4 Código pagina web para mostrar el resultado de una búsqueda........... 127

6.2.5 Código pagina web para modificar una incidencia............................... 129

6.2.6 Código constructor de incidencia............................................................ 132

6.2.7 Código control de incidencia................................................................... 135

6.2.8 Código operaciones de bbdd incidencia.................................................. 136

GUÍA DE USUARIO.................................................................................................. 142

PLANIFICACIÓN ..................................................................................................... 151

PRESUPUESTO DEL DESARROLLO................................................................... 157

CONCLUSIONES ...................................................................................................... 160

BIBLIOGRAFÍA ........................................................................................................ 162


12

Introducción


13

Durante el día a día de una empresa pueden ocurrir numerosas incidencias que

impidan a los usuarios desarrollar su actividad laboral correctamente provocando que la

empresa no funcione de la manera adecuada.

Estas incidencias pueden ser muy variadas, desde un fallo de un programa o con las

conexiones, un problema hardware como la avería de un PC o una impresora hasta una

petición para dar de alta a un nuevo usuario en el sistema o para solicitar derechos de

accesos para unas aplicaciones o carpetas.

Sin una herramienta de gestión de incidencias adecuada la resolución de estas

incidencias podría llevar mucho tiempo lo que podría provocar graves pérdidas para la

empresa lo cual es del todo inviable.

Desde hace unos años cada vez es mas frecuente ver en las empresas numerosas

aplicaciones online. Estas aplicaciones normalmente están instaladas en un servidor de

la empresa integrado dentro de la Intranet de la misma, por lo que consecuentemente

para poder utilizarla no es necesario instalarla en el PC del usuario, sino bastaría con

una conexión al ejecutable del servidor.

Este funcionamiento hace mucho más sencillo y práctico el funcionamiento de estas

herramientas y facilita enormemente su administración ya que al estar centralizada

permiten su correcto funcionamiento tanto desde la Intranet de la empresa como desde

cualquier PC exterior con conexión a la misma.

Otro punto favorable es el bajo coste necesario para el buen funcionamiento de estas

aplicaciones y además para el usuario es mucho más fácil manejarse con ellas ya que

cada día los usuarios están más acostumbrados a manejarse en Internet.

Actualmente en las empresas para dar de alta una incidencia los usuarios lo hace

vía telefónica llamando normalmente un departamento llamado S.A.U. (Servicio de


14

Atención al Usuario) el cuál da de alta las incidencias y, a partir de ese punto, el usuario

pierde total conocimiento sobre que esta pasando con su incidencia lo que provoca

malestar e inseguridad en él.

Los motivos principales para el desarrollo de una herramienta de gestión de

incidencias en la cual el usuario sea quien de directamente el parte de sus incidencias

son:

♦ Al solicitar la aplicación los datos al usuario nos aseguramos de que todos los datos

son correctos y no se ha producido ningún tipo de malentendido que pueda retrasar la

resolución de la incidencia.

♦ No va a impedir que el soporte telefónico desaparezca ya que los dos podría

coexistir perfectamente ya que podría ser usado por el usuario para notificar que ha

dado de alta una nueva incidencia.

♦ En el sistema actual al tener el usuario que ponerse en contacto con otra persona vía

telefónica para dar de alta sus incidencias esta sujeto a imprevistos del tipo , por

ejemplo, de que todas las líneas estén ocupadas retrasando la resolución de las

incidencias. Con el nuevo sistema no existirán estos problemas ya que al ser una

herramienta on-line las 24 horas del día los 365 días del año cualquier usuario podrá dar

de alta una incidencia en cualquier momento del día.

♦ Al ser el usuario quién de de alta sus propias incidencias podrá explicar

perfectamente la incidencia que esta sufriendo o el error mostrado por pantalla sin tener

que tener que explicárselo a otra persona y que sea esta quien de de alta la incidencias

ya que de este modo la información será menos precisa.

Debido a esta razones se pretende desarrollar una herramienta que sea eficaz y

responda a las necesidades de los usuarios pero , a la vez, tiene que ser muy fácil de


15

manejar ya que va dirigida a todos los usuarios de una empresa y a cierto tipo de

usuarios, como por ejemplo los integrantes del departamento jurídico, no tienen porque

tener unos altos conocimientos informáticos y tiene que ser una herramienta que desde

el primer día un usuario sepa manejar perfectamente ya que el objetivo final es facilitar

el trabajo a los empleados no complicárselo.

Además de estas razones las principales motivaciones para desarrollar esta aplicación

son:

� Elaborar una herramienta de software de desarrollo propio.

� Aumentar la eficacia y la productividad del los empleados en una empresa.

� Crear una herramienta que no suponga un gasto grande para la empresa.

� Hacer que el usuario se sienta más seguro y atendido con sus incidencias.


16

Identificación De Necesidades


17

Objetivos del sistema:

El objetivo fundamental que se persigue con esta herramienta es mejorar la gestión de la

resolución de incidencias. En todas las empresas cada día ocurren numerosas incidencias

de carácter informático que son necesarias solucionar en la mayor brevedad de tiempo

posible para que los usuarios puedan trabajar correctamente. Hasta ahora cuando surgía

una incidencia los usuarios normalmente tenían que llamar al servicio de atención al

usuario (S.A.U.), poner la incidencia y esperar a que esta fuera pasando por diversos

departamentos informáticos hasta que se solucionara.

En este método el usuario nunca podía ver el estado de su incidencia y además

dependían de los horarios que tuviera el S.A.U.; con esta herramienta se persigue

solucionar este problema proporcionando a los usuarios un sistema informático sencillo

que les permita a ellos mismos dar de alta una incidencia sin importar la hora que sea y

dándoles la oportunidad de ver el estado en el que se encuentra la misma y a los

departamentos informáticos encargados de resolver las incidencias les proporciona un

sistema en el que puedan ver las incidencias que surgen en tiempo real y sepan que

incidencia le corresponde resolver a cada departamento.

Estos objetivos podrían resumirse en 3 objetivos fundamentales:

- Agilizar el proceso de resolución de incidencias.

- Ofrecer a los usuarios la posibilidad de ver el estado de sus incidencias al instante.

- Ofrecer un servicio de resolución de incidencias las 24 horas del día sin depender del

horario de otros departamentos.


18

Alcance del sistema:

Debido a la gran cantidad de incidencias que ocurren en las empresas y a que algunas de

ellas pueden dejar a varias personas sin posibilidad de trabajar parece necesario el

desarrollo de una herramienta que permita la resolución de cualquier problema en la

mayor brevedad de tiempo posible.

Para poder realizar esta herramienta será necesario mecanizar todo el proceso de dar de

alta, modificar y cerrar incidencias mediante una aplicación que, a su vez, sea lo más

sencilla de utilizar posible ya que gran parte de los usuarios que darán de alta las

incidencias no tienen porque tener unos conocimientos informáticos altos.

Debido a este planteamiento las operaciones fundamentales que realizará la herramienta

serán alta, baja y modificaciones de todos los datos de las incidencias así como una

cuarta operación que será la validación de usuarios. Esta cuarta operación es

fundamental ya que cualquier trabajador de la empresa podrá acceder a la aplicación

pero es necesario distinguir entre un usuario de un departamento informático y un

usuario normal de manera que a estos últimos solo se les permita dar de alta incidencias

mientras que los primeros puedan realizar cualquier de las operaciones que permite la

aplicación.

Todos los datos de las incidencias estarán almacenados en una base de datos de manera

que irá creando un histórico de incidencias y serán borradas cuando transcurra cierto

tiempo desde su resolución.


19

Tipología de los usuarios:

- Los usuarios de la herramienta estarán diferenciados en dos grupos:

� Usuarios administradores o avanzados: esta formado por el conjunto de

usuarios encargados de resolver las incidencias. Este tipo de usuario tendrá

control total sobre la aplicación de manera que podrá dar de alta, modificar

o eliminar incidencias y tienen un conocimiento alto de informática.

� Usuarios estándar: esta formado por el resto de usuarios pertenecientes a

departamentos ajenos al departamento informático. Este tipo de usuario

únicamente podrá dar de alta incidencias y se considera que sus

conocimientos informáticos son de nivel medio-bajo.

Restricciones:

Vamos a tener dos tipos de restricciones a la hora de realizar esta aplicación:

- Restricciones técnicas: ya que será necesario un servidor Web desde el cual esté

instalada la aplicación así como su conexión en cada puesto dos tablas de datos para

contener por un lado la información concerniente a las incidencias pendientes de

resolver y por otro toda la información de los usuarios.

También será necesario que en cada puesto de trabajo esté instalada una Java virtual

Machine para que la aplicación funcione correctamente y el desarrollo de una

interfaz lo mas intuitiva posible.

- Restricciones de tiempo: el tiempo en el cual las incidencias deben llegar a los

responsables de resolverlas tiene que ser el menor posible ya que los usuarios

necesitan poder trabajar y que todo funcione correctamente.


20

Organización y funciones empresariales: Esta herramienta informática es válida para cualquier tipo de empresa pero tomamos esta

organización que es la más común en la mayoría de las empresas.

- Consejo de Administración: encargado de la toma de decisiones en la empresa y que

ejerce un control sobre los niveles inferiores.

- Planificación: este departamento se encarga de realizar las estrategias que seguirá la

empresa tanto de cara a ventas a clientes como a nivel interno.

- Producción: este departamento esta subdividido en otros tres:

� Operaciones: tomarán las decisiones correspondientes a la cantidad

producto que será fabricado.

� Fabricación: son los encargados de fabricar el producto.

� Logística: se encargan de todas las actividades que se suceden desde

que el producto esta en el almacén hasta que llega a los clientes.

Consejo de Administración

Planificación Producción Comercial RRHH Sistemas Informáticos

Operaciones Fabricación Logística Contabilidad Facturación

Consejo de Administración

Comercial RRHH Sistemas Informáticos

Logística


21

- Comercial: este departamento va a ser el encargado de representar a la empresa de

cara a posibles clientes así como de diseñar posibles ofertas para captar nuevos

clientes.

- Recursos humanos: este departamento se encarga de tener todos los datos de los

empleados así como de realizar entrevistas de trabajo y seleccionar a nuevos

trabajadores.

- Contabilidad: es el departamento encargado de manejar todas las cuentas de la

empresa así como realizar informes de la situación financiera de la empresa.

- Facturación : este departamento manejara la información relacionada con las facturas

que tienen los clientes con la empresa como las que tiene la empresa con los

proveedores y, además, informarán al departamento de contabilidad de las nuevas

facturas contraídas o las pagadas.

- Sistemas Informáticos: los integrantes de este departamento realizaran tres funciones

principales.

� Mantenimiento de las bases de datos y de los equipos informáticos

(tanto de PC como de servidores).

� Resolución de incidencias.

� Desarrollo de nuevas aplicaciones.

Antecedentes: Debido al gran numero de incidencias que ocurren a lo largo del día en las empresas y a la

necesidad de resolverlas en el menor tiempo posible es conveniente el desarrollo de una

herramienta informática que permita a las personas encargadas de solucionar las incidencias

tener notificación de ellas en el menor tiempo posible sin que estas pasen por departamentos

intermedios.


22

Análisis de Requisitos


23

2.1 Reconocimiento del problema. 2.1.1 Ámbito. Actualmente todo el proceso de gestión de las incidencias se realiza de manera manual

poniéndose los usuarios en contacto con el S.A.U. mediante vía telefónica y éstos, a su

vez, se ponían en contacto con los departamentos pertinentes. Debido a esto es

necesario automatizar el proceso desde que un usuario pone una incidencia hasta que los

responsables de solucionarla la dan por cerrada.

2.1.2 Contexto general. Todo el flujo e intercambio de datos y de información que se realiza desde que un

usuario pone una incidencia hasta que queda resuelta está reflejado en la siguiente

imagen.


24

USUARIOS RESPONSABLES INFORMATICOS

APLICACIÓN WEB

BBDD


25

2.2 Lista de requisitos.

FECHA: 10-06 VERSIÓN: V.1.0 ESTADO: DEFINITIVO FUENTE Gestión de usuarios PRIORIDAD Alta CATEGORIA : Seguridad IDENTIFICADOR DE REQUISITO: R01 TITULO: Control de acceso a la información.

DESCRIPCIÓN:

Deberá existir un control de acceso debido a que diversas actividades o

acciones de la herramienta no estarán disponibles para ciertos usuarios.

MEDICION:

Para cumplir existirá un sistema de password que deberá ir siendo

modificado periódicamente.

Los usuarios pertenecerán a un grupo de los dos posibles para el sistema

(usuarios de departamento informático o estándar).

BENEFICIO:

Con esto se pretende evitar que los usuarios de tipo estándar puedan

modificar datos de otras incidencias o las cierren sin que estas estén

resueltas.

REQUISITOS RELACIONADOS:


26

FECHA: 10-06 VERSIÓN: V.1.0 ESTADO: DEFINITIVO FUENTE Gestión de usuarios PRIORIDAD Alta CATEGORIA : Seguridad IDENTIFICADOR DE REQUISITO R02 TITULO: Control de privacidad de datos.

DESCRIPCIÓN:

Se debe asegurar a los usuarios que los datos cedidos por su parte al

sistema se emplearán sólo para uso interno y no serán divulgados dentro

de la empresa o a gente externa a la misma cumpliendo asi la

LOPAD(Ley Orgánica de Protección de Datos).

MEDICION:

Para cumplir con este requisito se firmará un contrato de manera que los

departamentos informáticos se comprometen a no hacer pública ninguna

información que proporcione el usuario.

BENEFICIO:

Con esto se persigue que los usuarios confíen más en el sistema y

proporcionen todos los datos necesarios sin temor a que alguien pueda

acceder a dichos datos.

REQUISITOS RELACIONADOS: R01.


27

FECHA: 10-06 VERSIÓN: V.1.0 ESTADO: DEFINITIVO

FUENTE Gestión de usuarios PRIORIDAD Media CATEGORIA : Operativos IDENTIFICADOR DE REQUISITO R03 TITULO: Creación y optimización del acceso a las consultas

DESCRIPCIÓN:

Este requisito se refiere a que la herramienta debe tener un perfecto

funcionamiento evitando posibles cuelgues de la herramienta así

proporcionando una respuesta a una petición por parte de un usuario en el

menor tiempo posible.

MEDICION:

El tiempo de respuesta a las peticiones de los usuarios no deberá superar

los 15-20 segundos.

Se realizarán pruebas realizando múltiples peticiones a la vez para

comprobar que no se produzcan sobrecargas.

BENEFICIO:

Gracias a estas pruebas se obtendrá una herramienta con un

funcionamiento totalmente óptimo y evitando que se produzcan cuelgues

debido a que se lancen numerosas peticiones al mismo tiempo al sistema.



28


FUENTE Gestión de usuarios PRIORIDAD Media CATEGORIA : Operativos IDENTIFICADOR DE REQUISITO R04 TITULO: Actualización información.

DESCRIPCIÓN:

Los datos de las incidencias se actualizarán en tiempo real en caso de

que se tenga que realizar alguna modificación en las mismas por

cualquier motivo.

MEDICION:

Se realizarán pruebas modificando diversa información de algunas

incidencias y comprobando que el tiempo de actualización desde que se

realiza la modificación no sea superior a los 5-10 segundos.

BENEFICIO:

Gracias a este requisito se evitará que algunos departamentos no puedan

resolver determinadas incidencias porque tengan información obsoleta de

las mismas.



29


FUENTE Gestión de usuarios PRIORIDAD Media CATEGORIA : Seguridad IDENTIFICADOR DE REQUISITO R05 TITULO: Control de la integridad de los datos.

DESCRIPCIÓN:

Este requisito se refiere a que la herramienta debe controlará el acceso a

los datos para evitar que esta sea alterada.

MEDICION:

Usuarios que, en teoría, no tendrían permiso para hacerlo intentaran

modificar la información para comprobar que el sistema es fiable y no se

lo permite.

BENEFICIO:

Con este requisito se pretende conseguir una mayor seguridad y evitar

posibles alteraciones de la información.

REQUISITOS RELACIONADOS: R01


30


FUENTE Gestión de usuarios PRIORIDAD: Baja CATEGORIA : Fiabilidad IDENTIFICADOR DE REQUISITO R06 TITULO: Control de incidencias

DESCRIPCIÓN:

Este requisito almacenará el número de incidencias que han puesto los

usuarios en su base de datos.

MEDICION:

Cada vez que un usuario de de alta una incidencia esta se almacenará

directamente en su base de datos.

BENEFICIO:

Con este requisito se conseguirá ver cuales son las ubicaciones en las

cuales los usuarios sufren más incidencias para poder realizar trabajos de

mantenimiento en las mismas y ver porque ocurre esa situación.



31

2.3 Modelo lógico del nuevo sistema.

2.3.1 Procesos del usuario estándar.

2.3.1.1 Proceso Entrada password.

Cada vez que un usuario accede a la aplicación deberá introducir un password.

Una vez introducido se validará con la base de datos de usuarios para determinar el tipo

de usuario que es y dependiendo de esto podrá realizar unas acciones u otras en los

siguiente procesos.

2.3.1.2 Proceso Selección opción.

Después de validar el usuario este proceso dará al usuario una serie de opciones que

serán dar de alta, modificar o consultar una incidencia y pedirá al usuario que indique

cual de ellas desea. Una vez que el usuario seleccione una, pasará al proceso elegido.

2.3.1.3 Proceso Dar de alta incidencia.

A través de este proceso el usuario podrá dar de alta cualquier incidencia que le surja.

Para hacerlo el proceso le requerirá información acerca de la incidencia y, una vez que

esta sea proporcionada por el usuario, se dará de alta dicha incidencia en la base de

datos hasta que esta sea resuelta.

2.3.1.4 Proceso Consulta de incidencia.

Este proceso servirá para que los usuarios puedan consultar la información de sus

incidencias y ver en que estado se encuentran.

Para ello una vez que el usuario a escogido en el menú esa opción el usuario indicará

cual es la incidencia que desea consultar y el sistema procederá a realizar una consulta a

la base de datos de las incidencias y a recoger toda la información de la misma. Una vez

hecho esto la información recogida de la incidencia será presentada al usuario.


32

2.3.1 Procesos del usuario de departamento informático.

2.3.1.1 Proceso Entrada password.

Cada vez que un usuario accede a la aplicación deberá introducir un password.

Una vez introducido se validará con la base de datos de usuarios para determinar el tipo

de usuario que es y dependiendo de esto podrá realizar unas acciones u otras en los

siguiente procesos.

2.3.1.2 Proceso Selección opción.

Después de validar el usuario este proceso dará al usuario una serie de opciones que

serán dar de alta, modificar o consultar una incidencia y pedirá al usuario que indique

cual de ellas desea. Una vez que el usuario escoja una pasará al proceso seleccionado.

2.3.1.3 Proceso Dar de alta incidencia.

A través de este proceso el usuario podrá dar de alta cualquier incidencia que le surja.

Para hacerlo el proceso le requerirá información acerca de la incidencia y, una vez que

esta sea proporcionada por el usuario, se dará de alta dicha incidencia en la base de

datos hasta que esta sea resuelta.

2.3.1.3 Proceso Modificar incidencia.

En este proceso el usuario podrá cambiar datos de cualquier incidencia ya que al ser un

usuario de un departamento informático podrá modificar tanto los datos acerca del

usuario como los de la propia incidencia en si, es decir, podrá cambiar datos acerca de la

extensión telefónica del usuario así como modificar el estado de la incidencia

Para ellos el usuario deberá introducir la nueva información y una vez hecho esto el

sistema actualizará la base de datos de las incidencias.


33

2.3.1.4 Proceso Consulta de incidencia.

Este proceso servirá para que los usuarios puedan consultar la información de sus

incidencias y ver en que estado se encuentran.

Para ello una vez que el usuario a escogido en el menú esa opción el usuario indicará

cual es la incidencia que desea consultar y el sistema procederá a realizar una consulta a

la base de datos de las incidencias y a recoger toda la información de la misma. Una vez

hecho esto la información recogida de la incidencia será presentada al usuario.

2.3.1.6 Cierre de incidencia.

Este proceso sirve para cerrar una incidencia y sólo se podrá acceder a él a través del

proceso consulta que les aparece a todos los usuarios pertenecientes al grupo de

usuarios de un departamento informático.

Una vez que los usuarios entren dentro del proceso de consulta el usuario debe indicar

que el estado de la petición será modificado poniéndola como resuelta y, una vez hecho

esto, se actualizará la base de datos de los usuarios tomando a la incidencia como que

esta resuelta.


34

2.4 Diagramación.

0.

SISTEMA DE GESTIÓN DE INCIDENCIAS

USUARIO TIPO

ESTÁNDAR

USUARIO TIPO

AVANZADO

Opciones disponibles, Petición de password y usuario. Petición criterio e información para búsquedas, petición daros para modificar o dar de alta incidencias

Opciones elegidas, Password y usuario. Criterio e información para búsquedas, Daros para modificar o dar de alta incidencias




35

Contexto de usuarios estándar.

0.


USUARIO

TIPO ESTÁNDAR

Opciones disponibles, Petición de datos a mostrar. Respuesta

Opción deseada, incidencia a dar de alta, Incidencia, datos a modificar


36

Contexto usuarios de departamento informático.

0.


USUARIO

TIPO AVANZADO

Opciones disponibles, Petición de datos a mostrar. Respuesta, incidencia a dar de baja, departamento al que se le asigna la incidencia

Opción deseada, incidencia a dar de alta, Incidencia, datos a modificar, confirmación de cierre, petición departamento e incidencia a asignar


37

2.4.1 Conceptual.

4 Cierre

incidencia

Usuario estándar

Opción deseada

Menú de opciones

Confirmación de cierre

1.1 Entrada password

Password

Usuarios

validación Respuesta

Usuario no aceptado

Incidencia a dar de alta

Petición de información

Respuesta Incidencia Datos a modificar

3 Gestión

Información Usuario

avanzado

Usuario avanzado

Opción deseada

Menú de opciones



Respuesta Incidencia Datos a modificar

Petición de cierre

Incidencia

Eliminar incidencia

Actualizar

Incidencia a cerrar

2 Gestión

Información Usuario estándar


38

2.4.1.1 Explosión Gestión información usuario estándar.

2.1 Selección opción

Acción deseada

Menú de opciones

Incidencia

Petición de información de la incidencia

Respuesta

2.2 Dar de alta incidencia

2.3 Consulta de incidencia

información de la incidencia

Alta de incidencia

Opción deseada

Opción deseada

Incidencia deseada

Información deseada

Incidencia

Opción deseada


39

4.1.2 Explosión Gestión información usuario avanzado.

3.1 Selección opción

Acción deseada

Menú de opciones


Respuesta


3.4 Consulta de incidencia

Alta de incidencia

Opción deseada

Opción deseada

Incidencia deseada


Incidencia

3.3 Modificar incidencia

Datos a modificar actualizar

Opción deseada

3.5 Petición de cierre

Opción deseada

Petición de cierre

información de la incidencia

Incidencia


40

Bases de datos

Entidades necesarias.

• USUARIOS (cod_usuario, password, perfil, nombre, apellido1, apellido2,

teléfono, correo, cod_departamento)

Esta tabla contendrá la información sobre que tipo de privilegios tendrá cada usuario

en la aplicación según el tipo de usuario que sea (usuario estándar o avanzado). Sus

atributos son:

� Cod_usuario: es el número con el que se identifica a cada usuario de

manera inequívoca.

� Password: es el password de cada usuario.

� Perfil: indica si el usuario es un usuario estándar o si pertenece a un

departamento informático y, por tanto, es un usuario avanzado.

� Nombre :es el nombre del usuario

� Apellido1: es el primero apellido del usuario.

� Apellido2: es el segundo apellido del usuario.

� Teléfono: es la extensión del usuario.

� Correo: dirección de correo dentro de la empresa.

� Cod_departamento: número que identifica al departamento al que

pertenece el usuario.

La clave de esta TABLA es cod_usuario, que también es clave extranjera con

INCIDENCIA y cod_departamento es clave extranjera con DEPARTAMENTO.


41

• INCIDENCIA (id, cod_usuario, cod_departamento, fecha_alta,

fecha_resolución, descripción, criticidad, estado, comentarios)

Esta tabla contendrá la información relativa a las incidencias que en ese momento

estén activas. Sus atributos son:

� Id: es el código con el que se identifica de manera inequívoca a cada

incidencia.

� Cod_usuario: sirve para identificar al usuario que ha puesto la incidencia.

� Cod_departamento: identifica al departamento que se encarga de resolver

la incidencia.

� Fecha_alta: es la fecha en la que se dio de alta la incidencia.

� Fecha_resolución: es la fecha en la que se dio por resuelta la incidencia.

� descripción: contiene una breve descripción sobre la incidencia.

� criticidad: identifica la criticidad de la incidencia.

� estado: indicia es el estado actual de la incidencia; si esta por ejemplo,

como trabajo en curso o si esta pendiente de asignar.

� Comentarios: muestra los comentarios que se añaden cada vez que la

incidencia es modificada.

La clave de esta tabla el id que será la clave principal pero, a su vez, tendrá como claves

extranjeras cod_usuario con la tabla de USUARIOS y cod_departamentos con la tabla

de DEPARTAMENTOS.

• DEPARTAMENTOS (cod_departamento, id, cod_usuario, nom_departamento)

Esta tabla contendrá la información relativa a los departamentos encargados de

resolver las incidencias así como que incidencias tiene cada uno.

� Cod_departamento: es el código con el que se identifica de manera

inequívoca a cada departamento.

� Id: es el código con el que se identifica de manera inequívoca a cada

incidencia.

� Cod_usuario: sirve para identificar al usuario que ha puesto la incidencia.

� Nom_departamento: nombre del departamento.


42

La clave de esta tabla será cod_departamento que será la clave principal pero id será

clave extranjera con la tabla INICIDENCIA y cod_usuario con la tabla USUARIOS.

2.5 DIAGRAMA M.E.R. 2.5.1 RELACIONES. R1: Un usuario tendrá solamente un código de usuario y un código de usuario será

solamente de un usuario.

R2: Cada usuario tendrá un nombre y unos apellidos aunque alguno de ellos podría

repetirse con los de otro usuario.

R3: Cada incidencia tendrá una fecha de alta y una fecha de resolución y estas fechas

podrán estar en varias incidencias.

R4: Un departamento tendrá asignadas varias incidencias pero una incidencia sólo

estará asignada a un departamento.

R5 Cada incidencia tendrá un estado pero ese estado podrá estar en varias incidencias.

R6: A cada incidencia le corresponderá una criticidad y una criticidad estará en varias

incidencias.

R7: Una incidencia tendrá un código de incidencia y dicho código será solamente de esa

incidencia.

R8: Una incidencia tendrá una descripción y un comentario que podrían aparecer en

otras incidencias.

R9: Cada usuario tendrá un número de teléfono que podrá ser compartido por varios

usuarios.


43

R10: Una dirección de correo electrónico podrá ser usada por varios usuarios pero un

usuario sólo tendrá una dirección.

R11: Un usuario será de un departamento y en un departamento habrá varios usuarios.

R12: Un usuario tendrá un perfil para la aplicación y varios usuarios podrán tener el

mismo perfil.

R13 Un usuario tendrá un password que le corresponderá solo a él.

R14 Una incidencia corresponderá a un único usuario pero un usuario podrá tener

varias incidencias.


44

2.5.2 DIAGRAMA.

2.5.3 PROPAGACIÓN RELACIONES. 2

apellido1 cod_usuario, apellido1 m

nombre cod_usuario, nombre m

cod_usuario

estado

id

cod_departameno

tipo

nom_departamento

descripción

criticidad

nombre R2

m

R14

R3

R8

R3

m

m R5

m

R4

R11

m m

R12

m

apellido2

m

apellido1

m

Fecha_resolución

Fecha_alta

m

m

R6

comentario m

m

m

m

teléfono

R9

m

correo

R10

password

R13


45

3

4

5

6

7

criticidad id, criticidad m

cod_departamento id, cod departamento m

fecha_resolución id, fecha_resolución m

apellido2 cod_usuario, apellido2 m

fecha_alta id, fecha_alta m

estado id, estado m

id,criticidad criticidad m


46

8

9

10

11

12

13

cod_usuario, password

teléfono cod_usuario, teléfono m

cod_usuario,cod_departamento cod_departameno m

id, descripción descripción m

cod_usuario,correo correo m

tipo Cod_usuario,tipo


47

2.5.4 DIAGRAMA RESULTANTE.

cod_usuario,nombre,apellido1, apellido2,teléfono,correo,

cod_departamento, perfil,password

id,fecha_alta, fecha_resolucion,criticidad,estado,cod_departamento, cod_usuario,

descripción,comentarios

cod_departamento, nom_dep,

teléfono,correo

m

m

m

INCIDENCIA

USUARIO

DEPARTAMENTO


48

2.5.4 BASES DE DATOS RELACIONADAS.

Incidencia ( id, fecha_alta, fecha_resolucion, criticidad, estado, cod_departamento,

cod_usuario, descripción, comentarios).

En esta tabla la clave es el código de incidencia ya que mediante dicho código se

identificara de manera inequívoca cada incidencia y las claves extranjeras serán

cod_usu que contiene el código de usuario que ha puesto la incidencia y que relacionará

esta tabla con la tabla de usuario y cod_departamento que contendrá el código de

departamento encargado de resolver la incidencia y relacionará esta tabla con la tabla

departamento. La tabla incidencia contendrá toda la información relativa a las

incidencias como el usuario que la ha puesto, el departamento encargado de resolverla,

la descripción de la incidencia, su criticidad, etc…

Usuario (cod_usuario, password, nombre, apellido1, apellido2, teléfono, correo,

cod_departamento, perfil).

En esta tabla la clave es cod_usu ya que mediante dicho código se identifica a cada

usuario y dos usuarios no pueden tener el mismo código, cod_usu también es clave

extranjera con la tabla incidencia y cod_departamento es clave extranjera con la tabla

departamento. Esta tabla contiene todos los datos de los usuarios tales como su código,

su password, su nombre, sus apellidos, etc…

Departamento (cod_departamento, nombre, teléfono, correo).

La clave de esta tabla es cod_departamento ya que es el código por el que se identifica a

cada departamento y, a su vez, también es clave extranjera con la tabla usuario. Esta

tabla contiene todos los datos relacionados con los departamentos los cuales son su

código, su nombre y su teléfono y correo departamental.


49

Estudio de la arquitectura


50

ESPECIFICACIÓN DE LAS ALTERNATIVAS

3.1.1.1 Tecnología de comunicaciones.

Existen varias posibles alternativas para realizar toda la infraestructura de

comunicaciones que necesita el proyecto aunque las tres principales serían las

siguientes:

3.1.1.1.1 Alquiler de servidor.

Esta alternativa consistiría en el alquiler de un servidor para uso exclusivo del cliente de

manera que todos los recursos de hardware y software serían para uso exclusivo del

cliente ya que no estaría compartido con nadie más.

3.1.1.1.2 Ventajas.

Ancho de banda dedicado ya que no compite por el.

Flexibilidad para la administración.

Posibilidad de realizar cambios de software libremente.

Mejor tiempo de respuesta.


51

3.1.1.1.3 Otras ventajas.

Ahorro de personal y hardware.

Uso exclusivo del servidor.

Menos coste que la adquisición de un servidor propio.

Actualizaciones de software.

3.1.1.1.4 Inconvenientes.

Menor control del servidor.

Dificultades a la hora de realizar cambios de hardware.

Confidencialidad no garantizada al 100%.

3.1.1.1.5 Servicios.

Esta alternativa abarca un alto número de grados de servicio los cuales supondrán un

coste diferente para la empresa y es que esta solución puede variar desde alquilar

simplemente el servidor hasta contratar un variado número de servicios aparte, tales

como administración del servidor o mantenimiento.

El coste principal de esta alternativa va a recaer, sobre todo, en dos apartados que son el

espacio físico que ocupen las maquinas y el ancho de banda requerido.

El espacio físico del servidor se divide en dos partes:

- Caja de servidor estándar: el servidor propiamente dicho cuyo precio

variará dependiendo de las características que posea pero cuyo alquiler puede rondar los

80-90 euros mensuales.

- Armario rack: armario donde estará colocado el servido dentro del CPD (Centro


52

de Proceso de Datos) cuyo precio variará según el tamaño del rack pero que podría ir

desde uno 500 hasta unos 800 euros. En caso de que ya se disponga de un armario rack

en el CDP donde colocar el servidor no sería necesario el alquiler de uno.

En cuanto al ancho de banda el precio también variará en función de las necesidades

que se dispongan cubrir el precio podría variar desde unos 5 euros al mes por 1 giga de

ancho de banda hasta los 280 euros por 100 gigas.

3.1.1.1.6 Características.

Monitorización de los equipos 24X7.

Consumo eléctrico garantizado.

Soporte técnico 24X7.

Conectividad a switches.

Aire acondicionado redundante.

Protección por firewall.

3.1.1.2 Alquiler servicios. Esta alternativa consiste en alquiler de un servidor para la aplicación del cliente pero no

teniendo un uso exclusivo del servidor.

3.1.1.2.1 Ventajas.

No es necesario invertir en mantenimiento del servidor.

No es necesario el alquiler de un armario de servidor ni ubicarlo dentro del CPD.

Mayor capacidad para concentrarse en el negocio sin preocuparse de los servidores.

Disponibilidad ya que la empresa a la que ofreciera su servidor para la aplicación

garantizaría su correcto funcionamiento así como personal cualificado en el uso de

servidores.


53

3.1.1.2.2 Otras ventajas.

Ahorro de personal y hardware.

Menos coste que la adquisición o alquiler de un servidor propio.

Actualizaciones de software.


Uso no exclusivo del servidor.

Menor control del servidor.

Confidencialidad no garantizada al 100%.

Dificultar para realizar cambios de software y hardware.

3.1.1.2.4 Especificaciones técnicas.

Para esta alternativa sería necesario:

� Alquiler servidor que podría ser de diferentes marcas como Sun o Intel.

� Sistema operativo Windows.

� Servidor web Apache.

� Garantía de soporte técnico con un servicio 24x7.

� Espacio en un rack.

� Garantía de un ancho de banda.

� Acceso remoto al servidor para que en caso de tener que realizar algún

cambio en el mismo no sea necesario desplazarse.

� Realización de copias de seguridad de la base de datos.

� Mantenimiento del servidor.


54

3.1.1.2.5 Servicios.

En esta alternativa existe un amplio abanico de posibilidades ya que se puede variar

desde el modelo y tipo de servidor hasta del software que queremos que lleve instalado.

El coste principal de esta alternativa va a recaer, sobre todo, en el trafico que tenga que

soportar el servidor y la capacidad que queremos que tenga por lo que el precio

requerido podrá variar mucho en estas dos características así como del tiempo por el que

contratemos el servicio.

El precio para un servidor de 1 GB y que soporte un tráfico de 15 GB será

aproximadamente de 19 euros para 1 mes, 54 para 3 meses y 150 para 1 años; sin

embargo un servidor de 30 GB y con un tráfico de 300 GB el precio sería 120 euros

para 1 mes, 300 para 3 meses y 1100 para un año.

3.1.1.3 Compra de un servidor propio.

La tercera y última alternativa consistiría en la adquisición de un servidor propio con

recursos y aplicaciones propios de la empresa lo que nos proporcionaría una libertad

total a la hora de realizar modificaciones o actualizaciones.

Sería necesario la contratación de personal para que se encargue del servidor (en caso

de que no se cuenta ya con dicho personal) y proporcione un servicio técnico en caso de

que el servidor falle así como de la realización de copias de seguridad.

3.1.1.3.1 Ventajas.

Uso exclusivo del servidor.

Total control del servidor.

Libertad para realizar modificaciones de hardware y software.


55

Confidencialidad garantizada al 100%.


Precio alto.

Es necesario ubicarlo dentro del CPD y comprar un rack en caso de que no exista

ninguno disponible para ubicar el nuevo servidor.

3.1.1.3.3 Especificaciones técnicas.

� Alquiler servidor que podría ser de diferentes marcas como Sun o Intel.

� Sistema operativo Windows.

� Servidor web Apache.

� Garantía de soporte técnico con un servicio 24x7.

� Espacio en un rack.

� Garantía de un ancho de banda.

� Acceso remoto al servidor para que en caso de tener que realizar algún cambio

en el mismo no sea necesario desplazarse.

� Realización de copias de seguridad de la base de datos.

� Mantenimiento del servidor.

3.1.1.3.4 Precio.

El precio va a variar mucho dependiendo de la alternativa escogida.

� Para alquiler un servidor existen una gama muy amplia de posibles precios

dependiendo de las características de un servidor ya que un servidor de 1 GB de

espacio y 15 GB de tráfico podría costar unos 150 euros mensualmente mientras

que otro con 30 GB de espacio y 300 GB de tráfico costaría entorno a los 1100


56

euros.

� Si lo que deseamos es simplemente alquilar los servicios de un servidor de otra

compañía el precio podría oscilar entre los 50 euros al año un servidor básico hasta

los 200 uno mas avanzado.

� Por último la comprar de un servidor aumentaría mucho más el coste de la

herramienta ya que la comprar un servidor podría llegar a costar hasta los 3000

euros aunque a largo plazo sería la opción más rentable de las tres.

3.1.1.4 Elección de una alternativa.

La elección mas adecuada sería la primera o la tercera ya que en la tercera habría

muchas dificultades para poder realizar cualquier cambio en el servidor y además el uso

del mismo no sería exclusivo de la empresa.

En cuanto a las otras dos opciones ya dependería de los recursos de la empresa ya que la

opción ideal seria la tercera pero seria necesario un desembolso importante de dinero

para la adquisición del servidor, de personal cualificado, espacio dentro del CPD y

mantenimiento de las aplicaciones así como instalación de actualizaciones.

3.1.1.2 Servidor WEB.

Para poder utilizar la herramienta será necesario un servidor Web que soporte servlets y

jsp de manera que los usuarios puedan realizar las consultas, altas y bajas de incidencias

a través de la red. Tres posibles alternativas son:

3.1.1.3 Apache Tomcat.

Con capacidad para servlets y jsp, soportado por todos los sistemas operativos y es

gratuito.


57

3.1.1.4 IIS.

Servidor de Microsoft con capacidad para servlets y jsp pero con limitación exclusiva a

sistemas operativos de Microsoft.

3.1.1.5 Sun´s Java Web Sever.

Escrito enteramente en java soportando servltes y jsp pero en desuso hoy en día.

3.1.2 Sistemas Gestores de Bases de Datos.

Para manejar la información que contienen las bases de datos actualmente existen

muchas herramientas que mejoran el uso de las mismas, sus seguridad y evitan la

redundancia. Algunas de estas herramientas son:

3.1.2.2 Microsoft SQL Server.

Herramienta de gestión de bases de datos para Windows sencilla de utilizar e intuitiva

3.1.3.2 Access.

Sencillo e intuitivo de fácil migración a SQL Server.

3.1.3.3 Mysql.

Herramienta muy potente y usada hoy en día que permite la administración de las tablas


58

a través de Internet. Su distribución es gratuita.

3.1.3.4 IBM DB2.

Similar a Mysql pero no es gratuito.

3.1.3.5 Oracle.

Herramienta de gestión de bases de datos líder del mercado.

3.1.4 Herramientas de desarrollo.

Para desarrollo existen una multitud de herramientas pero hay que ir adaptándolas según

las necesidades y el avance del desarrollo del proyecto. Algunas de estas herramientas

son:

3.1.4.1 Java Servlets.

Programas dinámicos y portables ejecutados en el servidor y que pueden compartir

datos entre ellos. Interactúan con los clientes Web a través de un mecanismo

implementado por un contenedor de servlet con gran rendimiento y que no se cargan

con cada instancia del cliente.

3.1.4.2 HTML.

El lenguaje java esta orientado a objetos que para su funcionamiento solo requiere la

instalación de la Java Virtual Machine y genera bytecode al compilar.


59

3.1.4.3 Java JSP.

Esta herramienta ofrece la posibilidad de mezclar HTML dinámico con HTML estático.

Mediante los JSP es posible crear plantillas html que realicen rutinas java para generar

paginas hmtl. Están basados en tecnologías servlets y funcionan en cualquier servidor

que tenga dicha tecnología.

3.1.4.4 Middleware.

Esta capa de software será la encargada de realizar las operaciones de gestión y control

de las comunicaciones entre los puestos cliente y el servidor.

Para esta capa hay diferentes tipos de arquitecturas de comunicación que se utilizarán

dependiendo de la acción que se requiera:

3.1.4.4.1 Llamada a procedimiento remoto.

Llamada a un subprograma desde el puesto cliente que el servidor tendrá que ejecutar.

El middleware se encargará del control de la comunicación.

3.1. 4.4.2 Acceso remoto.

Llamada a aplicación para la realización de las diferentes acciones permitidas por la

aplicación. El Middelware se encargará de la gestión de la llamada al programa.


60

3.1.4.4.3 Conversacional.

Petición a la aplicación y respuesta por parte de esta; el middleware controlará la

conversación.

El middleware para el acceso a las bases de datos será JDBC. Para la conexión con la

base de datos la aplicación requerirá el controlador de la misma contenido en la clase

DriverManager.

Toda la arquitectura de una aplicación Web deberá completar los tres niveles de

presentación, lógica de negocio y acceso a los datos en un modelo cliente-servidor.


61

3.1.5 Arquitectura.

3.1.5.1 Elección de la arquitectura.

Para esta aplicación la arquitectura que mejor se adecua a las necesidades que debemos

cubrir y al tipo de aplicación que estamos desarrollando el una arquitectura cliente-

servidor.

Este tipo de arquitectura va a implicar la distribución del software de la aplicación entre

las estaciones de trabajo y el servidor.

3.1.5.2 Niveles.

Nuestra aplicación se dividirá únicamente en dos niveles que son el nivel de datos y el

de presentación-aplicación.

3.1.5.2.1 Datos.

Es el software encargado de la gestión de la recuperación y el almacenamiento de datos.

Los usuarios no tendrán una copia de los datos sino que todos estarán almacenados en el

servidor de manera que puedan acceder a ellos mediante un sistema gestor de bases de

datos como MySQL u Oracle. Para realizar las operaciones los puestos cliente pedirán

los datos al servidor y una vez que este se los dé podrá trabajar con ellos. En caso de

que los datos fueran modificados el servidor los actualizará. En resumen las funciones

de este nivel serán:

- Almacenamiento de la información.

- Mantenimiento de la información.

- Acceso a la información mediante el gestor de bases de datos.


62

3.1.5.2.2 Aplicación.

Este nivel está formado por el software que implementa las funciones de negocio de

nuestra aplicación ya que en caso de que algún usuario tenga que realizar tareas

complejas como la eliminación de registros de la base de datos que necesite un equipo

mas potente que el resto por lo que es necesario separar la parte operacional de la

aplicación de la parte gráfica, de manera que la primera pueda residir en un equipo

potente y la parte gráfica pueda funcionar en cualquier equipo. Las funciones de este

nivel son:

- Recepción de datos.

- Validación de datos.

- Llamas al nivel de datos.

3.1.5.2.3 Presentación.

Este nivel lo forma el software que se encarga de la toma de datos así como de

presentarlos al usuario. Las funciones de este nivel son:

- Navegación por las ventanas.

- Validación de datos.

- Detección errores.


63

Tanto en las estaciones de usuario como en un servidor, los cuales estén interconectados

a la red podría ejecutarse estos niveles de aplicación. El uso de la arquitectura basada en

componentes nos proporciona las siguientes ventajas:

- Interfaz de gráfica para la presentación de datos al usuario.

- Función distribuida entre las estaciones de usuario y el servidor.

- Permite al cliente determinar el diálogo o la navegación para realizar los

servicios en lugar de ser el Mainframe quien lleve el control de flujo de las

operaciones.

- Encapsulamiento de servicios.

- Multitarea ya que el cliente podrá realizar varias operaciones asíncronas

al mismo tiempo.

- Integridad.

- Facilidad de escalabilidad.

- Posibilidad de encadenar diversos software del cliente con los servicios

HARDWARE

S.O.

NIVEL PRESENTACION

NIVEL APLICACION NIVEL DATOS


64

requeridos por lo que las funciones de negocio están bien delimitadas.

- Reutilización de los componentes.

3.1.5.3 Modelos de la arquitectura cliente-servidor.

3.1.5.3.1 Presentación local.

El nivel de presentación solo reside en el cliente.

La aplicación y la gestión de datos están en el servidor.

Usado para cliente ligero (HTML) y utiliza el protocolo HTTP.

Complejo de desarrollar.

3.1.5.3.2 Presentación distribuida.

Niveles de aplicación y gestión de datos residentes en el servidor.

Usado tanto para clientes pesados (Visual Basic) como ligeros (HTML) y utiliza

protocolos HTTP y TCP/IP.

Coste bajo en el desarrollo.

3.1.5.3.3 Aplicación local.

El nivel de presentación y aplicación reside en el cliente y los datos se encuentran en el

servidor.

Fácil de desarrollar.


65

3.1.5.3.4 Aplicación distribuida.

El nivel de presentación reside en el cliente, el de aplicación en el servidor y el de

aplicación distribuido entre el cliente y el servidor.

3.1.5.3.5 Gestión de datos distribuida.

Los niveles de aplicación y presentación residen totalmente en el cliente y la ubicación

de los datos queda distribuida entre el cliente y el servidor.

La ubicación de los datos es transparente para la aplicación.

3.1.6 Otros servidores.

3.1.6.1 Servidores de bases datos.

En este servidor junto con los puestos clientes se almacenarán las tablas de las bases de

datos.

3.1.6.2 Servidor de correo.

Permite el intercambio de correo electrónico entre diferentes usuarios.

3.1.6.3 Servidor DNS.

Servidor de nombres de domino de Internet, que tras la entrada de un nombre de

dominio devuelve la dirección IP correspondiente a dicha entrada.


66

3.1.7 Alternativas.

3.1.7.1 Primera.

IIS.

Java( JSP, Servlets).

Microsoft SQL Server.

Windows XP.

3.1.7.2 Segunda.

Apache Tomcat.

Windows XP.


Access.

3.1.7.3 Tercera.

Windows XP.


Oracle.

Sun´s Java Web Server.


67

EVALUACIÓN DE LAS ALTERNATIVAS

3.2.1 Evaluación económica.

Los costes en la segunda alternativa serían muy bajos debido a que tanto Apache como

Access son gratuitos.

3.2.2 Evaluación técnica.

Cualquiera de las opciones podría funcionar sin problemas con independencia de los

sistemas en los que funciones salvo la primera opción debido a que Microsoft SQL

Server es usado en sistemas Windows quedando su uso limitado a estos sistemas aunque

esta opción es la mas fácil de implantar mecanizar.


68

SELECCIÓN DE UNA ALTERNATIVA

La alternativa escogida ha sido la segunda; aunque cualquiera de ellas podría ser valida

para la realización de este proyecto. Las razones fundamentales para tomar dicha

decisión han sido:

- El servidor “Apache Tomcat” es muy utilizado actualmente y tiene dos

importantes puntos favorables y es que es de libre distribución y tiene una gran

potencia y rendimiento por lo que funcionaria perfectamente en los equipos cliente y

reduciría los costes del proyecto.

- Java (Servlets y JSP) es muy potente y el mas extendido en la actualidad.

- Para gestionar las BBDD se ha optado por Access ya que es potente y además es

gratuito al estar incluido dentro del office por lo que abarataría los costes del

proyecto.


69

Diseño Externo


70

ENTORNO OPERATIVO DEL SISTEMA

4.1.1 Entrada, salida y recogida de datos.

La entrada de datos se realizará a través de los formularios de la página Web donde la

aplicación le pedirá al usuario diversos datos como las acciones que quiera realizar el

0.


USUARIO TIPO ESTÁNDAR




71

usuario, su password y su usuario, el criterio y la información par alas búsquedas, etc....

Para la salida de datos también se realizará a través de la página Web en la que la

aplicación mostrará al usuario diversa información como la petición del password y el

usuario, el criterio que querrá utilizar, la información de las incidencias, etc....

Para los usuarios de tipo avanzado tanto el envío como la salida de datos se realizará de

la misma manera que para el usuario de tipo estándar; solo cambiará alguna información

que sea enviada o recibida por el sistema.

0.


USUARIO

TIPO AVANZADO




72

4.1.2 Mantenimiento de ficheros.

Las bases de datos tendrán un tipo de información que se actualizará dinámicamente

ya que toda la información de las incidencias se irá modificando de forma automática

por el sistema cuando los usuarios hagan algún tipo de cambio en los datos de las

mismas.

4.1.3 Generación de informes.

Esta aplicación solo generará un tipo de informe que contendrá la información de las

incidencias.

Este informe se generará cada vez que un usuario quiera realizar una búsqueda por

cualquiera de los criterios disponibles por la aplicación que una vez introducido el tipo

de criterio y la información del mismo mostraría por pantalla toda la información de la

incidencia buscada.

4.1.4 Control de información y seguridad del sistema.

Es importante disponer de una estrategia de administración del riesgo para proteger los

datos así como la confidencialidad y para implementar esto se divide la arquitectura en

redes físicas. Gracias a esto se compartimenta el sistema, gracias a lo cual, una

exposición parcial no va a provocar la perdida de los datos. La atención principal de la

seguridad recaerá en la red ya que es por donde la información podría sufrir más riesgo

de ataques y para evitarlos se utilizaran dispositivos de red como enrutadores con

restricciones de puertos o servidores de seguridad dedicados. Para los servidores se les

proporcionara tanta seguridad inherente como sea posible mediante la seguridad basta

en host.

Para llevar a cabo el control de la información la primera medida será controlar el

acceso a la información mediante la utilización de grupos de manera que dependiendo

del grupo al que pertenezca pueda acceder a un tipo de información u otra.

Para reforzar la seguridad se utilizaría hardware redundante de manera que si un

servidor fallará otro exactamente igual se pondría en funcionamiento evitando de esta


73

manera fallos y además se realizarían back-UPS todas cada cierto tiempo para que en

caso de que se pierda la información se pueda recuperar la mayor parte de ella posible.

4.1.4.1 Condiciones iniciales.

Dentro de la seguridad se deben considerar algunos mecanismos para la seguridad física

tales como:

4.1.4.1.1 A nivel preventivo.

Uso del equipo por personal autorizado.

Introducción de una clave personal así como su nombre de usuario de manera que esta

información se coteja con la base de datos y permite y deniega el acceso según los

permisos que disponga dicho usuario de manera que con esta medida hagamos una

diferenciación por perfiles de los usuario y nos aseguremos de que no pueda ser

utilizada la aplicación por parte de personas que no sean usuarios de la misma.

La información tendrá un respaldo continuo al tener más de un servidor de base de

datos los cuales asegurarán una integridad total de la información y además se instalará

una alarma la cual notifique cualquier fallo en la integridad física del sistema.

4.1.4.1.2 A nivel correctivo.

Asegurar los equipos con alguna aseguradora de cara a que si se produce algún

siniestro no se perdieran los elementos físicos y se pudieran conseguir unos nuevos en

el menor plazo de tiempo posible con el menor coste.

La seguridad lógica al referirse a controles lógicos dentro del software se implementa

mediante:

Construcción de dos tipos de perfil de manera que ciertas partes de la información así

como algunas funciones de la herramienta solo estén disponibles para miembros del

grupos de usuarios avanzados y dichas contraseñas solo podrán ser generaras por los

administradores del departamento de sistemas lo que aseguraría que ningún usuario


74

ajeno a dicho departamento pueda generar claves de acceso a la aplicación.

4.1.4.2 Encriptación de Datos.

Debido a que en las bases de datos van a tener datos confidenciales de los usuarios es

necesario que se encripten los datos en caso de que estos tengan que ser enviados con el

fin de mantener su integridad y confidencialidad.

Hay dos tipos de algoritmos para encriptación:

- Algoritmos simétricos: utilizan una clave con la cual se encripta y

desencripta el documento de manera que si el emisor mandar la información encriptada

con una clave el receptor de la misma solo podrá desencriptar con la misma clave. El

punto negativo de esta técnica es que la clave de encriptación debe viajar con la

información por lo que su seguridad queda disminuida y es imposible utilizarla en

ambientes donde interactúan muchos interlocutores.

- Algoritmos asimétricos: requiere dos claves; una privada que es

conocida solo por el dueño y es con la cual se encripta la información antes de enviarla

y otra pública que es con la que se desencripta en el destino. Ambas claves están

relacionadas mediante una fórmula matemática imposible de reproducir.

Otro aspecto de la criptografía a tener en cuenta es la seguridad de los datos en las

bases de datos ya que dicha información tiene que estar protegida contra accesos con

fines malintencionados. La pérdida accidental de la consistencia de los datos puede

deberse a:

- Caídas durante el procesamiento de las transacciones.

- Anomalías por acceso concurrente a la base de datos.

- Anomalías resultantes del envío de la información a varios PC´s.

Siempre es más fácil prevenir las posibles alteraciones o pérdidas de datos por un

motivo accidental que cuando es un acceso malintencionado a los datos. Algunas de las

formas de acceso malintencionado son:

- Lectura de datos sin autorización.

- Modificación de datos sin autorización.

- Destrucción no autorizada de datos.


75

Proteger los datos al 100% de cualquier acceso malintencionado es una tarea casi

imposible aunque puede hacerse que sea tan difícil acceder a los datos para cualquier

persona no autorizada que esta desista de su actitud. El término seguridad en la base de

datos se refiere a la protección contra un acceso malintencionado mientras que la

integridad se refiere a la protección contra una perdida accidental. Debido a que

asegurar al 100% que no se producirán accesos no autorizados no es posible sería

conveniente cifrar la información más importante de manera que aunque se produzca un

acceso no autorizado no se podrá leer dichos datos a menos que el autor de dicho

acceso sepa como descifrar la información. Las técnicas de cifrado tienen las siguientes

características:

- Para un usuario autorizado es fácil cifrar y descifrar los datos.

- El esquema de cifrado no depende de mantener en secreto el algoritmo de

cifrado sino en la clave de cifrar/descifrar la información.

- Para un intruso es muy difícil averiguar cual es la clave.

4.1.4.3 Ataque y defensa (Web seguro).

Para localizar una máquina en Internet es necesario conocer la dirección IP asignada por

el Proveedor de Servicios Internet (ISP), aunque conocer dicha dirección no

proporciona una vía de acceso a ella.

Para tener acceso es necesario encontrar un puerto abierto; normalmente en el acceso a

Web es el puerto 8080 y en el caso del acceso FTP (Protocolo de transferencia de

archivos) necesitamos el puerto 21.

Por lo tanto una vez conocida la dirección IP es necesario escanear los puertos del

equipo cuya dirección conocemos y para conseguir esto es importante adquirir una

herramienta conocida como escaneadores de puertos. Estos programas pueden variar de

formato pero todos tienen el mismo objetivo.

Otro métodos de apertura de puertos es enviar al usuario un programa que despliegue un

Caballo de Troya o Troyano; estos se pueden encubrir bajo un anexo en un correo.

Uno de los troyanos más conocidos es el “Back Orifice” cuyo objetivo es abrir un


76

puerto en el equipo para obtener el control del mismo a distancia; otros ejemplos de

troyanos son el UMG32.exe o el Sub Seven que ocasionan los mismo efectos que el

Back Orifice.

Para aumentar la seguridad sería conveniente planificar una estrategia para impedir

estos ataques. Ya que verificar uno a uno los puertos abiertos pos los programas sería

difícil y tedioso esta tarea debería realizarse mediante programas o hardware encargado

de verificar la entrada y la salida e cada uno de los puertos. Estos programas son

conocidos como firewalls o cortafuegos.

También es necesario implementar políticas en los sistemas operativos que ofrezcan los

servicios de Web o FTP.

Otros métodos de defensa es la implementación de un cortafuegos y detrás de estos el

montaje en cascada de proxies que controlen el tráfico interno de la red. La posibilidad

de entrada al servidor mediante una zona militarizada es prácticamente nula

Con estas medidas podríamos protegernos de cualquier ataque que se pudiera producir

desde el exterior pero aun deberíamos protegernos de las amenazas internas por lo que

sería necesario implemente políticas de grupos que limiten los permiso y expliciten los

mismo con tal de establecer reglas claras.

4.1.4.4 Conclusión.

Internet se creo como una serie de redes para promover el intercambio de información

fluyendo libremente y sin existir ninguna preocupación sobre la privacidad de la

información ni por otros aspectos relativos a la seguridad de la misma.

En los últimos años la conexión a Internet del mundo empresarial se ha producido a un

ritmo vertiginoso siendo esta la tecnología de mayor difusión.

Con estos cambios también han aumentado los intentos de realizar actos

malintencionados con la información o los recursos y sistemas de la red, cuya

complejidad dificulta la detección y corrección de los problemas de seguridad que van

surgiendo.

Para nuestra aplicación sería necesario considerar varios puntos respecto a la seguridad:


77

- Control de acceso: este mecanismos se utiliza para comprobar los

accesos a nuestra aplicación de tal manera que solo personal autorizado pueda acceder a

la misma de forma que cuando un usuario quiera logearse en el sistema este le pedirá su

nombre y su password.

- Confidencialidad de datos: protección para evitar el acceso a los datos

por usuarios no autorizado.

- Integridad de los datos: garantiza que los datos no sean manipulados

con fines malintencionados.

El intercambio de datos a través de la red depende en gran medida de la tecnología de

los sistemas de seguridad por lo que es necesario disponer de sistemas seguros para el

manejo de datos por lo que si es necesario el envío de información relevante sería

conveniente disponer de una tecnología de autentificación para evitar que cualquier

persona acceda a la información.

4.1.5 Rendimiento del sistema y escalabilidad.

El sistema va a tener grandes cantidad de modificaciones de datos así como entradas y

salidas en relación a la creación o eliminación de las incidencias.

Dicho tráfico de información se incrementará en las horas punta por lo que hay que

preparar el sistema para que soporte esas horas de forma correcta.

Todos los componentes de la arquitectura son escalables para permitir un crecimiento

continuo en función del uso de la herramienta y de las necesidades de la empresa. Los

principales componentes que requieren escalabilidad son los de red, en el cual la

escalabilidad se aplica al acho de banda, los componentes Web de aplicaciones para el

usuario que tienen que ser escalables en la capacidad de procesamiento, los de

infraestructura o aplicaciones y los de almacenamiento que tienen que ser escalables en

cuanto el tamaño y la velocidad de entrada y salida de los datos.

Para ampliar el sistema de forma eficaz, se necesita identificar la naturaleza de la

demanda y como influirá en los distintos componentes. Una vez se ha identificado el

componente que genera el problema se aumenta la capacidad de dicho componente para


78

eliminar los posibles problema que hubiera.

4.1.6 Forma de implantación.

La forma en la que se pretender abordar el proceso de implantación del sistema, su

estrategia, es por etapas, que consiste en dar marcha al sistema que se está creando

cubriendo parcelas operativas, para ir paulatinamente incorporando el resto.

4.2 Configuración hardware-software.

De acuerdo a las soluciones escogidas durante el estudio de la arquitectura la

arquitectura final del sistema quedaría representada por el siguiente gráfico.


79

Internet

Encaminador

Servidor de Seguridad

Conmutador

Zona desmilitarizada

Apache tomcat / DNS

Servidor de Seguridad

LAN

Puestos cliente Herramienta gestión de incidencias

BBDD


80

4.2.1 Especificaciones hardware del sistema.

La empresa posee unos Router Cisco que son utilizados para que los usuarios puedan

salir a Internet y navegar dentro de la red de la empresa y para los administradores de

sistema. También se utilizan unos servidores de seguridad que estarán a continuación de

los router y también separando la zona desmilitarizada de la red Lan. La arquitectura

también contará con conmutadores para enlazar los diferentes puntos. Del mismo modo

la empresa también posee unos servidores Apache Tomcat que son Pentium a 2.5 GHZ

con 1 GB de memoria y 200 Gb de disco duro con una unidad lectora de DVD

utilizados para dar servicio a los usuarios y para el administrador del sistema.

Los clientes necesitarán un módem para conectarse a Internet y un procesador de al

menor 733 Mhz.

4.2.2 Especificaciones software del sistema.

Los servidores Apache Tomcat gestionan la empresa con el sistema operativo Windows

2000.

Los servidores de bases de datos utilizan para la gestión de las bases de datos Microsoft

Access 2000.

Los clientes deberán tener un navegador para acceder a Internet que será el Microsoft

Explorer ya que es el corporativo de la empresa.


81

4.3 Desarrollo del modelo físico nuevo.

Se trata de volver al modelo lógico nuevo y transformarlo en un modelo físico

soportado ya en la arquitectura definida. Este modelo físico del nuevos sistema

convierte el “que se hace en el sistema” por un “como lo hace”.

4.3.1 Fronteras de mecanización.

DESCRIPCIÓN: Nada más acceder a la aplicación lo primero que tendrá que hacer el usuario es introducir su nombre y su password para poder acceder a la herramienta y , de este modo, validarse como un usuario de la misma y poder definir que tipo de usuario es

Proceso: Entrada password. Tipo: Manual.

DESCRIPCIÓN: Nada más acceder a la aplicación lo primero que tendrá que hacer el usuario es introducir su nombre y su password para poder acceder a la herramienta y , de este modo, validarse como un usuario de la misma y poder definir que tipo de usuario es.


82

DESCRIPCIÓN: Cuando el usuario en el menú de opciones selecciona dar de alta una incidencia directamente la aplicación muestra al usuario la pantalla donde tiene que introducir todos los datos relativos a la incidencia que quiere dar de alta. Una vez que el usuario introduzca los datos sólo tendrá que clickar en el botón de aceptar y la incidencia será dada de alta en la base de datos y en la aplicación.

Proceso: Dar de alta incidencia. Tipo: Manual.

DESCRIPCIÓN: Una vez validado el usuario la aplicación, le mostrará al usuario por pantalla las diferentes acciones que puede realizar la herramienta. Una vez el usuario ha elegido una de ellas pinchará sobre la opción elegida para su ejecución.

Proceso: Selección opción. Tipo: Manual.


83

DESCRIPCIÓN: Si en la pantalla para seleccionar que acción desea ejecutar el usuario eligiera consultar una incidencia le aparecería la pantalla de selección de criterio. En esta pantalla el usuario debe seleccionar el criterio por el cual desea realizar la búsqueda y posteriormente introducir el valor por el cual desea realizar la búsqueda según el criterio.

Proceso: Selección criterio. Tipo: Manual.

DESCRIPCIÓN: Si el usuario es de tipo avanzado y en la pantalla para seleccionar que acción desea ejecutar el usuario eligiera consultar una incidencia le aparecería la pantalla de selección de criterio. Una vez introducido el valor para realizar la búsqueda y el criterio seleccionado se mostrará por pantalla la información de la incidencia que coincida con el valor introducido con un botón adicional para modificar los datos. Una vez pulsado le aparecerá por pantalla los valores de la incidencia para que los modifique.

Proceso: Modificar incidencia. Tipo: Manual.


84

DESCRIPCIÓN: Si el usuario a la hora de modificar los datos de una incidencia pone como estado resuelta se salvarán los cambios y la incidencia se dará por resuelta.

Proceso: Cerrar incidencia. Tipo: Manual.

DESCRIPCIÓN: Si en la pantalla para seleccionar que acción desea ejecutar el usuario eligiera consultar una incidencia le aparecería la pantalla de selección de criterio. Una vez introducido el valor para realizar la búsqueda y el criterio seleccionado se mostrará por pantalla la información de la incidencia que coincida con el valor introducido.

Proceso: Consulta incidencia. Tipo: Manual.


85

DESCRIPCIÓN: Este proceso se realizará de manera automática por el sistema de manera que cada vez que un usuario da de alta una incidencia, modifica algún valor de alguna incidencia o cierra alguna se modifica automáticamente en la base de datos.

Proceso: Modificaciones BBDD. Tipo: Automático.


86

4.3.2 Diseño de entradas.

El resultado de la agrupación de los procesos en subsistemas es el siguiente.

4.3.2.1 Subsistema de validación.

1.1 Entrada password

1.2 Validación.

4.3.2.2 Dar de alta incidencias.

3.2 Dar de alta incidencia.

3.2.1 Petición de datos.

4 Actualización BBDD.

4.3.2.3 Modificar incidencias.

3.3 Introducción datos.

3.4 Búsqueda de la incidencia.

3.5 Modificar incidencia.

4 Actualización BBDD.

4.3.2.4 Consulta incidencias.

3.4.1 Seleccionar criterio.

3.4.2 Mostrar incidencias.

4.3.2.5 Cerrar incidencia.

4.1 Introducción incidencia a borrar.


87

4.3.3 Diseño de salidas.

DESCRIPCIÓN: Ventana que le aparece a los usuarios una vez se han validado y se ha comprobado que son usuarios permitidos para la aplicación. En esta ventana aparecen las distintas acciones que puede realizar el usuario con la herramienta.

Nombre: Menú.

DESCRIPCIÓN: Esta ventana le aparecerá a los usuarios nada mas iniciar la aplicación y en la cual los usuarios tendrán que introducir su nombre y su password para validarse.

Nombre: Validación usuarios.


88

DESCRIPCIÓN: Si es un usuario avanzado al realizar una búsqueda le aparecerá un botón adicional para realizar modificaciones en la incidencia que desee. Una vez pulsado le aparecerán todos los datos de la incidencia y, una vez introducidos los nuevos datos, al pulsar el botón aceptar salvará los cambios.

Nombre: Modificar incidencia.

DESCRIPCIÓN: Si los usuarios en la ventana menú escoger dar de alta una incidencia les aparecerá esta ventana en la cual la herramienta pide todos los datos necesarios para dar de alta una nueva incidencia.

Nombre: Alta incidencia.


89

DESCRIPCIÓN: Una vez que los usuarios introducen el criterio por el cual desean realizar la búsqueda y el valor por el que desean buscar aparece esta pantalla en la que se muestra toda la información de las incidencias que coinciden con la búsqueda.

Nombre: Mostrar.

DESCRIPCIÓN: Si el usuario escoge consultar una incidencia le aparecerá esta ventana en la cual deberá seleccionar el criterio de búsqueda así como el valor por el cual desea realizar la búsqueda.

Nombre: Criterio de búsqueda.


90

4.3.4 Modelo físico del nuevo sistema.

0.


USUARIO TIPO

ESTÁNDAR

USUARIO TIPO

AVANZADO

Opciones disponibles, Petición de password y usuario. Petición criterio e información para búsquedas, petición datos para modificar o dar de alta incidencias

Opciones elegidas, Password y usuario. Criterio e información para búsquedas, Datos para modificar o dar de alta incidencias




91

Usuario estándar

Opción deseada

Menú de opciones

1.1 Entrada

password

Password

Usuarios

validación Respuesta

Usuario no aceptado Petición pasword y nombre

Datos incidencia a dar de alta


Incidencia Datos a modificar

3 Gestión Usuario

avanzado

Usuario avanzado

Opción deseada

Menú de opciones



Incidencia Datos a modificar

Incidencia

2 Gestión Usuario estándar

Modificaciones en bbdd,( altas y bajas)

Modificaciones en bbdd,( altas y bajas) y consultas

Datos incidencia

Petición criterio y dato para la búsqueda.

Datos para la búsqueda y criterio seleccionado


92

2.1 Selección

opción

Acción deseada

Menú de opciones

Incidencia




Alta de incidencia

Opción deseada

Opción deseada

Petición criterio y dato para la búsqueda

2.3 Consulta

de incidencia

Incidencia deseada



Opción deseada


93

3.1 Selección

opción

Acción deseada

Menú de opciones

Incidencia


Petición criterio y dato para la búsqueda


3.4 Consulta

de incidencia


Alta de incidencia

Opción deseada

Opción deseada

Incidencia deseada



Datos a modificar

actualizar

Opción deseada

Modificar incidencia


94

4.3.4.1 Cuaderno de carga de los diagramas de flujo. 4.3.4.1.1 Diagrama de contexto

4.3.4.1.1.1 Entidades externas.

- Usuario tipo estándar: es un usuario que esta dado de alta en la

herramienta. Puede dar de alta incidencias así como consultas pero no tendrá privilegios

para realizar modificaciones en ellas.

- Usuario tipo avanzado: es un usuario que esta dado de alta en la

herramienta. Puede dar de alta incidencias, realizar consultas y realizar modificaciones

en ellas ya que posee todos los privilegios de la herramienta.

0.


USUARIO TIPO

ESTÁNDAR

USUARIO TIPO

AVANZADO






95

4.3.4.1.1.2 Procesos. El sistema de gestión de incidencias va a canalizar el flujo de información entre los

usuarios de tipo estándar y tipo avanzado con la herramienta de gestión de incidencias.

4.3.4.1.2 Diagrama conceptual.

Entrada password (1) será el primer proceso que se ejecutará. Este proceso pedirá al

usuario su nombre y su password para validarlo como usuario y así concederle nos

privilegios según el tipo de usuario que sea dentro de la aplicación. Una vez que el

usuario manda su nombre y su password se consultará en la BBDD Usuarios para saber

que tipo de usuario es o para indicarle que no es un usuario valido de la herramienta.

Gestión de usuario estándar (2) si un usuario es validado como un usuario estándar se

ejecutará una serie de procesos en los cuales el usuario podrá realizar diferentes

acciones.

Lo primero que se mostrará al usuario será el menú de acciones que puede realizar con

la herramienta basándose en su perfil y este elegirá una de las dos opciones posibles.

- Dar de alta una incidencia en la cual la aplicación le pedirá todos los datos

necesarios para dar de alta una incidencia y una vez que sean introducidos se

producirá el alta de la nueva incidencia en la BBDD de incidencias.

- Consultar incidencia que pedirá al usuario el criterio por el cual desea realizar la

búsqueda y el valor por el que desea buscar y tras hacer una consulta a la BBDD

de Incidencias muestra el resultado por pantalla.

Gestión de usuario avanzado (3) si un usuario es validado como un usuario avanzado se

ejecutará una serie de procesos en los cuales el usuario podrá realizar diferentes

acciones.

Lo primero que se mostrará al usuario será el menú de acciones entre las cuales estarán

las dos acciones que podía realizar un usuario de tipo estándar más una añadida.

- Modificar incidencia es una acción que esta reservada para los usuarios de tipo

avanzado. En esta acción el usuario podrá modificar el valor de la incidencia que

el desee introduciendo el numero de incidencia que es así como los datos

nuevos. Una vez introducida toda la información realizará la actualización en la

BBDD de Incidencias


96

Cierre (4) este proceso solo se ejecutará desde el proceso de gestión de usuario

avanzado ya que solo un usuario con ese tipo de privilegios podrá cerrar una incidencia.

Una vez que se quiere cerrar una incidencia el sistema pedirá una confirmación por

parte del usuario y en caso de que se produzca dicha confirmación se actualizada la

BBDD de Incidencias.

4.3.4.1.3 Diagramas Nivel 2.

Selección de opción (2.1): una vez validado como un usuario estándar le aparecerá al

usuario este menú con las posibles acciones que puede llevar a cabo con la herramienta

de gestión de incidencias. Una vez que el usuario seleccione la que quiere realizar se

ejecutará la acción seleccionada.

Dar de alta incidencia (2.2) si el usuario escoge la opción de dar de alta una incidencia

la herramienta pedirá todos los datos necesarios para poder darla de alta; una vez

introducido realizará el alta de la misma dentro de la BBDD de Incidencias.

Consulta de incidencia (2.3) si la opción escogida por el usuario es consultar una

incidencia lo primero que hará la herramienta es pedirle al usuario que introduzca el

criterio por el cual desea realizar la búsqueda y el valor por cual que desea buscar. Una

vez introducidos le herramienta realizará la consulta en la BBDD de Incidencias y

mostrará por pantalla todas las incidencias que coincidan con el valor y el criterio de

búsqueda introducido por el usuario.

Selección de opción (3.1) es similar a selección opción 2.1 y solo variará en una opción

más que será mostrada a los usuarios que posean un perfil de usuario avanzado.

Dar de alta incidencia (3.1) será igual a dar de alta (2.1)

Modificar incidencia (3.3) será una acción que solo podrá ejecutar los usuarios de nivel

avanzado ya que los usuarios de tipo estándar no podrán acceder a ella desde el menú de

su perfil. En este proceso el usuario deberá introducir el número de incidencia que desea

modificar así como todos los datos ya modificados de la misma. Una vez introducidos la

herramienta realizará la actualización en la BBDD de Incidencias.

Consulta de incidencias (3.4) será igual a Consulta de incidencia (2.3).


97

4.4 Modelo lógico de datos.

INCIDENCIA

DEPARTAMENTO USUARIO

Pertenece

Pertenece

Asignada


98

4.5 Estudio de los planes.

Se debe definir un plan de pruebas para especificar cuales son los resultados esperador y

cuales serán los márgenes de error para la no superación de las pruebas, detallando las

pruebas que se usaran para dar o no le visto bueno a la herramienta y comenzar con la

implantación y explotación de la misma.

4.5.1 Plan de pruebas funcionales.

Navegación de ventanas:

- Vínculos a pantallas y puntos de entrada bien diseñados para su fácil

navegación.

- Sitio gestionado como proyecto específico de interfaz de cliente.

- No saturar las ventanas ya que aumenta el tiempo de respuesta.

- Ayudas claras para la navegación.

- Todas las páginas con retorno.

- Proporcionar al usuario un acceso directo a la información.

Funcionalidad de operación de consulta.

- Asegurar el seguimiento de las operaciones con las incidencias.

- Correcto mantenimiento de actualización de las bases de datos.

- Total seguridad de los procesos del sistema.

Obtención de información.

- Fiabilidad en la actualización de las incidencias.

- Disponibilidad de los datos.

Interfaces con otros sistemas.

- Detección de la existencia de incompatibilidad con algún navegador o versión

del mismo.


99

Facilidad de gestión.

- Simplicidad y consistencia de los procesos.

- Correcta comunicación entre los procesos y su envío de datos.

- Procesos de actualización y limpieza de datos.

4.5.2 Plan de pruebas de prestaciones.

Tiempo de respuesta.

- Entre una décima de segundo y un segundo para cualquier manipulación en

tiempo real.

- Diez segundos es el tiempo máximo para mantener la atención del usuario.

- No mostrar listas desplegables tan rápido que el usuario no pueda trabajar con

ellos.

Necesidad de memoria.

- Debe existir mucha más memoria de la necesitada para atender a los usuarios en

las franjas o momentos en los que se produzca un mayor número de incidencias.

Tráfico de las líneas de comunicación.

- Correcto de rendimiento con múltiples sesiones.

Ocupación del disco

- El disco no tendrá nunca más del 60% ocupado.


100

Diseño Interno


101

5.1 Subsistema BATCH.

Para el subsiste batch se utiliza la derivación del DFD físico de cada función hacia el

diagrama de funciones o HIPO, que muestra la jerarquía y secuencialidad de los

procesos, e identifica cada programa o módulo de la función. Al conjunto de programas

de una función de negocio se las empaquetará en una cadena o script.

5.1.1 Función batch de backup.

Departamento Usuario Incidencia

BACKUP

Código

Copia seguridad


102

5.1.2 Función batch de recuperación.

Departamento Usuario Incidencia

Destruir archivos

Usuario regenerada

Departamento vacía Usuario

vacía Incidencia vacío

Generar archivos

Incidencia regenerada

Departamento regenerada


103

5.2 Modelo físico de datos.

CREATE TABLE INCIDENCIA

(identificador INTERGER NOT NULL,

fecha_alta INTEGER NOT NULL,

fecha_resolución INTEGER NOT NULL,

criticidad VARCHAR(50) NOT NULL,

estado VARCHAR(50) NOT NULL,

cod_departamento INTEGER NOT NULL,

cod_usuario INTEGER NOT NULL,

descripción VARCHAR(100) NOT NULL,

comentarios VARCHAR(100) NOT NULL,

CONSTRAINT PKE PRIMARY KEY (identificador)

REFERENCES USUARIO (cod_usuario)

DEPARTAMENTO (cod_departamento));

CREATE TABLE USUARIO

(cod_usuario INTERGER NOT NULL,

nombre VARCHAR(100) NOT NULL,

apellido1 VARCHAR(100) NOT NULL,

apellido2 VARCHAR(100) NOT NULL,

telefono INTERGER NOT NULL,

correo VARCHAR(100) NOT NULL,

perfil VARCHAR(100) NOT NULL,

tipo VARCHAR(100) NOT NULL,

password VARCHAR(100) NOT NULL,

CONSTRAINT PKE PRIMARY KEY (cod_usuario)

REFERENCES INCIDENCIA (cos_usuario));


104

CREATE TABLE DEPARTAMENTO-

(cod_departamento INTERGER NOT NULL,

nombre VARCHAR(100) NOT NULL,

correo VARCHAR(100) NOT NULL,

CONSTRAINT PKE PRIMARY KEY (cod_departamento)

REFERENCES INCIDENCIA (cos_departamento));


105

5.3 Subsistema on_line

Para el subsistema on_line, se utiliza la derivación del DFD físico de cada función hacia

el diagrama de cuadros estructurado o STC, que permite mostrar la jerarquía que existe

entre los módulos principales y los subordinados.

5.3.1 Principal.

Principal

Validación usuario

Menú Usuario estándar

Menú Usuario avanzado

Aceptación Rechazo


106

5.3.2 Menú principal usuario estándar.

Principal

Dar de alta incidencias

Consultar incidencias

Entrada

Cancelar Cancelar


107

5.3.3 Menú principal usuario avanzado.

Principal

Dar de alta incidencias

Consultar incidencias

Entrada

Cancelar

Cancelar


108

5.3.4 Alta incidencia.

Dar de alta

Pedir datos Salida

Rechazo

Introducir incidencia

Datos incidencia

Leer datos

Datos

Teclado

Datos incidencia

Incidencias

Pantalla


109

5.3.5 Consulta de incidencia.

Consultar

Pedir datos y criterio

Salida

Rechazo

Buscar incidencia

Datos incidencia

Leer datos

Datos

Teclado

Datos incidencia

Incidencias

Pantalla


110

5.3.6 Modificar incidencias.

Consultar

Pedir datos y criterio Guardar cambios

Rechazo

Buscar incidencia

Datos incidencia

Leer datos

Datos

Teclado

Datos incidencia

Incidencias

Datos modificados

Incidencias


111

5.3.7 Cerrar incidencia.

Consultar

Pedir datos y criterio Guardar cambios

Rechazo

Buscar incidencia

Datos incidencia

Leer datos

Datos

Teclado

Datos incidencia

Incidencias

Datos modificados Y estado de incidencia cerrada

Incidencias


112

Programación


113

6.1 Menú principal.

El menú principal será el interfaz de acceso a la aplicación y lo primero que verá

el usuario una vez la ejecute.

A través de este menú el usuario se validará mediante su clave de usuario y su

contraseña para, además de que la herramienta sepa si es un usuario

permitido para usar la aplicación o no, las diferentes acciones que podrá

realizar dependiendo de si es un usuario estándar o un usuario avanzado.

Debido a que durante la creación de la herramienta se ha buscado que sea lo

más simple y fácil de usar posible este menú sólo dispondrá de dos campos en

los que los usuarios podrá escribir y que será donde introduzcan su código de

usuario y su password

6.1.1 Código de página de menú principal. <%@ page language="java" contentType="text/html; charset=ISO-8859-1" pageEncoding="ISO-8859-1"%> <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"> <%@ page import="gestion.beans.UsuariosBeans" %> <html> <head> <meta http-equiv="Content-Language" content="es"> <meta http-equiv="Content-Type" content="text/html; charset=windows-1252"> <title>Herramienta de Gestión de Incide</title> </head> <body> <% UsuariosBeans usuarios=(UsuariosBeans)request.getAttribute("usuarios"); if(usuarios!=null && !usuarios.getError().equals("")){ %> <jsp:include file="pagerror.jsp"/> <%} %> <div style="position: absolute; width: 986px; height: 100px; z-index: 1; left: 18px; top: 4px; background-color: #FFFF00" id="capa1"> <p align="center"> </p>


114

<p align="center"><font color="#0000FF" size="6">Herramienta de Gestión de Incidencias</font></p> <p> </div> <p> </p> <p> </p> <p> </p> <p> </p> <p> </p> <p>BIENVENIDO A LA HERRAMIENTA DE GESTIÓN DE INCIDENCIAS</p> <p>POR FAVOR, INTRODUZCA SU USUARIO Y PASSWORD PARA INICIAR UNA SESIÓN</p> <p> </p> <form name=login method="post" action="ConsultaTipo" > <table> <input type=hidden name=fAccion value=login> <tr> <td> <b> <font face="Verdana,Helvetica" size="1"> <font color="#FF0000">Usuario </font>   </font><font face="Verdana,Helvetica" size="1" color="#FFFFFF">    </font></b> <input type="text" name="usuario" size="10"> </td> </tr> <tr> <td> <font face="Verdana,Helvetica" size="1" color="#FFFFFF"> <b>Co</b></font><p><b> <font face="Verdana,Helvetica" size="1" color="#FF0000">Contraseña </font></b> <input type="password" name="password" size="10"> </p> </td> </tr> </table> <p><input type="submit" value="ACEPTAR" ></p> </form> </body> </html>


115

6.1.2 Código que recogerá los datos de la pagina web para validarlos. package servlet; import gestion.beans.IncidenciaBeans; import gestion.beans.UsuariosBeans; import gestion.control.IncidenciaControl; import gestion.control.UsuariosControl; import java.io.IOException; import java.text.SimpleDateFormat; import java.util.Date; import java.math.*; import javax.servlet.RequestDispatcher; import javax.servlet.ServletException; import javax.servlet.http.HttpServlet; import javax.servlet.http.HttpServletRequest; import javax.servlet.http.HttpServletResponse; public class ConsultaTipo extends HttpServlet{ public void doPost(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { String accion = request.getParameter("fAccion"); if(accion.equals("login")){ login(request,response); }else if(accion.equals("salir")){ salir(request,response); }else if(accion.equals("alta")){ alta(request,response); }else if(accion.equals("altaIncidencia")){ altaInci(request,response); }else if(accion.equals("consulta")){ consulta(request,response); }else if(accion.equals("consultarIncidencia")){ consultaTipo(request,response); }else if(accion.equals("modificar")){ modificarPresentacion(request,response); }else if(accion.equals("aceptarModificar")){ aceptarModificar(request,response); }else{ request.setAttribute("error","Acción desconocida"); request.getRequestDispatcher("paginaError.jsp"); }


116

} public void doGet (HttpServletRequest req, HttpServletResponse res) throws ServletException, IOException { this.doPost (req, res); } public void login(HttpServletRequest request,HttpServletResponse response)throws ServletException, IOException{ UsuariosBeans usuarios= new UsuariosBeans(); UsuariosControl usuariosControl = new UsuariosControl(); String user =request.getParameter("usuario").trim(); try { usuarios.setCod_usuario(Integer.parseInt(user)); } catch (NumberFormatException e) { usuarios.setError("El campo usuario debe de ser numerico"); } usuarios.setPassword(request.getParameter("password").trim()); if(usuarios.getError().equals("") && usuariosControl.buscar(usuarios)){ request.getSession(true).setAttribute("usuario",usuarios); request.getRequestDispatcher("inicioUsuarioEstandar.jsp").forward(request,response); }else{ request.setAttribute("usuairo",usuarios); request.getRequestDispatcher("login.jsp").forward(request,response); } } public void salir(HttpServletRequest request,HttpServletResponse response)throws ServletException, IOException{ request.getRequestDispatcher("login.jsp").forward(request,response); } public void alta(HttpServletRequest request,HttpServletResponse response)throws ServletException, IOException{ request.getRequestDispatcher("alta.jsp").forward(request,response); }


117

public void altaInci(HttpServletRequest request,HttpServletResponse response)throws ServletException, IOException{ String valor = request.getParameter("B3"); if(valor.equals("ATRAS")){ request.getRequestDispatcher("inicioUsuarioEstandar.jsp").forward(request,response); }else{ IncidenciaBeans incidencia = new IncidenciaBeans(); IncidenciaControl inciControl = new IncidenciaControl(); Date fechaActual = new Date(); SimpleDateFormat formato = new SimpleDateFormat("yyyyMMdd"); String cadenaFecha = formato.format(fechaActual); incidencia.setId((int)(Math.random()*1000)); incidencia.setCod_usuario(Integer.parseInt(request.getParameter("usu"))); incidencia.setFecha_alta(Integer.parseInt(cadenaFecha)); incidencia.setFecha_resolucion(0); incidencia.setTelefono(Integer.parseInt(request.getParameter("tel"))); incidencia.setUbicacion(request.getParameter("ubi")); incidencia.setDescripcion(request.getParameter("des")); incidencia.setComentarios(request.getParameter("com")); incidencia.setCriticidad(request.getParameter("cri")); incidencia.setEstado("RECIBIDO"); while(inciControl.buscar(incidencia)){ incidencia.setId((int)(Math.random()*1000)); } inciControl.alta(incidencia); request.getRequestDispatcher("login.jsp").forward(request,response); } } public void consulta(HttpServletRequest request,HttpServletResponse response)throws ServletException, IOException{ request.getRequestDispatcher("criterioBusqueda.jsp").forward(request,response); } public void consultaTipo(HttpServletRequest request,HttpServletResponse response)throws ServletException, IOException{ int criterioBusqueda =


118

Integer.parseInt(request.getParameter("criterio")); String info = request.getParameter("info"); IncidenciaControl inciControl = new IncidenciaControl(); request.setAttribute("listaIncidencias",inciControl.consulta(criterioBusqueda, info) ); request.getRequestDispatcher("presentacionConsulta.jsp").forward(request,response); } public void modificarPresentacion(HttpServletRequest request,HttpServletResponse response)throws ServletException, IOException{ IncidenciaBeans incidencias= new IncidenciaBeans(); IncidenciaControl inciControl = new IncidenciaControl(); incidencias= inciControl.buscarModificar(Integer.parseInt(request.getParameter("id"))); request.setAttribute("incidencias",incidencias); request.getRequestDispatcher("modificarIncidencia.jsp").forward(request,response); } public void aceptarModificar(HttpServletRequest request,HttpServletResponse response)throws ServletException, IOException{ IncidenciaBeans incidencia = new IncidenciaBeans(); IncidenciaControl inciControl = new IncidenciaControl(); Date fechaActual = new Date(); SimpleDateFormat formato = new SimpleDateFormat("yyyyMMdd"); String cadenaFecha = formato.format(fechaActual); incidencia.setId(Integer.parseInt(request.getParameter("id"))); incidencia.setCod_usuario(Integer.parseInt(request.getParameter("codUsuario"))); incidencia.setFecha_alta(Integer.parseInt(request.getParameter("fechaAlta"))); incidencia.setFecha_resolucion(Integer.parseInt(cadenaFecha)); incidencia.setTelefono(Integer.parseInt(request.getParameter("telefono"))); incidencia.setUbicacion(request.getParameter("ubicacion")); incidencia.setDescripcion(request.getParameter("descripcion")); incidencia.setComentarios(request.getParameter("comentarios")+" "+request.getParameter("comentarios2")); incidencia.setCriticidad(request.getParameter("criticidad")); incidencia.setEstado("estado");


119

inciControl.modificar(incidencia); consulta(request,response); } } 6.1.3 Código de la consulta a la base de datos de usuarios. package gestion.dao; import java.sql.Connection; import java.sql.DriverManager; import java.sql.ResultSet; import java.sql.SQLException; import java.sql.Statement; import gestion.beans.Errores; import gestion.beans.UsuariosBeans; public class UsuariosDao { Errores errores = new Errores(); private Connection con = null; public void conectar(){ try{ Class.forName("sun.jdbc.odbc.JdbcOdbcDriver"); String myDB="jdbc:odbc:DRIVER=Microsoft Access Driver (*.mdb); DBQ=C:/WorkSpaces/WorkSpace Web/Gestion/Usuarios.mdb"; con=DriverManager.getConnection(myDB,"",""); }catch (SQLException se){ System.out.println("Error: "+se.getMessage()); }catch (ClassNotFoundException ce){ System.out.println("Error: "+ce.getMessage()); } } public boolean buscar(UsuariosBeans usuarios ){ Statement st = null; ResultSet rs = null; try {


120

String query = "SELECT * FROM Usuarios WHERE Cod_usuario = "+usuarios.getCod_usuario()+" And Password= '"+usuarios.getPassword()+"'";

conectar(); st = con.createStatement(); rs = st.executeQuery(query); if(rs.next()){ usuarios.setCod_usuario(rs.getInt("cod_usuario")); usuarios.setPassword(rs.getString("password")); usuarios.setNombre(rs.getString("nombre")); usuarios.setApellido1(rs.getString("apellido1")); usuarios.setApellido2(rs.getString("apellido2")); usuarios.setTelefono(rs.getInt("telefono")); usuarios.setCorreo(rs.getString("correo")); usuarios.setCod_departamento(rs.getInt("cod_departamento")); usuarios.setPerfil(rs.getString("Perfil")); st.close(); con.close(); return true; } } catch (SQLException e) { usuarios.setError(e.getMessage()); } finally{ try { st.close(); con.close(); } catch (SQLException e) { errores.setMensajeError(e.getMessage()); } } return false; } }


121

6.1.4 Código del constructor de usuarios. package gestion.beans; public class UsuariosBeans { private int cod_usuario; private String password; private String nombre; private String apellido1; private String apellido2; private int telefono; private String correo; private int cod_departamento; private String perfil; private String error = ""; public UsuariosBeans(){} public int getCod_usuario() { return cod_usuario; } public String getPassword() { return password; } public String getNombre() { return nombre; } public String getApellido1() { return apellido1; } public String getApellido2() { return apellido2; } public int getTelefono() { return telefono; } public String getCorreo() {


122

return correo; } public String getError() { return error; } public int getCod_departamento() { return cod_departamento; } public String getPerfil() { return perfil; } public void setCod_usuario(int cod_usuario) { this.cod_usuario = cod_usuario; } public void setPassword(String password) { this.password = password; } public void setNombre(String nombre) { this.nombre = nombre; } public void setApellido1(String apellido1) { this.apellido1 = apellido1; } public void setApellido2(String apellido2) { this.apellido2 = apellido2; } public void setTelefono(int telefono) { this.telefono = telefono; } public void setCorreo(String correo) { this.correo = correo; } public void setCod_departamento(int cod_departamento) { this.cod_departamento = cod_departamento; } public void setPerfil(String perfil) { this.perfil = perfil; } public void setError(String error){


123

this.error=error; } } 6.1.5 Código de la clase control de usuarios. package gestion.control; import gestion.beans.UsuariosBeans; import gestion.dao.UsuariosDao; public class UsuariosControl { public UsuariosControl(){} public boolean buscar(UsuariosBeans u){ UsuariosDao ud=new UsuariosDao(); boolean b=ud.buscar(u); return(b); } } Para evitar problemas de seguridad de que algún usuario estándar pueda hacerse pasar

por usuario avanzado mediante la url de la página se ha implementado el uso de

sesiones de manera que en cuanto el usuario se valide se guarde su perfil durante toda su

sesión impidiendo que mediante la url acceda al perfil de un usuario avanzado.

6.2 Menú de usuario. Una vez el usuario se ha validado le aparecerá el menú en el cuál podrá elegir si desea

dar de alta una incidencia o consultarla. Tanto para un usuario estándar como para un

usuario avanzado aparentemente tendrán el mismo menú pero la diferente radicará en

que un usuario estándar al hacer una consulta solamente podrá ver los datos referentes a

las incidencias que a consultado pero si es un usuario avanzado aparecerá un botón para

modificar los datos.

Una vez presionado el botón aparecerá la información actual de la incidencia y el

usuario podrá modificar los datos salvo el ID de la incidencia, la fecha en la que se dio

de alta la incidencia ya que toma la del sistema en el momento de darse de alta, la fecha


124

de resolución ya que será la fecha del sistema en el momento en que un usuario

modifique su estado poniéndola como resuelta y los datos personales del usuario

(teléfono, código, ubicación, etc…).

Para dar de alta una incidencia el usuario solo tendrá que presionar el botón de dar de

alta una incidencia en el menú y le aparecerá una pantalla con todos los datos requeridos

para dar de alta la incidencia. Una vez introducidos todos los datos se presionará el

botón aceptar y la incidencia será dada de alta.

6.2.1 Código pagina web menú usuario. <%@ page import = "gestion.beans.UsuariosBeans" %> <%@ page session='true'%> <html> <head> <meta http-equiv="Content-Language" content="es"> <meta http-equiv="Content-Type" content="text/html; charset=windows-1252"> <title>Herramienta de Gestión de Incide</title> </head> <body> <% HttpSession sesion= request.getSession(); UsuariosBeans us = (UsuariosBeans)sesion.getAttribute("usuario"); %> <div style="position: absolute; width: 986px; height: 100px; z-index: 1; left: 18px; top: 4px; background-color: #FFFF00" id="capa1"> <p align="center"> </p> <p align="center"><font color="#0000FF" size="6">Herramienta de Gestión de Incidencias</font></p> <p> </div> <p> </p> <p> </p> <p> </p> <p> </p> <p>BIENVENIDO</p> <p>Por favor: seleccione la operación que desea realizar:</p> <form action="ConsultaTipo" method="POST" > <p align="center">


125

<input type=hidden name=fAccion value=consulta> <p><input type="submit" value="CONSULTAR INCIDENCIA" name="CONSULTA"></p> </form> <form name=alta action="ConsultaTipo" method="POST" > <p align="center"> <input type=hidden name=fAccion value=alta> <p><input type="submit" value="DAR DE ALTA UNA INCIDENCIA" name="NUEVA"></p> </form> <p> </p> <form method=post name=salir action="ConsultaTipo"> <input type=hidden name=fAccion value=salir> <p><input type="submit" value="SALIR DE LA APLICACIÓN" name="SALIDA"></p> </form> </body> </html> 6.2.2 Código pagina web alta de incidencia. <html> <head> <meta http-equiv="Content-Language" content="es"> <meta http-equiv="Content-Type" content="text/html; charset=windows-1252"> <title>Herramienta de Gestión de Incide</title> </head> <body> <div style="position: absolute; width: 986px; height: 100px; z-index: 1; left: 18px; top: 4px; background-color: #FFFF00" id="capa1"> <p align="center"> </p> <p align="center"><font color="#0000FF" size="6">Herramienta de Gestión de Incidencias</font></p> <p> </div> <p> </p> <p> </p> <p> </p> <p>NUEVA INCIDENCIA</p> <FORM name=alta action="ConsultaTipo" method=post>


126

<input type=hidden name=fAccion value=altaIncidencia /> <p>USUARIO :      <input type="text" name="usu" size="20"></p> <p>TELEFONO:    <input type="text" name="tel" size="20"></p> <p>UBICACION :<input type="text" name="ubi" size="20"></p> <p>DESCRIPCIÓN BREVE   <textarea rows="2" name="des" cols="20"></textarea></p> <p>COMENTARIOS    <textarea rows="2" name="com" cols="20"></textarea></p> <p>CRITICIDAD        <select size="1" name="cri"> <option selected>BAJA</option> <option>MODERADA</option> <option>ALTA</option> </select></p> <p> </p> <p><input type="submit" value="ACEPTAR" name="B1"> <input type="reset" value="BORRAR" name="B2"> <input type="submit" value="ATRAS" name="B3"></p> </FORM> </body> </html> 6.2.3 Código pagina web selección de criterio para la búsqueda.

<html> <head> <meta http-equiv="Content-Language" content="es"> <meta http-equiv="Content-Type" content="text/html; charset=windows-1252"> <title>Herramienta de Gestión de Incide</title> </head> <body> <div style="position: absolute; width: 986px; height: 100px; z-index: 1; left: 18px; top: 4px; background-color: #FFFF00" id="capa1"> <p align="center"> </p> <p align="center"><font color="#0000FF" size="6">Herramienta de Gestión de Incidencias</font></p> <p> </div> <p> </p>


127

<p> </p> <p> </p> <p> </p> <form name=consulta action="ConsultaTipo" method="post"> <input type=hidden name=fAccion value="consultarIncidencia"> <p>CONSULTA DE INCIDENCIAS:</p> <p>SELECCIONE EL CRITERIO DE BÚSQUEDA <select size="1" name="criterio"> <option value="1">Por Usuario</option> <option value="2">Por Estado</option> <option value="3">Por Número de Incidencia</option> <option value="4">Por Departamento</option> </select></p> <p>Introduzca información para la consulta:   <input type="text" name="info" size="20"></p> <p> </p> <p> <input type="submit" value="ACEPTAR" name="B1"> <input type="reset" value="CANCELAR" name="B2"></p> </form> </body> </html> 6.2.4 Código pagina web para mostrar el resultado de una búsqueda. <%@ page language="java" contentType="text/html; charset=ISO-8859-1" pageEncoding="ISO-8859-1"%> <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"> <%@ page import="java.util.ArrayList" %> <%@ page import = "gestion.beans.IncidenciaBeans" %> <%@ page import = "gestion.beans.UsuariosBeans" %> <%@ page session='true'%> <html> <head> <meta http-equiv="Content-Language" content="es"> <meta http-equiv="Content-Type" content="text/html; charset=windows-1252"> <title>Datos Encontrado de la Consulta</title> </head> <%ArrayList listaIncidencias = (ArrayList)request.getAttribute("listaIncidencias"); %> <body> <% HttpSession sesion= request.getSession();


128

UsuariosBeans us = (UsuariosBeans)sesion.getAttribute("usuario"); %> <div style="position: absolute; width: 986px; height: 100px; z-index: 1; left: 18px; top: 4px; background-color: #FFFF00" id="capa1"> <p align="center"> </p> <p align="center"><font color="#0000FF" size="6">Datos Encontrado de la Consulta</font></p> <p> </div> <p> </p> <p> </p> <p> </p> <p> </p> <p> </p> <form name=modificar method=post action="ConsultaTipo"> <table border=2 align=center> <tr> <td><b>CODIGO DE INCIDENCIA</b></td> <td><b>FECHA DE ALTA</b></td> <td><b>FECHA DE RESOLUCIÓN</b></td> <td><b>CRITICIDAD</b></td> <td><b>ESTADO</b></td> <td><b>CODIGO DE DEPARTAMENTO</b></td> <td><b>CODIGO DE USUARIO</b></td> <td><b>DESCRIPCION</b></td> <td><b>COMENTARIOS</b></td> <td><b>TELEFONO</b></td> <td><b>UBICACION</b></td> <%if(us.getPerfil().equals("avanzado")){ %> <td></td> <%} %> </tr> <% for(int i=0 ; i<listaIncidencias.size();i++){ %> <tr> <input type=hidden name=fAccion value=modificar> <input type=hidden name=id value=<%= ((IncidenciaBeans)listaIncidencias.get(i)).getId()%>> <td><%= ((IncidenciaBeans)listaIncidencias.get(i)).getId()%></td> <td><%= ((IncidenciaBeans)listaIncidencias.get(i)).getFecha_alta()%></td> <td><%= ((IncidenciaBeans)listaIncidencias.get(i)).getFecha_resolucion()%></td> <td><%= ((IncidenciaBeans)listaIncidencias.get(i)).getCriticidad()%></td>


129

<td><%= ((IncidenciaBeans)listaIncidencias.get(i)).getEstado()%></td> <td><%= ((IncidenciaBeans)listaIncidencias.get(i)).getCod_departamento()%></td> <td><%= ((IncidenciaBeans)listaIncidencias.get(i)).getCod_usuario()%></td> <td><%= ((IncidenciaBeans)listaIncidencias.get(i)).getDescripcion()%></td> <td><%= ((IncidenciaBeans)listaIncidencias.get(i)).getComentarios()%></td> <td><%= ((IncidenciaBeans)listaIncidencias.get(i)).getTelefono()%></td> <td><%= ((IncidenciaBeans)listaIncidencias.get(i)).getUbicacion()%></td> <%if(us.getPerfil().equals("avanzado")){ %> <td><input type=submit name=MODIFICAR value=MODIFICAR></td> <%} %> </tr> <%} %> </table> </form> </body> </html> 6.2.5 Código pagina web para modificar una incidencia. <%@ page language="java" contentType="text/html; charset=ISO-8859-1" pageEncoding="ISO-8859-1"%> <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"> <%@ page import="java.util.ArrayList" %> <%@ page import = "gestion.beans.IncidenciaBeans" %> <%@ page import = "gestion.beans.UsuariosBeans" %> <%@ page session='true'%> <html> <head> <meta http-equiv="Content-Language" content="es"> <meta http-equiv="Content-Type" content="text/html; charset=windows-1252"> <title>Datos Encontrado de la Consulta</title> </head>


130

<%IncidenciaBeans incidencias = (IncidenciaBeans)request.getAttribute("incidencias"); %> <body> <% HttpSession sesion= request.getSession(); UsuariosBeans us = (UsuariosBeans)sesion.getAttribute("usuario"); %> <div style="position: absolute; width: 986px; height: 100px; z-index: 1; left: 18px; top: 4px; background-color: #FFFF00" id="capa1"> <p align="center"> </p> <p align="center"><font color="#0000FF" size="6">Datos Encontrado de la Consulta</font></p> <p> </div> <p> </p> <p> </p> <p> </p> <p> </p> <p> </p> <form name=aceptarModificar method=post action="ConsultaTipo"> <table border=2 align=center> <tr> <td><b>CODIGO DE INCIDENCIA</b></td> <td><b>FECHA DE ALTA</b></td> <td><b>FECHA DE RESOLUCIÓN</b></td> <td><b>CRITICIDAD</b></td> <td><b>ESTADO</b></td> <td><b>CODIGO DE DEPARTAMENTO</b></td> <td><b>CODIGO DE USUARIO</b></td> <td><b>DESCRIPCION</b></td> <td><b>COMENTARIOS</b></td> <td><b>TELEFONO</b></td> <td><b>UBICACION</b></td> <%if(us.getPerfil().equals("avanzado")){ %> <input type=hidden name=fAccion value=aceptarModificar> <td></td> <%} %> </tr> <tr> <input type=hidden name=id value=<%= incidencias.getId()%>> <input type=hidden name=fechaAlta value=<%= incidencias.getFecha_alta()%>> <input type=hidden name=fechaResolucion value=<%= incidencias.getFecha_resolucion()%>>


131

<input type=hidden name=codUsuario value=<%= incidencias.getCod_usuario()%>> <input type=hidden name=descripcion value=<%= incidencias.getDescripcion()%>> <input type=hidden name=comentarios value=<%= incidencias.getComentarios()%>> <input type=hidden name=telefono value=<%= incidencias.getTelefono()%>> <input type=hidden name=ubicacion value=<%= incidencias.getUbicacion()%>> <td><%= incidencias.getId()%></td> <td><%= incidencias.getFecha_alta()%></td> <td><%= incidencias.getFecha_resolucion()%></td> <td><input type=text name=criticidad value=<%= incidencias.getCriticidad()%>></td> <td><input type=text name=estado value=<%= incidencias.getEstado()%>></td> <td><input type=text name=codDepartamento value=<%= incidencias.getCod_departamento()%>></td> <td><%= incidencias.getCod_usuario()%></td> <td><%= incidencias.getDescripcion()%></td> <td><%= incidencias.getComentarios()%><input type=text name=comentarios2 value=""></td> <td><%= incidencias.getTelefono()%></td> <td><%= incidencias.getUbicacion()%></td> <%if(us.getPerfil().equals("avanzado")){ %> <td><input type=submit name=ACEPTAR value=ACEPTAR></td> <%} %> </tr> </table> </form> </body> </html>


132

6.2.6 Código constructor de incidencia. package gestion.beans; import java.util.ArrayList; public class IncidenciaBeans { // Atributos private int id; private int fecha_alta; private int fecha_resolucion; private String criticidad; private String estado; private int cod_departamento; private int cod_usuario; private String descripcion; private String comentarios; private int telefono; private String ubicacion; private ArrayList listaIncidencias; //Constructor public IncidenciaBeans(int id, int fecha_alta, int fecha_resolucion, String criticidad, String estado, int cod_departamento, int cod_usuario, String descripcion, String comentarios,int telefono,String ubicacion) throws NumberFormatException { this.id=id; this.fecha_alta=fecha_alta; this.fecha_resolucion=fecha_resolucion; this.criticidad=criticidad; this.estado=estado; this.cod_departamento=cod_departamento; this.cod_usuario=cod_usuario; this.descripcion=descripcion; this.comentarios=comentarios; this.telefono=telefono; this.ubicacion=ubicacion; } public IncidenciaBeans(){} //Métodos public String toString()


133

{ String s=id+" "+fecha_alta+" "+fecha_resolucion+" "+criticidad+""+estado+""+cod_departamento+""+ " "+cod_usuario+" "+descripcion+""+comentarios+""+telefono+" "+ubicacion; return s; } public int getId() { return id; } public void setId(int id) { this.id = id; } public int getFecha_alta() { return fecha_alta; } public void setFecha_alta(int fecha_alta) { this.fecha_alta = fecha_alta; } public int getFecha_resolucion() { return fecha_resolucion; } public void setFecha_resolucion(int fecha_resolucion) { this.fecha_resolucion = fecha_resolucion; } public String getCriticidad() { return criticidad; } public void setCriticidad(String criticidad) { this.criticidad = criticidad; } public String getEstado() { return estado; } public void setEstado(String estado) { this.estado = estado; }


134

public int getCod_departamento() {

return cod_departamento; } public void setCod_departamento(int cod_departamento) { this.cod_departamento = cod_departamento; } public int getCod_usuario() { return cod_usuario; }

public void setCod_usuario(int cod_usuario) { this.cod_usuario = cod_usuario; } public String getDescripcion() { return descripcion; } public void setDescripcion(String descripcion) { this.descripcion = descripcion; } public String getComentarios() { return comentarios; } public void setComentarios(String comentarios) { this.comentarios = comentarios; } public int getTelefono() { return telefono; } public void setTelefono(int telefono) { this.telefono = telefono; } public String getUbicacion() { return ubicacion; } public void setUbicacion(String ubicacion) {


135

this.ubicacion = ubicacion; } public ArrayList getListaIncidencias() { return listaIncidencias; } public void setListaIncidencias(ArrayList listaIncidencias) { this.listaIncidencias = listaIncidencias; } } 6.2.7 Código control de incidencia. package gestion.control; import java.util.ArrayList; import gestion.beans.IncidenciaBeans; import gestion.dao.IncidenciaDao; public class IncidenciaControl { public IncidenciaControl(){} public boolean buscar(IncidenciaBeans u){ IncidenciaDao ud=new IncidenciaDao(); boolean b=ud.buscar(u); return(b); } public void alta(IncidenciaBeans incidencia){ IncidenciaDao incidao = new IncidenciaDao(); incidao.alta(incidencia); } public ArrayList consulta(int param,String valor){ IncidenciaDao incidao = new IncidenciaDao(); return incidao.consulta(param,valor);

} public IncidenciaBeans buscarModificar(int id){ IncidenciaDao incidao = new IncidenciaDao(); return incidao.buscarModificar(id); }


136

public void modificar(IncidenciaBeans incidencia){ IncidenciaDao incidao = new IncidenciaDao(); incidao.modificar(incidencia); } } 6.2.8 Código operaciones de bbdd incidencia. package gestion.dao; import java.sql.Connection; import java.sql.DriverManager; import java.sql.ResultSet; import java.sql.SQLException; import java.sql.Statement; import java.util.ArrayList; import gestion.beans.IncidenciaBeans; public class IncidenciaDao { private Connection con = null; public void conectar(){ try{ Class.forName("sun.jdbc.odbc.JdbcOdbcDriver"); String myDB="jdbc:odbc:DRIVER=Microsoft Access Driver (*.mdb); DBQ=C:/WorkSpaces/WorkSpace Web/Gestion/Incidencia.mdb"; con=DriverManager.getConnection(myDB,"",""); }catch (SQLException se){ System.out.println("Error: "+se.getMessage()); }catch (ClassNotFoundException ce){ System.out.println("Error: "+ce.getMessage()); } } public void cerrar(Statement st ){ try { st.close(); con.close(); } catch (SQLException e) { // TODO Auto-generated catch block e.printStackTrace(); }


137

} public boolean buscar(IncidenciaBeans incidencia ){ Statement st = null; ResultSet rs = null; try { String query = "SELECT * FROM Incidencia WHERE id = "+incidencia.getId(); conectar(); st = con.createStatement(); rs = st.executeQuery(query); if(rs.next()){ rs.close(); cerrar(st); return true; } } catch (SQLException e) { // TODO Auto-generated catch block e.printStackTrace(); } finally{ try { rs.close(); } catch (SQLException e) { // TODO Auto-generated catch block e.printStackTrace(); } cerrar(st); } return false; } public void alta(IncidenciaBeans incidencia){ Statement st = null; String op="INSERT INTO Incidencia " + "VALUES("+incidencia.getId()+ ","+ incidencia.getFecha_alta()+ ","+ incidencia.getFecha_resolucion()+ ",'"+ incidencia.getCriticidad()+ "','"+ incidencia.getEstado()+ "',"+ incidencia.getCod_departamento()+ ","+ incidencia.getCod_usuario()+ ",'"+ incidencia.getDescripcion()+


138

"','"+ incidencia.getComentarios()+ "',"+ incidencia.getTelefono()+ ",'"+ incidencia.getUbicacion()+"')"; conectar(); try { st = con.createStatement(); st.executeUpdate(op); } catch (SQLException e) { // TODO Auto-generated catch block e.printStackTrace(); }finally{ cerrar(st); } } public ArrayList consulta(int param,String valor){ Statement st = null; ResultSet rs = null; ArrayList inci = new ArrayList(); try { String query = "SELECT * FROM Incidencia WHERE "; if(param==1) query +="Cod_usuario = "+valor; if(param==2) query +="Estado = '"+valor+"'"; if(param==3) query +="id = "+valor; if(param==4) query +="Cod_departamento = "+valor; conectar(); st = con.createStatement(); rs = st.executeQuery(query); while(rs.next()){ IncidenciaBeans incidencias = new IncidenciaBeans(); incidencias.setId(rs.getInt("id")); incidencias.setFecha_alta(rs.getInt("Fecha_alta")); incidencias.setFecha_resolucion(rs.getInt("Fecha_resolucion")); incidencias.setCriticidad(rs.getString("Criticidad")); incidencias.setEstado(rs.getString("Estado")); incidencias.setCod_departamento(rs.getInt("Cod_departamento")); incidencias.setCod_usuario(rs.getInt("Cod_usuario")); incidencias.setDescripcion(rs.getString("Descripcion"));


139

incidencias.setComentarios(rs.getString("Comentarios")); incidencias.setTelefono(rs.getInt("Telefono")); incidencias.setUbicacion(rs.getString("Ubicacion")); inci.add(incidencias); } return inci; } catch (SQLException e) { // TODO Auto-generated catch block e.printStackTrace(); } finally{ try { rs.close(); } catch (SQLException e) { // TODO Auto-generated catch block e.printStackTrace(); } cerrar(st); } return inci; } public IncidenciaBeans buscarModificar(int id){ Statement st = null; ResultSet rs = null; IncidenciaBeans incidencias = new IncidenciaBeans(); try { String query = "SELECT * FROM Incidencia WHERE id = "+id; conectar(); st = con.createStatement(); rs = st.executeQuery(query); if(rs.next()){ incidencias.setId(rs.getInt("id")); incidencias.setFecha_alta(rs.getInt("Fecha_alta")); incidencias.setFecha_resolucion(rs.getInt("Fecha_resolucion")); incidencias.setCriticidad(rs.getString("Criticidad")); incidencias.setEstado(rs.getString("Estado")); incidencias.setCod_departamento(rs.getInt("Cod_departamento")); incidencias.setCod_usuario(rs.getInt("Cod_usuario")); incidencias.setDescripcion(rs.getString("Descripcion")); incidencias.setComentarios(rs.getString("Comentarios"));


140

incidencias.setTelefono(rs.getInt("Telefono")); incidencias.setUbicacion(rs.getString("Ubicacion")); return incidencias; } } catch (SQLException e) { // TODO Auto-generated catch block e.printStackTrace(); } finally{ try { rs.close(); } catch (SQLException e) { // TODO Auto-generated catch block e.printStackTrace(); } cerrar(st); } return incidencias; } public void modificar(IncidenciaBeans incidencias){ Statement st = null; conectar(); try { st = con.createStatement(); String update = "UPDATE Incidencia SET Fecha_alta = "+incidencias.getFecha_alta()+ " ,Fecha_resolucion = "+incidencias.getFecha_resolucion()+ " ,Criticidad = '"+incidencias.getCriticidad()+"'"+ " ,Estado = '"+incidencias.getEstado()+"'"+ " ,Cod_departamento = "+incidencias.getCod_departamento()+ " ,Cod_usuario = "+incidencias.getCod_usuario()+ " ,Descripcion = '"+incidencias.getDescripcion()+"'"+ " ,Comentarios = '"+incidencias.getComentarios()+"'"+ " ,Telefono = "+incidencias.getTelefono()+


141

" ,Ubicacion = '"+incidencias.getUbicacion()+ "' where id ="+incidencias.getId(); st.executeUpdate(update); } catch (SQLException e) { // TODO Auto-generated catch block e.printStackTrace(); } finally{ cerrar(st); } } }


142

Guía de Usuario


143

Lo primero que veremos nada mas iniciar la aplicación será la pantalla del menú

principal.

En esta pantalla los usuarios deben introducir tanto su código de usuario como su

contraseña tecleándolos en las casillas correspondientes, para validarse como usuarios

de la aplicación, y, a continuación , presionar el botón de aceptar para empezar a

utilizar la aplicación.

La validación del usuario producirá un error tanto si no se rellenan todos los campos

como si los datos son erróneos.


144

El objetivo de esta parte de la aplicación es tanto validar a los usuarios que desean

utilizar la herramienta de gestión de incidencias como aplicar a cada usuario su perfil

según sean usuarios de tipo estándar o avanzado.


145

Una vez validado el usuario le aparecerá el menú con las dos acciones que puede

realizar. Para seleccionar la que desea el usuario solo tendrá que pulsar sobre el botón

de la acción deseada y si lo que desea es salir de la aplicación sólo tendrá que presionar

sobre el botón correspondiente y volverá a la pantalla de login.


146

Si el usuario elige dar de alta una incidencia le aparecerá la siguiente pantalla.

En esta pantalla el usuario debe introducir todos los datos de la incidencia que desea dar

de alta.

Una vez introducidos todos los datos dentro de sus casillas correspondientes solo tendrá

que pulsar el botón aceptar si desea dar de alta la incidencia, si por el contrario el

usuario desea resetear el valor de los campos de textos solo tendrá que pulsar el botón

borrar.

Si deseará el usuario volver al menú principal sin dar de alta ninguna incidencia solo

tendrá que presionar sobre el botón atrás.


147

Si el usuario en el menú principal quisiera consultar una incidencia, una vez presionado

el botón correspondiente en el menú principal, le aparecerá la siguiente pantalla.

En esta pantalla el usuario deberá elegir el criterio de búsqueda por el cual desea

realizar la búsqueda escogiendo uno del desplegable disponible e introducir el valor por

el cual desea realizar la búsqueda dentro de la casilla de texto.

Una vez introducido ambos datos solo tendrá que presionar el botón aceptar para

realizar la consulta o presionar el botón cancelar para volver al menú principal.


148

Una vez realizada la consulta se le presentarán al usuario todos los datos de las

incidencias que corresponden a la búsqueda realizada a partir de los datos suministrados

por el usuario.


149

Si el usuario fuera un usuario avanzado en la pantalla de las consultas a la derecha de

cada incidencia aparecerá el botón de modificar. Este botón sirve para que los usuarios

avanzados puedan realizar modificaciones sobre los datos de las incidencias,


150

Una vez presionado el botón de modificar le aparecerá al usuario la siguiente pantalla,

en la cual podrá modificar los valores de los campos criticidad, estado y código del

departamento el cual está resolviendo la incidencia y también podrá añadir nuevos

comentarios.

Estos valores los deberá introducir dentro de cada cuadro de texto correspondiente.


151

Planificación


152

Para la creación de la herramienta de gestión de incidencias se tienen que

realizar una serie de tareas, las cuales están agrupadas por fases y que son mostradas

en el siguiente diagrama con los respectivos tiempos necesarios para su correcta

realización.

Id Nombre de tarea Duración

1 Reunión Lanzamiento 0 días

2 FASE I 20 días

3 Identif icaci ón de Necesi dades 10 días

4 Anál isis de Requi si tos 10 días

5 FASE II 117 días

6 Estudi o Arquitectura 20 días

7 Diseño Interno 22 días

8 Diseño externo 50 días

9 VºBº Documentación 0 días

10 FASE III 116 días

11 Programación 90 días

12 Pruebas 15 días

13 Im pl antación 11 días

14 Reunión de Cierrre 0 días

01/09

Jefe Proyecto[50%];Analista 1

Jefe Proyecto[50%];Analista 1;Analista 2

Jefe Proyecto[50%];Tecnico Sistemas[25%];Analista 1 ;Analista 2

Jefe Proyecto[25%];Analista 1;Analista 2;Programado r 1

Jefe Proyecto[25%];Analista 1;Programador 1;Program ador 2;Programador 3

13/03

Jefe Proyecto[25%];Analista 1;Programador 1;Program ador 2;Programador 3

Jefe Proyecto[25%];Analista 1;Programador 1;Program ador 2[50%]

Jefe Proyecto[50%];Analista 1;Programador 1

22/08

jul ago sep oct nov dic ene feb mar abr may jun jul ago sep oct nov dic ene feb mar abr may2007 2008


153

� Fase I.

• Identificación de necesidades:

Esta etapa del desarrollo sirve como soporte a la petición del cliente para

establecer las pautas generales de sus necesidades y del contexto del sistema.

El objetivo es exponer el entorno global del problema en estudio, los

objetivos empresariales que se quieren conseguir con la herramienta,

establecer la tipología del usuario al que va dirigida la herramienta, conocer

las restricciones que puedan afectar al plan del desarrollo de la herramienta,

conocer como esta organizado empresarialmente el cliente y conocer

cualquier información acerca de los motivos que han llevado a la

organización del cliente el realizar esta herramienta.

El tiempo estimado para esta tarea es de 10 días.

• Análisis de requisitos:

En esta etapa se pretende alcanzar un conocimiento suficiente del sistema,

definiendo las necesidades, problemas y requisitos del usuarios.

Los objetivos de esta etapa es alcanzar un conocimiento suficiente del

sistema en estudio para proponer una solución al problema planteado y

expresar ese conocimiento mediante el modelo de procesos y el de datos y

obtener la aprobación del cliente para avanzar en el nuevo sistema.

El tiempo estimado para esta tarea es de 10 días.


154

� Fase II.

• Estudio de arquitectura:

En esta fase se pretende definir todas las posibles soluciones de arquitectura

que satisfagan tanto los requisitos como las restricciones de diseño. La

arquitectura debe indicar qué componentes básicos de software (sistemas

operativos a utilizar, el gestor de base de datos más apropiado, etc…), que

componentes básicos de hardware (servidores y estaciones de trabajo

necesarios para explotar el nuevo sistema indicando las características

básicas de estos) y los componentes básicos de comunicación (elementos

necesarios para realizar la conectividad entre los componentes hardware y

software del sistema).

Los objetivos de esta etapa son definir las posibles soluciones que satisfagan

los requisitos y las restricciones, elegir una alternativa propuesta, que será la

que se implante y obtener la aprobación del cliente para la alternativa

escogida.

El tiempo estimado para esta fase es de 20 días.

• Diseño interno:

En esta fase se identifican los diversos componentes software del sistema

describiendo detalladamente sus especificaciones físicas.

Los objetivos de esta fase son identificar y diseñar los componentes software

de cada subsistema, especificar cada uno de los programas a desarrollar ,

obtener el modelo físico de la base de datos y completar los planes de

pruebas , implantación formación y conversión.

El tiempo estimado para esta etapa es de 22 días.


155

• Diseño externo:

En esta fase se completa la definición de especificaciones del sistema a

mecanizar obteniéndose el modelo físico nuevo de procesos y el modelo

lógico de datos, de acuerdo a las plataformas hardware y software elegidas

en la fase anterior.

Los objetivos de esta etapa es obtener el modelo de procesos físico nuevo,

obtener el modelo lógico de datos y definir la estrategia de los planes de

pruebas, implantación, formación y conversión.


� Fase III.

• Programación:

En esta fase se alcanzará la transformación del sistema en un conjunto de

programas que puedan ser ejecutados correctamente bajo criterios de calidad.

Los objetivos de esta etapa son codificar los programas y componentes que

forman el software del sistema, realizar la prueba unitaria de cada uno de los

programas y componentes y documentar la operación del sistemas realizando

la guía o manual de usuario.


• Pruebas:

Una vez desarrollados y probados cada uno de los programas y componentes

que forman el software, deben realizarse una serie de pruebas para conseguir

integrar todo el sistema, de acuerdo al Plan de Pruebas establecido en la

etapa de Diseño Interno.

El único objetivo de esta etapa es probar la integración y funcionamiento


156

global del sistema.


• Implantación.

Una vez probada la integridad del software del sistema y especificada su

instalación y configuración se transfiere el software para llevara cabo la

explotación del sistema.

El único objetivo de esta etapa es implementar el nuevo sistema en la

producción real.



157

Presupuesto del Desarrollo


158

Para desarrollar el presupuesto necesario para la creación de la herramienta de

gestión de incidencias se tienen que tomar dos factores:

� Factor humano:

Este factor se refiere al equipo de personas necesarias para realizar la herramienta.

De acuerdo con la planificación que se ha realizado y al salario medio, los costes

aproximados serian:

- Un Jefe de proyecto cuyo salario suele rondar los 3500 euros mensuales y al

tener que estar presente durante todo el proyecto el coste total ascendería a 38500

euros.

- Un analista cuyo salario suele rondar los 2500 euros mensuales y que estará ç

presente todo durante todo el proyecto más un segundo analista que estará presente

durante unos tres meses sumando los dos un total de 35000 euros.

- Un técnico de sistemas cuyo salario mensual es de unos 1200 euros y , que al

estar presente solo durante un mes, el total será de 1200 euros.

- Un programados cuyo salario mensual es de unos 2000 euros y que estará

presente durante unos 10 meses, un segundo programado deberá estar durante unos

9 meses y un tercero estará en el proyecto unos 8 meses, por lo que el total será de

54000 euros.

De acuerdo a lo mencionado anteriormente el coste total de este factor ascendería a

128700 euros.

� Factor informático:

Dentro de este factor se tiene que tener en cuenta los factores tanto de software

como de hardware.

- Software: dentro de este apartado no será necesario realizar ningún gasto ya que

la herramienta solo necesita para poder funcionar una java virtual machine cuya

distribución es gratuita y el gestor de base de datos Access que viene incluido dentro


159

del paqueta básico de Microsoft Office que prácticamente tienen ya instalados todos

los PC´s de cualquier empresa.

- Hardware: para las estaciones de trabajo no será necesario realizar ningún gasto

ya que la aplicación podrá funcionar perfectamente en cualquier PC´s y para el

servidor el precio variaría entre los 1000 euros si se alquilará el servidor o los 3000

si se decidiera comprar uno.

Con los datos de los dos factores el coste aproximado seria de 129700 euros si se

alquila el servidor o 131700 si se compra un servidor


160

Conclusiones


161

Siempre la relación de los trabajadores con la misma se ha visto reflejado por el

trabajo que estos realizan aunque en ocasiones dicho trabajo no se puede realizar debido

a diferentes incidencias que ocurren en una empresa.

Con el paso de los años se fue actualizando según las tecnologías la forma en que estas

incidencias pasaban a conocimiento de las personas encargadas de resolverlas.

Actualmente se utiliza un servicio de atención telefónica conocido como S.A.U.

(Servicio de Atención al Usuario) al que llama el usuario e informa de la incidencia para

que dicho servicio haga llegar las incidencias a los diferentes departamentos implicados

en resolverlas.

Debido a mi propia experiencia no es difícil observar que este planteamiento tiene fallos

ya que muchas veces es más difícil y pesado para un usuario el tener que llamar para dar

una incidencia que si el mismo pudiera darla en el momento en el que ocurre y, además,

el usuario pierde la posibilidad de ver que ocurre con su incidencia o cuando podría ser

resuelta.

Esta herramienta permitirá al usuario ver y “gestionar” sus incidencias dándoles una

sensación de seguridad ya que en todo momento podrán ver toda la “vida” de su

incidencia desde el momento en el que se da de alta hasta que se resuelve y todo ello

desde un interfaz muy sencillo que no les costará nada en aprender a utilizar.

Es preciso crear herramientas de este tipo ya que una herramienta muy compleja y que

de de lado totalmente al usuario afectado por la incidencia sólo podría crear que los

usuarios se mostrarán reacios a poner sus incidencias y un problema que se podría

resolver en unas horas se tardarán días y, a fin de cuentas, lo más importante en una

empresa no es el uso de herramientas complejas sino de herramientas eficaces y un

buen estado de animo de los trabajadores.


162

Bibliografía


163

[CEBA06] Fco. Javier Ceballos , “Java 2 :Interfaces gráficas y aplicaciones

para Internet”, Ra-Ma

[CEBA05] Fco. Javier Ceballos , “Java 2: Curso de programación”, Ra-Ma

[ABAJ97] J. Benavides Abajo, J.M. Olaizola Bartolomé E. Rivero Cornelio

“SQL” Paraninfo

Documents

Herramienta de gesti n de incidencias · incidencias) de cara a que pueda ser usada por todo el mundo pero que solo los usuarios avanzados tengan la capacidad de modificar las incidencias