UNIVERSIDAD DE TALCA FACULTAD DE INGENIERÍA ESCUELA DE INGENIERÍA CIVIL EN COMPUTACIÓN

UNIVERSIDAD DE TALCA FACULTAD DE INGENIERÍA ESCUELA DE INGENIERÍA CIVIL EN COMPUTACIÓN Diseño, desarrollo e implementación de un Sistema Web para el control de la Investigación de Accidentes e Incidentes dentro de la Planta Cementos Bío Bío Centro CRISTIÁN GABRIEL APARICIO GUERRA Profesor Guía: PABLO ROJAS VALDÉS Memoria para optar al título de Ingeniero Civil en Computación Curicó Chile Agosto, 2010

UNIVERSIDAD DE TALCA FACULTAD DE INGENIERÍA ESCUELA DE INGENIERÍA CIVIL EN COMPUTACIÓN Diseño, desarrollo e implementación de un Sistema Web para el control de la Investigación de Accidentes e Incidentes dentro de la Planta Cementos Bío Bío Centro CRISTIÁN GABRIEL APARICIO GUERRA Profesor Guía: PABLO ROJAS VALDÉS Profesor Informante: FEDERICO MEZA Profesor Informante: RODOLFO ALLENDES Memoria para optar al título de Ingeniero Civil en Computación Curicó Chile Agosto, 2010

Dedicado a mi tío Ricardo Muñoz, fuente de inspiración, a mi padre por su confianza en mí,a mi querida madre que sufrió nuestra lejanía y a la distancia estuvo siempre a mi lado, a Ivon mujer amiga y compañera de mis noches de esfuerzo, a mis hijos Nicolás, Aylin y Cristián mi motivación permanente y fuente de energía para continuar, a mi abuela que me dio el coraje y la sabiduría desde mi infancia, a Dios y a mi amigo, hermano Jesús. i

AGRADECIMIENTOS Agradezco a muchas personas que estuvieron a mi lado dándome animo y apoyo para continuar, mi familia Ivon, Nicolás, Aylin y Cristian quienes sufrieron y lucharon para dar todo su apoyo a esta causa, a mi padre que siempre supieron que lo lograría y confiaron en mí, a mi madre que siempre me apoyo y me dio su amor incondicional, a mis hermanos Claudia, Rodrigo y Karolina por su cariño y apoyo, a mi tío Ricardo muñoz quien como un padre me dio su apoyo, confianza y un ejemplo a seguir. A mi amigo Rodrigo Fuentes quien me dio su apoyo en momentos muy duros de mi vida y me impulso a continuar. A mi jefe Enrique Bass quien me dio su apoyo consejos y amistad, a mi amigo y hermano fallecido Patricio Morales. A mi querida universidad que fue mi hogar durante tantos años y me dio el conocimiento suficiente para cumplir mis objetivos, a mis profesores Narciso Cerpa, Renzo Angles, Federico Meza, Matthew Bardene, Ruth Garrido, José Luis Giordano, Igor Ruiz Tagle y a mi profesor guía de memoria Pablo Rojas, quienes me dieron la oportunidad para aprender de sus conocimientos. Y por último y más importante a Dios, a su hijo y mi hermano Jesucristo que ha estado presente cada día de mi vida levantándome cada vez que tropecé, apoyándome con un milagro cada día y por sobre todo el regalo más grande que me dio, mi familia. Gracias a todos. ii

TABLA DE CONTENIDOS página Dedicatoria Agradecimientos Tabla de Contenidos Índice de Figuras Índice de Tablas Resumen Abstract I II III VI VIII IX X 1. Introducción 1 1.1. Descripción del Problema........................ 1 1.2. Objetivos................................. 2 1.2.1. Objetivo general......................... 2 1.2.2. Objetivos específicos....................... 2 1.3. Alcances del proyecto........................... 3 2. Marco Teórico 5 2.1. Ley N o 20.123 del código del trabajo.................. 5 2.2. Ley N o 16.744 de Prevención de Riesgos................ 6 2.2.1. Decreto supremo 76........................ 7 2.3. Normas Internacionales.......................... 8 2.3.1. Normas OHSAS 18000...................... 8 2.4. Feature Driven Development (FDD)................... 11 2.5. Arquitectura MVC (modelo-vista-controlador)............. 15 2.5.1. Descripción del patrón...................... 16 2.5.2. Servicios Web........................... 17 2.6. Rich Internet Applications (RIA)..................... 19 2.7. Aplicaciones Flex.............................. 22 iii

iv 2.7.1. ActionScript (AS3)......................... 23 2.8. Data Access Object (DAO)........................ 24 2.9. WebORB................................. 25 2.10. Estandarización.............................. 26 3. Aplicación de la Metodología 27 3.1. Metodología FDD adaptada....................... 27 3.1.1. Roles y responsabilidades..................... 27 3.2. Desarrollo de un modelo global..................... 28 3.3. Elaboración de una lista de características............... 29 3.4. Planificación por características..................... 30 3.5. Iteraciones................................. 31 4. Requisitos y diseño 35 4.1. Arquitectura Modelo-Vista-Controlador (MVC)............ 35 4.2. Servicios web............................... 38 4.3. Usuarios y requisitos funcionales..................... 42 4.4. Requisitos no funcionales......................... 46 4.5. Diagrama de clases............................ 46 4.6. Modelo de datos.............................. 49 4.7. Estándar de interfaz........................... 52 4.8. Estándar de código............................ 53 4.8.1. Nombres.............................. 53 4.8.2. Esquema.............................. 54 5. Desarrollo e implementación 56 5.1. Tecnología utilizada............................ 56 5.1.1. Hardware............................. 56 5.1.2. Software.............................. 57 5.1.3. Restricciones de Memoria física (RAM)............. 58 5.2. Lenguajes de programación....................... 58 5.3. Entornos de programación........................ 59 5.4. Comunicación entre los lenguajes.................... 60 5.5. Comunicación entre los servicios web.................. 62 5.6. Interfaces de usuario........................... 66

