diseño e implementación del procedimiento de notificación e investigación de...

T u t o r

J o s é M i g u e l L e ó n B l a n c o

A l u m n o

F r a n c i s c o M o r e n o G ó m e z

1 5 / 0 7 / 2 0 1 3

Escuela Técnica Superior de

Ingeniería

Departamento de Organización Industrial y Gestión

Empresarial 1

Diseño e implementación del procedimiento de notificación e investigación de accidentes e incidentes de un Sistema integrado de Gestión.

Francisco Moreno Gómez Ing. Organización Industrial

2 Diseño e implementación del procedimiento de notificación e investigación de accidentes e incidentes de un Sistema integrado de Gestión.

INDICE

INTRODUCCIÓN

1. OBJETO ................................................................................................................................. 6

1.1 Justificación del proyecto ...................................................................................................... 6

1.2 Objetivo ................................................................................................................................ 8

2. DOCUMENTO DE VISIÓN .................................................................................................... 9

2.1 Procedimiento ...................................................................................................................... 9

2.2 Responsables y funciones. ................................................................................................... 11

2.3 Glosario .............................................................................................................................. 12

3. DESARROLLO Y HERRAMIENTAS ...................................................................................... 14

3.2 Herramientas ...................................................................................................................... 14

3.1 Desarrollo ........................................................................................................................... 15

4. DESCRIPCIÓN DE REQUISITOS DEL SISTEMA ................................................................. 19

4.1 Introducción ....................................................................................................................... 19

4.2 Diagrama de casos de uso .................................................................................................. 19

5. CAPTURA DE LA EXPERIENCIA DEL USUARIO ............................................................... 34

5.1 Introducción ....................................................................................................................... 34

5.2 Definición de pantallas ........................................................................................................ 34

5.3 Mapa de navegación ......................................................................................................... 36

5.4 Enlace de las pantallas con los Diagramas de Actividad de los casos de uso ........................... 43

6. ANÁLISIS DEL SISTEMA ....................................................................................................... 48

6.1 Introducción al análisis ........................................................................................................ 48

6.2 Elaboración del diagrama de análisis ................................................................................... 49



7. DISEÑO DEL SISTEMA ......................................................................................................... 64

7.1. Introducción ...................................................................................................................... 64

7.2. Diagramas de clases de diseño ........................................................................................... 64

8. IMPLEMENTACIÓN ............................................................................................................. 72

8.1 Introducción .................................................................................................................................................... 72

8.2 Implementación ................................................................................................................. 72

9. CONCLUSIÓN ..................................................................................................................... 98

Bibliografía .............................................................................................................................. 99

Anexos I ................................................................................................................................100

Anexos II ...............................................................................................................................101

Anexos III ..............................................................................................................................102



INTRODUCCIÓN

La empresa

AGUAS, como empresa de Abastecimiento y Saneamiento de Aguas de Sevilla S.A.,

comienza su actividad el 23 de octubre de 1974, cuando fue erigida por el Ayuntamiento

de Sevilla como empresa privada municipal, habiendo modificado su denominación

como Metropolitana el 8 de mayo de 2007. Gestiona el abastecimiento directo de agua

potable de la capital hispalense y el de las poblaciones de Camas, Dos Hermanas, Alcalá

de Guadaira, Mairena del Alcor, San Juan de Aznalfarache, Coria del Río, La Puebla del

Río, Alcalá del Río, La Rinconada, El garrobo, y el Ronquillo. Con Agua bruta, sin tratar,

abastece también a las 26 poblaciones situadas en el Aljarafe sevillano y a Guillena - Las

Pajanosas.

Además es responsable del servicio público de alcantarillado y depuración de Sevilla,

Alcalá de Guadaíra, Camas, La Rinconada, San Juan de Aznalfarache, Coria del Río, La

Puebla del Río, Alcalá del Río, Mairena del Alcor, Dos Hermanas y El Ronquillo.

Infraestructuras:

Embalses: Aracena, Zufre, La Minilla y El Gercal.

Estación de tratamiento (E.T.A.P).

La Estación de Tratamiento de Aguas Potables de El Carambolo recibe el caudal (agua

bruta) de los cuatro embalses que gestiona AGUAS (Aracena, Zufre, Minilla y Gergal). El

agua recibe un tratamiento (potabilización) que la hace apta al consumo humano e

industrial. La ubicación de El Carambolo, en la cornisa del Aljarafe hace que el agua llegue

hasta Sevilla desde la Minilla sin necesidad de ser bombeada y desde Gergal a través de

los bombeos de Alcalá y Camas.

Red de distribución.

Abastecimiento. La red de abastecimiento de AGUAS Metropolitana, necesaria para

atender la demanda de toda la población directamente abastecida, tiene de norte sur y de

este a oeste una longitud de 69 y 43 Kilómetros respectivamente. Se abastece también a

doce pueblos de la provincia, que suponen una superficie total de 1.220 Km2 y una

longitud total de tuberías 3.796 kilómetros,



Esta compleja red permite suministrar agua potable tanto a los hogares sevillanos como a

la industria.

Para el riego de zonas verdes, AGUAS, en colaboración con el servicio de Parques y

Jardines, ha establecido abastecimientos autónomos con aguas freáticas y redes

independientes para reducir el consumo de agua potable, sobre todo en periodos de

sequía.

Saneamiento. El emplazamiento de Sevilla, que tiene condiciones favorables en muchos

aspectos, no es propicio para una fácil infraestructura de alcantarillado. El casco de la

ciudad tiene una escasa pendiente. La cota es muy baja. Basta recordar que buena parte de

la ciudad sólo queda a 8 metros por encima del nivel del mar. Por lo que el nivel freático

está bastante alto, sobre todo en invierno.

La red de alcantarillado de AGUAS, de 2.900 kilómetros de longitud, permite eliminar las

aguas residuales de la ciudad transportándola hasta las Estaciones depuradoras de aguas

residuales (EDAR).

Dispone de cuatro estaciones depuradoras de aguas residuales ubicadas en los puntos

cardinales: Norte (San Jerónimo), Este (Ranilla), Oeste (Tablada) y Sur (Copero),

representando una dotación de servicios de depuración para 1.850.000 habitantes

equivalentes:

• San Jerónimo: gestiona un caudal de 90.000 m3 de agua al día y cuya capacidad

(contabilizados como habitantes equivalentes) es de 350.000.

• Tablada: el caudal máximo de diseño es de 50.000 m3 de agua al día, y la capacidad

de tratamiento de 950.000 habitantes equivalentes.

• Copero: mueve un caudal de 255.000 m3 de agua al día, lo equivalente a 200.000

habitantes.

• Ranilla: en 2009 entró en funcionamiento la nueva estación, que utiliza las últimas

tecnologías en depuración de agua, gestionando un total de 50.000 metros cúbicos

de agua al día con una capacidad equivalente a 350.000 habitantes.



1. OBJETO

1.1 Justificación del proyecto.

Partiendo del Sistema Integrado de Gestión establecido por la Empresa y desgranándolo

escalón a escalón se explicara el origen de este proyecto y el motivo del desarrollo de este.

El Consejero Delegado de la Empresa AGUAS establece la Política del Sistema Integrado

de Gestión, como medio para alcanzar la mejora continua en su eficacia, asegurando que

es comprendida, aplicada y mantenida a todos los niveles de la organización, así como que

está a disposición de todas las partes interesadas y que se comunica a todas las personas y

empresas que trabajan para AGUAS o en su nombre.

La estrategia de Calidad, Medio Ambiente, Prevención de Riesgos Laborales (en adelante

PRL) e Investigación, Desarrollo e Innovación adoptada por AGUAS, está basada en los

principios definidos en la Política del Sistema Integrado de Gestión. Esta Política sirve de

marco para establecer los Objetivos globales de la organización.

La Política definida es adecuada a los propósitos de la organización y a la naturaleza y

magnitud de los impactos ambientales y riesgos laborales de sus actividades, productos y

servicios.

Asimismo, establece el compromiso de AGUAS de cumplir con los requisitos que le sean

de aplicación.

Sistema Integrado de Gestión.

El actual Sistema de Gestión integra los Sistemas de Gestión de Calidad, Ambiental, de

I+D+i y de Prevención de Riesgos Laborales, cumpliendo entre otros con los requisitos de

las Normas aplicables a los mismos, así como los establecidos por la legislación vigente.

Sistema de Gestión de PRL.

Según los requisitos especificados por la OHSAS 18001 para un sistema de gestión de la

Seguridad y Salud en el Trabajo, destinados a permitir que una organización controle sus

