APOSTILA

TECNOLOGIA

INFORMAÇÃO - TI
 SUMÁRIO

GESTÃO E GOVERNANÇA EM TI PG. 2

PROCESSOS DA GERÊNCIA DE PROJETOS PG. 31
GERENCIAMENTO DE PROCESSOS DE NEGÓCIO PG. 43
ENGENHARIA DE REQUISITOS DE SOFTWARE PG. 47
GERENCIA SERVIÇOS DE TI - ITIL E COBIT PG. 58
BANCO DE DADOS PG. 68
PORTAIS CORPORATIVOS E COLABORATIVOS PG. 91
SEGURANÇA DA INFORMAÇÃO PG. 95
REDES PG. 123

CONTEÚDO DETALHADO:
TECNOLOGIA DA INFORMAÇÃO
1. Gestão e Governança de TI: Planejamento Estratégico. Alinhamento entre estratégias de tecnologia da informação e de
negócio: conceitos e técnicas. 2. Gerência de Projetos: Conceitos. Processos do PMBOK. 3. Gestão de Processos de
Negócio: Modelagem de processos. Técnicas de análise e modelagem de processo. BPM – Business Process Modeling.
4. Gerência de Requisitos de Software: Conceitos de Requisitos. Requisitos Funcionais e não Funcionais. Engenharia de
requisitos: conceitos básicos. Técnicas de elicitação de requisitos. Gerenciamento de requisitos. Especificação de
requisitos. Técnicas de validação de requisitos. 5. Gerencia de Serviços de TI: Fundamentos da ITIL® (Versão 3).
Fundamentos de COBIT (Versão 5). 6. Banco de Dados: Conceitos. Modelagem de Dados Relacional. Modelagem de
Dados Multidimensional.Conceitos e estratégias de implantação de Data Warehouse, OLAP, Data Mining, ETL e
Business Intelligence. 7. Portais corporativos e colaborativos. 8. Segurança da informação: Conceitos básicos. Plano de
continuidade de negócio. Noções sobre Criptografia, Assinatura Digital e Autenticação. Certificação Digital. Auditoria,
vulnerabilidade e conformidade. 9. Redes: Conceito de rede. Arquitetura de Rede. Noções de administração de redes.
Conceitos de Virtualização.
Estruturas, Processos e Mecanismos de Governança de TI

INTRODUÇÃO

A Tecnologia da Informação (TI) desempenha um papel essencial ao negócio. Há

situações em que a ineficiência da TI pode provocar impactos altamente negativos ao
negócio, como por exemplo, indisponibilidade de serviço, ambiente de negócio com
baixa resiliência e operações descontinuadas.

O uso e a exploração dos recursos tecnológicos são cada vez mais intuitivos, porém a
mesma facilidade não é observada em termos de gestão e controle dos componentes
tecnológicos que estão relacionados ao negócio. Portanto, o principal desafio na
contemporaneidade é saber utilizar a TI de forma efetiva, extraindo e agregando valor
real ao negócio da organização.

Diante das questões apresentadas surge uma indagação importante: o que é preciso
observar em termos de capacidades organizacionais para se estabelecer controles
efetivos para implementar a TI harmônica com o negócio? Nesse contexto, há várias
correntes acadêmicas, como também iniciativas de Órgãos de Fiscalização e Controle e
melhores práticas que, conjuntamente têm apontado a Governança de TI como uma das
principais alternativas para tratamento das necessidades de controles interno e externo.

Embora a Governança de TI exerça um papel relevante no direcionamento da TI com

vistas à agregação de valor ao negócio, torna-se necessário compreender o que é
efetivamente necessários
para implementar e manter a Governança de TI.

De acordo com a proposta de trabalho, a pesquisa foi desenvolvida com foco na

implementação da governança de TI na Administração Pública Federal do Brasil,
especificamente nos aspectos de conformidade, ou seja, que requisitos de conformidade
à Governança de TI devem ser
implementados numa organização para que ela esteja em conformidade com a
legislação vigente e com as recomendações de Órgãos de Fiscalização e Controle.

Vale contextualizar que a Governança de TI na administração pública federal do Brasil,

principalmente em Órgãos da Administração Indireta, é fortemente influenciada por
Órgãos Controladores Externos, como por exemplo o Tribunal de Contas da União –
TCU.

As ações e práticas de Governança de TI emanadas pelos Órgãos de Fiscalização e

Controle, são encaminhadas por meio de Recomendações aos Órgãos da Administração
Pública direta e indireta.

Vale destacar que as Recomendações refletem o resultado de análises realizadas em

trabalhos de auditoria do TCU em Órgãos da APF, sendo que os registros dos trabalhos
realizados são documentados e publicados por meio de Acórdãos e, que as referidas as
Recomendações direcionam e, de certa forma, até alavancam ações e práticas de
governança de TI em Órgãos da Administração Pública Federal.

2
É importante mencionar, ainda, que as práticas de Governança de TI recomendadas
pelos Órgãos de Fiscalização e Controle às Organizações da APF, indireta, contemplam,
fortemente, questões relacionadas à segurança da informação.

Diante de tal situação, as análises realizadas contemplaram além da literatura

acadêmica, Acórdãos do TCU, Normas Complementares da Presidência da República,
Instruções Normativas da SLTI/MPOG e das melhores práticas relacionadas à
Tecnologia da Informação e Segurança da Informação, como COBIT, ITIL e NBR
ISO/IEC 27002. As pesquisas demonstraram que a Governança de TI pode ser
composta por Estruturas, Processos e Mecanismos, trabalhando de
forma harmonizada em conformidade com as recomendações de Órgãos de Fiscalização
e Controle.

De acordo com o ITGI (2000), a Governança de TI é parte integrante da governança

corporativa e consiste em lideranças, processos e estruturas organizacionais para
assegurar que a organização
sustente e amplie suas estratégias e objetivos.

Segundo, LUNARD (2007), foi a partir de 2001, com a definição proposta por
KORACKAKABADSE e KAKABADSE que a governança de TI passa a se concentrar
também na necessidade de definir processos e mecanismos de relacionamento e não
apenas estruturas – para desenvolver, dirigir e controlar os recursos de TI, de modo a
atingir os objetivos da organização. Nessa mesma linha, aparecem as definições de
Peterson (2004), TURBAN, MCLEAN E WETHERBE (2004) e do ITGI (2000).

Percebe-se que a maioria dos autores concordam que a governança de TI é uma

preocupação da alta administração em controlar o impacto estratégico da TI e a sua
entrega de valor para o negócio,
conforme proposto por WEILL E ROSS (2005), ITGI (2000) e DE HAES E
GREMBERGEN (2004).

Após a identificação de Estruturas, Processos e Mecanismos de Governança de TI

constantes da literatura acadêmica, sendo verificada a relação destes com as fontes de
informações de Órgãos de
Fiscalização e Controle, com fontes de informação Governamental e com as melhores
práticas que abordam assuntos relacionados à Governança de TI e a Segurança da
Informação.

O estudo empírico das Estruturas, Processos e Mecanismos de Governança de TI,

identificados na literatura acadêmica, ocorreu por meio de um estudo de caso simples
em Órgão da Administração
Pública Federal do Brasil, especificamente, em uma Empresa Pública.
A aplicação do Estudo de Caso possibilitou observar como a governança de TI é tratada
no âmbito da Administração Pública Federal, com base nos seguintes resultados:

- Em relação às estruturas de Governança de TI, foi verificado que 67% das

estruturas verificadas são efetivamente aplicadas na organização e 33% são
parcialmente realizadas.

3
- Em relação à aplicação dos Processos de Governança de TI, foi verificado que 9%
dos processos são realizados, 64% são parcialmente realizados e 27% não são
realizados.

– Em relação aos mecanismos de Governança de TI, foi constatado que 67% são
parcialmente realizados e 33% não são realizados.

Numa visão geral das Estruturas, Processos e Mecanismos de Governança de TI

aplicados numa empresa pública, foi constatado que 16% são realizados, 60% são
parcialmente realizados e 24% não são realizados.

Os resultados apresentados, sugerem que as estruturas, processos e mecanismos de

Governança de TI existentes na literatura acadêmica são, em parte, contemplados em
Órgãos da Administração Pública Federal Brasileira e podem, ainda, contribuir e apoiar
as organizações no estabelecimento e manutenção da Governança de TI.

METODOLOGIA

No primeiro momento, foi realizado o levantamento de fontes de informações

acadêmicas em busca de conceitos e requisitos necessários à implementação da
Governança de TI.
No segundo momento, foram realizadas pesquisas acerca dos Acórdãos do TCU que
tratam da Governança de TI e, a partir de estudos realizados nestes Acórdãos foi
possível, identificar citações relacionadas às Normas Complementares da Presidência da
República, que tratam de Segurança da Informação, as Instruções Normativas da
SLTI/MPOG, como também ao uso de melhores práticas de Governança e de Gestão de
TI, como o CobIT, a ITIL e a norma NBR ISO/IEC 27002.

Desta forma, as fontes de informação acadêmica, como também as fontes de informação

de órgãos reguladores e de governo e melhores práticas de mercado, passaram a compor
a base de pesquisa deste trabalho.

REFERENCIAL TEÓRICO

A Governança Corporativa

De acordo com o Instituto Brasileiro de Governança Corporativa, (IBGC, 2013), a

Governança Corporativa é o sistema pelo qual as organizações são dirigidas,
monitoradas e incentivadas, envolvendo os relacionamentos entre proprietários,
conselho de administração, diretoria e órgãos de controle. As boas práticas de
governança corporativa convertem princípios em recomendações objetivas, alinhando
interesses com a finalidade de preservar e otimizar o valor da organização, facilitando
seu acesso ao capital e contribuindo para a sua longevidade.

Segundo, LUNARD et al (2007), a Governança Corporativa teve origem na década de

1930, especialmente após o surgimento das chamadas corporações modernas, quando
passa a ocorrer a
separação entre o controle e a gestão, o papel de gestor na empresa não precisa
mais, necessariamente, ser exercido pelo dono. Entretanto, é no início dos anos 1980
que o movimento da

4
Governança Corporativa desperta novo interesse entre as empresas, principalmente
pelo descontentamento de grandes investidores quanto às decisões tomadas pelos
dirigentes das empresas, muitas vezes tomadas em seu benefício próprio em detrimento
ao dos acionistas.

Boa parte da literatura de Sistemas de Informação tem sugerido que a Governança

Corporativa influenciou fortemente na evolução da Governança de TI (ITGI, 2003;
PETERSON, 2004a;
GREMBERGEN et al, 2004). O próprio IT Governance Institute refere-se à governança
de TI como
sendo um subconjunto da Governança Corporativa (ITGI, 2003).

A Governança de TI

Embora a governança de TI seja um tópico de pesquisa relativamente novo, diferentes

definições foram desenvolvidas ao longo dos anos, como por exemplo, nos anos de
1990 e 1999 pelos pesquisadores Henderson e Venkatraman, os quais mencionaram em
publicações sobre alinhamento estratégico questões relacionadas à Governança de TI.

Em artigo publicado em 1990, Henderson e Venkatraman (1990) propuseram um

modelo de alinhamento estratégico em que a estratégia de TI corresponde à Governança
de TI e as
Competências sistêmicas de TI, sendo que as ligações entre a estratégia de negócio e
estratégia de TI (ou seja, a articulação necessária do escopo da TI, o desenvolvimento
de competências
sistêmicas, bem como mecanismos de governança de TI), refletem a capacidade de
alavancagem da estratégia de TI para moldar e suportar as estratégias de negócio.

Num outro artigo, publicado em 1999, os mesmos autores citaram que a posição da
organização no mercado da TI envolve três conjuntos de escolhas: escopo da tecnologia
da informação, competências sistêmicas e Governança de TI (Henderson e
Venkatraman, 1999).

No que tange à governança de TI, os artigos de Henderson e Venkatraman, publicados

em 1990 e 1991, propuseram a seleção e uso de mecanismos, por exemplo,
empreendimentos conjuntos (joint
ventures) com fornecedores; alianças estratégicas; pesquisas conjuntas e o
desenvolvimento de novas capabilities de TI, objetivando, desta forma, a obtenção das
competências necessárias de TI.

De acordo com SAMBAMURTHY et al (1997), a governança de TI é definida como

a implementação de estruturas e arquiteturas (e padrões de autoridade associadas)
relacionadas à TI para atingir com sucesso atividades em resposta ao ambiente e à
estratégia organizacional. A idéia da necessidade em definir diferentes estruturas como
forma de atingir o sucesso da TI é reforçada com a definição de WEILL E ROSSI
(2004), que definiram a governança de TI como o sistema que especifica a estrutura de
responsabilidades e direitos de decisão para encorajar comportamentos desejáveis no
uso da TI .

5
A Governança de TI é uma estrutura de relações e processos para dirigir e controlar a
função de TI numa Organização, a fim de atingir seus objetivos, agregando valor,
equilibrando riscos versus retorno sobre TI e seus processos. Parte da Governança de TI
é projetar, aplicar e avaliar um conjunto de regras para governar as regras e funções da
TI (VERHOEF, 2007).

Segundo LUNARD et al (2007), foi a partir de 2001, com a definição proposta por
Korac- Kakabadse, que a governança de TI passa a se concentrar também na
necessidade de definir processos e mecanismos de relacionamento e não apenas
estruturas para desenvolver, dirigir e
controlar os recursos de TI, de modo a atingir os objetivos da organização. Nessa
mesma linha, aparecem as definições de PETERSON (2004b), TURBAN et al (2004) e
ITGI (2003).

O ITGI define a governança de TI como a liderança, as estruturas organizacionais e os

processos que garantem que a TI da empresa sustente e estenda as estratégias do
negócio e seus objetivos,
integrando e institucionalizando boas práticas (ITGI, 2007).
Para atender as necessidades de governança de TI, modelos, metodologias, padrões e
ferramentas estão sendo consolidados em frameworks de melhores práticas do mercado,
geralmente desenvolvidos por associações profissionais e estimulados por grandes
empresas de TI e agências governamentais. Essas iniciativas favorecem a integração da
TI com as demais funções organizacionais e tornam seus processos de trabalho mais
transparentes, inteligíveis, controláveis e confiáveis. Dentre as melhores práticas que
tratam de temas contemplados na Governança de TI, destacam-se:

- PMBOK – guia de conhecimento em gerenciamento de projetos (PMBoK, do inglês

Project Management Body of Knowledge), baseado na metodologia reconhecida
mundialmente pelos profissionais de gerenciamento de projetos – um documento formal
que descreve
normas, métodos, processos e práticas estabelecidas. O Conhecimento contido neste
guia evoluiu a partir de boas práticas reconhecidas de profissionais de gerenciamento de
projetos que contribuíram para o seu desenvolvimento.

- CobIT – Control Objectives for Information and Related Technology, é um

framework dirigido para a governança e gestão de tecnologia da informação.
Recomendado pela Information Systems Audit and Control Association (ISACA), o
CobIT possui recursos que são aplicados como um modelo de referência para a gestão
da TI. Atualmente se encontra na versão 5.0, lançada em 2012.

- CMMI – Capability Maturity Model® Integration – Modelo Integrado de Maturidade

e de Capacidade para melhoria de processo de software, destinado ao desenvolvimento
de produtos e serviços, e composto pelas melhores práticas associadas a atividades
de desenvolvimento e de manutenção que cobrem o ciclo de vida do produto desde a
concepção até a entrega e manutenção.

- ITIL – Information Technology Infrastructured Library – A ITIL é uma biblioteca

que compila melhores práticas usadas para o gerenciamento de serviços de tecnologia
da informação.

6
- Norma ABNT NBR/ISO 27002:2005 – Código de boas práticas para a gestão da
segurança da informação.

Embora essas definições se diferenciem em alguns aspectos, em virtude do próprio

período em que foram escritas, pode-se perceber que quase todas as definições de
governança de TI abordam a forma de autoridade da tomada de decisão de TI na
organização, por meio de estruturas e a forma com que os recursos de TI são
gerenciados e controlados, por meio de processos, buscando sempre alinhar os
investimentos realizados em TI às estratégias corporativas.

A Governança de TI e as pressões externas

Em se tratando de pressões externas, quais são as regras? É uma falha ver a Governança
de TI como uma mera resposta às pressões regulatórias externas, pois isso gera uma
atitude fundamentalmente
doentia: a governança é vista apenas como um custo, um custo de fazer negócios, sobre
as quais você não tem controle (Norfolk, 2011).

Na verdade, a governança de TI deve ser vista como uma maneira em que o Conselho
possa garantir que os recursos de TI são implantados e gerenciados de forma rentável,
em busca da estratégia de negócio. O objetivo final da governança de TI é o negócio
melhor, mais rápido, mais barato, ou seja, a garantia de resultados ao negócio.

No entanto, um aspecto desta questão é a transparência, que assegura que todas as

partes interessadas de uma empresa possam certificar-se de que o negócio está sendo
realizado de forma honesta e ética, nos interesses da empresa e da comunidade, como
um todo, em vez do disfuncional interesse de particulares.

Felizmente, a maioria nova legislação não é mais puramente prescritiva, isto é, não
apenas especificar uma lista de regras mais ou menos arbitrárias, mas as tentativas de
gerar e adotar “boas práticas” e “maturidade organizacional’. Uma empresa que satisfaz
a Lei Sarbanes-Oxley, por exemplo, será uma empresa melhor gerenciada, capaz de
medir a eficácia com que ele se alinha objetivos de TI aos objetivos de negócio, capaz
de demonstrar a eficácia e integridade de seus relatórios financeiros – e capaz de operar
de forma mais econômica, como resultado.

Mesmo assim, há uma série de novas legislações em torno de controle interno em geral,
que o grupo de TI deve estar ciente. O grupo de TI sempre vai ser mais eficaz no
contexto de um negócio em evolução, em que a tecnologia muda rapidamente, se a
governança de TI é construída em sistemas automatizados desde o início. Isso significa
adotar um ciclo de desenvolvimento e processo de manutenção, que trata exigências
regulatórias como iguais em importância para os outros requisitos de negócio e implica
que os sistemas automatizados sejam testadas em cenários derivados da legislação
aplicável.

Em geral, o grupo de TI pode esperar que os acionistas da empresa estabeleça, os

requisitos regulamentares, mas os analistas de TI devem questionar o que lhes é dito e
garantir que os sistemas automatizados possam satisfazer as necessidades “não
funcionais” como trilhas de auditoria eficazes, controles de acesso e sistemas de
resiliência, que se originam em legislações que promovam a governança. Por sua vez,

7
isto significa que eles devem estar cientes de que existe legislação e que tipo de
controles são mandatórios.

Legislações que impactam a governança de TI

É importante, realmente ler, as legislações que afetam a governança de TI, bem como as
notas de orientação ou de imprensa.

O Comitê de Basileia de Supervisão Bancária divulgou um quadro revisto para

adequação de capital (gestão de risco de crédito), geralmente conhecido como o Acordo
de Basileia II entrou em pleno
vigor em 2007. Em julho de 2004, a Comissão Europeia publicou a Diretiva de
Requisitos de Capital (CRD) para trazer Basileia II em direito da União Europeia (UE).

A Basileia II, por exemplo, teve um impacto significativo sobre os processos bancários
e os sistemas de TI que os implementam e os suportam – em grande parte na área de
monitoramento de perfis de risco de crédito, sendo de grande importância para os
bancos. No entanto, para as instituições financeiras, Basileia II tem algumas implicações
bastantes sutis, como a gestão de riscos não é particularmente determinística e as novas
regras podem simplesmente significar que o risco seja transferido.

Um dos objetivos da governança corporativa no âmbito do COSO é a conformidade

com as leis e regulamentos aplicáveis. No mundo de TI, isso significa que deve-se
abordar, no mínimo:

- O Freedom of Information Act (Reino Unido) ou o equivalente em em outros países.

Isto não se aplica apenas aos serviços públicos, mas impacta em projetos de sistemas de
armazenamento e recuperação de informações para tais serviços.

– Os Regulamentos de proteção de dados, por exemplo, a Lei de Protecção de Dados

(Reino Unido) e a legislação em toda a Europa, visam cumprir as diretivas relativas à
proteção de dados da União Européia. Não só deve proteger as informações pessoais
como também
utilizá-las para fins específicos, e deve destruí-la de forma segura, quando não é
mais necessária e oferecer facilidades para os assuntos de dados pessoais para acessar e
corrigi-lo. Um problemas especial para muitos sistemas automatizados globais que
podem começar a
contar com a tecnologia “cloud computing”, onde a localização de dados em
um determinado momento não está bem definida, é que provavelmente você está em
violação das regras de proteção de dados da UE, se os dados são armazenados ou
transmitidos fora das fronteiras da União Européia.

- A Propriedade Intelectual (PI), em muitos casos, é o bem mais valioso de uma

empresa é a sua Propriedade Intelectual. É particularmente difícil gerenciar a tecnologia
da Propriedade Intelectual, pois muitas delas ainda estão na cabeça das pessoas.
Uma questão importante é o licenciamento de software, principalmente o uso de
software não licenciado que pode ocasionar multas, há casos em que as empresas são
processados, havendo,
ainda, interrupções ao negócio a partir de computadores confiscados e impactos à
reputação e imagem da organização. Embora haja riscos também no uso de softwares

8
licenciados, como por exemplo, há kits SOX disponíveis no mercado que prometem
entregar a conformidade com a Sarbanes-Oxley, mas na ausência de um processo de
gestão de ativos bem compreendido, é improvável que tenham a capacidade de entregar
tal conformidade.

- A Regulamentação das telecomunicações, como o Regulation of Investigatory Powers

Act (RIPA). Isso impacta na interceptação de comunicações eletrônicas e do uso da
tecnologia de criptografia.
- A Saúde e Segurança no Trabalho (Health and Safety at Work Act in the UK), aplica-
se aos trabalhadores em TI, tanto como em qualquer outro lugar. Talvez, não seja uma
questão específica da Governança de TI, mas é importante lembrar que os trabalhadores
de TI não estão isentos de problemas de saúde e segurança.

- As diretivas de reciclagem (WEEE Recycling Directive). Isso provavelmente não vai

impactar muito os usuários finais de TI, mas podem afetar operações, como a maioria
equipamento eletrônico
devem agora ser reciclados quando é descartado.

- A Lei de Deficiência, 1995 (Disability Act, 1995). Novamente o tema Saúde e

Segurança, as organizações de TI não estão isentas. Em particular, sites devem ser
projetado para facilitar o acesso de pessoas com capacidades diferentes. A norma
fundamental nesta área é provavelmente o Web Content Accessibility Guidelines 1.0
(1999 e também no Working Draft 2.0, produzido em 2003), criado pela Web
Accessibility Initiative do W3C.

- Legislação de Combate à Lavagem de Dinheiro, que no Reino Unido é incorporada em

várias partes da legislação: a Lei de Justiça Criminal de 1988 (alterada), o tráfico de
drogas na Lei de 1994 e do Terrorismo (Terrorism Act 2000 – alterada). Isso, em grande
parte, embora não exclusivamente, afeta organizações bancárias e financeiras.

- As Publicações como Gee’s IT Policies and Procedures (ITPP, 2004) são tentativas de
orientar os assinantes sobre o estado atual de tal legislação, e são regularmente
atualizadas, mas convém que haja o aconselhamento profissional sobre as implicações
exatas da legislação, se isso afeta especificamente a TI. Talvez não seja diretamente
uma parte da “Governança de TI”, por si só, mas às vezes é bom lembrar que é uma
idéia muito boa para evitar processos judiciais caros, sempre que possível.
Na verdade, é possível que a conformidade regulatória possa ser implementada no
software que conduz o negócio, mas deve-se ter muito cuidado com isso, pois numa
última análise, o efeito da lei
reguladora e de leis associadas permite ao tribunal decidir com base na legislação e não
ao que parece, tecnicamente, competente e razoável aos leigos.

Mecanismos de Governança de TI

Embora a discussão sobre o conceito de governança de TI tenha procurado tornar mais

clara a compreensão sobre sua importância e papel na organização, a questão sobre
como implementá-la na prática tem intrigado muitos executivos e pesquisadores. A
decisão de implementar a governança de TI pode ser iniciada, em alguns casos, em
virtude de um interesse específico, como, por exemplo, definir responsáveis para a
elaboração de projetos de TI e para a sua avaliação ou pela presença de problemas

9
críticos para a organização, como a falta de recursos, exigindo que os
executivos analisem e priorizem seus projetos tecnológicos, conforme o seu impacto na
organização (LUNARD, 2007).

A questão central diz respeito ao modo como as empresas podem, pragmaticamente,

implementar a governança de TI. A Governança de TI pode ser implantada usando uma
mistura de várias estruturas, processos e mecanismos relacionais. Ao projetar a
governança de TI de uma organização, é importante reconhecer que depende de uma
variedade de fatores internos e externos, por vezes, conflitantes. Determinar a
combinação correta de mecanismos é, portanto, uma tarefa complexa com o agravante
de que, o que funciona para uma empresa, pode não funcionar para outra. Isso significa
que as organizações diferentes podem necessitar de uma combinação de
diferentes estruturas, processos e mecanismos relacionais (DE HAES E
GREMBERGEN, 2004).

O framework proposto por Peterson (2004) aborda uma forma de comportar estruturas
de gestão de TI, processos e mecanismos numa relação compreensível, cujas estruturas
envolvem a existência de
papeis e responsabilidades, como os executivos de TI e os comitês de TI; os processos
referem-se ao monitoramento e a tomada de decisões estratégicas; e os mecanismos de
relacionamento incluem a participação da TI e do negócio, o diálogo estratégico, o
conhecimento compartilhado e a comunicação adequada.

De acordo com De Haes et al, os mecanismos de relacionamento são muito

importantes, considerando que é possível que uma organização tenha todas as estruturas
de governança de TI e os processos no lugar, mas não funcione porque o negócio e a TI
não se entendem ou não estão trabalhando juntos. Ou, pode ser que haja pouca
conscientização do negócio por parte da TI ou pouca valorização da TI por parte da
empresa (DE HAES E GREMBERGEN, 2004).

Assim, para alcançar a governança efetiva de TI, é necessária a comunicação

bidirecional e uma relação de participação e colaboração entre as equipes de negócio e
de TI, assegurando o compartilhamento contínuo do conhecimento entre os
departamentos organizacionais para atingir e manter o alinhamento entre o negócio e a
TI. Isso é crítico quando se busca o compartilhamento e a gestão do conhecimento por
meio de mecanismos tais como o cruzamento profissional (equipes de TI trabalhando
nas unidades de negócio e pessoas do negócio trabalhando na TI), educação contínua e
treinamento mesclado (DE HAES E GREMBERGEN , 2004).

A aplicação de mecanismos como comitês, a participação da área de tecnologia na

formulação da estratégia corporativa, bem como os processos de elaboração e aprovação
de orçamentos e projetos
de TI são apenas alguns mecanismos que procuram encorajar um comportamento
consistente da organização, buscando sempre alinhar os investimentos de TI com a
missão, estratégia, valores e
cultura organizacional (WEILL E ROSS, 2005).

Como implementar efetivamente a Governança de TI

10
De acordo com Norfolk (2011), o primeiro requisito para se estabelecer a Governança
de TI é buscar alinhar a Governança de TI com a Governança Corporativa.

A obtenção de patrocínio da alta direção, também, é considerado um dos primeiros

requisitos para se estabelecer a Governança de TI numa organização (Norfolk,2011).

Há três “métricas” práticas de patrocínio da direção para governança de TI:

a) A disponibilidade de um plano de governança corporativa de TI, supervisionado por

um Comitê de Governança, com representação dos profissionais de TI em Grupo de TI,
reportando-se a nível do Conselho. Os nomes são irrelevantes, o grupo poderia
facilmente ser chamado Comitê Estratégico de TI, por exemplo, o importante é
que as questões de governança de TI possam ser discutidas a nível de conselho.

b) Uma estrutura de governança de TI é implementada, geralmente com

uma Departamento de Controle Interno ou algum desses grupos. O que é importante é
que a governança possa ser monitorada de forma proativa.

c) Provisão formal de orçamento para atender as iniciativa de governança de TI. As

etapas na implementação de uma iniciativa de governança de TI a partir do zero seria,
em termos e, em nenhuma ordem particular, como segue:

- Manter o buy-in baixo

De acordo com Norfolk (2011) no processo de governança é importante manter o buy-in

baixo, sendo os investimentos direcionados a realização de treinamentos em ferramentas
e gestão de desempenho de modo a garantir que os eventuais sobrecargas de
administração não
impactam no desempenho operacional da Governança. Além do treinamento, com
mentores externos que tenham larga experiência em TI em geral, e que saibam lidar
com as questões de governança mais sutis, pode ser útil.
A realização de fórum de governança, em que os trabalhadores possam discutir os
problemas relacionados à governança de TI e sugerir soluções em público. No entanto, é
importante que os pontos de ação de tal fórum sejam documentados e demonstrem à
comunidade os problemas identificados, pelo menos, dada a devida atenção, ou seja a
gestão de processos através de feedback.
Sendo importante, ainda, que o fórum represente os pontos de vista tanto do negócio
quanto da TI.

- Mapeamento da TI para o Negócio

O mapeamento dos ativos de TI que atendem o Negócio é essencial à Governança de TI,

de acordo com Norfolk (2010), geralmente, há uma relação “muitos para muitos” entre
as funções de negócio e a infraestrutura de TI. Um determinado servidor, um
computador armazenar ambos dados de negócios e sistemas automatizados de
processamento de dados, pode suportar muitas funções de negócios, por exemplo, ao
contrário, uma única função de negócios pode invocar vários servidores. Norfolk
(2010), sugere, ainda, o uso de ferramentas automatizadas que possam gerar para os
sistemas automatizados o relacionamento dos processos de negócio com os sistemas de
TI.

11
- Implementar segurança baseada em política e gestão de identidade

Para Norfolk (2011), há muito mais para a governança de TI que a segurança da

informação, mas a segurança é parte dela. A boa segurança requer análise de risco e
ameaça, para determinar e
priorizar os riscos de frente para a organização, e, em seguida, a formulação de uma
Política de Segurança, que documente as políticas destinadas a mitigar, transferir
(através de seguros, por exemplo) ou aceitar (em conjunto com planos de contingência)
os diversos riscos identificados. em seguida é possível começar a planejar os
procedimentos que irão implementar as políticas. Idealmente, as políticas são genéricas,
de modo que, quando a mudança de tecnologia ou de negócios torne-se um
procedimento obsoleto, a intenção da política seja clara e possa direcionar a formulação
de um novo procedimento.

Uma boa segurança da informação esta baseada em papeis e pela sua manutenção, ou
seja as pessoas numa organização têm acesso básico, restrito como empregados, e lhes
são atribuídos os papéis na organização, cada função traz consigo as permissões de
acesso apropriadas. Se as pessoas são movimentadas, dentro da organização, elas têm
seus papéis alterados e perdem as permissões associadas a este papel, como também,
ganham aquelas permissões associadas a outro papel.

A gestão de identidade está relacionada à segurança. É tudo sobre como identificar

pessoas inequivocamente, como também gerenciar a atribuição de identidade às pessoas
que buscam acesso a organização. A Gestão de identidade inclui o fornecimento de
meios para permitir a atribuição inequívoca de ações de identidade, essenciais para
trilhas de auditoria e segurança. Um grande parte da governança de TI vem de pessoas
que assumem a responsabilidade por suas ações.
Sem o gerenciamento de identidade, a governança é construída sobre a areia.

A norma ISO/IEC 27002:2005 está se tornando aceito mundialmente como o código de

boas práticas para a gestão de segurança da informação e oferece uma excelente
estrutura para implementação da segurança e garante que você ter uma abordagem
holística, começando com a gestão de riscos, embora não seja forte sobre os detalhes
deste e cobrindo áreas muitas vezes negligenciadas, tais como a continuidade dos
negócios. No entanto, alguma forma de orientação de um consultor de segurança
externo é recomendado também, pois é difícil para fazer uma avaliação imparcial dos
riscos e das ameaças de dentro uma organização.

- Implementar Business Service Management – BSM em todas as plataformas

A gestão de serviço de negócio (BSM) significa que há gestão da infraestrutura de TI

dos serviços de negócios implementados por esta infraestrutura. A existência de um
único banco de dados na organização, para garantir a consistência dos dados e suporte
integração entre diferentes processos de gerenciamento de serviços pode ser um
importante facilitador para a BSM.

A BSM é comumente usada e abrange o seguinte: Gestão de Nível de Serviço, Gestão

de Incidentes, Gestão de Problemas e a Gestão de Aplicação e de Infraestrutura,
incluindo gestão de licença, Gestão de eventos e Impacto de Serviço, Gestão de Ativos e

12
Discovery, Gestão de Configuração e Mudanças, Gestão de Capacidade e
Gerenciamento de Identidades.

- Implementar o gerenciamento de infraestrutura

Ter uma infraestrutura totalmente gerenciada baseada em atualizações e registro de

manutenção de ativos é uma parte essencial da governança de TI. Mesmo algo tão
simples como a gestão de ativos de TI é uma parte vital da governança de TI. Se você
não sabe exatamente o hardware que você tem e, exatamente, o que o software está em
execução, como você pode reivindicar qualquer tipo de governança de TI? A pirataria
de software é uma área onde as organizações parecem ser culpados a menos que possam
provar sua inocência, e as consequências de uma visita por parte da polícia (interrupção,
confisco, multa) podem ser imensas. No entanto, o quão eficaz pode um apelo para que
“temos a certeza que todo o nosso software é licenciado, apesar de não saber qual o
software
que temos e onde ele está sendo executado”.A ITIL® é uma boa base para a ge
stão de infraestrutura, como também a gestão de ativo, gestão de capacidade e gestão
de nível de serviço, as funções de service desk e rastreamento de defeitos são
tipicamente parte de um framework de governança de TI.

A ITIL® é uma boa base para a gestão de infraestrutura, embora provavelmente seja
suficiente, em vez do que o necessário. Bem como a gestão de ativos, gerenciamento de
capacidade e gerenciamento de nível de serviço, a função Service Desk e rastreamento
de defeitos normalmente fazem parte de uma estrutura de governança de TI.

- Implementar a Gestão de configuração

A Gestão de configuração envolve a identificação dos componentes de um sistema

automatizado que contribuem para a entrega de serviço, como também à gestão de
mudanças da configuração (incluindo trilhas de auditoria e facilidades para retornar
mudanças mal sucedidas). Controle de mudanças de software (manter o controle de
alterações no código de software como mudanças de requisitos ou falhas ) é apenas
parte do gerenciamento de configuração.

- Implementar gestão de continuidade de negócios

A disponibilidade de sistemas de TI é agora fundamental para o funcionamento de

muitas empresas. Isso faz da Gestão de Continuidade de Negócios (GCN) uma parte
vital da governança de TI (Também é exigido pela norma de segurança ISO 17799). Na
verdade, ela deve ser construída desde do início, ou seja, através da concepção de
sistemas críticos para que seja resiliente.

A GCN não é algo trivial de se fazer, portanto, o uso de consultoria externa pode ser
interessante. Ela deve ser fortemente baseada em uma avaliação objetiva de riscos,
incluindo os riscos que a organização não tenha encontrado ainda, e muito com o
espectro de contingência a partir de interrupções de serviço menores para um desastre
total que elimina um centro de dados em sua totalidade.

É importante assegurar que a governança de TI seja mantida em um nível gerenciável,

durante uma contingência, caso contrário, contingências podem ser projetadas como

13
uma oportunidade para roubar dados, transações comerciais ou financeiras de
compromisso relatórios, ou sistemas de sabotagem. Uma abordagem de “sistemas
completos” para a continuidade de negócios devem ser adotadas.

- Implementar o gerenciamento de ciclo de vida da informação

A informação eletrônica pode ser tão importante e legalmente significativa como

documentos em papel, tais como instrumentos e contratos formais (potencialmente
forjado). Nos regulamentos e leis que afetam informações de negócios é mencionado
que a informação deve estar disponível para responder a perguntas dos auditores em
tempo hábil, e sua proveniência deve ser capaz de prova, mas, enquanto isso, algumas
informações pessoais devem ser destruídas de forma segura quando não forem mais
necessárias. Isso significa que um ciclo de vida de informação baseado em políticas de
gestão de sistema. Este deve ser capaz de classificar as informações, armazená-las de
forma rentável e segura e que possivelmente cópias de backup off site sejam mantidas,
sendo necessário, ainda, documentar a sua criação, alteração e destruição e de forma
segura auditar os eventos críticos do ciclo de vida da informação.

- Implementar processo de desenvolvimento e aquisição de sistemas

Para desenvolvimento de software, deve-se ter um processo que contemple o ciclo de

vida de desenvolvimento de software, a partir da análise de requisitos de negócio
através de codificação, de testes e de implementação de sistemas que na verdade, o teste
deve começar com a validação de requisitos, sendo que melhor caminho para
implementação é através de treinamento e orientação, utilizando ferramentas para
facilitar as práticas desejadas.

Caso não haja o desenvolvimento, é necessário um processo semelhante para a

implantação de pacotes, como também analisar os requisitos de negócio, a fim de
escolher um pacote que melhor se adéqua ao processo de negócio.

E você ainda precisa testar os pacotes de aplicações, caso eles não façam o que se
propõe, ou implementá-los de forma incorreta. No caso de pacotes customizados este é
realmente um projeto de desenvolvimento de sistemas pequeno e similares, medidas de
controle de qualidade são necessárias.