v 6. Conclusiones 77 6.1. Problemas en el desarrollo........................ 77 6.1.1. De la metodología......................... 77 6.1.2. Del producto........................... 78 6.2. Trabajos Futuros............................. 79 7. Anexos 81 Glosario 82 Bibliografía 84

ÍNDICE DE FIGURAS página 1.1. Diagrama de flujo del sistema....................... 4 2.1. Número acumulado de empresas certificadas con las normas OHSAS por año; Fuente: OHSAS Proyect Group................. 11 2.2. Cinco etapas metodología ágil FDD................... 12 2.3. Mini ciclo de Construcción, FDD..................... 13 2.4. Modelo Vista Controlador......................... 16 2.5. Servicios Web en funcionamiento..................... 17 2.6. Ejemplo interacción de servicios web con protocolos y estándares... 19 2.7. Características aplicaciones RIAs..................... 20 2.8. Interacción de tecnologías con RIAs................... 21 2.9. Elementos DAO.............................. 25 3.1. Sistema global............................... 29 4.1. Vista del modelo MVC........................... 36 4.2. Controlador del modelo MVC....................... 36 4.3. Arquitectura MVC............................. 38 4.4. Service en C Sharp............................. 39 4.5. Service de Flex............................... 39 4.6. Service agrupados............................. 41 4.7. Relación entidad Servicios......................... 42 4.8. Privilegios asociados a los Usuarios.................... 45 4.9. Diagrama de clases del sistema...................... 47 4.10. Modelo de datos del sistema........................ 51 4.11. Metáforas seleccionadas para el sistema................. 52 4.12. Diseño estilo papel Filtros del sistema.................. 53 5.1. Comunicación entre lenguajes....................... 60 5.2. Comunicación Flex, C Sharp y SQL................... 62 5.3. Login, interfaz inicial del sistema..................... 66 5.4. Interfaz Informe de accidente....................... 67 vi

vii 5.5. Interfaz datos empresa........................... 67 5.6. Interfaz datos trabajador......................... 68 5.7. Interfaz datos del accidente........................ 69 5.8. Interfaz descripción del accidente..................... 70 5.9. Interfaz análisis causal........................... 71 5.10. Interfaz crear causa inmediata....................... 72 5.11. Interfaz correcciones............................ 73 5.12. Interfaz modificar correctiva........................ 74 5.13. Interfaz exportar a pdf........................... 74 5.14. Interfaz finalizar.............................. 75 5.15. interfaz mantenedor de usuarios...................... 76 5.16. Interfaz crear usuario........................... 76 6.1. Mejoras futuras al sistema......................... 80

ÍNDICE DE TABLAS página 3.1. Lista de características........................... 30 3.2. Lista de características organizadas.................... 31 4.1. Lista de Service............................... 40 viii

RESUMEN La presente memoria muestra el diseño, desarrollo e implementación de un sistema web para el control de la Investigación de Accidentes e Incidentes dentro de la Planta Cementos Bío Bío Centro. El desarrollo se basa en la metodología Feature- Driven Development con ciertas modificaciones para adaptarse a las necesidades del proyecto. Para la creación del sistema se analizan aspectos básicos enmarcados en las leyes de la república 20.123 y 16.744 con su decreto supremo 76 que obligan a tener ciertos parámetros para el control de accidentes y la documentación junto a su contenido. Además se aplican normas internacionales (OHSAS 18.000) que establecen estándares que las empresas acogidas a estas normas deben cumplir. El sistema permite el control, creación, monitoreo y fácil acceso a las causas y correcciones que fomentan el suceso de Accidentes, y todos los datos necesarios que identifican el o los individuos relacionados a un accidente, permitiendo que la creación del informe pueda llevarse a cabo por distintos usuarios donde cada cual tiene acceso a ciertas funcionalidades del sistema a través de un mantenedor de usuarios con privilegios. Todo lo anterior acompañado por tecnologías de desarrollo de punta como son Flex, C Sharp y SQL server, que mediante la arquitectura Modelo- Vista-Controlador y aplicaciones dinámicas de alta usabilidad (aplicaciones RIAs) dan una interacción de fácil comprensión para los usuarios. Finalmente se hace un análisis de los resultados obtenidos junto al planteamiento de futuros trabajos sobre el sistema. ix

ABSTRACT This report shows the design, development and implementation of a web system for the control of the Investigation of Accidents and Incidents in Cementos Bio Bio Plant Centre. The development methodology is based on Feature-Driven Development with modifications to suit the needs of the project. For the establishment of basic aspects are discussed framed in the laws of the republic with its 20.123 and 16 744 Decree requiring 76 have certain parameters for the control of accidents and documentation along with its contents. Also apply International Standards (OHSAS 18,000), which establishes standards that companies benefit from these standards must be met. The building control system allows monitoring and easy access to the causes and corrections that foster the success of Crash and all the data needed to identify the individuals or related to an accident, allowing the creation of the report can be implemented by different users where everyone has access to certain features of the system through a maintainer privileged users. All this accompanied by cutting edge development technologies such as textitflex, C Sharp, SQL server, which by textitarchitecture Model-View-Controller and high usability dynamic applications (RIAs applications) provide interaction easily understood by users. Finally, an analysis of the results obtained from the approach to future work on the system. x

1. Introducción 1.1. Descripción del Problema El problema fue detectado en la planta Cementos Bío Bío Centro, localizada en las afueras de la ciudad de Curicó más específicamente en la comuna de Teno. Esta planta tiene un sistema de control de accidentes totalmente rudimentario que consiste en papel, lápiz y algunas planillas con formatos específicos. Para cumplir las nuevas normativas legales y estándares internacionales se requiere un sistema de control de informes de accidentes[10]. El problema concretamente es la forma en que se trabajan en la actualidad los informes de accidentes, totalmente contraria a los estándares internacionales de las empresas multinacionales. En la empresa actualmente el sistema de información que existe cuando ocurre un accidente o incidente es muy lento y nada automatizado, ya que se realiza a través de correos electrónicos donde se informa de los acontecimientos, y una persona encargada crea un informe de accidente sin ningún tipo de formato establecido y/o estandarizado. La persona que crea el informe de accidente recibe de parte de todos los involucrados en él un correo, teniendo que cortar y pegar cada texto, esto provoca un desorden grave, de acuerdo a la importancia que tiene un accidente y el seguimiento de las correcciones de estos[8][10], existiendo perdida de información, lo que dificulta desarrollar los informes con la calidad que lo exige la empresa y las leyes emanadas del Congreso Nacional que exigen un riguroso análisis de accidentes dentro de una empresa y la responsabilidad sobre el trabajador que esta subcontratado[11] e involucrado en un accidente[10]. Las leyes involucradas son relativamente nuevas (2007 aprox.), esto dificulta encontrar sistemas computacionales que se adapten a las necesidad de la empresa como 1