riesgos, La implantación de este Sistema de gestión nos permite:

• Disminuir la siniestralidad laboral y aumentar la productividad, identificando,

evaluando y controlando los riesgos asociados a cada puesto de trabajo, y evitando

las causas que originan los accidentes y las enfermedades en el trabajo. La

percepción de un entorno más seguro por los trabajadores, conlleva una



disminución de las enfermedades, bajas o absentismo laboral, un aumento de la

productividad, una reducción progresiva de la siniestralidad y una disminución de

sanciones y gastos innecesarios.

• Cumplir la legislación en materia de prevención, integrando ésta última en los

procesos de la organización, lo que conlleva una reducción de los costes y sanciones

administrativas derivadas de su incumplimiento, además de una mejora de la

gestión interna de la organización y de la comunicación entre empresa-trabajador, y

empresa-administraciones y partes interesadas.

• Fomentar una cultura preventiva mediante la integración de la prevención en el

sistema general de la empresa (exigido por ley) y el compromiso de todos los

trabajadores con la mejora continua en el desempeño de la SST.

Procedimiento Notificación e investigación de accidentes e

incidentes.

Dentro de la legislación en materia de prevención El artículo 23 de la Ley de Prevención de

Riesgos Laborales establece que el empresario deberá elaborar y conservar a disposición

de la autoridad laboral una determinada documentación técnica, entre la que se encuentra

la relación de accidentes de trabajo y enfermedades profesionales que hayan causado al

trabajador una incapacidad laboral superior a un día de trabajo. El empresario está

obligado a notificar por escrito a la autoridad laboral los daños para la salud de los

trabajadores a su servicio que se hubieran producido con motivo del desarrollo de su

trabajo.

Conclusión.

Dentro de los elementos que componen un Sistema de gestión de Seguridad la

identificación y evaluación de los accidentes es uno de ellos. Estableciéndolo mediante

procedimientos para revisar e incluir los resultados del estudio de incidentes y accidentes

ocurridos.

Por todo ello se desarrolla un sistema de información web para mejorar el flujo de

información dentro del Sistema, de esa manera se evitara la perdida de información a la

hora de analizar los informes de siniestralidad.



1.2 Objetivo

Establecer la sistemática y las pautas a seguir por AGUAS para realizar la notificación e

investigación de los incidentes, con objeto de:

• Registrar y analizar los incidentes, de manera que no se pierda información y los

análisis sean fieles a la realidad.

• Identificar las causas de los incidentes mediante los análisis de estos y las sinergias

entre los diferentes departamentos.

• Proponer medidas correctivas y/o preventivas para evitar que el mismo tipo de

incidente pueda volver a repetirse y verificar su eficacia.

• Dar conocimiento de los hechos a las partes interesadas, Mutua y Organismos

Oficiales de una manera rápida y eficaz.

Con la consecución de estos objetivos se conseguirá:

• Disminuir la siniestralidad laboral y aumentar la productividad.

• Cumplir la legislación en materia de prevención.



2. DOCUMENTO DE VISIÓN

2.1 Procedimiento

En este punto se describe como se debe de actuar según el procedimiento establecido.

Notificación.

El trabajador/es afectados, o testigos del suceso, avisan al Mando Inmediato.

El lesionado/s cuando la situación así lo requiera acudirá al Servicio Médico de la MUTUA

de Accidentes Profesionales.

El Mando Inmediato, o el responsable de la visita, en su caso, conjuntamente con los

testigos del incidente, cumplimenta el documento Comunicado de Incidente, una vez

tenga el Visto Bueno del Responsable de Área Funcional, lo envía simultáneamente al

Servicio de Prevención Propio, Administración de Recursos Humanos y al Jefe de Centro,

a la mayor brevedad (en ningún caso fuera de las 24 horas siguientes). En el supuesto de

que el incidente fuera mortal o muy grave, o afectara a más de cuatro trabajadores, la

comunicación sería inmediata.

Registros.

Los registros que se generan como consecuencia de la aplicación de este procedimiento

son:

Comunicado de incidente completado por el Mando Inmediato del trabajador con el Visto

Bueno del Responsable de Área Afectada, comunicándolo simultáneamente a

Administración de Recursos Humanos y al Servicio de Prevención Propio, quien lo

estudia. Ambas áreas archivan el comunicado.

Informes de No Conformidad e Informes de Acción Preventiva se emiten por el

Responsable del Área Afectada. Una vez realizado el cierre lo archiva el Servicio de

Prevención Propio.

Informes de siniestralidad laboral, elaborado y archivado por el Servicio de Prevención

Propio.



Investigación de incidentes que ocasionan daños personales o

deterioro de la salud

La investigación de incidentes se realizará por el Responsable del Área del trabajador

accidentado en un plazo no superior a 5 días laborables con el asesoramiento, si se

requiere, del Servicio de Prevención Propio y de los trabajadores, solicitando además su

participación en el proceso de la investigación del incidente. Este plazo será menor en caso

de que la gravedad del incidente así lo requiera. El Servicio de Prevención Propio

intervendrá en la investigación del incidente desde el inicio en caso de que éste fuera

mortal o muy grave, o afectara a más de cuatro trabajadores.

Siempre que ocurra un incidente, el Responsable de Área, con la colaboración del Mando

Intermedio, inicia la investigación del incidente, abriendo un Informe de No Conformidad,

como establece el Procedimiento del Sistema Integrado de Gestión: No Conformidades,

Acciones Correctivas y Preventivas. Para el inicio de la investigación del incidente deberán

tenerse en cuenta los siguientes criterios:

• Las causas serán siempre agentes, hechos o condiciones de trabajo realmente

existentes en el momento del incidente.

• Sólo se aceptan como causas los motivos demostrados, nunca los apoyados en

meras suposiciones. Se han de analizar las diferentes fases del incidente,

determinando las causas.

• Evitar la búsqueda de responsabilidades para obtener datos más fidedignos: se trata

de buscar las causas, no los culpables.

• Evitar hacer juicios de valor durante la toma de datos.

• Entrevistar a todas las personas que tengan información sobre el incidente, ya sea

por haber sido testigos del mismo, por su conocimiento del proceso o de las

instalaciones, solicitando además su participación en el proceso de investigación del

incidente.

• En el Informe de No Conformidad abierto para dejar constancia de la investigación

del incidente deberá incluirse la siguiente información:

• Departamento y sección;

• Centro de Trabajo/ Instalación en el que se ha producido el incidente;

• fecha, hora del día y hora de la jornada de trabajo (1ª, 2ª, 3ª …) en la que se ha

producido el incidente;



• fecha de inicio del informe;

• datos del accidentado (nombre, nº de matrícula, edad, puesto de trabajo, tiempo en

el puesto de trabajo);

• datos del incidente (naturaleza de la lesión, objeto/ equipo/ sustancia que causó la

lesión, persona con más control sobre el objeto/ equipo/ sustancia)

• testigos del incidente.

El Responsable de Área Funcional incluirá las acciones correctivas y/o preventivas que

considere.

El Servicio de Prevención Propio analiza y valida la investigación del incidente. El

Responsable de área definirá las medidas correctivas y/o preventivas a aplicar, las

planificará y propondrá el Responsable de implantarlas, conforme a las responsabilidades

asignadas por el Manual de Prevención de Riesgos Laborales. Si las medidas correctoras

afectaran al Centro de Trabajo, el Responsable del Servicio de Prevención Propio

informará al Jefe de Centro.

El Responsable del Servicio de Prevención Propio podrá consultar con la Dirección la

planificación de las medidas correctoras propuestas, en caso de que las circunstancias

particulares del incidente así lo hagan aconsejable. En este caso será el Director del Área

Responsable de la Implantación el que designe el Responsable de la Implantación de las

medidas.

2.2 Responsables y funciones.

Directores de área responsable de implantación

Nombrar a los responsables de la implantación de acciones correctivas, a solicitud del

Responsable del Servicio de Prevención.

Mando inmediato

Cumplimentar el documento Comunicado de incidente y, con el Visto Bueno del

Responsable de Área Afectada, entregarlo al Servicio de Prevención Propio, a

Administración de Recursos Humanos y al Jefe de Centro simultáneamente.



Responsable área funcional

Realizar la investigación de incidentes de los trabajadores de su Área, cumplimentando el

correspondiente Informe de No Conformidad o Informe de Acción Preventiva según

corresponda, con el asesoramiento del Servicio de Prevención Propio, si lo considera

necesario.

Proponer acciones correctivas o preventivas.

Servicio de prevención propio