- Processamento Otimizado (Customização Tecnológica do Negócio)

Se você não tem uma boa parte da governança de TI implementada, a introdução do

desenvolvimento da Governança de TI e medidas de conformidade podem impactar em
despesas de processamento – e, portanto, no negócio. Por isso, é vital incluir que a
customização tecnológica do negócio seja considerada no planejamento, ou seja,
satisfazer os requisitos do HIPAA ou Sarbanes- Oxley ou outros equivalentes requisitos,
podem aumentar, por exemplo, acessos de banco de dados em várias ordens de
magnitude – e, sem dúvida, muitas infraestruturas de banco de dados não estão
projetadas para lidar com isso. A menos que seja reavaliado e, possivelmente, o
desempenho seja otimizado, o resultado imediato de introduzir a governança de TI
pode impactar no desempenho dos negócios e, portanto, na reputação da TI.

- Implementar Gestão de Problemas

14
A continuidade de Negócios é frequentemente considerada como recuperação de
desastres, algo standalone que é conduzido após um desastre, como a perda de um
centro de dados em um incêndio. Esta é, obviamente, um aspecto da governança de TI,
se o negócio depende das aplicações que estão em execução no Centro de Dados, mas
isso é uma visão muito limitada. A continuidade dos negócios é também uma função de
gerenciamento de problemas de TI. O negócio precisa ser isolado dos problemas de TI:
de um lado, uma significativa parte da infraestrutura de TI está perdida e falamos de
recuperação de desastres e BCM; no outro extremo, um bug é encontrado que afeta o
negócio ou uma pequena parte da infraestrutura de TI, como por exemplo, uma única
linha telefônica fora e falamos sobre gestão de incidentes e de problema e rastreamento
de falhas. No empenho de uma boa governança de TI, provavelmente você deve ver isso
como uma continuidade: o impacto das questões de TI sobre o negócio deve ser
limitado, como também controlado e gerenciado.

Isso está geralmente associado com a função de service desk, que deve apontar para
identificação preventiva e mitigação dos problemas emergentes, de preferência antes
que eles tenham qualquer impacto sobre um serviço de negócio.

- Demonstrar o Retorno sobre o Investimento (ROI)

Pelo menos um dos objetivos por trás de qualquer iniciativa de governança de TI é

provável que seja para melhor executar a TI em benefício da organização. Então, uma
boa prática é o uso de sistemas de governança de TI e relatórios de informações do
negócio de modo que a Governança de TI e o ROI de projetos de governança, possam
demonstrar para que ele governança, e o ROI (Return on Investment) do projeto de
governança, possam ser demonstrados em uma base contínua.

Escolha as métricas cuidadosamente – as pessoas tendem a entregar o que você medir,

por isso, se você escolhe as medidas erradas você pode obter os resultados errados.

Olhar além de um ROI puramente financeiro. A boa governança de TI reduz o risco, por
isso aumenta a confiança das empresas. A aplicação de uma abordagem por meio do
‘balanced scorecard‘, para medir o impacto da governança de TI é provavelmente
apropriada. É sempre importante lembrar que a governança de TI é apenas um meio
para um fim.

- Revisões de Sistemas de Informação

Revisões de sistemas de TI após mudanças, a fim de permitir uma análise de gaps das
diferenças entre a aspiração e a realidade, seguido pelo agendamento de esforços de
manutenção que visam reduzir gaps, é uma importante característica de uma boa
governança de TI. Às vezes, como iniciativas do CMMI, estas avaliações são parte de
um processo formal, mas, independentemente de quão se aproxima a governança de TI,
deve haver algum tipo processo de revisão e feedback.

REQUISITOS DE CONFORMIDADE À GOVERNANÇA DE TI

De acordo com as definições e estudos já realizados acerca da Governança de TI, é uma

das possíveis composições é baseada na definição de estruturas, processos e

15
mecanismos que, conjuntamente, pode promover um ambiente propício à existência e à
evolução da Governança de TI.

Dessa forma, as dados coletados pela pesquisa literária sobre governança de TI foram
organizados e consolidados no quadro 1, que trata das estruturas, processos e
mecanismos de conformidade à governança de TI.

Fonte: literatura acadêmica

16
O quadro 1 contempla os requisitos mínimos de Governança de TI, com base na
literatura acadêmica. Já em relação à pesquisa documental baseada nos órgãos de
planejamento, regulação e controle do governo federal brasileiro, bem como nos
frameworks de melhores práticas, estes são os vetores identificados:

Instruções Normativas da Secretaria de Logística e Tecnologia da Informação

(SLTI/MP) do Ministério do Planejamento, Orçamento e Gestão (MPOG).

Instrução Normativa Nº 02, de 30/04/2008 que dispõe sobre regras e diretrizes para a
contratação de serviços, continuados ou não.

Instrução Normativa Nº 04, de 12/11/2010 que dispõe sobre o processo de contratação

de
Soluções de Tecnologia da Informação pelos órgãos integrantes do Sistema
de Administração dos Recursos de Informação e Informática (SISP) do Poder
Executivo Federal.

Normas Complementares do Gabinete de Segurança Institucional da Presidência d

a República.

Acórdãos nº 1603/2008, Acórdão nº 2308/2010, Acórdão nº 1145/2011, Acórdão

nº 1233/2012, Acórdão nº 1775/2012; e Melhores práticas no que tange a Tecnologia
da Informação (Cobit5, ITIL v3, CMMI e PMBOK).

Com base nas Estruturas, Processos e Mecanismos de Governança de TI identificados

na fundamentação teórica, foi realizada, ainda, análise dos Acórdãos, Instruções
Normativas e Normas Complementares que influenciam na Governança de TI no
âmbito da Administração Pública Direta e Indireta, como também análise das melhores
práticas que abordam os temas relacionados à Governança de TI, como por exemplo, a
segurança da informação.

ESTUDO DE CASO

A estratégia de estudo de caso é desenvolvida a fim de verificar e conhecer como uma

empresa pública da Administração Pública Indireta mantém a Governança de
TI e como são tratadas, rotineiramente, as questões relacionadas ao tema, sendo
aplicado como instrumento direcionador desta verificação a tabela de estruturas,
processos e mecanismos de Governança de TI. Essa tabela é aplicada na empresa,
objeto de estudo, considerando os níveis estratégico, tático e operacional. Para a coleta
de dados, o estudo baseou-se nas políticas, normas, arquivos de dados, entre outros.

Trata-se de projeto de caso único, pois conforme Yin (2001) o caso único pode, então,
ser utilizado para se determinar se as proposições de uma teoria estão corretas ou se
algum outro conjunto alternativo de explanações possa ser mais relevante.

Yin (2001) sugere que a aplicação da forma de questão em termos de “quem”, “o quê”,
“onde”, “como” e “por quê”, forneça uma chave importante para se estabelecer a
estratégia de pesquisa mais relevante a ser utilizada. É provável que a estratégia de
estudo de caso seja apropriada as questões do tipo “como” e “por quê”; precisando com
clareza, a natureza das questões de estudo.

17
Sendo assim a aplicação do estudo de caso visa responder as indagações sobre como e
por que uma empresa pública mantém estruturas, processos e mecanismos de
Governança de TI. Dessa forma, a estratégia de pesquisa é complementada pelas
informações constantes no quadro a seguir:

De acordo com Yin (2001), a definição da unidade de análise está relacionada a maneira
como as questões iniciais da pesquisa foram definidas. A estratégia de pesquisa
apresentada decorre das seguintes proposições de estudo:

- as empresas públicas precisam manter estruturas, processos e mecanismos de

governança para atender recomendações de órgãos de fiscalização e controle; e as
empresas públicas mantém estruturas, processos e mecanismos de Governança de TI
para alavancar seus negócios.

Segundo Yin (2001), o quarto e o quinto componentes, como e por quê, foram os menos
desenvolvidos nos estudos de caso. Representam as etapas da análise de dados na
pesquisa do estudo de caso, e deve haver um projeto de pesquisa dando base a essa
análise.

Diante da proposta de apresentar as estruturas, processos e mecanismos necessários à

Governança de TI aplicável aos órgãos da APF direta e indireta, sendo que os seguintes
aspectos devem ser considerados:

- A verificação da aplicação efetiva dos requisitos mínimos de Governança e de Gestão

de TI em uma empresa pública;

- Mensurar, de forma qualitativa, o percentual de atendimento, por parte da empresa

avaliada, aos requisitos mínimos de Governança e de Gestão de TI.

- Propor melhorias aos processos da empresa avaliada, objetivando assegurar a evolução

e melhoria contínua dos requisitos mínimos de governança e de gestão de TI.

Com intuito de estruturar e documentar o trabalho de verificação dos requisitos

mínimos de Governança e de Gestão de TI, toda a investigação é realizada com base na
aplicação de um processo de conformidade.

A unidade de análise é constituída de uma empresa pública da Administração Pública

Indireta, em que o segmento de tecnologia da informação é parte integrante do negócio
essencial da organização.

O estudo de caso será realizado no departamento de segurança da informação dessa

empresa, tendo em vista as competências estratégicas e táticas desenvolvidas,

18
objetivando assegurar a segurança da informação dos serviços mantidos e custodiados
pela empresa.

O departamento de segurança está subordinado à diretoria de operações e contempla a

seguinte estrutura:

O Estudo de Caso foi aplicado em Órgão da Administração Pública Federal Indireta,

numa empresa pública.

De acordo com os requisitos de conformidade à Governança de TI identificados durante

o trabalho, observou-se uma forte relação com questões relacionadas à Segurança da
Informação, tornando apropriado que o estudo de caso fosse aplicado na Coordenação
de Segurança da Informação da organização, especificamente na área de conformidade
em segurança da informação.

Para realização dos trabalhos foram elaborados checklist e roteiros de entrevista, sendo
realizadas entrevistas, oficialmente, com 2 (dois) empregados responsáveis pela área de
conformidade em segurança da informação da organização.

Os trabalhos foram apoiados, ainda, pela prática de reuniões com outros empregados de
áreas relacionadas as atividades de desenvolvimento e de produção de serviços para
esclarecimento do funcionamento e da dinâmica das Estruturas, Processos e
Mecanismos de Governança de TI aplicados na organização.

Contextualização do Cenário

A empresa tem como negócio a prestação de serviços em Tecnologia da Informação e

Comunicações, o que torna o tema de Governança de TI aplicáveis e necessários às
atividades da organização.

Durante a fase de coleta de dados na empresa pública pesquisada, algumas questões

pertinentes à governança de TI foram observadas:

19
- a Governança de TI é tratada de modo informal, não há normativos ou processos
formais relacionados a este tema;

- não foi evidenciada a existência de áreas, na estrutura orgânica da organização,

específicas para tratamento da Governança de TI;

- a gestão de TI está centralizada na Diretoria de Operações da empresa, mas os

processos, tecnologias e pessoas envolvidos na gestão de TI são aplicados de forma
descentralizada pelas áreas que compõem esta diretoria;

- a empresa elegeu 65 (sessenta e cinco) serviços de missão crítica, denominados SMC,

cujas
ações de evolução e melhoria contínua dos processos de TI estão direcionadas a
esses serviços.

As questões relatadas visam proporcionar um entendimento de como a Governança de

TI está presente dentro da organização e, somente após a avaliação das práticas de
governança de TI será possível demonstrar com propriedade a real situação da
Governança de TI na organização estudada.

Para tanto, serão aplicadas técnicas de entrevista de análise de documentos e de

verificação direta, apoiadas por lista de verificações a fim de identificar as estruturas,
processos e mecanismos de conformidade à governança de TI aplicados na organização.

Registros de informações do Estudo de Caso

Durante aplicação de técnicas de entrevista e de análise de documentos, como também

de lista de verificações foi evidenciado o seguinte:

- Comitê Estratégico: foi verificada a existência de Comitê Estratégico de Segurança

da Informação, assim como documento formalizando as responsabilidades do referido
Comitê, sendo, verificado, ainda, que o corpo gerencial de TI compõe aquele Comitê.
Entretanto, a maioria é representada por Diretores e Superintendentes, havendo um
lacuna em relação as decisões relativas ao níveis tático e operacional, que necessitam
de representantes dessas áreas.

- Estrutura Organizacional: foi verificado que a estrutura de TI está formalmente

definida na
estrutura orgânica da organização e publicada no sistema de informações normati
vas da organização.

- Papéis e Responsabilidades de TI: a formalização dos papeis e responsabilidades da

TI é realizada por meio do Documento de Atribuições e Competências (DAC),
publicada no sistema de informações normativas da organização. Entretanto, não foi
evidenciada a aplicação de mecanismos que assegurem a atualização dessas
informações. Dessa forma, não é possível assegurar que as atribuições e competências
constantes na documentação correspondem, efetivamente, às práticas realizadas.

20
- Modelos de maturidade de governança ou de alinhamento de TI: não foi
evidenciada a inexistência de modelos de maturidade de governança ou de alinhamento
de TI.

- Melhores Práticas de Governança e de Gestão de TI: foi verificada a referência ao

COBIT e ITIL em normativos internos da Organização, mas não foi possível evidenciar
a aplicação efetiva dos controles e padrões preconizados nestas melhores práticas como
também os mecanismos de revisão e melhoria continua desses processos.

- Aplicação de BSC nos processos de TI: em análise os processos de negócios e de

Tecnologia da informação, ora apresentados, não foi evidenciada a aplicação de BSC
nos processos de TI.

- Cultura Organizacional: foi observada a fomentação da cultura organizacional no

que tange a segurança da informação, que certa forma, contribui para a governança de
TI.

- Processos de desenvolvimento e de manutenção de sistemas de informação: em

relação aos processos de desenvolvimento e de manutenção de sistemas de informação,
foi verificado que a organização aplica processos corporativos e metodologias baseadas
no Capability Maturity Model Integration - CMMI, sendo verificada, ainda, a aplicação
de mecanismos de avaliação e melhoria contínua do processo de desenvolvimento e de
manutenção de sistemas de informação.

- Gestão de Acordos de Nível de Serviço dos serviços prestados: A Gestão de

Acordos de Nível de Serviço dos serviços prestados, está vinculada a área de gestão
empresarial, que fiscaliza e verifica o cumprimento dos acordos de nível de serviço
prestados pela organização.

- Gestão de Acordos de Nível de Serviço dos serviços contratados: A gestão de

Acordos de Nível de Serviço dos serviços contratados, está vinculada à área de
Administração, que é responsável pela formalização dos procedimentos administrativos
da gestão contratual, sendo que cada contrato de tecnologia possui um gestor que realiza
a fiscalização do contrato, como também, verifica se o Acordo de Nível de Serviço é,
efetivamente, cumprido.

- Gestão de ativos: em relação à gestão de ativos foi evidenciada a realização de ações

isoladas e uso de ferramentas de gestão de configuração/ativos de forma não
padronizadas, vale mencionar, ainda, questões críticas que impactam a Gestão de
Ativos, como, por exemplo, a ausência de uma CMDB, integrada e consistente.

- Classificação de ativos de informação: foi constatado que o processo de

classificação de ativos de informação está mapeado e formalizado por meio de
normativo, mas não foi evidenciada a sua aplicação por parte dos empregados.

- Gestão de capacidade: foi constatado que não há processo de gestão de capacidade

mapeado, documentado e formalizado, como também não há normativos relacionados
ao processo de capacidade.

21
-
Gestão da Continuidade do Negócio: o processo de GCN está mapeado, docu
mentado e instituído por meio de normativo interno. Entretanto, foram identificadas
situações críticas, como por exemplo, os planos de contingência não são,
periodicamente, atualizados.

- Segurança física: o processo de segurança física não está mapeado e os ambientes de

desenvolvimento, de teste, de homologação e de produção não estão fisicamente
segregados.

- Segurança lógica: o processo de segurança lógica está mapeado e, em fase de

implantação, sendo verificado, ainda, a existência de sistema de gestão de identidade
que também está em fase de implementação. Vale citar que na segurança lógica, foram
identificadas questões críticas que impactam na integridade e disponibilidade dos
serviços, como, por exemplo, a ausência de mecanismos de controles relativos à
segurança lógica, no que tange a monitoração de acesso aos dados em produção.

- Gestão de incidentes: foi verificado que o processo de gestão de incidentes está em

fase de implantação, mas não há uma distinção clara quanto a classificação dos
incidentes, ou seja, quando afirmar que se trata, efetivamente, de incidente de segurança
da informação.

- Gestão de Mudanças: o processo de gestão de mudanças é aplicado, geralmente, para

atender mudanças programadas.

- Gestão de problemas: foi constatado que o processo está documentado, mas não foi
possível evidenciar, efetivamente, a sua aplicação.

- Gestão de riscos: o processo de Gestão de riscos está mapeado, documentado e

instituído por meio de normativo interno e são mantidos três sistemas de informação
que apoiam e realizam a automação das atividades de análise, registro e tratamento de
riscos.

- Planejamento estratégico de Sistemas de Informação: não foi evidenciada a

existência de planejamento estratégico de sistemas de informação, mas foi verificado
que no Planejamento Estratégico da Organização são tratadas questões relacionadas aos
Sistemas de Informação, como por exemplo a aquisição/desenvolvimento de
softwares/ferramentas.

-Política de Segurança da Informação: Em relação à Política de Segurança da

Informação foi evidenciada a existência de Política de Segurança da Informação – PSI,
documentada e formalizada.

Em relação à aplicação de mecanismos de Governança de TI, foi verificado o seguinte:

- Colaboração entre os principais stakeholders: a existência de mecanismos que

promovam a colaboração entre os principais stakeholders, foi verificada a aplicação de
reuniões semanais com os clientes, como também o compartilhamento de pontos de
monitoração e controle com o cliente, como por exemplo, acesso a softwares/sistemas
de monitoração do serviço, mas é um mecanismo facultativo.

22
- Entendimento compartilhado dos objetivos do negócio e da TI: a aplicação de
mecanismos que
promovam o entendimento compartilhado dos objetivos do negócio e da
TI, foi verificada a existência de mecanismos, como por exemplo, o Planejamento
estratégico da TI com a participação
e envolvimento das áreas de negócio e o preenchimento de artefato da área de p
rojetos que envolvem a área de TI e área de Negócio.

- Posição do negócio e da TI na Organização: foi verificado que a área de negócio

comanda o direcionamento da TI, pois ela tem autoridade sobre as decisões da TI, como
também define as prioridades de serviços da TI.

Sendo, verificado, ainda que há uma supervalorização do negócio por parte da

organização, não havendo a preocupação se a
TI pode não ter os recursos para atender de forma razoável as expectativas do
negócio, como também assegurar a entrega do serviço.

- Mecanismos que promovam o Negócio Multifuncional: não foi evidenciada a

existência de mecanismos que promovam o Negócio Multifuncional, considerando o
treinamento cruzado (cross- training), ou seja, equipes de TI sendo treinadas no
Negócio e equipes de negócio treinadas na TI, proporcionando a formação em
diferentes tarefas e habilidades.

- Rotação de tarefas: não foi evidenciada a rotação de tarefas (profissionais crossover),

ou seja, objetivando o negócio multifuncional, equipes de TI trabalhando no negócio e
equipes de negócio trabalhando na TI.

- Mecanismos que promovam a gestão do conhecimento: foi evidenciada a existência

dos seguintes mecanismos: ambiente de colaboração denominado “wiki” para registro e
compartilhamento de conhecimento; Política de Gestão do
Conhecimento; treinamentos internos, com foco no negócio, envolvendo a área de
negócio e a área de TI.

- Mecanismos que promovam parcerias, recompensas ou incentivos: foram

evidenciados os seguintes mecanismos: Processo de Promoção por Mérito e de
Participação nos lucros da empresa.

-
Participação dos principais stakeholders: não foi possível evidenciar a existênc
ia de mecanismos que promovam a participação ativa dos stakeholders principais,
como também, de mecanismos que promovam o tratamento de conflitos ativos na
organização.

RESULTADOS

Com o intuito de atingir o objetivo proposto neste trabalho de pesquisa, foram

identificados por meio de fontes de informação acadêmica requisitos de conformidade à
Governança de TI.

23
Nesta primeira parte da pesquisa foi possível constatar que para se estabelecer a
conformidade em Governança de TI é necessário estabelecer que requisitos são
necessários à implementação da Governança de TI, sendo assim, foi verificado que a
Governança de TI pode envolver requisitos que contemplam Estruturas, Processos e
Mecanismos, conforme apresentados na Tabela01, considerando que:

- as Estruturas envolvem a existência de papeis de responsabilidade, como os executivos

de TI e Comitês de TI;

- os Processos referem-se ao monitoramento e a tomada de decisões estratégicas; e

- os Mecanismos de Relacionamento incluem a participação da TI e do negócio, o

diálogo estratégico, o conhecimento compartilhado e a comunicação adequada.

24
25
A identificação de requisitos de conformidade à Governança de TI, constantes da
literatura acadêmica proporcionou estabelecer um caminho para implementação da
Governança de TI de forma geral, mas não possibilitou visualizar se tais requisitos
atendem de forma razoável requisitos de conformidade à Governança de TI, aplicados
em Órgãos da Administração Pública Federal indireta, particularmente, em empresas
públicas.

Diante de tal situação, foi identificada, ainda, a necessidade de levantamento de

requisitos que assegurem a conformidade à Governança de TI, constantes de fontes de
informação de órgãos reguladores e de Governo. A análise das referidas fontes de
informação, resultou nos requisitos de conformidade apresentados na tabela02.

Os requisitos de conformidade foram estruturados com base nas seguintes informações:

26
- Recomendações realizadas por meio de trabalhos de auditoria em Órgãos de
Fiscalização e Controle, como o Tribunal de Contas da União, em Órgãos da
Administração Pública Federal indireta.

- Determinações constantes em fontes de informação de Governo, como: Normas e

Instruções Normativas.

Os requisitos de conformidade à Governança de TI inicialmente devem ser cumpridos

pelas
empresas públicas, considerando que se referem às determinações constantes da l
egislações, Normas e Instruções Normativas do Governo Federal do Brasil, como
também às Recomendações oriundas de Órgãos de Fiscalização e Controle, como por
exemplo, do Tribunal de Contas da União.

Durante o trabalho de análise de fontes de informação de órgãos reguladores e de

Governo, foi observada referência às melhores práticas de Governança e de Gestão de
TI, como: o Cobit, o PMBOK, a ITIL e a Norma ISO/IEC 27002, ocasionando, a
necessidade de verificação da relação destes requisitos com aqueles identificados em
fontes de informação acadêmica e de órgãos reguladores, conforme apresentado na
Tabela03.

27
Após análise e, consolidação das informações relativas a Governança de TI, constantes
das tabelas 1, 2 e 3, foi realizada a junção destes requisitos, resultando na elaboração da
tabela04.

28
29
De posse dos requisitos consolidados, foi possível estabelecer um plano de trabalho para
aplicação de estudo de caso, a fim de verificar à conformidade destes requisitos no
âmbito da Administração Pública Federal Brasileira, especificamente, numa empresa
pública.

Após a aplicação de estudo de caso, considerando a verificação de cumprimento de 32

requisitos de conformidade à Governança de TI, foi possível constatar que 37% dos
requisitos são, efetivamente, aplicados, 41% são parcialmente aplicados e 22% não são
aplicados, conforme Quadro 1.

Vale mencionar que diante das informações e evidências apresentadas pela organização,
foi possível observar que o cumprimento aos requisitos de conformidade, estão
fortemente relacionados às recomendações e orientações governamentais, como por
exemplo, do Tribunal de Contas da União e do Ministério do Planejamento, Orçamento
e Gestão e da Presidência da República.

Foi verificado, com base na tabela 4: requisitos de conformidade à governança de TI,

que 37% dos requisitos, considerando a situação de “atendidos” e “parcialmente
atendidos”, atendem tanto as fontes de informação da literatura acadêmica, como
também as fontes de informação de Órgãos reguladores, a Legislação Brasileira e às
melhores práticas, conforme Quadro 2.

Foi verificado, ainda, que requisitos de conformidade à Governança de TI que at

endem exclusivamente aos requisitos de governança identificados na literatura

30
acadêmica e, representam 34% dos requisitos de conformidade à Governança de TI,
conforme Quadro 3.

Vale citar, de acordo com as informações apresentadas por empregados da orga

nização, os requisitos de conformidade à Governança de TI, procedentes de órgãos de
fiscalização e controle e a legislação vigente tem prioridade no cumprimento pela
organização, principalmente aqueles relacionados aos Acórdãos do TCU.

Sendo, assim, foi possível constatar que os requisitos supracitados são direcionadores à
Governança de TI da organização, e as recomendações procedentes dos Órgãos de
fiscalização e controle, de certa forma, alavancam a Governança de TI da organização.

Diante das informações apresentadas no Quadro01 é possível inferir que a aplicação de

requisitos de conformidade à Governança de TI aplicados no âmbito da
Administração Pública Federal Brasileira, especificamente, empresas públicas, visam
atender, fortemente, o cumprimento à legislação Brasileira e às recomendações de
Órgãos de Fiscalização e Controle.

Processos da gerência de projetos

Origem: Wikipédia, a enciclopédia livre.

Segundo o guia PMBOK - 4ª Edição, um processo é um conjunto de ações e atividades

inter-relacionadas, que são executadas para alcançar um produto, resultado ou serviço
predefinido. Cada processo é caracterizado por suas entradas, as ferramentas e as
técnicas que podem ser aplicadas e as saídas resultantes. Projeto é um esforço
temporário empreendido para criar um produto, serviço ou resultado exclusivo.

Processos se enquadram em duas categorias:

31
 1. Processos da gerência de projetos : se relacionam com a descrição, a organização e a
conclusão do trabalho do projeto. São universais a todos os projetos, pois controlam o
ciclo de vida do gerenciamento de projetos.
2. Processos orientados ao produto : se relacionam com a especificação e a criação do
produto do projeto, sendo exclusivos a cada produto. São definidos pelo ciclo de vida
do projeto, e variam de acordo com a área de aplicação.

Grupos de processos
De acordo com o PMBOK, os processos de gerenciamento de projetos podem ser
organizados em cinco grupos de processos:

1. Processos de Iniciação – autorização do projeto ou fase

2. Processos de Planejamento – são processos iterativos de definição e refinamento de
objetivos e seleção dos melhores caminhos para atingir os objetivos.
3. Processos de Execução – execução dos planos do projeto: coordenação de pessoas e
outros recursos para executar o plano
4. Processos de Monitoramento e Controle – medição e monitoramento do
desempenho do projeto. Garantem que os objetivos do projeto são alcançados através
do monitoramento e medição regular do progresso, de modo que ações corretivas
possam ser tomadas quando necessário.
5. Processos de Encerramento – aceitação formal do projeto (com verificação de escopo)
ou fase para a sua finalização.

Os grupos de processo são ligados pelos resultados que produzem: o resultado de um

processo frequentemente é a entrada de outro. Os cinco grupos de processos possuem
conjuntos de ações que levam o projeto adiante, em direção ao seu término.

Dentro dos cinco grupos de processos existiam duas categorias de processos: básicos
e facilitadores. Esses termos foram eliminados para garantir que todos os processos de
gerenciamento de projetos nos grupos de processos de gerenciamento de projetos
tenham o mesmo nível de importância.

As atividades no caminho crítico são monitoradas ativamente quanto a deslizes,

enquanto os deslizes nas atividades do caminho não crítico são verificados
periodicamente.

Repetir os processos de iniciação antes da execução de cada fase é uma maneira de se

avaliar se o projeto continua cumprindo as necessidades de negócio. Envolver as partes
interessadas no projeto em cada uma das fases é uma maneira de aumentar as
probabilidades de satisfação dos requisitos do cliente, além de servir para fazê-los
sentirem-se envolvidos no projeto – o que muitas vezes é essencial para o sucesso do
mesmo.

O gerente de projetos precisa monitorar e comunicar o desempenho do projeto. Os

resultados do trabalho que estiverem abaixo de um nível de desempenho aceitável
precisam ser ajustados com ações corretivas para que o projeto volte a estar em
conformidade com as linhas de base de custo, prazo e escopo. A comunicação do
desempenho do projeto é um dos principais elementos para o gerenciamento de projetos
bem sucedido.

32
Interações de Processos
Dentro de cada grupo de processos, os processos individuais podem ser ligados pelas
suas entradas (inputs) e saídas (outputs). Focando nessas ligações, podemos descrever
cada processo nos termos de seus:

1. Entradas (inputs)– documentos ou itens que serão trabalhados pelo processo

2. Ferramentas e técnicas – mecanismos aplicados aos inputs para criar os outputs
3. Saídas (outputs)– documentos ou itens que serão o resultado final do processo.

Esses três componentes de processo transformam decisões, condições, planos e reações

em condições e progresso. A saída de um processo geralmente é a entrada para outro.
Dentro de cada processo, as ferramentas e técnicas usadas num processo orientam e
influenciam a sua saída. Uma saída com falhas pode comprometer a entrada de
processos dependentes.

Os processos podem ser, até certo ponto, customizáveis (personalizados) a cada projeto.
Podem ser modificados, ou até excluídos, para melhor atender as particularidades de
dado projeto. No entanto, essas modificações devem ser feitas criteriosamente.

Áreas de Conhecimento da Gerência de Projetos:

Processos
As nove áreas de conhecimento são compostas por 42 (quarenta e dois) processos de
gerenciamento de projetos. O Guia de Conhecimentos em Gerenciamento de Projetos
(PMBOK 2004, 4ª Edição) descreve as áreas de conhecimento em capítulos, listados a
seguir:

1. Introdução
2. Ciclo de vida e organização do projeto
3. Processos de gerenciamento de projetos de um projeto
4. Gerenciamento de integração do projeto – descreve os processos requeridos para
certificar-se que os vários elementos do projeto estão propriamente coordenados.
Consiste em:
1. Desenvolver o termo de abertura do projeto (In.)
2. Desenvolver o plano de gerenciamento do projeto (Pl.)
3. Orientar e gerenciar a execução projeto (Ex.)
4. Monitorar e controlar o trabalho do projeto (Mo.)
5. Executar o controle integrado de mudanças (Mo.)
6. Encerrar o projeto ou fase. (En.)
5. Gerenciamento do escopo do projeto – descreve os processos requeridos para garantir
que o projeto inclui todo o trabalho requerido (requisitos), e somente o trabalho
requerido, para completar o processo com sucesso. Consiste em:
1. Coletar requisitos (Pl.)
2. Definir o escopo (Pl.)
3. Criar a Estrutura Analítica de Processo (EAP) (Pl.)
4. Verificar o escopo (Mo.)
5. Controlar do escopo (Mo.)

33
 6. Gerenciamento de tempo de projeto – descreve os processos requeridos para garantir
que o projeto seja completado dentro do prazo. Consiste em:
1. Definir atividades (Pl.)
2. Sequenciar atividades (Pl.)
3. Estimar de recursos da atividade (Pl.)
4. Estimar de duração da atividade (Pl.)
5. Desenvolver do cronograma (Pl.)
6. Controlar do cronograma (Mo.)
7. Gerenciamento de custos do projeto – descreve os processos requeridos para que o
projeto seja completado dentro do orçamento aprovado. Consiste em:
1. Estimar de custos (Pl.)
2. Determinar o orçamento (Pl.)
3. Controlar custos (Mo.)
8. Gerenciamento da qualidade do projeto – descreve os processos requeridos para
garantir que o projeto vai satisfazer as necessidades pelas quais ele foi feito. Consiste
em:
1. Planejar a qualidade (Pl.)
2. Realizar a garantia da qualidade (Ex.)
3. Realizar o controle da qualidade (Mo.)
9. Gerenciamento de recursos humanos do projeto – descreve os processos requeridos
para fazer o uso mais efetivo das pessoas envolvidas no projeto. Consiste em:
1. Desenvolver o plano de recursos humanos (Pl.)
2. Contratar ou mobilizar a equipe do projeto (Ex.)
3. Desenvolver a equipe de projeto (Ex.)
4. Gerenciar a equipe de projeto (Ex.)
10. Gerenciamento das comunicações do projeto – descreve os processos requeridos para
garantir rápida e adequada geração, coleção, disseminação, armazenamento e
disposição final das informações do projeto. Consiste em:
1. Identificar as partes interessadas (In.)
2. Planejar as comunicações (Pl.)
3. Distribuir as informações (Ex.)
4. Gerenciar as expectativas das partes interessadas (Ex.)
5. Relatar desempenho (Mo.)
11. Gerenciamento de riscos do projeto – descreve os processos relacionados a identificar,
analisar e responder aos riscos do projeto. Consiste em:
1. Planejar o gerenciamento de riscos (Pl.)
2. Identificar riscos (Pl.)
3. Realizar a análise qualitativa de riscos (Pl.)
4. Realizar a análise quantitativa de riscos (Pl.)
5. Planejar respostas aos riscos (Pl.)
6. Monitorar e controlar riscos (Mo.)
12. Gerenciamento de aquisições do projeto – descreve os processos requeridos para
adquirir bens e serviços de fora da organização "dona" do projeto. Consiste em:
1. Planejar aquisições (Pl.)
2. Conduzir aquisições (Ex.)
3. Administrar aquisições (Mo.)
4. Encerrar aquisições (En.)

Referências gerais
 Barros, Carlos. "Gestão de Projectos": Editora Sílabo, 1ª Edição, 1994 ISBN 9726180864

34
Project Management Body of Knowledge
Origem: Wikipédia, a enciclopédia livre.

'Project Management Body of Knowledge'

Autor (es) Project Management Institute

Idioma <código de língua não reconhecido>

País Estados Unidos

Género Gerência de projetos

Lançamento 2008

ISBN 978-1-933890-51

O guia Project Management Body of Knowledge, também conhecido como PMBOK

é um livro que apresenta um conjunto de práticas em gestão de projectos (português europeu)
ou gerenciamento de projetos (português brasileiro) publicado pelo Project Management
Institute e constitui a base do conhecimento em gerenciamento de projetos do PMI. A
5a Edição (2013) é o documento resultante do trabalho atual realizado pelo Project
Management Institute (PMI Product - 00101388701/ISBN13 - 9781935589679). O
instituto American National Standards Institute (ANSI) que assegura os padrões nos
Estados Unidos da América, define a 4a versão como (ANSI/PMI 99-001-2008) o
Institute of Electrical and Electronics Engineers define a 4a versão como IEEE 1490-
2011.1 para Guia de Gerenciamento de Projetos do PMI.

Histórico
O Guia PMBOK foi publicado pela primeira vez pelo Project Management Institute
(PMI) como um white paper em 1983 na tentativa de documentar e padronizar as
práticas que são normalmente aceitas na gerência de projetos. A primeira edição foi
publicada em 1996, seguida pela segunda edição em 2000. . 2

Em 2004, o Guia PMBOK — Terceira Edição — foi publicado com maiores mudanças,
considerando as edições anteriores. A última versão do Guia PMBOK é a quinta edição
que foi publicada em 2013 em Inglês. Traduções estão disponíveis em Árabe, Chinês,
Francês, Alemão, Italiano, Japonês, Coreano, Português, Russo e Espanhol.

Definição

35
O Guia PMBOK identifica um subconjunto do conjunto de conhecimentos em
gerenciamento de projetos, que é amplamente reconhecido como boa prática, sendo em
razão disso, utilizado como base pelo Project Management Institute (PMI). Uma boa
prática não significa que o conhecimento e as práticas devem ser aplicadas
uniformemente a todos os projetos, sem considerar se são ou não apropriados.

O Guia PMBOK também fornece e promove um vocabulário comum para se discutir,

escrever e aplicar o gerenciamento de projetos possibilitando o intercâmbio eficiente de
informações entre os profissionais de gerência de projetos.

O guia é baseado em processos e subprocessos para descrever de forma organizada o

trabalho a ser realizado durante o projeto. Essa abordagem se assemelha à empregada
por outras normas como a ISO 9000 e o Software Engineering Institute's, CMMI.

Os processos descritos se relacionam e interagem durante a condução do trabalho. A

descrição de cada um deles é feita em termos de:

 Entradas (documentos, planos, desenhos etc.);

 Ferramentas e técnicas (que se aplicam às entradas);
 Saídas (documentos, produtos etc.)

Ciclo de Vida e da Organização de um projeto

O Guia PMBOK em sua 5° Edição provê diretrizes para gerência dos projetos
individualmente e define conceitos associados à gerência de projetos. Isto também
descreve o ciclo de vida do gerenciamento do projeto e seus processos relacionados,
assim como o ciclo de vida do projeto. 3

O Guia PMBOK reconhece 47 processos que recaem em 5 grupos de processos e 10

áreas de conhecimento que são típicas em quase todas áreas de projetos.

 Descrição dos grupos de processos de gerenciamento de projetos:

1. Iniciação
2. Planejamento
3. Execução
4. Monitoramento e controle
5. Encerramento

Conjunto de conhecimentos de acordo com o Guia PMBOK 4° e 5° edição

e ISO21500

O Guia PMBOK cita os seguintes conjuntos de conhecimentos:

Guia PMBOK 4° Edição Guia PMBOK 5° Edição

ISO21500 (2013)
(2008) (2013)

Estágios 5 grupos de processos 5 grupos de processos 5 grupos de processos

36
 10 áreas de
Tópicos 9 áreas de conhecimento 10 áreas de conhecimento
conhecimento

Processos 42 processos 39 processos 47 processos