CAPÍTULO 1. INTRODUCCIÓN 2 la creación, seguimiento, accesibilidad rápida y por múltiples usuarios simultáneamente, análisis de causas que provocan accidentes, la creación de correcciones y seguimientos a éstas, se ha vuelto un tema primordial y de suma urgencia para la empresa, ya que los accidentes que ocurran en la planta deben contar con todas esas características para ser controlados, ya que de lo contrario podrían ocurrir problemas graves legales, que incluso contemplan penas de cárcel para gerentes e involucrados y paralización total de las faenas en la empresas, lo que en este caso es una cuantiosa suma de dinero[8][10]. Accediendo rápidamente a la información a través de una plataforma Web podría llevarse un seguimiento de los problemas y se podría establecer medidas correctivas que permitan controlar todos los riesgos que existan en la planta y dar cumplimiento a las leyes y normas planteadas en este documento. 1.2. Objetivos 1.2.1. Objetivo general Diseñar e implementar un sistema de gestión de accidentes, para la planta de Cementos Bío Bío Centro S.A, a través de una plataforma web que permita informar, registrar, investigar y evaluar los accidentes y/o enfermedades profesionales que acontezcan dentro de la planta Cementos Bío Bío Centro S.A., con el propósito de evitar una posterior ocurrencia; identificando las causas de los eventos que intervinieron en la situación y estableciendo las adecuadas medidas correctivas y/o preventivas. 1.2.2. Objetivos específicos Dar cumplimiento a la ley 16.744, que establece normas sobre accidentes del trabajo y enfermedades profesionales [8][10]. Cumplir con la norma OHSAS en especifico la 18001, que trata sobre el establecimiento de un sistema de gestión, seguridad y Salud ocupacional.[7] Mantener actualizada la información sobre los accidentes que ocurran dentro de la planta Cementos Bío Bío.

CAPÍTULO 1. INTRODUCCIÓN 3 Registrar y categorizar la mayor cantidad posible de causas que provocan un accidente con un análisis causal, agrupando en causas básicas, causas inmediatas y/o fallo en el sistema de gestión. Generar medidas correctivas, emanadas del análisis causal, que permitan mitigar los accidentes y eliminar la mayor cantidad de causas posibles. Llevar una información actualizada y hacer un seguimiento de los informes de accidentes que se hayan creado, teniendo un fácil y rápido acceso a ellos. Lograr establecer la relación entre los trabajadores y empresas que desempeñan tareas en la planta Cementos Bío Bío con los accidentes que involucre a estos. [11] 1.3. Alcances del proyecto El proyecto está basado en sistema de gestión propuesto por la norma OHSAS 18001 y por los requerimientos de la ley de la república 16.744. De acuerdo a esto se desarrolla el sistema web que contempla la creación de un informe de accidente de fácil y rápido acceso, considerando la información necesaria para su creación, los datos del trabajador accidentado y a la empresa al cual éste pertenece, siendo esta información cargada automáticamente desde la base de datos de la empresa Cementos Bío Bío. Además, el sistema permitirá hacer un análisis causal de los hechos que llevaron a la ocurrencia del accidente, junto con la posibilidad, dentro de este sistema de gestión, de establecer medidas correctivas para cada causa[7] [8][10]. Además, el sistema contempla la visualización, de parte de otros usuarios, del informe de accidentes, con el fin de lograr tener muchos evaluadores de la información presente en el sistema. El sistema no contempla análisis estadístico ni gestión de planificación por razones de tiempo. Para la empresa es de suma importancia tener un sistema con estas características para acceder rápidamente y en cualquier momento a la información que contiene el sistema y lograr una investigación precisa del accidente con el fin de evitar accidentes y/o incidentes que puedan incluso llevar a la pérdida de vidas humanas. Podemos ver el alcance del sistema en la figura 1.1.

CAPÍTULO 1. INTRODUCCIÓN 4 Figura 1.1: Diagrama de flujo del sistema.

2. Marco Teórico En este capítulo se verán los pilares fundamentales para el entendimiento en el desarrollo de los objetivos de esta memoria. Estos pilares son las bases teóricas e históricas del los temas que sostienen el desarrollo de esta memoria. Pilares como las leyes laborales de nuestro país y normas internacionales de seguridad industrial describiendo las leyes y las normas y acuerdos internacionales que en la actualidad pretenden regular el control de accidentes en las empresas. Las leyes laborales son fundamentales para crear algún sistema que regulen y controlen los accidentes en las plantas o en alguna faena, estas tienen que ser consideradas al momento de buscar alguna solución para controlar los accidentes de una empresa, por ello es necesario considerar cada uno de los artículos que puedan sugerir u obligar un control especifico de los accidentes. 2.1. Ley N o 20.123 del código del trabajo Regula el trabajo en régimen de subcontratación, el funcionamiento de las empresas de servicios transitorios y el contrato de trabajo de servicios transitorios. Esta ley es muy reciente dentro de nuestra legislación chilena, fue creada con el fin de regular todos los aspectos de la subcontratación, el que es realizado en virtud de un contrato de trabajo por un trabajador para un empleador denominado contratista o subcontratista. Esta ley estableció la manera de regular las actividades industriales y los contratos que celebran las empresas mandantes(principal) con las empresa que prestan servicios (empresas subcontratistas), quizás lo más importante es el vínculo y responsabilidad que tiene la empresa mandante con un trabajador contratado por una 5