Revisar y validar las investigaciones de los incidentes, realizadas por los Responsables de

las Áreas Funcionales, y en su caso determinar si procede su ampliación, comprobando

que las acciones preventivas o correctivas son adecuadas, implantadas y eficaces.

Consultar, en los casos que estime conveniente, al Director de Área Responsable de la

Implantación, acerca de la designación del Responsable de Implantación de las medidas

correctivas o preventivas.

Elaborar informes de siniestralidad laboral.

Asesorar a los Responsables de Área Funcional en la investigación de incidentes.

Realizar, en su caso, las ampliaciones de las investigaciones de incidentes.

Proponer medidas correctivas o preventivas en caso de ampliación de las investigaciones

de incidentes.

Trabajador

Comunicar los incidentes al Mando Inmediato.

Colaborar en las investigaciones de incidentes.

2.3 Glosario

Notificación de accidentes: Es una técnica reactiva que consiste en la cumplimentación y

envío del parte oficial de accidente de trabajo, el cual describe el accidente de una forma

completa y resumida.

Registro de Accidentes: Es el paso siguiente a la notificación de accidentes y consiste en la

elaboración de unas bases de datos en las que se reflejan los datos del parte de accidente

para realizar después un análisis estadístico de estos datos que determinen los factores que



hay que corregir. Si el registro de accidentes lo elabora la propia empresa mediante parte

internos, será más fácil detectar maniobras peligrosas, actos inseguros, puestos de trabajo

con accidentes repetitivos

Si el registro de accidentes lo elabora la Administración mediante la información

suministrada en el parte oficial de accidente, se podrán comparar los datos con los de otras

empresas del mismo sector.

El registro de accidentes es una herramienta adecuada para:

• comparar accidentalidad entre puestos de trabajo, secciones, empresas, sectores

• identificar causas comunes

• elaborar fuentes de datos sobre siniestralidad

Accidente: laboral: Cualquier suceso no esperado ni deseado que da lugar a pérdidas de

salud o lesiones a los trabajadores, pudiendo provocar baja o no del accidentado. En

adelante se entenderá que el “accidente laboral” es, a su vez, un tipo de incidente.

Incidente: Suceso relacionado con el trabajo en el cual ocurre o podría haber ocurrido un

daño, o deterioro de la salud, o una fatalidad. Se incluye lo que con anterioridad se

denominaba “accidente laboral”, conllevara baja del trabajador o no.



3. DESARROLLO Y HERRAMIENTAS

3.1 Desarrollo

El primer paso es recolectar toda la información posible y analizar cuál será de utilidad y

cual no.

• Documentación sobre el sistema (Sistema integrado de gestión, Sistema de gestión

de seguridad, OHSAS 18001).

• Requerimientos legales (ley 31/1995).

• Documentación técnica (UML PHP, SQL).

Segundo paso Captura de requisitos.

• Descripción de Requisitos del sistema (Casos de Uso y diagramas de actividades).

Tercer paso Captura de la experiencia del usuario.

• Definición de las pantallas del sistema. Las pantallas representan las partes del

sistema que interactúa con el usuario.

• Descripción del mapa de navegación del sistema. el mapa de navegación del

sistema es la descripción de todas las pantallas del sistema y la relación entre las

mismas.

• Enlace de pantallas con los diagramas de actividades de los casos de uso.

Cuarto paso Análisis del sistema.

• Modelo de Clases de Análisis.

• Asociar clases tipo control a los Diagramas de actividades.

Quinto paso Diseño del sistema.

• Clases de diseño.

Sexto paso Implementación.



3.2 Herramientas

3.2.1 Unified Modeling Language (UML).

El Lenguaje Unificado de Modelado expresado por sus siglas UML del inglés Unified

Modeling Language, es un lenguaje de modelado de sistemas de software más conocido y

utilizado en la actualidad; está respaldado por el Object Management Group. Se trata de

un lenguaje gráfico para visualizar, especificar, construir y documentar un sistema. UML

ofrece un estándar para describir un modelo del sistema, incluyendo aspectos

conceptuales tales como procesos de negocio y funciones del sistema, y aspectos concretos

como expresiones de lenguajes de programación, esquemas de bases de datos y

componentes reutilizables.

Es importante resaltar que UML es un "lenguaje de modelado" para especificar o para

describir métodos o procesos. Se utiliza para definir un sistema, para detallar los artefactos

en el sistema y para documentar y construir.

En otras palabras, es el lenguaje en el que está descrito el modelo. Se puede aplicar en el

desarrollo de software entregando gran variedad de formas para dar soporte a una

metodología de desarrollo de software (tal como el Proceso Unificado Racional o RUP),

pero no especifica en sí mismo qué metodología o proceso usar.

UML no puede compararse con la programación estructurada, pues UML significa

Lenguaje Unificado de Modelado, no es programación, solo se diagrama la realidad de

una utilización en un requerimiento. Mientras que, programación estructurada, es una

forma de programar como lo es la orientación a objetos, sin embargo, la programación

orientada a objetos viene siendo un complemento perfecto de UML, pero no por eso se

toma UML sólo para lenguajes orientados a objetos.

A continuación se describirán los principales bloques en los que consta este lenguaje

3.2.1.1 Bloques de UML

Todos los bloques que se pueden dibujar con UML son construidos con tres tipos de

bloque:

Elementos: Son las entidades del sistema.

Relaciones: Sirven para establecer la conexión lógica que existe entre elementos.

Diagramas: Son agrupaciones de elemento y relaciones.



3.2.1.2 Elementos Básicos de UML

Existen cuatro tipos de elementos en UML:

Los elementos estructurales: Representan cosas conceptuales o físicas del modelo.

En la elaboración de este Sistema solo se describirán dos:

o Los Casos de Uso.

o Las clases.

Elementos de comportamiento: Describen la forma en la que se comporta el modelo

Elementos de agrupación: Las cajas o grupos de cosas en las que puede

descomponerse un modelo.

Elementos de anotación: Estos sirven para introducir comentarios en el modelo.

3.2.1.2 Diagramas de UML

UML dispone de un conjunto de diagramas para describir determinados aspectos del

Sistema de Información, no quiere decir que se utilicen todos, dependiendo del tipo de

sistema que se va a desarrollar y en función de la metodología que se vaya a emplear.

Estos diagramas son:

Diagramas de Caso de Uso.

Diagramas de Actividades.

Diagramas de Secuencia.

Diagrama de Clases.

Diagrama de Colaboración.

Diagrama de Objetos.

Diagrama de Estados.

Diagrama de Componentes.

Diagrama de Despliegue.

En este documento se trabajara con los siguientes diagramas:

Diagramas de Caso de Uso.


Diagrama de Clases.



3.2.2 HTML

HTML (HyperText Markup Language) es un lenguaje muy sencillo que permite describir

hipertexto, es decir, texto presentado de forma estructurada y agradable, con enlaces

(hyperlinks) que conducen a otros documentos o fuentes de información relacionadas, y

con inserciones multimedia (gráficos, sonido...) La descripción se basa en especificar en el

texto la estructura lógica del contenido (títulos, párrafos de texto normal, enumeraciones,

definiciones, citas, etc) así como los diferentes efectos que se quieren dar (especificar los

lugares del documento donde se debe poner cursiva, negrita, o un gráfico determinado) y

dejar que luego la presentación final de dicho hipertexto se realice mediante el navegador.

3.2.3 PHP

PHP (Hypertext Preprocessor) es un lenguaje de código abierto especialmente adecuado

para desarrollo web y que puede ser incrustado en HTML.

Un lenguaje del lado del servidor es aquel que se ejecuta en el servidor web, justo antes de

que se envíe la página a través de Internet al cliente. Las páginas que se ejecutan en el

servidor pueden realizar accesos a bases de datos, conexiones en red, y otras tareas para

crear la página final que verá el cliente. El cliente solamente recibe una página con el

código HTML resultante de la ejecución de la PHP. Como la página resultante contiene

únicamente código HTML, es compatible con todos los navegadores.

PHP se escribe dentro del código HTML, lo que lo hace realmente fácil de utilizar, Es

independiente de plataforma, puesto que existe un módulo de PHP para casi cualquier

servidor web. Esto hace que cualquier sistema pueda ser compatible con el lenguaje y

significa una ventaja importante, ya que permite portar el sitio desarrollado en PHP de un

sistema a otro sin prácticamente ningún trabajo.

Este lenguaje de programación está preparado para realizar muchos tipos de aplicaciones

web gracias a la extensa librería de funciones con la que está dotado. La librería de

funciones cubre desde cálculos matemáticos complejos hasta tratamiento de conexiones de