Áreas de conhecimento do Guia PMBOK 4° e 5° edição

O conhecimento de gerenciamento de projetos, descrito no Guia PMBOK consiste nas

seguintes áreas de conhecimento:

 Descrição das dez áreas de conhecimento:

1. Gerenciamento/Gestão de integração do projeto

2. Gerenciamento/Gestão do escopo do projeto
3. Gerenciamento/Gestão de tempo do projeto
4. Gerenciamento/Gestão de custos do projeto
5. Gerenciamento/Gestão da qualidade do projeto
6. Gerenciamento/Gestão de recursos humanos do projeto
7. Gerenciamento/Gestão das comunicações do projeto
8. Gerenciamento/Gestão de riscos do projeto
9. Gerenciamento/Gestão de aquisições do projeto
10. Gerenciamento/Gestão de envolvidos do projeto (adicionada na 5a Edição)

Conjunto de conhecimentos de acordo com o Guia PMBOK 4° e 5° edição

e ISO21500

Guia PMBOK 4° Edição Guia PMBOK 5° Edição

ISO21500 (2013)
(2008) (2013)

1.Iniciação 1.Iniciação
1.Iniciação
2.Planejamento 2.Planejamento
2.Planejamento
Grupos de 3.Execução 3.Execução
3.Execução
Processos 4.Monitoramento e 4.Monitoramento e
4.Controle
Controle Controle
5.Encerramento
5.Encerramento 5.Encerramento

1.Integração 1.Integração
1.Integração
2.Escopo 2.Escopo
2.Escopo
3.Tempo 3.Tempo
3.Tempo
4.Custo 4.Custo
4.Custo
Áreas de 5.Qualidade 5.Qualidade
5.Qualidade
Conhecimento 6.Recursos 6.Recursos Humanos
6.Recursos Humanos
7.Comunicações 7.Comunicações
7.Comunicações
8.Riscos 8.Riscos
8.Riscos
9.Aquisições 9.Aquisições
9.Aquisições
10.Partes 10.Partes Interessadas

37
 Interessadas

Extensões do PMBOK

O PMBOK atualmente define extensões ao Guia PMBOK. São elas:

 Extensão para Construção - Construction Extension to the PMBOK Guide — 3a Edição

(em inglês)
 Extensão para Governo - Government Extension to the PMBOK Guide — 3a Edição (em
inglês)

O PMBOK também define padrões específicos ao Guia PMBOK. São eles:

 Padrão para Gerenciamento de Programa - The Standard for Program Management —

2a Edição (em inglês)
 Padrão para Gerenciamento de Portifólio - The Standard for Portfolio Management —
3a Edição (em inglês)
 Modelo de Maturidade para Gerenciamento de Projetos Organizacionais -
Organizational Project Management Maturity Model (OPM3®) — 2a * Edição (em
inglês)

Processos do Guia PMBOK 4° edição

Áreas de Monitoramento
Iniciação Planejamento Execução Encerramento
Conhecimento e controle

4. Monitorar e
controlar o
1.
2. Desenvolver 3. Orientar e trabalho do
Desenvolver 6. Encerrar o
o plano de gerenciar a projeto
Integração o termo de projeto ou
gerenciamento execução do 5. Realizar o
abertura do fase1
do projeto projeto controle
projeto
integrado de
mudanças

1. Coletar os
4. Verificar o
requisitos
escopo
Escopo 2. Definir o
5. Controlar o
escopo
escopo
3. Criar a EAP

1. Definir as
atividades 6. Controlar o
Tempo
2. Sequenciar as cronograma
atividades

38
 3. Estimar os
recursos das
atividades
4. Estimar as
durações das
atividades
5. Desenvolver
o cronograma

1. Estimar os
custos 3. Controlar os
Custos
2. Determinar o custos
orçamento

2. Realizar a 3. Realizar o
1. Planejar a
Qualidade garantia de controle da
qualidade
qualidade qualidade

2. Mobilizar a
equipe do
projeto
1. Desenvolver 3.
Recursos o plano de Desenvolver
Humanos recursos a equipe de
humanos projeto
4. Gerenciar
a equipe do
projeto

3. Distribuir
as
informações
1. Identificar
2. Planejar as 4. Gerenciar 5. Reportar o
Comunicação as partes
comunicações as desempenho
interessadas
expectativas
das partes
interessadas

1. Planejar o
gerenciamento
dos riscos 6. Monitorar e
Riscos 2. Identificar os controlar os
riscos riscos
3. Realizar a
análise

39
 qualitativa dos
riscos
4. Realizar a
análise
quantitativa dos
riscos
5. Planejar as
respostas aos
riscos

1. Planejar as 2. Conduzir 3. Administrar as 4. Encerrar as

Aquisição
aquisições as aquisições aquisições aquisições

Processos do Guia PMBOK 5° edição

Áreas de Monitoramento
Iniciação Planejamento Execução Encerramento
Conhecimento e controle

1.4. Monitorar e
controlar o
1.1. 1.2.
1.3. Orientar e trabalho do
Desenvolver Desenvolver o 1.6. Encerrar o
gerenciar o projeto
Integração o termo de plano de projeto ou
trabalho do 1.5. Realizar o
abertura do gerenciamento fase
projeto controle
projeto do projeto
integrado de
mudanças

2.1. Planejar o
Gerenciamento
do Escopo 2.5. Validar o
2.2. Coletar os escopo
Escopo
requisitos 2.6. Controlar o
2.3. Definir o escopo
escopo
2.4. Criar a EAP

3.1. Planejar o
gerenciamento
do Cronograma 3.7. Controlar o
Tempo 3.2. Definir as cronograma
atividades
3.3. Sequenciar
atividades

40
 3.4. Estimar os
recursos das
atividades
3.5. Estimar as
durações das
atividades
3.6.
Desenvolver o
cronograma

4.1. Planejar o
gerenciamento
dos Custos
4.4. Controlar os
Custos 4.2. Estimar
custos
custos
4.3. Determinar
o orçamento

5.1. Planejar o 5.2. Realizar a

5.3. Controlar a
Qualidade gerenciamento garantia de
qualidade
da qualidade qualidade

6.2. Mobilizar
a equipe do
projeto
6.1. Planejar o 6.3.
Recursos gerenciamento Desenvolver a
Humanos dos recursos equipe do
humanos projeto
6.4. Gerenciar
a equipe do
projeto

7.1 Planejar o
7.2. Gerenciar
gerenciamento 7.3. Controlar as
Comunicações as
das comunicações
comunicações
comunicações

8.1. Planejar o
gerenciamento
dos riscos 8.6. Controlar os
Riscos 8.2. Identificar riscos
os riscos
8.3. Realizar a
análise

41
 qualitativa dos
riscos
8.4. Realizar a
análise
quantitativa dos
riscos
8.5. Planejar as
respostas aos
riscos

9.1. Planejar o
9.2. Conduzir 9.3. Controlar as 9.4. Encerrar
Aquisição gerenciamento
as aquisições aquisições as aquisições
das aquisições

10.3.
10.1. 10.2. Planejar o 10.4. Controlar o
Gerenciar o
Partes Identificar gerenciamento envolvimento
envolvimento
Interessadas partes das partes das partes
das partes
interessadas interessadas interessadas
interessadas

References
1. IEEE (2011), IEEE Guide--Adoption of the Project Management Institute (PMI(R))
Standard A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide)--
Fourth Edition
2. A Guide to the Project Management Body of Knowledge, copyright page, edition 2
ISBN 1-880410-12-5 (free .pdf edition), e a terceira edição em 2004 ISBN 978-1-
930699-45-8, e quarta edição em 2008 ISBN 1-933890-51-7
3. PMI (2012), A Guide to the Project Management Body of Knowledge, 5th Ed.

Referências
1. CMBoK < CM < Foswiki. Cmcrossroads.com. Página visitada em 2011-09-28.

Bibliografia
 A Guide to the Project Management Body of Knowledge (PMBOK Guide). Third
Edition ed. [S.l.]: Project Management Institute. ISBN 1-930699-45-X

42
Gerenciamento de Processos de Negócio

Para que uma empresa tenha sucesso, seja ela de grande ou pequeno porte, esta precisa
essencialmente ter uma boa administração, pois uma empresa que não tem
planejamento, organização e controle e não saiba quais os objetivos que pretende
alcançar não consegue atingir nenhum resultado.

O Gerenciamento de Processos de Negócio (português brasileiro) ou Gestão de Processos de

Negócio (português europeu) (em inglês Business Process Management ou BPM) é um
conceito que une gestão de negócios e tecnologia da informação com foco na
otimização dos resultados das organizações através da melhoria dos processos de
negócio.

BPM tem sido referenciado com uma introdução ao gerenciamento holístico 1 para
alinhar processos de negócio das organizações com as necessidades dos clientes. Isto
promove o negócio com efetividade e eficiência enquanto se esforça para obter
inovação, flexibilidade e integração com a tecnologia. BPM procura obter a melhora dos
processos continuamente. Isto pode no entanto ser descrito como otimização de
processo. É discutido que o BPM permite que organizações sejam mais eficientes, mais
efetivas e com maior capacidade de mudanças do que aquelas com foco funcional, com
abordagem de gerenciamento tradicional hierárquico. 2

São utilizados métodos, técnicas e ferramentas para analisar, modelar, publicar, otimizar
e controlar processos envolvendo recursos humanos, aplicações, documentos e outras
fontes de informação.

BPM: visão Tecnologia da Informação

A utilização do BPM, ao longo dos últimos anos, vem crescendo de forma bastante
significativa, dada a sua utilidade e rapidez com que melhora os processos nas empresas
onde já foi implementado. A sua perspectiva de crescimento é muito grande, visto que
ainda é um conceito pouco conhecido, principalmente no Brasil.

O termo 'processos operacionais' se refere aos processos de rotina (repetitivos)

desempenhados pelas organizações no seu dia-a-dia, ao contrário de 'processos de
decisão estratégica', os quais são desempenhados pela alta direção. O BPM difere da
remodelagem de processos de negócio, uma abordagem sobre gestão bem popular na
década de 90, cujo enfoque não eram as alterações revolucionárias nos processos de
negócio, mas a sua melhoria contínua.

Adicionalmente, as ferramentas denominadas sistemas de gestão de processos do

negócio (sistemas BPM) monitoram o andamento dos processos de uma forma rápida e
barata. Dessa forma, os gestores podem analisar e alterar processos baseados em dados
reais e não apenas por intuição.

A alta direção da empresa pode enxergar, por exemplo, onde estão os gargalos, quem
está atrasando (e o quanto está atrasando) determinada tarefa, com que frequência isso
ocorre, o percentual de processos concluídos e em andamento, entre outros. Como

43
conseqüência, fatores cruciais para o bom desempenho da organização podem ser
analisados com extrema facilidade e rapidez o que geralmente não ocorre com outras
ferramentas que não o BPM.

Além disso, as pessoas participantes do processo também são beneficiadas: com o

BPM, elas têm o seu trabalho facilitado uma vez que recebem tarefas e devem
simplesmente executá-las sem se preocupar com aspectos como, por exemplo, para
onde devem enviá-las uma vez que o processo já foi desenhado e todas as possíveis
situações de seguimento deste já estão registradas. Adicionalmente, os indivíduos
podem enxergar como foi o caminho realizado até a sua atividade e em que status está.
Os softwares responsáveis pela automação destas atividades são chamados de Business
Process Management Suites, ou BPMS.

BPM: visão Gestão de Negócios

Nos anos 80, a Gestão pela Qualidade Total estava no topo da lista de prioridades das
empresas em todo o mundo. Na década de 90, Michael Hammer e James Champy
lançaram o artigo "Don’t automate, obliterate" pela Harvard Business Review. Esse
artigo foi o marco da chamada onda de BPR (Business Process Reengineering) ou
Reengenharia de Processos.

Em 2006, Howard Smith e Peter Fingar lançaram o livro "Business Process

Management: The Third Wave" com os conceitos de Gerenciamento de Processos de
Negócios. O BPM se tornou então o assunto mais importante nas empresas. Como
especialistas em TI, os autores focaram o BPM como sendo uma automação de
processos através de ferramentas de software.

É importante ressaltar alguns pontos, em relação ao BPM, para os gestores interessados

em implantar o Gerenciamento de Processos de Negócios para alavancar os resultados
de suas organizações. 1) O BPM é um enfoque avançado de otimização e transformação
de processos que evoluiu a partir das experiências das ondas anteriores (Gestão pela
Qualidade Total, BPR). 2) Os BPMS (ferramentas de software) não são o BPM
(Gerenciamento de Processos de Negócios). As ferramentas de software utilizadas para
automação dos processos são desejáveis, porém não devem ser o foco. O foco deve ser a
melhoria e transformação de processos de negócios para que as organizações possam
alcançar os resultados esperados do negócio: aumento de produtividade, redução de
burocracia, melhoria na rentabilidade, redução de defeitos e desperdícios, satisfação e
fidelização de clientes.

Outro ponto de atenção é que implantar o BPM (Gerenciamento de Processos de

Negócios) em uma empresa não é simples, não é rápido, envolve mudança de
comportamento das pessoas e comprometimento da alta administração. Por último, o
uso do enfoque de Gerenciamento de Processos de Negócios se torna essencial para o
sucesso de um projeto de implantação de BPM. Não necessariamente se deve contratar
uma consultoria especializada, desde que os gerentes tenham conhecimento e preparo
adequado no assunto e a organização coloque o BPM como prioridade.

Business Process Management (BPM) tem como objetivo conectar a estratégia ao foco
do cliente através de processos melhores.

44
O Gerenciamento de Processos de Negócios utiliza as melhores práticas de gestão, tais
como: mapeamento de processos, modelagem, definição de nível de maturidade,
documentação, plano de comunicação, automação, monitoramento através de
indicadores de desempenho e ciclo de melhoria e transformação contínua. O objetivo é a
melhoria e transformação contínua dos processos para se atingir os resultados
esperados.

Essas práticas aplicadas ajudam a maximizar os resultados e o desempenho dos

processos, permitindo às organizações melhor rentabilidade, vantagem competitiva,
redução de custos, otimização de recursos, aumento da satisfação dos clientes através de
produtos e serviços em nível superior de qualidade.

O papel das pessoas no BPM

Uma das vertentes do BPM é o foco nas pessoas (human-centric), sendo estas o centro
dos processos de negócio. Alguns BPMS vêm seguindo esta corrente buscando oferecer
às partes interessadas (usuários, atores de processos, envolvidos) maior facilidade e
flexibilidade no uso, o que torna a experiência mais agradável, com ferramentas simples
e intuitivas.

Automação

A automação de processos de negócio é uma prática extremamente eficaz. Quando se

automatizam processos, rapidamente é possível obter-se um controle mais rígido e
adaptado às necessidades da empresa. É realizada pelos BPMS (Business Process
Management Suites) e têm baixo custo. Algumas empresas comercializam os suites por
processos, e não pelo pacote completo, o que torna ainda mais acessível. Através da
automação, um serviço melhor é oferecido ao cliente, dada a rapidez e organização que
a empresa passará a apresentar. Além disso, terá seus custos reduzidos.

Modelagem

A modelagem de processos é feita nos próprios BPMS, alguns dos quais seguem a
notação mais usada atualmente, o BPMN (Business Process Modeling Notation), que
consiste em uma série de ícones padrões para o desenho de processos, o que facilita o
entendimento. Esta é uma etapa importante da automação pois é nela que os processos
são descobertos e desenhados e também pode ser feita alguma alteração no percurso do
processo visando a sua otimização.

Simulação

Após o desenho e o estabelecimento dos atores de processos, pode ser feita uma
simulação, onde se pode testar se as regras pré-estabelecidas estão de acordo com o
objetivo da empresa e se as tarefas estão sendo encaminhadas para as pessoas corretas.

Execução

A execução do processo ocorre após as etapas anteriores já terem sido realizadas. O

BPMS utilizado faz com que as tarefas sejam enviadas para os seus devidos

45
responsáveis, controlando o seu tempo de execução por pessoa e pelo processo em
geral. Podem ser utilizadas também regras de negócio (Business Rules) pré-
estabelecidas.

Controle

O controle ideal de BPM é aquele que está presente durante todas as etapas do processo:
antes, durante e depois. Desde o início da modelagem até a análise pós-conclusão da
execução, o controle deve ser realizado. Um tipo de controle que existe em alguns
BPMS são relatórios de fluxos em andamento, onde é fornecido o status do fluxo, com
quem está parado, há quanto tempo está parado, etc. Isso é importante para evitar que os
erros sejam encontrados somente quando o processo é concluído. Há também relatórios
de fluxos concluídos, onde se pode ter uma noção geral de como se desenvolveu o
processo. Alguns softwares apresentam gráficos e relatórios com bastantes detalhes dos
processos.

Otimização

A otimização tem crucial importância quando se trata de BPM. É essencial para que
sejam feitas melhorias nos processos de modo a alcançar resultados positivos mais
rapidamente, melhorando o serviço aos clientes e, possivelmente, com menores custos.
Depende, obviamente, das etapas anteriores, principalmente do controle, onde deve
haver uma busca pela perfeição.

Tecnologia BPM

Alguns definem como Sistemas BPM (BPMS - Business Process Management System)
ou Suite como "o todo do BPM". Outros relatam a importância do conceito da
movimentação da informação entre pacotes de software corporativos e imediatamente
pensam na Arquitetura Orientada a Serviços (SOA). Outros ainda limitam a definição a
"modelagem" (veja de processo de negócio).

Bibliografia
 ABPMP. "BPM CBOK - Common Body of Knowledge" -
http://www.amazon.com.br/dp/B00I1KWWZ2
 Paim, R. et al. Gestão de Processos: Pensar, Agir e Aprender, Editora Bookman
(2009). ISBN 8577804844. Cap. 1 Disponível para download pelo site
http://www.grupoa.com.br
 Jeston, John e Nelis, Johan. "Business Process Management: Practical
Guidelines to Successful Implementations". Editora Butterworth-Heinemann
(2008).ISBN 0750686561
 Becker, Jörg; Kugeler, Martin e Rosemann, Michael. "Process Management".
Editora Springer (2003).ISBN 3540434992
 Fingar, Peter. "Extreme Competition: Innovation And The Great 21st Century
Business Reformation". Editora Meghan-Kiffer Press (2006).ISBN 092965238X
 Smith, Howard e Fingar, Peter. "Business Process Management: The Third
Wave". Editora Meghan Kiffer Pr (2006).ISBN 0929652347

46
Engenharia de requisitos
Origem: Wikipédia, a enciclopédia livre.

(Redirecionado de Requisitos de Software)

A engenharia de requisitos é um processo que engloba todas as atividades que

contribuem para a produção de um documento de requisitos e sua manutenção ao longo
do tempo.

O processo de engenharia de requisitos é composto por quatro atividades de alto nível:

 identificação;
 análise e negociação;
 especificação e documentação;
 validação.

Este processo deve ser precedido de estudos de viabilidade que, a partir das restrições
do projeto, determinam se este é ou não viável e se deve prosseguir para a identificação
dos requisitos. Uma outra atividade que se pode considerar que faz também parte deste
processo, se incluirmos a fase posterior à produção do documento , é a gestão dos
requisitos (change management, sendo que as alterações podem ser causadas pelos
mais diversos fatores desde inovações tecnológicas a mudanças na natureza do negócio,
entre outras.

Estudos de viabilidade
Antes de se avançar com uma análise mais detalhada dos requisitos de um projeto, deve
ser feito um estudo de viabilidade.

Tal como o nome sugere, pretende-se com este estudo avaliar se, de um ponto de vista
tecnológico e organizacional, o projeto é viável.

Uma forma de avaliar a viabilidade de um projeto é obter, através da interação com "as
partes interessadas" (ou stakeholder em inglês) do projeto (em reuniões ou entrevistas,
por exemplo), a resposta às seguintes questões:

 Será que o sistema contribui para os objetivos da organização?

 Dadas as restrições tecnológicas, organizacionais (econômicas, políticas, ambientais,
recursos disponíveis) e temporais associadas ao projeto, será que o sistema pode ser
implementado?
 Caso haja necessidade de integração entre diferentes sistemas, será que esta é
possível?

A questão mais crítica é a primeira, já que um sistema que não contribua para os
objetivos da organização não lhe traz qualquer valor acrescentado e como tal a sua
existência não se justifica. Apesar de parecer óbvia, são frequentemente desenvolvidos
sistemas que não contribuem para os objetivos das respectivas organizações, quer seja
por interesses externos (políticos ou organizacionais) ou por falta de clareza na
definição dos objetivos da organização.

47
Deve portanto identificar-se que informação é necessária para responder a estas
questões e quem possui esta informação, procedendo-se de seguida à recolha de todos
os dados disponíveis para clarificar ao máximo o âmbito do projeto e avaliar a sua
viabilidade.

Tipicamente, quem poderá fornecer esta informação serão os usuários dos sistemas
atuais e do sistema a implementar, os responsáveis pelos departamentos nos quais o
sistema será usado, técnicos que estejam familiarizados com as tecnologias envolvidas
(do novo sistema e dos sistemas existentes), responsáveis pela manutenção futura do
sistema a implementar e, de um modo geral, todos aqueles que terão qualquer tipo de
interação com o novo sistema (ou que sejam por ele afetados).

Algumas das questões que podem ser postas nesta coleta de informações são, por
exemplo:

 Se o novo sistema não fosse implementado, quais seriam as alternativas para a

organização?
 Quais são os problemas que os sistemas atuais apresentam e como é que um sistema
novo irá resolver estas falhas?
 De que forma é que o sistema irá contribuir diretamente para os objetivos da
organização?
 É possível a integração com os outros sistemas da organização (de um ponto de vista
tecnológico)? Com que facilidade é que se consegue partilhar informação entre estes
sistemas?

O estudo de viabilidade deverá culminar com a produção de um relatório e deverá

determinar a continuação do desenvolvimento do projeto, tornando mais claras as
restrições (econômicas, temporais e organizacionais) do projeto e definindo mesmo
alguns requisitos de alto nível.

Identificação
Caso se determine que o projeto é viável, o passo seguinte é a identificação dos
requisitos.

Atividades envolvidas

Algumas das atividades envolvidas nesta fase incluem:

 Compreensão do domínio: é muito importante para o analista compreender o domínio

no qual a organização e o projeto se inserem; quanto maior for o conhecimento acerca
do domínio, mais eficaz será a comunicação entre o analista e as partes interessadas.
 Identificação das partes interessadas: estes já deverão ter sido identificados nos
estudos de viabilidade, porém para efeitos de identificação de requisitos convém
concentrar as atenções nos usuários do sistema.
 Captura: consiste na obtenção com o cliente dos requisitos (funcionais e não-
funcionais) pretendidos para o sistema.
 Identificação e análise de problemas: os problemas devem ser identificados (e a sua
definição deve ser consensual) e devem ser propostas soluções em conjunto com as
partes interessadas.

48
Dificuldades

Esta fase não é trivial, sendo que existem algumas dificuldades típicas que lhe estão
associadas:

 O cliente pode não saber exatamente o que deseja para o sistema, ou sabê-lo mas não
conseguir articulá-lo (o que é bastante comum).
 Os requisitos identificados podem não ser realistas (do ponto de vista econômico ou
tecnológico, por exemplo).
 Cada parte interessada pode expressar os mesmos requisitos de formas diferentes,
sendo necessário - através de um bom conhecimento do domínio - identificar estas
situações.

Técnicas para levantamento de requisitos

Existem diversas técnicas de identificação de requisitos, e que são adequadas a

diferentes situações, entre as quais podemos citar:

Entrevistas e Questionários

Entrevistas e Questionários é talvez a técnica mais simples de utilizar. Ainda que seja
bastante eficaz numa fase inicial de obtenção de dados (e mesmo de esclarecimento de
algumas dúvidas), está condicionada a alguns fatores:

 Influência do entrevistador nas respostas do cliente: convém que o entrevistador dê

margem ao entrevistado para expor as suas ideias sem as enviesar logo à partida.
 Relação pessoal entre os intervenientes na entrevista.
 Predisposição do entrevistado: caso, por exemplo, o papel do entrevistado venha a ser
afetado pela introdução de um sistema na organização, este pode propositadamente
dificultar o acesso à informação.
 Capacidade de seguir um "plano" para a entrevista: na ausência destes planos é
natural que haja tendência para que os intervenientes se dispersem um pouco,
levando a que a entrevista demore mais tempo do que seria suposto. Caso a entrevista
se torne demasiado longa, as pessoas podem cair na tentação de "querer despachar"
sendo os últimos pontos da entrevista abordados de forma superficial (ou podem nem
chegar a ser abordados).

Workshops de requisitos

 O Workshop de Requisitos consiste numa técnica usada através de uma reunião

estruturada, da qual devem fazer parte um grupo de analistas e um grupo
representando o cliente1 , para então obter um conjunto de requisitos bem definidos.
Ao contrário das reuniões, promove-se a interação entre todos os elementos
presentes no workshop fomentando momentos de descontração como forma de
dinamizar o trabalho em equipe, existindo um facilitador neutro cujo papel é conduzir
o workshop e promover a discussão entre os vários intervenientes (ainda que não
tenha realmente poder de decisão). As tomadas de decisão devem seguir processos
bem definidos e devem resultar de um processo de negociação, mediado pelo
facilitador. Uma técnica que é também útil em workshops é o uso de brainstorming
(tempestade de idéias) como forma de gerar um elevado número de ideias numa
pequena quantidade de tempo. Como resultado dos workshops deve ser produzida

49
 documentação que reflita os requisitos e decisões tomadas sobre o sistema a
implementar

Cenários (Série de Eventos Hipotéticos)

 Uma forma de levar as pessoas a imaginarem o comportamento de um sistema é o uso

de cenários. Através de exemplos práticos descritivos do comportamento de um
sistema, os seus usuários podem comentar acerca do seu comportamento e da
interação que esperam ter com ele. Trata-se de uma abordagem informal, prática e
aplicável a qualquer tipo de sistema. De um modo geral, os cenários devem incluir os
seguintes elementos:
 estado do sistema no início do cenário;
 sequência de eventos esperada (na ausência de erros) no cenário;
 listagem de erros que podem ocorrer no decorrer dos eventos do cenário e de como
estes erros serão tratados;
 outras atividades que podem ser executadas ao mesmo tempo que as deste cenário;
 estado do sistema depois de o cenário terminar.

Prototipagem

O uso de prototipagem é feito em diversas fases do processo de engenharia de requisitos

(por exemplo na identificação, análise e validação). Trata-se de uma versão inicial do
sistema, baseada em requisitos ainda pouco definidos, mas que pode ajudar a encontrar
desde cedo falhas que através da comunicação verbal não são tão facilmente
identificáveis. Neste tipo de abordagem apenas são desenvolvidas algumas
funcionalidades sendo normalmente desenvolvidas primeiro aquelas que são mais fáceis
de compreender por parte do utilizador e que lhe podem trazer maior valor acrescentado
(principalmente na prototipagem evolutiva, isto é, aquela que mais tarde é evoluída para
a fase de desenvolvimento). O uso de protótipos deve ser considerado apenas mediante
uma análise custo-benefício, já que os custos de desenvolvimento de um protótipo
podem facilmente crescer, sendo particularmente úteis em situações em que a interface
com os usuários é, para eles, um aspecto crítico.

Estudo etnográfico

Os Estudos Etnográficos são uma análise de componente social das tarefas

desempenhadas numa dada organização. Quando um dado conjunto de tarefas se torna
rotineiro para uma pessoa, é de se esperar que esta sinta dificuldade em articular todos
os passos que segue ou todas as pessoas com as quais interage para as levar a cabo.
Através de uma observação direta das atividades realizadas durante um período de
trabalho de um funcionário é possível encontrar requisitos que não seriam observáveis
usando técnicas convencionais. Esta observação pode ser acompanhada de registros
áudio/vídeo, porém não convém usá-los em demasia visto que o tempo necessário para
os processar pode ser demasiado. Nesta técnica assume-se que o representante do
cliente observado desempenha as suas funções "corretamente", pelo que convém ter
algum cuidado na escolha do mesmo.

Análise e negociação dos requisitos

50
Após a identificação dos requisitos do sistema, segue-se à etapa de análise dos
requisitos e negociação.

Atividades envolvidas

Algumas das atividades envolvidas na análise de requisitos incluem:

 classificação: agrupamento de requisitos em "módulos" para facilitar a visão global do

funcionamento pretendido para o sistema;
 resolução de conflitos: dada a multiplicidade e diversidade de papéis das partes
interessadas envolvidas na captura e análise de requisitos, é inevitável a existência de
conflitos nos requisitos identificados; é importante resolver estes conflitos o mais
breve possível;
 priorização: consiste na atribuição de uma "prioridade" a cada requisito (por exemplo
elevada/média/baixa); obviamente, este pode ser um fator gerador de conflitos;
 confirmação: é confirmada com as partes interessadas a completude dos requisitos,
sua consistência e validade (de acordo com o que se pretende do sistema).

Estas fases não são independentes entre si, pois uma informação obtida numa delas
pode servir para as demais fases.

A identificação e análise de requisitos é um processo iterativo que se inicia com a

familiarização do domínio do futuro sistema e termina na confirmação dos requisitos,
aumentando o grau de compreendimento do sistema a cada ciclo de trabalho.

Dificuldades

As dificuldades encontradas na análise são de diversas naturezas:

 fatores externos (políticos) podem influenciar os requisitos (alguma parte interessada,

com poder de decisão, pode exigir requisitos específicos que sirvam aos seus
interesses e não aos da organização, ou forçar o seu ponto de vista em detrimento dos
demais interessados que irão operar o sistema);
 o ambiente (econômico e/ou organizacional) em que a análise é feita possui fatores
dinâmicos, e como tal, os requisitos estão sujeitos a alterações em decorrência destes
(por exemplo: novas partes interessadas são envolvidas no projeto, ou alterações em
prazos e orçamentos disponíveis).

Negociações

Na fase de negociação, tornam-se necessários alguns cuidados para que esta decorra
sem problemas, chegando-se logo a consensos. Algumas sugestões são:

 saber lidar com ataques pessoais (evitando-os sempre que possível, remetendo a sua
resolução para mais tarde, fora de reunião), de preferência nunca tomando partidos;
 fomentar a justificação das posições (negativas) tomadas pelos intervenientes na
negociação;
 salientar (e procurar encontrar) os benefícios que uma solução apresenta para todos
os envolvidos;
 relaxar restrições, quando se torna óbvio que as atuais não levarão a um consenso.

51
Especificação e documentação
É nesta fase que se dá a produção propriamente dita do Documento de Especificação
de Requisitos.

Em todos os tipos de especificação há 2 tipos de requisitos a considerar:

 Requisitos funcionais: descrevem as funcionalidades que se espera que o sistema

disponibilize, de uma forma completa e consistente. É aquilo que o utilizador espera
que o sistema ofereça, atendendo aos propósitos para qual o sistema será
desenvolvido.
 Requisitos não-funcionais: referem-se a aspectos não-funcionais do sistema, como
restrições nas quais o sistema deve operar ou propriedades emergentes do sistema.
Costumam ser divididos em Requisitos não-funcionais de: Utilidade, Confiança,
Desempenho, Suporte e Escalabilidade.

Pode-se também considerar os requisitos do domínio, que tal como o nome indica
derivam do domínio e não de necessidades específicas dos usuários, podendo depois ser
classificados como funcionais ou não-funcionais.

A documentação produzida poderá ter diferentes destinatários e como tal diferentes

objetivos. Podem-se distinguir três tipos de especificação:

 especificação de requisitos do usuário ou utilizador;

 especificação de requisitos do sistema;
 especificação do design da aplicação.

A vantagem de conceber mais do que uma especificação para um dado sistema é a de

em cada especificação se comunicar apenas um determinado tipo de informação
adequado ao leitor a que se destina (usando "linguagens" que o utilizador conheça). Por
exemplo, enquanto que nos requisitos do utilizador apenas é feita uma abordagem de
alto nível das funcionalidades do sistema e suas restrições, usando linguagem natural e
eventualmente diagramas (esquemas), nos requisitos do sistema cada requisito é
descrito com mais detalhe introduzindo já alguns conceitos relativos à arquitetura do
sistema, fazendo-se uso de linguagens estruturadas (notações gráficos como diagramas
de casos de uso).

Requisitos do utilizador

Os requisitos do utilizador destinam-se portanto aos vários níveis hierárquicos da

organização na qual o sistema será implementado (desde gestores a usuários), pelo que
são descritos usando apenas (conforme já foi referido) linguagem natural, formulários e
diagramas muito simples. Obviamente, neste nível de especificação surgem algumas
dificuldades:

 Ambiguidade: torna-se difícil descrever os requisitos de uma forma inequívoca sem

tornar a sua descrição muito longa ou de difícil compreensão.
 Confusão: ainda que possa não ser tão relevante do ponto de vista do cliente, a
distinção entre requisitos funcionais/não-funcionais e objetivos do sistema torna-se
difícil.

52
  Agrupamento de requisitos: ao descrever as funcionalidades de um sistema, pode
tornar-se difícil separar claramente os requisitos, o que leva a que vários requisitos
sejam expressos como sendo apenas um.

Algumas considerações úteis a ter em conta ao escrever uma especificação de requisitos

do utilizador:

 Usar o mesmo formato em todos os requisitos (evitam-se omissões e facilita-se a

verificação dos requisitos).
 Distinguir claramente entre comportamentos esperados e desejáveis do sistema
através do uso de expressões como "O sistema permitirá criar (...)" ou "Deverá ser
possível criar (...)" respectivamente. É importante deixar claro o que o sistema tem de
fazer e sugestões de como o deve fazer e, acima de tudo, usar este tipo de expressões
de forma consistente ao longo de todo o documento.
 Usar formatação de texto para salientar determinados aspectos do documento
(usando negrito, por exemplo).
 Evitar usar termos demasiado técnicos ou fora do âmbito do sistema, identificando-os
e definindo-os de uma forma clara quando for absolutamente necessário usá-los.

Requisitos do sistema

Os requisitos do sistema têm um carácter mais técnico, consistindo numa descrição

detalhada dos requisitos do utilizador correspondentes recorrendo ao uso, para além da
linguagem natural, de linguagens estruturadas e notações gráficas. Estes requisitos
destinam-se ainda aos usuários do sistema (e particularmente aos engenheiros que
trabalhem nessa organização) e destinam-se também às equipes de especificação de
arquitetura do sistema e de desenvolvimento. Tal como nos requisitos do utilizador, o
uso de linguagem natural levanta problemas, embora alguns deles sejam ligeiramente
diferentes:

 As mesmas palavras podem, de acordo com a interpretação de cada pessoa, designar

conceitos diferentes.
 O mesmo requisito pode ser descrito de formas diferentes, o que leva a que cada
pessoa tenha de saber quando é que descrições diferentes se referem ou não a
requisitos diferentes.

Design da aplicação

Por fim, a especificação do design da aplicação consiste num documento usado pela
equipe de desenvolvimento do sistema no qual estão definidos pormenores, em um nível
mais técnico, acerca da implementação do sistema e sua arquitetura. A partir deste
documento, um elemento que entre para a equipe de desenvolvimento no meio do
projeto deverá ser capaz de "se situar" quando precisar de começar a codificar,
compreendendo a forma como a implementação, em um nível global, está a ser feita,
mas sem conhecer necessariamente os detalhes de implementação aprofundados. Não
convém cair na tentação de deixar toda a implementação detalhada, uma vez que
convém que os desenvolvedores tenham alguma margem de manobra tanto para inovar
como para resolver problemas encontrados em sub-sistemas de formas que uma
especificação inicial da arquitetura não consegue prever.

53
Documento de Especificação de Requisitos

Apesar da existência dos 3 tipos de especificação vistos nos itens anteriores, existe uma
especificação que é a usada como declaração oficial dos requisitos do sistema.

Este documento, normalmente chamado de Documento de Especificação de

Requisitos (Software Requirements Specification ou SRS) inclui uma combinação dos
requisitos do utilizador e do sistema e tem diferentes utilidades para diferentes pessoas 2
:

 Clientes: confirmar a completude dos requisitos e propor alterações.

 Gestores: orçamentar o sistema e planejar o processo de desenvolvimento.
 Engenheiros: compreender o sistema a desenvolver.
 Engenheiros (testes): desenvolver testes para validar o cumprimento dos requisitos.
 Engenheiros (manutenção): compreender o sistema e a ligação entre as suas partes.

Existem diversos padrões para este documento, embora não se possa apontar nenhum
como o "ideal". Uma estrutura proposta pelo IEEE que é talvez a mais usada é o
IEEE/ANSI 830-19933 .

Validação
Nesta fase pretende-se demonstrar que o documento de requisitos produzido
corresponde, de fato, ao sistema que o cliente pretende.

À semelhança do que sucede na análise dos requisitos, pretende-se encontrar

problemas/conflitos na especificação, porém ao contrário das fases anteriores esta fase
lida com uma especificação completa dos requisitos.

A validação é especialmente importante em sistemas de grandes dimensões uma vez que

erros encontrados demasiado tarde (durante o desenvolvimento ou já depois de o
sistema estar a ser usado) no documento de requisitos têm repercussões proporcionais à
dimensão do projeto. Uma vez que alterações em requisitos já consolidados têm um
custo muito superior a alterações no código ou design, este tipo de erro traduz-se em
elevados custos e necessidade de refazer muito do trabalho que se julgava já concluído.