CAPÍTULO 2. MARCO TEÓRICO 6 empresa subcontratista, esto implica por lo general el aseguramiento de los derechos de los trabajadores de la empresa subcontratista, tengan los mismos derechos que los trabajadores de la empresa principal y trabajen bajos las mismas circunstancias, asegurando, por parte de la empresa principal, las normas legales que implica el contrato de cualquier trabajador[11], esto quiere decir que si la empresa subcontratada no cumpliese con alguna norma legal del código del trabajo, la empresa principal tendrá que hacerse cargo del cumplimiento del código del trabajo. Es importante destacar que no corresponde solo a la supervisión del cumplimiento de las normas por parte de la empresa subcontratistas, sino que también debe hacerse cargo de los pagos y normas de seguridad que rigen las leyes respectivas si estas no son cumplidas por parte de las empresas subcontratistas, se espera y es el espíritu de esta ley la solidaridad y protección de la empresa principal para con los trabajadores de las empresas subcontratadas, todo esto tiene una base legal muy importante que permite que al trabajador demandar a su empresa, y si se requiere por parte del trabajador extender la demanda a la empresa principal, si existiera alguna irregularidad en el cumplimiento de las normas legales para con ese trabajador, las multas y la forma de cancelar estas serán determinadas por el ministerio del trabajo. También es indispensable cumplir con la documentación necesaria para que la empresa subcontratista pueda realizar sus actividades o faenas dentro o para la empresa principal, estos documentos también son regulados por la ley 20.123 [11]. 2.2. Ley N o 16.744 de Prevención de Riesgos Establece Normas sobre accidentes del trabajo y enfermedades profesionales. Para resumir, esta ley está relacionada con la ley 20.123 ya que la regulación de las normas sobre accidentes del trabajo y enfermedades profesionales tendrán que ser también supervisadas por parte de la empresa principal para con los trabajadores de las empresas contratistas, esto con el fin que existan todas las obligaciones aseguradas para evitar accidentes del trabajo, dentro de esta ley nos enfocaremos un poco más en el Decreto Supremo 76 creado el año 2006, este decreto es el que regula en la actualidad todas las actividades de las empresas concerniente a prevención de riesgos [8] [10].

CAPÍTULO 2. MARCO TEÓRICO 7 2.2.1. Decreto supremo 76 Normas en materia de seguridad y salud en el trabajo para obras, faenas o servicios en que presten servicios trabajadores sujetos a régimen de subcontratación. El decreto supremo 76 logra establecer una relación directa entre la ley de subcontratación 20.123 y la ley 16.744, con el fin de regularizar y establecer las características de las actividades que se realizan por los trabajadores de empresas subcontratadas en la empresa principal, así se deben cumplir una serie de normas de higiene y seguridad dispuestas por la ley y en específico por el decreto supremo 76, estas normas deben cumplirse con el fin de evitar accidentes laborales y llevar un control si ocurriesen. Este control debe ser riguroso, se establecen los parámetros para evaluar las razones del por qué ocurre un accidente y los parámetros para evitar que estos ocurran. Es necesario que las empresas se hagan responsables del cumplimiento de esta ley ya que existen castigos muy duros para las empresas que no lo cumplen, y algo aun más importante las responsabilidades son compartidas entre la empresa subcontratista que contrata al trabajador directamente y la empresa principal que contrata la empresa subcontratista así como en el artículo 3 o dice: Las disposiciones de este reglamento, en caso alguno, eximirán a la empresa principal, así como tampoco a las empresas contratistas y subcontratistas, de sus obligaciones individuales respecto de la protección de la seguridad y salud de sus trabajadores, para lo cual deberán cumplir con las normas legales vigentes en dichas materias [10]. Por último el decreto supremo exige cierto tipo de documentación que debe entregarse por parte de la empresa subcontratista a la empresa principal de sus trabajadores, así como la obligación de que exista un experto en prevención de riesgo de parte de la empresa contratista y la empresa subcontratista, ambos por separado teniendo la responsabilidad de supervisar el cumplimiento de las normas vigentes por parte de la empresa principal y su experto en prevención de riesgos, en resumen las empresas contratistas/subcontratista y la empresa principal deben coordinar todas las actividades que se realicen y el cumplimiento de las normas legales a beneficio de los trabajadores.

CAPÍTULO 2. MARCO TEÓRICO 8 2.3. Normas Internacionales Las normas internacionales permiten la estandarización del trabajo en las empresas asegurando también la calidad de los productos y el cumplimiento de las normas legales de cada país. Dentro de las normas especificaré la más importante para nuestro marco teórico, esta norma es OHSAS 18000 [7]. Es de suma importancia el cumplimiento de esta norma, ya que permite asegurar la calidad de las empresas a nivel mundial. 2.3.1. Normas OHSAS 18000 La salud y seguridad son uno de los pilares para el desarrollo de una organización, por lo que éstas vienen integrando el tema cada vez con mayor exigencia en cada uno de sus procesos. Esto ha sido plasmado en las normas OHSAS 18000, Occupational Health and Safety Assessment Specification (Especificación de Evaluación de la Seguridad y Salud en el trabajo)por lo que describiremos sus principales características además de otros datos de interés. Antecedentes Las normas OHSAS nacieron en el año 1999 respondiendo a la necesidad de contar con un documento de reconocido prestigio que permitiese a las organizaciones diseñar, evaluar y certificar sus sistemas de gestión de seguridad y salud en el trabajo. Es así que se da inicio a la construcción de una serie de normas internacionales con la finalidad de establecer estándares en este rubro, a las que conocemos como OHSAS 18000 [7]. Los sistemas de salud y seguridad ocupacional Para entender las normas OHSAS, debemos conocer a qué se refieren los sistemas de salud y seguridad ocupacional (OHS por sus siglas en inglés). Los OHS son diseñados con la finalidad de prevenir, controlar y minimizar los riesgos en el lugar de trabajo. Las diferentes organizaciones, dependiendo de la actividad que realicen, identifican los posibles riesgos inherentes a su operación y formulan objetivos y políticas específicas para enfrentarlos[7].

