Implementação de um sistema de alertas de segurança e boletins tecnológicos

(1)

Implementac¸ ˜ao de um sistema de

alertas de seguranc¸a e boletins

tecnol ´

ogicos

Monografia submetida `a Universidade Federal de Santa Catarina

como requisito para a aprovac¸ ˜ao da disciplina:

DAS 5511: Projeto de Fim de Curso

Igor Marques de Souza Gois

(2)

Implementaç ão de um sistema de alertas de segurança

e boletins tecnol ´

ogicos

Igor Marques de Souza Gois

Esta monografia foi julgada no contexto da disciplina

DAS 5511: Projeto de Fim de Curso

e aprovada na sua forma final pelo

Curso de Engenharia de Controle e Automac¸ ˜ao

Banca Examinadora:

Eng

a

. Deborah Dantas

Orientadora da empresa

Prof. Agustinho Plucenio

Orientador do Curso

(3)

Agradecimentos

Deixo aqui registrado os meus sinceros agradecimentos para:

Rob ério e Selma: pela dedicaç ão, preocupaç ão e investimento em todas as

minhas empreitadas Brasil afora. Mesmo distantes, voc ês sempre estiveram ao meu lado me dando conselhos e me motivando a voar cada vez mais alto. A dedicaç ão de voc ês para com os seus filhos é algo imensur ável e eu serei eternamente grato por isso.

Isis: por torcer, de um jeito extremamente peculiar, pelo sucesso do irm ˜ao mais

velho. Acredite, a rec´ıproca ´e verdadeira.

Minha fam´ılia: pela torcida, pelas oraç ões e por sempre me receber de braços

abertos em Aracaju.

Felipe Aguiar (in memoriam): pelo exemplo de lic¸ ˜ao de vida e por me ensinar

a nunca desistir dos objetivos.

Rodrigo Le ˜ao: pela amizade digna de um irm ˜ao. Sou grato pela sua

compa-nhia nas viagens, festas, madrugadas de estudos e em Maca é. Agradeço tamb ém pelas profundas conversas sobre projetos inovadores, carreira, empreendedorismo, petr óleo, etc.

Alisson Calgaroto, Francisco Bezerra e Paulo Botura: por toda assist ˆencia

prestada a mim neste semestre. Sem voc ês morar em Maca é n ão seria a mesma coisa.

Guilherme Piazzetta e Bruno Balvedi: por compartilharem comigo as alegrias

e dificuldades de se ter a nossa pr ´opria empresa.

Amigos de Aracaju: pela amizade verdadeira que, apesar da dist ˆancia,

perdu-rar ´a por toda a vida.

Fam´ılia automac¸ ˜ao e agregados: por me adotarem nesses inesquec´ıveis anos

de muito estudo e muita festa que passei em Florian ´opolis.

Professores do DAS: por todos os conhecimentos compartilhados.

Funcion ários de TSS: pela atenç ão e paci ência para sanar todas as minhas

(4)

Resumo

Descrevem-se aqui as atividades desenvolvidas pelo estudante Igor Marques de Souza Gois durante o est ágio final na empresa Halliburton em Maca é-RJ, no contexto da disciplina Projeto de Fim de Curso (DAS 5511), do curso de Engenharia de Controle e Automaç ão.

A ind ústria do petr óleo possui diversos riscos intr´ınsecos, logo os aspectos rela-cionados à segurança s ão uma preocupaç ão constante na empresa. Frequentemente s ão gerados alertas de segurança e boletins tecnol ógicos que devem ser divulgados para todos os funcion ários da empresa. Os alertas de segurança s ão notificaç ões que relatam algum acidente que ocorreu recentemente, informando quais as cau-sas que levaram a esse acontecimento e o que se deve fazer para evit á-lo. Bole-tins tecnol ógicos, por sua vez, s ão notificaç ões emitidas pela Halliburton referentes a mudanças ocorridas em alguma ferramenta ou em um processo da companhia. Sendo assim, todos os funcion ários do segmento, sem exceç ão, devem estar cientes destes alertas e boletins para uma maior segurança nas operaç ões e para evitar que aciden-tes semelhanaciden-tes aos que j á aconteceram n ão se repitam.

Nesse contexto, as atividades do projeto s ão concentradas na implementaç ão de um sistema de alertas de segurança e boletins tecnol ógicos atrav és de um fra-mework web chamado CakePHP. O escopo do projeto é importante porque viabilizar á uma maior divulgaç ão dessas notificaç ões, e consequentemente um maior comprome-timento dos funcion ários com a segurança e com a qualidade dos serviços prestados pela empresa.

Palavras-chave: Alertas de segurança, boletins tecnol ógicos, aspectos de segurança,

(5)

Abstract

This report describes the activities developed by the student Igor Marques de Souza Gois during his internship at Halliburton in Maca ´e-RJ, in the context of the Final Project, as part of the Control and Automation Engineering undergraduate course.

The oil industry has several inherent risks, so safety is a constant concern in the company. Frequently, flash alerts and technology bulletins are published and they must be disclosed to all employees. Flash alerts are notifications that report an acci-dent that occurred recently, what were its causes and what should be done to prevent it. Technology bulletins are notifications issued by Halliburton relating to modifications in its operational tools or in its processes. Therefore, all employees, without excep-tion, should be aware of these notifications. Thus, the operations become safer and accidents are prevented.

In this context, the activities of this project are focused on the implementation of a flash alerts and technology bulletins system using a web framework called Ca-kePHP. The project scope is important because it will allow a greater disclosure of such reports. Therefore the employees will be more committed to safety and quality of services provided by the company.

(6)

Sum ´ario

Lista de Figuras viii

Lista de Tabelas xi

Simbologia xii

1 Introduc¸ ˜ao 1

1.1 A ind ´ustria do petr ´oleo . . . 1

1.2 Halliburton Servic¸os . . . 1

1.3 O PSL de Testing and Subsea (TSS) . . . 3

1.3.1 Data Acquisition Services (DAS) . . . 4

1.3.2 Fluid Sampling (SAM) . . . 4

1.3.3 Test Tools (TT) . . . 5

1.3.4 Surface Well Testing (SWT) . . . 6

1.3.5 Subsea Safety Systems (SSS) . . . 7

1.3.6 Reservoir Engineering (RE) . . . 7

1.4 HSE e SQ . . . 7

1.5 Apresentac¸ ˜ao do problema . . . 8

1.6 Objetivos . . . 12

1.6.1 Objetivos gerais . . . 12

1.6.2 Objetivos espec´ıficos . . . 13

1.7 Justificativa do projeto . . . 13

1.8 Paralelo com a engenharia de controle e automac¸ ˜ao . . . 14

(7)

2 Aspectos de seguranc¸a na Halliburton 16

2.1 Treinamentos HSE . . . 16

2.2 Programa de cart ões de observaç ão . . . 18

2.3 Stop Work Authority . . . 19

2.4 L´ıder de HSE e 5S . . . 20

2.5 Reuni ão di ária de segurança . . . 21

2.6 An ´alise de risco . . . 21

2.7 Considerac¸ ˜oes finais . . . 24

3 Concepç ão e elaboraç ão do sistema 25 3.1 Concepç ão . . . 25

3.1.1 Levantamento dos requisitos . . . 25

3.1.1.1 Vis ˜ao geral do sistema . . . 26

3.1.1.2 Especificac¸ ˜ao de requisitos . . . 26

3.1.2 Organizac¸ ˜ao dos requisitos . . . 31

3.2 Elaborac¸ ˜ao . . . 34

3.2.1 Expans ˜ao dos casos de uso . . . 34

3.2.2 Operac¸ ˜oes e consultas do sistema . . . 35

3.3 Projeto do banco de dados . . . 37

4 Implementac¸ ˜ao do sistema 40 4.1 Tecnologias utilizadas . . . 40 4.1.1 PHP . . . 41 4.1.2 MySQL . . . 42 4.1.2.1 phpMyAdmin . . . 43 4.1.3 XAMPP . . . 44 4.1.3.1 Servidor . . . 44

(8)

4.1.3.2 Backup . . . 46 4.1.4 Model-view-controller (MVC) . . . 46 4.1.5 CakePHP . . . 47 4.1.5.1 Modelos . . . 47 4.1.5.2 Controladores . . . 50 4.1.5.3 Vis ˜oes . . . 52 4.2 Seguranc¸a . . . 52 4.3 Detalhamento . . . 54

4.3.1 Confirmar leitura de alertas e boletins . . . 54

4.3.1.1 Excec¸ ˜oes . . . 57

4.3.1.2 Listar alertas e boletins j ´a lidos . . . 59

4.3.2 Area administrativa . . . .´ 60

4.3.2.1 Gerenciamento de alertas e boletins . . . 61

4.3.2.2 Gerenciamento de usu ´arios . . . 62

4.3.2.3 Relat ´orios . . . 64

4.4 Considerac¸ ˜oes finais . . . 66

5 Resultados 67 5.1 Resist ˆencia inicial . . . 67

5.2 Dados obtidos . . . 68

5.2.1 Tamanho do banco de dados . . . 68

5.2.2 Usu ´arios . . . 68

5.2.3 Alertas . . . 69

5.2.4 Confirmac¸ ˜ao de leitura . . . 70

5.3 Pr ˆemio de boas pr ´aticas . . . 71

(9)

6.1 Perspectivas . . . 73

6.1.1 Expans ˜ao para outros segmentos . . . 73

(10)

Lista de Figuras

1.1 Areas de atuac¸ ˜ao da Halliburton. [2] . . . .´ 2

1.2 Os sub-PSLs de Testing and Subsea. . . 5

1.3 Coluna b ´asica de Test Tools. . . 6

1.4 Exemplo de um alerta de seguranc¸a. . . 9

1.5 Exemplo de um boletim tecnol ´ogico. . . 10

1.6 Pasta classificadora utilizada. . . 11

1.7 Dificuldade na coleta de assinaturas. . . 12

2.1 Segurança é condiç ão de emprego na Halliburton. . . 17

2.2 Programa de cart ões de observaç ão. . . 19

2.3 Cart ˜ao Stop Work Authority. . . 20

2.4 Reuni ˜ao di ´aria do sub-PSL de SWT. . . 22

2.5 Matriz de an ´alise de risco. . . 23

2.6 Exemplo de um item da an ´alise de risco do laborat ´orio de DAS. . . 24

3.1 Diagrama de casos de uso do sistema. . . 32

3.2 Diagrama de sequ ˆencia do sistema. . . 37

3.3 Modelagem conceitual do banco de dados. . . 39

4.1 Exemplo de sintaxe PHP utilizada para a filtragem. . . 42

4.2 Criaç ão da tabela dos usu ários. . . 43

4.3 Interface do phpMyAdmin. . . 43

4.4 Interface do XAMPP. . . 45

4.5 Sistema sendo acessado no navegador web. . . 45

4.6 Arquitetura do modelo MVC. [15] . . . 47

4.7 Relac¸ ˜ao muitos para muitos implementada no CakePHP. . . 50

(11)

4.9 Configurac¸ ˜ao do XAMPP protegido por senha. . . 53

4.10 Configuraç ão do XAMPP e phpMyAdmin é poss´ıvel apenas localmente no servidor. . . 53

4.11 Requisic¸ ˜ao de senha para acessar o phpMyadmin. . . 54

4.12 Tela de login para os administradores. . . 54

4.13 Tentativa de acesso a conte ´udo protegido. . . 55

4.14 Listagem de alertas de seguranc¸a e boletins tecnol ´ogicos. . . 55

4.15 Boletins filtrados de acordo com seus sub-PSLs. . . 56

4.16 Vis ˜ao do m ´etodo view() do controlador Alertas. . . 57

4.17 Confirmaç ão da leitura de um boletim tecnol ógico. . . 58

4.18 Leitura confirmada com sucesso. . . 58

4.19 Erro gerado ao digitar um SAP inexistente. . . 59

4.20 Alerta gerado quando a opç ão ’Declaro que li e entendi’ n ão foi selecio-nada. . . 59

4.21 Confirmaç ão de leitura de um alerta ou boletim que j á foi lido. . . 59

4.22 Listar alertas e boletins que j ´a foram lidos. . . 60

4.23 Menu de gerenciamento do sistema. . . 61

4.24 Adic¸ ˜ao de um novo alerta ou boletim. . . 62

4.25 Remoc¸ ˜ao de um alerta ou boletim. . . 62

4.26 Adiç ão de um novo usu ário. . . 63

4.27 Alerta de confirmaç ão para a remoç ão de um usu ário. . . 63

4.28 Estat´ıtisca referente a um alerta de seguranc¸a. . . 64

4.29 Funcion ários que j á leram o alerta de segurança. . . 65

4.30 Funcion ários que ainda n ão leram o alerta de segurança. . . 66

5.1 Tamanho do banco de dados. . . 68

5.2 N ´umero de usu ´arios cadastrados sistema. . . 69

(12)

5.4 N ´umero de alertas e boletins adicionados ao sistema. . . 70

5.5 Confirmac¸ ˜oes de leitura. . . 71

(13)

Lista de Tabelas

3.1 Requisito funcional F1 e seus requisitos n ˜ao funcionais. . . 27

3.5 Consultas do sistema. . . 33

3.6 Expans ˜ao do caso de uso. . . 36

4.1 Modelos implementados no CakePHP. . . 49

(14)

Simbologia

PSL (Product Service Line): sigla referente a um segmento de atuac¸ ˜ao da Hal-liburton.

TSS (Testing and Subsea): PSL de Testing and Subsea da Halliburton.

DAS (Data Acquisition Services): sub-PSL de Testing and Subsea respons ável pela aquisiç ão de dados do poço.

SAM (Fluid Sampling): sub-PSL de Testing and Subsea respons ´avel pela amos-tragem de fluidos.

TT (Test Tools): sub-PSL de Testing and Subsea respons ´avel pelos equipamen-tos da coluna de teste.

SWT (Surface Well Testing): sub-PSL de Testing and Subsea respons ´avel pelos equipamentos de superf´ıcie.

SSS (Subsea Safety Systems): sub-PSL de Testing and Subsea respons ´avel pelos equipamentos subsea de seguranc¸a.

BOP (Blowout Preventer): conjunto de v álvulas de segurança respons áveis pelo controle de abertura e fechamento de poços de petr óleo.

RE (Reservoir Engineering): sub-PSL de Testing and Subsea respons ável pela an álise e avaliaç ão dos dados do reservat ório.

HSE (Health, Safety, and Environment): área respons ável por s áude, segurança e meio ambiente.

SQ (Service Quality): área respons ável pela qualidade do serviço.

5S: metodologia japonesa que preza pela organizac¸ ˜ao, ordem e limpeza do ambiente de trabalho.

RPC (Risk Priority Code): medida que avalia os perigos e risco de uma ativi-dade.

UP (Unified Proccess): metodologia de desenvolvimento de software atrav ´es do processo unificado.

(15)

RS (Respostas do sistema): respostas realizadas pelo sistema.

UML (Unified Modeling Language): ´e uma linguagem de modelagem de soft-ware.

PHP (PHP Hypertext Preprocessor - acr ônimo recursivo): linguagem de programaç ão utilizada para implementar o sistema.

SGBD (Sistema de Gerenciamento de Banco de Dados): sistema respons ´avel por gerenciar o banco de dados.

SQL (Structured Query Language): linguagem para realizar as consultas no banco de dados.

IP (Internet Protocol): enderec¸o que indica o local de um computador em uma rede local ou p ´ublica.

MVC (Model-view-controller): modelo de desenvolvimento de software em tr ˆes camadas.

(16)

Cap´ıtulo 1: Introduc¸ ˜ao

1.1: A ind ´

ustria do petr ´

oleo

O petr óleo - do latim petra (pedra) e oleum ( óleo) - é uma subst ância oleosa, inflam ável, menos densa que a água, com cheiro caracter´ıstico e de cor variando entre o negro e o castanho escuro.

Atualmente, o petr óleo é a principal fonte de energia n ão renov ável do mundo. Ele é um bem estrat égico, de import ância vital para a economia mundial. O petr óleo, juntamente com o g ás natural, representam 52% de toda a energia consumida no mundo [1]. Diante disso, se faz necess ária a exploraç ão e produç ão em áreas cada vez mais inacess´ıveis, como por exemplo em águas ultra profundas do pr é-sal e na floresta amaz ônica.

Nesse contexto, a engenharia desempenha um papel fundamental. É atrav és dela que as novas tecnologias s ão desenvolvidas, permitindo assim a exploraç ão e produç ão em condiç ões cada vez mais desafiadoras. As empresas que possu´ırem esse diferencial, bem como um serviço de qualidade estar ão a frente.

Al ém da qualidade do serviço, a segurança nas operaç ões, a confiabilidade e a preocupaç ão com o meio ambiente s ão fatores fundamentais na ind ústria de petr óleo. Uma vez que os custos com o processo de exploraç ão s ão extremamente elevados, qualquer tipo de erro é inadmiss´ıvel. E danos a equipamentos, acidentes de trabalho e ambientais resultam em s érias consequ ências para a empresa e a sua imagem.

´

E justamente na qualidade do serviço, segurança nas operaç ões e ao meio ambiente que est á vinculado este projeto. Antes, por ém, se faz necess ária uma apresentaç ão sobre a empresa onde o est ágio foi realizado.

1.2: Halliburton Servic¸os

A Halliburton é hoje uma das maiores empresas de serviços para campos pe-trol´ıferos do mundo. Atualmente ela conta com mais de sessenta mil funcion ários atu-ando em aproximadamente oitenta pa´ıses. Suas principais sedes est ão em Houston e em Dubai.

(17)

A vis ão da Halliburton é ser a empresa preferida em serviços de exploraç ão e produç ão para o desenvolvimento de recursos globais de óleo e g ás. Sua miss ão, por sua vez, é criar um valor sustent ável atrav és do fornecimento de soluç ões excepcio-nais em produtos, serviços e recursos digitais que auxiliem seus clientes a terem êxito atrav és: [2]

• da maximizaç ão da produç ão e recuperaç ão;

• da obtenc¸ ˜ao de reservas ambientais dif´ıceis;

• do aperfeic¸oamento da efici ˆencia operacional.

A empresa oferece produtos e serviços l´ıderes da ind ústria para todo o ciclo de vida do reservat ório, da localizaç ão de hidrocarbonetos e gerenciamento de dados geol ógicos at é a avaliaç ão de perfuraç ão e formaç ão, da construç ão e conclus ão do poço at é a melhoria da produç ão. As áreas de atuaç ão da Halliburton s ão mostradas na figura 1.1:

Figura 1.1: ´Areas de atua¸c˜ao da Halliburton. [2]

• Evaluation - caracterizaç ão de reservat órios;

(18)

• Production - produç ão de poços.

Cada área de atuaç ão é dividida em segmentos, tamb ém chamados de PSL (Product Service Line). Estes PSLs possuem ainda subdivis ões conhecidas como sub-PSLs. O projeto descrito neste documento foi realizado na área de caracterizaç ão de reservat órios, mais especificamente no PSL de Testing and Subsea, tamb ém co-nhecido como TSS. O mesmo ser á detalhado a seguir.

1.3: O PSL de Testing and Subsea (TSS)

O TSS no Brasil possui aproximadamente duzentos funcion ários espalhados por tr ês bases operacionais em Maca é-RJ, Mossor ó-RN e Manaus-AM. Al ém disso, o PSL possui tamb ém escrit órios no Rio de Janeiro-RJ e em Natal-RN.

Os principais clientes do segmento s ˜ao as empresas Petrobr ´as, Anadarko, HRT, Repsol, Statoil, Shell e Devon.

A fase de exploraç ão de um reservat ório consiste em diversos passos. E para entender em que parte desse processo os serviços de Testing and Subsea est ão in-seridos, se faz necess ário citar as operaç ões que antecedem o teste propriamente dito.

Primeiramente, o poço encontrado deve ser perfurado. Em seguida ele passa por uma caracterizaç ão chamada perfilagem. Ap ós isso, ele é revestido e cimentado. Somente ap ós todas essas etapas é que o poço pode ser, efetivamente, testado. Es-sas informaç ões obtidas no teste auxiliar ão o cliente a tomar a decis ão se é vi ável investir na produç ão desse poço ou se ele deve ser abandonado.

Os testes de poço ajudam na previs ão da capacidade de produç ão e suas tend ências. A partir dessas informaç ões, s ão tomadas decis ões importantes, tais como m étodos de produç ão, programas de recuperaç ão secund ária e desenvolvi-mento em perfuraç ão. Os encarregados de realizar o teste no poço t êm a responsa-bilidade de fornecer dados precisos e completos do comportamento do reservat ório. [3]

Dito isto, o PSL de Testing and Subsea oferece serviços relacionados a teste e avaliaç ão de poços de petr óleo. Seu principal objetivo é disponibilizar para o cliente informaç ões acerca do reservat ório, auxiliando-o na tomada de decis ão. Para isso, s ão realizadas as seguintes operaç ões:

(19)

• aquisiç ão de dados de press ão e temperatura;

• identificaç ão e obtenç ão de amostras representativas de fluidos;

• determinaç ão da vaz ão do fluido;

• identificac¸ ˜ao de problemas;

• determinaç ão de par âmetros do reservat ório;

O segmento é dividido em seis sub-PSLs como mostrado na figura 1.2. Ape-sar de trabalharem em conjunto, cada um é respons ável por um determinado tipo de serviço. S ão eles:

• Data Acquisition Services (DAS).

• Fluid Sampling (SAM).

• Test Tools (TT).

• Surface Well Testing (SWT).

• Subsea Safety Systems (SSS).

• Reservoir Engineering (RE).

1.3.1: Data Acquisition Services (DAS)

Aquisiç ão de dados é um dos principais objetivos durante um teste de poço. O DAS é o sub-PSL de Testing and Subsea respons ável, principalmente, pela aquisiç ão e tratamento desses dados. Estes, por sua vez, devem ser confi áveis, exatos e facil-mente disponibilizados para os clientes.

Os principais dados coletados s ão press ões e temperaturas do fundo da formaç ão e da superf´ıcie.

1.3.2: Fluid Sampling (SAM)

O sub-PSL de Fluid Sampling é respons ável pela coleta de amostras repre-sentativas do fluido do poço. Esse fluido pode ser coletado tanto na superf´ıcie, como tamb ém no fundo do poço. E a partir da an álise desse material pode-se obter informaç ões

(20)

Figura 1.2: Os sub-PSLs de Testing and Subsea.

1.3.3: Test Tools (TT)

Test Tools é o sub-PSL respons ável pela completaç ão tempor ária do poço. Suas ferramentas, em sua maioria hidr áulicas e mec ânicas, descem no fundo da formaç ão para executar e auxiliar a realizaç ão do teste. Por exemplo, as ferramentas eletr ônicas do DAS descem acopladas em uma ferramenta de TT chamada porta registrador, a qual faz parte da coluna de teste. Um exemplo de uma coluna b ásica de teste com suas ferramentas principais é mostrada na figura 1.3.

(21)

Figura 1.3: Coluna b´asica de Test Tools.

1.3.4: Surface Well Testing (SWT)

O subsegmento de SWT est á relacionado com todos os equipamentos de su-perf´ıcie que auxiliam a realizaç ão de um teste de formaç ão. Seus principais objetivos s ão:

• controlar a press ão e a vaz ão dos fluidos do poço na superf´ıcie;

• estabelecer um regime est ´avel de escoamento;

• gerar dados atrav és de mediç ões das vaz ões de óleo, g ás e água;

• descartar os fluidos recuperados da maneira menos agressiva poss´ıvel ao meio ambiente.

(22)

1.3.5: Subsea Safety Systems (SSS)

O sub-PSL de subsea é respons ável pelos equipamentos que se localizam junto ao Blowout Preventer (BOP). Esses equipamentos fornecem uma maior segurança e evita acidentes em casos de emerg ência em que é preciso desconectar a coluna de teste da plataforma.

1.3.6: Reservoir Engineering (RE)

No Brasil, o sub-PSL de Reservoir Engineering, respons ável pela an álise e avaliaç ão dos dados do reservat ório, ainda n ão existe. Ele se encontra em fase de planejamento e brevemente far á parte do PSL Testing and Subsea no pa´ıs.

1.4: HSE e SQ

Como j á dito anteriormente, a qualidade do serviço, a segurança nas operaç ões, a confiabilidade e a preservaç ão do meio ambiente s ão preocupaç ões constantes da empresa. Neste contexto, existem duas áreas respons áveis por esses fatores.

A primeira é chamada de HSE (Health, Safety, and Environment) que é res-pons ável por toda parte de sa úde, de segurança e de meio ambiente. Como principais metas e atribuiç ões do HSE est ão [4]:

• identificar e documentar os processos necess ários para prestar um serviço se-guro e ambientalmente saud ável e confi ável;

• fornecer as habilidades e conhecimentos para realizar o trabalho com seguranc¸a;

• eliminar os riscos percebidos relacionados a performance do trabalho;

• prover ferramentas necess ´arias para identificar e reduzir os impactos de

HSE nas atividades di ´arias.

A segunda se chama SQ (Service Quality ) que, como o pr óprio nome j á diz, é a respons ável pela qualidade do serviço e pela percepç ão do cliente em relaç ão aos serviços prestados pela Halliburton. Como principais atribuiç ões do SQ est ão [5]:

• estar em total conformidade com os padr ões da ind ústria e preparar a organizaç ão para potenciais certificaç ões;

(23)

• assegurar que cada funcion ´ario tenha o conhecimento, habilidades e comporta-mentos para trabalhar de forma eficaz e competente;

• fornecer aos funcion ´arios um mecanismo para comunicar e tratar os riscos;

• melhorar continuamente a tecnologia e processos para mitigar os impactos em SQ;

• verificar o desempenho atrav és de auditorias robustas e comunicaç ão de

lic¸ ˜oes aprendidas.

Dois itens citados anteriormente foram colocados em negrito de forma proposi-tal, pois eles est ão diretamente relacionados ao projeto em quest ão. O mesmo prop õe uma ferramenta para identificar e reduzir os impactos de HSE, bem como comunicar liç ões aprendidas com o passado, auxiliando assim o SQ.

1.5: Apresentac¸ ˜ao do problema

Para um entendimento completo do problema encontrado, primeiramente se faz necess ário a definiç ão de dois termos vinculados a este projeto:

• Alerta de segurança: é um documento, emitido principalmente pela Petrobr ás, que descreve algum acidente que ocorreu recentemente nas atividades da ind ústria de petr óleo e g ás. Ele contempla basicamente as causas, as consequ ências e o que poderia ter sido feito para evitar o ocorrido. A partir da figura 1.4 observa-se um exemplo de alerta de segurança.

• Boletim tecnol ógico: este é um documento, emitido pela área tecnol ógica da Halliburton, que fornece informaç ões sobre procedimentos a serem seguidos e/ou alteraç ões em peças, ferramentas e processos. Essas mudanças devem ser seguidas por todos funcion ários ao redor do mundo de forma a manter a padronizaç ão dos serviços. Normalmente nele é contemplada uma descriç ão da modificaç ão a ser efetuada e o que deve feito para realiz á-la. Um exemplo é observado na figura 1.5.

(24)

(25)

(26)

Assim que os alertas de segurança e boletins tecnol ógicos s ão gerados, as áreas de HSE e SQ encaminham estes para a ger ência de cada PSL. Estes, por sua vez, s ão respons áveis por repassar estes informativos a todos os funcion ários do segmento (sem exceç ão).

Al ém disso, frequentemente ocorrem auditorias internas e externas as quais a ger ência deve, de algum modo, comprovar que todos os funcion ários do seu PSL est ão cientes dos alertas e boletins gerados.

Para isso, o TSS utiliza uma pasta classificadora, como observa-se na figura 1.6, onde s ão colocados todos os alertas e boletins impressos. Essa pasta, por sua vez, permanece uma semana em cada sub-PSL para que seus funcion ários leiam todos os informativos e assinem uma lista declarando que leram e entenderam os mesmos. Como existem tr ês bases operacionais de TSS no Brasil, se faz necess ário a criaç ão de tr ês pastas id ênticas, uma para cada base.

Figura 1.6: Pasta classificadora utilizada.

A rotatividade das pessoas na base é elevada devido a grande quantidade de embarques. Assim, quando um funcion ário retorna de um trabalho e a pasta j á passou pelo seu sub-PSL, é necess ário que o mesmo saia a procura dela nas outras áreas e leia todo seu conte údo de uma s ó vez para no final assin á-la, comprovando assim que est á ciente do conte údo apresentado. Todo esse processo gera uma grande perda de tempo at é se encontrar o paradeiro dos informativos da semana e dificulta a coleta de assinaturas de todos os empregados, como observa-se na figura 1.7.

(27)

Figura 1.7: Dificuldade na coleta de assinaturas.

Al ém disso, outro ponto a ser destacado é a necessidade de se imprimir todos os alertas e boletins, bem como a lista com os nomes de todos os funcion ários. Esse gasto de papel poderia ser evitado atrav és da digitalizaç ão deste processo.

Em geral, o m étodo utilizado apresenta diversas desvantagens. Um fato que comprova isso é que nos últimos tr ês anos, nunca se conseguiu 100% das assinaturas, obtendo assim indicadores negativos nesse quesito nas auditorias de SQ e HSE.

Dito isto, este projeto tem como foco propor melhorias nesse processo de divulgaç ão dos sistemas de alertas de segurança e boletins tecnol ógicos.

1.6: Objetivos

1.6.1: Objetivos gerais

O objetivo geral deste trabalho é propor e implementar um sistema de alertas de segurança e boletins tecnol ógicos de f ácil acesso a todos os funcion ários.

Como produto final espera-se obter uma interface em que os usu ários poder ão ler e confirmar, a qualquer momento, a leitura dos alertas de segurança e dos boletins tecnol ógicos. Com isso, relat órios e estat´ısticas poder ão ser gerados para serem

(28)

utilizados nas auditorias de HSE e SQ.

Al ém disso, o sistema deve ser implementado segundo os padr ões utilizados na Engenharia de Software, facilitando assim futuras manutenç ões, atualizaç ões e at é a utilizaç ão do sistema em outros pa´ıses.

1.6.2: Objetivos espec´ıficos

Para alcanc¸ar o objetivo geral, foram definidos diversos objetivos espec´ıficos, os quais s ˜ao apresentados abaixo:

• entendimento do processo antigo e elaborac¸ ˜ao de uma proposta de melhoria;

• levantamento das especificac¸ ˜oes/requisitos do projeto;

• utilizac¸ ˜ao de uma metodologia padronizada para desenvolvimento de software;

• escolha da linguagem de programac¸ ˜ao e estudo da mesma;

• desenvolvimento de uma interface simples e amig ´avel;

• estudo e implementaç ão de um banco de dados, de forma a armazenar os aler-tas, os boletins e as confirmaç ões de leitura;

• escolha dos indicadores de desempenho mais relevantes para serem utilizados nos relat ´orios.

1.7: Justificativa do projeto

A motivaç ão deste projeto est á fortemente ligada aos quatro pilares da Hallibur-ton: segurança, excel ência operacional, inovaç ão tecnol ógica e ética.

A medida que os acidentes ocorridos s ão fortemente divulgados atrav és dos alertas de segurança, fatos semelhantes s ão prevenidos e evitados no futuro. Al ém disso, a cada alerta divulgado, os funcion ários ficam sensibilizados com o ocorrido e, consequentemente, ficam mais atentos aos perigos e riscos presentes ao seu redor. Assim, obt ém-se um ambiente de trabalho com maior segurança.

Com a divulgaç ão dos novos procedimentos ou alteraç ões nas ferramentas e processos atrav és dos boletins tecnol ógicos, evita-se poss´ıveis falhas nos trabalhos e garante uma excel ência operacional dos serviços.

(29)

Al ém disso, com a utilizaç ão de um sistema mais eficiente para a divulgaç ão dos alertas e boletins, espera-se um maior comprometimento por parte dos funcion ários. Somado a isso, tem-se a geraç ão de relat órios e estat´ısticas do sistema. Todos esses fatores contribuir ão para resultados positivos nas pr óximas auditorias de HSE e SQ, elevando assim os indicadores de Testing and Subsea.

Outra justificativa est á relacionada ao meio ambiente. Uma vez que, atrav és desse novo sistema, n ão haver á a necessidade da impress ão de in úmeras folhas.

1.8: Paralelo com a engenharia de controle e automac¸ ˜ao

Dentro do contexto do curso de Engenharia de Controle e Automaç ão, este pro-jeto est á intimamente ligado a área de engenharia de software. Al ém disso, todo o embasamento obtido na disciplina Metodologia para Desenvolvimento de Sistemas (DAS5312) foi de fundamental import ância para o levantamento dos requisitos do usu ário, modelagem do sistema e seus diagramas.

No que se refere a fatores relacionados à segurança na ind ústria do petr óleo, a disciplina Aspectos de Segurança em Sistemas de Controle e Automaç ão (DAS5401) foi de grande valia. J á a disciplina Fundamentos de Sistemas de Banco de Dados (INE5225) teve tamb ém grande import ância para o projeto do banco de dados do sis-tema. J á a disciplina Integraç ão de Sistemas Corporativos (DAS5316) tamb ém foi de suma import ância no entendimento das poss´ıveis consequ ências na implementaç ão de um software em um sistema corporativo.

Vale destacar tamb ém as disciplinas oferecidas pelo programa PRH-34 que for-neceram todo o conhecimento relacionado a ind ústria de petr óleo e g ás.

1.9: Organizac¸ ˜ao do documento

No decorrer deste documento ser á poss´ıvel acompanhar as etapas de desen-volvimento do trabalho realizado. Neste primeiro cap´ıtulo, foi feita uma apresentaç ão do local onde o est ágio foi realizado, bem como uma breve descriç ão do projeto. No pr óximo cap´ıtulo s ão mostrados aspectos relacionados a segurança que s ão utilizados na ind ústria do petr óleo e na Halliburton.

(30)

do sistema, desde o levantamento de requisitos at é o projeto do banco de dados. J á o quarto cap´ıtulo detalha a implementaç ão do sistema e as tecnologias utilizadas.

O cap´ıtulo cinco aborda todos os resultados obtidos com o sistema proposto. No sexto e último cap´ıtulo exp õe-se as conclus ões e perspectivas sobre o projeto, onde se faz uma an álise cr´ıtica das tarefas realizadas e das dificuldades encontradas durante o per´ıodo.

(31)

Cap´ıtulo 2: Aspectos de seguranc¸a na Halliburton

Considerando que o exerc´ıcio de qualquer atividade profissional provoca riscos, podemos verificar que em quase todos os pa´ıses a preocupaç ão com a proteç ão ao trabalhador se registra nas pr óprias constituiç ões. [6]

Na ind ústria do petr óleo n ão é diferente. Ela possui in úmeros riscos intr´ınsecos relacionados tanto ao meio ambiente como aos seus funcion ários. Uma prova disso s ão as cat ástrofes ambientais que, de vez em quando, est ão presentes nos notici ários.

E, apesar de toda a preocupaç ão com este assunto, dados de entidades re-guladoras do mundo inteiro sugerem que, ap ós anos avançando, a segurança de operaç ões de exploraç ão em alto mar piorou nos últimos dois anos. [7]

Apesar disso, muito continua sendo feito para atingir a meta de zero acidentes. A atual presidente da Petrobr ás, Maria das Graças Silva Foster, em um carta a todos os funcion ários e terceirizados, disse: ”nessas quest ões, n ão podemos simplesmente filosofar, muito menos nos contentar com o muito que, reconheço, conquistamos at é agora. Em quest ões de segurança no trabalho, sa úde dos nossos profissionais e res-peito ao meio ambiente, temos de ser absolutamente pragm áticos e conseguir o ideal: zero em estat´ısticas de acidentes, vazamentos, afastamentos e mortes no trabalho”.

A Halliburton possui a segurança como um dos seus quatro pilares. Para isso, ela promove diversos programas e atividades que t êm como objetivo a conscientizaç ão de seus funcion ários para as quest ões relacionadas a segurança, a sa úde e ao meio ambiente. O assunto é levado muito a s ério na empresa e é considerado como condiç ão n úmero um de emprego, como observado em um cartaz mostrado na figura 2.1. Ao longo desse cap´ıtulo ser ão apresentados exemplos de iniciativas relacionadas a segurança na Halliburton.

2.1: Treinamentos HSE

Assim que o funcion ário é contratado pela Halliburton, ele deve, obrigatoria-mente, participar de diversos cursos relacionados a HSE. S ão aproximadamente tr ês semanas de treinamentos, onde s ão absorvidos conhecimentos iniciais sobre a em-presa e conceitos sobre sa úde, segurança e meio ambiente. A seguir segue a lista de

(32)

Figura 2.1: Seguran¸ca ´e condi¸c˜ao de emprego na Halliburton.

alguns dos cursos iniciais obrigat ´orios:

• gerenciamento ambiental;

• primeiros socorros;

• an ´alise de risco;

• seguranc¸a em H2S;

(33)

• movimentac¸ ˜ao de cargas;

• protec¸ ˜ao auditiva;

• protec¸ ˜ao contra quedas;

• combate a inc ˆendio;

• procedimento de entrada em espac¸o confinado;

• protec¸ ˜ao das costas;

• programa de cart ões de observaç ão.

Os treinamentos podem ser presenciais ou de forma online atrav és de uma pla-taforma de ensino chamada Halliburton University. Todos eles possuem uma avaliaç ão ao final, em que é obrigat ório obter uma nota igual ou superior a 80 por cento.

2.2: Programa de cart ˜

oes de observac¸ ˜ao

O programa de cart ões de observaç ão é uma ferramenta que motiva os fun-cion ários a cuidar um dos outros. Assim que é verificada uma situaç ão de risco à segurança ou ao meio ambiente, o funcion ário deve abordar, de forma adequada, os envolvidos e mostrar a eles os riscos envolvidos e qual a maneira mais indicada de realizar tal atividade.

Ap ós isso, o funcion ário que realizou a intervenç ão deve registrar o acontecido em uma interface web, como mostrado na figura 2.2. Se o fato observado est á rela-cionado com segurança das pessoas, ferramentas e equipamentos, diz-se ent ão que ele criou um cart ão de observaç ão de segurança. E caso o fato esteja relacionado ao meio ambiente, cria-se um cart ão de observaç ão sobre o meio ambiente.

Os cart ões devem conter uma descriç ão detalhada da situaç ão observada, a aç ão corretiva imediata realizada e a atitude tomada para evitar a recorr ência. Um fato importante a ser citado é que os nomes dos envolvidos n ão s ão mencionados. O objetivo do programa é a obtenç ão de uma tend ência dos perigos e riscos e n ão a repreens ão.

Dessa forma, a ger ência consegue identificar os pontos mais cr´ıticos e tomar aç ões para evit á-los. Al ém disso, é poss´ıvel tamb ém criar cart ões de boas pr áticas.

(34)

Figura 2.2: Programa de cart˜oes de observa¸c˜ao.

Nesse caso, deve-se citar os nomes dos envolvidos nos cart ões e parabeniz á-los pelo comprometimento com segurança. O elogio é uma das melhores formas de promover a recorr ência das boas pr áticas.

2.3: Stop Work Authority

O Stop Work Authority é um cart ão, mostrado na figura 2.3, que todos os fun-cion ários da Halliburton Brasil possuem. Com este cart ão em m ãos, o funfun-cion ário, independente da hierarquia, tem o direito de parar qualquer atividade que ele julgue ser insegura.

De acordo com H.M., vice presidente da Halliburton no Brasil: ”O funcion ário que apresentar este cart ão tem autoridade e responsabilidade de intervir ou interrom-per uma tarefa sem medo de repres álias, se observar uma aç ão ou condiç ão insegura no local de trabalho, ou que tenham preocupaç ão com o controle de SQ ou risco HSE. Caso tenha d úvida em realizar qualquer trabalho ou n ão se sinta seguro em faz ê-lo, por favor, n ão o faça e chame seu supervisor”.

(35)

Figura 2.3: Cart˜ao Stop Work Authority.

2.4: L´ıder de HSE e 5S

O 5S é uma metodologia de trabalho que usa uma lista de cinco palavras japo-nesas: Seiri, Seiton, Seiso, Seiketsu e Shitsuke. Em portugu ês elas s ão:

• classificaç ão: eliminar do espaço de trabalho o que seja in útil;

• ordem: organizar o espac¸o de trabalho de forma eficaz;

• limpeza: melhorar o n´ıvel de limpeza;

• normatizaç ão: prevenir o aparecimento de sup érfluos e a desordem;

• manutenç ão: incentivar esforços de aprimoramento.

Dessa forma, a metodologia possibilita desenvolver um planejamento sistem ático de classificaç ão, ordem, limpeza, permitindo assim de imediato maior produtividade, segurança, clima organizacional e motivaç ão dos funcion ários, com consequente me-lhoria da competitividade organizacional. [8]

Em cada sub-PSL, todos os dias, uma pessoa é escolhida para exercer a funç ão de l´ıder de HSE e 5S. Assim, sua atribuiç ão é aguçar seu senso de segurança e de organizaç ão, motivando todos a fazerem o mesmo. Todas as observaç ões verificadas durante o dia dever ão ser comentadas a todos na reuni ão di ária do dia seguinte.

(36)

2.5: Reuni ão di ária de segurança

No in´ıcio de cada dia, acontece a reuni ão di ária de segurança de TSS. Ela se inicia com algum funcion ário lendo um alerta de segurança ou expondo algum ponto observado. Em seguida, os l´ıderes de HSE e 5S de cada sub-PSLS exp õem para todos suas observaç ões do dia anterior, relatando o que foi observado e o que foi feito para evitar reincid ência, ou at é mesmo elogiando alguma boa pr ática.

Por fim, os gerentes relatam a todos sobre as operaç ões em andamento e pon-tos relacionados à segurança observados nas plataformas. Ap ós isso, a reuni ão é finalizada com algum funcion ário proferindo a seguinte frase: ”Se algu ém aqui n ão se encontra apto, fisica ou psicologicamente, para exercer suas funç ões com segurança no dia de hoje, por favor contate seu supervisor. Bom dia de trabalho a todos”.

Terminada a reuni ão, os funcion ários de cada sub-PSL formam uma pequena roda onde acontece a sua reuni ão di ária, conforme mostrado na figura 2.4. Nela s ão planejadas e divididas as tarefas a serem executadas durante o dia, bem como a esco-lha do l´ıder de HSE e 5S. Al ém disso, todos devem assinar um documento chamado an álise de risco, comprovando que est ão cientes dos perigos e riscos presentes na

´area.

2.6: An ´alise de risco

A an álise de risco é um documento feito por cada sub-PSL que tem como obje-tivos identificar, avaliar e controlar os riscos existentes em cada área.

Assim, a identificaç ão exige que cada tarefa seja observada e os riscos intr´ınsecos a mesma sejam levantados. Um fato importante a ser citado é que toda tarefa nova deve ser, obrigatoriamente, analisada e adicionada ao documento. As atividades j á analisadas, por sua vez, devem ser revisadas de tempos em tempos de forma a ga-rantir uma an álise de risco atualizada que contemple todos os perigos e riscos envol-vidos.

Uma vez identificados, os riscos devem ser avaliados. Para isso, eles devem ser classificados de acordo com seus envolvidos, suas consequ ências e sua frequ ência. Esses par âmetros podem ser divididos em:

(37)

Figura 2.4: Reuni˜ao di´aria do sub-PSL de SWT.

• consequ ˆencias: catastr ´ofico, cr´ıtico, marginal ou desprez´ıvel;

• frequ ência: frequente, razoavelmente prov ável, ocasional, remota, extremamente improv ável ou imposs´ıvel.

Esses par âmetros devem ser interligados na matriz de an álise de risco. Atrav és dela obt ém-se o fator RPC (Risk Priority Code). Para isso, basta observar na tabela da figura 2.5 qual o valor do RPC para determinada consequ ência e frequ ência do perigo identificado. Existem tr ês poss´ıveis valores: 1 (vermelho), 2 (amarelo) ou 3 (verde). Por exemplo, para um perigo considerado como cr´ıtico (II) e que possui frequ ência avaliada em razoavelmente prov ável (B), de acordo com a tabela da matriz, ele pos-suir á um RPC de 1.

Caso a avaliaç ão obtenha um perigo com RPC 3, ent ão o mesmo é aceit ável e nada precisa ser feito. Entretanto, caso o perigo seja avaliado com RPC de 1 ou

(38)

2, medidas de controle devem ser tomadas de forma a diminuir a frequ ência ou a consequ ência do mesmo at é que um RPC 3 seja obtido.

(39)

Atrav és da figura 2.6 observa-se um item da an álise de risco do laborat ório de DAS. O item contempla o poss´ıvel risco referente a queda dos registradores, um equipamento utilizado para obter dados de press ão e temperatura. A poss´ıvel causa levantada é o descuido do operador no transporte e manuseio da ferramenta. Como efeito tem-se danos aos equipamentos e as pessoas. Diante disso, a consequ ência é considerada como cr´ıtica (II) e a frequ ência como ocasional (C), obtendo assim um RPC 2, o qual é inaceit ável. Como medida de controle aconselha-se manter a atenç ão constante e sempre deixar uma das m ãos livres durante o transporte do equipamento. Dessa forma, a frequ ência passa a ser considerada extremamente improv ável (E), logo o RPC se torna 3, o qual classifica o risco como aceit ável.

Figura 2.6: Exemplo de um item da an´alise de risco do laborat´orio de DAS.

2.7: Considerac¸ ˜

oes finais

Diante de todas as pr áticas citadas anteriormente, o projeto em quest ão prop õe uma nova ferramenta que auxilie os funcion ários a aguçar o senso de segurança atrav és da leitura de alertas de segurança e boletins tecnol ógicos.

Para a implementaç ão desse sistema, se faz necess ário o levantamento de requisitos do projeto a ser desenvolvido. As etapas de concepç ão e de elaboraç ão do sistema ser ão detalhadas no pr óximo cap´ıtulo.

(40)

Cap´ıtulo 3: Concepç ão e elaboraç ão do sistema

O desenvolvimento do software proposto foi implementado atrav és da meto-dologia UP (Unified Proccess), a qual é composta basicamente por quatro etapas: concepç ão, elaboraç ão, construç ão e transiç ão [9].

Neste cap´ıtulo ser ão detalhadas apenas as etapas de concepç ão e elaboraç ão do sistema, bem como o projeto do banco de dados do mesmo.

3.1: Concepc¸ ˜ao

´

E na fase de concepç ão que obt ém-se conhecimento do que realmente deve ser projetado. De acordo com Fred Brooks [10], ”a parte mais árdua da construç ão de um software consiste exatamente em identificar ’o que’ construir. Nenhuma outra parte do trabalho compromete tanto o resultado se elaborado de forma incorreta. Nenhuma outra parte oferece tanta dificuldade para efetuar correç ões posteriores”.

Por isso, é nessa fase que deve haver uma grande interaç ão entre o projetista e o cliente, de forma a obter, com clareza, uma vis ão geral do que deve ser desenvolvido.

Durante a fase de concepç ão, duas etapas s ão de fundamental import ância: o levantamento de requisitos e a organizaç ão dos requisitos

3.1.1: Levantamento dos requisitos

O mais importante da fase de concepç ão é determinar o que deve ser de-senvolvido, sem a preocupaç ão - pelo menos nesse momento - em como o projeto ser á implementado e quais tecnologias ser ão utilizadas. Assim, se faz necess ário a elaboraç ão de dois documentos:

• Vis ˜ao geral: documento que apresenta de maneira breve algumas id ´eias do pro-jeto, destacando as principais funcionalidades que caracterizam o sistema;

• Especificaç ão de requisitos: consiste na coleta e organizaç ão dos requisitos fun-cionais e n ão funfun-cionais que caracterizam a finalidade e uso do sistema.

(41)

Ap ós diversas reuni ões com os gerentes de Testing and Subsea - que nessa situaç ão fizeram o papel de cliente do projeto - respons áveis pelo processo de atualizaç ão da pasta contendo os alertas de segurança e boletins tecnol ógicos, foi poss´ıvel obter a vis ão geral do sistema a ser projetado, mostrada a seguir.

3.1.1.1: Vis ˜ao geral do sistema

O sistema de alertas de segurança e boletins tecnol ógicos visa informatizar e facilitar o acesso dos funcion ários aos alertas e boletins emitidos pela ger ência. A utilizaç ão desse sistema elimina o processo manual e ineficiente feito atrav és da impress ão das notificaç ões e simplifica o processo de leitura das mesmas. Os aler-tas e boletins gerados devem ser armazenados e visualizados, possibilitando que os usu ários confirmem a leitura dos mesmos de forma extremamente simples. Al ém disso, relat órios com base nas informaç ões adquiridas devem ser entregues como produto final.

Uma vez obtida a vis ˜ao geral do sistema, deve-se levantar os requisitos do sistema.

3.1.1.2: Especificac¸ ˜ao de requisitos

Existem dois tipos de requisitos: os funcionais e os n ão funcionais. Os funci-onais representam as funç ões b ásicas do sistema. Os n ão funcifunci-onais, por sua vez, est ão vinculados aos requisitos funcionais e suas restriç ões. Eles podem ser classifi-cados de acordo com:

• a especificaç ão: obrigat órios ou desej áveis;

• o tempo de utilizaç ão: permanentes ou transit órios;

• a categoria de padr ões de qualidade: interface, segurança, performance, usabi-lidade, confiabiusabi-lidade, especificaç ão, etc.

Para o sistema em quest ˜ao, os requisitos funcionais levantados foram:

• F1: mostrar os alertas e boletins existentes;

(42)

• F3: administrar o sistema;

• F4: gerar relat ´orios.

Os requisitos funcionais juntamente com seus respectivos requisitos n ˜ao funci-onais s ˜ao apresentados nas tabelas a seguir.

Tabela 3.1: Requisito funcional F1 e seus requisitos n˜ao funcionais.

F1 Mostrar os alertas e boletins existentes Oculto ( ) Descri¸cão: O sistema deve apresentar ao usuário os alertas de seguran¸ca e boletins tecnológicos.

Requisitos n˜ao funcionais:

C´odigo Nome Restri¸c˜ao Categoria Classe Permanente

NF 1.1 Apresenta¸cão As informa¸cões devem estar dispostas da maneira simples e amigável.

Interface Obrigat´orio Sim

NF 1.2 Presen¸ca de categorias Deve existir a distin¸c˜ao entre alertas e boletins. Os boletins devem ser divididos por

sub-PSLs.

Interface Obrigat´orio Sim

NF 1.3 Identificar alertas e boletins já lidos Identificar os alertas e boletins que já foram lidos pelo usuário.

Usabilidade Desej´avel Sim

NF 1.4 Filtragem

Os alertas e boletins devem ser filtrados de acordo com seus atributos (t´ıtulo, data de cria¸c˜ao,

descri¸c˜ao).

(43)

F2 Ler alertas e boletins existentes e

confirmar a leitura dos mesmos Oculto ( ) Descri¸c˜ao: O sistema deve disponibilizar uma interface para ler e confirmar a leitura dos alertas e boletins.

Requisitos n˜ao funcionais:

NF 2.1 Abrir ou salvar as notifica¸c˜oes Os alertas ou boletins podem ser acessados

ins-tantaneamente ou salvos no computador para posterior leitura.

Usabilidade Obrigat´orio Sim

NF 2.2 Processo simples e direto O processo de ler e confirmar a leitura deve ser simples, r´apido e

direto.

Interface,

usabili-dade

Obrigat´orio Sim

NF 2.3 Confirma¸c˜ao ´

unica

Apenas uma leitura pode ser confirmada por

vez.

Seguran¸ca Obrigat´orio Sim

NF 2.4 Confirma¸cão através de identificador ´ unico A confirma¸cão da leitura deve ser

feita mediante um identificador

´

unico para cada funcion´ario.

NF 2.5 Declara¸cão que leu e entendeu A confirma¸cão de leitura só será realizada após o usuário declarar que leu, entendeu

e est´a ciente da notifica¸c˜ao.

(44)

F3 Administrar o sistema Oculto ( ) Descri¸c˜ao: O sistema deve disponibilizar uma interface

administrativa para gerenciar os usu´arios e alertas do sistema. Requisitos n˜ao funcionais:

NF 3.1 Acesso restrito Acesso a interface administrativa apenas para usu´arios autorizados.

NF 3.2 Gerenciamento de usu´arios alertas e boletins Os administradores do sistema devem ser capazes de adicionar, editar e remover usu´arios, alertas

e boletins.

NF 3.3 Adi¸cão de usuários Os usuários devem estar vinculados a um identificador ´ unico, a um sub-PSL e a um n´ıvel de acesso ao sistema.

NF 3.4 Adi¸cão de alertas e boletins Os alertas e boletins devem estar vinculados a um t´ıtulo, a uma descri¸cão e a um arquivo. Os boletins também devem estar ligados a um sub-PSL.

(45)

F4 Gera¸cão de relatórios Oculto ( ) Descri¸cão: O sistema deve gerar relatórios com estat´ısticas e

indicadores de desempenho do sistema. Requisitos n˜ao funcionais:

NF 4.1 Acesso restrito

A ´area de relat´orios deve estar dispon´ıveis

apenas aos usu´arios com

acesso privilegiado.

NF 4.2 Estat´ısticas

O sistema deve possuir a porcentagem de funcion´arios que

j´a leram determinada

notifica¸c˜ao.

NF 4.3 Relat´orio de leitura

O sistema deve gerar relat´orios de quem j´a leu e de quem falta ler

determinada notifica¸c˜ao.

(46)

A maior preocupaç ão dos gerentes era em relaç ão a simplicidade do sistema e sua interface. Haja vista que alguns funcion ários n ão possuem conhecimentos em inform ática. Assim, chegou-se a conclus ão que o sistema acessado pelos usu ários comuns deveria ser direto e intuitivo.

Outra preocupaç ão existente era que o sistema n ão permitisse a confirmaç ão de leitura de diversos alertas e boletins simultaneamente. Ler dezenas de notificaç ões de segurança pode se tornar uma tarefa mon ótona. Com isso, os funcion ários poderiam ser induzidos a negligenciar a leitura, declarando que est á ciente de alertas e boletins que nem sequer leu. Dessa forma, optou-se pela confirmaç ão de apenas um alerta ou boletim por vez.

Como forma de comprovar, em poss´ıveis auditorias, que os alertas e boletins est ão sendo divulgados e os funcion ários est ão cientes dos mesmos, viu-se a neces-sidade da geraç ão de relat órios de participaç ão. Atrav és deste requisito tamb ém é poss´ıvel verificar quais funcion ários n ão est ão engajados com a segurança, fato n ão aceit ável na empresa.

Outro fator de extrema import ância levantado pelos gerentes é a segurança do sistema, que n ão deve permitir o acesso de pessoas que n ão s ão da Halliburton, pois nele cont ém informaç ões confidencias da parte tecnol ógica. Al ém disso, o acesso aos relat órios deve ser feito apenas por pessoas autorizadas. Esse requisito ser á detalhado no pr óximo cap´ıtulo.

3.1.2: Organizac¸ ˜ao dos requisitos

Com base nos requisitos levantados pelos gerentes, chegou-se a conclus ão que a implementaç ão do sistema era vi ável. Nessa etapa, segundo a metodologia utilizada e de acordo com o projeto proposto, deve-se modelar os seguintes itens:

• casos de uso: consiste na relaç ão dos principais processos do sistema. Deve ser pensado do ponto de vista do usu ário utilizando o sistema, e deve consistir em uma unidade funcional coerente;

• consultas: consiste em simples verificaç ões de informaç ões armazenadas. As-sim, devem ser relacionados os principais procedimentos que o sistema deve ser capaz de executar para realizar os casos de uso.

(47)

Um ponto importante a ser citado, para melhor entendimento das definiç ões anteriormente citadas, é que os casos de uso provocam uma mudança no estado do sistema. As consultas, por sua vez, apenas obt êm informaç ões e n ão as modifica.

Atrav és do levantamento de requisitos, observa-se que o sistema ter á basi-camente dois tipos de usu ários: os usu ários comuns e os administradores. Assim, espera-se que os casos de uso sejam executados por dois atores. Al ém disso, como j á era previsto, o ator administrador do sistema é respons ável por muito mais casos de uso do que o usu ário comum, como pode ser observado na figura 3.1.

Figura 3.1: Diagrama de casos de uso do sistema.

As consultas presentes no sistema s ˜ao detalhadas e interligadas aos requisitos funcionais atrav ´es da tabela 3.5.

Uma vez obtido os casos de uso e as consultas, a pr óxima etapa a ser execu-tada é a fase de elaboraç ão.

(48)

Tabela 3.5: Consultas do sistema.

Nome Descri¸c˜ao Referˆencia

Listar alertas de seguran¸ca

Listagem dos alertas de seguran¸ca existentes. Esta pode ser filtrada e ordenada de acordo com os atributos

nome, descri¸c˜ao, data de cria¸c˜ao.

F1

Listar boletins tecnol´ogicos

Listagem dos boletins tecnológicos existentes. Esta pode ser filtrada e ordenada de acordo com os atributos sub-PSL, nome, descri¸cão, data de cria¸cão.

F1

Listar alertas e boletins j´a lidos

Listagem dos alertas e boletins que já foram lidos. Esta consulta será feita através do identificador único de cada

usu´ario.

F1

Listar usu´arios Listagem dos usu´arios do sistema, feita

apenas pelos administradores. F3

Listar relat´orios das leituras

Listagem dos usuários que já leram e os que ainda não leram determinado alerta

ou boletim, feita apenas pelos administradores.

F4

Listar estat´ısticas das leituras

Listagem das estat´ısticas referente aos usu´arios que j´a confirmaram a leitura de

determinado alerta ou boletim, feita apenas pelos administradores.

(49)

3.2: Elaborac¸ ˜ao

A meta da fase de elaboraç ão é criar uma estrutura para a arquitetura do sis-tema a fim de fornecer uma base est ável para o esforço da fase de construç ão, que ser á abordada posteriormente. A etapa se desenvolve a partir do exame e do deta-lhamento dos requisitos mais significativos. [11]

Assim, de acordo com as necessidades do projeto nesta etapa deve-se obter os seguintes documentos:

• Expans ão dos casos de uso: consiste na documentaç ão dos casos de uso relaci-onados na etapa anterior, fornecendo detalhes que auxiliam na sua interpretaç ão;

• Operac¸ ˜oes e consultas do sistema: nesta etapa devem ser relacionados os prin-cipais procedimentos que o sistema deve ser capaz de executar para realizar os casos de uso.

3.2.1: Expans ˜ao dos casos de uso

A expans ão dos casos de uso é baseada nos casos de uso obtidos na etapa an-terior. O objetivo é levantar uma sequ ência de passos realizados durante o processo. Nesse caso ser á detalhado o principal caso de uso do sistema, realizado tanto por usu ários comuns quanto por usu ários administradores, que é a confirmaç ão da leitura de alertas de segurança e de boletins tecnol ógicos.

Para se detalhar o caso de uso de confirmaç ão de leitura, de acordo com [9], é necess ária obtenç ão do fluxo principal do processo. Assim, todos os passos para a execuç ão dessa funç ão s ão listados de forma cronol ógica.

Uma vez obtida a sequ ência do processo, deve-se listar todas as pr é condiç ões, exceç ões e p ós condiç ões da execuç ão dessa funç ão. Espera-se que todos esses fa-tores estejam vinculados aos requisitos funcionais e n ão funcionais obtidos na primeira etapa.

O principal caso de uso do sistema é a confirmaç ão de leitura de alertas de segurança e de boletins tecnol ógicos. É atrav és desses processos que os funcion ários ficam cientes dessas notificaç ões envolvendo segurança e qualidade do serviço. Al ém disso, é atrav és dessa confirmaç ão que a ger ência comprova, em poss´ıveis auditorias, que est á repassando esses alertas e os boletins a seus funcion ários.

(50)

Como pr é condiç ão para esse caso de uso, é necess ário que os administradores do sistema tenham adicionado algum alerta ou boletim. Sem eles no sistema, n ão h á como haver confirmaç ão de leitura. Outra pr é condiç ão para esse processo seria que o usu ário em quest ão deve estar devidamente cadastrado com seu identificador único.

Como poss´ıveis exceç ões para este caso est ão a digitaç ão incorreta do iden-tificador do usu ário e a tentativa de confirmaç ão de leitura de um alerta ou de um boletim que j á foi anteriormente confirmada pelo funcion ário em quest ão. J á como p ós condiç ão tem-se, caso n ão haja nenhuma exceç ão, a mensagem de confirmaç ão de leitura e o registro dessa confirmaç ão em algum banco de dados para a geraç ão de relat órios futuros.

Todas essas informaç ões s ão mostradas na tabela 3.6 de expans ão do caso de uso principal do sistema. Na tabela é utilizada a sigla EV para denotar eventos do sistema e a sigla RS para as respostas do sistema. Esta identificaç ão auxiliar á a pr óxima etapa.

Os outros casos de uso n ão ser ão detalhados, pois seus fluxos s ão funç ões b ásicas como adicionar, editar e deletar. Elas n ão influenciam no entendimento do sistema como um todo.

3.2.2: Operac¸ ˜oes e consultas do sistema

As operaç ões do sistema consistem em m étodos ativados a partir de um evento do sistema, nada mais é que a resposta a uma aç ão do usu ário. Elas geralmente provocam alguma alteraç ão nas informaç ões armazenadas. Um exemplo de uma operaç ão seria a ediç ão de um funcion ário, que altera as informaç ões sobre este no banco de dados.

J á uma consulta consiste em simples verificaç ão dos dados armazenados. Nada é alterado, as informaç ões s ão apenas apresentadas. Um exemplo de consulta seria a listagem dos alertas de segurança existentes no sistema.

As operaç ões e consultas do sistema devem ser modeladas de forma a repre-sentar todo o fluxo das informaç ões entre os objetos do sistema e sua din âmica. Para isso, ser á utilizado o diagrama de sequ ência do UML (Unified Modeling Language). Ele registra o comportamento de um único caso de uso e exibe os objetos e as men-sagens passadas entre esses objetos.

(51)

Tabela 3.6: Expansão do caso de uso. Caso de uso: Confirmar leitura de alertas e boletins Pré condi¸cões:

Existir alertas de seguran¸ca e boletins tecnológicos cadastrados no sistema; Usuário que for confirmar a leitura deve estar cadastrado no sistema. Pós condi¸cões:

Mensagem de confirma¸c˜ao de leitura;

Registro dessa confirma¸c˜ao em algum banco de dados. Requisitos envolvidos: F1,F2 e F3

Fluxo principal:

1- Usuário lista alertas de seguran¸ca e boletins tecnológicos; [EV] 2- Usuário escolhe alerta ou boletim a ser lido; [EV]

3- Usuário lê a notifica¸cão escolhida; 4- Usuário digita identificador único; [EV]

5- Usuário declara que leu e entendeu a notifica¸cão; [EV] 6- Usuário confirma a leitura; [EV]

7- Sistema apresenta mensagem de confirma¸c˜ao de leitura. [RS]

Exce¸c˜oes:

4.a- Usu´ario digita incorretamente o identificador ´unico para confirmar a leitura [EV]

4.a.1- Sistema mostra mensagem de erro; [RS]

4.a.2- Usuário digita seu identificador único corretamente; [EV] 4.a.3- Usuário declara que leu e entendeu a notifica¸cão; [EV]

4.a.4- Sistema apresenta mensagem de confirma¸c˜ao de leitura. [RS]

5.a- Usu´ario tenta confirmar a leitura de um alerta ou boletim que j´a foi lido [EV]

5.a.1- Sistema mostra mensagem de erro; [RS]

5.a.2- Usu´ario escolhe outro alerta ou boletim a ser lido. [EV]

6.a- Usu´ario tenta confirmar leitura sem declarar que leu e entendeu a notifica¸c˜ao [EV]

6.a.1- Sistema mostra mensagem de erro; [RS] 6.a.2- Volta ao passo 5. [EV]

(52)

confirmar a leitura de alertas e boletins.

Figura 3.2: Diagrama de sequˆencia do sistema.

3.3: Projeto do banco de dados

Outra etapa muito importante da fase de elaboraç ão é a modelagem conceitual. Ela serve basicamente para apresentar as principais entidades do dom´ınio do sistema, bem como suas relaç ões e principais caracter´ısticas.

Para o caso do sistema proposto, o modelo conceitual ´e semelhante ao pro-jeto conceitual do banco de dados. Por isso, optou-se pela modelagem conceitual do banco de dados devido a sua maior abrang ˆencia e detalhamento do sistema.

A modelagem do banco de dados do sistema possui tr ês entidades b ásicas: usu ário, notificaç ão e arquivo. A entidade usu ário se refere aos usu ários do sistema e podem ser de dois tipos: usu ários comuns ou administradores. Todos eles possuem

(53)

os atributos nome, e-mail e possuem como chave prim ária o identificador único para cada funcion ário, chamado de n úmero SAP. Os usu ários comuns possuem ainda a en-tidade sub-PSL. J á os administradores possuem um login e um senha para gerenciar o sistema.

J á a entidade notificaç ão se refere aos alertas e boletins emitidos. Ela possui um identificador (id) único como chave prim ária e os atributos t´ıtulo e descriç ão. A notificaç ão pode ser de dois tipos: alerta de segurança ou boletim tecnol ógico. Como j á dito nos cap´ıtulos iniciais, os boletins tecnol ógicos est ão vinculados a algum sub-PSL, por isso este é um de seus atributos. Estes devem ser, a princ´ıpio, lidos por todos os funcion ários do sub-PSL em quest ão. J á os alertas de segurança devem ser lidos por todos, independente do sub-PSL.

A entidade arquivo se refere aos alertas e boletins digitalizados, normalmente em formato pdf. Ela possui como atributos o nome, o diret ório, o tamanho do arquivo e a extens ão, sendo o nome sua chave prim ária.

As entidades est ão relacionadas entre si. Por exemplo, o usu ário pode ter lido nenhuma, uma ou diversas notificaç ões. Da mesma forma, uma notificaç ão (alerta ou boletim) pode ter sido lida por nenhum, um ou v ários usu ários. Essa relaç ão é cha-mada de muitos-para-muitos, tamb ém denotada por (0,n). J á a entidade notificaç ão tem um relacionamento do tipo um-para-um com a entidade arquivo. Assim, uma notificaç ão possui obrigatoriamente um, e apenas um, arquivo. Assim como um ar-quivo est á vinculado a uma, e apenas uma, notificaç ão.

Todas essas entidades e relaç ões citadas podem ser observadas na figura 3.3. Depois de modelado, o banco de dados precisa ser implementado e integrado ao sis-tema. As tecnologias respons áveis pela implementaç ão ser ão detalhadas no pr óximo cap´ıtulo.

(54)

(55)

Cap´ıtulo 4: Implementac¸ ˜ao do sistema

No cap´ıtulo anterior foi feito o detalhamento de todos os requisitos, casos de usos, operaç ões e consultas, bem como o projeto do banco de dados. A partir da´ı, tem-se uma id éia de como o sistema deve ser e como ser á seu fluxo de informaç ões. A todo o momento foi pensado o que deve ser feito, por ém nada foi discutido sobre como fazer. Esse é justamente o enfoque deste cap´ıtulo, detalhar a implementaç ão, baseada nos requisitos levantados, do sistema e as tecnologias envolvidas.

4.1: Tecnologias utilizadas

De acordo com os requisitos levantados, observou-se que o sistema a ser im-plementado deveria possuir uma interface amig ável e que fosse facilmente acessada por todos os usu ários. A princ´ıpio foi pensado em desenvolver um software. Entre-tanto, essa soluç ão n ão possu´ıa o alcance desejado, uma vez que seria necess ária a instalaç ão do mesmo em cada computador que fosse utilizar o sistema. Isso seria uma grande desvantagem, j á que nem todos os usu ários possuem conhecimentos em inform ática.

Dessa forma, optou-se por utilizar uma plataforma web para implementar o sis-tema. Essa soluc¸ ˜ao possui as seguintes vantagens:

• f ácil acesso/grande alcance: o usu ário n ão precisa instalar nenhum software em seu computador para utilizar o sistema. Na plataforma web ele j á est á dispon´ıvel a todos da empresa que acessarem seu endereço;

• conhecimento pr évio: todos os funcion ários, por mais inexperientes que sejam, j á est ão habituados de como acessar um website atrav és de seu navegador;

• sistemas Halliburton: alguns sistemas da Halliburton tamb ém s ão implemen-tados em plataformas web. Um exemplo deles é o programa de cart ões de observaç ão, largamente utilizado pelos funcion ários;

• f ácil atualizaç ão: em caso de mudanças, n ão é necess ária a atualizaç ão pelos usu ários. Ela é feita somente no servidor, fazendo com que todos acessem

(56)

• segurança: a plataforma web permite que endereços sejam acessados apenas em redes internas, protegendo assim as informaç ões confidenciais contidas no sistema.

4.1.1: PHP

PHP é uma das linguagens mais utilizadas no mundo. Sua popularidade se deve à facilidade em criar aplicaç ões din âmicas com suporte à maioria dos bancos de dados existentes e ao conjunto de funç ões que, por meio de uma estrutura flex´ıvel de programaç ão, permitem desde a criaç ão de simples portais at é complexas aplicaç ões de neg ócios. [12]

Para a implementaç ão do sistema web se escolheu a linguagem PHP (PHP Hypertext Preprocessor ). Ela é especificamente voltada para o desenvolvimento web, onde é largamente utilizada. Suas principais caracter´ısticas s ão:

• velocidade e robustez;

• estruturada e orientada a objetos;

• portabilidade;

• sintaxe similar a C/C++ e o Perl;

• open-source.

A linguagem PHP é recomendada para o desenvolvimento de sistemas web velozes, simples e eficientes. Esses s ão requisitos intr´ınsecos do projeto em quest ão. Eles foram os principais fatores respons áveis pela a escolha do PHP. Outro fator muito importante foi o fato dela ser open-source, n ão sendo necess ário nenhum tipo de custo para sua utilizaç ão. Al ém disso, como ela é bastante utilizada no mundo, h á um grande acervo de documentaç ão na internet e um suporte eficiente por partes daqueles que utilizam essa linguagem.

Na figura 4.1 observa-se um exemplo de sintaxe PHP com um condicional if para a implementaç ão da filtragem dos alertas de segurança e dos boletins tec-nol ógicos.