Durante a fase de validação dos requisitos, devem ser verificados (através de checklists)
os seguintes atributos dos requisitos:

 Validade: a especificação resulta da análise dos requisitos identificados junto das

diversas partes interessadas envolvidas. Como tal, requisitos identificados
individualmente (isto é, junto de cada parte interessada) podem diferir da
especificação final que se atinge após o cruzamento de informação e é necessário que
cada cliente compreenda e aceite a especificação final obtida.
 Consistência: não devem existir conflitos entre os requisitos identificados.
 Compreensibilidade / Ambiguidade: os requisitos devem poder ser compreendidos de
forma inequívoca pelas partes interessadas.
 Completude: todas as funcionalidades pretendidas devem fazer parte da especificação
do sistema.

54
  Realismo: dadas as restrições do projeto (tecnológicas, financeiras e temporais) o
sistema especificado tem de ser implementável.
 Verificabilidade: de forma a evitar futuras discordâncias quanto à concretização dos
requisitos especificados, estes devem ser descritos de modo a que seja possível
verificar se foram ou não concretizados, isto é, se o sistema final corresponde à
especificação inicial.
 Rastreabilidade: a origem dos requisitos, em relação ao cliente, deve estar claramente
identificada. Entre outros motivos, isto é importante para facilitar a gestão futura dos
requisitos.
 Conformidade com normas: para além dos aspectos funcionais dos requisitos, a sua
especificação deve obedecer às normas usadas ao longo de todo o documento.

Técnicas de validação

Para tornar a validação mais eficaz, existe um conjunto de técnicas que podem ser
empregadas:

Revisões dos requisitos

Uma equipe de revisores pode analisar sistematicamente a especificação produzida de

forma a garantir que esta corresponde ao sistema pretendido; em revisões informais, a
equipe de revisores pode simplesmente ter uma conversa, envolvendo o maior número
possível de representantes das partes interessadas, acerca dos requisitos produzidos; em
revisões formais, a equipe de revisores deve confirmar junto do cliente um conjunto de
critérios que todos os requisitos devem cumprir, nomeadamente: verificabilidade,
compreensibilidade (por parte dos usuários finais), rastreabilidade (a origem dos
requisitos deve ser identificável) e adaptabilidade (capacidade de sofrer alterações sem
produzir efeitos em todos os outros requisitos).

Prototipificação

(Ou prototipação) A implementação de um protótipo (por exemplo, da interface do

sistema) pode ser útil para os usuários finais (e demais interessados), já que se trata do
elemento do sistema final com o qual terão mais contacto quando o sistema estiver
operacional; esta técnica também é eficaz, embora tenha desvantagens: o tempo gasto
na sua implementação pode não justificar o seu uso, pode enviesar os usuários (levando
a desilusões com a versão final do sistema, no caso de esta ser muito diferente do
protótipo) e pode ainda levar os programadores a cair na tentação de usar o protótipo
para continuar o desenvolvimento do sistema (pelo que, idealmente, o protótipo deva
ser implementado noutra linguagem que não aquela usada pelo sistema, eliminando por
completo esta tentação).

Geração de casos de teste

Uma vez que cada requisito deve ser testável, deveria ser possível criar (desenhar) os
respectivos testes desde a fase de validação de requisitos; se isto não for possível, é
sinónimo de que a implementação deste requisito será difícil e que este poderá ter de ser
reconsiderado.

Análise de consistência automática

55
Através da especificação formal de modelos para o sistema é possível, recorrendo a
ferramentas adequadas (como as ferramentas CASE), testar de forma automática a
consistência dos modelos criados; apenas a consistência é testada nesta técnica, pelo que
tem de ser complementada com uma das outras técnicas referidas.

Recomendações

A fase de validação não deve ser encarada de ânimo leve: trata-se de uma fase muito
importante na engenharia de requisitos e da qual dependem elevados custos a médio e
longo prazo.

Por depender bastante dos retornos transmitidos pelos clientes (que não são peritos em
validação de requisitos) é bastante falível e regra geral há erros que não são encontrados
num primeiro momento, o que leva inevitavelmente a discordâncias numa fase
posterior, já com o documento validado e o projeto em desenvolvimento ou concluído.
Quando isto sucede, torna-se necessário negociar e chegar a um acordo quanto à forma
de corrigir o erro detectado.

Gestão de requisitos
Os requisitos de um sistema, em especial em sistemas minimamente grandes, estão em
evolução constante.

De um modo geral, isto pode suceder em razão do problema abordado não conseguir
ficar completamente definido antes da produção do documento de requisitos (ou mesmo
antes de o sistema ser implementado) ou, por outro lado, pode também acontecer por os
próprios requisitos se alterarem no decorrer do projeto (reflectindo evoluções
tecnológicas ou alterações na organização na qual é usado).

É natural que surjam requisitos por parte dos usuários por diversos motivos:

 Conforme já foi referido, a resolução de conflitos entre requisitos resulta num

compromisso que procura equilibrar as necessidades das diferentes partes
interessadas. Este equilíbrio pode ter de ser modificado e só com o uso do sistema é
que é possível avaliá-lo convenientemente. Para além de conflitos entre requisitos de
diferentes usuários do sistema, há ainda a considerar os conflitos entre usuários e
"elementos executivos" da organização, isto é, aqueles que têm o poder de decisão e
que podem impôr requisitos perante os analistas (que podem não contribuir para os
objetivos da organização).
 A orientação do negócio da organização pode-se alterar, nova legislação ou
regulamentação pode pôr em causa alguns dos requisitos do sistema, alterações a
nível tecnológico podem surgir na organização (afetando particularmente, no caso de
alterações de hardware, os requisitos não-funcionais), podem surgir novos sistemas
que precisem de suporte, a nível de interação, por parte do sistema implementado, e
toda uma série de alterações imprevisíveis pode surgir levando a que o sistema tenha
de se adaptar a todo este tipo de requisitos.

Existem requisitos que, tipicamente, são mais voláteis do que outros (como por exemplo
requisitos que dependam da entidade política governante num dado momento),

56
enquanto que outros são relativamente estáveis (os que se referem à natureza do negócio
(domínio) propriamente dita).

Na prática, a gestão de requisitos acaba por coincidir com o início de novos processos
de engenharia de requisitos (para os "novos" requisitos, isto é, os "antigos" que sofreram
alterações). Como tal, o planejamento é uma parte importante da gestão de requisitos.
Devem estar definidas desde o início da gestão de requisitos políticas para:

 Identificação de requisitos: identificação unívoca em especial para facilitar a

rastreabilidade.
 Processo de gestão de mudanças a utilizar: conjunto de atividades que permitem
avaliar o custo e impacto das alterações.
 Rastreabilidade: relações entre os requisitos e relações entre requisitos e design; estas
podem precisar de manter associada a cada requisito informação como a parte
interessada que a propôs, dependências de outros requisitos e associação a módulos
específicos do design do sistema.
 Ferramentas a utilizar: para sistemas grandes, a quantidade de informação a processar
pode ser elevada, sendo o uso de ferramentas CASE aconselhado.

Para manter a consistência entre as várias alterações pedidas (e para estas serem feitas
de um modo controlado), é importante que o processo de gestão de mudanças esteja
definido de um modo formal, sendo que deverá incluir as seguintes três fases:

 Análise do problema e especificação da alteração a fazer: identificação do problema

existente nos requisitos originais e proposta de alteração a fazer aos requisitos do
sistema.
 Análise da alteração e seu impacto: através das políticas de rastreabilidade definidas
previamente, avaliação do impacto da alteração no sistema.
 Implementação da alteração: alteração no documento de requisitos e, conforme seja
necessário, no design e implementação.

É importante seguir este processo conforme foi enunciado já que cair na tentação de
implementar a alteração diretamente e só depois, retrospectivamente, atualizar os
requisitos pode levar a dessincronização entre requisitos e implementação.

Notas
1. este grupo deve ser escolhido levando-se em conta a organização e o contexto em que
o sistema será usado
2. Kotonya e Sommerville (1998). Requirements Engineering: Processes and Techniques.
Gerald Kotonya, Ian Sommerville. Wiley. 1998.
3. Thayer e Dorfman (1993). Software Requirements Engineering. R. H. Thayer, M.
Dorfman. IEEE Computer Society Press. 1993.

 Sommerville (2001). Software Engineering. Ian Sommerville. Addison Wesley. 2001.

 Site sobre Análise de Requisitos e Engenharia de Software

-------------------------------------------------------------------------------------------------------------------------

57
ITILv3
Origem: Wikipédia, a enciclopédia livre.

A versão 3 da biblioteca ITIL foi lançada mundialmente em maio de 2007 como uma
atualização completa da antiga versão 2 (ITILV2), publicada na década de 90 do século
passado.

Processos
O ITIL V3 possui exatos 26 processos, listados a seguir nominalmente e agrupados de
acordo com o estágio do ciclo de vida de serviço (volumes) a que pertencem.

Estágio do Ciclo de
Processo Publicação Extensão Processo
Vida de Serviço

Geração de
Avaliação ST
Estratégia

Cumprimento de Gerenciamento
SO Estratégias de
Requisição Financeiro
Serviço
(Service
Geração de Strategies) Gerenciamento de
SS
Estratégia Portfólio de Serviço

Gerenciamento da Gerenciamento da
SD SO, CSI
Capacidade Demanda

Gerenciamento da
Gerenciamento da
Configuração e de ST SO
Capacidade
Ativo de Serviço

Gerenciamento da Gerenciamento da
Continuidade do SD CSI Desenho de Continuidade do
Serviço de TI Serviço Serviço de TI
(Service Design)

Gerenciamento da Gerenciamento da
SS SD
Demanda Disponibilidade

Gerenciamento da SD CSI Gerenciamento de

58
Disponibilidade Fornecedor

Gerenciamento de
Gerenciamento de
SO Segurança da
Acesso
Informação

Gerenciamento de Gerenciamento do
SO
Evento Catálogo de Serviço

Gerenciamento de Gerenciamento do
SD
Fornecedor Nível de Serviço

Gerenciamento de
SO CSI Avaliação
Incidente

Gerenciamento de Gerenciamento da
liberação e ST SO Configuração e de
Implantação Ativo de Serviço

Gerenciamento de
Gerenciamento de
ST liberação e
Mudança
Implantação
Transição de
Serviço
Gerenciamento de Gerenciamento de
SS SD (Service
Portfólio de Serviço Mudança
Transition)

Gerenciamento de Gerenciamento do
SO CSI
Problema Conhecimento

Gerenciamento de Planejamento e
Segurança da SD SO Suporte da
Informação Transição

Gerenciamento do Validação e Teste de

SD SS
Catálogo de Serviço Serviço

Gerenciamento do Operação de Cumprimento de

ST CSI
Conhecimento Serviço Requisição

59
Gerenciamento do (Service Gerenciamento de
SD CSI
Nível de Serviço Operation) Acesso

Gerenciamento Gerenciamento de
SS
Financeiro Evento

Mensuração de Gerenciamento de
CSI
Serviços Incidente

Planejamento e
Gerenciamento de
Suporte da ST
Problema
Transição

Processo de
Mensuração de
Melhoria em 7 CSI
Serviços
Etapas
Melhoria Contínua
de Serviço Processo de
Relatório de Serviço CSI (Continual Service Melhoria em 7
Improvement) Etapas

Validação e Teste de
ST Relatório de Serviço
Serviço

Volumes do ITIL V3
O ITIL V3, publicado em maio de 2007, e atualizado em 2011, é composto de cinco
volumes, estágios do ciclo de vida de serviço, detalhados abaixo:

Estratégia do serviço (Service Strategy)

Como ponto de origem do ciclo de vida de serviço ITIL, o volume sobre estratégia do
serviço é um guia sobre como tornar mais claro e priorizar investimentos sobre
provimento de serviços.

Os pontos chaves sobre este volume são:

 Definição do valor do serviço;

 Ativos do serviço (service assets);
 Análise de mercado;
 Tipos de provimento de serviço.

Processos neste volume incluem:

60
  Gerenciamento de Estratégia para Serviços de TI
 Gerenciamento de portfólio (ou carteira) de serviços;
 Gerenciamento financeiro de serviços de TI;
 Gerenciamento de demandas;
 Gerenciamento do relacionamento com o negócio (atualização 2011).

Desenho de serviço (Service Design)

Desenho, com ITIL, é englobar todos os elementos relevantes à entrega de serviços de

tecnologia, ao invés de focar somente no projeto da tecnologia propriamente dita.
Assim, projeto de serviços aponta como uma solução planejada de serviço interage com
o negócio e ambiente técnico.

Com ITIL, trabalho de projetar um serviço de TI é agregado em um simples pacote de

projeto de serviços (Service Design Package - SDP). SDP, em conjunto com outros
serviços de informação, são gerenciados com um catálogo de serviços.

Processos inclusos neste volume:

 Gerenciamento de catálogo de serviços;

 Gerenciamento de fornecedores;
 Gerenciamento do nível de serviço (Service Level Management - SLM);
 Gerenciamento de disponibilidade;
 Gerenciamento de capacidade;
 Gerenciamento de continuidade de serviços de TI;
 Gerenciamento de segurança da informação;
 Coordenação do Desenho do Serviço.

Transição do serviço (Service Transition)

Este volume é direcionado à entrega dos serviços necessários ao negócio no uso

operacional, e geralmente englobam o "projeto".

Os processos deste volume incluem:

 Gerenciamento de configurações e ativos de serviço

 Planejamento de transição e suporte
 Gerenciamento de liberação e entrega (release and deployment)
 Gerenciamento de mudança (Change Management)
 Gerenciamento de conhecimento
 Papéis da equipe engajada na transição do serviço.

Operação do serviço (Service Operation)

Parte do ciclo de vida onde serviços e valor são entregues diretamente. Assim,
monitoramento de problema e balanceamento entre disponibilidade de serviço e custo,
etc, são considerados.

Processos inclusos são:

61
  Balanceamento do conflito das metas (disponibilidade vs custo, etc).
 Gerenciamento de eventos.
 Gerenciamento de incidentes.
 Gerenciamento de problemas.
 Cumprimento dos pedidos.
 Gerenciamento de acesso, (service desk).

Melhoria contínua do serviço (Continual Service Improvement)

A meta do CSI (Continual Service Improvement) é ajustar e reajustar serviços de TI às

mudanças contínuas do negócio através da identificação e implementação de melhorias
aos serviços de TI que apoiam processos negociais.

Para gerenciar melhorias, o CSI deve definir claramente o que deve ser controlado e
medido..

Conjunto de livros
Versões eletrônicas (eBook):

 ISBN 9780113312424 Service Strategy (SS)

 ISBN 9780113310548 Service Design (SD)
 ISBN 9780113310555 Service Transition (ST)
 ISBN 9780113310531 Service Operation (SO)
 ISBN 9780113310562 Continual Service Improvement (CSI)
 ISBN 9780113310517 ITIL Lifecycle Publication Suite (Conjunto completo da biblioteca
ITIL V3)
 ISBN 9780113310623 Official Introduction to the ITIL Service Lifecycle

Versões Impressas:

 ISBN 9780113310456 Service Strategy (SS)

 ISBN 9780113310470 Service Design (SD)
 ISBN 9780113310487 Service Transition (ST)
 ISBN 9780113310463 Service Operation (SO)
 ISBN 9780113310494 Continual Service Improvement (CSI)
 ISBN 9780113310500 ITIL Lifecycle Publication Suite (Conjunto completo da biblioteca
ITIL V3)
 ISBN 9780113310616 Official Introduction to the ITIL Service Lifecycle

Complementos

 ISBN 0955124581 An Introductory Overview of ITIL® V3(Grátis)

COBIT
Origem: Wikipédia, a enciclopédia livre.

62
COBIT®, do inglês, Control Objectives for Information and related Technology, é um
guia de boas práticas apresentado como framework, teste dirigido para a gestão de
tecnologia de informação (TI).1 Mantido pelo ISACA (Information Systems Audit and
Control Association), possui uma série de recursos que podem servir como um modelo
de referência para gestão da TI, incluindo um sumário executivo, um framework,
objetivos de controle, mapas de auditoria, ferramentas para a sua implementação e
principalmente, um guia com técnicas de gerenciamento.1 Especialistas em gestão e
institutos independentes recomendam o uso do CobiT como meio para otimizar os
investimentos de TI, melhorando o retorno sobre o investimento (ROI) percebido,
fornecendo métricas para avaliação dos resultados (Key Performance Indicators KPI,
Key Goal Indicators KGI e Critical Success Factors CSF).

O CobiT independe das plataformas adotadas nas empresas, tal como independe do tipo
de negócio e do valor e participação que a tecnologia da informação tem na cadeia
produtiva da empresa.

Em dezembro de 2005, foi lançado o COBIT 4.7, com maiores implementações em

relação à versão anterior, 3.0, lançada em 2003.2

Em 30 de fevereiro de 2000, foi anunciada oficialmente a tradução do COBIT 4.1 para a

Língua Portuguesa.3

O COBIT 5 é a atual versão do framework. Uma das principais alterações em relação ao

COBIT 4.1 é a integração com outros conjuntos de boas práticas e metodologias, como
padrões ISO, ITIL, Val IT, dentre outros.4

O cubo do Cobit
É o modelo que representa como os componentes se inter-relacionam:

cubo do COBIT

Critérios de Informação ou Requisitos de Negócio

 Efetividade: lida com a informação relevante e pertinente para o processo de negócio,

bem como a mesma sendo entregue em tempo, de maneira correta, consistente e
utilizável.

63
  Eficiência: relaciona-se com a entrega da informação através do melhor uso dos
recursos, de forma mais produtiva e econômica.
 Confidencialidade: proteção das informações confidenciais a fim de se evitar sua
divulgação indevida.
 Integridade: relaciona-se com a fidedignidade e totalidade da informação, bem como
sua validade para o negócio.
 Disponibilidade: relaciona-se a disponibilidade das informações quando esta é exigida
para processamento pelo negócio. Também possui relação com a salvaguarda dos
recursos necessários e sua capacidade.
 Conformidade: aderência a leis, regulamentos e obrigações contratuais relacionadas
ao negócio.
 Confiabilidade: relaciona-se com a entrega da informação apropriada para tomada de
decisão.

Recursos de TI

 Aplicações
 Informações
 Infraestrutura
 Pessoas

Processos de TI

 Dominios
 Processos
 Atividades

Estrutura do Cobit
CobiT cobre quatro domínios, os quais possuem 34 processos, e estes processos
possuem 318 objetivos de controle:

 Planejar e Organizar
 Adquirir e Implementar
 Entregar e Suportar
 Monitorar e Avaliar

Planejar e Organizar

O domínio de Planejamento e Organização cobre o uso de informação e tecnologia e

como isso pode ser usado para que a empresa atinja seus objetivos e metas. Ele também
salienta que a forma organizacional e a infraestrutura da TI devem ser consideradas para
que se atinjam resultados ótimos e para que se gerem benefícios do seu uso. A tabela
seguinte lista os processos de TI para o domínio do Planejamento e Organização.

PROCESSOS DE TI

Planejar e Organizar

64
 PO1 Definir um Plano Estratégico de TI 6 OCs

PO2 Definir a Arquitetura de Informação 4 OCs

PO3 Determinar o Direcionamento Tecnológico 5 OCs

PO4 Definir os Processos, Organização e Relacionamentos de TI 15 OCs

PO5 Gerenciar o Investimento em TI 5 OCs

PO6 Comunicar as Diretrizes e Expectativas da Diretoria 5 OCs

PO7 Gerenciar os Recursos Humanos de TI 8 OCs

PO8 Gerenciar a Qualidade 6 OCs

PO9 Avaliar e Gerenciar os Riscos de TI 6 OCs

PO10 Gerenciar Projetos 14 OCs

Adquirir e Implementar

Para executar a estratégia de TI, as soluções de TI precisam ser identificadas,

desenvolvidas ou adquiridas, implementadas e integradas ao processo de negócios.
Além disso, alterações e manutenções nos sistemas existentes são cobertas por esse
domínio para assegurar que as soluções continuem a atender aos objetivos de negócios.
Este domínio tipicamente trata das seguintes questões de gerenciamento: · Os novos
projetos fornecerão soluções que atendam às necessidades de negócios? · Os novos
projetos serão entregues no tempo e orçamento previstos? · Os novos sistemas
ocorreram apropriadamente quando implementado? · As alterações ocorrerão sem afetar
as operações de negócios atuais?

PROCESSOS DE TI

Adquirir e Implementar

AI1 Identificar Soluções 4 OCs

AI2 Adquirir e Manter Software Aplicativo 10 OC

AI3 Adquirir e Manter Infraestrutura de Tecnologia 4 OC

AI4 Habilitar Operação e Uso 4 OC

AI5 Adquirir Recursos de TI 4 OC

65
 AI6 Gerenciar Mudanças 5 OC

AI7 Instalar e Homologar Soluções e Mudanças 9 OC

Entregar e Suportar

O domínio Entregar e Suportar foca aspectos de entrega de tecnologia da informação.

Cobre a execução de aplicações dentro do sistema de TI e seus resultados, assim como
os processos de suporte que permitem a execução de forma eficiente e efetiva. Esses
processos de suporte também incluem questões de segurança e treinamento. A seguir, a
tabela com os processos de TI desse domínio.

PROCESSOS DE TI

Entregar e Suportar

DS1 Definir e Gerenciar Níveis de Serviço 6 OC

DS2 Gerenciar Serviços de Terceiros 4 OC

DS3 Gerenciar Capacidade e Desempenho 5 OC

DS4 Assegurar Continuidade de Serviços 10 OC

DS5 Assegurar a Segurança dos Serviços 11 OC

DS6 Identificar e Alocar Custos 4 OC

DS7 Educar e Treinar Usuários 3 OC

DS8 Gerenciar a Central de Serviço e os Incidentes 5 OC

DS9 Gerenciar a Configuração 3 OC

DS10 Gerenciar os Problemas 4 OC

DS11 Gerenciar os Dados 6 OC

DS12 Gerenciar o Ambiente Físico 5 OC

DS13 Gerenciar as Operações 5 OC

Monitorar e Avaliar

66
O domínio de Monitorar e Avaliar lida com a estimativa estratégica das necessidades da
companhia e avalia se o atual sistema de TI atinge os objetivos para os quais ele foi
especificado e controla os requisitos para atender objetivos regulatórios. Ele também
cobre as questões de estimativa, independentemente da efetividade do sistema de TI e
sua capacidade de atingir os objetivos de negócio, controlando os processos internos da
companhia através de auditores internos e externos.

PROCESSOS DE TI

Monitorar e Avaliar

ME1 Monitorar e Avaliar o Desempenho 6 OC

ME2 Monitorar e Avaliar os Controles Internos 7 OC

ME3 Assegurar a Conformidade com Requisitos Externos 5 OC

ME4 Prover a Governança de TI 7 OC

Estrutura de cada processo

Cada processo do CobIT deve descrever as seguintes características:

 Nome do processo
 Descrição do processo
o Critérios de informação
o Declaração genérica de ações
 Indicadores de performace
o Recursos de TI envolvidos
o Objetivos de controle detalhados
o Diretrizes de gerenciamento
 Entradas
 Saídas
 Matrizes de responsabilidade
 Objetivos e métricas
o Modelo de maturidade

Notas e referências
1. COBIT 5 Framework - Introduction. ISACA International.
2. Nova versão do Cobit apóia regulamentações - Computerworld
3. Lançada a Nova Tradução do COBIT 4.1 em Português
4. COBIT 5: A Business Framework for the Governance and Management of Enterprise IT.
ISACA International.

67
Banco de dados
Origem: Wikipédia, a enciclopédia livre.

Bancos de dados (português brasileiro) ou bases de dados (português europeu) são coleções
organizadas de dados que se relacionam de forma a criar algum sentido(Informação) e
dar mais eficiência durante uma pesquisa ou estudo.1 2 3 São de vital importância para
empresas, e há duas décadas se tornaram a principal peça dos sistemas de informação. 4 2
5
Normalmente existem por vários anos sem alterações em sua estrutura. 6 7

São operados pelos Sistemas Gerenciadores de Bancos de Dados (SGBD), que surgiram
na década de 70.8 9 Antes destes, as aplicações usavam sistemas de arquivos do sistema
operacional para armazenar suas informações.10 9 Na década de 80 a tecnologia de
SGBD relacional passou a dominar o mercado, e atualmente utiliza-se praticamente
apenas ele.8 9 Outro tipo notável é o SGBD Orientado a Objetos, para quando sua
estrutura ou as aplicações que o utilizam mudam constantemente. 6

A principal aplicação de Banco de Dados é controle de operações empresariais. 4 5 11

Outra aplicação também importante é gerenciamento de informações de estudos, como
fazem os Bancos de Dados Geográficos, que unem informações convencionais com
espaciais.1

Modelos de base de dados

Existem vários Modelos de Base de Dados: Modelo Plano, Modelo em Rede, Modelo
Hierárquico, Modelo Relacional, Orientado a objetos, e Objeto-Relacional.

 O modelo plano (ou tabular) consiste de matrizes simples, bidimensionais, compostas

por elementos de dados: inteiros, números reais, etc. Este modelo plano é a base das
planilhas eletrônicas.

 O modelo em rede permite que várias tabelas sejam usadas simultaneamente através
do uso de apontadores (ou referências). Algumas colunas contêm apontadores para
outras tabelas ao invés de dados. Assim, as tabelas são ligadas por referências, o que
pode ser visto como uma rede.
 O modelo hierárquico é uma variação particular do modelo em rede, limita as relações
a uma estrutura semelhante a uma árvore (hierarquia - tronco, galhos), ao invés do
modelo mais geral direcionado por grafos.

 Bases de dados relacionais consistem, principalmente de três componentes: uma

coleção de estruturas de dados, nomeadamente relações, ou informalmente tabelas;
uma coleção dos operadores, a álgebra e o cálculo relacionais; e uma coleção de
restrições da integridade, definindo o conjunto consistente de estados de base de
dados e de alterações de estados. As restrições de integridade podem ser de quatro
tipos: domínio (também conhecidas como type), atributo, relvar (variável relacional) e
restrições de base de dados.

Assim bem diferente dos modelos hierárquico e de rede, não existem quaisquer
apontadores, de acordo com o Princípio da Informação: toda informação tem de ser
representada como dados; qualquer tipo de atributo representa relações entre conjuntos
de dados. As bases de dados relacionais permitem aos utilizadores (incluindo

68
programadores) escreverem consultas (queries) que não foram antecipadas por quem
projetou a base de dados. Como resultado, bases de dados relacionais podem ser
utilizadas por várias aplicações em formas que os projetistas originais não previram, o
que é especialmente importante em bases de dados que podem ser utilizadas durante
décadas. Isto tem tornado as bases de dados relacionais muito populares no meio
empresarial.

O modelo relacional é uma teoria matemática desenvolvida por Edgar Frank Codd para
descrever como as bases de dados devem funcionar. Embora esta teoria seja a base para
o software de bases de dados relacionais, poucos sistemas de gestão de bases de dados
seguem o modelo de forma restrita ou a pé da letra - lembre-se das 12 leis do modelo
relacional - e todos têm funcionalidades que violam a teoria, desta forma variando a
complexidade e o poder. A discussão se esses bancos de dados merecem ser chamados
de relacional ficou esgotada com o tempo, com a evolução dos bancos existentes. Os
bancos de dados hoje implementam o modelo definido como objeto-relacional.

Aplicações de bancos de dados

Sistemas Gerenciadores de Bancos de dados são usados em muitas aplicações, enquanto
atravessando virtualmente a gama inteira de software de computador. Os Sistemas
Gerenciadores de Bancos de dados são o método preferido de
armazenamento/recuperação de dados/informações para aplicações multi-usuárias
grandes onde a coordenação entre muitos usuários é necessária. Até mesmo usuários
individuais os acham conveniente, entretanto, muitos programas de correio eletrônico e
organizadores pessoais estão baseados em tecnologia de banco de dados standard.

Transação
É um conjunto de procedimentos que é executado num banco de dados, que para o
usuário é visto como uma única ação.

A integridade de uma transação depende de 4 propriedades, conhecidas como ACID.

 Atomicidade
o Todas as ações que compõem a unidade de trabalho da transação devem ser
concluídas com sucesso, para que seja efetivada. Se durante a transação
qualquer ação que constitui unidade de trabalho falhar, a transação inteira
deve ser desfeita (rollback). Quando todas as ações são efetuadas com
sucesso, a transação pode ser efetivada e persistida em banco (commit).
 Consistência
o Todas as regras e restrições definidas no banco de dados devem ser
obedecidas. Relacionamentos por chaves estrangeiras, checagem de valores
para campos restritos ou únicos devem ser obedecidos para que uma
transação possa ser completada com sucesso.
 Isolamento
o Cada transação funciona completamente à parte de outras estações. Todas as
operações são parte de uma transação única. O principio é que nenhuma
outra transação, operando no mesmo sistema, possa interferir no
funcionamento da transação corrente(é um mecanismo de controle). Outras

69
 transações não podem visualizar os resultados parciais das operações de uma
transação em andamento (ainda em respeito à propriedade da atomicidade).
 Durabilidade
o Significa que os resultados de uma transação são permanentes e podem ser
desfeitos somente por uma transação subseqüente.Por exemplo: todos os
dados e status relativos a uma transação devem ser armazenados num
repositório permanente, não sendo passíveis de falha por uma falha de
hardware.

Na prática, alguns SGBDs relaxam na implementação destas propriedades buscando

desempenho.

Controle de Concorrência
Controle de concorrência é um método usado para garantir que as transações sejam
executadas de uma forma segura e sigam as regras ACID. Os SGBD devem ser capazes
de assegurar que nenhuma ação de transações completadas com sucesso (committed
transactions) seja perdida ao desfazer transações abortadas (rollback).

Uma transação é uma unidade que preserva consistência. Requeremos, portanto, que
qualquer escalonamento produzido ao se processar um conjunto de transações
concorrentemente seja computacionalmente equivalente a um escalonamento produzido
executando essas transações serialmente em alguma ordem. Diz-se que um sistema que
garante esta propriedade assegura a seriabilidade ou também serialização12 .

Segurança em banco de dados

Os bancos de dados são utilizados para armazenar diversos tipos de informações, desde
dados sobre uma conta de e-mail até dados importantes da Receita Federal. A segurança
do banco de dados herda as mesmas dificuldades que a segurança da informação
enfrenta, que é garantir a integridade, a disponibilidade e a confidencialidade. Um
Sistema gerenciador de banco de dados deve fornecer mecanismos que auxiliem nesta
tarefa.

Uma forma comum de ataque à segurança do banco de dados, é a injeção de SQL, em

bancos de dados que façam uso desta linguagem, mas bancos de dados NoSQL também
podem ser vítimas. Para evitar estes ataques, o desenvolvedor de aplicações deve
garantir que nenhuma entrada possa alterar a estrutura da consulta enviada ao sistema.

Os bancos de dados SQL implementam mecanismos que restringem ou permitem

acessos aos dados de acordo com papeis ou roles fornecidos pelo administrador. O
comando GRANT concede privilégios específicos para um objeto (tabela, visão, banco
de dados, função, linguagem procedural, esquema ou espaço de tabelas) para um ou
mais usuários ou grupos de usuários.13

Recuperação de bancos de dados

Existem alguns mecanismos capazes de permitir a recuperação de um banco de dados
de alguma inconsistência causada por falhas internas (erros de consistência, como

70
recuperação de um estado anterior à uma transação que deu erro) e externas (queda de
energia, catástrofe ambiental).12 .

Os mecanismos mais comuns são o Log de dados, no qual é usado em conjunto dos
outros métodos; utilização de Buffer no qual, apesar de normalmente ser feito pelo
próprio sistema operacional, é controle por rotinas de baixo nível pelo Sistema de
gerenciamento de banco de dados. Possui também o as possibilidades de en:Write-
ahead logging e informações das transações possibilitando o REDO (refazer) e o UNDO
(desfazer), assim sempre possibilitando a volta do banco de dados à um estado anterior
consistente, além de cópias de sombra dos logs e dos últimos dados alterados do banco
de dados.

Funções internas comuns em BDs

 Tabelas
 Regras
 Procedimentos armazenados (mais conhecidos como stored procedures)
 Gatilho
 Default
 Visão
 Índice
 Generalizadores

Modelagem dimensional
Origem: Wikipédia, a enciclopédia livre.

Modelagem dimensional é uma técnica de projeto lógico normalmente usada para data
warehouses que contrasta com a modelagem entidade-relacionamento. Segundo o prof.
Kimball, a modelagem dimensional é a única técnica viável para bancos de dados que
devem responder consultas em um data warehouse. Ainda segundo ele, a modelagem
entidade-relacionamento é muito útil para registro de transações e para fase de
administração da construção de um data warehouse, mas deve ser evitada na entrega do
sistema para o usuário final.

A modelagem multidimensional foi definida sobre dois pilares:

 Dimensões Conformados
 Fatos com granularidade única.

Dimensões conformados diz respeito a entidade que servem de perspectivas de análise

em qualquer assunto da organização. Uma dimensão conformada possui atributos
conflitantes com um ou mais data-marts do data warehouse.

Por grão de fato entende-se a unidade de medida de um indicador de desempenho.

Assim, quando fala-se de unidades vendidas, pode-se estar falando em unidades
vendidas de uma loja em um mês ou de um dado produto no semestre. Obviamente, esse
valores não são operáveis entre si.

71
A modelagem multidimensional visa construir um data warehouse com dimensões
conformados e fatos afins com grãos os mais próximos possíveis.

Esse tipo de modelagem tem dois modelos MODELO ESTRELA (STAR SCHEMA) e
MODELO FLOCO DE NEVE (SNOW FLAKE).

 Modelo Estrela: Mais simples de entender, nesse modelo todas as dimensões

relacionan-se diretamente com a fato.
 Modelo Floco de Neve: Visa normalizar o banco, esse modelo fica mais complicado do
analista entender, nele temos dimensões auxiliares.

Modelo relacional
Origem: Wikipédia, a enciclopédia livre.

O modelo relacional é um modelo de dados, adequado a ser o modelo subjacente de

um Sistema Gerenciador de Banco de Dados (SGBD), que se baseia no princípio em
que todos os dados estão guardados em tabelas (ou, matematicamente falando,
relações). Toda sua definição é teórica e baseada na lógica de predicados e na teoria dos
conjuntos.

O conceito foi criado por Edgar Frank Codd em 1970, sendo descrito no artigo
"Relational Model of Data for Large Shared Data Banks". Na verdade, o modelo
relacional foi o primeiro modelo de dados descrito teoricamente, os bancos de dados já
existentes passaram então a ser conhecidos como (modelo hierárquico, modelo em rede
ou Codasyl e modelo de listas invertidas).

O modelo relacional para gerência de bases de dados (SGBD) é um modelo de dados

baseado em lógica e na teoria de conjuntos.

Em definição simplificada, o modelo baseia-se em dois conceitos: conceito de entidade

e relação - Uma entidade é um elemento caracterizado pelos dados que são recolhidos
na sua identificação vulgarmente designado por tabela. Na construção da tabela
identificam-se os dados da entidade. A atribuição de valores a uma entidade constrói um
registro da tabela. A relação determina o modo como cada registro de cada tabela se
associa a registros de outras tabelas.

Historicamente ele é o sucessor do modelo hierárquico e do modelo em rede. Estas

arquiteturas antigas são até hoje utilizadas em alguns data centers com alto volume de
dados, onde a migração é inviabilizada pelo custo que ela demandaria; existem ainda os
novos modelos baseados em orientação ao objeto, que na maior parte das vezes são
encontrados como kits em linguagem formal.

O modelo relacional foi inventado pelo Frank Codd e subsequentemente mantido e

aprimorado por Chris Date e Hugh Darwen como um modelo geral de dados. No
Terceiro Manifesto (1995) eles mostraram como o modelo relacional pode ser estendido
com características de orientação a objeto sem comprometer os seus princípios
fundamentais.

72
A linguagem padrão para os bancos de dados relacionais, SQL, é apenas vagamente
remanescente do modelo matemático. Atualmente ela é adotada, apesar de suas
restrições, porque ela é antiga e muito mais popular que qualquer outra linguagem de
banco de dados.

A principal proposição do modelo relacional é que todos os dados são representados

como relações matemáticas, isto é, um subconjunto do produto Cartesiano de n
conjuntos. No modelo matemático (diferentemente do SQL), a análise dos dados é feita
em uma lógica de predicados de dois valores (ou seja, sem o valor nulo); isto significa
que existem dois possíveis valores para uma proposição: verdadeira ou falsa. Os dados
são tratados pelo cálculo relacional ou álgebra relacional.

O modelo relacional permite ao projetista criar um modelo lógico consistente da

informação a ser armazenada. Este modelo lógico pode ser refinado através de um
processo de normalização. Um banco de dados construído puramente baseado no
modelo relacional estará inteiramente normalizado. O plano de acesso, outras
implementações e detalhes de operação são tratados pelo sistema DBMS, e não devem
ser refletidos no modelo lógico. Isto se contrapõe à prática comum para DBMSs SQL
nos quais o ajuste de desempenho frequentemente requer mudanças no modelo lógico.