CAPÍTULO 2. MARCO TEÓRICO 9 Si bien cada organización puede implementar su propio plan de OHS, las normas OHSAS OHSAS buscan establecer un marco referencial para el desarrollo y puesta en marcha de dicho plan, de modo que manejen el riesgo en sus operaciones y mejoren su desempeño. Normas OSHAS 18000 y su utilidad Las OHSAS 18000 son una serie de normas internacionales que buscan establecer estándares de salud y seguridad en el lugar de trabajo. Su objetivo fundamental es proveer a las organizaciones de una herramienta que les permita optimizar sus sistemas de salud y seguridad ocupacional con la finalidad de cumplir, actualmente y en un futuro, con los requerimientos que se realizan respecto a la normativa de los países y alcanzar sus objetivos particulares (sean estos económicos, productivos u otros). Las OSHAS son de implementación voluntaria para las diferentes organizaciones: Estado, empresas, ONGs, instituciones educativas, etc. No obstante, se pueden emitir certificaciones a aquellas instituciones que hayan decidido implementarlas[7]. Bajo el nombre de normas OHSAS se agrupan tres documentos: OHSAS 18001: son la base o definición teórica acerca de la salud y seguridad ocupacional. En ella se establecen las líneas generales que debe contener un sistema de OHS. OHSAS 18002: en una guía de ejecución de las OHSAS 18001. Busca fijar una serie de referencias típicas y ejemplos explicativos respecto de su implementación. OHSAS 18003: es un documento cuyo objetivo es facilitar el desarrollo de esquemas de acreditación de auditores y certificadores. Lineamientos de las OHSAS Al ser un documento referencial, engloba un conjunto de áreas básicas que deben ser cubiertas cuando se diseña un sistema de salud y seguridad en el trabajo. Entre ellas podemos encontrar: Identificación de amenazas y posibles riesgos, así como el establecimiento de controles.

CAPÍTULO 2. MARCO TEÓRICO 10 Identificación de los requisitos establecidos en la legislación nacional. Establecimiento de un programa de OHS (incluyendo sus respectivos objetivos) Identificación de los recursos disponibles, personas a cargo y sus responsabilidades. Asegurar la competencia, formación y concientización de todas aquellas personas que realicen una labor que involucre algún riesgo ocupacional a través del desarrollo de capacitaciones. Establecer un proceso de comunicación, participación y consulta, que permita involucrar a los diferentes actores (trabajadores, contratistas, etc.) en la identificación de posibles riesgos y la mejora de los procesos. Implementación de control operacional en aquellas áreas en las que se han identificado posibles riesgos. Planificación y respuesta ante emergencias. Medición y seguimiento continuo de los indicadores de salud y seguridad ocupacional, así como la implementación de medidas correctivas. Certificaciones OHSAS Las repercusiones positivas para la empresa al obtener la certificación de la norma OHSAS 18000 se reflejan en una óptima gestión en beneficio de su personal, lo cual les permite mostrar una mejor imagen interna y externa, además de incidir positivamente en la productividad de los trabajadores de la empresa al contar con un ambiente seguro de trabajo. Entre otros puntos a considerar, debe mencionarse que, debido a que sus riesgos están identificados y controlados por procedimientos claros, las empresas tienen mayores herramientas de negociación frente a las compañías de seguros. Además, las empresas pueden competir de igual a igual en los mercados mundiales, ahora que por efecto de la globalización los estándares de calidad son mayores. Cabe señalar que las normas OHSAS son dinámicas en el tiempo, es decir, su contenido es continuamente revisado con la finalidad de realizar mejoras a la misma. Así, por ejemplo, la primera norma OHSAS 18001 se publicó en el año 1999 y su contenido ha sido actualizado en

CAPÍTULO 2. MARCO TEÓRICO 11 el año 2007 (OHSAS 18001:2007) con la finalidad de incluir nuevos conceptos y actualizar aquellos que fuesen necesarios[7]. La incorporación de empresas industriales a la certificación OHSAS ha crecido cada año como muestra la figura 2.1. Figura 2.1: Número acumulado de empresas certificadas con las normas OHSAS por año; Fuente: OHSAS Proyect Group. [7] 2.4. Feature Driven Development (FDD) FDD es una metodología ágil para el desarrollo de sistemas[1], que fue diseñado, por Peter Coad, Eric Lefebvre y Jeff DeLuca. Este proceso no hace énfasis en la obtención de los requerimientos, sino en cómo se realizan las fases de diseño y construcción, donde su base es la creación de un listado de funcionalidades, listado que será el eje de todo el proceso. FDD incluye un monitoreo constante preocupándose de la calidad del proyecto, este monitoreo se realiza en conjunto con los clientes que son parte activa del desarrollo, esto ayuda a contrarrestar situaciones como el exceso o falta de presupuesto e incluso se detectan de forma más rápida los problemas que se presenten en el desarrollo del proyecto, lo que a su vez permite una rápida mejora, por lo mismo se requiere una comunicación fluida con los miembros del proyecto

CAPÍTULO 2. MARCO TEÓRICO 12 (incluido los clientes)[1]. Así esta metodología propone tener etapas de cierres cada dos semanas obteniendo resultados periódicos y tangibles lo que motiva mucho más la participación del cliente y la evaluación del desarrollo a cada momento. Sin embargo la documentación en este tipo de desarrollo es muy poco requerida, con el fin de utilizar el tiempo en dar resultados más prácticos. El Proceso requiere iteraciones cortas que produzcan un software funcional donde la empresa y los clientes puedan ver y monitorear, para esto es necesario definir estas formas de monitoreo y/o evaluaciones periódicas que cumplan el objetivo principal de esta metodología: dar resultados tangibles periódicamente[1]. El proceso iterativo, que dura aproximadamente dos semanas, consiste en cinco pasos principales (ver figura 2.2) de los cuales los dos últimos forman una especie de subciclo que se encarga de la construcción y diseño (figura 2.3). Figura 2.2: Cinco etapas metodología ágil FDD. Así los cinco pasos principales del ciclo de desarrollo con la metodología ágil FDD en detalle son: Desarrollo del modelo general: en esta etapa se tiene un conocimiento general acerca de lo que se quiere construir, además ya podría establecer de manera fidedigna el contexto del problema y el alcance de éste, con toda esta información general se establece y construye un modelo global del sistema que permite visualizar de mejor manera toda esta información General dando la base al sistema (el esqueleto).