red, por poner dos ejemplos.

Algunas de las más importantes capacidades de PHP son: compatibilidad con las bases de

datos más comunes, como MySQL, mSQL, Oracle, Informix, y ODBC, por ejemplo. Incluye

funciones para el envío de correo electrónico, upload de archivos, crear dinámicamente en

el servidor imágenes en formato GIF, incluso animadas y una lista interminable de

utilidades adicionales.

http://www.desarrolloweb.com/directorio/bases_de_datos/oracle/



3.2.4 SQL

SQL (Structured Query Language) es un lenguaje de programación diseñado para

almacenar, manipular y recuperar datos almacenados en bases de datos relacionales. La

primera encarnación de SQL apareció en 1974, cuando un grupo de IBM desarrolló el

primer prototipo de una base de datos relacional. Relational Software (luego se convirtió

en Oracle) lanzó la primera base de datos relacional comercial.

Existen estándares para SQL. Sin embargo, el SQL que puede utilizarse en cada uno de las

principales Sistema de gestión de bases de datos relacionales (RDBMS) actuales viene en

distintas formas. Esto se debe a dos razones: 1) el estándar SQL es bastante complejo, y no

es práctico implementar el estándar completo, y 2) cada proveedor de base de datos

necesita una forma de diferenciar su producto de otros.

Para la realización de este documento hemos utilizado MYSQL un RDBMS muy utilizado

en aplicaciones WEB.



4. DESCRIPCIÓN DE REQUISITOS DEL SISTEMA.

4.1 Introducción.

La captura de requisitos es el proceso para averiguar qué Sistema de información debe

desarrollarse. Un Sistema de Información se desarrolla con el propósito de que se apliquen

una serie de funciones, que aporten valor a la organización donde se implante.

En esta fase de captura de requisitos se realizara:

• Descripción de Requisitos del sistema (Casos de Uso y diagramas de actividades).

4.2 Diagrama de casos de uso

A continuación se describirá los requisitos funcionales del sistema mediante los Casos de

Uso. Estos describen el comportamiento del sistema y como interaccionan con los distintos

elementos del sistema.

Los Casos de Uso se representaran mediante uno o varios diagramas de Casos de Uso.

La notificación gráfica incluye Actores, Casos de Uso y Relaciones.

Actores: Los actores representan el papel de usuarios genéricos del sistema. Puede tratarse

de un perfil de usuario del sistema, o bien de un sistema externo al sistema que se desea

modelar. En este planteamiento solo tenemos actores con un perfil de usuario del sistema.

Casos de Uso: Es una descripción de la interacción entre un actor y el sistema. El caso de

Uso describe qué hace el sistema ante los requerimientos de los distintos actores

Relaciones: Relaciones entre actores y Casos de Uso representada mediante una línea

continua que indica que ha invocado a un Caso de Uso, o bien que caso de Uso y acto

interactúan entre sí.

Relaciones entre Casos de Uso representadas mediante una línea discontinua. En este caso

la relación es tipo <<include>>, que especifica que la invocación de un Caso de Uso implica

necesariamente que este invocará al menos una vez a los demás Casos de Usos con los que

tenga ese tipo de relación.



Figura 1. Diagrama de Casos de Uso.

Para completar la información proporcionada por el diagrama de Casos de Uso (figura1)

se detallara en qué consisten los Casos de Usos mediante información textual y los

diagramas de Actividades.



4.2.1 Especificación textual de los Casos de Uso

Se tratara en este punto de describir lo que hacen los diferentes Casos de Uso que forman

parte de este documento.

Caso de Uso Identificarse

Casos de Uso Identificarse

Descripción Este Caso de Uso se activa para poder acceder a su

parte del sistema

Actor Mando Intermedio, Recursos Humanos, Jefe de

Centro, Servicio de Prevención, Responsable Área

Funcional

Precondiciones Entrar en el portal web

Postcondiciones Acceso a su parte del sistema

Flujo principal:

Mando Intermedio, RRHH, Jefe de Centro,

Responsable de Área y Servicio de

Prevención.

Sistema

1. Entrar al sistema

3. Identificarse mediante Usuario y Clave 2. Muestra pantalla de validación

4. Validación del sistema

5. Carga los incidentes guardados que se verán en

las pantallas de inicio de RRHH, Jefe de Centro,

Responsable de Área y Servicio de Prevención

6. Muestra la pantalla del mando intermedio,

RRHH, Jefe de Centro, Responsable de Área y

Servicio de Prevención. .

Extensiones:

4a. El nombre de usuario o clave es incorrecto

Mando Intermedio, RRHH, Jefe de Centro,

Responsable de Área y Servicio de Prevención

Sistema

1. Muestra mensaje de error, No se han introducido

los datos correctamente 2. Vuelve al paso 2



Caso de uso Guardar comunicado de incidente.

Casos de Uso Guardar comunicado de incidente

Descripción Este Caso de Uso se activa para grabar el nuevo

comunicado de incidente.

Actor Mando Intermedio

Precondiciones El Mando Intermedio se ha identificado en el

sistema mediante usuario y clave.

Postcondiciones Datos grabados en la base de datos

Flujo principal:

Mando Intermedio Sistema

1. Rellenar datos del comunicado de incidente

2. Grabar comunicado de incidente 3. Grabar datos 4. Muestra mensaje de éxito. Datos grabados

correctamente

Extensiones:

4a. Muestra error


1. Muestra mensaje de error. No se han introducido

los datos correctos en el formulario

2. Vuelve al paso 1

Caso de Uso Búsqueda de incidentes

Casos de Uso Búsqueda de incidentes

Descripción Búsqueda de un incidente por su fecha

Actor Recursos Humanos, Jefe de Centro, Servicio de

Prevención, Responsable Área Funcional

Precondiciones Identificarse y acceder a la pantalla correspondiente

Postcondiciones Seleccionar incidente

Flujo principal:


1. Rellenar fecha del incidente 2. buscar incidente 3. Muestra en Pantalla comunicado de incidente

Extensiones:

2a. Muestra Error


1. Muestra mensaje de error. No hay incidentes

registrados.

2. Vuelve al paso 1



Caso de Uso Seleccionar incidente

Casos de Uso Seleccionar incidente

Descripción Selecciona de una lista el incidente que quiere ver.

Actor Recursos Humanos, Jefe de Centro, Servicio de

Prevención, Responsable Área Funcional

Precondiciones Identificarse

Postcondiciones Leer incidente, enviar incidente o redactar no

conformidad y/o acción correctiva,

Flujo principal:


1. Seleccionar incidente 2. Cargar datos del incidente.

3. Muestra Pantalla incidente

Caso de Uso Comunicación a organismos oficiales y mutua

Casos de Uso Comunicación a organismos oficiales y mutua

Descripción Envío de comunicado de accidente a la autoridad

pertinente

Actor Recursos Humanos

Precondiciones Identificarse

Postcondiciones Confirmación de que se ha enviado correctamente

Flujo principal:


1. Busca y selecciona o selecciona directamente el

incidente (caso de uso)

2. Enviar incidente 3. Envía 4. Enviado correctamente

Extensiones:

3a. Fallo del envío


1. Muestra mensaje de error. No se ha enviado

correctamente 2. Vuelve al paso 2



Caso de Uso Redactar no conformidad y/o informe de acción

preventiva

Casos de Uso Redactar no conformidad y/o informe de acción

preventiva

Descripción Da la posibilidad de redactar y guardar una no

conformidad y/o informe de acción preventiva

Actor Responsable de Área

Precondiciones Identificarse y acceder a la pantalla del Responsable

de Área

Postcondiciones Guardar en base de datos

Flujo principal:




2. Redactar informe de no conformidad y/o acción

preventiva y guardar 3. Guardar datos

4. Muestra grabar datos correcto

Extensiones:

3a. Error al cargar datos


1. Muestra mensaje de error. Se ha producido algún

error 2. Vuelve al paso 2



Caso de Uso Leer

Casos de Uso Leer no conformidad y Acción preventiva

Descripción Acceder a informe de no conformidad y acción

preventiva

Actor Servicio de prevención

Precondiciones Identificarse y acceder a la pantalla de Servicio de

Prevención

Postcondiciones Muestra pantalla de informes

Flujo principal:




3. Mostrar informe de no conformidad y acción

preventiva

4. Cargar informe de no conformidad y acción

preventiva 5. Muestra informe no conformidad y acción

preventiva

Extensiones:

4a. Error no tiene información


1. Error no tiene información

2. Mostrar informe de no conformidad y acción preventiva