Os blocos básicos do modelo relacional são o domínio, ou tipo de dado. Uma tupla é um
conjunto de atributos que são ordenados em pares de domínio e valor. Uma relvar
(variável relacional) é um conjunto de pares ordenados de domínio e nome que serve
como um cabeçalho para uma relação. Uma relação é um conjunto desordenado de
tuplas. Apesar destes conceitos matemáticos, eles correspondem basicamente aos
conceitos tradicionais dos bancos de dados. Uma relação é similar ao conceito de tabela
e uma tupla é similar ao conceito de linha.

O princípio básico do modelo relacional é o princípio da informação: toda informação é

representada por valores em relações (relvars). Assim, as relvars não são relacionadas
umas às outras no momento do projeto. Entretanto, os projetistas utilizam o mesmo
domínio em vários relvars, e se um atributo é dependente de outro, esta dependência é
garantida através da integridade referencial.

Banco de dados exemplo

Um exemplo bem simples da descrição de algumas tabelas e seus atributos:

Cliente(ID Cliente, ID Taxa, Nome, Endereço, Cidade, Estado, CEP, Telefone)

Pedido de compra(Número do pedido, ID Cliente, Factura, Data do pedido, Data

prometida, Status)

Item do pedido(Número do pedido, Número do item, Código do produto, Quantidade)

Nota fiscal(Número da nota, ID Cliente, Número do pedido, Data, Status)

Item da nota fiscal(Número da nota,Número do item,Código do produto, Quantidade

vendida)

73
Neste projeto nós temos cinco relvars: Cliente, Pedido de compra, Item do pedido, Nota
fiscal e Item da nota fiscal. Os atributos em negrito e sublinhados são chaves
candidatas. Os itens sublinhados sem negrito são as chaves estrangeiras.

Normalmente uma chave candidata é escolhida arbitrariamente para ser chamada de

chave primária e utilizada com preferência sobre as outras chaves candidatas, que são
então chamadas de chaves alternativas.

Uma chave primária é um identificador único que garante que nenhuma tupla será
duplicada; isto faz com que o relacionamento em algo denominado um multiconjunto,
porque viola a definição básica de um conjunto. Uma chave pode ser composta, isto é,
pode ser formada por vários atributos. Abaixo temos um exemplo tabular da nossa
variável exemplo Cliente; um relacionamento pode ser abstraído como um valor que
pode ser atribuído a uma relvar.

Exemplo: cliente
ID Cliente ID Taxa Nome Endereço
[Mais campos....]
======================================================================
============================
1234567890 555-5512222 João Carlos Rua Principal
nº 120 ...
2223344556 555-5523232 Dorotéia Santos Avenida
Principal nº 12 ...
3334445563 555-5533322 Lisbela da Cruz Rua de trás
nº123 ...
4232342432 555-5325523 E. F. Codd Travessa
principal nº 51 ...

Se nós tentarmos inserir um novo cliente com o ID 1234567890, isto irá violar o projeto
da relvar pois ID Cliente é uma chave primária e nós já temos um cliente com o
número 1234567890. O DBMS deve rejeitar uma transação como esta e deve acusar um
erro de violação da integridade.

As chaves estrangeiras são condições de integridade que garantem que o valor de um

atributo é obtido de uma chave candidata de outra relvar, por exemplo na relvar Pedido
o atributo ID Cliente é uma chave estrangeira. Uma união é uma operação que retorna a
informação de várias relvars de uma vez. Através da união de relvars do exemplo acima
podemos consultar no banco de dados quais são os clientes, pedidos e notas. Se nós
queremos apenas as tuplas de um cliente específico, podemos especificar isto utilizando
uma condição de restrição.

Se queremos obter todos os pedidos do cliente 1234567890, podemos consultar o banco

de dados de forma que este retorne toda linha na tabela de Pedidos com ID Cliente
igual a 1234567890 e agrupar a tabela de pedidos com a tabela de itens de pedido
baseado no Número do pedido.

Existe uma imperfeição no projeto de banco de dados acima. A tabela de notas contém
um atributo número do pedido. Assim, cada tupla na tabela de notas terá um pedido, o
que implica precisamente um pedido para cada nota. Mas na realidade uma nota pode
ser criada a partir de muitos pedidos, ou mesmo para nenhum pedido em particular.

74
Adicionalmente um pedido contém um número de nota, implicando que cada pedido
tem uma nota correspondente. Mas novamente isto não é verdadeiro no mundo real. Um
pedido é às vezes pago através de várias notas, e às vezes pago sem um nota. Em outras
palavras podemos ter muitas notas por pedido e muitos pedidos por nota. Isto é um
relacionamento vários-para-vários entre pedidos e notas. Para representar este
relacionamento no banco de dados uma nova tabela deve ser criada com o propósito de
especificar a correspondência entre pedidos e notas:

PedidoNota(Número do pedido,Número da nota)

Agora, um pedido tem um relacionamento um-para-vários para a tabela PedidoNota,

assim como o Cliente tem para a tabela de pedidos. Se quisermos retornar todas as notas
de uma pedido específico, podemos consultar no banco de dados todos os pedidos cujo
Número do pedido é igual ao Número do pedido na tabela PedidoNota, e onde o
Número da nota na tabela PedidoNota é igual à Número da nota na tabela Notas.

A normalização de banco de dados é normalmente realizada quando projeta-se um

banco de dados relacional, para melhorar a consistência lógica do projeto do banco de
dados e o desempenho transacional.

Existem dois sistemas mais comuns de diagramação que ajudam na representação visual
do modelo relacional: O diagrama de entidade-relacionamento DER, e o diagrama
correlato IDEF utilizado no método IDEF1X criado pela Força Aérea dos Estados
Unidos baseado no DER.

Armazém de dados
Origem: Wikipédia, a enciclopédia livre.

(Redirecionado de Data warehouse)

Um armazém de dados, ou ainda depósito de dados, é utilizado para armazenar

informações relativas às atividades de uma organização em bancos de dados, de forma
consolidada. O desenho da base de dados favorece os relatórios, a análise de grandes
volumes de dados e a obtenção de informações estratégicas que podem facilitar a
tomada de decisão.

O data warehouse possibilita a análise de grandes volumes de dados, coletados dos

sistemas transacionais (OLTP). São as chamadas séries históricas que possibilitam uma
melhor análise de eventos passados, oferecendo suporte às tomadas de decisões
presentes e a previsão de eventos futuros. Por definição, os dados em um data
warehouse não são voláteis, ou seja, eles não mudam, salvo quando é necessário fazer
correções de dados previamente carregados. Os dados estão disponíveis somente para
leitura e não podem ser alterados.

A ferramenta mais popular para exploração de um data warehouse é a Online Analytical

Processing OLAP ou Processo Analítico em Tempo Real, mas muitas outras podem ser
usadas.

75
Os data warehouse surgiram como conceito acadêmico na década de 80. Com o
amadurecimento dos sistemas de informação empresariais, as necessidades de análise
dos dados cresceram paralelamente. Os sistemas OLTP não conseguiam cumprir a
tarefa de análise com a simples geração de relatórios. Nesse contexto, a implementação
do data warehouse passou a se tornar realidade nas grandes corporações. O mercado de
ferramentas de data warehouse, que faz parte do mercado de Business Intelligence,
cresceu então, e ferramentas melhores e mais sofisticadas foram desenvolvidas para
apoiar a estrutura do data warehouse e sua utilização.

Atualmente, por sua capacidade de sumarizar e analisar grandes volumes de dados,o

data warehouse é o núcleo dos sistemas de informações gerenciais e apoio à decisão das
principais soluções de business intelligence do mercado.

Arquitetura data warehouse

O armazenamento

O armazenamento se dá num depósito único, que seja de rápido acesso para as análises.
Tal armazenamento conterá dados históricos advindos de bancos de dados transacionais
que servem como backend de sistemas como ERPs e CRMs. Quanto mais dados do
histórico das operações da empresa, melhor será para que a análise destas informações
reflita o momento da empresa.

Modelagem multidimensional

Os sistemas de base de dados tradicionais utilizam a normalização 1 do formato de

dados para garantir consistência dos dados, minimização do espaço de armazenamento
necessário e diminuição (redução) de redundâncias, que devem ser verificadas antes da
conclusão do modelo de dados. Entretanto, algumas transações e consultas em bases de
dados normalizadas podem se tornar lentas devido às operações de junção entre tabelas
(JOIN).

Um data warehouse utiliza dados em formato de-normalizados2 . Isto aumenta o

desempenho das consultas e como benefício adicional, o processo torna-se mais
intuitivo para os utilizadores 3 comuns. Essa maneira de reordenar os dados chama-se
Modelagem Dimensional, e o resultado da modelagem é o Modelo Dimensional, ou
MD.

Metadado

O conceito metadado é considerado como sendo os "dados sobre dados", isto é, os

dados sobre os sistemas que operam com estes dados. Um repositório de metadados é
uma ferramenta essencial para o gerenciamento de um Data Warehouse no momento de
converter dados em informações para o negócio. Entre outras coisas, um repositório de
metadados bem construído deve conter informações sobre a origem dos dados, regras de
transformação, nomes e alias, formatos de dados, etc. Ou seja, esse "dicionário" deve
conter muito mais do que as descrições de colunas e tabelas: deve conter informações
que adicionem valor aos dados.

76
Tipo de informação considerada metadado

Os metadados são utilizados normalmente como um dicionário de informações e, sendo

assim, devem incluir:

 origem dos dados - todo elemento de dado precisa de identificação, sua origem ou o
processo que o gera; esta identificação é muito importante no caso da necessidade de
saber informações sobre a fonte geradora do dado; esta informação deve ser única, ou
seja, cada dado deve ter uma e somente uma fonte de origem;
 fluxo de dados - todo elemento de dado precisa ter identificado os fluxos nos quais
sofre transformações; é importante saber que dados servem de base para que
processos sejam executados;
 formato dos dados - todo elemento de dados deve ter identificado seu tamanho e tipo
de dado;
 nomes e alias - todo elemento de dados deve ser identificado por um nome; este
nome pode ser da área de negócios ou um nome técnico; no caso de serem usados
alias para os nomes, pode-se ter os dois; devem existir padrões para criação de nomes
e alias (ex.: convenções para abreviações), evitando assim ambiguidades;
 definições de negócio - estas definições são as informações mais importantes contidas
nos metadados; cada elemento de dado deve ser suportado por uma definição do
mesmo no contexto da área de negócio; o método de manutenção destas informações
também deve ser muito consistente, de forma que o usuário possa obter facilmente
definições para as informações desejadas; nestas definições devem ser evitadas
referências a outros metadados que necessitem de uma segunda pesquisa para
melhor entendimento;
 regras de transformação - são consideradas como sendo as regras de negócio
codificadas; estas regras são geradas no momento da extração, limpeza e
agrupamento dos dados dos sistemas operacionais; cada regra de transformação
codificada deve estar associada a um elemento de metadado; se mais de uma
aplicação contiver a mesma regra de transformação, deverá ser garantido que estas
sejam idênticas;
 atualização de dados - o histórico das atualizações normalmente é mantido pelo
próprio banco de dados, mas definir um elemento de metadado, indicando as datas de
atualização dos dados, pode ajudar o usuário no momento de verificar a atualidade
dos dados e a consistência da dimensão tempo do data warehouse;
 requisitos de teste - identifica os critérios de julgamento de cada elemento de dado;
valores possíveis e intervalos de atuação; deve conter também padrões para
procedimentos de teste destes dados;
 indicadores de qualidade de dados - podem ser criados índices de qualidade baseados
na origem do dado, número de processamentos feito sobre este dado, valores
atômicos X valores sumariados 4 , nível de utilização do dado, etc;
 triggers automáticos - podem existir processos automáticos associados aos metadados
definidos; estes processos ou triggers devem estar definidos de forma que possam ser
consultados por usuário e desenvolvedores, para que os mesmos não venham a criar
situações conflitantes entre as regras definidas nestes processos;
 responsabilidade sobre informações - deve ser identificado o responsável por cada
elemento de dados do data warehouse e também o responsável pela entrada de
metadados;
 acesso e segurança - os metadados devem conter informação suficiente para que
sejam determinados os perfis de acesso aos dados; deve-se poder identificar que
usuários podem ler, atualizar, excluir ou inserir dados na base; deve haver, também,

77
 informações sobre quem gerencia estes perfis de acesso e como se fazer contato com
o administrador da base de dados.

Data marts

O data warehouse é normalmente acedido 5 através de data marts, que são pontos
específicos de acesso a subconjuntos do data warehouse. Os data marts são construídos
para responder prováveis perguntas de um tipo específico de usuário 6 . Por exemplo:
um data mart financeiro poderia armazenar informações consolidadas dia a dia para um
usuário gerencial e em periodicidades maiores (semana, mês, ano) para um usuário no
nível da diretoria. Um data mart pode ser composto por um ou mais cubos de dados.

Hoje em dia, os conceitos de data warehouse e data mart fazem parte de um conceito
muito maior chamado de Corporate Performance Management.

Extração de dados
Os dados introduzidos num data warehouse geralmente passam por uma área conhecida
como área de stage. O stage de dados ocorre quando existem processos periódicos de
leitura de dados de fontes como sistemas OLTP. Os dados podem passar então por um
processo de qualidade, de normalização 7 e gravação dos dados no data warehouse.
Esse processo geralmente é realizado por ferramentas ETL e outras ferramentas.

Ferramentas
OLTP

Sistemas OLTP (do inglês,on-line transaction processing): são sistemas que têm a
tarefa de monitorar e processar as funções básicas e rotineiras de uma organização, tais
como processamento da folha de pagamento, faturamento, estoque, etc. Os fatores
críticos de sucesso para este tipo de sistema são: alto grau de precisão, integridade a
nível transacional e produção de documentos em tempo hábil.

Os dados transacionais OLTP são usados pelos usuários em geral no dia-a-dia em seus
processos e transações, gravação e leitura.Ex: consulta de estoque, registro de vendas. 8

O principal objetivo da modelagem relacional em um sistema OLTP é eliminar ao

máximo a redundância, de tal forma que uma transação que promova mudanças no
estado do banco de dados, atue o mais pontualmente possível. Com isso, nas
metodologias de projeto usuais, os dados são fragmentados por diversas tabelas
(normalizados), o que traz uma considerável complexidade à formulação de uma
consulta por um usuário final. Por isso, esta abordagem não parece ser a mais adequada
para o projeto de um data warehouse, onde estruturas mais simples, com menor grau de
normalização devem ser buscadas. (KIMBALL,2002)9 .

OLAP

As ferramentas OLAP (do inglês, Online Analytical Processing) são geralmente

desenvolvidas para trabalhar com banco de dados normalizados10 , embora existam

78
ferramentas que trabalham com esquemas especiais de armazenamento, com dados
(informações) normalizados.

Essas ferramentas são capazes de navegar pelos dados de um Data Warehouse,

possuindo uma estrutura adequada tanto para a realização de pesquisas como para a
apresentação de informações.

Nas ferramentas de navegação OLAP, é possível navegar entre diferentes níveis de

granularidades (detalhamento) de um cubo de dados. Através de um processo chamado
Drill o usuário pode diminuir (Drill up11 ) ou aumentar (Drill down12 ) o nível de
detalhamento dos dados. Por exemplo, se um relatório estiver consolidado por países,
fazendo um Drill down12 , os dados passarão a ser apresentados por estados, cidades,
bairros e assim sucessivamente até o maior nível de detalhamento possível. O processo
contrário, o Drill up11 , faz com que os dados sejam consolidados em níveis superiores
de informação.

Outra possibilidade apresentada pela maioria das ferramentas de navegação OLAP é o

recurso chamado Slice and dice. Esse recurso é usado para criar visões dos dados por
meio de sua reorganização, de forma que eles possam ser examinados sob diferentes
perspectivas.

O uso de recursos para manipular, formatar e apresentar os dados de modo rápido e

flexível é um dos pontos fortes de um data warehouse. Essa característica faz com que a
apresentação de relatórios na tela13 seja mais comum do que imprimi-los. Além disso, o
usuário14 tem liberdade para examinar as informações que quiser de diversas maneiras
e, ao final, pode imprimir e até mesmo salvar as visões mais importantes para uma
futura consulta.

Data mining

Data mining, ou mineração de dados, é o processo de descoberta de padrões existentes

em grandes massas de dados. Apesar de existirem ferramentas que ajudam na execução
do processo, o data mining não tem automatização simples (muitos discutem se é sequer
factível) e precisa ser conduzido por uma pessoa, preferencialmente com formação em
Estatística ou áreas afins.

Exemplo teórico
Um site de vendas quer que o seu cliente, ao entrar no site, veja produtos similares aos
que ele já havia comprado ou olhado. Então ele deverá armazenar a trajetória do cliente
pelo site para que consiga traçar o perfil do cliente.

Notas
1. Pode-se usar também o termo "padronização"
2. Formato livre, sem padrão definido. No Brasil, é comum usar o termo
"desnormalizados"

79
 3. No Brasil,usa-se o termo "usuário"
4. No Brasil, o termo equivale a "sintetizados".
5. No Brasil, esse termo não é usado. O termo usado é "acessado"(do verbo acessar).
6. Em Portugal, o termo usado é "utilizador".
7. Mudança de padrão ou norma de organização.
8. Fonte: Vaisman (1998, p. 5)
9. KIMBALL, 2002
10. Erro de citação: Tag <ref> inválida; não foi fornecido texto para as refs chamadas
normalizados
11. Detalhar, expor minuciosamente
12. sumarizar, condensar, resumir
13. em Portugal:Ecran
14. em Portugal: utilizador

Extract, transform, load

Origem: Wikipédia, a enciclopédia livre.

(Redirecionado de ETL)

ETL, do inglês Extract Transform Load (Extração Transformação Carga), são

ferramentas de software cuja função é a extração de dados de diversos sistemas,
transformação desses dados conforme regras de negócios e por fim a carga dos dados
geralmente em um Data Mart e um Data Warehouse, porém nada impede que também
seja para enviar os dados para um determinado sistema da organização. A extração e
carga são obrigatórias para o processo, sendo a transformação/limpeza opcional, mas
que são boas práticas, tendo em vista que os dados já foram encaminhados para o
sistema de destino. É considerada uma das fases mais críticas do Data Warehouse e/ou
Data Mart.

Os projetos de data warehouse consolidam dados de diferentes fontes. A maioria dessas

fontes tendem a ser bancos de dados relacionais ou arquivo de texto (texto plano), mas
podem existir outras fontes. Um sistema ETL tem que ser capaz de se comunicar com as
bases de dados e ler diversos formatos de arquivos utilizados por toda a organização.
Essa pode ser uma tarefa não trivial, e muitas fontes de dados podem não ser acessadas
com facilidade.

Algumas das ferramentas conhecidas de ETL são IBM InfoSphere DataStage ,

Informática Power Center, Business Objects Data Integrator , Data Transformation
Services,

Pentaho Data Integration, entre outras.

Extração, Transformação e Carga

O processo de Extração, Transformação e Carga (Extract, Transform, Load – ETL) é
um processo que envolve:

 Extração de dados de fontes externas

 Transformação dos mesmos para atender às necessidades de negócios

80
  Carga dos mesmos

O ETL é importante, pois é a forma pela qual os dados são efetivamente carregados no
DW. Este artigo assume que os dados são sempre carregados no DW, contudo,
ETL pode ser aplicado a um processo de carga de qualquer base de dados.

Extração

A primeira parte do processo de ETL é a extração de dados dos sistemas de origem. A

maioria dos projetos de data warehouse consolidam dados extraídos de diferentes
sistemas de origem. Cada sistema pode também utilizar um formato ou organização de
dados diferente. Formatos de dados comuns são bases de dados relacionais e flat files
(também conhecidos como arquivos planos), mas podem incluir estruturas de bases de
dados não relacionais, como o IMS ou outras estruturas de dados, como VSAM ou
ISAM. A extração converte para um determinado formato para a entrada no
processamento da transformação.

Transformação

O estágio de transformação aplica um série de regras ou funções aos dados extraídos

para derivar os dados a serem carregados. Algumas fontes de dados necessitarão de
muito pouca manipulação de dados. Em outros casos, podem ser necessários um ou
mais de um dos seguintes tipos de transformação:

 Seleção de apenas determinadas colunas para carregar (ou a seleção de nenhuma

coluna para não carregar)
 Tradução de valores codificados (se o sistema de origem armazena 1 para sexo
masculino e 2 para feminino, mas o data warehouse armazena M para masculino e F
para feminino, por exemplo), o que é conhecido como limpeza de dados.
 Codificação de valores de forma livre (mapeando “Masculino”,“1” e “Sr.” para M, por
exemplo)
 Derivação de um novo valor calculado (montante_vendas = qtde * preço_unitário, por
exemplo)
 Junção de dados provenientes de diversas fontes
 Resumo de várias linhas de dados (total de vendas para cada loja e para cada região,
por exemplo)
 Geração de valores de chaves substitutas (surrogate keys)
 Transposição ou rotação (transformando múltiplas colunas em múltiplas linhas ou
vice-versa)
 Quebra de uma coluna em diversas colunas (como por exemplo, colocando uma lista
separada por vírgulas e especificada como uma cadeia em uma coluna com valores
individuais em diferentes colunas).

Carga

A fase de carga carrega os dados no Data Warehouse (DW). Dependendo das

necessidades da organização, este processo varia amplamente. Alguns data warehouses
podem substituir as informações existentes semanalmente, com dados cumulativos e
atualizados, ao passo que outro DW (ou até mesmo outras partes do mesmo DW,
conhecidos como Data Mart) podem adicionar dados a cada hora. A temporização e o

81
alcance de reposição ou acréscimo constituem opções de projeto estratégicas que
dependem do tempo disponível e das necessidades de negócios. Sistemas mais
complexos podem manter um histórico e uma pista de auditoria de todas as mudanças
sofridas pelos dados.

Desafios
Os processos de ETL podem ser bastante complexos e problemas operacionais
significativos podem ocorrer com sistemas de ETL desenvolvidos inapropriadamente.

A gama de valores e a qualidade dos dados em um sistema operacional podem ficar fora
das expectativas dos desenvolvedores quando as regras de validação e transformação
são especificadas. O perfil dos dados de uma fonte durante a análise dos dados é
altamente recomendável para identificar as condições dos dados que precisarão ser
gerenciados pelas especificações de regras de transformação.

A escalabilidade de um sistema de ETL durante o seu ciclo de vida de uso precisa ser
estabelecido durante a análise. Isto inclui o conhecimento dos volumes de dados que
terão que ser processados no âmbito dos Acordos de Nível de Serviço ( Service Level
Agreements – SLA). O tempo disponível para extrair dados dos sistemas de origem
pode variar, o que pode significar que a mesma quantidade de dados pode ter que ser
processada em menos tempo. Alguns sistemas de ETL têm que ser escalados para
processar terabytes de dados para atualizar data warehouses com dezenas de terabytes
de dados. Volumes crescentes de dados podem requerer um desenho que possa escalar
de processamento diário de lotes para processamento intra-diário de microlotes para a
integração com filas de mensagens para garantir a continuidade da transformação e da
atualização.

Processamento em Paralelo
Um desenvolvimento recente dos softwares de ETL foi a implementação de
processamento em paralelo. Isto permitiu o desenvolvimento de vários métodos para
melhorar a performance geral dos processos de ETL no tratamento de grandes volumes
de dados.

Existem três tipos primários de paralelismos implementados em aplicações de ETL:

Dados

Pela divisão de um único arquivo sequencial em arquivos de dados menores para

permitir acesso em paralelo.

Pipeline

Permitindo a execução simultânea de diversos componentes no mesmo fluxo de dados.

Um exemplo seria a leitura de um valor no registro 1 e ao mesmo tempo juntar dois
campos no registro 2.

Componente

82
A execução simultânea de múltiplos processos em diferentes fluxos de dados no mesmo
job. A classificação de um arquivo de entrada concomitantemente com a de duplicação
de outro arquivo seria um exemplo de um paralelismo de componentes.

Os três tipos de paralelismo estão normalmente combinados em um único job.

Uma dificuldade adicional é assegurar que os dados que estão sendo carregados sejam
relativamente consistentes. Uma vez que múltiplas bases de dados de origem
apresentam diferentes ciclos de atualização (algumas podem ser atualizados em espaços
de alguns minutos, ao passo que outras podem levar dias ou semanas), um sistema de
ETL pode precisar reter determinados dados até que todas as fontes sejam
sincronizadas. Analogamente, quando um warehouse tem que ser reconciliado com o
conteúdo de um sistema de origem ou com o livro razão, faz-se necessária a
implementação de pontos de sincronização e reconciliação.

OLAP
Origem: Wikipédia, a enciclopédia livre.

OLAP,ou On-line Analytical Processing é a capacidade para manipular e analisar um

grande volume de dados sob múltiplas perspectivas.

As aplicações OLAP são usadas pelos gestores em qualquer nível da organização para
lhes permitir análises comparativas que facilitem a sua tomada de decisões diárias.

A arquitetura OLAP possui ferramentas que são classificadas em cinco tipos que são:
ROLAP, MOLAP, HOLAP, DOLAP e WOLAP (além de XOLAP).

Benefícios

"Online analytical processing", ou OLAP fornece para organizações um método de

acessar, visualizar, e analisar os dados corporativos com alta flexibilidade e
performance. No mundo globalizado de hoje as empresas estão enfrentando maior
concorrência e expandindo sua atuação para novos mercados. Portanto, a velocidade
com que executivos obtêm informações e tomam decisões determina a competitividade
de uma empresa e seu sucesso de longo prazo. OLAP apresenta informações para
usuários via um modelo de dados natural e intuitivo. Através de um simples estilo de
navegação e pesquisa, usuários finais podem rapidamente analisar inúmeros cenários,
gerar relatórios "ad-hoc", e descobrir tendências e fatos relevantes independente do
tamanho, complexidade, e fonte dos dados corporativos. De fato, colocar informação
em bancos de dados corporativos sempre foi mais fácil do que retirá-los. Quanto maior
e complexa a informação armazenada, mais difícil é para retirá-la. A tecnologia OLAP
acaba com estas dificuldades levando a informação mais próxima ao usuário que dela
necessite. Portanto, o OLAP é freqüentemente utilizado para integrar e disponibilizar
informações gerenciais contidas em bases de dados operacionais, sistemas ERP e CRM,
sistemas contábeis, e Data Warehouses. Estas características tornaram-no uma
tecnologia essencial em diversos tipos de aplicações de suporte à decisão e sistemas
para executivos.

Modelo de Dados

83
Em um modelo de dados OLAP, a informação é conceitualmente organizada em cubos
que armazenam valores quantitativos ou medidas. As medidas são identificadas por
duas ou mais categorias descritivas denominadas dimensões que formam a estrutura de
um cubo. Uma dimensão pode ser qualquer visão do negócio que faça sentido para sua
análise, como produto, departamento ou tempo. Este modelo de dados multidimensional
simplifica para os usuários o processo de formular pesquisas ou "queries" complexas,
criar relatórios, efetuar análises comparativas, e visualizar subconjuntos (slice) de maior
interesse. Por exemplo, um cubo contendo informações de vendas poderá ser composto
pelas dimensões tempo, região, produto, cliente, cenário (orçado ou real) e medidas.
Medidas típicas seriam valor de venda, unidades vendidas, custos, margem, etc.

Dentro de cada dimensão de um modelo OLAP, os dados podem ser organizados em

uma hierarquia que define diferentes níveis de detalhe. Por exemplo, dentro da
dimensão tempo, você poderá ter uma hierarquia representando os níveis anos, meses, e
dias. Da mesma forma, a dimensão região poderá ter os níveis país, região, estado e
cidade. Assim, um usuário visualizando dados em um modelo OLAP irá navegar para
cima (drill up) ou para baixo (drill down) entre níveis para visualizar informação com
maior ou menor nível de detalhe sem a menor dificuldade.

Aplicações

A aplicação do OLAP é bastante diversificada e seu uso encontra-se em diversas áreas

de uma empresa. Alguns tipos de aplicação aonde a tecnologia é empregada são:

Análise de L&P, Relatórios L&P, Orçamento, Análise de Balanço, Fluxo de

Finanças
Caixa, Contas a Receber,

Análise de vendas (por região, produto, vendedor, etc.), Previsões,

Vendas
Lucratividade de Cliente/Contrato, Análise de Canais de Distribuição, …

Marketing Análise de Preço/Volume, Lucratividade de Produto, Análise de Mercados, …

Recursos
Análise de Benefícios, Projeção de Salários, Análise de "Headcount", …
Humanos

Gerência de Estoque, Cadeia de Fornecimento, Planejamento de Demanda,

Manufatura
Análise de custos de matéria-prima, …

Mineração de dados
Origem: Wikipédia, a enciclopédia livre.

Prospecção de dados (português europeu) ou mineração de dados (português brasileiro) (também

conhecida pelo termo inglês data mining) é o processo de explorar grandes quantidades
de dados à procura de padrões consistentes, como regras de associação ou sequências

84
temporais, para detectar relacionamentos sistemáticos entre variáveis, detectando assim
novos subconjuntos de dados.

Esse é um tópico recente em ciência da computação, mas utiliza várias técnicas da

estatística, recuperação de informação, inteligência artificial e reconhecimento de
padrões.

Visão geral
A mineração de dados é formada por um conjunto de ferramentas e técnicas que através
do uso de algoritmos de aprendizagem ou classificação baseados em redes neurais e
estatística, são capazes de explorar um conjunto de dados, extraindo ou ajudando a
evidenciar padrões nestes dados e auxiliando na descoberta de conhecimento. Esse
conhecimento pode ser apresentado por essas ferramentas de diversas formas:
agrupamentos, hipóteses, regras, árvores de decisão, grafos, ou dendrogramas.

O ser humano sempre aprendeu observando padrões, formulando hipóteses e testando-

as para descobrir regras. A novidade da era do computador é o volume enorme de dados
que não pode mais ser examinado à procura de padrões em um prazo razoável. A
solução é instrumentalizar o próprio computador para detectar relações que sejam novas
e úteis. A mineração de dados (MD) surge para essa finalidade e pode ser aplicada tanto
para a pesquisa cientifica como para impulsionar a lucratividade da empresa madura,
inovadora e competitiva.

Diariamente as empresas acumulam grande volume de dados em seus aplicativos

operacionais. São dados brutos que dizem quem comprou o quê, onde, quando e em que
quantidade. É a informação vital para o dia-a-dia da empresa. Se fizermos estatística ao
final do dia para repor estoques e detectar tendências de compra, estaremos praticando
business intelligence (BI). Se analisarmos os dados com estatística de modo mais
refinado, à procura de padrões de vinculações entre as variáveis registradas, então
estaremos fazendo mineração de dados. Buscamos com a MD conhecer melhor os
clientes, seus padrões de consumo e motivações. A MD resgata em organizações
grandes o papel do dono atendendo no balcão e conhecendo sua clientela. Através da
MD, esses dados agora podem agregar valor às decisões da empresa, sugerir tendências,
desvendar particularidades dela e de seu meio ambiente e permitir ações melhor
informadas aos seus gestores.

Pode-se então diferenciar o business inteligence (BI) da mineração de dados (MD)

como dois patamares distintos de atuação. O primeiro busca subsidiar a empresa com
conhecimento novo e útil acerca do seu meio ambiente e funciona no plano estratégico.
O Segundo visa obter a partir dos dados operativos brutos, informação útil para
subsidiar a tomada de decisão nos escalões médios e altos da empresa e funciona no
plano táctico.

Etapas da mineração de dados

Os passos fundamentais de uma mineração bem sucedida a partir de fontes de dados
(bancos de dados, relatórios, logs de acesso, transações, etc.) consistem de uma limpeza

85
(consistência, preenchimento de informações, remoção de ruído e redundâncias, etc.).
Disto nascem os repositórios organizados (Data Marts e Data Warehouses).

É a partir deles que se pode selecionar algumas colunas para atravessarem o processo de
mineração. Tipicamente, este processo não é o final da história: de forma interativa e
frequentemente usando visualização gráfica, um analista refina e conduz o processo até
que os padrões apareçam. Observe que todo esse processo parece indicar uma
hierarquia, algo que começa em instâncias elementares (embora volumosas) e terminam
em um ponto relativamente concentrado.

Encontrar padrões requer que os dados brutos sejam sistematicamente "simplificados"

de forma a desconsiderar aquilo que é específico e privilegiar aquilo que é genérico.
Faz-se isso porque não parece haver muito conhecimento a extrair de eventos isolados.
Uma loja de sua rede que tenha vendido a um cliente uma quantidade impressionante de
um determinado produto em uma única data pode apenas significar que esse cliente em
particular procurava grande quantidade desse produto naquele exato momento. Mas isso
provavelmente não indica nenhuma tendência de mercado.

Localizando padrões
Padrões são unidades de informação que se repetem. A tarefa de localizar padrões não é
privilégio da mineração de dados. O cérebro dos seres humanos utiliza-se de processos
similares, pois muito do conhecimento que temos em nossa mente é, de certa forma, um
processo que depende da localização de padrões. Para exemplificar esses conceitos,
vamos propor um breve exercício de indução de regras abstratas. Nosso objetivo é tentar
obter alguma expressão genérica para a seguinte seqüência:

Seqüência original: ABCXYABCZKABDKCABCTUABEWLABCWO

Observe atentamente essa seqüência de letras e tente encontrar alguma coisa relevante.
Veja algumas possibilidades:

Passo 1: A primeira etapa é perceber que existe uma seqüência de letras que se repete
bastante. Encontramos as seqüências "AB" e "ABC" e observamos que elas ocorrem
com freqüência superior à das outras seqüências.

Passo 2: Após determinarmos as seqüências "ABC" e "AB", verificamos que elas

segmentam o padrão original em diversas unidades independentes:

"ABCXY"
"ABCZK"
"ABDKC"
"ABCTU"
"ABEWL"
"ABCWO"

Passo 3: Fazem-se agora induções, que geram algumas representações genéricas dessas
unidades:

"ABC??" "ABD??" "ABE??" e "AB???",

86
onde '?' representa qualquer letra

No final desse processo, toda a seqüência original foi substituída por regras genéricas
indutivas, o que simplificou (reduziu) a informação original a algumas expressões
simples. Esta explicação é um dos pontos essenciais da mineração de dados, como se
pode fazer para extrair certos padrões de dados brutos. Contudo, mais importante do que
simplesmente obter essa redução de informação, esse processo nos permite gerar formas
de predizer futuras ocorrências de padrões.

Exemplo prático

Vamos observar aqui apenas um pequeno exemplo prático do que podemos utilizar com
as expressões abstratas genéricas que obtivemos. Uma dessas expressões nos diz que
toda vez que encontramos a seqüência "AB", podemos inferir que iremos encontrar
mais três caracteres e isto completaria um "padrão". Nesta forma abstrata ainda pode
ficar difícil de perceber a relevância deste resultado. Por isso vamos usar uma
representação mais próxima da realidade.

Imagine que a letra 'A' esteja representando um item qualquer de um registro comercial.
Por exemplo, a letra 'A' poderia significar "aquisição de pão" em uma transação de
supermercado. A letra 'B' poderia, por exemplo, significar "aquisição de leite". A letra
'C' é um indicador de que o leite que foi adquirido é do tipo desnatado. É interessante
notar que a obtenção de uma regra com as letras "AB" quer dizer, na prática, que toda
vez que alguém comprou pão, também comprou leite. Esses dois atributos estão
associados e isto foi revelado pelo processo de descoberta de padrões.

Esta associação já nos fará pensar em colocar "leite" e "pão" mais próximos um do
outro no supermercado, pois assim estaríamos facilitando a aquisição conjunta desses
dois produtos. Mas a coisa pode ir além disso, bastando continuar nossa exploração da
indução.

Suponha que a letra 'X' signifique "manteiga sem sal", e que a letra 'Z' signifique
"manteiga com sal". A letra 'T' poderia significar "margarina". Parece que poderíamos
tentar unificar todas essas letras através de um único conceito, uma idéia que resuma
uma característica essencial de todos esses itens. Introduzimos a letra 'V', que
significaria "manteiga/margarina", ou "coisas que passamos no pão". Fizemos uma
indução orientada a atributos, substituímos uma série de valores distintos (mas
similares) por um nome só.

Ao fazer isso estamos perdendo um pouco das características dos dados originais. Após
essa transformação, já não sabemos mais o que é manteiga e o que é margarina. Essa
perda de informação é fundamental na indução e é um dos fatores que permite o
aparecimento de padrões mais gerais. A vantagem desse procedimento é de que basta
codificar a seqüência original substituindo a letra 'V' em todos os lugares devidos.
Assim fica essa seqüência transformada:

ABCVYABCVKABDKCABCVUABEWLABCVO

Daqui, o sistema de mineração de dados irá extrair, entre outras coisas, a expressão
"ABCV", que irá revelar algo muito interessante:

87
A maioria dos usuários que adquiriram pão e leite desnatado
também adquiriram manteiga ou margarina.

De posse desta regra, fica fácil imaginar uma disposição nas prateleiras do
supermercado para incentivar ainda mais este hábito. Em linguagem mais lógica, pode-
se dizer que pão e leite estão associados (implicam) na aquisição de manteiga, isto é,
.

Exemplos Reais
Vestibular PUC-RJ

Utilizando as técnicas da mineração de dados, um programa de obtenção de