CAPÍTULO 2. MARCO TEÓRICO 13 Figura 2.3: Mini ciclo de Construcción, FDD. Construcción de una lista de funcionalidades: al tener y analizar la información con modelos, como por ejemplo de objetos y/o requerimientos, se comienza a desarrollar esta lista de funcionalidades que son pequeños ítems útiles al ojo del cliente. Esta lista debe ser dividida y reagrupada por afinidad y en constante revisión del cliente. Planeación por funcionalidad: en esta etapa del ciclo se crea un plan de alto nivel agrupando las funcionalidades por prioridad, establecidas en conjunto con el cliente y de acuerdo a esto, los integrantes del desarrollo adquieren sus respectivas responsabilidades Diseño por funcionalidad: en esta etapa del proceso comienza un nuevo sub ciclo (ver figura 4) donde se elige un conjunto de funcionalidades que ingresarán por prioridad a este ciclo iterativo y se comienza a diseñar de acuerdo a estas funcionalidades. Construcción por funcionalidad: en esta última etapa del ciclo se comienza

CAPÍTULO 2. MARCO TEÓRICO 14 a codificar lo que obtuvimos en los procesos anteriores de diseño, además se contempla las pruebas de cada una de las funcionalidades ya codificadas y finalmente el ensamblado al código general, de esta manera comienza a crecer el código integrando una a una cada funcionalidad. Según lo anterior hemos mencionado una serie de responsabilidades las cuales nos orientan la creación de roles que establece esta metodología, estos roles son: Director del proyecto: es el que decide finalmente en materia de visión planificación del cronograma y en la asignación del personal. También entrega apoyo y motivación al equipo. Arquitecto jefe: es el encargado del diseño y tiene la última palabra en lo que tenga relación a ésto, ya que es el responsable del modelo global del sistema y de la ejecución de todas las etapas del diseño Director de desarrollo: este rol es el encargado de resolver los conflictos que puedan existir en el quipo de desarrollo en conjunto con el arquitecto jefe, este debe ser un programador con experiencia ya que debe llevar las actividades diarias de desarrollo. Programador jefe: es quien selecciona las funcionalidades del sistema que serán codificadas siendo un actor principal en lo que a diseño construcción se refiere, es el encargado de manejar pequeños grupos de programadores. Propietario de clases: trabaja bajo la guía del programador jefe, le da la prioridad a las clases de acurdo con las funcionalidades deseadas que serán construidas en el proceso iterativo Expertos de dominio: son quienes conocen lo que se debe desarrollar y cuál debiera ser el producto final, estos pueden ser usuarios o clientes, estos deben tener un amplio conocimiento de los requerimientos del sistema, estos expertos deben traspasar el conocimiento a los desarrolladores asegurando la calidad de la entrega de estos. Además de estos roles existen otros que son enfocados en dar soporte, estos son:

CAPÍTULO 2. MARCO TEÓRICO 15 Administración del dominio: éste lidera al grupo de expertos de dominio siendo un conector en las relaciones y comunicación de estos con los desarrolladores y entre ellos mismos, así tiene la función de resolver cualquier diferencia de opinión que pueda existir entre los expertos de dominio. Administración de versiones: este es el encargado de hacer las revisiones del sistema de acuerdo al avance, y al análisis de éste, así sabrá si está de acuerdo a lo programado, con este análisis realiza reportes semanales. Ingeniero de construcción: se encarga de la publicación de la documentación concerniente al desarrollo. Administrador del sistema: Es el encargado de mantener operativos los servidores y redes que dan el soporte para las estaciones de trabajo y equipos de desarrollo y el sistema de testeo utilizado por los equipos. Por último existe unos roles adicionales que apoyan a los demás, estos son: Tester: Es el encargado de revisar la calidad del sistema realizando pruebas con el fin de dar cumplimiento a la funcionalidad específica que desea el cliente. Escritores de documentos: se encarga de preparar la documentación para los usuarios quienes pueden o no pertenecer al equipo de desarrollo. 2.5. Arquitectura MVC (modelo-vista-controlador) Este modelo representa una arquitectura de software que separa los datos de una aplicación, la interfaz de usuario y la lógica, esta manera de establecer una arquitectura se utiliza frecuentemente en aplicaciones web con diseños sofisticados de interfaces estipulando una división del código que da una estructura muy útil. La lógica de interfaz cambia con más frecuencia que la lógica de negocio y que el almacenamiento de datos, lo que nos sugiere elegir una arquitectura óptima que permita una independencia entre las tres capas, estos nos permite optimizar nuestra aplicación ya que al necesitar realizar cambios en la interfaz no tendremos la necesidad de hacer una cadena de cambios que afecte a las demás capas de negocio y de datos (ver figura 2.4).

CAPÍTULO 2. MARCO TEÓRICO 16 Figura 2.4: Modelo Vista Controlador. 2.5.1. Descripción del patrón El Modelo: representa la gestión de datos que responden a un modelo especifico y reglas de negocio, así este componente accede a la capa de almacenamiento de datos. Se debe tratar que el modelo sea independiente al sistema de almacenamiento Vista : es encargada de recibir los datos del modelo y los muestra al usuario Controlador: Recibe los eventos de entrada y contiene las reglas de gestión de eventos comunicándose con la vista y el modelo. Podemos graficar un ejemplo con los siguientes pasos: 1. El usuario introduce el evento desde la vista 2. El Controlador recibe el evento y lo traduce en una petición al Modelo (aunque también puede llamar directamente a la vista). 3. El modelo (si es necesario) llama a la vista para su actualización. 4. Para cumplir con la actualización la Vista puede solicitar datos al Modelo. 5. El Controlador recibe el control.