Caso de Uso Informe de siniestralidad

Casos de Uso: Informe de siniestralidad

Descripción Realizar informe definiendo fechas

Actor Servicio de prevención

Precondiciones Identificarse y acceder a la pantalla del Servicio de

Prevención

Postcondiciones Muestra Informe de siniestralidad

Flujo principal:


1. Definir fechas para el informe de siniestralidad 2. Cargar datos 3. Muestra Pantalla informe de siniestralidad

Extensiones:

2a. No hay incidentes


1. Muestra mensaje de error. no hay incidentes 2. Vuelve al paso 1



4.2.2 Especificación de los Casos de Uso mediante Diagrama

de Actividades

Los Diagramas de Actividades son unos de los elementos de UML que permiten

representar el comportamiento dinámico de un sistema. Son muy adecuados para

describir los distintos flujos de actividades del sistema para la realización de un Caso de

Uso.

Una de las ventajas del Diagrama de Actividades es que permite representar de forma

compacta en un único diagrama el flujo principal y los flujos alternativos.

4.2.2.1 Identificarse

El diagrama de Actividades “identificarse” muestra de que manera los actores pueden

acceder a la interfaz a la que tienen permiso. Introduciendo la dirección correcta en el

navegador aparecerá por pantalla la página inicial de validación. Con el Nombre y Clave

se identificaran. En el caso de no ser mando intermedio el Sistema cargaría la lista de

incidentes que han sido introducidos en el último mes.

Figura 2. Diagrama de Actividades, Identificarse.



4.2.2.2 Guardar comunicado de incidente

En el Diagrama de Actividades que representa este Caso de Uso “Guardar comunicado de

incidente” se puede observar la secuencia necesaria para grabar los datos del incidente.

Figura 3. Diagrama de Actividades, Guardar comunicado de incidente.



4.2.2.3 Seleccionar incidente

Los actores RRHH, Jefe de centro, Responsable de Área y Servicio de prevención tendrán

la posibilidad de seleccionar unos de los incidentes que se cargaron anteriormente en el

Caso de Uso "Identificarse". Una vez seleccionado el Sistema cargara el incidente y lo

mostrara por pantalla.

Figura 4. Diagrama de Actividades, Seleccionar incidente.



4.2.2.4 Búsqueda de incidente

Puntualizar que tanto el diagrama de Actividades que representa al Caso de Uso

"Búsqueda de Incidente" como el Diagrama "seleccionar Incidente" se encuentran dentro

de otros Diagramas de Actividades. Tras rellenar la fecha en la que ha sido redactado el

Incidente por parte de RRHH, Jefe de centro, Responsable de Área o Servicio de

prevención, el Sistema busca el Incidente y lo muestra por pantalla.

Figura 5. Diagrama de Actividades, Búsqueda de incidente.



4.2.2.5. Comunicación a organismos oficiales y mutua

Como ya se comento en el punto anterior, una vez que se tenga por pantalla el incidente,

el RRHH tendrá la opción de mandar el Incidente al organismo correspondiente. Si

hubiese algún problema en el envío, el sistema devolverá por pantalla “envío fallido” en

caso contrario nos mostrara “enviado correctamente”.

Figura 6. Diagrama de Actividades, Comunicación a organismos oficiales.



4.2.2.6 Redactar no conformidad y/o acción preventiva

En el escenario representado por el Caso de Uso “Redactar No conformidad y/o acción

preventiva” el Responsable de Área además de poder ver por pantalla el incidente,

también tendrá la opción de redactar una no conformidad y/o la acción preventiva

correspondiente. Pudiendo modificarlos cada vez que entre en el incidente.

Figura 6. Diagrama de Actividades, Redactar no conformidad y/o acción preventiva.



4.2.2.7 Leer

El Servicio de prevención, una vez mostrado el incidente en pantalla tiene la posibilidad

de cargar la no conformidad y la acción preventiva en el caso de que estén registradas. En

el caso de que no hubiese datos para mostrar el Sistema respondería con una pantalla de

error.

Figura 7. Diagrama de Actividades, Leer.



4.2.2.7 Informe de siniestralidad

Los actores del departamento del Servicio de prevención también tendrán la posibilidad

de analizar los incidentes. Dentro de su interfaz disponen de un formulario desplegable en

el que podrán seleccionar el intervalo del análisis, el servidor mostrara el informe si se ha

elegido un mes en el que ha habido incidentes.

Figura 8. Diagrama de Actividades, Informe de siniestralidad.



5. CAPTURA DE LA EXPERIENCIA DEL

USUARIO

5.1 Introducción

En esta fase se tratara de determinar la forma que tendrá la interfaz de usuario del sistema.

Esta cuestión es importante no solo porque la interfaz de usuario representa la parte

visible del sistema, sino porque además el diseño de interfaz nos permite validar la fase de

captura de requisitos. La fase de captura de experiencia del usuario recoge las siguientes

tareas:

• Definición de las pantallas del sistema.

• Descripción del mapa de navegación.

• Enlace de pantallas con los diagramas de actividades de los Casos de Uso.

5.2 Definición de las pantallas

Las pantallas de un Sistema de Información representan la interfaz entre el usuario y el

sistema. A través de estas el usuario invoca actuaciones del sistema, introduce datos en el

sistema, y requiere información del mismo.

Las pantallas del Sistema de Información basado en WEB emplearán una clase estereotipo

<<pantalla>>. Con estas pantallas se montara el Mapa de Navegación

Las pantallas que se van a representar en el Mapa de Navegación estarán definidas por el

título de la pantalla, en este caso "RRHH" y una serie de atributos, en este ejemplo

"nombre, apellidos, categoría".

Figura 9. Pantalla, estereotipo <<pantalla>>



En el caso de que se tuviese que introducir datos en el sistema que modifican el

comportamiento del este, estos deben ser recogidos en el modelo de Experiencia del

Usuario mediante un formulario. De este modo el formulario se modelara como una clase

de estereotipo <<formulario>> contenido en la pantalla a la que pertenece.

Figura 10. Formulario, estereotipo <<Formulario>>

En la imagen se observa como el formulario "Búsqueda de incidentes" está contenido

dentro de la pantalla RRHH. El atributo "Fecha" indica que se podrá meter una fecha en la

pantalla RRHH e invocara una actuación en el sistema.

Por último para diferenciar los tipos de listas que hay en una pantalla enlazaremos la

pantalla principal con otras que indicaran que son listas de otro tipo. En este caso serán los

incidentes que se cargan en la interfaz de RRHH. Destacar la multiplicidad de la relación,

en una pantalla de RRHH se pueden tener de cero incidentes hasta varios incidentes.



Figura 11. Representación de pantallas con varias listas.

5.3 Mapa de navegación

El Mapa de Navegación es un Diagrama de Clases en el que aparecen todas las pantallas

del sistema, junto a la relación con las mismas.

La relación entre las mismas se representa mediante una asociación 1 a 1 en la que la

navegavegabilidad de la asociación indica la forma en la que se accede a una pantalla

desde otra.

Debido al tamaño del mapa de navegación, se ha dividido en seis partes para poder ser

visualizado de forma global (anexo I).

5.3.1 Mando intermedio

La primera parte representa la forma como el actor entra en el Sistema de Información.

Destacar que algunas de las pantallas de un Sistema son especiales, este es el caso de la

pantalla principal "Validación" ya que es la pantalla que se muestra por defecto al entrar al

Sistema de Información WEB. Esta es la única dentro del sistema.



Figura 10. Mapa de navegación, Validación.

Las otras cinco partes que forman el Mapa de Navegación corresponden, cada una, a las

interfaces de los cinco diferentes actores que pueden intervenir en el sistema de

información. De esta forma el usuario se valida y accede a su interfaz.


En este escenario el Mando intermedio accede a una pantalla principal donde aparece

nombre, apellidos, categoría laboral y un formulario. En el formulario se dispondrá de

todos los campos obligatorios a rellenar para cumplimentar correctamente el informe. Si se

olvidase algún campo el sistema le mostrara por pantalla el mensaje que aparece en su

atributo “No se han introducido los datos correctos en el formulario”. Al igual que si los

introdujese correctamente, “Datos grabados correctamente”



Figura 11. Mapa de navegación, Mando intermedio.

5.3.3 RRHH

Los actores pertenecientes a esta interfaz se encontraran por pantalla, además de su

nombre, apellidos y categoría laboral otro listado y un formulario.

El listado muestra todos los incidentes que se han producido a lo largo del mes actual y los

ocurridos en el mes anterior.

El formulario da la opción de buscar un incidente por la fecha en que fue cargado en el