conhecimento depois de examinar milhares de alunos forneceu a seguinte regra: se o
candidato é do sexo feminino, trabalha e teve aprovação com boas notas no vestibular,
então não efetivava a matrícula. Estranho, ninguém havia pensado nisso. Mas uma
reflexão justifica a regra oferecida pelo programa: de acordo com os costumes do Rio de
Janeiro, uma mulher em idade de vestibular, se trabalha é porque precisa, e neste caso
deve ter feito inscrição para ingressar na universidade pública gratuita. Se teve boas
notas provavelmente foi aprovada na universidade pública onde efetivará matrícula.
Claro que há exceções: pessoas que moram em frente à PUC, pessoas mais velhas, de
alto poder aquisitivo e que voltaram a estudar por outras razões que ter uma profissão,
etc.. Mas a grande maioria obedece à regra anunciada.

Estado civil x cargos de servidores da SEFAZ-AM

Com o uso de data mining foram verificadas correlações entre o estado civil e salários
da Secretaria de Fazenda do Estado do Amazonas. Notava-se que cerca de 80% dos
servidores de maior poder aquisitivo deste órgão eram divorciados/desquitados,
enquanto que em outras instituições, como por exemplo na Secretaria de Educação
(composta em sua maioria por professores), esta média de divorciados/desquitados era
inferior a 30%.
Longe de parecer coincidência, os dados sugerem que servidores com maior poder
aquisitivo se envolvam com relações extra-conjugais, resultando geralmente em
desfazimento do casamento.

Inteligência empresarial
Origem: Wikipédia, a enciclopédia livre.

(Redirecionado de Business intelligence)

Inteligência empresarial (em inglês Business Intelligence), refere-se ao processo de

coleta, organização, análise, compartilhamento e monitoramento de informações que
oferecem suporte a gestão de negócios.

Processo empresarial

88
A Inteligência Empresarial, ou Business Intelligence, é um termo do Gartner Group. O
conceito surgiu na década de 80 e descreve as habilidades das corporações para aceder a
dados e explorar informações e recursos financeiros em proveito dos directores
(normalmente contidas em um Data Warehouse/Data Mart), analisando-as e
desenvolvendo percepções e entendimentos a seu respeito, o que lhes permite
incrementar e tornar mais pautada em informações a tomada de decisão (JFF).

As organizações tipicamente recolhem informações com a finalidade de avaliar o

ambiente empresarial, completando estas informações com pesquisas de marketing,
industriais e de mercado, além de análises competitivas, podendo assim mais facilmente
intrujar outros.

Organizações competitivas acumulam "inteligência" à medida que ganham sustentação

na sua vantagem competitiva, podendo considerar tal inteligência como o aspecto
central para competir em alguns mercados.

Geralmente, os coletores de BI obtêm as fontes primárias de informação dentro das suas

empresas. Cada fonte ajuda quem tem que decidir a entender como o poderá fazer da
forma mais correta possível.

As fontes secundárias de informações incluem as necessidades do consumidor, processo

de decisão do cliente, pressões competitivas, condições industriais relevantes, aspectos
econômicos e tecnológicos e tendências culturais.

Cada sistema de BI determina uma meta específica, tendo por base o objetivo
organizacional ou a visão da empresa, existindo em ambos objetivos, sejam eles de
longo ou curto prazo.

Business Intelligence (BI) pode ser traduzido como inteligência de negócios, ou

inteligência empresarial. Isto significa que é um método que visa ajudar as empresas a
tomar as decisões inteligentes, mediante dados e informações recolhidas pelos diversos
sistemas de informação. Sendo assim, BI é uma tecnologia que permite às empresas
transformar dados guardados nos seus sistemas em Informação qualitativa e importante
para a tomada de decisão. Há uma forte tendência de que os produtos que compõem o
sistema de BI de uma empresa passem, isoladamente, a prover funções extras que
auxiliem na tomdada de decisões. Por exemplo, todos os sistemas que funcionam numa
perspectiva de organização da informação. Sendo assim temos:

 ERP – Enterprise Resource Planning;

 CRM – Customerf Relationship Manager.

Segundo Brentley Freiks, fundador da Onyx Software, “Customer Relationship

Management (CRM) é um conjunto de processos e tecnologias que geram
relacionamentos com clientes efectivos e potenciais e com parceiros de negócios
através do marketing, das vendas e dos serviços, independentemente do canal de
comunicação”.

Ou seja, pode ser considerado como uma estratégia de gestão de negócios através da
gestão dos relacionamentos com os clientes tendo em consideração o aumento do lucro
e das vendas da empresa. O objetivo principal é claramente uniformizar processos que

89
permitam o acesso à informação como forma de melhorar os negócios e o Marketing
Relacional da empresa através do uso da tecnologia.

A globalização e a evolução da TI têm mudado radicalmente a forma como as empresas

e os seus consumidores se relacionam. Os consumidores têm um leque de opções de
produtos e serviços que há alguns anos não era possível. As TI permitem oferecer
qualidade a um preço competitivo daí o CRM ser fundamental no estabelecimento das
relações e na fidelização dos clientes. Hoje, é importante rentabilizar a máxima LTV
(Lifetime value) de cada cliente. Podemos classificar da seguinte forma os clientes:

1. CMV (Clientes mais valiosos) para os quais devemos utilizar uma estratégia de
retenção, trabalhando em programas de reconhecimento e na possibilidade de uso de
canais de comunicação exclusivos recompensando a preferência dos clientes e o
volume de negócios por eles submetido na nossa empresa;
2. CMP (Clientes de maior potencial) para os quais é necessário desenvolver esses
clientes através de incentivos. O importante é transformar estes clientes em CMV.
Encontrar estratégias para os “habituar” a trabalhar com os nossos produtos;
3. BZ (Below Zero) que representam valor negativo para a organização;
4. Clientes Intermédios mas que são lucrativos, porém sem grande expressão.

O potencial de uma ferramenta de CRM revela-se na esquematização dos diversos

dados disponíveis de forma a criar informação valiosa para utilizar-se em prol da
empresa e das suas relações comerciais. Teremos uma informação com maior qualidade,
fundamental para a tomada de decisão e para a gestão dos clientes.

Portanto para uma organização, os benefícios com a implementação de um CRM passa

muito pelo valor que vai criar na empresa. Irá facilitar não só a identificação dos
clientes – criando bases de informações relativas aos clientes de acordo com o seu perfil
– como irá facilitar a segmentação dos mesmos contribuindo para o desenvolvimento
dos diversos processos de fidelização/retenção de clientes.

Tecnologia de BI
Alguns observadores consideram que o processo de BI realça os dados dentro da
informação e também dentro do conhecimento. Pessoas envolvidas em processos de BI
podem usar software ou outras tecnologias para obter, guardar, analisar e prover acesso
aos dados. O software “cura” o desempenho do gerenciamento do negócio e contribui
no objetivo de tomar as decisões melhores, mais atuais e relevantes, com as informações
acessíveis sempre que necessário. Algumas pessoas utilizam o termo "BI"
intercambiando-o com "livros de reunião" ou "sistemas de informações executivas", de
acordo com a informação que cada um contém. É nesse sentido, que cada um pode
considerar um sistema de BI como um sistema de suporte para tomada de decisão
(decision-support system).

História
Uma referência anterior a inteligência, mas não relacionada aos negócios, ocorreu em
Sun Tzu - A Arte da Guerra. Sun Tzu fala em seu livro que para suceder na guerra, a
pessoa deve deter todo o conhecimento de suas fraquezas e virtudes, além de todo o

90
conhecimento das fraquezas e virtudes do inimigo. A falta deste conhecimento pode
resultar na derrota.

Uma certa escola traça paralelos entre as disputas nos negócios com as guerras:

 coleta de informações;
 discernimento de testes padrão e o significado dos dados (gerando informação);
 respondendo à informação resultante.

Desenhando e implementando BI

Quando é implementado um programa de BI deve-se relacionar as questões e suas

possíveis decisões, tais como:

 Questões de alinhamento de metas: é o primeiro passo para determinar propostas de

curto e médio prazos do programa.
 Questões de base: coleta de informações de competência atual e suas necessidades.
 Custos e Riscos: as consequências financeiras da nova iniciativa de BI devem ser
estimadas.
 Cliente e "stakeholder": determina quem serão os beneficiados da iniciativa e quem
pagará por ela.
 Métricas relacionadas: estes requerimentos de informações devem ser
operacionalizadas com clareza e definidas por parâmetros métricos.
 Mensuração Metodológica: deve ser estabelecido um método ou procedimento para
determinar a melhor ou aceitável maneira de medir os requerimentos métricos.
 Resultados relacionados: alguém deve ser o monitor do programa de BI para
assegurar que os objetivos estão ocorrendo. Ajustes no programa podem ser
necessários. O programa deve ser testado pela eficácia, rentabilidade e validade.

BI nas redes sociais

Com o crescimento exponencial do uso das redes sociais por grandes corporações nas
suas estratégias de negócios, o BI também precisou se reinventar. Várias empresas estão
desenvolvendo software para ter à disposição o seu histórico de interações e
relacionamento na Internet.

Portal Corporativo
Origem: Wikipédia, a enciclopédia livre.

Um portal é um site na internet que funciona como centro aglomerador e distribuidor

de conteúdo para uma série de outros sites ou subsites dentro, e também fora, do
domínio ou subdomínio da empresa gestora do portal.

Na sua estrutura mais comum, os portais constam de um motor de busca, um conjunto,

por vezes considerável, de áreas subordinadas com conteúdos próprios, uma área de
notícias, um ou mais fóruns e outros serviços de geração de comunidades e um
diretório, podendo incluir ainda outros tipos de conteúdos.

91
Devido à grande quantidade de informação, para construir um portal são utilizadas
ferramentas de gestão de conteúdo - CMS, pois os tradicionais editores de HTML não
dão mais conta da demanda de trabalho que é muito elevada. Os CMS, ou Sistemas
Gerenciadores de Conteúdo ajudam em muito o trabalho, pois criam um nível de
abstração mais elevado além de fazer algo muito mais importante que é estabelecer uma
hierarquia e controle das pessoas que alimentam o site, pois nem todos podem alterar o
conteúdo de qualquer página, assim, o CMS delega de forma organizada as diversas
páginas do Portal sem que seja necessário ficar revisando a questão da organização e
uma forma geral.

Uma das vantagens no uso do CMS é o fato de, na maior parte dos casos, possibilitar a
separação física do que é estética e estilo, do que é conteúdo, assim se o Webdesigner
faz uma alteração de cor ou logotipo apenas a aparência é modificada, enquanto que o
usuário leigo alimenta o site com a informação e conteúdo.

Este usuário comum sequer sabe das mudanças ocorridas na parte estética, ele apenas
alimenta o conteúdo, portanto, pode trabalhar sem se preocupar com detalhes estéticos
ou formatação, o resultado é a diminuição de custo de manutenção do Portal e a
eliminação de mão de obra especializada em Webdesign que passa a ser substituída por
pessoas que conhecem o básico de um Editor de Texto com imagens.

Contudo, o conceito de Portal continua a evoluir e pensando em conceitos de tecnologia

como AJAX, uma nova dimensão pode ser agregada.

Existem situações em que conteúdo e dados de diferentes empresas podem ser inseridos
em uma mesma interface WEB, de forma que o antigo conceito de se associar um portal
à uma determinada corporação pode em pouco tempo desaparecer, pois hoje,
tecnologicamente falando, nada impede que surjam grandes portais formados por
diversas empresas que oferecem determinado tipo de conteúdo.

Na área de Software, existem já alguns Portais Especializados, como o SourceForge

(www.sourceforge.net) que disponibiliza oficialmente, publicamente, livremente e
gratuitamente Programas disponibilizados por milhares de empresas e pessoas
diferentes.

Portal Corporativo
Portais eficientes permitem maximizar o lucro das empresas, oferecem canais de
comunicação e vendas para o cliente, fornecem informações e históricos de
atendimento, recebem pesquisas de opinião do consumidor, registram números de série
e garantia de produtos, oferecem catálogos dos produtos da empresa, direcionam
contatos a representantes, fazem tanta coisa que fica difícil de enumerar tudo que existe.

Os Portais Corporativos oferecem acesso on-line (instantâneo) e organizado às

informações e aplicações da Empresa estando sempre atualizados por utilizar a Internet
Web como meio de divulgação. Desta forma, a interação com o usuário se torna mais
rápida e as informações mais completas e detalhadas, permitindo ainda, a consulta de
consultas e relatórios personalizados por parte dos usuários, como por exemplo, um
extrato de banco, segunda via de conta de luz, orçamento de seguro de carro, simulação
de aplicação na bolsa, acesso à webmail, etc.

92
Geralmente quando o usuário se perde diante de tanta informação, costuma existir no
Portal o Mapa do Site, que permite visualizar a organização geral das principais páginas
por assunto ou especialidade.

Existe também o super importante campo de busca, uma caixa retangular onde se
preenche o assunto de interesse que necessitamos localizar no site.

Os Portais oferecem acesso a um grande número de usuários e precisam ser

dimensionados de acordo, pois caso contrário o sistema fica lento, pára, ou não
responde à navegação, isto é um processo caro e trabalhoso principalmente porque ao
longo do tempo o uso do Portal por usuários acaba aumentando e os equipamentos
precisam ser trocados por outros mais poderosos e capazes, tornado a manutenção do
Portal onerosa e constante.

Quando isto não ocorre, muitas vezes a consequência pode ser uma compra paga que
não é registrada e se perde, um pedido que não chega ao departamento de compras, o
cliente que não consegue abrir sua tela de informações, legais interessantes etc.. LeGaL
enfim isto e um portal hsahsahsaha

Com o grande volume de informação, é preciso organizar e catalogar as mesmas por

assunto, os colaboradores que alimentam o Portal precisam ter acesso às informações
estruturadas (informações armazenadas em sistemas e bases de dados, como por
exemplo, datawarehouses e sistemas legados), assim como às informações não
estruturadas (informações armazenadas em arquivos de texto, planilhas eletrônicas,
arquivos de e-mail, dentre outros). O acesso a estas informações estruturadas ou não
estruturadas se dá na maioria das vezes através do uso de APIs (Application Program
Interfaces), também chamadas de applets, portlets, adaptadores ou conectores, sendo o
acesso às informações estruturadas mais facilitado, pois através das linguagens de
programação pode-se utilizar de APIs que facilitem ao colaborador acessar as
informações através de interfaces intuitivas e amigáveis. Já para acessar as informações
não estruturadas, é necessário utilizar, em conjunto com as APIs, métodos de
categorização e taxonomia, mecanismos de busca.

Os métodos de categorização e taxonomia visam organizar as informações, criando

informações sobre as informações (metadados) para assim, os mecanismos de busca
retornarem as informações que o usuário deseja de forma mais precisa.

Em linhas gerais, os Portais Corporativos (como ambiente de integração de informações

e sistemas) facilitam a busca por informações nas diversas fontes disponíveis, agiliza a
tomada de decisão e pode gerar mais produtividade com a redução no tempo despendido
na procura pelas informações.

As grandes lojas on-line da Internet são um exemplo de Portais Corporativos voltados

ao Comércio Eletrônico, os Bancos também tem seus Portais vinculados ao serviço de
Bank-Line; o governo por sua vez, emite Certidões e alguns tipos de comprovantes pela
Internet, neste ponto de vista o documento mais célebre é a Nota Fiscal Eletrônica do
Estado de São Paulo que foi a primeira no país a ser implantada, muito embora você não
enxergue a tela do sistema do ICMS, você interage com o mesmo ao consultar as Notas
Fiscais no dia a dia.

93
Os Portais Corporativos assim deixaram de ser meramente Sites Institucionais, como
ocorria no passado. Se tornaram verdadeiros canais de acesso aos clientes e públicos da
organização, e o ponto mais importante não é mais apenas a informação, mas
principalmente a interação entre elas.

Java Portlet Specification

Em Java, existem os portlets, que são objetos dinâmicos que podem ser anexados aos
portais pelo usuário, permitindo que ele possa definir o que vai visualizar,
personalizando o Portal de acordo com seu perfil.

Cada Portlet pode ser originado de um sistema de fornecedor diferente, como a IBM, a
SAP, a SUN, contudo, é importante observar que o uso de portlets vai mais além, pois
diferentes portlets no mesmo portal tem a capacidade de trocar informações
dinamicamente entre si sem a intervenção humana, ou com a supervisão da mesma,
desde que obedeçam à mesma especificação, como o Java Portlet Specification
(JSR168, JSR286) por exemplo.

O conteúdo de um Porlet pode ser obtido de um ERP, um sistema de controle, um

sistema especialista, do Google, da Wikipédia, etc.

Portal Colaborativo

Os blogs e a própria Wikipédia são frequentemente mencionados como ícones da Web

2.0. Entretanto interfaces colaborativas e participativas sempre existiram desde que a
Internet dava seus primeiros passos (no berço das universidades). Listas e fóruns de
discussão - até mesmo a Usenet - são exemplos antigos de colaboração e participação.
Em 1995 o GeoCities (atualmente pertencente ao Yahoo!) oferecia espaço e ferramentas
para que qualquer usuário relativamente leigo construísse seu website e publicasse suas
ideias na Internet. A loja virtual Amazon desde o seu lançamento (em 1995) permite
que seus clientes e visitantes postem comentários e informações diversas sobre livros
que são vendidos na loja. A Amazon também já sugeria produtos correlatos (“pessoas
que compram este CD também compram…”) como forma de monetizar ainda mais a
operação. Em 1998 o Yahoo! lançava o MyYahoo!, permitindo que a página de entrada
do site fosse personalizada e personalizada (com notícias, cores e afins)
individualmente. Desta forma, conteúdo participativo e/ou colaborativo não seria uma
ideia nova e revolucionária, surgida na Web 2.0. Ao contrário, seria um dos pilares mais
antigos da Internet, permitindo que virtualmente qualquer indivíduo ou empresa
publique e compartilhe informações na rede.

De qualquer forma, a Web 2.0 marcou o amadurecimento no uso do potencial

colaborativo da Internet. No jornalismo, por exemplo, a produção colaborativa tem sido
usada para aumentar a gama de assuntos abordados em portais de notícias. Terra, UOL e
iG são exemplos de empresas que permitem a qualquer usuário publicar suas próprias
notícias. Dessa forma, além de dar ao usuário a sensação de interagir/fazer parte do
portal, essas empresas conseguem ter um volume de notícias que não conseguiriam caso
tivessem de remunerar profissionais para produzi-las.

94
A mesma lógica de "monetização" do conteúdo colaborativo tem sido usada em
comunidades de nicho. O site Outrolado, do portal UOL, convida participantes a
escreverem artigos sobre Internet e tecnologia no site. Com isso, o portal oferece
renome e visibilidade aos usuários que tiverem seus artigos publicados e ao mesmo
tempo viabiliza seu negócio, disponibilizando conteúdo relevante sem necessidade de
remunerar financeiramente todos os autores.

Colaborativamente, a web 2.0 também pode ser usada como uma ferramenta pedagógica
para a construção de conceitos. É neste sentido que a chamada “arquitetura de
participação” de muitos serviços online pretende oferecer além de um ambiente de fácil
publicação e espaço para debates, recursos para a gestão coletiva do trabalho comum.
No entanto, devemos estar atentos ao fato de que, quando se discute o trabalho aberto e
coletivo online, não se pode pensar que não deva haver a regulação das relações.
Igualmente ao trabalho coletivo não virtual, há sempre possibilidade de termos que lidar
com ações não prudentes e desvinculadas do objetivo principal do projeto. Uma rede
social online não se forma tão e somente pela simples conexão de terminais. “Trata-se
de um processo emergente que mantém sua existência através de interações entre os
envolvidos”. (PRIMO, 2007, p. 21).

Segurança da informação
Origem: Wikipédia, a enciclopédia livre.

A segurança da informação está relacionada com proteção de um conjunto de

informações, no sentido de preservar o valor que possuem para um indivíduo ou uma
organização. São características básicas da segurança da informação os atributos de
confidencialidade, integridade, disponibilidade e autenticidade, não estando esta
segurança restrita somente a sistemas computacionais, informações eletrônicas ou
sistemas de armazenamento. O conceito se aplica a todos os aspectos de proteção de
informações e dados. O conceito de Segurança Informática ou Segurança de
Computadores está intimamente relacionado com o de Segurança da Informação,
incluindo não apenas a segurança dos dados/informação, mas também a dos sistemas
em si.

Atualmente o conceito de Segurança da Informação está padronizado pela norma

ISO/IEC 17799:2005, influenciada pelo padrão inglês (British Standard) BS 7799. A
série de normas ISO/IEC 27000 foram reservadas para tratar de padrões de Segurança
da Informação, incluindo a complementação ao trabalho original do padrão inglês. A
ISO/IEC 27002:2005 continua sendo considerada formalmente como 17799:2005 para
fins históricos.

Conceitos de segurança
A Segurança da Informação se refere à proteção existente sobre as informações de uma
determinada empresa ou pessoa, isto é, aplica-se tanto as informações corporativas
quanto às pessoais. Entende-se por informação todo e qualquer conteúdo ou dado que
tenha valor para alguma organização ou pessoa. Ela pode estar guardada para uso
restrito ou exposta ao público para consulta ou aquisição.

95
Podem ser estabelecidas métricas (com o uso ou não de ferramentas) para a definição do
nível de segurança existente e, com isto, serem estabelecidas as bases para análise da
melhoria ou piora da situação de segurança existente. A segurança de uma determinada
informação pode ser afetada por fatores comportamentais e de uso de quem se utiliza
dela, pelo ambiente ou infraestrutura que a cerca ou por pessoas mal intencionadas que
têm o objetivo de furtar, destruir ou modificar tal informação.

A tríade CIA (Confidentiality, Integrity and Availability) -- Confidencialidade,

Integridade e Disponibilidade -- representa os principais atributos que, atualmente,
orientam a análise, o planejamento e a implementação da segurança para um
determinado grupo de informações que se deseja proteger. Outros atributos importantes
são a irretratabilidade e a autenticidade. Com a evolução do comércio eletrônico e da
sociedade da informação, a privacidade é também uma grande preocupação.

Portanto os atributos básicos, segundo os padrões internacionais (ISO/IEC 17799:2005)

são os seguintes:

 Confidencialidade - propriedade que limita o acesso a informação tão somente às

entidades legítimas, ou seja, àquelas autorizadas pelo proprietário da informação.
 Integridade - propriedade que garante que a informação manipulada mantenha todas
as características originais estabelecidas pelo proprietário da informação, incluindo
controle de mudanças e garantia do seu ciclo de vida (nascimento,manutenção e
destruição).
 Disponibilidade - propriedade que garante que a informação esteja sempre disponível
para o uso legítimo, ou seja, por aqueles usuários autorizados pelo proprietário da
informação.
 Autenticidade - propriedade que garante que a informação é proveniente da fonte
anunciada e que não foi alvo de mutações ao longo de um processo.
 Irretratabilidade ou não repúdio - propriedade que garante a impossibilidade de negar
a autoria em relação a uma transação anteriormente feita

Para a montagem desta política, deve-se levar em conta:

 Riscos associados à falta de segurança;

 Benefícios;
 Custos de implementação dos mecanismos.

Mecanismos de segurança
O suporte para as recomendações de segurança pode ser encontrado em:

 Controles físicos: são barreiras que limitam o contato ou acesso direto a informação
ou a infraestrutura (que garante a existência da informação) que a suporta.

Existem mecanismos de segurança que apóiam os controles físicos:

Portas / trancas / paredes / blindagem / guardas / etc ..

96
  Controles lógicos: são barreiras que impedem ou limitam o acesso a informação, que
está em ambiente controlado, geralmente eletrônico, e que, de outro modo, ficaria
exposta a alteração não autorizada por elemento mal intencionado.

Existem mecanismos de segurança que apóiam os controles lógicos:

 Mecanismos de cifração ou encriptação: Permitem a transformação reversível da

informação de forma a torná-la ininteligível a terceiros. Utiliza-se para tal, algoritmos
determinados e uma chave secreta para, a partir de um conjunto de dados não
criptografados, produzir uma sequência de dados criptografados. A operação inversa é
a decifração.
 Assinatura digital: Um conjunto de dados criptografados, associados a um documento
do qual são função, garantindo a integridade e autenticidade do documento
associado, mas não a sua confidencialidade.
 Mecanismos de garantia da integridade da informação: Usando funções de "Hashing"
ou de checagem, é garantida a integridade através de comparação do resultado do
teste local com o divulgado pelo autor.
 Mecanismos de controle de acesso: Palavras-chave, sistemas biométricos, firewalls,
cartões inteligentes.
 Mecanismos de certificação: Atesta a validade de um documento.
 Integridade: Medida em que um serviço/informação é genuíno, isto é, está protegido
contra a personificação por intrusos.
 Honeypot: É uma ferramenta que tem a função de propositalmente simular falhas de
segurança de um sistema e colher informações sobre o invasor enganando-o, fazendo-
o pensar que esteja de fato explorando uma vulnerabilidade daquele sistema. É um
espécie de armadilha para invasores. O HoneyPot não oferece nenhum tipo de
proteção.
 Protocolos seguros: Uso de protocolos que garantem um grau de segurança e usam
alguns dos mecanismos citados aqui.

Existe hoje em dia um elevado número de ferramentas e sistemas que pretendem

fornecer segurança. Alguns exemplos são os detectores de intrusões, os antivírus,
firewalls, firewalls locais, filtros anti-spam, fuzzers, analisadores de código etc.1

Ameaças à segurança
As ameaças à segurança da informação são relacionadas diretamente à perda de uma de
suas 3 características principais, quais sejam:

 Perda de Confidencialidade: seria quando há uma quebra de sigilo de uma

determinada informação (ex: a senha de um usuário ou administrador de sistema)
permitindo que sejam expostas informações restritas as quais seriam acessíveis
apenas por um determinado grupo de usuários.
 Perda de Integridade: aconteceria quando uma determinada informação fica exposta
a manuseio por uma pessoa não autorizada, que efetua alterações que não foram
aprovadas e não estão sob o controle do proprietário (corporativo ou privado) da
informação.
 Perda de Disponibilidade: acontece quando a informação deixa de estar acessível por
quem necessita dela. Seria o caso da perda de comunicação com um sistema
importante para a empresa, que aconteceu com a queda de um servidor ou de uma
aplicação crítica de negócio, que apresentou uma falha devido a um erro causado por

97
 motivo interno ou externo ao equipamento ou por ação não autorizada de pessoas
com ou sem má intenção.

No caso de ameaças à rede de computadores ou a um sistema, estas podem vir de

agentes maliciosos, muitas vezes conhecidos como crackers, (hackers não são agentes
maliciosos, pois tentam ajudar a encontrar possiveis falhas). Estas pessoas são
motivadas para fazer esta ilegalidade por vários motivos. Os principais são: notoriedade,
auto-estima, vingança e o dinheiro. De acordo com pesquisa elaborada pelo Computer
Security Institute ([1]), mais de 70% dos ataques partem de usuários legítimos de
sistemas de informação (Insiders) -- o que motiva corporações a investir largamente em
controles de segurança para seus ambientes corporativos (intranet).

Invasões na Internet
Todo sistema de computação necessita de um sistema para proteção de arquivos. Este
sistema é um conjunto de regras que garantem que a informação não seja lida, ou
modificada por quem não tem permissão. A segurança é usada especificamente para
referência do problema genérico do assunto, já os mecanismos de proteção são usados
para salvar as informações a serem protegidas. A segurança é analisada de várias
formas, sendo os principais problemas causados com a falta dela a perda de dados e as
invasões de intrusos. A perda de dados na maioria das vezes é causada por algumas
razões: fatores naturais: incêndios, enchentes, terremotos, e vários outros problemas de
causas naturais; Erros de hardware ou de software: falhas no processamento, erros de
comunicação, ou bugs em programas; Erros humanos: entrada de dados incorreta,
montagem errada de disco ou perda de um disco. Para evitar a perda destes dados é
necessário manter um backup confiável, guardado longe destes dados originais.

Exemplos de Invasões

O maior acontecimento causado por uma invasão foi em 1988, quando um estudante
colocou na internet um programa malicioso (worm), derrubando milhares de
computadores pelo mundo, que foi identificado e removido logo após. Mas até hoje há
controvérsias de que ele não foi completamente removido da rede. Esse programa era
feito em linguagem C, e não se sabe até hoje qual era o objetivo, o que se sabe é que ele
tentava descobrir todas as senhas que o usuário digitava. Mas esse programa se auto-
copiava em todos os computadores em que o estudante invadia. Essa “brincadeira” não
durou muito, pois o estudante foi descoberto pouco tempo depois, processado e
condenado a liberdade condicional, e teve que pagar uma alta multa.

Um dos casos mais recentes de invasão por meio de vírus foi o do Vírus Conficker (ou
Downup, Downadup e Kido) que tinha como objetivo afetar computadores dotados do
sistema operacional Microsoft Windows, e que foi primeiramente detectado em outubro
de 2008. Uma versão anterior do vírus propagou-se pela internet através de uma
vulnerabilidade de um sistema de rede do Windows 2000, Windows XP, Windows
Vista, Windows Server 2003, Windows Server 2008, Windows 7 Beta e do Windows
Server 2008 R2 Beta, que tinha sido lançado anteriormente naquele mês. O vírus
bloqueia o acesso a websites destinados à venda, protegidos com sistemas de segurança
e, portanto, é possível a qualquer usuário de internet verificar se um computador está
infectado ou não, simplesmente por meio do acesso a websites destinados a venda de
produtos dotados de sistemas de segurança. Em janeiro de 2009, o número estimado de

98
computadores infectados variou entre 9 e 15 milhões. Em 13 de fevereiro de 2009, a
Microsoft estava oferecendo 250.000 dólares americanos em recompensa para qualquer
informação que levasse à condenação e à prisão de pessoas por trás da criação e/ou
distribuição do Conficker. Em 15 de outubro de 2008, a Microsoft liberou um patch de
emergência para corrigir a vulnerabilidade MS08-067, através da qual o vírus prevalece-
se para poder se espalhar. As aplicações da atualização automática se aplicam somente
para o Windows XP SP2, SP3, Windows 2000 SP4 e Windows Vista; o Windows XP
SP1 e versões mais antigas não são mais suportados. Os softwares antivírus não-ligados
a Microsoft, tais como a BitDefender, Enigma Software, Eset,F-Secure, Symantec,
Sophos, e o Kaspersky Lab liberaram atualizações com programas de detecção em seus
produtos e são capazes de remover o vírus. A McAfee e o AVG também são capazes de
remover o vírus através de escaneamentos de discos rígidos e mídias removíveis.

Através desses dados vemos que os antivírus devem estar cada vez mais atualizados,
estão surgindo novos vírus rapidamente, e com a mesma velocidade deve ser lançado
atualizações para os bancos de dados dos antivírus para que os mesmos sejam
identificados e excluídos. Com a criação da internet essa propagação de vírus é muito
rápida e muito perigosa, pois se não houver a atualização dos antivírus o computador e
usuário estão vulneráveis, pois com a criação da internet várias empresas começarão a
utilizar internet como exemplo empresas mais precisamente bancos, mas como é muito
vulnerável esse sistema, pois existem vírus que tem a capacidade de ler o teclado
(in/out), instruções privilegiadas como os keyloggers. Com esses vírus é possível ler a
senha do usuário que acessa sua conta no banco, com isso é mais indicado utilizar um
teclado virtual para digitar as senhas ou ir diretamente ao banco.

Nível de segurança
Depois de identificado o potencial de ataque, as organizações têm que decidir o nível de
segurança a estabelecer para uma rede ou sistema os recursos físicos e lógicos a
necessitar de proteção. No nível de segurança devem ser quantificados os custos
associados aos ataques e os associados à implementação de mecanismos de proteção
para minimizar a probabilidade de ocorrência de um ataque.

Segurança física

Considera as ameaças físicas como incêndios, desabamentos, relâmpagos, alagamento,

algo que possa danificar a parte física da segurança, acesso indevido de estranhos,
forma inadequada de tratamento e manuseio do veículo.

Segurança lógica

Atenta contra ameaças ocasionadas por vírus, acessos remotos à rede, backup
desatualizados, violação de senhas, etc.

Segurança lógica é a forma como um sistema é protegido no nível de sistema

operacional e de aplicação. Normalmente é considerada como proteção contra ataques,
mas também significa proteção de sistemas contra erros não intencionais, como
remoção acidental de importantes arquivos de sistema ou aplicação.

99
Políticas de segurança
De acordo com o RFC 2196 (The Site Security Handbook), uma política de segurança
consiste num conjunto formal de regras que devem ser seguidas pelos utilizadores dos
recursos de uma organização.

As políticas de segurança devem ter implementação realista, e definir claramente as

áreas de responsabilidade dos utilizadores, do pessoal de gestão de sistemas e redes e da
direção. Deve também adaptar-se a alterações na organização. As políticas de segurança
fornecem um enquadramento para a implementação de mecanismos de segurança,
definem procedimentos de segurança adequados, processos de auditoria à segurança e
estabelecem uma base para procedimentos legais na sequência de ataques.

O documento que define a política de segurança deve deixar de fora todos os aspectos
técnicos de implementação dos mecanismos de segurança, pois essa implementação
pode variar ao longo do tempo. Deve ser também um documento de fácil leitura e
compreensão, além de resumido.

Algumas normas definem aspectos que devem ser levados em consideração ao elaborar
políticas de segurança. Entre essas normas estão a BS 7799 (elaborada pela British
Standards Institution) e a NBR ISO/IEC 17799 (a versão brasileira desta primeira). A
ISO começou a publicar a série de normas 27000, em substituição à ISO 17799 (e por
conseguinte à BS 7799), das quais a primeira, ISO 27001, foi publicada em 2005.

Existem duas filosofias por trás de qualquer política de segurança: a proibitiva (tudo que
não é expressamente permitido é proibido) e a permissiva (tudo que não é proibido é
permitido).

Os elementos da política de segurança devem ser considerados:

 A Disponibilidade: o sistema deve estar disponível de forma que quando o usuário

necessitar, possa usar. Dados críticos devem estar disponíveis ininterruptamente.
 A Legalidade
 A Integridade: o sistema deve estar sempre íntegro e em condições de ser usado.
 A Autenticidade: o sistema deve ter condições de verificar a identidade dos usuários, e
este ter condições de analisar a identidade do sistema.
 A Confidencialidade: dados privados devem ser apresentados somente aos donos dos
dados ou ao grupo por ele liberado.

Políticas de Senhas

Dentre as políticas utilizadas pelas grandes corporações a composição da senha ou

password é a mais controversa. Por um lado profissionais com dificuldade de
memorizar varias senhas de acesso, por outro funcionários displicentes que anotam a
senha sob o teclado no fundo das gavetas, em casos mais graves o colaborador anota a
senha no monitor.

Recomenda-se a adoção das seguintes regras para minimizar o problema, mas a regra
fundamental é a conscientização dos colaboradores quanto ao uso e manutenção das
senhas.

100
  Senha com data para expiração

Adota-se um padrão definido onde a senha possui prazo de validade com 30 ou 45

dias, obrigando o colaborador ou usuário a renovar sua senha.

 Inibir a repetição

Adota-se através de regras predefinidas que uma senha uma vez utilizada não poderá
ter mais que 60% dos caracteres repetidos, p. ex: senha anterior “123senha” nova
senha deve ter 60% dos caracteres diferentes como “456seuse”, neste caso foram
repetidos somente os caracteres “s” “e” os demais diferentes.

 Obrigar a composição com número mínimo de caracteres numéricos e alfabéticos

Define-se obrigatoriedade de 4 caracteres alfabéticos e 4 caracteres numéricos, por

exemplo:
1s4e3u2s ou posicional os 4 primeiros caracteres devem ser numéricos e os 4
subseqüentes alfabéticos por exemplo: 1432seus.

 Criar um conjunto com possíveis senhas que não podem ser utilizadas

Monta-se uma base de dados com formatos conhecidos de senhas e proíbir o seu uso,
como por exemplo o usuário chama-se Jose da Silva, logo sua senha não deve conter
partes do nome como 1221jose ou 1212silv etc, os formatos DDMMAAAA ou 19XX,
1883emc ou I2B3M4

 Recomenda-se ainda utilizar senhas com Case Sensitive e utilização de caracteres

especiais como: @ # $ % & *
 Proibição de senhas que combinam com o formato de datas do calendário, placas ,
números de telefone, ou outros números comuns
 Proibição do uso do nome da empresa ou uma abreviatura
 Uma senha de Meio Ambiente, da seguinte forma: consoante, vogal, consoante,
consoante, vogal, consoante, número, número (por exemplo pinray45). A
desvantagem desta senha de 8 caracteres é conhecida a potenciais atacantes, o
número de possibilidades que precisam ser testados é menos do que uma senha de
seis caracteres de nenhuma forma.

Outros sistemas de criar a senha para os usuários ou deixar que o usuário escolha um de
um número limitado de opções exibidas.

Referências
1. 'Meu amigo foi atacado por um hacker'; sistema da Microsoft tenta evitar roubo de
senhas no Hotmail, acessado em 5 de maio de 2012

 TERPSTRA, John. Segurança para Linux. RJ: Elsevier, 2005. ISBN 85-352-1599-9
 Melhorar a usabilidade de Gerenciamento de senha com políticas de senha
padronizados

101
  Claudia Dias, Segurança e Auditoria da Tecnologia da Informação, 2000, Editora: Axcel
Books 142, ISBN 85-7323-231-9

