UNIVERSIDADE DO VALE DO ITAJAÍ CENTRO DE CIÊNCIAS ...siaibib01.univali.br/pdf/Diogo Carvalho...
65
UNIVERSIDADE DO VALE DO ITAJAÍ CENTRO DE CIÊNCIAS TECNOLÓGICAS DA TERRA E DO MAR CURSO DE CIÊNCIA DA COMPUTAÇÃO SISTEMA DE ANÁLISE DE CONFLITOS DE TRANSAÇÕES CRÍTICAS Área de Gestão de TI por Diogo Carvalho Moraes Vinagre Ovidio Felippe Pereira da Silva Júnior, Dr. Orientador Itajaí (SC), novembro de 2009
Transcript of UNIVERSIDADE DO VALE DO ITAJAÍ CENTRO DE CIÊNCIAS ...siaibib01.univali.br/pdf/Diogo Carvalho...
UNIVERSIDADE DO VALE DO ITAJAÍ
CENTRO DE CIÊNCIAS TECNOLÓGICAS DA TERRA E DO MAR
CURSO DE CIÊNCIA DA COMPUTAÇÃO
SISTEMA DE ANÁLISE DE CONFLITOS DE TRANSAÇÕES CRÍTICAS
Área de Gestão de TI
por
Diogo Carvalho Moraes Vinagre
Ovidio Felippe Pereira da Silva Júnior, Dr.
Orientador
Itajaí (SC), novembro de 2009
ii
UNIVERSIDADE DO VALE DO ITAJAÍ
CENTRO DE CIÊNCIAS TECNOLÓGICAS DA TERRA E DO MAR
CURSO DE CIÊNCIA DA COMPUTAÇÃO
SISTEMA DE ANÁLISE DE CONFLITOS DE TRANSAÇÕES CRÍTICAS
Área de Gestão de TI
por
Diogo Carvalho Moraes Vinagre
Relatório apresentado à Banca Examinadora do
Trabalho de Conclusão do Curso de Ciência da
Computação para análise e aprovação.
Orientador: Ovidio Felippe Pereira da Silva Jr,
Dr.
Itajaí (SC), Novembro de 2009
iii
SUMÁRIO
LISTA DE ABREVIATURAS................................................................... v
LISTA DE FIGURAS ................................................................................ vi
RESUMO ................................................................................................... vii
ABSTRACT .............................................................................................. viii
1 INTRODUÇÃO ...................................................................................... 1
1.1 PROBLEMATIZAÇÃO .............................................................................................................. 3
1.1.1 Formulação do Problema ................................................................................. 3
1.1.2 Solução Proposta ............................................................................................... 3
1.2 OBJETIVOS ................................................................................................................................ 3
1.2.1 Objetivo Geral ................................................................................................... 3
1.2.2 Objetivos Específicos ........................................................................................ 4
1.3 Metodologia ................................................................................................................................ 4
1.4 Estrutura do trabalho ................................................................................................................... 4 2 FUNDAMENTAÇÃO TEÓRICA .............................................................................................. 6 2.1 Governança Corporativa ............................................................................................................. 6
2.1.1 Governança de TI.............................................................................................. 7
2.1.2 Framework de Governança de TI ................................................................... 9
2.2 Lei Sarbanes-Oxley ................................................................................................................... 14
2.2.1 Lei Sarbanes Oxley na TI ............................................................................... 16
2.3 Pesquisar e analisar soluções similares ..................................................................................... 19
2.3.1 Virsa Compliance Cablibrator ...................................................................... 19
2.3.2 AutoSeg ............................................................................................................ 20
2.3.3 Comentários sobre as soluções similares ...................................................... 21
2.4 Ferramentas de desenvolvimento .............................................................................................. 21
2.4.1 SAP ................................................................................................................... 22
2.4.2 Metodologia de Desenvolvimento .................................................................. 22
2.4.3 Linguagem de Programação .......................................................................... 23
2.4.4 Banco de Dados ............................................................................................... 23
3 PROJETO ............................................................................................. 26
3.1.1 Sistema de Análise de Conflitos de Transações Críticas ............................. 26
3.2 Análise de Requisitos ................................................................................................................ 28
3.2.1 Requisitos Funcionais ..................................................................................... 28
3.2.2 Requisitos Não Funcionais ............................................................................. 29
3.2.3 Regras de Negócio ........................................................................................... 29
3.3 Diagrama de Casos de Uso ........................................................................................................ 29
3.3.1 Módulo Conflito .............................................................................................. 30
3.3.2 Módulo Analisa Acesso ................................................................................... 30
3.4 Diagrama de Classes ................................................................................................................. 31 3.5 Interfaces do Sistema ................................................................................................................ 32 3.6 Metodologia .............................................................................................................................. 38
iv
3.6.1 Análise de Riscos ............................................................................................. 38
3.7 Implementação .......................................................................................................................... 38 3.8 Verificação do Sistema .............................................................................................................. 39
3.8.1 Performace ....................................................................................................... 40
3.8.2 Verificação junto ao Público Alvo ................................................................. 40
3.8.2.1 Manutenção de Conflitos ......................................................................... 40
3.8.2.2 Manutenção de uma transação em um conflito .................................... 42
3.8.2.3 Verificação conflitos de um usuário ....................................................... 42
3.8.2.4 Verificação das não conformidades ........................................................ 43
3.8.2.5 Comentários .............................................................................................. 44
4 CONSIDERAÇÕES FINAIS .................................................................................................... 45
4.1 Dificuldades encontradas .......................................................................................................... 45 4.2 Trabalhos Futuros ...................................................................................................................... 46
REFERÊNCIAS BIBLIOGRÁFICAS ................................................... 47
A DESCRIÇÃO DOS CASOS DE USO ................................................. 51
A.1 MODULO Conflito ..................................................................................................................... 51
A.2 MODULO CONFlitos ................................................................................................................. 54
B APÊNDICE DO DIAGRAMA ENTIDADE-RELACIONAMENTO
57
v
LISTA DE ABREVIATURAS
ADR`s American Depositary Receipts
CMMi Capability Maturity Model Integration
COBIT Control Objectives for Information and Related Technology
ERP Enterprise Resource Planning
EUA Estados Unidos da America
GNU General Public License
ISACA Information System Audit and Control Association
ITGI Information Techology Governance Institute
ITIL Information Technology Infrastructure Library
MVC Model View Control
PMBok Project Management Body of Knowledge
RC Risco do Controle
RFC Remote Function Call
RI Risco Inerente
S.A. Sociedade Anônima
SACTC Sistema de Análise de Conflitos Transações Críticas
SAP Systems Applications and Products in Data Processing
SARBOX Sarbanes-Oxley
SCI Sistema de Controle Interno
SGBD Sistema de Gerenciamento de Banco de Dados
SOX Sarbanes-Oxley
TCC Trabalho de Conclusão de Curso
TI Tecnologia da Informação
UNIVALI Universidade do Vale do Itajaí
vi
LISTA DE FIGURAS
Figura 1. Modelo de Governança Coorporativa ................................................................................... 6
Figura 2. Framework da Governança corporativa da TI. ................................................................... 10 Figura 3. Relacionamento entre os modelos, padrões e suas áreas de atuação .................................. 10 Figura 4. Processos ITIL .................................................................................................................... 11 Figura 5. Amadurecimento do CMMI................................................................................................ 12 Figura 6. Metodologia COBIT ........................................................................................................... 13
Figura 7. Demonstração COBIT e ITIL. ............................................................................................ 14 Figura 8. Lei SOX e Frameworks Fonte: Imasters ............................................................................. 17 Figura 9. Fluxograma do sistema SACTC ......................................................................................... 27 Figura 10. Diagrama de Casos de Uso do Módulo Conflito .............................................................. 30 Figura 11. Diagrama de Casos de Uso do Módulo Segregação de Funções ...................................... 31
Figura 12. Diagrama de Classes ......................................................................................................... 31 Figura 13. Tela para manutenção de conflitos (TEL001) .................................................................. 32
Figura 14. Tela para manutenção de conflitos (TEL002) .................................................................. 33 Figura 15. Tela de conflitos (TEL003) ............................................................................................... 33 Figura 16. Tela de procura usuário (TEL004) .................................................................................... 34 Figura 17. Tela para manutenção de usuário SOX (TEL005) ............................................................ 34
Figura 18. Tela de Analise de conflitos (TEL006). ............................................................................ 35 Figura 19. Tela de para análise de dados do sistema. ........................................................................ 35
Figura 20. Tela de relatório de conflitos. ........................................................................................... 36 Figura 21. Tela de relatório de usuários. ............................................................................................ 36 Figura 22. Tela de relatório de usuários com conflitos. ..................................................................... 37
Figura 23. Tela de relatório de usuários sem conflitos. ..................................................................... 37 Figura 24. Tela de não conformidades. .............................................................................................. 38
Figura 25. Tela de Manutenção de Conflitos ..................................................................................... 41 Figura 26. Tela de Manutenção de Conflitos ..................................................................................... 41
Figura 27. Tela manutenção de transação em um conflito ................................................................. 42 Figura 28. Tela manutenção de transação em um conflito ................................................................. 42 Figura 29. Tela verificação conflitos de um usuário .......................................................................... 43
Figura 30. Tela verificação conflitos de um usuário .......................................................................... 43 Figura 31. Tela verificação de não conformidades ............................................................................ 44
Figura 32. Diagrama do Banco de dados ........................................................................................... 57
vii
RESUMO
VINAGRE, Diogo Carvalho Moraes. Sistema de análise de conflitos de transações críticas.
Itajaí, 2009. no f. Trabalho de Conclusão de Curso (Graduação em Ciência da Computação)–Centro
de Ciências Tecnológicas da Terra e do Mar, Universidade do Vale do Itajaí, Itajaí, 2009.
Devido a vários escândalos financeiros foi criada uma política de governança corporativa para as
empresas que estão listadas na Bolsa de Valores e possuem ações ADR`s (American Depositary
Receipts). Essas empresas devem fazer parte de várias políticas de segurança da informação e de
tecnologia da informação e seguir as recomendações da lei Sarbanes Oxley. Este trabalho busca
auxiliar os gestores de controles internos a segregar funções em acessos de sistemas informatizados,
nesse trabalho o foco maior são para sistemas SAP (Systems Applications and Products in Data
Processing). Será utilizada a linguagem JAVA para a construção desse sistema computacional,
onde o usuário fará a interação com o sistema, o banco de dados será PostgreSQL, para o
armazenamento das informações. O sistema fará comparação dos acessos atuais do usuário com os
novos, com as regras já configuradas pelo usuário e esses valores irão informar se há conflito ou
não no novo acesso computacional desse usuário.
Palavras-chave: Controles Internos. Governança de TI.
viii
ABSTRACT
Due to various financial scandals, a policy of corporate governance was created for companies
which are listed in the stock exchanges and have ADR `s. These companies should be part of
various policies on information security and information technology and follow the
recommendations of Sarbanes Oxley law. This paper assists the managers of internal controls to
segregate functions in access to systems, the focus of this work is on SAP systems. The Java
language will be used for the construction of this computer system, where the user will interact with
the system, the database is postgreSQL for the storage of information. The system will compare the
current user's access to the new ones, with the rules already set by the user and these values will
inform if there is a conflict or not in the new computer access this user.
Keywords: Internals Controls. IT Governance.
1 INTRODUÇÃO
Para as empresas do Brasil com o seu capital aberto e nível de governança do Novo
Mercado na Bovespa, ―O Novo Mercado é um segmento de listagem destinado à negociação de
ações emitidas por companhias que se comprometam, voluntariamente, com a adoção de práticas de
governança corporativa adicionais em relação ao que é exigido pela legislação.‖ (BOVESPA,
2009).
Uma boa governança corporativa é fundamental para os investidores e significam bons
resultados financeiros das empresas. A governança ganhou força após uma série de escândalos
financeiros de grandes companhias em 2002, devido a esses, ganhou força devido à estrutura da
confiança abalada dos investidores. A crise na confiança contribuiu para os preços das ações caírem
na bolsa de valores.
―A governança corporativa – os arranjos institucionais que regem as relações entre
acionistas (ou outros grupos) e as administrações das empresas – deverá se transformar numa
preocupação importante no Brasil, na medida em que as mudanças em curso nos seus sistemas de
propriedade estatal e familiar acelerem e atraiam novos investidores, especialmente estrangeiros‖.
(BNDES, 2009, p.1)
Para governar em Tecnologia da Informação (TI), a empresa deve possuir uma boa
governança financeira e corporativa. Esta atividade é essencial para tomada de decisões, os riscos
também devem ser controlados e monitorados. A área de TI tornou-se uma parceira do negócio, e a
governança ganhou força ao lado da governança corporativa para atender a Sarbanes-Oxley (SOX),
Lei dos Estados Unidos que visa garantir os controles da empresa, com auditorias, comitês e
supervisionar as atividades que possam comprometer o balanço da empresa e também a
transparência financeira.
Segundo Hamaker e Hutton (2004, p. 2): ―Governança não é mais apenas um luxo, deve vir
entalhada na forma como as empresas fazem negócios, e isto se estende a todos os departamentos
da empresa‖.
Governança de Tecnologia de Informação é a capacidade de formular, controlar e
implementar estratégias da gestão de TI. ―A Governança de TI é de responsabilidade dos executivos
e da mesa de diretores, e consiste na liderança, na estrutura organizacional e em processos,
2
assegurando que a área de TI sustente e estenda os objetivos da estratégia organizacional‖ (ITGI,
2005, p. 5).
Para atender a lei SOX, pré-requisito para estar na bolsa de valores de Nova Iorque, e do
Novo Mercado da Bovespa a empresa deve garantir integridade dos dados e também dos acessos
aos sistemas informatizados. Uma das maneiras de garantir melhor o controle e evitar fraudes é a
segregação de funções nos sistemas, com isso, podem-se diminuir os riscos de fraudes por um
usuário.
A segregação de função é atribuir plano de organização, segundo José Filho (2008, p.94),
―Plano de organização – plano simples que se deve prestar ao estabelecimento de linhas claras de
autoridade e responsabilidade. Um elemento importante em qualquer plano de organização é a
independência estrutural das funções de operações, custódia, contabilidade e auditoria‖.
Ao segregar as funções são estabelecidos conflitos, um exemplo básico é um usuário que
cria uma requisição não poderá aprová-la, senão está passível de fraude, e se houver esse risco
deve-se controlar, via relatórios ou sistema o no qual toda a requisição criada por um usuário não
pode ser aprovada pelo mesmo.
Como não há solução computacional no mercado nacional viável, financeiramente, e com a
experiência do autor deste trabalho no sistema SAP, verifica-se a necessidade da criação de uma
solução utilizando a Tecnologia da Informação. A proposta passou pela criação de um software,
com a utilização de um Sistema de Gerenciamento de Banco de Dados (SGBD), para analisar
conflitos e encaminhar um workflow.
Segundo Laudon e Laudon (2007, p.90), ―Gerenciamento de fluxo de trabalho (workflow) é
o processo de simplificar procedimentos empresariais, de maneira que os documentos possam ser
transferidos com maior facilidade e eficiência de um lugar para outro‖.
Para o usuário conforme a necessidade do controle e outra funcionalidade para toda nova
transação criada deverá ser encaminhada uma mensagem eletrônica para o responsável da base de
conflitos, para esta ser avaliada, e se houver a necessidade, haverá a sua inclusão.
Várias empresas que atendem a SOX utilizam o controle manual para verificar a base de
conflitos ou até mesmo controles em planilhas eletrônicas. Para melhorar a eficiência será proposto
automatizar esse processo de análise de conflitos.
3
Com base nos conhecimentos sólidos obtidos no curso Ciência da Computação, tais como
sistemas de informação, engenharia de software, banco de dados e programação, será desenvolvido
um sistema para análise de conflitos de transações críticas, como base na pesquisa realizada no
projeto.
1.1 PROBLEMATIZAÇÃO
1.1.1 Formulação do Problema
Atualmente as soluções de mercado existentes para análise de novos acessos são
extremamente inviáveis, devido ao alto custo. Com esse trabalho foi criada uma solução adequada,
a baixo custo, e que seja viável a qualquer empresa, independente do seu tamanho físico e
financeiro, que verifique e monitore os controles necessários de acessos, e quando necessários, seja
validado e controlado os acessos críticos de um sistema informatizado.
1.1.2 Solução Proposta
Foi criado um sistema para análise de acessos críticos, com integração ao Enterprise
Resource Planning (ERP), que nesse caso é o SAP, sistema criado por uma empresa alemã que
controla todos os processos de uma empresa. Nesse sistema haverá uma base de conflitos
cadastrados, uma base dos usuários que possuem conflitos para haver o controle de monitoramento
de todos os controles compensatórios existentes e, por fim, todos os programas desse sistema para
monitorar quando houver novos programas e irá dificultar os usuários efetuarem fraudes nos
sistemas informatizados de uma empresa.
1.2 OBJETIVOS
1.2.1 Objetivo Geral
Desenvolver um sistema de informação que possibilita a redução dos riscos da empresa e
fraudes em seus sistemas informatizados, que atenda as necessidades da Lei SOX quanto à análise
de conflitos nas liberações de acessos.
4
1.2.2 Objetivos Específicos
Estudar a Governança de TI e Lei SOX;
Pesquisar e analisar soluções similares;
Definir o escopo e os requisitos do sistema;
Modelar o sistema através da utilização da Linguagem de Modelagem (UML);
Implementar e testar o sistema;
Realizar a validação do sistema; e
Documentar o desenvolvimento e os resultados obtidos.
1.3 Metodologia
As etapas a serem realizadas para o desenvolvimento deste trabalho são:
Levantamento Bibliográfico: Pesquisa de material bibliográfico: livros, artigos,
periódicos, teses, sites internet, a fim de fundamentar todo o estudo nesse projeto;
Revisão Bibliográfica: Realização da monografia, utilizando o levantamento
bibliográfico realizado na etapa anterior, as fundamentações e conceituações sobre as
tecnologias utilizadas no desenvolvimento do trabalho;
Preparação para Apresentação Banca TCC1: criação do conteúdo e estudar apresentação
desse trabalho;
Análise do Projeto: será realizada a análise do sistema dos requisitos do sistema
Implementação: desenvolvimento do software, implementação do banco de dados;
Testes: realização dos testes como validação do sistema; e
Preparação para apresentação Banca TCC2: refinar conteúdo para a pesquisa.
1.4 Estrutura do trabalho
Este projeto está dividido em capítulos. Um capítulo contém a introdução do projeto, sua
metodologia e como ele está estruturado.
5
Na Fundamentação Teórica são descritos todos os conceitos necessários para a realização do
projeto. Neste capítulo, também são apresentadas as principais características que o projeto deve
apresentar.
O Projeto especifica a modelagem do sistema, através da análise funcional e de dados
envolvidos no projeto.
O último capítulo, Considerações Finais, apresenta alguns tópicos relativos ao
desenvolvimento ao sistema.
6
2 FUNDAMENTAÇÃO TEÓRICA
Na fundamentação teórica desse projeto torna-se necessário apresentar alguns conceitos
relevantes para o cenário organizacional das empresas em relação à governança corporativa de TI e
Lei SOX.
2.1 Governança Corporativa
A economia mundial passou por uma série de escândalos financeiros, com isso foi
necessária a criação de uma política de responsabilidade e melhoria na gestão. ―Um sistema de
governança corporativa é composto pelo conjunto de instituições, regulamentos e convenções
culturais, que rege a relação entre as administrações das empresas e os acionistas ou outros grupos
às quais as administrações, de acordo com o tipo de modelo, devem prestar contas‖ (BOVESPA,
2009). A Figura 1 ilustra o esquema da governança Corporativa.
Figura 1. Modelo de Governança Coorporativa
Fonte: IT Governance
7
Um sistema de governança corporativa é composto pelo conjunto de instituições,
regulamentos e convenções culturais, que rege a relação entre as administrações das empresas e os
acionistas ou outros grupos às quais as administrações, de acordo com o tipo de modelo, devem
prestar contas. As características e o desenvolvimento desses modelos, que podem ser associados a
grupos de países, refletem as peculiaridades de formas distintas de organização capitalista e
prioridades políticas e sociais diversas. (BNDES, 2009)
2.1.1 Governança de TI
Governança em TI é uma derivação de Governança Corporativa, atualmente é utilizado em
empresas de classe mundial. A Governança em TI inclui estruturas de relacionamentos e processos
que tem como objetivos guiar e controlar a organização para que alcance seus objetivos, e monitore
os riscos em relação ao retorno da tecnologia de informação e seus processos. São estruturas e
processos que permitem controlar a execução e a qualidade dos serviços, viabilizando o
acompanhamento de contratos internos e externos, ou seja, a Governança em TI define as condições
para o exercício eficaz da gestão com base em conceitos consolidados de qualidade.
Para governar a TI, podemos aprender e muito com uma ótima governança financeira e
corporativa. A boa governança, por exemplo, financeira, pode ser estabelecida quando são indicadas
alçadas de aprovações, ou seja, delegar poderes a determinadas pessoas. Com isso o Diretor da
empresa não precisa aprovar todas as solicitações.
A Governança de TI está diretamente relacionada com o objetivo de melhorar o desempenho
da tecnologia no âmbito corporativo, e essa envolve uma série de medidas e práticas a fim de
influenciar o comportamento corporativo e direcionar de forma correta as atividades da TI. Além de
responder aos acionistas com uma maior transparência, atender as novas legislações a governança
de TI traz uma série de benefícios, tais como operacional, efetivo e alinhamento dos negócios e
redução de custos.
A governança de TI é especificar Key Users, são pessoas chaves de uma determinada
empresa para tomada de decisões e que possuem grande influência, para os direitos decisórios e do
framework de responsabilidade para haver um comportamento desejado na utilização da TI.
Segundo D'Andrea (2003), muitos CIOs têm questionado seus gerentes sobre suas
preocupações com relação:
8
Ao conhecimento dos envolvidos sobre os riscos, sistemas, controles e a segurança da
área de TI;
O nível de profundidade adequado para se estabelecer controles e se o benefício
justificaria o custo;
Os fatores críticos de sucesso de TI;
Os indicadores de bom desempenho da área de tecnologia e da organização; e
Os riscos do não atendimento dos objetivos, e como a corporação faria para medir e
comparar seus resultados com os concorrentes.
Devido a constantes alterações no mercado empresarial, estão sendo procuradas outras
formas de gerenciamento mais ágeis e flexíveis, assim de forma alinhada ao negócio da empresa e
do mercado essa nova visão de gestão de TI esta sendo cada vez mais procuradas por empresas e
essa é chamada de governança de TI. A Governança de TI é estruturar e definir os papéis, relações,
processos e padrões de avaliação, que controlam uma organização. A Governança de TI busca
alinhar os processos de negócio, de infra-estrutura, de pessoas e de operações sejam levadas
conforme os interesses da companhia, assim de uma forma estrutura haverá o alinhamento da TI
com a estratégia da empresa.
A Governança em TI auxilia na tomada de decisão e nas questões relevantes com o
propósito de atingir os objetivos de negócio da organização. Em muitas corporações este processo
se inicia pela demonstração dos riscos envolvidos na falta de controle sobre o ambiente de TI.
Assim, foram identificadas cinco áreas de domínios relevantes para as decisões de TI:
Princípios da TI: O papel de negócio da TI;
Arquitetura da TI: Padronização e Integração;
Infra-estrutura da TI: Escopo do suporte e serviços;
Aplicações da TI: Aplicações voltadas ao negocio da empresa; e
Investimento e priorização das demandas da TI: analisar quais e quanto investir.
Com os itens inter-relacionados haverá uma boa governança de TI, correlacionados esses
irão auxiliar nas tomadas de decisões.
9
Mas para se tomar decisões é necessário que haja informações, controles, processos e
procedimentos, todo framework de responsabilidades deve estimular comportamentos desejáveis na
utilização de TI. Hoje quanto mais rápida e precisa for a informação, mais eficaz é a gestão e o
direcionamento da área de TI e do negócio para o sucesso. Todos estes controles, também
estimulam a transparência das instituições para com os seus investidores, mostrando a real aplicação
dos valores e o retorno esperado e o alcançado até o momento. Atualmente a transparência nos
controles e na tomada de decisões é fundamental para uma boa governança.
Internamente, a governança deve desenvolver competências e se adequar ao negócio e
também designar os direitos de decisão nas questões de real valor tendo por fim atingir os objetivos
de negócio. Neste aspecto, a governança em TI se apresenta como uma estrutura bem definida de
relações e processos que controlam e dirigem uma organização dentro de um cenário de extrema
competitividade. O foco é permitir que as perspectivas de negócios, de infra-estrutura, de pessoas e
de operações sejam levadas em consideração no momento de definição do que mais interessa à
empresa, alinhando a tecnologia da informação a essa estratégia.
2.1.2 Framework de Governança de TI
Como em outras áreas da tecnologia há uma série de metodologias para as melhores práticas
e essas auxiliam as empresas na preparação para seguir o modelo de Governança Corporativa de TI.
Cada dessas metodologias possuem um foco específico, e cada empresa segue e customiza para o
seu negócio esse conjunto de melhores práticas. Com a combinação dessas metodologias haverá a
estrutura que é denominada de framework de governança corporativa de TI.
O PDCA significa Plan, Do, Check, Action na linguagem portuguesa significa
Planejamento, Controle, Administração e Realizar. Segundo CAMPOS (1992): a fase P consiste nas
etapas de identificação do problema, observação (reconhecimento das características do problema),
análise do processo (descoberta das causas principais que impedem o atingimento das metas) e
plano de ação (contramedidas sobre as causas principais). A fase D do PDCA de melhoria é a de
ação, ou atuação de acordo com o plano de ação para bloquear as causas fundamentais. Na fase C, é
feita a verificação, ou seja, a confirmação da efetividade do plano de ação para ver se o bloqueio foi
efetivo. Já na fase A existem duas etapas, a de padronização e a de conclusão. Na etapa de
padronização, caso o bloqueio tenha sido efetivo, é feita a eliminação definitiva das causas para que
o problema não reapareça. Na etapa de conclusão ocorre a revisão das atividades e planejamento
10
para trabalhos futuros. A governança corporativa da TI é composto por vários processos, a seguir a
Figura 02 ilustra e também explicação dos processos do framework.
Figura 2. Framework da Governança corporativa da TI.
Fonte: WebInsider
A seguir estarão disponíveis as principais metodologias para a utilização do framework de
governança de TI. A Figura 3 informa a visão níveis como estratégico, controle e execução de
processos, instrução de trabalho.
Figura 3. Relacionamento entre os modelos, padrões e suas áreas de atuação
Fonte: Adaptado de: Project Management University, 2006.
11
Segundo Mansur (2007, p. 21), O Information Technology Infrastructure Libray (ITIL) é um
conjunto de orientações descrevendo as melhores práticas para um processo integrado do
gerenciamento de serviços de TI. Foi desenvolvido pela OGC, United Kingdom`s Office of
Government Commerce, no final dos anos 80, para melhorar o gerenciamento de serviços de TI do
governo da Inglaterra.
ITIL tem foco na operação e na infra-estrutura de TI. Esse modelo serve para monitorar o
desempenho e conjunto de recomendações e melhores práticas de TI para a gestão da infra-estrutura
de TI. A Figura 4 ilustra todos os processos de ITIL, com os níveis gerenciais.
Figura 4. Processos ITIL
Fonte: TI Master.
Segundo Mansur (2007, p. 131): O Capability Matury Model Integration (CMMI) tem como
foco o desenvolvimento e a manutenção de software. O objetivo do CMMI é disponibilizar modelos
para melhorar os processos e habilidades das corporações no desenvolvimento, compra ou
manutenção de produtos e serviços.
O Capability Matury Model Integration mede o grau de maturidade no processo de
desenvolvimento e manutenção de um software. A Figura 5 ilustra todos os processos e estágios de
maturidade de um desenvolvimento de software com a utilização do framework CMMI em cinco
níveis.
12
Figura 5. Amadurecimento do CMMI
Fonte: Software Process Improvement.
O Project Management Boby of Knowlegdge (PMBok) Guide 2000 define o Projeto ―como
um empreendimento temporário com o objetivo de criar um produto ou serviço único. Por ser
temporário, cada projeto possui um início e um fim bem definidos. Pode-se chegar ao fim de um
projeto quando seus objetivos são alcançados ou quando se torna claro que os seus objetivos jamais
serão alcançados‖.
PMBok é um framework onde são estão as principais áreas de conhecimento e as melhores
praticas na área de gerência de projeto. O PMBok também surgiu da necessidade da padronização
de termos na gerência de projetos.
Segundo a NBR ISO 17799:2005, o objetivo da Política é ―prover uma orientação e apoio da
direção para a segurança da informação de acordo com os requisitos do negócio e com as leis e
regulamentos pertinentes‖. Deste modo, a construção da Política de Segurança da Informação do
colégio foi confeccionada após a finalização dos trabalhos, mas obedecendo ao que preconiza a
NBR ISO/IEC 17799, bem como as outras legislações do Exército Brasileiro e a Lei Nº. 3505 –
Política de Segurança da Informação para órgãos do Governo Federal.
13
ISO 17799 é uma norma homologada pelo comitê ISO, são diversos tópicos para a área de
segurança da informação. Contém vários controles e mantém o foco na gestão de riscos, a principal
definição são os códigos de práticas para a gestão da informação, como a confidencialidade,
integridade e disponibilidade.
Para o Brasil, a ABNT publicou ISSO 27002 essa equivalente como norma brasileira NBR
ISO IEC 17799:2005.
O COBIT inclui vários recursos para uma melhor gestão dos recursos de TI como um
sumário executivo, um framework, controle de objetivos, mapas de auditoria, um conjunto de
ferramentas de implementação e um guia de técnicas de gerenciamento. Na Figura 6 está a
metodologia do COBIT. A figura ilustra o ITIL e COBIT na organização da tecnologia da
informação.
Figura 6. Metodologia COBIT
Fonte: Modelagem de Processos Aplicada na Gestão de um Ambiente
Real de TI
Segundo ISACA (Information System Audit and Control Association), o COBIT é editado
pelo ITGI (Information Techology Governance Institute) e aceito internacionalmente como uma boa
prática de controle sobre informações, TI, riscos relacionados. Utiliza-se o COBIT para implantar a
governança de TI e melhorar os controles de TI.
Na Figura 7 expressa onde estão COBIT e ITIL, o COBIT está mais próximo do nível
estratégico e o ITL mais do operacional. A figura ilustra o processo de ITIL e COBIT em níveis
estratégico, tático e operacional.
14
Figura 7. Demonstração COBIT e ITIL.
Fonte: Gestão Estratégica de um Mundo Colaborativo.
O COBIT proporciona um conjunto de práticas internacionais geralmente aceitas e
respeitadas que ajudam os conselhos de diretores, executivos e gerentes a aumentar o valor de TI e
reduzir os riscos correspondentes (ITGI, 2005).
2.2 Lei Sarbanes-Oxley
Em 30 de julho de 2002, o congresso americano aprovou o Ato Sarbanes-Oxley, dos
senadores americanos Michael Oxley e Paul Sarbanes. A legislação federal "The U.S. Public
Company Accounting Reform and Investor Protection Act of 2002", mais conhecida como
Sarbanes-Oxley, apelidada de Sarbox ou ainda de SOX, contém 11 títulos e foca principalmente a
responsabilidade penal da alta administração. Esta lei, que teve como objetivo restabelecer e
aumentar a confiança do investidor e a sustentabilidade das corporações, que afetou a forma como
as empresas de capital aberto passaram a relatar suas operações financeiras, ela foi criada devido a
uma série de escândalos financeiros corporativos onde os investidores perderam a confiança no
mercado de investimento e bolsa de valores dos Estados Unidos.
A Lei SOX veio exigir que as sociedades anônimas (S.A.) públicas dos EUA e respectivas
filiais internacionais que estejam listadas no mercado bolsista NYSE e NASDAQ. Além disso, a
secção 806 da lei SOX prevê medidas de proteção contra ações de retaliação aos empregados que
recorram ao sistema de denúncia de infrações com o intuito de apresentar provas de fraudes
ocorridas em sociedades cotadas na bolsa.
15
A lei Sarbanes-Oxley tem como o principal objetivo garantir a criação de novos métodos de
auditoria confiáveis e segurança no mercado corporativo, também criação de um comitê para
supervisionar esses controles e assim sejam cumpridos. Os controles servem para monitorar
processos e segregar as funções, assim evitar fraudes e quando houver sejam de fácil identificação,
assim é possível uma boa governança corporativa.
A seção 404 dessa lei é uma das mais polêmicas e importantes, pois determina que
anualmente esses controles sejam avaliados por uma equipe independente, ou seja, de auditores.
Esses devem emitir um relatório anual para avaliar se os controles dos comitês estão sendo
efetuados conforme informado pelo comitê interno da Sarbanes-Oxley.
Para melhorar esse controle da Lei SOX, em algumas empresas foi criado um novo
departamento chamado de Controle Interno. Esse departamento serve para reduzir o risco do
controle (RC) a um nível inferior ao máximo, para que haja mais benefícios e diminua o nível de
testes realizados por uma empresa, com a diminuição dos testes haverá uma redução significativa
dos custos de uma organização.
O conhecimento dos aspectos relevantes do Sistema de Controle Interno (SCI), juntamente
com as avaliações do Risco Inerente (RI) e do RC e outras considerações, possibilidade ao
revisor/auditor de:
Identificar os tipos de potenciais distorções materialmente relevantes que possam ocorrer
nas Demonstrações Financeiras;
Considerar fatores que afetem o risco de distorções materialmente relevantes; e
Conceber procedimentos de revisão/auditoria apropriados.
A natureza, extensão, profundidade e oportunidade dos procedimentos que o revisor/auditor
escolhe executar para obter a compreensão do SCI dependerão, entre outros aspectos, de:
A dimensão e complexidade da entidade e do seu sistema informatizado;
Considerações de materialidade;
O tipo de controles internos envolvidos;
A natureza da documentação da entidade sobre os controles internos específicos;
16
A avaliação pelo revisor/auditor quanto ao risco inerente; e
A seleção dos procedimentos a adotar é em função da experiência e do juízo
profissional.
Procedimentos específicos de análise de Controles Internos podem referir, entre outros:
Conferência da exatidão aritmética dos registros;
Manutenção de conciliações;
Rotinas de validação;
Controle de contas e balancetes de verificação;
Aprovação e controle de documentos;
Comparação com fontes externas de informação;
Confronto das contagens de caixa, títulos e existências com os registros contábeis;
Limitação do acesso físico direto aos ativos e registros;
Comparação dos elementos finais obtidos com os orçamentos.
Como forma de compilar todos os procedimentos efetuados bem como concluir sobre os
mesmos, definir a forma como têm impacto nas demonstrações financeiras finais, o auditor deverá
registrar qual o estágio do controle interno bem como a sua evolução ao longo dos anos.
2.2.1 Lei Sarbanes Oxley na TI
A SOX acabou apresentando um enorme impacto sobre a área de Tecnologia da Informação
das organizações ao nível mundial uma vez que se insere a governança corporativa e apresenta
artigos diretamente voltados para a área de TI. Com a lei, rígidos parâmetros legais foram impostos
às companhias de capital aberto e suas respectivas subsidiárias, cujas ações são negociadas em
Bolsas (NYSE e Nasdaq), o que inclui também algumas corporações estrangeiras que negociam
American Depositary Receipts (ADR‘s) não negociáveis no país de origem. No Brasil, essa lei se
aplica às empresas com ações negociadas nos mercados de capitais dos Estados Unidos, ou seja,
multinacionais de capital americano e empresas brasileiras com ações naquele país. No entanto, as
responsabilidades criadas pela lei são de interesse de todas as empresas que queiram se atualizar
sobre práticas de gestão de riscos, que estão entrando em vigor nos Estados Unidos e que, em curto
17
prazo, terão ressonância mundial (Faculdade de Católica de Cuiabá, 2009). A Figura 8 representa o
processo da Lei SOX e controles com os seus frameworks.
Figura 8. Lei SOX e Frameworks
Fonte: Imasters
Como não é possível separar processos de negócios e tecnologia no panorama corporativo
atual, uma avaliação da infra-estrutura operacional e pessoal de TI das empresas é igualmente
requerida. A Seção 404 do Ato Sarbanes-Oxley é o principal foco de atenção das empresas neste
particular, por trazer as determinações sobre os controles de processos internos e sistemas contábeis
da empresa. Esta seção determina uma avaliação anual dos controles e processos internos para a
realização de relatórios financeiros, com a obrigação de emissão de relatório a ser encaminhado à
SEC (Security Exchange Comission - órgão regulador das empresas de capital aberto dos EUA),
uma instituição equivalente à Comissão de Valores Mobilários (CVM) no Brasil, que ateste estes
parâmetros. Este relatório deve conter: (Faculdade de Católica de Cuiabá, 2009)
Atestado de responsabilidade dos administradores da empresa e manutenção da
estrutura dos controles internos e demais procedimentos;
18
Avaliação e relatório de cumprimento de metas, ao final de cada ano fiscal, da eficácia
dos procedimentos internos adotados para emissão de relatórios financeiros;
Declaração que o auditor independente da companhia atestou a avaliação dos
procedimentos elaborada pela administração.
A Lei Sarbanes Oxley serviu para melhorar e assegurar a segurança da informação na
empresa e evitar fraudes nos sistemas informatizados, assim segregar funções, dois importantes atos
são o da segurança da informação de sistemas informatizados e também o controle de registro.
Para Lei Sarbanes Oxley existem dois conceitos utilizados para o controle de acesso, sendo
eles:
Transação Crítica: Toda a transação que pode alterar demonstrativo financeiro e
balanço final da empresa; e
Transação Conflitante: São transações combinadas, duas ou mais transações que um
usuário possua que possa alterar demonstrativo financeiro e balanço final da
empresa.
O conflito surge quando o usuário possui duas transações conflitante, com isso surge a idéia
do conflito.
Neste momento, dois pontos devem ser observados cuidadosamente no que se refere ao uso
dos sistemas de informação inserido no âmbito do Ato Sarbanes-Oxley: (Faculdade de Católica de
Cuiabá, 2009)
Segurança de sistemas de informação - A adequação do conteúdo da SOX deve ocorrer
entre toda a cadeia de comunicação da empresa, principalmente nos recursos
concernentes a informações financeiras. Sistemas de gestão - ERP (Enterprise Resource
Planning), aplicativos contábeis, sistemas de relacionamento com clientes - CRM
(Customer Relationship Management), Sistemas de gerenciamento de cadeia de
suprimentos (Supply Chain Management), em conjunto com as demais aplicações de
comunicação, banco de dados e armazenamento de informações precisam estar em
sintonia com as regras adotadas na legislação. Consequentemente, a atenção do
administrador deve se estender à utilização de todo e qualquer recurso tecnológico da
19
empresa por parte dos funcionários e as políticas de segurança da informação adotadas
devem ser adaptadas ao teor do Ato Sarbanes-Oxley. Uma atenção especial também
deve ser conferida a terceirização (outsourcing) de serviços;
Controle de registros - Um arquivo de registros de procedimentos é fundamental para a
tranqüilidade dos administradores. Estes registros devem ser tanto tangíveis (em papel)
ou intangíveis (arquivos digitais e demais mídias) e a redundância em sistemas de
backup é altamente recomendada. No bojo da lei encontram-se disposições que
penalizam severamente a falsificação, destruição e perda de documentos e registros, bem
como prevêem a observação de prazos para seu armazenamento após o fechamento de
cada exercício fiscal.
2.3 Pesquisar e analisar soluções similares
Para esse tópico foram avaliados os sistemas os sistemas VIRSA e AutoSeg. Atualmente no
mercado possui poucas soluções de mercado, com isso nos possibilita a criação de uma nova
ferramenta a baixo custo, acessível a qualquer empresa do mundo, que tenha inicialmente idioma
base português.
2.3.1 Virsa Compliance Cablibrator
O Virsa System é um sistema da SAP e se concentra nos controles do usuário e acesso, esse
possui o monitoramento de transações críticas. Esse sistema por ser da SAP é totalmente integrado
ao sistema ERP e possui um gerenciamento dos recursos de controle interno. Ele possui também a
segregação a funcionalidade de segregação de função.
O sistema auxilia na avaliação de riscos e de segregação de funções, simula a inclusão de
uma transação em uma função, assim verifica se haverá risco ou não para a empresa. Esse sistema é
um módulo do SAP.
O Virsa Compliance Calibrator se concentra nos controles do usuário e de acesso, incluindo
o monitoramento de transações críticas em toda a extensão do sistema. Esta solução está totalmente
integrada ao SAP ERP e complementa o sistema de informações da auditoria e o gerenciamento dos
recursos de controle interno. Ele combina a experiência da SAP em segurança com um abrangente
20
conjunto de normas devidamente validadas, além de uma detalhada análise da segregação de
funções (SOD – segregation of duties), em forma de uma solução abrangente para os artigos 404 e
409 da Lei Sarbanes-Oxley (SAP, 2009)
Segundo SAP, 2009: Os principais benefícios do Virsa Compliance Calibrator para as
empresas incluem:
Verificação imediata e ampla da conformidade de autorizações do ERP;
Análise automática da segregação de funções (SOD) e monitoramento de transações
críticas;
Avaliação imediata dos riscos de autorização para os usuários, auditores e profissionais
de segurança da área de TI;
Bloqueio das violações, antes que estas comprometam a produção;
Correções rápidas, com verificação direta das causas que ocasionaram o problema;
Impossibilidade de análise manual e de falso-positivos; e
Integração transparente com o SAP ERP, dispensando manutenção adicional de
servidores ou dados.
2.3.2 AutoSeg
O sistema AutoSeg um sistema para auxílio na segregação de funções, e esse possui conexão
ao SAP assim tornando a aplicação mais simples e sem necessidade de um serviço para conexão ou
até mesmo importação de dados para o sistema.
O sistema possui definição dos Processos Críticos, definição da tabela de segregação de
funções (Combinações de Processos), identificação das ocorrências de conflitos de processos na
base de perfis de acesso, identificação das ocorrências de conflitos de processos na base de
usuários, análise dos conflitos de processos e simulação de atribuições para a manutenção dos
controles de acesso.
A seguir serão informados os módulos de controle de autorizações do sistema AutoSeg:
(AutoSeg, 2009)
21
Análise completa de autorizações críticas:
Fornece um raio-x do estado atual das atribuições de autorizações críticas e de
Segregação de Funções.
Revisão de atribuição de autorizações críticas:
Lista detalhada de usuários que possuem as principais autorizações críticas incluindo os
perfis de acesso envolvidos.
Revisão por Segregação de Funções:
Lista detalhada de Combinações Críticas de acessos listadas por usuários e organizadas
por usuários ou Processos de Negócio.
Manutenção de regras de aprovação para atribuição de autorizações e Segregação de
Funções:
Ferramentas de simulação de inclusão de criticidades em um usuário ou em um perfil de
acesso e fluxo de aprovação de conflitos de Segregação de Funções; e
Histórico detalhado para documentação de evidências de aprovação de acessos a
autorizações críticas e a conflitos de Segregação de Funções.
2.3.3 Comentários sobre as soluções similares
Os sistemas analisados estão há um tempo no mercado e estáveis, como não há muitos no
mercado foi verificada a necessidade da criação de um sistema para segregar funções e agregar
conhecimento acadêmico.
2.4 Ferramentas de desenvolvimento
O sistema de análise de acessos críticos será integrado com o SAP - ERP e utilizará o
conceito de workflow, a linguagem será o JAVA e o banco de dados será o PostgreSQL Server. A
seguir estarão as informações sobre o sistema.
22
2.4.1 SAP
O SAP é uma empresa alemã criadora do software de gestão de negócios, a empresa possui
o software com o mesmo nome.
O aplicativo SAP ERP — incluído no SAP Business Suite — é um software integrado de
planejamento de recursos corporativos, de qualidade mundialmente reconhecida, destinado a
atender aos principais requisitos de software das mais exigentes empresas de médio e grande porte,
de todos os setores e mercados verticais, em qualquer país do mundo. O software SAP ERP é
constituído de quatro soluções individuais que sustentam as principais áreas funcionais das
organizações. (SAP, 2009)
O sistema de gestão integrada SAP ERP (Enterprise Resource Planning), essa é líder no
seguimento de software. O SAP é dividido em vários módulos: vendas e distribuição, recursos
humanos, financeiro, controle de qualidade, planejamento de produção e outros.
2.4.2 Metodologia de Desenvolvimento
A metodologia para o desenvolvimento será utilizado todo o trabalho de pesquisa realizado
nesse semestre, com o principal foco o projeto realizado em UML. Será desenvolvido e realizado e
documentado os testes realizados.
Segundo Martins (2009, p.169): A Unified Modeling Language (UML) é uma linguagem
padrão para documentar projetos de software. A UML pode ser utilizada para visualizar,
especificar, construir e documentar os elementos de um sistema baseado em software. A UML é
concebida para modelar sistemas dos mais variados tipos: sistemas de tempo real, sistemas
distribuídos baseados na web, sistemas de informação e outros.
A UML auxilia no desenvolvimento de projetos a fim de evitar problemas, é utilizada para
criação de projetos, desde sistemas sem comunicação até mesmo nos distribuídos na internet.
Segundo Martins (2009, p.169): Os relacionamentos são as associações entre coisas e podem
ser de quatro tipos diferentes: dependência, associação, generalização e agregação.
A UML irá definir a infra-estrutura técnica para desenvolvimento do software, com base nos
casos de uso, auxiliar na criação dos requisitos do sistema e banco de dados.
23
2.4.3 Linguagem de Programação
A tecnologia Java é uma plataforma de computação inovadora lançada pela Sun
Microsystems. Inicialmente denominada OAK, essa linguagem de programação foi rebatizada como
Java em 1995 (JAVA, 2009).
O Java permite executar praticamente todos os aplicativos - como jogos, ferramentas,
programas e serviços de informações - na maioria dos computadores e dispositivos. Hoje a
tecnologia Java pode ser encontrada em quase todos os dispositivos: de desktops a dispositivos
móveis portáteis e telefones celulares (JAVA, 2009).
A linguagem de programação é JAVA, devido a sua portabilidade.
2.4.4 Banco de Dados
De acordo com Santos (2006), banco de dados é um conjunto de dados, que tipicamente
descreve as atividades de uma ou mais organizações que se encontrem relacionadas. .Sistema de
Banco de Dados serve para gerenciar grandes quantidades de informações e esse envolve uma
estrutura para armazenamento da informação como a provisão de mecanismos para manipulá-la.
Em adição, o sistema de banco de dados deve proporcionar a segurança das informações
armazenadas no banco de dados, mesmo em casos de queda no sistema ou de tentativas de acessos
não autorizados. São Ambientes de apoio ao reuso de software, necessitam de recursos de
armazenamento e manipulação de diversos tipos de componentes ligados ao Desenvolvimento
Baseado em Componentes. Sendo assim, um Sistema de Gerência de Bases de Dados (SGBD)
surge como uma solução mais indicada. Entretanto, o modelo de representação relacional não se
mostra adequado, pois é deficiente quanto ao poder de representação de relacionamentos complexos
e de herança, por exemplo. Tais restrições não ocorrem em SGBDs com capacidade de
representação do modelo de objetos.
O PostgreSQL é um sistema gerenciador de banco de dados objeto-relacional de código
aberto. Tem mais de 15 anos de desenvolvimento ativo e uma arquitetura que comprovadamente
ganhou forte reputação de confiabilidade, integridade de dados e conformidade a padrões. Roda em
todos os grandes sistemas operacionais, incluindo GNU/Linux, Unix (AIX, BSD, HP-UX, SGI
IRIX, Mac OS X, Solaris, Tru64), e MS Windows. É totalmente compatível com ACID, tem
suporte completo a chaves estrangeiras, junções (JOINs), visões, gatilhos e procedimentos
24
armazenados (em múltiplas linguagens). Inclui a maior parte dos tipos de dados do ISO SQL:1999,
incluindo INTEGER, NUMERIC, BOOLEAN, CHAR, VARCHAR, DATE, INTERVAL, e
TIMESTAMP. Suporta também o armazenamento de objetos binários, incluindo figuras, sons ou
vídeos. Possui interfaces nativas de programação para C/C++, Java, .Net, Perl, Python, Ruby, Tcl,
ODBC, entre outros, e uma excepcional documentação. (PostgreSQL, 2009).
A MySQL AB, adquirida pela Sun Microsystems, que por sua vez foi adquirida pela Oracle,
é a empresa que desenvolve, suporta e comercializa o banco de dados MySQL em todo o mundo.
Nossa missão é criar um banco de dados superior, que contribua para aplicações de missão crítica,
com altos volumes e que esteja disponível e acessível a todos. Nós criamos nosso produto e
disponibilizamos a custo zero sob a licença GPL (GNU General Public License), ou sob uma
licença comercial para quem pretende não seguir os termos da GPL. (MySQL, 2009).
Atualmente o MySQL é o servidor de bancos de dados de código aberto mais popular do
mundo, com mais de 70 milhões de instalações entre websites, datawarehouses, aplicações
comerciais e outras mais. Empresas como Yahoo! Finance, MP3.com, Motorola, NASA, Silicon
Graphics, Texas Instruments, Google e Amazon.com usam o MySQL em aplicações de missão
crítica (MySQL, 2009).
Para gerenciar melhor as informações, e viabilizar as informações da melhor maneira será
utilizado um banco de dados, com a idéia de minimizar custos será utilizado um banco de dados
open source, serão analisados dois bancos de dados MySQL e PostgreSQL. Conforme analisado na
internet foi localizado a tabela apresentada pela DBExperts, como é mostrado na Tabela 1.
25
Tabela 1. Comparação entre PostgreSQL e MySQL.
PostgreSQL MySQL
Voltado para qualquer tipo de aplicações, página
simples web ou sistema administrativo completo.
Voltado para página web com algum tipo de
acesso ao banco de dados.
Excelente velocidade com total suporte a
transações atômicas e integridade referencial.
Não tem transações, integridade referencial nos
tipos de tabelas padrões. Quando usado com
tabelas Berkeley DB possuem um sistema
rudimentar de transações, mas neste caso torna-
se muito lento.
Permite a criação de tipos de dados, funções
pelos usuários em diversas linguagens entre elas:
SQL, PgSQL, Perl, Pyton, Tcl e C.
Não possui integridade referencial.
Modelo objeto-relacional. Não é orientado a objetos.
Permite herança de tabelas. Não possui stored procedures.
Fonte: DBExperts (2009).
Conforme analisado para o desenvolvimento dessa linguagem será utilizado o banco de
dados PostgreSQL, permite várias funcionalidades que o MySQL não possui.
26
3 PROJETO
Nesse capítulo é apresentada a análise de requisitos, os diagramas de casos de uso, diagrama
de classes e os protótipos de tela utilizados para a construção do Sistema de análise de conflitos e
transações críticas.
Foram analisados os dados para a criação desse projeto junto com dois analistas da área de
controles internos de uma empresa alimentícia. O perfil são dois técnicos que analisam os perfis de
acesso. Foi realizada uma discussão, criado um fluxo e também o diagrama de caso de uso. Para
isso foi discutido o processo de fluxo de trabalho (workflow), os acessos conflitantes, de acordo
com cada responsabilidade.
A base de dados desse sistema é alimentada através do sistema SAP, que fornecerão as
transações, usuários e perfis de acesso. Essa consulta é feita utilizando Remote Function Call
(RFC), onde o sistema externo montará os dados em uma estrutura e encaminhará para o SACTC
analisar e atualizar em sua base de dados.
3.1.1 Sistema de Análise de Conflitos de Transações Críticas
O sistema de análise de conflitos de transações críticas irá verificar os eventuais conflitos
que um usuário possui. O processo é iniciado quando um usuário possui necessidade de um novo
acesso. Quando necessário um novo acesso, é solicitado para uma área avaliar e essa área irá utilizar
o sistema de análise de conflitos de transações críticas. Para essa solicitação de um novo acesso é
necessário solicitante informar o usuário e o novo acesso no SAP. O operador do sistema informa o
usuário e o novo acesso no SAP, com isso é iniciado o processo de análise de conflitos no SACTC,
o sistema consulta sua base de dados e avalia os acessos conflitantes e quando houver conflitos é
incluído em sua base de dados.
Na Figura 9 é apresentado o fluxograma que ilustra todo o processo. Vale ressaltar que o
sistema SACTC auxilia na realização de uma parte desse processo.
27
Figura 9. Fluxograma do sistema SACTC
Tabela 2. Comparação entre Sistemas.
Funcionalidades AutoSeg Virsa Calibrator SACTC
Verificação da conformidade de autorizações do ERP X X X
Análise automática da segregação de funções (SOD) e monitoramento de transações críticas X X X
Avaliação imediata dos riscos de autorização para os usuários, auditores e profissionais de segurança da área de TI X X X
Integrado ao SAP X X X
Single-Sign On integrado X X
Na tabela 2, existe a comparação entre as funcionalidades do sistema AutoSeg, Virsa
Calibrator e SACTC. Nos aspectos gerais o sistema somente não contempla o Single-Sign On, ou
seja, um login único no sistema.
28
3.2 Análise de Requisitos
Segundo Paula Filho (2001), afirma que requisitos são características que definem os
critérios de aceitação de um produto. A análise de requisitos tem por finalidade colocar nesses
produtos as características, ou seja, os requisitos.
Segundo Conallen (2003), uma especificação de requisitos é um conjunto de componentes,
tais como documentos, registros de bancos de dados, modelos que descrevem um sistema de
software a ser criado sem ambigüidade.
A análise de requisitos foi realizada com o objetivo de identificar o escopo do projeto e
definir as funcionalidades que o sistema disponibilizará. Na análise, os requisitos funcionais, os não
funcionais e as regras de negócio foram citados, documentados e analisados. As seções seguintes
apresentam o resultado desse trabalho.
3.2.1 Requisitos Funcionais
Os requisitos funcionais descrevem o funcionamento do sistema e abrangem as tarefas que
ele disponibilizará aos usuários. Para maior entendimento e dimensão do sistema, os requisitos
funcionais foram divididos em módulos: conflitos, segregação de funções. Na etapa de análise os
seguintes requisitos funcionais foram identificados:
Conflito
RF01: O sistema permite criar, alterar e inativar um novo conflito;
RF02: O sistema permite incluir, remover uma transação do conflito;
RF03: O sistema permite incluir, remover um aprovador do conflito;
RF04: O sistema permite o período que será executado o workflow;
RF05: O sistema permite incluir, remover uma transação do conflito;e
RF06: O sistema permite incluir, remover um aprovador do conflito.
Segregação de funções
RF01: O sistema permite visualizar e remover um usuário da base de conflitos;
RF02: O sistema atualiza a base de conflitos;
29
RF03: O sistema verifica as não conformidades, os conflitos modificados, na base; e
RF04: O sistema verifica na base de transações do SAP e identifica se há uma nova
transação.
3.2.2 Requisitos Não Funcionais
Para Kotonya e Sommerville (1997), definem requisitos não funcionais como qualidade total
ou atributos do sistema resultante. Os requisitos não funcionais servem de base para que os
requisitos do usuário sejam definidos da melhor forma.
Os requisitos não funcionais especificam as características do software, neste caso, a
linguagem de programação, o banco de dados e a plataforma utilizados.
RNF01: O sistema é desenvolvido em desktop e integrado no SAP;
RNF02: O sistema é desenvolvido na linguagem Java;
RNF04: O sistema utiliza o Banco de Dados PostgreSQL;
RNF05: O sistema é integrado com o SAP;e
RNF06: Conforme solicitação do usuário, as telas não são do tamanho do desktop.
3.2.3 Regras de Negócio
As regras de negócio definem as particularidades do funcionamento da ferramenta:
RN01: O sistema encaminha mensagens para os usuários que possuem conflitos ativos;
RN02: O sistema sempre verifica se há novas transações;
RN03: O sistema informa o conflito; e
RN04: O sistema recebe as transações e usuários do sistema.
3.3 Diagrama de Casos de Uso
O Diagrama de Caso de Uso representa as funcionalidades do ponto de vista do operador do
sistema. A seguir serão apresentados os módulos que irá compor o sistema desse projeto e a
descrição detalhada esta no apêndice A.
30
3.3.1 Módulo Conflito
Esse permite ao usuário efetuar a manutenção no módulo de conflitos, sendo ―Criar
Conflitos‖ e atribuir transações em conflitos. A Figura 10 ilustra este caso de uso.
Figura 10. Diagrama de Casos de Uso do Módulo Conflito
3.3.2 Módulo Analisa Acesso
Esse módulo de permite efetuar a manutenção e análise no módulo de segregação de funções
no sistema. A Figura a 11 ilustra este caso de uso.
31
Figura 11. Diagrama de Casos de Uso do Módulo Segregação de Funções
3.4 Diagrama de Classes
Nesta seção o diagrama de classes de domínio para o sistema é apresentado. A Figura 12
descreve as principais classes envolvidas juntamente com o relacionamento com outras classes.
Figura 12. Diagrama de Classes
O sistema é integração com o SAP, essa integração será efetuada via carga de dados
conforme item UC 02.03 (em anexo no apêndice), com as transações que há no sistema SAP e irá
verificar os acessos do usuário, para analise das não conformidades como há descrição nesse
projeto.
32
3.5 Interfaces do Sistema
O protótipo de interface tem como objetivo apresentar uma visão geral da interface do
sistema. O protótipo de interfaces sofreram poucas modificações do TCC I, devido a algumas
funcionalidades adicionadas no sistema.
A Figura 13 é apresentada a tela inicial do sistema de análise de conflitos, onde o usuário
possui as funcionalidades iniciais do sistema.
Figura 13. Tela para manutenção de conflitos (TEL001)
A Figura 14 é o processo de manutenção de conflitos na base de dados do sistema.
33
Figura 14. Tela para manutenção de conflitos (TEL002)
A Figura 15 é o processo de inclusão de transações e aprovadores em um conflito, esse
servira para a base de análise de conflitos.
Figura 15. Tela de conflitos (TEL003)
A Figura 16 serve para identificar os usuários cadastrados no SAP, via o sistema de analise
de conflitos.
34
Figura 16. Tela de procura usuário (TEL004)
A Figura 17 são os conflitos que um usuário possui e também é possível a remoção do
usuário da base de conflitos.
Figura 17. Tela para manutenção de usuário SOX (TEL005)
A Figura 18 é tela de análise de perfis de acesso do usuário e informa os novos conflitos
gerados pelo novo acesso ao sistema.
35
Figura 18. Tela de Analise de conflitos (TEL006).
A Figura 18 é tela de análise de perfis de acesso do usuário e informa os novos conflitos
gerados pelo novo acesso ao sistema.
A seguir as telas de relatórios gerados pelo sistema SACTC. Essas telas foram geradas para
o navegador Internet Explorer, porém, para melhor visualização foram recortadas. Os relatórios são:
Estatísticas com os dados do sistema (Figura 19);
Todos os conflitos cadastrados no sistema (Figura 20);
Relatório com todos os usuários do sistema (Figura 21);
Relatório com todos que estão na base de conflitos por conflitos gerado pelo sistema (Figura
22); e
Relatório com todos os usuários que não possuem conflitos (Figura 23).
Figura 19. Tela de para análise de dados do sistema.
36
Figura 20. Tela de relatório de conflitos.
Figura 21. Tela de relatório de usuários.
37
Figura 22. Tela de relatório de usuários com conflitos.
Figura 23. Tela de relatório de usuários sem conflitos.
38
Figura 24. Tela de não conformidades.
3.6 Metodologia
A implementação dos processos utilizada à linguagem JAVA, e deve seguir a Análise e
Projeto realizados. No código há comentários, para facilitar a análise e atualização.
3.6.1 Análise de Riscos
Como trata-se de uma solução com integração com SAP ou integração de arquivos, foram
necessários vários testes e também a viabilidade da utilização desse sistema em tempo online.
3.7 Implementação
39
Com base na análise dos requisitos, diagrama de casos de usos, modelagem do banco de
dados e protótipos de interfaces que foram desenvolvidos durante a primeira etapa do trabalho de
conclusão de curso, procedeu-se uma revisão e validação com os responsáveis pelas atividades de
análise de conflitos na empresa.
Para a implementação do projeto utilizou-se seguintes ferramentas: 1) Para o
desenvolvimento do SACTC foi utilizado NetBeans IDE 6.5.1 que auxiliou a criação do sistema em
JAVA, conforme estudo realizado para a linguagem de programação no item 2.4.3 Linguagem de
Programação deste trabalho. 2) O Sistema Gerenciador de Banco de Dados utilizado foi o
PostgreSQL 8.4, o gerenciador foi escolhido com base na pesquisa realizada no item 2.4.4 Banco de
dados. Para criar e popular o banco de dados da aplicação, necessário para o desenvolvimento e
testes, foi utilizado o pgAdmin III 4.2.2. 3) Dreamweaver MX 2004: o programa foi utilizado para o
desenvolvimento das interfaces dos relatórios que foram gerados pelo sistema SACTC. 4) Para
auxiliar a integração e simulação do sistema SAP foi criado um ambiente virtualizado do servidor
SAP, para essa virtualização foi utilizado o Microsoft Virtual PC sendo instalada a base de dados e
sistema MiniSAP, onde essa versão é utilizada para testes de estudantes. 5) Para criação de usuários
no SAP foi utilizada a ferramenta SAPlogon, esse programa é utilizado para efetuar conexões no
sistema SAP no modo diálogo. Nesse modo é possível a criação de usuários, alteração de perfis de
acesso e configurações do sistema.
Para efetuar as consultas dos usuários cadastrados no sistema MiniSAP foi utilizada uma
conexão chamada Remote Function Call (RFC). Essa conexão não atualiza a base de dados do SAP
e com isso mantém integridade dos dados do sistema.
3.8 Validação do Sistema
Para a validação do Sistema de Análise de Conflitos com Transações Criticas (SACTC), foi
utilizada uma equipe com conhecimento de técnico na área de Controles Internos de uma grande
empresa no ramo alimentício, situada na cidade de Itajaí – SC, os testes foram realizados utilizando
o sistema SAP, onde foi possível realizar todos os testes do sistema neste ambiente.
Inicialmente os testes foram feitos a partir das funções do sistema de manutenção de dados e
analise da conexão com o SAP, testes como análise de conflitos, armazenamento de informações
nas bases de dados, criação de conflitos, verificação de novos conflitos e a rotina de análise de
conflitos gerada conforme solicitado e no contexto geral. O sistema funciona perfeitamente.
40
Para a execução do sistema foi necessário a utilização de uma maquina virtual Java e o
computador estar em rede, devido à conexão utilizada no sistema.
Nesta seção serão vistos alguns resultados já obtidos com a utilização do protótipo, bem
como algumas características importantes do mesmo. Serão mostradas as impressões dos usuários
em relação à utilização da ferramenta, o fluxo dos conhecimentos dentro do protótipo, o mapa de
competências, os ranking's existentes e os resultados organizacionais que podem advir com a
utilização do protótipo.
3.8.1 Performace
Referente à performace não foi testado em um ambiente com muitos usuários, transações e
perfis com o nosso ambiente de teste não verificamos lentidão.
3.8.2 Verificação junto ao Público Alvo
Após explicar as funcionalidades do sistema para o público alvo (definições na seção
seguinte) foi solicitado ao publico alvo realizar testes no sistema os testes abaixo:
Manutenção de conflitos: Todo o conflito do sistema é cadastrado nesse modulo, onde o
usuário especifica o controle e o risco existente;
Manutenção de uma transação em um conflito: Toda a transação é incluída para um
conflito nesse módulo; e
Verificação conflitos de um usuário: análise de conflitos de um usuário, onde o operador
informa quais conflitos o usuário possuirá após a inserir o acesso;
A seguir estarão os testes realizados no sistema de análise de conflitos com transações
críticas, onde foram realizados por dois colaboradores de uma grande empresa alimentícia de Santa
Catarina.
3.8.2.1 Manutenção de Conflitos
Após explicar a funcionalidade de manutenção de conflitos foi solicitado ao público testar e
com isso os resultados que foram obtidos estão abaixo. Foi inserido um novo conflito para testes do
SACTC e teste efetuado com sucesso, assim como suas respectivas alterações nesse modulo.
41
Segundo Loismei Lima Nascimento (responsável pela análise de conflitos da área de
controles internos de uma empresa alimentícia de grande porte) foi criado um conflito de
segregação de vendas e incluída a descrição do conflito, descrição do código do controle de
descrição do controle:
Figura 25. Tela de Manutenção de Conflitos
Segundo Leandro Cucker de Souza (responsável pela liberação de acessos na área de
controles internos de uma empresa alimentícia de grande porte), foi criado um conflito de
segregação de vendas e incluída a descrição do conflito, descrição do código do controle de
descrição do controle:
Figura 26. Tela de Manutenção de Conflitos
42
3.8.2.2 Manutenção de uma transação em um conflito
Após explicar a funcionalidade de manutenção de uma transação em um conflito foi
solicitado ao público testar e com isso os resultados que foram obtidos seguem abaixo. Foi inserida
uma transação em um conflito para testes do SACTC e teste efetuado com sucesso, assim como
suas respectivas alterações nesse modulo.
Segundo Loismei Lima Nascimento, foi solicitada a inclusão de transações e usuários
aprovadores na base de conflitos:
Figura 27. Tela manutenção de transação em um conflito
Segundo Leandro Cucker de Souza foi solicitada a inclusão de transações e usuários
aprovadores na base de conflitos:
Figura 28. Tela manutenção de transação em um conflito
3.8.2.3 Verificação conflitos de um usuário
Após explicar a funcionalidade da verificação de conflitos em um usuário foi solicitado ao
publico testar e com isso os resultados que foram obtidos estão abaixo. Foi inserida uma transação
em um conflito para testes do SACTC e teste efetuado com sucesso, assim como suas respectivas
alterações nesse modulo.
43
Segundo Loismei Lima Nascimento, nesse processo foi solicitado excluir um usuário da
base de conflito:
Figura 29. Tela verificação conflitos de um usuário
Segundo Leandro Cucker de Souza, nesse processo foi solicitado excluir um usuário da base
de conflito:
Figura 30. Tela verificação conflitos de um usuário
3.8.2.4 Verificação das não conformidades
O processo de não conformidade do sistema, que serve para verificar novos conflitos e
novas transações, foi executado com sucesso e nesse módulo foi criada uma tela para auxiliar a
verificação das não conformidades do sistema. Esse módulo também serve para carregar as
informações no sistema SACTC, após o processo de integração e os dados foram incluídos com
sucesso na base de dados de usuários, transações e conflitos. Esse módulo é fundamental para o
sistema de análise de conflitos, pois nesse irá carregar no sistema e avaliar as não conformidades e
evitar futuras fraudes de processos. A Figura 31 é um exemplo da tela de avaliar as não
conformidades do sistema, onde pode ser escolhido por: transação, usuário e conflitos.
44
Figura 31. Tela verificação de não conformidades
3.8.2.5 Comentários
Segundo comentários da Srta. Loismei Lima Nascimento e Sr. Leandro Cucker de Souza, os
responsáveis pelos testes do sistema, foi solicitado como trabalho futuro à criação de relatórios
gerenciais, a fim de detalhar, quando necessário, os usuários com acessos críticos nesse sistema.
Como sugestão nos relatórios, expandir os usuários que possuem acesso a transações crítica, criação
de um log de segurança para validar dados de liberações dos acessos.
45
4 CONSIDERAÇÕES FINAIS
O compromisso inicial deste projeto se propôs a apresentar uma solução para a segregação
de funções em acessos ao sistema SAP R/3. Com a validação do protótipo, outras empresas poderão
utilizar o sistema para fins de segregação de função e análise de conflitos a um baixo custo com a
utilização do conceito de governança corporativa.
Após o estudo da governança corporativa de TI e Lei SOX, agregou e muito valor final do
trabalho proposto, com o conhecimento nas soluções similares, auxiliou no processo da criação do
sistema, com base no escopo e requisitos de sistema.
Com base na modelagem do projeto SACTC, foi possível criar o sistema proposto nesse
projeto, auxiliou com o conhecimento obtido no curso ciência da computação, o sistema foi
verificado, por dois integrantes de uma grande empresa alimentícia. Todos os processos foram
analisados e documentados no sistema.
Além de atingir os objetivos propostos, o projeto irá fornecer uma facilidade às empresas até
para as que não fazem parte da Lei SOX, assim poderão garantir uma segurança maior nas
informações organizacionais.
O objetivo desse trabalho é que toda empresa possa utilizar esse sistema a um baixo custo e
aumentar o controle na segurança da informação.
Uma contribuição para o mundo acadêmico, principalmente para a computação, é despertar
o interesse na área de gestão de TI, sendo governança corporativa e controlar riscos de sistemas.
A contribuição pessoal que ao término desse projeto foi conhecer melhor os processos de
governança corporativa de TI e a Lei Sarbanes-Oxley, com o grande impacto que há na área da TI.
4.1 Dificuldades encontradas
As principais dificuldades com as quais se deparou durante a execução deste trabalho
estiveram relacionadas com a elaboração da conexão ao SAP, devido a um conflito em uma DLL da
integração com o sistema SAP. Essa dificuldade foi superada, o erro estava em uma biblioteca no
diretório C:\Windows\System32 nos arquivos: librfc32.dll e sapjcorfc.dll.
46
Dificuldades também para tratar os dados recebidos do SAP. Foram encontradas para a
utilização do Swing (classe do Java para a criação de aplicações gráficas) no Java. Essa dificuldade
foi superada, após muitos estudos sobre a utilização da classe Swing do Java.
4.2 Trabalhos Futuros
Ao concluir este trabalho acadêmico, foi possível constatar, através da implantação e estudo
dos resultados, sua importante contribuição para as atividades de análise e gestão de acessos críticos
de uma empresa, agregando mais agilidade e segurança aos processos.
Contudo, identificaram-se possíveis aperfeiçoamentos ao sistema, com o intuito de torná-lo
mais abrangente e contributiva. Dentre eles, podem ser citados:
Criação de novos relatórios para acompanhamento e gestão das atividades e
liberações de acessos ao sistema;
Criação de um processo de analise das trilhas de auditorias do sistema na integração;
Criação de um sistema de workflow, que permita a automatização das atividades de
detecção e aprovação dos conflitos diretamente na base de dados do sistema;
Trabalhar na incorporação de novos indicadores à base de conhecimento e aos
algoritmos de mineração de dados; e
Processo de revisão da base de conflitos periodicamente, sempre ser encaminhada
uma mensagem ao responsável pelo conflito.
47
REFERÊNCIAS BIBLIOGRÁFICAS
AUTOSEG. AutoSeg. Disponível em: <http://www.autoseg.com/dl/AP01.pdf>. Acesso em: 26 de
maio de 2009.
BNDES. Governança Corporativa. Disponível em:
<http://www.bndes.gov.br/conhecimento/revista/rev809.pdf>. Acesso em: 26 de maio de 2009.
BOVESPA 2009. Empresas do Novo Mercado 2009. Disponível em:
<http://www.bovespa.com.br/Empresas/NovoMercadoNiveis/NovoMercado.asp>. Acesso em: 14
de abril de 2009.
CAMPOS, André. Sistemas de segurança da informação: controlando riscos. Florianópolis:
Visual Books, 2007.
CAMPOS, V.F. TQC: Controle da Qualidade Total (no Estilo Japonês). Belo Horizonte:
Fundação Christiano Ottoni, 1992. (Rio de Janeiro;.)
CAMURUGY, Patrícia. Planejamento e Carreira. Disponível em:
<http://webinsider.uol.com.br/index.php/2007/06/13/ontem-ilhas-funcionais-hoje-frameworks/>.
Acesso em: 10 de julho de 2009
CAMURUGY, Patrícia. TI Master. Disponível em:
<http://www.timaster.com.br/revista/artigos/main_artigo.asp?codigo=1113>. Acesso em 10 de
julho de 2009.
COMUNIDADE BRASILEIRA DE POSTGRESQL. Sobre o PostgreSQL. Disponível em:
<http://www.postgresql.org.br/sobre>. Acesso em: 19 de maio de 2009.
CONALLEN, Jim. Desenvolvimento de aplicações Web com UML. Rio de Janeiro: Campos,
2003.
Congresso Anual de Tecnologia de Informação, 2004, São Paulo. ―Tecnologia da Informação na
Governança do Sistema Financeiro Nacional (SFN)”. São Paulo: Centro de Informática Aplicada
da Escola de Administração de Empresas de São Paulo da Fundação Getulio Vargas
COSTA, Luciana. O que é Lei Sarbanes-Oxley e quais os impactos na TI. Disponível em:
<http://www.imasters.com.br>. Acesso em: 26 de maio de 2009.
DBEXPERTS. PostgreSQL x MySQL. Disponível em: <http://www.dbexperts.com.br/
documentos/mysql>. Acesso em: 15 de maio de 2009.
FACULDADE CATÓLICA DE CUIABÁ. Sarbanes-Oxley e o Impacto sobre a Governança de
TI. Disponível em:
<http://www.macmt.com.br/catolica/Sox%20na%20Governan%C3%A7a%20de%20TI.pdf>.
Acesso: em 14 de junho de 2009.
FERREIRA Rafael G.; RALHA, Célia. Modelagem de Processos Aplicada na Gestão de um
Ambiente Real de TI. Disponível em:
<http://www.unb.br/ceam/neorg/sos/sos5/arquivos/825pdf.pdf>. Acesso em 01 de junho de 2009
48
FILHO, José. A importância do controle interno na administração pública, Disponível em:
<http://www.ufpi.br/parnaiba/revista/ed1ano1/artigo6_antoniofilho.pdf>. Acesso em: 13 de abril de
2009
HAMAKER, STACEY; HUTTON, AUSTIN. CISA, Principles of IT Governance, Information
Systems Control Journal, vol. 2, 2004.
HARDY, G. Using IT governance and COBIT to deliver value with IT and respond to legal,
regulatory and compliance challenges. Information Security Technical Report. Elsevier, 2006,
p. 55-61.
ISACA. Informações Gerais. Disponível em: <http://www.isaca.org.br/>. Acessado em: 23 de
maio de 2009
ITGI, IT Governance Institute. Control Objectives, Management Guidelines, Maturity
Models. ISACF, Information Systems Audit and Control Foundation. CobiT 4rd Ed., 2005.
JAVA. Sobre o JAVA. Disponível em:
<http://www.java.com/pt_BR/download/faq/whatis_java.xml>. Acesso em: 25 de maio de 2009
KOTONYA, Gerald. SOMMERVILLE, Ian. Requeriments engeneering: process and techniques.
Chichester: John Wiley & Sons, 1997.
LAUDON, Kenneth e LAUDON, Jane. Sistemas de informação gerenciais. São Paulo: Pearson
Education do Brasil, 2007
MANSUR, Ricardo. Governança de TI. São Paulo: Brasport, 2007. PROJECT MANAGEMENT
INSTITUTE. A Guide to the Project Management Body of Knowledge (PMBOK Guide):
Edição 2000.
MARTINS, José Carlos Cordeiro. Gerenciando projetos de desenvolvimento de software com
PML, RUP e UML. Rio de Janeiro: Brasport, 2007.
MEYER, Mário. Gestão Estratégica de um Mundo Colaborativo. Disponível em:
<http://www.meyer.eti.br/ >. Acesso em: 02 de junho de 2009.
MYSQL. Sobre MySQL. Disponível em: <http://www.mysqlbrasil.com.br/>. Acesso em: 15 de
junho de 2009.
NBR/ISO/IEC 17799. Tecnologia da Informação: Código de prática para a gestão da
segurança da informação. ABNT, 2005.
NOLAN, R.; MCFARLAN, F.W. Information Technology and the Board of Directors. Harvard
Business Review. V.83, n.10, p.96, Oct, 2005.
PAULA FILHO, Wilson de Pádua. Engenharia de software: fundamentos, métodos e padrões. Rio
de Janeiro: LTC, 2001.
SANTOS, Lara. O que é uma base de dados. Disponível em:
<http://www.deetc.isel.ipl.pt/sinfoconhecimento/isi/semAnteriores/sem%20ver%202003-
2004/SemestreActual/info/docs/slides/Introdu%C3%A7%C3%A3o%20aos%20SGBDs.pdf> .
Acesso em: 19 de julho de 2009.
49
SAP - Systems Applications and Products in Data Processing. Virsa Compliance Calibrator.
Disponível em: <http://www.sap.com/brazil/solutions/business-
suite/erp/compliancecalibrator.epx>. Acesso em: 25 de maio de 2009.
SAP. Sobre SAP. Disponível em: <http://www.sap.com/brazil/company/index.epx>. Acesso em:
25 de maio de 2009.
SOFTWARE PROCESS IMPROVEMENT. Disponível em: <http://www.mustang-
technologies.com/Quality/SWCMMI.aspx>. Acesso em: 15 de maio de 2009.
TERZIAN, F. Gerenciamento de mudanças - ITIL. Info Corporate. Pp. 48-59, Março/Abril 2004.
WEILL, P.; ROSS, J. W. IT Governance: How Top Performers Manage IT Decision Rights for
Superior Results. Harvard Business School Press, 2004.
WEILL, Peter e ROSS, Jeanne W. Governança de TI – Tecnologia da Informação. São Paulo:
M Books, 2006.
50
APÊNDICES
51
A DESCRIÇÃO DOS CASOS DE USO
Neste apêndice são apresentadas detalhadamente as descrições dos casos de uso mostrados
na seção 3.2
A.1 MODULO CONFLITO
UC 01.01 – Criar Conflitos
Permite o operador efetuar manutenção na base de conflitos do sistema.
Requisito:
RF01: O sistema permite criar, alterar e inativar um novo conflito;
RF02: O sistema permite incluir, remover uma transação do conflito
RF03: O sistema permite incluir, remover um aprovador do conflito; e
RF04: O sistema permite o período que será executado o workflow
Condição:
Pré-Condição: Possuir usuário cadastrado no SAP.
Pós-Condição: Novo conflito cadastrado.
Cenários:
Criar Novo Conflito – Principal
1. O operador deverá selecionar a opção Manutenção de conflitos (TEL002);
2. O operador descreverá o novo conflito
3. O operador deverá informar o código do controle;
4. O operador deverá informar a descrição do controle;
5. O operador deverá selecionar a opção Incluir.
6. O sistema atribui uma data atual para o tipo criado; e
7. O sistema armazena informações no Banco de dados.
Voltar para Menu principal – Alternativo
52
Caso o usuário desista criar um novo conflito volta para o cenário principal:
8. Sistema não armazena informações no banco de dados; e
9. Sistema exibe Menu Principal.
Voltar para Menu principal – Exceção
Dados inválidos – campos obrigatórios não informados volta para o cenário principal
Caso não sejam informados todos os dados, apresenta mensagem (‗Preencher todos
Campos‘). Retorna ao passo 2.
Manutenção de Conflito – Principal
1. O operador irá selecionar o conflito; (TEL002);
2. O operador alterara as informações;
3. O operador deve selecionar a opção Salvar.
4. O sistema atribui uma data atual para o tipo alterado; e
5. O sistema armazena informações no Banco de dados.
Voltar para Menu principal – Alternativo
Caso o usuário desista criar um novo conflito volta para o cenário principal:
13. Sistema não armazena informações no banco de dados; e
14. Sistema exibe Menu Principal.
Voltar para Menu principal – Exceção
Dados inválidos – campos obrigatórios não informados volta para o cenário principal
Caso não sejam informados todos os dados, apresenta mensagem (‗Preencher todos
Campos‘). Retorna ao passo 2.
Desativar de Conflito – Principal
1. O operador deverá selecionar o conflito; (TEL002);
2. O operador deverá selecionar a opção Desativar.
53
3. O sistema atribui uma data atual para o tipo desativado; e
4. O sistema armazena informações no Banco de dados.
Voltar para Menu principal – Alternativo
Caso o usuário desista criar um novo conflito volta para o cenário principal:
5. Sistema não armazena informações no banco de dados; e
6. Sistema exibe Menu Principal (TEL001).
Voltar para Menu principal – Exceção
Dados inválidos – campos obrigatórios não informados volta para o cenário principal
Caso não sejam informados todos os dados, apresenta mensagem ('Dados incorretos').
Retorna ao passo 1.
UC 01.02 – Manutenção de Transações Conflitantes
Permite o operador cadastro as transações em conflitos.
Requisito:
RF01: O sistema permite incluir, remover um transação do conflito;
RF02: O sistema permite incluir, remover um aprovador do conflito; e
RF03: O sistema permite o período que será executado o workflow.
Condição:
Pré-Condição: Possuir conflito cadastrado e usuário no SAP.
Pós-Condição: Novo usuário conflito com transações e aprovadores cadastrados.
Cenários:
Manutenção de Transações Conflitantes – Principal
1. O operador deverá selecionar o conflito (TEL002);
2. O operador irá inserir e remover transações;
3. O operador deverá inserir e remover o operador e nível de aprovação.
4. O operador irá selecionar o período de envio da mensagem do workflow; e
54
5. O sistema armazena informações no Banco de dados.
Voltar para Menu principal – Alternativo
Caso o usuário desista cadastrar a transação e usuário para a o processo de manutenção
conflitante volta para o cenário principal:
1. Sistema não armazena informações no banco de dados; e
2. Sistema exibe Menu Principal (TEL001).
Voltar para Menu principal – Exceção
Dados inválidos – campos obrigatórios não informados volta para o cenário principal
Caso não sejam informados todos os dados, apresenta mensagem (‗Preencher todos
Campos‘). Retorna ao passo 2.
A.2 MODULO CONFLITOS
UC 02.01 – Verificar Usuário Conflito
Permite o operador verificar os conflitos de um usuário no sistema informatizado.
Requisito:
RF01: O sistema deverá permitir visualizar e remover um usuário da base de conflitos.
Condição:
Pré-Condição: Usuário ativo na base de conflitos.
Pós-Condição: Usuário removido da base de conflitos.
Cenários:
Remover usuário base conflitos – Principal
1. O sistema mostra a opção usuário (TEL005);
2. O operador deverá selecionar campo usuário;
2.1 O sistema irá abrir a tela de procura usuário (TEL004);
2.2 O operador irá selecionar o usuário;
3. O operador deverá selecionar a opção Remove base conflitos; e
55
4. O sistema armazena informações no Banco de dados.
Voltar para Menu principal – Alternativo
Caso o usuário desista de remover o usuário:
1. Sistema não armazena informações no banco de dados; e
2. Sistema exibe Menu Principal (TEL001).
UC 02.02 – Analisa Conflito
Permite o operador verificar os conflitos de um usuário no sistema informatizado.
Requisito:
RF01: O sistema deverá permitir visualizar e remover um usuário da base de conflitos.
Condição:
Pré-Condição: Usuário SAP.
Pós-Condição: Usuário removido da base de conflitos
Cenários:
Remover usuário base conflitos – Principal
1. O sistema mostra a opção usuário (TEL006);
2. O operador deverá selecionar campo usuário;
2.1 O sistema irá abrir a tela de procura usuário (TEL004);
2.2 O operador irá selecionar o usuário;
3. O operador deverá selecionar a opção Remove base conflitos; e
4. O sistema armazena informações no Banco de dados.
Voltar para Menu principal – Alternativo
Caso o usuário desista de remover o usuário:
5. Sistema não armazena informações no banco de dados; e
6. Sistema exibe Menu Principal (TEL001).
56
UC 02.03 – Verifica Não Conformidade
O sistema verifica as não conformidades na base de conflitos e transações.
Requisito:
RF01: O sistema irá atualizar a base de conflitos;
RF02: O sistema irá verificar as não conformidades, os conflitos modificados, na base; e
RF03: O sistema irá verificar a base de transações para verificar se há uma nova
transação.
Condição:.
Pós-Condição: Atualização da base de conflitos; e
Pós-Condição: Mensagem encaminhada para o auditor com as alterações na base.
Cenários:
Verificação da Base de Conflitos – Principal
1. O sistema irá validar e inserir as os novos conflitos na base;
2. O sistema irá verificar se há novas transações no sistema;
3. O sistema irá encaminhar uma mensagem com as atualizações da base para o auditor; e
4. O sistema armazena informações no Banco de dados.
57
B APÊNDICE DO DIAGRAMA ENTIDADE-RELACIONAMENTO
Figura 32. Diagrama do Banco de dados