sistema por parte del redactor. Si se elige esta opción mostrara una pantalla idéntica a la

anterior pero con los incidentes redactados en esa fecha.



Una vez elegido el incidente en el listado, se podrá seleccionar y el sistema mostrara por

pantalla el informe. Una vez que el actor dé el visto bueno al incidente lo enviara, sino

podrá regresar para seleccionar otro incidente diferente.

Figura 12. Mapa de navegación, Recursos humanos.



5.3.4 Jefe de centro

La interfaz del Jefe de centro es igual que la que se vio anteriormente pero no tiene la

posibilidad de enviar incidentes,

Figura 13. Mapa de navegación, Jefe de centro.



5.3.5 Responsable de área

En esta parte el Responsable de Área será el encargado de realizar el informe de

investigación y adoptar las medidas correctivas y acciones preventivas si así lo ve

oportuno.

Después de la búsqueda del incidente o selección de este, el sistema le mostrara además

del incidente, un formulario que rellenara si lo ve conveniente. En el caso contrario

regresara a la pantalla inicial de esta interfaz.

Figura 13. Mapa de navegación, Responsable de área.



5.3.6 Servicio de prevención

El servicio de prevención es el actor que más posibilidades de interactuar tiene con el

sistema, puede ver incidentes e informes de no conformidad y acción preventiva, y

dispone de una Herramienta para poder analizar los datos introducidos.

La página principal del Servicio de Prevención dispone del formulario "fecha intervalo"

con el se analizara por mes o por año los incidentes que se deseen. Tras meter la fecha,

saldrá por pantalla el Total de incidentes, Las bajas, Las no bajas, Los turnos en que se

produjeron Y las partes afectadas como se muestra en la pantalla "informa de

siniestralidad".

Figura 14. Mapa de navegación, Servicio de prevención.



5.4 Enlace de las pantallas con los Diagramas de Actividad

de los casos de uso

Es interesante para las fases posteriores identificar que pantallas muestra el sistema en

cada actividad de los Diagramas de Actividad desde los distintos Casos de Uso.

5.4.1 Identificarse

Figura 14. Diagrama de análisis identificarse.



5.4.2 Guardar comunicado de incidente

Figura 15. Diagrama de análisis, guardar comunicado de incidente.

5.4.3 Seleccionar incidente

Figura 16. Diagrama de análisis, Seleccionar incidente.



5.4.4 Búsqueda de incidente

Figura 17 Diagrama de análisis, Búsqueda de incidente.

5.4.5 Comunicado a organismos oficiales y mutua

Figura 18. Diagrama de análisis, Comunicado a organismos oficiales y mutua.



5.4.6 Redactar no conformidad y/o informe de acción

preventiva

Figura 19. Diagrama de análisis, Redactar no conformidad y/o informe de acción preventiva.



5.4.7 Leer

Figura 20. Diagrama de análisis, Leer.

5.4.8 Informe de siniestralidad.

Figura 21. Diagrama de análisis, Informe de siniestralidad.



6. ANÁLISIS DEL SISTEMA

6.1 Introducción al análisis

En este capítulo se representara el Diagrama de Análisis, que ayudara a categorizar los

elementos del sistema de información. También facilitara la lectura que hace el sistema de

las acciones que le pasa el usuario, y cómo el sistema interacciona con la base de datos.

Una de las cuestiones más importantes del análisis es que permite categorizar los

elementos del Sistema de Información basado en Web en tres tipos de clases conocidas

como clases de análisis. Estas clases de análisis pueden ser:

Boundary: Representa la interfaz entre usuario y el sistema, en el sistema

representara pantallas WEB.

Control: Es el estereotipo donde el sistema lleva acabo la acción, en el sistema

representa operaciones en el servidor.

Entity: Corresponde a las tablas de la base de datos, donde el sistema interviene.

A continuación se muestra el diagrama de clases de análisis para tener una visión más

global:



Figura 22. Diagrama de clases de análisis.

6.2 Elaboración del diagrama de análisis

Partiendo de los Casos de Uso del sistema y de su detalle mediante el Diagrama de

Actividades se elaborara el Diagrama de Análisis.

Para empezar tendrá que haber un <<Boundary>> por cada Caso de Uso. Seguidamente se

analizaran todas las actividades del sistema del Diagramas de actividades asociado al

Caso de Uso. Si la actividad que realiza el sistema tiene entidad suficiente como para

constituir una funcionalidad independiente, entonces se genera una clase del estereotipo

<<control>> correspondiente a esa actividad. Por último se identificara las clases que

representa a los datos que intervienen en el sistema mediante el estereotipo <<Entity>>.



6.2.1 Análisis de los Casos de Uso

Interfaces y funcionalidades de Identificarse:

Mostrar pantalla de validación se trataría de un formulario vacio cargado como

una página estática desde el cliente. Por tanto, no se implementaría funcionalidad

alguna y no existiría clase <<Control>> correspondiente.

Validación del sistema se trataría de una funcionalidad que se implementa en el

sistema. Por tanto, se crearía la clase <<Control>> denominada Validar usuario.

Muestra error se trataría de una página estática desde el cliente.

Cargar incidentes se trata de una funcionalidad del sistema. La clase <<Control>>

se denominara Cargar incidentes.

Mando intermedio, RRHH, Jefe de centro, Responsable de área y Servicio de

prevención son pantallas clientes por tanto no tienen funcionalidad como tal.

Clases del tipo <<Entity>> de identificarse:

En este caso de detecta perfectamente del Diagrama de actividades y de las

funcionalidades del sistema que hay dos entidades diferenciadas. Para la

funcionalidad Validación del sistema se tendrá la tabla Actores y para la

funcionalidad Cargar Incidentes se tratara de la tabla Incidente. Los atributos de

las clases vienen dados simplemente por la inspección de los formularios de las

páginas estáticas.

Figura 23. Diagrama de clases de análisis, Identificarse.



Las Entidades “actores” e “incidentes” están enlazadas mediante la clave externa

“FK_Id_actor” esto permitirá trabajar con las dos tablas a la hora de implementar.

La multiplicidad indica que un actor puede realizar de cero a varios incidentes.

Figura 24. Entidades1.

Interfaces y funcionalidades de Guardar comunicado de

incidente:

Grabar datos se trata de una funcionalidad del sistema. La clase <<Control>> se

denominara Grabar datos.

Grabar datos correcto y Muestra error solo serían paginas informativas que no

tienen ninguna funcionalidad.

Clases del tipo <<Entity>> de Guardar comunicado de incidente:



A partir de ahora todas las funcionalidades del sistema van a estar íntimamente

relacionadas con la base de datos Incidentes, ya que todos los atributos son parte

fundamental de los datos que tienen que contener este informe.

Figura 25. Diagrama de clases de análisis, Guardar comunicado de incidente.

Para dar más flexibilidad al sistema la información del formulario de incidentes se ha

repartido en tres entidades claramente definidas como se puede observar en la figura 26.

La relación entre estas tablas se ha elaborado igualmente con claves externas.

La multiplicidad de una asociación determina cuantos objetos de cada tipo intervienen en

la relación. En el caso de la relación entre el incidente y la baja médica cuando hay un

incidente podrá haber una baja médica o ninguna. Otro caso que se puede observar es que

un empleado puede estar envuelto desde cero a varios incidentes.



Figura 26. Entidades 2.

Interfaces y funcionalidades de Búsqueda de incidentes:

Búsqueda de incidentes sería una clase <<Control>> y seria implementada en el

sistema como Busca incidentes.

Muestra error páginas cliente sin funcionalidad.

Mostrar incidentes sería una página cliente en la que se representaría la

funcionalidad de búsqueda de incidentes.



Interfaces y funcionalidades de Seleccionar incidente:

Cargar datos del incidente tendría funcionalidad y se representaría la clase

<<Control >> como Cargar datos del incidente.

Mostrar incidente esta página sin funcionalidad no hay que confundirla con la

anterior que se encontraba en Búsqueda de incidentes, una saca un listado de

incidentes y la otra saca por pantalla los datos de un incidente.

Figura 27. Diagrama de clases de análisis, Búsqueda de incidente i seleccionar incidentes.



Interfaces y funcionalidades de Comunicado a organismos

oficiales y mutua:

Envía se ve claramente que es una acción representada por la clase <<Control>>

Enviar.

Muestra error y Enviado correctamente no tiene funcionalidad.

Figura 28. Diagrama de clases de análisis, Comunicado a organismos oficiales y mutua.



Interfaces y funcionalidades de Redactar no conformidad y