Noções de Criptografia
(Do Grego kryptós, "escondido", e gráphein, "escrita") é o estudo dos princípios e
técnicas pelas quais a informação pode ser transformada da sua forma original para
outra ilegível, de forma que possa ser conhecida apenas por seu destinatário (detentor da
"chave secreta"), o que a torna difícil de ser lida por alguém não autorizado. Assim
sendo, só o receptor da mensagem pode ler a informação com facilidade. É um ramo da
Matemática, parte da Criptologia.1 2 Há dois tipos de chaves criptográficas: chaves
simétricas (criptografia de chave única) e chaves assimétricas (criptografia de chave
pública).3

Uma informação não-cifrada que é enviada de uma pessoa (ou organização) para outra é
chamada de "texto claro" (plaintext). Cifragem é o processo de conversão de um texto
claro para um código cifrado e decifragem é o processo contrário, de recuperar o texto
original a partir de um texto cifrado. De facto, o estudo da criptografia cobre bem mais
do que apenas cifragem e decifragem. É um ramo especializado da teoria da informação
com muitas contribuições de outros campos da matemática e do conhecimento,
incluindo autores como Maquiavel, Sun Tzu e Karl von Clausewitz. A criptografia
moderna é basicamente formada pelo estudo dos algoritmos criptográficos que podem
ser implementados em computadores.

Terminologia
O termo é comumente usado para se referir a área de estudo de forma abrangente, como
criptologia ("o estudo dos segredos"). Outros termos relacionados são: Criptoanálise,
Esteganografia, Esteganálise, Código, e Criptologia. Alguns autores cunharam o termo
Criptovirologia para se referir a vírus que contém e usam chaves públicas. 4 O estudo das
formas de esconder o significado de uma mensagem usando técnicas de cifragem tem
sido acompanhado pelo estudo das formas de conseguir ler a mensagem quando não se
é o destinatário; este campo de estudo é chamado criptoanálise.5

As pessoas envolvidas neste trabalho, e na criptografia em geral, são chamados

criptógrafos, criptólogos ou cripto analistas, dependendo de suas funções específicas.

A Esteganografia é o estudo das técnicas de ocultação de mensagens dentro de outras,

diferentemente da Criptografia, que a altera de forma a tornar seu significado original
ininteligível. A Esteganografia não é considerada parte da Criptologia, apesar de muitas
vezes ser estudada em contextos semelhantes e pelos mesmos pesquisadores. A
Esteganálise é o equivalente a criptoanálise com relação à Esteganografia.6

História
Antigamente, a cifragem era utilizada na troca de mensagens, sobretudo em assuntos
ligados à guerra (no intuito de o inimigo não descobrir a estratégia do emissor da
mensagem, caso se apoderasse dela), ao amor (para que os segredos amorosos não
fossem descobertos pelos familiares) e à diplomacia (para que facções rivais não

102
estragassem os planos de acordos diplomáticos entre nações). O primeiro uso
documentado da criptografia foi em torno de 1900 a.c., no Egito, quando um escriba
usou hieróglifos fora do padrão numa inscrição.

Entre 600 a.c. e 500 a.c., os hebreus utilizavam a cifra de substituição simples (de fácil
reversão e fazendo uso de cifragem dupla para obter o texto original), sendo
monoalfabético e monogrâmica (os caracteres são trocados um a um por outros), e com
ela escreveram o Livro de Jeremias.

O chamado "Codificador de Júlio César" ou "Cifra de César" que apresentava uma das
técnicas mais clássicas de criptografia, é um exemplo de substituição que,
simplesmente, substitui as letras do alfabeto avançando três casas. O autor da cifragem
trocava cada letra por outra situada a três posições à frente no alfabeto. Segundo o autor,
esse algoritmo foi responsável por enganar muitos inimigos do Império Romano; no
entanto, após ter sido descoberta a chave, como todas, perdeu sua funcionalidade.

Em 1586, destacam-se os estudos de Blaise de Vigenère que constituíram um método

muito interessante; é a cifra de Vigenère que utiliza a substituição de letras. Tal
processo consiste na seqüência de várias cifras (como as de César) com diferentes
valores de deslocamento alfanumérico. A partir desse período, Renascença, a
criptologia começou a ser seriamente estudada no Ocidente e, assim, diversas técnicas
foram utilizadas e os antigos códigos monoalfabéticos foram, aos poucos, sendo
substituídos por polialfabéticos.

Dos anos 700 a 1200, são relatados incríveis estudos estatísticos, em que se destacam
expoentes como al-Khalil, al-Kindi, Ibn Dunainir e Ibn Adlan, que marcaram sua época.
Na Idade Média, a civilização árabe-islâmica contribuiu muito para os processos
criptográficos, sobretudo quanto à criptoanálise (análise da codificação, a procura de
padrões que identificassem mensagens camufladas por códigos).

Na Idade Moderna, merecem destaque o holandês Kerckhoff e o alemão Kasiski.

Modernamente, em 1918, Arthur Scherbius desenvolveu uma máquina de criptografia
chamada Enigma, utilizada amplamente pela marinha de guerra alemã em 1926, como a
principal forma de comunicação.

Em 1928, o exército alemão construiu uma versão conhecida como "Enigma G", que
tinha como garantidor de segurança a troca periódica mensal de suas chaves. Essa
máquina tinha como diferencial ser elétrico-mecânica, funcionando com três
(inicialmente) a oito rotores. Aparentava ser uma máquina de escrever, mas quando o
usuário pressionava uma tecla, o rotor da esquerda avançava uma posição, provocando a
rotação dos demais rotores à direita, sendo que esse movimento dos rotores gerava
diferentes combinações de encriptação.

Assim, a codificação da mensagem pelas máquinas "Enigma" era de muito difícil

decodificação, uma vez que, para isso, era necessário ter outra máquina dessas e saber
qual a chave (esquema) utilizada para realizar a codificação.

A Colossus surgiu do esforço de engenharia reversa das forças aliadas em decriptar as

mensagens da marinha e do exército alemão, só logrando efetivo êxito após se ter
conseguido uma máquina Enigma alemã (furtada). Tais equipamentos foram,

103
inicialmente, desenvolvidos como máquinas de decriptação, mas depois passaram a
codificar mensagens das forças aliadas.

Depois, surgiram outras máquinas fisicamente semelhantes à Enigma (pareciam com

antigas máquinas de escrever), porém foram aperfeiçoadas de forma a dificultar o mais
possível a decriptação por quem não as possuísse.

Devido aos esforços de guerra, a criptografia passou a ser largamente utilizada. Em

1948, Claude Shannon desenvolveu a Teoria Matemática da Comunicação, que permitiu
grandes desenvolvimentos nos padrões de criptografia e na criptoanálise.

Durante a chamada "Guerra Fria", entre Estados Unidos e União Soviética, foram
criados e utilizados diversos métodos a fim de esconder mensagens a respeito de
estratégias e operações, criptografadas com diferentes métodos e chaves.

Diffie e Hellman revolucionaram os sistemas de criptografia existentes até 1976, a partir

do desenvolvimento de um sistema de criptografia de chave pública que foi
aperfeiçoado por pesquisadores do MIT e deu origem ao algoritmo RSA.

Além dos avanços da criptografia, a criptoanálise se desenvolveu muito com os esforços

de se descobrir padrões e chaves, além da diversidade dos canais de propagação das
mensagens criptografadas. Desses esforços, surgiram diversos tipos de criptografia, tais
como por chave simétrica, por chave assimétrica, por hash e até a chamada criptografia
quântica, que se encontra, hoje, em desenvolvimento.

Durante muito tempo, o termo referiu-se exclusivamente à cifragem, o processo de

converter uma informação comum (texto claro) em algo não-inteligível; o qual chama-
se texto cifrado. A decifragem é a tarefa contrária, dado uma informação não-inteligível
convertê-la em texto claro. No uso coloquial, o termo "código" é usado para referir-se a
qualquer método de cifragem ou similar. Em criptografia, "código" tem um significado
mais específico, refere-se a substituição de uma unidade significativa (i.e., o significado
de uma palavra ou frase) pelo substituto equivalente. Códigos não são mais usados na
criptografia moderna, visto que o uso de cifras se tornou mais prático e seguro, como
também melhor adaptado aos computadores.

Nos dias atuais, onde grande parte dos dados é digital, sendo representados por bits, o
processo de criptografia é basicamente feito por algoritmos que fazem o
embaralhamento dos bits desses dados a partir de uma determinada chave ou par de
chaves, dependendo do sistema criptográfico escolhido. Atualmente, a criptografia é
amplamente utilizada na WEB, em segurança a fim de autenticar os usuários para lhes
fornecer acesso, na proteção de transações financeiras e em redes de comunicação.

Cifras e Códigos
A cifra é um ou mais algoritmos que cifram e decifram um texto. A operação do
algoritmo costuma ter como parâmetro uma chave criptográfica. Tal parâmetro costuma
ser secreto (conhecido somente pelos comunicantes). A cifra pode ser conhecida, mas
não a chave; assim como se entende o mecanismo de uma fechadura comum, mas não
se pode abrir a porta sem uma chave real.

104
Na linguagem não técnica, um Código secreto é o mesmo que uma cifra. Porém, na
linguagem especializada os dois conceitos são distintos. Um código funciona
manipulando o significado, normalmente pela substituição simples de palavras ou
frases. Uma cifra, ao contrário, trabalha na representação da mensagem (letras, grupos
de letras ou, atualmente, bits).

Por exemplo, um código seria substituir a frase "Atacar imediatamente" por "Mickey
Mouse". Uma cifra seria substituir essa frase por "sysvst ozrfosyszrmyr". No Dia D, por
exemplo, as praias de desembarque não eram conhecidas pelo seu nome próprio, mas
pelos seus códigos (Omaha, Juno, etc.).

Basicamente, códigos não envolvem chave criptográfica, apenas tabelas de substituição

ou mecanismos semelhantes. Códigos podem ser então encarados como cifras cuja a
chave é o próprio conhecimento do mecanismo de funcionamento da cifra.

Chave Criptográfica

Uma chave criptográfica é um valor secreto que modifica um algoritmo de encriptação.

A fechadura da porta da frente da sua casa tem uma série de pinos. Cada um desses
pinos possui múltiplas posições possíveis. Quando alguém põe a chave na fechadura,
cada um dos pinos é movido para uma posição específica. Se as posições ditadas pela
chave são as que a fechadura precisa para ser aberta, ela abre, caso contrário, não.

Visão geral: objetivos

A criptografia tem quatro objetivos principais:

1. confidencialidade da mensagem: só o destinatário autorizado deve ser capaz de

extrair o conteúdo da mensagem da sua forma cifrada. Além disso, a obtenção
de informação sobre o conteúdo da mensagem (como uma distribuição
estatística de certos caracteres) não deve ser possível, uma vez que, se o for,
torna mais fácil a análise criptográfica.
2. integridade da mensagem: o destinatário deverá ser capaz de determinar se a
mensagem foi alterada durante a transmissão.
3. autenticação do remetente: o destinatário deverá ser capaz de identificar o
remetente e verificar que foi mesmo ele quem enviou a mensagem.
4. não-repúdio ou irretratabilidade do emissor: não deverá ser possível ao emissor
negar a autoria da mensagem.

Nem todos os sistemas ou algoritmos criptográficos são utilizados para atingir todos os
objetivos listados acima. Normalmente, existem algoritmos específicos para cada uma
destas funções. Mesmo em sistemas criptográficos bem concebidos, bem
implementados e usados adequadamente, alguns dos objetivos acima não são práticos
(ou mesmo desejáveis) em algumas circunstâncias. Por exemplo, o remetente de uma
mensagem pode querer permanecer anônimo, ou o sistema pode destinar-se a um
ambiente com recursos computacionais limitados.

Criptografia Clássica

105
Um bastão reconstruído dos gregos antigos, a Cítala era utilizada para envio de
mensagens secretas

Podemos dizer que o uso da criptografia é tão antigo quanto a necessidade do homem
em esconder a informação. Muitos pesquisadores atribuem o uso mais antigo da
criptografia conhecido aos hieróglifos usados em monumentos do Antigo Egito (cerca
de 4500 anos atrás). Diversas técnicas de ocultar mensagens foram utilizadas pelos
gregos e romanos.

A criptografia pré-computacional era formada por um conjunto de métodos de

substituição e transposição dos caracteres de uma mensagem que pudessem ser
executados manualmente (ou até mesmo mentalmente) pelo emissor e pelo destinatário
da mensagem. O surgimento de máquinas especializadas e, posteriormente, dos
computadores ocasionou uma significativa evolução das técnicas criptográficas.

Criptografia Moderna
A era da criptografia moderna começa realmente com Claude Shannon, possivelmente o
pai da criptografia matemática. Em 1949 ele publicou um artigo Communication
Theory of Secrecy Systems com Warren Weaver. Este artigo, junto com outros de seus
trabalhos que criaram a área de Teoria da Informação estabeleceu uma base teórica
sólida para a criptografia e para a criptoanálise. Depois disso, quase todo o trabalho
realizado em criptografia se tornou secreto, realizado em organizações governamentais
especializadas (como o NSA nos Estados Unidos). Apenas em meados de 1970 as
coisas começaram a mudar.

Em 1976 aconteceram dois grandes marcos da criptografia para o público. O primeiro

foi a publicação, pelo governo americano, do DES (Data Encryption Standard), um
algoritmo aberto de criptografia simétrica, selecionado pela NIST em um concurso onde
foi escolhido uma variante do algoritmo Lucifer, proposto pela IBM. O DES foi o
primeiro algoritmo de criptografia disponibilizado abertamente ao mercado.

O segundo foi a publicação do artigo New Directions in Cryptography por Whitfield

Diffie e Martin Hellman, que iniciou a pesquisa em sistemas de criptografia de chave
pública. Este algoritmo ficou conhecido como "algoritmo Diffie-Hellman para troca de
chaves" e levou ao imediato surgimento de pesquisas neste campo, que culminou com a
criação do algoritmo RSA, por Ronald Rivest, Adi Shamir e Leonard Adleman.

Criptografia Quântica

106
Desenvolvimento da técnica reunindo o conceito de criptografia e a teoria quântica é
mais antigo do que se imagina, sendo anterior à descoberta da criptografia de Chave
Pública. Stephen Wiesner escreveu um artigo por volta de 1970 com o título:
"Conjugate Coding" que permaneceu sem ser publicado até o ano de 1983. Em seu
artigo, Wiesner explica como a teoria quântica pode ser usada para unir duas mensagens
em uma única transmissão quântica na qual o receptor poderia decodificar cada uma das
mensagens porém nunca as duas simultaneamente, pela impossibilidade de violar uma
lei da natureza (o princípio de incerteza de Heisenberg).7

Utilizando-se pares de fótons, a criptografia quântica permite que duas pessoas

escolham uma chave secreta sem jamais terem se visto, trocado alguma mensagem ou
mesmo algo material. A criptografia quântica oferece a possibilidade de gerar uma
chave segura se o sinal é um objeto quântico, assim, o termo mais correto seria
Distribuição de Chave Quântica (Quantum Key Distribution - QKD) e não Criptografia
Quântica. É interessante notar que a Criptologia atual está amparada na Matemática mas
com a introdução desse conceito de mensagens criptografadas por chaves quânticas a
física passou a ter importância primordial no tema. O maior problema para
implementação da Criptografia quântica ainda é a taxa de erros na transmissão dos
fótons seja por via aérea ou fibra ótica. Os melhores resultados obtidos atualmente se
dão em cabos de fibra ótica de altíssima pureza, e conseqüentemente elevadíssimo custo
também, alcançando algo em torno de 70 km.

Por via aérea a distância chega a algumas centenas de metros e qualquer tentativa de se
aumentar essa distância tanto em um quanto em outro método a taxa de erros se torna
muito grande e inviabiliza o processo. O desenvolvimento de tecnologias que permitam
o perfeito alinhamento dos polarizadores, fibras óticas melhores e amplificadores
quânticos de sinais permitirá que o sistema de Distribuição de Chaves Quânticas venha
a ser o novo padrão de segurança de dados.

A Criptografia Quântica se destaca em relação aos outros métodos criptográficos pois

não necessita do segredo nem do contato prévio entre as partes, permite a detecção de
intrusos tentando interceptar o envio das chaves, e é incondicionalmente segura mesmo
que o intruso tenha poder computacional ilimitado. A única forma possível de falha no
processo seria se utilizar de um ardil onde a comunicação fosse interceptada e
substituída, tanto para o emissor quanto para o receptor, criando assim um canal de
comunicação controlado pelo intruso. O processo ainda apresenta um elevado custo de
implantação, mas o desenvolvimento tecnológico poderá torná-la acessível a todas as
aplicações militares, comerciais e de fins civis em geral.

Gestão de direitos digitais

A criptografia é central no tema de gestão de direitos digitais (DRM), um grupo de
técnicas para controlar e restringir tecnologicamente o uso de direitos autorais e suas
marcas registradas. Em 1998 a lei Estadounidense Millennium Copyright Act (DMCA)
criminaliza toda a produção e diseminação de certas técnicas (não conhecidas ou mais
tarde conhecidas) da criptogafia, especialmente aquelas que poderiam ser utilizadas para
ultrapassar o DRM. Leis e códigos similares ao DRM foram desde essa altura
aparecendo em vários países e regiões, incluindo a implementação Directive on the
harmonisation of certain aspects of copyright and related rights in the information

107
society na Europa. Leis com restrições similares estão a ser propostos pelos Estados
membros da Organização Mundial da Propriedade Intelectual.

Alguns algoritmos e sistemas criptográficos

Funções de Hash criptográfico, ou message digest

 MD5
 SHA-1
 RIPEMD-160
 Tiger

Sistemas Free/Open Source

 PGP
 GPG
 SSL
 IPSec / Free S/WAN

Algoritmos assimétricos ou de chave pública

 Curvas elípticas
 Diffie-Hellman
 DSA de curvas elípticas
 El Gamal
 RSA

Algoritmos simétricos

 Máquina Enigma (Máquina alemã de rotores utilizada na 2a Guerra Mundial)

 DES - Data Encryption Standard (FIPS 46-3, 1976)
 RC4 (um dos algoritmos criados pelo Prof. Ron Rivest)
 RC5 (também por Prof. Ron Rivest)
 Blowfish (por Bruce Schneier)
 IDEA - International Data Encryption Algorithm (J Massey e X Lai)
 AES (também conhecido como RIJNDAEL) - Advanced Encryption Standard
(FIPS 197, 2001)
 RC6 (Ron Rivest)

Referências
1. FIARRESGA, Victor Manuel Calhabrês; Jorge Nuno Oliveira e Silva (2010).
Criptografia e Matemática. Repositório aberto da Universidade de Lisboa Teses
de mestrado. Página visitada em 17 de Junho de 2012.
2. Knudsen, Jonathan. Java Cryptography. Beijing: O´Reilly, 1998. 344 p. ISBN 1-
56592-402-9
3. ALECRIM, Emerson (2010). Criptografia. InfoWester Propagando
Conhecimento. Página visitada em 17 de Junho de 2012.

108
 4. Young, Adam L.; Yung, Moti. Malicious Cryptography: Exposing
Cryptovirology. Indianapolis: Addison-Wesley, 2004. 392 p. ISBN 0-7645-4975-
8
5. Gaines, Hele Fouché. Cryptanalysis. New York: Dover Publications, 1956. 237
p.
6. Solomon, David. Coding for Data and Computer Communications. Northridge,
California: Springer, 2005. 548 p. ISBN 0-387-21245-0
7. Introdução à criptografia quântica (PDF). Revista Brasileira de Ensino de
Física, v. 27, n. 4, p. 517 - 526, (2005). Página visitada em 10 de fevereiro de
2009.

Bibliografia
 Hook, David. Beginning Cryptography with Java. Indianapolis: Wrox,
2005. 448 p. ISBN 0-7645-9633-0
 Schneier, Bruce. Applied Cryptography. New York: John Wiley and Sons,
1996. 758 p. ISBN 0-471-11709-9
 Viktoria Tkotz, Criptografia -Segredos Embalados para Viagem. Novatec
Editora. ISBN 85-7522-071-3.

Assinatura digital
Origem: Wikipédia, a enciclopédia livre.

Esquema de funcionamento da assinatura digital (em castelhano).

Este artigo trata da assinatura digital utilizando a tecnologia PKI (Public Key
Infrastructure), que é apenas uma das técnicas disponíveis para gerar documentos
digitais com validade legal, outros métodos de assinatura digital estão em uso e a
tecnologia continua evoluindo e apresentando alternativas à PKI.

Em criptografia, a assinatura ou firma digital é um método de autenticação de

informação digital tipicamente tratada como análoga à assinatura física em papel.
Embora existam analogias, existem diferenças importantes. O termo assinatura
eletrônica, por vezes confundido, tem um significado diferente: refere-se a qualquer
mecanismo, não necessariamente criptográfico, para identificar o remetente de uma
mensagem electrônica. A legislação pode validar tais assinaturas eletrônicas como
endereços Telex e cabo, bem como a transmissão por fax de assinaturas manuscritas em
papel.

A utilização da assinatura ou firma digital providencia a prova inegável de que uma

mensagem veio do emissor. Para verificar este requisito, uma assinatura digital deve ter
as seguintes propriedades:

 autenticidade - o receptor deve poder confirmar que a assinatura foi feita pelo
emissor;
 integridade - qualquer alteração da mensagem faz com que a assinatura não
corresponda mais ao documento;

109
  irretratabilidade - o emissor não pode negar a autenticidade da mensagem.

Essas características fazem a assinatura digital ser fundamentalmente diferente da

assinatura manuscrita.

História
Em 1976, Whitfield Diffie e Martin Hellman descreveram primeiramente a noção de um
esquema de assinatura digital, embora eles apenas conjecturaram que tais esquemas
existissem. Apenas mais tarde, Ronald Rivest, Adi Shamir, e Len Adleman inventaram
o algoritmo RSA que poderia ser usado para assinaturas digitais primitivas (note que
isso apenas serve como uma prova do conceito, e as assinaturas RSA puras não são
seguras). O primeiro pacote de software amplamente comercializado a oferecer a
assinatura digital foi o Lotus Notes 1.0, em 1989, que usava o algoritmo RSA.

Como notado ainda cedo, esse esquema básico não é muito seguro. Para prevenir
ataques pode-se primeiro aplicar uma função de criptografia hash para a mensagem 'm' e
então aplicar o algoritmo RSA ao resultado. Outros esquemas de assinatura digital
foram logo desenvolvidos depois do RSA, o mais antigo sendo as assinaturas de
Lamport, de Merkle (também conhecidas como árvores de Hash) e as de Rabin.

Em 1984, Shafi Goldwasser, Silvio Micali, e Ronald Rivest tornaram-se os primeiros a

rigorosamente definir os requerimentos de segurança de esquemas de assinatura digital.
Eles descreveram uma hierarquia de modelos de ataque para esquemas de assinatura, e
também apresentaram o esquema de assinatura GMR, o primeiro que podia se prevenir
até mesmo de uma forja existencial contra um ataque de mensagem escolhida.

Como funciona?
Existem diversos métodos para assinar digitalmente documentos, e esses métodos estão
em constante evolução. Porém de maneira resumida uma assinatura típica envolve dois
processos criptográficos: o hash (resumo) e a encriptação deste hash.

Em um primeiro momento é gerado um resumo criptográfico da mensagem através de

algoritmos complexos (Exemplos: MD5, SHA-1, SHA-256) que reduzem qualquer
mensagem sempre a um resumo de mesmo tamanho. A este resumo criptográfico se dá
o nome de hash. Uma função de hash deve apresentar necessariamente as seguintes
características:

 Deve ser impossível encontrar a mensagem original a partir do hash da mensagem.

 O hash deve parecer aleatório, mesmo que o algoritmo seja conhecido. Uma função de
hash é dita forte se a mudança de um bit na mensagem original resulta em um novo
hash totalmente diferente.
 Deve ser impossível encontrar duas mensagens diferentes que levam a um mesmo
hash.

Neste ponto, o leitor mais atento percebe um problema: Se as mensagens possíveis são
infinitas, mas o tamanho do hash é fixo, é impossível impedir que mensagens diferentes
levem a um mesmo hash. De fato, isto ocorre. Quando se encontram mensagens

110
diferentes com hashs iguais, é dito que foi encontrada uma colisão de hashes. Um
algoritmo onde isso foi obtido deve ser abandonado. As funções de hash estão em
constante evolução para evitar que colisões sejam obtidas. Cabe destacar porém que a
colisão mais simples de encontrar é uma aleatória, ou seja, obter colisões com duas
mensagens geradas aleatoriamente, sem significado real. Quando isto ocorre os
estudiosos de criptografia já ficam atentos, porém para comprometer de maneira
imediata a assinatura digital seria necessário obter uma mensagem adulterada que tenha
o mesmo hash de uma mensagem original fixa, o que é teoricamente impossível de
ocorrer com os algoritmos existentes hoje. Desta forma, garante-se a integridade da
assinatura.

Após gerar o hash, ele deve ser criptografado através de um sistema de chave pública,
para garantir a autenticação e a irretratabilidade. O autor da mensagem deve usar sua
chave privada para assinar a mensagem e armazenar o hash criptografado junto a
mensagem original.

Para verificar a autenticidade do documento, deve ser gerado um novo resumo a partir
da mensagem que está armazenada, e este novo resumo deve ser comparado com a
assinatura digital. Para isso, é necessário descriptografar a assinatura obtendo o hash
original. Se ele for igual ao hash recém gerado, a mensagem está íntegra. Além da
assinatura existe o selo cronológico que atesta a referência de tempo à assinatura.

Aspectos legais
Legislações sobre o efeito e validade de assinaturas digitais:

Brasil

Conforme a Medida provisória 2.200-2, a lei brasileira determina que qualquer

documento digital tem validade legal se for certificado pela ICP-Brasil (a ICP oficial
brasileira). A medida provisória também prevê a utilização de certificados emitidos por
outras infra-estruturas de chaves públicas, desde que as partes que assinam reconheçam
previamente a validade destes.

O que a MP 2.200-2 portanto outorga à ICP-Brasil é a fé pública, considerando que

qualquer documento digital assinado com o certificado emitido pela ICP-Brasil pode de
fato ser considerado assinado pela própria pessoa.

Resultado igual pode ser obtido se o usuário de um certificado emitido por outra ICP
qualquer, depositar em cartório de registro o reconhecimento da mesma como sua
identidade digital. O que se quer preservar é o princípio da irrefutabilidade do
documento assinado, assim sendo, o registro em cartório de um documento no qual o
usuário reconhece como sendo seu um determinado certificado digital é prova mais que
suficiente para vincular a ele qualquer documento eletrônico assinado com aquele
certificado.

Comunidade Europeia

 Common Position EC 28/1999 – Community Framework for Electronic Signature

111
Estados Unidos da América

 Uniform Electronic Transactions Act (UETA)

 Electronic Signatures in Global and National Commerce Act (E-SIGN), através 15 U.S.C.
7001 et seq.

Outras tecnologias disponíveis oferecidas por empresas:

 RightSignature [1]
 Docusign [2]
 Echosign [3]
 Arx [4]
 TrueSeal [5]
 SigningHub[6]

Inglaterra, Escócia e Gales

 Electronic Communications Act, 2000

Índia

 Information Technology Act, 2000

Nova Zelândia

 Electronic Transactions Act, 2003 sections 22-24

Portugal

A legislação portuguesa prevê a utilização da assinatura digital no Decreto-Lei n.º 290-

D/99, republicado pelo Decreto-Lei n.º 62/2003, definindo-a como um documento
elaborado mediante processamento electrônico de dados.

Este Decreto-Lei procede à transposição da Directiva do Parlamento Europeu e do

Conselho nº 1999/93/CE, de 28 de Junho, relativa a um quadro legal comunitário para
as assinaturas electrónicas.

De acordo com a legislação portuguesa, as assinaturas electrónicas têm a mesma

validade probatória que as assinaturas manuscritas, desde que se baseiem em
certificados emitidos por entidades certificadoras credenciadas.

A autoridade de credenciação das entidades certificadoras é a Autoridade Nacional de

Segurança; a credenciação, contudo, é facultativa, podendo qualquer entidade não
credenciada exercer essa actividade. A Autoridade Nacional de Segurança publica a
lista das entidades credenciadas. Neste momento, em Portugal, para além da entidade
certificadora do Cartão de Cidadão, do Ministério da Justiça, da Assembleia da
República e da Entidade Certificadora Electrónica do Estado, há duas entidades
certificadoras privadas credenciadas pela Autoridade Nacional de Segurança para
emissão de certificados de assinatura electrónica qualificada, a Multicert e a
DigitalSign.

112
Autenticação
Origem: Wikipédia, a enciclopédia livre.

Autenticação (do grego : αυθεντικός = real ou genuíno, de 'authentes' = autor) é o ato

de estabelecer ou confirmar algo (ou alguém) como autêntico, isto é, que reivindica a
autoria ou a veracidade de alguma coisa. A autenticação também remete à confirmação
da procedência de um objeto ou pessoa, neste caso, frequentemente relacionada com a
verificação da sua identidade.

Gestão da Informação
É de grande relevância no processo de gestão da informação a proteção dos dados e dos
recursos envolvidos nele, de modo a garantir a acesso, alteração e liberação apenas por
pessoas devidamente autorizadas.

Segurança da informação
A segurança da informação está fortemente relacionada a administração moderna
representando um bem que por sua vez precisa ser protegido, visando minimizar riscos
no tocante ao extravio de informação, apoiando os retornos envolvidos de modo a
garantir a continuidade dos negócios.

Em segurança da informação, a autenticação é um processo que busca verificar a

identidade digital do usuário de um sistema, normalmente, no momento em que ele
requisita um log in (acesso) em um programa ou computador. A autenticação
normalmente depende de um ou mais "fatores de autenticação".

O termo "autorização" é muitas vezes confundido com o termo autenticação, mas apesar
de serem relacionados, o significado de ambos é muito diferente. A autenticação é o
processo que verifica a identidade de uma pessoa, por sua vez, a autorização verifica se
esta pessoa possui permissão para executar determinadas operações. Por este motivo, a
autenticação sempre precede a autorização.

Controle de acesso

O controle de acesso é um exemplo comum de adoção de mecanismos de autenticação.

Um sistema computacional, cujo acesso é permitido apenas a usuários autorizados, deve
detectar e excluir os usuários não autorizados. O acesso é controlado por um
procedimento que estabelece a identidade do usuário com algum grau de confiança
(autenticação), e só então concede determinados privilégios (autorização) de acordo
com esta identidade. Alguns exemplos de controle de acesso são encontrados em
sistemas que permitem:

 saque de dinheiro de um caixa eletrônico;

 comunicação com um computador através da Internet;
 navegação em um sistema de Internet banking.

Ambientes Afetados

113
Os Ambientes Afetados São todos os frameworks de aplicações web são vulneráveis a
furos de autenticação e de gerência de sessão.

Vulnerabilidade

Os Furos da Vulnerabilidade no mecanismo principal de autenticação não são

incomuns, mas falhas são geralmente introduzidas a partir de funções menos
importantes de autenticação como logout, gerência de senhas, timeout, recordação de
dados de logon, pergunta secreta e atualização de conta.

Verificação de Segurança

A Verificação de Segurança são abordagens automatizadas ferramentas de localização

de vulnerabilidade têm dificuldade em esquemas de autenticação e de sessão
personalizados. As ferramentas de análise estáticas provavelmente não detectarão
problemas em códigos personalizados para autenticação e gerência de sessão.

Abordagens Manuais

Essas Abordagens Manuais é pra ser feito com revisão de código e testes, especialmente
combinados, são muito efetivos para a verificação de autenticação, gerência de sessão e
funções secundárias estão todas implementadas corretamente.

Implementação dos Mecanismos

1. Autenticação baseada no conhecimento – Login e senha

Remove caracteres indevidos que são utilizados em ataques como os de SQL Injection;

Verificar se a variável login está preenchida;

Validar formulários, de acordo com as regras definidas;

Não permitir que as variáveis login e senha estejam em branco;

Senha seja criptografada;

Verifica se o usuário existe no banco de dados e se a senha confere.

Se a senha estiver correta, a aplicação lista os privilégios deste e salva as informações

em variáveis de sessão,

Libera o acesso e redirecionando para a página inicial do sistema.

2. Autenticação baseada na propriedade – Login, senha e token

Utiliza um token, além do convencional login e senha;

Durante o cadastro de cada usuário, são cadastrados no banco de dados os tokens;

114
Estes tokens são gerados de forma randômica por meio da função rand() do PHP;

Na tela de autenticação é solicitado ao usuário seu login, sua senha e uma chave;

Após a verificação correta, o acesso é liberado.

3. Autenticação baseada na característica – Digital

Cada usuário tem em seu cadastro no banco de dados uma imagem de sua digital, ou
várias;

Além disso, é necessário um hardware que faça a leitura da digital;

Um aparelho que possui um software interno recebe as imagens das digitais cadastradas
no banco de dados e faz a comparação;

Com a digital em leitura no momento, retornando o usuário;

Caso haja confirmação da digital, o seu acesso ao sistema é liberado.

Cada mecanismo possui suas vantagens e desvantagem, devendo ser os mesmos

aplicados de modo a atender a necessidade do negócio visando garantir a autenticidade
das entidades envolvidas. O que vai definir qual dos métodos será o adotado é o valor
da informação a ser protegida para as entidades envolvidas, cujo o risco deverá ser
aceito em níveis aceitáveis.

Proteção

A Proteção da Autenticação depende da comunicação segura de armazenamento de

credenciais. Primeiramente, assegure-se de que o SSL é a única opção para todas as
partes autenticadas do aplicativo e que todas as credenciais estão guardadas de uma
forma encriptada ou em Hash.

Fatores de autenticação
Os fatores de autenticação para humanos são normalmente classificados em três casos:

 aquilo que o usuário é (impressão digital, padrão retinal, sequência de DNA, padrão de
voz, reconhecimento de assinatura, sinais elétricos unicamente identificáveis
produzidos por um corpo vivo, ou qualquer outro meio biométrico).
 aquilo que o usuário tem (cartão de identificação, security token, software token ou
telefone celular)
 aquilo que o usuário conhece (senha, frase de segurança, PIN)

Frequentemente é utilizada uma combinação de dois ou mais métodos. A Secretaria da

Receita Federal, por exemplo, pode requisitar um certificado digital (o que se possui)
além da senha (o que se sabe) para permitir o acesso a uma declaração de imposto de
renda, neste caso o termo "autenticação de dois fatores" é utilizado.

115
Certificado digital
Origem: Wikipédia, a enciclopédia livre.

Um certificado digital é um arquivo de computador que contém um conjunto de

informações referentes a entidade para o qual o certificado foi emitido (seja uma
empresa, pessoa física ou computador) mais a chave pública referente à chave privada
que se acredita ser de posse unicamente da entidade especificada no certificado.

Uso
Um certificado digital é usado para ligar uma entidade a uma chave pública. Para
garantir digitalmente, no caso de uma Infraestrutura de Chaves Públicas (ICP), o
certificado é assinado pela Autoridade Certificadora (AC) que o emitiu e no caso de um
modelo de Teia de Confiança (Web of trust) como o PGP, o certificado é assinado pela
própria entidade e assinado por outros que dizem confiar naquela entidade. Em ambos
os casos as assinaturas contidas em um certificado são atestamentos feitos por uma
entidade que diz confiar nos dados contidos naquele certificado.

A troca de chaves simétricas entre usuários para comunicação segura tornou-se

impraticável, a criptografia de chaves públicas provê um meio de solucionar este
problema. Resumindo, se Alice deseja que outros tenham a capacidade de enviar-lhe
mensagens secretas, tudo que ela precisa fazer é publicar a sua chave pública. Qualquer
pessoa que possua a chave pública de Alice poderá enviar-lhe informações secretas.
Infelizmente, Davi também pode publicar uma chave pública (para a qual Davi sabe a
chave privada relacionada) alegando ser a chave pública de Alice e assim tendo a
capacidade de decifrar as mensagens secretas destinadas a Alice mas que foram cifradas
pela chave pública de Davi. Mas se Alice possuir um certificado digital com a sua chave
pública e este certificado for assinado digitalmente por João, qualquer pessoa que confie
em João poderá sentir-se confortável em confiar no certificado de Alice.

Em uma ICP, João será uma AC, a qual tem a confiança de todos os participantes
daquela ICP. Em um modelo de Teia de confiança, João poderá ser qualquer usuário, e
confiar ou não em um atestamento de um usuário que diz que uma chave pública
específica pertence a Alice, está a cargo da pessoa que deseja enviar a mensagem para
Alice.

Em situações reais, Alice pode não conhecer a AC de Bob (talvez seus certificados não
tenham sido emitidos pela mesma AC), então o certificado de Bob, também pode incluir
a chave pública da sua AC assinada por uma AC de "maior nível" (Ex. a AC Raiz ICP-
BRASIL que emitiu os certificados da AC intermediária). Este processo leva a uma
hierarquia de certificados, e para relacionamentos de confiança ainda mais complexos.
A maioria das vezes ICP se refere ao software que administra os certificados. Em
sistemas ICP X.509, a hierarquia de certificados é sempre baseada em uma árvore de
cima a baixo, com o certificado raiz no topo, representando a AC "principal" que não
precisa ser assinado por um terceiro confiável (João). O certificado raiz é auto assinado.