CAPÍTULO 2. MARCO TEÓRICO 17 2.5.2. Servicios Web Los servicios web podrían definirse de muchas maneras por la enorme complejidad que tienen, pero quizás la más adecuada es: aplicaciones que intercambian datos entre sí con el objetivo de ofrecer algunos servicios. Los proveedores ofrecen sus servicios como procedimientos remotos y los usuarios solicitan un servicio llamando a estos procedimientos a través de la Web como muestra la figura 2.5, estableciendo algunos estándares con el fin de facilitar la comunicación entre diferentes aplicaciones sin importar los lenguaje utilizados en éstas, proporcionando operatividad que permita combinar las diferentes operaciones para que trabajen en conjunto, de esta manera se puede mostrar de forma dinámica la información al usuario. Figura 2.5: Servicios Web en funcionamiento. La comunicación y el funcionamiento de los servicios web están regidos por una

CAPÍTULO 2. MARCO TEÓRICO 18 serie de protocolos y estándares que se describen a continuación: Web Services Protocol Stack: Así se denomina al conjunto de servicios y protocolos de los servicios Web. XML (Extensible Markup Language): Es el formato estándar para los datos que se vayan a intercambiar. SOAP (Simple Object Access Protocol) o XML-RPC (XML Remote Procedure Call): Protocolos sobre los que se establece el intercambio. Otros protocolos: los datos en XML también pueden enviarse de una aplicación a otra mediante protocolos normales como HTTP (Hypertext Transfer Protocol), FTP (File Transfer Protocol), o SMTP (Simple Mail Transfer Protocol). WSDL (Web Services Description Language): Es el lenguaje de la interfaz pública para los servicios Web. Es una descripción basada en XML de los requisitos funcionales necesarios para establecer una comunicación con los servicios Web. UDDI (Universal Description, Discovery and Integration): Protocolo para publicar la información de los servicios Web. Permite comprobar qué servicios web están disponibles. WS-Security (Web Service Security): Protocolo de seguridad aceptado como estándar por OASIS (Organization for the Advancement of Structured Information Standards). Garantiza la autenticación de los actores y la confidencialidad de los mensajes enviados (ver figura 2.6). Es claro distinguir tres razones fundamentales de por qué utilizar estos servicios web descritos anteriormente, quizás la más importante sea que estos se basan en HTTP sobre TCP, utilizando el puerto 80 lo que nos da mucha libertad tomando en cuenta que las empresas e instituciones protegen sus redes con cortafuegos (Firewall), que impiden la utilización de algunos puertos TCP menos el 80 ya que éste es el que utilizan los servidores web. Otra razón es que en la actualidad existen interfaces mucho más dinámicas y que mejoran cada día con el fin de dar mayor usabilidad a los sistemas así podemos interactuar con distintos entornos visuales sin importar

CAPÍTULO 2. MARCO TEÓRICO 19 Figura 2.6: Ejemplo interacción de servicios web con protocolos y estándares. en que plataforma tengamos nuestro entorno lógico, todo esto gracias a los servicios web. Finalmente los servicios Web pueden aportar gran independencia entre la aplicación que usa el servicio Web, y el propio servicio. De esta forma, los cambios a lo largo del tiempo en uno no deben afectar al otro. Esta flexibilidad será cada vez más importante, dado que la tendencia a construir grandes aplicaciones a partir de componentes distribuidos más pequeños es cada día más utilizada, como por ejemplo en la arquitectura orientada a servicios que brinda una forma bien definida de exposición e invocación de servicios (comúnmente pero no exclusivamente servicios web)[9]. 2.6. Rich Internet Applications (RIA). Las aplicaciones RIAs son entornos dinámicos WEB (figura 2.7) donde el cliente puede tener interacciones mucho más llamativas y útiles que las tradicionales, es decir permiten ir un paso más allá en la calidad y la productividad en el desarrollo de aplicaciones web-based. Actualmente existen muchas herramientas para la creación de entornos RIA. Algunas de estas se pueden mencionar las plataformas Adobe Flash, Adobe Flex y Adobe AIR de Adobe, AJAX, OpenLaszlo, Silverlight de Microsoft, JavaFX, Oracle, Bindows y Javascript, etc[3]. Para relacionar de mejor manera esta nueva tecnología con las más antiguas comenzaremos por mencionar las tecnologías de interfaz de usuario más conocidas como son: el cliente de escritorio, cliente web y el nuevo RIA así podemos ver la relación que existe combinando distintas tecnologías como Flex y C Sharp (de vi-

CAPÍTULO 2. MARCO TEÓRICO 20 Figura 2.7: Características aplicaciones RIAs. sual estudio) (ver figura 2.8) para lograr una mezcla interesante entre aplicaciones conocidas de escritorio con funcionalidades especiales que logran entregar un entorno agradable al usuario con aplicaciones fáciles y rápidas[3]. Las aplicaciones RIA logran optimizar la rapidez de las consultas, por el hecho de cargar toda la aplicación de una sola vez si se quiere, así las aplicaciones RIA hacen una nueva consulta solamente para actualizar datos, de esta manera el cliente solicita servicios y se actualiza la parte visual de la aplicación, siendo el servidor el encargado de ejecutar e implementar los servicios, permitiendo las transacciones con el cliente y retornando al entorno visual requerido. El servidor por su parte es el que procesa todas las peticiones del cliente (entorno lógico) donde se guardan los datos y se obtienen desde y hacia la base de datos[3]. Algunas ventajas de la utilización de esta tecnología son: Ofrece a los usuarios una experiencia más sofisticada y atractiva con características que no son nativas en los navegadores web como captura de video. Las aplicaciones se parecen visualmente a las de escritorio lo que permite una

CAPÍTULO 2. MARCO TEÓRICO 21 Figura 2.8: Interacción de tecnologías con RIAs. mayor usabilidad por un entorno ya conocido por el usuario. Se pueden utilizar sin la necesidad de instalar en cada computador, sólo se necesita tener un navegador web actualizado. La mayoría de las RIAs permiten que la experiencia del usuario sea coherente, independientemente de qué sistema operativo utiliza el cliente. Las actualizaciones hacia nuevas versiones son automáticas. Aplicaciones basadas en Web y generalmente son menos propensas a la infección viral que correr un ejecutable real. Procesar localmente en el cliente sin necesidad de intervenir en el servidor. El cliente tiene una alta expectativa permanentemente. En el desarrollo de esta memoria se utilizará el cliente Flex herramienta creada por Adobe.