actividad preventiva:

Guardar datos tendría funcionalidad y se representaría la clase <<Control >> como

Guardar datos.

Muestra error y Muestra grabar datos correcto.

Figura 29. Diagrama de clases de análisis, Redactar no conformidad y acción preventiva.



Interfaces y funcionalidades de Leer:

Cargar informe de investigación de no conformidad y acción preventiva

Error no tiene información no tiene funcionalidad.

Informe no conformidad y acción preventiva páginas cliente sin funcionalidad.

Figura 30. Diagrama de clases de análisis, Leer.



Interfaces y funcionalidades de Informe de siniestralidad:

Cargar datos tendría funcionalidad y se representaría la clase <<Control >> como

Cargar datos.

Error y Informe de siniestralidad son pantallas clientes por tanto no tienen

funcionalidad como tal.

Figura 31. Diagrama de clases de análisis, Informe de siniestralidad



6.2.2 Asociación de las clases tipo <<Control>> a los


Una vez definido todos los objetos <<control>>, se procede a enlazarlos a los diagramas de

actividades. Los objetos <<control>> Se deben enlazar a las actividades que existen en los

diagramas de actividad.

Este paso podría haberse hecho conjuntamente con el análisis de los casos de uso

anteriormente descrito. Confirmara que el sistema se está diseñando de forma correcta y si

no es así, Ayudara a detectar los fallos.

6.2.2.1 Identificarse

Figura 32. Diagrama de Análisis, Identificarse.



6.2.2.2 Guardar comunicado de incidente

Figura 33. Diagrama de análisis, Guardar comunicado de incidente.

6.2.2.3 Seleccionar incidente

Figura 34. Diagrama de clases de análisis, Seleccionar incidente.



6.2.2.4 Búsqueda incidente

Figura 35. Diagrama de análisis, Búsqueda de incidente.

6.2.2.5 Comunicación a organismos oficiales

Figura 36. Diagrama de análisis, Comunicación a organismos oficiales.



6.2.2.6 Redactar no conformidad y de acción preventiva

Figura 37. Diagrama de análisis, Redactar no conformidad.



6.2.2.7 Leer

Figura 38. Diagrama de análisis, Leer.

6.2.2.8 Informe de siniestralidad

Figura 39. Diagrama de análisis, Informe de siniestralidad



7. DISEÑO DEL SISTEMA

7.1. Introducción

Partiendo de las pantallas de usuario del mapa de navegación y el modelo de clases de

análisis se elabora el diseño del sistema. En el diseño del sistema se puede contemplar dos

puntos de vista del sistema que van a ser implementados. El punto de vista lógica y la

vista de componentes.

Vista lógica: La vista lógica del sistema describe un conjunto de clases que

representan elementos concretos del sistema de información basado en WEB.

Formularios HTML, paginas clientes y páginas de servidor.

Entre Los estereotipos antes mencionados se pueden establecer una serie de

estereotipos de asociación:

· Link: Relaciona una clase de página cliente bien con otra igual, o bien con una

clase de página servidor. Esta asociación representa una abstracción de los

hiperenlaces que se pueden ofrecer entre dos páginas.

· Build: Relaciona una clase de página de servidor con una clase de página de

cliente. Esta asociación representa una abstracción de lo que se muestra al

usuario tras la ejecución de una página de servidor.

· Submit: Relaciona una clase de formulario con una clase de página de servidor.

Esta asociación representa una abstracción de la entrada de datos de usuario

para su posterior procesamiento en la página de servidor.

Vista de componentes: La vista de componentes describe qué archivos van a

constituir el sistema de información basado en WEB. Paginas estáticas (HTML) o

paginas dinámicas (PHP).

7.2. Diagramas de clases de diseño

Debido al tamaño del sistema este se dividirá en seis partes bien diferenciadas, Validación,

Mando intermedio, Recursos Humanos, Jefe de centro, Responsable de centro y Servicio

de prevención. Se puede observar completo en el Anexo II.



Se han diferenciado los estereotipos de clase con diferentes colores para que se puedan

visualizar y diferenciar con facilidad. De esta manera se verá claramente los que

pertenecen a la vista lógica o a la vista de componentes.

7.2.1 Validación

Figura 40. Diseño del sistema, Validación

Se ha seguido la misma fragmentación que en el mapa de navegación. En esta primera

parte la vista de componentes estaría representada por la página dinámica

“validar_usuario.php” en color rojo y las páginas estáticas “Index.html” y

“error_identificación” en color verde. La vista lógica la compondrían las paginas cliente

“validación” y “muestra error” en color rosa, el formulario “validar” en color gris y la

página servidor “validar usuario” en color amarillo. Se puede observar que estas páginas

servidor coinciden con los elementos estereotipados como <<control >> en el Diagrama de

Análisis y las paginas clientes con las pantallas en el Mapa de Navegación.



La pagina servidor validar usuario sería la que interactuaría con las tablas de la base de

datos, en este caso con la <<entity>> actores.

Destacar que la vista de componentes coincide con los archivos que serán implementados.

De esta manera es mucho más sencillo detectar que archivos implementan determinadas

acciones

En las siguientes partes del Diseño del Sistema sigue el mismo patrón que se ha explicado.




Figura 41. Diseño del sistema, Mando intermedio



7.2.3 Recursos Humanos (RRHH)

Figura 42. Diseño del sistema, Recursos Humano



7.2.4 Jefe de centro

Figura 43. Diseño del sistema, Jefe de Centro



7.2.5 Responsable de área

Figura 44. Diseño del sistema, Responsable de Área



7.2.6 Servicio de prevención

Figura 45. Diseño del sistema, Servicio de Prevención



8. IMPLEMENTACIÓN

8.1 Introducción

En esta fase se procede a la generación del código correspondiente de las clases de diseño

definidas en el apartado 9. Emplearemos los lenguajes HTML y PHP para codificar el

sistema de diseño, estas herramientas se explicaron en el punto 3. Durante esta fase se

transformarán las clases de tipo <<entity>> en tablas de la bases de datos del sistema.

A partir de la vista lógica y la vista de componentes de las clases de diseño se generan las

páginas HTML y PHP. A cada clase del estereotipo <<página estática>> le corresponde un

archivo HTML, mientras que a cada clase del estereotipo <<página dinámica>> le

corresponde un archivo PHP. Las funcionalidades concretas de cada una de las clases de

la vista de componentes se implementan teniendo en cuenta las clases de la vista lógica y

las asociaciones correspondientes.

Observando la vista de componentes del Diseño del Sistema podemos contabilizar los

archivos HTML y PHP: Index.html; Validar_usuario.php; Error_identificación.html;

Pagina_mando_intermedio.php; Grabar_datos.php; Rrhh.php; Buscar_incidente.php;

Cargar_datos_del_incidente.php; Enviado.php; Jefe_de_centro.php;

Responsable_de_area.php; Guardar datos.php; Servicio _de_prevención.php;

Cargar_informe.php; Cargar_datos.php



8.2 Implementación

8.2.1 Index.html

La página en código HTML “Index” es la página principal. Cargando nombre y clave

dirige a la página con código PHP “validar_usuario”.

Figura 46.

Figura 47.



8.2.2 Validar_usuario.php

En la imagen inferior se observa como con la variable $_post se obtienen los datos

introducidos en el formulario. A continuación se conecta con el servidor mediante la

función mysqli_connect. Una vez conectados se lanza la consulta (obteniendo de la tabla

actores el nombre y la clave). Se utiliza la función mysqli_query para simplificar la acción

de ejecutar una consulta sobre la base de datos.

Figura 48.

La función mysql_fetch_assoc devuelve una matriz asociativa que corresponde a la fila

recuperada y mueve el apuntador de datos interno hacia adelante. Si devuelve un valor

sacamos el Id_actor, Categoría laboral, nombre y apellidos.

El switch servirá mediante la variable categoría para dirigir a la interfaz que corresponda.

Importante destacar los datos que serán arrastrados a dichas interfaces.

En el caso de que mysql_fetch_assoc devuelva false se pasaría directamente a else y el

sistema llevaría a la página “error_identificacion.html”.



Figura 49.

8.2.3 Error_identificación.html

Página con código HTML que saca por pantalla: El usuario introducido no es válido.

Figura 50.



8.2.4 Pagina_mando_intermedio.php

Figura 51.

Mediante la variable $_get se recuperan los valores arrastrados desde la pantalla validar y

se utilizan por ejemplo para sacar por pantalla nombre, apellidos y categoría. Mediante

echo se podrán visualizar esos datos