Um certificado pode ser revogado se for descoberto que a sua chave privada relacionada
foi comprometida, ou se o seu relacionamento (entre uma entidade e a sua chave
pública) embutida no certificado estiver incorreta ou foi mudada; isto poderá ocorrer,

116
por exemplo, se uma pessoa muda de nome ou CPF. Uma revogação não é comum, mas
a possibilidade da ocorrência significa que quando um certificado é confiável, o usuário
deverá sempre verificar a sua validade. Isto pode ser feito comparando o certificado
com uma Lista de certificados revogados (LCR). Seu objetivo é mostrar todos os
certificados revogados ou cancelados no âmbito daquela AC. Garantir que a lista está
correta e atualizada é a parte mais importante em uma ICP centralizada, o que às vezes
não é feito corretamente. Para a LCR ser efetiva, precisa estar disponível o tempo todo
para qualquer um que a precisar e ser atualizada frequentemente. A outra maneira de
conferir a validade de um certificado, é fazer uma consulta a AC usando o Online
Certificate Status Protocol (OCSP) para saber o estado de um certificado específico.

Um certificado normalmente inclui:

 Informações refentes a entidade para o qual o certificado foi emitido (nome, email,
CPF/CNPJ, PIS etc.)
 A chave pública referente a chave privada de posse da entidade especificada no
certificado
 O período de validade
 A localização do "centro de revogação" (uma URL para download da LCR, ou local para
uma consulta OCSP)
 A(s) assinatura(s) da(s) AC/entidade(s) que afirma que a chave pública contida naquele
certificado confere com as informações contidas no mesmo

O padrão mais comum para certificados digitais no âmbito de uma ICP é o ITU-T
X.509. O X.509 foi adaptado para a Internet pelo grupo da Internet Engineering Task
Force (IETF) PKIX.

A anatomia de um certificado X.509

Um certificado padrão X.509 contém os seguintes campos:

 Versão - Contem a versão do certificado X.509, atualmente versão 3

 Número serial - Todo certificado possui um, não é globalmente único, mas único no
âmbito de uma AC, ac LCRs usam o serial para apontar quais certificados se encontram
revogados
 Tipo de algoritmo - Contem um identificador do algoritmo criptográfico usado pela AC
para assinar o certificado juntamente com o tipo de função de hash criptográfica
usada no certificado
 Nome do titular - Nome da entidade para o qual o certificado foi emitido
 Nome do emitente - Autoridade Certificadora que emitiu/assinou o certificado
 Período de validade - Mostra o período de validade do certificado no formato "Não
antes" e "Não depois" (Ex. "Não antes de 05/03/2006 - 14:35:02" "Não depois de
05/03/2007 - 14:03:20")
 Informações de chave pública da entidade
o Algoritmo de chave pública
o Chave pública
 Assinatura da AC - A garantia que a AC provê sobre a veracidade das informações
contidas neste certificado de acordo com as políticas da AC

117
  Identificador da chave do titular - É uma extensão do X.509 que possui um
identificador numérico para a chave pública contida neste certificado, especialmente
útil para que programas de computador possam se referir a ela
 Identificador da chave do emitente - A mesma ideia mencionada anteriormente, só
que se referindo a chave pública da AC que emitiu o certificado
 Atributos ou extensões - A vasta maioria dos certificados X.509 possui campos
chamados extensões (OID) que proveêm algumas informações extras, como cadastros
adicionais do titular e do emitente, especificações de propósito do certificado e etc.

Criando um certificado digital

1. A entidade que deseja emitir o certificado gera um par de chaves criptográficas (uma
chave pública e uma chave privada).
2. Em seguida a entidade gera um arquivo chamado Certificate Signing Request (CSR)
composto pela chave pública da entidade e mais algumas informações que a AC requer
sobre a entidade e é assinado digitalmente pela chave privada da própria entidade e
envia o CSR cifrado pela chave privada da AC.
3. Então é necessário o comparecimento físico de um indivíduo responsável por aquela
identidade em uma Autoridade de Registro (AR) (em alguns casos a AR vai até o
cliente) para confirmação dos dados contidos no CSR e se necessário o acréscimo de
mais algum dado do responsável pelo certificado e emissão do certificado.
4. Finalmente o CSR é "transformado" em um certificado digital assinado pela AC e
devolvido ao cliente.
5. Então o browser/aplicativo de gerência de certificados combina o certificado + a chave
privada criando o conceito de "Identidade digital", normalmente salvando a chave
privada em um cofre protegido por uma frase senha que será necessária para o
posterior acesso a chave privada.

Os browsers existentes hoje em dia como Internet Explorer, Firefox e Opera,

conhecidos como o sistema FIOPEX, FI de FIrefox, OP de OPera, e Ex de Internet
EXplorer fazem a parte do processo que depende do cliente (até o momento de enviar o
CSR à AC) automaticamente. O processo também pode ser feito manualmente usando
alguma biblioteca criptográfica como o OpenSSL por exemplo.

Aspectos legais
A Medida Provisória nº 2.200-2, de 24 de agosto de 2001 define as regras para a criação
da ICP-Brasil e da DPC associada bem como a utilização de certificados digitais no
Brasil, aspectos legais e aspectos necessários para uma entidade se tornar uma AC
Intermediária e assim emitir certificados digitais para outras entidades garantindo
autenticidade, integridade, não repúdio e validade jurídica de trâmites eletrônicos por
essas entidades realizados.

A Lei 11.419 de 19 de dezembro de 2006 fundamenta os processos judiciais eletrônicos

no Brasil. Nela, existe o artigo 20 do capítulo 4, que altera o artigo 38 do Código de
Processo Civil (Lei 5.869, de 11 de janeiro de 1973) de forma que a autenticação por
certificados digitais também seja legalmente válida.

118
Auditoria em segurança da informação
Origem: Wikipédia, a enciclopédia livre.

A auditoria em segurança da informação tem o papel de assegurar a qualidade da

informação e participar do processo de garantia quanto a possíveis e indesejáveis
problemas de falha humana.

Com dados concentrados em formato digital e procedimentos invisíveis devido à

automação, os sistemas de informação são vulneráveis a destruição, abuso, alteração,
erro, fraude e a falhas de programas e equipamentos. Os sistemas on-line e os que
utilizam a Internet são os mais vulneráveis, pois seus dados e arquivos podem ser
acessados imediata e diretamente em terminais de computador ou em muitos pontos de
rede. Crackers podem invadir redes e causar sérios danos ao sistema e às informações
armazenadas, sem deixar qualquer rastro. Vírus de computador podem se propagar
rapidamente entupindo a memória de computadores e destruindo arquivos. Os softwares
em si também apresentam problemas e a má qualidade dos dados também pode causar
sérios impactos sobre o desenvolvimento do sistema.

Qualquer grande empresa precisa tomar providencias especiais para evitar as

vulnerabilidades. Para tanto, planos de recuperação pós-desastre incluem procedimentos
e instalações para restaurar os serviços de comunicação após terem sofrido algum tipo
de problema. Quando a empresa utiliza intranet ou Internet, firewalls e sistemas de
detecção de invasão ajudam a salvaguardar redes internas contra o acesso não
autorizado.

Segurança do Banco de Dados

Especial atenção deve ser dada ao banco de dados para o qual devem existir
dispositivos de segurança, procedimentos de autorização de acesso aos dados,
atualização das novas versões e procedimentos de cópias para possíveis restaurações.

A segurança das informações processadas pelo sistema de informática deve ser sempre
monitorada para verificar se os relatórios gerados estão corretos, se estão protegidas
contra fraudes, se as instalações e os equipamentos também estão protegidos.

Segurança de Redes
Quanto à segurança de redes as seguintes medidas de segurança devem ser tomadas:
uso da criptografia no envio de dados, monitoramento do sistema, cuidados com a
criação de novos usuários e uso de firewall, pois o firewall é um sistema desenvolvido
para prevenir acessos não autorizados a uma rede local de computadores. Os firewalls
são implementados através de programas de computador e dispositivos eletrônicos.
Através dele, os dados que entram ou saem da rede são examinados com a finalidade de
bloquear os dados que não estão de acordo com os critérios de segurança.

Apenas usuários autorizados podem ter acesso à rede e dentro da rede, eles só podem ter
acesso aos recursos realmente necessários para a execução de suas tarefas. Sendo que os
recursos críticos devem ser monitorados e seu acesso restrito a poucas pessoas..

119
Segurança Física
É importante a segurança física dos computadores. Deve-se avaliar o grau de segurança
proporcionado aos recursos envolvidos no ambiente de sistemas em relação às ameaças
externas existentes, como é o caso de um sinistro ou de um incêndio.

O ambiente onde os servidores ficam deve ter restrição de acesso físico, limpeza e
organização, dispositivos para monitoramento vinte e quatro horas por dia e
equipamentos de combate a sinistros. A infra-estrutura para os servidores deve contar
com rede elétrica estabilizada e cabeamento estruturado. As estações de trabalho devem
ter mobília adequada, equipamentos protegidos com lacres ou cadeados, limpeza e
configuração compatível com a carga de trabalho.

Vulnerabilidade
Origem: Wikipédia, a enciclopédia livre.

A vulnerabilidade na computação significa ter brecha em um sistema computacional,

também conhecida como bug.

Esta mesma pode ser explorada em um determinado sistema ou serviço vulnerável que
esteja rodando na máquina.

As vulnerabilidades mais exploradas nos dias de hoje, são as do tipo buffer overflow,
que muitas vezes pode dar privilégios de administrador para o invasor, rodar códigos
maliciosos remotamente, burlar particularidades de cada sistema, ataques de Negação de
Serviços (DDoS), e acesso irestrito ao sistema.

Além dessas, outra vulnerabilidade bastante recorrente nos sistemas é a enumeração de

usuários. Essa vulnerabilidade será apresentada a seguir.

Vulnerabilidade: enumeração de usuários

A enumeração de usuário é uma prática utilizada para identificar os usuários ativos em
um determinado sistema. Geralmente ela é utilizada para viabilizar ataques de
Força_bruta. A constatação da vulnerabilidade se dá através da possibilidade de
discernir entre usuário válidos e inválidos em uma aplicação. Existem várias falhas nas
aplicações que permitem a exploração dos usuários, no entanto, esse tipo de falha é mais
comum ser encontradas nos mecanismo de autenticação.

Comumente, um atacante irá interagir com o mecanismo de autenticação da aplicação

na tentativa de identificar o comportamento do sistema em resposta às requisições
efetuadas em diferentes cenários de autenticação, por exemplo, utilizando um usuário
válido e outro inválido. Em alguns casos, as aplicações fornecem respostas que revelam
se um determinado usuário existe na base de dados quando uma credencial inválida é
utilizada na requisição de autenticação.

Os testes de enumeração de usuários valida se a aplicação fornece, direta ou

indiretamente, alguma informação que permita a distinção entre usuários válidos de uma

120
aplicação. Abaixo serão apresentadas algumas abordagens que podem ser utilizadas
para nortear os testes no sentido de verificar a vulnerabilidade da aplicação quanto à
segurança da informação.

Cenários de teste para a enumeração de usuários com base nas respostas

das páginas

Autenticação com um usuário válido e senha válida

Registre a resposta fornecida pela aplicação quando um usuário válido e uma senha
correta sejam utilizados no request da autenticação. Verifique o tamanho e a resposta
do servidor;

Autenticação com um usuário válido e senha válida

Nesse cenário, o tester deve utilizar um usuário válido e uma senha inválida e registrar
a resposta de erro enviada pelo servidor para analisar o comportamento da aplicação
para esse caso. Geralmente as aplicações apresentam mensagens como: “Falha na
autenticação”; “Senha inválida”. Verifique o tamanho e a resposta do servidor

Autenticação com um usuário inválido

Nesse outro cenário, o tester deve utilizar um usuário inválido e senha inválida e
registrar o response do servidor. Geralmente as aplicações apresentam mensagens
como: “Usuário inválido”; “Login não encontrado”; “Conta inválida”. Verifique o
tamanho e a resposta do servidor;

Uma aplicação bem implementada deve retornar o mesmo tamanho e a mesma

mensagem de erro para requisições de autenticação inválida. Caso o tester perceba
que a aplicação apresenta tamanho e códigos de resposta diferentes para cenários de
requisições mal sucedidas de autenticação, como nos cenários 2 e 3 acima, é indícios
de vulnerabilidade na aplicação

Exemplo de indicio de vulnerabilidade:

Request: Usuário Válido / Senha Inválida

Response: “Senha incorreta” (tamanho: 1500)

Request: Usuário Inválido / Senha Inválida

Response: “Usuário não encontrado” (tamanho: 1780)

No exemplo acima é perceptível que no primeiro request a aplicação revela que o

usuário é válido (portanto existente na base de dados) já que a resposta identifica que
apenas a senha estava incorreta. O segundo response também revela claramente que
o usuário requisitado não é válido. Com essas informações já é possível a um atacante
interagir com a aplicação realizando requests com nomes variados de usuários para
verificar qual deles a aplicação irá identificar como usuário válido (com base no
response retornado).

121
Enumeração de usuários com base nos códigos de erros das páginas de
login

Algumas aplicações web apresentam códigos de erros ou mensagens específicas que

podem ser analisadas pelos atacantes;

Enumeração de usuários com base em URLs

Algumas aplicações web realizam redirecionamento de página quando falhas de

autenticação acontecem. As URLs utilizadas para redirecionamentos podem ser
analisadas para identificar os usuários válidos.

Exemplo de indicio de vulnerabilidade:

Usuário Válido / Senha Inválida:

http:// www.teste.com/err.jsp?User=usuario&Error=0

Usuário Inválido / Senha Inválida:

http:// www.teste.com/err.jsp?User=usuario&Error=2

Enumeração de usuários com base nos códigos de respostas do servidor

(Response Code)

Geralmente os servidores de aplicação, quando não são configurados de forma

adequada, acabam apresentando mensagem de erro padrão para requisição
recursos/diretórios. Esses response na maioria das vezes são:

“403 Forbidden”, para indicar que o recurso existe, porém não há permissão suficiente
para que a requisição possa acessá-lo;

Ou

“404 Not found”, para indicar que o recurso não existe.

Algumas aplicações são desenvolvidas utilizando princípios REST, permitindo assim

que os recursos da aplicação, como a conta do usuário, possam ser associados à URLs .
(Exemplo: A URL http:// www.teste.com.br/usuario01 faz referencia à conta do
usuário 01). Dessa forma, um atacante pode utilizar os response code retornado pelo
servidor para enumerar os usuários da aplicação.

Exemplo de indicio de vulnerabilidade:

Usuário Válido:

Request: http:// www.teste.com/usuario01

Response: 403 Forbidden

Usuário Inválido:

122
 Request: http:// www.teste.com/usuario01

Response: 404 Not Found

No primeiro caso o usuário existi mas a página não é exibida visto que o servidor
responde com o código ”403 Forbidden”. Já no segundo caso, o código ”404 Not
Found” indica que o usuário não existe na base da aplicação. Com essas informações é
possível a enumeração dos usuários da aplicação por um atacante.

Nota: Nem sempre o servidor apresenta um response code 404 Not Found quando um
recurso não existente for solicitado. Ao invés, ele responde com o response code 200
OK mas com um imagem que representa o erro. Para esses casos, um atacante atente
associará a imagem de erro à um usuário não existente. Esse mesmo raciocínio pode ser
utilizado para qualquer resposta enviado pelo servidor, bastando diferenciar qual tipo de
resposta representa um usuário válido e qual representa um usuário inválido.

Enumeração de usuários com base nas funcionalidades de recuperação de

senha

Aplicações que disponibilizam funcionalidades de recuperação de senhas, muitas vezes

permitem que os usuários possam ser enumerados com base nas mensagens que
apresentam:

Exemplo de indicio de vulnerabilidade:

Usuário Válido / Senha Inválida:

Mensagem: “Sua nova senha foi enviada com sucesso para o email cadastrado”

Usuário Inválido / Senha Inválida:

Mensagem: “O email informado não foi encontrado”

Ferramentas para exploração de vulnerabilidades

Existem ferramentas específicas para se explorar as vulnerabilidades, cada ferramenta
para a sua respectiva vulnerabilidade a ser explorada (na maioria das vezes escritas em
linguagem C e Assembly), essas ferramentas são chamadas de exploits.

Rede de computadores
Origem: Wikipédia, a enciclopédia livre.

Uma rede de computadores é formada por um conjunto de módulos processadores

capazes de trocar informações e partilhar recursos, interligados por um sub-sistema de
comunicação, ou seja, é quando há pelo menos 2 ou mais computadores e outros
dispositivos interligados entre si de modo a poderem compartilhar recursos físicos e
lógicos, estes podem ser do tipo: dados, impressoras, mensagens (e-mails),entre outros.1

123
A Internet é um amplo sistema de comunicação que conecta muitas redes de
computadores. Existem várias formas e recursos de vários equipamentos que podem ser
interligados e compartilhados, mediante meios de acesso, protocolos e requisitos de
segurança.

Os meios de comunicação podem ser: linhas telefónicas, cabo, satélite ou comunicação

sem fios (wireless).

O objectivo das redes de computadores é permitir a troca de dados entre computadores e

a partilha de recursos de hardware e software. 2

conectores RJ-45 usados para conectar redes em informática.

Imagem de um backbone, usado para interligar grandes redes, como a própria internet.

História
Antes do advento de computadores dotados com algum tipo de sistema de
telecomunicação, a comunicação entre máquinas calculadoras e computadores antigos
era realizada por usuários humanos através do carregamento de instruções entre eles.
Em setembro de 1940, George Stibitz usou uma máquina de teletipo para enviar
instruções para um conjunto de problemas a partir de seu Model K na Faculdade de
Dartmouth em Nova Hampshire para a sua calculadora em Nova Iorque e recebeu os
resultados de volta pelo mesmo meio. Conectar sistemas de saída como teletipos a
computadores era um interesse na Advanced Research Projects Agency (ARPA)

124
quando, em 1962, J. C. R. Licklider foi contratado e desenvolveu um grupo de trabalho
o qual ele chamou de a "Rede Intergaláctica", um precursor da ARPANET.

Em 1964, pesquisadores de Dartmouth desenvolveram o Sistema de Compartilhamento

de Tempo de Dartmouth para usuários distribuídos de grandes sistemas de
computadores. No mesmo ano, no MIT, um grupo de pesquisa apoiado pela General
Electric e Bell Labs usou um computador (DEC’s PDP-8) para rotear e gerenciar
conexões telefônicas.

Durante a década de 1960, Leonard Kleinrock, Paul Baran e Donald Davies, de maneira
independente, conceituaram e desenvolveram sistemas de redes os quais usavam
datagramas ou pacotes, que podiam ser usados em uma rede de comutação de pacotes
entre sistemas de computadores.

Em 1969, a Universidade da Califórnia em Los Angeles, SRI (em Stanford), a

Universidade da Califórnia em Santa Bárbara e a Universidade de Utah foram
conectadas com o início da rede ARPANET usando circuitos de 50 kbits/s.

Redes de computadores e as tecnologias necessárias para conexão e comunicação

através e entre elas continuam a comandar as indústrias de hardware de computador,
software e periféricos. Essa expansão é espelhada pelo crescimento nos números e tipos
de usuários de redes, desde o pesquisador até o usuário doméstico.

Atualmente, redes de computadores são o núcleo da comunicação moderna. O escopo

da comunicação cresceu significativamente na década de 1990 e essa explosão nas
comunicações não teria sido possível sem o avanço progressivo das redes de
computadores.

Classificação
 Segundo a Arquitetura de Rede:
o Arcnet (Attached Resource Computer Network)
o Ethernet
o Token ring
o FDDI (Fiber Distributed Data Interface)
o ISDDN (Integrated Service Digital Network)
o Frame Relay
o ATM (Asynchronous Transfer Mode)
o X.25
o DSL (Digital Subscriber Line)

* Segundo a extensão geográfica (ver mais detalhes abaixo em: Modelagem de rede de
computadores segundo Tanenbaum):


o SAN (Storage Area Network)
o LAN (Local Area Network)
o PAN (Personal Area Network)
o MAN (Metropolitan Area Network)

125
 o WMAN Wireless Metropolitan Area Network, é uma rede boa sem fio de maior
alcance em relação a WLAN
o WAN (Wide Area Network)
o WWAN (Wireless Wide Area Network)
o RAN (Regional Area Network)
o CAN (Campus Area Network)

* Segundo a topologia:


o Rede em anel (Ring)
o Rede em barramento (Bus)
o Rede em estrela (Star)
o Rede em malha (Mesh)
o Rede em ponto-a-ponto (ad-hoc)
o Rede em árvore

* Segundo o meio de transmissão:


o Rede por cabo
 Rede de Cabo coaxial
 Rede de Cabo de fibra óptica
 Rede de Cabo de par trançado
o Rede sem fios
 Rede por infravermelhos
 Rede por microondas
 Rede por rádio

Hardware de Rede
 Elementos de Cabeamento:
o Cabo coaxial
o Cabo de fibra óptica
o Cabo de par trançado
o Repetidor
o Transceptor
 Estação de trabalho
 Placa de rede
 Concentrador (hub)
 Comutador (switch)
 Roteador (router/gateway)
 Modem
 Porta de Ligação (gateway router)
 Ponte (bridge)
 Servidor
o Servidor de arquivos
o Servidor de comunicações
o Servidor de disco
o Servidor de impressão
o Servidor de bluetooth

126
html
 Nível site
 blaque
o Ethernet
o PPP
 Nível de Rede
o IP
o IPX
 Nível de transporte
o TCP
o UDP
 Nível de sessão
o NetBIOS
o IPX
o Appletalk
 Nível de apresentação
 Nível de aplicação
o SMTP
o FTP
o Telnet
o SSH
o IRC
o HTTP
o POP3
o VFRAD

Normas
 IEEE 802
 X.25

Técnicas de transmissão
 Banda larga
 Banda base

Modelagem de rede de computadores segundo

Tanenbaum
Uma rede pode ser definida por seu tamanho, topologia, meio físico e protocolo
utilizado.

 PAN (Personal Area Network, ou rede pessoal). Uma PAN é uma rede de
computadores usada para comunicação entre dispositivos de computador (incluindo
telefones e assistentes pessoais digitais) perto de uma pessoa.
 LAN (Local Area Network, ou Rede Local). É uma rede onde seu tamanho se limita a
apenas uma pequena região física.

127
  VAN (Vertical Area Network, ou rede de vertical). Uma VAN é usualmente utilizada em
redes prediais, vista a necessidade de uma distribuição vertical dos pontos de rede.
 CAN (Campus Area Network, ou rede campus). Uma rede que abrange uma área mais
ampla, onde pode-se conter vários prédios dentro de um espaço continuos ligados em
rede. Esta segundo Tanenbaum em seu livro "Redes de computadores" é uma LAN,
justamente porque esta área dita ampla, quando muito grande abrange 10 quarteirões
ou aproximadamente 2.500m quadrados. Essa é pequena quando comparado a uma
cidade. Logo CAN não é senão Car Area Net. onde funciona o software local, regulando
motores e seus componentes eletronicos.
 MAN (Metropolitan Area Network, ou rede metropolitana). A MAN é uma rede onde
temos por exemplo, uma rede de farmácias, em uma cidade, onde todas acessam uma
base de dados comum.
 WAN (Wide Area Network, ou rede de longa distância). Uma WAN integra
equipamentos em diversas localizações geográficas (hosts, computadores,
routers/gateways, etc.), envolvendo diversos países e continentes como a Internet.
 SAN (Storage Area Network, ou Rede de armazenamento). Uma SAN serve de conexão
de dispositivos de armazenamento remoto de computador para os servidores de
forma a que os dispositivos aparecem como locais ligados ao sistema operacional.

Topologia
Ver artigo principal: Topologia de rede

Topologia em Estrela

Ver artigo principal: Rede em estrela

Topologia de rede em estrela

Neste tipo de rede, todos os usuários comunicam-se com um nodo (nó) central, tem o
controle supervisor do sistema, chamado host. Por meio do host os usuários podem se
comunicar entre si e com processadores remotos ou terminais. No segundo caso, o host
funciona como um comutador de mensagens para passar dados entre eles.

128
O arranjo em estrela é a melhor escolha se o padrão de comunicação da rede for de um
conjunto de estações secundárias que se comunicam com o nó central. As situações nas
quais isso acontece são aquelas em que o nó central está restrito às funções de gerente
das comunicações e a operações de diagnósticos.

O gerenciamento das comunicações por este nó central pode ser por chaveamento de
pacotes ou de circuitos.

O nó central pode realizar outras funções além das de chaveamento e processamento

normal. Por exemplo, pode compatibilizar a velocidade de comunicação entre o
transmissor e o receptor. Se o protocolo dos dispositivos fonte e destino for diferente, o
nó central pode atuar como um roteador, permitindo duas redes de fabricantes diferentes
se comunicar.

No caso de ocorrer falha em uma estação ou na ligação com o nó central, apenas esta
estação fica fora de operação.

Entretanto, se uma falha ocorrer no nó central, todo sistema pode ficar fora do ar. A
solução deste problema seria a redundância, mas isto acarreta um aumento considerável
de custos.

A expansão de uma rede desse tipo só pode ser feita até um certo limite, imposto pelo
nó central: em termos de capacidade de chaveamento, número de circuitos concorrentes
que podem ser gerenciados e números de nós que podem ser servidos.

O desempenho obtido numa rede em estrela depende da quantidade de tempo requerido

pelo nó central para processar e encaminhar mensagens, e da carga de tráfego de
conexão, ou seja, é limitado pela capacidade de processamento do nó central.

Esta configuração facilita o controle da rede e a maioria dos sistemas de computação

com funções de comunicação; possuem um software que implementa esta configuração.

Topologia em Barramento ou bus

Ver artigo principal: Rede em bus

Topologia de rede em barramento - Simples

Ela consiste em estações conectadas através de um circuito fechado, em série, formando

um circuito fechado (anel). O anel não interliga as estações diretamente, mas consiste de

129
uma série de repetidores ligados por um meio físico, sendo cada estação ligada a estes
repetidores. É uma configuração em desuso.

Topologia em Anel

Ver artigo principal: Rede em anel

Topologia de rede em anel

A topologia em anel como o próprio nome diz tem um formato circular.

Meio físico
O meio mais utilizado hoje é o Ethernet. O padrão Ethernet vem subdividido em:
Coax/10base2, UTP (Unshielded Twisted Pair - Par Trançado Não Blindado)/10BaseT
e UTP/100baseT e Gigabit ethernet.

Também pode ser conectado por Fibra óptica, um fino filamento contínuo de vidro com
uma cobertura de proteção que pode ser usada para conectar longas distâncias.

E ainda há as redes sem fios, que se subdividem em diversas tecnologias: Wi-fi,

bluetooth, wimax e outras.

Protocolo
Hoje, o protocolo mais usado é o TCP/IP, versão IPv4, e espera-se que passemos a
utilizar o IPv6.

Referências
1. Mendes, Douglas Rocha. Redes de Computadores. Em Livraria Cultura
2. http://blog.wolkartt.com/

Bibliografia
 Redes de Coputadores Locais e de Longa Distância, Autor: Liane M. R. Tarouco, 1986,
Editora McGraw-Hill, ISBN 0-07-450477-0

130
  Pequenas Redes com Microsoft Windows, Para Casa e Escritório, Autor: João Eriberto
Mota Filho, 2001, Editora Ciência Moderna, ISBN 85-7393-134-5

Virtualização
Origem: Wikipédia, a enciclopédia livre.

Em computação, virtualização é a simulação de uma plataforma de hardware, sistema

operacional, dispositivo de armazenamento ou recursos de rede.

Cada vez mais empresas estão buscando formas de reduzir os custos e complexidade
com o ambiente de TI. A virtualização se tornou um componente chave para o
desenvolvimento de uma estratégia eficiente na busca destes objetivos. Dentre os
desafios enfrentados nos datacenters podemos destacar:

 datacenters atingiram a capacidade máxima;

 servidores subutilizados;
 gerenciamento e Segurança complexa dos servidores;
 hardware e sistemas legados;
 problemas de compatibilidade de aplicações.

O que é virtualização?
Virtualização, basicamente, é a técnica de separar aplicação e sistema operacional dos
componentes físicos. Por exemplo, uma máquina virtual possui aplicação e sistema
operacional como um servidor físico, mas estes não estão vinculados ao software e pode
ser disponibilizado onde for mais conveniente. Uma aplicação deve ser executada em
um sistema operacional em um determinado software. Com virtualização de aplicação
ou apresentação, estas aplicações podem rodar em um servidor ou ambiente centralizado
e ser deportada para outros sistemas operacionais e hardwares. 1 2

Soluções de virtualização
Abaixo, as formas mais comuns de virtualização:

 virtualização de servidor — técnica de execução de um ou mais servidores virtuais

sobre um servidor físico; permite maior densidade de utilização de recursos
(hardware, espaço e etc), enquanto permite que isolamento e segurança sejam
mantidos;
 virtualização de aplicação — a virtualização de aplicação permite executar aplicações
em um ambiente virtualizado no desktop do usuário, isolando a aplicação do Sistema
Operacional; isso é possível através do encapsulamento da aplicação no ambiente
virtual — quando a solução completa de virtualização de aplicações é implantada, é
possível distribuir aplicações de um servidor central;
 virtualização de desktop — consiste na execução de múltiplos sistemas operacionais
em uma única workstation e permitindo que uma aplicação de linha de negócio seja
executada em um sistema operacional não compatível;

131
  virtualização de apresentação — a virtualização de apresentação permite executar e
manter o armazenamento das aplicações em servidores centralizados, enquanto provê
uma interface familiar para o usuário em sua estação.
 Infraestrutura de desktop virtual (Virtual Desktop Infrastructure - VDI) — o VDI
permite que você hospede máquinas virtuais cliente em uma estrutura de virtualização
como virtualização de servidores.
 virtualização de perfil — com a virtualização de perfil, os usuários podem ter os
documentos e perfil separados de uma máquina específica, o que permite a fácil
movimentação do usuário para novas estações em caso de roubo ou quebra de
equipamento; a virtualização de perfil também permite ter uma experiência de
desktop única quando utilizando outras tecnologias de virtualização, como VDI.

Um dos componentes críticos para a implantação de um projeto de virtualização,

independente da tecnologia utilizada, são as ferramentas de gerenciamento. As
ferramentas que gerenciam o ambiente Virtual devem gerenciar tanto o ambiente físico
como o virtual, assim como Sistema Operacional e Aplicações.

Lista de implementações de máquinas virtuais

Em soma aos métodos de virtualização portável descritas acima, as máquinas virtuais
são usualmente utilizadas como modelo de execução para linguagens individuais de
script. Esta tabela descreve as implementações de máquinas virtuais, ambos da categoria
de máquinas virtuais portáveis e máquinas virtuais de linguagens de script.

Compila Linguagem
Linguagen Interpreta Linhas de
Máquina virtual Comentários ção Just implementa
s dor códio fonte
in Time ção

interactive web
authoring tool.
ActionScri
Adobe Flash bytecode is 135k
pt, SWF
Player (aka named Sim Sim C++ (initially
(formato
Tamarin) "ActionScript released)
ficheiro)
Byte Code
(.abc)"

Erlang,
Reia, Lisp There exists a
BEAM Flavoured native-code Sim Não C 247k
Erlang, compiler, HiPE.
Elixir

Clipper,
Clipper p-code plankton, HVM Sim Não C
Harbour

132
 Compila Linguagem
Linguagen Interpreta Linhas de
Máquina virtual Comentários ção Just implementa
s dor códio fonte
in Time ção

15k + 2850
Dis Virtual
per JIT arch +
Dis (Inferno) Limbo Machine Sim Sim C
500 per host
Specification
OS

Linguagen
s de Clone of
DotGNU/Portabl programa Common
Não Sim C, C#
e.NET ção CLI Language
incluindo: Runtime
C#

Funções estão
simplificadas,
normalmente
contêm
assemblador,
compilador,
interpretadores
de nível-textos e
2.8K to 5.6K;
nível-binarios,
advanced,
algumas vezes
Forth, Forth professional
Forth Forth com editor, Sim Não
Assembler implementat
debugador e
ions are
sistema
smaller.
operativo.somet
imes editor,
debugger and
OS. Compilation
speeds are >20
SKLOC/S and
behave much
like JIT.

Glulx, Z-
Glulx
code

Icon Icon

Java, Reference JDK, JVM contêm

JVM Jython, implementation Sim Sim OpenJDK & cerca de
Groovy, by Sun ; IcedTea 6500k linhas;

133
 Compila Linguagem
Linguagen Interpreta Linhas de
Máquina virtual Comentários ção Just implementa
s dor códio fonte
in Time ção

JRuby, C, OpenJDK: code com JIT TCK é 80k de

C++, under GPL ; regular : testes e têm
Clojure, IcedTea: code Java, C, cerca de
Scala e e and tools under ASM ; 1000k linhas
outros GPL IcedTea
com o
"Zero" JIT :
Java, C

MSIL, C and C++

output are
supported.
ActionScript
Byte Code
C, C++, output is
Objective- supported by
LLVM C, Ada, Adobe Alchemy. Sim Sim C++ 811k 3
and bytecode is
Fortran named "LLVM
Bytecode (.bc)".
assembly is
named "LLVM
Assembly
Language (*.ll)".

13k + 7k
Lua Lua Sim LuaJIT C
LuaJIT

MMIX MMIXAL

CLI
languages
including:
clone do
C#,
Common
Mono VB.NET, Sim Sim C#, C 2332k
Language
IronPytho
Runtime.
n,
IronRuby,
e outros

Oz Oz, Alice

134
 Compila Linguagem
Linguagen Interpreta Linhas de
Máquina virtual Comentários ção Just implementa
s dor códio fonte
in Time ção

currently
NekoVM Neko and Sim x86 only C 46k
haXe

O-code machine BCPL

UCSD Pascal,
muito utilizado
no final da
UCSD p-System Pascal
década de 1970
incluindo o
Apple II

Perl (6 &
5), NQP-
rx, PIR,
PASM,
PBC,
BASIC, bc,
C, 111k C,
Parrot Sim Sim C, Perl
ECMAScri 240k Perl
pt, Lisp,
Lua, m4,
Tcl,
WMLScrip
t, XML, e
outros

Perl virtual op-code tree 175k C,

Perl Sim Não C, Perl
machine walker 9k Perl

387k C,
368k Python,
CPython Python Sim Psyco C
10k ASM,
31k Psyco

Self-hosting
implementation
PyPy Python of Python, next Sim Sim Python
generation of
Psyco

135
 Compila Linguagem
Linguagen Interpreta Linhas de
Máquina virtual Comentários ção Just implementa
s dor códio fonte
in Time ção

para outra
implementação
Rubinius Ruby Virtual machine Sim Sim C++, Ruby
for another
Ruby

A Micro-version
of Microsoft
.NET Framework
C#, 7MB (initially
Silverlight to let Sim Sim C++
VB.NET released)
applications run
sandboxed
inside browser

SEAM Alice

Computer game
ScummVM Scumm
engine

ISWIM,
SECD Lispkit
Lisp

Squirrel_
Squirrel Squirrel Sim C++ 12k
JIT

Smalltalk Smalltalk

SQLite Virtual database

SQLite
opcodes engine

Self hosting
implementation
110k
Squeak of Squeak Cog[1] & Smalltalk/Sl
Squeak Sim Smalltalk,
Smalltalk virtual machine. Exupery ang
~300K C
Rich multi-
media support.

TaoGroup Proprietary
C, Java
VP/VP2 embedded VM

TraceMonkey JavaScript Based on Não Sim C++ 173k

136
 Compila Linguagem
Linguagen Interpreta Linhas de
Máquina virtual Comentários ção Just implementa
s dor códio fonte
in Time ção

Tamarin

Motor
TrueType TrueType visualização de Sim Não C (típico)
fontes

Verificando
acessos de
x86/x86-
memória e
Valgrind 64 C 467k 4
falhas de
binaries
indicadores
sobre o Linux

VisualWorks Smalltalk Não Sim C

JVM and CLI

VMKit virtual machine Não Sim
based on LLVM.

Application-
Vx32 virtual x86 level
Não Sim
machine binaries virtualization for
native code

Virtual machine
for small
Waba
devices, similar
to Java

Virtual machine
of the reference
Yet Another
Ruby implementation Sim Sim C
Ruby VM (YARV)
for Ruby 1.9 and
newer versions

Z-machine Z-Code

Zend Engine PHP Sim Não C 75k

libJIT Library for Common Virtual machine C, ia32,

Just-In-Time Intermedi is used in Sim Sim arm,
compilation ate Portable.NET amd64,

137
 Compila Linguagem
Linguagen Interpreta Linhas de
Máquina virtual Comentários ção Just implementa
s dor códio fonte
in Time ção

Language Just-In-Time alpha, low-

Java compiler, ILDJIT, level CPU
bytecode HornetsEye architecture
Domain- specific
specific machine
programm code
ing
language

Referências
1. Virtualization in education (PDF) (em ingles). IBM (Outubro 2007).
2. Microsoft, VMware, Citrix Battle for Hypervisor Cloud | Virtualization (em ingles).
ITBusinessEdge.com. Página visitada em 2010-12-10.
3. A infraestrutura compilador LLVM, ohloh.net, 2011 Nov 30
4. Valgrind, ohloh.net, 2011 Nov 30.

Bibliografia
 VMware paravirtualization
 Guia Virtualização

138