CAPÍTULO 2. MARCO TEÓRICO 22 2.7. Aplicaciones Flex. Son aplicaciones que agrupan una serie de tecnologías con el fin de dar soporte adecuado a las aplicaciones enriquecidas de internet altamente productivas y expresivas, que se implantan coherentemente en exploradores, que se basan en la plataforma que es propietaria Flash. Flex que compila su propio lenguaje (MXML) es ejecutado por ActionScript para flash, de esta manera Flex enmarca los desarrollos en interfaces graficas de usuarios usando el lenguaje XML llamado MXML como se menciono anteriormente, así Flex tiene varios componentes y características que aportan algunas funcionalidades que son muy importantes como Servicios Web, Objetos Remotos, arrastrar y soltar, columnas dinámicas de los Grid, gráficos, efectos de animación y muchas otras herramientas que han sido desarrollada. El objetivo principal de Flex es lograr construir aplicaciones de internet enriquecidas de manera fácil y rápida, así Flex en el modelo multicapa es la capa visual junto con esto Flex tienen una compatibilidad muy alta con los navegadores Web. Para mejorar el flujo de datos el cliente carga la aplicación solo una vez así Flex se vuelve una herramienta superior frente a aplicaciones en HTML, las cuales requieren ejecutar plantillas en el servidor para cada acción. Con esta facilidad de Flex que trabaja en formato multicapa se logra desacoplar la lógica y el diseño permitiendo una cierta independencia dedicada al cliente[6]. El servidor Flex también actúa como un Gateway permitiendo al cliente comunicarse con servicios web XML y objetos remotos (tales como Coldfusion CFCs, clases Java, y cualquiera que soporte el formato de mensajes de acciones). Las alternativas a Flex son (entre otras) Google Web Toolkit, JavaFX, OpenLaszlo y Silverlight de Microsoft[6]. Proceso de desarrollo de una aplicación Flex Los datos mostrados a continuación han sido extraídos directamente del archivo de ayuda de la versión 2.0 Beta 3 de Flex: Definir un interfaz de aplicación usando un conjunto de componentes predefinidos (formularios, botones, etc.). Ordenar estos componentes en el diseño del interfaz de usuario.

CAPÍTULO 2. MARCO TEÓRICO 23 Usar estilos y temas para definir el diseño visual. Añadir comportamiento dinámico (una parte de la aplicación interactuando con otra, por ejemplo). Definir y conectar a servicios de datos según sea necesario (servicios web). Compilar el código fuente en un archivo SWF que funcione en el reproductor Flash. Finalmente cabe mencionar algunas desventajas de Flex frente a otras herramientas como por ejemplo que se necesita un plugin para ejecutar estas aplicaciones, además se debe esperar que cargue el contenido Flash al iniciar la pagina por último el problema que el contenido Flash no sea indexado por los buscadores también es una clara desventaja ya que no podremos acceder a información que se encuentre dentro de las aplicaciones desde un buscador. En los últimos meses se ha utilizado una forma de evitar esta ultima problemática llamada Metatags que son etiquetas que nos permiten acceder desde un buscador algunos metadatos definidos en la aplicación flash lo que resuelve en parte el ultimo inconveniente presentado por estas aplicaciones pero solo parcialmente ya que aun sería problema acceder a información no identificada como metadato, además ésta es una manera experimental que aun no está completamente estudiada [12]. 2.7.1. ActionScript (AS3). Lenguaje de programación utilizado en aplicaciones web animadas realizadas en el entorno Adobe Flash es decir es un lenguaje creado por y para flash donde podemos crear nuestros propios scripts además es un lenguaje orientado a objetos, que fue incorporado desde la versión 4 de Flash, en la actualidad ha crecido de forma muy rápida transformándose en un lenguaje robusto y completo incluyendo desde la versión 2 de Flex ActionScript 3.0. Es un lenguaje de script, por lo tanto no requiere creación de un programa para su ejecución. Este lenguaje es muy parecido al conocido JavaScript, la razón es que cuentan con los mismos estándares de industria ECMA-262. Las principales funciones de ActionScript 3.0 son:

CAPÍTULO 2. MARCO TEÓRICO 24 Una nueva máquina virtual ActionScript, denominada AVM2, que utiliza un nuevo conjunto de instrucciones de código de bytes y proporciona importantes mejoras de rendimiento. Una base de código de compilador más moderna, que se ajusta mejor al estándar ECMAScript (ECMA 262) y que realiza mejores optimizaciones que las versiones anteriores del compilador. Una interfaz de programación de aplicaciones (API) ampliada y mejorada, con un control de bajo nivel de los objetos y un auténtico modelo orientado a objetos. Un núcleo del lenguaje basado en el próximo borrador de especificación del lenguaje ECMAScript (ECMA-262) edición 4. Una API XML basada en la especificación de ECMAScript para XML (E4X) (ECMA-357 edición 2). E4X es una extensión del lenguaje ECMAScript que añade XML como un tipo de datos nativo del lenguaje. Un modelo de eventos basado en la especificación de eventos DOM (modelo de objetos de documento) de nivel 3. 2.8. Data Access Object (DAO). Es un patrón de diseño que permite abstraer y encapsular todo el acceso a la fuente de datos, entregando una interfaz común entre la interfaz y la base de datos actuando como un adaptador entre los componentes y la fuente de datos. Este patrón surge de la necesidad de gestionar una gran diversidad de fuentes de datos, el encapsulamiento no solo se refiere a la fuente de datos, sino que además oculta la forma de acceder a los datos. Al tener este patrón de diseño se puede tratar de forma independiente la base de datos propiamente tal de la lógica de negocio lo que permite que se puedan hacer modificaciones a la fuente de los datos. DAO está compuesto por una serie de elementos que se describen a continuación en la figura 2.9: BusinessObject: representa los datos del cliente. Requiere acceso a la fuente de datos.