En esta página existe codificación PHP y HTML. Siempre que se tenga PHP la extensión

del archivo será PHP. Para diferenciar la parte en código PHP se insertara dentro de <?php

… ?>

Una vez se acaba la parte en PHP inicial aparece un formulario en el se introducen todos

los valores que tiene que registrarse en la base de datos.



Figura 52.

Debido al tamaño del formulario se ha representado la parte inicial en la figura xx y la

parte final en la figura xx.

Por último una vez introducidos los datos iremos a la página “grabar datos”.



Figura 53.

8.2.5 Grabar_datos.php

La función principal de esta página es guardar los datos. Lo primero que se hará es

recuperar los datos y guardarlos en variables.

Figura 54.



En la siguiente figura se adaptaran los formatos de las fechas para que casen con los de la

base de datos y seguidamente se imponen unas condiciones para que se rellene

correctamente el formulario.

Figura 55.

Una vez relleno el formulario correctamente se introduce los datos mediante una consulta

en la base de datos. Al tener tres tablas en las que introducir datos, se ha optado por hacer

tres consultas una seguida de la otra siempre que se realicen correctamente cada una de

ellas.

Con la función mysql_insert_id Se devolverá el identificador generado por el último

Insert. Con la variable obtenida se realiza una consulta para que relacione la tabla anterior

con la nueva.



Figura 56.

Si no se introdujesen bien los datos del incidente aparecería un mensaje por pantalla y la

opción de volver a la página del mando intermedio.

Figura 57.



Figura 58.



8.2.6 Rrhh.php

Como se comento en el punto 5 en las interfaces RRHH, Jefe de Centro, Responsable de

Área y Servicio de prevención aparecen por pantalla una lista de incidentes. Esta lista

tendrá los incidentes producidos a lo largo del mes y en el mes anterior.

La fecha en que se realizo el informe servirá para seleccionar los incidentes mediante una

consulta. Se utilizara la clave externa “Id_empleado” para enlazar las dos tablas.

Mientras que haya incidentes registrados saldrá por pantalla el listado.

Figura 56.

Figura 57.



8.2.7 Buscar_incidente.php

En las interfaces RRHH, Jefe de Centro, Responsable de Área y Servicio de prevención

dispone de un formulario que una vez introducida la fecha saca por pantalla los incidentes

de esa fecha.

La página dinámica encargada de dicha acción es “Buscar_incidentes”. Esta realiza la

misma consulta que vimos en “RRHH”.

Figura 58.

Debido a que esta funcionalidad puede ser llamada desde diferentes páginas una vez

llamada realizada la búsqueda volverá a dirigirse a la interfaz correspondiente. Se utiliza

el mismo método que en la validación. Mediante el switch y siempre arrastrando el

numero, nombre, apellidos y categoría se vuelve a la página que corresponde.



Figura 59.

8.2.8 Cargar_datos_del_incidente.php

Al igual que buscar esta funcionalidad puede ser utilizada por varios actores. Una vez

seleccionado un incidente el sistema cargara mediante una consulta el incidente.

Se muestra a continuación la conexión a la base de datos, en este caso se observa que se

realiza consultando en la base de datos las tres tablas.

Figura 60.



Realizada la consulta se saca la información de la fila y se guarda en la variable $fila, a

partir de aquí se irán sacando todos los datos de la cadena y se introducirán en diferentes

variables, esto dará la posibilidad de sacarlos por pantalla.

Figura 61.



La variable $Baja tendrá 1 o 0, mediante If se cambiara el contenido de la variable por “si”

o por “no”, de esa manera se puede presentar en el informe.

Con las variables registradas y la función echo se sacarn los valores por pantalla.

Figura 62.

Para redirigir a las diferentes pantallas de los diferentes actores la información, se usa la

misma herramienta que en casos anteriores. La diferencia en este caso, es que cada una de

esas pantallas tendrán utilidades diferentes.



Figura 63.

Figura 64.



8.2.9 Enviado.php

Figura 65.

Figura 66.



Mediante la función PHP mail() se conseguirá enviar el informe a los organismos

correspondientes.

Figura 67.



8.2.10 Jefe_de_centro.php

La página dinámica “jefe de centro” sigue el mismo mecanismo que lo explicado hasta el

momento.

Figura 68.



8.2.11 Responsable_de_area.php

A esta página le ocurre lo mismo que a la página anterior por ese motivo no se parara a

explicar ninguna función de este archivo.

Figura 69.



8.2.12 Guardar datos.php

El responsable de Área una vez seleccionado el incidente tiene la posibilidad de introducir

en el formulario un texto de no conformidad y otro de acción preventiva.

La diferencia que se tiene a la hora de realizar la consulta es que en este caso se usa update

en lugar de insert. Con update se actualiza la fila con los datos nuevos no registrados

anteriormente, y con insert se introduce una fila nueva.

Figura 70.



8.2.13 Servicio _de_prevención.php

Como se comentó en el punto 5, el Servicio de Prevención podrá analizar los incidentes en

una franja temporal. Dispondrá de un formulario adicional, con un desplegable que

contiene todos los meses del año, también dispone de una opción representada por un

guión para sacar el análisis anual.

Figura 72.



Figura 73.

Recordar que puede ver incidentes al igual que los demás actores. Como se observa en la

figura 72.

Figura 74.



8.2.14 Cargar_informe.php

Una vez cargado el incidente seleccionado. El servicio de Prevención podía ver la no

conformidad y la acción preventiva.

En la posterior imagen solo es reseñable la orden if, con ella el sistema detectara si

tenemos registrados la no conformidad y la acción preventiva, de este modo se cargara un

informe o nos saldrá por pantalla que no están redactados.

Figura 75.



8.2.15 Cargar_datos.php

Para poder sacar por pantalla por ejemplo el número de bajas ocurridas en un periodo

utilizaremos la función count(), con ella contabilizaremos los datos consultados.

Figura 76.

Figura 77.



Fuera de la consulta, count(*) nos sirve para introducir en las variables las cantidades

antes consultadas.

Figura 78.

Figura 79.



9. CONCLUSIÓN

El Diseño e implentación del Sistema de Información que se ha elaborado ayudara

principalmente a paliar los problemas de comunicación que se producen en la

empresa AGUAS. Destacar que aunque se trate de una empresa de un tamaño

importante no está exenta de este tipo de deficiencias.

En el mercado existen otros tipos de herramientas parecidas, pero ninguna se ajusta

a los sistemas de gestión de calidad de la empresa, son impersonales.

Gracias a este Sistema de Información WEB, se facilita la labor de los trabajadores

implicados y se mejora la eficiencia de sus tareas. Esto conlleva, no solo lo comentado

anteriormente sino un beneficio económico para AGUAS.

Aparte de mejorar el procedimiento de notificación e investigación de accidentes e

incidentes, se ha dado una herramienta que permite reducir el número de accidentes.

Esta herramienta no solo cumple con la política de la empresa, también cumple con

la normativa de seguridad, y sigue el patrón marcado por el Sistema de Gestión

OHSAS que ayuda a proteger tanto a sus empleados como a la empresa.

El proyecto abarca un amplio abanico de campos a la hora de hablar de su

realización, Sistemas de Gestión, Prevención de Riesgos Laborales, Diseño mediante

un lenguaje de modelado de Sistemas de Información e implementación. De esta

manera se puede llegar a comprender la magnitud de la herramienta elaborada.

Por último recalcar la facilidad del manejo. Hoy en día todo el mundo sabe como

navegar y desenvolverse en una página WEB, sin embargo las aplicaciones software

suelen ser más complejas y menos intuitivas.

Por todo ello este proyecto es idóneo para ser aplicado en el día a día de la empresa

AGUAS.



BIBLIOGRAFIA

OHSAS 18001 “Sistemas de gestión de la seguridad y salud en el trabajo”.

LEY 31/1995, de 8 de noviembre, de Prevención de Riesgos Laborales.

José Manuel Tramitan Torres (2007). Introducción a la arquitectura y desarrollo de

sistemas de información basados en la web.

Manual práctico de HTML. Álvaro Martínez Echevarría. Escuela Técnica Superior

de Ingenieros de Telecomunicación. Universidad Politécnica de Madrid, España.

www.etsit.upm.es [consulta: 15/06/2013].

Manual de PHP. www.php.net [consulta: 15/06/2013].

Tutorial SQL. www.1keydata.com/es/sql/ [consulta: 20/06/2013].

http://www.etsit.upm.es/

http://www.php.net/



Anexo I



Anexo II



Anexo III

diseño e implementación del procedimiento de notificación e investigación de...

Documents